我有以下查詢：通過TCP需要應用級重傳和確認嗎？
1）TCP是否保證數據包的傳輸，因此，如果使用的傳輸協議是TCP，則應用級重新傳輸是必需的。假設我已經在客戶端和服務器之間建立了TCP連接，並且服務器向客戶端發送了一條消息。然而，客戶端脫機並且在10個小時後纔回來，TCP堆棧會如何處理重新傳輸並將消息傳遞給客戶端，或者服務器上運行的應用程序是否需要處理？
2）與上述問題相關的是，如果傳輸協議是TCP，則需要應用級ACK。應用程序確認的一個原因是沒有它，應用程序不知道遠程端何時收到消息。除此之外還有什麼理由嗎？含義是交付的消息本身有保證嗎？
分組是否TCP保證遞送，因而如果使用的傳輸協議是TCP
TCP保證遞送的消息流的字節到TCP層上的另一端部從而永遠需要應用級重傳的TCP連接。因此，應用程序不必擔心重傳的細微差別。然而，在把它作爲一個絕對的東西之前，先閱讀我的答案。
然而，客戶端脫機並且只有在說了10個小時之後纔回來，那麼TCP堆棧會如何處理重新傳輸並將消息傳遞給客戶端，或者服務器上運行的應用程序是否需要處理它？
不，不是真的。即使TCP對各個TCP數據包有某種程度的重試邏輯，但如果遠程端點斷開，它也不能執行重新連接。換句話說，它將最終「超時」，等待從遠程端獲得TCP ACK並重試幾次。但最終會放棄並通過套接字接口通知應用程序遠程端點連接處於已關閉或已關閉狀態。典型模式是，當客戶端應用程序檢測到它丟失與服務器的套接字連接時，它會嚮應用程序的用戶界面報告錯誤或重試連接。無論哪種方式，它都是應用程序級別決定如何處理失敗的TCP連接。
是如果傳輸協議是TCP
是的，絕對必要的應用程序級的ACK。大多數客戶機 - 服務器協議都有一些請求/響應消息的概念。 TCP套接字只能嚮應用程序指示應用程序「發送」的數據是否已成功排隊到內核的網絡堆棧。它不保證遠程端套接字上的應用程序實際上「獲得了」或「處理了它」。在TCP之上的協議應該在處理消息時提供某種響應指示。這裏使用HTTP作爲一個很好的例子。想象一下，如果應用程序將HTTP POST消息發送到服務器，但是沒有從服務器確認（例如200 OK）。客戶端如何知道服務器處理了它？
在網絡地址轉換器（NAT）和代理服務器的世界中，由於NAT或代理關閉代表實際端點的連接，處於空閒狀態（彼此之間無數據）的TCP連接可能會失敗，因爲它感知到缺乏數據發送。解決方案是有某種週期性的「ping」和「pong」協議，通過這種協議，應用程序可以在沒有數據發送的情況下保持TCP連接處於活動狀態。