Protokol QUIC menarik banget kanggo ditonton, mula kita seneng nulis babagan iki. Nanging yen publikasi sadurunge babagan QUIC luwih saka sejarah (sajarah lokal, yen sampeyan seneng) alam lan hardware, dina iki kita seneng nerbitake terjemahan saka macem-macem jinis - kita bakal ngomong babagan aplikasi nyata saka protokol ing 2019. Kajaba iku, kita ora ngomong babagan infrastruktur cilik sing adhedhasar ing garasi sing diarani, nanging babagan Uber, sing makaryakke meh kabeh ndonya. Kepiye insinyur perusahaan mutusake nggunakake QUIC ing produksi, kepiye carane nindakake tes lan apa sing dideleng sawise diluncurake ing produksi - ing ngisor potongan kasebut.
Gambar bisa diklik. Seneng maca!
Uber nduweni skala global, yaiku 600 kutha sing ana, ing saben aplikasi kasebut gumantung ing Internet nirkabel saka luwih saka 4500 operator seluler. Pangguna ngarepake app ora mung cepet, nanging ing wektu nyata - kanggo entuk iki, aplikasi Uber mbutuhake latensi sing sithik lan sambungan sing dipercaya banget. Alas, nanging tumpukan ora apik ing jaringan nirkabel dinamis lan rawan mundhut. Kita nyadari yen ing kasus iki, kinerja kurang langsung ana hubungane karo implementasi TCP ing kernel sistem operasi.
Kanggo ngatasi masalah, kita aplikasi , protokol multiplexing saluran modern sing menehi kontrol luwih saka kinerja protokol transportasi. Saiki klompok kerja standarisasi QUIC minangka .
Sawise tes ekstensif, kita nyimpulake yen ngetrapake QUIC ing aplikasi kita bakal nyebabake latensi buntut sing luwih murah tinimbang TCP. Kita mirsani pangirangan ing kisaran 10-30% kanggo lalu lintas HTTPS ing aplikasi driver lan penumpang. QUIC uga menehi kontrol end-to-end babagan paket pangguna.
Ing artikel iki, kita nuduhake pengalaman ngoptimalake TCP kanggo aplikasi Uber nggunakake tumpukan sing ndhukung QUIC.
Teknologi paling anyar: TCP
Saiki, TCP minangka protokol transportasi sing paling akeh digunakake kanggo ngirim lalu lintas HTTPS ing Internet. TCP nyedhiyakake stream byte sing dipercaya, saengga bisa ngatasi kemacetan jaringan lan kerugian lapisan link. Panggunaan TCP sing nyebar kanggo lalu lintas HTTPS amarga ana ing ngendi-endi (meh kabeh OS ngemot TCP), kasedhiyan ing umume infrastruktur (kayata penyeimbang beban, proxy HTTPS lan CDN), lan fungsi sing ora ana ing kothak sing kasedhiya. ing meh kabeh platform lan jaringan.
Umume pangguna nggunakake aplikasi kita nalika lelungan, lan latensi buntut TCP ora ana ing ngendi wae sing dikarepake lalu lintas HTTPS wektu nyata. Cukup, pangguna ing saindenging jagad wis ngalami iki - Gambar 1 nuduhake wektu tundha ing kutha-kutha utama:
Gambar 1: Latensi buntut beda-beda ing kutha-kutha utama Uber.
Sanajan latensi ing jaringan India lan Brasil luwih dhuwur tinimbang ing AS lan Inggris, latensi buntut luwih dhuwur tinimbang latensi rata-rata. Lan iki bener malah kanggo AS lan Inggris.
TCP liwat kinerja udhara
TCP digawe kanggo kabel jaringan, yaiku, kanthi penekanan ing pranala sing bisa diprediksi. Nanging, nirkabel jaringan duwe ciri lan kangelan dhewe. Kaping pisanan, jaringan nirkabel gampang rusak amarga gangguan lan atenuasi sinyal. Contone, jaringan Wi-Fi sensitif marang gelombang mikro, bluetooth lan gelombang radio liyane. Jaringan seluler ngalami mundhut sinyal () amarga refleksi / panyerepan sinyal dening obyek lan bangunan, uga saka saka tetanggan . Iki nyebabake luwih penting (4-10 kaping) lan luwih maneka warna lan mundhut paket dibandhingake sambungan kabel.
Kanggo nglawan fluktuasi lan kerugian bandwidth, jaringan seluler biasane nggunakake buffer gedhe kanggo lalu lintas. Iki bisa nyebabake antrian sing akeh banget, tegese wektu tundha luwih suwe. Asring banget TCP nganggep antrian iki minangka sampah amarga wektu entek sing luwih dawa, mula TCP cenderung relay lan ngisi buffer. Masalah iki dikenal minangka (), lan iki banget Internet modern.
Pungkasan, kinerja jaringan seluler beda-beda miturut operator, wilayah, lan wektu. Ing Gambar 2, kita ngumpulake wektu tundha median lalu lintas HTTPS ing sel ing jarak 2 kilometer. Data sing diklumpukake kanggo rong operator seluler utama ing Delhi, India. Kaya sing sampeyan ngerteni, kinerja beda-beda gumantung saka sel menyang sel. Uga, produktivitas siji operator beda-beda saka produktivitas kaloro. Iki dipengaruhi dening faktor kayata pola entri jaringan sing njupuk wektu lan lokasi, mobilitas pangguna, uga infrastruktur jaringan sing nimbang kapadhetan menara lan rasio jinis jaringan (LTE, 3G, lsp.).
Gambar 2. Tundha nggunakake radius 2 km minangka conto. Delhi, India.
Uga, kinerja jaringan seluler beda-beda saka wektu. Gambar 3 nuduhake latensi median miturut dina minggu. Kita uga mirsani beda ing skala sing luwih cilik, sajrone sedina lan jam.
Figure 3. telat buntut bisa beda-beda Ngartekno antarane dina, nanging kanggo operator padha.
Kabeh ing ndhuwur nyebabake kinerja TCP ora efektif ing jaringan nirkabel. Nanging, sadurunge nggoleki alternatif kanggo TCP, kita pengin ngembangake pemahaman sing tepat babagan poin ing ngisor iki:
- Apa TCP dadi penyebab utama ing mburi latensi buntut ing aplikasi kita?
- Apa jaringan modern duwe wektu tundha (RTT) sing signifikan lan macem-macem?
- Apa impact saka RTT lan mundhut ing kinerja TCP?
Analisis Kinerja TCP
Kanggo mangerteni carane kita nganalisa kinerja TCP, ayo dipikir cepet carane TCP nransfer data saka pangirim menyang panrima. Kaping pisanan, pangirim nggawe sambungan TCP, nindakake telung arah : Pangirim ngirim paket SYN, ngenteni paket SYN-ACK saka panrima, banjur ngirim paket ACK. Pass kapindho lan katelu tambahan digunakake kanggo nggawe sambungan TCP. Panampa ngakoni panrimo saben paket (ACK) kanggo mesthekake pangiriman dipercaya.
Yen paket utawa ACK ilang, pangirim ngirim maneh sawise wektu entek (RTO, ). RTO diwilang dinamis adhedhasar macem-macem faktor, kayata wektu tundha RTT samesthine antarane pangirim lan panampa.
Gambar 4. Ijol-ijolan paket liwat TCP / TLS kalebu mekanisme transmisi ulang.
Kanggo nemtokake cara TCP ditindakake ing aplikasi kita, kita ngawasi paket TCP nggunakake kanggo minggu ing lalu lintas pertempuran teka saka server pinggiran Indian. Kita banjur nganalisa sambungan TCP nggunakake . Kajaba iku, kita nggawe aplikasi Android sing ngirim lalu lintas sing ditiru menyang server uji, niru lalu lintas nyata sabisa-bisa. Smartphone karo aplikasi iki disebarake kanggo sawetara karyawan, sing diklumpukake log liwat sawetara dina.
Asil saka loro eksperimen padha konsisten karo saben liyane. Kita weruh latency RTT dhuwur; nilai buntut meh 6 kaping luwih dhuwur tinimbang nilai median; rata-rata telat aritmetika luwih saka 1 detik. Akeh sambungan sing ilang, nyebabake TCP ngirim maneh 3,5% kabeh paket. Ing wilayah sing rame kayata bandara lan stasiun sepur, kita ngalami kerugian 7%. Asil kasebut nyebabake keraguan babagan kawicaksanan konvensional sing digunakake ing jaringan seluler Ngartekno nyuda losses ing tingkat transportasi. Ing ngisor iki asil tes saka aplikasi "simulator":
metrik jaringan
Nilai kasebut
RTT, milidetik [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT divergence, detik
Rata-rata ~ 1,2 s
Paket mundhut ing sambungan ora stabil
Rata-rata ~3.5% (7% ing wilayah sing kakehan beban)
Meh setengah saka sambungan iki wis paling siji mundhut paket, paling mau paket SYN lan SYN-ACK. Paling implementasine TCP nggunakake Nilai RTO 1 detik kanggo paket SYN, kang mundhak exponentially kanggo mundhut sakteruse. Wektu mbukak aplikasi bisa saya tambah amarga TCP butuh wektu luwih suwe kanggo nggawe sambungan.
Ing kasus paket data, nilai RTO sing dhuwur banget nyuda panggunaan jaringan sing migunani nalika ana kerugian sementara ing jaringan nirkabel. Kita nemokake manawa wektu transmisi ulang rata-rata kira-kira 1 detik kanthi wektu tundha buntut meh 30 detik. Latensi dhuwur ing tingkat TCP iki nyebabake wektu entek HTTPS lan panjaluk maneh, nambah latensi lan inefisiensi jaringan.
Nalika persentil kaping 75 saka RTT sing diukur watara 425 ms, persentil kaping 75 kanggo TCP meh 3 detik. Iki nuduhake yen mundhut nyebabake TCP njupuk 7-10 pass kanggo kasil ngirim data. Iki bisa dadi akibat saka pitungan RTO sing ora efisien, TCP ora bisa nanggapi kerugian kanthi cepet ing jendhela lan inefficiency saka algoritma kontrol rame, kang ora mbedakake antarane losses nirkabel lan losses amarga jaringan rame. Ing ngisor iki asil tes mundhut TCP:
Statistik mundhut paket TCP
Nilai
Persentase sambungan karo paling 1 mundhut paket
45%
Persentase sambungan karo losses sak persiyapan sambungan
30%
Persentase sambungan karo losses sak ijol-ijolan data
76%
Distribusi wektu tundha ing transmisi ulang, detik [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Distribusi jumlah transmisi ulang kanggo siji paket utawa segmen TCP
[1,3,6,7]
Aplikasi saka QUIC
Originally dikembangake dening Google, QUIC minangka protokol transportasi modern multi-threaded sing mlaku ing ndhuwur UDP. Saiki QUIC ing (kita wis nulis yen ana, kaya-kaya, rong versi QUIC, penasaran - kira-kira. penerjemah). Kaya sing ditampilake ing Gambar 5, QUIC diselehake ing HTTP / 3 (nyatane, HTTP / 2 ing ndhuwur QUIC yaiku HTTP / 3, sing saiki wis distandarisasi kanthi intensif). Iki ngganti sebagian lapisan HTTPS lan TCP kanthi nggunakake UDP kanggo mbentuk paket. QUIC mung ndhukung transfer data sing aman amarga TLS wis dibangun kanthi lengkap ing QUIC.
Gambar 5: QUIC mlaku ing HTTP / 3, ngganti TLS, sing sadurunge mlaku ing HTTP / 2.
Ing ngisor iki ana alasan sing nggawe kita yakin nggunakake QUIC kanggo amplifikasi TCP:
- 0-RTT panyiapan sambungan. QUIC ngidini nggunakake maneh wewenang saka sambungan sadurunge, ngurangi jumlah jabat tangan keamanan. Ing mangsa ngarep bakal ndhukung 0-RTT, nanging jabat tangan TCP telung arah isih dibutuhake.
- ngatasi pamblokiran HoL. HTTP/2 nggunakake siji sambungan TCP saben klien kanggo nambah kinerja, nanging iki bisa nyebabake pamblokiran HoL (head-of-line). QUIC nyederhanakake multiplexing lan ngirim panjalukan menyang aplikasi kanthi mandiri.
- kontrol kemacetan. QUIC manggon ing lapisan aplikasi, nggawe luwih gampang kanggo nganyari algoritma transportasi utama sing kontrol ngirim adhedhasar paramèter jaringan (nomer losses utawa RTT). Umume implementasi TCP nggunakake algoritma , sing ora optimal kanggo lalu lintas sing sensitif latensi. Algoritma sing bubar dikembangake kaya , luwih akurat model jaringan lan ngoptimalake latensi. QUIC ngidini sampeyan nggunakake BBR lan nganyari algoritma iki nalika digunakake. .
- replenishment saka losses. QUIC nelpon loro TLPs () sadurunge RTO micu - malah nalika losses banget ngelingke. Iki beda karo implementasi TCP. TLP ngirim ulang utamane paket pungkasan (utawa sing anyar, yen ana) kanggo micu isi ulang kanthi cepet. Nangani tundha buntut utamane migunani kanggo cara Uber ngoperasikake jaringan, yaiku kanggo transfer data sing cendhak, sporadis, lan sensitif latensi.
- ACK sing dioptimalake. Amarga saben paket duwe nomer urutan sing unik, ora ana masalah paket nalika lagi dikirim maneh. Paket ACK uga ngemot wektu kanggo ngolah paket lan ngasilake ACK ing sisih klien. Fitur kasebut njamin QUIC ngetung RTT kanthi luwih akurat. ACK ing QUIC ndhukung nganti 256 band , ngewangi pangirim dadi luwih tahan kanggo ngocok paket lan nggunakake luwih sithik bita sajrone proses kasebut. ACK selektif () ing TCP ora ngatasi masalah iki ing kabeh kasus.
- migrasi sambungan. Sambungan QUIC diidentifikasi dening ID 64-bit, dadi yen klien ngganti alamat IP, ID sambungan lawas bisa terus digunakake ing alamat IP anyar tanpa gangguan. Iki minangka praktik sing umum banget kanggo aplikasi seluler ing ngendi pangguna ngalih ing antarane Wi-Fi lan sambungan seluler.
Alternatif kanggo QUIC
Kita nimbang pendekatan alternatif kanggo ngrampungake masalah sadurunge milih QUIC.
Babagan pisanan sing kita coba yaiku masang TPC PoPs (Points of Presence) kanggo mungkasi sambungan TCP sing luwih cedhak karo pangguna. Ateges, PoPs mungkasi sambungan TCP karo piranti seluler sing luwih cedhak karo jaringan seluler lan proxy lalu lintas bali menyang infrastruktur asli. Kanthi mungkasi TCP luwih cedhak, kita bisa nyuda RTT lan mesthekake yen TCP luwih responsif marang lingkungan nirkabel sing dinamis. Nanging, eksperimen kita wis nuduhake yen sebagian besar RTT lan mundhut asale saka jaringan seluler lan panggunaan PoP ora menehi perbaikan kinerja sing signifikan.
Kita uga ndeleng tuning paramèter TCP. Nyiyapake tumpukan TCP ing server pinggiran heterogen kita angel amarga TCP duwe implementasi sing beda-beda ing macem-macem versi OS. Iku angel kanggo ngleksanakake iki lan nyoba konfigurasi jaringan beda. Konfigurasi TCP langsung ing piranti seluler ora bisa amarga ora ana ijin. Sing luwih penting, fitur kayata sambungan 0-RTT lan prediksi RTT sing luwih apik penting kanggo arsitektur protokol, mula ora mungkin entuk keuntungan sing signifikan kanthi nyetel TCP mung.
Pungkasan, kita ngevaluasi sawetara protokol basis UDP sing ngatasi masalah streaming video-kita pengin ndeleng apa protokol kasebut bakal mbantu ing kasus kita. Sayange, padha banget kurang ing akeh setelan keamanan, lan uga mbutuhake sambungan TCP tambahan kanggo metadata lan informasi kontrol.
Riset kita wis nuduhake yen QUIC mbok menawa mung protokol sing bisa mbantu masalah lalu lintas Internet, nalika njupuk keamanan lan kinerja.
Integrasi QUIC menyang platform
Kanggo kasil nglebokake QUIC lan ningkatake kinerja aplikasi ing lingkungan konektivitas sing kurang, kita ngganti tumpukan lawas (HTTP/2 liwat TLS/TCP) nganggo protokol QUIC. Kita nggunakake perpustakaan jaringan saka , sing ngemot asli, versi Google saka protokol - gQUIC. Implementasi iki uga terus ditingkatake kanggo ngetutake spesifikasi IETF paling anyar.
Kita pisanan nggabungake Cronet menyang aplikasi Android kanggo nambah dhukungan kanggo QUIC. Integrasi ditindakake kanthi cara sing bisa nyuda biaya migrasi. Tinimbang rampung ngganti tumpukan jaringan lawas sing digunakake perpustakaan , kita wis nggabungake Cronet ING kerangka API OkHttp. Kanthi nindakake integrasi kanthi cara iki, kita nyingkiri owah-owahan ing telpon jaringan (sing digunakake dening ) ing tingkat API.
Kaya pendekatan kanggo piranti Android, kita ngetrapake Cronet menyang aplikasi Uber ing iOS, nyegat lalu lintas HTTP saka jaringan. nggunakake . Abstraksi iki, diwenehake dening iOS Foundation, nangani data URL khusus protokol lan mesthekake yen kita bisa nggabungake Cronet menyang aplikasi iOS tanpa biaya migrasi sing signifikan.
Ngrampungake QUIC ing Google Cloud Balancers
Ing sisih mburi, completion QUIC diwenehake dening infrastruktur Google Cloud Load balancing, sing nggunakake header ing respon kanggo ndhukung QUIC. UmumΓ©, balancer nambah header alt-svc kanggo saben panjalukan HTTP, lan iki wis validates dhukungan QUIC kanggo domain. Nalika klien Cronet nampa respon HTTP nganggo header iki, nggunakake QUIC kanggo panjalukan HTTP sakteruse menyang domain kasebut. Sawise balancer ngrampungake QUIC, infrastruktur kita kanthi jelas ngirim tumindak iki liwat HTTP2/TCP menyang pusat data kita.
Kinerja: Asil
Kinerja output minangka alasan utama kanggo nggoleki protokol sing luwih apik. Kanggo miwiti, kita nggawe ngadeg karo kanggo mangerteni carane QUIC bakal tumindak ing profil jaringan beda. Kanggo nguji kinerja QUIC ing jaringan nyata, kita nindakake eksperimen nalika nyopir ing New Delhi nggunakake lalu lintas jaringan sing ditiru meh padha karo telpon HTTP ing aplikasi penumpang.
Eksperimen 1
Peralatan kanggo eksperimen:
- nyoba piranti Android nganggo tumpukan OkHttp lan Cronet kanggo mesthekake yen kita ngidini lalu lintas HTTPS liwat TCP lan QUIC;
- server emulasi basis Java sing ngirim jinis header HTTPS sing padha ing respon lan ngemot piranti klien kanggo nampa panjalukan saka wong-wong mau;
- proxy maya sing dumunung sacara fisik cedhak karo India kanggo mungkasi sambungan TCP lan QUIC. Nalika kanggo mandap TCP kita nggunakake proxy mbalikke ing , angel golek proxy reverse open source kanggo QUIC. Kita nggawe proxy mbalikke kanggo QUIC dhewe nggunakake tumpukan QUIC dhasar saka Chromium lan dadi kromium minangka open source.
Gambar 6. Suite test dalan TCP vs QUIC kasusun saka piranti Android kanthi OkHttp lan Cronet, proxy maya kanggo mungkasi sambungan, lan server emulasi.
Eksperimen 2
Nalika Google nggawe QUIC kasedhiya karo , kita nggunakake persediaan sing padha, nanging kanthi siji modifikasi: tinimbang NGINX, kita njupuk Google load balancers kanggo mungkasi sambungan TCP lan QUIC saka piranti, uga kanggo nuntun lalu lintas HTTPS menyang server emulasi. Balancer disebarake ing saindenging jagad, nanging gunakake server PoP sing paling cedhak karo piranti kasebut (amarga geolokasi).
Gambar 7. Ing eksperimen kapindho, kita pengin mbandhingake latency completion TCP lan QUIC: nggunakake Google Cloud lan nggunakake proxy awan kita.
AkibatΓ©, sawetara wahyu nunggu kita:
- mandap liwat PoP apik kinerja TCP. Wiwit balancers mungkasi sambungan TCP luwih cedhak karo pangguna lan dioptimalake banget, iki nyebabake RTT sing luwih murah, sing nambah kinerja TCP. Lan sanajan QUIC kurang kena pengaruh, nanging isih ngluwihi TCP babagan nyuda latensi buntut (dening 10-30 persen).
- buntut kena pengaruh . Sanajan proksi QUIC kita luwih adoh saka piranti (udakara 50 ms sing luwih dhuwur) tinimbang pengimbang beban Google, iki menehi kinerja sing padha - pangurangan latensi 15% tinimbang pengurangan persentil kaping 20 kanggo TCP 99%. Iki nuduhake yen transisi mil pungkasan minangka bottleneck ing jaringan.
Gambar 8: Asil saka rong eksperimen nuduhake yen QUIC luwih unggul tinimbang TCP.
lalu lintas pertempuran
Diilhami dening eksperimen, kita wis ngetrapake dhukungan QUIC ing aplikasi Android lan iOS. Kita nganakake tes A/B kanggo nemtokake pengaruh QUIC ing kutha-kutha sing dioperasikake Uber. UmumΓ©, kita weruh pangurangan sing signifikan ing wektu tundha buntut ing loro wilayah, operator telekomunikasi lan jinis jaringan.
Grafik ing ngisor iki nuduhake persentase dandan ing buntut (95 lan 99 persentil) miturut wilayah makro lan jinis jaringan sing beda - LTE, 3G, 2G.
Gambar 9. Ing tes perang, QUIC ngluwihi TCP ing babagan latensi.
Mung maju
Mungkin iki mung wiwitan - rilis QUIC menyang produksi wis nyedhiyakake kesempatan sing apik kanggo nambah kinerja aplikasi ing jaringan sing stabil lan ora stabil, yaiku:
Tambah jangkoan
Sawise nganalisa kinerja protokol ing lalu lintas nyata, kita weruh yen kira-kira 80% sesi kasil nggunakake QUIC kanggo Π²ΡΠ΅Ρ panjalukan, nalika 15% sesi nggunakake kombinasi QUIC lan TCP. Kita nganggep yen kombinasi kasebut amarga wektu entek perpustakaan Cronet bali menyang TCP, amarga ora bisa mbedakake antara gagal UDP nyata lan kahanan jaringan sing ora apik. Saiki kita nggoleki solusi kanggo masalah iki nalika kita ngupayakake implementasi QUIC sabanjure.
Optimasi QUIC
Lalu lintas saka aplikasi seluler sensitif latensi, nanging ora sensitif bandwidth. Uga, aplikasi kita utamane digunakake ing jaringan seluler. Adhedhasar eksperimen, latensi buntut isih dhuwur sanajan nggunakake proxy kanggo mungkasi TCP lan QUIC sing cedhak karo pangguna. Kita aktif nggoleki cara kanggo nambah manajemen kemacetan lan ningkatake efisiensi algoritma pemulihan kerugian QUIC.
Kanthi iki lan sawetara dandan liyane, kita rencana kanggo nambah pengalaman pangguna tanpa preduli saka jaringan lan wilayah, nggawe transportasi paket sing trep lan lancar luwih gampang diakses ing saindenging jagad.
Source: www.habr.com