Bagaimana saya bisa merumuskan latensi komunikasi dalam TCP / IP?


12

Saya mengalami kesulitan dalam menurunkan model / persamaan matematika untuk memperkirakan latensi pulang pergi antara dua node yang berkomunikasi menggunakan TCP / IP. Node bertukar data berdasarkan protokol HTTP. Dalam model ini, faktor yang paling penting untuk dipelajari adalah jarak fisik antara dua node dalam jaringan, jumlah hop antara, bandwidth, keterlambatan pemrosesan pada setiap hop. Saya mencari di web tetapi tidak dapat menemukan apa pun dalam pengertian ini, melainkan menemukan sesuatu tentang jaringan circuit switching dan protokol UDP. Bisakah saya menyesuaikannya agar sesuai dengan TCP?


Ini adalah target yang bergerak dan ada banyak dependensi yang akan mengubah konstanta model Anda. Misalnya, jika Anda ingin menyertakan penundaan penerusan per hop, maka sebagai baseline, Anda harus mengetahui merek dan model masing-masing perangkat yang ada. Jika Anda tidak mengontrol atau mengetahui setiap perangkat di jalur, seperti melalui internet atau jaringan lain, maka ini hampir mustahil untuk dipertimbangkan. Jika Anda berasumsi bahwa Anda tahu segalanya tentang setiap lompatan di lintasan, maka Anda dapat menerapkan penundaan penerusan garis dasar, misalnya 1,2 mikrodetik untuk model sakelar "A" dan 5,0 untuk model sakelar "B" dan seterusnya.
netdad

1
+1 di sini juga !, Anda harus memberi tanda pada SO untuk menghapus pertanyaan Anda sekarang, duplikatnya
Grijesh Chauhan

kode sumber httpinghttping -Gbg www.google.com -c 5
:,

@Espanta, apakah tujuan Anda untuk memperkirakan latensi atau throughput saja? Throughput sangat tergantung pada fitur TCP seperti SACK, RWIN, chattiness protokol aplikasi, dan, tentu saja, latensi.
generalnetworkerror

@generalnetworkerror, saya perlu latensi pulang-pergi untuk mendapatkan dan mengirim permintaan dan tanggapan http.
Espanta

Jawaban:


8

Ini adalah proses yang sangat rumit, sehingga untuk merumuskan persamaan yang dapat berguna untuk memprediksi RTT secara akurat sangat sulit. Paling-paling, saya akan mengatakan Anda dapat membuat model yang menggunakan banyak rata-rata untuk setiap tahap, yang dapat Anda atur jika Anda kebetulan "tahu lebih baik" untuk situasi tertentu adalah sedekat mungkin. Ini adalah sesuatu yang saya pelajari saat ini sehingga saya dapat memberi tahu Anda apa yang saya ketahui sejauh ini (dari bawah ke atas, mulai dari lapisan fisik):

  • Lihat pertanyaan saya di Electronics SE; Pengkodean keterlambatan Ethernet dan hubungannya dengan peringkat frekuensi kabel dan Kecepatan listrik (perambatan sinyal?) Melalui tembaga untuk keterlambatan komunikasi . Karena Anda akan menggunakan kecepatan standar (100Mbps, 1Gbps, 10Gbps dll), jangan memperlakukan serat atau tembaga secara berbeda. "Penundaan" pada keduanya hampir sama, tetapi tembaga tidak dapat membawa sinyal sejauh yang jelas. Saya memiliki pertanyaan ini di situs Fisika SE, yang saya tahu jawabannya sekarang. Saya hanya perlu mencari waktu untuk memperbaikinya, jadi perhatikan bahwa jika Anda tertarik (saya akan memposting beberapa pertanyaan terkait penggunaan telekomunikasi yang sekarang saya tahu jawabannya ketika saya mendapat kesempatan) ).

  • Lebih banyak penundaan akan ditambahkan oleh perangkat di akhir tautan. Tidak ada cara standar untuk mengatakan "oh 2 switch di sepanjang jalan adalah penundaan Xms, 4 switch adalah 2 * Xms, 2 router adalah Yms ... dll". Dengan asumsi Anda menggunakan katakanlah 1Gpbs misalnya dan perangkat di jalur maju pada tingkat garis, kita tahu itu adalah 1000000000bps, sehingga antarmuka fisik berjalan pada tingkat pengkodean tetap (mulai dari 1 nanodetik per bit hingga apa pun maks skema pengkodean simbol yang digunakan adalah, seperti 10b )

  • Ada tiga jenis keterlambatan utama (pada lapisan fisik) yang perlu Anda perhatikan dan faktorkan; Keterlambatan serialisasi, keterlambatan pengkodean, keterlambatan propagasi (dan keterlambatan pemrosesan, keterlambatan antrian, keterlambatan penyandian dan dekode, tetapi ini berada di atas lapisan fisik tetapi perlu disebutkan!). Ini cukup didokumentasikan dengan baik di Internet, VoIP: Analisis Mendalam , Slide 13 di sini , memuat di Google Cendekia , dan banyak lagi.

  • Ketika kita naik stack protokol, saya akan bekerja dengan asumsi bahwa MAC tujuan di setiap switch cam table, dan pada layer IP, MAC tujuan di tabel ARP. Penundaan tambahan yang disebabkan oleh proses penemuan ini hanya terjadi untuk paket pertama dalam aliran sehingga mereka dapat dielakkan dengan menaikkan batas waktu dan mengirimkan ARP gratis.

  • Ketika Anda masuk ke lapisan aplikasi, ini akan menjadi sangat sulit karena ini tergantung pada server (misalnya) yang memproses permintaan, yang akan dikenakan penundaan interupsi. Jumlah interupsi yang diperlukan untuk memproses permintaan dan konteks beralih karena memuat tidak dapat diprediksi.

