VPS Bant Genişliği Nedir? İhtiyacınızı Hesaplayın

VPS bant genişliği nedir?

Bir VPS satın alırken CPU çekirdeği ve RAM miktarı hemen göze çarpar. Bant genişliği ise paket tablosunda küçük bir satır olarak kalır. Trafiğiniz artana, yedekler yanlış zamanda çalışana veya büyük bir dosya sosyal medyada paylaşılana kadar.

VPS bant genişliği, sunucunuzun belirli bir sürede internete gönderebileceği ve internetten alabileceği veri miktarını ifade eder. Sağlayıcılar bunu genellikle iki ayrı değerle anlatır: bağlantı hızı olarak Mbps veya Gbps, aylık veri transferi kotası olarak GB veya TB. İkisi ilişkili olsa da aynı şey değildir.

Örneğin 1 Gbps portunuz olabilir ama aylık transfer limitiniz 2 TB ile sınırlandırılabilir. Aylık transfer hakkınız yüksekken anlık bağlantı hızınız 100 Mbps ile sınırlı da olabilir. İhtiyaç hesabında bu iki değeri ayrı tutmak gerekir.

Mbps ile aylık trafik arasındaki fark

İlk karışıklık birimlerden çıkıyor. Mbps, megabit/saniye demektir. Dosya boyutlarını ölçerken kullandığımız MB ise megabayttır. Bir byte 8 bittir; bu nedenle 100 Mbps teorik olarak saniyede 12,5 MB veri anlamına gelir.

Teorik olarak diyorum, çünkü TCP/IP ve TLS başlıkları, yeniden iletimler, disk okuma hızı ve karşı tarafın bağlantısı bu değeri aşağı çeker. Kullanıcının gördüğü gerçek hız port kapasitesinden genellikle daha düşüktür. Kaba hesap için şu dönüşüm yeterli olur:

100 Mbps / 8 = 12,5 MB/s
12,5 MB/s × 3.600 = 45.000 MB/saat
45.000 MB × 24 × 30 = 32.400.000 MB/ay
≈ 32,4 TB/ay

Bu hesap, 100 Mbps bağlantının 30 gün boyunca hiç boş kalmadan kullanıldığını varsayar. Web sitesi, API veya oyun sunucusu böyle sürekli veri üretmez. Port hızını doğrudan aylık trafik ihtiyacı olarak okumak bu yüzden yanıltıcıdır.

Aylık transfer, belirli bir ay içinde gönderilen ve alınan toplam veri miktarıdır. Bazı firmalar yalnızca çıkış trafiğini, bazıları giriş ve çıkış toplamını, bazıları da iki yönden yüksek olanı sayar. Satın almadan önce trafik tanımını ve aşım ücretini okuyun.

Giriş trafiği ve çıkış trafiği

Bir ziyaretçinin web sitenizden 3 MB JavaScript ve görsel indirmesi, sunucunun çıkış trafiğine 3 MB ekler. Tarayıcının sunucuya gönderdiği HTTP isteği ise giriş trafiğidir. Klasik web sitelerinde bu istek, yanıt verisine kıyasla çoğu zaman çok daha küçüktür.

Yedekleri VPS’e almak giriş trafiğini, VPS’ten uzak depolamaya göndermek çıkış trafiğini büyütür. Veritabanı replikasyonu, Docker image çekme, işletim sistemi güncellemeleri ve video yüklemeleri de hesaba katılmalıdır. Yalnızca ziyaretçi sayısını çarpmak yetmez.

İhtiyacınızı hesaplarken hangi verileri toplayın?

Hesaba tahminle başlamak yerine mevcut ölçümleri kullanmak daha sağlıklıdır. Yeni kurulan bir projede tahmin kaçınılmazsa trafik kaynaklarını tek tek yazın. Ben bir VPS için şu kalemleri ayrı izlemeyi tercih ediyorum:

• Web sayfası, API ve statik dosyaların çıkış trafiği
• Dosya yükleme ve indirme işlemleri
• Veritabanı replikasyonu veya uzak yedekleme
• İşletim sistemi güncellemeleri ve container image indirmeleri
• Monitoring, log gönderimi ve yönetim trafiği
• Oyun sunucusu, medya sunucusu veya canlı yayın gibi sürekli bağlantılar
• Beklenmeyen bot, tarama ve saldırı trafiği

