Interneta inženierijas darba grupa (IETF), kas ir atbildīga par interneta protokolu un arhitektūras izstrādi, ir pabeigusi QUIC protokola RFC un publicējusi saistītās specifikācijas ar identifikatoriem RFC 8999 (no versijas neatkarīgi protokola rekvizīti), RFC 9000 (transports). pār UDP), RFC 9001 (QUIC sakaru kanāla TLS šifrēšana) un RFC 9002 (pārslodzes kontrole un pakešu zudumu noteikšana datu pārraides laikā).
RFC saņēma “Ierosinātā standarta” statusu, pēc kura tiks uzsākts darbs, lai RFC piešķirtu standarta projekta (Standarta projekts) statusu, kas faktiski nozīmē pilnīgu protokola stabilizāciju un ņemot vērā visus izteiktos komentārus. HTTP/3 protokols, kas definē QUIC protokola izmantošanu kā HTTP/2 transportu, joprojām ir specifikācijas projekta stadijā, taču drīzumā to beidzot standartizēs IETF.
Paredzams, ka QUIC standartizācija dos impulsu šī protokola plašākai ieviešanai, kā arī uz tā balstītu paplašinājumu izstrādei, piemēram, WebTransport (tehnoloģija datu nosūtīšanai un saņemšanai starp pārlūkprogrammu un serveri) un MASQUE. (savienojuma starpniekserverēšanas tehnoloģija, kas paplašina SOCKS un HTTP CONNECT iespējas un kā transportu izmanto HTTPS, izmantojot QUIC).
Atgādināsim, ka QUIC (Quick UDP Internet Connections) protokolu Google izstrādā kopš 2013. gada kā alternatīvu TCP+TLS kombinācijai tīmeklī, risinot problēmas ar garo savienojumu iestatīšanas un sarunu laiku TCP un novēršot aizkaves, kad datu pārsūtīšanas laikā tiek zaudētas paketes. QUIC ir UDP protokola paplašinājums, kas atbalsta vairāku savienojumu multipleksēšanu un nodrošina TLS/SSL līdzvērtīgas šifrēšanas metodes. IETF standarta izstrādes laikā tika veiktas izmaiņas protokolā, kā rezultātā parādījās divi paralēli atzari, viens HTTP/3, bet otrs atbalsta Google (Chrome atbalsta abas opcijas, un Firefox atbalsta IETF versiju) .
Galvenās QUIC funkcijas:
- Augsta drošība, līdzīga TLS (patiesībā QUIC nodrošina iespēju izmantot TLS, izmantojot UDP);
- Straumes integritātes kontrole, lai novērstu pakešu zudumu;
- Iespēja uzreiz izveidot savienojumu (0-RTT, aptuveni 75% gadījumu datus var pārsūtīt uzreiz pēc savienojuma iestatīšanas paketes nosūtīšanas) un nodrošināt minimālu aizkavi starp pieprasījuma nosūtīšanu un atbildes saņemšanu (RTT, Round Trip Time);
- Atkārtoti pārsūtot paketi, tiek izmantots cits kārtas numurs, kas ļauj izvairīties no neskaidrībām saņemto pakešu identificēšanā un atbrīvoties no taimauta;
- Pakešu zudums ietekmē tikai ar to saistītās straumes piegādi un neaptur datu piegādi straumēs, kas tiek pārraidītas paralēli pašreizējā savienojumā;
- Kļūdu labošanas rīki, kas samazina aizkavi zaudēto pakešu atkārtotas pārsūtīšanas dēļ. Īpašu kļūdu labošanas kodu izmantošana pakešu līmenī, lai samazinātu situācijas, kurās nepieciešams atkārtoti nosūtīt zaudētos pakešdatus.
- Kriptogrāfisko bloku robežas tiek saskaņotas ar QUIC pakešu robežām, kas samazina pakešu zudumu ietekmi uz nākamo pakešu satura dekodēšanu;
- Nav problēmu ar TCP rindas bloķēšanu;
- Savienojuma ID atbalsts, lai samazinātu atkārtota savienojuma laiku mobilajiem klientiem;
- Iespēja pieslēgt progresīvus mehānismus savienojuma pārslodzes kontrolei;
- Izmantojot joslas platuma prognozēšanas paņēmienus katrā virzienā, lai nodrošinātu optimālu pakešu nosūtīšanas intensitāti, novēršot pārtīšanu pārslodzes stāvoklī, kurā notiek pakešu zudumi;
- Ievērojams veiktspējas un caurlaidspējas pieaugums salīdzinājumā ar TCP. Ir pierādīts, ka tādiem video pakalpojumiem kā YouTube, QUIC samazina atkārtotas buferizācijas darbības, skatoties videoklipus par 30%.
Avots: opennet.ru