HTTP/3 yaygın biçimde desteklenmesine rağmen neden pratikte neredeyse hiç kullanılmıyor?

• HTTP/3 2016'dan beri geliştiriliyor ve temel aldığı protokol olan QUIC ilk kez 2013'te Google tarafından tanıtıldı
• Şu anda standartlaştırılmış durumda ve şu ölçüde geniş destek görüyor
  • Tarayıcıların %95'inde destekleniyor
  • Cloudflare'ın HTTP isteklerinin %32'si HTTP/3 kullanıyor
  • Web sitelerinin %35'inde HTTP/3 desteği gösteriliyor (alt-svc veya DNS üzerinden)
• Ancak başlıca dillerin standart kütüphanelerinde QUIC ve HTTP/3 desteği yetersiz
  • Node.js, Go, Rust, Python, Ruby vb. dillerde standart kütüphaneye dahil değil
  • Curl kısa süre önce HTTP/3 desteği ekledi ancak hâlâ deneysel durumda ve varsayılan olarak devre dışı
  • Popüler sunucu Nginx deneysel destek aşamasında ve varsayılan olarak devre dışı
  • Apache'nin HTTP/3 desteği için bir planı yok
  • Kubernetes'in Ingress-Nginx'i HTTP/3 destek planından vazgeçti

HTTP/1.1 sonrasında neden gerekli?

• HTTP/3, yüksek gecikmeli web tarayıcısı ve CDN trafiğinde faydalı
• HTTP/2 ve HTTP/3'ün sağladığı başlıca avantajlar:
  • Multiplexing ile yanıt bekleme süresinin azalması
  • HTTP başlık sıkıştırması ile trafiğin azalması (HPACK, QPACK kullanılır)
  • Çift yönlü streaming ile istemci ve sunucu arasında gerçek zamanlı veri alışverişi yapılabilmesi
  • Önceliklendirme sayesinde önemli isteklerin önce işlenebilmesi
• HTTP/3'ün ek avantajları:
  • Bağımsız akış işleme sayesinde paket kaybının diğer akışları etkilememesi
  • 0-RTT TLS handshake ile bağlantı başlatma hızının artması
  • Bağlantı migrasyonu sayesinde IP adresi değişse bile bağlantının korunabilmesi
  • İyileştirilmiş congestion control ile performans ve kararlılığın artması

HTTP/3'ün performans artışı etkisi

• RequestMetric benchmark sonuçları:
  • HTTP/3, HTTP/1.1 ve HTTP/2'den daha hızlı yanıt süreleri sağlıyor
• Fastly'nin gerçek örneği:
  • HTTP/3'te ilk bayta kadar geçen süre %18 kısalıyor

HTTP/3 desteğinin yetersizliği sorunu

