16 min. okuyun

HTTP/2: Modern Web Performansı için Eksiksiz Kılavuz

Hiper metin aktarım protokolü, başlangıcından bu yana önemli ölçüde gelişti ve HTTP/2, dünya çapında web üzerinden veri aktarma şeklimizdeki en önemli sıçramalardan birini temsil ediyor. Son birkaç yıldır web sayfalarının daha hızlı yüklendiğini fark ettiyseniz, HTTP/2‘nin perde arkasında çalışıyor olma ihtimali yüksektir.

Bu kılavuz, HTTP/2‘nin temel mekaniği ve performans avantajlarından pratik dağıtım adımlarına kadar HTTP/2hakkında bilmeniz gereken her şeyi açıklıyor. İster web sunucunuzu optimize etmek isteyen bir geliştirici olun, ister modern web sitelerini neyin harekete geçirdiğini merak ediyor olun, burada uygulanabilir bilgiler bulacaksınız.

Hızlı Yanıt: HTTP/2 Nedir ve Neden Önemlidir?

HTTP/2, İnternet Mühendisliği Görev Gücü tarafından RFC 7540’ta (Mayıs 2015) standartlaştırılan hiper metin aktarım protokolü sürüm 1.1‘in büyük bir revizyonudur. Mevcut HTTP semantikleri ile geriye dönük tam uyumluluğu korurken , gecikmeyi azaltmaya, ağ kaynaklarının kullanımını iyileştirmeye ve web sayfalarının önemli ölçüde daha hızlı yüklenmesinisağlamaya odaklanır.

2026’da HTTP/2 neredeyse her yerde kullanılıyor olacak. W3Techs verilerine göre, en iyi web sitelerinin 1/3’ünden fazlası HTTP/2’yi aktif olarak kullanıyor ve çoğu büyük CDN (Cloudflare, AWS CloudFront, Fastly) HTTPS trafiği için varsayılan olarak etkinleştiriyor. Siteniz modern bir web sunucusuyla HTTPS üzerinde çalışıyorsa, muhtemelen herhangi bir ek yapılandırma yapmadan HTTP/2’den zaten yararlanıyorsunuzdur.

Protokol, HTTP 1.1’in performans darboğazlarını ele alan birkaç başlık özelliği sunar:

Çoklama: Birden fazla veri akışı tek bir TCP bağlantısı üzerinden aynı anda geçer
Başlık sıkıştırma (HPACK): Gereksiz HTTP başlık meta verilerini önemli ölçüde azaltan başlık alanı sıkıştırma özelliği
İkili çerçeve katmanı: Metin tabanlı komutları verimli ikili mesaj çerçevelemesi ile değiştiren tamamen genel bir çerçeve katmanı
Sunucu itme: Tarayıcı açıkça talep etmeden önce kaynakların proaktif olarak sunulması
Akış önceliklendirme: Sunuculara hangi kaynakların daha önemli olduğunu söyleyen istemci ipuçları

Bunun pratikteki anlamı şudur:

Özellikle kaynak açısından ağır sitelerde daha hızlı sayfa yüklemeleri
Kaynak başına daha az TCP bağlantısı gerekir
Yüksek gecikme süresine sahip mobil ağlarda daha iyi performans
Genel olarak iyileştirilmiş ağ kullanımı

HTTP/0.9’dan HTTP/2’ye: Kısa Bir Tarihçe

HTTP protokolü, Tim Berners-Lee’nin 1991 yılında HTML belgelerini almak için basit bir mekanizma olarak HTTP/0.9’u tanıtmasından bu yana uzun bir yol kat etti. HTTP/1.0 1996’da başlıklar ve durum kodları ekleyerek bunu takip etti ve HTTP/1.1 RFC 2068’de (1997) standartlaştırıldı ve daha sonra RFC 2616’da (1999) geliştirildi. HTTP/1.1, yaklaşık yirmi yıl boyunca web üzerindeki istemci-sunucu iletişiminin belkemiği olarak hizmet vermiştir.

