对于不耐烦的人:
如何使用/proc/sys/net/ipv4/tcp_retries2
,setsockopt()
等更改Linux中单个连接的ioctl()
值,还是可以?
更长的解密:
我正在开发一个使用长轮询HTTP请求的应用程序。在服务器端,需要知道客户端何时关闭连接。准确性并不重要,但肯定不能是15分钟。接近一分钟就可以了。
对于不熟悉该概念的人,长轮询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()
等进行此操作。< / p>
另一种选择是在超过R1
时收到通知(项目e)。这不如设置R2
那么好,因为我认为R1
很快就会被点击(几秒钟内),并且每个连接都无法设置R1
的值,或者至少RFC不要求它。
答案 0 :(得分:24)
看起来这是在内核2.6.37中添加的。 来自内核Git的Commit diff和摘自change log以下的内容;
提交 dca43c75e7e545694a9dd6288553f55c53e2a3a3 作者:朱镕基 日期:8月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>
答案 1 :(得分:13)
我建议如果Kimvais描述的TCP_USER_TIMEOUT
套接字选项可用,则使用该选项。在没有该套接字选项的旧内核上,您可以重复调用SIOCOUTQ
ioctl()
来确定套接字发送队列的大小 - 如果发送队列在超时期限内没有减少,那么表示未收到任何ACK,您可以关闭套接字。
答案 2 :(得分:3)
经过一番思考(和谷歌搜索)后,我得出的结论是,除非您对内核应用某种补丁,否则不能更改单个套接字的tcp_retries1
和tcp_retries2
值。这对你来说可行吗?
另外,你可以使用TCP_KEEPALIVE
套接字选项,其目的是检查连接是否仍处于活动状态(在我看来,这正是你想要实现的,所以它有意义)。注意你需要调整一下它的默认参数这一事实,因为默认是在大约2小时后断开连接!!!
答案 3 :(得分:0)
这是我的理解。 tcp_retries2是系统在删除连接之前允许的重传次数。因此,如果我们想要使用TCP_USER_TIMEOUT更改tcp_retries2的默认值,TCP_USER_TIMEOUT指定传输数据可能保持未确认的最大时间,我们必须增加TCP_USER_TIMEOUT对吗?
在这种情况下,conction将等待更长的时间,并且不会重新传输数据包。 如果出现问题,请纠正我。
答案 4 :(得分:-1)
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连接,而不仅仅是一个连接。