UDP 正在向数据报的末尾添加字节? [英] UDP is adding bytes to end of datagram?
问题描述
我有一个用 C 编写的 Linux UDP 服务器，我正在发送一个 16 字节的 UDP 数据报.客户端正确接收了所有数据，但wireshark日志显示正在添加两个额外字节:
I have a Linux UDP Server written in C and I am sending a UDP datagram of 16 bytes. All the data is received correctly by the client, but the wireshark log is showing that two extra bytes are being added:
00 16 00 00 c8 44 01 14 01 01 02 01 02 00 00 10 00 00
00 16 00 00 c8 44 01 14 01 01 02 01 02 00 00 10 00 00
这两个字节都是零，我不确定它们来自哪里，我的 sendto() 函数中发送了 16 个字节的数据.
The two bytes are all zeros, I'm not sure where they are coming from, I have the data of 16 bytes sent in my sendto() function.
这些必须从 Linux 内核层的填充中添加吗?有没有办法阻止这种情况发生?
These must be added on from padding at the Linux Kernel layer? Is there anyway to stop this from happening?
wireshark 的屏幕截图，显然这是以太网填充字节......他们为什么在这里?
Screen shot of wireshark, apparently this is Ethernet padding bytes... Why are they here?
推荐答案
以太网帧最少需要 64 个八位字节，包括未显示的帧校验序列 (FCS) 的 4 个八位字节在屏幕截图中.如果没有那 2 个零填充八位字节，该帧的长度将只有 62 个八位字节.另请注意，它们不在 UDP 数据包中，它们在之外.外部 UDP 帧的长度为 24，这包括您发送的数据的 16 个八位字节；剩下的 8 个八位字节是 4 个 16 位数字:源端口、目标端口、长度和校验和.以太网填充字节在 UDP 和 IP 帧之外.
the Ethernet frames need to be minimum of 64 octets, including the 4 octets of Frame Check Sequence (FCS) that is not shown in the screenshot. Without those 2 zero padding octets, that frame would be only 62 octets long. Also notice that they're not in the UDP packet, they're outside. The length of the UDP frame on the outside is given as 24, this includes 16 octets of the data that you sent; the remaining 8 octets are 4 16-bit numbers: source port, destination port, length and checksum. The Ethernet padding bytes are outside both the UDP and the IP framing.
最小 64 八位字节帧长度的原因是旧的 - 以太网最初是为总线拓扑设计的，其中媒体访问通过一种称为 带有冲突检测的载波侦听多路访问 (CSMA/CD).任何设备都可以在总线空闲时随时在总线上传输，但它们必须监视总线以进行同步传输.如果发生冲突，则每个当前发送方都会退回一个随机延迟.设置了 64 字节的最小值，以便发送设备在完成发送帧之前注意到数百米长的电缆上的冲突.
The reason for the minimum 64-octet frame length is old - Ethernet was originally designed for bus topology, where media access was regulated with a method called carrier-sense multiple access with collision detection (CSMA/CD). Any device may transmit on the bus at any time when the bus is free, but they must monitor the bus for simultaneous transmissions. If a collision occurs, then each currently sending party backs off for a random delay. The 64-byte minimum was set so that the sending device would notice a collision on a cable run that is hundreds of metres long before it has finished sending the frame.
来自 Wireshark 文档，通过 Google 搜索wireshark 最小以太网框架"em>:
From Wireshark documentation via Google search for "wireshark minimum ethernet frame":
以太网数据包小于最小 64 字节的以太网数据包(标头 + 用户数据 + FCS)被填充为 64 字节，这意味着如果小于 64-(14+4) = 46 字节的用户数据，额外的填充数据被添加到数据包中.
Ethernet packets with less than the minimum 64 bytes for an Ethernet packet (header + user data + FCS) are padded to 64 bytes, which means that if there's less than 64-(14+4) = 46 bytes of user data, extra padding data is added to the packet.
注意:通常提到的最小以太网数据包大小为 64 字节，其中包括 FCS.这可能会令人困惑，因为 FCS 通常不会被 Wireshark 显示，仅仅是因为底层机制根本不提供它.[...]
Beware: the minimum Ethernet packet size is commonly mentioned at 64 bytes, which is including the FCS. This can be confusing as the FCS is often not shown by Wireshark, simply because the underlying mechanisms simply don't supply it. [...]
顺便说一下，这与 C 编程语言无关.
By the way this is in no way related to the C programming language.
这篇关于UDP 正在向数据报的末尾添加字节?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
