Este QUIC mai rapid decât TCP?

Pentru sarcinile de lucru reale, de obicei da - de obicei, cu 10–30% mai rapid pe rețelele mobile și cu pierderi, beneficii mai puține pe conexiunile cu fir curate. Îmbunătățirea vine din multiplexarea fără blocarea capului de linie, strângeri de mână mai rapide și migrarea conexiunii. Într-o rețea perfectă, fără pierderi, decalajul se micșorează.

QUIC criptează traficul?

Da, obligatoriu și end-to-end. Fiecare pachet QUIC după strângere de mână este criptat cu chei TLS 1.3. Nu există un mod „chic simplu”. Observatorii rețelei văd UDP criptat cu ID-ul conexiunii QUIC; nu pot citi fluxurile din interior.

De ce rulează QUIC pe UDP, nu pe propriul protocol IP?

Posibilitate de implementare. Un nou protocol IP ar necesita actualizări pentru fiecare NAT, firewall și router ISP de pe Internet - zeci de ani de muncă. UDP este deja acceptat universal. QUIC implementează propria sa fiabilitate, controlul congestiei și comanda pe lângă datagramele UDP cu cele mai bune eforturi.

Poate un tunel VPN QUIC?

Da — QUIC este doar pachete UDP către VPN, care le încapsulează în propriul tunel, așa cum o face cu orice alt trafic. WireGuard se descurcă curat; OpenVPN, de asemenea, bine. Traficul QUIC din interiorul tunelului este dublu criptat (strat QUIC + strat VPN), cu o supraîncărcare minoră.

HTTP/3 necesită QUIC?

Da, prin definiție. HTTP/3 este HTTP peste QUIC; nu există HTTP/3-over-TCP. Denumirea este puțin confuză, deoarece HTTP/2 are și prototipuri „over QUIC” (gQUIC), dar versiunea IETF a HTTP/3 este cea care a fost livrată în 2021.

QUIC explicat: Protocolul modern de transport care a înlocuit TCP+TLS

QUIC este protocolul de transport creat de Google pentru a face web-ul mai rapid, apoi transmis IETF, apoi lansat pe jumătate de internet sub numele HTTP/3. Funcționează pe UDP în loc de TCP, integrează criptarea din primul pachet și elimină câteva decenii de frustrări din era TCP într-un singur design.

Întregul articol al articolului este oferit în limba engleză mai jos.

QUIC (inițial „Quick UDP Internet Connections”) este un protocol de transport de uz general conceput de Google începând cu anul 2012 și standardizat de IETF ca RFC 9000 în 2021. Funcționează peste UDP, transportă fluxuri de date, se ocupă de propria sa criptare și de control al congestiei HTTP/3 și servește ca control al HTTP/3. La sfârșitul anului 2025, QUIC transportă mai mult de 30% din traficul de internet în volum pe rețelele majore.

De ce nu era suficient TCP

TCP a fost proiectat în 1981 și nu s-a schimbat în esență de atunci. Trei probleme au devenit din ce în ce mai dureroase:

Blocarea capului de linie. Un singur pachet scăpat blochează toate datele în spatele lui în aceeași conexiune TCP, chiar dacă pachetul pierdut aparține unui flux și alte fluxuri sunt în regulă. HTTP/2 a multiplexat multe fluxuri printr-o conexiune TCP, ceea ce a făcut ca blocarea capului de linie să fie mai proastă, nu mai bună. adăugarea TLS în partea de sus face 2,5+ călătorii dus-întors. Pe conexiunile mobile, această latență era vizibilă pentru utilizatori.
Migrarea conexiunii. Conexiunile TCP sunt identificate prin 5-tuplu (IP sursă, port sursă, IP destinație, port de destinație, protocol). Când telefonul dvs. trece de la Wi-Fi la cel mobil, IP-ul se schimbă și fiecare conexiune TCP se întrerupe.

QUIC a fost proiectat pentru a le remedia pe toate trei.

Streamuri fără blocarea capului de linie

QUIC transportă mai multe fluxuri independente într-o singură conexiune. Fiecare flux are propria sa ordine și fiabilitate. Dacă se pierde un pachet, numai fluxul afectat se blochează - alte fluxuri continuă. Aceasta este caracteristica titlului și este proprietatea care face ca HTTP/3 să fie considerabil mai rapid decât HTTP/2 în conexiunile cu pierderi.

Ecriptare gătită în

Efiecare pachet QUIC după prima strângere de mână este criptat cu chei TLS 1.3, inclusiv anteturi la nivel de transport. Acolo unde TCP expune numerele de secvență și steaguri la casetele de mijloc, QUIC le criptează. Strângerea de mână se finalizează într-o singură călătorie dus-întors sau zero dacă clientul are starea de sesiune în cache (0-RTT, cu avertismente pentru protecția la reluare).

