HTTP/2 ve proxy

Proxy servisleri HTTP/2'yi, HTTP/2 bağlantılarını sonlandırıp istekleri origin sunuculara HTTP/1.1 üzerinden ileten ya da HTTP/2'yi istemci ile origin arasında uçtan uca geçiren bir aracı olarak çalışarak destekler.

HTTP/2, HTTP/1.1'in yapısal sınırlamalarını gidererek web performansını artırmak için tasarlanmış, HTTP protokolünün önemli bir revizyonudur. Başlıca özellikleri arasında istek ve yanıtların tam çoğullanması (multiplexing), HPACK ile başlık sıkıştırma, server push ve istek önceliklendirme yer alır. Bir proxy servisi için bu özellikleri yönetmek, uyumluluğu ve denetimi korurken HTTP/2'nin avantajlarından yararlanmak adına özel mimari değerlendirmeler gerektirir.

HTTP/2 protokolünün temelleri

HTTP/2 tek bir TCP bağlantısı üzerinde çalışır ve eşzamanlı istek/yanıt iletişimi için birden çok çift yönlü stream kurar. Bu çoğullama, HTTP/1.1'de bulunan head-of-line blocking sorununu ortadan kaldırır. Başlık sıkıştırma (HPACK), HTTP başlıklarını kompakt bir ikili biçimde kodlayarak ve paylaşılan bir dinamik tablo tutarak ek yükü azaltır. Server push, sunucunun ihtiyaç duyulacağını öngördüğü kaynakları istemciye önceden göndermesine olanak tanır ve gecikmeyi azaltır.

Bu özellikler faydalı olmakla birlikte, geleneksel olarak ayrı TCP bağlantıları üzerinde istek-yanıt modeliyle çalışan proxy servisleri için karmaşıklık getirir.

HTTP/2 için proxy mimarileri

Proxy servisleri HTTP/2 desteği için genellikle iki temel mimariden birini uygular: sonlandırma veya uçtan uca.

HTTP/2 sonlandırma (frontend HTTP/2, backend HTTP/1.1)

Bu modelde proxy sunucusu istemciyle bir HTTP/2 bağlantısı kurar. HTTP/2 protokolünü sonlandırır, istekleri çözer ve ardından bunları HTTP/1.1 kullanarak origin sunucuya iletir. Origin sunucudan gelen yanıtlar (HTTP/1.1) daha sonra HTTP/2'ye dönüştürülüp istemciye gönderilir.

İşlem akışı:

1. İstemci, proxy'ye bir HTTP/2 bağlantısı başlatır (genellikle TLS üzerinden, ALPN ile h2 görüşülerek).
2. Proxy, HTTP/2 frame'lerini alır ve HTTP/1.1 benzeri istekleri yeniden oluşturur (HPACK başlıklarının çözülmesi dahil).
3. Proxy, HTTP/1.1 isteklerini origin sunucuya iletir.
4. Origin sunucu HTTP/1.1 ile yanıt verir.
5. Proxy, HTTP/1.1 yanıtlarını alır, bunları HTTP/2 frame'lerine kodlar (HPACK sıkıştırması dahil) ve istemciye gönderir.

Avantajları:

• Backend uyumluluğu: origin sunucuların HTTP/2'yi desteklemesi gerekmez. Bu, eski sistemler veya henüz yükseltilmemiş servisler için faydalıdır.
• Yük devretme: proxy, HTTP/2 protokol görüşmesi, başlık sıkıştırma/açma ve stream yönetiminin işlem yükünü üstlenerek origin sunucuların yükünü azaltır.
• Denetim: genellikle HTTP/1.1 semantiğine göre tasarlanmış önbellekleme, yük dengeleme, istek değiştirme ve güvenlik filtreleme gibi geleneksel proxy işlevlerini gerçekleştirmek daha kolaydır.

Dezavantajları:

• Özellik kaybı: origin sunucudan gelen server push gibi HTTP/2 özellikleri doğrudan geçirilemez. Proxy'nin kendi server push mantığını uygulaması gerekir.
• Protokol uyumsuzluğu ek yükü: HTTP/2 ile HTTP/1.1 arasındaki sürekli dönüştürme, proxy tarafında işlem yükü oluşturur.
• Artan gecikme: bu ek işlem adımı, doğrudan bir HTTP/2 bağlantısına kıyasla küçük bir gecikme getirebilir.

