Hız Testi Sunucusu Kurulumu ve Ölçüm Düğümleri

Bir operatörün abonesine "1 Gbps veriyorum" diyebilmesi için ölçümün doğru yerden yapılması gerekir: ölçüm düğümü şebekeye ne kadar yakınsa sonuç erişim ağının gerçek kapasitesini o kadar yansıtır, düğüm uzaklaştıkça ölçtüğünüz şey abonenin hattı değil, aradaki transit ve peering yolu olur. Bu yüzden operatörler, ölçüm ve raporlama firmaları ve kurumsal ağ ekipleri kendi hız ölçüm düğümlerini kurar. Bu yazıda ölçüm düğümünün ne işe yaradığını, doğru ölçümün hangi metrikleri gerektirdiğini, tek bir TCP akışının neden 1 Gbps'i dolduramadığını ve altyapıyı kurarken nelere dikkat edilmesi gerektiğini anlatıyoruz.

Ölçüm düğümü nedir, neden kendi düğümünüz olmalı?

Hız ölçüm düğümü (measurement node), abonenin ya da test istemcisinin karşısına konumlandırılan, yüksek kapasiteli bağlantıya sahip bir sunucudur. İstemci bu sunucuya veri gönderip alarak indirme hızı, yükleme hızı, gecikme ve jitter değerlerini ölçer.

Buradaki kritik nokta şudur: ölçüm sonucu, istemci ile sunucu arasındaki en zayıf halkayı gösterir. Abonenin hattı 1 Gbps olsa bile ölçüm düğümü başka bir ülkedeyse ya da transit üzerinden dolambaçlı bir yoldan erişiliyorsa, ölçtüğünüz şey abonenin erişim hızı değil, o yolun kapasitesidir.

Kendi düğümünüzü işletmenin üç somut faydası vardır:

• Doğru teşhis: Şikâyet geldiğinde erişim ağı ile omurga arasındaki sorunu ayırt edebilirsiniz.
• Tutarlı raporlama: Aynı yöntem, aynı sunucu ve aynı ölçüm koşullarıyla dönemler arası karşılaştırılabilir veri üretirsiniz.
• Abone algısı: Aboneler hızlarını test ederken kullandıkları sunucu size yakınsa, ölçüm gerçek deneyimi yansıtır ve gereksiz şikâyet trafiği azalır.

Doğru ölçüm neyi ölçer?

"Hız testi" tek bir sayı üretir ama arkasında birden fazla büyüklük vardır ve bunları ayırmadan yapılan ölçüm yanıltıcıdır.

• Throughput (aktarım hızı): Belirli bir sürede taşınan gerçek veri miktarı. Uygulama katmanında ölçülür.
• Gecikme (RTT): Paketin gidiş-dönüş süresi. Oyun, VoIP ve etkileşimli uygulamalarda throughput'tan önemlidir.
• Jitter: Gecikmenin dalgalanması. Ses ve görüntü kalitesini doğrudan belirler.
• Paket kaybı: TCP'de yeniden gönderim, dolayısıyla hız düşüşü demektir.

TCP tabanlı ölçümlerin nasıl yapılması gerektiği RFC 6349 ile çerçevelenmiştir. Bu belge yalnızca "kaç Mbps" demekle yetinmez, üç ek metrik tanımlar:

• TCP Transfer Time Ratio: Gerçekleşen aktarım süresinin, ideal aktarım süresine oranı. 1'e ne kadar yakınsa o kadar iyidir.
• TCP Efficiency (%): (Gönderilen bayt − yeniden gönderilen bayt) / gönderilen bayt × 100. Paket kaybının aktarıma etkisini gösterir.
• Buffer Delay (%): Yük altında RTT'nin, boştaki RTT'ye göre ne kadar arttığı. Ara cihazlardaki tampon şişmesini (bufferbloat) açığa çıkarır.

