TLS:n suorituskyky: QUIC ja HTTP/3

HTTP/2 käyttää useita rinnakkaisia stream-virtoja yhden TCP-yhteyden yli ja ratkaisee HTTP/1.1:n yhteyskohtaisen head-of-line-eston. TCP itsessään kuitenkin aiheuttaa head-of-line-estoa siirtokerroksessa: jos yksi TCP-segmentti katoaa, kaikki sen jälkeen jonossa olevat tiedot odottavat uudelleenlähetystä, mikä estää samanaikaisesti kaikkien HTTP/2-stream-virtojen etenemisen. Jo 1 %:n pakettihävikki voi heikentää HTTP/2:n suorituskyvyn HTTP/1.1:tä heikommaksi useita yhteyksiä käytettäessä. QUIC (Quick UDP Internet Connections) ratkaisee tämän toteuttamalla multipleksoidut stream-virrat UDP:n päällä, jolloin stream-kohtainen hävikistä palautuminen ei estä muita stream-virtoja.

QUIC on UDP:n päälle rakennettu siirtoprotokolla, jonka Google kehitti vuosina 2012–2015 ja jonka IETF standardoi RFC 9000 -määrittelynä vuonna 2021. QUIC integroi TLS 1.3:n siirtokerrokseen: QUIC:n päällä ei ole erillistä TLS-kättelyä, vaan TLS on kudottu suoraan QUIC-kättelyyn. QUIC tarjoaa seuraavat ominaisuudet: multipleksoidut stream-virrat ilman head-of-line-estoa, yhteyden siirron verkosta toiseen (yhteyden säilyttäminen verkkoa vaihdettaessa, esimerkiksi WiFi-verkosta LTE-verkkoon), 0-RTT-yhteydenmuodostuksen toistuville yhteyksille sekä sisäänrakennetun hävikin havaitsemisen ja ruuhkanhallinnan. HTTP/3 (RFC 9114) tarkoittaa HTTP-semanttiikkaa QUIC-stream-virtojen päällä.

QUIC-kättely yhdistää yhteyden muodostamisen ja TLS-neuvottelun. Ensimmäisessä pakettierässä (QUIC-terminologiassa 0 RTT) asiakas lähettää Initial-paketteja, jotka sisältävät TLS ClientHello -viestin. Palvelin vastaa omalla Initial-paketillaan (ServerHello) sekä Handshake-paketeilla (salatut laajennukset, varmenne ja Finished). Asiakas lähettää Handshake Finished -viestin ja on sen jälkeen valmis lähettämään sovellustietoja – tämä on 1-RTT. 0-RTT-yhteyksissä asiakas lähettää 0-RTT-paketteja (sovellustietoja) ClientHello-viestin yhteydessä käyttäen edellisen istunnon uudelleenmuodostussalaisuudesta johdettua avainta. Näin välimuistissa oleville istunnoille ei tarvita yhtään ylimääräistä edestakaista viestinvaihtoa.

QUIC käyttää neljää erillistä salauskerrosta, jotka vastaavat TLS:n avainajastuksen vaiheita: Initial (QUIC:sta johdettu AEAD, joka käyttää tunnettua vakioavainta – tarjoaa eheyden mutta ei luottamuksellisuutta kehittyneitä hyökkääjiä vastaan), Handshake (johdettu TLS:n handshake_secret-arvosta – tarjoaa TLS-kättelyviestien luottamuksellisuuden), 0-RTT (johdettu edellisen istunnon early_secret-arvosta – salaa 0-RTT-sovellustiedot) ja 1-RTT (johdettu TLS:n master_secret-arvosta – salaa kaikki sovellustiedot). QUIC-otsakkeet salataan osittain: pakettinumero ja hyötykuorma salataan, mutta osa reititystiedoista (Connection ID) jää näkyviin kuormantasaajia varten.

