Ping vaqtlari qanday hisoblangan

Ping (IPV4) javob vaqti/va boshqalar paket o'lchamlarini grafikalar bilan bezatdim. MTU chegarasi atrofida (aslida, taxminan 1464 bayt, MTU bu segmentda 1492) atrofida javob vaqtida taxminan 2 * MTU/BandWidth ning keskinligini ko'rishni kutmoqdaman. Mening taxminlarimning mantiqiy sababi shundaki, 2 MTU/BW 1 MTU o'lchamli paketning aylanma muddati bo'lib, paketning bo'linishi bu miqdordan ikki marotabalik bosqichlarda aylanish vaqtlarini ko'paytiradi.

Afsuski, bu men ko'rmagan narsa emas. Foydalanish

   # ping -f -c 30 -s $sz my.host

Men paket o'lchami va quyidagi kabi (masalan, hajmi, min avg max, milodiy) o'zaro o'xshashligini ko'rmoqdaman, lekin hech qanday tartibsizliklar mavjud emas:

1159  40.575 41.778 47.200
1220  41.392 42.145 45.420
1281  41.921 43.461 46.974
1342  42.498 43.840 52.638
1403  42.813 44.037 49.272
1464  43.741 45.455 49.795
1525  45.382 50.406 59.891
1586  45.579 55.605 66.309
1647  47.498 53.464 64.518
1708  49.373 73.681 84.820
1769  49.726 80.030 101.057

Shuning uchun men paketlarni jo'natish/yuborishda qandaydir bir narsa bilan urilayapmanmi, yoki agar mening fikrimcha xato yoki boshqacha bo'lsa (va bu holatda bu xato bo'lsa) bilmayman.

Bu 100MB simli Ethernet orqali ketadigan, FGT60 va zixelni kesib o'tadigan internetga ADSL liniyasiga ulanadi, va MTG (1492) hisoboti ham (shuningdek, Ping -M do) hisobot. FC22 linux qutisidan test qilaman. Bilmayman, lekin menimcha, tarmoqning tashqi tafsilotlari muhim emas (ko'p). IQTISODIY Natijada yo'qolishim mumkin, chunki parchalanish mahalliy interfeysdan 1500 MTU belgisidan (ya'ni, Ethernet aloqasi MTU) o'tib ketishidan oldin (kamida)

Edit: And the (hidden) faulty piece of reasoning lies in equating the minimum transmission unit (which for tcpV4 over ethernet would be something around 64 bytes), lets call it the mTU, to the MTU - ie, in assuming that all packets will be padded to the MTU. That not being the case, the discontinuity due to fragmentation should be around mTU/Bw, around 20 times smaller than MTU/Bw and likely to be swallowed by the jitter due to varying network conditions

5
Siz natijalarni e'lon qilyapsiz, lekin siz parametrlarni unutib qo'ydingiz. Sizning savolingizni diagramma va ikkita qurilma o'rtasidagi tarmoqning tavsifi bilan tartibga solishingiz kerak.
qo'shib qo'ydi muallif Ron Maupin, manba
Buni qo'shish uchun savolingizni tahrirlashingiz kerak.
qo'shib qo'ydi muallif Ron Maupin, manba
Bu 100MB simli Ethernet orqali ketadigan, FGT60 va zixelni kesib o'tadigan internetga ADSL liniyasiga ulanadi, va MTG (1492) hisoboti ham (shuningdek, Ping -M do) hisobot. FC22 linux qutisidan test qilaman. Bilmayman, lekin menimcha, tarmoqning tashqi tafsilotlari muhim emas (ko'p). IQTISODIY Natijada yo'qolishim mumkin, chunki parchalanish mahalliy interfeysdan 1500 MTU belgisidan (ya'ni, Ethernet aloqasi MTU) o'tib ketishidan oldin (kamida)
qo'shib qo'ydi muallif CEObrainz, manba

1 javoblar