RFC 6349 ayrıca test sırasını da tanımlar: önce yol MTU'sunun belirlenmesi, sonra yoğun olmayan saatlerde temel RTT ve kapasite ölçümü, ardından doğru boyutlandırılmış tamponlarla her iki yönde throughput testi. Bu sıra atlandığında elde edilen sayı tekrar edilebilir olmaz.

En sık yapılan hata: pencere boyutu ve BDP

Sahada en sık karşılaşılan sorun şudur: hat 1 Gbps'tir, test 200 Mbps gösterir ve herkes şebekeyi suçlar. Oysa sebep çoğu zaman TCP'nin kendi fiziğidir.

Tek bir TCP akışının taşıyabileceği azami hız şu bağıntıyla sınırlıdır:

azami throughput = pencere boyutu / RTT

Gereken pencere boyutuna BDP (Bandwidth-Delay Product) denir ve bant genişliği × RTT ile hesaplanır. RFC 6349'un kuralı nettir: gönderme ve alma soket tamponları BDP'ye eşit veya ondan büyük olmalıdır.

Sayısal örnek: 100 Mbps kapasiteli, 5 ms RTT'li bir yolda 16 KB'lık bir pencere ile ancak 25,6 Mbps elde edilir. Hat sağlıklıdır; sınırlayan şey penceredir.

Yüksek kapasiteli ve uzak yollarda tablo daha da çarpıcıdır:

• 1 Gbps, 100 ms RTT: gereken BDP ≈ 12,5 MB → iperf3 -c sunucu -w 12M -P 4
• 10 Gbps, 100 ms RTT: gereken BDP ≈ 125 MB → iperf3 -c sunucu -w 100M -P 4

Paralel akışlar (-P) aynı sorunu farklı yoldan çözer: dört akış, her biri 64 KB pencereyle çalışsa bile toplamda 256 KB veri havada tutar. Bu, teşhis için de kullanışlı bir ayrımdır:

• Tek akış yavaş, paralel hızlıysa → akış başına bir sınır vardır (pencere boyutu, akış başına QoS/policing veya ECMP dağılım dengesizliği).
• İkisi de aynı tavana vuruyorsa → paylaşılan bir sınır vardır (hat kapasitesi, yol üzerinde shaper).
• Paralel, tekten daha kötüyse → uç nokta CPU'su doymuştur.

Son uyarı: işletim sistemi, istenen tampon boyutunu sessizce kısabilir. iperf3 çıktısındaki "socket buffer size" satırını mutlaka kontrol edin.

Peering ve transit: sonucu belirleyen görünmez katman

Ölçüm düğümünün donanımı ne kadar güçlü olursa olsun, sonucu belirleyen şey o düğüme giden yoldur. Burada iki kavram ayrılır: transit, bir üst sağlayıcıdan internetin tamamına erişim satın almanızdır; peering ise iki ağın kendi trafiklerini doğrudan, genellikle bir internet değişim noktası (IXP) üzerinden değiş tokuş etmesidir.

Peering'in ölçüm açısından değeri, atlanan sıçrama sayısı ve kısalan yoldur. Yurt içi bir aboneden yurt içi bir ölçüm düğümüne giden trafik, bir IXP üzerinden doğrudan aktarıldığında hem gecikme düşer hem de transit tıkanıklığından etkilenmez.

Türkiye tarafında altyapı bu açıdan olgunlaşmıştır. Internet Society Pulse verilerine göre Türkiye'de 5 aktif internet değişim noktası ve toplam 95 üye bulunuyor; bunların dördü İstanbul'da, biri Ankara'da konumlu. Ağların %64'ü ya doğrudan bir IXP üyesi ya da bir IXP üyesinin müşterisi durumunda ve Türkiye'de en çok ziyaret edilen 1.000 sitenin %66'sına yurt içi bir sunucu veya önbellek üzerinden erişilebiliyor.

Pratik sonuç: ölçüm düğümünüzü yurt içinde ve iyi peering'e sahip bir altyapıda konumlandırdığınızda, ölçtüğünüz şey gerçekten erişim ağının performansı olur. Yurt dışı bir düğümde ölçüm yaparsanız, sonuca uluslararası kapasite ve transit koşulları da karışır.

