QUIC протокол нь үзэхэд маш сонирхолтой байдаг тул бид энэ тухай бичих дуртай. Гэхдээ QUIC-ийн тухай өмнөх нийтлэлүүд нь түүхэн (хэрэв та дуртай бол) мөн чанар, техник хангамжтай байсан бол өнөөдөр бид өөр төрлийн орчуулгыг нийтлэхдээ баяртай байна - бид 2019 онд протоколын бодит хэрэглээний талаар ярих болно. Түүгээр ч барахгүй, бид гараж гэж нэрлэгддэг жижиг дэд бүтцийн тухай биш, харин бараг бүх дэлхий даяар үйл ажиллагаа явуулдаг Uber-ийн тухай ярьж байна. Компанийн инженерүүд QUIC-ийг үйлдвэрлэлд ашиглах шийдвэрт хэрхэн хүрсэн, туршилтыг хэрхэн хийж, үйлдвэрлэлд нэвтрүүлсний дараа юу олж харсан бэ гэдэг нь огтхон ч доогуур үзүүлэлт юм.
Зургууд нь товших боломжтой. Уншихыг сайхан өнгөрүүлээрэй!
Uber нь дэлхийн хэмжээнд, тухайлбал 600 хотод байрладаг бөгөөд тус програм нь 4500 гаруй үүрэн холбооны операторын утасгүй интернетэд бүрэн тулгуурладаг. Хэрэглэгчид уг аппликейшн нь зөвхөн хурдан биш, бодит цаг хугацаанд байх болно гэж найдаж байна - үүнд хүрэхийн тулд Uber програмд бага хоцролт, маш найдвартай холболт хэрэгтэй. Харамсалтай нь, гэхдээ стек динамик, алдагдалд өртөмтгий утасгүй сүлжээнд сайн ажилладаггүй. Энэ тохиолдолд бага гүйцэтгэл нь үйлдлийн системийн цөм дэх TCP хэрэгжилттэй шууд холбоотой гэдгийг бид ойлгосон.
Асуудлыг шийдэхийн тулд бид өргөдөл гаргасан , орчин үеийн сувгийн мультиплекс протокол нь тээвэрлэлтийн протоколын гүйцэтгэлийг илүү хянах боломжийг бидэнд олгодог. Одоогоор ажлын хэсэг ажиллаж байна QUIC-г стандартчилдаг .
Өргөн хүрээг хамарсан туршилтын дараа бид QUIC-ийг хэрэглээнд нэвтрүүлэх нь TCP-тэй харьцуулахад сүүлний хоцрогдол багатай байх болно гэж бид дүгнэсэн. Жолооч болон зорчигчийн хэрэглээний программ дахь HTTPS урсгалын хувьд 10-30%-иар буурсныг бид ажигласан. Мөн QUIC нь бидэнд хэрэглэгчийн багцуудыг эцэслэн хянах боломжийг олгосон.
Энэ нийтлэлд бид QUIC-ийг дэмждэг стек ашиглан Uber програмуудад зориулсан TCP-ийг оновчтой болгох туршлагаа хуваалцах болно.
Хамгийн сүүлийн үеийн технологи: TCP
Өнөөдөр TCP нь HTTPS урсгалыг интернетэд дамжуулахад хамгийн их ашиглагддаг тээврийн протокол юм. TCP нь байтуудын найдвартай урсгалыг хангадаг бөгөөд ингэснээр сүлжээний түгжрэл, холбоосын давхаргын алдагдлыг даван туулдаг. HTTPS траффикт TCP-ийг өргөнөөр ашиглах болсон нь эхнийх нь хаа сайгүй байдаг (бараг бүх үйлдлийн систем нь TCP-ийг агуулдаг), ихэнх дэд бүтцэд (ачаалал тэнцвэржүүлэгч, HTTPS прокси болон CDN гэх мэт) ашиглах боломжтой, бэлэн байгаа бэлэн ажиллагаатай холбоотой юм. бараг ихэнх платформ болон сүлжээнд.
Ихэнх хэрэглэгчид манай програмыг явж байхдаа ашигладаг бөгөөд TCP-ийн хоцрогдол нь бидний бодит цагийн HTTPS траффикийн шаардлагад ойр байсангүй. Энгийнээр хэлбэл, дэлхийн бүх хэрэглэгчид үүнийг мэдэрсэн - Зураг 1-д томоохон хотуудын сааталыг харуулав:
Зураг 1: Uber-ийн гол хотуудад сүүлний саатал харилцан адилгүй байна.
Хэдийгээр Энэтхэг, Бразилийн сүлжээнүүдийн хоцролт нь АНУ, Их Британитай харьцуулахад өндөр байсан ч сүүлний хоцролт нь дунджаас хамаагүй өндөр байна. Энэ нь АНУ, Их Британийн хувьд ч үнэн юм.
Агаарын TCP гүйцэтгэл
TCP-д зориулагдсан утастай сүлжээнүүд, өөрөөр хэлбэл маш их урьдчилан таамаглах боломжтой холбоосыг онцолсон. Гэсэн хэдий ч, утасгүй сүлжээнүүд нь өөрийн онцлог, бэрхшээлтэй байдаг. Нэгдүгээрт, утасгүй сүлжээ нь хөндлөнгийн оролцоо, дохионы сулралын улмаас алдагдалд өртөмтгий байдаг. Жишээлбэл, Wi-Fi сүлжээ нь богино долгион, bluetooth болон бусад радио долгионд мэдрэмтгий байдаг. Үүрэн сүлжээнүүд дохионы алдагдалд ордог () объект, барилга байгууламжийн дохионы тусгал/шингээлтийн улмаас, түүнчлэн хөршөөс . Энэ нь илүү чухал ач холбогдолтой (4-10 дахин) болон илүү олон янз байдалд хүргэдэг утастай холболттой харьцуулахад багцын алдагдал.
Дамжуулах зурвасын өргөний хэлбэлзэл, алдагдалтай тэмцэхийн тулд үүрэн сүлжээнүүд ихэвчлэн замын хөдөлгөөний тасалдалд том буфер ашигладаг. Энэ нь хэт их дараалал үүсгэхэд хүргэдэг бөгөөд энэ нь илүү удаан саатдаг гэсэн үг юм. Ихэнхдээ TCP нь энэ дарааллыг уртасгасан хугацаанаас болж дэмий зүйл гэж үздэг тул TCP нь дамжуулж, улмаар буферийг дүүргэх хандлагатай байдаг. Энэ асуудал гэж нэрлэгддэг (), мөн энэ нь маш их юм орчин үеийн интернет.
Эцэст нь, үүрэн холбооны сүлжээний гүйцэтгэл нь оператор, бүс нутаг, цаг хугацаанаас хамаарч өөр өөр байдаг. Зураг 2-т бид 2 километрийн зайд байгаа нүднүүдийн HTTPS урсгалын дундаж саатлыг цуглуулсан. Энэтхэгийн Дели хотын үүрэн холбооны хоёр томоохон операторын мэдээллийг цуглуулсан. Таны харж байгаагаар гүйцэтгэл нь эс бүрт өөр өөр байдаг. Мөн нэг операторын бүтээмж хоёр дахь операторын бүтээмжээс ялгаатай. Үүнд цаг хугацаа, байршлыг харгалзан сүлжээний нэвтрэх загвар, хэрэглэгчийн хөдөлгөөн, түүнчлэн цамхагийн нягтрал, сүлжээний төрлүүдийн харьцаа (LTE, 3G гэх мэт) харгалзан сүлжээний дэд бүтэц зэрэг хүчин зүйлүүд нөлөөлдөг.
Зураг 2. 2 км радиусыг жишээ болгон ашигласан саатал. Дели, Энэтхэг.
Мөн үүрэн сүлжээний гүйцэтгэл цаг хугацааны явцад харилцан адилгүй байдаг. Зураг 3-т долоо хоногийн өдрүүдээр дундаж хоцролтыг харуулав. Бид бас нэг өдөр, цагийн дотор ялгааг бага хэмжээгээр ажигласан.
Зураг 3. Сүүлний саатал нь өдрийн хооронд ихээхэн ялгаатай байж болох ч нэг операторын хувьд.
Дээр дурдсан бүх зүйл нь утасгүй сүлжээнд TCP гүйцэтгэлийг үр дүнгүй болгоход хүргэдэг. Гэсэн хэдий ч, TCP-ийн өөр хувилбаруудыг хайхаасаа өмнө бид дараах зүйлсийн талаар нарийн ойлголтыг хөгжүүлэхийг хүссэн.
- TCP нь манай программуудын хоцрогдлын гол буруутан мөн үү?
- Орчин үеийн сүлжээнүүд хоёр талдаа ихээхэн хэмжээний саатал (RTT) байдаг уу?
- RTT болон алдагдал нь TCP гүйцэтгэлд ямар нөлөө үзүүлдэг вэ?
TCP гүйцэтгэлийн шинжилгээ
TCP-ийн гүйцэтгэлд хэрхэн дүн шинжилгээ хийснийг ойлгохын тулд TCP нь илгээгчээс хүлээн авагч руу өгөгдлийг хэрхэн дамжуулж байгааг харцгаая. Эхлээд илгээгч нь TCP холболтыг бий болгож, гурван талын үйлдлийг гүйцэтгэдэг : Илгээгч нь SYN пакет илгээж, хүлээн авагчаас SYN-ACK багцыг хүлээж, дараа нь ACK пакет илгээдэг. TCP холболтыг бий болгоход нэмэлт хоёр ба гурав дахь дамжуулалт зарцуулагдана. Хүлээн авагч нь найдвартай хүргэлтийг хангахын тулд багц бүрийг (ACK) хүлээн авснаа хүлээн зөвшөөрдөг.
Хэрэв пакет эсвэл ACK алдагдсан бол илгээгч хугацаа дууссаны дараа дахин дамжуулна (RTO, ). RTO-г илгээгч болон хүлээн авагчийн хооронд хүлээгдэж буй RTT саатал гэх мэт янз бүрийн хүчин зүйл дээр үндэслэн динамикаар тооцдог.
Зураг 4. TCP/TLS-ээр пакет солилцох нь дахин дамжуулах механизмыг агуулдаг.
Манай програмуудад TCP хэрхэн ажилладгийг тодорхойлохын тулд бид TCP пакетуудыг ашиглан хяналт тавьсан долоо хоногийн турш Энэтхэгийн захын серверүүдээс ирж буй байлдааны хөдөлгөөнд. Дараа нь бид TCP холболтуудыг ашиглан дүн шинжилгээ хийсэн . Нэмж дурдахад бид жинхэнэ траффикийг аль болох дуурайлган туршилтын сервер рүү дуурайлган траффик илгээдэг Android програмыг бүтээсэн. Энэхүү программтай ухаалаг гар утсыг хэд хэдэн ажилтанд тарааж, тэд хэд хоногийн турш бүртгэл цуглуулсан.
Хоёр туршилтын үр дүн бие биетэйгээ нийцэж байсан. Бид өндөр RTT хоцролтыг харсан; сүүлний утга нь дундаж утгаас бараг 6 дахин их байсан; саатлын арифметик дундаж нь 1 секундээс их байна. Олон холболтууд алдагдалтай байсан тул TCP нь нийт пакетуудын 3,5%-ийг дахин дамжуулахад хүргэсэн. Нисэх буудал, галт тэрэгний буудал гэх мэт түгжрэл ихтэй газруудад бид 7%-ийн алдагдал хүлээсэн. Эдгээр үр дүн нь үүрэн холбооны сүлжээнд ашигладаг уламжлалт мэргэн ухаанд эргэлзээ төрүүлж байна тээврийн түвшинд алдагдлыг мэдэгдэхүйц бууруулах. "Симулятор" програмын туршилтын үр дүнг доор харуулав.
Сүлжээний хэмжүүр
Утга нь
RTT, миллисекунд [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT зөрүү, секунд
Дунджаар ~1,2 сек
Тогтворгүй холболтууд дээр пакет алдагдах
Дунджаар ~3.5% (хэт ачаалалтай газарт 7%)
Эдгээр холболтын бараг тал хувь нь дор хаяж нэг пакет алдагдсан ба ихэнх нь SYN болон SYN-ACK пакетууд байсан. Ихэнх TCP хэрэгжүүлэлтүүд нь SYN пакетуудын хувьд 1 секундын RTO утгыг ашигладаг бөгөөд энэ нь дараагийн алдагдлын хувьд экспоненциалаар нэмэгддэг. TCP холболт хийхэд удаан хугацаа шаардагддаг тул програмыг ачаалах хугацаа нэмэгдэж болзошгүй.
Өгөгдлийн пакетуудын хувьд өндөр RTO утгууд нь утасгүй сүлжээнд түр зуурын алдагдал байгаа тохиолдолд сүлжээний ашигтай ашиглалтыг ихээхэн бууруулдаг. Дахин дамжуулах дундаж хугацаа нь ойролцоогоор 1 секунд, сүүлний саатал нь бараг 30 секунд болохыг бид олж мэдсэн. TCP түвшний эдгээр өндөр хоцрогдол нь HTTPS-ийн завсарлага, дахин хүсэлтийг үүсгэж, сүлжээний хоцрогдол, үр ашиггүй байдлыг улам нэмэгдүүлсэн.
Хэмжсэн RTT-ийн 75 дахь хувь нь 425 мс орчим байсан бол TCP-ийн 75 дахь хувь нь бараг 3 секунд байв. Энэ нь алдагдлаас болж TCP өгөгдлийг амжилттай дамжуулахын тулд 7-10 дамжуулалт хийсэн болохыг харуулж байна. Энэ нь үр ашиггүй RTO тооцооны үр дагавар, TCP алдагдалд хурдан хариу өгөх чадваргүй байж болох юм цонхонд болон сүлжээний түгжрэлээс үүдэлтэй утасгүй холболтын алдагдал, алдагдлыг ялгаж чаддаггүй түгжрэлийг хянах алгоритмын үр ашиггүй байдал. TCP алдагдлын тестийн үр дүнг доор харуулав.
TCP пакет алдагдлын статистик
үнэ цэнэ
Хамгийн багадаа 1 пакет алдагдалтай холболтын хувь
45%
Холболтыг тохируулах явцад алдагдсан холболтын хувь
30%
Өгөгдөл солилцох явцад алдагдсан холболтын хувь
76%
Дахин дамжуулах саатлын хуваарилалт, секунд [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Нэг пакет эсвэл TCP сегментийн дахин дамжуулалтын тоог хуваарилах
[1,3,6,7]
QUIC-ийн хэрэглээ
Google-ээс анх боловсруулсан QUIC нь UDP дээр ажилладаг олон урсгалтай орчин үеийн тээврийн протокол юм. Одоогоор QUIC орж байна (Бид аль хэдийн QUIC-ийн хоёр хувилбар байдаг гэж аль хэдийн бичсэн, сониуч - ойролцоогоор. орчуулагч). Зураг 5-д үзүүлсэнчлэн QUIC-г HTTP/3-ийн доор байрлуулсан (үнэндээ QUIC-ийн дээд талд байгаа HTTP/2 нь HTTP/3 бөгөөд одоо эрчимтэй стандартчилагдан ажиллаж байна). Энэ нь пакет үүсгэхийн тулд UDP ашиглан HTTPS болон TCP давхаргыг хэсэгчлэн сольдог. TLS нь QUIC-д бүрэн суурилагдсан тул QUIC нь зөвхөн аюулгүй өгөгдөл дамжуулахыг дэмждэг.
Зураг 5: QUIC нь HTTP/3 дор ажилладаг бөгөөд өмнө нь HTTP/2 дээр ажиллаж байсан TLS-ийг орлодог.
TCP олшруулалтад QUIC ашиглахыг ятгасан шалтгаануудыг доор харуулав.
- 0-RTT холболт бий болгох. QUIC нь өмнөх холболтуудын зөвшөөрлийг дахин ашиглах боломжийг олгож, аюулгүй байдлын гар барилтуудын тоог багасгадаг. Ирээдүйд 0-RTT-г дэмжих боловч гурван талын TCP гар барих шаардлагатай хэвээр байх болно.
- HoL бөглөрөлтийг даван туулах. HTTP/2 нь гүйцэтгэлийг сайжруулахын тулд үйлчлүүлэгч тус бүрд нэг TCP холболтыг ашигладаг боловч энэ нь HoL (хэрэглээний шугам) блоклоход хүргэдэг. QUIC нь мультиплексийг хялбарчилж, хүсэлтийг програмд бие даан хүргэдэг.
- түгжрэлийн хяналт. QUIC нь хэрэглээний давхаргад байрладаг бөгөөд сүлжээний параметрүүд (алдагдлын тоо эсвэл RTT) дээр үндэслэн илгээлтийг хянадаг тээврийн үндсэн алгоритмыг шинэчлэхэд хялбар болгодог. Ихэнх TCP хэрэгжилт нь алгоритмыг ашигладаг , энэ нь хоцролтод мэдрэмтгий урсгалын хувьд оновчтой биш юм. гэх мэт саяхан боловсруулсан алгоритмууд , сүлжээг илүү нарийвчлалтай загварчилж, хоцролтыг оновчтой болгох. QUIC нь танд BBR-г ашиглах боломжийг олгодог бөгөөд энэ алгоритмыг ашиглаж байгаа үед нь шинэчлэх боломжийг олгодог. .
- алдагдлыг нөхөх. QUIC нь хоёр TLP дууддаг () RTO-г асаахаас өмнө - алдагдал нь маш мэдэгдэхүйц байсан ч гэсэн. Энэ нь TCP хэрэгжүүлэлтээс ялгаатай. TLP нь хамгийн сүүлийн багцыг (эсвэл хэрэв байгаа бол шинийг) дахин дамжуулж, хурдан дүүргэлтийг идэвхжүүлдэг. Хоцрогдолтой ажиллах нь Uber-ийн сүлжээгээ хэрхэн ажиллуулах, тухайлбал, богино, үе үе, хоцрогдолд мэдрэмтгий өгөгдөл дамжуулахад тустай.
- оновчтой ACK. Пакет бүр өвөрмөц дарааллын дугаартай тул ямар ч асуудал гарахгүй пакетуудыг дахин дамжуулах үед. ACK пакетууд нь багцыг боловсруулж, үйлчлүүлэгч тал дээр ACK үүсгэх цагийг агуулна. Эдгээр функцууд нь QUIC нь RTT-ийг илүү нарийвчлалтай тооцоолох боломжийг олгодог. QUIC дахь ACK нь 256 хүртэлх зурвасыг дэмждэг , илгээгчийг пакет холиход илүү уян хатан байхад тусалж, процесст цөөн байт ашиглах. Сонгомол ACK () TCP-д энэ асуудлыг бүх тохиолдолд шийдэж чадахгүй.
- холболтын шилжилт. QUIC холболтууд нь 64 битийн ID-аар тодорхойлогддог тул хэрэв үйлчлүүлэгч IP хаягаа өөрчилбөл хуучин холболтын ID-г шинэ IP хаяг дээр үргэлжлүүлэн ашиглах боломжтой. Энэ нь хэрэглэгч Wi-Fi болон үүрэн холбооны хооронд шилжих хөдөлгөөнт програмуудад маш түгээмэл хэрэглэгддэг практик юм.
QUIC-ийн өөр хувилбарууд
Бид QUIC-ийг сонгохоосоо өмнө асуудлыг шийдэх өөр аргуудыг авч үзсэн.
Бидний оролдсон хамгийн эхний зүйл бол хэрэглэгчдэд ойртсон TCP холболтыг зогсоохын тулд TPC PoPs (Oils of Presence) байрлуулах явдал байв. Үндсэндээ PoP нь үүрэн сүлжээнд ойр байгаа хөдөлгөөнт төхөөрөмжтэй TCP холболтыг зогсоож, траффикийг анхны дэд бүтцэд буцааж өгдөг. TCP-г ойртуулах замаар бид RTT-ийг багасгаж, TCP нь динамик утасгүй орчинд илүү хариу үйлдэл үзүүлэх боломжтой. Гэсэн хэдий ч RTT болон алдагдлын дийлэнх нь үүрэн сүлжээнээс үүдэлтэй бөгөөд PoP ашиглах нь гүйцэтгэлийг мэдэгдэхүйц сайжруулдаггүй болохыг бидний туршилт харуулж байна.
Бид мөн TCP параметрүүдийг тааруулах талаар авч үзсэн. Манай янз бүрийн захын серверүүд дээр TCP стекийг тохируулах нь хэцүү байсан, учир нь TCP нь үйлдлийн системийн өөр хувилбаруудад ялгаатай хэрэгжүүлэлттэй байдаг. Үүнийг хэрэгжүүлэх, өөр өөр сүлжээний тохиргоог шалгахад хэцүү байсан. Зөвшөөрөл байхгүйн улмаас хөдөлгөөнт төхөөрөмж дээр TCP-ийг шууд тохируулах боломжгүй байсан. Хамгийн чухал нь, 0-RTT холболт, сайжруулсан RTT таамаглал зэрэг функцууд протоколын архитектурт чухал ач холбогдолтой тул TCP-ийг дангаар нь тааруулах замаар мэдэгдэхүйц үр дүнд хүрэх боломжгүй юм.
Эцэст нь бид видео дамжуулалтын асуудлыг шийдвэрлэх хэд хэдэн UDP-д суурилсан протоколуудыг үнэлэв-бид эдгээр протоколууд манай тохиолдолд тус болох эсэхийг харахыг хүссэн. Харамсалтай нь тэдгээр нь аюулгүй байдлын олон тохиргоонд маш их дутагдалтай байсан бөгөөд мета өгөгдөл болон хяналтын мэдээлэлд нэмэлт TCP холболт шаардлагатай байсан.
Бидний судалгаагаар QUIC нь аюулгүй байдал, гүйцэтгэлийн аль алиныг харгалзан интернетийн траффикийн асуудлыг шийдвэрлэх цорын ганц протокол гэдгийг харуулсан.
QUIC-ийг платформд нэгтгэх
QUIC-г амжилттай суулгаж, холболт муутай орчинд програмын гүйцэтгэлийг сайжруулахын тулд бид хуучин стекийг (TLS/TCP дээр HTTP/2) QUIC протоколоор сольсон. Бид сүлжээний номын санг ашигласан нь , протоколын анхны Google хувилбарыг агуулсан gQUIC. Энэхүү хэрэгжилтийг мөн IETF-ийн хамгийн сүүлийн үеийн үзүүлэлтүүдийг дагаж мөрдөхийн тулд байнга сайжруулж байна.
Бид эхлээд QUIC-д дэмжлэг үзүүлэхийн тулд Cronet-ийг Андройд програмууддаа нэгтгэсэн. Шилжилт хөдөлгөөний зардлыг аль болох бууруулах үүднээс интеграци хийсэн. Номын санг ашиглаж байсан хуучин сүлжээний стекийг бүрэн солихын оронд , бид Cronet-ийг OkHttp API хүрээний дор нэгтгэсэн. Интеграцийг ийм байдлаар хийснээр бид сүлжээний дуудлагадаа (хэрэглэдэг ) API түвшинд.
Андройд төхөөрөмжүүдийн арга барилтай адил бид Cronet-ийг iOS дээрх Uber програмуудад нэвтрүүлж, сүлжээнээс HTTP урсгалыг таслан зогсоосон. ашиглах . iOS сангаас гаргасан энэхүү хийсвэрлэл нь протоколд хамаарах URL-н өгөгдлийг зохицуулдаг бөгөөд бид Cronet-ийг iOS програмууддаа шилжүүлэхэд ихээхэн зардалгүйгээр нэгтгэх боломжийг олгодог.
Google Cloud Balancers дээр QUIC-г дуусгаж байна
Ар талд нь Google Cloud Load тэнцвэржүүлэгч дэд бүтцээр QUIC-ийн гүйцэтгэлийг хангадаг. QUIC-г дэмжих хариултуудын толгой. Ерөнхийдөө тэнцвэржүүлэгч нь HTTP хүсэлт бүрт alt-svc толгойг нэмдэг бөгөөд энэ нь домэйны QUIC дэмжлэгийг аль хэдийн баталгаажуулдаг. Cronet үйлчлүүлэгч энэ толгойтой HTTP хариу хүлээн авах үед тэр домайн руу дараагийн HTTP хүсэлтүүдэд QUIC ашигладаг. Тэнцвэржүүлэгч QUIC-г дуусгасны дараа манай дэд бүтэц энэ үйлдлийг HTTP2/TCP-ээр манай мэдээллийн төв рүү илгээдэг.
Гүйцэтгэл: Үр дүн
Гаралтын гүйцэтгэл нь бидний илүү сайн протокол хайх гол шалтгаан юм. Эхлэхийн тулд бид индэр үүсгэсэн өөр өөр сүлжээний профайлуудын дор QUIC хэрхэн ажиллахыг олж мэдэх. QUIC-ийн гүйцэтгэлийг бодит сүлжээн дээр туршихын тулд зорчигчийн аппликейшн дээрх HTTP дуудлагатай тун төстэй дуурайлган сүлжээний траффик ашиглан Шинэ Дели хотыг тойрон явахдаа туршилт хийсэн.
Туршилт 1
Туршилт хийх тоног төхөөрөмж:
- TCP болон QUIC дээр HTTPS урсгалыг зөвшөөрч байгаа эсэхийг шалгахын тулд Android төхөөрөмжүүдийг OkHttp болон Cronet стекээр турших;
- Java-д суурилсан эмуляцийн сервер нь ижил төрлийн HTTPS толгойг илгээж, тэдгээрээс хүсэлт хүлээн авахын тулд үйлчлүүлэгчийн төхөөрөмжүүдийг ачаалдаг;
- TCP болон QUIC холболтыг зогсоохын тулд Энэтхэгт ойрхон байрладаг үүл прокси. TCP дуусгавар болгохын тулд бид урвуу прокси ашигласан , QUIC-д зориулсан нээлттэй эхийн урвуу прокси олоход хэцүү байсан. Бид QUIC-д зориулсан урвуу прокси-г Chromium болон-н үндсэн QUIC стек ашиглан бүтээсэн үүнийг Chromium-д нээлттэй эх болгон ашиглах.
Зураг 6. TCP vs QUIC замын туршилтын иж бүрдэл нь OkHttp болон Cronet-тэй Android төхөөрөмжүүд, холболтыг зогсоох үүлэн прокси болон эмуляц серверээс бүрдсэн.
Туршилт 2
Google QUIC-г ашиглах боломжтой болгосон үед , бид ижил бараа материалыг ашигласан боловч нэг өөрчлөлттэй: NGINX-ийн оронд бид төхөөрөмжүүдийн TCP болон QUIC холболтыг зогсоох, мөн HTTPS урсгалыг эмуляцийн сервер рүү чиглүүлэхийн тулд Google-ийн ачааллын тэнцвэржүүлэгчийг ашигласан. Тэнцвэржүүлэгчид дэлхий даяар тархсан боловч төхөөрөмжид хамгийн ойр байгаа PoP серверийг ашиглана уу (гео байршлын ачаар).
Зураг 7. Хоёр дахь туршилтаар бид TCP болон QUIC-ийн гүйцэтгэлийн хоцролтыг харьцуулахыг хүссэн: Google Cloud ашиглах болон үүл прокси ашиглах.
Үүний үр дүнд хэд хэдэн илчлэлт биднийг хүлээж байв:
- PoP-ээр дамжуулан дуусгавар болгох нь TCP гүйцэтгэлийг сайжруулсан. Тэнцвэржүүлэгчид TCP холболтыг хэрэглэгчдэд ойртуулж, өндөр оновчтой болгосон тул RTT-ийг багасгаж, TCP гүйцэтгэлийг сайжруулдаг. Хэдийгээр QUIC-д бага өртсөн ч сүүлний хоцролтыг (10-30 хувиар) бууруулснаар TCP-ээс давсан.
- сүүл өртдөг . Хэдийгээр манай QUIC прокси нь Google-ийн ачаалал тэнцвэржүүлэгчээс төхөөрөмжүүдээс хол (50 мс-ээр илүү хоцролт) байсан ч энэ нь ижил төстэй гүйцэтгэлийг үзүүлсэн бөгөөд TCP-ийн 15 дэх хувь 20%, хоцролт нь 99% буурсан. Энэ нь хамгийн сүүлийн миль шилжилт нь сүлжээнд гацаа болж байгааг харуулж байна.
Зураг 8: Хоёр туршилтын үр дүн нь QUIC нь TCP-ээс илт давуу болохыг харуулж байна.
Замын хөдөлгөөнтэй тэмцэх
Туршилтаас санаа аван бид Android болон iOS програмууддаа QUIC дэмжлэгийг хэрэгжүүлсэн. Бид Uber-ийн үйл ажиллагаа явуулдаг хотуудад QUIC-ийн нөлөөллийг тодорхойлохын тулд A/B тест хийсэн. Ерөнхийдөө бид хоёр бүс нутаг, харилцаа холбооны операторууд болон сүлжээний төрлөөр хоцрогдол их хэмжээгээр буурсаныг харсан.
Доорх графикууд нь макро-бүс нутаг болон өөр өөр сүлжээний төрлүүд болох LTE, 95G, 99G-ээр сүүлний (3 ба 2 хувь) сайжирч байгааг харуулж байна.
Зураг 9. Тулааны туршилтуудад QUIC нь хоцрогдлын хувьд TCP-ээс илүү гарсан.
Зөвхөн урагшаа
Магадгүй энэ нь дөнгөж эхлэл байж магадгүй - QUIC-ийг үйлдвэрлэлд нэвтрүүлсэн нь тогтвортой болон тогтворгүй сүлжээн дэх програмын гүйцэтгэлийг сайжруулах гайхалтай боломжийг олгосон.
Хамрах хүрээ нэмэгдсэн
Бодит траффик дээрх протоколын гүйцэтгэлд дүн шинжилгээ хийсний дараа бид сешнүүдийн 80 орчим хувь нь QUIC-г амжилттай ашиглаж байгааг олж харлаа. всех хүсэлтүүд, харин сешнүүдийн 15% нь QUIC болон TCP-ийн хослолыг ашигласан. Энэ хослол нь бодит UDP алдаа болон сүлжээний муу нөхцөл хоёрыг ялгаж чадахгүй тул Cronet номын сангийн TCP руу буцах хугацаа дууссантай холбоотой гэж бид таамаглаж байна. Бид одоо QUIC-ийг дараагийн хэрэгжүүлэхээр ажиллаж байгаа тул энэ асуудлыг шийдэх гарцыг хайж байна.
QUIC оновчлол
Хөдөлгөөнт програмын урсгал нь хоцролтод мэдрэмтгий боловч зурвасын өргөнөөс хамаардаггүй. Мөн манай программуудыг үндсэндээ үүрэн холбооны сүлжээнд ашигладаг. Туршилтууд дээр үндэслэн хэрэглэгчдэд ойрхон TCP болон QUIC-г зогсоохын тулд прокси ашиглаж байсан ч сүүлний хоцролт өндөр хэвээр байна. Бид түгжрэлийн менежментийг сайжруулах, QUIC алдагдлыг сэргээх алгоритмын үр ашгийг дээшлүүлэх арга замыг идэвхтэй хайж байна.
Эдгээр болон бусад хэд хэдэн сайжруулалтыг хийснээр бид сүлжээ, бүс нутгаас үл хамааран хэрэглэгчийн туршлагыг сайжруулж, дэлхий даяар тав тухтай, саадгүй пакет тээвэрлэлтийг илүү хүртээмжтэй болгохоор төлөвлөж байна.
Эх сурвалж: www.habr.com