TLS Sonlandırma mı Yoksa Aktarım mı? Doğru Webship Ters Proxy Sınırını Seçmek

TLS sonlandırma ile TLS geçişi arasında seçim yapmak basit bir proxy ayarı değildir. Bu, şifrelemenin nerede sona ereceğini, hangi sistemin oturum anahtarlarını tutacağını, Webship'in HTTP'yi inceleyip inceleyemeyeceğini ve hangi katmanın uygulama güvenliğini uygulamak zorunda olduğunu belirler.

Webship varsayılan olarak geçiş modundadır. Bu, uygulamanın düz metin ve aktif oturum anahtarlarının kaynağında kalmasını sağlar. Yalnızca uç noktanın HTTP isteğini anlaması ve buna göre işlem yapması gerektiğinde sonlandırmayı etkinleştirin.

Bir cümlede karar

TLS sınırının orijine ait olması gerektiğinde TLS geçişi (pass-through) kullanın. Webship HTTP trafiğini yönlendirmeli, korumalı, dönüştürmeli, önbelleğe almalı veya gözlemlemeli ise TLS sona erdirme (termination) kullanın.

Hiçbir mod evrensel olarak daha güvenli değildir. Geçiş modu, uçta işlenen hassas materyali azaltır, ancak uca ait HTTP güvenlik kontrollerini ortadan kaldırır. Sonlandırma, denetlenebilir bir uygulama noktası ekler, ancak Webship öğesini güvenilir TLS sınırının bir parçası yapar.

| Endişe | TLS sonlandırma | TLS geçişi | | --- | --- | --- | | TLS uç noktası | Webship | Kaynak | | Uygulama düz metni Webship'de | Evet | Hayır | | Webship üzerindeki aktif aşağı yönlü oturum anahtarları | Evet | Hayır | | HTTP yolu veya yöntemi ile yönlendir | Evet | Hayır | | WAF, API Shield ve gövde limitleri Webship üzerinde | Evet | Hayır | | Vekil önbelleği, yeniden yazmalar ve yönlendirme başlıkları | Evet | Hayır | | TCP yönlendirme girişi | HTTP yetkisi ve yönlendirme politikası | ClientHello SNI | | HTTP/3 yönlendirme | HTTP istek verisi | Bir ortak UDP kaynağı | | Orijin sorumluluğu | HTTP veya ayrı yapılandırılmış upstream TLS | Tam TLS, ALPN ve HTTP yığını |

Bu nedenle önemli soru “Hangi anahtar daha hızlı?” değildir. Önemli soru “Hangi bileşenin talebi görmesine ve kontrol etmesine izin verilmelidir?”dir.

Webship hangi sonlandırmayı verir

tls_termination = true ile, Webship aşağı akış TLS işlemini tamamlar ve şifre çözülmüş isteği HTTP ters proxy hattına iletir. Bu, aşağıdaki özelliklerin mümkün olmasını sağlar:

• yol, ana bilgisayar ve yönteme duyarlı yönlendirme;
• WAF ve API Shield denetimi;
• istek-gövdesi sınırları ve politika zaman aşımı süreleri;
• vekil önbellekleme ve nesil-güvenli geçersiz kılma;
• forwarding-header yönetimi ve HTTP erişim günlüğü alanları;
• vücut farkında SORGULAMA işlemi, güvenli olduğunda yeniden denemeler ve devre kesici politikası;
• istemciye yönelik ve yukarı akış bağlantıları arasındaki protokol çevirisi.

Bu mod aynı zamanda güvenlik sorumluluğunu değiştirir. Webship sunucusu, sertifika özel anahtarını, oturum anahtarlarını, çözülen istek ve yanıt verilerini, gözlemlenebilirlik çıktısını ve herhangi bir önbelleğe alınmış temsili korumalıdır. Eğer sonraki aşama şifreli kalmak zorundaysa, türlendirilmiş yukarı akış TLS ayrı olarak yapılandırılmalıdır; aksi takdirde HTTP yukarı akışı düz metindir.

Sonlandırma, Webship yalnızca şifreli bir taşıma aracısı olarak değil, aynı zamanda uygulama farkında bir uç nokta olarak davranması beklendiğinde sağ sınırdır.

Geçişin neyi koruduğu

tls_termination = false ile—varsayılan—Webship, HTTP isteği veya yanıtını çözmeden şifreli TLS veya QUIC trafiğini iletir. Uygulama düz metni ve aktif oturum anahtarları kaynaktaki (origin) konumda kalır.

Daha küçük güven sınırı, sertifikaların uygulama katmanında kalması gerektiğinde, uyumluluk politikası uçta şifre çözmeyi yasakladığında veya belirli bir kaynağa ait TLS kimliğinin değişmeden istemciye ulaşması gerektiğinde değerlidir. Ayrıca, iletim yolundan HTTP çözümlemesi ve politika işlerini de kaldırır.

Takası katıdır: Webship şifreleyemediğini inceleyemez. HTTP WAF kurallarını uygulayamaz, yol bazında yönlendirme yapamaz, başlıkları yeniden yazamaz, gövde-donanımlı API politikası uygulayamaz veya HTTP alan erişim günlüklerini dolduramaz. Kaynak, bu kontrollerin tümünü kendisi sağlamalıdır.

