HTTP TCP Multiplexing

HTTP TCP Multiplexing Aksiyonu Nedir?

HTTP TCP Multiplexing aksiyonu, TR7 üzerinde HTTP tabanlı vService'lerde TR7 ile Kurum Servisleri arasındaki bağlantıların oturumlar arasında nasıl paylaşılacağını belirlemek için kullanılır. Bu aksiyon yalnızca response aşamasında devreye alınır ve Kurum Servisi bağlantılarının yeniden kullanım politikasını yönetir.

Doğru yapılandırıldığında, Kurum Servisi bağlantılarının verimli kullanılması sayesinde bağlantı kurulum maliyetleri azalır, kaynak tüketimi optimize edilir ve özellikle yüksek trafik altında daha stabil bir servis davranışı elde edilir. Yanlış yapılandırıldığında ise Kurum Servislerinin bağlantı/oturum beklentileri ile çelişerek beklenmeyen davranışlara yol açabilir.

Az paylaşım · izolasyonÇok paylaşım · performans

Never

Safe

Aggressive

Always

Bu aksiyon, TR7'nin Kurum Servisleri tarafında bağlantı yönetimi ve performans optimizasyonu ihtiyaçları için kullanılan temel aksiyonlardan biridir.

HTTP TCP Multiplexing Aksiyonunun Önemi

Canlı ortamlarda Kurum Servisleri; bağlantı sayısı, bağlantı ömrü ve bağlantı yeniden kullanım davranışına göre farklı tepkiler verebilir. Özellikle yüksek trafik alan servislerde, her istek için yeni bağlantı açılması hem gecikmeyi artırabilir hem de Kurum Servisi tarafında bağlantı limiti nedeniyle kapasite sorunlarına yol açabilir.

HTTP TCP Multiplexing aksiyonu;

• Kurum Servisi bağlantılarının daha verimli kullanılmasını sağlar,
• Bağlantı kurulum maliyetlerini azaltarak performansı artırır,
• Kurum Servisi tarafında bağlantı sayısını kontrol altında tutmaya yardımcı olur,
• Yük altında daha öngörülebilir bir bağlantı davranışı sağlar,
• Uygulamanın bağlantı yeniden kullanımına uygunluğuna göre esnek stratejiler sunar.

Bu nedenle HTTP TCP Multiplexing aksiyonu, TR7 üzerinde performans ve kapasite yönetimi açısından kritik bir optimizasyon aracıdır.

Kullanılabildiği vService Tipleri

HTTP

L7 TCP

Network

Çalışma Anı

İstek Anı (On Request)

Cevap Anı (On Response)

Nasıl Eklenir?

Yeni bir HTTP TCP Multiplexing Aksiyonu, TR7 web yönetim arayüzü üzerinden aşağıdaki adımlar izlenerek eklenebilir:

1. Sol altta bulunan TR7 logosuna tıklanarak Configuration Menu açılır.
2. Load Balancer → Actions → Add adımları takip edilir.
3. Aksiyon için benzersiz ve açıklayıcı bir isim girilir.
4. Action Type olarak HTTP TCP Multiplexing seçilir.
5. Aksiyona ait ilgili konfigürasyonlar yapılandırılır.
6. Add butonuna tıklanarak aksiyon eklenir.

HTTP TCP Multiplexing Aksiyonu Ekleme Formu

HTTP TCP Multiplexing Aksiyonu Ekleme Formu

INFO

Action Name

Oluşturulacak olan aksiyona benzersiz ve açıklayıcı bir isim girilir.

INFO

Action Type

Aksiyon tipi olarak HTTP TCP Multiplexing seçilir.

INFO

Connection Mode Varsayılan: Keep the connection open

TR7 ile Kurum Servisi arasındaki bağlantının istek tamamlandıktan sonra açık kalıp kalmayacağını belirler.

• Keep the connection open (default): Bağlantılar istek sonrası açık tutulur ve sonraki isteklerde yeniden kullanılabilir. Bağlantı paylaşımı yalnızca bu modda anlamlıdır.
• Close the backend service connection (not recommended): İstemci tarafındaki bağlantı açık kalır, Kurum Servisi bağlantısı her yanıttan sonra kapatılır.
• Close after every request (not recommended): Her istekten sonra iki taraftaki bağlantı da kapatılır.