Ancak web dramatik bir şekilde değişti. Modern web sayfaları basit belgelerden düzinelerce JavaScript paketi, CSS dosyası, resim ve API çağrısı yükleyen karmaşık uygulamalara dönüştü. Geniş bant bağlantılar ve güçlü donanımlarla bile HTTP/1.1’in mimarisi darboğazlar yarattı:

Hat başı engelleme: Her TCP bağlantısı bir seferde yalnızca bir isteği işleyebilir, bu da kaynaklar sıraya girdiğinden gereksiz ağ trafiğine neden olur
Bağlantı ek yükü: Masaüstü web tarayıcıları ve mobil web tarayıcıları bu sınırlamayı aşmak için genellikle kaynak başına 6-8 paralel TCP bağlantısı açar
Gereksiz başlıklar: Her HTTP isteği aynı ayrıntılı üstbilgileri (çerezler, kullanıcı aracısı, kabul üstbilgileri) tekrar tekrar gönderir

Google bu sorunların farkına vardı ve 2009 yılında SPDY projesini başlattı. İlk olarak 2010 yılı civarında Chrome’da uygulanan SPDY, çeşitli yenilikler getirdi:

Metin tabanlı protokoller yerine ikili çerçeveleme
Tek bir bağlantı üzerinden birden fazla isteği çoğullama
Ek yükü azaltmak için başlık sıkıştırma
Kritik kaynaklar için akış önceliklendirmesi

IETF HTTP Çalışma Grubu SPDY’nin potansiyelini görmüş ve 2012 yılında HTTP/2 için başlangıç noktası olarak kabul etmiştir. IETF http çalışma grubunun kapsamlı çalışmalarının ardından RFC 7540 (HTTP/2) ve RFC 7541 (HPACK) Mayıs 2015’te yayınlanmıştır.

Tarayıcıların benimsenmesi hızla ilerledi:

Chrome, Chrome 51’den itibaren HTTP/2 lehine SPDY’yi kullanımdan kaldırdı (Mayıs 2016)
Firefox HTTP/2 desteğini 36. sürümde ekledi (Şubat 2015)
Safari sürüm 9’da (Eylül 2015) takip edildi
Microsoft Edge ilk sürümünden itibaren HTTP/2 desteği ile birlikte gönderildi
Internet Explorer 11 bile Windows 8.1 ve sonrasında HTTP/2 desteği kazandı

Tasarım Hedefleri ve HTTP/1.1’den Temel Farklılıklar

HTTP/2, HTTP/1.1 semantiği ile tam uyumluluğu korur. GET ve POST gibi yöntemler aynı şekilde çalışır. Durum kodları değişmeden kalır. URI’ler ve HTTP başlık alanları aynı kuralları izler. Değişen şey, bu verilerin kablo boyunca nasıl hareket ettiğidir – gerçek yük hızını belirleyen taşıma katmanı mekaniği.

Protokolün tasarım hedefleri açıktı:

Hedef	HTTP/2 Bunu Nasıl Başarıyor?
Gecikme süresini azaltın	Çoklama, HTTP düzeyinde hat başı engellemeyi ortadan kaldırır
Daha iyi bağlantı kullanımı	Tek bir TCP bağlantısı, bir kaynağa gelen tüm istekleri işler
Başlık üstünü kesin	HPACK sıkıştırması önceden aktarılan başlık değerlerini küçültür
Mobil performansı iyileştirin	Daha az bağlantı ve daha küçük başlıklar yüksek gecikmeli ağlara fayda sağlar

Bu tasarımın güzelliği, uygulama düzeyinde geriye dönük uyumluluktur. Mevcut web uygulama kodunuzun (rotalar, işleyiciler, yanıt mantığı) değişmesi gerekmez. Faydalarını görmek için yalnızca istemci ve sunucu yığınının HTTP/2’yi desteklemesi gerekir.

Bu durum, HTTP/1.1’in geliştiricilerin manuel olarak uygulamak zorunda kaldığı geçici çözümleriyle keskin bir tezat oluşturmaktadır:

Etki alanı parçalama: Daha fazla bağlantı açmak için varlıkları birden fazla etki alanına yayma
Varlık birleştirme: İstekleri azaltmak için CSS ve JavaScript dosyalarını bir araya getirme
Görüntü sprite’ları: Birden fazla görüntüyü tek dosyada birleştirme
Inlining: CSS ve JavaScript’i doğrudan HTML’ye gömme

