Inaasahang maglulunsad ang Firefox ng suporta sa HTTP/3 sa katapusan ng Mayo.

Inanunsyo ng Mozilla ang intensyon nitong simulan ang pag-phase sa HTTP/3 at QUIC sa pagpapalabas ng Firefox 88, na naka-iskedyul para sa Abril 19 (orihinal na inaasahang ilalabas sa Abril 20, ngunit sa paghusga sa iskedyul, ito ay ibabalik ng isang araw). Ie-enable ang suporta sa HTTP/3 para lamang sa maliit na porsyento ng mga user sa simula at, maliban sa anumang hindi inaasahang isyu, ilulunsad sa lahat sa katapusan ng Mayo. Sa gabi-gabi na mga build at beta na bersyon, ang HTTP/3 ay pinagana bilang default sa katapusan ng Marso.

Alalahanin natin na ang pagpapatupad ng HTTP/3 sa Firefox ay batay sa neqo na proyekto na binuo ng Mozilla, na nagbibigay ng pagpapatupad ng kliyente at server para sa QUIC protocol. Ang component code para sa HTTP/3 at QUIC na suporta ay nakasulat sa Rust. Upang kontrolin kung ang HTTP/3 ay pinagana, ang about:config ay nagbibigay ng opsyong “network.http.http3.enabled”. Mula sa software ng kliyente, ang pang-eksperimentong suporta para sa HTTP/3 ay idinagdag din sa Chrome at curl, at para sa mga server ay available ito sa nginx, gayundin sa anyo ng isang nginx module at isang test server mula sa Cloudflare. Sa panig ng website, ang suporta sa HTTP/3 ay ibinibigay na sa mga server ng Google at Facebook.

Ang HTTP/3 protocol ay nasa yugto pa rin ng draft na detalye at hindi pa ganap na na-standardize ng IETF. Nangangailangan ang HTTP/3 ng suporta sa kliyente at server para sa parehong bersyon ng pamantayan ng QUIC draft at HTTP/3, na tinukoy sa header ng Alt-Svc (Sinusuportahan ng Firefox ang mga spec draft 27 hanggang 32).

Tinutukoy ng HTTP/3 ang paggamit ng QUIC protocol bilang transport para sa HTTP/2. Ang protocol ng QUIC (Quick UDP Internet Connections) ay binuo ng Google mula noong 2013 bilang isang alternatibo sa kumbinasyon ng TCP+TLS para sa Web, paglutas ng mga problema sa mahabang setup at mga oras ng negosasyon para sa mga koneksyon sa TCP at pag-aalis ng mga pagkaantala kapag nawala ang mga packet sa panahon ng data. paglipat. Ang QUIC ay isang extension ng UDP protocol na sumusuporta sa multiplexing ng maraming koneksyon at nagbibigay ng mga paraan ng pag-encrypt na katumbas ng TLS/SSL. Sa panahon ng pagbuo ng pamantayan ng IETF, ginawa ang mga pagbabago sa protocol, na humantong sa paglitaw ng dalawang parallel na sangay, isa para sa HTTP/3, at ang pangalawa ay suportado ng Google (Sinusuportahan ng Chrome ang parehong mga opsyon).

Mga pangunahing tampok ng QUIC:

• Mataas na seguridad na katulad ng TLS (talagang nagbibigay ang QUIC ng kakayahang gumamit ng TLS sa UDP);
• Kontrol sa integridad ng daloy, na pumipigil sa pagkawala ng packet;
• Ang kakayahang agad na magtatag ng koneksyon (0-RTT, sa humigit-kumulang 75% ng mga kaso, ang data ay maaaring maipadala kaagad pagkatapos ipadala ang packet ng pag-setup ng koneksyon) at magbigay ng kaunting mga pagkaantala sa pagitan ng pagpapadala ng kahilingan at pagtanggap ng tugon (RTT, Round Trip Time);
• Paggamit ng ibang sequence number kapag muling nagpapadala ng packet, na nag-iwas sa kalabuan sa pagtukoy ng mga natanggap na packet at inaalis ang mga timeout;
• Ang pagkawala ng isang packet ay nakakaapekto lamang sa paghahatid ng stream na nauugnay dito at hindi humihinto sa paghahatid ng data sa parallel stream na ipinadala sa pamamagitan ng kasalukuyang koneksyon;
• Mga feature sa pagwawasto ng error na nagpapaliit ng mga pagkaantala dahil sa muling pagpapadala ng mga nawawalang packet. Paggamit ng mga espesyal na code sa pagwawasto ng error sa antas ng packet upang mabawasan ang mga sitwasyon na nangangailangan ng muling pagpapadala ng nawalang packet data.
• Ang mga hangganan ng cryptographic block ay nakahanay sa mga hangganan ng QUIC packet, na binabawasan ang epekto ng mga pagkawala ng packet sa pag-decode ng mga nilalaman ng kasunod na mga packet;
• Walang mga problema sa TCP queue blocking;
• Suporta para sa pagkakakilanlan ng koneksyon, na binabawasan ang oras na kinakailangan upang magtatag ng muling pagkonekta para sa mga mobile client;
• Posibilidad ng pagkonekta ng mga advanced na koneksyon sa congestion control mechanism;
• Gumagamit ng per-direction throughput forecasting techniques upang matiyak na ang mga packet ay naipadala sa pinakamainam na mga rate, na pinipigilan ang mga ito na maging masikip at magdulot ng packet loss;
• Malaking pagtaas sa performance at throughput kumpara sa TCP. Para sa mga serbisyo ng video gaya ng YouTube, ipinakita ng QUIC na bawasan ang mga operasyon ng rebuffering kapag nanonood ng mga video ng 30%.

Pinagmulan: opennet.ru