SYN和RTO

LA0WAN9

发布于 2021-12-14 00:47:19

84700

代码可运行

运行总次数：0

代码可运行

前两天，我在微博上推荐了一篇朝花夕拾的文章：The story of one latency spike，文章中介绍了 cloudflare 工程师如何一步一步 debug 网络延迟问题，细细读来受益良多，不过我并不打算详细介绍那篇文章的细枝末节，本文只摘录一个点：

When debugging network problems the delays of 1s, 30s are very characteristic. They may indicate packet loss since the SYN packets are usually retransmitted at times 1s, 3s, 7s, 15, 31s.

为什么是 1 秒、3 秒、7 秒、15 秒、31 秒？说来惭愧，我以前从没有注意过 SYN 重建时的时间特征，知耻而后勇，正好借此机会来一探究竟。

下面让我们通过一个实验来重现一下 SYN 超时重传的现象：

在服务端屏蔽请求：「iptables -A INPUT –dport 1234 –syn -j DROP」
在服务端监听 1234 端口：「nc -l 1234」
在客户端开启抓包：「tcpdump -nn -i any port 1234」
在客户端发起请求：「date; nc <SERVER> 1234; date」

经过一段时间的等待后，我们可以看到 tcpdump 输出如下：

12:53:15.511826 IP CLIENT.53384 > SERVER.1234: Flags [S], ...
12:53:16.511042 IP CLIENT.53384 > SERVER.1234: Flags [S], ...
12:53:18.511058 IP CLIENT.53384 > SERVER.1234: Flags [S], ...
12:53:22.511042 IP CLIENT.53384 > SERVER.1234: Flags [S], ...
12:53:30.511065 IP CLIENT.53384 > SERVER.1234: Flags [S], ...
12:53:46.511068 IP CLIENT.53384 > SERVER.1234: Flags [S], ...

第一行是正常发出的 SYN，后面五行是超时重传发出的 SYN，相对于正常发出的 SYN，它们的延迟分别是：1 秒、3 秒、7 秒、15 秒、31 秒，正好符合开头的描述。之所以重传五次是因为 net.ipv4.tcp_syn_retries 的缺省值是 5。

此外，我们可以看到两次 date 命令输出的时间如下：

Sun Aug 13 12:53:15 CST 2017
Sun Aug 13 12:54:18 CST 2017

可见整个握手过程从开始到超时一共持续了 63 秒，其中 31 秒是总计五次 SYN 发送的时间，剩下的 32 秒是确认第五次 SYN 超时的时间（2 的 5 次方）。由此可见，在握手阶段一旦出现严重丢包，网络延迟会非常久，很多时候这是没有必要的，比如 Web 服务器，可以考虑设置 net.ipv4.tcp_syn_retries 为 2 或者 3 比较合适，一旦出现严重丢包，与其不断重传，不如及时放弃。

如果要研究得更深入些，我们还需要了解 RTO（retransmission timeout），即超时重传时间，具体计算方法很复杂，我就不多说了，有兴趣的可以参考本文解决的推荐链接，你只要知道系统会根据网络连接的情况动态调整该值的大小即可。不过在 SYN 握手阶段，网络连接还没有建立起来，如果此时发生丢包，那么因为系统没有可以参照的 RTT（Round-Trip Time），所以此时只能给出系统缺省设置的 RTO：

#define TCP_RTO_MAX	((unsigned)(120*HZ))
#define TCP_RTO_MIN	((unsigned)(HZ/5))
#define TCP_TIMEOUT_INIT ((unsigned)(1*HZ))

...

unsigned long timeo;

if (req->num_timeout++ == 0)
    atomic_dec(&queue->young);
timeo = min(TCP_TIMEOUT_INIT << req->num_timeout, TCP_RTO_MAX);
mod_timer(&req->rsk_timer, jiffies + timeo);
return;