Çoğu yük dengeleme tasarımında bağlantı limiti tek bir alan gibi ele alınır: en fazla kaç bağlantı açılsın? Bu yaklaşım eksiktir. 10.000 bekleyen keep-alive bağlantı düşük maliyetli olabilirken, 1.000 eş zamanlı yeni SSL handshake kurum servisi CPU'sunu hızla tüketebilir. Aynı sayı, farklı trafik türlerinde tamamen farklı maliyet üretir.
Bağlantı sayısı ile bağlantı oranı da aynı şey değildir. "Aynı anda 20.000 bağlantı açık olabilir" kapasite sınırıdır; "saniyede 10.000 yeni bağlantı açılabilir" ise burst ve connection storm kontrolüdür. Bu iki değeri ayırmayan sistemler ya gerçek kullanıcı trafiğini gereksiz kısar ya da ani saldırı dalgasında kurum servisini koruyamaz.
TLS trafiği ayrı düşünülmelidir. SSL/TLS handshake işlemleri CPU açısından pahalıdır ve plain HTTP bağlantılarıyla aynı limit altında yönetildiğinde gerçek yük görünmez. Özellikle public web, API geçidi ve kampanya dönemlerinde handshake oranını ayrıca sınırlamak kurum servisi tarafındaki CPU tüketimini kontrol altında tutar.
Kuyruk davranışı da çoğu zaman belirsizdir. Limit aşıldığında bağlantı sessizce düşüyor mu, timeout mu üretiyor, kuyrukta mı bekliyor, yoksa net şekilde 503 mü dönüyor? Bu davranış görünür değilse olay anında root cause anlaşılmaz; kullanıcı timeout görür, operasyon ekibi gerçek sebebi geç fark eder.
TR7'nin havuz bağlantı limitleri, toplam bağlantı, bağlantı oranı, oturum oranı, SSL yükü, buffer bütçesi ve yeniden deneme davranışını ayrı ayrı kontrol ederek kurum servislerini sessiz overload yerine öngörülebilir kapasite yönetimiyle korur.
TR7, havuz kapasitesini tek alanla değil; bağlantı, oran, SSL, retry ve buffer eksenlerinden oluşan profil yapısıyla yönetir.
Tek profil içinde maxConn, maxRetries, rateLimitSessions, maxConnRate, maxSessRate, maxSslConn, maxSslRate ve maxBufferSize tanımlanır. Böylece kurum servisinin bağlantı, hız, TLS ve bellek sınırları ayrı ayrı ayarlanır.
TLS handshake CPU açısından pahalı olduğu için TR7, maxSslConn ve maxSslRate değerlerini ayrı yönetir. Bu ayrım, bağlantı sayısı düşük görünse bile handshake fırtınasının kurum servisini yormasını engellemeye yardımcı olur.
Limit profili benzersiz adla tanımlanır ve farklı servis havuzlarına bağlanabilir. Üretim, staging, canary veya tenant bazlı kapasite politikaları tek profil düzeniyle yönetilebilir.
maxRetries, geçici bağlantı hatalarında yeniden deneme sayısını tanımlar. maxBufferSize ise yavaş istemci veya yavaş kurum servisi durumlarında bağlantı başına bellek kullanımını kontrol eder.
TR7 Havuz Bağlantı Limitleri, kurum servislerini bağlantı fırtınası, TLS yükü, oturum patlaması ve bellek tüketimine karşı kontrollü şekilde sınırlar.
maxConn, havuz başına anlık açık bağlantı tavanını belirler ve varsayılan değeri 20.000'dir. Üst sınır 1.000.000 bağlantıya kadar ayarlanabilir. Bu değer, kurum servisinin aynı anda taşıyabileceği bağlantı kapasitesini ADC seviyesinde kodlar. Limit aşıldığında yeni bağlantılar kuyruk davranışına veya reddetme akışına tabi olur.
maxConnRate, saniyede açılabilecek yeni TCP bağlantı sayısını sınırlar ve varsayılan değeri 10.000'dir. Bu alan toplam bağlantıdan farklı olarak bağlantı açılma hızını kontrol eder. Connection storm, agresif tarama veya hatalı load test davranışlarında kurum servisinin bir anda boğulmasını engellemeye yardımcı olur. Public servislerde burst koruması için kritik bir kontroldür.
maxSessRate, saniyedeki yeni oturum oranı için kullanılır ve varsayılan değeri 10.000'dir. Keep-alive bağlantıların yeniden kullanımı ile sürekli yeni oturum açma davranışı aynı maliyeti üretmez. Bu ayrım, özellikle cookie bazlı oturum açma fırtınaları veya uygulama oturumu tüketen bot davranışlarında faydalıdır. Trafik yalnızca bağlantı değil, oturum üretim hızı açısından da sınırlandırılır.
rateLimitSessions, yeni connection slot tahsisi için ayrı bir per-second kontrol alanı sağlar ve varsayılan değeri 5.000'dir. Bu değer, yeni bağlantı kabul davranışını daha granüler yönetmek için kullanılır. Ani bağlantı patlamalarında havuzun kontrollü kapasiteyle ilerlemesine yardımcı olur. Kurum servisi kapasitesi ile ADC kabul hızı arasındaki ilişki daha net ayarlanır.
maxSslConn, aktif SSL/TLS bağlantıları için ayrı eş zamanlı bağlantı sınırı tanımlar ve varsayılan değeri 5.000'dir. TLS bağlantıları CPU, bellek ve kriptografik işlem maliyeti nedeniyle plain bağlantılardan farklı ele alınmalıdır. Bu limit, kurum servisinin TLS tarafındaki gerçek kapasitesini daha doğru yansıtır. Özellikle public web ve API trafiğinde SSL kapasite planlamasını sadeleştirir.
maxSslRate, saniyede başlatılabilecek SSL/TLS handshake sayısını sınırlar ve varsayılan değeri 2.000'dir. Handshake işlemleri RSA veya ECDSA kullanımına, anahtar boyutuna ve CPU kapasitesine göre yüksek maliyet üretebilir. Bu alan, TLS handshake fırtınalarının kurum servisi CPU'sunu tüketmesini engellemeye yardımcı olur. DDoS veya agresif bot trafiğinde plain bağlantı limitinden daha anlamlı bir koruma sağlar.
maxBufferSize, bağlantı başına kullanılabilecek buffer boyutunu kB cinsinden belirler ve varsayılan değeri 128 kB'dir. 16–256 kB aralığında ayarlanabilir. Yavaş istemci, yavaş okuyucu veya büyük gövde taşıyan isteklerde bellek tüketimi bu değerle kontrol edilir. Bu alan, Slowloris benzeri davranışlara ve bellek baskısına karşı operasyonel koruma sağlar.
maxRetries, kurum servisine bağlantı kurulamadığında kaç kez yeniden deneme yapılacağını belirler ve varsayılan değeri 3'tür. Üst sınır 1.000'e kadar ayarlanabilir. Düşük değer hızlı hata dönüşü sağlar, yüksek değer geçici ağ dalgalanmalarında dayanıklılığı artırabilir. Ancak fazla retry, sorunlu kurum servisine ek yük bindirebileceği için dikkatli seçilmelidir.
Limit profili benzersiz adla tanımlanır ve birden fazla havuza atanabilir. Aynı profilin düzenlenmesi, bağlı tüm havuzların bağlantı davranışını değiştirir. Bu model, çok sayıda servis havuzunda tek tek ayar yapma ihtiyacını azaltır. Üretim, test, kampanya veya tenant profilleri ayrı ayrı yönetilebilir.
Limit aşıldığında bağlantılar belirli kuyruk derinliğinde bekleyebilir. Kuyruk dolarsa istemci net hata alır; bu davranış sessiz timeout veya kontrolsüz drop'a göre daha izlenebilir bir sonuç üretir. Operasyon ekibi, 503 benzeri açık hata sinyalleriyle kapasite sınırına ulaşıldığını daha hızlı görebilir. Böylece sorun kullanıcı deneyiminde belirsiz bekleme yerine ölçülebilir kapasite olayına dönüşür.
Havuz bağlantı limitleri, varsayılan değerler, devre dışı bırakma davranışı, global/frontend/havuz üretimi ve bellek bütçesiyle birlikte planlanmalıdır.
Varsayılan modelde maxConn 20K, maxRetries 3, rateLimitSessions 5K, maxConnRate 10K, maxSessRate 10K, maxSslConn 5K, maxSslRate 2K ve maxBufferSize 128 kB olarak ele alınır. Bu değerler başlangıç noktasıdır. Gerçek ayar kurum servisi kapasitesine, TLS maliyetine ve trafik desenine göre yapılmalıdır.
Limit alanlarında minimum değer 0 olarak kabul edilir. Bu, ilgili kontrolün devre dışı bırakılması veya sınırsız gibi davranması gereken senaryolarda kullanılabilir. Ancak üretim ortamında 0 değeri bilinçli seçilmelidir; aksi hâlde beklenen koruma ortadan kalkabilir.
maxConn değeri 1.000.000'a kadar ayarlanabilir. Bu, çok yüksek yoğunluklu keep-alive veya bağlantı havuzu senaryolarında esneklik sağlar. Yine de gerçek kapasite yalnızca bu sayıdan ibaret değildir; dosya tanıtıcıları, bellek, CPU, TLS maliyeti ve kurum servisi sınırları birlikte hesaplanmalıdır.
maxBufferSize bağlantı başına bellek tüketimini doğrudan etkiler. Düşük değer bellek korumasını artırırken, büyük gövdeli veya yavaş akışlı uygulamalarda uyumluluk sorunu yaratabilir. 16–256 kB aralığı, güvenlik ve uygulama ihtiyacı arasında kontrollü seçim yapılmasını sağlar.
Profil değerleri global, frontend ve havuz seviyesindeki bağlantı davranışlarına yansıtılabilir. Bu ayrım, aynı cihazdaki genel kapasite ile belirli havuzun kapasitesinin ayrı yönetilmesini sağlar. Özellikle büyük kurulumlarda toplam ADC kapasitesi ve tek havuz kapasitesi karıştırılmamalıdır.
SSL bağlantı sınırları TLS bind davranışıyla ilişkilendirilir. maxSslConn gibi değerler TLS bağlantılarının plain bağlantılardan ayrı yönetilmesini sağlar. Bu, TLS trafiği yoğun olan public servislerde CPU bütçesini korumak için önemlidir.
E-ticaret platformu normal günlerde 20K bağlantı profili kullanırken kampanya döneminde daha yüksek bağlantı profiline geçebilir. Aynı havuz korunur, yalnızca limit profili değiştirilerek kampanya trafiğine hazırlanılır.
Banka, internal API havuzunda yüksek toplam bağlantıya izin verirken SSL bağlantı ve handshake oranını daha dar tutabilir. Bu yapı, TLS maliyetini kontrol ederek kurum servisi CPU'sunu ani handshake yükünden korur.
İnternete açık bir web uygulamasında bot taraması veya hatalı istemciler kısa sürede çok sayıda bağlantı açabilir. TR7, maxConnRate ve rateLimitSessions ile yeni bağlantı hızını sınırlayarak kurum servisini bağlantı fırtınasından korur.
Yavaş okuyan istemciler bağlantı başına buffer kullanımını artırabilir. TR7, daha düşük maxBufferSize profiliyle bu trafiğin bellek tüketimini sınırlar ve diğer kullanıcıların servis almaya devam etmesini sağlar.
Bağlantı fırtınası, TLS yükü ve yavaş istemci bellek baskısı için 8 eksenli bağlantı limit profilleri. Kendi servisleriniz üzerinde canlı bir kurulum için hazırız.