Hızlı internette bile yeterince hızlı olmayan QUIC teknolojisi

 (arxiv.org)
2 puan yazan GN⁺ 2024-10-20 | 1 yorum | WhatsApp'ta paylaş

QUIC, hızlı internette yeterince hızlı değil

  • Araştırma arka planı

    • QUIC'in web uygulamalarının performansını iyileştirmede önemli bir rol oynaması bekleniyor.
    • Bu makale, yüksek hızlı ağlarda QUIC'in performansını sistematik olarak inceliyor.

  • Başlıca bulgular

    • Yüksek hızlı internette UDP+QUIC+HTTP/3 yığını, TCP+TLS+HTTP/2'ye kıyasla veri aktarım hızında en fazla %45,2 düşüş gösteriyor.
    • Temel bant genişliği arttıkça QUIC ile HTTP/2 arasındaki performans farkı büyüyor.
    • Bu sorun yalnızca dosya aktarımını değil, video akışı (video bit hızında en fazla %9,8 düşüş) ve web gezintisi gibi çeşitli uygulamaları da etkiliyor.

  • Analiz yöntemi

    • Paket izleme analizi ile çekirdek ve kullanıcı alanı profillemesi üzerinden sorunun kök nedeni belirleniyor.
    • Alıcı taraftaki işlem yükünün yüksek olması, özellikle de aşırı veri paketleri ve QUIC'in kullanıcı alanındaki ACK'leri, sorunun nedeni olarak öne çıkıyor.

  • İyileştirme önerileri

    • Gözlemlenen performans sorunlarını hafifletmek için somut öneriler sunuluyor.

GN⁺ özeti

  • Bu makale, yüksek hızlı ağ ortamlarında QUIC'in performans sorunlarını analiz ederek web uygulaması performansını iyileştirmeye katkı sağlayabilecek önemli içgörüler sunuyor.
  • QUIC'in performans düşüşünün nedenini alıcı taraftaki işlem yükü olarak ortaya koyup bunu çözmek için somut yöntemler önererek ağ mühendisleri ve geliştiriciler için faydalı bilgiler sağlıyor.
  • Benzer işlevlere sahip diğer bir protokol olan HTTP/2 ile yapılan performans karşılaştırması üzerinden QUIC'in iyileştirme yönünü ortaya koyuyor.

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-20
Hacker News görüşleri

  • Sektör, hafif web siteleri yapmak dışında her şeyi deniyor. 90'ların sonlarında hızlı bir internet bağlantınız varsa sayfalar küçüktü ve neredeyse hiç JavaScript yoktu. Bugün bile bu tür hızlı yüklenen hafif sayfalar bulunabiliyor ve deneyim neredeyse gerçeküstü geliyor. Kullanıcı deneyimi daha iyi olsaydı buna daha fazla katlanılabilirdi.

  • Google'da saf JS Speedtest üzerinde çalıştım. O zamanlar Ookla Flash tabanlıydı, bu yüzden Chromebooks'ta çalışmıyordu. TCP'nin çeşitli etkenlere nasıl tepki verdiği hakkında çok şey öğrendim. Bu makaleyi görünce sonucun beklendiği gibi olduğunu düşündüm. Çünkü akış kontrolünü çekirdekten kullanıcı alanına itiyor. TCP'nin akış kontrolü ve sıralaması var. QUIC ise bunları kendisi yönetiyor. TCP tıkanıklık kontrolü modern bağlantı hızlarına uymuyor, bu yüzden BRR gibi yeni algoritmalar gerekiyor ama bunların bir maliyeti var. En büyük ders, ağ testlerinde gecikmenin önemini hafife almamak gerektiği. Asya'da ya da Avustralya'da yaşayanlar 100 ms RTT gecikmesinin ne kadar yıkıcı olabileceğini bilir. QUIC'in ek yükü pratikte önemli olmayabilir. Çünkü tek bir TCP bağlantısı veya QUIC akışı üzerinden elde edilen gerçek bant genişliği, ham bant genişliğinden çok daha düşük olabilir.

  • Curl'ün yaratıcısı ve bakımcısı Daniel Stenberg, HTTP/3 hakkında blogunda yazmıştı. HTTP/3'ün yüksek CPU kullanımını vurgulamış ve CPU'nun aktarım hızını sınırlayabileceğini belirtmişti. Bunun uygulamaların henüz olgunlaşmamış olmasından mı, yoksa QUIC'in tasarım biçiminden mi kaynaklandığını merak ediyorum.

  • Hızlı internette UDP+QUIC+HTTP/3 yığınının, TCP+TLS+HTTP/2'ye kıyasla veri aktarım hızını en fazla %45,2 düşürdüğü söyleniyor. Makalenin tamamını henüz okumadım ama 600 Mbit/s altının "yavaş internet" sayılması dikkat çekici.

  • QUIC'in hızlı internette yeterince hızlı olmadığı söyleniyor. quic+http3 ile 900mbps hıza ulaştım; sorun TLS uygulamasının kötü olması mı, yoksa ilk uygulamaların verimsizliği mi emin değilim. CPU kullanımı gen 2 epyc çekirdeğinde ortalama yaklaşık %5'ti.

  • Buradaki "hızlı internet" 500 Mbps demek ve söylenene göre quic CPU'ya bağımlı. Test sisteminin sıradan bir tüketici sistemi mi olduğunu, yoksa yüksek performanslı masaüstlerinde de sorun olup olmadığını kontrol etmedim.

  • QUIC'in gecikme süresine göre optimize edildiğini sanıyordum. Web sayfalarında ve video oyunlarında çok sayıda küçük paketi yüklemek için optimize edilmiş. Yalnızca toplam aktarım hızı ölçülünce yetersiz kalabilir. Protokol seviyesinde büyük dosya aktarımlarını veya yüksek bant genişlikli video akışını algılayıp daha az CPU yoğun bir şeye geçmenin mümkün olup olmadığını merak ediyorum. Ayrıca QUIC'in, donanım/işletim sistemi düzeyinde TCP kadar optimize edilmemiş olup olmadığını da merak ediyorum.

  • QUIC'in TLS'siz bir modu olmasını isterdim. Yerelde geliştirme yaparken bazen aktarılan trafiği görmek istiyorum ve bu gereksiz bir sürtünme ekliyor.