Network Throttling Nedir? Hosting Sağlayıcılar Neden Uygular?

Network throttling, sunucu ile internet bağlantısı arasında belirli koşullarda bant genişliğinin (throughput) kasıtlı olarak düşürülmesidir. Bu uygulama çoğu kullanıcı için “site neden yavaşladı?” sorusunun cevabı olabilir. Aynı zamanda hosting sağlayıcıların kapasite planlaması, adil kullanım ve güvenilir hizmet hedefiyle ilişkili bir konudur. Bu rehberde throttling’in ne olduğunu, nasıl çalıştığını, neden devreye alındığını ve kullanıcı olarak bunu tespit edip azaltmak için net adımları öğreneceksiniz.

Network throttling ne demek? (Ağ bant genişliği kısıtlaması)

Network throttling; belirli bir trafik türü ya da belirli bir hesap/sunucu için ağ hızının otomatik veya manuel yöntemlerle kısılmasıdır. Amaç, tüm hizmeti tek bir kullanıcıdan gelen yükle “tamamen çöktürmeden” diğer kullanıcıların etkilenmesini sınırlamaktır.

Throttling çoğu zaman şu şekillerde görülür: - Bant genişliği (Mbps/Mbps) kısıtı: Örneğin belirli bir limit aşılırsa bağlantı hızı 100 Mbps yerine 10 Mbps’e düşer. - Paket/istek başına gecikme ekleme: Ağdan gelen paketlerin işlenme aralığı uzatılır; bu durum özellikle küçük isteklerde TTFB’yi artırabilir. - Süre tabanlı kısıt: Belirli saatlerde ya da belirli trafik pencerelerinde hız kısıtı uygulanır. - Kalite sınıfına göre önceliklendirme (QoS): Bazı trafik sınıfları (ör. bulk download) daha düşük öncelik alır.

Buradaki kritik nokta şudur: Network throttling, CPU/RAM’i kısan bir uygulama değildir; genellikle ağ katmanında (network layer) etki eder. Ancak dolaylı olarak web uygulamanızın yanıt süresi de etkilenebilir; çünkü uygulama veri gönderip aldıkça gecikme artar.

Throttling ile bandwidth shaping aynı şey mi?

Pratikte benzer kavramlar sık karışır: - Throttling: Genellikle “hızı kısma” anlamında kullanılır. - Traffic shaping / QoS: Trafiği sınıflandırıp kurallarla düzenleme anlamına gelir. Bir sağlayıcı “traffic shaping” dese bile uyguladığı kural sonuçta throttling gibi hissedilebilir. Bu nedenle değerlendirmeyi sağlayıcının açıkladığı politikaya ve ölçüme dayandırmak gerekir.

Hosting sağlayıcılar throttling’i neden uygular?

Network throttling’in arkasında tek bir sebep değil, birkaç operasyonel ihtiyaç vardır. En sık görülen senaryoları net şekilde ayıralım.

1) Adil kullanım (fair-use) ve aşırı tüketimi sınırlama

Paylaşımlı altyapıda bant genişliği tekil bir müşterinin yüküyle hızla tükenebilir. Sağlayıcılar “adil kullanım” hedefiyle limit aşımlarında etkili bir freni devreye alır.

Limit aşımı: Örneğin ay içinde yüksek outbound trafik
Bir anda pik: Gün içinde yoğun veri çekme/transfer
Beklenmedik trafik: Otomasyon, bot akışı, yanlış yapılandırılmış tarama

Bu kısıtlama, diğer müşterilerin bağlantısının da tamamen yavaşlamasını engeller.

2) Kapasite planlaması ve maliyet kontrolü

Ağ altyapısı maliyet odaklıdır: transit maliyetleri, uplink kapasitesi ve upstream sağlayıcı limitleri vardır. Throttling; “her şeyi sınırsız büyütme” yerine mevcut altyapıyı daha öngörülebilir kullanmayı sağlar.

Bu yüzden özellikle: - Bütçe dostu VPS/VDS paketleri - Öncelik/limit politikası olan paylaşımlı planlar - Yeni gelen kullanıcılar için ramp-up yapan servisler

throttling riski daha görünür olabilir.

3) Güvenlik: DDoS ve anomali trafiğini durdurma (veya etkisini azaltma)

Tam bir DDoS engelleme yerine, bazı sağlayıcılar önce “etkiyi azaltmak” için throttling benzeri geçici önlemler alır. Bu süreçte saldırı trafiği filtrelenirken kaynak tüketimi dengelenir.

