HTTP/2 Nedir, Ne Kazandırır

Sitenizin bütün görselleri optimize, CSS'iniz küçültülmüş, sunucunuz güçlü; ama tarayıcının şelale (waterfall) grafiğine baktığınızda isteklerin sıra sıra beklediğini görüyorsunuz. Bu bekleyişin sebebi çoğu zaman sunucunuz değil, kullandığınız protokoldür. HTTP/2, HTTP/1.1'in yirmi yıldır taşıdığı en büyük yapısal sorunu — tek bağlantıda tek isteğin sırayla işlenmesini — ortadan kaldıran bir protokol sürümüdür ve genellikle tek satırlık bir yapılandırma değişikliğiyle açılır.

Bu yazıda HTTP/2'nin HTTP/1.1'den tam olarak nerede ayrıldığını, ikili çerçeveleme (binary framing), multiplexing ve HPACK başlık sıkıştırmasının ne işe yaradığını, Nginx ve Apache üzerinde nasıl etkinleştirildiğini ve hangi eski optimizasyon alışkanlıklarının HTTP/2 ile birlikte artık zarar verir hale geldiğini anlatacağım. Sonunda protokolün gerçekten aktif olup olmadığını nasıl doğrulayacağınızı da göstereceğim.

HTTP/1.1'in Asıl Sorunu: Sıra Beklemek#

HTTP/1.1'de bir TCP bağlantısı üzerinden aynı anda yalnızca bir istek işlenir. Tarayıcı style.css istediğinde, yanıt tamamen gelmeden aynı bağlantıda app.js isteyemez. Buna uygulama katmanı hat başı engellemesi (head-of-line blocking) denir. Tarayıcılar bu sorunu, alan adı başına genellikle altı paralel bağlantı açarak aşmaya çalışır — ama her yeni bağlantı kendi TCP el sıkışmasını ve TLS anlaşmasını gerektirir, yani her biri en az bir gidiş-dönüş süresi (RTT) maliyeti taşır.

Bunun pratik sonucu şudur: 60 kaynaklı bir sayfada tarayıcı altı kanaldan on tur atmak zorunda kalır. Her turda ağ gecikmesi kadar bekler. Bağlantınız 100 Mbit olsa bile, 80 milisaniyelik bir gecikme bu on turda 800 milisaniyeye dönüşür. HTTP/2'nin çözdüğü asıl problem bant genişliği değil, işte bu tur sayısıdır. Bağlantı kurma maliyetini azaltan Keep-Alive mekanizmasını da HTTP/1.1 tarafında ayrıca ayarlamanız gerekir; detayları Keep-Alive bağlantı ayarları yazısında bulabilirsiniz.

Multiplexing: Tek Bağlantı, Paralel Akışlar#

HTTP/2'nin kalbi multiplexing'dir. Protokol metin tabanlı olmaktan çıkıp ikili çerçevelere (frames) bölündüğü için, tek bir TCP bağlantısı üzerinde birbirinden bağımsız yüzlerce "akış" (stream) aynı anda ilerleyebilir. Tarayıcı 60 kaynağın hepsini tek bağlantıdan aynı anda ister; sunucu hazır olan yanıtları hazır olduğu sırada göndermeye başlar. Bir kaynağın yavaş olması diğerlerini bekletmez.

Bu değişimin somut sonucu bağlantı sayısında görülür. Aynı sayfa iki protokolde şöyle davranır:

Tek bağlantıya inmenin ikinci bir faydası daha vardır: TLS el sıkışması bir kez yapılır ve TCP'nin yavaş başlangıç (slow start) penceresi tek bir bağlantıda hızla büyür. Altı ayrı bağlantıda ise her biri sıfırdan başlar ve hiçbiri tam hızına ulaşamadan sayfa yüklenmiş olur.

HPACK: Başlıkların Tekrarını Ortadan Kaldırmak#

Bir HTTP isteğinde User-Agent, Accept, Cookie, Referer gibi başlıklar toplamda kolayca 800-1500 bayt tutar. HTTP/1.1'de bu başlıklar her istekte, tamamen aynı olmalarına rağmen baştan sona tekrar gönderilir. 60 kaynaklı bir sayfada bu, yalnızca başlıklar için 60-90 KB yukarı yönlü trafik demektir — ve yukarı yönlü bant genişliği mobil bağlantılarda çoğu zaman aşağı yönlüden çok daha dardır.

HPACK bu tekrarı iki yöntemle yok eder. Birincisi, sık kullanılan başlık adları ve değerleri için önceden tanımlı statik bir tablo taşır; :method: GET gibi bir başlık tek bir indeks numarasına iner. İkincisi, bağlantı boyunca dinamik bir tablo tutar: ilk istekte gönderilen uzun Cookie değeri tabloya yazılır, sonraki isteklerde yalnızca indeksi gönderilir. Sonuçta 1 KB'lık bir başlık kümesi ikinci istekten itibaren birkaç on bayta düşer.

