Seit mehr als 20 Jahren betrachten wir Webseiten über das HTTP-Protokoll. Die meisten Benutzer denken nicht einmal darüber nach, was es ist und wie es funktioniert. Andere wissen, dass es irgendwo unter HTTP TLS gibt und darunter TCP, darunter IP und so weiter. Und wieder andere – Ketzer – glauben, dass TCP der Vergangenheit angehört; sie wollen etwas Schnelleres, Zuverlässigeres und Sichereres. Doch bei ihren Versuchen, ein neues ideales Protokoll zu erfinden, greifen sie auf die Technologie der 80er Jahre zurück und versuchen, darauf ihre schöne neue Welt aufzubauen.
Eine kleine Geschichte: HTTP/1.1
Im Jahr 1997 erhielt das Textinformationsaustauschprotokoll HTTP Version 1.1 einen eigenen RFC. Zu diesem Zeitpunkt wurde das Protokoll bereits mehrere Jahre lang von Browsern verwendet, und der neue Standard hielt weitere fünfzehn Jahre Bestand. Das Protokoll funktionierte ausschließlich nach dem Request-Response-Prinzip und war hauptsächlich für die Übertragung von Textinformationen gedacht.
HTTP wurde so konzipiert, dass es auf dem TCP-Protokoll läuft und sicherstellt, dass Pakete zuverlässig an ihr Ziel übermittelt werden. TCP funktioniert, indem es eine zuverlässige Verbindung zwischen Endpunkten herstellt und aufrechterhält und den Datenverkehr in Segmente aufteilt. Segmente haben ihre eigene Seriennummer und Prüfsumme. Wenn plötzlich eines der Segmente nicht oder mit einer falschen Prüfsumme ankommt, wird die Übertragung unterbrochen, bis das verlorene Segment wiederhergestellt ist.
In HTTP/1.0 wurde die TCP-Verbindung nach jeder Anfrage geschlossen. Das war äußerst verschwenderisch, denn... Der Aufbau einer TCP-Verbindung (3-Way-Handshake) ist ein langsamer Prozess. HTTP/1.1 führte den Keep-Alive-Mechanismus ein, der es Ihnen ermöglicht, eine Verbindung für mehrere Anfragen wiederzuverwenden. Da es jedoch leicht zu einem Engpass kommen kann, ermöglichen verschiedene Implementierungen von HTTP/1.1 das Öffnen mehrerer TCP-Verbindungen zum selben Host. Beispielsweise erlauben Chrome und neuere Versionen von Firefox bis zu sechs Verbindungen.
Auch die Verschlüsselung sollte anderen Protokollen überlassen werden und wurde hierfür über TCP auf das TLS-Protokoll zurückgegriffen, das die Daten zwar zuverlässig schützte, aber die Zeit für den Verbindungsaufbau zusätzlich erhöhte. Infolgedessen sah der Handshake-Prozess folgendermaßen aus:
Cloudflare-Illustration
Daher hatte HTTP/1.1 eine Reihe von Problemen:
- Langsamer Verbindungsaufbau.
- Die Übermittlung der Daten erfolgt in Textform, die Übermittlung von Bildern, Videos und anderen nicht-textlichen Informationen ist daher unwirksam.
- Für eine Anfrage wird eine TCP-Verbindung verwendet, was bedeutet, dass andere Anfragen entweder eine andere Verbindung finden oder warten müssen, bis die aktuelle Anfrage diese freigibt.
- Es wird nur das Pull-Modell unterstützt. Im Standard steht nichts über Server-Push.
- Überschriften werden im Text übermittelt.
Wenn Server-Push zumindest über das WebSocket-Protokoll implementiert wird, müssten die verbleibenden Probleme radikaler angegangen werden.
Ein bisschen Modernität: HTTP/2
Im Jahr 2012 begann Google mit der Arbeit am SPDY-Protokoll (ausgesprochen „speedy“). Das Protokoll sollte die Hauptprobleme von HTTP/1.1 lösen und gleichzeitig die Abwärtskompatibilität wahren. Im Jahr 2015 führte die IETF-Arbeitsgruppe die HTTP/2-Spezifikation auf Basis des SPDY-Protokolls ein. Hier sind die Unterschiede bei HTTP/2:
- Binäre Serialisierung.
- Multiplexen mehrerer HTTP-Anfragen in einer einzigen TCP-Verbindung.
- Server-Push sofort einsatzbereit (ohne WebSocket).
Das Protokoll war ein großer Fortschritt. Er stark und erfordert nicht die Erstellung mehrerer TCP-Verbindungen: Alle Anfragen an einen Host werden in einem gemultiplext. Das heißt, in einer Verbindung gibt es mehrere sogenannte Streams, von denen jeder eine eigene ID hat. Der Bonus ist ein Box-Server-Push.
Multiplexing führt jedoch zu einem weiteren zentralen Problem. Stellen Sie sich vor, wir führen asynchron 5 Anfragen an einen Server aus. Bei Verwendung von HTTP/2 werden alle diese Anfragen innerhalb derselben TCP-Verbindung ausgeführt. Das heißt, wenn eines der Segmente einer Anfrage verloren geht oder falsch empfangen wird, wird die Übertragung aller Anfragen und Antworten gestoppt, bis das verlorene Segment verloren geht restauriert. Offensichtlich ist HTTP/2 umso langsamer, je schlechter die Verbindungsqualität ist. Unter Bedingungen, bei denen verlorene Pakete 2 % aller Pakete ausmachen, schneidet HTTP/1.1 im Browser besser ab als HTTP/2, da sechs Verbindungen statt einer geöffnet werden.
Dieses Problem wird als „Head-of-Line-Blockierung“ bezeichnet und ist mit TCP leider nicht lösbar.
Illustration von Daniel Steinberg
Infolgedessen haben die Entwickler des HTTP/2-Standards großartige Arbeit geleistet und fast alles getan, was auf der Anwendungsebene des OSI-Modells möglich war. Es ist an der Zeit, auf die Transportschicht vorzudringen und ein neues Transportprotokoll zu erfinden.
Wir brauchen ein neues Protokoll: UDP vs. TCP
Ziemlich schnell wurde klar, dass die Implementierung eines völlig neuen Transportschichtprotokolls in der heutigen Realität eine unmögliche Aufgabe ist. Tatsache ist, dass Hardware oder Middle-Boxen (Router, Firewalls, NAT-Server ...) über die Transportschicht Bescheid wissen und es eine äußerst schwierige Aufgabe ist, ihnen etwas Neues beizubringen. Darüber hinaus ist die Unterstützung für Transportprotokolle in den Kernel von Betriebssystemen integriert, und Kernel sind ebenfalls nicht sehr bereit, sich zu ändern.
Und hier könnte man die Hände hochwerfen und sagen: „Wir werden natürlich mit Vorliebe und Kurtisanen ein neues HTTP/3 erfinden, aber es wird 10-15 Jahre dauern, bis es implementiert ist (nach ungefähr dieser Zeit wird der Großteil der Hardware fertig sein). ersetzt)“, aber es gibt noch eine weitere Option, die nicht so ist. Die offensichtliche Option ist die Verwendung des UDP-Protokolls. Ja, ja, dasselbe Protokoll, das wir Ende der XNUMXer und Anfang der XNUMXer Jahre zum Übertragen von Dateien über das LAN verwendet haben. Fast alle heutige Hardware kann damit arbeiten.
Was sind die Vorteile von UDP gegenüber TCP? Erstens haben wir keine Transportschichtsitzung, die der Hardware bekannt ist. Dadurch können wir die Sitzung auf den Endpunkten selbst bestimmen und dort Konflikte lösen. Das heißt, wir sind nicht auf eine oder mehrere Sitzungen beschränkt (wie bei TCP), sondern können so viele davon erstellen, wie wir benötigen. Zweitens ist die Datenübertragung per UDP schneller als per TCP. Somit können wir theoretisch die derzeit in HTTP/2 erreichte Geschwindigkeitsobergrenze durchbrechen.
UDP garantiert jedoch keine zuverlässige Datenübertragung. Tatsächlich senden wir einfach Pakete in der Hoffnung, dass die andere Seite sie empfängt. Nicht bekommen haben? Na ja, kein Glück... Das reichte aus, um Videos für Erwachsene zu übertragen, aber für ernstere Dinge braucht man Zuverlässigkeit, was bedeutet, dass man UDP mit etwas anderem überziehen muss.
Wie bei HTTP/2 begannen die Arbeiten an der Erstellung eines neuen Protokolls bei Google im Jahr 2012, also etwa zeitgleich mit den Arbeiten an SPDY. Im Jahr 2013 stellte sich Jim Roskind der breiten Öffentlichkeit vor , und bereits 2015 wurde der Internet Draft zur Standardisierung in der IETF eingeführt. Schon damals unterschied sich das von Roskind bei Google entwickelte Protokoll stark vom Standard, weshalb die Google-Version den Namen gQUIC erhielt.
Was ist QUIC
Erstens handelt es sich, wie bereits erwähnt, um einen Wrapper über UDP. Auf UDP baut eine QUIC-Verbindung auf, bei der analog zu HTTP/2 mehrere Streams existieren können. Diese Streams existieren nur auf den Endpunkten und werden unabhängig bereitgestellt. Wenn in einem Stream ein Paketverlust auftritt, hat dies keine Auswirkungen auf andere.
Illustration von Daniel Steinberg
Zweitens wird die Verschlüsselung nicht mehr auf einer separaten Ebene implementiert, sondern ist im Protokoll enthalten. Dadurch können Sie in einem einzigen Handshake eine Verbindung herstellen und öffentliche Schlüssel austauschen. Außerdem können Sie den cleveren 0-RTT-Handshake-Mechanismus nutzen und Handshake-Verzögerungen im Allgemeinen vermeiden. Darüber hinaus ist es nun möglich, einzelne Datenpakete zu verschlüsseln. Dies ermöglicht es Ihnen, nicht auf den Abschluss des Datenempfangs aus dem Stream zu warten, sondern die empfangenen Pakete unabhängig zu entschlüsseln. Diese Betriebsart war in TCP im Allgemeinen unmöglich, weil TLS und TCP arbeiteten unabhängig voneinander und TLS konnte nicht wissen, in welche Teile TCP-Daten zerhackt würden. Und deshalb konnte er seine Segmente nicht so vorbereiten, dass sie eins zu eins in TCP-Segmente passen und unabhängig voneinander entschlüsselt werden konnten. All diese Verbesserungen ermöglichen es QUIC, die Latenz im Vergleich zu TCP zu reduzieren.
Drittens ermöglicht Ihnen das Konzept des Light-Streamings, die Verbindung von der IP-Adresse des Clients zu entkoppeln. Dies ist beispielsweise wichtig, wenn ein Client von einem WLAN-Zugangspunkt zu einem anderen wechselt und dabei seine IP ändert. In diesem Fall kommt es bei der Verwendung von TCP zu einem langwierigen Prozess, bei dem bestehende TCP-Verbindungen ablaufen und neue Verbindungen von einer neuen IP erstellt werden. Im Fall von QUIC sendet der Client einfach weiterhin Pakete von einer neuen IP mit der alten Stream-ID an den Server. Weil Die Stream-ID ist jetzt eindeutig und wird nicht wiederverwendet; der Server erkennt, dass der Client die IP geändert hat, sendet verlorene Pakete erneut und setzt die Kommunikation unter der neuen Adresse fort.
Viertens wird QUIC auf Anwendungsebene und nicht auf Betriebssystemebene implementiert. Dadurch können Sie einerseits schnell Änderungen am Protokoll vornehmen, denn Um ein Update zu erhalten, müssen Sie lediglich die Bibliothek aktualisieren und müssen nicht auf eine neue Betriebssystemversion warten. Andererseits führt dies zu einem starken Anstieg des Prozessorverbrauchs.
Und schließlich die Schlagzeilen. Die Header-Komprimierung ist eines der Dinge, die sich zwischen QUIC und gQUIC unterscheiden. Ich sehe keinen Sinn darin, viel Zeit darauf zu verwenden, ich sage nur, dass in der zur Standardisierung eingereichten Version die Header-Komprimierung so ähnlich wie möglich an die Header-Komprimierung in HTTP/2 angepasst wurde. Sie können mehr lesen .
Wie viel schneller ist es?
Das ist eine schwierige Frage. Tatsache ist, dass es nichts Besonderes zu messen gibt, bis wir einen Standard haben. Vielleicht sind die einzigen Statistiken, die wir haben, Statistiken von Google, das gQUIC seit 2013 und im Jahr 2016 verwendet dass etwa 90 % des Datenverkehrs, der vom Chrome-Browser zu ihren Servern geht, jetzt QUIC verwendet. In derselben Präsentation berichten sie, dass Seiten durch gQUIC etwa 5 % schneller geladen werden und es beim Video-Streaming im Vergleich zu TCP 30 % weniger Ruckler gibt.
Im Jahr 2017 veröffentlichte eine Forschergruppe unter der Leitung von Arash Molavi Kakhki um die Leistung von gQUIC im Vergleich zu TCP zu untersuchen.
Die Studie offenbarte mehrere Schwächen von gQUIC, wie z. B. Instabilität beim Mischen von Netzwerkpaketen, Gier (Ungerechtigkeit) bei der Kanalbandbreite und langsamere Übertragung kleiner (bis zu 10 kb) Objekte. Letzteres kann jedoch durch den Einsatz von 0-RTT ausgeglichen werden. In allen anderen untersuchten Fällen zeigte gQUIC eine Geschwindigkeitssteigerung im Vergleich zu TCP. Es ist schwierig, hier über konkrete Zahlen zu sprechen. Besser lesen oder .
Hier muss gesagt werden, dass es sich bei diesen Daten speziell um gQUIC handelt und sie für den zu entwickelnden Standard nicht relevant sind. Was mit QUIC passieren wird: Es ist noch ein Geheimnis, aber es besteht die Hoffnung, dass die in gQUIC festgestellten Schwächen berücksichtigt und behoben werden.
Ein bisschen Zukunft: Was ist mit HTTP/3?
Aber hier ist alles glasklar: Die API wird sich in keiner Weise ändern. Alles bleibt genau so, wie es in HTTP/2 war. Wenn die API dieselbe bleibt, muss der Übergang zu HTTP/3 durch die Verwendung einer neuen Version der Bibliothek im Backend gelöst werden, die den QUIC-Transport unterstützt. Allerdings müssen Sie noch einige Zeit auf alte HTTP-Versionen zurückgreifen, denn Das Internet ist derzeit nicht bereit für eine vollständige Umstellung auf UDP.
Wer unterstützt schon
Hier bestehende QUIC-Implementierungen. Trotz des Fehlens eines Standards ist die Liste nicht schlecht.
Derzeit unterstützt kein Browser QUIC in einer Produktionsversion. Kürzlich gab es Informationen, dass Unterstützung für HTTP/3 in Chrome enthalten sei, bislang jedoch nur in Canary.
Von den Backends unterstützt nur HTTP/3 и , aber immer noch experimentell. NGINX Ende Frühjahr 2019 , dass sie mit der Arbeit an der HTTP/3-Unterstützung begonnen, diese aber noch nicht abgeschlossen haben.
Was sind die Probleme?
Sie und ich leben in der realen Welt, in der keine große Technologie die Massen erreichen kann, ohne auf Widerstand zu stoßen, und QUIC ist keine Ausnahme.
Das Wichtigste ist, dass Sie dem Browser irgendwie erklären müssen, dass „https://“ keine Tatsache mehr ist, sondern zum TCP-Port 443 führt. Möglicherweise gibt es überhaupt kein TCP. Hierzu wird der Alt-Svc-Header verwendet. Damit können Sie dem Browser mitteilen, dass diese Website auch auf diesem und jenem Protokoll unter dieser und jener Adresse verfügbar ist. Theoretisch sollte das wie ein Zauber funktionieren, in der Praxis werden wir jedoch auf die Tatsache stoßen, dass UDP beispielsweise auf einer Firewall verboten werden kann, um DDoS-Angriffe zu verhindern.
Aber selbst wenn UDP nicht verboten ist, befindet sich der Client möglicherweise hinter einem NAT-Router, der so konfiguriert ist, dass er eine TCP-Sitzung über die IP-Adresse hält, und das auch noch Wir verwenden UDP, das keine Hardware-Sitzung hat, NAT hält die Verbindung nicht und eine QUIC-Sitzung .
All diese Probleme sind darauf zurückzuführen, dass UDP bisher nicht zur Übertragung von Internetinhalten eingesetzt wurde und die Hardwarehersteller nicht vorhersehen konnten, dass dies jemals passieren würde. Ebenso verstehen Administratoren noch nicht wirklich, wie sie ihre Netzwerke richtig konfigurieren, damit QUIC funktioniert. Diese Situation wird sich allmählich ändern, und in jedem Fall werden solche Änderungen weniger Zeit in Anspruch nehmen als die Implementierung eines neuen Transportschichtprotokolls.
Darüber hinaus erhöht QUIC, wie bereits beschrieben, die CPU-Auslastung erheblich. Daniel Stenberg Prozessorwachstum um das Dreifache.
Wann kommt HTTP/3?
Standard bis Mai 2020, aber angesichts der Tatsache, dass die für Juli 2019 geplanten Dokumente derzeit noch nicht abgeschlossen sind, können wir sagen, dass der Termin höchstwahrscheinlich verschoben wird.
Nun, Google verwendet seine gQUIC-Implementierung seit 2013. Wenn Sie sich die HTTP-Anfrage ansehen, die an die Google-Suchmaschine gesendet wird, sehen Sie Folgendes:
Befund
QUIC sieht jetzt nach einer eher groben, aber vielversprechenden Technologie aus. Wenn man bedenkt, dass in den letzten 20 Jahren alle Optimierungen der Transportschichtprotokolle hauptsächlich TCP betrafen, sieht QUIC, das in den meisten Fällen die beste Leistung aufweist, bereits äußerst gut aus.
Allerdings gibt es noch ungelöste Probleme, die in den nächsten Jahren gelöst werden müssen. Der Prozess kann sich aufgrund der Tatsache, dass es sich um Hardware handelt, die niemand gerne aktualisiert, verzögern, aber dennoch scheinen alle Probleme durchaus lösbar zu sein, und früher oder später werden wir alle HTTP/3 haben.
Die Zukunft steht vor der Tür!
Source: habr.com