Linux上TCP重传的应用程序控制 [英] Application control of TCP retransmission on Linux

问题描述

对于急躁的人:

如何在Linux中使用setsockopt()，ioctl()等更改单个连接的/proc/sys/net/ipv4/tcp_retries2值，或者有可能吗?

How to change the value of /proc/sys/net/ipv4/tcp_retries2 for a single connection in Linux, using setsockopt(), ioctl() or such, or is it possible?

更长的时间:

我正在开发一个使用长时间轮询HTTP请求的应用程序.在服务器端，需要知道客户端何时关闭连接.准确性并不严格，但肯定不能为15分钟.接近一分钟就可以了.

I'm developing an application that uses long polling HTTP requests. On the server side, it needs to be known when the client has closed the connection. The accuracy is not critical, but it certainly cannot be 15 minutes. Closer to a minute would do fine.

对于那些不熟悉此概念的人，长轮询HTTP请求的工作方式如下:

For those not familiar with the concept, a long polling HTTP request works like this:

• 客户端发送请求
• 服务器使用HTTP标头进行响应，但响应保持打开状态.使用分块传输编码，允许服务器在数据可用时发送数据.
• 所有数据发送完毕后，服务器将发送一个关闭块"以表示响应已完成.

在我的应用程序中，服务器此后每隔一段时间(默认30秒)向客户端发送心跳".心跳只是作为响应块发送的换行符.这是为了保持线路繁忙，以便我们通知连接丢失.

In my application, the server sends "heartbeats" to the client every now an then (30 seconds by default). A heartbeat is just a newline character that is sent as a response chunk. This is meant to keep the line busy so that we notify the connection loss.

客户端正确关闭时没有问题.但是，如果强行关闭它(例如，客户端计算机断电)，则不会发送TCP重置.在这种情况下，服务器将发送一个心跳信号，客户端不会对其进行确认.此后，在放弃并向应用程序层(我们的HTTP服务器)报告故障之后，服务器将继续重传数据包大约15分钟.在我的情况下，等待15分钟太长了.

There's no problem when the client shuts down correctly. But when it's shut down with force (the client machine loses power, for example), a TCP reset is not sent. In this case, the server sends a heartbeat, which the client doesn't ACK. After this, the server keeps retransmitting the packet for roughly 15 minutes after giving up and reporting the failure to the application layer (our HTTP server). And 15 minutes is too long a wait in my case.

我可以通过写入/proc/sys/net/ipv4/中的以下文件来控制重传时间:

I can control the retransmission time by writing to the following files in /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秒)的重传时间与上面引用的内核文档一致.

The default value of tcp_retries2 is indeed 8, and my experience of 15 minutes (900 seconds) of retransmission is in line with the kernel documentation quoted above.

例如，如果将tcp_retries2的值更改为5，则连接死亡的速度更快.但是像这样设置它会影响系统中的所有连接，我真的很想只为这个长轮询连接设置它.

If I change the value of tcp_retries2 to 5 for example, the connection dies much more quicker. But setting it like this affects all the connections in the system, and I'd really like to set it for this one long polling connection only.

RFC 1122的引文:

A quote from 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()等来实现它.

It seems to me that tcp_retries1 and tcp_retries2 in Linux correspond to R1 and R2 in the RFC. The RFC clearly states (in item d) that a conforming implementation MUST allow setting the value of R2, but I have found no way to do it using setsockopt(), ioctl() or such.

另一个选择是当超过R1时获得通知(项目e).但是，这不如设置R2那样好，因为我认为R1很快就会被击中(几秒钟)，并且不能为每个连接设置R1的值，或者至少RFC没有设置.不需要它.

Another option would be to get a notification when R1 is exceeded (item e). This is not as good as setting R2, though, as I think R1 is hit pretty soon (in a few seconds), and the value of R1 cannot be set per connection, or at least the RFC doesn't require it.

推荐答案

在内核2.6.37中添加了类似的内容. 从内核Git 提交diff 和摘录自下面的更改日志；

Looks like this was added in Kernel 2.6.37. Commit diff from kernel Git and Excerpt from change log below;

提交 dca43c75e7e545694a9dd6288553f55c53e2a3a3 作者:杰里·朱(Jerry Chu) 日期:2010年8月27日星期五19:13:28 +0000

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 <[e-mail]>
Signed-off-by: David S. Miller <[e-mail]>

这篇关于Linux上TCP重传的应用程序控制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！