HTTP/3, QUIC ve Linux BBR Optimizasyon Rehberi (2026)

Web sitelerinin ve bulut uygulamalarının açılış hızını optimize ederken genellikle PHP sürümü, veritabanı indeksleri veya CSS/JS sıkıştırmasına odaklanılır. Ancak 2026 yılında sunucu hızının ve İlk Bayt Zamanı (TTFB - Time to First Byte) metriğinin en büyük belirleyicisi taşıma katmanı (transport layer) ve kullanılan ağ protokolleridir.

Geleneksel TCP tabanlı HTTP/1.1 ve HTTP/2 protokolleri, paket kaybı yaşanan mobil bağlantılarda ve yüksek gecikmeli hatlarda ciddi darboğazlar yaşar. HTTP/3 (QUIC) ve Linux çekirdeğine yerleşik Google BBR (Bottleneck Bandwidth and RTT) algoritması, altyapı kodunu değiştirmeden sayfa yüklenme hızını %30 ile %80 arasında artırabilir.

Bu rehberde; Linux VPS, VDS veya Dedicated sunucunuzda TCP BBR tıkanıklık kontrolünü nasıl açacağınızı, Nginx ve LiteSpeed üzerinde HTTP/3'ü nasıl yapılandıracağınızı ve UDP 443 güvenlik duvarı ayarlarını adım adım inceliyoruz.

1. HTTP/1.1, HTTP/2 ve HTTP/3 (QUIC) Mimari Karşılaştırması

TCP Head-of-Line (HoL) Blocking Sorunu Neden Önemlidir?

HTTP/2 protokolü tüm web sitesi varlıklarını (CSS, JS, resimler) tek bir TCP bağlantısı üzerinden paralel olarak aktarır. Ancak TCP protokolü veri paketlerinin kesinlikle sıralı iletilmesini şart koşar. Eğer tek bir CSS dosyasına ait tek bir paket paket kaybı nedeniyle kaybolursa, TCP işletim sistemi çekirdeğinde tüm kuyruğu durdurur ve kayıp paketin yeniden iletilmesini bekler. Bu durum, özellikle Türkiye'deki mobil veya dalgalı internet hatlarında HTTP/2'nin vaat ettiği hız avantajını yok edebilir.

HTTP/3 ise QUIC protokolüyle UDP üzerinden çalışır. Her veri akışı tamamen bağımsız bir kimliğe (Stream ID) sahiptir. Bir görsel paketinin kaybolması, arkasından gelen JavaScript veya HTML akışını 1 milisaniye bile bekletmez.

2. Linux Çekirdeğinde TCP BBR Algoritmasını Etkinleştirme

Web trafiğinin önemli bir kısmı hâlâ TCP üzerinden akar. Standart Linux dağıtımlarında (Ubuntu, Debian, AlmaLinux) varsayılan TCP tıkanıklık kontrol algoritması genellikle CUBIC veya Reno olarak gelir.

• CUBIC Yaklaşımı: Ağda paket kaybı olana kadar hızı artırır; paket kaybı gördüğü anda transfer hızını yarıya (%50) düşürür. Wi-Fi ve mobil ağlardaki doğal sinyal dalgalanmalarını "ağ çöktü" sanarak hızı gereksiz yere boğar.
• Google BBR Yaklaşımı: Paket kaybına değil, hattın gerçek bant genişliği (bottleneck bandwidth) ve gidiş-dönüş süresine (min RTT) bakar. Ağ tamponlarını şişirmeden (bufferbloat önleyerek) hattı maksimum verimle doldurur.

Adım Adım BBR Kurulumu (Ubuntu 22.04 / 24.04 ve Debian 12)

Linux çekirdeği 4.9 ve üzerindeki tüm modern sistemlerde BBR doğrudan çekirdek modülü olarak yerleşiktir.

1. Mevcut Çekirdek ve Algoritmayı Kontrol Edin

# Çekirdek sürümünü kontrol edin (En az 5.x veya 6.x olmalıdır)
uname -r

# Şu an aktif algoritmayı görüntüleyin (Genellikle 'cubic' çıkar)
sysctl net.ipv4.tcp_congestion_control

2. BBR ve Fair Queueing (fq) Ayarlarını Ekleyin

BBR algoritmasının milisaniye hassasiyetinde paket gönderebilmesi için Linux kuyruk disiplini olarak fq (Fair Queueing) kullanılmalıdır:

# sysctl.conf dosyasına yapılandırmayı yazın
cat << 'EOF' | sudo tee -a /etc/sysctl.d/99-bbr-optimizasyon.conf
# Google BBR TCP Tıkanıklık Kontrolü & Buffer Optimizasyonu
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Yüksek bant genişliği için ağ tampon limitleri (1 Gbps+ hatlar için)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
EOF

3. Yapılandırmayı Yeniden Başlatmadan Uygulayın

sudo sysctl --system

4. BBR'nin Aktif Olduğunu Doğrulayın

# Çıktıda 'net.ipv4.tcp_congestion_control = bbr' görmelisiniz:
sysctl net.ipv4.tcp_congestion_control

# BBR çekirdek modülünün yüklendiğini kontrol edin:
lsmod | grep bbr

3. Web Sunucularında HTTP/3 (QUIC) Yapılandırması

HTTP/3'ün çalışabilmesi için web sunucunuzun TLS 1.3 desteğine ve QUIC motoruna sahip olması gerekir.

