Recentment els desenvolupadors que estan darrere de el navegador web Google Chrome, van donar a conèixer la notícia de l'addició de el suport per al protocol HTTP / 3 a les compilacions experimentals de Chrome Canary, que implementa un complement per habilitar HTTP sobre QUIC.
El protocol QUIC en si mateix es va agregar a el navegador fa cinc anys i des de llavors s'ha utilitzat per optimitzar el treball amb els serveis de Google. A el mateix temps, la versió QUIC de Google utilitzada en Chrome diferia en alguns detalls de la versió de les especificacions IETF, però ara les implementacions estan sincronitzades.
Google Chrome Canary just became the first (available) browser to Integrate (very) experimental #QUIC and HTTP / 3 support!
Add flags "-enable-quic -quic-version = h3-23" and you should see "http / 2 + quic / 99" show up in the DevTools, which is actually http3 in disguise! pic.twitter.com/5Fhui46h3x
- Robin Marx (@programmingart) Setembre 19, 2019
És important ressaltar que Google ha desenvolupat QUIC (Quick UDP Internet Connections) des de 2013 com una alternativa a el paquet TCP + TLS per a la Web, Que resol problemes amb llargs temps de configuració i negociació per a les connexions TCP i elimina els retards en la pèrdua de paquets durant la transferència de dades.
QUIC és un complement de l'protocol UDP que admet la multiplexació de múltiples connexions i proporciona mètodes de xifrat equivalents a TLS / SSL.
El protocol en qüestió ja està integrat en la infraestructura de servidor de Google, és part de Chrome, està planejat per a la seva inclusió en Firefox i s'utilitza activament per atendre les sol·licituds dels clients en els servidors de Google.
Dins de les principals característiques de QUIC que es destaquen són:
- Alta seguretat, similar a TLS (de fet, QUIC proporciona la capacitat de fer servir TLS sobre UDP)
- Control d'integritat de flux que evita la pèrdua de paquets
- La capacitat d'establir una connexió a l'instant (0-RTT, en aproximadament el 75% dels casos, les dades es poden transmetre immediatament després d'enviar el paquet de configuració de la connexió) i garantir retards mínims entre l'enviament d'una sol·licitud i la recepció d'una resposta (RTT, Temps d'anada i tornada)
- No fer servir el mateix nombre de seqüència a l'retransmetre un paquet, el que evita l'ambigüitat en la determinació dels paquets rebuts i elimina els temps d'espera
- La pèrdua d'un paquet afecta el lliurament de només el flux associat amb ell i no atura el lliurament de dades en fluxos transmesos en paral·lel a través de la connexió actual
- Eines de correcció d'errors que minimitzen els retards a causa de la retransmissió de paquets perduts.
- L'ús de codis especials de correcció d'errades a nivell de paquet per reduir situacions que requereixen la retransmissió de dades de paquets perduts.
- Els límits criptogràfics dels blocs estan alineats amb els límits dels paquets QUIC, el que redueix l'efecte de la pèrdua de paquets en la descodificació de el contingut dels següents paquets
- No hi ha problemes amb el bloqueig de la cua TCP
- Suport per l'identificador de connexió, que redueix el temps per establir una reconnexió per a clients mòbils
- Capacitat per connectar mecanismes avançats per controlar la sobrecàrrega de connexió
També es destaca que fa ús la tècnica de predir l'ample de banda en cada direcció per assegurar una intensitat òptima d'enviament de paquets, evitant que arribi a un estat de congestió en el qual s'observa la pèrdua de paquets;
Així com també un rendiment notable i guanys de rendiment sobre TCP. Per a serveis de vídeo com YouTube, QUIC va mostrar una reducció de l'30% en les operacions de re-emmagatzematge en memòria intermèdia a l'mirar vídeos.
El protocol HTTP / 3 estandarditza l'ús de QUIC com transport per a HTTP / 2. Per habilitar HTTP / 3 i la versió QUIC dels 23 esborranys de les especificacions IETF, s'ha d'executar Chrome amb les opcions «-enable-quic -quic-version = h3-23» i després, quan s'obri el lloc de prova quic .rocks: 4433 en mode d'inspecció de xarxa en les eines de desenvolupador, l'activitat hTTP / 3 es mostrarà com «http / 2 + quic / 99».
En comparació amb un paquet perdut per connexions HTTP en paral·lel només es detindrà 1 de les tantes connexions, amb la qual cosa QUIC pot suportar el lliurament fora d'ordre de manera que un paquet perdut tindrà menys impacte.
Si vols conèixer més a l'respecte sobre això, pots consultar el següent enllaç.