Burada amaç saldırıyı “tamamen” durdurmak değil; ancak hizmetin çökmesini engellemektir.

4) Hizmet kalitesini (SLA benzeri beklenti) koruma

Özellikle managed dedicated / VDS gibi hizmetlerde sağlayıcılar, belirli performans beklentilerini korumak ister. Throttling; “tek bir aboneden kaynaklı tıkanma”yı yönetmenin pratik bir yoludur.

Network throttling nasıl anlaşılır? (Somut işaretler)

Throttling’i tahmin etmek yerine ölçmek gerekir. Aşağıdaki işaretler birlikte görülürse “ağ kısıtı” ihtimali artar.

Tipik belirtiler

Dosya indirmeleri veya büyük içerik gönderimleri beklenenden çok yavaşlar.
Günün belirli saatlerinde hız aniden düşer (trafik piki olabilir).
Aynı sunucuda CPU/RAM normal görünürken yanıt süreleri artar.
FTP/SFTP/rsync gibi transferlerde hız bariz düşer.
Önbellek dışından gelen isteklerde hız etkisi daha net görülür.

Ölçümle doğrulama: basit kontrol adımları

Aşağıdaki kontroller, “throttling mi var, yok mu?” sorusunu netleştirir.

1) Sunucu içinden hız testi (iletişim gecikmesi)

Sunucunuzdan harici bir endpoint’e hız testi yapın. Sonuçları sağlayıcı destek ekibinin isteyebileceği formatta saklayın.

Örnek (Linux): - iperf3 ile karşılaştırma yapın (varsa) - Basitçe curl ile büyük dosya indirme testinde indirilen hız ve süreyi kaydedin

2) Dışarıdan (client tarafı) test

Farklı lokasyonlardan deneme yapın. Eğer sorun sadece bir bölgeden görünüyorsa throttling değil, rota/peering veya CDN meselesi olabilir.

3) Sunucu metrikleriyle eşleştirin

Şu metrikleri aynı zaman aralığında kontrol edin: - CPU kullanımı (çok düşükken yavaşlama olması throttling’i düşündürür) - Network interface tx/rx (band genişliği doygunluğu) - Packet loss / retransmits (varsa) - Uygulama loglarında gecikme artışı

Throttling web performansını nasıl etkiler? (TTFB, indirme, API)

Network kısıtlaması farklı trafik tiplerinde farklı davranır.

TTFB neden artabilir?

TTFB (Time to First Byte) çoğu zaman uygulama gecikmesi gibi düşünülür; ancak ağ kısıtında istemcinin ilk yanıtı alma süresi de uzar. Özellikle: - İlk byte gönderimi bekler (socket buffer doluluğu) - Uzun yanıtlar paket paket gider - Reverse proxy / web server katmanı gecikmeyi kullanıcıya yansıtır

Büyük dosya gönderiminde etkisi daha görünür

Medya dosyaları (video, görsel)
Yedek (backup) dosyaları
Paket güncellemeleri
CDN yoksa doğrudan origin’den gelen içerik

Bunlarda bant genişliği kısıtı daha net anlaşılır.

API çağrıları ve küçük istekler

Küçük isteklerde de gecikme hissedilebilir; ancak genellikle asıl fark, istek sayısı arttığında (concurrency yükseldiğinde) görünür olur.

Hosting planınız throttling içeriyor mu? Net kontrol listesi

Throttling’i azaltmak için ilk adım “paketiniz ne diyor?” kısmıdır. Sağlayıcıların çoğu bunu açıkça yazar; bazen ise “fair use / acceptable use policy” veya “network policy” başlığı altında gizlidir.

Aşağıdaki maddeleri kontrol edin: - Paket sayfasında band genişliği limiti ve aşım politikası var mı? - “Unlimited” ibaresi varsa: adil kullanım throttling koşulu yazıyor mu? - Throttling hangi trafik yönünde uygulanıyor: inbound mi outbound mı? - Kısıt sürekli mi geçici mi? (ör. gün sonuna kadar / 24 saat) - Limit aşımı sonrası ne kadar sonra geri geliyor? - İstisna tanımları var mı? (ör. DDoS mitigation, üretken trafik) - Sağlayıcı “network throttling yapıyoruz” diyor mu yoksa “QoS” adıyla mı geçiyor?

Sağlayıcıya sorulacak net sorular

