我有以下疑问：
1) TCP 是否保证数据包的传递，因此如果使用的传输协议是 TCP，则需要应用程序级别的重新传输。假设我已经在客户端和服务器之间建立了 TCP 连接，并且服务器向客户端发送了一条消息。然而，客户端离线并在 10 小时后才回来，那么 TCP 堆栈将处理重新传输并将消息传递给客户端，还是运行在服务器上的应用程序需要处理它？
2) 与上述问题相关，如果传输协议是 TCP，是否需要应用程序级别的 ACK。应用程序 ACK 的一个原因是没有它，应用程序将不知道远程端何时收到消息。除此之外还有什么原因吗？意思是消息本身的传递是否得到保证？
【问题讨论】：
如果使用的传输协议是 TCP，TCP 是否保证数据包的传递，因此是否需要应用程序级别的重新传输
TCP 保证将消息流字节传送到 TCP 连接另一端的 TCP 层。因此，应用程序不必为重新传输的细微差别而烦恼。但是，在将其作为绝对答案之前，请阅读我的其余答案。
但是客户端下线并在 10 小时后才回来，那么 TCP 堆栈将处理重新传输并将消息传递给客户端，还是运行在服务器上的应用程序需要处理它？
不，不是真的。即使 TCP 对单个 TCP 数据包有一定程度的重试逻辑，如果远程端点断开连接，它也无法执行重新连接。换句话说，它最终会“超时”等待从远程端获取 TCP ACK 并重试几次。但最终会放弃并通过socket接口通知应用程序远程端点连接处于死或关闭状态。典型的模式是，当客户端应用程序检测到它丢失与服务器的套接字连接时，它要么向应用程序的用户界面报告错误，要么重试连接。无论哪种方式，如何处理失败的 TCP 连接都是应用程序级别的决定。
如果传输协议是 TCP，是否需要应用程序级别的 ACK
是的，当然。大多数客户端-服务器协议都有一些请求/响应消息对的概念。如果应用程序“发送”的数据成功排队到内核的网络堆栈，TCP 套接字只能向应用程序指示。它不保证远程端套接字顶部的应用程序实际上“得到它”或“处理它”。在处理消息时，您基于 TCP 的协议应该提供某种响应指示。在这里使用 HTTP 作为一个很好的例子。想象一下，如果应用程序将向服务器发送 HTTP POST 消息，但没有来自服务器的确认（例如 200 OK）。客户端如何知道服务器处理了它？
在网络地址转换器 (NAT) 和代理服务器的世界中，空闲的 TCP 连接（彼此之间没有数据）可能会失败，因为 NAT 或代理代表实际端点关闭连接，因为它认为缺少正在发送的数据。解决方案是使用某种周期性的“ping”和“pong”协议，应用程序可以通过该协议在没有数据发送的情况下保持 TCP 连接处于活动状态。
【讨论】：