java - 如何实现 TCP 出站消息的重试策略

Question

我有一个系统，它使用 Java 通过 TCP 套接字向外部系统发送消息。如果我们想尽最大努力确保发送的消息能够被接收，我们是否需要执行重试逻辑，以防在 send 方法中捕获网络故障？

在我看来，没有必要重试，因为它已经由 TCP 在幕后处理。这个论点有效吗？

谢谢!

博

Answer 1

事情没那么简单。

了解 TCP 是一种传输协议(protocol)非常重要。其目的是在机器之间而不是应用程序之间建立可靠的数据流。成功的send并不意味着消息已经被传递，它意味着你的内核已经将消息排队并且很快就会发送。当主机收到消息并确认它时，并不意味着您的应用程序已经调用或将调用 recv 并实际获取数据。

因此，您当然可以依靠套接字错误来检测断开的连接。但是，当连接中断时，您的应用程序将无法仅根据您可以从 TCP 获取的信息来确定已传送的内容以及未传送的内容。

因此，您为程序开发的应用程序级协议(protocol)需要有自己的机制来跟踪应用程序之间成功交付的内容。重新连接和重试机制将是其中的一部分。

示例

1. Alice 通过 TCP 将包含其状态更新的数据包发送给 Bob。在某个时间点，爱丽丝要发送三个更新。 Alice 的 send 调用成功。

2. 鲍勃接收第一个更新。他的机器收到了第二次更新，但在 Bob 第二次调用 recv 之前，机器突然重新启动。

3. 第三次更新被 Bob 办公室的某些安全中间设备丢弃。

4. Alice 然后想再发送一个更新。连接已经处于错误状态，因此发送失败。

此时，Alice 已发送了三个更新，但 Bob 只收到了一个。当 Bob 的机器重新上线并建立新连接时，Alice 和 Bob 需要同步他们的状态，然后才能继续进行。他们需要同步，因为 Alice 实际上并不知道 Bob 能够处理多少个更新。仅基于 TCP，她可能只能对 Bob 的机器已收到多少更新做出有根据的猜测。