UDP 数据包中的数据在应用程序级别是否可以假定是正确的？
我记得在某处读到，如果 udp 实际上到达应用程序层，则数据可以假设是完整的。不考虑中间有人发送假包的可能性，我在应用层收到的数据是否总是发送出去的数据？
I recall reading somewhere that if a udp actually gets to the application layer that the data can assume to be intact. Disregarding the possibility of someone in the middle sending fake packets will the data I receive in the application layer always be what was sent out?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
UDP 使用 16 位可选校验和。校验和测试失败的数据包将被丢弃。
假设校验和完美，那么 65536 个损坏数据包中的 1 个将不会被注意到。较低层也可能有校验和（或更强大的方法，如 802.11 的前向纠错）。假设较低层每 n 个数据包（平均）将损坏的数据包传递到 IP，并且所有校验和完全不相关，那么您的应用程序每 65536*n 个数据包就会看到损坏。
示例：假设底层也使用 16 位校验和，因此每 2^16* 2^16 = 2^32 个损坏的数据包中就有一个将通过损坏的数据包。如果 1/100 个数据包损坏，则应用程序平均每 2^32*100 个数据包将看到 1 个损坏。
如果我们将其称为 1/(65536*n) 数字 p，那么您可以将完全没有损坏的机会计算为 (1-p)^i，其中 i 是发送的数据包数量。在示例中，要获得高达 0.5% 的损坏概率，您需要发送近 22 亿个数据包。
（注意：在现实世界中，损坏的可能性取决于数据包计数和大小。此外，这些校验和都不是加密安全的，攻击者损坏数据包是微不足道的。以上仅适用于随机损坏。）
UDP uses a 16-bit optional checksum. Packets which fail the checksum test are dropped.
Assuming a perfect checksum, then 1 out of 65536 corrupt packets will not be noticed. Lower layers may have checksums (or even stronger methods, like 802.11's forward error correction) as well. Assuming the lower layers pass a corrupt packet to IP every n packets (on average), and all the checksums are perfectly uncorrelated, then every 65536*n packets your application will see corruption.
Example: Assume the underlying layer also uses a 16-bit checksum, so one out of every 2^16 * 2^16 = 2^32 corrupt packets will pass through corrupted. If 1/100 packets are corrupted, then the app will see 1 corruption per 2^32*100 packets on average.
If we call that 1/(65536*n) number p, then you can calculate the chance of seeing no corruption at all as (1-p)^i where i is the number of packets sent. In the example, to get up to a 0.5% chance of seeing corruption, you need to send nearly 2.2 billion packets.
(Note: In the real world, the chance of corruption depends on both packet count and size. Also, none of these checksums are cryptographically secure, it is trivial for an attacker to corrupt a packet. The above is only for random corruptions.)
UDP 使用 16 位校验和，因此您可以合理地保证数据没有被链路层损坏。然而，这并不是绝对的保证。如果可能的话，在应用程序层验证任何传入数据总是好的。
请注意，在 IPv4 中，校验和在技术上是可选的。这应该会进一步降低您对通过互联网发送的数据包的“绝对置信度”水平。
查看 UDP 白皮书
UDP uses a 16-bit checksum so you have a reasonable amount of assurance that the data has not been corrupted by the link layer. However, this is not an absolute guarantee. It is always good to validate any incoming data at the application layer, when possible.
Please note that the checksum is technically optional in IPv4. This should further drop your "absolute confidence" level for packets sent over the internet.
See the UDP white paper
仅保证校验和与 UDP 数据包中的标头和数据一致。校验和与损坏的数据或标头匹配的几率是 2^16 中的 1。对于某些应用程序来说，这些可能性很大，但对于另一些应用程序来说则很糟糕。如果链条上的某个人丢失了校验和，您就会被淹没，甚至无法猜测数据包的任何部分是否“正确”。为此，您需要 TCP。
You are guaranteed only that the checksum is consistent with the header and data in the UDP packet. The odds of a checksum matching corrupted data or header are 1 in 2^16. Those are good odds for some applications, bad for others. If someone along the chain is dropping checksums, you're hosed, and have no way of even guessing whether any part of the packet is "correct". For that, you need TCP.
理论上，数据包到达时可能已损坏：数据包具有校验和，但校验和并不是非常强的检查。我猜想这种损坏不太可能，（因为如果它是通过嘈杂的调制解调器或媒体层可能有自己的更强大的损坏检测的东西发送的）。
相反，我猜测最可能的损坏形式是丢失数据包（根本没有到达）、数据包重复（同一数据包的两个副本到达）以及数据包不按顺序到达（后一个数据包先于前一个数据包到达） ）。
Theoretically a packet might arrive corrupted: the packet has a checksum, but a checksum isn't a very strong check. I'd guess that that kind of corruption is unlikely though, (because if it's being sent via a noisy modem or something that the media layer is likely to have its own, stronger corruption detection).
Instead I'd guess that the most likely forms of corruption are lost packets (not arriving at all), packets being duplicated (two copies of the same packet arriving), and packets arriving out of sequence (a later one arriving before an earlier one).
并不真地。这取决于你所说的“正确”是什么意思。
UDP 数据包具有校验和，该校验和将在网络层（应用层以下）进行检查，因此如果您在应用层收到 UDP 数据包，则可以假设校验和已通过。
然而，总是有可能数据包被损坏，校验和也同样被损坏，所以这实际上是正确的。这种情况极其罕见——使用当今的现代硬件，这种情况很难发生。此外，如果攻击者有权访问数据包，他们只需更新校验和以匹配他们更改的任何数据。
有关 UDP 的更多信息，请参阅 RFC 768（对于技术规范来说相当小:）。
Not really. And it depends on what you mean by "Correct".
UDP packets have a checksum that would be checked at the network layer (below the application layer) so if you get a UDP packet at the application layer, you can assume the checksum passed.
However, there is always the chance that the packet was damaged and the checksum was similarly damaged so that is is actually correct. This would be extremely rare - with today's modern hardware it would be really hard for this to happen. Also, if an attacker had access to the packet, they could just update the checksum to match whatever data they changed.
See RFC 768 for more on UDP (quite small for a tech spec :).
值得注意的是，相同的 16 位 crc 实现适用于每个数据包的 TCP 和 UDP。在描述 UDP 的特性时，请考虑当今 Internet 上发生的大多数数据传输都使用 TCP。当您从网站下载文件时，将使用相同的 CRC 进行传输。
秘密在于大多数接入技术的物理层和虚拟层 (L1) 比 TCP 更加稳健，并且 L1 和 L2 之间的综合出错几率非常低。
例如，调制解调器有纠错硬件，PPP 层也有自己的校验和。
DSL 与 ATM（所罗门码）的纠错和 PPPoA 层的 CRC 的纠错方式相同。
Docsis 电缆调制解调器使用与 DSL 类似的技术进行错误检测和纠正。
最终结果是现代系统中的错误极不可能超过 L1。
14 年前，我曾见过旧帧中继电路的时钟问题通常会导致 TCP 层损坏。还听说过故障硬件上的位翻转模式促进 CRC 取消和 TCP 损坏的故事。
因此，是的，可能会发生损坏，并且如果数据非常重要，您应该实施自己的错误检测。如今，在互联网和专用网络的实践中，这种情况很少见。
所有硬件：磁盘驱动器、总线、处理器，甚至 ECC 内存都有自己的错误概率 - 对于大多数应用程序来说，它们的错误概率足够低，以至于我们认为它们是理所当然的。
Its worth noting the same 16-bit crc implementation applies to TCP as well as UDP on a per packet basis. When characterizing the properties of UDP consider the majority of data transfers that take place on the Internet today use TCP. When you download a file from a web site the same CRC is used for the transmission.
The secret is the physical and virtual layers (L1) of most access technologies is significantly more robust than TCP and the combined chance of error between L1 and L2 is very low.
For example modems had error correcting hardware and the PPP layer also had its own checksum.
DSL is the same way with error correction at the ATM (Solomon codes) and CRC at the PPPoA layers.
Docsis cable modems use similiar technology to that of DSL for error detection and correction.
The end result is that errors in modern systems are extremely unlikely to ever get past L1.
I have seen clock issues with old frame relay circuts 14 years ago routinly cause corruption at the TCP layer. Have also heard stories of patterns of bit flips on malfunctioning hardware promoting canceling of CRCs and corrupting TCP.
So yes it is possible for corruption and yes you should implement your own error detection if the data is very important. In practice on the Internet and private networks its a rare occurance today.
All hardware: disk drives, buses, processors, even ECC memory have their own error probabilities - for most applications their low enough that we take them for granted.
不，不能假定 UDP 数据包中的数据在应用程序级别是正确的。
请参阅 https://null.53bits.co .uk/index.php?page=crc-and-checksum-error-detection。
No, the data in a UDP packet cannot be assumed to be correct at the application level.
See https://null.53bits.co.uk/index.php?page=crc-and-checksum-error-detection.