QUIC protokolini tomosha qilish juda qiziq, shuning uchun biz bu haqda yozishni yaxshi ko'ramiz. Ammo agar QUIC haqidagi oldingi nashrlar ko'proq tarixiy (mahalliy tarix, agar xohlasangiz) tabiat va apparat bo'lsa, bugun biz boshqa turdagi tarjimani nashr etishdan mamnunmiz - biz 2019 yilda protokolning haqiqiy qo'llanilishi haqida gaplashamiz. Bundan tashqari, biz garaj deb ataladigan kichik infratuzilma haqida emas, balki deyarli butun dunyoda ishlaydigan Uber haqida gapiramiz. Kompaniya muhandislari QUIC-ni ishlab chiqarishda qo'llash to'g'risida qanday qarorga kelishgan, ular qanday sinovlarni o'tkazganliklari va uni ishlab chiqarishga chiqargandan so'ng nimani ko'rganlari - pastda.
Rasmlarni bosish mumkin. O'qishdan zavqlaning!
Uber global miqyosga ega, ya'ni 600 ta shahar mavjud bo'lib, ularning har birida dastur butunlay 4500 dan ortiq uyali aloqa operatorlarining simsiz Internetiga tayanadi. Foydalanuvchilar ilovaning nafaqat tez, balki real vaqtda bo‘lishini kutishadi – bunga erishish uchun Uber ilovasiga past kechikish va juda ishonchli ulanish kerak bo‘ladi. Afsuski, lekin stack dinamik va yo'qotishga moyil simsiz tarmoqlarda yaxshi ishlamaydi. Biz tushundikki, bu holatda past unumdorlik operatsion tizim yadrolarida TCP amalga oshirish bilan bevosita bog'liq.
Muammoni hal qilish uchun biz murojaat qildik , zamonaviy kanal multiplekslash protokoli, bu bizga transport protokolining ishlashi ustidan ko'proq nazorat qilish imkonini beradi. Hozirda ishchi guruh QUICni standartlashtiradi .
Keng ko'lamli sinovlardan so'ng, biz QUICni ilovamizga joriy qilish TCP ga nisbatan past kechikishlarga olib keladi degan xulosaga keldik. Haydovchi va yo'lovchi ilovalarida HTTPS trafigi uchun 10-30% oralig'ida pasayish kuzatildi. QUIC shuningdek, bizga foydalanuvchi paketlari ustidan oxirigacha nazorat qilish imkonini berdi.
Ushbu maqolada biz QUIC-ni qo'llab-quvvatlaydigan stek yordamida Uber ilovalari uchun TCP-ni optimallashtirish bo'yicha tajribamiz bilan o'rtoqlashamiz.
Eng yangi texnologiya: TCP
Bugungi kunda TCP Internetda HTTPS trafikini etkazib berish uchun eng ko'p ishlatiladigan transport protokoli hisoblanadi. TCP ishonchli bayt oqimini ta'minlaydi va shu bilan tarmoq tiqilib qolishi va havola qatlamining yo'qolishi bilan kurashadi. TCP ning HTTPS trafigi uchun keng qo'llanilishi birinchisining hamma joyda mavjudligi (deyarli har bir OT TCP ni o'z ichiga oladi), ko'pgina infratuzilmalarda mavjudligi (masalan, yuk balanslari, HTTPS proksi-serverlari va CDN) va mavjud bo'lgan tayyor funksionallik bilan bog'liq. deyarli aksariyat platformalar va tarmoqlarda.
Aksariyat foydalanuvchilar bizning ilovamizdan yo‘l-yo‘lakay foydalanishadi va TCP ning kechikishlari bizning real vaqt rejimidagi HTTPS trafigimiz talablariga yaqin emas edi. Oddiy qilib aytganda, butun dunyodagi foydalanuvchilar buni boshdan kechirishgan - 1-rasmda yirik shaharlardagi kechikishlar ko'rsatilgan:
1-rasm: Uberning asosiy shaharlarida quyruqning kechikishi har xil.
Hindiston va Braziliya tarmoqlaridagi kechikish AQSh va Buyuk Britaniyadagidan yuqori bo'lsa-da, dumli kechikish o'rtacha kechikishdan sezilarli darajada yuqori. Va bu hatto AQSh va Buyuk Britaniya uchun ham amal qiladi.
Havo orqali TCP ishlashi
TCP uchun yaratilgan simli tarmoqlar, ya'ni yuqori darajada prognoz qilinadigan havolalarga urg'u berilgan. Biroq, simsiz tarmoqlarning o'ziga xos xususiyatlari va qiyinchiliklari bor. Birinchidan, simsiz tarmoqlar shovqin va signalning zaiflashishi tufayli yo'qotishlarga moyil. Masalan, Wi-Fi tarmoqlari mikroto'lqinli pechlar, bluetooth va boshqa radio to'lqinlarga sezgir. Uyali tarmoqlar signal yo'qolishidan aziyat chekmoqda () signalni ob'ektlar va binolar tomonidan aks ettirish / yutilishi tufayli, shuningdek qo'shnidan . Bu yanada sezilarli (4-10 marta) va ko'proq xilma-xillikka olib keladi va simli ulanish bilan solishtirganda paket yo'qolishi.
O'tkazish qobiliyatining o'zgarishi va yo'qotishlariga qarshi kurashish uchun uyali tarmoqlar odatda trafik portlashlari uchun katta buferlardan foydalanadi. Bu ortiqcha navbatga olib kelishi mumkin, bu esa uzoqroq kechikishlarni anglatadi. Ko'pincha TCP bu navbatni cho'zilgan vaqt tugashi tufayli isrof sifatida ko'radi, shuning uchun TCP o'tishga intiladi va shu bilan buferni to'ldiradi. Bu muammo sifatida tanilgan (), va bu juda zamonaviy Internet.
Va nihoyat, uyali tarmoqning ishlashi operator, mintaqa va vaqtga qarab farq qiladi. 2-rasmda biz 2 kilometrlik diapazondagi hujayralar bo'ylab HTTPS trafikining o'rtacha kechikishlarini to'pladik. Hindistonning Dehli shahridagi ikkita yirik uyali aloqa operatorlari uchun maʼlumotlar toʻplangan. Ko'rib turganingizdek, unumdorlik hujayradan hujayraga farq qiladi. Shuningdek, bitta operatorning mahsuldorligi ikkinchisining mahsuldorligidan farq qiladi. Bunga vaqt va joylashuvni hisobga olgan holda tarmoqqa kirish sxemalari, foydalanuvchi harakatchanligi, shuningdek, minora zichligi va tarmoq turlarining nisbati (LTE, 3G va boshqalar) hisobga olingan tarmoq infratuzilmasi kabi omillar ta'sir ko'rsatadi.
Shakl 2. Misol sifatida 2 km radiusdan foydalangan holda kechikishlar. Dehli, Hindiston.
Bundan tashqari, uyali tarmoqlarning ishlashi vaqt o'tishi bilan farq qiladi. 3-rasmda haftaning kunlari bo'yicha o'rtacha kechikish ko'rsatilgan. Shuningdek, biz bir kun va soat ichida kichikroq miqyosda farqlarni kuzatdik.
Shakl 3. Quyruqdagi kechikishlar kunlar orasida sezilarli darajada farq qilishi mumkin, lekin bir xil operator uchun.
Yuqoridagilarning barchasi simsiz tarmoqlarda TCP ishlashining samarasiz bo'lishiga olib keladi. Biroq, TCP ga alternativalarni izlashdan oldin, biz quyidagi masalalar bo'yicha aniq tushunchani ishlab chiqmoqchi edik:
- TCP bizning ilovalarimizdagi kechikishlar ortidagi asosiy aybdormi?
- Zamonaviy tarmoqlarda sezilarli va xilma-xil aylanish kechikishlari (RTT) bormi?
- RTT va yo'qotishning TCP ishlashiga ta'siri qanday?
TCP ishlash tahlili
TCP ishlashini qanday tahlil qilganimizni tushunish uchun keling, TCP ma'lumotlarni jo'natuvchidan qabul qiluvchiga qanday o'tkazishini tezda ko'rib chiqaylik. Birinchidan, jo'natuvchi uch tomonlama amalga oshiruvchi TCP ulanishini o'rnatadi : Yuboruvchi SYN paketini yuboradi, qabul qiluvchidan SYN-ACK paketini kutadi, keyin ACK paketini yuboradi. Qo'shimcha ikkinchi va uchinchi o'tish TCP ulanishini o'rnatish uchun sarflanadi. Qabul qiluvchi ishonchli yetkazib berishni ta'minlash uchun har bir paketni (ACK) olganligini tasdiqlaydi.
Agar paket yoki ACK yo'qolsa, jo'natuvchi vaqt tugashidan keyin qayta uzatadi (RTO, ). RTO dinamik ravishda turli omillar, masalan, jo'natuvchi va qabul qiluvchi o'rtasidagi kutilgan RTT kechikishi asosida hisoblanadi.
4-rasm. TCP/TLS orqali paket almashinuvi qayta uzatish mexanizmini o'z ichiga oladi.
Ilovalarimizda TCP qanday ishlashini aniqlash uchun biz TCP paketlarini nazorat qildik bir hafta davomida Hindiston chekka serverlaridan keladigan jangovar trafik bo'yicha. Keyin biz TCP ulanishlarini tahlil qildik . Bundan tashqari, biz Android ilovasini yaratdik, u taqlid qilingan trafikni test serveriga yuboradi va imkon qadar real trafikni taqlid qiladi. Ushbu ilovaga ega smartfonlar bir necha kun davomida jurnallarni to'plagan bir nechta xodimlarga tarqatildi.
Ikkala tajriba natijalari bir-biriga mos keldi. Biz yuqori RTT kechikishlarini ko'rdik; quyruq qiymatlari o'rtacha qiymatdan deyarli 6 baravar yuqori edi; kechikishlarning arifmetik o'rtacha qiymati 1 sekunddan ortiq. Ko'pgina ulanishlar yo'qolgan, bu esa TCP barcha paketlarning 3,5 foizini qayta uzatishiga sabab bo'lgan. Aeroportlar va vokzallar kabi tirband joylarda biz 7% yo'qotishlarni ko'rdik. Ushbu natijalar uyali aloqa tarmoqlarida ishlatiladigan an'anaviy donolikka shubha tug'diradi transport darajasida yo'qotishlarni sezilarli darajada kamaytirish. Quyida “simulyator” ilovasining test natijalari keltirilgan:
Tarmoq ko'rsatkichlari
Qadriyatlar
RTT, millisekundlar [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT farqi, soniya
O'rtacha ~1,2 s
Barqaror ulanishlarda paket yo'qolishi
O'rtacha ~3.5% (haddan tashqari yuklangan joylarda 7%)
Ushbu ulanishlarning deyarli yarmida kamida bitta paket yo'qolgan, ularning aksariyati SYN va SYN-ACK paketlari. Ko'pgina TCP ilovalari SYN paketlari uchun 1 soniya RTO qiymatidan foydalanadi, bu keyingi yo'qotishlar uchun eksponent ravishda oshadi. TCP ulanishlarni o'rnatish uchun ko'proq vaqt talab qilganligi sababli ilovalarni yuklash vaqtlari oshishi mumkin.
Ma'lumotlar paketlari holatida, yuqori RTO qiymatlari simsiz tarmoqlarda vaqtinchalik yo'qotishlar mavjud bo'lganda tarmoqdan foydali foydalanishni sezilarli darajada kamaytiradi. Qayta uzatishning o'rtacha vaqti taxminan 1 soniyani tashkil etadi, bu esa deyarli 30 soniyani tashkil qiladi. TCP darajasidagi ushbu yuqori kechikishlar HTTPS-ning kutish vaqti va qayta so'rovlarini keltirib chiqardi, bu esa tarmoqning kechikishi va samarasizligini yanada oshirdi.
O'lchangan RTT ning 75-persentili 425 ms atrofida bo'lsa, TCP uchun 75-persentil deyarli 3 soniya edi. Bu shuni ko'rsatadiki, yo'qotish TCP ma'lumotlarni muvaffaqiyatli uzatish uchun 7-10 o'tishga olib keldi. Bu samarasiz RTO hisobining natijasi bo'lishi mumkin, TCP ning yo'qotishlarga tezda javob bera olmasligi oynada va tarmoq tiqilib qolishi sababli simsiz yo'qotishlar va yo'qotishlarni ajrata olmaydigan tiqilib qolishni nazorat qilish algoritmining samarasizligi. Quyida TCP yo'qotish testlarining natijalari keltirilgan:
TCP paketlarini yo'qotish statistikasi
ma'no
Kamida 1 paket yo'qolgan ulanishlar foizi
45%
Ulanishni o'rnatish vaqtida yo'qotishlar bilan ulanishlar foizi
30%
Ma'lumotlar almashinuvi paytida yo'qotishlar bilan bog'lanishlar foizi
76%
Qayta uzatishdagi kechikishlarning taqsimlanishi, soniyalar [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Bitta paket yoki TCP segmenti uchun qayta uzatishlar sonini taqsimlash
[1,3,6,7]
QUIC dasturini qo'llash
Dastlab Google tomonidan ishlab chiqilgan QUIC ko'p tarmoqli zamonaviy transport protokoli bo'lib, UDP tepasida ishlaydi. Hozirda QUIC mavjud (biz allaqachon yozgan edik, QUIC ning ikkita versiyasi bor, qiziq - taxminan. tarjimon). 5-rasmda ko'rsatilganidek, QUIC HTTP/3 ostida joylashgan (aslida QUIC ning tepasida HTTP/2 HTTP/3 bo'lib, hozir intensiv ravishda standartlashtirilmoqda). U paketlarni shakllantirish uchun UDP yordamida HTTPS va TCP qatlamlarini qisman almashtiradi. QUIC faqat xavfsiz ma'lumotlarni uzatishni qo'llab-quvvatlaydi, chunki TLS QUIC ichiga to'liq o'rnatilgan.
5-rasm: QUIC HTTP/3 ostida ishlaydi, ilgari HTTP/2 ostida ishlagan TLS o'rnini bosadi.
Quyida bizni TCP kuchaytirilishi uchun QUIC dan foydalanishga ishontirgan sabablar keltirilgan:
- 0-RTT ulanishini o'rnatish. QUIC oldingi ulanishlardagi avtorizatsiyadan qayta foydalanishga imkon beradi, bu esa xavfsizlik bilan muloqot qilish sonini kamaytiradi. Kelajakda 0-RTT ni qo'llab-quvvatlaydi, lekin uch tomonlama TCP qo'l siqish hali ham talab qilinadi.
- HoL blokirovkasini engish. HTTP/2 ish faoliyatini yaxshilash uchun har bir mijoz uchun bitta TCP ulanishidan foydalanadi, ammo bu HoL (yo'nalish boshi) bloklanishiga olib kelishi mumkin. QUIC multiplekslashni soddalashtiradi va so'rovlarni dasturga mustaqil ravishda yetkazib beradi.
- tirbandlikni nazorat qilish. QUIC dastur sathida joylashgan bo'lib, tarmoq parametrlari (yo'qotishlar soni yoki RTT) asosida jo'natishni boshqaradigan asosiy transport algoritmini yangilashni osonlashtiradi. Ko'pgina TCP dasturlari algoritmdan foydalanadi , bu kechikishga sezgir trafik uchun maqbul emas. kabi yaqinda ishlab chiqilgan algoritmlar , tarmoqni aniqroq modellash va kechikishni optimallashtirish. QUIC sizga BBR dan foydalanish va ushbu algoritmni ishlatilganidek yangilash imkonini beradi. .
- yo'qotishlarni to'ldirish. QUIC ikkita TLPni chaqiradi () RTO ishga tushirilgunga qadar - hatto yo'qotishlar juda sezilarli bo'lsa ham. Bu TCP ilovalaridan farq qiladi. TLP tez to'ldirishni boshlash uchun asosan oxirgi paketni (yoki agar mavjud bo'lsa, yangisini) qayta uzatadi. Quyruqdagi kechikishlarni boshqarish, ayniqsa, Uber tarmog'ini boshqarish usuli uchun, xususan, qisqa, vaqti-vaqti bilan va kechikishga sezgir ma'lumotlarni uzatish uchun foydalidir.
- optimallashtirilgan ACK. Har bir paket noyob tartib raqamiga ega bo'lganligi sababli, hech qanday muammo yo'q paketlar qayta uzatilganda. ACK paketlarida paketni qayta ishlash va mijoz tomonida ACK yaratish uchun vaqt ham mavjud. Bu xususiyatlar QUIC RTT ni aniqroq hisoblashini ta'minlaydi. QUIC-dagi ACK 256 tagacha diapazonni qo'llab-quvvatlaydi , jo‘natuvchiga paketlarni aralashtirishga chidamliroq bo‘lishiga va jarayonda kamroq baytdan foydalanishga yordam beradi. Tanlangan ACK () TCP da barcha holatlarda bu muammoni hal qilmaydi.
- ulanish migratsiyasi. QUIC ulanishlari 64 bitli identifikator bilan aniqlanadi, shuning uchun agar mijoz IP manzillarini o'zgartirsa, eski ulanish identifikatori yangi IP manzilida uzilishlarsiz foydalanishda davom etishi mumkin. Bu foydalanuvchi Wi-Fi va uyali ulanishlar o'rtasida almashinadigan mobil ilovalar uchun juda keng tarqalgan amaliyotdir.
QUICga muqobillar
QUIC ni tanlashdan oldin muammoni hal qilishning muqobil yondashuvlarini ko'rib chiqdik.
Biz sinab ko'rgan birinchi narsa, TCP ulanishlarini foydalanuvchilarga yaqinroq to'xtatish uchun TPC PoPs (Mavjudlik nuqtalari) ni o'rnatish edi. Aslida, PoPlar uyali tarmoqqa yaqinroq bo'lgan mobil qurilma bilan TCP ulanishini to'xtatadi va trafikni asl infratuzilmaga proksi-server orqali qaytaradi. TCP-ni yaqinroq tugatish orqali biz RTT-ni kamaytirishimiz va TCP dinamik simsiz muhitga ko'proq javob berishini ta'minlashimiz mumkin. Biroq, bizning tajribalarimiz shuni ko'rsatdiki, RTT va yo'qotishlarning aksariyati uyali tarmoqlardan kelib chiqadi va PoP-lardan foydalanish unumdorlikni sezilarli darajada yaxshilamaydi.
Shuningdek, biz TCP parametrlarini sozlashni ko'rib chiqdik. Bizning heterojen chekka serverlarimizda TCP to'plamini o'rnatish qiyin edi, chunki TCP turli xil operatsion tizim versiyalarida turli xil ilovalarga ega. Buni amalga oshirish va turli tarmoq konfiguratsiyalarini sinab ko'rish qiyin edi. TCP-ni to'g'ridan-to'g'ri mobil qurilmalarda sozlash ruxsat yo'qligi sababli mumkin emas edi. Eng muhimi, 0-RTT ulanishlari va takomillashtirilgan RTT prognozi kabi xususiyatlar protokol arxitekturasi uchun juda muhim va shuning uchun faqat TCP ni sozlash orqali sezilarli foyda olish mumkin emas.
Va nihoyat, biz video oqimidagi muammolarni bartaraf etadigan bir nechta UDP-ga asoslangan protokollarni baholadik - biz ushbu protokollar bizning holatlarimizda yordam beradimi yoki yo'qligini bilishni xohladik. Afsuski, ular ko'pgina xavfsizlik sozlamalarida juda kam edi va metadata va boshqaruv ma'lumotlari uchun qo'shimcha TCP ulanishini talab qildi.
Bizning tadqiqotimiz shuni ko'rsatdiki, QUIC xavfsizlik va ishlash samaradorligini hisobga olgan holda Internet-trafik muammosini hal qilishda yordam beradigan yagona protokoldir.
QUIC ning platformaga integratsiyasi
QUIC-ni muvaffaqiyatli o'rnatish va yomon ulanish muhitlarida dastur ish faoliyatini yaxshilash uchun biz eski stekni (TLS/TCP orqali HTTP/2) QUIC protokoli bilan almashtirdik. Biz tarmoq kutubxonasidan foydalandik dan , unda protokolning asl Google versiyasi mavjud - gQUIC. Ushbu dastur, shuningdek, so'nggi IETF spetsifikatsiyasiga rioya qilish uchun doimiy ravishda takomillashtirilmoqda.
Biz QUIC-ni qo'llab-quvvatlash uchun birinchi navbatda Cronet-ni Android ilovalarimizga qo'shdik. Integratsiya migratsiya xarajatlarini imkon qadar kamaytiradigan tarzda amalga oshirildi. Kutubxonadan foydalangan eski tarmoq to'plamini to'liq almashtirish o'rniga , biz Cronet-ni OkHttp API ramkasi ostida birlashtirdik. Integratsiyani shu tarzda amalga oshirib, biz tarmoq qo'ng'iroqlaridagi o'zgarishlardan qochdik (ular tomonidan foydalaniladi ) API darajasida.
Android qurilmalari uchun yondashuvga o'xshab, biz Cronet-ni iOS-da Uber ilovalariga kiritdik va tarmoqdan HTTP-trafikni ushlab turdik. foydalanish . iOS Foundation tomonidan taqdim etilgan ushbu abstraktsiya protokolga xos URL ma'lumotlarini boshqaradi va biz Cronet-ni iOS ilovalarimizga katta migratsiya xarajatlarisiz integratsiya qilishimizni ta'minlaydi.
Google Cloud Balancers-da QUIC to'ldirilmoqda
Orqa tomonda, QUIC yakunlanishi Google Cloud Load balanslash infratuzilmasi tomonidan ta'minlanadi. QUIC-ni qo'llab-quvvatlash uchun javoblardagi sarlavhalar. Umuman olganda, balanslashtiruvchi har bir HTTP so'roviga alt-svc sarlavhasini qo'shadi va bu allaqachon domen uchun QUIC qo'llab-quvvatlashini tasdiqlaydi. Cronet mijozi ushbu sarlavha bilan HTTP javobini olganida, u ushbu domenga keyingi HTTP so'rovlari uchun QUIC-dan foydalanadi. Balanslashtiruvchi QUICni tugatgandan so'ng, bizning infratuzilmamiz ushbu amalni HTTP2/TCP orqali ma'lumotlar markazlarimizga aniq yuboradi.
Ishlash: Natijalar
Chiqish samaradorligi bizning yaxshiroq protokolni izlashimizning asosiy sababidir. Boshlash uchun biz stend yaratdik QUIC turli tarmoq profillarida qanday harakat qilishini bilish uchun. QUIC-ning real tarmoqlarda ishlashini sinab ko'rish uchun biz Nyu-Dehli bo'ylab harakatlanayotganda yo'lovchi ilovasidagi HTTP qo'ng'iroqlariga juda o'xshash taqlid qilingan tarmoq trafigidan foydalangan holda tajribalar o'tkazdik.
Tajriba 1
Tajriba uchun jihozlar:
- mos ravishda TCP va QUIC orqali HTTPS trafigiga ruxsat berishimizga ishonch hosil qilish uchun Android qurilmalarini OkHttp va Cronet steklari bilan sinab ko'ring;
- javoblarda bir xil turdagi HTTPS sarlavhalarini yuboradigan va ulardan so'rovlarni qabul qilish uchun mijoz qurilmalarini yuklaydigan Java-ga asoslangan emulyatsiya serveri;
- TCP va QUIC ulanishlarini tugatish uchun jismoniy jihatdan Hindistonga yaqin joylashgan bulutli proksi-serverlar. TCP-ni tugatish uchun biz teskari proksi-serverdan foydalandik , QUIC uchun ochiq manbali teskari proksi-serverni topish qiyin edi. Biz Chromium va.ning asosiy QUIC stekidan foydalanib, QUIC uchun teskari proksi-serverni yaratdik uni ochiq manba sifatida xromga kiriting.
Shakl 6. TCP va QUIC yo'l sinovlari to'plami OkHttp va Cronet bilan Android qurilmalari, ulanishlarni tugatish uchun bulutli proksi-serverlar va emulyatsiya serveridan iborat edi.
Tajriba 2
Qachon Google QUIC bilan foydalanish mumkin , biz bir xil inventardan foydalandik, lekin bitta modifikatsiya bilan: NGINX o'rniga biz qurilmalardan TCP va QUIC ulanishlarini to'xtatish, shuningdek, HTTPS trafikini emulyatsiya serveriga yo'naltirish uchun Google yuk balanslagichlarini oldik. Balansatorlar butun dunyo bo'ylab tarqatiladi, lekin qurilmaga eng yaqin PoP serveridan foydalaning (geolokatsiya tufayli).
Shakl 7. Ikkinchi tajribada biz TCP va QUIC ning tugallanish kechikishini solishtirmoqchi edik: Google Cloud-dan foydalanish va bulutli proksi-serverimizdan foydalanish.
Natijada, bizni bir nechta vahiylar kutmoqda:
- PoP orqali tugatish TCP unumdorligini oshirdi. Balanslashtirgichlar TCP ulanishlarini foydalanuvchilarga yaqinroq tugatganligi va yuqori darajada optimallashtirilganligi sababli, bu TCP ish faoliyatini yaxshilaydigan past RTT ga olib keladi. Va QUIC kamroq ta'sirlangan bo'lsa-da, u hali ham quyruq kechikishini (10-30 foizga) kamaytirish bo'yicha TCP dan ustun keldi.
- dumlar ta'sir qiladi . Garchi QUIC proksi-serverimiz qurilmalardan uzoqroqda bo'lsa ham (taxminan 50 ms yuqori kechikish) Google yuk balanslagichlariga qaraganda, u shunga o'xshash samaradorlikni ta'minladi - TCP uchun 15 foizli proksi-server 20 foizga, kechikish 99 foizga kamaygan. Bu shuni ko'rsatadiki, oxirgi milya o'tish tarmoqdagi darboğazdir.
Shakl 8: Ikki tajriba natijalari QUIC TCP dan sezilarli darajada ustun ekanligini ko'rsatadi.
Trafikga qarshi kurash
Tajribadan ilhomlanib, biz Android va iOS ilovalarimizda QUIC qo'llab-quvvatlashini joriy qildik. Uber ishlayotgan shaharlarda QUIC taʼsirini aniqlash uchun A/B testini oʻtkazdik. Umuman olganda, biz ikkala mintaqada, aloqa operatorlari va tarmoq turi bo'yicha kechikishlarning sezilarli darajada kamayganini ko'rdik.
Quyidagi grafiklarda makromintaqa va turli xil tarmoq turlari - LTE, 95G, 99G bo'yicha dumlarning (3 va 2 foizli) foiz yaxshilanishi ko'rsatilgan.
Shakl 9. Jang sinovlarida QUIC kechikish bo'yicha TCP dan oshib ketdi.
Faqat oldinga
Ehtimol, bu hali boshlanishi - QUIC-ning ishlab chiqarishga chiqarilishi barqaror va beqaror tarmoqlarda dastur ish faoliyatini yaxshilash uchun ajoyib imkoniyatlarni taqdim etdi, xususan:
Qoplamaning ortishi
Haqiqiy trafik bo'yicha protokolning ishlashini tahlil qilib, biz seanslarning taxminan 80% QUIC-dan muvaffaqiyatli foydalanganligini ko'rdik. всех so'rovlar, seanslarning 15% QUIC va TCP kombinatsiyasidan foydalangan. Bu kombinatsiya Cronet kutubxonasining TCP ga qaytishi bilan bog'liq deb taxmin qilamiz, chunki u haqiqiy UDP nosozliklari va yomon tarmoq sharoitlarini ajrata olmaydi. Biz hozirda ushbu muammoning yechimini izlayapmiz, chunki biz QUICni keyingi joriy etish ustida ishlayapmiz.
QUIC optimallashtirish
Mobil ilovalardan kelgan trafik kechikishga sezgir, lekin tarmoqli kengligi sezgir emas. Shuningdek, bizning ilovalarimiz asosan uyali tarmoqlarda qo'llaniladi. Tajribalarga asoslanib, foydalanuvchilarga yaqin bo'lgan TCP va QUIC protokollarini to'xtatish uchun proksi-serverdan foydalanilgan bo'lsa ham, kechikishlar hali ham yuqori. Biz tirbandlikni boshqarishni yaxshilash va QUIC yo'qotishlarni tiklash algoritmlari samaradorligini oshirish yo'llarini faol ravishda qidirmoqdamiz.
Ushbu va boshqa bir qator yaxshilanishlar orqali biz tarmoq va mintaqadan qat'iy nazar foydalanuvchi tajribasini yaxshilashni rejalashtirmoqdamiz, bu esa butun dunyo bo'ylab qulay va uzluksiz paketli tashishni yanada qulayroq qilish imkonini beradi.
Manba: www.habr.com