Yanlış timeout ayarı production'da sessiz kesinti, hayalet kopma ve gereksiz bekleme üretir.
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.
Yaklaşımımız
TR7, timeout yönetimini havuzlara tek tek dağılmış ayarlar yerine, tekrar kullanılabilir named profile modeliyle yönetir.
Named profile oluşturulur ve havuzlara bağlanır
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, TCP, queue, tunnel ve FIN eksenleri ayrılı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 tunnel timeout HTTP keepalive'dan bağımsızdır
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.
clientFIN ve serverFIN yarı-kapalı bağlantıları sınırlar
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.
Yetenekler
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 idle HTTP bağlantısının açık kalma süresini belirler
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 yavaş header gönderimini sınırlayarak slowloris riskini azaltı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 kurum servisine TCP bağlantı bekleme süresini yönetir
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 servisinden response bekleme süresini belirler
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 bekleme davranışını kontrol eder
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 havuz doluyken istemcinin ne kadar bekleyeceğini sınırlar
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 tunnel bağlantılarını ayrı yönetir
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 istemci kapatma sinyali sonrası bekleme süresini belirler
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 servisi kapanışında graceful drain süresini yönetir
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.
Aynı timeout profili birden fazla havuza bağlanabilir
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.
Native generate akışı profil alanlarını runtime timeout direktiflerine çevirir
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.
Health check timeout profil dışı ayrı bir kontrol olarak kalır
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.
Operasyonel derinlik
Timeout profilleri; değer aralığı, varsayılanlar, ondalık destek, tunnel davranışı, FIN dengesi ve havuz binding modeliyle birlikte işletilir.
Değer aralığı
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.
Ondalık destek
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.
Production-safe defaultlar
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.
Tunnel semantiği
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.
FIN dengesi
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.
Preset yerine named profile
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.
Hangi senaryolarda kullanılır
Standart web uygulaması için dengeli timeout profili
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.
Real-time chat için uzun WebSocket tunnel süresi
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 API için serverTimeout yükseltme
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 dosya upload için clientTimeout genişletme
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.
Hızlı bankacılık API için agresif timeout profili
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.
Public web için slow attack savunma profili
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.
Sık sorulanlar
9 timeout alanının her biri ne işe yarar?
WebSocket bağlantıları neden ayrı bir timeout profiline ihtiyaç duyar?
clientFIN ve serverFIN değerleri güvenlik açısından neden önemlidir?
Aynı profil birden fazla havuza nasıl bağlanır?
serverTimeout ve queueTimeout arasındaki fark nedir?
Hazır timeout profil şablonları var mı?
Timeout yönetimini trafik tipine göre modelleyin
Web, API, WebSocket ve upload havuzlarınız için 9 eksenli named timeout profilleri. Kendi konfigürasyonunuzla canlı bir kurulumda gezdirelim.