Kurumsal ağlarda “web trafiği” uzun yıllar boyunca basit bir varsayımla yönetildi: HTTP, TCP üzerinde akar; kontrol noktaları (proxy/WAF/IDS/NDR) bunu görür, sınıflandırır, gerektiğinde bloke eder. QUIC ve HTTP/3 bu varsayımı kırıyor.
Bu yazıda HTTP/3’ü “protokol merakı” olarak değil; güvenlik ve operasyon tasarımı olarak ele alıyorum: Nerede izin verilir, nerede kontrol edilir, nerede bilinçli biçimde kapatılır?
QUIC/HTTP/3 neyi değiştiriyor?
Özet farklar:
- HTTP/3, QUIC üzerinde çalışır ve QUIC çoğunlukla UDP/443 kullanır.
- TCP’deki bazı “ağ davranışları” (middlebox optimizasyonları, state takibi, reset’ler) QUIC’te farklıdır.
- Şifreleme seviyesi yükseldikçe DPI tabanlı ayrıştırma zorlaşır; bu da görünürlük ve politika uygulamayı etkiler.
Pratikte kurumsal ağlarda bu şu sorulara dönüşür:
- Egress/Proxy katmanı HTTP/3’ü nasıl ele alacak?
- NDR/IDS/Firewall, UDP/443 trafiğini nasıl sınıflandıracak?
- NAT/State tabloları, UDP oturumlarını nasıl yönetecek?
- Incident anında “sorun QUIC mi?” teşhisini nasıl hızlandıracağız?
Kurumsal karar matrisi: Nerede açılır, nerede kapatılır?
Sahada en sağlıklı yaklaşım, HTTP/3’ü “her yerde aç” veya “her yerde kapat” diye değil; akış bazlı yönetmektir.
Örnek karar matrisi:
- Kritik SaaS (kimlik, e-posta, iş uygulamaları): Proxy/egress kontrolü varsa kontrollü aç.
- Genel internet (best-effort): Varsayılan kapalı veya sınırlı aç (özellikle DLP/denetim ihtiyacı yüksekse).
- İç servisler: HTTP/3 genelde gereksiz; önce HTTP/2 + mTLS + gözlem olgunluğu.
- Mobil/uzak kullanıcı trafiği: QUIC faydalı olabilir ama NAT timeout ve Wi‑Fi/ISP davranışları yüzünden ölçüm şart.
Kontrol noktaları: Proxy, WAF, NDR, Firewall
1) Egress/Proxy
Kurumsal denetim istiyorsanız, egress hattında şu seçenekleri netleştirin:
- HTTP/3’ü terminate edip HTTP/2’ye düşürmek (proxy üzerinden kontrol)
- HTTP/3’ü uçtan uca geçirmek (daha az görünürlük, daha çok “doğrudan internet” davranışı)
Operasyonel önerim:
- Önce proxy’nin HTTP/3 destek durumunu netleştirin.
- Destek yoksa, en azından kritik segmentlerde UDP/443’ü kontrollü yönetin (allowlist / rate-limit / log).
2) WAF / CDN katmanı
Eğer dışarıya servis sunuyorsanız:
- CDN/LB tarafında HTTP/3 açmak, istemci deneyimini iyileştirebilir.
- Ama WAF politikalarının HTTP/3 trafiği için de aynı şekilde uygulandığından emin olun (terminasyon nerede?).
3) NDR / IDS görünürlüğü
QUIC şifreli olduğundan, “içerik odaklı” bazı tespitler zorlaşır. Alternatif sinyaller:
- Akış meta verisi (hedef, hacim, süre, jitter)
- DNS telemetry (özellikle ECH/DoH/DoQ kombinasyonlarında)
- Sertifika/handshake metrikleri (varsa terminasyon noktasından)
4) Firewall / NAT / State
UDP akışları genelde daha “kısa ömürlü” varsayılır. QUIC ise uzun yaşayan oturumlar üretebilir.
Kontrol listesi:
- UDP state timeout’ları: Çok kısa ise kopmalar artar.
- Conntrack kapasitesi: UDP/443 artışı tabloyu şişirebilir.
- Rate-limit: “UDP flood” korumaları QUIC’i yanlışlıkla kırabilir.
Rollout planı: “Açtık” değil, “kademeli açtık ve ölçtük”
- Gözlem: Ağ cihazlarında UDP/443 hacmi, düşen paket, NAT timeout, conntrack trendi.
- Kapsam seçimi: Önce belirli lokasyon/segment veya belirli SaaS seti.
- Fallback kuralı: Sorunda hızlı kapatma (feature flag mantığı).
- Runbook: QUIC kaynaklı şikâyetlerde teşhis adımları.
Incident triage: “Sorun QUIC mi?” hızlı kontrol
Belirti örnekleri:
- Sadece bazı ISP/lokasyonlarda yavaşlık
- TCP (HTTP/2) iyi, HTTP/3 kötü (veya tersi)
- VPN üzerinden iyi, direkt internetten kötü
Hızlı teşhis:
# İstemci tarafında protokol doğrulama
curl -I --http3 https://example.com 2>/dev/null | head -n 5 || true
curl -I --http2 https://example.com 2>/dev/null | head -n 5 || true
# UDP/443 trafiği gerçekten var mı?
sudo tcpdump -nn -i any 'udp port 443' -c 50 2>/dev/null || trueOperasyonel karar:
- HTTP/2 iyi, HTTP/3 kötü ise: HTTP/3’ü geçici kapat, root-cause için MTU/PMTUD, NAT timeout, UDP rate-limit ve middlebox loglarını incele.
- HTTP/3 iyi, HTTP/2 kötü ise: LB/Proxy terminasyonunda TCP tarafı (SYN backlog, TLS offload, proxy kapasitesi) daha olasıdır.
Sonuç
QUIC/HTTP/3; “daha hızlı web” etiketinden çok daha büyük bir değişiklik: kurumsal ağın denetim ve görünürlük varsayımlarını güncelliyor. Sağlıklı model; kademeli rollout + ölçüm + hızlı geri alma ve kontrol noktalarında bilinçli terminasyon kararlarıdır.