Kapatan modların maliyeti

Varsayılan yalnızca kalıcı bağlantıyla düzgün çalışmayan Kurum Servisleri için değiştirilmelidir. Kapatan modlarda her istek yeni bir bağlantı (HTTPS ise yeni bir TLS anlaşması) anlamına gelir; limit profilindeki saniyelik bağlantı ve SSL sınırları baskı altına girer. Close after every request seçildiğinde zaman aşımı profilindeki HTTP KeepAlive değeri de işlevsiz kalır.

INFO

Connection Share Strategy

Bu alan, TR7'nin Kurum Servisleri ile kurduğu TCP bağlantılarını oturumlar arasında hangi seviyede paylaşabileceğinin belirlendiği alandır.

Seçilen strateji; bağlantı sayısı, gecikme süresi, kaynak kullanımı ve Kurum Servisi uyumluluğu üzerinde doğrudan etkilidir.

Alan yalnızca Connection Mode olarak Keep the connection open seçiliyken görünür; kapatan modlarda bağlantı havuzu oluşmadığından alan formdan kalkar ve daha önce seçilmiş bir strateji varsa yok sayılır.

Alanın önceden seçili bir değeri yoktur; boş bırakılırsa yapılandırmaya strateji satırı yazılmaz ve Safe davranışı geçerli olur.

• Never: Kurum Servisi tarafında açılmış boştaki TCP bağlantılar hiçbir zaman oturumlar arasında paylaşılmaz. Her istemci oturumu, kendi bağlantısı üzerinden iletişim kurar. Bağlantı izolasyonunun kritik olduğu, eski veya bağlantı yeniden kullanımını desteklemeyen Kurum Servisleri için tercih edilir.
• Safe: Bir oturumun ilk isteği her zaman kendisine ait yeni bir bağlantı üzerinden Kurum Servisine iletilir. Aynı oturumun sonraki istekleri, uygun olması halinde mevcut bağlantılar üzerinden gönderilebilir. Güvenli varsayılan davranış sunar ve çoğu standart web uygulaması için önerilen stratejidir.
• Aggressive: İlk istekler, yalnızca daha önce en az bir kez başarıyla yeniden kullanılmış Kurum Servisi bağlantıları üzerinden iletilir. Bu yaklaşım, Kurum Servislerinin bağlantı paylaşımını sorunsuz desteklediğinin bilindiği ortamlarda daha yüksek verimlilik sağlar. Yanlış yapılandırılmış Kurum Servislerinde dikkatli kullanılmalıdır.
• Always: Bir oturumun ilk isteğinin dahi mevcut bir Kurum Servisi bağlantısı üzerinden iletilmesine izin verir. En yüksek seviyede bağlantı paylaşımı ve en düşük bağlantı açma maliyetini sağlar. Yüksek trafikli, modern ve bağlantı yeniden kullanımına tam uyumlu Kurum Servisleri için uygundur.

Bağlantıya bağlı kimlik doğrulamada paylaşım yapılmamalı

NTLM ve Kerberos (SPNEGO) kimlik doğrulaması TCP bağlantısının kendisine bağlıdır: kimlik doğrulanmış bir bağlantı başka bir istemcinin isteğine verilirse yetki sızıntısı veya sürekli 401 döngüsü oluşur. TR7 bu durumu tespit edip engellemez.

Bu kimlik doğrulama yöntemlerini kullanan Kurum Servislerinde (Exchange, SharePoint, IIS tabanlı kurum içi uygulamalar) Never veya Safe kullanılmalıdır; Always kullanılmamalı, Aggressive ise risklidir.

Aynı vService'e yalnızca bir HTTP TCP Multiplexing aksiyonu eklenebilir; ikinci aksiyon eklenmek istendiğinde kullanım aşım limiti uyarısı verilir.

INFO

Form Butonları

Add

Add butonuna tıklanarak aksiyon ekleme işlemi tamamlanır.

