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

• QUIC, web uygulaması performansını iyileştirmede çığır açıcı bir değişim yaratması beklenen bir protokol olsa da performansı beklentilerin altında kalıyor
• Bu makale, yüksek hızlı ağlarda QUIC performansını sistematik olarak analiz ediyor

Özet

• 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
• QUIC ile HTTP/2 arasındaki performans farkı, temel bant genişliği arttıkça büyüyor
• Bu sorun, hafif veri aktarım istemcileri ve başlıca web tarayıcılarında (Chrome, Edge, Firefox, Opera), çeşitli ana sistemlerde (masaüstü, mobil) ve farklı ağlarda (kablolu geniş bant, hücresel) gözlemleniyor
• Yalnızca dosya aktarımını değil, video akışı (video bit hızında en fazla %9,8 düşüş), web'de gezinme gibi çeşitli uygulamaları da etkiliyor
• Ayrıntılı paket izleme analizi ile çekirdek ve kullanıcı alanı profillemesi sayesinde kök nedenler belirleniyor
• Özellikle, aşırı veri paketi yükü ve QUIC'in kullanıcı alanındaki ACK'leri nedeniyle alıcı tarafındaki işleme ek yükü yüksek
• Gözlemlenen performans sorunlarını hafifletmek için somut öneriler sunuluyor

Performans düşüşünün kök nedenleri

• Alıcı tarafında çekirdek düzeyinde aşırı paket işleme ek yükü oluşuyor
  • QUIC, UDP GRO (Generic Receive Offload) kullanmadığı için TCP'ye göre çok daha fazla paketi işlemek zorunda kalıyor
  • Bunun, QUIC'te netif_receive_skb fonksiyonu çağrı sayısının çok daha yüksek olmasıyla doğrulandığı belirtiliyor
• Kullanıcı alanında da QUIC'in aşırı paket işleme ek yükü oluşuyor
  • Çekirdekten iletilen çok sayıdaki paketi işlemenin ek yükü büyük
  • QUIC ACK'lerinin kullanıcı alanında oluşturulması da bu ek yükün nedenlerinden biri

Performans düşüşünü hafifletmeye yönelik öneriler

• Alıcı tarafında UDP GRO'nun devreye alınması
  • UDP yığınının işlemesi gereken paket sayısını azaltarak çekirdek ve kullanıcı alanı ek yükünü düşürmek
  • Ancak UDP GRO'yu farklı istemci ortamlarında devreye almak kolay olmayabilir
• GSO/GRO gibi offloading çözümlerini QUIC'e uygun şekilde iyileştirmek
  • Farklı boyutlardaki UDP paket trenlerinin de offloading kapsamında desteklenmesi
  • Ağ tıkanıklığını önlemek için GSO'ya uygun pacing ayarlarının eklenmesi
• Alıcı tarafındaki QUIC mantığını optimize etmek
  • QUIC ACK gönderimini geciktirerek yanıt üretme ek yükünü azaltmak
  • recvmmsg kullanarak bir seferde birden fazla UDP paketini okuyup performansı artırmak
• Çok iş parçacıklı indirme kullanmak
  • Büyük dosyalarda birden fazla CPU çekirdeğinden yararlanan çok iş parçacıklı indirme ile alım performansı artırılabilir
  • Ancak adalet sorunları dikkate alınmalı

[GN⁺]

Hacker News görüşü

• syscall arayüzü karmaşık ve temel API, normal boyuttaki paketlere (yaklaşık 1500 bayt) kıyasla fazla yavaş
  • GSO yardımcı oluyor, ancak API karmaşık ve yakın zamanda da çok sayıda hatası vardı
• Spectre azaltımları nedeniyle syscall maliyeti daha da yükseldi
  • BSD socket / POSIX API'nin yerini alacak bir şeye ihtiyaç var
  • uring karmaşık, ancak orta seviye bir API gerekli
• Sistem UDP tamponları varsayılan olarak fazla küçük
  • Bunu yalnızca uzmanlar kullanıyor ve uzmanlar ayarları değiştiriyor
• UDP yığını optimize edilebilir
  • GSO bunu gösteriyor, ancak GSO'nun kendisi pahalı ve karmaşık
• Şu anda kullanılabilen bazı optimizasyonlar yalnızca düşük/orta ölçekte çalışıyor
  • Örneğin, rota aramasından kaçınmak için bağlantı bağlama
• GSO uygulanırsa performans büyük ölçüde artabilir
  • Platform tarafındaki tampon boyutlarını artırmak gerekebilir
• QUIC'in ilk dönemlerinde UDP yığını, TCP yığınına kıyasla daha az optimize edilmişti
  • UDP generic receive offload gibi optimizasyonlara ihtiyaç var
• HTTP/2 de aceleyle yayımlanmış gibi görünüyor
  • Chrome, server push desteğini kaldırdı
  • Daha fazla düşünülmesi gerekiyor
• QUIC ve HTTP/2, ağ bant genişliği düşük olduğunda benzer performans gösteriyor
  • Bant genişliği 500Mbps'yi aştığında QUIC performansı düşüyor
  • Bu sorun çoğunlukla yerel ağlarda ortaya çıkıyor
• Google'ın işlem yükünü kullanıcılara yıkma eğilimi var
  • Örneğin AV1 video codec'i, tüketicilerde HW decoding özelliği yokken dağıtıldı
• Araştırma makalesi arXiv'de bulunuyor
  • https://arxiv.org/pdf/2310.09423
• RTT'nin 0.23ms olduğu bir ping'den söz ediliyor
  • Yüksek gecikmede bile QUIC en iyisi
• RFC9000'ü okumak zor ve karmaşık
  • QUIC'in yüksek seviyeli fikri basit, ancak spesifikasyon çok sayıda istisna işlenmesini gerektiriyor
• Araştırmanın ücretsiz PDF dosyası sunuluyor
  • https://arxiv.org/pdf/2310.09423
• Bağlantı protokolünü kullanıcı alanına taşımak iyi bir plan olmayabilir