HTTP-over-QUIC wird offiziell zu HTTP / 3

    Dreieinhalb Jahre sind seit der Einführung des HTTP / 2-Standards vergangen: Die RFC 7540- Spezifikation wurde im Mai 2015 veröffentlicht, wird jedoch nicht überall verwendet. Das Protokoll ist seit Ende 2015 in allen Browsern implementiert. Drei Jahre später 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 gewechselt.

    Trotzdem steht der Fortschritt nicht still - und die nächste Version von HTTP / 3 ist bereits in Arbeit. Wie bekannt ist , haben die Entwickler der beiden Alternativen die Kompatibilität erreicht, und das Protokoll HTTP-over-QUIC ändert jetzt seinen Namen und wird offiziell als HTTP / 3 bezeichnet. Dementsprechend wird der TCP-Transport in einer zukünftigen Version von HTTP durch QUIC ersetzt.

    Verwechslung mit verschiedenen QUIC-Optionen


    QUIC ist ein TCP-Ersatz, der auf UDP basiert. Ursprünglich wurde diese Technologie von Google-Ingenieuren entwickelt, wie auch das vorherige SPDY-Protokoll, das zur Grundlage von HTTP / 2 wurde. QUIC wurde zunächst als "HTTP / 2-verschlüsselt über UDP" bezeichnet.

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

    Gleichzeitig arbeitete Google weiter an seiner eigenen Implementierung - und implementierte sie im Chrome-Browser. Obwohl Tests das zeigenDie QUIC-Implementierung von Google funktioniert viel schlechter als TCP, wenn das Netzwerk die Reihenfolge der Paketzustellung nicht garantiert .


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


    Der Unterschied in der Leistung zwischen QUIC mit TCP (in Prozent) in einem Netzwerk mit 112 ms RTT und 10 ms Jitter, wodurch die Reihenfolge der Pakete geändert wird. Die Quelle

    Einige Entwickler nennen sogar jede Version von QUIC für UDP "das wildeste Experiment" .

    Die Unterschiede bei den QUIC-Versionen und deren Benennung werden von Daniel Stenberg erklärt, einem führenden Entwickler von Locken, der für Mozilla arbeitet. Er verfolgt diese Geschichte seit langem.

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

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

    Das Protokoll zum Übertragen von HTTP über iQUIC (IETF-Version) wurde lange als "hq" (HTTP-over-QUIC) bezeichnet.

    Im Allgemeinen gab es für verschiedene Versionen keinen festen Namen. Beim QUIC-Workshop hat Mike Bishop mit dieser Folie jeden als ein Logo erschreckt.


    Folie von der Präsentation von Mike Bishop

    Die Workshopleiter baten Mike, es nie wieder zu zeigen .

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

    Merge Iquic und gQUIC genannt HTTP / 3 im September vorgeschlagenMark Nottingham, einer der einflussreichsten Ingenieure der IETF, war Mitautor mehrerer Webstandards. Seiner Meinung nach hilft dies, die Verwirrung zwischen dem QIUC-Transport und dem QUIC-Wrapper für HTTP zu beseitigen.

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

    QUIC-Transport


    Was sind die Vorteile des QUIC-Transportprotokolls gegenüber TCP? Die Vorteile sind vielfältig, und die Worte von Mark Nottingham, der Übergang von Legacy neuen TCP - Protokollen einfach unvermeidlich, weil es klar ist , dass TCP von Ineffizienz Problemen leidet.

    „Da TCP ein Paketübermittlungsprotokoll in der richtigen Reihenfolge ist, kann der Verlust eines Pakets verhindern, dass die Anwendung nachfolgende Pakete aus dem Puffer liefert. In einem Multiplex-Protokoll kann dies zu einem erheblichen Leistungsverlust führen, erklärt Mark Nottingham. "QUIC versucht, dieses Problem zu lösen, indem die TCP-Semantik (zusammen mit einigen Aspekten des HTTP / 2-Streaming-Modells) über UDP effektiv neu erstellt wird."



    Neben dem Umschalten einer erheblichen Menge an Datenverkehr von TCP zu UDP und Google QUIC (gQUIC) und IETF QUIC (iQUIC) ist eine obligatorische Verschlüsselung erforderlich: Eine unverschlüsselte QUIC ist überhaupt nicht vorhanden . iQUIC verwendet TLS 1.3, um Sitzungsschlüssel festzulegen und 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 wesentliche Verbesserungen der Sicherheit beim Wechsel zu QUIC:

    Tatsächlich erhalten Sie mit dem aktuellen "kurzen Header" von iQUIC , der für alle Pakete außer Handshaking verwendet wird, nur die Paketnummer, eine optionale Verbindungskennung und ein Statusbyte, die für Prozesse wie das Ändern von Verschlüsselungsschlüsseln und einen Pakettyp (der auch verschlüsselt werden kann) erforderlich ist. Alles andere ist verschlüsselt - einschließlich ACK-Paketen, was die Messlatte für die Durchführung von Angriffen mit Verkehrsanalyse erheblich anhebt .

    Außerdem wird es unmöglich, RTT- und Paketverluste durch einfaches Überwachen der Verbindung passiv auszuwerten. Dafür gibt es nicht genug Informationen.

    Die mangelnde Beobachtbarkeit hat bei einigen Vertretern der Kommunikationsbetreibergemeinde große Besorgnis ausgelöst. Sie sagen, dass solche passiven Messungen für das Debugging und die Analyse ihrer Netzwerke kritisch sind.

    Ein Vorschlag zur Lösung dieses Problems ist die Einführung eines Spin-Bits . Dies ist ein Bit im Header, das seinen Wert einmal auf dem Weg hin und her ändert, sodass der Beobachter die RTT bewerten kann. Da es nicht an den Status der Anwendung gebunden ist, sollte es keine Informationen über die Endpunkte bereitstellen, mit Ausnahme einer ungefähren Schätzung des Netzwerkstandorts.

    Möglicherweise wäre die Einführung des QUIC-Standards bereits vorgekommen, wenn Google die Implementierung im Chrome-Browser nicht eilig gemacht hätte. Jetzt macht die proprietäre Version von iQUIC mehr als 7% des Datenverkehrs im Internet aus.

    Trotzdem sind Fortschritte unvermeidlich - und in den kommenden Jahren werden die Standardisierung und die weit verbreitete Einführung verschiedener Protokolle der neuen Generation, einschließlich HTTP / 3, auf dem QUIC-Transport fortgesetzt.




    Jetzt auch beliebt: