Perjuangan untuk milidetik. Cara memilih server dengan ping paling tidak

Untuk banyak tugas, penundaan antara klien dan server sangat penting, misalnya, dalam game online, konferensi video / suara, IP telephony, VPN, dll. Jika server terlalu jauh dari klien di tingkat jaringan IP, maka penundaan (dikenal sebagai "ping", "lag") akan mengganggu pekerjaan.

Kedekatan geografis server tidak selalu sama dengan kedekatan pada tingkat IP routing. Jadi, misalnya, server di negara lain mungkin "lebih dekat" dengan Anda daripada server di kota Anda. Semua karena fitur routing dan jaringan. Bagaimana memilih server sedekat mungkin dengan semua pelanggan potensial? Apa itu konektivitas jaringan IP? Bagaimana cara mengarahkan klien ke server terdekat? Mari kita simak artikelnya.





Kami mengukur keterlambatan


Pertama, pelajari cara mengukur latensi. Tugas ini tidak sesederhana kelihatannya, karena untuk protokol dan ukuran paket yang berbeda, penundaan dapat bervariasi. Anda juga tidak dapat melihat fenomena jangka pendek, seperti kegagalan yang berlangsung beberapa milidetik.

ICMP - ping biasa


Kami akan menggunakan utilitas ping Unix, memungkinkan Anda untuk secara manual mengatur interval antar paket, yang tidak diketahui versi ping untuk windows. Ini penting, karena jika jeda antar paket panjang, Anda tidak bisa melihat apa yang terjadi di antara keduanya.

Ukuran paket (opsi -s) - secara default, ping mengirim paket ukuran 64 byte. Dengan paket kecil seperti itu, fenomena yang terjadi pada paket besar mungkin tidak terlihat, jadi kami akan mengatur ukuran paket menjadi 1.300 byte.

Interval antar paket (opsi -i) - waktu antara pengiriman data. Secara default, paket dikirim sekali per detik, butuh waktu yang sangat lama, program nyata mengirim ratusan dan ribuan paket per detik, jadi kami menetapkan interval ke 0,1 detik. Program ini tidak memungkinkan lebih sedikit.

Akibatnya, perintahnya terlihat seperti ini:

ping -s 1300 -i 0.1 yandex.ru

Desain ini memungkinkan Anda untuk melihat gambaran penundaan yang lebih realistis.

Ping melalui UDP dan TCP


Dalam beberapa kasus, koneksi TCP tidak ditangani dengan cara yang sama seperti paket ICMP, dan karena itu, pengukuran dapat berbeda tergantung pada protokol. Ini juga sering terjadi bahwa tuan rumah tidak menanggapi ICMP, dan ping reguler tidak berfungsi. Jadi, misalnya, host microsoft.com membuat seumur hidup .

Utilitas nping dari pengembang pemindai nmap yang terkenal dapat menghasilkan paket apa pun. Ini juga dapat digunakan untuk mengukur keterlambatan.
Karena UDP dan TCP bekerja pada yang spesifik, kita perlu "melakukan ping" ke port tertentu. Mari kita coba ping TCP 80, yaitu port server web:

$ 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

Secara default, nping mengirim 4 paket dan berhenti. Opsi -c 0 memungkinkan pengiriman paket tanpa batas. Untuk menghentikan program, tekan Ctrl + C. Pada akhirnya, statistik akan ditampilkan. Kami melihat bahwa rata-rata rtt (waktu perjalanan) adalah 101ms.

MTR - traceroute pada steroid


Program MTR (English My Traceroute) adalah utilitas canggih untuk melacak rute ke host jarak jauh. Tidak seperti traceroute utilitas sistem biasa (di windows itu adalah utilitas tracert), ia dapat menunjukkan penundaan ke setiap host dalam rantai paket. Juga tahu cara melacak rute tidak hanya melalui ICMP, tetapi juga melalui UDP dan TCP.

$ sudo mtr microsoft.com


(Dapat diklik) Antarmuka program MTR. Pelacakan rute telah dimulai ke microsoft.com

