A construccions experimentals suport per al protocol HTTP/3, que implementa un complement per permetre que HTTP funcioni amb el protocol QUIC. El propi protocol QUIC es va afegir al navegador fa cinc anys i des de llavors s'ha utilitzat per optimitzar el treball amb els serveis de Google. Al mateix temps, la versió QUIC de Google utilitzada a Chrome difereix en alguns detalls de la versió de IETF, però ara les implementacions estan sincronitzades.
HTTP/3 estandarditza l'ús de QUIC com a transport per a HTTP/2. Per habilitar l'opció HTTP/3 i QUIC des de Les especificacions de l'IETF requereixen que Chrome s'iniciï amb les opcions "-enable-quic -quic-version=h3-23" i després en obrir el lloc de prova En el mode d'inspecció de xarxa a les eines de desenvolupament, l'activitat HTTP/3 es mostrarà com a "http/2+quic/99".
Recordem que el protocol (Quick UDP Internet Connections) ha estat desenvolupat per Google des del 2013 com una alternativa a la combinació TCP+TLS per a la web, solucionant problemes amb llargs temps de configuració i negociació de connexions en TCP i eliminant els retards quan es perden paquets durant la transferència de dades. QUIC és una extensió del protocol UDP que admet la multiplexació de múltiples connexions i proporciona mètodes de xifratge equivalents a TLS/SSL. El protocol en qüestió ja està integrat a la infraestructura del servidor de Google i forma part de Chrome. per incloure'ls al Firefox i s'utilitza activament per atendre les sol·licituds dels clients als servidors de Google.
El principal QUIC:
- Alta seguretat, similar a TLS (de fet, QUIC ofereix la possibilitat d'utilitzar TLS sobre UDP);
- Control de la integritat del flux per evitar 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 un paquet de configuració de connexió) i garantir uns retards mínims entre l'enviament d'una sol·licitud i la recepció d'una resposta (RTT, temps d'anada i tornada) ;
- No utilitzeu el mateix número de seqüència en retransmetre un paquet, la qual cosa us permet evitar l'ambigüitat a l'hora de determinar els paquets rebuts i eliminar els temps d'espera;
- La pèrdua de paquets només afecta el lliurament del flux associat i no atura el lliurament de dades en fluxos transmesos en paral·lel a la connexió actual;
- Eines de correcció d'errors que minimitzen els retards a causa de la retransmissió de paquets perduts. Ús de codis especials de correcció d'errors a nivell de paquet per reduir les situacions que requereixen la retransmissió de dades de paquet perduts.
- Els límits dels blocs criptogràfics estan alineats amb els límits dels paquets QUIC, la qual cosa redueix l'impacte de les pèrdues de paquets en la descodificació del contingut dels paquets posteriors;
- No hi ha problemes per bloquejar la cua TCP;
- Suport d'identificació de connexió per reduir el temps de reconnexió dels clients mòbils;
- Possibilitat de connectar mecanismes avançats de control de sobrecàrrega de connexió;
- Ús de tècniques de predicció d'ample de banda en cada direcció per garantir la velocitat òptima d'enviament de paquets, evitant el rodatge a un estat de congestió, en què hi ha una pèrdua de paquets;
- Perceptible rendiment i rendiment en comparació amb TCP. Per a serveis de vídeo com YouTube, s'ha demostrat que QUIC redueix les operacions de rebuffer de vídeo en un 30%.
Font: opennet.ru