Her kalem için günlük ortalamayı, yoğun saat değerini ve ay içindeki özel günleri not edin. Bir e-ticaret sitesi kampanya gününde, bir eğitim platformu sınav haftasında, bir oyun sunucusu da hafta sonunda farklı davranır. Ortalama değer tek başına kapasite kararı vermeye yetmez.

Basit web sitesi hesabı

Diyelim ki aylık 100.000 sayfa görüntülemeniz var. CSS, JavaScript, görsel ve HTML dahil bir sayfanın ortalama 4 MB veri ürettiğini varsayalım:

100.000 × 4 MB = 400.000 MB
400.000 MB / 1.024 ≈ 390,6 GB/ay

Bu, yalnızca sayfa görüntülemelerinin kaba hesabıdır. Bot istekleri, görsellerin önbelleksiz tekrar indirilmesi, yönetim paneli, API çağrıları ve yedekler ayrıca eklenmelidir. Ben bu noktada en az yüzde 30-50 operasyon payı bırakırım; yeni projede trafik davranışı belirsizse daha geniş pay seçerim.

Örnekte 390 GB üzerine yüzde 50 pay eklediğinizde yaklaşık 585 GB aylık web trafiği çıkar. Paketi bu sayıya tam olarak eşitlemek yerine bir üst güvenli seviyeye bakmak daha sakin bir işletme sağlar. Limit aşıldığında sitenin yavaşlaması kadar beklenmedik fatura da can sıkabilir.

Dosya indirme servisi için hesap

Dosya dağıtan bir uygulamada formül daha doğrudandır. Dosya boyutu, indirme sayısı ve tekrar indirme oranı birlikte düşünülür.

Dosya boyutu × aylık indirme sayısı = temel transfer

2 GB’lık bir imaj dosyası ayda 4.000 kez indiriliyorsa temel çıkış trafiği 8.000 GB, yani yaklaşık 7,8 TiB olur. HTTP başlıkları ve yeniden denemeler için pay bıraktığınızda ihtiyaç biraz yükselir. Burada tek başına port hızına değil, sağlayıcının aylık çıkış politikasına da bakmak gerekir.

Dosyalarınız çok büyükse nesne depolama ve CDN seçeneklerini değerlendirin. CDN içeriği kullanıcıya daha yakın noktalardan sunabilir; fakat origin sunucudan CDN’e yapılan ilk çekimler, cache süresi ve cache dışı istekler yine trafik üretir. CDN kullanınca VPS trafiğinin sıfırlanacağını varsaymayın.

Port hızı ihtiyacını nasıl belirlemeli?

Aylık kotayı hesaplamak bir taraf, aynı anda kaç kullanıcıya hizmet vereceğinizi tahmin etmek başka bir taraf. Bir sitenin aylık 500 GB trafik tüketmesi, 1 Gbps porta ihtiyaç duyduğu anlamına gelmez. Trafik gün içine yayıldığında 100 Mbps bağlantı bile yeterli olabilir.

Yoğun saat için yaklaşık hesabı şöyle kurabilirsiniz:

Yoğun saatte gönderilecek veri / 3.600 = gereken ortalama MB/s
Gereken MB/s × 8 = gereken Mbps

Örneğin yoğun bir saatte toplam 18 GB veri göndereceğinizi varsayalım:

18 GB × 1.024 = 18.432 MB
18.432 / 3.600 ≈ 5,12 MB/s
5,12 × 8 ≈ 41 Mbps

Bu ortalama yaklaşık 41 Mbps’tir. Ani yüklenmeler, eş zamanlı indirmeler ve protokol payı nedeniyle doğrudan 41 Mbps port seçmek yerine kapasite payı bırakırım. Amaç portu sürekli doldurmak değil, kısa süreli piklerde kuyruğun büyümesini önlemektir.