MTR segera menunjukkan ping ke setiap host di rantai, apalagi, data terus diperbarui saat program sedang berjalan dan Anda dapat melihat perubahan jangka pendek.
Tangkapan layar menunjukkan bahwa ada kehilangan paket pada node No.6, tetapi pada kenyataannya ini tidak sepenuhnya benar, karena beberapa router dapat dengan mudah menjatuhkan paket dengan TTL kedaluwarsa dan tidak mengembalikan respons kesalahan, sehingga data tentang kehilangan paket dapat diabaikan di sini.

WiFi vs kabel



Topik ini tidak sepenuhnya relevan dengan artikel, tetapi menurut saya itu sangat penting dalam konteks penundaan. Saya sangat suka WiFi, tetapi jika saya memiliki kesempatan sekecil apa pun untuk menghubungkan kabel ke Internet, saya akan menggunakannya. Juga, saya selalu mencegah orang menggunakan kamera WiFi.
Jika Anda memainkan penembak online serius, menyiarkan streaming video, berdagang di bursa: silakan gunakan Internet melalui kabel.

Berikut ini adalah tes visual untuk membandingkan konektivitas WiFi dan kabel. Ini ping ke router WiFi, yaitu, bahkan tidak ke Internet. (Dapat diklik) Perbandingan ping ke router WiFi melalui kabel dan WiFi Dapat dilihat bahwa penundaan WiFi lebih lama 1ms dan terkadang ada paket dengan penundaan sepuluh kali lebih lama! Dan ini hanya periode waktu yang singkat. Dalam hal ini, router yang sama menghasilkan penundaan yang stabil <1ms.

gambar




Pada contoh di atas, WiFi 802.11n pada 2.4GHz digunakan, hanya laptop dan telepon yang terhubung ke titik akses melalui WiFi. Jika ada lebih banyak pelanggan di titik akses, hasilnya akan jauh lebih buruk. Itu sebabnya saya sangat menentang transfer semua komputer kantor ke WiFi, jika ada kesempatan untuk menjangkau mereka dengan kabel.

Konektivitas IP


Jadi, kami mempelajari cara mengukur keterlambatan ke server, coba temukan server terdekat dengan kami. Untuk melakukan ini, kita dapat melihat bagaimana perutean penyedia kami diatur. Untuk ini, lebih mudah menggunakan layanan bgp.he.net



Saat memasuki situs, kami melihat bahwa alamat IP kami milik sistem otonom AS42610 .

Melihat grafik konektivitas sistem otonom, kita dapat melihat melalui penyedia unggul mana penyedia kami terhubung ke seluruh dunia. Masing-masing poin dapat diklik, Anda dapat masuk dan membaca penyedia apa itu.


Grafik konektivitas penyedia

Dengan menggunakan alat ini, Anda dapat mempelajari cara mengatur saluran dari penyedia mana pun, termasuk hosting. Lihat penyedia yang terhubung langsung dengannya. Untuk melakukan ini, arahkan IP server ke pencarian bgp.he.net dan lihat grafik sistem otonomnya. Anda juga dapat memahami bagaimana satu pusat data atau penyedia hosting terkait dengan yang lain.

Sebagian besar titik pertukaran lalu lintas menyediakan alat khusus yang disebut mencari kaca, yang memungkinkan Anda untuk melakukan ping dan traceroute dari router tertentu pada titik pertukaran.

Misalnya, mencari kaca dari MGTS

Jadi, memilih server, kita dapat melihat di muka bagaimana itu akan terlihat dari berbagai titik pertukaran lalu lintas. Dan jika pelanggan potensial kami berada di area geografis tertentu, kami dapat menemukan lokasi yang optimal untuk server.

Pilih server terdekat


Kami memutuskan untuk menyederhanakan proses menemukan server yang optimal untuk pelanggan kami dan membuat halaman dengan tes otomatis dari lokasi terdekat: pusat data RUVDS .
Saat Anda memasuki halaman, skrip mengukur penundaan dari browser Anda ke setiap server dan menampilkannya pada peta interaktif. Ketika Anda mengklik pada pusat data, informasi dengan hasil tes ditampilkan. Tombol ini mengarah ke halaman uji keterlambatan ke semua pusat data kami. Untuk melihat hasil tes, klik pada titik pusat data di peta








All Articles