Почему пакетные пакеты в UDP коррелируют с количеством пакетов и использованием полосы пропускания

Question

Я тестирую скорость между клиентом и хостом, используя iperf. В моем приложении мне нужно иметь возможность отправлять 2-байтные UDP-кадры примерно на 5 кГц.

Doing нормальный тест UDP скорость можно легко получить 10Mb/s:

$iperf -uVc some_ip -b 10M 
Interval  Transfer Bandwidth Dropped/Sent 
0.0-10.0 sec 11.9 MBytes 10.0Mbit/sec 0/8504 (0%) 

Когда я затем попытаться отразить мое заявление, отправив 2B на 5Гц (который соотносит 80 Кб/с) дейтаграмм:

$iperf -l 2 -uVc some_ip -b 80K 

На стороне сервера указано, что пакеты не прошли, через которые я угадываю, потому что счетчик или что-то, что iperf использует для отслеживания пакетов, не может быть помещен в полезную нагрузку 2B. Имеет ли это смысл?

Как правило, как плохо это послать много небольших пакетов против нескольких крупных? Может ли кто-нибудь указать на литературу, которая иллюстрирует компромисс между ожиданием «упаковки» большой дейтаграммы и моментальной отправки 2B данных, как только вы ее получите?

Чтобы уточнить, меня интересует штраф, который вы платите за отправку множества небольших пакетов (включая накладные расходы, пакеты составляют всего около 60 Б) по сравнению с отправкой меньших, но больших пакетов. В моих тестах до сих пор падение пакетов явно не коррелирует с использованием полосы пропускания, скорее они коррелируют с количеством пакетов, которые я нахожу контр-интуитивными!

EDIT:

Я делаю это на самом простом клиенте - настройка сервера, между двумя Linux PC, подключенных к локальной сети, в которой они являются только интерфейсы в сети с коммутатором Ethernet между ними.

Answer 1

Ответ на ваш общий вопрос «как это плохо» в значительной степени зависит от вашей топологии сети, где происходит связь и тип устройств.

1. Если вы отправляете дейтаграммы через Интернет, большое количество небольших пакетов не является оптимальным. TCP реализует Nagle's Algorithm, чтобы избежать отправки небольших пакетов с 1 или 2 байтами полезной нагрузки, что отмечено в RFC 896, может привести к краху перегрузки.
2. Если вы отправляете дейтаграммы через сеть с большим количеством переходов, вероятность того, что упавшие пакеты увеличится, так как каждый прыжок не сможет обрабатывать одинаковое количество пакетов в своих очередях.
3. Если ваш источник и пункт назначения находятся в одном и том же сегменте локальной сети, это не имеет большого значения. Вы потеряете некоторую пропускную способность из-за накладных расходов на один пакет.

В зависимости от типа систем, отправляющих и принимающих, большое количество небольших пакетов увеличит отток сетевого стека, драйверов и приложений. Во встроенной системе устройство может проводить больше циклов ЦП, маршируя все пакеты через сетевой стек, а не обрабатывая данные.

Answer 2

Вы должны понимать, что ваши 2 байта являются полезной нагрузкой, а сетевые уровни будут добавлять заголовки перед вами полезная нагрузка. Один только IP-заголовок составляет 20 байтов, но UDP или TCP также имеют свои заголовки, и, конечно же, есть и заголовок ethernet.

Скорее всего, но не гарантируется, что сеть находится в сети ethernet, а это означает, что mtu составляет около 1500. Если ваш пакет с включенными заголовками не такой размер, вы не используете оптимальное использование сети.

IP сделает фрагментацию, если ваш пакет не подходит в mtu. Предположим, что mtu 1500 и что разные слои ничего не добавляют, тогда отправка 2000 байт будет разделяться на 1500 и 500. Если у вас 1501, он будет разделен на 1500 и 1. Опять же, не оптимальный. IP способен фрагментировать до 64K. Если вы отправляете что-то такое, то, конечно, оно будет разделено по IP, и у вас будет множество оптимальных пакетов, кроме последнего.

Оптимальный размер пакета = mtu - используются заголовки разных слоев. слои

• TCP или UDP
• IP
• Ethernet

быть предупрежден о том, что МТУ не гарантирована 1492. Это может быть ниже, чем это зависит от всей сети.

TCP сделает все возможное для вас. Потому что это в природе TCP, чтобы попытаться оптимально использовать mtu. Nagle реализуется как непрерывный 50 мс таймер, и сегмент отправляется только в том случае, если таймер истекает, или если сверстник ожидает получить то, что он отправил сам.