Add & Repeat

Add & Repeat butonu ile aksiyon ekleme işlemi tamamlanır ve farklı konfigürasyonlarla ilgili pencereden çıkılmadan yeni bir aksiyon daha eklenebilir.

Aksiyon Eklendi

WARNING

HTTP TCP Multiplexing aksiyonu koşul gerektirmez ve tanımlandığı vService üzerinde koşulsuz olarak uygulanır.

Bu bir tercih değil, teknik bir zorunluluktur: bağlantı modu ve paylaşım stratejisi tek tek isteklere değil, vService'in tüm Kurum Servisi bağlantılarına uygulanan yapılandırma ayarlarıdır. Aynı nedenle formda Hit Counter ve Set Variable on Hit alanları da bulunmaz.

Koşulsuz çalışan aksiyonlar, trafik içeriğine bağlı değerlendirme yapmadan, ilgili vService üzerindeki tüm trafiği veya davranışı doğrudan etkiler.

Canlı ortamlarda, bu tür aksiyonların devreye alınması öncesinde hedef servis davranışlarının ve olası etkilerin dikkatle değerlendirilmesi önerilir. Aksi durumda, beklenmeyen servis davranışları veya operasyonel sorunlar oluşabilir.

Operasyonel ve Güvenli Kullanım Önerileri

HTTP TCP Multiplexing aksiyonu, TR7 üzerinde performansı artırabilir; ancak Kurum Servislerinin bağlantı davranışına uygun seçilmelidir.

• Önce Bağlantı Moduna Karar Verin. Paylaşım stratejisi yalnızca bağlantılar açık tutulduğunda anlamlıdır; kapatan modlar seçilirse strateji alanı zaten kalkar.
• Safe ile Başlayın. Kurum Servisi davranışı net değilse Safe seçilmeli, agresif stratejilere ölçüm yapıldıktan sonra geçilmelidir.
• Kimlik Doğrulama Yöntemini Doğrulayın. Kurum Servisi NTLM/Kerberos kullanıyorsa paylaşım Never veya Safe ile sınırlanmalıdır.
• Kurum Servisi bağlantı davranışı doğrulanır. Kurum Servisinin keep-alive, bağlantı havuzu ve bağlantı yeniden kullanımını doğru desteklediği doğrulanır; aksi hâlde beklenmeyen oturum davranışları görülebilir.
• Yük Altında Gözlem Yapın. Strateji değişikliği sonrası bağlantı sayısı, gecikme ve hata oranları izlenmeli; iyileşme veya olumsuz etki ölçülmelidir.
• Kritik Uygulamalarda Kademeli Geçiş Yapın. Daha agresif stratejilere geçiş, canlı ortamda kademeli olarak uygulanmalı ve servis davranışı doğrulanmalıdır.
• Uygulama Tipine Göre Seçim Yapın. Oturum bağımlılığı yüksek veya bağlantı yönetimi hassas uygulamalarda daha kontrollü stratejiler tercih edilmelidir.

Canlı Ortamlarda Yaygın Kullanım Senaryoları

Aşağıdaki örnekler, ilgili aksiyonun gerçek sistemlerde en sık karşılaşılan kullanım senaryolarında nasıl uygulandığını göstermektedir. Bu senaryolar, canlı ortamlarda yaygın olarak tercih edilen ve sahada edinilmiş deneyimlere dayanan pratikleri temel alır.

Senaryo 1: Yüksek Trafikli E-Ticaret Sitesi Performans Optimizasyonu

Problem: E-ticaret sitesi yüksek trafik altında (1000+ eşzamanlı kullanıcı) Kurum Servisine çok sayıda TCP bağlantısı açıyor (her kullanıcı için 2-3 bağlantı). Kurum Servisi bağlantı limiti dolarak yeni istekler reddediliyor ve site yavaşlıyor.

Çözüm: Always stratejisiyle TCP bağlantıları en üst düzeyde yeniden kullanılarak Kurum Servisi bağlantı sayısı belirgin biçimde azaltılır.

Konfigürasyon: Connection mode → Keep the connection open · Connection share strategy → Always

