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