Çoğu görev için, istemci ile sunucu arasındaki gecikmeler kritik öneme sahiptir; örneğin çevrimiçi oyunlar, video/sesli konferans, IP telefonu, VPN vb. gibi durumlarda. Sunucu, IP ağı düzeyinde istemciden çok uzaktaysa, gecikmeler (halk arasında "ping", "gecikme" olarak adlandırılır) çalışmayı engelleyecektir.
Bir sunucunun coğrafi yakınlığı her zaman IP yönlendirme düzeyinde yakınlığa eşit değildir. Yani örneğin başka bir ülkedeki bir sunucu size şehrinizdeki bir sunucudan “daha yakın” olabilir. Hepsi yönlendirme ve ağ yapısının özelliklerinden kaynaklanmaktadır.
Tüm potansiyel müşterilere mümkün olduğunca yakın bir sunucu nasıl seçilir? IP ağ bağlantısı nedir? Bir istemciyi en yakın sunucuya nasıl yönlendiririm? Makalede öğrenelim.
Gecikmelerin ölçülmesi
Öncelikle gecikmeleri nasıl ölçeceğimizi öğrenelim. Bu görev göründüğü kadar basit değildir çünkü gecikmeler farklı protokollere ve paket boyutlarına göre değişiklik gösterebilir. Ayrıca birkaç milisaniye süren düşüşler gibi kısa vadeli olayları da kaçırabilirsiniz.
ICMP - düzenli ping
Unix ping yardımcı programını kullanacağız; Windows için ping sürümünün yapamadığı paket gönderme arasındaki aralıkları manuel olarak ayarlamanıza olanak tanır. Bu önemlidir çünkü paketler arasında uzun duraklamalar varsa aralarında neler olduğunu göremeyebilirsiniz.
Paket Boyutu (seçenek -s) - varsayılan olarak ping yardımcı programı 64 bayt boyutunda paketler gönderir. Bu kadar küçük paketlerde, daha büyük paketlerde meydana gelen olaylar fark edilmeyebilir, bu nedenle paket boyutunu 1300 bayta ayarlayacağız.
Paketler arasındaki aralık (seçenek -i) — veri gönderimleri arasındaki süre. Varsayılan olarak paketler saniyede bir kez gönderilir, bu çok uzun bir süre, gerçek programlar saniyede yüzlerce ve binlerce paket gönderir, bu nedenle aralığı 0.1 saniyeye ayarlayacağız. Program daha azına izin vermiyor.
Sonuç olarak komut şöyle görünür:
ping -s 1300 -i 0.1 yandex.ru
Bu tasarım, gecikmelerin daha gerçekçi bir resmini görmenizi sağlar.
UDP ve TCP aracılığıyla pingleme
Bazı durumlarda TCP bağlantıları ICMP paketlerinden farklı işlenir ve bu nedenle ölçümler protokole bağlı olarak değişiklik gösterebilir. Ayrıca, ana bilgisayarın ICMP'ye yanıt vermemesi ve normal ping'in çalışmaması da sıklıkla görülür. Örneğin bir ev sahibinin hayatı boyunca yaptığı şey budur. microsoft.com.
Yarar Ünlü tarayıcının geliştiricilerinden nmap herhangi bir paket oluşturabilir. Gecikmeleri ölçmek için de kullanılabilir.
UDP ve TCP belirli bağlantı noktaları üzerinde çalıştığından, belirli bir bağlantı noktasına "ping" atmamız gerekir. TCP 80'e yani web sunucusu bağlantı noktasına ping atmayı deneyelim:
$ sudo nping --tcp -p 80 --delay 0.1 -c 0 microsoft.com
Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2020-04-30 13:07 MSK
SENT (0.0078s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
SENT (0.1099s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.2068s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44 seq=1480267007 win=64240 <mss 1440>
SENT (0.2107s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.3046s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=43 id=0 iplen=44 seq=1480267007 win=64240 <mss 1440>
SENT (0.3122s) TCP 10.0.0.1:63236 > 13.77.161.179:80 S ttl=64 id=49156 iplen=40 seq=3401731188 win=1480
RCVD (0.4247s) TCP 13.77.161.179:80 > 10.0.0.1:63236 SA ttl=42 id=0 iplen=44 seq=2876862274 win=64240 <mss 1398>
Max rtt: 112.572ms | Min rtt: 93.866ms | Avg rtt: 101.093ms
Raw packets sent: 4 (160B) | Rcvd: 3 (132B) | Lost: 1 (25.00%)
Nping done: 1 IP address pinged in 0.43 seconds
Varsayılan olarak nping 4 paket gönderir ve durur. Seçenek -c0 sonsuz sayıda paket gönderilmesini sağlar; programı durdurmak için Ctrl+C tuşlarına basmanız gerekir. İstatistikler sonunda gösterilecektir. Ortalama rtt (gidiş-dönüş süresi) değerinin 101ms olduğunu görüyoruz.
MTR - steroidlerde traceroute
Program My Traceroute, uzak bir ana bilgisayara giden yolları izlemeye yönelik gelişmiş bir yardımcı programdır. Alışılmış sistem yardımcı programı traceroute'un aksine (Windows'ta bu, tracert yardımcı programıdır), paket zincirindeki her ana bilgisayara gecikmeleri gösterebilir. Ayrıca rotaları yalnızca ICMP üzerinden değil aynı zamanda UDP ve TCP üzerinden de izleyebilir.
$ sudo mtr microsoft.com
(Tıklanabilir) MTR program arayüzü. Microsoft.com'a rota takibi başlatıldı
MTR, zincirdeki her bir ana bilgisayara ping'i anında gösterir ve program çalışırken veriler sürekli güncellenir ve kısa süreli değişiklikler görülebilir.
Ekran görüntüsü, 6 numaralı düğümün paket kayıplarına sahip olduğunu gösteriyor, ancak aslında bu tamamen doğru değil, çünkü bazı yönlendiriciler, süresi dolmuş bir TTL'ye sahip paketleri basitçe atabilir ve bir hata yanıtı döndürmeyebilir, dolayısıyla paket kaybı verileri burada göz ardı edilebilir.
WiFi vs kablo
Bu konu tamamen yazıyla alakalı değil ama bence gecikmeler bağlamında çok önemli. WiFi'yi gerçekten çok seviyorum ama internete kabloyla bağlanmak için en ufak bir fırsatım olsa bile kullanacağım. Ayrıca insanları her zaman WiFi kameraları kullanmaktan caydırırım.
Ciddi çevrimiçi nişancı oyunları oynuyorsanız, video akışı yapıyorsanız veya borsada işlem yapıyorsanız: lütfen interneti kablolu olarak kullanın.
İşte WiFi ve kablo bağlantılarını karşılaştırmak için görsel bir test. Bu, WiFi yönlendiricisine, yani henüz İnternet'e bile bir ping değil.
(Tıklanabilir) Kablo ve WiFi aracılığıyla bir WiFi yönlendiriciye ping karşılaştırması
WiFi üzerinden gecikmenin 1 ms daha uzun olduğu ve bazen on kat daha uzun gecikmeli paketlerin olduğu görülebilir! Ve bu sadece kısa bir süre. Aynı zamanda, aynı yönlendirici <1 ms'lik kararlı gecikmeler üretir.
Yukarıdaki örnekte 802.11GHz'de WiFi 2.4n kullanılıyor, WiFi erişim noktasına yalnızca bir dizüstü bilgisayar ve bir telefon bağlı. Erişim noktasında daha fazla istemci olsaydı sonuçlar çok daha kötü olurdu. Bu yüzden tüm ofis bilgisayarlarına kabloyla ulaşmak mümkünse WiFi'ye geçilmesine karşıyım.
IP bağlantısı
Böylece sunucuya gelen gecikmeleri ölçmeyi öğrendik, hadi bize en yakın sunucuyu bulmaya çalışalım. Bunu yapmak için sağlayıcımızın yönlendirmesinin nasıl çalıştığına bakabiliriz. Bunun için hizmeti kullanmak uygundur
Siteye girdiğimizde IP adresimizin otonom sisteme ait olduğunu görüyoruz. .
Otonom sistemlerin bağlantı grafiğine bakarak sağlayıcımızın dünyanın geri kalanına hangi üst düzey sağlayıcılar aracılığıyla bağlandığını görebiliriz. Noktaların her biri tıklanabilir, içeri girip ne tür bir sağlayıcı olduğunu okuyabilirsiniz.
Sağlayıcının otonom sistemlerinin bağlantı grafiği
Bu aracı kullanarak barındırma dahil herhangi bir sağlayıcının kanallarının nasıl yapılandırıldığını inceleyebilirsiniz. Hangi sağlayıcılara doğrudan bağlı olduğunu görün. Bunu yapmak için bgp.he.net aramasına sunucunun IP adresini girmeniz ve otonom sisteminin grafiğine bakmanız gerekir. Ayrıca bir veri merkezinin veya barındırma sağlayıcısının diğerine nasıl bağlandığını da anlayabilirsiniz.
Çoğu trafik değişim noktası, değişim noktasında belirli bir yönlendiriciye ping atmanıza ve yönlendirme yapmanıza olanak tanıyan, ayna adı verilen özel bir araç sağlar.
Burada, örneğin, MGTS'den
Yani bir sunucu seçerken farklı trafik değişim noktalarından nasıl görüneceğini önceden görebiliyoruz. Potansiyel müşterilerimiz belirli bir coğrafi bölgede bulunuyorsa sunucu için en uygun konumu bulabiliriz.
En yakın sunucuyu seçin
Müşterilerimiz için en uygun sunucuyu bulma prosedürünü basitleştirmeye karar verdik ve yakındaki konumların otomatik olarak test edildiği bir sayfa oluşturduk: .
Bir sayfayı ziyaret ettiğinizde, komut dosyası tarayıcınızdan her sunucuya olan gecikmeleri ölçer ve bunları etkileşimli bir haritada görüntüler. Bir veri merkezine tıkladığınızda test sonuçlarını içeren bilgiler görüntülenir.
Düğme sizi tüm veri merkezlerimizin gecikme testi sayfasına götürür. Test sonuçlarını görüntülemek için haritadaki veri merkezi noktasına tıklayın
Kaynak: habr.com