我读了一些关于PAWS（防护环绕序列）的文章。这很有趣。我不知道如何实施这些复杂的事情来保证TCP的可靠性。如果没有PAWS，在数据速率较高的情况下，可能会收到一个延迟的旧数据包，并被误认为是新数据包。延迟的数据包能持续多久？
我之前没有多想这件事。但是现在我开始想知道一个数据包可以留在网络中多长时间（尤其是UDP数据包，如果数据包的类型很重要的话）。数据包可能会被延迟，在交付之前暂时停留在网络中。但它只能停留很短的时间，对吧？
换句话说，在断定它不会到来之前需要多长时间等待（UDP）数据包？
如果有答案，那么它是如何确定的？如何估计它？ （用于编写与分组超时有关的程序）
简化示例：服务器接收到2个UDP数据包。每个都包含一个整数以指示顺序。它拿到了1号和3号。它知道2号要么延迟要么丢失。一段时间后，2号仍然没有来，那么它的结论是数据包丢失。数据包不再存在。 （因此，将来不会对新数据包造成任何麻烦，类似于PAWS希望解决的问题。）但是，在结束No.2之前服务器应该等待多长时间不再存在？
生存时间
住由发送者到 数据报被允许在网络系统中的最大时间设定的时间。如果数据报 在互联网系统中的时间比生存时间长，则必须销毁数据报。
在处理因特网报头 以反映处理数据报花费的时间的每个点上，必须减少此字段。 即使在实际使用 的时间内没有本地信息可用，该字段也必须递减1.该时间以 秒为单位进行测量（即值1表示1秒）。因此，最大生存时间是255秒或4.25分钟。由于每个处理数据报的 模块都必须将TTL减少至少 ，即使它在不到一秒的时间内处理数据报，TTL 必须被认为只是数据报可能存在的时间的上限。其目的是丢弃无法传送的数据报，并将其丢弃，并限制最大数据报使用期限。
这是IP本身，它放置了一个IP数据包在丢弃之前可以在网络上生存多长时间的上界。它没有解决应用程序等待UDP段的时间，然后才相信它不会到达，并且可能会重新请求发件人发送另一个段。 UDP不会等待某个特定的数据包到达，因此它不会在意它是否丢失。如果一个应用程序对UDP缺乏保证有缓解，它依赖于应用程序，并且会因应用程序而异。大多数人使用UDP，因为他们不关心。 –
@RonMaupin它是用于IP本身，并且由于UDP数据报无法超越它所封装的IP数据包，所以在推断出UDP数据报是结束之前，应用程序等待比IP TTL更长的时间是没有意义的丢失。我没有在任何地方声明UDP是“关心它是否丢失”。 IP TTL为应用程序应该执行的操作提供了一个上限。 – EJP
我指向OP的观点是，如果应用程序在某个时间范围内关心接收UDP分段（大多数关心的应用程序将等待比IP超时少得多的时间），它依赖于应用程序来确定时间段，而不是UDP，因为UDP本身不关心。 UDP不期待下一个数据包，因此它不知道它是否丢失，延迟或失灵。 –
UDP是一个遗忘，尽力而为的协议。接收主机没有期望UDP数据包即将到来。上层可以使用自己的保证或期望，但UDP没有。
UDP不会像TCP那样等待数据包。
我的意思是一个UDP包花了一段时间旅行。数据包甚至可以比先前的数据包更早到达目的地。那么旅行多长时间？ – cshu
你不明白，UDP不关心这一点。对于TCP来说非常重要，但是一个UDP数据包到达那里时会到达那里，或者它没有到达，并且UDP不关心。使用UDP的应用程序可能很在意，但这是依赖于应用程序的，UDP不关心。 –
根据您的编辑，这取决于使用UDP的应用程序。 UDP本身并没有以任何特定的顺序寻找任何特定的数据包。从网络协议的角度来看，这个问题没有任何意义;这是一个应用程序问题。有些应用程序很在意，他们已经实现了自己的可靠性程序，或者他们使用TCP。 –