Network throttling nedir? Hosting sağlayıcılar neden uygular?

Network throttling, sunucunun internete erişim hızının (bant genişliği) kontrollü biçimde düşürülmesi anlamına gelir. Hosting sağlayıcılar bunu genellikle ağın genel sağlığını korumak, aşırı yükleyen trafiği dengelemek ve belirli “adil kullanım” kurallarını uygulamak için kullanır. Bu yazıda throttling’in neyi etkilediğini, hangi ölçümlerde görüldüğünü ve hangi senaryolarda risk oluşturduğunu net şekilde öğreneceksiniz.

Network throttling nedir? (Ağ kısıtlaması nasıl çalışır?)

Network throttling, kullanıcının sunucusundan çıkan ya da gelen trafiğin belirli eşiklerin üstünde kalması durumunda hız limitlenmesi veya gecikme (latency) artışıyla sonuçlanmasıdır. Bu, CPU veya RAM’le ilgili bir kısıtlama değildir; doğrudan network katmanına yapılan müdahaledir.

Throttling neyi etkiler?

Network throttling; genellikle şu metrikleri doğrudan etkiler: - Bağlantı hızınızın düşmesi (throughput): Örneğin 200 Mbps yerine 20 Mbps efektif hıza düşüş. - Yüksek gecikme (RTT/latency): Süreç hız düşümü gibi algılanır. - Transfer sürelerinin uzaması: Dosya indirme, yedek (backup) yükleme, büyük veri aktarımları belirgin etkilenir. - Bottleneck’in oluşması: Sunucu tarafı hızlı olsa bile ağ tarafı “dar boğaz” olur.

“Throttling” ile “DDoS mitigasyonu” aynı şey değildir

Network throttling: Genellikle planlı bir kapasite yönetimi/adil kullanım politikasıdır.
DDoS mitigasyonu: Saldırıyı filtrelemek ve saldırı trafiğini temizlemek için uygulanır. Burada amaç güvenliktir, bant genişliği yönetimi ikincil olabilir.

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

Ağ kısıtlamasının arkasındaki temel gerekçe, veri merkezinde paylaşılan altyapının adil çalışmasını sağlamaktır. Sağlayıcılar aynı fiziksel ağ üzerinde çok sayıda müşteriyi barındırdığı için, az sayıda müşterinin aşırı kullanımı tüm topluluğu yavaşlatabilir.

1) Adil kullanım (fair use) ve kapasite yönetimi

Bir VPS/VDS havuzunda bant genişliği tek bir hesaba “limitsiz” bırakılırsa, tek bir yoğun transfer müşterisi diğerlerini etkiler. Throttling bu etkinin önüne geçer.

2) Ağ tıkanmalarını önlemek (congestion control)

Ağda yoğunluk olduğunda paket kuyrukları artar. Throttling, trafiği eşiklerde tutarak tıkanmayı azaltır. Sonuç olarak; diğer kullanıcıların gecikmesi daha az etkilenir.

3) Belirli tarife/plan sınırlarını uygulamak

Birçok sağlayıcı bant genişliği için: - Aylık transfer (data transfer) - Paylaşımlı hız hedefleri - Anlık burst (kısa süreli yükselme) limitleri gibi sınırlar tanımlar. Throttling bu sözleşmeye/abonelik modeline uyum sağlar.

4) Günlük/haftalık “pik” dönemlerini dengelemek

Yedekleme yükleri, büyük güncellemeler, içerik çekmeleri veya kampanyalar bazı zamanlarda toplu trafik oluşturur. Ağ yönetimi, bu pikleri daha kontrollü hale getirir.

Throttling hangi durumlarda devreye girer?

Sağlayıcıdan sağlayıcıya detaylar değişir; ancak pratikte sık görülen devreye girme koşulları şunlardır:

Yaygın tetikleyiciler

Aylık transfer limitini aşmak veya transfer hızının planı aşan seviyelere çıkması
Belirli saatlerde beklenmedik yüksek outbound (sunucudan çıkan) trafik
Aynı IP/hesaptan yoğun bağlantı kurma veya çok sayıda küçük paketle uzun süreli trafik
Büyük ölçekli yedek (backup) yükleme/indirme, log arşivleme, veri replikasyonu

Sağlayıcı “throttling yaptık” derken ne kastedebilir?

Bazı sağlayıcılar şunları da aynı başlık altında raporlayabilir: - Trafiği hız limitiyle kısıtlamak - Burst süresini kısaltmak - Belirli protokollerde (ör. sadece büyük dosya transferlerinde) kısıtlama uygulamak

Bu yüzden sözleşmede “network throttling”, “fair use” ve “bandwidth policy” başlıklarının birlikte okunması gerekir.

Throttling’i nasıl anlarsınız? (Gerçek hayatta ipuçları)

Throttling’i sadece “hız yavaş” diye yorumlamak doğru değildir. En sağlıklı yöntem; ölçüm yaparak sunucu/uygulama tarafı mı yoksa ağ tarafı mı sorun yaşıyor anlamaktır.

Sunucu içi değil, ağ etkisini ayırın

CPU/RAM kullanımınız düşükken transfer yavaşsa ağ throttling ihtimali yükselir.
HTTP uygulamanız hızlı bir şekilde sayfa üretse bile dosya indirme/yükleme süreleri uzuyorsa yine ağ tarafı şüphelidir.

