是否需要通過TCP進行應用程序級重傳和確認？

Question

我有以下問題：

1）TCP是否保證分組的傳送，因此如果使用的傳輸協議是TCP，則需要應用級重傳。 假設我已經在客戶端和服務器之間建立了TCP連接，並且服務器向客戶端發送消息。 然而，客戶端脫機並且僅在說了10個小時后才返回，因此TCP堆棧會處理重新傳輸並將消息傳遞給客戶端還是服務器上運行的應用程序需要處理它？

2）與上述問題相關的是，如果傳輸協議是TCP，則需要應用級別ACK。 應用程序ACK的一個原因是沒有它，應用程序將不知道遠程端何時收到消息。 除此之外有什么理由嗎？ 意思是保證郵件本身的傳遞？

Answer 1

TCP是否保證數據包的傳送，因此如果使用的傳輸協議是TCP，則需要應用程序級重新傳輸

TCP保證將消息流字節傳遞到TCP連接另一端的TCP層。 因此，應用程序不應該擔心重新傳輸的細微差別。 但是，在將其作為絕對答案之前，先閱讀我的其余部分。

然而，客戶端脫機並且僅在說了10個小時后才返回，因此TCP堆棧會處理重新傳輸並將消息傳遞給客戶端還是服務器上運行的應用程序需要處理它？

不，不是真的。 即使TCP對單個TCP數據包具有某種程度的重試邏輯，但如果遠程端點斷開連接，它也無法執行重新連接。 換句話說，它最終將“超時”等待從遠程端獲得TCP ACK並進行一些重試。 但最終將放棄並通過套接字接口通知應用程序遠程端點連接處於死或關閉狀態。 典型模式是當客戶端應用程序檢測到它丟失了與服務器的套接字連接時，它會向應用程序的用戶界面報告錯誤或重試連接。 無論哪種方式，它的應用程序級別決定如何處理失敗的TCP連接。

是傳輸協議是TCP所需的應用程序級別的ACK

是的，一點沒錯。 大多數客戶端 - 服務器協議都有一些請求/響應消息的概念。 TCP套接字只能向應用程序指示應用程序“發送”的數據是否成功排隊到內核的網絡堆棧。 它不能保證遠程端套接字頂部的應用程序實際上“得到它”或“處理它”。 在處理消息時，TCP上的協議應提供某種響應指示。 在這里使用HTTP作為一個很好的例子。 想象一下，如果應用程序將HTTP POST消息發送到服務器，但是沒有來自服務器的確認（例如200 OK）。 客戶如何知道服務器處理它？

在網絡地址轉換器（NAT）和代理服務器的世界中，空閑的TCP連接（彼此之間沒有數據）可能會失敗，因為NAT或代理代表實際端點關閉連接，因為它認為缺少數據發送。 解決方案是使用某種周期性的“ping”和“pong”協議，通過該協議，應用程序可以在沒有數據發送的情況下保持TCP連接存活。