linux tcp 超时重传源码,TCP-聊一聊重传次数

柔光的暖阳◎ 2023-01-21 12:17 6阅读 0赞

在RTO的计算方法中，介绍了RFC6298对于RTO的计算和RTO timer的管理算法。

但有一个重要的问题RFC没有提到，那就是如果出现了超时重传，那重传多少次可以放弃呢？

当然这是一个实现相关的细节，不同的操作系统可能有不同的实现策略。

在这篇wiki中，就来介绍一下Linux中是怎么限制超时重传次数的。

1 听说Linux有两个参数限制超时重传次数

没错，Linux中确实定义了两个参数来限定超时重传的次数的，以下是源码中Documentation/networking/ip-sysctl.txt文档中的描述

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\_retries1这个阈值后，到底是report了怎样一种suspicion呢？

tcp\_retries1和tcp\_retries2的数字是表示RTO重传的次数上限，对吗？

文档中提到，924.6s is a lower bound for the effective timeout。

这里的effective timeout是指什么？为什么是lower bound，tcp\_retries2不应该是限制重传次数的upper bound吗？

下面就结合Linux 3.10的源码来逐个解释一下以上几个问题。并在最后给出一个总结。

2 重传超过tcp\_retries1会怎样

文档中说的suspicion到底是什么呢？来看一下tcp\_retries1相关的代码部分

// RTO timer的处理函数是tcp\_retransmit\_timer()，与tcp\_retries1相关的代码调用关系如下

tcp\_retransmit\_timer()

=> tcp\_write\_timeout() // 判断是否重传了足够的久

=> retransmit\_timed\_out(sk, sysctl\_tcp\_retries1, 0, 0) // 判断是否超过了阈值

// tcp\_write\_timeout()的具体相关内容

...

