延迟的数据包可以持续多长时间？答案

【问题标题】：How long can a delayed packet persist?延迟的数据包可以持续多长时间？
【发布时间】：2015-09-24 12:27:27
【问题描述】：

我阅读了一些关于 PAWS（防止包装序列的保护）的信息。这很有趣。我不知道为了保证TCP的可靠性而实现了如此复杂的事情。没有PAWS，在高数据率的情况下，可能会接收到一个延迟的旧数据包，并误认为是新数据包。

我之前并没有考虑太多。但是现在我开始想知道一个数据包可以在网络中停留多长时间（如果数据包的类型很重要，尤其是 UDP 数据包）。一个数据包可以延迟，在它被传递之前暂时停留在网络中。但它只能停留很短的时间，对吧？

换句话说，等待（UDP）数据包需要多长时间才能断定它不会到来？

如果有答案，那么它是如何确定的？如何估算？（用于编写包超时相关的程序。）

一个简化的例子：一个服务器收到了 2 个 UDP 数据包。每个都包含一个整数来指示顺序。它获得了第一和第三。它知道 No.2 要么延迟要么丢失。过了一段时间，2号还没来，就断定丢包了。数据包不存在了。（所以以后新的数据包不会有问题，类似于PAWS要解决的问题。）但是服务器要等多久才能断定No.2不再存在呢？

【问题讨论】：

根据您的编辑，这取决于使用 UDP 的应用程序。 UDP 本身并不以任何特定的顺序寻找任何特定的数据包。从网络协议的角度来看，这个问题没有任何意义。这是一个应用问题。一些应用程序很关心，他们已经实现了自己的可靠性程序，或者他们使用 TCP。

标签： networking tcp udp delay

【解决方案1】：

UDP 是一种即发即弃、尽力而为的协议。接收主机不期望 UDP 数据包即将到来。上层可以使用自己的保证或期望，但 UDP 没有。

UDP 不像 TCP 那样等待数据包。

【讨论】：

我的意思是 UDP 数据包需要花费一些时间。一个数据包甚至可以比它的前一个数据包更早地到达目的地。那么旅行最多需要多长时间？
你不明白 UDP 不关心这个。它对 TCP 很重要，但是 UDP 数据包到达那里时到达那里，或者没有到达那里，而 UDP 不在乎。使用 UDP 的应用程序可能关心，但这取决于应用程序，而 UDP 不关心。

【解决方案2】：

见RFC 791 #3.2:

生存时间

生存时间由发送者设置为最大时间数据报被允许在互联网系统中。如果数据报在互联网系统中的时间长于生存时间，那么必须销毁数据报。

该字段必须在 Internet 标头的每一点减少被处理以反映处理数据报所花费的时间。即使在实际时间上没有可用的本地信息花费，该字段必须减 1。时间以以秒为单位（即值 1 表示一秒）。就这样最长生存时间为 255 秒或 4.25 分钟。由于每处理数据报的模块必须将 TTL 至少减少即使它在不到一秒的时间内处理数据报，TTL 必须仅将其视为数据报可能的时间上限存在。目的是导致无法传递的数据报丢弃，并限制最大数据报生命周期。

【讨论】：

这是针对 IP 本身的，它设置了 IP 数据包在被丢弃之前可以在网络上存活多长时间的上限。它没有解决应用程序在相信它不会到达之前等待 UDP 段的时间，并且可能会重新请求发送者发送另一个。 UDP 不等待特定数据包的到达，因此它不关心它是否丢失。如果一个应用程序对 UDP 缺乏保证有缓解措施，它是依赖于应用程序的，并且会因应用程序而异。大多数人使用 UDP，因为他们不在乎。
@RonMaupin 它是针对 IP 本身的，并且，由于 UDP 数据报不能比它所封装的 IP 数据包寿命更长，因此应用程序等待的时间超过 IP TTL 是没有意义的在得出 UDP 数据报丢失的结论之前。我没有在任何地方说明 UDP 是否“担心它是否丢失”。 IP TTL 为应用程序应该做什么提供了一个上限。
我对 OP 的看法是，如果应用程序关心在特定时间范围内接收 UDP 段（大多数关心的应用程序等待的时间比 IP 超时时间短得多），它取决于应用程序来确定该时间段，而不是 UDP，因为 UDP 本身并不关心。 UDP 不期待下一个数据包，因此它不知道它是否丢失、延迟或乱序。
@RonMaupin 你不需要教我有关 UDP 的知识。如果您要向 OP 讲话，您应该清楚地标记您的 cmets，或在他的问题下发表评论。但你似乎在叫错树。 OP 的“简化示例”显然是关于应用程序等待，而不是 UDP。