Sa mga pang-eksperimentong build suporta para sa HTTP/3 protocol, na nagpapatupad ng add-on para paganahin ang HTTP sa QUIC protocol. Ang QUIC protocol mismo ay idinagdag sa browser limang taon na ang nakakaraan at mula noon ay ginamit upang i-optimize ang trabaho sa mga serbisyo ng Google. Kasabay nito, ang QUIC na bersyon mula sa Google na ginamit sa Chrome ay naiiba sa ilang detalye mula sa bersyon mula sa IETF, ngunit ngayon ang mga pagpapatupad ay naka-synchronize.
Ini-standardize ng HTTP/3 ang paggamit ng QUIC bilang transport para sa HTTP/2. Upang paganahin ang HTTP/3 at QUIC na opsyon mula sa Ang mga detalye ng IETF ay nangangailangan na ang Chrome ay ilunsad gamit ang mga opsyon na "-enable-quic -quic-version=h3-23" at pagkatapos ay kapag binubuksan ang site ng pagsubok Sa network inspection mode sa mga tool ng developer, ang aktibidad ng HTTP/3 ay ipapakita bilang βhttp/2+quic/99β.
Alalahanin na ang protocol (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 paglilipat ng data. 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. Ang protocol na pinag-uusapan ay isinama na sa imprastraktura ng server ng Google at bahagi ito ng Chrome. para sa pagsasama sa Firefox at aktibong ginagamit upang maghatid ng mga kahilingan ng kliyente sa mga server ng Google.
Ang pangunahing 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 ipadala 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);
- Hindi gumagamit ng parehong 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;
- Nahahalata pagganap 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