Saya sangat ingin membantu Anda dengan pertanyaan Anda, sayangnya ini semua yang saya punya waktu untuk saat ini. Saya akan memperbarui jawaban ini mungkin nanti malam atau besok, saya ingin memposting apa yang saya miliki sejauh ini.

Sementara itu, kebanyakan orang cenderung bekerja dengan angka untuk keterlambatan pada lapisan tembaga / serat fisik sekitar 0,6 * c (C = kecepatan cahaya). Juga, Anda perlu berpikir tentang pertukaran TCP dari ACK setiap paket X, yang berbeda jika Anda menggunakan SACK misalnya, dan jika Anda menggunakan frame jumbo dan / atau ukuran MSS yang lebih besar (sekarang MTU juga harus diperhitungkan!) , jika Anda mengirim lebih banyak di antara ACK (jika volume data yang ditransfer menarik bagi Anda). Anda juga perlu mempertimbangkan Produk Penundaan Bandwidth yang terkenal dan jangan membuat kesalahan interpretasi bodoh yang saya lakukan pada halaman itu. Saya mulai membuat berbagai kalkulator data sederhana (dan sangat jelek) di sini. Lagi pekerjaan yang sedang berjalan saya akan mencoba dan memperbaruinya segera. Saya berencana untuk menambahkan kalkulator yang mirip dengan apa yang Anda coba lakukan. Saya juga telah membuat beberapa kalkulator ringan dan serat jika Anda tertarik, tetapi sekali lagi, tidak ada waktu !, saya belum sempat mengunggahnya. Saya akan mencoba secepatnya untuk memperbarui jawaban ini lagi, dalam beberapa hari mendatang.

PS Saya lupa menyebutkan QoS! Jika QoS sedang bermain di mana saja di jalur, akan menjadi sangat sulit untuk menghitung RTT!


Terima kasih. Itu detail yang cukup bagus. Saya perlu menekankan bahwa jumlah lompatan antara dua node memiliki dampak tinggi pada jarak fisik antara dua node dalam jaringan kabel. (Setidaknya sejak tolok ukur saya yang sebenarnya menunjukkan hal itu.) Jadi, saya akan mengumpulkan semuanya dan segera datang dengan model saya. banyak terima kasih dari semua orang yang membaca, meningkatkan, menjawab, dan akan menjawab.
Espanta

Telekomunikasi-menggunakan-serat (dengan asumsi bahwa OP tidak berurusan dengan penundaan hanya dalam Pusat Data, atau beberapa pengaturan di mana ia memiliki kontrol penuh atas infrastruktur fisik) dapat menjadi menarik dan membuat pemodelan hampir tidak mungkin. Anekdot untuk menyoroti masalah. Saya pernah memiliki T-1 Louisville, KY <-> Lexington, KY dan Louisville, KY <-> Cincinnati, OH gagal. Menyebut perusahaan telekomunikasi dan mereka memberi tahu saya bahwa pemotongan serat di Illinois barat adalah penyebabnya. Lihatlah peta dan lihat mengapa itu gila. Namun, bandwidth yang lebih tinggi cenderung menjadi mangsa dari kegilaan telekomunikasi ini.
Jeff McAdams

5

(Saya ingin menunjukkan bahwa orang lain telah memposting jawaban yang sangat baik tentang bagaimana penundaan bekerja dan apa yang menyebabkannya. Tetapi OP bertanya tentang pemodelan; Model dasar sederhana dan Anda cukup memasukkan nomor contoh. Jika Anda ingin tahu mengapa penundaan adalah apa adanya, kemudian lihat jawaban orang lain: ^)

Latensi jaringan hanyalah waktu transit dari satu titik ujung ke titik ujung lainnya, mencakup N hop antara .

