Предположим, что машина A хочет отправить данные на машину B. В середине много маршрутизаторов, скажем, 100.
Объем данных, которые нужно отправить, скажем, 1000000 байт. Мой вопрос заключается в том, уменьшит ли разделение данных на размер пакета, например, пакет в 1000 байт, сквозную задержку, а не отправку всех данных сразу?
Я ценю любую информацию в этом сомнении, которое у меня есть.
Спасибо!
Вы можете спросить о целесообразности использования кадров Ethernet Jumbo (ссылка на Википедию), определенных как пакеты с полезной нагрузкой более 1500 байт. Гигантские кадры обычно несут полезную нагрузку 9000 байт.
Измерения показали, что задержка улучшается такими большими пакетами для сквозной производительности TCP. Однако они могут оказывать негативное влияние при прохождении через каналы с низкой пропускной способностью (что в настоящее время менее вероятно).
Вы можете найти более подробную информацию в приведенной выше ссылке на Википедию и в разделе «Ссылки».
Мое собственное мнение: при игре с размерами MTU я никогда не достигал значительных улучшений при больших передачах, когда устанавливал размер MTU больше, чем по умолчанию (1500). Однако, не делая каких-либо точных измерений, я считаю, что использование слишком маленького размера пакета медленнее. Поэтому я не верю, что вы должны изменить MTU по умолчанию.
Если я правильно понял ваш вопрос об отправке всех или по частям, я бы посоветовал отправлять полезные нагрузки, которые полностью заполняют один пакет Ethernet. Помните, что данные, которые вы отправляете, являются полезной нагрузкой, которая затем будет обернута заголовками протокола, которые больше для IPv6, чем для IPv4 (см. Это). Отправка больших блоков данных автоматически сделает это за вас, поскольку операционная система сократит их для максимальной переупаковки по размеру MTU. Так что отправляйте большие куски, но улучшения от отправки гигантских улучшений не будет.
короче говоря: да размер пакетов влияет на эффективную скорость передачи, чем больше пакетов, тем меньше количество требуемых пакетов и, следовательно, в зависимости от используемых протоколов и т. д., в целом требуется меньше служебных данных
jumbo-кадры могут использоваться в некоторых случаях (не все средние / аппаратные средства поддерживают это), чтобы уменьшить еще меньше, чем накладные расходы.
Однако есть и другие факторы, которые могут оказать еще большее влияние на скорость передачи. если между ними находится 100 переходов / устройств, вы получаете другие проблемы, такие как маршрутизация и коммутация пакетов, которые становятся большой нагрузкой на скорость передачи. В этот момент могут быть запрещены не только гигантские кадры, но сомнительно, что вы сможете использовать полные 1500-байтовые пакеты, и только одна только обработка становится достаточно запретительной, чтобы MTU больше не имел значения.
для 1000000 байтов MTU даже не имеет большого значения, потому что его всего 1 МБ, и это займет около 1 секунды. за 1 Тб на регулярной основе, то вы бы посмотреть на оптимизацию. даже если вы предварительно сегментируете файл на несколько, это не заставит его работать быстрее. но на самом деле это может сделать его медленнее, потому что даже если вы разделите файлы на 1 пакет, ваш интерфейс может посчитать, что пакет можно разделить дальше. соединение рассчитывается по "наименьшему доступному" MTU, означающему наименьший "промежуток"(MTU конкретной линии связи) в пути, по которому будет идти пакет, - это размер, по которому будет согласовываться соединение. то есть, если он не фрагментирован дальше из-за "невидимых" издержек другими вещами, такими как соединения ppp, сети mpls, шифрование и туннели и т.д ...