HTTP/2’nin temel mekaniği bu hilelerin yerini alıyor:

İkili çerçeveleme katmanı: Çerçevelere bölünmüş mesajlar, verileri ikili protokol birimleri olarak verimli bir şekilde taşır
Çoklanmış akışlar: Aynı bağlantı üzerinden birden fazla eşzamanlı değişim gerçekleşir
HPACK başlık sıkıştırması: Dinamik tablolar başlıkları takip ederek fazlalıkları ortadan kaldırır
Sunucu itme: Sunucular, istemcinin ihtiyaç duyacağı kaynakları proaktif olarak gönderir
Akış önceliklendirme: İstemciler, akış bağımlılık ağırlıkları aracılığıyla hangi kaynakların daha önemli olduğunu bildirir

İkili Çerçeveleme, Akışlar, Mesajlar ve Çoklama

HTTP/2’nin kalbinde, HTTP/1.1’in metin tabanlı formatından temel bir farklılık olan ikili çerçeve katmanı yer almaktadır. Her HTTP mesajı tutarlı bir çerçeve düzenine sahip ikili çerçevelere ayrılır: uzunluk, tür, bayraklar ve akış tanımlayıcılarını içeren 9 baytlık bir çerçeve başlığı ve ardından isteğe bağlı yük verileri.

Hiyerarşinin anlaşılması üç kavramın kavranmasını gerektirir:

Akışlar, tek bir bağlantı içindeki bağımsız, çift yönlü kanallardır. Her akışın 31 bitlik benzersiz bir tanımlayıcısı vardır. İstemciler akışları tek numaralı kimliklerle (1, 3, 5…) başlatırken, sunucular push gibi sunucu tarafından başlatılan akışlar için çift numaralı kimlikleri (2, 4, 6…) kullanır. Beklenmeyen bir akış tanımlayıcısı bir hatayı tetikler. Maksimum eşzamanlı akış ayarı, kaç tanesinin aynı anda etkin olabileceğini kontrol eder.

Mesajlar HTTP isteklerinin veya yanıtlarının tamamını temsil eder. Tam bir başlık bloğu bir veya daha fazla çerçeveden oluşur ve yanıtlar gövde için birden fazla veri çerçevesi içerebilir. Bir alıcı başlık bloğu parçalarıyla karşılaştığında, tam mesajı yeniden oluşturmak için bunları yeniden birleştirir.

Çerçeveler kablo üzerindeki en küçük birimlerdir. Yaygın çerçeve ve hata türleri şunlardır:

VERİ çerçeveleri: İstek/yanıt gövde içeriğini taşır
HEADERS çerçevesi: Muhtemelen başlık bloğu parçaları olarak adlandırılan birden fazla çerçeveye bölünmüş HTTP başlık alanlarını içerir
AYARLAR: Yapılandırma için bağlantı kontrol mesajları
WINDOW_UPDATE: Akış kontrol penceresi ayarlamaları
PUSH_PROMISE: Sunucu push’unu duyurur
RST_STREAM: Bir akışı bir hata koduyla sonlandırır
GOAWAY: Zarif bağlantı kapatma işlemini başlatır

Sihir çoklama yoluyla gerçekleşir. Eşzamanlı olarak açık olan birden fazla akıştan gelen çerçeveler tek bir TCP bağlantısı üzerinden birbirine eklenebildiğinden (her iki uç nokta da çerçeveleri gerektiği gibi birbirine ekler) bekleme olmaz. Alıcı çerçeveleri akış tanımlayıcısına göre yeniden birleştirir.

İhtiyaç duyulan tipik bir web sayfasını yüklediğinizi düşünün:

index.html (10 KB)
styles.css (25 KB)
app.js (100 KB)
logo.png (15 KB)
hero-image.jpg (200 KB)

