Seite 3: Was HTTP 1.1 gebracht hat

Inhaltsverzeichnis

HTTP 1.1 hat demgegenüber eine Verbesserung mitgebracht: Damit lässt sich bei Abrufen von mehreren Elementen von einem Host immerhin die TCP-Verbindung wiederverwenden (Connection:
Keep-alive). Wenn also immer nur ein Server die Elemente einer Webseite liefert, werden nach der Startphase nur noch HTTP-Pakete übermittelt. Deshalb benötigt HTTP 1.1 pro Request nur noch eine RTT
(zum Beispiel GET + Response).

Das spart zwar Zeit, aber bei modernen Webseiten, die aus vielen Elementen aufgebaut sind, sind immer noch viele Requests erforderlich und jeder Abruf dauert mindestens eine RTT. Der Browser versucht Zeit zu sparen, indem er nicht abwartet, bis er den jeweiligen Response des Servers komplett erhalten hat. Statt dessen feuert er seine Anfragen ab, sobald er aus dem einlaufenden HTML-Code herausgelesen hat, welche erforderlich sind.

HTTP 1.1 sieht sogar Pipelining vor, das heisst, der Client dürfte zeitsparenderweise über dieselbe TCP-Verbindung weitere Requests zum selben Host abfeuern, während ein aktueller noch in Arbeit ist. Doch das gilt als unzuverlässig und ist standardmäßig deaktiviert. Deshalb bauen die Browser mit HTTP 1.1 sicherheitshalber für jeden weiteren Request zum selben Host eine separate TCP-Verbindung auf. Das tun sie auch schon während die Daten des aktuellen Requests auf der ersten TCP-Verbindung eingehen, warten also nicht dessen Ende ab. Um die Server nicht zu stark zu belasten, dürfen Clients mit HTTP 1.1 nicht mehr als 6 bis 8 TCP-Verbindungen öffnen; für jeden Verbindungsaufbau vergeht wieder eine RTT.

Die Konzeptionierung von HTTP 1.1 hat aber noch weiteren Raum für Verbesserungen gelassen. Das Verfahren ist nach dem Vorbild von RFC 822 als Textprotokoll aufgebaut, sodass Requests und deren Parameter im Klartext übertragen werden. Pro Request benötigt man mehrere 100 Bytes an Zusatzinformationen (HTTP Header). Schickt ein Client mehrere Requests gleichzeitig, summiert sich das und verstopft den Uplink. Das wird besonders bei schmalbandingen DSL-Anschlüssen spürbar und führt um so mehr zu Problemen, je mehr HTTP-Verbindungen gleichzeitig zum Server aufgebaut werden.

Und eine weitere Schwäche des Protokolls offenbart sich, wenn man das Verfahren analysiert, mit dem Browser ermitteln, ob sich Teile einer bereits zuvor abgerufenen Webseite in der Zwischenzeit geändert haben. Das passiert beispielsweise bei Nachrichten-Seiten ganz häufig am Tag, bei anderen vielleicht nur selten, aber mit HTTP 1.1 auf jeden Fall für den Client nicht vorhersehbar.

Um zu erfahren, ob sich eine Resource auf dem Server geändert hat, muss der Client zum Beispiel bei einem Reload-Befehl des Benutzers einen Request an den Server senden und eine RTT abwarten. Dann bekommt er entweder die Antwort "304 Not modified" oder "200 OK" und die aktualisierte Resource. Das ist schon mal besser als das Minimalverfahren, bei dem er eine RTT zum Abfragen von Änderungen braucht und dann eine weitere RTT zum Abruf der Resource mittels des GET-Befehls.

Beispiel für einen optimierten Webseitenabruf per HTTP 1.1
Aktion	Dauer
Der Client baut die TCP-Verbindung zum Server auf	1 RTT für SYN/SYN-ACK
Der Client sendet GET für die Datei Index.html	1 RTT
Parsing: Der Client liest die Datei Index.html und stellt fest, dass er Script.js und Style.css noch laden muss	10 ms
Der Client sendet GET für Script.js auf der bestehenden Verbindung	1 RTT
Der Client baut eine zweite TCP-Verbindung auf	1 RTT
Der Client sendet GET für Style.css	1 RTT

Aktuelle Browser schöpfen fast alle Möglichkeiten von HTTP 1.1 aus. Ein Beispiel für dieses hoch optimierte Verfahren, sieht so aus:

Obwohl er script.js und style.css gleichzeitig über zwei TCP-Verbindungen holen kann, benötigt der Client für den Seitenaufbau mindestens vier RTTs plus die parse time für index.html. Mit HTTP 1.1 sind aber keine weiteren Verbesserungen möglich.