QUIC-yhteydet tunnistetaan Connection ID:n (CID) avulla 4-tuplen (src IP, src port, dst IP, dst port) sijaan. Tämän ansiosta yhteydet säilyvät verkkoyhteyden muuttuessa: kun mobiiliasiakas vaihtaa WiFi-verkosta LTE-verkkoon, IP-osoite muuttuu mutta CID pysyy samana. Asiakas lähettää uudella reitillä PATH_CHALLENGE-kehyksen, johon palvelin vastaa PATH_RESPONSE-kehyksellä ja vahvistaa uuden osoitteen. Yhteys jatkuu saumattomasti ilman uudelleenneuvottelua. TCP ei tue tätä: TCP-yhteys on sidottu 4-tupleen, ja se on muodostettava verkkoyhteyden muuttuessa uudelleen, mikä edellyttää uutta TLS-kättelyä. QUIC:n yhteyden siirtäminen verkosta toiseen parantaa mobiilikäyttäjien koettua suorituskykyä huomattavasti.

HTTP/3 yhdistää HTTP-semanttiikan QUIC-stream-virtoihin. Kukin HTTP-pyyntö–vastauspari käyttää erillistä kaksisuuntaista QUIC-streamia. QUIC-streamit ovat toisistaan riippumattomia: streamin 3 hävikki ei estä streamia 7. HTTP/3 käyttää otsakkeiden pakkaamiseen QPACKia (HTTP/2:n HPACKin sijaan); QPACK suunniteltiin uudelleen niin, ettei se edellytä tietojen toimittamista järjestyksessä. Kaksi erillistä yksisuuntaista ohjausstreamia välittää asetukset sekä dekooderin ja enkooderin ohjeet. HTTP/3:n palvelinpush käyttää push-streameja (yksisuuntaisia). Kokonaisvaikutus on, että HTTP/3 päihittää HTTP/2:n selvimmin pakettihäviötilanteissa, kuten mobiiliverkoissa ja ruuhkautuneilla reiteillä, joissa TCP:n head-of-line-esto aiheuttaa eniten haittaa.

QUIC:n ja HTTP/3:n suorituskyvyn tosielämän mittaustulokset vaihtelevat verkko-olosuhteiden mukaan. Laadukkaissa verkoissa (pieni viive ja vähäinen pakettihävikki) HTTP/3 ja HTTP/2 toimivat samankaltaisesti – QUIC:n aiheuttama lisäkustannus (suuremmat otsakkeet ja UDP:n käsittelyn lisäkustannus) voi jopa tehdä HTTP/3:sta hieman hitaamman. Hävikkiä sisältävissä verkoissa (yli 1 %:n pakettihävikki, joka on yleistä mobiili- ja satelliittiverkoissa) HTTP/3 päihittää HTTP/2:n merkittävästi. Google raportoi YouTuben uudelleenpuskuroinnin vähentyneen 7–8 %, kun palvelu siirtyi käyttämään QUICia. Facebook (Meta) raportoi Instagram-syötteiden pyyntöviiveen lyhentyneen 7–15 % QUICia käytettäessä. Hyödyt näkyvät parhaiten häntäviiveessä (p95, p99), johon TCP:n uudelleenlähetyksistä johtuvat pysähdykset vaikuttavat eniten.

QUIC:n kuormantasaus on TCP:tä monimutkaisempaa, koska QUIC perustuu UDP:hen eivätkä tilattomat UDP-kuormantasaajat pysty säilyttämään yhteyssidosryhmitystä. IETF:n luonnos draft-ietf-quic-load-balancers määrittelee lähestymistavan, jossa palvelimet koodaavat reititystiedot Connection ID:hen. Näin kuormantasaajat voivat ohjata saman yhteyden paketit samalle palvelimelle seuraamatta jokaisen yhteyden tilaa. Connection ID sisältää salatun palvelintunnisteen, joka on salattu kuormantasaajan ja palvelinten yhteisellä avaimella. Cloudflare, Fastly ja Nginx toteuttavat tästä lähestymistavasta muunnelmia. NAT-läpikulku on toinen huomioitava asia: QUIC-yhteyksien on selvittävä NAT-uudelleensidonnasta, jonka yhteyden siirtomekanismi käsittelee.

