一、概述

我们之前介绍过一种具有大的带宽时延乘积(band-delay product、BDP)的网络，这种网络称为长肥网络(LongFatNetwork,即LFN)。我们想象一种简单的场景，假设发送端的发送窗口为5000bytes，网络的RTT为200ms，那么每秒的最大速率则为5000*(1000/200)=25000bytes/s，这大约为24kb/s，可以看到这个速率是非常低的，这就是TCP发送窗口对于发送速率的限制，实际的window size应该至少为带宽时延积才能高效的利用网络传输能力。因此对于长肥网络需要扩大TCP的window size，我们之前就已经介绍过RFC1323提高的高性能TCP扩展选项WSOPT，这允许了TCP使用更大的window size(大约是1GB)。但是我们在连接建立初始化的时候很难确切的知道这个这个网络的带宽时延积，这就需要对于window size的一种自动调整(auto-tuning)算法，对于长肥网络能自动抬升TCP的接收缓存，进而增大window size。有时这种接收缓存自动调整技术也称为Dynamic Right-Sizing(DRS)。

二、linux下相关的几个配置参数简单介绍

net.ipv4.tcp_moderate_rcvbuf

这个参数设置为非0，且用户没有通过SO_RCVBUF设置socket对应的接收缓存的时候，那么TCP就会自动调整接收缓存。但是调整的接收窗口最大值不会超过tcp_rmem[2]。这对于长时延高传输速率的网络来说，可以大幅提高接收窗口提高传输速率。

net.core.wmem_max和net.core.rmem_max

这两个参数分别决定了通过SO_SNDBUF和SO_RCVBUF这两个SOCKET选项能设置的最大的发送缓存值和接收缓存值，另外通过SO_SNDBUF和SO_RCVBUF设置的时候还有两个下限，在ubuntu16.04上分别是4608和2304,，还记前前面实例中我们介绍过通过这两个选项设置接收缓存的时候实际上内核会将设置的值先乘2吧，假如通过SO_RCVBUF设置接收缓存为3500，那么内核会max(min(3500*2,rmem_max),2304)=7000，最终将接收缓存设置为7000。

net.ipv4.tcp_adv_win_scale

上面举例中的7000bytes缓存会分为两部分，一部分用于接收窗口的称为内核缓存，这个对应实际的接收的有效TCP数据，另外一部分用于存储这些TCP数据的辅助结构(skb)，这部分称为应用缓存，这个是linux的man page的称呼，应用缓存这个称呼好像不是很合适(linux的man page也会有错误的，比如对于tcp_retries2参数的解释就是错的,对于这个应用缓存和内核缓存的解释实在不想吐槽了)。这两部分的比例可以通过tcp_adv_win_scale设置。如果tcp_adv_win_scale>0，则应用缓存占bytes/2^tcp_adv_win_scale，如果这个参数小于0，则应用缓存占bytes- bytes/2^(-tcp_adv_win_scale)。比如设置为tcp_adv_win_scale为2的时候，用于window size的缓存则为7000*(1-1/2^2)=5250bytes。

net.core.wmem_default和net.core.rmem_default

这两个参数指定了传输层协议的默认发送缓存和接收缓存

net.ipv4.tcp_wmem和net.ipv4.tcp_rmem

其中tcp_wmem这个值是由三个整数组成，三个整数分别是min, default, max。min是给每个socket的最小接收缓存的保证值，即使在有内存压力的情况下，如果当前已经真实分配的接收缓存低于min，分配的时候仍然可以分配出内存。default则会覆盖wmem_default，wmem_default指定的是传输层协议的发送缓存默认值，default进一步指定了TCP协议下发送缓存的默认值。比如UDP没有指定自己的发送缓存的默认值那么就会使用wmem_default作为默认值。max则指定了发送缓存的最大值。tcp_rmem这个参数与tcp_wmem类似。

三、wireshark示例

1、缓存自动调整这块在实现上相对复杂一些，这里仅给出一个示例，不再仔细说明调整过程。如下面两张图所示，client端开始每隔5ms写入40bytes的数据，连续写入三次，接着client端在连续写入5次4096bytes的数据，每次写入之间不停顿。可以看到在开始的每次写入40bytes的数据的时候server端的window size一直为2088，在连续大量写入5次4096bytes的数据后，server端开始缓慢增加window size直到最后第49个数据包window size变为43848。

补充说明：

1、

2、

3、具体的接收缓存调整算法已经超过本文的介绍范围了，可以参考tcp_rcv_space_adjust、tcp_rcv_rtt_update、tcp_clamp_window、tcp_grow_window