Bu, çerezleri ağır olan sitelerde şaşırtıcı derecede büyük bir kazançtır. Özellikle her alt kaynağa çerez gönderen yapılandırmalarda HTTP/2'ye geçmek, tek başına yukarı yönlü trafiği belirgin biçimde azaltır. Yine de en iyi yaklaşım, statik dosyaları çerez taşımayan bir yol üzerinden servis etmektir; HPACK bunu telafi eder ama tamamen gereksiz kılmaz.

Nginx ve Apache Üzerinde HTTP/2'yi Açmak#

Tarayıcılar HTTP/2'yi pratikte yalnızca TLS üzerinden, ALPN (Application-Layer Protocol Negotiation) uzantısıyla kullanır. Yani ilk şart geçerli bir SSL sertifikasıdır; şifresiz HTTP üzerinden HTTP/2 hiçbir masaüstü tarayıcıda çalışmaz. Sertifikanız yoksa SSL sertifikası tarafını halletmek ilk adımınız olmalı.

Nginx 1.25.1 sürümüyle birlikte HTTP/2 ayrı bir direktife taşındı. Güncel ve doğru biçim şudur:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;                      # Nginx 1.25.1+ için doğru biçim

    server_name firmaniz.com www.firmaniz.com;

    ssl_certificate     /etc/letsencrypt/live/firmaniz.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/firmaniz.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    root /var/www/firmaniz.com/public;
}

Daha eski bir Nginx kullanıyorsanız listen 443 ssl http2; biçimi geçerlidir. Yapılandırmayı yazdıktan sonra söz dizimini test edip yeniden yükleyin:

# Yapılandırmayı doğrula
sudo nginx -t

# Bağlantıları kesmeden yeniden yükle
sudo systemctl reload nginx

Apache tarafında mod_http2 modülünü etkinleştirip desteklenen protokolleri sıralarsınız. Sıralama önemlidir; listedeki ilk protokol tercih edilendir:

sudo a2enmod http2
sudo systemctl restart apache2

# Sanal host bloğu içinde
<VirtualHost *:443>
    ServerName firmaniz.com
    Protocols h2 http/1.1

    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/firmaniz.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/firmaniz.com/privkey.pem
</VirtualHost>

Apache'de dikkat edilmesi gereken bir nokta var: mod_php ile prefork MPM kullanıyorsanız HTTP/2 desteklenmez ya da ciddi biçimde kısıtlanır. Bu durumda event MPM ve PHP-FPM kombinasyonuna geçmeniz gerekir. LiteSpeed tabanlı sunucularda ise HTTP/2 yerleşiktir ve genellikle ek yapılandırma istemez; iki sunucu arasındaki mimari farklar için LiteSpeed ve Apache karşılaştırması yazısına bakabilirsiniz.

HTTP/2 ile Anlamsızlaşan Eski Alışkanlıklar#

HTTP/1.1 döneminde geliştirilen bazı optimizasyon teknikleri, tek bağlantı modelinde ya faydasız hale gelir ya da doğrudan zarar verir. Bunları temizlemek, HTTP/2'yi açmak kadar önemlidir.

1. Alan adı bölme (domain sharding). Bağlantı limitini aşmak için static1.firmaniz.com, static2.firmaniz.com gibi alt alan adları oluşturmak HTTP/1.1'de mantıklıydı. HTTP/2'de her ek alan adı ayrı bir TCP+TLS el sıkışması, ayrı bir DNS sorgusu ve ayrı bir HPACK tablosu demektir. Tek alan adında toplayın.
2. CSS sprite dosyaları. Onlarca küçük ikonu tek bir büyük görselde birleştirmek, istek sayısını azaltmak içindi. Artık istek sayısı ucuz; buna karşılık sprite yaklaşımı, sayfanın ihtiyaç duymadığı ikonları da indirtir ve önbellek geçersizleştirmeyi zorlaştırır.
3. Aşırı dosya birleştirme (concatenation). Tüm JavaScript'i tek bir dev dosyada toplamak, tek satır değişiklikte tüm paketin önbellekten düşmesine yol açar. HTTP/2'de mantıklı boyutta parçalara ayırmak hem daha iyi önbelleklenir hem de paralel iner.
4. Veri URI ile gömme (inlining). Küçük görselleri base64 olarak CSS'e gömmek boyutu yaklaşık üçte bir büyütür ve ayrı önbelleklenemez hale getirir. Yalnızca gerçekten kritik, çok küçük varlıklar için düşünün.