HTTP/1.1 ile tarayıcınız bunları paralel olarak almak için birden fazla bağlantı açar ve yine de sınırlara ulaşır. HTTP/2 ile, beş kaynağın tümü birden fazla veri akışı olarak tek bir bağlantı üzerinden eş zamanlı olarak iletilir. Hem istemci hem de sunucu tüm bağlantıyı verimli bir şekilde yönetirken, farklı akışlardan gelen VERİ çerçeveleri iç içe geçer.

Bu, birden fazla TCP bağlantısı ihtiyacını ortadan kaldırarak bağlantı akış kontrol penceresi ek yükünü azaltır ve web performansını önemli ölçüde artırır.

HPACK ile Başlık Sıkıştırma

RFC 7541’de (Mayıs 2015’te HTTP/2 ile birlikte yayınlandı) tanımlanan HPACK, HTTP/2 için özel olarak tasarlanmış başlık sıkıştırması sağlar. Bu önemli çünkü HTTP/1.1 başlıkları ayrıntılı ve tamamen sıkıştırılmamıştı ve her istekte gereksiz ağ trafiğine neden oluyordu.

Tipik bir HTTP isteğinin başlıklarını düşünün:

Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9...
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cookie: session=abc123def456; tracking=xyz789...

Bu başlıklar genellikle istek başına 700-800 baytı aşar. Çerezlerle birlikte birkaç kilobayta kadar çıkabilirler. Sayfa başına düzinelerce istekle çarptığınızda, önemli miktarda bant genişliği harcarsınız – özellikle mobil ağlarda acı verici.

HPACK üstbilgileri üç mekanizma aracılığıyla sıkıştırır:

Statik tablo: 61 önceden tanımlanmış ortak başlık alanı/değer çifti (örneğin :method: GET veya :status: 200) asla iletime ihtiyaç duymaz
Dinamik tablo: İstemci ve sunucunun birlikte oluşturduğu, daha önce aktarılan başlık değerlerini yeniden kullanmak üzere depolayan, bağlantıya özel bir tablo
Huffman kodlaması: Dize değerleri, önceden tanımlanmış bir Huffman tablosu kullanılarak kodlanır ve metin gösterimleri küçültülür

Sonuç dramatiktir. İlk istek dinamik tabloda ortak başlıklar oluşturduktan sonra, sonraki istekler yalnızca dizin referansları iletebilir. Kilobayt olarak başlayan başlıklar onlarca bayta kadar küçülür.

HPACK, SPDY’nin DEFLATE’i gibi daha önceki sıkıştırma şemalarını etkileyen CRIME ve BREACH gibi güvenlik açıklarından kaçınmak için özel olarak tasarlanmıştır. Statik Huffman kodları ve dikkatli tablo yönetimi kullanan HPACK, saldırganların karışık saldırgan/kurban verilerinden sırları çıkarmak için sıkıştırma oranı analizini kullanmasını engeller.

HPACK’in yalnızca HTTP başlıkları üzerinde çalıştığını belirtmek gerekir. Yanıt gövdeleri, başlık sıkıştırmasından tamamen ayrı olarak HTTP katmanında gzip veya Brotli gibi standart içerik kodlama mekanizmalarını kullanmaya devam eder.

Sunucu İtme ve Akış Önceliklendirme

HTTP/2, HTTP/1.1 geçici çözümlerinin yerini almak üzere tasarlanmış iki optimizasyon özelliği sunar: proaktif kaynak teslimi için sunucu itme ve akıllı kaynak sıralaması için akış önceliklendirme.

Sunucu İtme

Sunucu push’u, bir web sunucusunun kaynakları açıkça talep edilmeden önce istemciye göndermesini sağlar. Mekanizma PUSH_PROMISE çerçeveleri aracılığıyla çalışır:

Müşteri istekleri /index.html
Sunucu HTML ile yanıt verir ancak /styles.css ve /app.js dosyalarını göndereceğini bildiren PUSH_PROMISE çerçeveleri de gönderir
Sunucu bu kaynakları sunucu tarafından başlatılan yeni akışlara gönderir (akış tanımlayıcıları, düşük değerli akış tanımlayıcı atama kurallarına göre çift sayılar kullanılarak)
Tarayıcı, HTML’yi ayrıştırmadan önce kaynakları alır ve onlara ihtiyacı olduğunu keşfeder

