对于不耐烦的人:
如何在 Linux 中为单个连接更改 /proc/sys/net/ipv4/tcp_retries2 的值，使用 setsockopt(), ioctl( ) 之类的，或者有可能吗？
更长的说明:
我正在开发一个使用长轮询 HTTP 请求的应用程序。在服务器端，需要知道客户端何时关闭连接。准确性并不重要，但肯定不能是 15 分钟。接近一分钟就可以了。
对于不熟悉这个概念的人来说，长轮询 HTTP 请求的工作方式如下:
- 客户端发送请求
- 服务器使用 HTTP header 进行响应，但将响应保持打开状态。使用分 block 传输编码，允许服务器在数据位可用时发送它们。
- 当所有数据都发送完毕后，服务器会发送一个“关闭 block ”来表示响应完成。
在我的应用程序中，服务器每隔一段时间(默认为 30 秒)向客户端发送“心跳”。心跳只是作为响应 block 发送的换行符。这是为了保持线路繁忙，以便我们通知连接丢失。
客户端正常关机没有问题。但是当它被强制关闭时(例如，客户端机器断电)，不会发送 TCP 重置。在这种情况下，服务器发送一个心跳，客户端不确认。在此之后，服务器在放弃并向应用层(我们的 HTTP 服务器)报告失败后继续重传数据包大约 15 分钟。对我来说，等待 15 分钟太长了。
我可以通过在/proc/sys/net/ipv4/中写入以下文件来控制重传时间:
tcp_retries1 - INTEGER
This value influences the time, after which TCP decides, that
something is wrong due to unacknowledged RTO retransmissions,
and reports this suspicion to the network layer.
See tcp_retries2 for more details.
RFC 1122 recommends at least 3 retransmissions, which is the
default.
tcp_retries2 - INTEGER
This value influences the timeout of an alive TCP connection,
when RTO retransmissions remain unacknowledged.
Given a value of N, a hypothetical TCP connection following
exponential backoff with an initial RTO of TCP_RTO_MIN would
retransmit N times before killing the connection at the (N+1)th RTO.
The default value of 15 yields a hypothetical timeout of 924.6
seconds and is a lower bound for the effective timeout.
TCP will effectively time out at the first RTO which exceeds the
hypothetical timeout.
RFC 1122 recommends at least 100 seconds for the timeout,
which corresponds to a value of at least 8.
tcp_retries2的默认值确实是8，我15分钟(900秒)重传的经验和上面引用的内核文档是一致的。
例如，如果我将 tcp_retries2 的值更改为 5，则连接断开的速度会更快。但是这样设置会影响系统中的所有连接，我真的很想只为这个长轮询连接设置它。
引用 RFC 1122:
4.2.3.5 TCP Connection Failures
Excessive retransmission of the same segment by TCP
indicates some failure of the remote host or the Internet
path. This failure may be of short or long duration. The
following procedure MUST be used to handle excessive
retransmissions of data segments [IP:11]:
(a) There are two thresholds R1 and R2 measuring the amount
of retransmission that has occurred for the same
segment. R1 and R2 might be measured in time units or
as a count of retransmissions.
(b) When the number of transmissions of the same segment
reaches or exceeds threshold R1, pass negative advice
(see Section 3.3.1.4) to the IP layer, to trigger
dead-gateway diagnosis.
(c) When the number of transmissions of the same segment
reaches a threshold R2 greater than R1, close the
connection.
(d) An application MUST be able to set the value for R2 for
a particular connection. For example, an interactive
application might set R2 to "infinity," giving the user
control over when to disconnect.
(e) TCP SHOULD inform the application of the delivery
problem (unless such information has been disabled by
the application; see Section 4.2.4.1), when R1 is
reached and before R2. This will allow a remote login
(User Telnet) application program to inform the user,
for example.
在我看来，Linux 中的 tcp_retries1 和 tcp_retries2 对应于 RFC 中的 R1 和 R2。 RFC 明确指出(在 d 项中)符合要求的实现必须允许设置 R2 的值，但我发现无法使用 setsockopt() 来设置，ioctl() 之类的。
另一种选择是在超过 R1 时收到通知(项目 e)。但是，这不如设置 R2 好，因为我认为 R1 很快(几秒钟内)就会被命中，并且 R1 的值code> 不能为每个连接设置，或者至少 RFC 不需要它。
最佳答案
看起来这是在内核 2.6.37 中添加的。 来自内核 Git 的 Commit diff 和以下 change log 的摘录；
commit dca43c75e7e545694a9dd6288553f55c53e2a3a3 Author: Jerry Chu Date: Fri Aug 27 19:13:28 2010 +0000
tcp: Add TCP_USER_TIMEOUT socket option. This patch provides a "user timeout" support as described in RFC793. The socket option is also needed for the the local half of RFC5482 "TCP User Timeout Option". TCP_USER_TIMEOUT is a TCP level socket option that takes an unsigned int, when > 0, to specify the maximum amount of time in ms that transmitted data may remain unacknowledged before TCP will forcefully close the corresponding connection and return ETIMEDOUT to the application. If 0 is given, TCP will continue to use the system default. Increasing the user timeouts allows a TCP connection to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows applications to "fail fast" if so desired. Otherwise it may take upto 20 minutes with the current system defaults in a normal WAN environment. The socket option can be made during any state of a TCP connection, but is only effective during the synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Moreover, when used with the TCP keepalive (SO_KEEPALIVE) option, TCP_USER_TIMEOUT will overtake keepalive to determine when to close a connection due to keepalive failure. The option does not change in anyway when TCP retransmits a packet, nor when a keepalive probe will be sent. This option, like many others, will be inherited by an acceptor from its listener. Signed-off-by: H.K. Jerry Chu <hkchu@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
关于linux - Linux上TCP重传的应用控制，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5907527/