if ((1 << sk->sk\_state) & (TCPF\_SYN\_SENT | TCPF\_SYN\_RECV)) \{

// 如果超时发生在三次握手期间，此时有专门的tcp\_syn\_retries来负责限定重传次数

...

\} else \{ // 如果超时发生在数据发送期间

// 这个函数负责判断重传是否超过阈值，返回真表示超过。后续会详细分析这个函数

if (retransmits\_timed\_out(sk, sysctl\_tcp\_retries1, 0, 0)) \{

/\* Black hole detection \*/

tcp\_mtu\_probing(icsk, sk); // 如果开启tcp\_mtu\_probing(默认关闭)了，则执行PMTU

dst\_negative\_advice(sk); // 更新路由缓存

...

从以上的代码可以看到，一旦重传超过阈值tcp\_retries1，主要的动作就是更新路由缓存。

用以避免由于路由选路变化带来的问题。

3 重传超过tcp\_retries2会怎样

会直接放弃重传，关闭TCP流

// 依然还是在tcp\_write\_timeout()中，retry\_until一般是tcp\_retries2

...

if (retransmits\_timed\_out(sk, retry\_until, syn\_set ? 0 : icsk->icsk\_user\_timeout, syn\_set)) \{

/\* Has it gone just too far? \*/

tcp\_write\_err(sk); // 调用tcp\_done关闭TCP流

return 1;

4 retries限制的重传次数吗

咋一看文档，很容易想到retries的数字就是限定的重传的次数，甚至源码中对于retries常量注释中都写着”This is how many retries it does…”

\#define TCP\_RETR1 3 /\*

\* This is how many retries it does before it

\* tries to figure out if the gateway is

\* down. Minimal RFC value is 3; it corresponds

\* to ~3sec-8min depending on RTO.

\*/

\#define TCP\_RETR2 15 /\*

\* This should take at least

\* 90 minutes to time out.

\* RFC1122 says that the limit is 100 sec.

\* 15 is ~13-30min depending on RTO.

\*/

那就就来看看retransmits\_timed\_out的具体实现，看看到底是不是限制的重传次数

/\* This function calculates a "timeout" which is equivalent to the timeout of a

\* TCP connection after "boundary" unsuccessful, exponentially backed-off

\* retransmissions with an initial RTO of TCP\_RTO\_MIN or TCP\_TIMEOUT\_INIT if

\* syn\_set flag is set.

\*/

static bool retransmits\_timed\_out(struct sock \*sk,

unsigned int boundary,

unsigned int timeout,

bool syn\_set)

unsigned int linear\_backoff\_thresh, start\_ts;

// 如果是在三次握手阶段，syn\_set为真

unsigned int rto\_base = syn\_set ? TCP\_TIMEOUT\_INIT : TCP\_RTO\_MIN;

if (!inet\_csk(sk)->icsk\_retransmits)

return false;

// retrans\_stamp记录的是数据包第一次发送的时间，在tcp\_retransmit\_skb()中设置

if (unlikely(!tcp\_sk(sk)->retrans\_stamp))

start\_ts = TCP\_SKB\_CB(tcp\_write\_queue\_head(sk))->when;

else

start\_ts = tcp\_sk(sk)->retrans\_stamp;

// 如果用户态未指定timeout，则算一个出来

if (likely(timeout == 0)) \{

/\* 下面的计算过程，其实就是算一下如果以rto\_base为第一次重传间隔，

\* 重传boundary次需要多长时间

\*/

linear\_backoff\_thresh = ilog2(TCP\_RTO\_MAX/rto\_base);

if (boundary <= linear\_backoff\_thresh)

timeout = ((2 << boundary) - 1) \* rto\_base;

else

timeout = ((2 << linear\_backoff\_thresh) - 1) \* rto\_base +

(boundary - linear\_backoff\_thresh) \* TCP\_RTO\_MAX;

// 如果数据包第一次发送的时间距离现在的时间间隔，超过了timeout值，则认为重传超于阈值了

return (tcp\_time\_stamp - start\_ts) >= timeout;

从以上的代码分析可以看到，真正起到限制重传次数的并不是真正的重传次数。

而是以tcp\_retries1或tcp\_retries2为boundary，以rto\_base(如TCP\_RTO\_MIN 200ms)为初始RTO，计算得到一个timeout值出来。如果重传间隔超过这个timeout，则认为超过了阈值。

上面这段话太绕了，下面举两个个例子来说明

以判断是否放弃TCP流为例，如果tcp\_retries2=15，那么计算得到的timeout=924600ms。

1. 如果RTT比较小，那么RTO初始值就约等于下限200ms

由于timeout总时长是924600ms，表现出来的现象刚好就是重传了15次，超过了timeout值，从而放弃TCP流

2. 如果RTT较大，比如RTO初始值计算得到的是1000ms

那么根本不需要重传15次，重传总间隔就会超过924600ms。

比如我测试的一个RTT=400ms的情况，当tcp\_retries2=10时，仅重传了3次就放弃了TCP流

5 另外几个小问题

理解了Linux决定重传次数的真实机制，就不难回答一下几个问题了

>> effective timeout指的是什么？

<< 就是retransmits\_timed\_out计算得到的timeout值

>> 924.6s是怎么算出来的？

<< 924.6s = (( 2 << 9) -1) \* 200ms + (15 - 9) \* 120s

>> 为什么924.6s是lower bound？

<< 重传总间隔必须大于timeout值，即 (tcp\_time\_stamp - start\_ts) >= timeout

>> 那RTO超时的间隔到底是不是源码注释的"15 is ~13-30min depending on RTO."呢？

<< 显然不是! 虽然924.6s(15min)是一个lower bound，但是它同时也是一个upper bound!

怎么理解？举例说明

1. 如果某个RTO值导致，在已经重传了14次后，总重传间隔开销是924s

那么它还需要重传第15次，即使离924.6s只差0.6s。这就是发挥了lower bound的作用

2. 如果某个RTO值导致，在重传了10次后，总重传间隔开销是924s

重传第11次后，第12次超时触发时计算得到的总间隔变为1044s，超过924.6s

那么此时会放弃第12次重传，这就是924.6s发挥了upper bound的作用

总的来说，在Linux3.10中，如果tcp\_retres2设置为15。总重传超时周期应该在如下范围内

\[924.6s, 1044.6s)

所以综合上述，Linux并不是直接拿tcp\_retries1和tcp\_retries2来限制重传次数的，而是用计算得到

的一个timeout值来判断是否要放弃重传的。真正的重传次数同时与RTT相关。

linux tcp 超时重传源码,TCP-聊一聊重传次数

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 linux tcp 超时重传源码,TCP-聊一聊重传次数

相关 TCP协议-TCP超时重传机制

相关【原创】TCP超时重传机制探索

相关 TCP 的超时与重传

相关 TCP/IP详解学习笔记(12)-TCP的超时与重传

相关 TCP超时与重传

相关 TCP重传

相关 TCP-超时与重传

相关 TCP之超时重传机制

相关 TCP/IP笔记三.运输层(3)——TCP超时重传算法