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

Question

我有以下问题:

1) TCP 是否保证数据包的传送，因此如果使用的传输协议(protocol)是 TCP，则是否需要应用程序级重传。假设我已经在客户端和服务器之间建立了 TCP 连接，服务器向客户端发送了一条消息。然而，客户端离线并在大约 10 小时后才恢复正常，那么 TCP 堆栈是否会处理重新传输和向客户端传递消息，或者服务器上运行的应用程序是否需要处理它？<​​/p>

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

Answer 1

Does TCP guarantee delivery of packets and thus is thus application level re-transmission ever required if transport protocol used is TCP

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

However the client goes offline and comes back only after say 10 hours, so will TCP stack handle re-transmission and delivering message to the client or will the application running on the server need to handle it?

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

is application level ACK needed if transport protocol is TCP

是的，绝对是。大多数客户端-服务器协议(protocol)都有一些请求/响应消息对的概念。如果应用程序“发送”的数据已成功排队到内核的网络堆栈，则 TCP 套接字只能向应用程序指示。它不保证远程端套接字之上的应用程序实际上“得到它”或“处理它”。 TCP 之上的协议(protocol)应该在处理消息时提供某种响应指示。此处以 HTTP 为例。想象一下，如果应用程序向服务器发送 HTTP POST 消息，但没有来自服务器的确认(例如 200 OK)。客户端如何知道服务器处理了它？

在网络地址转换器 (NAT) 和代理服务器的世界中，空闲的 TCP 连接(彼此之间没有数据)可能会失败，因为 NAT 或代理会代表实际端点关闭连接，因为它认为缺少正在发送的数据。解决方案是使用某种周期性的“ping”和“pong”协议(protocol)，应用程序可以通过这些协议(protocol)在没有数据可发送的情况下保持 TCP 连接有效。