Dreieinhalb Jahre sind seit der Einführung des HTTP / 2-Standards vergangen: Die RFC 7540- Spezifikation wurde im Mai 2015 veröffentlicht, wird jedoch noch nicht überall verwendet. Das Protokoll wurde seit Ende 2015 in allen Browsern implementiert, und nach drei Jahren unterstützen nur 31,2% der 10 Millionen beliebtesten Internetseiten HTTP / 2. Von den beliebtesten Websites haben Google, Youtube, Wikipedia, Twitter, Vk.com und andere darauf umgestellt.

Trotzdem steht der Fortschritt nicht still - und an der nächsten Version von HTTP / 3 wird bereits gearbeitet. Wie jetzt bekannt wurde, haben die Entwickler von zwei alternativen Optionen Kompatibilität erreicht, und das HTTP-over-QUIC-Protokoll ändert nun seinen Namen und heißt offiziell HTTP / 3 . Dementsprechend wird in einer zukünftigen Version von HTTP der TCP-Transport durch QUIC ersetzt.

Verwechslung mit verschiedenen QUIC-Optionen

QUIC ist ein TCP-Ersatz, der auf UDP aufbaut. Ursprünglich wurde diese Technologie von Google-Ingenieuren wie das vorherige SPDY-Protokoll entwickelt, das die Grundlage für HTTP / 2 bildete. Zunächst wurde QUIC als "HTTP / 2-verschlüsselt über UDP" bezeichnet.

Die QUIC-Entwicklung wurde dann zur Standardisierung an die IETF übertragen. Hier wurde es in zwei Teile geteilt: Transport und HTTP. Die Idee ist, dass das Transportprotokoll auch zum Übertragen anderer Daten verwendet werden kann, und zwar nicht nur ausschließlich für HTTP- oder HTTP-ähnliche Protokolle. Der Name bleibt jedoch gleich: QUIC. Das Transportprotokoll wird von der QUIC-Arbeitsgruppe des Internet Engineering Council (IETF) entwickelt.

Gleichzeitig arbeitete Google weiter an seiner eigenen Implementierung - und implementierte sie im Chrome-Browser. Tests zeigen zwar, dass die QUIC-Implementierung von Google erheblich schlechter ist als die von TCP, wenn das Netzwerk keine Paketzustellung garantiert .


Leistungsunterschied zwischen QUIC mit TCP (in Prozent) in einem Netzwerk mit 112 ms RTT und 10 ms Jitter, Quelle


Leistungsunterschied zwischen QUIC mit TCP (in Prozent) in einem Netzwerk mit RTT 112 ms und 10 ms Jitter, wodurch sich die Reihenfolge der Pakete ändert, Quelle

Einige Entwickler bezeichnen im Allgemeinen jede Version von QUIC unter UDP als "wildestes Experiment".

Die Zwietracht in QUIC-Versionen und Namen wird von Daniel Stenberg, Lead Curl-Entwickler bei Mozilla, erklärt, der diese Geschichte schon lange verfolgt.

Ihm zufolge haben sich informelle Namen der beiden Versionen von QUIC unter den Entwicklern verbreitet, da die Optionen von IETF und Google in den Implementierungsdetails erheblich variieren:

• iQUIC (IETF-Version)
• gQUIC (Google-Version)

Das Protokoll zum Senden von HTTP über iQUIC (IETF-Version) wird seit langem als "hq" (HTTP-over-QUIC) bezeichnet.

Im Allgemeinen gab es keinen festgelegten Namen für verschiedene Versionen. Beim QUIC Workshop-Seminar erschreckte Mike Bishop alle mit einer Folie, als wäre es ein Logo.


Folie aus Mike Bishops Präsentation

Die Workshop-Moderatoren baten Mike, es nie wieder zu zeigen .

Am 7. November 2018 gab jedoch einer der führenden Entwickler des Protokolls, Dmitry Tikhonov, bekannt, dass LiteSpeed ​​Tech und Facebook die Protokollkompatibilität erreicht haben. Die Entwicklung wird nun in die gleiche Richtung fortgesetzt.

