clones писал(а):
Почему приходиться понижать значение MTU на одной версии прошивки, а на другой нет? Задайтесь вопросом – ответ очевиден.
Для меня ответ очевиден, только поймете ли вы его.
Теперь немного лирики и кой каких расчетов будет ли интересно не знаю. Мне достаточно применения параметра на windows - EnablePMTUDiscovery (алгоритма определения MTU) и на канале 4Мбит/с снижение производительности как многие пишут не заметил. Сравним теперь MTU = 1500байт = 1460 + 40 (заголовок) скорость канала 2Мбит/с. Задержка одного пакета на разных MTU:
(1460B+40B) * 8 / 2000000b/c = 0,006c * 1000 = 6mc
(1260B+40B) * 8 / 2000000b/c = 0,0052c * 1000 = 5,2mc
(960B+40B) * 8 / 2000000b/c = 0,004c * 1000 = 4mc
4mc очень хорошо при MTU 1000, но давайте передадим файл в 10Мбайт, для MTU передача :
10 * 1048576B/1460B = 7184 пакетов * 6mc / 1000 = 43,1c
10 * 1048576B/1260B = 8323 пакета * 5,2mc / 1000 = 43,28c
10 * 1048576B/960B = 10924 пакета * 4mc / 1000 = 43,69c
-----------------------------------------------------------------------------------
Что лучше для маршрутизатора передать 7184 пакета или 10924 пакета, а что случиться если на маршруте до цели 10 или 15 марщрутизаторов. Так же учтем что кадр Ethernet имеет заголовок 40 байт следовательно и их тоже надо передать имеем накладные расходы по доп.передачи байт в размере:
1500 = 7184 * 40B / 1024 = 281KB
1300 = 8323 * 40B / 1024 = 325KB
1000 = 10924 * 40B / 1024 = 426KB
----------------------------------------------
Второе не мало важное сама таблица NAT на роутере имеет вид:
Proto Inside global Inside local Outside local Outside global
UDP 11.22.33.44:1111 192.168.0.х:1111 1.2.3.4:53 1.2.3.4:53
Не трудно подсчитать что чем больше пакетов, тем больше ей надо места и следовательно время для поиска соответствия когда пакет придет обратно, чтоб его вернуть адресату, поиск адресата идет по порту.
И теперь возьмем бурное развитие сетей P2P, мультимедаи и их потоки (для которых уже важны временные метки и объемы), которые бурно используют UDP, который не требует подтверждения.