Pasukan Tugas Téknik Internét (IETF), anu tanggung jawab pikeun ngembangkeun protokol sareng arsitéktur Internét, parantos ngabéréskeun RFC pikeun protokol QUIC sareng nyebarkeun spésifikasi anu aya hubunganana dina idéntifikasi RFC 8999 (sipat protokol bebas versi), RFC 9000 (transportasi). leuwih UDP), RFC 9001 (enkripsi TLS saluran komunikasi QUIC) jeung RFC 9002 (kontrol kamacetan sarta deteksi leungitna pakét salila pangiriman data).
RFCs nampi status "Standar Diusulkeun", nu satutasna karya bakal ngawitan masihan RFC status draf standar (Draft Standar), nu sabenerna hartina stabilisasi lengkep tina protokol jeung nyokot kana akun sagala komentar dijieun. Protokol HTTP / 3, anu ngahartikeun panggunaan protokol QUIC salaku angkutan pikeun HTTP / 2, masih aya dina tahap spésifikasi draf, tapi engké bakal dibakukeun ku IETF.
Diperkirakeun yén standarisasi QUIC bakal masihan dorongan pikeun nyoko anu langkung lega tina protokol ieu, ogé pikeun ngembangkeun ekstensi dumasar kana éta, sapertos WebTransport (téknologi pikeun ngirim sareng nampi data antara browser sareng server) sareng MASQUE. (téknologi proxying sambungan anu ngalegaan kamampuan SOCKS sareng HTTP CONNECT, sareng nganggo HTTPS leuwih QUIC salaku angkutan).
Hayu urang émut yén protokol QUIC (Gancangan UDP Internét Sambungan) parantos dikembangkeun ku Google ti saprak 2013 salaku alternatif pikeun kombinasi TCP + TLS pikeun Wéb, ngarengsekeun masalah sareng setelan panjang sareng waktos negosiasi sambungan dina TCP sareng ngaleungitkeun telat nalika. pakét leungit nalika mindahkeun data. QUIC mangrupikeun penyuluhan protokol UDP anu ngadukung multiplexing sababaraha sambungan sareng nyayogikeun metode enkripsi anu sami sareng TLS / SSL. Salila pamekaran standar IETF, parobahan dilakukeun kana protokol, anu nyababkeun mecenghulna dua cabang paralel, hiji pikeun HTTP / 3, sareng anu kadua dirojong ku Google (Chrome ngadukung dua pilihan, sareng Firefox ngadukung versi IETF) .
Fitur konci QUIC:
- Kaamanan anu luhur sami sareng TLS (dasarna QUIC nyayogikeun kamampuan ngagunakeun TLS dina UDP);
- Kontrol integritas aliran, nyegah pakét leungitna;
- Kamampuhan pikeun instan nyieun sambungan (0-RTT, kira-kira 75% kasus data bisa dikirimkeun langsung saatos ngirim pakét setelan sambungan) jeung nyadiakeun reureuh minimal antara ngirim pamundut jeung narima respon (RTT, Round Trip Time);
- Nganggo nomer sekuen anu béda nalika ngirimkeun deui pakét, anu ngahindarkeun ambiguitas dina ngaidentipikasi pakét anu ditampi sareng ngaleungitkeun waktosna;
- Leungitna pakét ngan ukur mangaruhan pangiriman aliran anu aya hubunganana sareng henteu ngeureunkeun pangiriman data dina aliran paralel anu dikirimkeun ku sambungan ayeuna;
- Fitur koréksi kasalahan anu ngaminimalkeun telat kusabab pangiriman ulang pakét anu leungit. Pamakéan kodeu koreksi kasalahan husus dina tingkat pakét pikeun ngurangan kaayaan merlukeun retransmission data pakét leungit.
- Wates blok kriptografis saluyu sareng wates pakét QUIC, anu ngirangan dampak karugian pakét dina ngadekodekeun eusi pakét anu salajengna;
- Teu aya masalah sareng blokir antrian TCP;
- Rojongan pikeun identifier sambungan, nu ngurangan waktu nu diperlukeun pikeun nyieun reconnection pikeun klien mobile;
- Kamungkinan nyambungkeun mékanisme kontrol kamacetan sambungan canggih;
- Ngagunakeun téhnik forecasting throughput per-arah pikeun mastikeun yén pakét dikirim dina ongkos optimal, nyegah aranjeunna tina jadi congested sarta ngabalukarkeun leungitna pakét;
- Kanaékan signifikan dina kinerja sarta throughput dibandingkeun TCP. Pikeun jasa pidéo sapertos YouTube, QUIC parantos ditingalikeun ngirangan operasi rebuffering nalika ningali pidéo ku 30%.
sumber: opennet.ru