Në versionet nocturne të Firefox, si dhe në versionin beta, mbështetja për protokollin HTTP/3 është e aktivizuar nga default. Aktivizimi i HTTP/3 në versionin stabil është planifikuar për lançimin e Firefox 88, i cili është caktuar për 20 prill. Në Chrome, aktivizimi selektiv i HTTP/3 filloi në tetor 2020.
Mbështetja për HTTP/3 në Firefox bazohet në projektin neqo të zhvilluar nga Mozilla, i cili ofron implementimin e klientit dhe server serverit për protokollin QUIC. Kodi i komponenteve për mbështetje të HTTP/3 dhe QUIC është shkruar në gjuhën Rust. Për menaxhimin e aktivizimit të HTTP/3, në about:config ekziston një opsion "network.http.http3.enabled". Si pjesë e klientëve, mbështetja eksperimentale për HTTP/3 gjithashtu është shtuar tashmë në Chrome dhe curl, si dhe servera është e disponueshme në nginx, si dhe në formën e një moduli nginx dhe serverit testues nga kompania Cloudflare. Për të verifikuar funksionimin e klientëve HTTP/3 janë lansuar disa faqe testuese.
Protokolli HTTP/3 aktualisht është në fazën e specifikimit të provizor dhe ende nuk është standardizuar përfundimisht në IETF. HTTP/3 përcakton përdorimin e protokollit QUIC si transport për HTTP/2. Protokolli QUIC (Quick UDP Internet Connections) është zhvilluar nga kompania Google që nga viti 2013 si një alternativë për lidhjen TCP+TLS për Web, duke zgjidhur problemet e vonesave të mëdha në vendosjen dhe pajtimin e lidhjeve në TCP dhe duke eliminuar vonesat gjatë humbjes së paketave në procesin e transferimit të të dhënave. QUIC paraqet një shtesë mbi protokollin UDP, e cila mbështet shumë lidhje dhe ofron metoda enkriptimi të barabarta me TLS/SSL. Gjatë zhvillimit të standardit në IETF, në protokoll janë bërë ndryshime, duke përfunduar me krijimin e dy degëve të zakonshme, një për HTTP/3 dhe një tjetër e mbështetur nga Google (Chrome mbështet të dyja variantet).
Karakteristikat kryesore të QUIC:
- Siguri e lartë, e ngjashme me TLS (në thelb, QUIC ofron mundësinë e përdorimit të TLS mbi UDP);
- Kontrolli i integritetit të rrjedhës, duke parandaluar humbjen e paketave;
- Mundësia për të vendosur menjëherë një lidhje (0-RTT, në rreth 75% të rasteve, të dhënat mund të transmetohen menjëherë pas dërgimit të paketës së vendosjes së lidhjes) dhe të sigurojë vonesa minimale midis dërgimit të kërkesës dhe marrjes së përgjigjes (RTT, Round Trip Time);
- Përdorimi i një numri tjetër renditje për ripërsëritjen e paketës, çka lejon evitimin e paqartësisë në përcaktimin e paketimeve të pranuara dhe heqjen e vonesave;
- humbja e paketave ndikon vetëm në dërgesën e lidhur me grupe të caktuara dhe nuk ndalon dërgimin e të dhënave në grupe paralelisht të transferuara përmes këtij lidhjeje;
- Mjetet për korrektionin e gabimeve, të cilat minimizojnë vonesat për shkak të ripërsëritjes së paketimeve të humbura. Përdorimi i kodeve speciale të korrekcioni të gabimeve në nivelin e paketës për të reduktuar situatat që kërkojnë ripërsëritjen e të dhënave të paketave të humbura.
- Kufijtë e blloqeve kriptografike janë rreshtuar me kufijtë e pakove QUIC, duke zvogëluar ndarjen e humbjeve të pakove në dekodimin e përmbajtjes së pakove të ardhshme;
- Mungesa e problemeve me bllokimin e radhës TCP;
- Mbështetje për identifikimin e lidhjes, që lejon të shkurtohet koha e vendosjes së lidhjes së re për klientët e lëvizshëm;
- Aftësia për të lidhur mekanizma të avancuar të kontrollit të mbingarkesës së lidhjes;
- Përdorimi i teknikave të parashikimit të kapacitetit në çdo drejtim për të garantuar intensitetin optimal të dërgimit të paketeve, duke parandaluar rënien në një gjendje mbipopullimi, ku vërehet humbja e paketeve;
- Një rritje e dukshme e performancës dhe kapacitetit, krahasuar me TCP. Për shërbimet video, si YouTube, përdorimi i QUIC tregoi një reduktim të operacioneve të ripërshkallëzimit gjatë shikimit të videove me 30%.
Burimi: opennet.ru
