Cloudflare parantos ngalaksanakeun modul pikeun ngadukung HTTP / 3 di NGINX

Perusahaan Cloudflare disiapkeun modul nyadiakeun rojongan pikeun HTTP / 3 protokol di NGINX. modul nu dirancang salaku tambihan-on ka perpustakaan dikembangkeun ku Cloudflare puncak kalawan palaksanaan QUIC na HTTP / 3 protokol angkutan. Kode quiche ditulis dina Rust, tapi modul NGINX sorangan ditulis dina C sarta aksés ka perpustakaan ngagunakeun linking dinamis. Kamekaran muka handapeun lisénsi BSD.

Pikeun ngumpul, ngan ngundeur tambalan mun nginx 1.16 jeung di perpustakaan quiche, teras ngawangun deui nginx sareng pilihan "-with-http_v3_module -with-quiche=../quiche". Nalika ngawangun, rojongan TLS kudu dumasar kana perpustakaan BoringSSL ("--with-openssl=../quiche/deps/boringssl"), pamakéan OpenSSL teu acan dirojong. Pikeun nampi sambungan, anjeun kedah nambihan diréktif ngadangukeun kalayan bendera "quic" kana setélan (contona, "ngadangukeun 443 quic reuseport").

Dina parangkat lunak klien, dukungan HTTP / 3 parantos parantos ditambah kana ékspérimén ngawangun Chrome Canary sareng utilitas curl. Dina sisi server, nepi ka ayeuna perlu ngagunakeun misah, kawates palaksanaan tés. Kamampuhan pikeun ngolah HTTP / 3 dina nginx bakal nyederhanakeun panyebaran server kalayan dukungan HTTP / 3 sareng bakal ngajantenkeun palaksanaan uji protokol énggal langkung gampang diaksés. Mecenghulna rojongan baku pikeun HTTP / 3 di nginx diperkirakeun dina cabang 1.17.x pikeun 6-12 bulan.

Ngelingan yén HTTP / 3 standarisasi pamakéan protokol QUIC salaku angkutan pikeun HTTP / 2. Protokol CEPAT (Gancangan UDP Internet Connections) geus dimekarkeun ku Google saprak 2013 salaku alternatif pikeun kombinasi TCP + TLS pikeun Wéb, ngarengsekeun masalah sareng setelan panjang tur negosiasi kali pikeun sambungan di TCP sarta ngaleungitkeun reureuh nalika pakét leungit salila mindahkeun data. QUIC mangrupikeun penyuluhan protokol UDP anu ngadukung multiplexing sababaraha sambungan sareng nyayogikeun metode enkripsi anu sami sareng TLS / SSL.

utama Fitur CEPAT:

• 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);
• Henteu nganggo nomer sekuen anu sami 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;
• Perceptible tumuwuhna 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