关于Linux TCP接收缓存以及接收窗口的一个细节解析

时间  2020-11-20 标签 linux c++ golang 缓存 安全 服务器 网络 架构 app 负载均衡

关于TCP的接收缓存以及通告窗口，通常而言懂TCP的都能说出个大概，可是涉及到细节的话可能理解就不那么深刻了。linux

问题：
明明在接收端有8192字节的接收缓存，为何收了不到8000字节的数据就ZeroWindow了呢？c++

0.network buffer & application buffer

深刻接收缓存管理机制的过程当中，你可能会在代码的注释中看到这样的分割，将接收缓存分割成了所谓的network buffer和application buffer，具体参见__tcp_grow_window的注释：golang

/* 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数据包的关系：架构

关于Linux TCP接收缓存以及接收窗口的一个细节解析

【注意，当我说“TCP数据包”的时候，个人意思是这是一个带有以太头的完整数据包，当我说“TCP数据段”的时候，我想表达的则是我并不关系IP层及如下的东西。】
图示的最后，我特地标红了一个“极力要避免”的警示，确实，若是直接把可用的窗口都通告出去了，且发送端并不按照满MSS发送的话，是存在溢出风险的，这要怎么解决呢？app

须要C/C++ Linux服务器架构师学习资料加群812855908（资料包括C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等）负载均衡

免费学习地址：c/c++ linux服务器开发后台架构师

关于Linux TCP接收缓存以及接收窗口的一个细节解析

附：如何肯定通告窗口可使用的接收缓存

在代码中，咱们注意一个函数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描述：

From: Eric Dumazet <edum...@google.com>
[ 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.

单纯从TCP载荷比来说，开销的增长意味着效率的下降，然而注意到这部分开销的增长并不是网络协议头所为，而是skb_shared_info结构体被计入开销以及skb结构体等系统载体的膨胀所致使：
咱们分别来看一下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.一、收到满MSS的TCP数据包时的慢启动

若是能保证发送端一直发送满MSS长度的TCP数据包，那么接收缓存是不会溢出的，由于整个通告窗口可使用的内存就是经过这个满MSS长度和接收缓存按照比例缩放而生成的，可是谁也不能保证发送端会一直发送满MSS长度的TCP数据包，因此就不能容许发送端一会儿发送全部可用的窗口缓存那么大的数据量，所以慢启动是必须的。
收到满MSS长度的数据或者大于MSS长度的数据，窗口能够毫无压力地增长2个MSS大小。

2.二、收到非满MSS

这里的状况比较复杂了。虽然收到数据长度比MSS小的TCP数据包有缓存溢出的风险，可是受限于当前的通告窗口上限(因为慢启动的功劳)小于整个可用的通告窗口内存，这种状况下即使是发送一整窗的数据，也不会形成整个接收缓存的溢出。这就是说某些时候，当当前的接收窗口上限未达到整个可用的窗口缓存时，长度小于MSS的TCP数据包的额外高于 (n-1)/n比例的开销能够暂时“借用”剩余的窗口可用的缓存，只要不会形成溢出，管它是否是借用，都是能够接受的。
如此复杂的状况，我画了一个稍微复杂点的图来展现，以节省文字篇幅：

关于Linux TCP接收缓存以及接收窗口的一个细节解析

看懂了上图以后，我来补充一个动态过程，若是持续收到小包的状况下，会怎样？
若是持续收到小于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接收缓存以及接收窗口的一个细节解析

联系我们 沪ICP备13005482号-10