Suuret CDN:t ovat ottaneet QUICin ja HTTP/3:n käyttöön laajassa mittakaavassa. Cloudflare on tarjonnut HTTP/3:a vuodesta 2019 lähtien ja raportoi, että noin 20 % liikenteestä käyttää QUICia silloin, kun sekä asiakas että palvelin tukevat sitä. Fastly, Akamai ja AWS CloudFront tukevat HTTP/3:a reunapalveluissaan. Googlen oma infrastruktuuri (Search, YouTube, Gmail) on käyttänyt QUICia sisäisesti vuodesta 2013 lähtien ja tarjoaa HTTP/3:a julkisesti. CDN-käyttöönotot hyötyvät QUIC:n 0-RTT-uudelleenmuodostuksesta: toistuvat kävijät muodostavat yhteydet nopeammin, ja yhteyden siirtäminen verkosta toiseen parantaa mobiilikäyttäjien suorituskykyä, kun he siirtyvät tukiasemasta toiseen sisällön toimituksen aikana.

QUIC:n UDP-pohjainen rakenne tuo mukanaan erityisiä tietoturvanäkökohtia. Vahvistushyökkäyksissä hyökkääjä voi väärentää lähde-IP-osoitteen ja lähettää pieniä Initial-paketteja, jolloin palvelin lähettää uhrille suuria Handshake-vastauksia. QUIC rajoittaa tätä siten, että palvelin saa lähettää enintään kolme kertaa vastaanotetun tietomäärän verran tietoja, kunnes osoite on vahvistettu RETRY-mekanismin avulla. Yhteyksien tulvimisen estämiseksi QUIC-palvelinten on rajoitettava samasta IP-osoitteesta tulevien uusien yhteysyritysten määrää. Versioneuvotteluhyökkäykset estetään sisällyttämällä versio kryptografisesti suojattuun kättelyyn. QUIC:n sisäänrakennetun salauksen vuoksi tarkastuslaitteet eivät voi analysoida QUIC-hyötykuormaa ilman, että ne ovat palvelimen varmennetta käyttävänä välittäjänä verkon reitillä – tämä parantaa yksityisyyttä verrattuna tarkastettavissa olevaan TCP-liikenteeseen.

HTTP/3:n käyttöönotto edellyttää seuraavia asioita: (1) QUICia tukeva palvelin (nginx 1.25+, Caddy, HAProxy 2.6+, LiteSpeed tai sovellustason toteutus quic-go-, aioquic- tai ngtcp2-kirjastolla). (2) UDP-portin 443 salliminen palomuureissa – monet yritysten palomuurit estävät UDP-portin 443, jolloin QUIC siirtyy käyttämään TCP:tä ja TLS:ää. (3) HTTP/3-tuen ilmoittaminen Alt-Svc-vastausotsakkeella: Alt-Svc: h3=":443"; ma=86400, mikä kehottaa HTTP/2-asiakkaita päivittämään yhteyden. (4) QUICia ymmärtävät kuormantasaajat tai L4-tason UDP-läpivienti. (5) QUIC-kohtaisten mittareiden seuranta: yhteyden siirtotapahtumat, 0-RTT-hyväksymisaste ja protokollan palautumisaste. Asteittainen käyttöönotto HTTPS:ään palaamisen kanssa on läpinäkyvää asiakkaille, jotka eivät tue QUICia.

QUIC integroi TLS 1.3:n UDP:n päällä toimivaan siirtokerrokseen ja poistaa siten TCP:n head-of-line-eston, koska hävikistä palaudutaan stream-kohtaisesti toisista stream-virroista riippumatta. Connection ID:t mahdollistavat yhteyden siirtämisen verkosta toiseen ilman uudelleenneuvottelua. HTTP/3 yhdistää HTTP:n QUIC-stream-virtoihin ja käyttää otsakkeiden pakkaamiseen QPACKia. 0-RTT-yhteyden uudelleenmuodostus käyttää uudelleen TLS-istunnon salaisuuksia. QUIC päihittää HTTP/2:n selvimmin pakettihävikissä, kuten mobiili- ja ruuhkautuneissa verkoissa. QUIC:n kuormantasaus edellyttää palvelimen reititystietojen koodaamista Connection ID:ihin. Käyttöönotto edellyttää UDP-porttia 443, QUICia tukevia palvelimia ja Alt-Svc-otsakkeita protokollan ilmoittamiseen.