Böylece gidiş gelişler ortadan kalkar. Bunun yerine:

HTML İste → HTML Al
HTML’yi ayrıştırın, gereken CSS’yi keşfedin → CSS isteyin
CSS’yi ayrıştırın, gereken fontları keşfedin → Fontları isteyin

Sunucu itme işlemi 2-3. adımları 1. adıma dönüştürür.

Ancak sunucu itme işleminin uygulamada sorunlu olduğu kanıtlanmıştır:

Tarayıcılar kaynakları zaten önbelleğe almış olabilir, bu da itme işlemlerini boşa çıkarır
Yanlış yapılandırılmış sunucular bant genişliğini boşa harcayarak çok agresif bir şekilde zorluyor
Önbellek özetleme mekanizmaları hiçbir zaman yaygın olarak benimsenmedi
Birçok CDN ve tarayıcı artık varsayılan olarak push’u sınırlandırıyor veya devre dışı bırakıyor

İstemciler, bağlantı önsözlerinde SETTINGS_ENABLE_PUSH = 0 ayarını yaparak push özelliğini tamamen devre dışı bırakabilirler. Bir istemci bağlantı önsözü push’u hemen devre dışı bıraktığında, sunucu bağlantı önsözü onay ve uyumluluktan oluşur.

Akarsu Önceliklendirmesi

Akış önceliklendirme, istemcilerin kaynak önemine işaret etmesini sağlayarak sunucuların bant genişliğini etkili bir şekilde tahsis etmesine yardımcı olur. Mekanizma şunları kullanır:

Ağırlıklar: Göreceli önemi gösteren 1-256 arası değerler
Bağımlılıklar: Akışlar, akış bağımlılık bildirimleri aracılığıyla bir bağımlılık ağacı oluşturarak diğer akışlara bağımlı olabilir

Pratik örnek:

HTML akışı (ağırlık 256, bağımlılık yok) – en yüksek öncelik
CSS akışı (ağırlık 200, HTML’ye bağlıdır) – yüksek öncelik
Kat üstü görüntüler (ağırlık 100, CSS’ye bağlıdır)
Analitik JavaScript (ağırlık 16, HTML’ye bağlıdır) – düşük öncelikli

Bu, kritik işleme yolu kaynaklarının önce ulaşmasını sağlayarak toplam aktarım süresi benzer kalsa bile algılanan yükleme hızını artırır.

Önemli uyarılar:

Önceliklendirme tavsiye niteliğindedir, zorunlu değildir
Sunucu uygulamaları, öncelikleri nasıl yerine getirdikleri konusunda büyük farklılıklar gösterir
Aracılar (proxy’ler, CDN’ler) çerçeveleri yeniden sıralayabilir
Ayarlama, varsayımlarla değil gerçek trafikle test yapılmasını gerektirir

İlan edilen eşzamanlı akış sınırı, aynı anda kaç akışın etkin önceliğe sahip olabileceğini etkiler.

Akış Kontrolü, Hata İşleme ve Güvenlik Hususları

HTTP/2, uygulama katmanı zekasının taşıma katmanı varsayılanlarından daha iyi performans gösterdiği senaryoları ele alarak TCP’nin üzerinde kendi akış kontrolünü ve hata işlemesini uygular.

Akış Kontrolü

Akış kontrolü, hızlı göndericilerin yavaş alıcıları ezmesini önler. HTTP/2, WINDOW_UPDATE çerçeveleri ile kredi tabanlı bir sistem kullanır:

Her akışın kendi alıcı akış kontrol penceresi vardır
Bağlantıda ayrıca bir bağlantı akış kontrol penceresi vardır
Varsayılan pencere boyutu: 65.535 bayt (64 KB)
Göndericiler, alıcının kullanılabilir penceresini aşan VERİ çerçevelerini iletemez
Alıcılar daha fazla kredi vermek için WINDOW_UPDATE çerçeveleri gönderir

Temel özellikler:

Akış kontrolü hop-by-hop’tır (her gönderici/alıcı çifti arasında uygulanır)
Devre dışı bırakılamaz
Yalnızca VERİ çerçeveleri pencereye karşı sayılır; diğer zorunlu çerçeve verileri sayılmaz
Hem akış kontrolü hem de bağlantı akış kontrolü bağımsız olarak çalışır

