Dlaczego opóźnienie DNS sprawia, że aplikacja serwera domowego działa wolno w sieci LAN?

Aplikacja serwera domowego może wydawać się wolna w szybkiej sieci LAN, ponieważ klient może musieć rozwiązać nazwę hosta, zanim rozpocznie nowe połączenie. Jeśli to wyszukiwanie czeka na pustą pamięć podręczną, niedostępny resolver lub ścieżkę zapasową, przerwa następuje zanim aplikacja zdąży odpowiedzieć.

To nie oznacza, że DNS działa przed każdym żądaniem HTTP lub zmniejsza przepustowość ustanowionego połączenia. DNS jest najbardziej widoczny, gdy klient potrzebuje nowego wyniku adresu lub nowego połączenia, dlatego pierwsze ładowanie może wydawać się wolne, a późniejsza nawigacja normalna.

Opóźnienia DNS wydłużają start połączenia, nie każde żądanie aplikacji

Gdy przeglądarka lub klient otwiera nazwę hosta, jego resolver musi zwrócić adres, którego może użyć stos sieciowy. Model resolvera DNS pozwala, aby odpowiedź pochodziła z pamięci podręcznej lub z jednego lub więcej serwerów nazw, więc czas wyszukiwania może się różnić, nawet jeśli docelowy serwer nigdy się nie zmienia.

Gdy adres i połączenie są dostępne, późniejsze żądania mogą je ponownie wykorzystać. HTTP/2, na przykład, kojarzy wymiany żądań i odpowiedzi z niezależnymi strumieniami na połączeniu; to multipleksowanie strumieni HTTP/2 jest jednym z powodów, dla których wiele zasobów nie wymaga osobnego połączenia i wyszukiwania DNS.

Sieć LAN ułatwia zauważenie różnicy. Transfer danych i rundy serwera mogą być krótkie, podczas gdy ponowne próby resolvera lub ścieżka zapasowa pozostają osobnym oczekiwaniem przed nimi. Użytkownik doświadcza łącznego czasu i może obwiniać aplikację, pamięć masową lub sieć, mimo że opóźnienie wystąpiło zanim ruch aplikacji się rozpoczął.

Jak rozwiązywana jest nazwa hosta serwera domowego w sieci LAN

Pamięci podręczne przeglądarki i systemu operacyjnego

Klient może już posiadać użyteczny wynik adresu. Trafienie w pamięć podręczną może wyeliminować potrzebę wymiany DNS w sieci, podczas gdy wygasły lub brakujący wpis wysyła żądanie dalej wzdłuż ścieżki rozwiązywania. Pamięci podręczne przeglądarki, systemu operacyjnego i resolvera rekurencyjnego to oddzielne warstwy, więc ich stan nie zawsze zmienia się jednocześnie.

Skonfigurowany resolver LAN

Gdy lokalne dane w pamięci podręcznej są niedostępne, klient zwykle pyta skonfigurowany resolver, którym może być router, dedykowana lokalna usługa DNS lub inny rekurencyjny resolver. Ten resolver może odpowiedzieć z autorytatywnej lokalnej strefy, z własnej pamięci podręcznej lub kontynuować zapytanie gdzie indziej. To, że serwer znajduje się w sieci LAN, nie gwarantuje, że każdy zaangażowany resolver jest równie blisko lub działa poprawnie.

Domeny wyszukiwania, mDNS i ścieżki zapasowe

Krótkie nazwy hostów i nazwy kończące się na .local mogą korzystać z różnych mechanizmów. zasady multicast DNS dla nazw .local kierują te zapytania do multicastu link-local, podczas gdy implementacje mogą jednocześnie używać innych mechanizmów. Sufiksy wyszukiwania i zachowanie zapasowe mogą więc dodawać próby, których zwykłe opisy unicast DNS nie uwzględniają.

Braki w pamięci podręcznej i limity czasu resolvera powodują różne przerwy

Brak w pamięci podręcznej nie jest automatycznie błędem. Oznacza, że odpowiedź musi zostać uzyskana z innego źródła, więc pierwsze wyszukiwanie może trwać dłużej niż wyszukiwanie z pamięci podręcznej. Limit czasu jest inny: resolver nie otrzymał użytecznej odpowiedzi w czasie oczekiwania i może spróbować ponownie z innym serwerem lub transportem.