Bu nedenle geçiş, “daha az özellikli bir sonlandırma” değildir. Farklı bir güvenlik sahibine sahip farklı bir mimaridir.

Protokole özgü sınırlar önemlidir

HTTP/1.1 TLS ve HTTP/2 TLS için, Webship ClientHello'yu yalnızca SNI ile yapılandırılmış TCP hedefini seçmek için yeterince denetler. Her geçiş alanının gerçek istek yolu şifreli kaldığı için bir yakalama amaçlı path_prefix = "/" rotasına ihtiyacı vardır. SNI olmadan bir istemci yalnızca konfigürasyonda bir alan olduğunda kabul edilir.

Origin, istemcinin ALPN'sini müzakere etmeli ve seçilen protokolü desteklemelidir. Webship, TLS oturumu değişmeden geçerken bir HTTP/2 istemciyi bir HTTP/1.1 origin'e dönüştüremez.

HTTP/3 UDP üzerinden QUIC kullanır ve daha sıkı bir sınırı vardır. Passthrough, şifrelenmiş HTTP yetkilisine göre güvenli bir şekilde yönlendirilemez, bu nedenle yapılandırılmış her HTTP/3 rotası aynı IP-soket UDP kaynağına çözülmelidir. Webship, yapılandırma doğrulaması sırasında Unix soketlerini ve birden fazla HTTP/3 passthrough kaynağını kabul etmez, bunun yerine belirsiz bir şekilde sessizce yönlendirme yapmaz.

Düz metin HTTP/1.1 ve h2c, reverse_proxy.tls_termination tarafından etkilenmez. Bu ayar, yalnızca aşağı akış HTTP/1.1 TLS, HTTP/2 TLS ve HTTP/3 TLS'i kontrol eder.

Ölçülen istek kapasitesi

Webship 1.3.1 Debian kapasite kıyaslaması, iki şifreli ters-proxy modunu ayrı ayrı ölçtü. Kabul edilen her örnek, sıfır HTTP, soket, protokol, proxy, büyük sayfa hatası ve HTTP/3 paket kaybı hatası gerektiriyordu.

| Ters-proksi modu | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | TLS sonlandırma | 123,344 RPS | 124,957 RPS | 131,529 RPS | | TLS geçişi | 203.950 RPS | 266.845 RPS | 167.010 RPS |

Küçük yanıt geçişi, gerçekleştirmesi gereken daha az uygulama işine sahiptir: TLS'yi sonlandırmak, HTTP'yi çözümlemek, politikayı değerlendirmek ve yeni bir aşağı yöndeki TLS akışı üretmek yerine şifreli taşıma verilerini iletir. Daha yüksek geçiş isteği oranları, bu daha dar işi yansıtır.

Bu satırlar aynı özellik setlerini temsil etmez ve bir güvenlik mimarisinin evrensel olarak daha iyi olduğunu iddia etmek için kullanılmamalıdır. Sonlandırma, geçişin kasıtlı olarak sağlayamadığı HTTP farkındalığına sahip yetenekler için ödeme yapar.

Toplu akış sonucu değiştirir

Aynı kıyaslama testi, 100 MB akış matrisi için tam olarak 99.943.778 baytlık bir yanıt gövdesi kullandı. Burada, TLS sonlandırması tüm üç protokol için daha yüksek ortanca yük aktarım verisi sağladı:

| Ters-proksi modu | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | TLS sonlandırma | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | TLS geçişi | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |

Yön neden değişiyor? Sonlandırma modunda, kıyaslama kaynağı Webship adresine düz metin HTTP gönderir ve Webship optimize edilmiş alt akış toplu yolunun sahibidir. Büyük HTTP/1.1 ve HTTP/2 yanıtlar, uyarlanabilir Linux kTLS ve sınırlı taşıma özel tamponlama kullanabilir. HTTP/3 kTLS yerine QUIC hız kontrolü, DPLPMTUD ve her reaktör için toplu işleme kullanır.

Geçiş modu (pass-through) durumunda, kaynak (origin) aşağı yönlü TLS'e sahiptir ve Webship, ortaya çıkan şifreli akışı veya QUIC paketlerini iletir. Bu, kaynak TLS sınırını korur, ancak Webship'nin HTTP farkında toplu yanıt yolunu kullanamaz.

Yedi örnekli HTTP/3 kalifikasyonu ayrıca kararlılığı da kontrol etti. Sonlandırılmış akış, %2,12 varyasyon katsayısı ile 1.938,6 MiB/s medyan hızına ulaştı; geçiş modu ise %1,65 varyasyon katsayısı ile 1.748,5 MiB/s hızına ulaştı. Her ikisi de sıfır istemci, protokol ve paket kaybı hatasıyla tamamen aynı içeriği teslim etti.

Veri iletimini kasıtlı olarak yapılandır

Minimal bir geçiş yapılandırması, bir operatörün sertifika yollarını değiştirmeden daha sonra sonlandırmayı etkinleştirebilmesi için TLS kimliğini hazır durumda tutar:

[reverse_proxy]
enabled = true
tls_termination = false

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:443"]

[[reverse_proxy.policies]]
name = "default"
path_prefixes = ["/"]
total_timeout_ms = 30000

Sahneye konmuş Webship sertifikası doğrulanmıştır ancak aktif geçiş oturumları tarafından kullanılmamaktadır. 10.0.0.20:443 üzerindeki kaynak, TLS'yi sonlandırmalı ve istemci tarafından müzakere edilen protokolü desteklemelidir.

Edge HTTP gerektirdiğinde sonlandırmayı etkinleştir

Uygulama farkında bir uç için, sonlandırmayı etkinleştirin ve ortaya çıkan HTTP trafiğini seçilen kaynağa gönderin:

[reverse_proxy]
enabled = true
tls_termination = true

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/api"
strip_path_prefix = true
upstreams = ["10.0.0.20:8080", "10.0.0.21:8080"]

[[reverse_proxy.policies]]
name = "default"
hosts = ["app.example.com"]
path_prefixes = ["/"]
max_body_bytes = 1048576
request_body_idle_timeout_ms = 5000
upstream_header_timeout_ms = 5000
response_body_idle_timeout_ms = 5000
downstream_write_idle_timeout_ms = 5000
total_timeout_ms = 30000

Bu yapılandırma HTTP trafiğini yönlendirebilir ve inceleyebilir. Webship ile orijin arasındaki ağ zaten güvenilir veya izole değilse upstream TLS ekleyin.

Modları yeniden başlatmadan değiştir Webship

Webship, bir yapılandırma dosyası yeniden yüklemesi veya sürüm kontrolü yapılmış webship.reverse_proxy.apply_config MCP aracı ile tls_termination değerini değiştirebilir. Mevcut nesneyi ve sürümü webship.reverse_proxy.get_config ile okuyun, yalnızca istenen alanı tam olarak döndürülen nesnede değiştirin ve eşleşen expected_version_id ile gönderin.

Yeni TCP bağlantıları yeni modu kullanır. HTTP/3 istemciler değiştirilmiş UDP taşımasına yeniden bağlanır. Sertifika ve anahtar yolu değişiklikleri süreç bağımlıdır ve yeniden başlatma gerektirir, bu nedenle canlı bir geçişten önce geçerli bir sonlandırma kimliğini hazırlayın.

Sürüm kontrolü, bir operatörün eşzamanlı bir yapılandırma değişikliğini üzerine yazmasını önler. Reddedilen bir güncelleme, etkin çalışma zamanı ve kalıcı yapılandırmayı değiştirmeden bırakır.

Pratik bir seçim kontrol listesi

Bunların tümü doğru olduğunda geçiş yolunu seçin:

1. Kaynak, sertifika sınırını ve oturum anahtarlarını korumalıdır.
2. SNI düzeyinde TCP yönlendirmesi—veya paylaşılan bir HTTP/3 UDP kaynağı—yeterlidir.
3. Kaynak, gerekli WAF, yetkilendirme, kayıt tutma, gövde sınırları ve istismar kontrollerini sağlar.
4. Kenarlık önbelleği, yol yeniden yazımı, iletme başlığı politikası veya HTTP protokolü çevirisi gerekli değildir.

Aşağıdakilerden herhangi biri Webship gerektirildiğinde sonlandırmayı seçin:

1. Yönlendirme ana bilgisayar, yol veya yöntem ile.
2. İstekleri WAF veya API Shield ile denetleyin.
3. Gövde sınırlarını, HTTP zaman aşımlarını veya uç doğrulamasını uygulayın.
4. Yanıtları önbelleğe al veya HTTP başlıklarını yeniden yaz.
5. Aşağı akış ve yukarı akış HTTP protokolleri arasında çeviri yapın.
6. HTTP alanlarını vekil sunucu sınırında gözlemleyin.

Hangi modu seçerseniz seçin, SNI, ALPN, sertifika kimliği, istemci iptali, üst akış yarım kapatma ve tam yanıt bütünlüğünü test edin. İstek kapasitesini ve akış verimliliğini ayrı ayrı ölçün: küçük bir yanıt için en hızlı mod, mutlaka 100 MB'lık bir gövde için en hızlı mod olmayabilir.

Webship bir proxy'nin güven sınırını sessizce genişletmemesi gerektiğinden geçişi varsayılan yapar. HTTP farkında uç davranışı o sorumluluğa değdiğinde, sonlandırma canlı ve açık bir operasyonel tercih olarak kalır.

Tüm [reverse-proxy dokümantasyonunu](/docs/1.3.1) okuyun, kabul edilen [karşılaştırma matrisini](/benchmarks) inceleyin veya Webship dosyasını [İndirilenler](/downloads) bölümünden indirin.

Kaynaklar ve içerik yöntemi

Performans değerleri, 11 Eylül 2026 tarihli Webship 1.3.1 birleşik Debian kapasite kıyaslamasından kabul edilmiş medyanlardır; kabul kriterleri, sıfır istemci, HTTP, soket, protokol, proxy, büyük sayfa hatası ve HTTP/3 paket kaybı hatası gerektirir.