TCP和UDP如何检测传输错误？
这些协议如何检测数据传输过程中发生的错误？
How do these protocols detect that an error has occurred during the data transmission?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
这些协议如何检测数据传输过程中发生的错误？
How do these protocols detect that an error has occurred during the data transmission?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（3）
可能会发生不同的错误：
UDP 仅提供一种机制来克服数据损坏（这是一个可选功能）在 IPv4 中，在 IPv6 中是强制的）。
数据损坏
如果每个数据包的标头中都使用了校验和字段，则 UDP 只能抵抗数据包内部数据的损坏。基本上，它需要标头、数据包内容和一些更多信息（如 IP 地址），将其解释为补码形式的一长串 16 位单词，并将它们相加 UDP 校验和。
TCP 有类似的方法来解决数据损坏问题。
所有其他问题
TCP 为每个数据包都有所谓的序列号。序列号寻址字节，因此如果发送者说“这是序列号为 102 的数据包”，他说，他发送的数据包以流的字节 102 开始。然后接收方向接收方发送确认。例如，如果数据包的长度为 10 个字节，则接收方将发送序列号为 112 的 Ack，这意味着“我希望接收到的下一个数据包以序列号 112 开始”。每个具有不同序列号的数据包要么是重复的（太低），要么是数据包丢失（接收到的序列号太高），要么是幻像（预期序列号与接收到的序列号完全不匹配）。因此，在所有序列号不匹配的情况下，接收方都知道出现问题并可以做出反应（与不同的 TCP 版本不同）。
发送方等待接收方的确认。如果他在一段时间内没有收到预期的确认，他将重新传输数据包，因为他认为数据包在途中丢失了。
这只是一个非常简短的解释。这个主题比这里描述的要大一些；）
There are different errors that can occur:
UDP only provides a mechanism to overcome the corruption of data (which is an optional feature in IPv4, mandatory in IPv6).
Corruption of Data
UDP is only resistant against the corruption of data inside packets, if the checksum field is used in the header of every packet. Basically it takes the header, the packet content and some more information (like IP addresses), interprets this as a long list of 16 bit words in ones-complement and sums them up UDP checksum.
TCP has a similar approach to tackle corruption of data.
All the other problems
TCP has so-called sequence numbers for every packet. The sequence number addresses bytes, so if the sender says "this is the packet with sequence number 102", he says, that the packet he sent starts with the byte 102 of the stream. The receiver then sends and acknowledgement to the receiver. For example, if the packet has a length of 10 bytes, the receiver will send and Ack with the sequence number 112, which means "i expect the next packet to be received to start with the sequence number 112". Every packet that has a different sequence number is either a duplicate (too low) or a packet got lost (received sequence number is too high) or it is a phantom (total mismatch of expected sequence number and received one). So in all cases of sequence-number mismatch, the receiver knows that something goes wrong and can react (differs from different TCP versions).
The sender waits for the acknowledgements of the receiver. If he does not receive an expected ack for a certain time, he will retransmit packets, because he assumes, that the packets got lost on their way.
This is only a very brief explanation. The topic is somewhat bigger than described here ;)
在 IP 协议级别（UDP 和 TDP 均基于该协议），有一个校验和确认数据包的内容有效。但是，在某些情况下，此校验和无法检测到某些错误。
通常在较高级别（例如传输文件时），会根据文件内容计算出更稳健的哈希值。这可以在整个文件上完成，也可以在某个大小的文件的各个块上完成（通常比单个 IP 数据包大得多）。
At the IP protocol level (on which both UDP and TDP are based), there is a checksum that confirms that the contents of the packet are valid. However, there are situations where certain errors are not detected by this checksum.
Usually at a higher level (such as when transferring a file), there is a more robust hash calculated on the contents of the file. This might be done on the complete file, or on individual blocks of the file of some size (usually much larger than a single IP packet).
如果我记得在不同的课程中，格雷格（Greg）认为校验和是少数数据验证来源之一，这是正确的。然而，UDP（按其设计方式）并不总是 100% 可靠。这使得它非常适合流数据（例如网络摄像头），因为丢失一帧并不是什么大问题。虽然这在 TCP 中被认为是一个错误（然后必须重新发送帧，延迟所有后续帧），但 UDP 并不真正关心，除非它被配置为。
如果需要接收所有数据，则请求方的相关协议确保要求发送每个数据包，通常按顺序发送。校验和在这里发挥作用，因为然后检查每个部分以确保其正确（当数据部分错误偶数次时出现小问题，因为校验和可能会抛出误报，但这种情况非常罕见）。每次一个部件失败时，都会重新请求它，直到它被接收并且校验和竖起大拇指。当接收到每个部分时，接收方的协议会向发送方回复一切都很好。如果发送方在一段时间内没有收到此响应，则会重新发送数据包。
If I recall from various classes, Greg was right with the checksum as one of a few sources of data verification. However, UDP (designed the way it is) is not always 100% reliable. This makes it perfect for streaming data (webcams, for example), as losing a frame is not that big a deal. While this would be considered an error in TCP (which would then have to resend the frame, delaying all following frames), UDP does not really care unless it is configured to.
Provided that all data is required to be received, the protocol in question on the requesting side makes sure to ask for each packet to be sent, typically in order. Checksum comes in to play here as each part is then checked to make sure it is correct (small problem when the data part errors an even number of times as the checksum can then throw a false positive, but this is pretty rare). Each time a part fails, it is re-requested until it is both received and checksum gives a thumbs up. As each part is received, the protocol at the receiver responds to the sender that everthing is cool. If the sender does not receive this response within some time limit, it resends the packet.