Bu temizliği yaparken sayfanızın en büyük görsel öğesinin ne kadar sürede boyandığını takip etmek işinize yarar; ölçüm ve iyileştirme yöntemleri için LCP nasıl iyileştirilir yazısı iyi bir başlangıç noktasıdır.

Bir de artık geride kalmış bir özellik var: Server Push. HTTP/2 spesifikasyonunda sunucunun, tarayıcı istemeden kaynak göndermesine izin veren bu mekanizma pratikte beklenen faydayı vermedi; sunucu çoğu zaman tarayıcının önbelleğinde zaten var olan dosyayı tekrar gönderdi ve bant genişliği israf etti. Büyük tarayıcılar desteği kaldırdı. Yerine Link: </style.css>; rel=preload başlığını ya da HTML içinde önden yükleme ipuçlarını kullanın.

Gerçekten HTTP/2 Konuşulduğunu Doğrulamak#

Yapılandırmayı değiştirdikten sonra protokolün aktif olduğunu varsaymayın, ölçün. En hızlı yöntem curl ile hangi sürümün müzakere edildiğine bakmaktır:

# Yanıtın ilk satırı kullanılan protokolü gösterir
curl -I --http2 https://firmaniz.com/ 2>/dev/null | head -n 1
# Beklenen çıktı:
# HTTP/2 200

# ALPN müzakeresini ayrıntılı görmek için
curl -v --http2 https://firmaniz.com/ 2>&1 | grep -i 'alpn'
# * ALPN: server accepted h2

openssl ile doğrudan TLS katmanına bakarak sunucunun h2 protokolünü ilan edip etmediğini de görebilirsiniz:

openssl s_client -connect firmaniz.com:443 -alpn h2 -servername firmaniz.com </dev/null 2>/dev/null \
  | grep -i 'ALPN protocol'
# ALPN protocol: h2

Tarayıcı tarafında Chrome veya Firefox geliştirici araçlarında Ağ sekmesini açın, sütun başlıklarına sağ tıklayıp Protocol sütununu görünür yapın. Her istek için h2 (HTTP/2), h3 (HTTP/3) ya da http/1.1 değerini görürsünüz. Bazı isteklerde http/1.1 görüyorsanız, o kaynaklar büyük ihtimalle farklı bir alan adından ya da HTTP/2 desteklemeyen bir üçüncü taraf sunucudan geliyordur.

Bir sitenin nesnel hız değişimini ölçmek isterseniz protokolü açmadan önce ve sonra aynı sayfayı aynı koşullarda test edin; test yöntemleri ve tuzakları için GTmetrix ile WordPress hız testi yazısı iyi bir rehberdir.

HTTP/2'nin Çözemediği Şey ve Sınırları#

HTTP/2 uygulama katmanındaki hat başı engellemesini çözer, ama altındaki TCP katmanındakini çözemez. Tek bir TCP bağlantısı üzerinde ilerleyen onlarca akıştan herhangi birine ait bir paket kaybolursa, TCP sıralı teslimat garantisi verdiği için o paket yeniden iletilene kadar bütün akışlar bekler. Yani paket kaybının yüksek olduğu mobil ya da zayıf ağlarda HTTP/2, tek bağlantıya indiği için bazen HTTP/1.1'den daha kötü davranabilir. Bu sorunun çözümü protokolü TCP yerine UDP üzerine taşıyan HTTP/3'tür; nasıl açıldığını HTTP/3 (QUIC) etkinleştirme yazısında anlattım.

İkinci sınır, HTTP/2'nin sunucu tarafındaki yavaşlığı gizlememesidir. Veritabanı sorgunuz 800 milisaniye sürüyorsa protokol bunu düzeltmez; yalnızca ağ üzerinde harcanan turları azaltır. Sunucu tarafı gecikmesi baskınsa önce önbellekleme katmanına bakmalısınız — Nginx FastCGI cache ya da Memcached gibi çözümler burada protokolden çok daha fazlasını kazandırır.

Üçüncüsü, HTTP/2'nin akış önceliklendirme mekanizması pratikte istemciden istemciye farklı yorumlandığı için beklenen kadar işe yaramadı. Kritik CSS'in geç gelmesi gibi sorunlarda tek gerçek çözüm, kaynakların HTML içindeki sırasını ve önden yükleme ipuçlarını doğru kurmaktır. Protokol size paralel bir kanal verir; hangi kaynağın önce gelmesi gerektiğine yine sizin karar vermeniz gerekir.

Sıkça Sorulan Sorular#

HTTP/2 için SSL sertifikası zorunlu mu#