A. Nginx 1.25+ ve Üzerinde HTTP/3 Kurulumu

Resmi Nginx 1.25 sürümünden itibaren HTTP/3 desteği ana depoya eklenmiştir. Nginx sunucu bloğunuzda aşağıdaki yönergeleri tanımlamanız yeterlidir:

server {
    # Standart TCP üzerinden HTTP/2 ve HTTP/1.1 dinlemesi
    listen 443 ssl;
    listen [::]:443 ssl;

    # QUIC ve HTTP/3 dinlemesi (UDP protokolü)
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    server_name example.com www.example.com;

    # TLS 1.3 zorunludur (QUIC TLS 1.2 desteklemez)
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Tarayıcılara HTTP/3 desteğini bildiren Alt-Svc başlığı (Kritik Adım!)
    add_header Alt-Svc 'h3=":443"; ma=86400';
    add_header X-Protocol $server_protocol always;

    # GZIP ve Brotli sıkıştırma
    gzip on;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

Önemli Not: Tarayıcılar bir siteyi ilk ziyaret ettiklerinde HTTPS portuna TCP üzerinden bağlanırlar. Nginx'in döndürdüğü Alt-Svc: h3=":443"; ma=86400 başlığını okuyan tarayıcı, sonraki tüm istekleri UDP 443 üzerinden HTTP/3 ile gerçekleştirecektir.

B. LiteSpeed ve OpenLiteSpeed

LiteSpeed Enterprise ve OpenLiteSpeed web sunucuları HTTP/3 ve QUIC protokolünü doğuştan (native) destekler. Herhangi bir derleme yapmanıza gerek yoktur:

1. OpenLiteSpeed WebAdmin konsoluna girin (:7080).
2. Listeners > SSL Listener (443) sekmesini açın.
3. Allow QUIC seçeneğini Yes yapın.
4. Sunucuyu yeniden başlatın (Graceful Restart).

C. Caddy Web Server

Caddy, modern web sunucuları arasında HTTP/3'ü sıfır konfigürasyonla sunan en gelişmiş çözümdür. Caddyfile içinde alan adınızı tanımladığınız anda Let's Encrypt TLS 1.3 sertifikasını alır ve HTTP/3'ü otomatik olarak etkinleştirir.

4. Güvenlik Duvarı Yapılandırması: En Sık Yapılan Hata

HTTP/3 ile ilgili en yaygın problem; yöneticilerin sunucuda HTTP/3'ü açmasına rağmen güvenlik duvarında yalnızca TCP 443 portuna izin vermeleridir.

QUIC tamamen UDP üzerinden çalışır. UDP 443 portu açık değilse tarayıcı QUIC paketlerine yanıt alamaz ve mecburen 200-300 ms zaman aşımı gecikmesiyle HTTP/2'ye geri düşer (fallback).

# UFW (Ubuntu/Debian) üzerinde UDP 443 izni verin:
sudo ufw allow 443/udp comment 'HTTP3 QUIC'
sudo ufw status verbose

# firewalld (AlmaLinux/CentOS/Rocky Linux):
sudo firewall-cmd --permanent --add-port=443/udp
sudo firewall-cmd --reload

# nftables / iptables doğrudan kuralı:
sudo iptables -A INPUT -p udp --dport 443 -j ACCEPT

5. Doğrulama ve Test Yöntemleri

HTTP/3 ve BBR'nin doğru çalıştığını doğrulamak için şu adımları izleyin:

1. curl ile Komut Satırından Test

Modern curl sürümleri --http3 bayrağını destekler:

curl --http3 -I https://example.com

Dönen yanıtta HTTP/3 200 veya alt-svc başlığını görmelisiniz.

2. Tarayıcı Geliştirici Araçları (DevTools)

1. Google Chrome veya Edge tarayıcısında sitenizi açın.
2. F12 > Network (Ağ) sekmesine gelin.
3. Tablo başlıklarına sağ tıklayıp Protocol sütununu açın.
4. İsteklerin protokol kısmında h3 görüyorsanız siteniz tam HTTP/3 ile çalışmaktadır.

3. Linux Çekirdeği Canlı Soket İncelemesi (ss)

Sunucuda aktif TCP bağlantılarının BBR kullanıp kullanmadığını doğrulamak için:

ss -tin '( dport = :443 or sport = :443 )'

Çıktı satırlarında bbr ve bw: (bant genişliği tahmini) ibarelerini görmelisiniz.

6. Özet ve Uygulama Tavsiyesi

• VPS & VDS Sunucular: Linux çekirdeğinde TCP BBR'yi açmak 1 dakikalık risksiz bir işlemdir ve tüm giden TCP trafiğini hızlandırır.
• WordPress & E-Ticaret: WooCommerce veya yüksek trafikli WordPress sitelerinde LiteSpeed + HTTP/3 + BBR kombinasyonu, mobil kullanıcılarda sepet terk oranlarını düşürür ve Google Core Web Vitals puanlarını yukarı çeker.
• Reverse Proxy / Cloudflare: Cloudflare arkasındaki sitelerde Cloudflare Dashboard > Speed > Optimization > Protocol Optimization altından HTTP/3'ü açabilirsiniz; ancak sunucunuz ile Cloudflare arasındaki bağlantıda da BBR etkinleştirildiğinde TTFB minimuma iner.