A QUIC gyorsabb, mint a TCP?

Valódi munkaterhelés esetén általában igen – általában 10–30%-kal gyorsabb mobil és veszteséges hálózatokon, kevesebb előny a tiszta vezetékes kapcsolatokon. A javulás a vonalfej-blokkolás nélküli multiplexelésből, a gyorsabb kézfogásból és a kapcsolat migrációjából származik. Egy tökéletes hálózaton veszteség nélkül a különbség csökken.

A QUIC titkosítja a forgalmat?

Igen, kötelező és végpontig. A kézfogás után minden QUIC-csomag TLS 1.3-as kulcsokkal van titkosítva. Nincs "sima QUIC" mód. A hálózati megfigyelők titkosított UDP-t látnak a QUIC kapcsolatazonosítójával; nem tudják elolvasni a benti patakokat.

Miért fut a QUIC UDP-n, nem a saját IP-protokollján?

Telepíthetőség. Egy új IP-protokollhoz az interneten található összes NAT-, tűzfal- és ISP-útválasztó frissítésére lenne szükség – ez több évtizedes munka. Az UDP már általánosan támogatott. A QUIC saját megbízhatóságát, torlódás-ellenőrzését és rendezését valósítja meg az UDP legjobb teljesítményű datagramjain.

Tud egy VPN alagút QUIC?

Igen – a QUIC csak UDP-csomagok a VPN-hez, amely beágyazza őket a saját alagútjába, mint bármely más forgalom esetében. A WireGuard tisztán kezeli; Az OpenVPN is jó. Az alagúton belüli QUIC forgalom kettős titkosítású (QUIC réteg + VPN réteg), kisebb többletterheléssel.

A HTTP/3-hoz QUIC szükséges?

Igen, értelemszerűen. A HTTP/3 a HTTP QUIC felett; nincs HTTP/3-over-TCP. Az elnevezés kissé zavaró, mert a HTTP/2-nek is vannak "over QUIC" prototípusai (gQUIC), de a HTTP/3 IETF-es verziója az, amit 2021-ben szállítottak ki.

A QUIC magyarázata: A modern szállítási protokoll, amely felváltotta a TCP+TLS-t

A QUIC az a szállítási protokoll, amelyet a Google épített az internet gyorsabbá tételére, majd átadták az IETF-nek, majd HTTP/3 néven az internet felén megjelentették. TCP helyett UDP-n fut, az első csomagtól kezdve integrálja a titkosítást, és egyetlen tervben kiküszöböli a több évtizedes TCP-korszak frusztrációit.

A cikk teljes szövege alább olvasható angol nyelven.

QUIC (eredeti nevén "Quick UDP Internet Connections") egy általános célú átviteli protokoll, amelyet a Google tervezett 2012 körül, és 2021-ben az IETF RFC 9000 néven szabványosította. UDP-n fut, adatfolyamokat hordoz, a HTTP saját alapjait, titkosítását és titkosítását kezeli3. 2025 végén a QUIC az internetes forgalom több mint 30%-át szállítja a nagy hálózatokon.

Miért nem volt elég a TCP?

TCP-t 1981-ben tervezték, és lényegében azóta sem változott. Három probléma vált egyre fájdalmasabbá:

Vonalvégi blokkolás. Egyetlen kiesett csomag minden adatot leállít maga mögött ugyanabban a TCP-kapcsolatban, még akkor is, ha az elveszett csomag egy adatfolyamhoz tartozik, és a többi adatfolyam rendben van. A HTTP/2 sok adatfolyamot multiplexelt egy TCP-kapcsolaton keresztül, ami a vonalak blokkolását rontotta, nem pedig jobbat.
Lassú kézfogás. A TCP-nek 1,5 körútra van szüksége az adatfolyamok megkezdése előtt; TLS hozzáadásával 2,5+ oda-vissza utak. Mobilkapcsolatokon ez a várakozási idő látható volt a felhasználók számára.
Kapcsolat-áttelepítés. A TCP-kapcsolatokat az 5 sor (forrás IP, forrásport, cél IP, cél port, protokoll) azonosítja. Amikor a telefon Wi-Fi-ről mobilra vált, az IP-cím megváltozik, és minden TCP-kapcsolat megszakad.

QUIC-ot úgy tervezték, hogy mindhárom javítást kijavítsa.

Streamok a vonalfej blokkolása nélkül.

QUIC több független adatfolyamot hordoz egyetlen kapcsolaton belül. Minden adatfolyamnak megvan a maga sorrendje és megbízhatósága. Ha egy csomag elveszik, csak az érintett adatfolyam leáll – a többi adatfolyam folytatódik. Ez a címsor funkció, és ez az a tulajdonság, amely veszteséges kapcsolatok esetén észrevehetően gyorsabbá teszi a HTTP/3-at, mint a HTTP/2-t.

Titkosítás a

-ben. Ahol a TCP sorszámokat és jelzőket tesz közzé a middleboxok számára, a QUIC titkosítja azokat. A kézfogás egy körben fejeződik be, vagy nulla, ha az ügyfél gyorsítótárazott munkamenet-állapottal rendelkezik (0-RTT, az újrajátszás elleni védelemre vonatkozó figyelmeztetésekkel).

Ennek van egy jelentős mellékhatása: a middleboxok – beleértve a DPI-rendszereket, az átlátszó proxykat és a vállalati tűzfalakat – már nem tudják úgy módosítani a QUIC-forgalmat, ahogyan a TCP-t. Látják, hogy az that QUIC forgalom folyik, de nem tudják dekódolni. A hálózatüzemeltetők számára ez zavaró volt; a végfelhasználók számára ez egyértelmű adatvédelem.

