Die Entwicklung des HTTP-Protokolls: Von 1.0 zu 2.0

HTTP (HyperText Transfer Protocol) ist das am weitesten verbreitete Netzwerkprotokoll im Internet, und alle WWW-Dateien müssen diesem Standard folgen. Sein ursprüngliches Designziel war es, eine Methode zum Veröffentlichen und Empfangen von HTML-Seiten bereitzustellen, die zum Übertragen von Hypertext von einem WWW-Server zu einem lokalen Browser verwendet wird, und es verwendet standardmäßig Port 80. Wenn ein HTTP-Client eine Anfrage initiiert, stellt er eine TCP-Verbindung zum angegebenen Port des Servers her (standardmäßig Port 80).

Es ist erwähnenswert, dass das HTTP-Protokoll nicht mit dem TCP-Protokoll in Konflikt steht. HTTP befindet sich auf der Anwendungsschicht des Sieben-Schichten-Modells, während TCP für die Lösung der logischen Probleme der Transportschicht verantwortlich ist. HTTP wählt TCP anstelle von UDP, da beim Öffnen einer Webseite eine große Datenmenge übertragen werden muss und das TCP-Protokoll eine Übertragungssteuerung bereitstellen kann, um die ordnungsgemäße Organisation und Fehlerkorrektur von Daten zu erreichen. Darüber hinaus basieren die Engpässe und Optimierungstechniken des HTTP-Protokolls auch auf den Eigenschaften des TCP-Protokolls. Beispielsweise verursacht der Drei-Wege-Handschlag beim Aufbau einer TCP-Verbindung eine Verzögerung von 1,5 RTTs (Round-Trip Time). Um die Handschlagverzögerung jeder Anfrage zu vermeiden, verwendet die Anwendungsschicht HTTP-Persistent-Connection-Schemas mit unterschiedlichen Strategien; und da TCP im Anfangsstadium der Verbindung die Slow-Start-Eigenschaft hat, ist die Leistung der Verbindungs-Wiederverwendung in der Regel besser als die einer neuen Verbindung.

Die HTTP-Verbindung verwendet den Modus „Anfrage-Antwort“. Es muss nicht nur zuerst eine Verbindung hergestellt werden, wenn eine Anfrage gestellt wird, sondern der Server kann erst dann mit Daten antworten, wenn der Client eine Anfrage an den Server sendet. Mit der Entwicklung des Internets wurde auch das HTTP-Protokoll kontinuierlich aktualisiert, und es sind Versionen wie HTTP/1.0, HTTP/1.1 und HTTP/2.0 entstanden, und jede Version wurde in Bezug auf Leistung und Funktionalität optimiert und verbessert.

Vergleichstabelle der HTTP-Protokollversionen

HTTP/1.0

HTTP/1.0 ist die erste Version des HTTP-Protokolls, die eine Versionsnummer in der Kommunikation angibt und immer noch in Szenarien wie Proxy-Servern weit verbreitet ist. Diese Version legt fest, dass der Browser und der Server nur eine kurzfristige Verbindung aufrechterhalten. Der Browser muss für jede Anfrage eine TCP-Verbindung mit dem Server herstellen, und der Server trennt die TCP-Verbindung sofort, nachdem er die Anforderungsverarbeitung abgeschlossen hat. Er verfolgt nicht jeden Client oder zeichnet vergangene Anfragen auf.

Dieser Mechanismus führt zu einigen Leistungsmängeln. Nehmen wir als Beispiel eine Webseite, die eine große Anzahl von Bildern enthält. Die Webseite selbst enthält keine Bilddaten, sondern gibt nur die URL-Adresse des Bildes an. Wenn der Browser auf diese Webseite zugreift, sendet er zuerst eine Anfrage für die Webseite-Datei. Wenn er beim Parsen des HTML-Inhalts ein Bild-Tag findet, sendet er erneut eine Anfrage an den Server, um die Bilddaten gemäß der im src-Attribut angegebenen URL herunterzuladen. Dies bedeutet, dass der Zugriff auf eine Webseite mit vielen Bildern mehrere Anfragen und Antworten erfordert und jedes Mal eine separate Verbindung hergestellt werden muss, um ein einzelnes Dokument oder Bild zu übertragen. Selbst wenn die Bilddateien klein sind, ist der Prozess des häufigen Auf- und Abbaus von Verbindungen zeitaufwändig und beeinträchtigt die Leistung sowohl des Clients als auch des Servers erheblich. Wenn eine Webseite Inhalte wie JavaScript-Dateien und CSS-Dateien enthält, treten ähnliche Probleme auf.

