Video Streaming için Bant Genişliği Planlaması: Net Hesap Rehberi

Video streaming projelerinde bant genişliği planlaması, hem maliyeti hem de kullanıcı deneyimini doğrudan belirler. Yanlış kapasite hesapları “takılma” ve paket kaybı olarak geri döner; fazla kapasite ise gereksiz maliyet üretir. Bu rehberde, bitrate, eşzamanlı kullanıcı, protokol/format overhead ve CDN/katman mimarisi üzerinden net bir bant genişliği hesabı yapmayı öğreneceksiniz. Ayrıca büyüme senaryosu için kapasiteyi nasıl revize edeceğinizi de adım adım göreceksiniz.

1) Streaming’de bant genişliği hangi ölçüye dayanır?

Video transferini planlarken temel büyüklük “toplam veri” ve bunun “zamana bölünmüş hızı”dır. İnternette bant genişliği genelde Mbps (megabit/saniye) veya Gbps olarak; trafik ise GB/TB olarak takip edilir.

Streaming’de bant genişliği ihtiyacı iki şekilde görülür:

• İstemci başına ortalama çıkış (egress) hızı: Kullanıcının aldığı segmentlerin toplam veri hızı.
• Eşzamanlı kullanıcı sayısı (concurrency): Aynı anda izleyen kullanıcı sayısı.

Bitrate (bps) ve çözünürlük ilişkisi

Bitrate, codec ve taşıma formatına göre değişir. Pratik planlama için “hedef bitrate” üzerinden ilerlemek en sağlıklı yöntemdir.

Aşağıdaki değerler; H.264/H.265 ve ABR (Adaptive Bitrate) sistemlerinde sık görülen örnek hedeflerdir:

• 360p: 0.8–1.2 Mbps
• 480p: 1.5–2.0 Mbps
• 720p: 2.5–4.0 Mbps
• 1080p: 4.0–6.0 Mbps
• 1440p: 6.0–9.0 Mbps
• 2160p (4K): 12–18 Mbps

ABR kullanıyorsanız kullanıcılar ağ koşuluna göre farklı bitrate’lere iner/çıkar. Bu yüzden tek bir çözünürlük yerine ortalama izleme bitrate hesaplamalısınız.

ABR’de “ortalama bitrate” nasıl çıkarılır?

En basit yaklaşım: ABR için hedef ladder (ör. 360p–1080p) belirleyip, dağılım oranlarını tahmin etmektir.

Örnek dağılım (varsayım): - %10 360p (1.0 Mbps) - %25 480p (1.8 Mbps) - %45 720p (3.2 Mbps) - %20 1080p (5.0 Mbps)

Ortalama bitrate: - 0.10×1.0 + 0.25×1.8 + 0.45×3.2 + 0.20×5.0 = 0.10 + 0.45 + 1.44 + 1.00 = 2.99 Mbps

Planlama için bu değeri “izleme anında” ortalama olarak kabul edebilirsiniz.

2) Eşzamanlı kullanıcıdan kapasiteye geçiş formülü

Bant genişliği planlamasının özü şudur:

1) Kullanıcı başına ortalama bitrate hesapla 2) Eşzamanlı kullanıcıyla çarp 3) Overhead (container, segment, protokol) ve burst payı ekle

Temel formül

Gerekli çıkış (egress) Mbps ≈ Ortalama Bitrate (Mbps) × Eşzamanlı Kullanıcı × Overhead Katsayısı × Burst Payı

Overhead katsayısı, özellikle HTTP tabanlı segment streaming (HLS/DASH) veya parçalı transferlerde gerçek veriden daha fazlasını kapsar. Ortalama kullanım için pratik aralık:

• Overhead: 1.15–1.25

Burst payı: CDN olmadan veya pik saatlerde akışların aynı anda hızlanması nedeniyle eklenir. Pratik aralık:

• Burst payı: 1.1–1.3

Somut örnek: 720p ağırlıklı bir servis

Varsayalım: - ABR ortalama bitrate: 3.0 Mbps - Eşzamanlı kullanıcı (peak): 2.000 - Overhead: 1.20 - Burst payı: 1.20

Gerekli egress: - 3.0 × 2.000 = 6.000 Mbps - Overhead: 6.000 × 1.20 = 7.200 Mbps - Burst payı: 7.200 × 1.20 = 8.640 Mbps

Bu yaklaşık 8.6 Gbps dış bant genişliği demektir.

Not: Eğer CDN kullanıyorsanız, origin sunucunuzdaki yük daha düşer. Ancak CDN hit ratio (bellekte bulunma oranı) ve yerel önbellekleme süreleri, origin üzerindeki gerçek egress’i belirler.

3) Origin (sunucu) mi? CDN mi? Bant genişliği stratejisi

Video streaming çoğu senaryoda CDN ile çalışır. Bu durumda planlama iki katmana ayrılır:

• Kullanıcı-ile CDN arası: Yük CDN’in egress’i
• CDN-ile origin arası: Segmentlerin ilk isabetlerinde origin trafiği

CDN planlamasında dikkat edilmesi gerekenler

CDN yalnızca “daha hızlı” değildir; aynı zamanda origin bant genişliği faturasını düşürür.

CDN kullanırken kapasite tahmini için şu metrikleri netleştirin:

• Hit ratio: Aynı segmentin CDN’den servis edilme oranı
• TTL (time-to-live): Ön belleğin ne kadar süre taze kaldığı
• Cache key: Kullanıcı ajanı/DRM/parametreler segmentleri bölebilir
• Bitrate ladder: Ladder çok genişse cache davranışı değişir

Origin için pratik yaklaşım

CDN’in hit ratio’su %80–95 aralığında stabil ise origin’e düşen trafik ciddi azalır. Ancak şu durumlarda origin yük yükselir:

• Yeni içerik yayınlama anında düşük cache isabeti
• Çok niş içerikler (düşük izlenme)
• DRM/oynatma parametrelerinin cache’i azaltması
• Çok agresif TTL ayarı

Planlamayı güvenli yapmak için iki senaryo hesaplayın:

• Senaryo A (iyileşmiş cache): Origin’e giden oran %20
• Senaryo B (zayıf cache): Origin’e giden oran %50

Örneğin yukarıdaki 8.6 Gbps’lik kullanıcı egress’i, CDN arkasındaysa origin’de: - Senaryo A: 8.6 × 0.20 = 1.72 Gbps - Senaryo B: 8.6 × 0.50 = 4.32 Gbps

Bu, origin sunucunun ağ kapasitesi ve fiyatlandırma seçimi için doğrudan bir çerçeve sağlar.

4) Saatlik/aylık trafik hesabı (GB/TB planı)

Bant genişliği (Mbps) tek başına “ay sonu faturası” tahminine yetmez. Trafik birikimi için izlenme süresi önemlidir.

İzlenme temelli trafik formülü

Aylık veri (GB) ≈ Ortalama bitrate (Mbps) × toplam izleme saniyesi × 1.15–1.25 / 8 / 1024

Neden bölüyoruz? - Mbps = megabit/saniye - GB için megabit→megabyte→GB dönüşümü gerekir: /8 ve /1024

Basit örnek

• Ortalama bitrate: 3.0 Mbps
• Aylık toplam izleme süresi: 1.000.000 dakika

Dönüşüm: - 1.000.000 dakika = 60.000.000 saniye - Toplam megabit = 3.0 × 60.000.000 = 180.000.000 Mbps*saniye - Bu da megabit cinsinden veri: 180.000.000 megabit - GB: 180.000.000 / 8 / 1024 ≈ 21.48 TB

Overhead ekleyelim (1.20): - 21.48 × 1.20 = 25.8 TB/ay

Bu hesap; sadece streaming içeriği için kapasite planlar. Web sayfası, API, reklam veya istatistik trafiğini ayrı ele alın.

5) Planlamayı “kontrol paneli seviyesi”ne indirin (kayıp yaşamayın)

Bant genişliği planı tek seferlik bir sayı değildir; izleme (monitoring) ile güncellenir. NetKıyas gibi karşılaştırma platformlarında ürün seçerken “kullanım planı” kadar “ölçüm yöntemi” de kritik olur.

Ölçmeniz gereken göstergeler

Aşağıdaki metrikler, planın doğruluğunu test eder:

• Origin sunucu network egress (Gbps ve toplam TB)
• Kuyruk/yanıt süreleri: İlk segment (TTFB) ve oynatma devamı
• HTTP 4xx/5xx oranı: Segment isteklerinde hata varsa yeniden denemeler trafik şişirir
• Cache hit ratio (CDN): Origin yükünü anlamak için
• Bitrate dağılımı: ABR gerçekten beklediğiniz gibi mi akıyor?

Overhead’i büyüten gerçek nedenler

Overhead katsayısını 1.20 varsaymak, pratikte şu etkileri kapsar:

• Segment başına başlık (header) ve manifest (m3u8/mpd) istekleri
• HTTP yeniden denemeleri
• Kullanıcıların farklı cihaz/oynatıcı davranışları
• Çoklu parça indirme/seek (oynatma konumuna atlama)

Seek (ileri/geri sarmalama) yoğun olduğunda egress artar. Planlama için “ortalama izleme süresi” yerine “pencere içinde gerçek istek yoğunluğu” da dikkate alınmalıdır.

Hız testi ile doğrulama

Bant genişliği planınızı doğrulamak için iki tip test kullanın:

1) Sahada ABR ladder simülasyonu: Farklı bağlantı hızlarıyla bitrate davranışını ölçün 2) Eşzamanlı oyuncu senaryosu: Load test ile concurrency’yi peak’e yakın test edin

İlk segmentin geç gelmesi (manifest veya ilk chunk gecikmesi) kullanıcıyı daha düşük bitrate’e iter; bu da ortalama bitrate’i etkiler. Bu yüzden “sadece hesap” yerine test + ölçüm şarttır.

6) Senaryo bazlı kapasite tablosu (hedefinizi netleştirin)

Aşağıdaki tablo, ortalama bitrate ve concurrency’ye göre yaklaşık egress değerini hızlı görmek için hazırlanmıştır. Overhead 1.20 ve burst payı 1.20 kabul edilmiştir.

Bu değerler CDN’siz origin gibi düşünülmelidir. CDN varsa origin üzerindeki egress, hit ratio’ya göre bu sayının bir kısmına iner. Bu nedenle CDN kullanıyorsanız mutlaka origin için ikinci bir hesap yapın (ör. %20 ve %50 orijin yük senaryosu).

Sonuç: Planı tek sayıya indirip değil, iki seviyeli testle tamamlayın

Video streaming için bant genişliği planlamasında doğru yol; önce ortalama bitrate + concurrency ile Mbps/Gbps’yi hesaplamak, sonra overhead ve burst payı ekleyerek güvenli kapasiteyi görmek ve son olarak bunu ölçümle doğrulamaktır. İlk lansman için origin’de pik egress’i “iyileşmiş cache” ve “zayıf cache” senaryolarında iki farklı değer olarak ele alın. Aksiyon önerisi: ABR ladder’ınızı (bitrate dağılımı) netleştirin, peak concurrency için formülü çalıştırın, ardından CDN hit ratio ve origin egress metriklerini izleyerek 1–2 hafta içinde katsayıları revize edin. Böylece hem takılma riski azalır hem de bant genişliği maliyeti kontrollü kalır.