Nimaga siz parchalanish vaqtni ikki barobarga oshirishini o'ylashingiz mumkinligiga ishonchim komil emas. Agar yo'riqnoma paketni parchalagan bo'lsa, u ikkala parchani ham ketma-ket yuboradi. Boshqa tomondan, uy egasi bo'laklarni olib, ularni qayta to'playdi va javob beradi. Parchalanish vaqtidagi o'sish ko'p jihatdan to'g'ri bo'lishi kerak. Bir yo'riqchining paketni parchalashiga vaqt kerak bo'ladi va qabul qiluvchi kompyuterning parchalarini qayta yig'ish uchun vaqt kerak bo'ladi.

Vaqtni ikki barobarga qisqartirish, javob olish, keyingi qismini yuborish, javob olish va keyin vaqt haqida xabar berish kerak. Bu qanday ishlamaydi.

RFC 793, TRANSMISSION CONTROL PROTOCOL, explains how IP fragmentation works.

Bundan tashqari, ICMP (ping ICMP echo va ICMP echo javobini ishlatadi) ko'pincha Internetdagi muntazam IP-trafikdan farqli ravishda ishlov berishini tushunishingiz kerak. Odatda past ustuvor bo'ladi va odatda muntazam transportning foydasiga navbatga qo'yiladi va bu sodir bo'lgan o'zgaruvchan tiqilishga nisbatan sezgir bo'ladi. Hatto muntazam transport vositalaridan ko'ra boshqa yo'llarni tanlash mumkin. Kechiktirilgan latentlik, kattalashtirish buyrug'iga binoan, qisqartirilish natijasida bo'linib ketishi mumkin. Bu egri tekislash ta'siriga ega bo'lishi mumkin.

Parchalanishni sinab ko'rishning haqiqiy yo'li nazorat qilinmaydigan o'zgaruvchilarni yo'q qilish uchun boshqariladigan muhitda. Ikki xonadon o'rtasidagi nuqta-to-point aloqasi bilan testni boshlang. Keyin, ikkita qurilma o'rtasida boshqariladigan bosqichlarda qurilmalarni (kalitlarni, routerlarni va boshqalarni) qo'shishni boshlang. Sinov muhitini o'zgartirishdan oldin har bir testni bir necha marta bajaring. Internetda tekshiruv sizni kutilmagan natijalarga olib kelishi mumkin, chunki sizda Internet ustidan nazorat yo'q.

3
qo'shib qo'ydi
parchalanish tizim protsessori orqali "sekin yo'l" orqali o'tishi kerak. (Cisco sharoitida, "punted") CPU paketini ishlash jarayoni sekin. Fragmentatsiya zamonaviy tarmoqlarda chekka holatdir, shuning uchun uni odatda asta-sekinlik bilan amalga oshiradi. (fortikatda apparatning yetkazib berilishi, zyxel ehtimoldan yiroq emas). Qabul qilgichda qayta ishlash uchun qo'shimcha ishlov berish kerak.
qo'shib qo'ydi muallif Neall, manba
"Ishonchim komilki, nima uchun siz parchalanish vaqtni ikki barobarga oshirishini o'ylaysiz?" Bu meni xato deb biladi. - Izohga qarang.
qo'shib qo'ydi muallif CEObrainz, manba
(Yashirilgan) noto'g'ri aqlli qism, men MTUga minimal transmissiya blokini (eternet orqali tcp uchun 64 bayt atrofida bo'lishi mumkin) tenglashtiradigan narsa demoqdaman - ya'ni, barcha paketlarni MTU uchun to'ldirish kerak deb o'ylayman. Bunday bo'lmasa, parchalanish natijasida hosil bo'ladigan uzilish mTU/Bw atrofida bo'lishi kerak, atrofida MTU/Bw dan 20 barobar kichik bo'lishi va o'zgaruvchan tarmoq shartlari tufayli jitter tomonidan yutilish ehtimoli bor.
qo'shib qo'ydi muallif CEObrainz, manba
Va, albatta, boshqa barcha e'tirozlar ham juda mantiqqa to'g'ri kelardi, biroq, men bu juda kam bo'lgan (30 milodiy vaqt ichida 20 milya masofani bosib o'tish) aniqroq bo'lishi kerak bo'lgan sifatli ta'sirni kutgan edim. tashqi hisobga olish, noma'lum nosozliklar. Lekin, albatta, men noto'g'ri bo'ldim.
qo'shib qo'ydi muallif CEObrainz, manba