Ang IETF (Internet Engineering Task Force), na responsable para sa pagbuo ng mga protocol at arkitektura ng Internet, ay nakumpleto ang pagbuo ng isang RFC para sa HTTP/3.0 protocol at naglathala ng mga kaugnay na detalye sa ilalim ng mga identifier na RFC 9114 (protocol) at RFC 9204 ( QPACK header compression technology para sa HTTP/3) . Ang pagtutukoy ng HTTP/3.0 ay nakatanggap ng katayuan ng isang "Iminungkahing Pamantayan", pagkatapos ay magsisimula ang trabaho upang bigyan ang RFC ng katayuan ng isang draft na pamantayan (Draft Standard), na talagang nangangahulugan ng kumpletong pag-stabilize ng protocol at isinasaalang-alang ang lahat. ang mga komentong ginawa. Kasabay nito, ang mga na-update na bersyon ng mga detalye para sa HTTP/1.1 (RFC 9112) at HTTP/2.0 (RFC 9113) na mga protocol ay nai-publish, pati na rin ang mga dokumentong tumutukoy sa mga semantika ng mga kahilingan sa HTTP (RFC 9110) at HTTP caching control header (RFC 9111).
Tinutukoy ng HTTP/3 protocol ang paggamit ng QUIC (Quick UDP Internet Connections) protocol bilang transport para sa HTTP/2. 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 ay ginawa noong 2013 ng Google bilang alternatibo sa kumbinasyon ng TCP+TLS para sa Web, paglutas ng mga problema sa mahabang pag-setup ng koneksyon at mga oras ng negosasyon sa TCP at pag-aalis ng mga pagkaantala kapag nawala ang mga packet sa panahon ng paglilipat ng data.
Sa kasalukuyan, ang QUIC at HTTP/3.0 na suporta ay ipinapatupad na sa lahat ng sikat na web browser (sa Chrome, Firefox at Edge, ang suporta sa HTTP/3 ay pinagana bilang default, at sa Safari ay nangangailangan ito ng setting na βAdvanced > Experimental Features > HTTP/3β paganahin). Sa panig ng server, ang mga pagpapatupad ng HTTP/3 ay magagamit para sa nginx (sa isang hiwalay na sangay at sa anyo ng isang hiwalay na module), Caddy, IIS at LiteSpeed. Ang suporta sa HTTP/3 ay ibinibigay din ng network ng paghahatid ng nilalaman ng Cloudflare.
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%.
Kabilang sa mga pagbabago sa detalye ng HTTP/1.1, mapapansin ng isa ang pagbabawal sa nakahiwalay na paggamit ng character na carriage return (CR) sa labas ng katawan na may nilalaman, i.e. Sa mga elemento ng protocol, ang CR character ay maaari lamang gamitin kasama ng line feed character (CRLF). Ang chunked request layout algorithm ay pinahusay upang pasimplehin ang paghihiwalay ng mga naka-attach na field at mga seksyon na may mga header. Nagdagdag ng mga rekomendasyon para sa pangangasiwa ng hindi maliwanag na nilalaman upang harangan ang mga pag-atake ng βHTTP Request Smuggling,β na nagbibigay-daan sa aming i-wedge ang aming sarili sa nilalaman ng mga kahilingan ng ibang mga user sa daloy sa pagitan ng frontend at backend.
Ang pag-update ng detalye ng HTTP/2.0 ay tahasang tumutukoy sa suporta para sa TLS 1.3. Hindi na ginagamit ang scheme ng prioritization at nauugnay na mga field ng header. Ang hindi nagamit na mekanismo para sa pag-update ng koneksyon sa HTTP/1.1 ay idineklara na hindi na ginagamit. Mga pinababang kinakailangan para sa pagsuri sa mga pangalan at halaga ng field. Iminungkahi para sa paggamit ang ilang dating nakareserbang mga uri at parameter ng frame. Ang mga ipinagbabawal na field ng header na nauugnay sa koneksyon ay mas tiyak na tinukoy.
Pinagmulan: opennet.ru