Sockets 是否需要通过TCP进行应用程序级重传和确认？

我有以下疑问：

1） 如果使用的传输协议是TCP，TCP是否保证数据包的传输，因此是否需要应用程序级的重新传输。假设我在客户端和服务器之间建立了TCP连接，服务器向客户端发送消息。然而，客户端离线，并且只有在10小时后才会返回，那么TCP堆栈将处理重新传输并向客户端传递消息，还是服务器上运行的应用程序需要处理它

2） 与上述问题相关，如果传输协议是TCP，是否需要应用程序级ACK。应用程序确认的一个原因是，如果没有它，应用程序将不知道远程端何时收到消息。除此之外还有其他原因吗？意思是消息本身的传递有保证吗

如果使用的传输协议是TCP，TCP是否保证数据包的传输，因此是否需要应用程序级的重新传输

TCP保证将消息流字节传递到TCP连接另一端的TCP层。因此，应用程序不必担心重传的细微差别。然而，在将其视为绝对答案之前，请阅读我的其余答案

然而，客户端离线，并且只有在10小时后才会返回，那么TCP堆栈将处理重新传输并向客户端传递消息，还是服务器上运行的应用程序需要处理它

不，不是真的。即使TCP对单个TCP数据包具有某种程度的重试逻辑，但如果远程端点断开连接，它也无法执行重新连接。换句话说，它最终将“超时”等待从远程端获取TCP ACK并重试几次。但最终将放弃，并通过套接字接口通知应用程序远程端点连接处于死状态或关闭状态。典型的模式是，当客户端应用程序检测到它丢失了与服务器的套接字连接时，它要么向应用程序的用户界面报告错误，要么重试连接。无论哪种方式，如何处理失败的TCP连接都是应用程序级的决定

如果传输协议为TCP，是否需要应用程序级确认

是的，绝对是。大多数客户机-服务器协议都有一些消息请求/响应对的概念。TCP套接字只能向应用程序指示应用程序“发送”的数据是否成功排队到内核的网络堆栈。它不保证远程端套接字顶部的应用程序实际“获取”或“处理”。TCP之上的协议应该在处理消息时提供某种响应指示。这里使用HTTP作为一个很好的例子。想象一下，如果应用程序将向服务器发送HTTP POST消息，但没有来自服务器的确认（例如200 OK）。客户机如何知道服务器处理了它

在网络地址转换器（NAT）和代理服务器的世界中，当NAT或代理代表实际端点关闭连接时，空闲的TCP连接（彼此之间没有数据）可能会失败，因为它感知到发送的数据不足。解决方案是使用某种周期性的“ping”和“pong”协议，通过这种协议，应用程序可以在没有数据发送的情况下保持TCP连接的活动状态