Karşı tarafın bağlantısı da sınırdır. 1 Gbps portunuz olsa bile kullanıcı 20 Mbps mobil bağlantıdaysa dosyayı 1 Gbps ile alamaz. Darboğaz her zaman sunucuda bulunmaz.

Bağlantı sayısı ile bant genişliği aynı değil

Web sunucusunun aynı anda binlerce bağlantı kabul etmesi, bu bağlantıların binlerce yüksek hızlı aktarım yaptığı anlamına gelmez. Keep-alive bağlantıları uzun süre açık kalabilir ama çok az veri taşıyabilir. WebSocket, oyun sunucusu ve canlı yayın gibi uygulamalarda bağlantı süresi ile saniyedeki veri miktarını birlikte incelemek gerekir.

Örneğin 2.000 çevrim içi kullanıcının her biri saniyede 20 KB veri alıyorsa:

2.000 × 20 KB = 40.000 KB/s
40.000 × 8 / 1.000 ≈ 320 Mbps

Mesajların yönü, paket başlıkları ve sunucunun gönderdiği ek veriler bu kaba hesaba dahil değildir. Oyun protokolünüz UDP kullanıyorsa paket kaybı ve yeniden gönderme davranışı da farklılaşır. Oyun veya gerçek zamanlı uygulamalarda sağlayıcıya yalnızca aylık TB bilgisini değil, port kapasitesini ve ağ politikasını da sorun.

Gerçek VPS trafiğini Linux’ta ölçmek

Yeni bir projede tahmin gerekir; çalışan bir VPS’te ise tahmini bırakıp ölçüm almak gerekir. Ben günlük toplamı görmek için çoğu makinede vnstat kullanıyorum. Paket depolarındaki sürüm dağıtıma göre değişebilir.

sudo apt update
sudo apt install vnstat
sudo systemctl enable --now vnstat
vnstat -d
vnstat -m

vnstat -d günlük, vnstat -m aylık trafiği gösterir. İlk kurulumdan hemen sonra anlamlı bir geçmiş beklemeyin; veritabanının ölçüm biriktirmesi gerekir. Çıktıda RX ve TX değerlerini ayrı görürsünüz. Sağlayıcınız toplam trafiği sayıyorsa iki değeri toplamanız gerekir.

Anlık durumu görmek istediğimde sar veya arayüz sayaçlarına bakarım:

ip -s link show eth0
sar -n DEV 1 5

ip -s link çıktısındaki RX ve TX byte sayaçları, arayüzün açılmasından beri geçen toplamı gösterir. sar ise beş saniye boyunca ağ istatistiklerini örnekler. Arayüz adınız eth0 olmayabilir; modern dağıtımlarda ens3 veya benzeri bir ad görebilirsiniz.

Bir dönem cron’a fazladan bir yıldız eklediğim için yedek script’i her dakika çalışmış ve kısa sürede posta kuyruğu büyümüştü. Sorunu ağ trafiği sanıp önce bant genişliğine bakmıştım; mailq ve cron kayıtları asıl nedeni gösterdi. O günden beri ağ grafiği yükseldiğinde yalnızca portu değil, işi üreten süreci de kontrol ediyorum.

Hangi süreç trafik üretiyor?

Toplam trafiği bilmek, kaynağı bilmeden eksik kalır. Anlık bağlantıları görmek için iftop veya nload kullanabilirsiniz. Sade bir başlangıç şöyle:

sudo apt install iftop
sudo iftop -i eth0

iftop anlık bağlantıları ve hangi uzak adreslerle veri alışverişi yapıldığını gösterir. Komuttaki -i seçeneği doğru ağ arayüzünü seçer. Şifreli HTTP trafiğinin içeriğini göremezsiniz; kaynak, hedef ve aktarım hızını görebilirsiniz.

Uzun süreli gözlem için Prometheus ve Grafana daha kullanışlıdır. Benim Proxmox laboratuvarımda her makinedeki node_exporter ağ sayaçlarını topluyor. Grafana’da günlük TX artışını CPU grafiğiyle birlikte izlemek, site yavaşladı şikâyetinin aslında gece çalışan bir replikasyon işi olduğunu fark ettirebiliyor.