• HTTP/3 tarayıcılarda ve CDN'lerde geniş destek görse de sıradan geliştiricilerin kullanması zor
• Günümüz web trafiğinin iki türü var:
  • Hyperscale web: büyük tarayıcılar ve büyük sunucu altyapılarına dayalı (Google, Meta, Amazon vb.)
  • Long-tail web: küçük ve orta ölçekli sunucu ve istemci tabanlı (backend API'leri, mobil uygulamalar, IoT vb.)
• Başlıca farklar:
  • Long-tail trafik toplam trafiğin %67'sini oluşturuyor
  • Hyperscale hızlı geliştirme ve yaygınlaştırma yapabilirken, long-tail tarafında kaynak kıtlığı ve kararlılık önceliği öne çıkıyor
  • Açık kaynak araçlara bağımlılık yüksek

OpenSSL ve QUIC sorunu

• OpenSSL, çoğu açık kaynak ağ aracının temelini oluşturuyor
• BoringSSL 2018'de QUIC destek API'sini yayımladı, ancak OpenSSL kendine özgü bir QUIC API'si sundu
• Başlıca sorunlar:
  • Mevcut BoringSSL tabanlı uygulamalarla uyumlu değil
  • Curl ve başlıca dillerin OpenSSL bağımlılığını değiştirmesi zor
  • Node.js, OpenSSL yerine BoringSSL kullanmayı değerlendirdi ancak bu gerçekleşmedi

İleriye dönük görünüm

• Hyperscale web HTTP/3'ü benimsedikçe, long-tail web ile arasında performans farkı oluşabilir
• HTTP/3 desteğinin yetersizliği şu sorunlara yol açabilir:
  • Hyperscale sitelerin hız ve kararlılık avantajının daha da güçlenmesi
  • HTTP/3 tabanlı framework'ler yaygınlaşırsa long-tail web'in bunlara erişmesinin zorlaşması
  • HTTP/3 desteği olmamasının istemci engelleme kriteri olarak kullanılabilmesi
• Çözüm yolları:
  • OpenSSL'in QUIC API sorunlarının çözülmesi gerekiyor
  • Mevcut QUIC ve HTTP/3 uygulamalarıyla uyumluluğu artıracak araçlar ve adaptörler geliştirilmeli
  • Açık kaynak araçlarda HTTP/3 desteğinin yaygınlaştırılması için çaba gerekiyor

Sonuç

• HTTP/3 açık performans ve kararlılık avantajları sunuyor, ancak şu anda yalnızca hyperscale şirketlerin kolayca kullanabildiği bir durumda
• Long-tail web'in de HTTP/3'ü kolayca kullanabilmesi için araçların ve standartların iyileştirilmesi gerekiyor

[GN⁺]

Hacker News görüşü

• HTTP/3'ü tam olarak destekleyen popüler açık kaynak araçları bulmanın zor olduğu yönünde bir görüş var

  • BT yöneticileri ve DevOps mühendisleri genellikle HTTP/3 bağlantısını load balancer üzerinde sonlandırıyor, SSL'i sonlandırdıktan sonra da HTTP 1.1'i arka uç servislerine iletiyor
  • HTTP/3 ve IPv6, veri merkezlerinden ziyade geçici ve kararsız bağlantılarda daha faydalı olan, mobil odaklı teknolojiler

• Başlıca dillerin standart kütüphanelerinde QUIC veya HTTP/3 yer almıyor

  • .NET, HTTP/3 için makul düzeyde destek sunuyor
  • Geliştirme ekiplerinin çoğu ağ odaklı ürünler geliştirmediği için HTTP/3 düşük öncelikli kalıyor

• HTTP/3'ün büyük ölçekli dağıtımlarındaki en büyük sorun, potansiyel olarak zafiyet içeren kod yüzeyinin artması

  • İşletim sisteminin güvenli bir socket katmanı ve dinamik olarak bağlanan SSL kütüphaneleri sunması daha tercih edilir
  • Çoğu istemci uygulamasında isteklerde birkaç milisaniyelik gecikme büyük bir sorun oluşturmuyor

• QUIC'in yavaş benimsenmesinin nedeni, OpenSSL'in mevcut QUIC uygulamalarının ihtiyaç duyduğu temel yapı taşlarını sunmamış olması

  • Kısa süre önce OpenSSL 3.5, üçüncü taraf QUIC stack'leri için API sunmaya başladı

• HTTP/2 ve HTTP/3 artık uygulama katmanı protokolleri olarak değil, TCP ve TLS düzeyi olarak algılanıyor

  • Geliştiriciler hâlâ "düz metin HTTP 1.1" dünyasında yaşıyor

• nginx hâlâ production-ready HTTP/3 desteği sunmuyor

• Python'da niquests kullanılıyor ve HTTP/3'ü destekliyor

  • Python ekosistemi inertia nedeniyle requests paketinde kalmıştı

• Node.js, QUIC'in durumuna ilişkin bir güncelleme yayımladı ve OpenSSL'in API desteğini yavaş sunması nedeniyle zorlanıyor

• Public cloud sağlayıcılarının load balancer'larını kullanan durumlarda varsayılan olarak HTTP/3 kullanılıyor

  • Kendi sunucularını kullanan siteler HTTP/3'ün avantajlarından yararlanamıyor

• Tüm projeler bir ölçüde açık kaynak ve topluluk odaklı ilerliyor

  • HTTP/3'ü hızlıca destekleme ihtiyacı pek hissedilmiyor