如果我在c#中发送0有效负载数据，udp数据包的大小是多少？
我已经计算出使用 udp 的 2 个端点之间的分段之前的最大数据是 1472（其他端点可能有所不同）。这表明 mtu 为 1500 字节，每个数据包的标头开销为 28 字节。是否可以安全地假设，如果我发送 0 字节数据（有效负载），则实际传输的数据是 28 字节？我正在做一些基准测试，所以了解通道中发生的情况对我来说至关重要。
I have figured out the maximum data before fragmentation between 2 endpoints using udp is 1472(other endpoints may vary). This states that mtu is 1500bytes and header overhead per packet is 28bytes. Is it safe to assume that if I send 0 bytes data (payload), the actual data being transferred is 28bytes? I am doing some benchmark, so it is crucial for me to know, what happens in the channel.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
IP 开销是 20 字节，UDP 是 8 字节，所以是的，28 字节。
http://en.wikipedia.org/wiki/User_Datagram_Protocol
不要忘记以太网开销，如果你正在进行内部测试
IP overhead is 20bytes and UDP is 8 btes, so yes, 28 bytes.
http://en.wikipedia.org/wiki/User_Datagram_Protocol
Don't forget about Ethernet overhead if you're doing internal testing
MTU 是可以在不分段的情况下传输的 IP 数据包的最大大小。
IPv4 要求路径 MTU 至少为 576 字节，IPv6 要求路径 MTU 至少为 1280 字节。
以太网的 MTU 为 1500 字节。
IP数据包由两部分组成：数据包头和负载。
IPv4 标头的大小至少 20 字节，IPv6 标头的大小至少 40 字节。
IP 数据包的负载通常是 TCP 段或 UDP 数据报。
UDP数据报由UDP报头和传输的数据组成。
UDP 报头的大小为 8 个字节。
这意味着以空 UDP 数据报作为有效负载的 IP 数据包至少需要 28 (IPv4) 或 48 (IPv6) 字节，但可能需要更多字节。
另请注意，在以太网的情况下，IP 数据包将另外包装在 MAC 数据包（14 字节标头 + 4 字节 CRC）中，该数据包将嵌入以太网帧（8 字节前导序列）中。这会向 IP 数据包添加 26 字节的数据，但不计入 MTU。
因此，您不能假设 UDP 数据报将导致传输特定数量的字节。
The MTU is the maximum size of an IP packet that can be transmitted without fragmentation.
IPv4 mandates a path MTU of at least 576 bytes, IPv6 of at least 1280 bytes.
Ethernet has an MTU of 1500 bytes.
An IP packet is composed of two parts: the packet header and the payload.
The size of an IPv4 header is at least 20 bytes, the size of an IPv6 header at least 40 bytes.
The payload of an IP packet is typically a TCP segment or a UDP datagram.
A UDP datagram consists of a UDP header and the transported data.
The size of a UDP header is 8 bytes.
This means an IP packet with an empty UDP datagram as payload takes at least 28 (IPv4) or 48 (IPv6) bytes, but may take more bytes.
Also note that in the case of Ethernet, the IP packet will additionally be wrapped in a MAC packet (14 byte header + 4 byte CRC) which will be embedded in an Ethernet frame (8 byte preamble sequence). This adds 26 bytes of data to the IP packet, but doesn't count against the MTU.
So you cannot assume that a UDP datagram will cause a specific number of bytes to be transmitted.
如果未选择任何选项，典型的 IP 标头为 20 字节。 UDP 标头为 8 个字节。通过以太网，帧大小为 14 字节（标头）+ 4 字节（标尾）。根据您捕获这些数据包的方式，您可能需要也可能不需要考虑帧大小。
无以太网 (IP + UDP) = 20 + 8 = 28 字节
以太网 = 18 + 28 = 46 字节
C# 中的 UdpClient 类将从第 5 层开始返回数据包，因此您不必考虑上述情况。
更新：
1500 字节 MTU 在 IP 层强制执行。这意味着 IP 层以下的数据包大小在分段时可以忽略不计。
这意味着：
以太网帧字节（固定）= 18
IP 标头（最小）= 20
UDP 标头（固定）= 8
最大限度。允许无碎片的有效负载 = 1472
线路上传输的总字节数 =（以上总和）1518 字节
（您可以使用 Wireshark 等工具计算留下的字节数）
如果（IP 标头 + UDP 标头 + 有效负载 > 1500）则数据包被分段。
Typical IP headers are 20 bytes, if no options have been selected. UDP headers are 8 bytes. Over Ethernet, frame size is 14 bytes (header) + 4 bytes (trailer). Depending on how you capture these packets, you may or may not have to account for frame size.
Without Ethernet (IP + UDP) = 20 + 8 = 28 bytes
With Ethernet = 18 + 28 = 46 bytes
The UdpClient class in C# will return the packet from layer 5 onwards, so you won't have to account for the above.
Update:
The 1500 bytes MTU is enforced at the IP layer. That means that the packet size below the IP layer is insignificant when fragmenting.
That translates to:
Ethernet frame bytes (fixed) = 18
IP header (min) = 20
UDP header (fixed) = 8
Max. allowed payload for no fragmentation = 1472
Total number of bytes that go on the wire = (Sum above) 1518 bytes
(You can count the number of bytes leaving with a tool like Wireshark)
If (IP header + UDP header + Payload > 1500) then the packet is fragmented.
否
（是的......因为它通常没有真正的区别，就其“安全”而言
）无负载无选项 UDP/IPv4 数据报正好是 28 个字节（或网络术语中的“八位字节”），这绝不是一个安全的假设。
然而，这在很大程度上是无关紧要的。交换机和路由器转发小数据包的速度通常与转发大数据包的速度完全相同（或者差异可以忽略不计）。您可能会看到差异的唯一情况是您的带宽账单（您为线路上的所有位付费，而不仅仅是为您使用的位付费！）。
IPv4 可能附加有最多 40 个八位位组的“选项”，并且 IPv4 可能封装在 IPv6 中（甚至在您不知情的情况下）。两者都可以大大增加数据报的大小，从而以相当明显的方式传输数据。
此外，数据报将在链路层进一步封装，添加前导码和报头数据，并具有最小帧长度。额外标头的存在再次非常明显，但除了最大大小之外，有效负载还具有最小大小这一事实是一个不太为人所知的事实。
以太网和 ATM 是两种广泛使用的标准，它们可能会妨碍您的假设（但其他链路层类似）。
以太网帧的最小大小为 64 字节，并用零填充到该大小。如果存在 802.1Q (VLAN)，这意味着以太网帧的最小有效负载为 42 个八位位组，否则为 46 个八位位组。
因此，通过“普通”以太网发送零长度 UDP/IPv4 数据报将在有效负载中附加 18 个零字节。您永远看不到它们，但它们就在那里，并且会出现在您的账单上。
类似地，ATM 信元（与“帧”相同，由于某种原因使用不同的词）始终为 53 字节，其中有 48 字节的零填充有效负载。因此，零有效负载 UDP 图将导致添加 20 个零字节，而零长度 UDP/IPv6 数据报将保持其原始大小（大小恰好为 48 字节），假设中间没有其他封装（例如 PPPoE）。
最后，请注意，可能需要发送和接收额外的数据包才能发送您的数据包。例如，您的以太网卡可能必须执行 ARP（或 NDP）才能发送数据报。当您发送多个数据报时，缓存结果会分摊此费用，但如果您只发送一个 UPD 数据报，您可能会惊讶地发现发送和接收的“数据”大约是您可能发送和接收的数据的三倍天真地期待。
No
(and yes... because it usually makes no real difference, insofar it is "safe")
While it is true that a no-payload-no-option UDP/IPv4 datagram is exactly 28 bytes (or "octets" in network jargon), this is by no means a safe assumption.
It is, however, for the most part inconsequential. Switches and routers usually forward a small packet exactly as fast as a larger one (or, with neglegible difference). The only occasion at which you may see a difference is on your bandwidth bill (you pay for all bits on the wire, not just for the ones that you use!).
IPv4 may have up to 40 octets of "options" attached to it, and IPv4 may be encapsulated in IPv6 (without you knowing, even). Both could drastically increase the datagram's size and thus data transferred in a rather obvious way.
Also, the datagram will be further encapsulated on the link layer, both adding preambles and header data, and having minimum frame lengths. The presence of additional headers is, again, pretty obvious, the fact that besides maximum sizes, payloads also have minimum sizes is a less well-known fact.
Ethernet and ATM are two widely used standards that can get in your way on your assumptions here (but other link layers are similar).
An ethernet frame has a minimum size of 64 bytes, and is zero-padded to this size. In presence of 802.1Q (VLAN) this means that the minimum payload for an ethernet frame is 42 octets, otherwise it is 46 octets.
Sending a zero-length UDP/IPv4 datagram over "ordinary" ethernet will therefore append 18 zero bytes to the payload. You never get to see them, but they are there and they will appear on your bill.
Similarly, ATM cells (same as "frame", they use a different word for some reason) are always 53 bytes, with 48 bytes of zero-padded payload. Thus, a zero-payload UDP diagram will cause 20 zero bytes being added whereas a zero-length UDP/IPv6 datagram would keep its original size (being exactly 48 bytes in size), assuming there is no other encapsulation such as PPPoE in between.
Lastly, do note that additional packets may be needed to be sent and received in order to being able to send your packet at all. For example, your ethernet card may have to do ARP (or NDP) to be able to send your datagram. Caching the results amortizes this as you are sending several datagrams, but if you send just one UPD datagram, you may be surprised that about three times as much "data" is sent and received compared to what you might naively expect.