linux tcp项目,Linux上TCP重传的应用控制

对于不耐烦的人：

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

更长的描述：

我正在开发一个使用长轮询HTTP请求的应用程序。在服务器端，当客户端关闭连接时，需要知道它。准确性并不重要，但肯定不会超过15分钟。更接近一分钟就行了。

对于不熟悉这个概念的人来说，长时间的轮询HTTP请求如下：

>客户端发送请求

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

>当发送所有数据时，服务器发送一个“关闭块”，表示响应完成。

在我的应用程序中，服务器会立即向客户端发送“心跳”(默认为30秒)。心跳只是作为响应块发送的换行符。这意味着保持线路忙，以便我们通知连接丢失。

当客户端正确关闭时，没有问题。但是当它被强制关闭时(例如客户端计算机掉电)，则不会发送TCP复位。在这种情况下，服务器发送心跳，客户端不发送ACK。此后，服务器在放弃并向应用层(我们的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不需要。