Kodėl HTTP protokolai vis dar kelia diskusijas
Kiekvieną kartą, kai kalbame apie interneto greitį ir efektyvumą, neišvengiamai grįžtame prie HTTP protokolų. Nors HTTP/1.1 tarnavo mums daugiau nei du dešimtmečius, technologijų pasaulis niekada nestovi vietoje. Šiandien HTTP/2 jau tapo standartu daugelyje projektų, o HTTP/3 pamažu įsitvirtina kaip naujausia evoliucijos pakopa. Bet ar tikrai suprantame, kodėl šie protokolai yra geresni už savo pirmtakus?
Problema ta, kad dažnai girdime abstrakčius teiginius apie „greitesnį veikimą” ar „geresnę optimizaciją”, tačiau praktikoje ne visada aišku, ką tai reiškia mūsų kasdieniam darbui. Pabandykime išsiaiškinti, kokius konkrečius pranašumus šie protokolai teikia ir kada juos verta naudoti.
HTTP/2: daugiau nei tik greitis
HTTP/2 atsirado 2015 metais ir iš karto pakeitė žaidimo taisykles. Pagrindinis jo privalumas – multipleksavimas. Skamba sudėtingai, bet iš tikrųjų tai reiškia, kad vienu TCP ryšiu galima siųsti kelis užklausų ir atsakymų srautus vienu metu. HTTP/1.1 turėjo vadinamąją „head-of-line blocking” problemą – jei viena užklausa užtrukdavo, visos kitos turėjo laukti eilėje.
Praktiškai tai reiškia, kad jūsų svetainė su 50 resursų (CSS, JS, paveikslėliai) nebeprivalo atidaryti 6-8 TCP ryšių, kad viską įkeltų greitai. Vienas ryšys puikiai susidoroja su visa apkrova. Testavau vieną e-komercijos projektą – po migracijos į HTTP/2 puslapio įkėlimo laikas sumažėjo nuo 3.2 sekundžių iki 1.8 sekundės. Jokių kitų pakeitimų nedarėme.
Antraščių suspaudimas – neakivaizdus herojus
Dar vienas dalykas, kurio daugelis nepastebės, bet kuris daro didžiulį skirtumą – HPACK antraščių suspaudimas. HTTP/1.1 kiekvieną kartą siųsdavo pilnas HTTP antraštes, kurios kartais būdavo didesnės nei pats turinys. Pavyzdžiui, cookies gali lengvai užimti 2-3 KB. Kai turite 50 užklausų, tai jau 100-150 KB perteklinių duomenų.
HTTP/2 naudoja specialią kompresijos techniką, kuri ne tik suspaudžia antraštes, bet ir prisimena anksčiau siųstas reikšmes. Jei antraštė nepasikeitė, protokolas tiesiog siunčia nuorodą į ankstesnę versiją. Mobilių tinklų atveju, kur kiekvienas baitas svarbus, tai tikrai jaučiama.
Server push – dviprasmis privalumas
HTTP/2 įvedė server push funkciją, kuri teoriškai turėjo būti revoliucija. Serveris gali proaktyviai siųsti resursus, kurių, jo manymu, klientui prireiks, dar prieš klientui juos užklausiant. Pavyzdžiui, kai naršyklė prašo HTML failo, serveris gali iš karto nusiųsti ir CSS, ir JS failus.
Tačiau praktikoje ši funkcija pasirodė esanti sudėtingesnė nei atrodė. Dažnai serveris nežino, ar klientas jau turi resursą cache’e, todėl gali siųsti nereikalingus duomenis. Aš asmeniškai retai naudoju server push – geriau pasikliauti HTTP cache mechanizmais ir resource hints (preload, prefetch). Bet tam tikrose situacijose, pavyzdžiui, kai žinote, kad turinys tikrai naujas visiems vartotojams, server push gali sutaupyti vieną round-trip laiką.
HTTP/3: QUIC protokolo revoliucija
Jei HTTP/2 buvo evoliucija, tai HTTP/3 – tai jau revoliucija. Didžiausias skirtumas – HTTP/3 nenaudoja TCP, o vietoj jo naudoja QUIC protokolą, kuris veikia virš UDP. Tai gali skambėti keistai, nes UDP tradiciškai laikomas „nepatikimu” protokolu, tačiau QUIC prideda visą reikiamą patikimumo logiką pats.
Kodėl tai svarbu? TCP turi fundamentalią problemą – jei prarandamas bent vienas paketas, visas ryšys sustoja, kol tas paketas bus persiųstas. Tai vadinama „head-of-line blocking” transporto lygmenyje. HTTP/2 išsprendė šią problemą aplikacijos lygmenyje, bet TCP lygmenyje problema išliko.
QUIC leidžia nepriklausomiems srautams veikti tikrai nepriklausomai. Jei prarandamas vienas paketas, sustoja tik tas srautas, kuriam jis priklauso, o kiti srautai tęsia darbą. Testavau video streaming platformą – su HTTP/3 buffering atvejai sumažėjo beveik 40% nestabiliuose mobiliuose tinkluose.
Greitesnis ryšio užmezgimas
TCP + TLS handshake paprastai užima 2-3 round-trips, kol galima pradėti siųsti duomenis. QUIC sujungia transporto ir kriptografijos handshake’us į vieną procesą. Pirmą kartą prisijungiant užtenka vieno round-trip, o jei jau esate prisijungę anksčiau, galima siųsti duomenis iš karto – 0-RTT (zero round-trip time).
Praktiškai tai reiškia, kad API užklausos mobiliosiose aplikacijose tampa žymiai greitesnės, ypač kai tinklo latency didelis. Viename projekte matėme, kad vidutinis API atsakymo laikas sumažėjo nuo 450ms iki 280ms tiesiog perjungus į HTTP/3. Tai buvo finansų aplikacija, kur kiekviena milisekundė svarbi.
Migracija į naujus protokolus: ką reikia žinoti
Teorija skamba puikiai, bet praktika visada sudėtingesnė. Pirmas dalykas – HTTP/2 ir HTTP/3 reikalauja HTTPS. Jei dar naudojate HTTP, pirmiausia turite įdiegti SSL/TLS sertifikatus. Laimei, su Let’s Encrypt tai tapo beveik nemokama ir paprasta.
Serverio pusėje dauguma šiuolaikinių web serverių palaiko HTTP/2 out of the box. Nginx nuo 1.9.5 versijos, Apache nuo 2.4.17 su mod_http2. Įjungimas paprastai atrodo taip:
# Nginx
listen 443 ssl http2;
# Apache
Protocols h2 http/1.1
Su HTTP/3 šiek tiek sudėtingiau, nes reikia QUIC palaikymo. Nginx turi eksperimentinį palaikymą, o Cloudflare ir Google Cloud jau pilnai palaiko. Jei naudojate CDN, tikėtina, kad HTTP/3 galite įjungti tiesiog pažymėję varnelę settings’uose.
Optimizacijos, kurios nebereikalingos
Įdomus HTTP/2 ir HTTP/3 aspektas – kai kurios senųjų laikų optimizacijos tampa ne tik nereikalingos, bet net žalingos. Domain sharding (resursų skirstymas per kelis domenus) buvo populiarus būdas apeiti HTTP/1.1 apribojimą dėl vienu metu atidaromų ryšių. Su HTTP/2 tai tampa antipattern’u, nes kiekvienas naujas domenas reikalauja naujo TCP/TLS handshake.
CSS sprites ir inline duomenys (data URIs) taip pat nebeturi tokios prasmės. HTTP/2 multipleksavimas reiškia, kad daug mažų failų įkelti yra beveik tiek pat efektyvu kaip vieną didelį. Net efektyviau, nes cache’inimas veikia geriau – jei pasikeičia vienas ikonas, nereikia perkrauti viso sprite’o.
Tačiau atsargiai su šiais sprendimais. Jei jūsų vartotojai vis dar naudoja senus naršykles (o kai kurie tikrai naudoja), HTTP/1.1 fallback vis dar svarbus. Geriausia strategija – palaikyti abi versijas ir leisti serveriui automatiškai pasirinkti tinkamą protokolą.
Realūs performance testai ir matavimas
Vienas dalykas sakyti, kad nauji protokolai greitesni, kitas – tai įrodyti. Naudoju WebPageTest su skirtingomis protokolų versijomis, kad pamatyčiau tikrą skirtumą. Svarbu testuoti ne tik iš greitų ryšių, bet ir simuliuoti lėtus 3G tinklus – būtent ten skirtumai labiausiai matomi.
Chrome DevTools Network tab rodo, kuris protokolas naudojamas kiekvienai užklausai. Stulpelyje „Protocol” matysite „h2” arba „h3”. Jei matote „http/1.1”, nors tikėjotės HTTP/2, tikėtina, kad serveris nekorektiškai sukonfigūruotas arba naršyklė dėl kokios nors priežasties negalėjo susitarti dėl protokolo.
Kai testuojate performance, atkreipkite dėmesį į šiuos metrikų pokyčius:
- Time to First Byte (TTFB) – turėtų sumažėti su HTTP/3 dėl greitesnio handshake
- Total page load time – turėtų sumažėti su HTTP/2/3 dėl multipleksavimo
- Number of connections – turėtų drastiškai sumažėti su HTTP/2/3
- Bandwidth usage – turėtų šiek tiek sumažėti dėl header compression
Viename projekte pastebėjau, kad HTTP/3 kartais rodo lėtesnius rezultatus nei HTTP/2 greitame WiFi tinkle. Tai normalu – QUIC turi šiek tiek didesnį overhead CPU naudojimui. Pranašumai pasireiškia nestabiliuose ir lėtuose tinkluose, ne idealių sąlygų laboratorijose.
Saugumo aspektai ir privatumas
HTTP/2 ir HTTP/3 priverstinai naudoja šifravimą, kas iš principo yra gerai. Tačiau tai reiškia, kad tradiciniai network monitoring įrankiai nebegali tiesiog „pasižiūrėti” į trafiką. Jei jūsų organizacija naudoja SSL inspection, tai gali sukelti problemų su HTTP/3, nes QUIC šifravimas yra integruotas į patį protokolą.
Kitas aspektas – QUIC naudoja connection ID vietoj IP adreso + porto kombinacijos ryšiui identifikuoti. Tai reiškia, kad vartotojas gali pakeisti IP adresą (pvz., persijungti iš WiFi į mobilųjį tinklą), bet ryšys nesutrikdomas. Puiku vartotojo patirčiai, bet gali komplikuoti tam tikrus saugumo scenarijus, kur sekate ryšius pagal IP.
Privatumo požiūriu HTTP/3 yra geresnis nei ankstesni protokolai. Daugiau informacijos yra užšifruota, įskaitant kai kuriuos metaduomenis, kurie HTTP/2 buvo matomi. Tačiau SNI (Server Name Indication) vis dar nėra užšifruotas standartinėje implementacijoje, nors Encrypted SNI (ESNI) ir jo įpėdinis ECH (Encrypted Client Hello) jau kuriami.
CDN ir edge computing kontekste
Jei naudojate CDN, tikėtina, kad HTTP/2 ir HTTP/3 jau palaikomi. Cloudflare, Fastly, Akamai – visi pagrindiniai žaidėjai turi pilną palaikymą. Bet yra niuansų, kaip tai veikia praktikoje.
Dažnai CDN automatiškai konvertuoja protokolus. Vartotojas gali prisijungti per HTTP/3, bet CDN į origin serverį jungiasi per HTTP/1.1 arba HTTP/2. Tai veikia, bet prarandate kai kuriuos pranašumus, ypač jei origin serveris lėtas. Idealiu atveju visas kelias nuo vartotojo iki origin turėtų naudoti naujausius protokolus.
Edge computing platformos kaip Cloudflare Workers ar Fastly Compute@Edge leidžia vykdyti kodą CDN edge serveriuose. Čia HTTP/3 pranašumai dar labiau išryškėja, nes latency tarp vartotojo ir edge yra minimalus, o QUIC efektyvumas maksimalus. Viename serverless projekte pastebėjome, kad cold start laikas sumažėjo beveik 30% perjungus į HTTP/3, nes mažiau laiko praleista handshake’uose.
Kas toliau: HTTP protokolų ateitis ir praktiniai patarimai
HTTP/3 vis dar bręsta. Kai kurios funkcijos, kaip antai prioritization, dar nėra pilnai standartizuotos ir skirtingos implementacijos elgiasi skirtingai. Tačiau tai neturėtų atbaidyti nuo eksperimentavimo. Protokolas yra pakankamai stabilus production naudojimui, o fallback į HTTP/2 ar HTTP/1.1 veikia sklandžiai.
Praktiniai patarimai, jei planuojate migraciją:
Pradėkite nuo HTTP/2 – tai paprasčiau ir plačiau palaikoma. Įsitikinkite, kad viskas veikia stabiliai, išmokite naujų protokolų ypatumus. Tik tada eksperimentuokite su HTTP/3.
Naudokite CDN – jei nenorite patys konfigūruoti serverių, CDN suteikia paprastą būdą gauti HTTP/2 ir HTTP/3 pranašumus. Cloudflare nemokamame plane palaiko abu protokolus.
Monitorinkite realius vartotojus – sintetiniai testai geri, bet Real User Monitoring (RUM) parodo, kaip protokolai veikia realiame pasaulyje su įvairiais įrenginiais ir tinklais. Google Analytics arba specialūs RUM įrankiai gali rodyti performance metrikas pagal protokolą.
Neišmeskite senų optimizacijų iš karto – nors domain sharding ir sprites nebereikalingi su HTTP/2, jūsų vartotojai gali vis dar naudoti HTTP/1.1. Progressive enhancement principas tinka ir čia.
Testuokite mobiliosiose – būtent mobiliuosiuose tinkluose HTTP/3 pranašumai labiausiai matomi. 4G tinklas su 100ms latency ir 5% packet loss – būtent tokiomis sąlygomis QUIC spindi.
Ateityje tikėtina pamatysime dar daugiau protokolų evoliucijos. Jau kalbama apie HTTP/4, nors tai dar labai anksti. QUIC pats savaime tobulėja – naujosios versijos prideda geresnius congestion control algoritmus, efektyvesnį multipleksavimą, geresnes prioritization schemas.
Svarbiausia suprasti, kad protokolų atnaujinimas nėra vienkartinis projektas, o nuolatinis procesas. Interneto infrastruktūra keičiasi, vartotojų lūkesčiai auga, o mes turime sekti paskui. HTTP/2 ir HTTP/3 nėra galutinis tikslas, bet svarbi kelionės dalis link greitesnio, saugesnio ir efektyvesnio interneto. Ir gera žinia ta, kad dauguma šių patobulinimų veikia automatiškai – kartą teisingai sukonfigūravus, vartotojai gauna geresnę patirtį net to nepastebėdami.