Aktualne wytyczne dotyczące błędów i ponownych prób DNS rozróżniają błędy, niedostępne serwery, ponowne próby i buforowane błędy. Zauważa też, że identyczne oczekujące zapytania mogą być łączone zamiast wysyłane jako niezależne zapytania upstream, dlatego opóźnienia DNS nie powinny być mechanicznie mnożone przez liczbę zasobów aplikacji.

Widoczny wzorzec jest często bardziej informacyjny niż pojedyncza średnia. Konsekwentnie małe opóźnienie pierwszego ładowania, opóźnienie zimnej pamięci podręcznej i nieregularna długa przerwa wskazują na różne stany i nie powinny być grupowane pod jedną ogólną etykietą „wolny DNS”.

Jeden ekran aplikacji może obejmować kilka nazw hostów

Lokalny pulpit może ładować swój główny dokument z jednej nazwy hosta, jednocześnie kontaktując się z innymi nazwami dla API, punktu końcowego WebSocket, usługi tożsamości, wtyczki, czcionki, obrazu okładki lub sprawdzenia aktualizacji. Tylko główna aplikacja musi być lokalna, aby ekran wyglądał na lokalny; jej graf zależności może nadal obejmować kilka źródeł.

Każde nowe źródło może stworzyć kolejną możliwość rozdzielczości i połączenia, ale opóźnienia niekoniecznie sumują się liniowo. Przeglądarki mogą wykonywać zadania równocześnie, resolverzy mogą buforować lub łączyć pasujące zapytania, a wiele zasobów z tego samego źródła może korzystać z jednego połączenia.

Praktyczne pytanie brzmi więc nie „Ile plików jest na stronie?”, lecz „Ile różnych nazw i nowych ścieżek połączeń jest potrzebnych, zanim interfejs stanie się użyteczny?” Małe, ale blokujące zależności API mogą mieć większe znaczenie niż wiele obrazów ładowanych później równolegle.

Dlaczego pierwsze ładowanie może być wolne, a odświeżenia wydają się szybkie

Pierwsza wizyta może obejmować wyszukiwanie DNS, nowe połączenie TCP, uścisk dłoni TLS, uwierzytelnianie i początkową pracę aplikacji. Odświeżenie może korzystać jednocześnie z pamięci podręcznej adresów, istniejących połączeń, wpisów pamięci podręcznej HTTP i rozgrzanych danych aplikacji.

To sprawia, że szybsze odświeżenie jest użyteczną wskazówką, a nie dowodem, że DNS był jedyną przyczyną. Aby wyizolować DNS, faza wyszukiwania musi być oddzielona od nawiązywania połączenia i odpowiedzi serwera, zamiast traktować całą różnicę pierwszego ładowania jako czas resolvera.

Lokalizacja resolvera ma największe znaczenie, gdy nazwa jest lokalna

Lokalna nazwa hosta wymaga mechanizmu rozwiązywania, który rozumie jej przestrzeń nazw. Lokalna strefa autorytatywna, podzielony DNS lub nazwa mDNS mogą utrzymać odpowiedź powiązaną z siecią LAN, podczas gdy ogólny publiczny resolver może nie mieć rekordu dla tej wewnętrznej nazwy.

To nie oznacza, że każda lokalna nazwa hosta wysłana do zewnętrznego resolvera odbywa powolną podróż i ostatecznie się powiedzie. W zależności od nazwy i konfiguracji wynik może być natychmiastową negatywną odpowiedzią, ponowną próbą lub przejściem do innego mechanizmu. Lokalizacja resolvera ma znaczenie, ponieważ zmienia, który system może poprawnie odpowiedzieć, a nie tylko dlatego, że jeden serwer jest fizycznie bliżej.

DNS nie jest jedynym źródłem wolnej pierwszej odpowiedzi

Uruchomienie aplikacji, zapytania do bazy danych, operacje I/O na pamięci masowej, routing reverse-proxy, uwierzytelnianie i TLS mogą opóźniać pierwszą widoczną odpowiedź po zakończeniu rozwiązywania nazwy. Jeśli nazwa hosta i kontrolowany test oparty na adresie są równie wolne, wąskie gardło jest mniej prawdopodobne w DNS.

Porównanie oparte na adresie również ma ograniczenia. Certyfikaty HTTPS i hosting wirtualny zależą od nazw, a reverse proxy może kierować ten sam adres IP do różnych aplikacji w zależności od żądanej nazwy hosta. Nieudany lub różniący się zachowaniem test adresu nie jest czystym benchmarkiem DNS.

