Свободные байты малых пакетов UDP (внутри MTU) во время передачи?

Предыстория: Кодирование многопользовательской игры для симулятора (Windows, .net) с использованием одноранговой передачи UDP. Этот вопрос касается не преимуществ UDP по сравнению с TCP и не заголовков пакетов. Обсуждение этого вопроса связано с здесь.

Рассмотрим: я отправляю пакет UDP с размером полезной нагрузки X, где X может быть любым значением от 1 до 500 байт.

В: Будут ли/могут ли в любой момент передачи временно добавляться резервные байты к пакету, т.е. байт в дополнение к необходимым заголовкам/полезной нагрузке? Например, может ли быть так, что какой-либо участник передачи (ОС Windows - NAT - интернет - NAT - ОС Windows) добавил байты для выполнения определенного размера блока, чтобы эти добавленные байты стали частью передачи (даже если обрезаны позже), и на самом деле передаются, потребляя такты процессора (коммутатора, сервера)?

(Причина вопроса в том, сколько усилий затрачивается на составление/разложение пакета, конечно же :-). Сожмите его до последнего бита (маленькие, более локальные циклы ЦП) вместо того, чтобы позволить пакету быть частично самоописываемым (больше, меньше локального ЦП). Обратите внимание, что размер пакета всегда меньше, чем (ближайший ко мне, который я знаю) MTU, обычно ближе к 1500 байтам)

Спасибо!


person Stormwind    schedule 02.03.2016    source источник


Ответы (1)


Короткий ответ: Да.

Возьмите Ethernet в качестве примера. В целях обнаружения коллизий минимальный размер полезной нагрузки кадра Ethernet составляет 42 байта. Если полезная нагрузка (которая включает в себя данные приложения, заголовок UDP и IP, в данном случае) меньше этого значения, к кадру Ethernet будет добавлено заполнение.

Кроме того, насколько я знаю, сетевая карта будет выполнять эту работу, а не ее драйвер или ОС.

Если вы хотите решить, лучше ли отправлять маленькие пакеты или подождать и отправить большие, взгляните на алгоритм Нэгла.

Здесь вы можете увидеть заполнение Ethernet на практике: Что такое 0 байтов в конце кадра Ethernet в Wireshark?

person Jefferson    schedule 04.03.2016
comment
Основываясь на приведенном выше ответе, будет ли справедливо предположить, что для части передачи, когда пакет находится вне компьютеров двух одноранговых узлов, не имеет значения, составляет ли полезная нагрузка 1 или 42 байта. или что-то среднее, если ориентироваться на скорость передачи? Это примерно, поскольку я понимаю, что есть множество других факторов, влияющих, например, время срабатывания и локальные циклы обслуживания. Тем не менее, это имеет значение, поскольку можно, например, локализовать бенчмаркинг для управления пакетами ‹42 байта и исключить Интернет как константу . - person Stormwind; 05.03.2016
comment
Да, для таких маленьких пакетов это не имеет значения, пакет будет иметь длину не менее 72 байт в сети, с достаточным количеством данных или без них. Чтобы решить лучше, пожалуйста, имейте в виду эти 2 момента: 1 - Время обработки намного меньше, чем время работы в сети, поэтому старайтесь отправлять как можно меньше пакетов для повышения производительности. 2. Все эти накладные расходы увеличивают ваши данные, поэтому отправка большого количества небольших пакетов на самом деле означает отправку огромного количества байтов по сравнению с отправкой нескольких больших пакетов. Пожалуйста, не забудьте проголосовать за ответ, если я развею ваши сомнения. - person Jefferson; 05.03.2016
comment
Это очень хорошо ответило на мой вопрос, спасибо. Несколько лучше. Ненаучно у меня сложилось впечатление, что икота (отзывчивость) работает лучше, если пациент находится в состоянии покоя :-). Боюсь, мой голос не считается; я сделал это, естественно, но это не будет публично видно, пока я не заработаю репутацию 15 (это мой самый первый вопрос о стеке). Что (в моем случае) довольно глупо, так как я старый пес в программном обеспечении с 30-летним опытом. Ну ладно, я останусь и посмотрю :-). - person Stormwind; 05.03.2016
comment
PS. Добавлен еще один вопрос: ссылка. Может быть, у вас есть время посмотреть на него? - person Stormwind; 05.03.2016