Um dem Domain-Namen des gesuchten Webservers die passende IP-Adresse zuzuordnen befragt der Client einen DNS-Server. Diesen Vorgang bezeichnet man als DNS-Lookup. Der vorkonfigurierte DNS-Server speichert allerdings nur einige Einträge so dass er in der Regel einen anderen DNS-Server befragen muss (rekursives DNS-Lookup). Der übergeordnete DNS-Server für eine Domain wird als autoritativer DNS-Server bezeichnet. Eine „nicht autoritative“ Antwort ist bereits ausreichend, um eine Routingstrecke zum gesuchten Ziel zu bestimmen.
Ein DNS-Lookup können Sie in der Kommandozeile auslösen. Hier einmal wieder am Beispiel der Domain google.de (man beachte den Punkt am Ende der letzten Befehlszeile):
[www:~] user% nslookup > set recursive > server www.google.de.
Die Anfrage fördert als Antwort eine Reihe von Servern und die zugehörigen IP-Adressen zu Tage, zum Beispiel:
Default Server: www.google.de Address: 74.125.228.255
Bei Bedarf liefert das Kommando „set debug“ (im interaktiven Modus von nslookup) zusätzliche Informationen zu anderen verfügbaren Servern. Die Dauer der Abfrage lässt sich am besten mittels dig (statt nslookup) ermitteln. Sie wird in der Zeile:
;; Total query time:
in Milisekunden (ms) angegeben. Zusätzliche Informationen liefert die Anforderung von „start of authoority“ (soa):
[www:/Users/user] root# dig soa www.google.de ; <<>> DiG 8.3 <<>> soa www.google.de [...] ;; STION SECTION: ;; www.google.de, IN SOA ;; AUTHORITY SECTION: google.de. 5 IN SOA ns2.google.com. dns-admin.google.com. 108188305 900 900 1800 60 ;; Total query time: 55 msec [...]
Der DNS-Server in dem Netz des Clients speichert das Ergebnis seiner Ermittlungen für eine vordefinierte Zeitspanne, um sie danach wieder zu löschen. Die Antwortzeit kann also bei der ersten Abfrage deutlich höher ausfallen als der Durchschnitt der Folgeversuche. Die wertvollsten Informationen liefert die erste Ermittlung. Ein DNS-Lookup im Cache des lokalen Servers benötigt natürlich weniger Zeit als ein Web-Besucher in dieser Phase investieren muss. Entsprechend unterschiedlich fallen die gesamten messbaren Wartezeiten aus.
Der erste DNS-Lookup nach www.google.es (Ziel: die iberische Halbinsel) wurde im Test binnen von 145 msec bewältigt. Die erste Abfrage von www.google.com (das amerikanische Kontinent) nahm mittels dig im Beispiel 92 msec in Anspruch. Dieselbe Abfrage war im Falle von www.google.de bereits nach 20 msec abgeschlossen (der autoritative DNS-Server war nur wenige Kilometer entfernt). Bei wiederholten Versuchen schwankte die Wartezeit zwischen 20 und 120 msec interessanterweise unabhängig von der geografischen Lage des gesuchten Zielservers, weil die DNS-Informationen bereits im Cache gesischert wurden. Oft besuchte Webserver profitieren also bereits beim DNS-Lookup von ihrer Bekanntheit.
Dieses simple Beispiel illustriert, dass das Heranholen von Daten von anderen Domains (wie etwa ein Börsenticker) und Umleitungen des Browsers (Redirections) spürbare und vor allem unnötige Verzögerungen verursachen. Bereits die Suche der Zieladresse nimmt ein messbares Zeitintervall in Anspruch. Die Topologie der Netzinfrastruktur beeinflusst die Performance.
Nach dem abgeschlossenen DNS-Lookup wird nun anhand der ermittelten IP-Adresse die optimale Strecke zum gesuchten Server ermittelt, indem die vorhandenen Routing-Tabellen auf dem Weg zum Ziel zu Rat gezogen werden. Die Datenpakete wandern dann schrittweise zum Empfänger und – sollten sie unterwegs zu Schaden kommen – durch den Client erneut angefordert (nur im Falle von TCP, nicht bei UDP). In dieser Phase können für die Diagnose der Netzwerkverbindung Tools wie traceroute, ping oder spray behilflich sein. Der Befehl:
[www:~] user% ping -c 100 -q xxx.71.104.20 PING xxx.71.104.20 (xxx.71.104.20): 56 data bytes --- xxx.71.104.20 ping statistics --- 100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max = 87.34/96.165/137.007 ms
lieferte einen Wert in Milisekunden als die durchschnittliche Antwortzeit vom Server google.de bei einem Versuch mit 100 Datenpaketen von 56 Bytes (gemessen wird der Weg hin- und zurück). Mit der Option [-s] kann man die Größe der Datenpakete variieren, um mit der Antwortsbereitschaft des Servers zu experimentieren. Netzwerk-Diagnosetools sollte man mit Bedacht verwenden insbesondere wenn man Skripte einsetzt (es besteht Gefahr, versehentlich einen DoS-Angriff auszulösen wenn sich ein Skript nicht beenden sollte; Letzteres könnte Ihren Hosting-Account terminieren!).