Каков размер udp-пакетов, если я отправляю 0 данных полезной нагрузки в C#?

Я выяснил, что максимальные данные перед фрагментацией между 2 конечными точками с использованием udp - 1472 (другие конечные точки могут отличаться). это означает, что mtu составляет 1500bytes, а накладные расходы заголовка на пакет-28bytes.можно ли предположить, что если я отправлю 0 байт данных(полезная нагрузка), фактические передаваемые данные будут 28bytes? я делаю некоторые bencchmark, поэтому для меня важно знать, что происходит в канале. спасибо.

9
c# header packet udp udpclient

4 ответов

  • MTU-это максимальный размер IP-пакета, который может быть передан без фрагментации.

    IPv4 мандаты MTU пути по крайней мере 576 байт, IPv6 по крайней мере 1280 байт.

    Ethernet имеет MTU 1500 байт.

  • IP-пакет состоит из двух частей: заголовка пакета и полезной нагрузки.

    размер заголовка IPv4 -по крайней мере 20 байт, размер заголовка IPv6 at не менее 40 байт.

    полезная нагрузка IP-пакета обычно является сегментом TCP или дейтаграммой UDP.

  • ДЕЙТАГРАММА UDP состоит из заголовка UDP и транспортируемых данных.

    размер заголовка UDP составляет 8 байт.

Это означает, что IP-пакет с пустой дейтаграммой UDP в качестве полезной нагрузки принимает по крайней мере 28 (IPv4) или 48 (IPv6) байт, но может занять больше байт.

также обратите внимание, что в случае из Ethernet IP-пакет дополнительно будет обернут в пакет MAC (14 байтовый заголовок + 4 байтовый CRC), который будет встроен в кадр Ethernet (8 байтовая последовательность преамбулы). Это добавляет 26 байт данных в IP-пакет, но не считается против MTU.

поэтому вы не можете предположить, что дейтаграмма UDP приведет к передаче определенного количества байтов.

26

типичные IP-заголовки составляют 20 байт, если параметры не были выбраны. Заголовки UDP составляют 8 байт. По Ethernet размер кадра составляет 14 байт (заголовок) + 4 байта (трейлер). В зависимости от того, как вы захватываете эти пакеты, вы можете или не должны учитывать размер кадра.

без Ethernet (IP + UDP) = 20 + 8 = 28 байт
С Ethernet = 18 + 28 = 46 байт

класс UdpClient в C# вернет пакет из слоя 5 и далее, поэтому вам не придется учитывать выше.

обновление:
MTU 1500 байт применяется на уровне IP. Это означает, что размер пакета ниже уровня IP незначителен при фрагментации.

Что переводится как:
Байты кадров Ethernet (фиксированные) = 18
IP заголовок (мин) = 20
Заголовок UDP (фиксированный) = 8
Максимум. допускается нагрузка без фрагментации = 1472
Общее количество байтов, которые идут по проводу = (сумма выше) 1518 байт
(Вы можете подсчитать количество байт оставив инструмент, как Wireshark)

Если (IP-заголовок + UDP-заголовок + полезная нагрузка > 1500), то пакет фрагментирован.

7

накладные расходы IP 20bytes и UDP 8 btes, так что да, 28 байт.

http://en.wikipedia.org/wiki/User_Datagram_Protocol

Не забывайте о накладных расходах Ethernet, если вы делаете внутреннее тестирование

1

можно ли предположить, что если я отправлю 0 байт данных(полезная нагрузка), фактические передаваемые данные составляют 28bytes

нет

(и да... потому что это обычно не имеет никакого реального значения, поскольку это "безопасно")

хотя верно, что дейтаграмма UDP / IPv4 без полезной нагрузки без опции составляет ровно 28 байт (или" октетов " на сетевом жаргоне), это отнюдь не безопасное предположение.
Однако по большей части это несущественно. Переключатели и маршрутизаторы, как правило, вперед небольшой пакет точно так же быстро, как большой (или, с neglegible разница). Единственный случай, когда вы можете увидеть разницу, - это ваш счет за пропускную способность (вы платите за все биты на проводе, а не только за те, которые вы используете!).

IPv4 может иметь до 40 октетов "опций", прикрепленных к нему, и IPv4 может быть инкапсулирован в IPv6 (даже без вашего ведома). Оба могут резко увеличить размер дейтаграммы и, таким образом, данные, передаваемые в довольно очевидном путь.

кроме того, дейтаграмма будет дополнительно инкапсулирована на уровне ссылки, добавляя предварительные и заголовочные данные и имея минимальную длину кадра. Наличие дополнительных заголовков, опять же, довольно очевидно, тот факт, что помимо максимальных размеров, полезные нагрузки также имеют минимум размеры-менее известный факт.

Ethernet и ATM-это два широко используемых стандарта, которые могут помешать вам в ваших предположениях здесь (но другие слои ссылок подобный.)

кадр ethernet имеет минимальный размер 64 байта и имеет нулевой размер. При наличии 802.1 Q (VLAN) это означает, что минимальная полезная нагрузка для фрейма ethernet составляет 42 октета, в противном случае-46 октетов.
Поэтому отправка дейтаграммы UDP/IPv4 нулевой длины через "обычный" ethernet добавит 18 нулевых байтов к полезной нагрузке. Вы никогда не увидите их, но они есть, и они появятся на вашем счете.

аналогично, ячейки ATM (такие же, как "кадр", они почему-то используют другое слово) всегда 53 байта, с 48 байтами нулевой полезной нагрузки. Таким образом, диаграмма UDP с нулевой полезной нагрузкой приведет к добавлению 20 нулевых байтов, тогда как датаграмма UDP/IPv6 с нулевой длиной сохранит свой исходный размер (ровно 48 байтов), предполагая, что между ними нет другой инкапсуляции, такой как PPPoE.

наконец, обратите внимание, что дополнительные пакеты могут потребоваться для отправки и получения, чтобы иметь возможность отправлять ваш пакет вообще. Например, вашей ethernet-карте может потребоваться ARP (или NDP) для отправки вашей дейтаграммы. Кэширование результатов амортизирует это, поскольку вы отправляете несколько датаграмм, но если вы отправляете только один UPD datagram, вы можете быть удивлены, что примерно в три раза больше "данных" отправляется и принимается по сравнению с тем, что вы могли бы наивно ожидать.

1