HTTP / 3: Breaking the Ground a Brave New World

Fir méi wéi 20 Joer hu mir Websäite gekuckt mat dem HTTP Protokoll. Déi meescht Benotzer denken net emol un wat et ass a wéi et funktionnéiert. Anerer wëssen datt iergendwou ënner HTTP TLS gëtt, an ënner deem TCP ass, ënner deem IP ass, a sou weider. An nach anerer - Heretics - gleewen datt TCP eng Saach vun der Vergaangenheet ass, si wëllen eppes méi séier, méi zouverléisseg a sécher. Awer an hire Versuche fir en neien ideale Protokoll ze erfannen, si si zréck an d'Technologie vun den 80er Joren a probéieren hir brave nei Welt drop ze bauen.

Eng kleng Geschicht: HTTP/1.1

Am Joer 1997 huet den Textinformatiounsaustauschprotokoll HTTP Versioun 1.1 säin eegene RFC kritt. Deemools gouf de Protokoll vu Browser fir e puer Joer benotzt, an den neie Standard huet weider fofzéng gedauert. De Protokoll huet nëmmen um Ufro-Äntwert Prinzip geschafft a war virun allem fir d'Transmissioun vun Textinformatioun geduecht.

HTTP gouf entwéckelt fir uewen um TCP Protokoll ze lafen, fir sécherzestellen datt Päck zouverlässeg op hir Destinatioun geliwwert ginn. TCP funktionnéiert andeems se eng zouverlässeg Verbindung tëscht Endpunkte etabléiert an ënnerhalen an de Traffic a Segmenter briechen. Segmenter hunn hir eege Seriennummer a Kontrollsumme. Wann op eemol ee vun de Segmenter net ukomm ass oder mat enger falscher Kontrollsumm kënnt, da stoppt d'Transmissioun bis de verluerene Segment restauréiert ass.

An HTTP/1.0 gouf d'TCP Verbindung no all Ufro zougemaach. Dëst war extrem verschwendend, well ... eng TCP Verbindung (3-Way-Handshake) opzebauen ass e luesen Prozess. HTTP/1.1 huet den Keep-alive Mechanismus agefouert, deen Iech erlaabt eng Verbindung fir verschidde Ufroen ze benotzen. Wéi och ëmmer, well et einfach e Flaschenhals ka ginn, erlaaben verschidde Implementatioune vun HTTP/1.1 datt verschidde TCP Verbindunge mam selwechte Host opgemaach ginn. Zum Beispill, Chrome a rezent Versioune vu Firefox erlaben bis zu sechs Verbindungen.

D'Verschlësselung sollt och un aner Protokoller iwwerlooss ginn, a fir dëst gouf den TLS-Protokoll iwwer TCP benotzt, wat d'Donnéeën zouverlässeg geschützt huet, awer d'Zäit erfuerderlech fir eng Verbindung ze grënnen. Als Resultat huet de Handshakeprozess ugefaang esou ausgesinn:

Cloudflare Illustratioun

Also hat HTTP/1.1 eng Rei Probleemer:

• Lues Verbindung Setup.
• Daten ginn an Textform iwwerdroen, dat heescht datt d'Transmissioun vu Biller, Videoen an aner net-Textinformatioun net effikass ass.
• Eng TCP Verbindung gëtt fir eng Ufro benotzt, dat heescht datt aner Ufroe mussen entweder eng aner Verbindung fannen oder waarden bis déi aktuell Ufro se verëffentlecht.
• Nëmmen de Pullmodell gëtt ënnerstëtzt. Et gëtt näischt am Standard iwwer Server-Push.
• Rubriken ginn am Text iwwerdroen.

Wann Server-Push op d'mannst mam WebSocket Protokoll implementéiert gëtt, da missten déi verbleiwen Probleemer méi radikal behandelt ginn.

E bësse Modernitéit: HTTP/2

