Untuk banyak tugas, kelewatan antara klien dan pelayan adalah kritikal, contohnya dalam permainan dalam talian, persidangan video/suara, telefon IP, VPN, dsb. Jika pelayan terlalu jauh dari klien di peringkat rangkaian IP, maka kelewatan (biasa dipanggil "ping", "lag") akan mengganggu kerja.
Kedekatan geografi pelayan tidak selalu sama dengan kedekatan pada tahap penghalaan IP. Jadi, sebagai contoh, pelayan di negara lain mungkin "lebih dekat" dengan anda daripada pelayan di bandar anda. Semuanya disebabkan oleh keanehan penghalaan dan pembinaan rangkaian.
Bagaimana untuk memilih pelayan yang sedekat mungkin dengan semua bakal pelanggan? Apakah sambungan rangkaian IP? Bagaimana untuk mengarahkan pelanggan ke pelayan terdekat? Mari kita ketahui dalam artikel.
Mengukur kelewatan
Mula-mula, mari kita pelajari cara mengukur kelewatan. Tugas ini tidak semudah yang kelihatan kerana kelewatan mungkin berbeza untuk protokol dan saiz paket yang berbeza. Anda juga mungkin terlepas acara jangka pendek, seperti penurunan yang berlangsung beberapa milisaat.
ICMP - ping biasa
Kami akan menggunakan utiliti ping Unix; ia membolehkan anda menetapkan secara manual selang antara penghantaran paket, yang versi ping untuk Windows tidak boleh lakukan. Ini penting kerana jika terdapat jeda yang lama antara paket, anda mungkin tidak melihat apa yang berlaku di antara paket tersebut.
Saiz bungkusan (pilihan -s) - secara lalai, utiliti ping menghantar paket bersaiz 64 bait. Dengan paket kecil sedemikian, fenomena yang berlaku dengan paket yang lebih besar mungkin tidak dapat dilihat, jadi kami akan menetapkan saiz paket kepada 1300 bait.
Selang antara paket (pilihan -i) β masa antara penghantaran data. Secara lalai, paket dihantar sekali sesaat, ini sangat panjang, program sebenar menghantar ratusan dan ribuan paket sesaat, jadi kami akan menetapkan selang kepada 0.1 saat. Program ini tidak membenarkan kurang.
Akibatnya, arahan kelihatan seperti ini:
ping -s 1300 -i 0.1 yandex.ru
Reka bentuk ini membolehkan anda melihat gambaran kelewatan yang lebih realistik.
Ping melalui UDP dan TCP
Dalam sesetengah kes, sambungan TCP diproses secara berbeza daripada paket ICMP, dan disebabkan ini, pengukuran mungkin berbeza-beza bergantung pada protokol. Ia juga sering berlaku bahawa hos hanya tidak bertindak balas kepada ICMP, dan ping biasa tidak berfungsi. Inilah yang dilakukan oleh tuan rumah sepanjang hidupnya, sebagai contoh. microsoft.com.
Utiliti
Memandangkan UDP dan TCP beroperasi pada yang tertentu, kita perlu "ping" port tertentu. Mari cuba ping TCP 80, iaitu port pelayan 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 lalai, nping menghantar 4 paket dan berhenti. Pilihan -c 0 membolehkan penghantaran paket yang tidak berkesudahan; untuk menghentikan program, anda perlu menekan Ctrl+C. Statistik akan ditunjukkan pada akhir. Kami melihat bahawa nilai purata rtt (masa pergi balik) ialah 101ms.
MTR - traceroute pada steroid
Program
$ sudo mtr microsoft.com
(Boleh Diklik) Antara muka program MTR. Pengesanan laluan ke microsoft.com bermula
MTR serta-merta menunjukkan ping kepada setiap hos dalam rantaian, dan data sentiasa dikemas kini semasa program sedang berjalan dan perubahan jangka pendek dapat dilihat.
Tangkapan skrin menunjukkan bahawa nod #6 mempunyai kehilangan paket, tetapi sebenarnya ini tidak sepenuhnya benar, kerana sesetengah penghala hanya boleh membuang paket dengan TTL tamat tempoh dan tidak mengembalikan respons ralat, jadi data kehilangan paket boleh diabaikan di sini.
WiFi vs kabel
Topik ini tidak sepenuhnya berkaitan dengan artikel itu, tetapi pada pendapat saya ia sangat penting dalam konteks kelewatan. Saya sangat menyukai WiFi, tetapi jika saya mempunyai peluang yang sedikit untuk menyambung ke Internet dengan kabel, saya akan menggunakannya. Saya juga sentiasa tidak menggalakkan orang ramai daripada menggunakan kamera WiFi.
Jika anda bermain penembak dalam talian yang serius, strim video atau berdagang di bursa saham: sila gunakan Internet melalui kabel.
Berikut ialah ujian visual untuk membandingkan sambungan WiFi dan kabel. Ini ialah ping kepada penghala WiFi, iaitu, Internet pun belum lagi.
(Boleh Diklik) Perbandingan ping kepada penghala WiFi melalui kabel dan melalui WiFi
Ia boleh dilihat bahawa melalui WiFi kelewatan adalah 1ms lebih lama dan kadang-kadang terdapat paket dengan kelewatan sepuluh kali lebih lama! Dan ini hanya tempoh masa yang singkat. Pada masa yang sama, penghala yang sama menghasilkan kelewatan yang stabil <1ms.
Dalam contoh di atas, WiFi 802.11n pada 2.4GHz digunakan, hanya komputer riba dan telefon disambungkan ke pusat akses WiFi. Jika terdapat lebih ramai pelanggan pada titik akses, hasilnya akan menjadi lebih teruk. Inilah sebabnya saya sangat menentang menukar semua komputer pejabat kepada WiFi jika boleh menghubungi mereka dengan kabel.
Kesambungan IP
Jadi, kami telah belajar untuk mengukur kelewatan ke pelayan, mari cuba mencari pelayan yang paling dekat dengan kami. Untuk melakukan ini, kami boleh melihat cara penghalaan pembekal kami berfungsi. Ia adalah mudah untuk menggunakan perkhidmatan untuk ini
Apabila kami mengakses tapak, kami melihat bahawa alamat IP kami tergolong dalam sistem autonomi
Dengan melihat graf ketersambungan sistem autonomi, kami dapat melihat melalui penyedia peringkat tinggi yang mana pembekal kami disambungkan ke seluruh dunia. Setiap titik boleh diklik, anda boleh masuk dan membaca jenis pembekal itu.
Graf ketersambungan sistem autonomi pembekal
Menggunakan alat ini, anda boleh mengkaji bagaimana saluran mana-mana pembekal, termasuk pengehosan, distrukturkan. Lihat pembekal yang disambungkan secara langsung. Untuk melakukan ini, anda perlu memasukkan alamat IP pelayan ke dalam carian bgp.he.net dan melihat graf sistem autonominya. Anda juga boleh memahami cara satu pusat data atau penyedia pengehosan disambungkan kepada yang lain.
Kebanyakan titik pertukaran trafik menyediakan alat khas yang dipanggil kaca cari, yang membolehkan anda melakukan ping dan tracerout dari penghala tertentu di titik pertukaran.
Sebagai contoh,
Jadi, apabila memilih pelayan, kita boleh melihat terlebih dahulu bagaimana ia akan kelihatan dari titik pertukaran trafik yang berbeza. Dan jika bakal pelanggan kami terletak di kawasan geografi tertentu, kami boleh mencari lokasi yang optimum untuk pelayan.
Pilih pelayan terdekat
Kami memutuskan untuk memudahkan prosedur mencari pelayan optimum untuk pelanggan kami dan mencipta halaman dengan ujian automatik lokasi berdekatan:
Apabila anda melawat halaman, skrip mengukur kelewatan daripada penyemak imbas anda ke setiap pelayan dan memaparkannya pada peta interaktif. Apabila anda mengklik pada pusat data, maklumat dengan keputusan ujian dipaparkan.
Butang membawa anda ke halaman ujian kependaman untuk semua pusat data kami. Untuk melihat keputusan ujian, klik pada titik pusat data pada peta
Sumber: www.habr.com