Was genau passiert im Hintergrund, wenn Sie eine URL eingeben?

Als Softwareentwickler müssen Sie über ein vollständiges hierarchisches Verständnis der Funktionsweise von Netzwerkanwendungen verfügen, wozu auch die von diesen Anwendungen verwendeten Technologien gehören: Browser, HTTP, HTML, Netzwerkserver, Anforderungsverarbeitung usw.

In diesem Artikel wird genauer untersucht, was im Hintergrund passiert, wenn Sie eine URL eingeben.

Der erste Schritt bei der Navigation besteht darin, die IP-Adresse des Domänennamens herauszufinden, den Sie besuchen. Der DNS-Lookup-Prozess läuft wie folgt ab:

Die rekursive DNS-Suche wird in der folgenden Abbildung dargestellt:

Denn dynamische Seiten wie etwa die Startseite von Facebook verfallen nach dem Öffnen zeitnah oder sogar sofort in den Cache des Browsers und können diesen nicht auslesen.

Der Browser sendet daher die folgende Anfrage an den Facebook-Server:

 GET http://facebook.com/ HTTP/1.1
 Akzeptieren: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
 User-Agent: Mozilla/4.0 (kompatibel; MSIE 8.0; Windows NT 6.1; WOW64; [...]
 Akzeptierte Kodierung: gzip, deflate
 Verbindung: Keep-Alive
 Gastgeber: facebook.com
 Cookies: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

GET Diese Anfrage definiert die zu lesende URL : „http://facebook.com/“. Der Browser definiert sich selbst ( User-Agent- Header) und welche Art von Antworten er erhalten möchte (Accept- und Accept -Encoding -Header). Der Connection- Header fordert den Server auf, die TCP-Verbindung für nachfolgende Anfragen nicht zu schließen.

Die Anfrage umfasst auch die vom Browser für die Domain gespeicherten Cookies . Wie Sie wahrscheinlich bereits wissen, sind Cookies Schlüssel-Wert-Paare, die den Status einer Website über verschiedene Seitenanforderungen hinweg verfolgen. Auf diese Weise werden in Cookies der Anmeldebenutzername, das vom Server zugewiesene Passwort und einige Benutzereinstellungen gespeichert. Cookies werden im Client als Textdatei gespeichert und bei jeder Anfrage an den Server gesendet.

Neben den Get-Requests gibt es auch noch die Send-Request, welche häufig beim Absenden von Formularen zum Einsatz kommt. Senden Sie eine Anfrage mit Angabe ihrer Parameter über die URL (z. B.: http://robozzle.com/puzzle.aspx?id=85). Eine Sendeanforderung sendet ihre Parameter nach den Anforderungstext-Headern.

Wie in „http://facebook.com/“ ist der Schrägstrich entscheidend. In diesem Fall kann der Browser den Schrägstrich bedenkenlos hinzufügen. Bei einer Adresse wie „http://example.com/folderOrFile“ kann der Browser nicht automatisch einen Schrägstrich hinzufügen, da er nicht weiß, ob es sich bei folderOrFile um einen Ordner oder eine Datei handelt. An diesem Punkt greift der Browser direkt auf die Adresse ohne Schrägstrich zu und der Server antwortet mit einer Umleitung, was zu einem unnötigen Handshake führt.

Das Bild zeigt die Antwort, die der Facebook-Server an den Browser zurücksendet:

 HTTP/1.1 301 dauerhaft verschoben
 Cache-Steuerung: privat, kein Speichern, kein Cache, muss erneut validiert werden, Post-Check=0,
 Vorprüfung=0
 Läuft ab: Samstag, 01. Januar 2000, 00:00:00 GMT
 Standort: http://www.facebook.com/
 P3P: CP="DSP-GESETZ"
 Pragma: kein Cache
 Set-Cookie: made_write_conn=gelöscht; läuft ab=Do, 12.02.2009 05:09:50 GMT;
 Pfad=/; Domäne=.facebook.com; nur http
 Inhaltstyp: text/html; Zeichensatz=utf-8
 X-Connection: schließen
 Datum: Fr, 12. Februar 2010 05:09:51 GMT
 Inhaltslänge: 0

Der Server antwortet dem Browser mit einer 301 Permanent Redirect-Antwort, sodass der Browser „http://www.facebook.com/“ statt „http://facebook.com/“ besucht.

Jetzt weiß der Browser, dass „http://www.facebook.com/“ die richtige Adresse ist, und sendet eine weitere GET-Anfrage:

 GET http://www.facebook.com/ HTTP/1.1
 Akzeptieren: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
 Akzeptieren-Sprache: en-US
 User-Agent: Mozilla/4.0 (kompatibel; MSIE 8.0; Windows NT 6.1; WOW64; [...]
 Akzeptierte Kodierung: gzip, deflate
 Verbindung: Keep-Alive
 Cookies: lsd=XW[...]; c_user=21[...]; x-referer=[...]
 Gastgeber: www.facebook.com

Die Header-Informationen haben die gleiche Bedeutung wie in der vorherigen Anfrage.

Der Server empfängt die GET-Anfrage, verarbeitet sie und gibt eine Antwort zurück.

Auf den ersten Blick mag dies eine einfache Aufgabe sein, aber tatsächlich passieren dabei viele interessante Dinge – bei einer so einfachen Website wie dem Blog des Autors, ganz zu schweigen von einer Website mit so vielen Besuchern wie Facebook!

Im einfachsten Beispiel kann die Anforderungsverarbeitung in einer Dateihierarchie gespeichert werden, die die Struktur einer Website-Adresse abbildet. Beispielsweise wird die Adresse http://example.com/folder1/page1.aspx der Datei /httpdocs/folder1/page1.aspx zugeordnet. Die Webserver-Software kann so konfiguriert werden, dass Adressanforderungen manuell verarbeitet werden, sodass die Veröffentlichungsadresse von page1.aspx http://example.com/folder1/page1 lauten kann.

Die Abbildung zeigt die vom Server generierte und zurückgegebene Antwort:

 HTTP/1.1 200 OK
 Cache-Steuerung: privat, kein Speichern, kein Cache, muss erneut validiert werden, Post-Check=0,
 Vorprüfung=0
 Läuft ab: Samstag, 01. Januar 2000, 00:00:00 GMT
 P3P: CP="DSP-GESETZ"
 Pragma: kein Cache
 Inhaltskodierung: gzip
 Inhaltstyp: text/html; Zeichensatz=utf-8
 X-Connection: schließen
 Übertragungskodierung: chunked
 Datum: Fr, 12. Februar 2010 09:05:55 GMT

 2b3Tn@[...]

Die gesamte Antwortgröße beträgt 35 kB, wovon der Großteil nach dem Zuschneiden als Blob übertragen wird.

Der Content-Encoding -Header teilt dem Browser mit, dass der gesamte Antworttext mit dem Gzip-Algorithmus komprimiert werden soll. Nach dem Dekomprimieren des Blobs können Sie das erwartete HTML sehen:

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de"
 lang="de" id="facebook" class="no_js">
 <Kopf>
 <meta http-equiv="Inhaltstyp" content="text/html; charset=utf-8" />
 <meta http-equiv="Inhaltssprache" content="en" />
 ...

In Bezug auf die Komprimierung geben die Header-Informationen an, ob die Seite zwischengespeichert werden soll, wie dies im Falle einer Zwischenspeicherung erfolgen soll, welche Cookies gesetzt werden sollen (dies ist in der vorherigen Antwort nicht enthalten), Datenschutzinformationen usw.

Noch bevor der Browser das gesamte HTML-Dokument gelesen hat, beginnt er mit der Anzeige dieser Seite:

Wenn der Browser das HTML anzeigt, erkennt er die Tags, die den Inhalt anderer Adressen abrufen müssen. An diesem Punkt sendet der Browser eine Get-Anfrage, um die Dateien abzurufen.

Hier sind einige URLs, die wir erneut abrufen müssen, wenn wir facebook.com besuchen:

Diese Adressen durchlaufen einen Prozess, der dem Lesen von HTML ähnelt. Der Browser sucht also nach diesen Domänen im DNS, sendet die Anfrage, leitet um usw.

Im Gegensatz zu dynamischen Seiten können statische Dateien jedoch von Browsern zwischengespeichert werden. Einige Dateien müssen möglicherweise nicht mit dem Server kommunizieren und können direkt aus dem Cache gelesen werden. Die Antwort des Servers enthält Informationen darüber, wie lange statische Dateien aufbewahrt werden sollen, sodass der Browser weiß, wie lange er sie zwischenspeichern muss. Darüber hinaus kann jede Antwort einen ETag-Header enthalten (den Entity-Wert der angeforderten Variable), der wie eine Versionsnummer funktioniert. Wenn der Browser feststellt, dass die Versions-ETag-Informationen der Datei bereits vorhanden sind, stoppt er die Übertragung der Datei sofort.

Im Sinne des Web 2.0 bleibt der Client auch nach der Anzeige der Seite mit dem Server verbunden.

Nehmen wir als Beispiel die Chat-Funktion von Facebook: Sie bleibt mit dem Server in Verbindung, um den Status Ihrer hellen und grauen Freunde rechtzeitig zu aktualisieren. Um den Status dieser Freunde, deren Avatare leuchten, zu aktualisieren, sendet der im Browser ausgeführte JavaScript-Code eine asynchrone Anfrage an den Server. Diese asynchrone Anfrage wird an eine bestimmte Adresse gesendet und ist eine programmgesteuert erstellte Abruf- oder Sendeanfrage. Immer noch im Facebook-Beispiel sendet der Client eine Veröffentlichungsanforderung an http://www.facebook.com/ajax/chat/buddy_list.php, um die Online-Statusinformationen darüber abzurufen, welche Ihrer Freunde online sind.

Bei diesem Muster müssen wir von „AJAX“ sprechen – „Asynchronous JavaScript and XML“, obwohl es keinen klaren Grund gibt, warum der Server im XML-Format antwortet. Ein weiteres Beispiel: Bei asynchronen Anfragen gibt Facebook einige JavaScript-Codeausschnitte zurück.