QUIC (Quick UDP Internet Connections) este un protocol bazat pe UDP, care susține toate funcționalitățile TCP, TLS și HTTP/2, rezolvând majoritatea problemelor acestora. Este adesea numit un protocol nou sau „experimentativ”, dar a depășit de multă vreme stadiul experimentului: dezvoltarea a avut loc timp de mai bine de 7 ani. În acest interval, protocolul nu a ajuns să devină un standard, dar a câștigat în continuare o răspândire largă. De exemplu, QUIC este utilizat pentru accelerarea traficului și reducerea latențelor în rețelele mobile de gigantii precum Google și Facebook, iar IETF a declarat fork-ul său ca bază pentru standardul HTTP/3 (având în vedere că HTTP/2 folosește din site-uri).
Conceptul
QUIC a fost dezvoltat ca o alternativă la TCP-ul învechit, care a fost inițial conceput pentru rețele cablate cu un procent scăzut de pierderi. TCP livrează pachetele în ordinea în care sunt primite, astfel că, în caz de pierdere a unui pachet, întreaga coadă se blochează (), ceea ce afectează negativ calitatea și stabilitatea conexiunii. Pentru a evita pierderile masive, rețelele mobile recurg la utilizarea bufferelor mari, ceea ce, la rândul său, duce la redundanță și reacția fals negativă a protocolului (). În plus, TCP consumă foarte mult timp pentru a stabili o conexiune: cererile SYN/ACK și TLS sunt trimise separat, necesitând trei runde de returnare în loc de una, așa cum face QUIC.
Deoarece QUIC combină înlocuirea TCP cu implementarea TLS 1.3, toate conexiunile sunt întotdeauna criptate, iar decriptarea unui astfel de trafic nu este mai ușoară decât dacă ar circula prin HTTPS. În plus, QUIC este implementat la nivel de aplicație, deoarece o înlocuire completă a stivului TCP ar dura eternitate.
În ciuda suportului pentru multiplexare în HTTP/2, problema head-of-line blocking a rămas din cauza necesității de a livra pachetele în ordine. QUIC este implementat deasupra UDP, astfel încât blocajele nu există în principiu, iar pentru a evita pierderile irecuperabile ale pachetelor, acestea sunt numerotate și pot conține părți ale „vecinilor”, asigurând redundanță. În plus, QUIC împarte coada monolitică în mai multe fluxuri pentru diferite tipuri de cereri într-o singură conexiune. Astfel, în caz de pierdere a unui pachet, problemele pot apărea doar într-o singură coadă (de exemplu, în transmiterea unui anumit fișier):
Utilizare
Inițial, QUIC a fost dezvoltat în interiorul Google și a fost în mare parte adaptat pentru utilizarea în cadrul companiei. În 2013, a fost predat IETF pentru standardizare (care continuă și în prezent), iar acum oricine poate participa la dezvoltarea protocolului, propunând ceea ce îi lipsește. Grupul de lucru IETF organizează anual întâlniri în cadrul cărora se aprobă un nou standard și se discută inovațiile. Această implementare a QUIC este considerată principală și pe baza ei se certifică standardul HTTP/3.
Deocamdată, nu se discută despre includerea HTTP/3 ca protocol principal, deoarece acesta nu este finalizat și este aproape deloc suportat:
Însă QUIC poate fi implementat ca transport între aplicație și server, ceea ce a fost realizat cu succes de Uber:
Comentariul Uber despre implementarea QUIC
Pentru a integra cu succes QUIC și a îmbunătăți performanța aplicației în condiții de conexiune slabă, am înlocuit vechea stivă (HTTP/2 deasupra TLS/TCP) cu protocolul QUIC. Am utilizat biblioteca de rețea din , care conține versiunea originală, dezvoltată de Google, a protocolului – gQUIC. Această implementare este, de asemenea, îmbunătățită constant pentru a urma ultima specificație IETF.
Am integrat mai întâi Cronet în aplicațiile noastre Android pentru a adăuga suport pentru QUIC. Integrarea a fost realizată astfel încât să reducem la minimum costurile migrației. În loc să înlocuim complet vechiul stack de rețea care folosea biblioteca , am integrat Cronet sub cadrul API-ului OkHttp. Realizând integrarea în acest mod, am evitat modificările în apelurile noastre de rețea (care utilizează ) la nivel de API.
Similar abordării pentru dispozitivele Android, am implementat Cronet în aplicațiile Uber pe iOS, interceptând traficul HTTP din , utilizând . Această abstracție oferită de fundația iOS gestionează datele URL specifice protocolului și garantează că putem integra Cronet în aplicațiile noastre iOS fără costuri semnificative de migrare.
preluat din articolului Uber
Pe backend, aceștia au captat conexiunile QUIC prin intermediul Google Cloud lb, care din mijlocul anului 2018.
Nu este surprinzător că Google Cloud funcționează foarte bine cu protocolul dezvoltat de Google, dar ce alternative există?
Nginx
Nu cu mult timp în urmă, CloudFlare nginx (care în mod implicit nu suportă HTTP/3) cu instrumentul său Quiche. Implementarea este disponibilă sub formă de un singur fișier .patch, la care este atașat un tutorial de instalare:
curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patchAici poți să-ți conectezi modulele, dacă este necesar
./configure
--prefix=$PWD
--with-http_ssl_module
--with-http_v2_module
--with-http_v3_module
--with-openssl=../quiche/deps/boringssl
--with-quiche=../quiche
makeRămâne doar să activezi suportul HTTP/3
events {
worker_connections 1024;
}
http {
server {
# Activează QUIC și HTTP/3.
listen 443 quic reuseport;
# Activează HTTP/2 (opțional).
listen 443 ssl http2;
ssl_certificate cert.crt;
ssl_certificate_key cert.key;
# Activează toate versiunile TLS (TLSv1.3 este necesar pentru QUIC).
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
# Bufferizarea cererilor nu este momentan suportată pentru HTTP/3.
proxy_request_buffering off;
# Adaugă header Alt-Svc pentru a negocia HTTP/3.
add_header alt-svc 'h3-27=":443"; ma=86400';
}
} În browserele obișnuite, conectarea prin HTTP/3 nu este posibilă deocamdată, dar se poatelua și rula cu flagul --enable-quic, să se adreseze serverului său sau, de exemplu, site-ului quic.rocks și să verifice tipul de conexiune în Developer Tools:
În loc de HTTP/3 se va scrie http2+quic/99, dar acesta este în esență același lucru.
Alte tehnologii
- QUIC este, de asemenea, susținut (care s-au conectat cu mare fast la Facebook prin HTTP/3) și progresiv . Apache încă nu poate, dar munca este în curs .
- Pe 21 ianuarie a fost actualizat
- Cu doar câteva zile în urmă, Microsoft a deschis , în care nu toate funcțiile din standardul IETF sunt deocamdată disponibile, dar este deja un mare pas înainte.
Concluzie
Interesul pentru QUIC este instabil, dar în creștere; se lucrează la standardizarea sa. Noi implementări ale protocolului apar aproape în fiecare lună, iar din ce în ce mai mulți dezvoltatori se conving că viitorul aparține QUIC. Se acceptă chiar includerea protocolului în viitoarele versiuni ale stivei TCP, iar asta înseamnă că, mai devreme sau mai târziu, întregul internet va trece la conexiuni mai stabile și mai rapide.
Deja acum, puteți configura interacțiunea QUIC pentru infrastructura dumneavoastră sau chiar să o oferiți browserelor — toate planifică să adauge suport pentru protocol, iar statistica tristă de pe caniuse va deveni mai optimistă.
Sursa: habr.com
