QUIC protokolunu izləmək olduqca maraqlıdır, ona görə də biz bu barədə yazmağı sevirik. Ancaq QUIC haqqında əvvəlki nəşrlər daha çox tarixi (yerli tarix, istəsəniz) təbiət və aparat idisə, bu gün biz fərqli bir tərcüməni dərc etməkdən məmnunuq - 2019-cu ildə protokolun real tətbiqi haqqında danışacağıq. Üstəlik, söhbət qaraj deyilən yerdə yerləşən kiçik infrastrukturdan yox, demək olar ki, bütün dünyada fəaliyyət göstərən Uber-dən gedir. Şirkətin mühəndisləri QUIC-dən istehsalda istifadə etmək qərarına necə gəldilər, sınaqları necə keçirdilər və istehsalda yaydıqdan sonra nə gördülər - kəsilmənin altında.
Şəkillər tıklanabilir. Oxumaqdan həzz alın!
Uber qlobal miqyasda, yəni 600 mövcud şəhərə malikdir, onların hər birində proqram tamamilə 4500-dən çox mobil operatorun simsiz İnternetinə əsaslanır. İstifadəçilər proqramın sadəcə sürətli deyil, real vaxt rejimində olmasını gözləyirlər - buna nail olmaq üçün Uber tətbiqinə aşağı gecikmə və çox etibarlı əlaqə lazımdır. Təəssüf ki, amma yığın dinamik və itkiyə meylli simsiz şəbəkələrdə yaxşı nəticə vermir. Biz başa düşdük ki, bu halda aşağı performans əməliyyat sisteminin nüvələrindəki TCP tətbiqləri ilə birbaşa bağlıdır.
Problemi həll etmək üçün müraciət etdik , nəqliyyat protokolunun icrasına daha çox nəzarət etməyə imkan verən müasir kanal multipleksləşdirmə protokolu. Hazırda işçi qrup kimi QUIC standartlaşdırır .
Geniş sınaqdan sonra belə nəticəyə gəldik ki, tətbiqimizdə QUIC tətbiqi TCP ilə müqayisədə daha az gecikmə ilə nəticələnəcək. Sürücü və sərnişin tətbiqlərində HTTPS trafiki üçün 10-30% intervalında azalma müşahidə etdik. QUIC həmçinin bizə istifadəçi paketləri üzərində başdan sona nəzarət imkanı verdi.
Bu yazıda biz QUIC-i dəstəkləyən yığından istifadə edərək Uber tətbiqləri üçün TCP-nin optimallaşdırılması üzrə təcrübəmizi paylaşırıq.
Ən son texnologiya: TCP
Bu gün TCP HTTPS trafikini İnternetdə çatdırmaq üçün ən çox istifadə edilən nəqliyyat protokoludur. TCP etibarlı bayt axını təmin edir və bununla da şəbəkə sıxlığı və keçid qatının itkiləri ilə mübarizə aparır. HTTPS trafiki üçün TCP-nin geniş istifadəsi birincinin hər yerdə olması (demək olar ki, hər bir ƏS-də TCP var), əksər infrastrukturda (yük balanslaşdırıcıları, HTTPS proksiləri və CDN-lər kimi) mövcudluğu və mövcud olan hazır funksionallıq ilə bağlıdır. demək olar ki, əksər platformalarda və şəbəkələrdə.
Əksər istifadəçilər proqramımızı yolda istifadə edirlər və TCP gecikmələri real vaxt rejimində HTTPS trafikimizin tələblərinə yaxın deyildi. Sadəcə olaraq, bütün dünyada istifadəçilər bunu yaşadılar - Şəkil 1 böyük şəhərlərdəki gecikmələri göstərir:
Şəkil 1: Quyruq gecikməsi Uber-in əsas şəhərlərində dəyişir.
Hindistan və Braziliya şəbəkələrində gecikmə ABŞ və Böyük Britaniyadan daha yüksək olsa da, quyruq gecikməsi orta gecikmədən əhəmiyyətli dərəcədə yüksəkdir. Bu, hətta ABŞ və Böyük Britaniya üçün də doğrudur.
Hava üzərindən TCP performansı
TCP üçün yaradılmışdır simli şəbəkələr, yəni yüksək proqnozlaşdırıla bilən bağlantılara vurğu ilə. Bununla belə, simsiz şəbəkələrin öz xüsusiyyətləri və çətinlikləri var. Birincisi, simsiz şəbəkələr müdaxilə və siqnalın zəifləməsi səbəbindən itkilərə məruz qalır. Məsələn, Wi-Fi şəbəkələri mikrodalğalı sobalara, bluetooth və digər radio dalğalarına həssasdır. Mobil şəbəkələr siqnal itkisindən əziyyət çəkir () siqnalın obyektlər və tikililər tərəfindən əks olunması/udulması ilə əlaqədar qonşudan . Bu, daha əhəmiyyətli (4-10 dəfə) və daha müxtəlifliyə gətirib çıxarır və simli əlaqə ilə müqayisədə paket itkisi.
Bant genişliyinin dəyişməsi və itkiləri ilə mübarizə aparmaq üçün mobil şəbəkələr adətən trafik partlayışları üçün böyük buferlərdən istifadə edir. Bu, həddindən artıq növbələrə səbəb ola bilər ki, bu da daha uzun gecikmələr deməkdir. Çox vaxt TCP bu növbəni uzadılmış fasiləyə görə israf kimi qəbul edir, ona görə də TCP ötürülməyə və bununla da buferi doldurmağa meyllidir. Bu problem kimi tanınır (), və bu çox müasir internet.
Nəhayət, mobil şəbəkə performansı daşıyıcıya, bölgəyə və vaxta görə dəyişir. Şəkil 2-də biz 2 kilometr diapazondakı hüceyrələr arasında HTTPS trafikinin median gecikmələrini topladıq. Məlumat Hindistanın Dehli şəhərində iki əsas mobil operator üçün toplanıb. Gördüyünüz kimi, performans hüceyrədən hüceyrəyə dəyişir. Həmçinin bir operatorun məhsuldarlığı ikincinin məhsuldarlığından fərqlənir. Buna vaxt və məkan nəzərə alınmaqla şəbəkəyə giriş nümunələri, istifadəçi mobilliyi, həmçinin qüllənin sıxlığını nəzərə alan şəbəkə infrastrukturu və şəbəkə növlərinin nisbəti (LTE, 3G və s.) kimi amillər təsir edir.
Şəkil 2. Nümunə olaraq 2 km radiusdan istifadə etməklə gecikmələr. Dehli, Hindistan.
Həmçinin, mobil şəbəkələrin performansı zamanla dəyişir. Şəkil 3 həftənin günlərinə görə orta gecikməni göstərir. Biz eyni zamanda bir gün və saat ərzində daha kiçik miqyasda fərqləri müşahidə etdik.
Şəkil 3. Quyruq gecikmələri günlər arasında əhəmiyyətli dərəcədə dəyişə bilər, lakin eyni operator üçün.
Yuxarıda göstərilənlərin hamısı simsiz şəbəkələrdə TCP performansının təsirsiz olmasına səbəb olur. Bununla belə, TCP-yə alternativlər axtarmazdan əvvəl, aşağıdakı məqamlar haqqında dəqiq bir anlayış inkişaf etdirmək istədik:
- Tətbiqlərimizdə gecikmələrin arxasında əsas günahkar TCPmi?
- Müasir şəbəkələrdə əhəmiyyətli və müxtəlif gediş-gəliş gecikmələri (RTT) varmı?
- RTT və itkilərin TCP performansına təsiri nədir?
TCP Performans Təhlili
TCP performansını necə təhlil etdiyimizi anlamaq üçün gəlin TCP-nin məlumatı göndəricidən qəbulediciyə necə ötürdüyünə qısaca nəzər salaq. Birincisi, göndərən üç yollu bir TCP bağlantısı qurur : Göndərən SYN paketini göndərir, qəbuledicidən SYN-ACK paketini gözləyir, sonra ACK paketini göndərir. TCP bağlantısını qurmaq üçün əlavə ikinci və üçüncü keçid sərf olunur. Alıcı etibarlı çatdırılmanı təmin etmək üçün hər bir paketi (ACK) qəbul etdiyini təsdiq edir.
Əgər paket və ya ACK itirilərsə, göndərici fasilədən sonra yenidən göndərir (RTO, ). RTO, göndərən və alıcı arasında gözlənilən RTT gecikməsi kimi müxtəlif amillər əsasında dinamik olaraq hesablanır.
Şəkil 4. TCP/TLS üzərindən paket mübadiləsi təkrar ötürmə mexanizmini ehtiva edir.
Tətbiqlərimizdə TCP-nin necə işlədiyini müəyyən etmək üçün istifadə edərək TCP paketlərinə nəzarət etdik bir həftə Hindistan kənar serverlərindən gələn döyüş trafikində. Daha sonra istifadə edərək TCP bağlantılarını təhlil etdik . Bundan əlavə, biz real trafiki mümkün qədər təqlid edərək sınaq serverinə emulyasiya edilmiş trafik göndərən Android proqramı yaratdıq. Bu proqrama malik smartfonlar bir neçə gün ərzində jurnallar toplayan bir neçə işçiyə paylanıb.
Hər iki təcrübənin nəticələri bir-birinə uyğun idi. Biz yüksək RTT gecikmələrini gördük; quyruq dəyərləri median dəyərdən təxminən 6 dəfə yüksək idi; gecikmələrin arifmetik ortalaması 1 saniyədən çoxdur. Bir çox əlaqə itkili idi və bu, TCP-nin bütün paketlərin 3,5%-ni yenidən ötürməsinə səbəb oldu. Hava limanları və qatar stansiyaları kimi tıxaclı ərazilərdə 7% itki gördük. Bu nəticələr mobil şəbəkələrdə istifadə edilənlərin ənənəvi müdrikliyinə şübhə yaradır nəqliyyat səviyyəsində itkiləri əhəmiyyətli dərəcədə azaldır. Aşağıda "simulyator" tətbiqindən əldə edilən test nəticələri:
Şəbəkə ölçüləri
Mənaları
RTT, millisaniyələr [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT fərqi, saniyə
Orta hesabla ~1,2 s
Qeyri-sabit bağlantılarda paket itkisi
Orta ~3.5% (həddindən artıq yüklənmiş ərazilərdə 7%)
Bu əlaqələrin demək olar ki, yarısında ən azı bir paket itkisi olub, əksəriyyəti SYN və SYN-ACK paketləridir. Əksər TCP tətbiqləri SYN paketləri üçün 1 saniyəlik RTO dəyərindən istifadə edir ki, bu da sonrakı itkilər üçün eksponent olaraq artır. TCP-nin bağlantıların qurulması daha uzun sürdüyünə görə tətbiqin yüklənmə müddətləri arta bilər.
Məlumat paketləri vəziyyətində yüksək RTO dəyərləri simsiz şəbəkələrdə keçici itkilərin olması halında şəbəkənin faydalı istifadəsini əhəmiyyətli dərəcədə azaldır. Orta təkrar ötürmə vaxtının təxminən 1 saniyəlik gecikmə ilə təxminən 30 saniyə olduğunu gördük. TCP səviyyəsindəki bu yüksək gecikmələr HTTPS-in fasilələrinə və təkrar sorğulara səbəb olub, şəbəkə gecikmə müddətini və səmərəsizliyini daha da artırıb.
Ölçülmüş RTT-nin 75-ci faizi təxminən 425 ms olduğu halda, TCP üçün 75-ci faizlik demək olar ki, 3 saniyə idi. Bu, itkinin TCP-nin məlumatları uğurla ötürmək üçün 7-10 keçid almasına səbəb olduğuna işarə edir. Bu, səmərəsiz RTO hesablamasının, TCP-nin itkiyə tez cavab verə bilməməsinin nəticəsi ola bilər pəncərədə və şəbəkə sıxlığı səbəbindən simsiz itkilər və itkilər arasında fərq qoymayan sıxlığa nəzarət alqoritminin səmərəsizliyi. Aşağıda TCP itkisi testlərinin nəticələri verilmişdir:
TCP paket itkisi statistikası
Dəyər
Ən azı 1 paket itkisi olan bağlantıların faizi
45%
Bağlantının qurulması zamanı itkiləri olan birləşmələrin faizi
30%
Məlumat mübadiləsi zamanı itkilərlə əlaqənin faizi
76%
Retranslyasiyada gecikmələrin paylanması, saniyələr [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Bir paket və ya TCP seqmenti üçün təkrar ötürmələrin sayının paylanması
[1,3,6,7]
QUIC tətbiqi
Əvvəlcə Google tərəfindən hazırlanmış QUIC, UDP üzərində işləyən çox yivli müasir nəqliyyat protokoludur. Hazırda QUIC var (Artıq yazdıq ki, QUIC-in iki versiyası var, maraqlıdır – təqribən. tərcüməçi). Şəkil 5-də göstərildiyi kimi, QUIC HTTP/3 altında yerləşdirilir (əslində QUIC-in üstündəki HTTP/2 hazırda intensiv şəkildə standartlaşdırılan HTTP/3-dür). Paket yaratmaq üçün UDP istifadə edərək HTTPS və TCP qatlarını qismən əvəz edir. QUIC yalnız təhlükəsiz məlumat ötürülməsini dəstəkləyir, çünki TLS QUIC-ə tam şəkildə daxil edilmişdir.
Şəkil 5: QUIC HTTP/3 altında işləyir, əvvəllər HTTP/2 altında işləyən TLS-ni əvəz edir.
Aşağıda bizi TCP gücləndirilməsi üçün QUIC istifadə etməyə inandıran səbəblər verilmişdir:
- 0-RTT bağlantısının qurulması. QUIC təhlükəsizlik əl sıxmalarının sayını azaldaraq, əvvəlki bağlantılardan icazələrin təkrar istifadəsinə imkan verir. Gələcəkdə 0-RTT-ni dəstəkləyəcək, lakin üçtərəfli TCP əl sıxması hələ də tələb olunacaq.
- HoL bloklanmasının aradan qaldırılması. HTTP/2 performansı yaxşılaşdırmaq üçün hər müştəri üçün bir TCP bağlantısından istifadə edir, lakin bu, HoL (xətt başlığı) bloklanmasına səbəb ola bilər. QUIC multipleksləşdirməni asanlaşdırır və sorğuları proqrama müstəqil şəkildə çatdırır.
- tıxaclara nəzarət. QUIC proqram səviyyəsində yerləşir və şəbəkə parametrləri (itkilərin sayı və ya RTT) əsasında göndərilməsini idarə edən əsas nəqliyyat alqoritmini yeniləməyi asanlaşdırır. Əksər TCP tətbiqləri alqoritmdən istifadə edir , bu gecikməyə həssas trafik üçün optimal deyil. kimi bu yaxınlarda hazırlanmış alqoritmlər , şəbəkəni daha dəqiq modelləşdirin və gecikmə müddətini optimallaşdırın. QUIC sizə BBR-dən istifadə etməyə və bu alqoritmi istifadə edildiyi kimi yeniləməyə imkan verir. .
- itkilərin ödənilməsi. QUIC iki TLP çağırır () RTO işə salınmazdan əvvəl - hətta itkilər çox nəzərə çarpdıqda. Bu, TCP tətbiqlərindən fərqlidir. TLP, sürətli doldurmanı işə salmaq üçün əsasən sonuncu paketi (və ya varsa, yenisini) təkrar ötürür. Quyruq gecikmələrinin idarə edilməsi xüsusilə Uber-in öz şəbəkəsini idarə etmə tərzində, yəni qısa, arabir və gecikməyə həssas məlumat ötürmələri üçün faydalıdır.
- optimallaşdırılmış ACK. Hər bir paketin özünəməxsus ardıcıllıq nömrəsi olduğundan, heç bir problem yoxdur paketlər təkrar ötürüldükdə. ACK paketlərində həmçinin paketi emal etmək və müştəri tərəfində ACK yaratmaq üçün vaxt var. Bu xüsusiyyətlər QUIC-in RTT-ni daha dəqiq hesablamasını təmin edir. QUIC-də ACK 256-a qədər diapazonu dəstəkləyir , göndərənə paketlərin qarışdırılmasına daha davamlı olmasına və prosesdə daha az bayt istifadə etməsinə kömək edir. Seçilmiş ACK () TCP-də bütün hallarda bu problemi həll etmir.
- əlaqə miqrasiyası. QUIC əlaqələri 64-bit ID ilə müəyyən edilir, ona görə də müştəri IP ünvanlarını dəyişərsə, köhnə əlaqə identifikatoru fasiləsiz olaraq yeni IP ünvanında istifadə olunmağa davam edə bilər. Bu, istifadəçinin Wi-Fi və mobil bağlantılar arasında keçid etdiyi mobil tətbiqlər üçün çox yayılmış bir təcrübədir.
QUIC üçün alternativlər
QUIC-i seçməzdən əvvəl problemin həllinə alternativ yanaşmaları nəzərdən keçirdik.
Çalışdığımız ilk şey istifadəçilərə daha yaxın olan TCP bağlantılarını dayandırmaq üçün TPC PoP-lərini (Mövcudluq Nöqtələrini) yerləşdirmək oldu. Əsasən, PoP-lər mobil şəbəkəyə daha yaxın olan mobil cihazla TCP bağlantısını dayandırır və trafiki orijinal infrastruktura geri qaytarır. TCP-ni daha yaxından dayandırmaqla biz RTT-ni potensial olaraq azalda və TCP-nin dinamik simsiz mühitə daha həssas olmasını təmin edə bilərik. Bununla belə, təcrübələrimiz göstərdi ki, RTT və itkilərin çoxu mobil şəbəkələrdən qaynaqlanır və PoP-lərdən istifadə performansın əhəmiyyətli dərəcədə yaxşılaşdırılmasını təmin etmir.
TCP parametrlərinin tənzimlənməsinə də baxdıq. Heterojen kənar serverlərimizdə TCP yığını qurmaq çətin idi, çünki TCP müxtəlif OS versiyalarında fərqli tətbiqlərə malikdir. Bunu həyata keçirmək və müxtəlif şəbəkə konfiqurasiyalarını sınaqdan keçirmək çətin idi. İcazələrin olmaması səbəbindən TCP-ni birbaşa mobil cihazlarda konfiqurasiya etmək mümkün olmadı. Daha da əhəmiyyətlisi, 0-RTT əlaqələri və təkmilləşdirilmiş RTT proqnozu kimi xüsusiyyətlər protokolun arxitekturası üçün kritik əhəmiyyətə malikdir və buna görə də tək TCP-ni tənzimləməklə əhəmiyyətli fayda əldə etmək mümkün deyil.
Nəhayət, video axını ilə bağlı problemləri həll edən bir neçə UDP əsaslı protokolları qiymətləndirdik - bu protokolların bizim vəziyyətimizdə kömək edib-etməyəcəyini görmək istədik. Təəssüf ki, bir çox təhlükəsizlik parametrlərində ciddi çatışmazlıqlar var idi və həmçinin metadata və nəzarət məlumatı üçün əlavə TCP bağlantısı tələb olunurdu.
Tədqiqatımız göstərdi ki, QUIC həm təhlükəsizlik, həm də performansı nəzərə alaraq internet trafiki probleminin həllinə kömək edə biləcək yeganə protokoldur.
QUIC-in platformaya inteqrasiyası
QUIC-i uğurla yerləşdirmək və zəif keçid mühitlərində tətbiq performansını yaxşılaşdırmaq üçün biz köhnə yığını (TLS/TCP üzərində HTTP/2) QUIC protokolu ilə əvəz etdik. Şəbəkə kitabxanasından istifadə etdik haqqında , protokolun orijinal Google versiyasını ehtiva edir - gQUIC. Bu tətbiq də ən son IETF spesifikasiyasına riayət etmək üçün daim təkmilləşdirilir.
QUIC üçün dəstək əlavə etmək üçün ilk olaraq Cronet-i Android proqramlarımıza inteqrasiya etdik. İnteqrasiya elə həyata keçirilirdi ki, miqrasiya xərcləri mümkün qədər azalsın. Kitabxanadan istifadə edən köhnə şəbəkə yığınını tamamilə əvəz etmək əvəzinə , biz Cronet-i OkHttp API çərçivəsi ALTINDA inteqrasiya etdik. İnteqrasiyanı bu şəkildə etməklə biz şəbəkə zənglərimizdə dəyişikliklərin qarşısını aldıq (onlardan ) API səviyyəsində.
Android cihazları üçün yanaşmaya bənzər şəkildə, biz Cronet-i iOS-da Uber proqramlarına tətbiq etdik, şəbəkədən HTTP trafikini kəsdik. istifadə . iOS Fondu tərəfindən təmin edilən bu abstraksiya protokola aid URL məlumatlarını idarə edir və Cronet-i əhəmiyyətli miqrasiya xərcləri olmadan iOS proqramlarımıza inteqrasiya edə bilməmizi təmin edir.
Google Cloud Balancers-də QUIC tamamlanır
Arxa tərəfdə QUIC tamamlama Google Cloud Load balanslaşdırma infrastrukturu tərəfindən təmin edilir. QUIC-i dəstəkləmək üçün cavab başlıqları. Ümumiyyətlə, balanslaşdırıcı hər HTTP sorğusuna alt-svc başlığı əlavə edir və bu artıq domen üçün QUIC dəstəyini təsdiqləyir. Cronet müştərisi bu başlıqla HTTP cavabı aldıqda, həmin domenə sonrakı HTTP sorğuları üçün QUIC-dən istifadə edir. Balanslaşdırıcı QUIC-i tamamladıqdan sonra infrastrukturumuz bu əməliyyatı açıq şəkildə HTTP2/TCP üzərindən data mərkəzlərimizə göndərir.
Performans: Nəticələr
Çıxış performansı daha yaxşı protokol axtarışımızın əsas səbəbidir. Başlamaq üçün biz stend yaratdıq QUIC-in müxtəlif şəbəkə profilləri altında necə davranacağını öyrənmək üçün. QUIC-in real dünya şəbəkələrində performansını yoxlamaq üçün sərnişin proqramında HTTP zənglərinə çox oxşar olan təqlid edilmiş şəbəkə trafikindən istifadə edərək Yeni Dehli ətrafında avtomobil sürərkən təcrübələr apardıq.
Təcrübə 1
Təcrübə üçün avadanlıq:
- müvafiq olaraq TCP və QUIC üzərindən HTTPS trafikinə icazə verdiyimizə əmin olmaq üçün Android cihazlarını OkHttp və Cronet yığınları ilə sınaqdan keçirin;
- cavablarda eyni tip HTTPS başlıqlarını göndərən və onlardan sorğu almaq üçün müştəri cihazlarını yükləyən Java əsaslı emulyasiya serveri;
- TCP və QUIC bağlantılarını dayandırmaq üçün fiziki olaraq Hindistana yaxın olan bulud proksiləri. TCP-nin dayandırılması üçün biz əks proxy-dən istifadə etdik , QUIC üçün açıq mənbəli əks proxy tapmaq çətin idi. Biz özümüz Chromium və əsas QUIC yığınından istifadə edərək QUIC üçün əks proksi yaratdıq açıq mənbə kimi xroma daxil edin.
Şəkil 6. TCP vs QUIC yol test dəsti OkHttp və Cronet ilə Android cihazlarından, əlaqələri dayandırmaq üçün bulud proksilərindən və emulyasiya serverindən ibarət idi.
Təcrübə 2
Google QUIC-i ilə əlçatan etdikdə , biz eyni inventardan istifadə etdik, lakin bir dəyişikliklə: NGINX əvəzinə biz cihazlardan TCP və QUIC bağlantılarını dayandırmaq, həmçinin HTTPS trafikini emulyasiya serverinə yönləndirmək üçün Google yük balanslaşdırıcılarını götürdük. Balanslaşdırıcılar bütün dünyada paylanır, lakin cihaza ən yaxın PoP serverindən istifadə edin (geolokasiya sayəsində).
Şəkil 7. İkinci təcrübədə biz TCP və QUIC-in tamamlama gecikmə müddətini müqayisə etmək istədik: Google Cloud-dan istifadə və bulud proksi-mizdən istifadə.
Nəticədə, bizi bir neçə açıqlama gözləyirdi:
- PoP vasitəsilə xitam TCP performansını yaxşılaşdırdı. Balanslaşdırıcılar istifadəçilərə daha yaxın olan TCP bağlantılarını dayandırdıqları və yüksək dərəcədə optimallaşdırıldıqları üçün bu, TCP performansını yaxşılaşdıran aşağı RTT-lərə səbəb olur. QUIC daha az təsirlənsə də, quyruq gecikməsini azaltmaq (10-30 faiz) baxımından yenə də TCP-dən üstün idi.
- quyruqlar təsirlənir . Baxmayaraq ki, bizim QUIC proksi Google-un yük balanslaşdırıcıları ilə müqayisədə cihazlardan (təxminən 50 ms yüksək gecikmə) uzaqda olsa da, o, oxşar performans göstərdi - TCP üçün 15 faizlikdə 20% azalma ilə müqayisədə gecikmədə 99% azalma. Bu, son mil keçidinin şəbəkədə darboğaz olduğunu göstərir.
Şəkil 8: İki təcrübənin nəticələri göstərir ki, QUIC TCP-dən əhəmiyyətli dərəcədə üstündür.
Trafiklə mübarizə
Təcrübədən ilhamlanaraq biz Android və iOS proqramlarımızda QUIC dəstəyi tətbiq etdik. Uber-in fəaliyyət göstərdiyi şəhərlərdə QUIC-in təsirini müəyyən etmək üçün A/B testi keçirdik. Ümumiyyətlə, biz hər iki regionda, telekommunikasiya operatorları və şəbəkə növü üzrə gecikmələrin əhəmiyyətli dərəcədə azaldığını gördük.
Aşağıdakı qrafiklər makro-region və müxtəlif şəbəkə növləri - LTE, 95G, 99G üzrə quyruqlarda (3 və 2 faiz) faiz yaxşılaşmalarını göstərir.
Şəkil 9. Döyüş testlərində QUIC gecikmə müddətinə görə TCP-dən üstün olmuşdur.
Yalnız irəli
Bəlkə də bu, yalnız başlanğıcdır - QUIC-in istehsala buraxılması həm sabit, həm də qeyri-sabit şəbəkələrdə tətbiq performansını yaxşılaşdırmaq üçün heyrətamiz imkanlar yaratdı, yəni:
Artan əhatə dairəsi
Protokolun real trafik üzrə performansını təhlil etdikdən sonra seansların təxminən 80%-nin QUIC-dən uğurla istifadə etdiyini gördük. Bütün sorğular, seansların 15%-i isə QUIC və TCP birləşməsindən istifadə edirdi. Güman edirik ki, bu birləşmə Cronet kitabxanasının TCP-yə geri qayıtması ilə bağlıdır, çünki o, real UDP uğursuzluqları ilə zəif şəbəkə şərtlərini ayırd edə bilmir. Hazırda QUIC-in sonrakı tətbiqi üzərində işlədiyimiz üçün bu problemin həllini axtarırıq.
QUIC optimallaşdırma
Mobil tətbiqlərdən gələn trafik gecikməyə həssasdır, lakin bant genişliyinə həssas deyil. Həmçinin, bizim proqramlarımız əsasən mobil şəbəkələrdə istifadə olunur. Təcrübələrə əsasən, istifadəçilərə yaxın TCP və QUIC-i dayandırmaq üçün proksidən istifadə etsə də, gecikmə gecikmələri hələ də yüksəkdir. Biz sıxlığın idarə edilməsini təkmilləşdirmək və QUIC itkisinin bərpası alqoritmlərinin səmərəliliyini artırmaq üçün fəal şəkildə yollar axtarırıq.
Bu və bir sıra digər təkmilləşdirmələrlə biz şəbəkə və regiondan asılı olmayaraq istifadəçi təcrübəsini təkmilləşdirməyi, rahat və qüsursuz paket daşınmasını bütün dünyada daha əlçatan etməyi planlaşdırırıq.
Mənbə: www.habr.com