Jadi, Anda memiliki segmen N (hop) dengan N-1 node menengah. Setiap node memiliki penundaan (efek kumulatif dari beberapa hal pada simpul itu, seperti penundaan antrian, penundaan pemrosesan, dll), dan setiap segmen memiliki penundaan transit. Secara keseluruhan itu 2N - 1 variabel independen. Jadi seg1 + node1 + seg2 ... + node (N-1) + segN Satu hop, hanya = seg1, dua harapan adalah seg1 + node1 + seg2, dll.

Selanjutnya Anda harus mendefinisikan apa semua potongan itu. Jadi Anda dapat membangun jaringan model dengan jaringan CATV, tautan satelit, tautan serat optik, ethernet, dll. Untuk masing-masing teknologi tersebut, Anda harus mencari informasi contoh.

Keterlambatan transit akan menjadi sekitar ukuran data dibagi dengan kecepatan transmisi segmen. Jika Anda membutuhkan model yang lebih akurat, Anda harus menambahkan jeda waktu penerbangan - kira-kira panjang segmen, dibagi dengan kecepatan aliran data (perkiraan kecepatan cahaya). Ini TIDAK PENTING jika Anda memiliki tautan satelit; Naik-turunnya ke satelit geosynchronous sangat penting.

Penundaan pada setiap simpul yang harus Anda perkirakan berdasarkan pada peralatan apa yang Anda tempatkan dalam model Anda.

Jika Anda menginginkan latensi aplikasi, (misalnya penundaan hingga dimulainya aliran data transfer FTP), Anda membangun dengan menghitung berapa kali latensi jaringan Anda ikut bermain. Misalnya, jabat tangan TCP 3-arah menambah triple-the latency jaringan, dan seterusnya membangun apa yang dilihat aplikasi.


3

Anda dapat memperkirakan latensi bolak-balik dengan mengambil tangkapan paket di kedua sisi, lalu mengukur penundaan antara permintaan yang keluar dari mesin yang dipantau dan respons yang datang kembali. Misalnya, jika Anda menandai waktu SYN pergi ke mesin jarak jauh, lalu menandai waktu respons SYN + ACK masuk, perbedaannya akan memberi Anda rata-rata yang cukup bagus untuk latensi tolak-balik TCP round trip.

Perlu diingat bahwa ini akan lebih besar daripada latensi jaringan yang sebenarnya, dan seberapa besar tergantung pada seberapa banyak mesin yang dimuat.


terima kasih atas jawaban Anda, tetapi saya tidak ingin mengukurnya menggunakan pengkodean atau interpretasi mesin apa pun, saya perlu merumuskannya menggunakan model matematika. Misalnya sesuatu seperti: Total Delay = total propagasi + total transmisi + total toko & maju + total pemrosesan. Dan untuk setiap pengaturan waktu ini, saya dapat memiliki formula lain. Jadi bisa diukur secara matematis.
Espanta

3

Penundaan antara dua host akan tergantung pada beberapa faktor:

  • Penundaan propagasi
  • Penundaan serialisasi
  • Keterlambatan antrian / buffering

Keterlambatan propagasi adalah berapa lama waktu yang diperlukan secara fisik untuk paket untuk melakukan perjalanan antara dua lokasi. Kecepatan cahaya dalam serat adalah sekitar 200000 km / s. Swedia tempat saya tinggal sekitar 1570 km sehingga akan menjadi 7,85 ms tetapi pada kenyataannya itu lebih karena itu adalah jarak melalui tampilan burung.

Penundaan serialisasi adalah berapa banyak waktu yang diperlukan untuk melakukan seralize paket melalui media fisik, yaitu antarmuka pada perangkat jaringan. Jika Anda memiliki koneksi 2 Mbit dan Anda mengirim paket 1500 byte, itu akan menjadi 6 ms untuk membuat serialisasi paket tersebut (12000/2000000).

Keterlambatan antrian / buffering adalah berapa banyak waktu paket harus tetap dalam antrian / buffer sebelum dikirim pada antarmuka. Tergantung pada kecepatan pada antarmuka dan seberapa besar buffer yang digunakan, ini bisa menjadi tidak ada apa-apa atau penundaan yang signifikan.

Kemudian akan ada beberapa penundaan pada host untuk menghasilkan paket dan untuk aplikasi untuk menanganinya. Ada aplikasi untuk mengukur keterlambatan HTTP. Orang tidak menerima banyak keterlambatan di situs web sebelum menyerah, jadi itu adalah faktor penting.


bagaimana dengan jumlah hop? dan keterlambatan di setiap hop?
Espanta

Sulit untuk membuat formula umum karena beberapa faktor bervariasi seperti serialisasi dan antrian. Ini seseorang yang menulis tentang itu. ccieflyer.com/pdf/2009-Mar-Oleg-Berzin.pdf - Matematika itu di luar kemampuan matematika saya :) :)
Daniel Dib
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.