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