Kapcsolat-áttelepítés

A A QUIC-kapcsolatot a minden csomagba beágyazott 64 bites Connection ID azonosítja, nem pedig a hálózati 5 sorból. Amikor megváltozik az IP-cím – a telefon mozog a cellák között, a laptopok hálózatát váltja, a NAT újrakötése –, a QUIC kapcsolat zökkenőmentesen folytatódik. A könyvtár bizonyítja a szervernek, hogy az új IP/port továbbra is ugyanaz a kliens egy kis érvényesítési kézfogással, és a forgalom újraindul.

Az elővárosi vonatokon és repülőgép Wi-Fi-t használó mobilfelhasználók számára ez kiküszöböli a "videohívásom megszakadt, mert sarkon fordultam" hibákat.

XXXPLZ A control

QUIC megvalósítások saját torlódásszabályozást szállítanak – jellemzően Reno, Cubic vagy BBR. Mivel a QUIC egy felhasználói terület protokoll (nem az operációs rendszer kernelében, például a TCP-ben), a torlódáskezelési fejlesztések alkalmazásfrissítésként kerülnek bevezetésre, nem pedig operációs rendszer frissítésként. A Google ezt arra használta, hogy a BBRv2-t a Chrome+QUIC kapcsolatokon gyorsabban terjessze ki, mint ahogyan ugyanazt az algoritmust operációs rendszer-frissítésekkel telepítették volna.

Ahol a QUIC használatban van, és hol nem?

QUIC uralja a böngésző-szerver forgalmat A/3-képes HTTP, Google, Cloud, Fastly:. A böngészők visszaállnak a HTTP/2-re TCP-n keresztül, ha a QUIC meghibásodik (egyes hálózatok blokkolják az UDP/443-at, egyes tűzfalak eldobják az ismeretlen UDP-t, és a QUIC-csomagok elvesztése perverz módon magas lehet a TCP-re hangolt hálózatokon).

A HTTP-n túl a QUIC továbbítja a Google RPC-forgalmát, a QUIC egyes részei a gCRP-felhasználók számára DNS-over-QUIC. A QUIC a WebTransport alapja – egy alacsony szintű API, amellyel a böngésző kétirányú streamelést végezhet a QUIC-on keresztül. Hosszú távon várhatóan több alkalmazásprotokoll kerül portolásra a QUIC-ra.

Működési figyelmeztetések

AQUIC bonyolítja a hálózati műveleteket:

DPI alapú forgalomformálás nem működik ugyanúgy. A YouTube-ot DPI-n keresztül korlátozó internetszolgáltatók úgy találják, hogy a QUIC-forgalom átláthatatlan.Az
NAT időtúllépési viselkedése eltérő – az UDP NAT-ok jellemzően 30 másodperces időtúllépéssel rendelkeznek a TCP-percekhez képest, így a QUIC agresszívebben küldi az életet.
Néhány QUIC-kimenet; az ügyfeleknek ezt észlelniük kell, és vissza kell térniük. A tartalék késleltetés korlátozott, de látható.
A QUIC hibakeresése más eszközöket igényel, mint a tcpdump; qlog kimenet és Wireshark TLS kulcsokkal a modern beállítás.

Gyakran ismételt kérdések

A QUIC gyorsabb, mint a TCP?: Valódi munkaterhelés esetén általában igen – általában 10–30%-kal gyorsabb mobil és veszteséges hálózatokon, kevesebb előny a tiszta vezetékes kapcsolatokon. A javulás a vonalfej-blokkolás nélküli multiplexelésből, a gyorsabb kézfogásból és a kapcsolat migrációjából származik. Egy tökéletes hálózaton veszteség nélkül a különbség csökken.
A QUIC titkosítja a forgalmat?: Igen, kötelező és végpontig. A kézfogás után minden QUIC-csomag TLS 1.3-as kulcsokkal van titkosítva. Nincs "sima QUIC" mód. A hálózati megfigyelők titkosított UDP-t látnak a QUIC kapcsolatazonosítójával; nem tudják elolvasni a benti patakokat.
Miért fut a QUIC UDP-n, nem a saját IP-protokollján?: Telepíthetőség. Egy új IP-protokollhoz az interneten található összes NAT-, tűzfal- és ISP-útválasztó frissítésére lenne szükség – ez több évtizedes munka. Az UDP már általánosan támogatott. A QUIC saját megbízhatóságát, torlódás-ellenőrzését és rendezését valósítja meg az UDP legjobb teljesítményű datagramjain.
Tud egy VPN alagút QUIC?: Igen – a QUIC csak UDP-csomagok a VPN-hez, amely beágyazza őket a saját alagútjába, mint bármely más forgalom esetében. A WireGuard tisztán kezeli; Az OpenVPN is jó. Az alagúton belüli QUIC forgalom kettős titkosítású (QUIC réteg + VPN réteg), kisebb többletterheléssel.
A HTTP/3-hoz QUIC szükséges?: Igen, értelemszerűen. A HTTP/3 a HTTP QUIC felett; nincs HTTP/3-over-TCP. Az elnevezés kissé zavaró, mert a HTTP/2-nek is vannak "over QUIC" prototípusai (gQUIC), de a HTTP/3 IETF-es verziója az, amit 2021-ben szállítottak ki.