kamakailan ang IETF (Internet Engineering Task Force), na bumubuo ng mga protocol at arkitektura ng Internet, ipinaalam ito ang balita na nakumpleto ang pagbuo ng RFC para sa HTTP/3.0 protocol at nai-publish ang mga kaugnay na detalye sa ilalim ng mga identifier na RFC 9114 at RFC 9204.
Ang pagtutukoy ng HTTP/3.0 nakatanggap ng katayuan ng "Iminungkahing Pamantayan", pagkatapos kung saan ang trabaho ay magsisimulang bigyan ang RFC ng katayuan ng isang draft na pamantayan (Draft Standard), na talagang nangangahulugan ng isang kumpletong pagpapapanatag ng protocol at isinasaalang-alang ang lahat ng mga komento na ginawa.
Protocol Tinutukoy ng HTTP/3 ang paggamit ng QUIC protocol (Mabilis na UDP Internet Connections) bilang transportasyon para sa HTTP/2. Ang QUIC ay isang plugin sa 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 TCP + TLS para sa Web, paglutas sa problema ng mahabang pag-setup ng koneksyon at oras ng negosasyon sa TCP at pag-aalis ng mga pagkaantala dahil sa pagkawala ng packet sa panahon ng paglilipat ng data.
sa kasalukuyan, Ang QUIC at HTTP/3.0 na suporta ay ipinatupad na sa lahat ng browser mga sikat na website. Sa panig ng server, ang mga pagpapatupad ng HTTP/3 ay magagamit para sa nginx (sa isang hiwalay na sangay at bilang isang hiwalay na module), Caddy , IIS at LiteSpeed. Ang HTTP/3 ay sinusuportahan din ng Network ng Paghahatid ng Nilalaman ng Cloudflare.
Mga pangunahing tampok ng QUIC:
- Mataas na seguridad, katulad ng TLS (sa katunayan, ang QUIC ay nagbibigay ng kakayahang gumamit ng TLS sa UDP)
- Transmission integrity control para maiwasan ang packet loss
- Ang kakayahang magtatag ng koneksyon kaagad at matiyak ang kaunting mga pagkaantala sa pagitan ng pagpapadala ng kahilingan at pagtanggap ng tugon (RTT, round trip time)
- Gumamit ng ibang sequence number kapag muling nagpapadala ng packet, na nagbibigay-daan sa iyong maiwasan ang kalabuan kapag tinutukoy ang mga natanggap na packet at alisin ang mga timeout
- Ang pagkawala ng isang packet ay nakakaapekto sa paghahatid ng stream lamang na nauugnay dito at hindi titigil sa paghahatid ng data sa mga stream na nailipat nang kahanay sa kasalukuyang koneksyon
- Mga tool 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 nawawalang data ng packet.
- Ang mga hangganan ng cryptographic block ay nakahanay sa mga hangganan ng QUIC packet, na binabawasan ang epekto ng pagkawala ng packet sa pag-decode ng nilalaman ng mga kasunod na packet
- Walang problema sa pag-block sa pila ng TCP
- Suporta sa pagkakakilanlan ng koneksyon upang bawasan ang oras ng muling pagkonekta para sa mga mobile client
- Posibilidad ng pagkonekta ng mga advanced na mekanismo para sa kontrol ng overload ng koneksyon
- Gumamit ng mga diskarte sa paghula ng bandwidth sa bawat direksyon upang matiyak ang pinakamainam na rate ng pagpapasa ng packet, pag-iwas sa mga kondisyon ng congestion kung saan nawawala ang mga packet.
- Kapansin-pansing performance at performance gains sa TCP. Para sa mga serbisyo ng video tulad ng YouTube, ipinakita ng QUIC na bawasan ang mga pagpapatakbo ng video buffering ng 30%.
Bilang karagdagan dito, 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).
Sa mga pagbabago sa ang pagtutukoy HTTP/1.1, mapapansin mo ang pagbabawal mula sa hiwalay na paggamit ng carriage return character (CR) sa labas ng katawan na may nilalaman, ibig sabihin, sa mga elemento ng protocol, ang CR character ay magagamit lamang kasama ng bagong line character (CRLF).
El Ang algorithm ng layout ng chunked request ay napabuti upang pasimplehin ang paghihiwalay ng mga kalakip na field at seksyon na may mga header. Nagdagdag ng mga alituntunin para sa paghawak ng hindi maliwanag na nilalaman upang harangan ang mga pag-atake ng klase ng "HTTP Request Smuggling" na maaaring makagambala sa nilalaman ng mga kahilingan ng ibang mga user sa daloy sa pagitan ng frontend at backend.
Isang update sa detalye Ang HTTP/2.0 ay tahasang tumutukoy sa suporta para sa TLS 1.3, hindi na ginagamit na scheme ng prioritization at mga nauugnay na field ng header at mekanismo ng pag-update hindi na ginagamit ang HTTP/1.1 na koneksyon ay hindi na ginagamit.
Panghuli, kung interesado kang malaman ang higit pa tungkol dito, maaari mong konsultahin ang mga detalye sa sumusunod na link.