Spesifikasyon şifresiz HTTP/2'ye (h2c) izin verse de hiçbir yaygın masaüstü tarayıcı bunu desteklemez. Pratikte HTTP/2 kullanmak istiyorsanız geçerli bir TLS sertifikanız olmalı ve site HTTPS üzerinden servis edilmelidir. Ücretsiz Let's Encrypt sertifikaları bu iş için tamamen yeterlidir; ek olarak HTTPS zaten arama sıralaması ve tarayıcı güven göstergeleri için gereklidir.

HTTP/2 siteyi ne kadar hızlandırır#

Kazanç, sayfanızdaki kaynak sayısına ve kullanıcının ağ gecikmesine bağlıdır. Çok sayıda küçük dosya barındıran ve kullanıcıları sunucudan uzakta olan sitelerde ilk yükleme süresinde belirgin bir düşüş görürsünüz. Buna karşılık üç dört kaynaklı sade bir sayfada fark ölçülemeyecek kadar küçük kalabilir. Protokolü açmak neredeyse bedava olduğu için yine de yapılması gereken bir adımdır.

HTTP/2 açıkken hâlâ dosyaları birleştirmeli miyim#

Aşırıya kaçmadan, evet. HTTP/2 istek maliyetini büyük ölçüde düşürür ama sıfırlamaz; yüzlerce minik dosya hâlâ ek çerçeve ve öncelik yükü getirir. Makul yaklaşım, mantıksal olarak ilişkili kodu birkaç orta boy pakete ayırmak ve sık değişen kodu nadiren değişenden ayırmaktır. Böylece hem paralellikten hem de önbellek isabetinden yararlanırsınız.

Sitem HTTP/2 kullanıyor mu, nasıl kontrol ederim#

En hızlısı komut satırından curl -I --http2 https://firmaniz.com/ çalıştırıp yanıtın ilk satırında HTTP/2 200 görmektir. Tarayıcıda ise geliştirici araçlarının Ağ sekmesine Protocol sütununu ekleyip her isteğin yanında h2 yazıp yazmadığına bakabilirsiniz. Bazı isteklerde eski protokol görünüyorsa, o kaynaklar farklı bir sunucudan geliyor olabilir.

CDN kullanıyorsam sunucumda HTTP/2 açmam gerekir mi#

CDN kullandığınızda ziyaretçiyle konuşan taraf CDN'dir ve büyük sağlayıcılar HTTP/2 ile HTTP/3'ü zaten sunar. Yine de CDN ile kendi sunucunuz arasındaki bağlantı ayrıdır; orada da HTTP/2 açık olması önbellekte olmayan istekler için fayda sağlar. Ayrıca CDN'i devre dışı bıraktığınız ya da doğrudan sunucuya gelen trafiğin olduğu durumlar için sunucu tarafını hazır tutmak doğru olur.

HTTP/2 açtım ama bazı istekler hâlâ http/1.1 görünüyor#

Bu genellikle o kaynakların sizin sunucunuzdan gelmemesinden kaynaklanır; üçüncü taraf yazı tipleri, analiz betikleri veya reklam kaynakları kendi sunucularının desteklediği protokolü kullanır. Kendi alan adınızdaki bir kaynak eski protokolde görünüyorsa, o kaynağın farklı bir sanal host bloğundan servis edilip edilmediğini ve o blokta HTTP/2 direktifinin bulunup bulunmadığını kontrol edin.

Kapanış#

HTTP/2, performans işlerinde nadir görülen türden bir kazanımdır: uygulama kodunuza dokunmadan, tek satırlık bir sunucu ayarıyla ağ üzerindeki tur sayısını ciddi biçimde azaltır. Aklınızda kalması gereken dört şey var. Geçerli bir TLS sertifikanız olmadan HTTP/2 çalışmaz. Multiplexing sayesinde alan adı bölme ve sprite gibi eski numaralar artık zararlıdır, temizleyin. Server Push ölmüştür, yerine önden yükleme ipuçları kullanın. Ve her değişiklikten sonra protokolün gerçekten müzakere edildiğini curl ya da geliştirici araçlarıyla doğrulayın.

Sunucu yapılandırmasıyla uğraşmadan HTTP/2'nin açık olduğu bir altyapı istiyorsanız, Clou.TR paketlerinde protokol desteği hazır gelir. LiteSpeed tabanlı web hosting ve WordPress hosting paketlerimizde HTTP/2 varsayılan olarak etkindir; sunucu yapılandırmasını satır satır kendiniz yönetmek isterseniz tam root erişimli VDS sunucu ve bulut sunucu seçeneklerimize göz atabilirsiniz. Kurulumu bize bırakmak isterseniz sunucu yönetimi hizmetimiz TLS, HTTP/2 ve önbellek ayarlarını birlikte yapılandırır.