Am 2012 huet Google ugefaang um SPDY (ausgeschwat "speedy") Protokoll ze schaffen. De Protokoll gouf entwéckelt fir d'Haaptproblemer vun HTTP / 1.1 ze léisen a gläichzäiteg sollt d'Réckkompatibilitéit erhalen. Am 2015 huet den IETF Aarbechtsgrupp d'HTTP/2 Spezifizéierung op Basis vum SPDY Protokoll agefouert. Hei sinn d'Ënnerscheeder am HTTP/2:

• Binär Serialiséierung.
• Multiplexing multiple HTTP-Ufroen an eng eenzeg TCP Verbindung.
• Server-Push aus der Këscht (ouni WebSocket).

De Protokoll war e grousse Schrëtt no vir. Hien staark schléit déi éischt Versioun a Geschwindegkeet a erfuerdert net d'Schafung vu multiple TCP Verbindungen: all Ufroe fir een Host ginn an een multiplexéiert. Dat ass, an enger Verbindung ginn et e puer sougenannte Streamen, jidderee vun deenen seng eegen ID huet. De Bonus ass e Boxed Server-Push.

Wéi och ëmmer, Multiplexing féiert zu engem anere Schlësselproblem. Stellt Iech vir datt mir asynchron 5 Ufroen op ee Server ausféieren. Wann Dir HTTP/2 benotzt, ginn all dës Ufroe bannent der selwechter TCP Verbindung duerchgefouert, dat heescht datt wann ee vun de Segmenter vun enger Ufro verluer ass oder falsch empfänkt, d'Transmissioun vun all Ufroen an Äntwerte stoppt bis de verluerene Segment ass. restauréiert. Natierlech, wat méi schlecht d'Verbindungsqualitéit ass, dest méi lues funktionnéiert HTTP/2. Dem Daniel Stenberg no, a Bedéngungen, wou verluere Pakete fir 2% vun alle Paketen ausmaachen, funktionnéiert HTTP/1.1 am Browser besser wéi HTTP/2 wéinst der Tatsaach, datt et 6 Verbindungen opmaacht anstatt eng.

Dëse Problem gëtt "Head-of-Line Blocking" genannt an et ass leider net méiglech et ze léisen wann Dir TCP benotzt.

Illustratioun vum Daniel Steinberg

Als Resultat hunn d'Entwéckler vum HTTP / 2 Standard eng super Aarbecht gemaach an hunn bal alles gemaach wat an der Applikatiounsschicht vum OSI Modell gemaach ka ginn. Et ass Zäit op d'Transportschicht erof ze goen an en neien Transportprotokoll ze erfannen.

Mir brauchen en neie Protokoll: UDP vs TCP

Zimlech séier gouf et kloer datt d'Ëmsetzung vun engem komplett neien Transportschichtprotokoll eng onméiglech Aufgab an der heiteger Realitéit ass. D'Tatsaach ass datt d'Hardware oder d'Mëttelboxen (Router, Firewalls, NAT Serveren ...) iwwer d'Transportschicht wëssen, an hinnen eppes Neies ze léieren ass eng extrem schwiereg Aufgab. Zousätzlech ass d'Ënnerstëtzung fir Transportprotokoller an de Kernel vun de Betribssystemer agebaut, an d'Kären sinn och net ganz gewëllt ze änneren.

An hei kéint een d'Hänn an d'Hand werfen a soen "Mir erfannen natierlech en neien HTTP/3 mat Preferenz a Courtesane, awer et dauert 10-15 Joer fir ëmgesat ze ginn (no ongeféier dës Zäit wäert de gréissten Deel vun der Hardware sinn ersat)", awer et gëtt eng méi net sou Déi offensichtlech Optioun ass den UDP Protokoll ze benotzen. Jo, jo, dee selwechte Protokoll dee mir benotzt hunn fir Dateien iwwer LAN an de spéiden XNUMXer an fréien XNUMXer ze werfen. Bal all haut d'Hardware kann mat et schaffen.

Wat sinn d'Virdeeler vun UDP iwwer TCP? Als éischt hu mir keng Transportschichtsessioun déi d'Hardware weess. Dëst erlaabt eis d'Sessioun op den Endpunkte selwer ze bestëmmen a Konflikter do ze léisen. Dat ass, mir sinn net limitéiert op eng oder e puer Sessiounen (wéi am TCP), mee kënne sou vill vun hinnen erstellen wéi mir brauchen. Zweetens, Dateniwwerdroung iwwer UDP ass méi séier wéi iwwer TCP. Also, an der Theorie, kënne mir déi aktuell Geschwindegkeet Plafong duerchbriechen, déi am HTTP/2 erreecht gëtt.

Wéi och ëmmer, UDP garantéiert keng zouverlässeg Dateniwwerdroung. Tatsächlech schécken mir einfach Päckchen, an der Hoffnung datt deen aneren Enn se kritt. Hutt net kritt? Gutt, kee Gléck ... Dëst war genuch fir Videoe fir Erwuessener ze iwwerdroen, awer fir méi sérieux Saache brauch Dir Zouverlässegkeet, dat heescht datt Dir eppes anescht op UDP wéckelt.

Wéi mat HTTP/2, hunn d'Aarbechten un der Schafung vun engem neie Protokoll bei Google am Joer 2012 ugefaang, dat heescht ongeféier d'selwescht Zäit wéi d'Aarbechten um SPDY ugefaang hunn. Am Joer 2013 huet Jim Roskind dem allgemenge Public presentéiert QUIC (Quick UDP Internet Connections) Protokoll, a schonn 2015 gouf den Internet Draft fir Standardiséierung am IETF agefouert. Schonn zu där Zäit war de Protokoll deen Roskind bei Google entwéckelt huet ganz anescht wéi de Standard, sou datt d'Google Versioun ugefaang huet gQUIC ze ginn.

Wat ass QUIC

Als éischt, wéi scho gesot, ass dëst e Wrapper iwwer UDP. Eng QUIC Verbindung klëmmt uewen op UDP, an deem, Analogie mat HTTP/2, verschidde Streame kënne existéieren. Dës Stréimunge existéieren nëmmen op den Endpunkten a ginn onofhängeg zerwéiert. Wann e Paketverloscht an engem Stroum geschitt, wäert et anerer net beaflossen.

Illustratioun vum Daniel Steinberg

Zweetens gëtt d'Verschlësselung net méi op engem getrennten Niveau ëmgesat, mee ass am Protokoll abegraff. Dëst erlaabt Iech eng Verbindung ze etabléieren an ëffentlech Schlësselen an engem eenzegen Handshake auszetauschen, an erlaabt Iech och de cleveren 0-RTT Handshakemechanismus ze benotzen an Handshake Verspéidungen ganz ze vermeiden. Zousätzlech ass et elo méiglech individuell Datepäck ze verschlësselen. Dëst erlaabt Iech net op d'Fäerdegstellung vun der Erhaalung vun Daten aus dem Stream ze waarden, awer fir déi empfangene Pakete onofhängeg ze entschlësselen. Dëse Modus vun Operatioun war am TCP allgemeng onméiglech, well TLS an TCP hunn onofhängeg vuneneen geschafft, an TLS konnt net wëssen a wéi eng Stécker TCP-Date gehackt ginn. An dofir konnt hien seng Segmenter net virbereeden, sou datt se an TCP-Segmenter een op een passen an onofhängeg decryptéiert kënne ginn. All dës Verbesserungen erlaben QUIC d'Latenz ze reduzéieren am Verglach zum TCP.

Drëttens, d'Konzept vum Liichtstreaming erlaabt Iech d'Verbindung vun der IP Adress vum Client ofzekoppelen. Dëst ass wichteg, zum Beispill, wann e Client vun engem Wi-Fi Zougangspunkt op en aneren wiesselt, seng IP ännert. An dësem Fall, wann Dir TCP benotzt, geschitt e laange Prozess während deem existéierend TCP Verbindunge Timeout an nei Verbindunge vun enger neier IP erstallt ginn. Am Fall vu QUIC setzt de Client einfach weider Päckchen op de Server vun enger neier IP mat der aler Stream ID ze schécken. Well D'Stream-ID ass elo eenzegaarteg a gëtt net weiderbenotzt, de Server versteet datt de Client IP geännert huet, verluere Pakete schéckt a weider Kommunikatioun op der neier Adress.

Véierten, QUIC gëtt um Applikatiounsniveau implementéiert, net um Betribssystemniveau. Dëst, engersäits, erlaabt Iech séier Ännerungen am Protokoll ze maachen, well Fir en Update ze kréien, musst Dir just d'Bibliothéik aktualiséieren, anstatt op eng nei OS Versioun ze waarden. Op der anerer Säit féiert dëst zu enger staarker Erhéijung vum Prozessorverbrauch.

An endlech d'Schlagzeilen. Header Kompressioun ass eng vun de Saachen déi tëscht QUIC an gQUIC ënnerscheeden. Ech gesinn net de Punkt fir vill Zäit fir dëst ze widmen, ech wäert just soen datt an der Versioun, déi fir Standardiséierung presentéiert gouf, Header Kompressioun sou ähnlech wéi méiglech gemaach gouf wéi Header Kompressioun an HTTP / 2. Dir kënnt méi liesen hei.

Wéi vill méi séier ass et?

Et ass eng schwéier Fro. De Fakt ass datt bis mir e Standard hunn, gëtt et näischt Besonnesches ze moossen. Vläicht déi eenzeg Statistike déi mir hunn sinn Statistike vu Google, déi gQUIC zënter 2013 an 2016 benotzt dem IETF gemelltdatt ongeféier 90% vum Traffic, deen op hir Servere vum Chrome Browser geet, elo QUIC benotzt. An der selwechter Presentatioun mellen se datt Säiten ongeféier 5% méi séier duerch gQUIC lueden an et gi 30% manner Stotteren am Video Streaming am Verglach zum TCP.

Am 2017 huet eng Grupp vu Fuerscher gefouert vum Arash Molavi Kakhki publizéiert super Aarbecht d'Leeschtung vun gQUIC am Verglach zu TCP ze studéieren.
D'Studie huet verschidde Schwächen vu gQUIC opgedeckt, sou wéi Onstabilitéit fir d'Vermëschung vun Netzpakete, Gierlechkeet (Ongerechtegkeet) fir d'Bandbreedung ze kanaliséieren a méi lues Transfer vu klenge (bis zu 10 kb) Objeten. Déi lescht kann awer kompenséiert ginn andeems Dir 0-RTT benotzt. An all anere Fäll studéiert, huet gQUIC eng Erhéijung vun der Geschwindegkeet am Verglach zum TCP gewisen. Et ass schwéier iwwer spezifesch Zuelen hei ze schwätzen. Besser liesen d'Etude selwer oder kuerz Post.

Hei muss gesot ginn datt dës Donnéeën speziell iwwer gQUIC handelen, an et ass net relevant fir de Standard deen entwéckelt gëtt. Wat geschitt fir QUIC: et ass nach ëmmer e Geheimnis, awer et gëtt Hoffnung datt d'Schwächten, déi am gQUIC identifizéiert goufen, berücksichtegt a korrigéiert ginn.

E bësse vun der Zukunft: wat iwwer HTTP/3?

Awer hei ass alles glaskloer: d'API wäert op kee Fall änneren. Alles bleift genau d'selwecht wéi et an HTTP/2 war. Gutt, wann d'API d'selwecht bleift, muss den Iwwergank op HTTP / 3 geléist ginn andeems Dir eng frësch Versioun vun der Bibliothéik um Backend benotzt, deen QUIC Transport ënnerstëtzt. Richteg, Dir musst de Réckfall op al Versioune vun HTTP fir eng laang Zäit halen, well Den Internet ass momentan net prett fir e kompletten Iwwergang op UDP.

Wien schonn ënnerstëtzt

hei Lëscht bestehend QUIC Implementatiounen. Trotz dem Mangel un engem Standard ass d'Lëscht net schlecht.

Kee Browser ënnerstëtzt de Moment QUIC an enger Produktiounsrelease. Viru kuerzem gouf et Informatioun datt Ënnerstëtzung fir HTTP / 3 am Chrome abegraff ass, awer bis elo nëmmen op Kanaresch.

Vun de Backends ënnerstëtzt HTTP/3 nëmmen Caddy и Cloudflare, awer nach ëmmer experimentell. NGINX um Enn vum Fréijoer 2019 ugekënnegt, datt se ugefaang hunn un HTTP/3 Ënnerstëtzung ze schaffen, awer nach net fäerdeg sinn.

Wat sinn d'Problemer?

Dir an ech liewen an der realer Welt, wou keng grouss Technologie d'Massen erreechen kann ouni Resistenz ze treffen, a QUIC ass keng Ausnahm.

Déi wichtegst Saach ass datt Dir iergendwéi dem Browser erkläre musst datt "https://" net méi e Fakt ass datt et op den TCP Hafen 443 féiert. Et kann guer net TCP ginn. Den Alt-Svc Header gëtt dofir benotzt. Et erlaabt Iech de Browser ze soen datt dës Websäit och op esou an esou engem Protokoll op esou an esou enger Adress verfügbar ass. An der Theorie soll dëst wéi e Charme funktionnéieren, awer an der Praxis komme mir op d'Tatsaach datt UDP zum Beispill op enger Firewall verbuede ka ginn fir DDoS Attacken ze vermeiden.

Awer och wann UDP net verbueden ass, kann de Client hannert engem NAT Router sinn deen konfiguréiert ass fir eng TCP Sessioun duerch IP Adress ze halen, an zënter mir benotzen UDP, déi keng Hardware Sëtzung huet, NAT wäert d'Verbindung net halen, an eng QUIC Sëtzung wäert stänneg ofbriechen.

All dës Probleemer si wéinst der Tatsaach datt UDP net virdru benotzt gouf fir den Internetinhalt ze vermëttelen, an d'Hardwarehersteller konnten net viraussoen datt dëst jee géif geschéien. Am selwechte Wee verstinn d'Administrateuren nach net wierklech wéi se hir Netzwierker richteg konfiguréieren fir datt QUIC funktionnéiert. Dës Situatioun wäert sech no an no änneren, an op alle Fall wäerten esou Ännerungen manner Zäit daueren wéi d'Ëmsetzung vun engem neien Transportschichtprotokoll.

Zousätzlech, wéi scho beschriwwen, erhéicht QUIC d'CPU Benotzung staark. Daniel Stenberg bewäert Prozessor Wuesstem bis zu dräimol.

Wéini kënnt HTTP/3?

Standard wëlle akzeptéieren bis Mee 2020, awer well d'Dokumenter, déi fir Juli 2019 geplangt sinn, am Moment ongeschloss bleiwen, kënne mir soen datt den Datum héchstwahrscheinlech zréckgedréckt gëtt.

Gutt, Google huet seng gQUIC Implementatioun zënter 2013 benotzt. Wann Dir d'HTTP-Ufro kuckt, déi op d'Google Sichmotor geschéckt gëtt, gesitt Dir dëst:

Conclusiounen

QUIC gesäit elo aus wéi eng zimlech rau, awer ganz villverspriechend Technologie. Bedenkt datt iwwer déi lescht 20 Joer all Optimisatiounen vun Transportschichtprotokollen haaptsächlech TCP betraff hunn, QUIC, déi meeschtens déi bescht Leeschtung huet, gesäit schonn extrem gutt aus.

Et sinn awer nach ongeléiste Problemer, déi an den nächste Jore musse gehandhabt ginn. De Prozess kann verspéit ginn wéinst der Tatsaach, datt et Hardware involvéiert ass, déi kee gär aktualiséieren, awer trotzdem gesinn all d'Problemer zimlech léisbar aus, a fréier oder spéider wäerte mir all HTTP/3 hunn.

D'Zukunft ass just ronderëm den Eck!

Source: will.com