Login
Newsletter
Werbung

Do, 26. Mai 2011, 15:00

Webzugriff

Was passiert dabei im Detail?

Normalerweise muss man nicht im Detail wissen, wie ein Browser auf eine Webseite zugreift. Die genaue Kenntnis der Vorgänge kann jedoch bei der Fehlersuche eine große Hilfe sein.

Einleitung

Das Zusammenspiel von DNS, Protokollen und Proxys soll hier exemplarisch am Zugriff auf eine Webseite gezeigt werden. Dabei ist hoffentlich alles enthalten: Zerlegen der URL, Finden des Servers, Holen der Seite und anschließende Darstellung.

Der verwendete Testaufbau sieht so aus:

Testaufbau

Dirk Geschke

Testaufbau

Zerlegen der URL

Der erste Schritt besteht in der Analyse der URL, so wird diese in die drei wichtigen Bestandteile Protokoll, Servername und Pfad auf dem Zielsystem zerlegt. Beim Protokoll wird gewöhnlich HTTP verwendet. Wird kein Port angegeben, so ist es der www-Port oder auch der http-Port, das ist ein Alias, wie in /etc/services definiert:

www             80/tcp          http            # WorldWideWeb HTTP
www             80/udp                          # HyperText Transfer Protocol

Definiert sind die Services in der Regel immer für beide Protokolle, also TCP und UDP. Nur wird wohl keiner jemals UDP für HTTP verwenden.

Neben HTTP wird oft noch HTTP over SSL/TLS verwendet, das wird durch https angegeben. Dabei wird zwischen dem Transportprotokoll TCP und HTTP noch eine Verschlüsselungsschicht eingebaut. Dann gibt es oft noch FTP, dann wird ganz normal Port 21 verwendet. Aber auch der Zugriff auf lokale Dateien ist mit file möglich.

Nach dem Protokoll folgt ein Doppelpunkt und zwei Slashes ://, bis zum nächsten Slash folgt dann der Servername, gefolgt vom Pfad auf dem Zielsystem. Also bei

http://www.lug-erding.de/index.html

ist HTTP das Protokoll, www.lug-erding.de der Servername und index.html der Pfad zu den Daten auf dem Zielsystem. Gewöhnlich kann index.html weggelassen werden, dann besteht der Pfad nur aus einem »/«. Der Webserver liefert dann in aller Regel die Datei index.html aus, oder eine Lokalisierung wie z.B. index.html.de, falls der Browser die deutsche Sprache bevorzugt.

Wer sich schon einmal gewundert hat, warum der Browser beim Zugriff auf lokale Dateien drei Slashes in die URL einbaut, hat nun die Antwort: Der Servername ist leer. Andernfalls würde er den ersten Pfadteil als Servernamen interpretieren. Das ergibt bei file natürlich keinen Sinn.

Die URL für den lokalen Dateizugriff könnte also so aussehen:

file:///home/geschke/WEB/index.html

Auch die Protokollnamen, TCP oder UDP, also das nächst höhere Protokoll nach IP, kann in die entsprechenden Zahlenwerte per /etc/protocols aufgelöst werden:

tcp     6       TCP             # transmission control protocol
udp     17      UDP             # user datagram protocol

TCP ist also das IP-Protokoll 6, UDP hat die Nummer 17. Es ist auch später entstanden und deutlich einfacher als TCP.

Proxy finden

Ein Browser kann natürlich versuchen, die Seite direkt vom Server zu laden, es ist aber auch möglich, die Seite über einen (Caching-) Webproxy zu holen. Das kann den Vorteil haben, dass Daten dort im Cache liegen können oder auch einfach nur verschiedene Wege zu den Servern hier zentral gepflegt werden können. Auch besteht hier die Möglichkeit, zentral den Zugriff zu reglementieren.

Wenn der Browser für den Gebrauch eines Proxys konfiguriert ist, so muss er auch wissen, welchen Proxy er wann verwenden soll. Da gibt es mehrere Möglichkeiten:

  1. Keinen Proxy verwenden
  2. Manuelle Proxy-Konfiguration, also Angabe von der Adresse und Port
  3. Automatische Proxy-Konfiguration via URL, PAC-Datei
  4. Proxy-Einstellungen des Systems, Environment-Variablen wie http_proxy, ftp_proxy oder https_proxy
  5. Proxy-Einstellungen über das Netzwerk automatisch erkennen, wpad.dat

Bei der PAC-Datei und wpad.dat wird ein kleines Java-Programm geladen, über dieses können verschiedene Proxys je nach Art der URL verwendet werden. Bei der manuellen Konfiguration kann man nur einen Proxy angeben, es besteht aber die Möglichkeit, dass man Ausnahmen definiert. Diese werden dann direkt vom Server bezogen und nicht via Proxy.

Die via Netzwerk automatisch erkannten Proxy-Einstellungen können über vielfache Wege ermittelt werden, das kann das Suchen nach einem Webserver in der eigenen Domain oder via DHCP oder DNS bedeuten. Genauer kann man es bei Wikipedia nachlesen.

Hier wird aber auch mitunter der nächste Schritt schon relevant: Die Namensauflösung. Gerade wenn Namen und Ausnahmen für IP-Adressen verwendet werden oder die PAC-Datei auf Basis von IP-Adressen den zuständigen Proxy bestimmen will, so wird auch eine Namensauflösung benötigt. Hier wird DNS notwendig. Ein Vorteil eines Proxys, dass man das DNS leichter konfigurieren kann.

Sollte man also beim Surfen immer eine Verzögerung von 5-10 Sekunden bei Erstzugriffen merken, dann könnte es an der fehlerhaften Namensauflösung liegen. Das ist der typische Zeitraum, wann der Resolver aufgibt und der Browser einfach alles über den definierten Default-Proxy abwickelt.

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