Timeout yanlış ayarlandığında hata her zaman açıkça görünmez. Bir API'nin serverTimeout değeri 30 saniyeye sabitlenmişse long-polling istekleri 504 ile dönebilir. Connect timeout çok uzunsa, düşmüş bir kurum servisine bağlanmaya çalışan istemciler saniyelerce bekler ve retry kaskadı başlar. Tunnel timeout kısa tutulursa WebSocket bağlantıları sebepsiz kopar ve kullanıcı "hayalet disconnect" yaşar.
Birçok sistem timeout ayarlarını düz bir liste olarak sunar. Operatör hangi değerin HTTP request başlangıcını, hangisinin kurum servisi yanıtını, hangisinin WebSocket tunnel bağlantısını, hangisinin FIN bekleme süresini etkilediğini net göremez. Sonuçta ya tüm değerler gereğinden büyük yapılır ve bağlantı sızıntısı oluşur ya da tüm değerler küçük tutulur ve gerçek kullanıcı trafiği kesilir.
WebSocket ve long-lived bağlantılar bu problemin en net görüldüğü alanlardır. HTTP keepalive 30-120 saniye aralığında anlamlı olabilir; fakat bir WebSocket bağlantısı saatlerce açık kalabilir. Tunnel timeout ayrı yönetilmezse gerçek zamanlı uygulamalar klasik HTTP timeout davranışına sıkışır.
TCP kapanış davranışı da önemlidir. clientFIN ve serverFIN değerleri kontrol edilmezse yarı-kapalı bağlantılar file descriptor havuzunu tüketebilir. Public-facing servislerde bu durum slowloris benzeri yavaş kapanış pattern'leriyle birleştiğinde kaynak tüketimi problemine dönüşür.
TR7 Zaman Aşımı Profilleri, 9 bağımsız timeout eksenini tek named profile içinde toplar; her havuzun trafik tipine göre doğru bekleme, drain ve bağlantı kapanış davranışı uygulanmasını sağlar.
TR7, timeout yönetimini havuzlara tek tek dağılmış ayarlar yerine, tekrar kullanılabilir named profile modeliyle yönetir.
Operatör bir profile adı tanımlar ve 9 timeout değerini bu profil içinde toplar. Aynı profile birden fazla havuza bağlanabilir; böylece web, API veya WebSocket havuzları ortak timeout standardı kullanır.
HTTP request, keepalive, connect, server, client, queue, tunnel, clientFIN ve serverFIN ayrı alanlar olarak yönetilir. Her alan kendi trafik semantiğine göre ayarlanır; bir timeout değeri diğerinin yerine kullanılmaz.
WebSocket ve HTTP CONNECT gibi uzun yaşayan bağlantılar tunnelTimeout ile ayrı yönetilir. Böylece chat, canlı yayın veya stream benzeri bağlantılar klasik HTTP idle süresine takılıp gereksiz kapanmaz.
TCP kapanış sinyali sonrası bağlantının ne kadar tutulacağı ayrı ayrı ayarlanır. Bu, FIN-WAIT benzeri kaynak tüketimi riskini azaltır ve public-facing servislerde daha agresif drain politikası kurulmasını sağlar.
Zaman Aşımı Profilleri, her trafik tipine uygun bağlantı ömrünü ve bekleme davranışını 9 ayrı alan üzerinden hassas biçimde yönetir.
httpKeepaliveTimeout, HTTP/1.1 keep-alive bağlantısının istekler arasında ne kadar süre açık tutulacağını belirler. Varsayılan değer 120 saniyedir. Değer çok yüksek olursa gereksiz idle bağlantılar kaynak tüketebilir; çok düşük olursa bağlantı yeniden kurma maliyeti artabilir. Kurum servisinin idle connection bütçesine göre ayarlanarak denge sağlanır.
httpRequestTimeout, istemcinin request line ve header bilgilerini tamamlaması için tanınan süredir. Varsayılan değer 30 saniyedir. Header'ı çok yavaş gönderen istemciler bu sınırla kesilebilir. Public-facing servislerde slowloris benzeri davranışlara karşı önemli bir savunma noktasıdır.
connectTimeout, TR7'den kurum servisine TCP bağlantı kurulması için beklenecek süreyi belirler. Varsayılan değer 20 saniyedir. Değer çok uzun olursa düşmüş veya erişilemeyen kurum servisi istemciyi gereksiz bekletir. Hızlı hata dönmesi gereken API senaryolarında daha düşük connectTimeout tercih edilebilir.
serverTimeout, kurum servisinin yanıt üretmesi için tanınan süredir. Varsayılan değer 90 saniyedir. Hızlı API'lerde düşük tutulabilir; ağır rapor, long-polling veya yavaş sorgu yapan endpoint'lerde artırılabilir. Yanlış düşük değer, çalışan ama uzun süren isteklerin 504 almasına neden olabilir.
clientTimeout, istemciden veri gelmesini bekleme süresidir. Request body upload, pipelined request veya yavaş istemci senaryolarında etkilidir. Varsayılan değer 90 saniyedir. Büyük dosya upload trafiğinde artırılabilir; public API'de slow client riskini azaltmak için daha düşük tutulabilir.
queueTimeout, kurum servisi havuzunda bağlantı kapasitesi doluyken isteğin kuyrukta ne kadar bekleyeceğini belirler. Varsayılan değer 60 saniyedir. Aşıldığında istek hata ile döndürülür ve istemci sonsuz bekletilmez. Bu değer maxconn sınırları ve uygulama SLA'iyle birlikte düşünülmelidir.
tunnelTimeout, WebSocket ve HTTP CONNECT benzeri tunnel bağlantıları için idle süreyi belirler. Varsayılan değer 120 saniyedir; gerçek zamanlı uygulamalarda bu değer 3600 saniye veya daha yüksek seçilebilir. Bu timeout HTTP keepalive'dan bağımsız olduğu için uzun yaşayan bağlantılar web trafiği ayarlarına sıkışmaz. Chat, canlı bildirim ve stream uygulamaları için kritik alandır.
clientFIN, istemciden FIN sinyali geldikten sonra bağlantının ne kadar süre tutulacağını kontrol eder. Varsayılan değer 3 saniyedir. Düşük değerler yarı-kapalı bağlantıların kaynak tüketmesini engeller. Public-facing servislerde FIN-WAIT kaynak baskısını azaltmak için özellikle önemlidir.
serverFIN, kurum servisinden FIN sinyali geldikten sonra bağlantı davranışını sınırlar. Varsayılan değer 6 saniyedir. serverFIN'in clientFIN'den daha yüksek tutulması, kurum servisi kapanırken daha toleranslı drain davranışı sağlar. Bu ayar özellikle yoğun kurum servisi havuzlarında bağlantı kapanış kalitesini etkiler.
Profil-pool binding modeliyle aynı timeout standardı birden fazla havuzda kullanılabilir. Örneğin tüm web havuzları web profiline, API havuzları api profiline, WebSocket havuzları websocket profiline bağlanabilir. Bir profil değişikliği, ona bağlı havuzların timeout davranışını merkezi biçimde günceller. Bu, konfigürasyon tekrarını ve drift riskini azaltır.
Profildeki 9 alan runtime yapılandırmaya karşılık gelen timeout direktiflerine dönüştürülür. connect, server, client, queue, tunnel, http-keep-alive, http-request, client-fin ve server-fin davranışları bu dönüşümle uygulanır. Operatör altta yatan direktifleri tek tek yazmaz; profil değerleri üzerinden yönetir. Bu yaklaşım GUI ve runtime davranışı arasında tutarlı köprü kurar.
Sağlık kontrolü kendi timeout alanıyla yönetilir ve trafik timeout profilinden bağımsızdır. Bu ayrım önemlidir; probe gecikmesi ile üretim trafiği bekleme davranışı birbirine karışmaz. Kurum servisi health check'i kısa tutulurken, gerçek endpoint serverTimeout değeri daha uzun olabilir. Böylece servis sağlığı ve kullanıcı trafiği farklı semantiklerle izlenir.
Timeout profilleri; değer aralığı, varsayılanlar, ondalık destek, tunnel davranışı, FIN dengesi ve havuz binding modeliyle birlikte işletilir.
Timeout alanları 0 ile 60.000 saniye aralığında yapılandırılabilir. Bu aralık milisaniye seviyesine yakın kısa savunma ayarlarından 16 saati aşan uzun bağlantı senaryolarına kadar geniş kullanım sağlar. Long-poll ve persistent connection ihtiyaçları için yeterli esneklik sunar.
httpKeepaliveTimeout ondalık değer kabul edebilir. Örneğin 0.5 saniye gibi daha hassas idle keepalive davranışı tanımlanabilir. Diğer 8 timeout alanı saniye cinsinden tamsayı olarak ele alınır.
Varsayılan değerler çoğu web ve API trafiğine uygun güvenli başlangıç noktası sağlar. httpKeepaliveTimeout 120, httpRequestTimeout 30, connectTimeout 20, serverTimeout 90, clientTimeout 90, queueTimeout 60, tunnelTimeout 120, clientFIN 3 ve serverFIN 6 saniye olarak düşünülebilir. Özel trafik tiplerinde bu değerler profile bazında değiştirilmelidir.
tunnelTimeout, WebSocket ve HTTP CONNECT gibi tünellenmiş bağlantılar için kullanılır. Bu değer klasik HTTP request veya keepalive timeout ile aynı değildir. Uzun yaşayan bağlantılarda yanlış düşük ayar kopma problemi üretir.
Varsayılan modelde serverFIN değeri clientFIN'den daha toleranslıdır. Bu, kurum servisi kapanışında graceful drain için daha fazla alan bırakır. Public-facing servislerde iki değer daha agresif düşürülerek yarı-kapalı bağlantıların kaynak tüketimi azaltılabilir.
TR7 hazır preset dayatmaz; operatör kendi senaryosuna göre named profile oluşturur. web, api, websocket, longpoll veya upload gibi isimler kurum standardına göre tanımlanabilir. Servis bazında tek tek override yerine havuzun uygun profile bağlanması tercih edilir.
Web trafiği için varsayılan değerlere yakın bir web profili oluşturulabilir. Keepalive kullanıcı deneyimini korurken, request ve FIN timeout değerleri yavaş veya yarı-kapalı bağlantıları sınırlar. Aynı profil birden fazla web havuzuna bağlanabilir.
Chat uygulaması WebSocket bağlantılarının sık kopmamasını ister. websocket profili içinde tunnelTimeout 3600 saniye gibi uzun bir değere çekilir, diğer HTTP timeout'ları varsayılanda kalabilir. Böylece uzun yaşayan bağlantı HTTP keepalive süresine takılmaz.
Long-polling endpoint'i kurum servisinden yanıt gelene kadar birkaç dakika bekleyebilir. longpoll profilinde serverTimeout 300 saniye olarak ayarlanarak 5 dakikalık bekleme desteklenir. Aksi halde normal API timeout'u istekleri erken kesebilir.
Büyük POST body veya dosya upload trafiğinde istemciden veri gelmesi uzun sürebilir. upload profilinde clientTimeout ve gerekirse httpRequestTimeout 600 saniyeye çıkarılabilir. Bu, yavaş ama meşru upload işlemlerinin kesilmesini önler.
Bankacılık API'si kurum servisi yanıtını hızlı bekliyorsa connectTimeout 2 saniye, serverTimeout 5 saniye gibi sıkı değerler kullanılabilir. Yavaş veya düşmüş servis istemciyi uzun süre bekletmez. Retry ve failover davranışı daha erken tetiklenir.
Defensive profilde httpRequestTimeout 5 saniye, clientFIN ve serverFIN 1 saniye gibi düşük değerler kullanılabilir. Bu yapı yavaş header gönderimi ve yarı-kapalı bağlantı tüketimi gibi pattern'leri sınırlar. Public-facing servislerde saldırı yüzeyini daraltır.
Web, API, WebSocket ve upload havuzlarınız için 9 eksenli named timeout profilleri. Kendi konfigürasyonunuzla canlı bir kurulumda gezdirelim.