Mozilla parantos ngumumkeun niatna pikeun ngamimitian phasing dina HTTP / 3 sareng QUIC kalayan sékrési Firefox 88, dijadwalkeun pikeun 19 April (asalna diperkirakeun dileupaskeun dina 20 April, tapi ditilik ku jadwalna, éta bakal kadorong deui ku hiji dinten). Pangrojong HTTP / 3 bakal diaktipkeun ngan ukur perséntase leutik pangguna awalna sareng, upami teu aya masalah anu teu kaduga, bakal digulung ka sadayana dina ahir Mei. Dina ngawangun wengi sareng versi beta, HTTP / 3 diaktipkeun sacara standar dina ahir Maret.
Hayu urang ngelingan yén palaksanaan HTTP / 3 di Firefox dumasar kana proyék neqo dikembangkeun ku Mozilla, nu nyadiakeun klien tur palaksanaan server pikeun protokol QUIC. Kode komponén pikeun HTTP / 3 sarta rojongan QUIC ditulis dina Rust. Pikeun ngadalikeun naha HTTP / 3 diaktipkeun, about:config nyadiakeun pilihan "network.http.http3.enabled". Tina parangkat lunak klien, dukungan ékspérimén pikeun HTTP / 3 ogé parantos ditambah kana Chrome sareng curl, sareng pikeun pangladén sayogi di nginx, ogé dina bentuk modul nginx sareng server uji Cloudflare. Di sisi halaman wéb, dukungan HTTP / 3 parantos disayogikeun dina server Google sareng Facebook.
Protokol HTTP/3 masih dina tahap draf spésifikasi sareng henteu acan distandarkeun sapinuhna ku IETF. HTTP / 3 merlukeun rojongan klien tur server pikeun versi sarua tina QUIC draf standar na HTTP / 3, nu dieusian dina Alt-Svc lulugu (Firefox ngarojong spésifik draf 27 ngaliwatan 32).
HTTP / 3 ngahartikeun pamakéan protokol QUIC salaku angkutan pikeun HTTP / 2. Protokol QUIC (Quick UDP Internet Connections) parantos dikembangkeun ku Google ti saprak 2013 salaku alternatip pikeun kombinasi TCP + TLS pikeun Wéb, ngarengsekeun masalah sareng setelan panjang sareng waktos negosiasi pikeun sambungan dina TCP sareng ngaleungitkeun telat nalika pakét leungit salami data. mindahkeun. QUIC mangrupikeun penyuluhan protokol UDP anu ngadukung multiplexing sababaraha sambungan sareng nyayogikeun metode enkripsi anu sami sareng TLS / SSL. Salila ngembangkeun standar IETF, parobahan dijieun kana protokol, nu ngakibatkeun mecenghulna dua cabang paralel, hiji keur HTTP / 3, sarta kadua dirojong ku Google (Chrome ngarojong duanana pilihan).
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