Bu, tek bir hızlı akışın bağlantı kaynaklarını tekelleştirmesini önler, özellikle istemciler ve kaynaklar arasında proxy’ler veya CDN’ler bulunduğunda önemlidir.

Hata İşleme

HTTP/2 ayrıntılı hata sinyali sağlar:

Akış düzeyinde hatalar: RST_STREAM, PROTOCOL_ERROR veya FLOW_CONTROL_ERROR gibi hata kodları taşıyan bir akışı diğerlerini etkilemeden hemen sonlandırır
Bağlantı düzeyinde hatalar: GOAWAY bağlantıyı zarif bir şekilde kapatarak uçuş halindeki isteklerin tamamlanmasına izin verirken yenilerini engeller

Protokol, aşağıdakileri içeren bir hata kodu kayıt defteri tanımlar:

PROTOCOL_ERROR (0x1): Genel protokol ihlali
FLOW_CONTROL_ERROR (0x3): Akış kontrol kuralları ihlal edildi
FRAME_SIZE_ERROR (0x6): Çerçeve SETTINGS_MAX_FRAME_SIZE değerini aştı
INADEQUATE_SECURITY (0xc): Aktarım katmanı güvenlik yapılandırması yetersiz

Güvenlikle İlgili Hususlar

RFC 7540 teknik olarak şifreleme gerektirmese de, tüm büyük web tarayıcıları taşıma katmanı güvenliği (TLS) üzerinden HTTP/2 gerektirir. Bu da TLS 1.2+’yı fiili temel haline getirmektedir:

Bağlantı ALPN (Uygulama Katmanı Protokolü Anlaşması) dahil TLS el sıkışması ile başlar
ALPN uzantısı HTTP/2 için “h2” tanımlayıcısı ile anlaşır
Sunucular, teknik özellikler tarafından kara listeye alınmış zayıf şifre paketlerinden kaçınmalıdır
RC4 veya diğer kullanımdan kaldırılmış algoritmaları kullanan şifre paketleri INADEQUATE_SECURITY hatalarını tetikler

Gizlilikle ilgili hususlar şunları içerir:

AYARLAR ve öncelik desenleri istemcilerin parmak izini alabilir
Kaynak başına tek bağlantı, tüm kullanıcı etkinliğini o kaynakla ilişkilendirir
İkili protokol trafiği gizler ancak ağ gözlemcilerinden saklamaz

TCP Hat Başı Engelleme

HTTP/2, HTTP düzeyindeki hat başı engellemesini çoğullama yoluyla çözer, ancak TCP düzeyindeki engelleme devam eder. Bir TCP paketi kaybolduğunda, bu bağlantıdaki tüm akışlar, verileri başarıyla ulaşan akışlar bile yeniden iletim tamamlanana kadar durur.

Bu sınırlama, gerçek akış bağımsızlığı sağlamak için QUIC (UDP tabanlı) üzerinden çalışan HTTP/3’ü motive etmiştir. Bir akışı etkileyen paket kaybı diğerlerini engellemez.

HTTP/2’yi Uygulamada Dağıtma ve Kullanma

2026 yılında HTTP/2’yi etkinleştirmek çok kolay. Modern web sunucularının ve CDN’lerin çoğu, öncelikle HTTPS üzerinden olmak üzere, kutudan çıkar çıkmaz bunu destekler. HTTP yükseltme mekanizması müzakereyi şeffaf bir şekilde gerçekleştirir.

İstemci Tarafı Gereksinimleri

Kullanıcıların özel bir şey yapmasına gerek yoktur:

Tüm modern masaüstü web tarayıcıları (Chrome, Firefox, Safari, Edge) varsayılan olarak HTTP/2’yi destekler
Mobil web tarayıcıları (Android için Chrome, iOS için Safari) tam destek içerir
Güncel tarayıcı sürümlerinde kalmak uyumluluk sağlar
HTTP/2 kullanılabilir olduğunda otomatik olarak anlaşır

Sunucu Tarafı Yapılandırması

Apache HTTP Sunucusu (2.4.17+):