Gleichzeitig sind Bandbreite und Latenz ebenfalls wichtige Faktoren, die sich auf Netzwerkanfragen auswirken. Mit der deutlichen Verbesserung der Bandbreite in der aktuellen Netzwerkinfrastruktur ist das Latenzproblem der Reaktionsgeschwindigkeit stärker in den Vordergrund getreten. Die beiden am meisten kritisierten Probleme von HTTP/1.0 sind die Unfähigkeit, Verbindungen wiederzuverwenden, und Head-of-Line Blocking.

Um diese beiden Probleme zu verstehen, sollte klar sein, dass der Client eine Verbindung zum Server gemäß dem Domainnamen herstellt. Im Allgemeinen stellt ein PC-Browser gleichzeitig 6-8 Verbindungen zum Server einer einzelnen Domain her, während ein mobiler Browser dies auf 4-6 begrenzt. Die Anzahl der Verbindungen ist nicht je mehr, desto besser, da zu viele den Ressourcenaufwand und die Gesamtlatenz erhöhen. Die Unfähigkeit, Verbindungen wiederzuverwenden, führt zu einem Drei-Wege-Handschlag und einem langsamen Start für jede Anfrage. Der Drei-Wege-Handschlag hat erhebliche Auswirkungen in Szenarien mit hoher Latenz, und der Slow-Start hat größere Auswirkungen auf Anfragen nach großen Dateien. Head-of-Line Blocking führt dazu, dass die Bandbreite nicht vollständig genutzt werden kann und nachfolgende gesunde Anfragen blockiert werden.

Head-of-Line Blocking führt dazu, dass gesunde Anfragen von ungesunden Anfragen beeinflusst werden, und dieser Verlust wird von der Netzwerkumgebung beeinflusst, die zufällig und schwer zu überwachen ist. Um die durch Head-of-Line Blocking verursachte Latenz zu beheben, führten die Protokolldesigner den Pipelining-Mechanismus ein, aber dieser Mechanismus ist nur auf HTTP/1.1 anwendbar und hat strenge Nutzungsbedingungen, und viele Browserhersteller unterstützen ihn nicht.

In HTTP/1.0 ist der Anfrage-Header relativ einfach. Zum Beispiel beim Abrufen von Webseitenressourcen:

GET /index.html HTTP/1.0
User - Agent: Mozilla/5.0

HTTP/1.1

Um die Mängel von HTTP/1.0 zu beheben, unterstützt HTTP/1.1 persistente Verbindungen (der Standardmodus ist eine persistente Verbindung mit Pipelining). Über eine einzige TCP-Verbindung können mehrere HTTP-Anforderungen und -Antworten übertragen werden, wodurch der Verbrauch und die Latenz der Verbindungsherstellung und -schließung reduziert werden. Nehmen wir als Beispiel eine Webseite, die eine große Anzahl von Bildern enthält. Es können mehrere Anfragen und Antworten in einer Verbindung übertragen werden, aber die Anfragen und Antworten für jede einzelne Webseite-Datei müssen weiterhin ihre eigenen Verbindungen verwenden. Darüber hinaus ermöglicht HTTP/1.1 dem Client, die nächste Anfrage zu senden, ohne auf die Rückgabe des Ergebnisses der vorherigen Anfrage zu warten, und der Server muss die Antwort Ergebnisse in der Reihenfolge des Empfangs der Anfragen zurücksenden, um sicherzustellen, dass der Client den Antwortinhalt jeder Anfrage unterscheiden kann, was die für den gesamten Downloadprozess benötigte Zeit erheblich reduziert.

In HTTP/1.1 kann der connection-Header in den Anfrage- und Antwortheadern erscheinen, der verwendet wird, um anzugeben, wie der Client und der Server die persistente Verbindung behandeln. Standardmäßig gehen der Client und der Server davon aus, dass die Gegenpartei persistente Verbindungen unterstützt. Wenn der Client das HTTP/1.1-Protokoll verwendet, aber keine persistente Verbindung verwenden möchte, muss er den Wert von connection im Header als close angeben; wenn der Server keine persistente Verbindung unterstützen möchte, muss er auch den Wert von connection in der Antwort explizit als close setzen. Unabhängig davon, ob der Wert close im Header der Anfrage oder der Antwort enthalten ist, gibt er an, dass die aktuelle TCP-Verbindung nach Abschluss der Anforderungsverarbeitung getrennt wird und nachfolgende neue Anfragen vom Client eine neue TCP-Verbindung erstellen müssen. Zum Beispiel:

# Anfrage-Header
GET /index.html HTTP/1.1
User - Agent: Mozilla/5.0
Connection: close

# Antwort-Header
HTTP/1.1 200 OK
Content - Type: text/html
Connection: close

Darüber hinaus hat HTTP/1.1 die Funktionen von HTTP/1.0 durch Hinzufügen weiterer Anfrage- und Antwortheader verbessert und erweitert:

• Host-Header-Unterstützung: HTTP/1.0 unterstützt das Host-Anfrage-Header-Feld nicht, und der Browser kann die spezifische WEB-Site auf dem Server, auf die über den Host-Header-Namen zugegriffen werden soll, nicht angeben, was die Konfiguration mehrerer virtueller WEB-Sites auf derselben IP-Adresse und Portnummer einschränkt. Nachdem HTTP/1.1 das Host-Anfrage-Header-Feld hinzugefügt hat, kann der Browser die Site, auf die zugegriffen werden soll, über den Host-Header-Namen eindeutig angeben, wodurch die Erstellung mehrerer virtueller WEB-Sites mit unterschiedlichen Hostnamen auf derselben IP-Adresse und Portnummer ermöglicht wird. Zum Beispiel:

GET /index.html HTTP/1.1
Host: example.com

• Persistente Verbindungssteuerung: Die persistente Verbindung von HTTP/1.1 wird durch neue Anfrageheader implementiert. Wenn der Wert des Connection-Anfrageheaders Keep - Alive ist, benachrichtigt der Client den Server, die Verbindung nach der Rückgabe des Ergebnisses dieser Anfrage aufrechtzuerhalten; wenn der Wert close ist, benachrichtigt er den Server, die Verbindung nach der Rückgabe des Ergebnisses zu schließen.
• Caching und Fortsetzen unterbrochener Downloads: HTTP/1.0 unterstützt das Fortsetzen unterbrochener Downloads von Dateien nicht, und jede Dateiübertragung beginnt an der 0-Byte-Position. HTTP/1.1 fügt ein neues Feld RANGE:bytes hinzu, und RANGE:bytes=XXXX bedeutet, dass der Server aufgefordert wird, die Übertragung ab der XXXX-Byte-Position der Datei zu starten, wodurch das Fortsetzen unterbrochener Downloads ermöglicht wird. Zum Beispiel:

GET /largefile.zip HTTP/1.1
Range: bytes=1000 -

Darüber hinaus wurde HTTP/1.1 in Bezug auf Cache-Verarbeitung, Bandbreitenoptimierung, Fehlermeldungsverwaltung usw. verbessert:

• Cache-Verarbeitung: HTTP/1.0 verwendet hauptsächlich If - Modified - Since und Expires als Cache-Beurteilungskriterien, und HTTP/1.1 hat mehr Cache-Kontrollstrategien eingeführt, wie z. B. Entity tag, If - Unmodified - Since, If - Match, If - None - Match usw.
• Bandbreitenoptimierung: In HTTP/1.0 gibt es ein Phänomen der Bandbreitenverschwendung, und es unterstützt das Fortsetzen unterbrochener Downloads nicht. HTTP/1.1 führt das range-Header-Feld im Anfrage-Header ein, das es ermöglicht, nur einen Teil der Ressource anzufordern, und der Rückgabecode ist 206 (Partial Content), was die Bandbreitenauslastung verbessert.
• Fehlermeldung: HTTP/1.1 fügt 24 neue Fehlerstatus-Antwortcodes hinzu, wie z. B. 409 (Conflict), der angibt, dass die angeforderte Ressource mit dem aktuellen Zustand in Konflikt steht; 410 (Gone), der angibt, dass die Ressource auf dem Server dauerhaft gelöscht wurde.

SPDY: Der Vorläufer von HTTP/2.0

SPDY ist kein Standardprotokoll. Sein Entwicklungsteam hat es gefördert, ein Internet-Draft zu werden, aber es ist letztendlich nicht gelungen, ein offizieller Standard zu werden. Die Mitglieder des SPDY-Entwicklungsteams waren jedoch am gesamten Prozess der Formulierung von HTTP/2.0 beteiligt. Die Schlüsselfunktionen von HTTP/2.0 stammen hauptsächlich aus der SPDY-Technologie, und es kann davon ausgegangen werden, dass die Errungenschaften von SPDY übernommen und in HTTP/2.0 weiterentwickelt wurden. Im September 2015 kündigte Google die Entfernung der Unterstützung für SPDY an und setzte stattdessen auf HTTP/2.0, das in Chrome 51 in Kraft trat.

