sockets - 持续传输数据的客户端和服务器的最佳套接字选项

Question

我正在使用 Java(尽管我认为大多数语言都实现了套接字选项)来实现客户端和服务器。服务器将数据发送到客户端进行处理，客户端确认。然后在另一个端口上，客户端将处理结果发送回服务器。当涉及到诸如

之类的选项时

• SO_LINGER
• SO_KEEPALIVE
• SO_NODELAY
• SO_REUSEADDRESS
• SO_SENDBUFFER
• SO_RECBUFFER
• TCP_NODELAY

我们注意到客户端和服务器之间的连接偶尔会中断。发送或接收会有超时。发生这种情况时会终止套接字并打开一个新的继续。

根据上述情况设置的最佳选项是什么？我们可以从我们这边(以编程方式或选项方式)做些什么来尽量减少连接断开的次数。我们使用的是普通 TCP/IP。

更新:这方面的赏金很快就会结束。我还没有一个满意的答案，所以它仍然是开放的。我认为每个人都错过了任务的重点。对于持续聊天的套接字，上述选项的最佳实践是什么。我已经收到了一个 ping 数据包，如果没有工作要做(几乎没有这种情况)，发送的正常消息没有内部元素，所以总是有处理。

Answer 1

严格来说，您不需要任何这些套接字选项:

* SO_LINGER

只有在 close(2) 或 shutdown(2) 有未完成的数据包要发送时，您才需要设置 SO_LINGER被调用。并不真正适用于您的应用程序。

* SO_KEEPALIVE

每两个小时发送一次keepalive-pings实际上只会帮助非常长的但非常安静的连接通过有状态的防火墙并且 session 超时非常长。 (两次 ping 之间的时间太长了，在当今的互联网上不实用。)

* SO_NODELAY

这(可能是 TCP_NODELAY 的别名)禁用 Nagle's algorithm ，这只是一个小包规避问题。也许 Nagle 妨碍了您的应用程序，但它需要特殊的数据包序列才能在处理过程中引入 500 毫秒的延迟；它从不只是挂起连接。

* SO_REUSEADDRESS

适用于所有监听知名端口号的“服务器”；在“客户端”上使用几乎总是掩盖一些错误或其他错误，但如果请求必须来自众所周知的端口号，有时这是必要的。

* SO_SENDBUFFER
* SO_RECBUFFER

当您的程序(接收缓冲区)或套接字(发送缓冲区)尚未准备好接受更多数据时，这些缓冲区大小会影响为接收或发送数据而维护的内核端缓冲区大小。如果这些设置太小，您的应用程序可能无法尽可能平滑地传输数据，从而降低吞吐量，但如果这些设置小于最佳值，则不会导致任何停顿。当然，太大可能会对内核内存提出不合理的要求，但应该有一个合理的系统范围最大允许大小。

* TCP_NODELAY

禁用 Nagle。如果您的应用程序在尝试阻塞读取之前发送多个小数据包，则不会超过 500 毫秒的延迟。

真的，您不需要设置任何套接字选项。

您能否将您的代码提炼成可以粘贴到此处并进行测试或检查的内容？我已经习惯了 TCP session 可以毫无问题地存活数天或数周，所以这非常令人惊讶。