Я мав графічний аналіз 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