HTTP UDP-n keresztül – a QUIC protokoll jó kihasználása
A QUIC (Quick UDP Internet Connections) egy UDP-n felüli protokoll, amely támogatja a TCP, TLS és HTTP/2 összes funkcióját, és megoldja a legtöbb problémát. Gyakran nevezik új vagy „kísérleti” protokollnak, de már rég túlélte a kísérleti szakaszt: a fejlesztés több mint 7 éve folyik. Ez idő alatt a protokoll nem vált szabványossá, de mégis széles körben elterjedt. Például a QUIC-ot olyan óriáscégek használják, mint a Google és a Facebook, hogy felgyorsítsák a forgalmat és csökkentsék a késéseket a mobilhálózatokban, és az IETF a protokoll forkját nyilvánította a HTTP/3 szabvány alapjául (annak ellenére, hogy a HTTP/2 csak 44.8% oldalak).
koncepció
A QUIC-ot a régi TCP helyettesítésére fejlesztették ki, amelyet eredetileg alacsony veszteségű vezetékes hálózatokhoz terveztek. A TCP sorrendben kézbesíti a csomagokat, így ha egy csomag elveszik, a teljes sor leáll (head-of-line blokkolás), ami negatívan befolyásolja a kapcsolat minőségét és stabilitását. A tömeges veszteségek elkerülése érdekében a mobilhálózatok nagy pufferek használatához folyamodnak, ami viszont redundanciához és a protokoll hamis negatív válaszához vezet (bufferbloat). Ezenkívül a TCP sok időt tölt a kapcsolat létrehozásával: a SYN/ACK és a TLS kérések külön-külön kerülnek feldolgozásra, és három körútra van szükség egy helyett, ahogy a QUIC teszi.
Mivel a QUIC egyesíti a TCP helyettesítését és a TLS 1.3 megvalósítását, minden kapcsolat mindig titkosítva van, és az ilyen forgalom visszafejtése semmivel sem egyszerűbb, mintha HTTPS-en keresztül menne. Ezenkívül a QUIC alkalmazásszinten valósul meg, mivel a TCP-verem teljes cseréje szükséges örökkévalóság.
Annak ellenére, hogy támogatja a HTTP/2-ben történő multiplexelést, a head-of-line blokkolás problémája ott maradt, mivel a csomagokat rendben kellett kézbesíteni. A QUIC az UDP tetején van megvalósítva, így elvileg nincs blokkolása, és hogy a csomagok ne vesszenek el örökre, számozva vannak, és tartalmazhatják a „szomszédok” részeit, ami redundanciát biztosít. Ezenkívül a QUIC több szálra osztja fel a monolitikus sort a különböző típusú kérésekhez egyetlen kapcsolaton belül. Így, ha egy csomag elveszik, akkor csak egy sornál merülhetnek fel problémák (például egy adott fájl átvitelénél):
Használat
A QUIC-ot kezdetben a Google fejlesztette ki, és nagyrészt a vállalaton belüli használatra szabták. 2013-ban átkerült az IETF-hez szabványosításra (amely jelenleg is folyamatban van), és most már mindenki részt vehet a protokoll fejlesztésében azzal, hogy javaslatot tesz a hiányzókra. Az IETF munkacsoport éves üléseket szervez, amelyek során jóváhagyják az új szabványt és megvitatják az újításokat. A QUIC ezt a megvalósítását tekintik a főnek, és ennek alapján tanúsítják a HTTP/3 szabványt.
Egyelőre nem esik szó a HTTP/3 fő protokollként való felvételéről, mert még nincs kész, és szinte nem is támogatott:
De a QUIC megvalósítható szállításként az alkalmazás és a szerver között, ami az Ubernél sikeresen megtörtént:
Az Uber megjegyzése a QUIC bevezetéséhez
A QUIC sikeres beágyazása és az alkalmazások teljesítményének javítása érdekében gyenge csatlakozási környezetben a régi verem (HTTP/2 over TLS/TCP) helyett a QUIC protokollt. A hálózati könyvtárat használtuk Cronet A Chromium projektek, amely tartalmazza a protokoll eredeti, Google verzióját - gQUIC. Ezt a megvalósítást is folyamatosan fejlesztik, hogy kövesse a legújabb IETF specifikációt.
Először integráltuk a Cronetet Android-alkalmazásainkba, hogy a QUIC-t is támogassuk. Az integrációt úgy hajtották végre, hogy a migrációs költségeket a lehető legnagyobb mértékben csökkentsék. Ahelyett, hogy teljesen lecserélné a könyvtárat használó régi hálózati veremet OkHttp, integráltuk a Cronetet az OkHttp API keretrendszerébe. Az integráció ilyen módon történő végrehajtásával elkerültük a hálózati hívásaink módosítását (amelyeket a Utólagosan) API-szinten.
Hasonlóan az Android-eszközökhöz, a Cronetet az Uber-alkalmazásokban implementáltuk iOS rendszeren, elfogva a hálózat HTTP-forgalmát. APIsegítségével NSURLProtocol. Ez az iOS Foundation által biztosított absztrakció a protokoll-specifikus URL-adatokat kezeli, és biztosítja, hogy jelentős migrációs költségek nélkül tudjuk integrálni a Cronetet iOS-alkalmazásainkba.
A háttérben QUIC kapcsolatokat fogtak a Google Cloud lb-n keresztül, ami támogatja a protokollt 2018 közepe óta.
Nem meglepő, hogy a Google Cloud remekül működik a Google által fejlesztett protokollal, de mik az alternatívák?
nginx
Nem is olyan régen CloudFlare Megpróbáltam átkelni nginx (amely alapértelmezés szerint nem támogatja a HTTP/3-at) a Quiche eszközzel. A megvalósítás egyetlen .patch fájlként érhető el, amelyhez egy telepítési útmutató is tartozik:
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.patch
Ide csatlakoztathatja a moduljait, ha szükséges
./configure
--prefix=$PWD
--with-http_ssl_module
--with-http_v2_module
--with-http_v3_module
--with-openssl=../quiche/deps/boringssl
--with-quiche=../quiche
make
Már csak a HTTP/3 támogatás engedélyezése van hátra
events {
worker_connections 1024;
}
http {
server {
# Enable QUIC and HTTP/3.
listen 443 quic reuseport;
# Enable HTTP/2 (optional).
listen 443 ssl http2;
ssl_certificate cert.crt;
ssl_certificate_key cert.key;
# Enable all TLS versions (TLSv1.3 is required for QUIC).
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
# Request buffering in not currently supported for HTTP/3.
proxy_request_buffering off;
# Add Alt-Svc header to negotiate HTTP/3.
add_header alt-svc 'h3-27=":443"; ma=86400';
}
}
Normál böngészőkben még nem lehet HTTP/3-on keresztül csatlakozni, de használható Chrome Canary és fuss a zászlóval --enable-quic, lépjen a szerverére vagy például a quic.rocks webhelyre, és nézze meg a kapcsolat típusát a Fejlesztői eszközökben:
HTTP/3 helyett ez van írva http2+quic/99, de lényegében ugyanaz.
Egyéb technológiák
A QUIC is támogatja litespeed (ami nagy felhajtással HTTP/3-on keresztül csatlakozott a Facebookhoz) és progresszív Labdaszedő. Az Apache még nem tudja megtenni, de a munka folyamatban van teljes lendülettel.
Épp a minap nyitott a Microsoft msquic megvalósítási kód, amelyben még nem érhető el minden funkció az IETF szabványból, de ez már nagy áttörés.
Következtetés
A QUIC iránti érdeklődés instabil, de növekszik, és folyamatban van a szabványosítása. Szinte havonta jelennek meg a protokoll új implementációi, és évről évre egyre több fejlesztő van meggyőződve arról, hogy a QUIC a jövő. Még a TCP verem jövőbeli verzióiba is beépíthető a protokoll, ami azt jelenti, hogy előbb-utóbb a teljes internet stabilabb és gyorsabb kapcsolatokra költözik.
Már most beállíthatja a QUIC interakciót az infrastruktúrájához, vagy akár böngészőknek is megadhatja – mindannyian a protokoll támogatását tervezik, és a caniuse szomorú statisztikái vidámabbak lesznek.