Hangi ölçüm platformu?

Tek bir doğru araç yoktur; amaca göre seçilir ve çoğu operatör bunları birlikte kullanır.

Ookla Speedtest düğümü

Abonenin tanıdığı ve kendiliğinden kullandığı arayüzdür. Kendi düğümünüzü işletmek, abonelerinizin testlerinin şebekenizin içinde sonlanmasını sağlar. Marka algısı ve şikâyet yönetimi açısından değerlidir, ancak metodolojisi üzerinde kontrolünüz sınırlıdır.

M-Lab / ndt7

Açık kaynak ölçüm platformudur. ndt7, mümkün olduğunda TCP BBR kullanır ve TCP_INFO üzerinden çekirdek düzeyinde istatistik toplar: throughput, RTT, paket kaybı ve kullanılan tıkanıklık kontrol algoritması. Ölçümün nasıl yapıldığını görebilmek istiyorsanız uygundur.

iperf3

Referans ölçüm aracıdır. Abone testi için değil, mühendislik doğrulaması için kullanılır: pencere boyutu, paralel akış sayısı, TCP/UDP seçimi ve süre tamamen sizin kontrolünüzdedir. Kabul testleri ve arıza teşhisinde standarttır.

FTP / HTTP indirme sunucusu

Özellikle mobil şebeke ölçümlerinde tercih edilir; çünkü test istemcisi standart bir uygulama davranışı sergiler ve saha ekipleri özel araç kurmadan ölçüm yapabilir. Mobil tarafta bu yaklaşımı mobil şebeke hız ölçümü için FTP test sunucusu yazımızda ayrıntılandırdık.

Mobil şebeke ölçümü ve saha testleri

Sabit hat ölçümünden farklı olarak mobil ölçüm, konum ve zaman boyutunu da içerir. Aynı hücrede, aynı saatte, farklı operatörlerle yapılan ölçümlerin karşılaştırılabilir olması için sunucu tarafının değişmez kalması gerekir: aynı sunucu, aynı dosya boyutu, aynı protokol, aynı kapasite.

Sunucu tarafı sabit değilse elde edilen fark operatör farkı mı yoksa sunucu yükü mü, ayırt edemezsiniz. Bu yüzden saha ölçümü yapan firmalar için ölçüm sunucusunun kapasitesi kadar tutarlılığı da önemlidir: sunucunun ölçüm anında başka bir yük altında olmaması gerekir.

5G'de tablo daha da hassaslaşır; yüksek throughput değerlerinde tek akış ve varsayılan tampon ayarları hızla yetersiz kalır. Bu senaryonun ayrıntılarını 5G şebekelerde FTP tabanlı throughput testi ve QoS raporlama yazımızda ele aldık.

Ölçüm sunucusu altyapısı: nelere bakılmalı?

Ölçüm sunucusu, normal bir web sunucusundan farklı bir profil ister. Öncelik sırası şudur:

• Port hızı ve trafik politikası: Ölçmek istediğiniz hızın en az iki katı port kapasitesi hedefleyin. Aylık kota, sürekli ölçüm yapan bir düğümde hızla dolar; sınırsız trafik tercih edin.
• Şekillendirme (shaping) olmaması: Sağlayıcının hat üzerinde herhangi bir hız sınırlama uygulamadığını yazılı olarak teyit edin. Ölçüm sunucusunda shaping, ölçümü baştan geçersiz kılar.
• CPU: Yüksek throughput'ta darboğaz çoğu zaman ağ değil, TCP işleme yüküdür. Tek çekirdek performansı yüksek, güncel nesil bir işlemci gerekir.
• Disk: FTP/HTTP tabanlı ölçümde dosya okuma hızı sınırlayıcı olabilir; NVMe M.2 SSD tercih edin. Bellekten servis edilebilen test dosyaları daha da iyidir.
• Lokasyon ve peering: Hedef kitlenizin bulunduğu ülkede ve iyi peering'e sahip bir altyapıda konumlandırın.
• IP ve ters kayıt: Sabit IP ve doğru PTR kaydı, ölçüm sonuçlarının izlenebilirliği için gereklidir.
• İzleme: Sunucunun kendi CPU, bellek, disk ve arayüz istatistiklerini kaydedin. Ölçüm anındaki sunucu yükünü bilmiyorsanız sonucu savunamazsınız.

