- Yüksek hızlı kablolu ağlar, WiFi 6/7 ve 5G gibi bağlantı başına 500 Mbps~1 Gbps üzeri hızların mümkün olduğu ortamlarda UDP+QUIC+HTTP/3 yığını, TCP+TLS+HTTP/2’ye göre en fazla %45,2 daha düşük veri aktarım hızı gösteriyor
- Basit dosya indirmelerinin ötesinde; Chrome, Edge, Firefox, Opera ile masaüstü ve mobil ortamlarda bant genişliği arttıkça QUIC ile HTTP/2 arasındaki performans farkı büyüyor
- Paket izleme ve çekirdek/kullanıcı alanı profillemesi sonuçlarına göre darboğaz, gönderici taraftan çok alıcı taraf işlem yüküne daha yakın; QUIC alımında daha fazla paket ve kullanıcı alanında ACK işleme gerçekleşiyor
- Uygulama etkisi, DASH videoda en fazla %9,8 bit hızı düşüşü ve en popüler 100 web sitesi ortalamasında %3,0 daha uzun sayfa yükleme süresi olarak ortaya çıkıyor
- Azaltma için alıcı tarafta UDP GRO dağıtımı, GSO/GRO’nun QUIC’e uygun şekilde iyileştirilmesi, alım mantığının geliştirilmesi ve birden fazla CPU çekirdeğinin kullanılması gerekiyor; ancak istemci cihazları ve işletim sistemlerinin çeşitliliği bunu hayata geçirmeyi zorlaştırıyor
Yüksek hızlı ağlarda ortaya çıkan QUIC performans farkı
- QUIC, UDP üzerinde çalışan çoklamalı bir aktarım katmanı protokolüdür ve HTTP/3’ün aktarım temeli olarak IETF tarafından standartlaştırılmıştır
- Google, Akamai, Meta, Cloudflare gibi birçok şirket 2013’ten bu yana QUIC’i ticari olarak devreye alıyor; QUIC, HTTP/3 ile birlikte web performansını değiştirebilecek adaylardan biri olarak dikkat çekiyor
- Mevcut QUIC performans araştırmalarında uygulamalar, hesaplama ortamları ve ağ koşulları çeşitlilik gösteriyordu; çalışmaların çoğu düşük iş hacimli kullanım senaryolarına odaklanıyordu
- Ölçümlerin odağı, yüksek hızlı kablolu bağlantılar, WiFi 6/7 ve 5G gibi bağlantı başına 500 Mbps üzeri veya 1 Gbps üzeri hıza ulaşan yüksek hızlı ağlarda QUIC’in davranışı
- Karşılaştırma tek bir protokolü değil, tüm yığını kapsıyor
- QUIC tarafı: UDP+QUIC+HTTP/3
- Geleneksel taraf: TCP+TLS+HTTP/2
- Özetle bunlar sırasıyla QUIC ve HTTP/2 olarak adlandırılıyor
Dosya indirme deneylerinde görülen fark
- cURL ve Chromium tabanlı
quic_clientkullanılarak yapılan basit dosya indirme deneylerinde, tıkanıklık kontrol algoritması, sunucu yapılandırması ve ağ koşulları eşitlenerek karşılaştırma yapıldı - Bant genişliğinin görece düşük olduğu yaklaşık 600 Mbps altı seviyelerde QUIC ve HTTP/2 performansı benzerdi; daha yüksek bant genişliklerinde ise QUIC’in iş hacmi HTTP/2’den en fazla %15,7 daha düşük oldu
- Bant genişliği arttıkça performans farkı daha belirginleşti; paket alımı sırasında QUIC, modern istemci makinelerde HTTP/2’ye göre çok daha yüksek CPU kullanımı gösterdi
- Başlıca tarayıcı deneylerinde fark daha da büyüdü
- Hedef tarayıcılar Chrome, Edge, Firefox, Opera idi
- Chrome’da bant genişliği yaklaşık 500 Mbps’yi aşınca QUIC geride kalmaya başladı
- Bant genişliği 1 Gbps’ye ulaştığında QUIC, HTTP/2’den %45,2 daha yavaş oldu
- Mobil gibi daha zayıf istemcilerde fark daha da büyüdü
Web uygulamalarındaki etkisi
- Performans düşüşü yalnızca büyük dosya aktarımlarıyla sınırlı kalmıyor; aralıklı trafik desenlerine sahip uygulamalarda da görülüyor
- DASH video parçaları yüksek hızlı Ethernet ve 5G üzerinden iletilirken QUIC, HTTP/2’ye kıyasla en fazla %9,8 daha düşük video bit hızı gösterdi
- Bu QoE düşüşü yalnızca temel bant genişliği yeterince yüksek olduğunda ortaya çıkıyor
- 4G’de etki görünmez hale geliyor
- 5G’de etki ortaya çıkıyor
- Web gezintisi deneylerinde, en popüler 100 web sitesinin ortalamasında QUIC’in sayfa yükleme süresi (PLT) HTTP/2’den %3,0 daha uzun oldu
- Uzun kuyrukta sayfa yükleme süresi farkının %50’yi aştığı örnekler de var
Darboğazın nedeni: alıcı taraf işleme ve kullanıcı alanı ACK
- Paket izleri ve performans verileri, QUIC istemcisinin HTTP/2 indirmesine kıyasla çok daha fazla paket aldığını gösteriyor
- QUIC yüksek veri aktarım hızıyla alım yaparken gelen veri paketleri ile bunlara karşılık gelen ACK paketleri arasındaki gecikme büyüyor; bu da QUIC paket işleme süresini artırıyor
- Bu iki gözlem, yüksek hızlı internette QUIC performans düşüşünün nedeninin alıcı taraf işlem kapasitesi sınırı olduğuna işaret ediyor
- Alıcı tarafın darboğaz olarak gösterilmesinin iki nedeni var
- Sunucular genellikle masaüstü, dizüstü ve akıllı telefon gibi istemcilerden daha güçlüdür
- QUIC tasarımı gereği veri alma işlemede kendine özgü zorluklara sahiptir
- Derin profillemede iki ana neden belirlendi
- Aşırı veri paketi
- Aynı dosya indirilirken çekirdek içindeki UDP yığını, TCP’ye göre çok daha fazla
netif_receive_skbpaket okuması üretiyor - İncelenen QUIC uygulamalarının hiçbiri UDP generic receive offload, yani UDP GRO kullanmıyor
- UDP GRO, bağlantı katmanı modülünün birden fazla alınan UDP datagramını aktarım katmanına geçirmeden önce tek bir büyük datagramda birleştirmesi yöntemidir
- Bu durum, TCP segmentation offload’un yaygın biçimde dağıtılmış olması ve UDP gönderici taraf offload’u olan GSO’nun son dönemde öne çıkarılmasıyla tezat oluşturuyor
- Aynı dosya indirilirken çekirdek içindeki UDP yığını, TCP’ye göre çok daha fazla
- Kullanıcı alanında ACK işleme
- Kullanıcı alanında QUIC, alınan paketlerin işlenmesi ve yanıt üretilmesi için daha yüksek ek yük taşıyor
- Nedenler arasında çekirdekten gelen aşırı paket sayısı, QUIC ACK’lerinin kullanıcı alanında işlenmesi ve QUIC’te delayed ACK gibi bazı optimizasyonların bulunmaması yer alıyor
- Aşırı veri paketi
Ön ölçümler ve azaltma yönleri
- Chrome tarayıcıda 1 GB dosya indirmeye yönelik ön deney, QUIC etkinleştirildiğinde indirme süresinin yaklaşık iki katına çıktığını gösterdi
- Örnek sonuçlar 10 çalıştırmanın ortalamasıdır
- Masaüstü Ethernet: HTTP/2 9,32 saniye, HTTP/3 18,60 saniye ile %99 artış; CPU kullanımı %77,5’ten %96,9’a çıktı
- Pixel 5 low-band 5G: HTTP/2 37,11 saniye, HTTP/3 78,65 saniye ile %112 artış; CPU kullanımı %121,55’ten %161,77’ye çıktı
- Pixel 5 mmWave 5G: HTTP/2 30,10 saniye, HTTP/3 63,20 saniye ile %110 artış; CPU kullanımı %128,43’ten %165,20’ye çıktı
- Masaüstü CPU kullanımı tarayıcının ağ servisi bazındadır; akıllı telefon ölçümü ise tüm tarayıcı süreci bazındadır
- CPU kullanımının %100’ü aşması, çok çekirdekli sistemde tarayıcı sürecinin birden fazla çekirdek kullandığı anlamına gelir
- Önerilen azaltma yöntemleri; alıcı tarafta UDP GRO dağıtımı, GSO ve GRO’nun QUIC’e uygun şekilde iyileştirilmesi, alıcı taraf QUIC mantığının geliştirilmesi ve QUIC veri alımının birden fazla CPU çekirdeği üzerinden yapılmasıdır
- İstemci makineler; PC’ler, mobil cihazlar, gömülü cihazlar ve çeşitli işletim sistemlerinden oluştuğu için sunuculara göre daha heterojendir; bu yüzden azaltma yöntemlerini hayata geçirmede pratik zorluklar vardır
- Ölçüm verileri ve kaynak kodu ilgili araştırmayla birlikte yayımlanmıştır
1 yorum
Hacker News yorumları
Sektör, hafif siteler yapmak dışında her şeyi yapmaya çalışıyor gibi
90’ların sonunda bile hızlı bir bağlantınız varsa internet anında tepki verirdi; sayfalar küçüktü ve neredeyse hiç JavaScript yoktu
Bugün de böyle hızlı, hafif sayfalar bulabiliyorsunuz; fare düğmesini bırakmadan sayfa tamamen yüklenmiş gibi hissettirdiği için neredeyse gerçeküstü geliyor
Kullanıcı deneyimi iyileşmiş olsaydı buna katlanılabilirdi, ama onu da elde etmedik
Daha hızlı ve çok daha sağlam hale geldi; frontend ile backend arasındaki durum tutarsızlıkları da ortadan kalktı
Kolaylık için asgari düzeyde JavaScript’e izin veriyorum; şu anda birkaç yüz satır civarında ve hâlâ tek sayfa uygulama gibi görünmesi için biraz daha ekleyeceğim
Böylece yaklaşık 40 bin satır React ve yaklaşık 20 bin satır Kotlin’i kaldırabiliyorum, ama backend kodunun yaklaşık 30 bin satırını yeniden yazmam gerekiyor
Yine de hoşuma gidiyor
Bu yüzden deneyim kazanmak için ana sayfamı statik bir VUE.JS sürümüne taşımayı denedim; ama değişken adlarını string olarak geçirip view ile state’i bağlama biçimi tuhaftı, build ortamını genişletmek gereksiz yere karmaşıktı, her şey yavaştı ve her şeyi belirli bir şekilde yapmak gerekiyordu
Herkes kullandığına göre doğrudur diye düşünmüştüm, ama artık o bakış açısından çıktım ve yeni sürümü ham HTML ile statik site oluşturucu şablonlarıyla tamamladım
HTML boyutu %90 azaldı, JS kullanımı %97 düştü ve build süresi 20 saniyeden 2 saniyeye indi
Kullanıcı deneyimi de iyileşti; yeni sürümden sonra ziyaretler %30 arttı
Web’i daha az kullanırsanız web çok daha harika olabilir
Backend tarafında da günümüzde altın yumurtlayan tavuk, API’lerle bağlanan headless SaaS ürünleri üzerinden mikroservis satmak; performansın da zaten iyi olacağı varsayılıyor
https://macharchitecture.com/
İnsanlar böyle kürekler satın almak istiyorsa, IT dünyasında bizim de bu kürekleri stoklamaktan başka çaremiz yok
Blog, statik olarak render edilen bir Hugo sitesi olduğu için hiç JS yok; projeler ise Rails ve sunucuda render edilen HTML tabanlı, yalnızca olsa iyi olur denecek özellikler için asgari JS içeriyor
JS olmasa da çalışıyor
Kendi sitem olduğu için söylüyor olabilirim ama deneyim web’in büyük kısmından çok daha iyi ve çok fazla şey kaybettik
Google bir zamanlar tamamen JS tabanlı bir Speedtest yapmıştı
O dönemde Ookla hâlâ Flash tabanlıydı, bu yüzden Chromebook’ta çalışmıyordu ve kurulumdan sorumlu kişi için kurulum durumunu doğrulamak sorun oluyordu
Bu süreçte TCP’nin çeşitli etkenlere nasıl tepki verdiği hakkında çok şey öğrendim
Bu yazının sonucu neredeyse beklediğim gibi; çünkü akış kontrolünü çekirdekten ve belki de ağ adaptöründen kullanıcı alanına itmiş oluyor
TCP’de akış kontrolü ve sıralama garantisi var; QUIC ise bunları doğrudan sizin yönetmenizi sağlıyor sayılır
Elbette bunun için iyi nedenler de var
TCP tıkanıklık kontrolünün modern bağlantı hızlarının gerisinde kaldığı bilinir; BBR gibi yeni algoritmalar da çıktı ama bunların bir maliyeti var [1]
Ağ testlerinde veya web uygulaması testlerinde çok sık gözden kaçan temel nokta gecikmedir
Asya’da ya da Avustralya’da yaşayan biriyseniz 100 ms gidiş-dönüş gecikmenin ne kadar yıkıcı olabildiğini bilirsiniz
Tamamen tepkisel olan bir şeyi hiç kullanılamaz hale getirebilir; pencereleme nedeniyle bağlantının destekleyebileceği bant genişliğini düşürür, hata ve tıkanıklık kontrolüne karşı da hantallaştırır
Bir ağı veya web uygulamasını test ediyorsanız gecikmeye rastgele 100 ms ekleyen testleri şiddetle öneririm [2]
Bu yüzden QUIC’in ek yükü pratikte önemli olmayabilir
Çünkü tek bir TCP bağlantısında veya QUIC akışında etkin bant genişliği, gerçek ham bant genişliğinden çok daha düşük olabilir
Başka bir deyişle, %45 ek veri olsa bile tıkanıklık kontrolünü doğrudan yöneterek iki nokta arasındaki etkin hız daha yüksek hale geliyorsa bu kazançlı olabilir
[1]: https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...
[2]: https://bencane.com/simulating-network-latency-for-testing-i...
Geriye dönüp bakınca bariz ama TCP’de “çekirdek, şu devasa tamponu gönderiver” demek yeterliyken, UDP paket alışverişi yöntemi olduğundan 0 göndermek bile çoğu işletim sistemi ve tüketici donanımında mod geçişi yüzünden CPU açısından maliyetli
Etrafından dolaşmanın yolları var ama kolay değiller; deneyimime göre henüz yeterince hazır da değiller ve kullanabileceğiniz dil, kütüphane ve platform seçeneklerini de kısıtlıyorlar
Ek olarak, MacBook’u pille kullanırken aktarım hızının ciddi şekilde düştüğünü gördüm; muhtemelen verimlilik çekirdekleriyle ilgili gibi duruyor
İkincisi, QUIC tıkanıklık kontrolünü iyi yapamadı
quic-go kullandığım için ortama göre değişebilir ama hiçbir ayar ciddi şekilde yardımcı olmadı ve TCP akışlarıyla birlikteyken TCP daha fazla bant genişliği aldı
Üçüncüsü, API garip
QUIC’in kendisi birden fazla akışa sahip olduğu için TCP’nin bire bir tak-çalıştır ikamesi değil
Yalnızca HTTP/3’ü daha üst katmanda tak-çalıştır bir ikame yapma niyeti var; onu denemediğim için bir şey söyleyemem
Akış düzeyinde çalışıyorsanız akılda tutmaya değer
Sonuçta epey yenilmiş gibi hissettim ama aynı zamanda eski dost TCP’nin optimizasyonlarına ve dayanıklılığına yeniden saygı duydum
Gerçekten şaşırtıcı bir teknoloji ve işletim sistemi bunu her zaman ücretsiz sunuyor
TCP’nin başlıca sorunlarından bazıları da tasarım kusurundan çok muhafazakâr ya da legacy varsayılanlardan kaynaklanıyor
Linux’taki tampon sınırları, Nagle gibi şeyler
Tekerleği yeniden icat etmek yerine keşke sadece TCP’yi iyileştirebilsek
[1]: https://payload.app/
QUIC’in yola çıkabilmesi için gerekli bir karardı ama artık var olduğuna göre yeniden değerlendirilebilir
QUIC’i çekirdekte uygulamanın teknik bir engeli yok; performans avantajı büyükse birileri çok yakında neredeyse kesinlikle bunu yapacaktır
Fark geceyle gündüz gibi
Slow/Fast 4G ve 3G ön ayarları var; ayrıca indirme/yükleme hızını, ms cinsinden gecikmeyi, paket kayıp oranını, paket kuyruk uzunluğunu doğrudan belirleyebileceğiniz ve paket yeniden sıralamayı açabileceğiniz özel ön ayarlar oluşturabilirsiniz
curl’ün yaratıcısı ve bakımcısı Daniel Stenberg’in birkaç ay önce curl’de HTTP/3 hakkında yazdığı bir yazı var: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...
Vurguladığı noktalardan biri HTTP/3’ün daha yüksek CPU kullanımıydı; CPU, aktarım hızını sınırlayacak düzeydeydi
Bunun ne kadarının uygulamanın olgunlaşmamış olmasından, ne kadarının QUIC tasarımının kendi özelliklerinden kaynaklandığını merak ediyorum
Üçüncü öneri UDP GRO; gelen UDP paketlerini birleştirerek paket başına yapılan işi azaltıp grup başına yapılan işe dönüştürmek için çekirdeği, ideal olarak da NIC donanımını değiştirmek anlamına geliyor
TCP’de bu zaten var; gönderici tarafta da TSO ve Linux’taki GSO gibi benzer şeyler bulunuyor
Bu da olgunlaşmamışlık gibi hissettiriyor, ancak donanım özelliği eksikliği ihtimali düşünülürse düzeltilmesi daha zor olabilir
Özet, QUIC’in ACK yönteminin maliyetinden bahsediyor ama o argümana ayrıntılı bakmadım
Modern TCP tabanlı sunucularda görülebilen başka bir özellik de TLS’in donanıma offload edilmesi
Aynı anda çok sayıda TCP stream’i gönderen sunucularda daha önemli görünüyor
Linux’ta bu, kullanıcı alanı ağ yığını kullanarak ya da ‘kernel tls’ üzerinden mümkün; mümkünse donanıma offload ediliyor
Bu özellik, TCP stream’lerini ‘mesajlara’ bölüp farklı iş parçacıklarına göndermeyi sağlayan Linux’a özgü bir özellikle de ilişkili; ancak önceki bir paket kaybolduğunda arkadaki mesajların önceden iletilip iletilemeyeceğini bilmiyorum
Amacının tüm bağlantıları daha hızlı hâle getirmek olduğu izlenimini hiç almadım
Bu açıdan bakınca ödünleşimler mantıklı geliyor
Uzman değilim; daha iyi bilen biri düzeltirse sevinirim
QUIC, internetteki tüm donanımın ve ara katmanların yeni bir TCP ya da TLS standardını desteklemesini sağlamanın hiçbir yolu olmadığı için ortaya çıktı
Bu yüzden QUIC, UDP üzerinde yeni bir aktarım standardını eski internet donanımının üstüne yerleştiren zarif bir çözüm
İdeal bir dünyada yeni TCP ve TLS standartları oluşturur, dünyadaki tüm internet yönlendiricilerini ve donanımlarını değiştirir ya da günceller, bunu da daha düşük CPU kullanımıyla uygular olurduk
Testte CPU’ya takılan quiche 200MB/s’nin altında kalırken nghttp2 900MB/s’yi aştı
CPU’nun throttling’e girip girmediğini merak ediyorum
HTTP/3 uygulaması CPU’yu 4 kat kullanıyorsa bu ilginç; ama mutlak değerler en başta çok düşükse illa büyük bir sorun olmayabilir
“Hızlı internette UDP+QUIC+HTTP/3 yığını, TCP+TLS+HTTP/2’ye kıyasla veri hızını en fazla %45,2 düşürüyor” kısmı kilit nokta; makalenin tamamını henüz okumadım ama giriş bölümünde 600Mbit/s altını yavaş internet olarak görüyor gibi
Cloudflare örneğinde, yalnızca istemci <> edge arasında QUIC’i destekliyor, origin bağlantılarında desteklemiyor
Edge <> origin bağlantısı yeniden kullanılabilir, kararlı ve “hızlı” ise bu mantıklı
https://developers.cloudflare.com/speed/optimization/protoco...
Protokolün kendisinde temel bir sorun varmış gibi gelmiyor
Ancak bu tür gecikme sorunları, CPU’yu boost etmeye iten CPU kullanım sorunlarının aksine pil tüketimini ciddi ölçüde artırmaz
Sunucular arası iletişimde de sorun değil
Temelde son kullanıcı cihazlarında, 2024 itibarıyla bile çok hızlı bağlantılar kullanılırken yüksek bant genişlikli aktarımın “yavaşlaması” söz konusu
Burada bahsedilen hız, reklamla satılan hız değil; gerçek cihazdan sunucuya kadar olan etkin hız
Bu, makalenin işe yaramaz olduğu anlamına gelmiyor; tarayıcı uygulamalarının iyileştirilmesi gerekiyor ve bunu iyi gösteriyor
Ancak makale başlığı neredeyse %100 clickbait
Gigabit internet yaygınlaşırken daha yavaş bir aktarım yöntemine geçmek açıkça hata
30 yıl sonra daha da hızlı olacak; hat hızını tam kullanmak için daha eski protokolleri kullanmak zorunda kalırsak bu aptalca olur
Aynı yazı eylülde de paylaşılmıştı: QUIC is not quick enough over fast internet (acm.org)
https://news.ycombinator.com/item?id=41484991 (327 yorum)
Brave/Vivaldi/Opera gibi tarayıcılar bilinçli olarak tercih edilmeli
Reklamlar hızlı ulaştığı sürece gerisi önemli değil gibi
Bu gerçekten çok tuhaf geliyor
Sadece QUIC+HTTP/3 ile de, yalnızca QUIC ile de 900mbps hızına ulaştığım oldu
Kötü bir TLS uygulaması ya da verimli olmayan erken dönem bir uygulama gibi görünüyor
CPU kullanımı 2. nesil EPYC çekirdeğinde yaklaşık %5 civarındaydı; oldukça ortalamaydı
Bir anekdot olarak, wordpress.org’a erişimde sorun yaşanmıştı.
Wordpress’i ilk kullanmaya başladığımda belgeleri sorunsuz okuyabiliyordum, ama bir noktadan sonra web sitesine hiç erişemez oldum.
Linux ile çift önyükleme yaptığım için bunun bir Windows sorunu olmadığı belliydi; ping sorunsuzdu ve üç farklı tarayıcı denememe rağmen sonuç aynıydı.
Siteye girdiğimde sayfa takılı kalıp hiç yüklenmiyor ya da bazen sayfa yarıda yüklenmeyi durduruyordu.
Bugün çözümü buldum: Chrome ayarlarında Experimental QUIC Protocol’ü kapatmak.
Aylardır wordpress.org’a erişim sorunu yaşıyordum ve bunun QUIC’ten kaynaklandığına dair hiçbir belirti olmaması endişe verici.
Geliştirici araçlarında QUIC ile ilgili hataların yalnızca ara sıra görünmesi sayesinde bunu zar zor fark ettim.
Bu protokol yüzünden erişilemez hâle gelen, kullanıcıların da nedenini bilmediği başka kaç web sitesi vardır merak ediyorum.
Buradaki hızlı internet 500Mbps demek; nedeni de QUIC’in bunun üzerindeki hızlarda CPU’ya takılıyormuş gibi görünmesi.
Test sisteminin sıradan tüketici sınıfı bir sistem olup olmadığına ya da yüksek performanslı bir masaüstünde de sorunun hâlâ yaşanıp yaşanmadığına bakacak kadar ayrıntıya girmedim.
Komik olan şu: Ayrıntıları pek bilmesek de hızlı = iyi diye “QUIC yeni HTTP/2’dir” gibi bir düşünceyi örtük biçimde kabul ediyoruz.
Yeni 5G telefonun 4G’den birkaç kat hızlı olduğu söylenince onu satın almaya benziyor.
Oysa 1) benim 4G telefonum hiçbir zaman 4G’nin azami hızında çalışmadı ve 2) bağlantı sorunları neredeyse her zaman internet hattının hızından değil; DNS sunucusundan, hedef web sitesinden ya da operatör tarafındaki bağlantı çoğullama ekipmanından kaynaklanıyor.
Yine de mesele “ama bu 5G”ye dönüşüyor.
“Fiber broadband” reklamlarında insanların TV izlerken saçları rüzgârda uçuşuyormuş gibi gösterilmesi de komik.
Gerçekte böyle çalışmıyor.
Eskiden 8Mb bağlantıyla bile streaming yapıyorduk; dolayısıyla 300Mb bazı işler için iyi olabilir, ama büyük bir fark hissedilir mi şüpheli.
QUIC’te TLS olmayan bir mod olmasını isterdim.
Yerel geliştirme sırasında bazen sadece hat üzerinden ne gidip geldiğini görmek istiyorum; bu da gereksiz yere çok fazla sürtünme ekliyor.
Bu yüzden onlar olmadan çalışamaz.