Ölçüm için pratik testler

Aşağıdaki kontroller “ağ kısıtlaması” şüphesini doğrular:

1) Aynı anda küçük ve büyük transfer farkını gözleyin

Küçük dosyalar hızla gelirken büyük dosyalar belirgin yavaşlıyorsa bant genişliği yönetimi söz konusu olabilir.

2) Basit hız testi yapın (içerik değil, ham transfer)

Örnek bir mantık: - Aynı bölgeden bir dosyayı indirin. - 1 GB, 5 GB gibi farklı boylarda tekrar edin. - Sonuçlar sürekli “tavan hız” civarında mı kalıyor kontrol edin.

3) İzleme ve log kontrolü

Sağlayıcı panelinde “network usage” veya benzeri alanlar varsa orayı karşılaştırın.
Sunucu tarafında transfer sayacını (varsa) ve sağlayıcı metriklerini eşleyin.

Hangi iş yükleri throttling’den daha çok etkilenir?

Throttling, özellikle bant genişliği yoğun işlerde performansı net düşürür. Aşağıdaki senaryolar yüksek risk grubudur.

Yüksek etkilenme senaryoları

CDN pull: CDN edge’lerin origin’den yüksek hacimde çekim yapması
Büyük dosya indirme (ISO, arşiv, kurulum paketleri)
Sürekli log akışı veya arşivlerin düzenli dışa aktarımı
Sunucular arası replikasyon / veri senkronizasyonu (rsync, benzeri araçlarla sık tarama)
Video/streaming altyapıları (özellikle origin’e yüksek istek bindiyse)

Orta/az etkilenme senaryoları

CPU odaklı işler (render, bazı işlemci yoğun görevler)
Küçük içerikli web siteleri (sık değişmeyen, küçük boyutlu sayfalar)
Uygulama cache’i güçlü, istek hacmi düşük sistemler

Network throttling ile doğru plan seçimi: Net kontrol listesi

Throttling’i yaşamamak için “tek bir metrik” yerine birden fazla kriteri birlikte değerlendirin. Aşağıdaki liste, hosting seçimini netleştirir.

1) Sözleşmede bant genişliği politikasını bulun

Şunları arayın: - Limit tipi: aylık transfer mi, hız limiti mi? - Burst (kısa süreli yükselme) var mı? - Limit aşımı sonrası ne yapılıyor: hız düşümü mü, ek ücret mi?

2) Ölçülebilir metrik isteyin

Tercihen şunları görün: - “Network usage” grafikleri - Kısıtlamanın nasıl hesaplandığı (ör. outbound ağırlıklı mı?) - Kısıtlamanın devre süresi (hemen mi, günlük mi?)

3) Trafik deseninizi planla

Kendi kullanım modelinizi yazın: - Yüksek outbound dönemleriniz var mı? (yedekleme, güncelleme, replikasyon) - Dosya boyutları ortalama kaç GB? - CDN kullanıyor musunuz, origin’de ne kadar veri çekilecek?

4) Alternatif mimariyi değerlendirin

Throttling riski taşıyan iş yüklerinde şu mimariler fark yaratır: - Origin trafiğini azaltmak için CDN - Yedekleri düzenli çekişe değil, daha planlı zaman pencerelerine almak - Büyük veri aktarımı için ayrı zamanlama/plan (ör. düşük talep saatleri)

Hosting sağlayıcıyla görüşürken sorulacak net sorular

Bunları “varsayımla” bırakmayın. Görüşme veya destek biletinde kısa ve net cevap isteyin.

Sorulacak 8 soru

Bu plan kapsamında bandwidth limiti nasıl hesaplanıyor (aylık transfer / hız limiti)?
Limit aşımında throttling var mı? Varsa nasıl uygulanıyor (hız tavanı mı, gecikme artışı mı)?
Throttling hangi trafik yönünde (inbound mı, outbound mı)?
Throttling eşiği kaçıncı GB/Mbps seviyesinde başlıyor?
Uygulanan kısıt ne kadar sürüyor (o gün mü, ay sonuna kadar mı)?
Sağlayıcının ağ yoğunluğu arttığında otomatik kısıtlama uygulanıyor mu?
CDN kullanımında origin’den çekimler throttling’e takılır mı?
Yükseltme (upgrade) ile kısıt kalkıyor mu, yoksa sadece limit mi artıyor?

Bu sorulara somut sayılarla cevap gelmezse, planın uygulama riski yüksektir.

Sonuç: Throttling’i “olsa da olur” değil, ölçülebilir risk olarak ele alın

Network throttling, sağlayıcının ağ sağlığını korumak için kullandığı kontrollü bir kapasite yönetimi mekanizmasıdır. Ancak özellikle bant genişliği yoğun işlerde performans düşüşü doğurur. Aksiyon olarak; satın alım/plan seçimi öncesinde bant genişliği politikasını (throttling eşiği, yönü ve süresi) yazılı şekilde netleştirin, ardından ilk kurulumdan itibaren birkaç büyük transferle gerçek performansı ölçün. Eğer iş yükünüz sürekli büyük veri aktarımı içeriyorsa, CDN ve zamanlama mimarisiyle origin trafiğini azaltın ya da daha uygun bant genişliği tanımlı bir plan tercih edin.