首页 > 代码库 > 关于Linux TCP接收缓存以及接收窗口的一个细节解析
关于Linux TCP接收缓存以及接收窗口的一个细节解析
关于TCP的接收缓存以及通告窗口，一般而言懂TCP的都能说出个大概，但是涉及到细节的话可能理解就不那么深入了。由于我最近的工作与TCP有关，顺便又想起了很久之前遇到的一个问题：
明明在接收端有8192字节的接收缓存，为什么收了不到8000字节的数据就ZeroWindow了呢？
当时我的解决方案是直接扩大接收缓存完事，然后就没有然后了。后来深挖了一下细节，发现了很多曾经不知道的东西，如今对TCP的理解想必又深入了一些，趁着国庆假期顺便就把很多想法整理成一篇文章了。
/* 2. Tuning advertised window (window_clamp, rcv_ssthresh)
*
* All tcp_full_space() is split to two parts: "network" buffer, allocated
* forward and advertised in receiver window (tp->rcv_wnd) and
* "application buffer", required to isolate scheduling/application
* latencies from network.
* window_clamp is maximal advertised window. It can be less than
* tcp_full_space(), in this case tcp_full_space() - window_clamp
* is reserved for "application" buffer. The less window_clamp is
* the smoother our behaviour from viewpoint of network, but the lower
* throughput and the higher sensitivity of the connection to losses. 8)
*
* rcv_ssthresh is more strict window_clamp used at "slow start"
* phase to predict further behaviour of this connection.
* It is used for two goals:
* - to enforce header prediction at sender, even when application
* requires some significant "application buffer". It is check #1.
* - to prevent pruning of receive queue because of misprediction
* of receiver window. Check #2.
*
* The scheme does not work when sender sends good segments opening
* window and then starts to feed us spagetti. But it should work
* in common situations. Otherwise, we have to rely on queue collapsing.
*/
然后，几乎所有的分析接收缓存的文章都采用了这种说法，诚然，说法并不重要，关键是要便于人们去理解。因此我尝试用一种不同的说法去解释它，其实本质上是相同的，只是更加啰嗦一些。
和我一向的观点一样，本文不会去大段大段分析源码，也就是说不会去做给源码加注释的工作，而是希望能绘制一个关于这个话题的蓝图，就像之前分析OpenVPN以及Netfilter的时候那样。
但这不是重点，重点是：接收窗口无法完全占完接收缓存的内存，即接收缓存的内存并不能完全用于接收窗口！Why？
这是因为接收窗口是TCP层的概念，仅仅描述TCP载荷，然而这个载荷之所以可以收到，必须使用一个叫做数据包的载体，在Linux中就是skb，另外为了让协议运行，必须为载荷封装TCP头，IP头，以太头...等等。
我用下图来解释接收缓存以及其和TCP数据包的关系：
图示的最后，我特意标红了一个“极力要避免”的警示，确实，如果直接把可用的窗口都通告出去了，且发送端并不按照满MSS发送的话，是存在溢出风险的，这要怎么解决呢？
以上函数确定了接收缓存，其中有3个要点：
1).初始通告窗口的大小
默认是10个MSS满1460字节的段，这个数值10来自google的测试，与拥塞窗口的初始值一致，然而由于MSS各不同，其会按照1460/mss的比例进行缩放来适配经验值10。
2).TCP载体开销的最小值128
展开宏SKB_TRUESIZE会发现其最小值就是128，这对通告窗口慢启动过程定义了一个安全下界，载荷小于128字节的TCP数据段将不会增加通告的上限大小。
3).参数tcp_adv_win_scale的含义
对比我上面的图示，上述代码的注释，我们知道tcp_adv_win_scale就是控制“载荷/载体”比例的，我们看一下其Kernel DOC
tcp_adv_win_scale - INTEGER Count buffering overhead as bytes/2^tcp_adv_win_scale
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
if it is <= 0.
Possible values are [-31, 31], inclusive.
Default: 1
[ Upstream commit b49960a05e32121d29316cfdf653894b88ac9190 ]
tcp_adv_win_scale default value is 2, meaning we expect a good citizen
skb to have skb->len / skb->truesize ratio of 75% (3/4)
In 2.6 kernels we (mis)accounted for typical MSS=1460 frame :
1536 + 64 + 256 = 1856 ‘estimated truesize‘, and 1856 * 3/4 = 1392.
So these skbs were considered as not bloated.
With recent truesize fixes, a typical MSS=1460 frame truesize is now the
more precise :
2048 + 256 = 2304. But 2304 * 3/4 = 1728.
So these skb are not good citizen anymore, because 1460 < 1728
(GRO can escape this problem because it build skbs with a too low
truesize.)
This also means tcp advertises a too optimistic window for a given
allocated rcvspace : When receiving frames, sk_rmem_alloc can hit
sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often,
especially when application is slow to drain its receive queue or in
case of losses (netperf is fast, scp is slow). This is a major latency
source.
We should adjust the len/truesize ratio to 50% instead of 75%
This patch :
1) changes tcp_adv_win_scale default to 1 instead of 2
2) increase tcp_rmem[2] limit from 4MB to 6MB to take into account
better truesize tracking and to allow autotuning tcp receive window to
reach same value than before. Note that same amount of kernel memory is
我们分别来看一下2.6.32和3.10两个版本的sk_buff的大小，怎么看呢？不要想着写一个模块然后打印sizeof，直接用slabtop去看即可，里面信息很足。
a).2.6.32版本的sk_buff大小
slabtop的结果是：
skbuff_head_cache 550 615 256 15 1 : tunables 120 60 8 : slabdata 41 41 0
我们看到其大小是256字节。
b).3.10版本的sk_buff大小
slabtop的结果是：
skbuff_head_cache 3675 3675 320 25 2 : tunables 0 0 0 : slabdata 147 147 0
我们看到其大小是320字节。
差别并不是太大！这不是主要因素，但确实会有所影响。
除了skb的膨胀之外，系统中还有别的膨胀，比如为了效率的“对齐开销”，但更大的开销增加是skb_shared_info结构体的计入(个人认为以前开销中不计入skb_shared_info结构体是错误的)等，最终导致新版本(以3.10+为例)的内核计算TRUESIZE的方法改变：
packet_size = mss + MAX_TCP_HEADER + SKB_DATA_ALIGN(sizeof(struct sk_buff)) + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
然而以往的老内核(以2.6.32为例)，其开销的计算是非常鲁莽的，少了很多东西：
packet_size = mss + MAX_TCP_HEADER + 16 + sizeof(struct sk_buff);
虽然这种开销的膨胀在TCP层面几乎看不到什么收益(反而付出了代价，你不得不配置更大的rcvbuf...)，然而skb等并不单单服务于TCP，这种膨胀的收益可能被调度，中断，IP路由，负载均衡等机制获取了，记住两点即可：首先，Linux内核各个子系统是一个整体，其次，内存越来越便宜而时间一去不复返，空间换时间，划得来！
在阐明了风险的来源后，我们就可以畅谈何以规避风险了。
我们知道，TCP拥塞控制通过慢启动来规避突发造成的网络缓存溢出的的风险，事实上拥塞控制也是一种流量控制，作为标准的方案，慢启动几乎是规避溢出的标配方案！这很好理解，慢启动的含义是“快速地从起点试探到稳态”，并非其字面含义所说的“慢慢地启动”，之所以有“慢”字是因为与进入稳定状态后相比，它的起点是低的。这和开车是一样的道理，静止的汽车从踩下油门开始一直到匀速，是一个快速加速的过程，达到100km/h的时间也是一个重要的指标，当然，很多情况下是越小越好！
所以说，通告窗口也是采用慢启动方式逐步张开的。
收到满MSS长度的数据或者大于MSS长度的数据，窗口可以毫无压力地增加2个MSS大小。
如此复杂的情况，我画了一个稍微复杂点的图来展示，以节省文字篇幅：
如果持续收到小于MSS的小包，假设长度都相等，那么从慢启动开始，通告窗口的最大值，即rcv_ssthresh将会在每收到一个数据包后从初始值开始按照2倍数据段长度的增量持续增长，直到其达到小于所有可用通告窗口内存的某个值停止再增长，增长到该值的位置时，一整窗的数据连同其开销将会完全占满整个rcvbuf。
这是因为通告窗口的实际值并非单单由接收缓存溢出检测这么一个因素控制，这个因素事实上反而不是主导因素，主导因素是应用程序是不是即时腾出了接收缓存。我们从代码中如何确定通告窗口的逻辑中可以看出：
在本文的最后，我来总结一幅图，将上面谈到的所有这些概念与Linux内核协议栈TCP实现关联起来：
温州老板坠马落水。
明明在接收端有8192字节的接收缓存，为什么收了不到8000字节的数据就ZeroWindow了呢？
当时我的解决方案是直接扩大接收缓存完事，然后就没有然后了。后来深挖了一下细节，发现了很多曾经不知道的东西，如今对TCP的理解想必又深入了一些，趁着国庆假期顺便就把很多想法整理成一篇文章了。
0.network buffer & application buffer
深入接收缓存管理机制的过程中，你可能会在代码的注释中看到这样的分割，将接收缓存分割成了所谓的network buffer和application buffer，具体参见__tcp_grow_window的注释：/* 2. Tuning advertised window (window_clamp, rcv_ssthresh)
*
* All tcp_full_space() is split to two parts: "network" buffer, allocated
* forward and advertised in receiver window (tp->rcv_wnd) and
* "application buffer", required to isolate scheduling/application
* latencies from network.
* window_clamp is maximal advertised window. It can be less than
* tcp_full_space(), in this case tcp_full_space() - window_clamp
* is reserved for "application" buffer. The less window_clamp is
* the smoother our behaviour from viewpoint of network, but the lower
* throughput and the higher sensitivity of the connection to losses. 8)
*
* rcv_ssthresh is more strict window_clamp used at "slow start"
* phase to predict further behaviour of this connection.
* It is used for two goals:
* - to enforce header prediction at sender, even when application
* requires some significant "application buffer". It is check #1.
* - to prevent pruning of receive queue because of misprediction
* of receiver window. Check #2.
*
* The scheme does not work when sender sends good segments opening
* window and then starts to feed us spagetti. But it should work
* in common situations. Otherwise, we have to rely on queue collapsing.
*/
然后，几乎所有的分析接收缓存的文章都采用了这种说法，诚然，说法并不重要，关键是要便于人们去理解。因此我尝试用一种不同的说法去解释它，其实本质上是相同的，只是更加啰嗦一些。
和我一向的观点一样，本文不会去大段大段分析源码，也就是说不会去做给源码加注释的工作，而是希望能绘制一个关于这个话题的蓝图，就像之前分析OpenVPN以及Netfilter的时候那样。
1.通告窗口与接收缓存
在TCP的配置中，有一个接收缓存的概念，另外在TCP滑动窗口机制中，还有一个接收窗口的概念，毋庸置疑，接收窗口所使用的内存必须分配自接收缓存，因此二者是包容的关系。但这不是重点，重点是：接收窗口无法完全占完接收缓存的内存，即接收缓存的内存并不能完全用于接收窗口！Why？
这是因为接收窗口是TCP层的概念，仅仅描述TCP载荷，然而这个载荷之所以可以收到，必须使用一个叫做数据包的载体，在Linux中就是skb，另外为了让协议运行，必须为载荷封装TCP头，IP头，以太头...等等。
我用下图来解释接收缓存以及其和TCP数据包的关系：
图示的最后，我特意标红了一个“极力要避免”的警示，确实，如果直接把可用的窗口都通告出去了，且发送端并不按照满MSS发送的话，是存在溢出风险的，这要怎么解决呢？
附：如何确定通告窗口可以使用的接收缓存
在代码中，我们注意一个函数tcp_fixup_rcvbuf：static void tcp_fixup_rcvbuf(struct sock *sk)
{
u32 mss = tcp_sk(sk)->advmss;
u32 icwnd = TCP_DEFAULT_INIT_RCVWND;
int rcvmem;
/* Limit to 10 segments if mss <= 1460,
* or 14600/mss segments, with a minimum of two segments.
*/
if (mss > 1460)
icwnd = max_t(u32, (1460 * TCP_DEFAULT_INIT_RCVWND) / mss, 2);
rcvmem = SKB_TRUESIZE(mss + MAX_TCP_HEADER);
// 将rcvbuf按比例缩放到其(n-1)/n可以完全容纳TCP纯载荷的程度，n由系统参数net.ipv4.tcp_adv_win_scale来确定。
while (tcp_win_from_space(rcvmem) < mss)
rcvmem += 128;
rcvmem *= icwnd;
if (sk->sk_rcvbuf < rcvmem)
sk->sk_rcvbuf = min(rcvmem, sysctl_tcp_rmem[2]);
}以上函数确定了接收缓存，其中有3个要点：
1).初始通告窗口的大小
默认是10个MSS满1460字节的段，这个数值10来自google的测试，与拥塞窗口的初始值一致，然而由于MSS各不同，其会按照1460/mss的比例进行缩放来适配经验值10。
2).TCP载体开销的最小值128
展开宏SKB_TRUESIZE会发现其最小值就是128，这对通告窗口慢启动过程定义了一个安全下界，载荷小于128字节的TCP数据段将不会增加通告的上限大小。
3).参数tcp_adv_win_scale的含义
对比我上面的图示，上述代码的注释，我们知道tcp_adv_win_scale就是控制“载荷/载体”比例的，我们看一下其Kernel DOC
tcp_adv_win_scale - INTEGER Count buffering overhead as bytes/2^tcp_adv_win_scale
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
if it is <= 0.
Possible values are [-31, 31], inclusive.
Default: 1
这个参数曾经的default值是2而不是1，这意味着以往TCP的载荷占比由3/4变成了1/2，好像是开销更大了，这是为什么呢？以下是该Change的patch描述：
[ Upstream commit b49960a05e32121d29316cfdf653894b88ac9190 ]
tcp_adv_win_scale default value is 2, meaning we expect a good citizen
skb to have skb->len / skb->truesize ratio of 75% (3/4)
In 2.6 kernels we (mis)accounted for typical MSS=1460 frame :
1536 + 64 + 256 = 1856 ‘estimated truesize‘, and 1856 * 3/4 = 1392.
So these skbs were considered as not bloated.
With recent truesize fixes, a typical MSS=1460 frame truesize is now the
more precise :
2048 + 256 = 2304. But 2304 * 3/4 = 1728.
So these skb are not good citizen anymore, because 1460 < 1728
(GRO can escape this problem because it build skbs with a too low
truesize.)
This also means tcp advertises a too optimistic window for a given
allocated rcvspace : When receiving frames, sk_rmem_alloc can hit
sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often,
especially when application is slow to drain its receive queue or in
case of losses (netperf is fast, scp is slow). This is a major latency
source.
We should adjust the len/truesize ratio to 50% instead of 75%
This patch :
1) changes tcp_adv_win_scale default to 1 instead of 2
2) increase tcp_rmem[2] limit from 4MB to 6MB to take into account
better truesize tracking and to allow autotuning tcp receive window to
reach same value than before. Note that same amount of kernel memory is
consumed compared to 2.6 kernels.
我们分别来看一下2.6.32和3.10两个版本的sk_buff的大小，怎么看呢？不要想着写一个模块然后打印sizeof，直接用slabtop去看即可，里面信息很足。
a).2.6.32版本的sk_buff大小
slabtop的结果是：
skbuff_head_cache 550 615 256 15 1 : tunables 120 60 8 : slabdata 41 41 0
我们看到其大小是256字节。
b).3.10版本的sk_buff大小
slabtop的结果是：
skbuff_head_cache 3675 3675 320 25 2 : tunables 0 0 0 : slabdata 147 147 0
我们看到其大小是320字节。
差别并不是太大！这不是主要因素，但确实会有所影响。
除了skb的膨胀之外，系统中还有别的膨胀，比如为了效率的“对齐开销”，但更大的开销增加是skb_shared_info结构体的计入(个人认为以前开销中不计入skb_shared_info结构体是错误的)等，最终导致新版本(以3.10+为例)的内核计算TRUESIZE的方法改变：
packet_size = mss + MAX_TCP_HEADER + SKB_DATA_ALIGN(sizeof(struct sk_buff)) + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
然而以往的老内核(以2.6.32为例)，其开销的计算是非常鲁莽的，少了很多东西：
packet_size = mss + MAX_TCP_HEADER + 16 + sizeof(struct sk_buff);
虽然这种开销的膨胀在TCP层面几乎看不到什么收益(反而付出了代价，你不得不配置更大的rcvbuf...)，然而skb等并不单单服务于TCP，这种膨胀的收益可能被调度，中断，IP路由，负载均衡等机制获取了，记住两点即可：首先，Linux内核各个子系统是一个整体，其次，内存越来越便宜而时间一去不复返，空间换时间，划得来！
2.如何规避接收缓存溢出的风险
在谈如何规避溢出风险之前，我必须先说一下这个风险并不是常在的，如果应用程序非常迅速的读取TCP数据并释放skb，那么几乎不会有什么风险，问题在于应用程序并不受TCP层的控制，所以我说的“溢出风险”指的是一种合理但很极端的情况，那就是应用程序在TCP层收满一窗数据前都不会去读取数据，这虽然很极端，但是符合TCP滑动窗口的规范：通告给发送端的窗口表示发送端可以一次性发送这么多的数据，至于应用程序什么时候来读取，滑动窗口机制并不控制。在阐明了风险的来源后，我们就可以畅谈何以规避风险了。
我们知道，TCP拥塞控制通过慢启动来规避突发造成的网络缓存溢出的的风险，事实上拥塞控制也是一种流量控制，作为标准的方案，慢启动几乎是规避溢出的标配方案！这很好理解，慢启动的含义是“快速地从起点试探到稳态”，并非其字面含义所说的“慢慢地启动”，之所以有“慢”字是因为与进入稳定状态后相比，它的起点是低的。这和开车是一样的道理，静止的汽车从踩下油门开始一直到匀速，是一个快速加速的过程，达到100km/h的时间也是一个重要的指标，当然，很多情况下是越小越好！
所以说，通告窗口也是采用慢启动方式逐步张开的。
2.0.收到极小载荷的TCP数据包时的慢启动
比如说收到了一个只包含1个字节载荷的数据包时，此时仅仅skb，协议头等开销就会超过几百字节，通告窗口增加是非常危险的。Linux TCP实现中，将128字节定为下限，凡是收到小于128字节载荷的数据包，接收一大窗的数据非常有可能造成缓存溢出，因此不执行慢启动。2.1.收到满MSS的TCP数据包时的慢启动
如果能保证发送端一直发送满MSS长度的TCP数据包，那么接收缓存是不会溢出的，因为整个通告窗口可以使用的内存就是通过这个满MSS长度和接收缓存按照比例缩放而生成的，但是谁也不能保证发送端会一直发送满MSS长度的TCP数据包，所以就不能允许发送端一下子发送所有可用的窗口缓存那么大的数据量，因此慢启动是必须的。收到满MSS长度的数据或者大于MSS长度的数据，窗口可以毫无压力地增加2个MSS大小。
2.2.收到非满MSS
这里的情况比较复杂了。虽然收到数据长度比MSS小的TCP数据包有缓存溢出的风险，但是受限于当前的通告窗口上限(由于慢启动的功劳)小于整个可用的通告窗口内存，这种情况下即便是发送一整窗的数据，也不会造成整个接收缓存的溢出。这就是说某些时候，当当前的接收窗口上限未达到整个可用的窗口缓存时，长度小于MSS的TCP数据包的额外高于(n-1)/n比例的开销可以暂时“借用”剩余的窗口可用的缓存，只要不会造成溢出，管它是不是借用，都是可以接受的。如此复杂的情况，我画了一个稍微复杂点的图来展示，以节省文字篇幅：
如果持续收到小于MSS的小包，假设长度都相等，那么从慢启动开始，通告窗口的最大值，即rcv_ssthresh将会在每收到一个数据包后从初始值开始按照2倍数据段长度的增量持续增长，直到其达到小于所有可用通告窗口内存的某个值停止再增长，增长到该值的位置时，一整窗的数据连同其开销将会完全占满整个rcvbuf。
3.一个差异：通告窗口大小与通告窗口上限
为什么拥塞窗口的慢启动是直接增加的拥塞窗口的值，通告窗口的慢启动并不直接增加通告窗口而是增加的通告窗口的上限呢？这是因为通告窗口的实际值并非单单由接收缓存溢出检测这么一个因素控制，这个因素事实上反而不是主导因素，主导因素是应用程序是不是即时腾出了接收缓存。我们从代码中如何确定通告窗口的逻辑中可以看出：
u32 __tcp_select_window(struct sock *sk)
{
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
/* MSS for the peer‘s data. Previous verions used mss_clamp
* here. I don‘t know if the value based on our guesses
* of peer‘s MSS is better for the performance. It‘s more correct
* but may be worse for the performance because of rcv_mss
* fluctuations. --SAW 1998/11/1
*/
int mss = icsk->icsk_ack.rcv_mss;
// free_space就是应用程序和TCP层合力确定的通告窗口基准值，它简单来讲就是(rcvbuf - sk_rmem_alloc)中的纯数据部分，缩放比例就是本文开始提到的(n-1)/n。
int free_space = tcp_space(sk);
int full_space = min_t(int, tp->window_clamp, tcp_full_space(sk));
int window;
if (mss > full_space)
mss = full_space;
// 这里是为了防止接收缓存溢出的最后防线，当free_space小于全部rcvbuf按纯数据比例缩放后的大小的一半时，就要小心了！
if (free_space < (full_space >> 1)) {
icsk->icsk_ack.quick = 0;
if (sk_under_memory_pressure(sk))
tp->rcv_ssthresh = min(tp->rcv_ssthresh,
4U * tp->advmss);
// 我们要多大程度上信任mss，取决于发送端mss的波动情况，如注释中所提到的“It‘s more correct but may be worse for the performance because of rcv_mss fluctuations.”
if (free_space < mss)
return 0;
}
// 这里的核心是，虽然应用程序为TCP接收缓存腾出了free_space这么大小的空间，但是并不能全部通告给发送端，需要一点点通告并增加通告的大小，这就是慢启动了。
// 注意这里，free_space不能超过ssthresh，这便是通告窗口上限慢启动的根本了。
if (free_space > tp->rcv_ssthresh)
free_space = tp->rcv_ssthresh;
...// 这里的窗口计算详细过程反而不是本文关注的，可以参见其它源码分析的文章和书籍
...// 最终free_space要落实到window，为了便于理解核心，可以认为free_space就是window。
return window;
}在本文的最后，我来总结一幅图，将上面谈到的所有这些概念与Linux内核协议栈TCP实现关联起来：
温州老板坠马落水。
关于Linux TCP接收缓存以及接收窗口的一个细节解析
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。