我讀了一些關於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。 –