Login
Newsletter
Werbung

Do, 26. Mai 2011, 15:00

Webzugriff

Was passiert dabei im Detail?

Fazit

Wir haben nun gesehen, was hinter einem einzelnen Mausklick im Browser alles passiert, welche Prozesse involviert sind. Wir sind sogar bis in die Paketebene hinuntergegangen und haben diverse Dinge beobachten können.

Gewöhnlich verschwendet man daran keinen Gedanken: Es funktioniert ja auch in der Regel recht gut. Warum sollte man also einen Gedanken daran verschwenden, was unter der Haube passiert? Die meisten werden es in der Regel nicht tun, geschweige denn sich einmal im Detail ansehen, was da wirklich passiert.

Auf der anderen Seite gibt einem das Verständnis aber ein wenig Sicherheit im Umgang mit den Internet-Diensten. Diesen Punkt hatten wir allerdings noch nicht betrachtet, ich hatte es erst überlegt: Sicherheit! Da wir nun alle im Detail wissen, was abläuft, kann man sich auch relativ einfach überlegen, wo überall etwas schief gehen kann und vor allem, wenn es einer mit Absicht macht.

Ich glaube aber, das wäre dann doch zu viel für diesen Artikel gewesen, daher habe ich den Punkt weggelassen. Vermutlich muss dafür das Wissen sich erst noch ein wenig festigen, bis man ein Auge dafür entwickelt, was man alles anstellen kann.

Wer aufgepasst hat, der weiß jetzt auch, wie sinnlos Websperren per DNS sein können: Sie treffen nur diejenigen, die sich nicht auskennen. Sonst nimmt man einfach einen anderen Nameserver, z.B. den von Google: 8.8.8.8. Wie soll man dessen Antworten nicht nur filtern, sondern auch noch ändern?

Oder soll mit den DNS-Sperren sämtlicher DNS-Verkehr geblockt werden, außer zum lokalen Provider? Das dürfte extrem schwer zu rechtfertigen sein. Wobei die T-Home das durchaus macht(e): Da war zumindest damals eine Abfrage des Google-Nameservers geblockt.

Warum alles fast immer so einwandfrei läuft, ist recht einfach erklärt: Das Internet ist in den mehr als 40 Jahren, die es existiert, darin gewachsen. Aber dennoch können immer wieder Probleme auftauchen, sie sind nur so selten, dass es einem meist nicht auffällt. Wenn mal eine Webseite nicht funktioniert, dann braucht man in der Regel nicht lange zu warten, bis das repariert wurde.

Und in vielen Fällen gibt es Redundanzen. So schreibt das DeNIC sogar vor, dass man wenigstens zwei Nameserver haben muss. Idealerweise sollten die auch nicht auf dem gleichen System sein, sie sollten nach Möglichkeit auch in unterschiedlichen Netzsegmenten liegen.

Man kann man mit DNS auch noch so einiges mehr anstellen, so wie es z.B. Akamai tut: Man kann die Zugriffe auf Webserver beschleunigen. Ein Verfahren dabei ist, dass Akamai weltweit Webserver für ihre Kunden betreibt und den Traffic auf den nächstgelegenen Webserver umleitet.

Wie machen die das? Ein Verfahren ist nun leicht zu verstehen, nehmen wir z.B. www.rtl2.de. Die Nameserveranfrage offenbart es:

www.rtl2.de.            3600    IN      CNAME   www.rtl2.de.edgesuite.net.

Das ist nicht ungewöhnlich, die Namensauflösung wird auf den rechten Namen weitergeleitet. Das ist ein Nameserver von Akamai. Dieser sieht nun, woher der Client kommt. Das dürfte nämlich von der IP-Adresse des ISPs kommen.

An Hand dieser Adresse kann Akamai nun feststellen, in welcher Region der Anfragende (vermutlich) sitzen wird. Um ihm dann den nächstgelegenen Server, möglichst der mit der geringsten Load, zuzuordnen, gibt es einen zweiten CNAME:

www.rtl2.de.edgesuite.net. 21600 IN     CNAME   a1195.g.akamai.net.

Für diese Namensauflösung muss nun ein Nameserver von Akamai befragt werden, der in der Nähe liegen sollte. Dieser weiß, welche Webserver die geringste Last haben, und liefert dessen IP-Adresse aus. Damit diese schnell reagieren können, ist die TTL des Nameserver-Eintrags recht kurz:

a1195.g.akamai.net.     20      IN      A       95.100.249.122
a1195.g.akamai.net.     20      IN      A       95.100.249.113

Das sind nur 20 Sekunden, nach dieser Zeit muss die Namensauflösung erneut angestoßen werden. Dann könnte z.B. die Antwort so aussehen:

a1195.g.akamai.net.     20      IN      A       77.67.20.18
a1195.g.akamai.net.     20      IN      A       77.67.20.41

Und offenbar muss sich das bei der Performance rechnen: Die zusätzlichen Namensauflösungen scheinen durch den Standortvorteil gerechtfertigt zu sein, zumindest ist Akamai gut im Geschäft...

Kommentare (Insgesamt: 6 || Alle anzeigen )
Java != JavaScript (Weinzierl Stefan, Mi, 1. Juni 2011)
Re: HTTP ueber UDP... (LSD-Derivat, Fr, 27. Mai 2011)
Tippfehler? (elGuerrillero, Fr, 27. Mai 2011)
Re: "Nur wird wohl keiner jemals UDP für HTTP verwenden." (frinky, Do, 26. Mai 2011)
"Nur wird wohl keiner jemals UDP für HTTP verwenden." (cweiske, Do, 26. Mai 2011)
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung