Fa més de 20 anys que estem veient pàgines web mitjançant el protocol HTTP. La majoria dels usuaris ni tan sols pensen en què és i com funciona. Altres saben que en algun lloc sota HTTP hi ha TLS, i sota d'això hi ha TCP, sota el qual hi ha IP, etc. I encara d'altres - heretges - creuen que el TCP és cosa del passat volen alguna cosa més ràpida, més fiable i segura. Però en els seus intents d'inventar un nou protocol ideal, han tornat a la tecnologia dels anys 80 i estan intentant construir-hi el seu nou món valent.
Una mica d'història: HTTP/1.1
El 1997, el protocol d'intercanvi d'informació de text HTTP versió 1.1 va adquirir el seu propi RFC. Aleshores, els navegadors feien servir el protocol durant diversos anys, i el nou estàndard va durar quinze més. El protocol només funcionava segons el principi de petició-resposta i estava destinat principalment a la transmissió d'informació de text.
HTTP es va dissenyar per executar-se a la part superior del protocol TCP, assegurant que els paquets s'entreguen de manera fiable a la seva destinació. TCP funciona establint i mantenint una connexió fiable entre punts finals i dividint el trànsit en segments. Els segments tenen el seu propi número de sèrie i suma de verificació. Si de sobte un dels segments no arriba o arriba amb una suma de verificació incorrecta, la transmissió s'aturarà fins que es recuperi el segment perdut.
A HTTP/1.0, la connexió TCP es va tancar després de cada sol·licitud. Això va ser molt malbaratador, perquè... establir una connexió TCP (3-Way-Handshake) és un procés lent. HTTP/1.1 va introduir el mecanisme de manteniment, que us permet reutilitzar una connexió per a diverses sol·licituds. Tanmateix, com que es pot convertir fàcilment en un coll d'ampolla, diverses implementacions d'HTTP/1.1 permeten obrir múltiples connexions TCP al mateix host. Per exemple, Chrome i les versions recents de Firefox permeten fins a sis connexions.
El xifratge també s'havia de deixar en mans d'altres protocols, i per això es va utilitzar el protocol TLS sobre TCP, que protegia de manera fiable les dades, però augmentava encara més el temps necessari per establir una connexió. Com a resultat, el procés d'encaixada de mans va començar a semblar així:
Il·lustració de Cloudflare
Així, HTTP/1.1 va tenir una sèrie de problemes:
- Configuració de connexió lenta.
- Les dades es transmeten en forma de text, la qual cosa significa que la transmissió d'imatges, vídeos i altra informació no textual és ineficaç.
- S'utilitza una connexió TCP per a una sol·licitud, el que significa que altres sol·licituds han de trobar una altra connexió o esperar fins que la sol·licitud actual l'alliberi.
- Només s'admet el model pull. No hi ha res a l'estàndard sobre server-push.
- Els encapçalaments es transmeten en text.
Si el servidor push s'implementa com a mínim mitjançant el protocol WebSocket, els problemes restants s'havien de tractar de manera més radical.
Una mica de modernitat: HTTP/2
El 2012, Google va començar a treballar en el protocol SPDY (pronunciat "ràpid"). El protocol va ser dissenyat per resoldre els principals problemes d'HTTP/1.1 i, al mateix temps, se suposava que mantingués la compatibilitat enrere. El 2015, el grup de treball de l'IETF va introduir l'especificació HTTP/2 basada en el protocol SPDY. Aquí hi ha les diferències en HTTP/2:
- Serialització binària.
- Multiplexació de múltiples peticions HTTP en una única connexió TCP.
- Server-push fora de la caixa (sense WebSocket).
El protocol va ser un gran pas endavant. Ell amb força i no requereix la creació de múltiples connexions TCP: totes les sol·licituds a un host es multiplexen en un. És a dir, en una connexió hi ha diversos anomenats fluxos, cadascun dels quals té el seu propi identificador. La bonificació és un servidor push en caixa.
Tanmateix, la multiplexació condueix a un altre problema clau. Imagineu que estem executant de manera asíncrona 5 peticions a un servidor. Quan s'utilitza HTTP/2, totes aquestes sol·licituds es realitzaran dins de la mateixa connexió TCP, la qual cosa significa que si un dels segments d'alguna petició es perd o es rep de manera incorrecta, la transmissió de totes les peticions i respostes s'aturarà fins que el segment perdut s'aturarà. restaurada. Òbviament, com pitjor sigui la qualitat de la connexió, més lent funciona HTTP/2. , en condicions en què els paquets perduts representen el 2% de tots els paquets, HTTP/1.1 al navegador funciona millor que HTTP/2 a causa del fet que obre 6 connexions en lloc d'una.
Aquest problema s'anomena "bloqueig de cap de línia" i, malauradament, no és possible resoldre'l quan s'utilitza TCP.
Il·lustració de Daniel Steinberg
Com a resultat, els desenvolupadors de l'estàndard HTTP/2 van fer una gran feina i van fer gairebé tot el que es podia fer a la capa d'aplicació del model OSI. És hora de baixar a la capa de transport i inventar un nou protocol de transport.
Necessitem un nou protocol: UDP vs TCP
Molt ràpidament es va fer evident que la implementació d'un protocol de capa de transport completament nou és una tasca impossible en les realitats actuals. El cas és que el maquinari o les caixes mitjanes (encaminadors, tallafocs, servidors NAT...) coneixen la capa de transport, i ensenyar-los alguna cosa nova és una tasca extremadament difícil. A més, el suport per als protocols de transport està integrat al nucli dels sistemes operatius, i els nuclis tampoc estan molt disposats a canviar.
I aquí es podria aixecar les mans i dir "Nosaltres, per descomptat, inventarem un nou HTTP/3 amb preferència i cortesanes, però trigaran entre 10 i 15 anys a implementar-se (al cap d'aquest temps la majoria del maquinari estarà substituït)," però n'hi ha un més que no és així. L'opció òbvia és utilitzar el protocol UDP. Sí, sí, el mateix protocol que vam utilitzar per llançar fitxers per LAN a finals dels noranta i principis dels XNUMX. Gairebé tot el maquinari actual pot funcionar amb ell.
Quins avantatges té UDP sobre TCP? En primer lloc, no tenim una sessió de capa de transport que el maquinari conegui. Això ens permet determinar nosaltres mateixos la sessió als punts finals i resoldre els conflictes allà. És a dir, no estem limitats a una o diverses sessions (com en TCP), sinó que podem crear-ne tantes com necessitem. En segon lloc, la transmissió de dades mitjançant UDP és més ràpida que mitjançant TCP. Així, en teoria, podem trencar el sostre de velocitat actual aconseguit a HTTP/2.
Tanmateix, UDP no garanteix la transmissió de dades fiable. De fet, simplement estem enviant paquets, amb l'esperança que l'altre extrem els rebi. No han rebut? Bé, no hi ha sort... Això va ser suficient per transmetre vídeos per a adults, però per a coses més serioses cal fiabilitat, la qual cosa vol dir que s'ha d'embolicar una altra cosa a sobre d'UDP.
Igual que amb HTTP/2, el treball de creació d'un nou protocol va començar a Google l'any 2012, és a dir, més o menys al mateix temps que es va començar a treballar en SPDY. El 2013, Jim Roskind es va presentar al públic en general , i ja l'any 2015 es va introduir l'Internet Draft per a l'estandardització a l'IETF. Ja en aquell moment, el protocol desenvolupat per Roskind a Google era molt diferent de l'estàndard, per la qual cosa la versió de Google va començar a anomenar-se gQUIC.
Què és QUIC
En primer lloc, com ja s'ha esmentat, es tracta d'un embolcall sobre UDP. Una connexió QUIC s'eleva a sobre d'UDP, en la qual, per analogia amb HTTP/2, poden existir diversos fluxos. Aquests fluxos només existeixen als punts finals i es serveixen de manera independent. Si es produeix una pèrdua de paquets en un flux, no afectarà els altres.
Il·lustració de Daniel Steinberg
En segon lloc, el xifratge ja no s'implementa a un nivell separat, sinó que s'inclou al protocol. Això us permet establir una connexió i intercanviar claus públiques en una sola encaixada de mans, i també us permet utilitzar el mecanisme intel·ligent d'encaix de mans 0-RTT i evitar els retards en l'enllaç de mans. A més, ara és possible xifrar paquets de dades individuals. Això us permet no esperar que finalitzi la recepció de dades del flux, sinó desxifrar els paquets rebuts de manera independent. Aquest mode d'operació era generalment impossible en TCP, perquè TLS i TCP funcionaven independentment l'un de l'altre, i TLS no podia saber en quins trossos es tallarien les dades TCP. I per tant, no va poder preparar els seus segments perquè encaixin en segments TCP un a un i es poguessin desxifrar de manera independent. Totes aquestes millores permeten que QUIC redueixi la latència en comparació amb TCP.
En tercer lloc, el concepte de transmissió lleugera us permet desacoblar la connexió de l'adreça IP del client. Això és important, per exemple, quan un client canvia d'un punt d'accés Wi-Fi a un altre, canviant la seva IP. En aquest cas, quan s'utilitza TCP, es produeix un procés llarg durant el qual les connexions TCP existents s'esgoten i es creen connexions noves a partir d'una IP nova. En el cas de QUIC, el client simplement continua enviant paquets al servidor des d'una IP nova amb l'identificador de flux antic. Perquè L'identificador de flux ara és únic i no es reutilitza, el servidor entén que el client ha canviat d'IP, torna a enviar els paquets perduts i continua la comunicació a la nova adreça.
En quart lloc, QUIC s'implementa a nivell d'aplicació, no a nivell de sistema operatiu. Això, d'una banda, permet fer canvis ràpidament al protocol, perquè Per obtenir una actualització, només cal que actualitzeu la biblioteca, en lloc d'esperar una nova versió del sistema operatiu. D'altra banda, això comporta un fort augment del consum del processador.
I finalment, els titulars. La compressió de la capçalera és una de les coses que difereixen entre QUIC i gQUIC. No veig el sentit de dedicar-hi molt de temps, només diré que a la versió presentada per a l'estandardització, la compressió de capçalera es va fer el més semblant possible a la compressió de capçalera en HTTP/2. Podeu llegir més .
Quant més ràpid és?
És una pregunta difícil. El cas és que fins que no tinguem un estàndard, no hi ha res especial a mesurar. Potser les úniques estadístiques que tenim són les de Google, que utilitza gQUIC des del 2013 i el 2016. que al voltant del 90% del trànsit que va als seus servidors des del navegador Chrome ara utilitza QUIC. A la mateixa presentació, informen que les pàgines es carreguen al voltant d'un 5% més ràpid mitjançant gQUIC i hi ha un 30% menys de tartamudes en la transmissió de vídeo en comparació amb TCP.
El 2017, un grup d'investigadors liderat per Arash Molavi Kakhki va publicar per estudiar el rendiment de gQUIC en comparació amb TCP.
L'estudi va revelar diverses debilitats de gQUIC, com ara la inestabilitat a la barreja de paquets de xarxa, la cobdícia (injustícia) per a l'ample de banda del canal i la transferència més lenta d'objectes petits (fins a 10 kb). Això últim, però, es pot compensar utilitzant 0-RTT. En tots els altres casos estudiats, gQUIC va mostrar un augment de velocitat en comparació amb TCP. És difícil parlar de números concrets aquí. Millor llegir o .
Aquí cal dir que aquestes dades són específicament sobre gQUIC, i no són rellevants per a l'estàndard que s'està desenvolupant. Què passarà amb el QUIC: encara és un secret, però hi ha l'esperança que les debilitats identificades a gQUIC es tinguin en compte i es corregin.
Una mica de futur: què passa amb HTTP/3?
Però aquí tot és clar: l'API no canviarà de cap manera. Tot seguirà exactament igual que a HTTP/2. Bé, si l'API continua sent la mateixa, la transició a HTTP/3 s'haurà de resoldre utilitzant una versió nova de la biblioteca al backend que admeti el transport QUIC. És cert que haureu de mantenir el recurs a les versions antigues d'HTTP durant força temps, perquè Actualment Internet no està preparat per a una transició completa a UDP.
Qui ja dóna suport
aquí està implementacions QUIC existents. Tot i la manca d'un estàndard, la llista no està malament.
Actualment cap navegador admet QUIC en una versió de producció. Recentment es va informar que el suport per a HTTP/3 estava inclòs a Chrome, però fins ara només a Canary.
Dels backends, HTTP/3 només és compatible и , però encara experimental. NGINX a finals de primavera de 2019 , que van començar a treballar en suport HTTP/3, però encara no l'han acabat.
Quins són els problemes?
Tu i jo vivim al món real, on cap gran tecnologia pot arribar a les masses sense trobar resistència, i QUIC no és una excepció.
El més important és que heu d'explicar d'alguna manera al navegador que "https://" ja no és un fet que condueixi al port TCP 443. Pot ser que no hi hagi TCP en absolut. Per a això s'utilitza la capçalera Alt-Svc. Permet dir al navegador que aquest lloc web també està disponible en tal o tal protocol a tal o tal adreça. En teoria, això hauria de funcionar com un encant, però a la pràctica ens trobarem amb el fet que UDP es pot, per exemple, prohibir-se en un tallafoc per evitar atacs DDoS.
Però fins i tot si UDP no està prohibit, el client pot estar darrere d'un encaminador NAT que està configurat per mantenir una sessió TCP per adreça IP, i ja que fem servir UDP, que no té sessió de maquinari, NAT no mantindrà la connexió i una sessió QUIC .
Tots aquests problemes es deuen al fet que l'UDP no s'havia utilitzat anteriorment per transmetre contingut a Internet, i els fabricants de maquinari no podien preveure que això passaria mai. De la mateixa manera, els administradors encara no entenen com configurar correctament les seves xarxes perquè funcioni QUIC. Aquesta situació anirà canviant progressivament i, en tot cas, aquests canvis trigaran menys que la implantació d'un nou protocol de capa de transport.
A més, com ja s'ha descrit, QUIC augmenta considerablement l'ús de la CPU. Daniel Stenberg creixement del processador fins a tres vegades.
Quan arribarà HTTP/3?
Patró al maig de 2020, però tenint en compte que els documents previstos per al juliol de 2019 romanen inacabats de moment, podem dir que és molt probable que la data s'endarrerirà.
Bé, Google fa servir la seva implementació gQUIC des del 2013. Si mireu la sol·licitud HTTP que s'envia al motor de cerca de Google, veureu això:
Troballes
Ara QUIC sembla una tecnologia bastant crua, però molt prometedora. Tenint en compte que durant els últims 20 anys, totes les optimitzacions dels protocols de la capa de transport s'han referit principalment a TCP, QUIC, que en la majoria dels casos té el millor rendiment, ja es veu molt bé.
No obstant això, encara hi ha problemes sense resoldre que s'hauran de resoldre en els propers anys. El procés pot ser retardat pel fet que hi ha maquinari implicat, que a ningú li agrada actualitzar, però, tanmateix, tots els problemes semblen bastant solucionables i, tard o d'hora, tots tindrem HTTP/3.
El futur és a la volta de la cantonada!
Font: www.habr.com