Sonuç:

• ✅ Bağlantı sayısı → Eşzamanlı kullanıcı sayısından bağımsız olarak, havuzdaki bağlantı sayısı belirgin şekilde azalır.
• ✅ Bağlantı kurulum gecikmesi → Minimize edilir, sayfa yüklenme hızı artar.
• ✅ Kurum Servisi → Bağlantı limiti sorunları ortadan kalkar.
• ✅ Performans → Bağlantı açma maliyeti ortadan kalktığı için işlem hızı artar.
• ⚠️ Ön koşul → Kurum Servisinin bağlantıya bağlı kimlik doğrulama kullanmadığı doğrulanmalıdır.

Senaryo 2: Session Tabanlı WordPress/Drupal Uygulaması

Problem: Kurum Servisinin bağlantı paylaşımını sorunsuz desteklediği doğrulanmamış; agresif paylaşımın yol açabileceği bağlantı hatalarından kaçınılmak isteniyor, ancak performans kazancından da tamamen vazgeçilmek istenmiyor.

Çözüm: Safe stratejisi ile her oturumun ilk isteği yeni bir bağlantıdan gönderilir, sonraki istekler mevcut bağlantılardan yeniden kullanılır.

Konfigürasyon: Connection mode → Keep the connection open · Connection share strategy → Safe

Sonuç:

• ✅ İlk istek → Kendine ait yeni bağlantıdan gönderilir, yeniden kullanım kaynaklı sürprizler yaşanmaz.
• ✅ Performans kazancı → Sonraki istekler mevcut bağlantıları kullanır, bağlantı kurulum gecikmesi azalır.
• ✅ Denge → Uyumluluk ve performans arasında dengeli davranış sağlanır.
• ℹ️ Not → Strateji boş bırakıldığında da bu davranış geçerlidir.

Senaryo 3: Legacy Java EE Uygulaması Uyumluluk Sorunu

Problem: Kurum içi uygulama NTLM ile kimlik doğrulaması yapıyor. Kimlik doğrulaması TCP bağlantısına bağlı olduğundan, doğrulanmış bir bağlantı başka bir kullanıcının isteğine verildiğinde kullanıcılar sürekli kimlik penceresiyle karşılaşıyor veya başka bir kullanıcının yetkisiyle işlem görüyor.

Çözüm: Never stratejisi ile bağlantılar oturumlar arasında hiç paylaşılmaz; her oturum kendi kimlik doğrulanmış bağlantısını kullanır.

Konfigürasyon: Connection mode → Keep the connection open · Connection share strategy → Never

Sonuç:

• ✅ Kimlik doğrulama → Doğrulanmış bağlantı başka bir oturuma devredilmez.
• ✅ Yetki güvenliği → Kullanıcıların birbirinin oturumu üzerinden işlem görmesi engellenir.
• ✅ Uyumluluk → NTLM/Kerberos kullanan Kurum Servisleri sorunsuz çalışır.
• ❌ Performans → Bağlantı yeniden kullanımı olmadığından daha fazla bağlantı açılır.

Senaryo 4: REST API Gateway Optimizasyonu

Problem: REST API gateway yüksek trafik alıyor ve Kurum Servisinin bağlantı yeniden kullanımını desteklediği test edildi. Safe stratejisi kullanılıyor ama daha fazla performans kazancı isteniyor.

Çözüm: Aggressive stratejisiyle ilk istekler de önceden test edilmiş bağlantılar üzerinden gönderilerek performans artırılır.

Konfigürasyon: Connection mode → Keep the connection open · Connection share strategy → Aggressive

Sonuç:

• ✅ Performans → Safe stratejisinden daha yüksek performans kazancı elde edilir.
• ✅ Bağlantı sayısı → Minimum seviyede tutulur, Kurum Servisi kaynakları korunur.
• ✅ İlk istek hızı → Test edilmiş bağlantılar kullanıldığı için gecikme azalır.
• ⚠️ Gereksinim → Kurum Servisinin bağlantı yeniden kullanımını desteklediği önceden doğrulanmalı.