Yedekleme, güncelleme ve loglar hesabı nasıl değiştirir?

Bir VPS’in web trafiği küçükken yedekler toplam transferin büyük kısmını oluşturabilir. 80 GB’lık diskin tamamını her gece uzak depolamaya göndermek, kullanıcı trafiğiniz olmasa bile ayda yaklaşık 2.400 GB çıkış anlamına gelir. Gerçek değer sıkıştırma ve değişen blok davranışına göre farklılaşır.

rsync yalnızca değişen dosyaları aktarmada faydalı olabilir; büyük bir veritabanı dump’ı her çalışmada baştan oluşuyorsa tasarruf sınırlı kalır. borgbackup deduplikasyon ve sıkıştırmayla tekrar eden veriyi azaltabilir. Ben yine de sıkıştırıyor, o halde trafik yok diye düşünmem; gerçek aktarımı ölçerim.

İşletim sistemi güncellemeleri ve Docker image’ları, özellikle sık yeniden oluşturulan sunucularda birikir. Staging ortamındaki her deploy işleminde yüzlerce megabayt image çekiliyorsa ay sonunda toplamı görmek şaşırtıcı olabilir. CI/CD işini ayrı bir runner’a taşımak veya image cache kullanmak VPS çıkışını azaltabilir.

Logların dış bir servise gönderilmesi de trafik üretir. Debug seviyesinde açık unutulmuş bir uygulama hem disk hem ağ tarafında gereksiz yük oluşturur. Log seviyesini düşürmek, rotasyon ayarlamak ve yalnızca gerekli kayıtları merkezi sisteme aktarmak daha temizdir.

VPS paketi seçerken sözleşmede neye bakmalı?

Paket karşılaştırırken aşağıdaki ifadeleri aynı anlama geliyormuş gibi okumayın:

Limitsiz kelimesini gördüğünüzde hizmet şartlarını okumadan karar vermeyin. Bazı sağlayıcılar yüksek kullanımda portu sınırlar, bazıları olağan dışı trafiği incelemeye alır. Yedekleme sunucusu, proxy veya dosya dağıtım servisi çalıştıracaksanız kabul edilebilir kullanım kuralları özellikle önemlidir.

Fiyat hesabına aşım ücretini de ekleyin. Trafiğiniz 600 GB civarındaysa 1 TB paket ile 2 TB paket arasındaki fark yalnızca aylık ücret değildir; kampanya gününde ne kadar güvenlik payı kaldığıdır. Bulut Maliyetleri Nasıl Düşürülür? 10 Etkili Yöntem yazısındaki kaynak planlama yaklaşımı burada da işinize yarar.

İhtiyaç büyüdüğünde ilk neyi değiştirmeli?

Trafik sınırına yaklaşıyorsanız refleks olarak daha pahalı VPS’e geçmeyin. Önce hangi verinin çıktığını bulun. Büyük görselleri WebP veya AVIF’e dönüştürmek, cache başlıklarını düzeltmek, gereksiz API yanıtlarını küçültmek ve CDN kullanmak çoğu zaman CPU veya RAM artırmaktan daha doğrudan sonuç verir.

WordPress gibi CMS kullanan bir sitede sayfa cache’i yoksa her istekte PHP ve veritabanı çalışır. Bu durum bant genişliğini tek başına azaltmaz; fakat aynı sunucunun daha fazla isteği karşılamasını zorlaştırır. CMS Performans ve Hız Ayarları: WordPress, Joomla, Drupal içeriğindeki cache ve statik dosya yaklaşımı burada tamamlayıcıdır.

Dosya servisi yapıyorsanız CDN veya nesne depolama; API çalıştırıyorsanız yanıt sıkıştırma ve pagination; yedek alıyorsanız artımlı aktarım düşünün. Trafik azaltma ile kapasite artırma birbirinin alternatifi değildir. Yoğunluk kalıcıysa kapasite artırılır, gereksiz veri üretiliyorsa üretim kaynağında düzeltme yapılır.

