Linux上TCP重传的应用控制

问题描述：

对于没有耐心的人：

/proc/sys/net/ipv4/tcp_retries2如何使用或类似方法更改 Linux 中单个连接的值setsockopt()，ioctl()或者是否可能？

更长的描述：

我正在开发一个使用长轮询 HTTP 请求的应用程序。在服务器端，需要知道客户端何时关闭了连接。精度并不重要，但肯定不能是 15 分钟。接近一分钟就可以了。

对于那些不熟悉该概念的人来说，长轮询 HTTP 请求的工作原理如下：

• 客户端发送请求

• 服务器使用 HTTP 标头进行响应，但将响应保持开放。使用分块传输编码，允许服务器在数据可用时发送数据位。

• 当所有数据都发送完毕后，服务器会发送一个“结束块”来表示响应已完成。

在我的应用程序中，服务器会不时向客户端发送“心跳”（默认为 30 秒）。心跳只是一个作为响应块发送的换行符。这是为了保持线路繁忙，以便我们通知连接丢失。

当客户端正确关闭时，不会出现问题。但是当客户端强制关闭时（例如，客户端计算机断电），不会发送 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，或者至少 RFC 不要求这样做。

解决方案 1：

看起来这是在内核 2.6.37 中添加的。
从内核 Git提交差异并从下面的更改日志中摘录；

提交 dca43c75e7e545694a9dd6288553f55c53e2a3a3 作者：Jerry Chu 日期：2010 年 8 月 27 日星期五 19:13:28 +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>

解决方案 2：

我建议，如果KimvaisTCP_USER_TIMEOUT描述的套接字选项可用，请使用它。在没有该套接字选项的旧内核上，您可以反复调用来确定套接字发送队列的大小 - 如果发送队列在超时期限内没有减少，则表明未收到任何 ACK，您可以关闭套接字。SIOCOUTQ ioctl()

解决方案 3：

经过一番思考（和谷歌搜索），我得出的结论是，除非对内核应用某种补丁，否则无法更改单个套接字的值。这对您来说可行吗tcp_retries1？tcp_retries2

否则，您可以使用TCP_KEEPALIVE套接字选项，其目的是检查连接是否仍然处于活动状态（在我看来，这正是您想要实现的目标，因此这是有意义的）。请注意，您需要稍微调整其默认参数，因为默认设置是在大约 2 小时后断开连接！

解决方案 4：

这是我的理解。tcp_retries2 是系统在断开连接之前允许的重新传输次数。因此，如果我们想使用 TCP_USER_TIMEOUT 更改 tcp_retries2 的默认值（该值指定了传输数据可能保持未确认的最长时间），我们必须增加 TCP_USER_TIMEOUT 的值，对吗？

在这种情况下，连接将等待更长时间，并且不会重新传输数据包。如果有错误，请纠正我。

解决方案 5：

int name[] = {CTL_NET, NET_IPV4, NET_IPV4_TCP_RETRIES2};
long value = 0;
size_t size = sizeof(value);
if(!sysctl(name, sizeof(name)/sizeof(name[0]), &value, &size, NULL, 0) {
  value // It contains current value from /proc/sys/net/ipv4/tcp_retries2
}
value = ... // Change value if it needed
if(!sysctl(name, sizeof(name)/sizeof(name[0]), NULL, NULL, &value, size) {
  // Value in /proc/sys/net/ipv4/tcp_retries2 changed successfully
}

使用 C 以编程方式。它至少在 Ubuntu 上有效。但（根据代码和系统变量）看起来它会影响系统中的所有 TCP 连接，而不仅仅是单个连接。