Kullanım senaryosu: HTTP/2'nin istemci tarafındaki performans avantajlarının istendiği ancak backend altyapısının henüz HTTP/2'ye hazır olmadığı durumlar veya proxy tarafında kapsamlı istek manipülasyonu gerektiğinde idealdir.

Uçtan uca HTTP/2 (tam proxy)

Uçtan uca HTTP/2 proxy kurulumunda proxy, hem istemciyle hem de origin sunucuyla HTTP/2 bağlantılarını sürdürür. Proxy şeffaf bir aracı olarak davranır ve HTTP/2 frame'lerini veya stream'lerini protokol dönüşümü yapmadan doğrudan iletir.

İşlem akışı:

1. İstemci, proxy'ye bir HTTP/2 bağlantısı başlatır.
2. Proxy, origin sunucuya bir HTTP/2 bağlantısı kurar.
3. Proxy, HTTP/2 frame'lerini/stream'lerini istemci ile origin arasında iletir.
4. Proxy, stream ID'lerini yönetir ve gerektiğinde stream'leri önceliklendirir.

Avantajları:

• Tüm özelliklerin korunması: origin'den gelen server push, stream önceliklendirme ve HPACK sıkıştırma dahil tüm HTTP/2 özellikleri uçtan uca korunur.
• Daha düşük gecikme: dönüştürme ek yükünü ortadan kaldırır; origin sunucu coğrafi olarak yakınsa veya HTTP/2 için yüksek düzeyde optimize edilmişse gecikme daha düşük olabilir.
• Proxy üzerinde azalan yük: proxy'nin rolü tam protokol dönüşümü yerine ağırlıklı olarak frame iletimi ve stream yönetimidir.

Dezavantajları:

• Origin sunucu gereksinimi: origin sunucunun HTTP/2'yi tam olarak desteklemesi gerekir.
• Azalan görünürlük/denetim: HPACK sıkıştırması ve HTTP/2 frame'lerinin ikili yapısı nedeniyle proxy'nin HTTP başlıklarını veya istek gövdelerini doğrudan değiştirmesi daha karmaşık hale gelir. Derin paket incelemesi genellikle frame'lerin tümüyle çözülüp yeniden kodlanmasını gerektirir.
• Güvenlik etkileri: origin bağlantısı da TLS ise proxy bir TLS sonlandırma noktası olarak davranır ve origin'e yeni bir TLS bağlantısı kurar; bu, güvenlik duruşunu etkileyebilir veya sertifika yönetimi gerektirebilir.

Kullanım senaryosu: hem istemcilerin hem de origin sunucuların HTTP/2'yi desteklediği ve amacın, yönlendirme ile yük dengelemenin ötesinde asgari proxy müdahalesiyle HTTP/2'nin performans avantajlarını tüm bağlantı yolu boyunca en üst düzeye çıkarmak olduğu durumlar için en uygunudur.

Proxy servisleri için temel değerlendirmeler

Application-Layer Protocol Negotiation (ALPN)

HTTP/2 genellikle TLS üzerinden ALPN kullanılarak görüşülür. Bir istemci proxy'ye bağlandığında, TLS ClientHello mesajında h2 (TLS üzerinden HTTP/2) ve http/1.1 desteğini belirten bir ALPN uzantısı gönderir. Proxy tercih edilen protokolü seçer.

Örnek (kavramsal ALPN el sıkışması):

ClientHello (ALPN: [h2, http/1.1]) -> Proxy
Proxy selects h2
ServerHello (ALPN: h2) <- Proxy

Başlık çevirisi ve HPACK

HTTP/2 ile HTTP/1.1 arasında geçiş yaparken (sonlandırma modeli), proxy'nin HTTP/2 isteklerindeki HPACK başlıklarını açması ve HTTP/2 yanıtları için HTTP/1.1 başlıklarını HPACK ile yeniden kodlaması gerekir. Bu, durum bilgisi tutan HPACK dinamik tablosunun yönetilmesini içerir.

Stream yönetimi ve önceliklendirme

