QUIC protokolünü izlemek son derece ilginç, bu yüzden onun hakkında yazmayı seviyoruz. Ancak QUIC ile ilgili önceki yayınlar daha çok tarihsel (isterseniz yerel tarih) nitelikte ve donanımsal olsaydı, bugün farklı türden bir çeviri yayınlamaktan mutluluk duyarız - 2019'da protokolün gerçek uygulaması hakkında konuşacağız. Üstelik garaj denilen küçük bir altyapıdan değil, neredeyse dünyanın her yerinde faaliyet gösteren Uber'den bahsediyoruz. Şirketin mühendisleri QUIC'i üretimde kullanma kararına nasıl vardılar, testleri nasıl gerçekleştirdiler ve onu üretime soktuktan sonra kesimin altında neler gördüler?
Resimler tıklanabilir. Okumanın tadını çıkar!
Uber küresel bir ölçeğe sahiptir, yani 600 şehirde faaliyet göstermektedir ve bunların her birinde uygulama tamamen 4500'den fazla hücresel operatörün kablosuz internetine dayanmaktadır. Kullanıcılar, uygulamanın yalnızca hızlı değil aynı zamanda gerçek zamanlı olmasını da bekler; bunu başarmak için Uber uygulamasının düşük gecikme süresine ve çok güvenilir bir bağlantıya ihtiyacı vardır. Ne yazık ki, ama yığın dinamik ve kaybolmaya eğilimli kablosuz ağlarda iyi performans göstermez. Bu durumda düşük performansın doğrudan işletim sistemi çekirdeklerindeki TCP uygulamalarıyla ilgili olduğunu fark ettik.
Sorunu çözmek için başvurduk , taşıma protokolünün performansı üzerinde bize daha fazla kontrol sağlayan modern bir kanal çoğullama protokolü. Şu anda çalışma grubu QUIC'i şu şekilde standartlaştırır: .
Kapsamlı testlerden sonra uygulamamızda QUIC uygulamasının TCP'ye kıyasla daha düşük kuyruk gecikmesi sağlayacağı sonucuna vardık. Sürücü ve yolcu uygulamalarında HTTPS trafiğinde %10-30 aralığında bir azalma gözlemledik. QUIC ayrıca bize kullanıcı paketleri üzerinde uçtan uca kontrol olanağı da sağladı.
Bu makalede, QUIC'i destekleyen bir yığın kullanarak Uber uygulamaları için TCP'yi optimize etme konusundaki deneyimimizi paylaşıyoruz.
En son teknoloji: TCP
Günümüzde TCP, İnternet üzerinde HTTPS trafiğini iletmek için en çok kullanılan aktarım protokolüdür. TCP güvenilir bir bayt akışı sağlayarak ağ tıkanıklığı ve bağlantı katmanı kayıplarıyla başa çıkar. HTTPS trafiği için TCP'nin yaygın kullanımı, TCP'nin her yerde bulunmasından (neredeyse her işletim sistemi TCP içerir), çoğu altyapıda kullanılabilirliğinden (yük dengeleyiciler, HTTPS proxy'leri ve CDN'ler gibi) ve kullanıma hazır işlevselliklerden kaynaklanmaktadır. neredeyse çoğu platformda ve ağda.
Çoğu kullanıcı uygulamamızı hareket halindeyken kullanıyor ve TCP kuyruk gecikmeleri, gerçek zamanlı HTTPS trafiğimizin taleplerinin yakınında bile değildi. Basitçe söylemek gerekirse, dünyanın her yerindeki kullanıcılar bunu deneyimledi - Şekil 1, büyük şehirlerdeki gecikmeleri gösteriyor:
Şekil 1: Kuyruk gecikmesi, Uber'in ana şehirlerinde farklılık gösterir.
Hindistan ve Brezilya ağlarındaki gecikme ABD ve İngiltere'dekinden daha yüksek olmasına rağmen kuyruk gecikmesi ortalama gecikmeden önemli ölçüde daha yüksektir. Ve bu ABD ve İngiltere için bile geçerli.
Havadan TCP performansı
TCP bunun için oluşturuldu kablolu ağlar, yani oldukça öngörülebilir bağlantılara vurgu yaparak. Fakat, kablosuz ağların kendine has özellikleri ve zorlukları vardır. Birincisi, kablosuz ağlar girişim ve sinyal zayıflaması nedeniyle kayıplara karşı hassastır. Örneğin Wi-Fi ağları mikrodalgalara, bluetooth'a ve diğer radyo dalgalarına karşı hassastır. Hücresel ağlar sinyal kaybından muzdariptir () sinyalin nesneler ve binalar tarafından yansıtılması/absorblanması nedeniyle ve ayrıca komşudan . Bu, daha önemli (4-10 kat) ve daha çeşitliliğe yol açar ve kablolu bağlantıyla karşılaştırıldığında paket kaybı.
Bant genişliği dalgalanmaları ve kayıpları ile mücadele etmek için hücresel ağlar genellikle trafik patlamaları için büyük tamponlar kullanır. Bu, aşırı kuyruğa neden olabilir, bu da daha uzun gecikmeler anlamına gelir. Çoğu zaman TCP bu kuyruğa alma işlemini, uzun zaman aşımı nedeniyle bir atık olarak ele alır, bu nedenle TCP geçiş yapma ve dolayısıyla arabelleği doldurma eğilimindedir. Bu sorun şu şekilde bilinir: () ve bu çok modern internet.
Son olarak hücresel ağ performansı operatöre, bölgeye ve zamana göre değişir. Şekil 2'de, 2 kilometrelik aralıktaki hücreler arasındaki HTTPS trafiğinin medyan gecikmelerini topladık. Hindistan'ın Delhi kentindeki iki büyük cep telefonu operatörü için toplanan veriler. Gördüğünüz gibi performans hücreden hücreye farklılık gösteriyor. Ayrıca bir operatörün üretkenliği ikincinin üretkenliğinden farklıdır. Bu, zaman ve konumu dikkate alan ağ giriş modelleri, kullanıcı hareketliliği, kule yoğunluğu ve ağ türlerinin (LTE, 3G vb.) oranını dikkate alan ağ altyapısı gibi faktörlerden etkilenir.
Şekil 2. Örnek olarak 2 km'lik bir yarıçapı kullanan gecikmeler. Delhi, Hindistan.
Ayrıca hücresel ağların performansı zamanla değişir. Şekil 3'te haftanın günlerine göre ortalama gecikme süresi gösterilmektedir. Ayrıca tek bir gün ve saat içinde daha küçük ölçekte de farklılıklar gözlemledik.
Şekil 3. Kuyruk gecikmeleri günler arasında önemli ölçüde farklılık gösterebilir, ancak aynı operatör için.
Yukarıdakilerin tümü, kablosuz ağlarda TCP performansının etkisiz olmasına neden olur. Ancak TCP'ye alternatif aramadan önce aşağıdaki noktalar üzerinde kesin bir anlayış geliştirmek istedik:
- Uygulamalarımızdaki kuyruk gecikmelerinin arkasındaki ana suçlu TCP mi?
- Modern ağlarda önemli ve çeşitli gidiş-dönüş gecikmeleri (RTT) var mı?
- RTT ve kaybın TCP performansı üzerindeki etkisi nedir?
TCP Performans Analizi
TCP performansını nasıl analiz ettiğimizi anlamak için, TCP'nin verileri göndericiden alıcıya nasıl aktardığına hızlıca bir göz atalım. İlk olarak gönderen, üç yönlü bir bağlantı gerçekleştirerek bir TCP bağlantısı kurar. : Gönderen SYN paketini gönderir, alıcıdan SYN-ACK paketini bekler ve ardından ACK paketini gönderir. TCP bağlantısını kurmak için ek bir ikinci ve üçüncü geçiş harcanır. Alıcı, güvenilir teslimatı sağlamak için her paketin (ACK) alındığını onaylar.
Bir paket veya ACK kaybolursa, gönderen bir zaman aşımından sonra yeniden iletim yapar (RTO, ). RTO, gönderen ile alıcı arasında beklenen RTT gecikmesi gibi çeşitli faktörlere dayalı olarak dinamik olarak hesaplanır.
Şekil 4. TCP/TLS üzerinden paket alışverişi bir yeniden iletim mekanizması içerir.
TCP'nin uygulamalarımızda nasıl performans gösterdiğini belirlemek için TCP paketlerini kullanarak izledik. Bir hafta boyunca Hint uç sunucularından gelen savaş trafiği üzerine. Daha sonra kullanarak TCP bağlantılarını analiz ettik. . Ek olarak, gerçek trafiği olabildiğince taklit ederek taklit trafiği bir test sunucusuna gönderen bir Android uygulaması oluşturduk. Bu uygulamaya sahip akıllı telefonlar, birkaç gün boyunca günlükleri toplayan birçok çalışana dağıtıldı.
Her iki deneyin sonuçları birbiriyle tutarlıydı. Yüksek RTT gecikmeleri gördük; kuyruk değerleri medyan değerinden neredeyse 6 kat daha yüksekti; gecikmelerin aritmetik ortalaması 1 saniyeden fazladır. Birçok bağlantı kayıplıydı ve TCP'nin tüm paketlerin %3,5'ini yeniden iletmesine neden oluyordu. Havaalanları, tren istasyonları gibi sıkışık bölgelerde yüzde 7 kayıp gördük. Bu sonuçlar, hücresel ağlarda kullanılanların geleneksel inanışına şüphe düşürüyor. Taşıma düzeyindeki kayıpları önemli ölçüde azaltır. Aşağıda “simülatör” uygulamasından elde edilen test sonuçları yer almaktadır:
Ağ metrikleri
anlam
RTT, milisaniye [50%,75%, 95%,99%]
[350, 425, 725, 2300]
RTT sapması, saniye
Ortalama ~1,2 sn
Kararsız bağlantılarda paket kaybı
Ortalama ~%3.5 (aşırı yüklü alanlarda %7)
Bu bağlantıların neredeyse yarısında en az bir paket kaybı vardı; bunların çoğu SYN ve SYN-ACK paketleriydi. Çoğu TCP uygulaması, SYN paketleri için 1 saniyelik bir RTO değeri kullanır; bu, sonraki kayıplar için katlanarak artar. TCP'nin bağlantı kurmasının daha uzun sürmesi nedeniyle uygulama yükleme süreleri artabilir.
Veri paketleri söz konusu olduğunda yüksek RTO değerleri, kablosuz ağlarda geçici kayıpların varlığında ağın yararlı kullanımını büyük ölçüde azaltır. Ortalama yeniden iletim süresinin yaklaşık 1 saniye olduğunu ve kuyruk gecikmesinin neredeyse 30 saniye olduğunu bulduk. TCP düzeyindeki bu yüksek gecikmeler, HTTPS zaman aşımlarına ve yeniden isteklere neden olarak ağ gecikmesini ve verimsizliği daha da artırdı.
Ölçülen RTT'nin 75'inci yüzdelik dilimi 425 ms civarındayken, TCP'nin 75'inci yüzdelik dilimi neredeyse 3 saniyeydi. Bu, kaybın TCP'nin başarıyla veri iletmek için 7-10 geçiş yapmasına neden olduğunu ima ediyor. Bu, verimsiz RTO hesaplamasının ve TCP'nin kayba hızla yanıt verememesinin bir sonucu olabilir. pencerede ve kablosuz kayıplar ile ağ tıkanıklığından kaynaklanan kayıplar arasında ayrım yapmayan tıkanıklık kontrol algoritmasının verimsizliği. Aşağıda TCP kayıp testlerinin sonuçları verilmiştir:
TCP paket kaybı istatistikleri
Değer
En az 1 paket kaybı olan bağlantıların yüzdesi
%45
Bağlantı kurulumu sırasında kayıplı bağlantıların yüzdesi
%30
Veri alışverişi sırasında kayıplı bağlantıların yüzdesi
%76
Yeniden iletimdeki gecikmelerin dağılımı, saniye [%50, %75, %95,%99] [1, 2.8, 15, 28]
Bir paket veya TCP segmenti için yeniden iletim sayısının dağılımı
[1,3,6,7]
QUIC'in uygulanması
Başlangıçta Google tarafından geliştirilen QUIC, UDP üzerinde çalışan, çok iş parçacıklı, modern bir aktarım protokolüdür. Şu anda QUIC (QUIC'in iki versiyonu olduğunu zaten yazmıştık, merak uyandırıcı – yaklaşık. çevirmen). Şekil 5'te gösterildiği gibi, QUIC, HTTP/3'ün altına yerleştirilmiştir (aslında, QUIC'nin üstündeki HTTP/2, şu anda yoğun bir şekilde standartlaştırılan HTTP/3'tür). Paket oluşturmak için UDP'yi kullanarak HTTPS ve TCP katmanlarının yerini kısmen alır. TLS tamamen QUIC'e yerleşik olduğundan QUIC yalnızca güvenli veri aktarımını destekler.
Şekil 5: QUIC, daha önce HTTP/3 altında çalışan TLS'nin yerini alarak HTTP/2 altında çalışır.
Bizi TCP amplifikasyonu için QUIC kullanmaya ikna eden nedenler aşağıdadır:
- 0-RTT bağlantı kurulumu. QUIC, önceki bağlantılardan gelen yetkilerin yeniden kullanılmasına olanak tanıyarak güvenlik anlaşmalarının sayısını azaltır. Gelecekte 0-RTT'yi destekleyecektir ancak üç yönlü TCP anlaşması yine de gerekli olacaktır.
- HoL engellemesinin üstesinden gelmek. HTTP/2, performansı artırmak için istemci başına bir TCP bağlantısı kullanır, ancak bu, HoL (hat başı) engellemesine yol açabilir. QUIC çoğullamayı basitleştirir ve istekleri uygulamaya bağımsız olarak iletir.
- tıkanıklık kontrolü. QUIC, uygulama katmanında bulunur ve ağ parametrelerine (kayıp sayısı veya RTT) dayalı olarak gönderimi kontrol eden ana aktarım algoritmasının güncellenmesini kolaylaştırır. Çoğu TCP uygulaması algoritmayı kullanır gecikmeye duyarlı trafik için ideal değildir. Son zamanlarda geliştirilen algoritmalar , ağı daha doğru bir şekilde modelleyin ve gecikmeyi optimize edin. QUIC, BBR'yi kullanmanıza ve bu algoritmayı kullanıldıkça güncellemenize olanak tanır. .
- kayıpların yenilenmesi. QUIC iki TLP'yi çağırır () RTO tetiklenmeden önce - kayıplar çok belirgin olduğunda bile. Bu, TCP uygulamalarından farklıdır. TLP, hızlı yenilemeyi tetiklemek için esas olarak son paketi (veya varsa yeni paketi) yeniden iletir. Kuyruk gecikmelerinin ele alınması, Uber'in ağını işletme şekli açısından, yani kısa, düzensiz ve gecikmeye duyarlı veri aktarımları açısından özellikle faydalıdır.
- ACK'yi optimize etti. Her paketin kendine özgü bir sıra numarası olduğundan herhangi bir sorun yaşanmaz. Paketler yeniden iletildiklerinde. ACK paketleri ayrıca paketi işlemek ve istemci tarafında bir ACK oluşturmak için gereken zamanı da içerir. Bu özellikler QUIC'in RTT'yi daha doğru hesaplamasını sağlar. QUIC'deki ACK, 256'ya kadar bandı destekler gönderenin paket karıştırmaya karşı daha dayanıklı olmasına ve süreçte daha az bayt kullanmasına yardımcı olur. Seçici ACK () TCP'de bu sorunu her durumda çözmez.
- bağlantı geçişi. QUIC bağlantıları 64 bitlik bir kimlikle tanımlanır; böylece bir istemci IP adreslerini değiştirirse eski bağlantı kimliği kesintisiz olarak yeni IP adresinde kullanılmaya devam edebilir. Bu, kullanıcının Wi-Fi ve hücresel bağlantılar arasında geçiş yaptığı mobil uygulamalar için çok yaygın bir uygulamadır.
QUIC'e alternatifler
QUIC'i seçmeden önce sorunu çözmek için alternatif yaklaşımları değerlendirdik.
Denediğimiz ilk şey, kullanıcılara daha yakın olan TCP bağlantılarını sonlandırmak için TPC PoP'ları (Varlık Noktaları) dağıtmaktı. Temel olarak PoP'lar, hücresel ağa daha yakın bir mobil cihazla TCP bağlantısını sonlandırır ve trafiği orijinal altyapıya geri gönderir. TCP'yi daha yakın sonlandırarak potansiyel olarak RTT'yi azaltabilir ve TCP'nin dinamik bir kablosuz ortama daha duyarlı olmasını sağlayabiliriz. Ancak deneylerimiz, RTT ve kaybın çoğunun hücresel ağlardan geldiğini ve PoP kullanımının önemli bir performans artışı sağlamadığını gösterdi.
Ayrıca TCP parametrelerinin ayarlanmasına da baktık. TCP'nin farklı işletim sistemi sürümlerinde farklı uygulamaları olduğundan, heterojen uç sunucularımızda bir TCP yığını oluşturmak zordu. Bunu uygulamak ve farklı ağ yapılandırmalarını test etmek zordu. İzin eksikliği nedeniyle TCP'yi doğrudan mobil cihazlarda yapılandırmak mümkün olmadı. Daha da önemlisi, 0-RTT bağlantıları ve geliştirilmiş RTT tahmini gibi özellikler protokolün mimarisi açısından kritik öneme sahiptir ve bu nedenle yalnızca TCP'yi ayarlayarak önemli faydalar elde etmek imkansızdır.
Son olarak, video akışı sorunlarını gideren birkaç UDP tabanlı protokolü değerlendirdik; bu protokollerin bizim durumumuzda yardımcı olup olmayacağını görmek istedik. Ne yazık ki, birçok güvenlik ayarında ciddi eksiklikler vardı ve ayrıca meta veriler ve kontrol bilgileri için ek bir TCP bağlantısı gerektiriyorlardı.
Araştırmamız, QUIC'in hem güvenliği hem de performansı hesaba katarak İnternet trafiği sorununa yardımcı olabilecek belki de tek protokol olduğunu gösterdi.
QUIC'in platforma entegrasyonu
QUIC'i başarıyla yerleştirmek ve zayıf bağlantı ortamlarında uygulama performansını artırmak için eski yığını (TLS/TCP üzerinden HTTP/2) QUIC protokolüyle değiştirdik. Ağ kütüphanesini kullandık arasında , protokolün orijinal Google sürümünü içeren gQUIC. Bu uygulama aynı zamanda en son IETF spesifikasyonunu takip edecek şekilde sürekli olarak geliştirilmektedir.
QUIC desteği eklemek için ilk olarak Cronet'i Android uygulamalarımıza entegre ettik. Entegrasyon, göç maliyetlerini mümkün olduğunca azaltacak şekilde gerçekleştirildi. Kütüphaneyi kullanan eski ağ yığınını tamamen değiştirmek yerine Cronet'i OkHttp API çerçevesi ALTINA entegre ettik. Entegrasyonu bu şekilde yaparak, ağ çağrılarımızda (şirketlerin kullandığı) değişikliklerden kaçındık. ) API düzeyinde.
Android cihazlara yönelik yaklaşıma benzer şekilde, Cronet'i iOS'taki Uber uygulamalarına uyguladık ve ağdan gelen HTTP trafiğini yakaladık kullanma . iOS Foundation tarafından sağlanan bu soyutlama, protokole özel URL verilerini işler ve Cronet'i önemli geçiş maliyetleri olmadan iOS uygulamalarımıza entegre edebilmemizi sağlar.
Google Cloud Balancer'larda QUIC'i tamamlama
Arka uç tarafında, QUIC tamamlama, Google Cloud Yük dengeleme altyapısı tarafından sağlanır. QUIC'i desteklemek için yanıtlardaki başlıklar. Genel olarak dengeleyici, her HTTP isteğine bir alt-svc başlığı ekler ve bu, alan adı için QUIC desteğini zaten doğrular. Bir Cronet istemcisi bu başlıkla bir HTTP yanıtı aldığında, o etki alanına yönelik sonraki HTTP istekleri için QUIC'yi kullanır. Dengeleyici QUIC'yi tamamladıktan sonra altyapımız bu eylemi HTTP2/TCP üzerinden veri merkezlerimize açıkça gönderir.
Performans: Sonuçlar
Çıkış performansı, daha iyi bir protokol arayışımızın ana nedenidir. Başlangıç olarak bir stand oluşturduk. QUIC'in farklı ağ profilleri altında nasıl davranacağını öğrenmek için. QUIC'nin gerçek dünya ağlarındaki performansını test etmek için, Yeni Delhi'de dolaşırken, yolcu uygulamasındaki HTTP çağrılarına çok benzeyen taklit ağ trafiğini kullanarak deneyler yaptık.
Deney 1
Deney için ekipman:
- sırasıyla TCP ve QUIC üzerinden HTTPS trafiğine izin verdiğimizden emin olmak için Android cihazlarını OkHttp ve Cronet yığınlarıyla test edin;
- yanıtlarda aynı tür HTTPS başlıklarını gönderen ve istemci cihazlarını onlardan istek alacak şekilde yükleyen Java tabanlı bir emülasyon sunucusu;
- TCP ve QUIC bağlantılarını sonlandırmak için fiziksel olarak Hindistan'a yakın bulunan bulut proxy'leri. TCP sonlandırma için ters proxy kullandık QUIC için açık kaynaklı bir ters proxy bulmak zordu. Chromium'un temel QUIC yığınını kullanarak QUIC için kendimiz için bir ters proxy oluşturduk ve açık kaynak olarak kroma dönüştürdü.
Şekil 6. TCP ve QUIC yol testi paketi, OkHttp ve Cronet içeren Android cihazlardan, bağlantıları sonlandırmak için bulut proxy'lerden ve bir emülasyon sunucusundan oluşuyordu.
Deney 2
Google QUIC'i kullanıma sunduğunda , aynı envanteri kullandık, ancak bir değişiklikle: NGINX yerine, cihazlardan TCP ve QUIC bağlantılarını sonlandırmak ve HTTPS trafiğini emülasyon sunucusuna yönlendirmek için Google yük dengeleyicilerini aldık. Dengeleyiciler dünyanın her yerine dağıtılmıştır ancak cihaza en yakın PoP sunucusunu kullanır (coğrafi konum sayesinde).
Şekil 7. İkinci deneyde TCP ve QUIC'nin tamamlanma gecikmesini karşılaştırmak istedik: Google Cloud kullanarak ve bulut proxy'mizi kullanarak.
Sonuç olarak bizi birkaç açıklama bekliyordu:
- PoP yoluyla sonlandırma, TCP performansını iyileştirdi. Dengeleyiciler TCP bağlantılarını kullanıcılara daha yakın bir yerde sonlandırdığından ve yüksek düzeyde optimize edildiğinden, bu daha düşük RTT'lerle sonuçlanır ve bu da TCP performansını artırır. QUIC daha az etkilenmesine rağmen kuyruk gecikmesini azaltma açısından TCP'den daha iyi performans gösterdi (yüzde 10-30).
- kuyruklar etkilenir . QUIC proxy'miz cihazlardan Google'ın yük dengeleyicilerine göre daha uzakta olmasına rağmen (yaklaşık 50 ms daha yüksek gecikme), benzer performans sağladı; TCP için 15. yüzdelik dilimde %20'lik bir azalmaya karşılık gecikmede %99'lik bir azalma. Bu, son mil geçişinin ağda bir darboğaz olduğunu gösteriyor.
Şekil 8: İki deneyden elde edilen sonuçlar, QUIC'nin TCP'den önemli ölçüde daha iyi performans gösterdiğini göstermektedir.
Trafikle mücadele
Deneylerden ilham alarak Android ve iOS uygulamalarımızda QUIC desteğini hayata geçirdik. Uber'in faaliyet gösterdiği şehirlerde QUIC'in etkisini belirlemek için A/B testi gerçekleştirdik. Genel olarak her iki bölgede, telekom operatörlerinde ve ağ türünde kuyruk gecikmelerinde önemli bir azalma gördük.
Aşağıdaki grafikler, makro bölgeye ve farklı ağ türlerine (LTE, 95G, 99G) göre kuyruklardaki yüzdelik iyileşmeleri (yüzde 3 ve yüzde 2) göstermektedir.
Şekil 9. Savaş testlerinde QUIC, gecikme açısından TCP'den daha iyi performans gösterdi.
Sadece ileri
Belki de bu sadece bir başlangıçtır; QUIC'in üretime sunulması, hem kararlı hem de kararsız ağlarda uygulama performansını artırmak için inanılmaz fırsatlar sağladı:
Arttırılmış kapsam
Protokolün gerçek trafik üzerindeki performansını analiz ettiğimizde oturumların yaklaşık %80'inin QUIC'i başarıyla kullandığını gördük. Tüm oturumların %15'i QUIC ve TCP kombinasyonunu kullanıyordu. Gerçek UDP hataları ile zayıf ağ koşulları arasında ayrım yapamadığı için, birleşimin Cronet kitaplığının TCP'ye geri zaman aşımına uğramasından kaynaklandığını varsayıyoruz. Şu anda QUIC'in daha sonra uygulanmasına yönelik çalışırken bu soruna bir çözüm arıyoruz.
QUIC optimizasyonu
Mobil uygulamalardan gelen trafik gecikmeye duyarlıdır ancak bant genişliğine duyarlı değildir. Ayrıca uygulamalarımız öncelikle hücresel ağlarda kullanılmaktadır. Deneylere göre, kullanıcılara yakın TCP ve QUIC'yi sonlandırmak için bir proxy kullanılmasına rağmen kuyruk gecikmeleri hala yüksek. Aktif olarak tıkanıklık yönetimini iyileştirmenin ve QUIC kayıp kurtarma algoritmalarının verimliliğini artırmanın yollarını arıyoruz.
Bunlar ve diğer birçok iyileştirmeyle, ağ ve bölgeden bağımsız olarak kullanıcı deneyimini geliştirmeyi, rahat ve kesintisiz paket aktarımını dünya çapında daha erişilebilir hale getirmeyi planlıyoruz.
Kaynak: habr.com