Taceasta are un efect secundar semnificativ: casetele de mijloc - inclusiv sistemele DPI, proxy-urile transparente și firewall-urile corporative - nu mai pot modifica traficul QUIC așa cum au făcut-o TCP. Ei pot vedea că traficul QUIC circulă, dar nu îl pot decoda. Pentru operatorii de rețea, acest lucru a fost perturbator; pentru utilizatorii finali este un câștig clar de confidențialitate.

Migrarea conexiunii

A Conexiunea QUIC este identificată printr-un ID de conexiune pe 64 de biți încorporat în fiecare pachet, nu prin rețeaua 5-tuple. Când IP-ul dvs. se schimbă - telefonul se mișcă între celule, rețele de comutare de laptop, relegarea NAT - conexiunea QUIC continuă fără probleme. Biblioteca demonstrează serverului că noul IP/port este în continuare același client prin finalizarea unei mici strângeri de mână de validare, iar traficul se reia.

Pentru utilizatorii de telefonie mobilă din trenurile de navetă și Wi-Fi aeronavelor, acest lucru elimină o întreagă clasă de eșecuri „apelul meu video a căzut pentru că am făcut un colț”. propriul control al congestiei - de obicei Reno, Cubic sau BBR. Deoarece QUIC este un protocol pentru spațiul utilizatorului (nu în nucleul sistemului de operare precum TCP), îmbunătățirile de control al congestiei sunt implementate ca actualizări ale aplicației, mai degrabă decât actualizări ale sistemului de operare. Google a folosit acest lucru pentru a lansa BBRv2 în conexiunile Chrome+QUIC mai rapid decât ar fi putut fi implementat același algoritm prin actualizările sistemului de operare. Browserele revin la HTTP/2 prin TCP dacă QUIC eșuează (unele rețele blochează UDP/443, unele firewall-uri elimină UDP necunoscut, iar pierderea de pachete QUIC poate fi pervers mare pe rețelele reglate pentru TCP). DNS-over-QUIC. QUIC este baza pentru WebTransport — un API de nivel scăzut pentru browser pentru a face streaming bidirecțional prin QUIC. Pe termen lung, așteptați ca mai multe protocoale de aplicație să fie portate la QUIC.

Avertismente operaționale

QUIC complică operațiunile de rețea:

DPI nu funcționează în același mod. ISP-urile care limitează rata YouTube prin DPI constată că traficul QUIC este opac. Comportamentul de timeout

NAT diferă — NAT-urile UDP au de obicei timeout-uri de 30 de secunde față de minutele TCP, așa că QUIC trimite keepalives mai agresiv.

Unele firewall-uri scad QUIC; clienții trebuie să detecteze acest lucru și să se retragă. Întârzierea de rezervă este limitată, dar vizibilă.

Debugging QUIC necesită instrumente diferite decât tcpdump; Ieșirea qlog și Wireshark cu chei TLS sunt configurația modernă.

Întrebări frecvente

Este QUIC mai rapid decât TCP?: Pentru sarcinile de lucru reale, de obicei da - de obicei, cu 10–30% mai rapid pe rețelele mobile și cu pierderi, beneficii mai puține pe conexiunile cu fir curate. Îmbunătățirea vine din multiplexarea fără blocarea capului de linie, strângeri de mână mai rapide și migrarea conexiunii. Într-o rețea perfectă, fără pierderi, decalajul se micșorează.
QUIC criptează traficul?: Da, obligatoriu și end-to-end. Fiecare pachet QUIC după strângere de mână este criptat cu chei TLS 1.3. Nu există un mod „chic simplu”. Observatorii rețelei văd UDP criptat cu ID-ul conexiunii QUIC; nu pot citi fluxurile din interior.
De ce rulează QUIC pe UDP, nu pe propriul protocol IP?: Posibilitate de implementare. Un nou protocol IP ar necesita actualizări pentru fiecare NAT, firewall și router ISP de pe Internet - zeci de ani de muncă. UDP este deja acceptat universal. QUIC implementează propria sa fiabilitate, controlul congestiei și comanda pe lângă datagramele UDP cu cele mai bune eforturi.
Poate un tunel VPN QUIC?: Da — QUIC este doar pachete UDP către VPN, care le încapsulează în propriul tunel, așa cum o face cu orice alt trafic. WireGuard se descurcă curat; OpenVPN, de asemenea, bine. Traficul QUIC din interiorul tunelului este dublu criptat (strat QUIC + strat VPN), cu o supraîncărcare minoră.
HTTP/3 necesită QUIC?: Da, prin definiție. HTTP/3 este HTTP peste QUIC; nu există HTTP/3-over-TCP. Denumirea este puțin confuză, deoarece HTTP/2 are și prototipuri „over QUIC” (gQUIC), dar versiunea IETF a HTTP/3 este cea care a fost livrată în 2021.