当该值大于 0 时，它指定在 TCP 强制关闭相应连接并向应用程序返回 ETIMEDOUT 之前，传输的数据可能保持未确认的最长时间（以毫秒为单位）。
非常短的 USER TIMEOUT 值会影响高延迟路径上的 TCP 传输。如果在未完成段的确认到达之前发生用户超时（可能是由于数据包丢失），则连接将关闭。许多 TCP 实现默认将 USER TIMEOUT 值设置为几分钟。虽然 UTO 选项允许建议短超时，但宣传它们的应用程序应考虑这些影响。
我预计 2 毫秒的 TCP_USER_TIMEOUT 会产生灾难性的后果：在 RTT 小于 2 毫秒的网络中，发送的每个 TCP 数据包都会在等待 ACK 时超时，并且连接将被关闭。但是，在我的环境中，我没有遇到这种情况。可以建立连接，数据可以正常发送和接收。但是，我确实注意到，如果我拔掉电源线或关闭接收接口，TCP_USER_TIMEOUT 确实可以有效地检测到连接丢失，并且连接会及时关闭。因此，TCP_USER_TIMEOUT 正在工作，只是不像我期望的那样。
我对 TCP_USER_TIMEOUT 有什么误解？为什么低于 RTT 的值不会导致连接断开？
如果有帮助的话，我的客户端是带有 2.6.32 内核的 Scientific Linux 6.1 机箱。
答案1
Linux 中的 UTO 实现不准确，最近已由此补丁集修复：（以防您不是此补丁集的作者）： https://lkml.org/lkml/2018/7/18/1090
但是，即使在 UTO 触发后，主机也会停止重传并进入 TCP_CLOSE 状态，但不会重置连接。应用程序有责任发送 RST。