急切者请注意：
如何在Linux中为单个连接更改/proc/sys/net/ipv4/tcp_retries2的值，使用setsockopt()、ioctl()或类似方法，或者是否可能？
更长的描述：
我正在开发一个使用长轮询HTTP请求的应用程序。在服务器端，需要知道客户端何时关闭了连接。准确性并不是关键，但肯定不能是15分钟。接近一分钟就可以。
对于那些不熟悉这个概念的人，长轮询HTTP请求的工作方式如下：
- 客户端发送一个请求
- 服务器响应HTTP头，但保持响应打开。使用分块传输编码，允许服务器在数据可用时发送数据块。
- 当所有数据都发送完毕时，服务器发送一个“关闭块”，表示响应已完成。
在我的应用程序中，服务器每隔一段时间（默认为30秒）向客户端发送“心跳”。心跳只是作为响应块发送的换行符。这旨在保持线路繁忙，以便我们通知连接丢失。
当客户端正确关闭时没有问题。但是当它被强制关闭时（例如，客户端机器断电），不会发送TCP复位。在这种情况下，服务器发送一个心跳，客户端不会ACK。此后，服务器会保持重发该数据包约15分钟之久，然后放弃并将失败报告给应用程序层（我们的HTTP服务器）。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的值，至少RFC没有要求这样做。