Raporlama ve şeffaflık tarafı

Ölçüm bir teknik faaliyet olduğu kadar bir belgeleme faaliyetidir. BTK'nın genişbant hizmetlerine ilişkin şeffaflık yaklaşımı, taahhüt edilen bağlantı hızı ile gerçekleşen hız bilgilerinin, adil kullanım noktası uygulamasının ve hizmet kalitesi parametrelerinin abonelere doğru ve güncel biçimde duyurulmasını esas alır.

Bu, ölçüm altyapısı kuran taraf için şu anlama gelir: üretilen verinin yöntemi belgelenmiş, tekrar edilebilir ve arşivlenebilir olması gerekir. Bir rapor ancak hangi sunucuya, hangi protokolle, hangi pencere boyutuyla, hangi saatte ve hangi konumda ölçüm yapıldığı yazılıysa savunulabilir.

Pratik öneri: her ölçüm kaydında sunucu kimliği, test dosyası boyutu, protokol, paralel akış sayısı, pencere boyutu, istemci konumu, zaman damgası ve ham sonuçlar birlikte saklansın. Toplu istatistik üretmek kolaydır; sonradan eksik meta veriyi geri kazanmak imkânsızdır.

Ölçüm düğümü kurarken yapılan 7 hata

• Varsayılan TCP ayarlarıyla yüksek hız ölçmek: Pencere boyutu BDP'nin altındaysa sonuç hattı değil, tamponu ölçer.
• Tek akışla gigabit test etmek: Uzun RTT'li yollarda tek akış hattı dolduramaz; paralel akış kullanın.
• Sunucu yükünü kaydetmemek: Ölçüm anında sunucu doluysa sonuç şebekeyi değil, sunucuyu yansıtır.
• Yurt dışı düğümle yurt içi erişim ağı ölçmek: Sonuca transit ve uluslararası kapasite karışır.
• Kotalı hat kullanmak: Sürekli ölçüm yapan bir düğüm aylık kotayı hızla tüketir ve ay sonunda ölçüm bozulur.
• Meta veri tutmadan rapor üretmek: Yöntemi yazılı olmayan bir sonuç itiraz karşısında savunulamaz.
• Tek bir aracı mutlak doğru saymak: Ookla, ndt7 ve iperf3 farklı şeyleri farklı biçimde ölçer; çelişki hata değil, yöntem farkıdır.

Nubitro test ve ölçüm sunucuları

Nubitro, telekomünikasyon ve ölçüm firmalarının ihtiyaç duyduğu profile göre yapılandırılmış sunucular sunar: Türkiye / İstanbul lokasyonu, 1 Gbps sınırsız trafik, NVMe M.2 SSD disk ve AMD Ryzen 9 9950X işlemciler. Kaynaklar fiziksel bölümlendirme ile tanımlandığından ölçüm anında komşu yoğunluğuna bağlı dalgalanma yaşanmaz — bu, ölçüm sunucusunda en kritik özelliktir.

Yapılandırmalar 2 çekirdek / 4 GB RAM seviyesinden 12 çekirdek / 64 GB RAM / 180 GB NVMe'ye kadar ölçeklenir. Daha yüksek kapasite, özel port hızı veya birden fazla IP gerektiren kurulumlar için fiziksel sunucu seçenekleri değerlendirilebilir.