Używaj granicy objawów ostrożnie: DNS jest prawdopodobny, gdy opóźnienia skupiają się wokół niebuforowanego użycia nazwy, awarii resolvera lub nowych ścieżek połączeń. Jest mniej prawdopodobny, gdy czas wyszukiwania jest znikomy, ale czas do pierwszego bajtu pozostaje wysoki.

Oddziel czas DNS od czasu TCP, TLS i aplikacji

Przydatny łańcuch opóźnień to wyszukiwanie DNS, nawiązywanie połączenia, ustanawianie bezpiecznego połączenia, gdy ma to zastosowanie, rozpoczęcie żądania, rozpoczęcie odpowiedzi oraz transfer treści. Model fazowy Navigation Timing W3C udostępnia oddzielne znaczniki czasowe dla wyszukiwania domeny i połączenia, w tym przypadek, gdy informacje o domenie pochodzą z pamięci podręcznej.

Dla poszczególnych zasobów strony interfejs Resource Timing rozdziela fazy wyszukiwania, połączenia, żądania i odpowiedzi. Zasady prywatności cross-origin mogą ukrywać niektóre szczegóły, więc brakujące pola czasowe nie są automatycznie dowodem zerowego opóźnienia.

Ping i przepustowość kopiowania plików odpowiadają na różne pytania. Ping mierzy dostępność i zachowanie sieci podczas rundy; duży transfer mierzy ustaloną ścieżkę danych. Żaden z nich nie izoluje rozwiązywania nazw, które może mieć miejsce przed otwarciem pierwszego połączenia przez aplikację.

FAQ

Czy DNS wpływa na każdy klik w aplikacji serwera domowego?

Nie. DNS ma znaczenie, gdy klient potrzebuje rozwiązać nazwę dla nowego lub wygasłego wyniku. Pamięci podręczne adresów, trwałe połączenia i multipleksowane żądania pozwalają wielu interakcjom przebiegać bez nowego zapytania DNS w sieci.

Dlaczego aplikacja ładuje się szybciej po adresie IP niż po nazwie hosta?

Ominięcie nazwy hosta może usunąć rozwiązywanie nazw z tej ścieżki testowej, więc różnica może wskazywać na DNS. Nie jest to jednak rozstrzygające, ponieważ certyfikaty, wirtualne hosty, przekierowania i reguły reverse-proxy mogą powodować, że ścieżka adresu zachowuje się inaczej.

Czy mDNS może być wolniejszy niż zwykły lokalny DNS?

Może zachowywać się inaczej, ponieważ używa multicastu link-local i może współistnieć z innymi mechanizmami wyszukiwania. To, czy jest wolniejszy, zależy od klienta, sieci, nazwy, pamięci podręcznej i zachowania zapasowego, a nie od uniwersalnej kary mDNS.

Czy zmiana publicznego DNS przyspieszy rozwiązywanie nazw lokalnego serwera domowego?

Tylko jeśli ten publiczny resolver faktycznie jest częścią ścieżki udanej lub nieudanej. Nazwa przechowywana w lokalnej strefie lub rozwiązywana przez mDNS wymaga odpowiedniego lokalnego mechanizmu; zmiana niezwiązanego publicznego resolvera może nic nie zmienić.

Dlaczego aplikacja znowu zwalnia po restarcie lub długim okresie bezczynności?

Restart lub długi okres bezczynności mogą usunąć dane adresowe z pamięci podręcznej i zamknąć ponownie używalne połączenia, podczas gdy sama aplikacja może również stracić rozgrzane pamięci podręczne. Kolejne ładowanie może więc powtórzyć kilka etapów uruchamiania, nie tylko DNS.

Zmiany DNS wpływają na czas uruchamiania aplikacji, a nie na przepustowość domowego NAS

Niskie opóźnienia i niezawodne rozwiązywanie nazw mogą sprawić, że pierwsze połączenia i nowe zależności aplikacji będą bardziej responsywne, ale nie zwiększają prędkości dysku ani przepustowości ustalonego transferu LAN. Diagnozuj DNS na etapie przed rozpoczęciem połączenia, a następnie mierz osobno odpowiedzi TCP, TLS i aplikacji, zanim obwinisz serwer domowy.