SPDY ersetzt HTTP nicht, sondern ändert die Art und Weise, wie HTTP-Anforderungen und -Antworten über das Netzwerk übertragen werden. Durch einfaches Hinzufügen einer SPDY-Transportschicht müssen die vorhandenen serverseitigen Anwendungen keine Änderungen vornehmen. Bei Verwendung von SPDY für die Übertragung werden HTTP-Anforderungen verarbeitet, markiert, vereinfacht und komprimiert.

SPDY hat die folgenden neuen Funktionen:

• Multiplexing: Mehrere Anfrageströme teilen sich eine einzige TCP-Verbindung, wodurch das HOL-Blocking-Problem gelöst, die Latenz reduziert und die Bandbreitenauslastung verbessert wird.
• Anfragepriorität: Ermöglicht das Festlegen einer Priorität für jede Anfrage, um sicherzustellen, dass wichtige Anfragen zuerst beantwortet werden. Wenn der Browser beispielsweise die Startseite lädt, kann er der Anzeige des HTML-Inhalts Priorität einräumen und dann statische Ressourcen und Skriptdateien laden.
• Header-Komprimierung: Die Header in HTTP/1.x enthalten oft doppelte und redundante Informationen. SPDY wählt einen geeigneten Komprimierungsalgorithmus aus, um die Größe und Anzahl der Pakete zu reduzieren.
• Verschlüsselte Protokollübertragung basierend auf HTTPS: Verbessert die Zuverlässigkeit der übertragenen Daten.
• Server Push: Für eine Webseite, die SPDY verwendet, pusht der Server sytle.js an den Client, wenn der Client sytle.css anfordert. Wenn der Client anschließend sytle.js abruft, kann er sie direkt aus dem Cache abrufen, ohne eine weitere Anfrage zu stellen.

HTTP/2.0

Unterschiede zwischen HTTP/2.0 und SPDY

• Transportprotokoll: HTTP/2.0 unterstützt die Klartext-HTTP-Übertragung, während SPDY die Verwendung von HTTPS erzwingt. Obwohl HTTP/2.0 Nicht-HTTPS unterstützt, unterstützen gängige Browser wie Chrome und Firefox nur das auf TLS basierende HTTP/2.0-Protokoll. Daher erfordert das Upgrade auf HTTP/2.0 in der Regel zuerst ein Upgrade von HTTPS.
• Algorithmus zur Komprimierung von Nachrichtenkopfzeilen: HTTP/2.0 verwendet den HPACK-Algorithmus zum Komprimieren von Nachrichtenkopfzeilen, während SPDY den DEFLATE-Algorithmus verwendet.

Neue Funktionen von HTTP/2.0 im Vergleich zu HTTP/1.x

• Multiplexing: HTTP/2.0 ermöglicht das gleichzeitige Initiieren mehrerer Anfrage-Antwort-Nachrichten über eine einzelne HTTP/2-Verbindung. Im HTTP/1.1-Protokoll hat der Browser-Client Einschränkungen hinsichtlich der Anzahl der Anforderungen unter demselben Domänennamen, und Anforderungen, die das Limit überschreiten, werden blockiert. Dies ist einer der Gründe, warum einige Websites mehrere statische Ressourcen-CDN-Domänennamen verwenden. Das Multiplexing von HTTP/2.0 ermöglicht den parallelen Austausch von Nachrichten über eine einzelne Verbindung, wodurch die Grundeinheit der HTTP-Protokollkommunikation auf Frames reduziert wird, und diese Frames entsprechen Nachrichten in logischen Streams, wodurch die Parallelität mehrerer Streams erreicht wird, ohne auf mehrere TCP-Verbindungen angewiesen zu sein. Zum Beispiel, wenn gleichzeitig mehrere Ressourcen angefordert werden:

:method: GET
:scheme: https
:authority: example.com
:path: /image1.jpg

:method: GET
:scheme: https
:authority: example.com
:path: /image2.jpg

Im Vergleich zur Wiederverwendung persistenter Verbindungen in HTTP/1.1 wird in HTTP/1.* für jede Anfrage-Antwort eine Verbindung hergestellt und nach Gebrauch geschlossen, und jede Anfrage muss eine Verbindung herstellen; im Pipeling-Modus von HTTP/1.1 werden mehrere Anfragen zur seriellen Single-Thread-Verarbeitung in die Warteschlange gestellt, und nachfolgende Anfragen müssen warten, bis die vorherige Anfrage zurückkehrt, bevor sie ausgeführt werden können. Sobald eine Anfrage abläuft, werden nachfolgende Anfragen blockiert; während in HTTP/2.0 parallel mehrere Anfragen über eine Verbindung ausgeführt werden können, und eine Anfrage mit ernsthaften Latenzzeiten die normale Ausführung anderer Verbindungen nicht beeinträchtigt.