Ölçüm altyapınızı planlarken kaynak ve lokasyon seçimi için VDS satın alma rehberimiz, sunucuyu teslim aldıktan sonra yapılandırma için yeni sunucu güvenliği kontrol listemiz yol gösterir. Bu alandaki tüm yazılarımıza test ve ölçüm sunucuları kategorisinden ulaşabilirsiniz.

Sıkça Sorulan Sorular

Ölçüm sunucusu için kaç Gbps port gerekir?

Ölçmek istediğiniz azami abone hızının en az iki katını hedefleyin. 1 Gbps abone hızlarını doğrulamak için 1 Gbps port sınırda kalır; eşzamanlı birden fazla test yapılacaksa yetersizdir. Ayrıca aylık kota değil, sınırsız trafik tercih edin.

Neden tek akışlı test hattı dolduramıyor?

Tek bir TCP akışının hızı pencere boyutu bölü RTT ile sınırlıdır. Pencere BDP'nin altındaysa akış, onay bekleyerek zaman kaybeder. Çözüm ya pencereyi BDP'ye çıkarmak ya da paralel akış kullanmaktır.

Ookla düğümü ile iperf3 sonuçları neden farklı çıkıyor?

Farklı şeyleri ölçüyorlar. Ookla çoklu bağlantıyla uygulama katmanı deneyimini, iperf3 ise sizin belirlediğiniz parametrelerle ham aktarım kapasitesini ölçer. Aradaki fark hata değil, yöntem farkıdır; raporlarda hangi aracın kullanıldığı mutlaka belirtilmelidir.

Ölçüm sunucusunda sanallaştırma sorun çıkarır mı?

Kaynak paylaşımlı bir sanal sunucuda evet — ölçüm anında komşu yükü sonucu bozar. Kaynakların rezerve edildiği bir yapılandırmada sorun olmaz. Sunucunun gerçekten ithaflı kaynakla çalıştığını top çıktısındaki %st (steal time) değerinin sıfıra yakın olmasından anlarsınız.

Test dosyası ne kadar büyük olmalı?

Aktarımın TCP'nin yavaş başlangıç aşamasını geçip dengeye ulaşmasına yetecek kadar. Yüksek hızlı bağlantılarda küçük dosyalar yalnızca yavaş başlangıcı ölçer ve gerçek kapasiteyi olduğundan düşük gösterir. Süre bazlı test yapmak da (örneğin 30 saniye) tercih edilebilir bir yaklaşımdır.

Ölçüm sonuçlarını ne kadar süre saklamalıyım?

Raporlama yükümlülüğünüz ve müşteri sözleşmeniz ne gerektiriyorsa en az o kadar; pratikte ham veriyi meta verisiyle birlikte saklamak, sonradan gelen itirazlarda tek savunmanızdır. Saklama süresi ve kişisel veri boyutu için hukuk danışmanınıza başvurun.

Özet

• Ölçüm sonucu, istemci ile sunucu arasındaki en zayıf halkayı gösterir; düğümün konumu sonucun kendisidir.
• Hız testi tek sayı üretir ama throughput, RTT, jitter ve paket kaybı ayrı ayrı değerlendirilmelidir.
• RFC 6349 üç ek metrik tanımlar: Transfer Time Ratio, TCP Efficiency ve Buffer Delay.
• Soket tamponları BDP'ye eşit veya ondan büyük olmalıdır.
• 100 Mbps / 5 ms bir yolda 16 KB pencere yalnızca 25,6 Mbps verir.
• 1 Gbps / 100 ms için ~12,5 MB, 10 Gbps / 100 ms için ~125 MB pencere gerekir.
• Paralel akış hem çözümdür hem teşhis aracıdır.
• Türkiye'de 5 aktif IXP ve 95 üye var; ağların %64'ü doğrudan veya dolaylı olarak IXP'ye bağlı.
• Ölçüm sunucusunda shaping olmamalı ve trafik kotasız olmalıdır.
• Ölçüm anındaki sunucu yükü kaydedilmezse sonuç savunulamaz.
• Her ölçümün meta verisi ham sonuçla birlikte arşivlenmelidir.