Пинг уақыттары қалай есептеледі

Мен пингтің (IPV4) жауап уақыттарын/пакет өлшемінің графигін графиктім. Мен MTU шекарасының айналасында (шын мәнінде, шамамен 1464 байт, MTU 1492 бұл сегмент бойынша) жауап уақытында шамамен 2 * MTU/BandWidth үзілімін көруді күткен едім. Менің болжауымша, 2 MTU/BW 1 MTU өлшемі бар пакеттің айналдыру уақыты болып табылады, пакеттік фрагментациялау бұл сомадан екі есе асатын кезеңге барады.

Өкінішке орай, бұл менің емес. Қолдану

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

Мен пакеттің өлшемі мен келесі бағыттар бойынша сызықтық тәуелділікті көріп отырмын (өлшемі, мин. Мг максимум, мс.), Бірақ сұрыптаудың үзіліссіздігі:

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

Сондықтан пакеттердің жіберілуіне/хабарлануына немесе менің пікірім дұрыс емес немесе басқаларға қатысы бар (немесе осы жағдайда қате) қандай да бір нәрсе арқылы тоқтап қалатынымды білмеймін.

Ол 100 МВт сымды Ethernet арқылы өтетін Интернетке қосылып, ADSL желісіне қосылады, FGT60 және оның шығу жолында кесіп өтеді, ал трассалық жолды (Ping -M do) 1492 деп MTU деп көрсетеді. FC22 линукс қорабынан тестілеуден өтіп жатырмын. Мен білмеймін, бірақ, менің ойымша, желідегі сыртқы деректер маңызды емес (көп). Мен жоғалтатын сапалық нәтиже, себебі үзіндісі жергілікті интерфейсті 1500 MTU белгісінен (бұл Ethernet қосылымы MTU) өткеннен кейін (кем дегенде)

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
Сіз нәтижелерді жариялап жатырсыз, бірақ параметрлерді ұмытып кетесіз. Сұрақыңызды екі құрылғы арасындағы желі диаграммасымен және сипаттамасымен өңдеуіңіз қажет.
қосылды автор Ron Maupin, көзі
Сіз бұл мәселені қосу үшін оны өзгертуіңіз керек.
қосылды автор Ron Maupin, көзі
Ол 100 МВт сымды Ethernet арқылы өтетін Интернетке қосылып, ADSL желісіне қосылады, FGT60 және оның шығу жолында кесіп өтеді, ал трассалық жолды (Ping -M do) 1492 деп MTU деп көрсетеді. FC22 линукс қорабынан тестілеуден өтіп жатырмын. Мен білмеймін, бірақ, менің ойымша, желідегі сыртқы деректер маңызды емес (көп). Мен жоғалтатын сапалық нәтиже, себебі үзіндісі жергілікті интерфейсті 1500 MTU белгісінен (бұл Ethernet қосылымы MTU) өткеннен кейін (кем дегенде)
қосылды автор CEObrainz, көзі

1 жауаптар

Бөлшектеу уақытты екі есе көбейтеді деп ойласаңыз не үшін сенімдімін. Егер маршрутизатор буманы үзіп тастаса, онда ол үзінділерді дәйекті түрде жібереді. Хост басқа фрагменттерді алады, оларды қайта жинайды және жауап береді. Фрагментация уақытының ұзаруы әділ сызықты болуы керек. Маршрутизаторға пакетті бөлшектеуге уақыт кетеді, ал қабылдаушы хосттың фрагменттері қайта жиналуы үшін уақыт қажет.

Уақытты екі еселеу бір фрагментті жіберуді, жауап алуды, келесі фрагментті жіберуді, жауап алуды және уақытты хабарлауды қамтиды. Бұл жұмыс істемейді.

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

Сондай-ақ ICMP (ping ICMP Echo және ICMP Echo Reply) жиі Интернеттегі тұрақты IP трафигіне қарағанда әртүрлі өңделетінін түсінуіңіз керек. Бұл әдетте төмен басымдық болып табылады және ол әдеттегі трафиктің пайдасына кезекке қойылады және ол айнымалы кептелудің сезімтал болады. Тіпті әдеттегі трафиктен басқа жолды алуға болады. Қосылған кешіктіру кішкене бұйрықтар бойынша кішкене күрделілікте болуы мүмкін, кешігу фрагментация арқылы туындауы мүмкін. Бұл қисықтың тегістелуіне әсер етуі мүмкін.

Фрагментацияны сынаудың нақты жолы басқарылатын тыс айнымалыларды жоюға арналған. Екі хост арасындағы нүкте-нүктелі сілтеме арқылы сынақты бастаңыз. Содан кейін, екі құрылғы арасында, басқарылатын қадамдарда құрылғылар (қосқыштар, маршрутизаторлар, т.б.) қосуды бастаңыз. Сынақ ортасын өзгерткенге дейін әрбір сынақты бірнеше рет орындаңыз. Интернетте тестілеу Сізге күтпеген нәтижелер береді, себебі сізде Интернетті бақылау жоқ.

3
қосылды
үзіндісі жүйенің процессоры арқылы «баяу жол» арқылы өтуі керек. (Cisco терминдерінде, «punted») CPU пакетін өңдеу баяу. Фрагменттеу қазіргі заманғы желілерде шеткі жағдай болып табылады, сондықтан ол әдетте төмен басымдықпен баяу орындалады. (Fortigate аппараттық экспедицияға ие, зиксель мүмкін емес.) Және қосымша өңдеуді қабылдағышта бірге жасау керек.
қосылды автор Neall, көзі
«Мен фрагментация уақытты екі есе көбейтеді деп ойлаймын». Бұл менің қателігімді көруге мүмкіндік береді. - Келесі ескертуді қараңыз.
қосылды автор CEObrainz, көзі
(Жасырын) ақаулықты бөлік, менің ең төменгі трансмиссиялық бөлімді (Ethernet үшін шамамен 64 байт болатын) MTU-ге теңестіретіндіктен, яғни, барлық пакеттерді MTU-ға толтыру керек деп ойладым. Бұлай болмаған жағдайда, фрагментацияға байланысты үзіліс mTU/Bw айналасында болуы керек, айналасында MTU/Bw-ден 20 есе аз және әр түрлі желілік жағдайларға байланысты джиттердің жұтылуы мүмкін.
қосылды автор CEObrainz, көзі
Және, әрине, барлық басқа да қарсылықтар да көп мағынаға ие болады, дегенмен, менің ойымша, сапалы әсер күтіп тұрған еді, ол жеткілікті түрде түсірілмеген сілтеме анық көрінуі керек еді (30 мс псингтен 20 мс секіру) сырттан есептеледі, белгісіз наразылықтар. Бірақ, әрине, мен қателеспесем.
қосылды автор CEObrainz, көзі