Pasukan Tugas Teknik Internet (IETF), sing tanggung jawab kanggo pangembangan protokol lan arsitektur Internet, wis ngrampungake RFC kanggo protokol QUIC lan nerbitake spesifikasi sing gegandhengan miturut pengenal RFC 8999 (properti protokol independen versi), RFC 9000 (transportasi). liwat UDP), RFC 9001 (enkripsi TLS saluran komunikasi QUIC) lan RFC 9002 (kontrol kemacetan lan deteksi mundhut paket nalika transmisi data).
RFCs nampa status "Standar Ngajokaken", sawise karya bakal miwiti kanggo menehi RFC status konsep standar (Draft Standard), kang bener tegese stabilisasi lengkap saka protokol lan njupuk menyang akun kabeh komentar. Protokol HTTP / 3, sing nemtokake panggunaan protokol QUIC minangka transportasi kanggo HTTP / 2, isih ana ing tahap spesifikasi draf, nanging pungkasane bakal distandarisasi dening IETF.
Diarepake yen standarisasi QUIC bakal menehi dorongan kanggo adopsi protokol iki sing luwih akeh, uga kanggo pangembangan ekstensi adhedhasar, kayata WebTransport (teknologi kanggo ngirim lan nampa data antarane browser lan server) lan MASQUE (teknologi proxy sambungan sing ngembangake kemampuan SOCKS lan HTTP CONNECT lan nggunakake HTTPS liwat QUIC minangka transportasi).
Elinga yen protokol QUIC (Sambungan Internet UDP Cepet) wis dikembangake dening Google wiwit 2013 minangka alternatif kanggo kombinasi TCP + TLS kanggo Web, ngrampungake masalah karo persiyapan sing dawa lan wektu negosiasi sambungan ing TCP lan ngilangi telat nalika paket ilang nalika transfer data. QUIC minangka extension saka protokol UDP sing ndhukung multiplexing saka macem-macem sambungan lan nyedhiyakake cara enkripsi sing padha karo TLS / SSL. Sajrone pangembangan standar IETF, owah-owahan digawe ing protokol kasebut, sing ndadékaké munculé rong cabang paralel, siji kanggo HTTP/3, lan sing kapindho didhukung Google (Chrome ndhukung loro opsi, lan Firefox ndhukung versi IETF) .
Fitur utama QUIC:
- Keamanan dhuwur padha karo TLS (utamane QUIC nyedhiyakake kemampuan kanggo nggunakake TLS liwat UDP);
- Kontrol integritas aliran, nyegah mundhut paket;
- Kemampuan kanggo nggawe sambungan langsung (0-RTT, kira-kira 75% kasus, data bisa dikirim langsung sawise ngirim paket persiyapan sambungan) lan menehi wektu tundha minimal antarane ngirim panjalukan lan nampa respon (RTT, Round Trip Time) ;
- Nggunakake nomer urutan sing beda nalika ngirim maneh paket, sing ngindhari ambiguitas kanggo ngenali paket sing ditampa lan nyingkirake wektu entek;
- Mundhut paket mung mengaruhi pangiriman stream sing ana gandhengane lan ora mungkasi pangiriman data ing aliran paralel sing ditularake liwat sambungan saiki;
- Fitur koreksi kesalahan sing nyilikake wektu tundha amarga pangirim maneh paket sing ilang. Gunakake kode koreksi kesalahan khusus ing tingkat paket kanggo nyuda kahanan sing mbutuhake transmisi ulang data paket sing ilang.
- Watesan pamblokiran kriptografis didadekake siji karo wates paket QUIC, sing nyuda impact mundhut paket ing dekoding isi paket sakteruse;
- Ora ana masalah karo pamblokiran antrian TCP;
- Dhukungan kanggo pengenal sambungan, sing nyuda wektu kanggo nggawe sambungan maneh kanggo klien seluler;
- Kamungkinan nyambungake mekanisme kontrol kemacetan sambungan lanjut;
- Nggunakake teknik prakiraan throughput saben arah kanggo mesthekake yen paket dikirim kanthi tarif sing optimal, nyegah supaya ora dadi rame lan nyebabake paket ilang;
- Tambah pinunjul ing kinerja lan throughput dibandhingake TCP. Kanggo layanan video kayata YouTube, QUIC wis ditampilake nyuda operasi rebuffering nalika nonton video kanthi 30%.
Source: opennet.ru