Das Multiplexing von HTTP/2.0 nutzt TCP-Verbindungen effektiver und verbessert die HTTP-Leistung. TCP-Verbindungen „optimieren sich selbst“, indem sie die Verbindungsgeschwindigkeit in der Anfangsphase begrenzen und die Geschwindigkeit schrittweise erhöhen, wenn Daten erfolgreich übertragen werden, d. h. TCP Slow Start. HTTP/2.0 ermöglicht es allen Datenströmen, dieselbe Verbindung zu teilen, wodurch die Ineffizienz von HTTP-Verbindungen reduziert, Staus und Paketverluste reduziert und der Verbindungsdurchsatz erhöht wird.

• Anfragepriorität: Multiplexing kann dazu führen, dass wichtige Anfragen blockiert werden. HTTP/2.0 ermöglicht das Festlegen einer Priorität für jede Anfrage, wobei ein 31-Bit-Prioritätswert verwendet wird, wobei 0 die höchste Priorität und 2(31) - 1 die niedrigste Priorität darstellt. Der Server kann die Ressourcenzuweisung entsprechend der Priorität steuern und vorzugsweise Anforderungs-Frames mit hoher Priorität verarbeiten und an den Client zurückgeben.
• Binäre Framing: HTTP/1.1 basiert auf Text-Parsing, und die Vielfalt der Textformate erfordert die Berücksichtigung mehrerer Szenarien während des Parsens, was zu einer schlechten Robustheit führt. HTTP/2.0 verwendet binäres Format-Parsing und fügt eine binäre Framing-Schicht zwischen der Anwendungsschicht (HTTP/2.0) und der Transportschicht (TCP oder UDP) hinzu. Diese Schicht unterteilt alle übertragenen Informationen in kleinere Nachrichten und Frames (Frame) und codiert sie im binären Format. Die Header-Informationen von HTTP/1.x werden in den HEADER-Frame und der RequestBody in den DATA-Frame gekapselt. Die gesamte Kommunikation in HTTP/2.0 wird über eine Verbindung abgeschlossen, und diese Verbindung kann eine beliebige Anzahl von bidirektionalen Datenströmen tragen.
• Header-Komprimierung: HTTP/1.1 unterstützt keine HTTP-Header-Komprimierung, und SPDY und HTTP/2.0 entstanden zu diesem Zweck. SPDY verwendet den DEFLATE-Algorithmus und HTTP/2.0 den HPACK-Algorithmus. HTTP/2.0 verwaltet ein Wörterbuch und aktualisiert die HTTP-Header inkrementell, um den durch die Header-Übertragung erzeugten Datenverkehr zu reduzieren. Beide Kommunikationspartner cachen jeweils eine Tabelle mit Header-Feldern, um die Übertragung doppelter Header zu vermeiden und die Übertragungsgröße zu reduzieren.
• Server Push: In HTTP/2.0 kann der Server mehrere Antworten auf eine einzelne Anfrage vom Client senden. Server Push macht die Optimierungsmethoden der Verwendung eingebetteter Ressourcen in der HTTP/1.x-Ära überflüssig. Wenn eine Anfrage von der Startseite initiiert wird, kann der Server mit dem Startseiteninhalt, dem Logo und dem Stylesheet und anderen vom Client benötigten Ressourcen antworten, und diese Ressourcen können zwischengespeichert werden, wodurch die gemeinsame Nutzung zwischengespeicherter Ressourcen zwischen verschiedenen Seiten unter demselben Ursprung realisiert wird.

Referenzlinks

• MDN Web Docs: HTTP
• IETF HTTP/2 Specification

Leapcell: Das Beste aus Serverless Webhosting

Abschließend möchte ich eine Plattform empfehlen, die sich am besten für die Bereitstellung von Diensten eignet: Leapcell

🚀 Bauen Sie mit Ihrer Lieblingssprache

Entwickeln Sie mühelos in JavaScript, Python, Go oder Rust.

🌍 Stellen Sie unbegrenzt Projekte kostenlos bereit

Zahlen Sie nur für das, was Sie nutzen – keine Anfragen, keine Gebühren.

⚡ Pay-as-You-Go, keine versteckten Kosten

Keine Leerlaufgebühren, nur nahtlose Skalierbarkeit.

📖 Erkunden Sie unsere Dokumentation

🔹 Folgen Sie uns auf Twitter: @LeapcellHQ