Destek talebinde şu cümlelerle ilerlemek işinizi hızlandırır: - "Network throttling uygulanıyorsa limit değeri nedir? (Mbps/mbps veya ratio) - "Throttling outbound traffic için mi, inbound için mi? - "Aşım sonrası kısıt kaç saat sürer ve geri dönüş nasıl ölçülür? - "IP/port bazlı bir kural var mı? (ör. bulk download) - "Eğer throttling yoksa, benzer etkiyi veren diğer kök nedenler neler olabilir?"

Network throttling’i azaltmak için kullanıcı tarafında net aksiyonlar

Throttling kaçınılmaz bir altyapı kuralıysa bile etkisini azaltacak teknik hamleler vardır. Burada “her sorunu throttling ile açıklamak” doğru değildir; CDN, cache, optimizasyon ve doğru mimari genelde daha belirleyicidir.

1) Trafik profilinizi ayırın: kim “topu” atıyor?

Önce hangi kaynak tüketiyor bulmanız gerekir. - Sunucu loglarında en çok istek yapan URL’leri bulun. - Büyük outbound yapan endpointleri tespit edin. - Bot trafiğini ayırın (gerekirse WAF)

2) CDN ve cache katmanı ekleyin

Eğer içerik statik ağırlıktaysa (görsel, CSS, JS, video), throttling etkisini origin yükünü düşürerek azaltabilirsiniz. - CDN ile statik içerikleri kenara (edge) taşıyın - Cache kontrol başlıklarını (Cache-Control) doğru ayarlayın

3) “Bulk transfer” davranışını düzenleyin

SFTP/rsync ile büyük transfer yapıyorsanız hız düşüşü throttling ile karışabilir. - Transferleri parçalara bölün - Yoğun saat dışına alın - Transfer yönünü (özellikle outbound) sağlayıcının politikasına göre planlayın

4) Uygulama çıktısını küçültün

Throttling varsa bile veri boyutunu azaltmak gecikmeyi azaltır. - Görselleri optimize edin (image optimization) - Gzip/Brotli kullanın - Gereksiz büyük response’ları sayfa başına bölün

5) Ölçüm ve limit takibi kurun

En pratik yöntem: bant genişliği ve hata oranını sürekli izlemek. - Grafana/Prometheus veya sağlayıcının panel metrikleri - Alert kuralları: ör. network eşiği aşıldığında bildirim - Transfer yoğunluğu ile uygulama gecikmesi arasında korelasyon

6) Gerekirse plan değiştirin: network limiti kritik belirleyici

Eğer throttling sürekli ve işinizi doğrudan etkiliyorsa, teknik optimizasyon tek başına çoğu zaman yetmez. Değiştirirken şu kriterleri net ele alın: - Paketinizin network limiti - Aşım sonrası uygulanacak throttling oranı - Kısıtın yönü (rx/tx) - Overcommit oranı (sağlayıcı açıklıyorsa)

Network throttling ile diğer yavaşlatma nedenlerini karıştırmayın

Benzer belirtiler veren birkaç yaygın durum var. Karışmamak için ayırıcı noktalar şunlar:

CPU/RAM darboğazı: Metriğe yansır; uygulama yavaşlar ama network tx/rx normal olabilir.
Disk I/O darboğazı: Özellikle veritabanı ve log yazmalarında belirgin olur.
Yanlış cache ayarları: Her istek origin’e gider; network artar ama throttling politikası olmayabilir.
DNS/SSL sorunları: İlk bağlantı gecikir; TTFB değişimi olabilir.

Throttling şüphesinde her zaman aynı zaman aralığında CPU, RAM, disk ve network metriklerini birlikte değerlendirin.

Sonuç: Throttling şüphesi varsa 30 dakikada net teşhis yapın

Network throttling; sağlayıcıların adil kullanım, kapasite planlama ve güvenlik hedefleriyle uyguladığı ağ bant genişliği kısıtıdır. Ancak “yavaşlık” tek başına throttling anlamına gelmez; bu yüzden ölçüm ve paket politikası kontrolü şarttır. Aksiyon planınız şu olsun: (1) Paketinizin network politikasını bulun, (2) aynı zaman aralığında network/CPU/disk metriklerini eşleştirin, (3) gerekirse sağlayıcıya limit değeri ve süreyi sorarak kısıtın varlığını netleştirin, (4) CDN/cache ve veri optimizasyonu ile origin trafiğini azaltın. İhtiyacınız devam ediyorsa bir sonraki adım doğru network limiti olan bir plana geçmektir.