我记得在某处读过如果udp实际上到达应用程序层，数据可以假定是完整的。如果忽略中间某人发送假包的可能性，我在应用层收到的数据总是会被发送出来的？
答案 0 :(得分：4)
UDP使用16位可选校验和。未通过校验和测试的数据包将被丢弃。
假设一个完美的校验和，那么65536个损坏的数据包中就有一个不会被注意到。较低层也可能具有校验和（甚至更强大的方法，如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亿个数据包。
（注意：在现实世界中，损坏的可能性取决于数据包数量和大小。此外，这些校验和都不是加密安全的，攻击者破坏数据包是微不足道的。以上仅适用于随机数据包。损坏。）
答案 1 :(得分：3)
UDP使用16位校验和，因此您可以确保数据未被链路层破坏。但是，这不是绝对的保证。在可能的情况下，最好在应用层验证任何传入数据。
请注意，IPv4中的校验和在技术上是可选的。这应该会进一步降低通过互联网发送的数据包的“绝对置信度”水平。
答案 2 :(得分：2)
只保证校验和与UDP数据包中的标头和数据一致。校验和匹配损坏的数据或标头的几率是1 ^ 2 ^ 16。对于某些应用来说，这是很好的赔率，对其如果链上的某个人正在丢弃校验和，那么你就会受到冲击，甚至无法猜测数据包的任何部分是否“正确”。为此，您需要TCP。
答案 3 :(得分：0)
理论上，数据包可能已损坏：数据包有校验和，但校验和不是一个非常强大的检查。我猜这种腐败是不太可能的，（因为如果它是通过嘈杂的调制解调器发送的，或者媒体层可能有自己的，更强的腐败检测）。
相反，我猜测最可能的损坏形式是丢失数据包（完全没有到达），数据包被复制（相同数据包的两个副本到达），数据包不按顺序到达（后来到达的数据包）较早的一个）。
答案 4 :(得分：0)
不是真的。这取决于你所说的“正确”。
UDP数据包的校验和将在网络层（应用程序层下方）进行检查，因此，如果在应用程序层获得UDP数据包，则可以假定校验和已通过。
然而，数据包总是有可能被损坏并且校验和同样受损，因此这实际上是正确的。这将是非常罕见的 - 今天的现代硬件将很难发生这种情况。此外，如果攻击者可以访问数据包，他们只需更新校验和即可匹配他们更改的数据。
有关UDP的更多信息，请参阅RFC 768（技术规格相当小:)。
答案 5 :(得分：0)
值得注意的是，相同的16位crc实现适用于TCP以及基于每个数据包的UDP。在表征UDP的属性时，考虑今天在Internet上发生的大多数数据传输都使用TCP。从网站下载文件时，使用相同的CRC进行传输。
秘密是大多数接入技术的物理层和虚拟层（L1）比TCP强大得多，L1和L2之间的错误概率非常低。
例如，调制解调器具有纠错硬件，PPP层也有自己的校验和。
DSL与ATM（Solomon码）的纠错和PPPoA层的CRC纠错方式相同。
Docsis电缆调制解调器使用与DSL类似的技术进行错误检测和纠正。
最终结果是现代系统中的错误极不可能超过L1。
我已经看到14年前旧帧中继电路的时钟问题常常导致TCP层的损坏。还听说过故障硬件上的位翻转模式故事，促使消除CRC并破坏TCP。
所以是的，腐败是可能的，是的，如果数据非常重要，你应该实现自己的错误检测。在互联网和私人网络的实践中，它今天很少出现。
所有硬件：磁盘驱动器，总线，处理器，甚至ECC内存都有自己的错误概率 - 对于大多数应用程序而言，它们足够低，我们认为它们是理所当然的。