mod_http2 modülünü etkinleştirin (eski mod_spdy değil)
TLS sanal konaklarına Protokoller h2 http/1.1 ekleyin
OpenSSL sürümünün ALPN’yi desteklediğinden emin olun

Nginx (1.9.5+):

server {
    listen 443 ssl http2;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    # ... rest of configuration
}

IIS (Windows Server 2016+):

HTTP/2, TLS 1.2+ ile HTTPS için varsayılan olarak etkinleştirilmiştir
Ek yapılandırma gerekmez

CDN Sağlayıcıları:

Cloudflare: HTTP/2 tüm planlarda varsayılan olarak etkin
AWS CloudFront: HTTPS dağıtımları için varsayılan olarak etkin
Fastly: Varsayılan olarak desteklenir ve etkinleştirilir

Doğrulama ve Sorun Giderme

HTTP/2’nin bu kontrol listesi ile çalıştığını onaylayın:

Tarayıcı DevTools: Ağ sekmesini açın, Protokol sütununu etkinleştirin, “h2 “yi arayın
Komut satırı: curl –http2 -I https://example.com yanıt olarak HTTP/2 gösterir
Çevrimiçi araçlar: HTTP/2 test hizmetleri yapılandırmayı doğrulama
Aracıları kontrol edin: CDN veya ters proxy HTTP/2’yi desteklemelidir, sadece kaynak sunucu değil

HTTP/2’yi engelleyen yaygın sorunlar:

OpenSSL sürümü ALPN desteği için çok eski
Yalnızca TLS 1.0/1.1 yapılandırması
Geri dönüşü tetikleyen zayıf şifre paketleri
HTTP/2 desteğini sıyıran yanlış yapılandırılmış proxy

HTTP/2 ve Ötesi

HTTP/3 (RFC 9114, 2022’de yayınlandı) dağıtılmaya başlasa bile HTTP/2, modern web iletişimi için baskın protokol olmaya devam ediyor. HTTP/3, QUIC üzerinden çalışarak TCP hat başı engellemesini ele alır, ancak HTTP/2’nin tek TCP bağlantı modeli web trafiğinin çoğuna etkili bir şekilde hizmet vermeye devam eder.

Çoğu site için HTTP/2, minimum yapılandırma çabasıyla önemli web performansı iyileştirmeleri sağlar. Bugün HTTP/2 üzerinden çerçeve alışverişine başlayın ve ister masaüstünde ister mobil cihazlarda olsun kullanıcılarınız daha hızlı, daha verimli sayfa yüklemeleriyle karşılaşsın.

Önemli Çıkarımlar

HTTP/2, çoklama yoluyla web performansında devrim yaratarak tek bir bağlantı üzerinden birden fazla eşzamanlı alışverişe izin veriyor
HPACK başlık sıkıştırması, özellikle mobil kullanıcılara fayda sağlayarak gereksiz başlık iletimini ortadan kaldırır
Uygulama farklılık gösterse de sunucu itme ve akış önceliklendirme kaynak dağıtımını optimize eder
Akış kontrolü, birden fazla akışta kaynak açlığını önler
Modern sunucularda dağıtım basittir, öncelikle HTTPS yapılandırması gerektirir
Tüm büyük tarayıcılar HTTP/2’yi destekleyerek son kullanıcılar için benimsemeyi sorunsuz hale getirir

Sonraki Adımlar

Web sunucunuzda HTTP/2’yi doğrulamadıysanız, şimdi tam zamanı. Tarayıcınızın geliştirici araçlarını açın, sitenizi yükleyin ve Protokol sütununu kontrol edin. “h2” yerine “http/1.1” görüyorsanız, sunucu yapılandırmanızı gözden geçirin; önemli performans kazanımlarını masada bırakıyorsunuz demektir.

Halihazırda HTTP/2 çalıştıranlar için sunucunuzun HTTP/2 bağlantı metriklerini izlemeyi düşünün. Birden fazla eş zamanlı akışın gerçek trafik altında nasıl davrandığını anlamak, kullanıcılarınız sorunları fark etmeden önce optimizasyon fırsatlarını belirlemeye yardımcı olur.