HTTP/2, tek bir bağlantı üzerinde birden çok eşzamanlı stream'e izin verir. Bir proxy bu stream'leri yönetmeli, onları backend bağlantılarına eşlemeli (HTTP/1.1 backend'ler için) ya da öncelik ipuçlarına uyarak iletmelidir. Hatalı stream yönetimi, HTTP/2'nin çoğullama avantajlarını ortadan kaldırabilir.

Server push yönetimi

• Sonlandırma: proxy HTTP/2'yi sonlandırıyorsa, origin'den gelen server push isteklerini doğrudan iletemez. Proxy, içerik analizine veya yapılandırmaya dayalı olarak kendi server push mantığını uygulayabilir.
• Uçtan uca: uçtan uca bir kurulumda origin'den gelen server push frame'leri doğrudan istemciye iletilir.

Trafik inceleme ve değiştirme

HTTP/2 trafiğini incelemek veya değiştirmek HTTP/1.1'e göre daha zordur.
* Şifreleme: HTTP/2 neredeyse her zaman TLS ile kullanılır; inceleme için proxy'nin TLS'i sonlandırması gerekir.
* Başlık sıkıştırma: başlıkları değiştirmek, HPACK ile çözme, değiştirme ve yeniden kodlamayı gerektirir; bu durum bilgisi tutar ve karmaşık olabilir.

Yük dengeleme

HTTP/2 ile tek bir istemciden gelen birden çok istek aynı bağlantı üzerinden ulaşabilir. Yük dengeleyiciler, tek bir istemci bağlantısındaki tüm stream'leri tek bir backend sunucuya mı yönlendireceğine (oturum yapışkanlığı) yoksa stream'leri birden çok backend sunucuya mı dağıtacağına karar vermelidir. İkincisi, stream farkındalığı olan daha gelişmiş bir yük dengeleme gerektirir.

Yapılandırma örnekleri (Nginx)

Yaygın bir reverse proxy olan Nginx, hem HTTP/2 sonlandırmayı hem de uçtan uca proxy'lemeyi destekler.

HTTP/2 sonlandırma (frontend HTTP/2, backend HTTP/1.1):

server {
    listen 443 ssl http2; # İstemci bağlantıları için HTTP/2'yi etkinleştirir
    server_name example.com;

    ssl_certificate /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;

    location / {
        proxy_pass http://backend_servers; # Backend HTTP/1.1
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        # Nginx, istemcinin HTTP/2 isteklerini backend için otomatik olarak HTTP/1.1'e çevirir
    }
}

upstream backend_servers {
    server 192.168.1.100:80;
    server 192.168.1.101:80;
}

Uçtan uca HTTP/2 (frontend HTTP/2, backend HTTP/2):

server {
    listen 443 ssl http2; # İstemci bağlantıları için HTTP/2'yi etkinleştirir
    server_name example.com;

    ssl_certificate /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;

    location / {
        proxy_pass https://backend_h2_servers; # Backend HTTP/2
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_ssl_server_name on; # SNI'yi backend'e iletir
        proxy_http_version 2; # Nginx'e backend bağlantısında HTTP/2 kullanmasını söyler
    }
}

upstream backend_h2_servers {
    server 192.168.1.100:443;
    server 192.168.1.101:443;
}

Karşılaştırma: HTTP/2 sonlandırma ile uçtan uca

Pratik sonuçlar

Bir proxy servisinde HTTP/2 uygulamak, kullanıcı deneyimini ve altyapı verimliliğini doğrudan etkiler. Kullanıcılar, çoğullama ve başlık sıkıştırma sayesinde daha hızlı sayfa yüklemelerinden ve daha akıcı bir web deneyiminden yararlanır. Proxy altyapısı açısından HTTP/2 desteği, özellikle TLS sonlandırma ve HPACK işleme için CPU kullanımı konusunda dikkatli kaynak yönetimi gerektirir. Sonlandırma ile uçtan uca arasındaki seçim, mevcut backend mimarisine, performans hedeflerine ve trafik üzerinde proxy düzeyinde denetim ihtiyacına bağlıdır. Güvenlik hâlâ en öncelikli konudur; çoğu HTTP/2 dağıtımında TLS bir ön koşuldur ve sağlam sertifika yönetimi ile güvenli yapılandırma gerektirir.