Mark Nottingham, einer der einflussreichsten IETF-Ingenieure, Co-Autor mehrerer Webstandards, schlug im September die Kombination von iQUIC und gQUIC mit dem Namen HTTP / 3 vor . Ihm zufolge wird dies dazu beitragen, Verwechslungen zwischen dem QIUC-Transport und dem QUIC-Wrapper für HTTP zu vermeiden.

Daher ist HTTP / 3 die neue Version von HTTP, die den QUIC-Transport verwendet .

QUIC Transport

Was sind die Vorteile des QUIC-Transportprotokolls gegenüber TCP? Es gibt viele Vorteile, und laut Mark Nottingham selbst ist der Übergang von veraltetem TCP zu neuen Protokollen einfach unvermeidlich, da jetzt offensichtlich ist, dass TCP unter Ineffizienzproblemen leidet.

„Da TCP ein Paketübermittlungsprotokoll ist, kann der Verlust eines Pakets die Übermittlung nachfolgender Pakete vom Puffer an die Anwendung beeinträchtigen. In einem Multiplex-Protokoll kann dies zu einem großen Leistungsverlust führen “, erklärt Mark Nottingham. "QUIC versucht, dieses Problem zu lösen, indem die Semantik von TCP (zusammen mit einigen Aspekten des HTTP / 2-Stream-Modells) über UDP effektiv wiederhergestellt wird."



Neben der Umstellung eines erheblichen Datenverkehrs von TCP auf UDP müssen sowohl Google QUIC (gQUIC) als auch IETF QUIC (iQUIC) verschlüsselt werden: Unverschlüsseltes QUIC ist überhaupt nicht vorhanden . iQUIC verwendet TLS 1.3, um Sitzungsschlüssel festzulegen und dann jedes Paket zu verschlüsseln. Da es jedoch auf UDP basiert, werden viele der in TCP geöffneten Sitzungsinformationen und Metadaten in QUIC verschlüsselt.

In dem Artikel „Die Zukunft der Internetprotokolle“ spricht Mark Nottingham über signifikante Sicherheitsverbesserungen beim Wechsel zu QUIC:

Tatsächlich gibt der aktuelle "Short Header" iQUIC, der für alle Pakete außer einem Handshake verwendet wird, nur die Paketnummer, die optionale Verbindungskennung und das Statusbyte aus, die für Prozesse wie das Ändern von Verschlüsselungsschlüsseln und Pakettyp (die auch verschlüsselt werden können) erforderlich sind. Alles andere ist verschlüsselt - einschließlich ACK-Paketen, was die Messlatte für Angriffe mit Verkehrsanalyse erheblich höher legt .

Darüber hinaus wird es unmöglich, RTT und Paketverlust passiv zu bewerten, indem einfach die Verbindung überwacht wird. Dafür gibt es nicht genügend Informationen.

Die mangelnde Beobachtbarkeit gab einigen Vertretern der Gemeinschaft der Telekommunikationsbetreiber ernsthafte Besorgnis. Sie sagen, dass solche passiven Messungen für das Debuggen und Analysieren ihrer Netzwerke entscheidend sind.

Einer der Vorschläge zur Lösung dieses Problems ist die Einführung eines Spinbits . Dies ist ein Bit in der Kopfzeile, das seinen Wert einmal auf dem Roundtrip ändert, damit der Beobachter die RTT auswerten kann. Da es nicht an den Status der Anwendung gebunden ist, sollte es keine Informationen zu den Endpunkten liefern, außer einer ungefähren Schätzung des Netzwerkstandorts.

Möglicherweise wäre die Übernahme des QUIC-Standards früher erfolgt, wenn Google seine Implementierung nicht im Chrome-Browser implementiert hätte. Jetzt macht die proprietäre Version von iQUIC mehr als 7% des Datenverkehrs im Internet aus.

Dennoch sind Fortschritte unvermeidlich - und in den kommenden Jahren wird die Standardisierung und umfassende Implementierung verschiedener Protokolle der neuen Generation, einschließlich HTTP / 3 für den QUIC-Transport, definitiv fortgesetzt.

---