Saldırı trafiği normal kullanım hesabına dahil edilmemelidir. Uygulama katmanındaki kötü botlar, açık proxy kullanımı veya UDP flood gibi durumlarda portu büyütmek çözüm olmayabilir. DDoS Saldırısı Nedir? VPS Koruma Rehberi içinde bağlantı sayaçları, upstream filtreleme ve rate limit başlıklarını ayrıca ele almıştım.

Ne zaman VPS yerine başka bir mimari?

İçerik dağıtımı ağırlıklı bir servis, tek VPS’in sürekli yüksek çıkış trafiği taşıdığı bir yapıya dönüşebilir. VPS’i uygulama ve API için tutup büyük dosyaları ayrı bir depolamaya taşımak bu noktada daha mantıklı olabilir. Projenin tamamını başka bir modele geçirmeniz gerekmeyebilir.

Farklı servis modellerini değerlendirirken IaaS, PaaS ve SaaS Farkı Nedir? yazısındaki sorumluluk paylaşımını da hesaba katın. Ağ sınırları kadar işletim yükü, izleme ve yedekleme sorumluluğu da kararın parçasıdır.

Pratik bir hesap şablonu

Kendi projeniz için şu sırayla ilerleyebilirsiniz:

1. Bir sayfanın veya API yanıtının ortalama boyutunu ölçün.
2. Aylık istek, görüntüleme ya da indirme sayısını belirleyin.
3. Yükleme, yedek, güncelleme ve log trafiğini hesaba katın.
4. Yoğun saat için ayrı bir veri miktarı ve eş zamanlı kullanıcı tahmini çıkarın.
5. Yoğun saat verisini saniyeye çevirip gereken Mbps değerini bulun.
6. Protokol, yeniden deneme, kampanya ve büyüme payı bırakın.
7. Sağlayıcının RX/TX hesabını, aşım politikasını ve port paylaşımını doğrulayın.
8. VPS çalışmaya başladıktan sonra vnstat ve monitoring ile tahmini gerçek ölçümle karşılaştırın.

Örneğin aylık 700 GB tahmin ettiyseniz 700 GB’lık sınıra yaslanmayın. Günlük ortalamayı, en yüksek günü ve en yüksek saati ayrı kaydedin. Üç ay sonra tahmininiz hâlâ ölçümle uyuşmuyorsa formülü değil, varsayımlarınızı düzeltin.

Benim için güvenilir kapasite planı, satın alma sayfasındaki en büyük sayıya bakmak değil; trafiğin ne zaman ve hangi süreç yüzünden yükseldiğini bilmektir. Ağ sayaçlarını izlemeye başladığınızda bant genişliği soyut bir paket özelliği olmaktan çıkar. Hangi veriyi neden taşıdığınızı görürsünüz.

Sık Sorulan Sorular

VPS bant genişliği ile internet hızı aynı şey mi?

Hayır. İnternet hızı genellikle portun anlık kapasitesini, bant genişliği kotası ise ay boyunca aktarılabilecek toplam veriyi anlatır. 1 Gbps portu olan bir VPS’in aylık transfer sınırı yine de düşük olabilir.

Bir web sitesi için ne kadar VPS bant genişliği gerekir?

Değer; sayfa boyutuna, aylık ziyaret sayısına, görsel ve video kullanımına, bot trafiğine ve yedekleme düzenine göre değişir. Sayfa boyutunu aylık görüntüleme sayısıyla çarpıp yedek ve güvenlik payını ekleyerek başlangıç tahmini yapabilirsiniz.

Aylık trafik kotası aşılırsa VPS kapanır mı?

Sağlayıcının politikasına bağlıdır. Ek ücret, hız kısıtlaması, bağlantının durdurulması veya manuel inceleme uygulanabilir. Paket seçmeden önce aşım ücretini ve limitsiz trafik ifadesinin kullanım şartlarını okuyun.

VPS trafiğini Linux’ta nasıl takip edebilirim?

vnstat günlük ve aylık RX/TX toplamlarını, ip -s link arayüz sayaçlarını, iftop ise anlık bağlantıları gösterir. Uzun dönemli karşılaştırma için bu ölçümleri Prometheus ve Grafana gibi monitoring araçlarına aktarmak daha kullanışlıdır.