Як обчислюються часів ping

Я мав графічний аналіз ping (IPV4) часу відгуку/розмір пакета. Я очікував побачити розрив близько 2 * MTU/BandWidth у час відгуку навколо межі MTU (насправді, близько 1464 байт, MTU 1492 на цьому сегменті). Обґрунтування мого очікування полягає в тому, що 2 * MTU/BW, що є часом обходу пакета з розміром 1 MTU, фрагментація пакетів збільшуватиме кількість разів поспіль у два рази вище суми.

На жаль, це не те, що я бачу. Використовуючи

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

Я бачу лінійну залежність між розміром пакету та roundtrip наступним чином (розмір, min avg max, ms.), Але не розривів сортування:

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

Отже, я не знаю, чи щось порушується яким-небудь чином, коли пакети надсилаються/повідомляються, або якщо моє міркування не так чи інакше (і в даному випадку, де є помилка).

Це і ADSL llink до Інтернету, який проходить через провідну мережу 100 Мб, перетинає FGT60 і zyxel на своєму шляху, а tracepath (також ping -M do) повідомляє 1492 як MTU. Я тестую з коробки linux 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, джерело
Це і ADSL llink до Інтернету, який проходить через провідну мережу 100 Мб, перетинає FGT60 і zyxel на своєму шляху, а tracepath (також ping -M do) повідомляє 1492 як MTU. Я тестую з коробки linux 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 "пробито") обробка пакетів процесора відбувається повільно. Фрагментація - крайовий випадок у сучасних мережах, тому, як правило, відбувається повільно, при низькому пріоритеті. (fortigate має апаратне пересилання, ймовірне, що zyxel це не так.) І додаткова обробка повинна бути зроблена в приймачі, щоб поставити все це назад разом.
додано Автор Neall, джерело
"Я не знаю, чому ви думаєте, що фрагментація подвоїть час". Це змушує мене бачити мою помилку. - Див. Наступний коментар.
додано Автор CEObrainz, джерело
Прихована помилкова аргументація полягає в тому, що я прирівнював мінімальну одиницю передачі (яка для tcp через Ethernet буде приблизно 64 байтами) до MTU - тобто я вважав, що всі пакети потрібно додати до MTU. Це не означає, що розрив через фрагментацію повинен становити близько mTU/Bw, приблизно в 20 разів менше, ніж MTU/Bw, і може бути проковтнути джитер через різні умови мережі.
додано Автор CEObrainz, джерело
І, звичайно, всі інші заперечення також мають сенс, однак, я очікував на якісний ефект, який, на тому досить не завантаженому зв'язку, повинен був бути цілком очевидним (20 мс. Стрибати через 30 мс. Ping) навіть облік зовнішніх, невідомих збурень. Але, звичайно, я помилявся.
додано Автор CEObrainz, джерело