关于linux:linux高性能网络编程之tcp连接的内存使用

当服务器的并发 TCP 连贯数以十万计时，咱们就会对一个 TCP 连贯在操作系统内核上耗费的内存多少感兴趣。socket 编程办法提供了 SO_SNDBUF、SO_RCVBUF 这样的接口来设置连贯的读写缓存，linux 上还提供了以下零碎级的配置来整体设置服务器上的 TCP 内存应用，但这些配置看名字却有些互相冲突、概念含糊的感觉，如下（sysctl - a 命令能够查看这些配置）：

net.ipv4.tcp_rmem = 8192 87380 16777216
net.ipv4.tcp_wmem = 8192 65536 16777216
net.ipv4.tcp_mem = 8388608 12582912 16777216
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

还有一些较少被提及的、也跟 TCP 内存相干的配置：

net.ipv4.tcp_moderate_rcvbuf = 1net.ipv4.tcp_adv_win_scale = 2

（注：为不便下文讲述，介绍以上系统配置时前缀省略掉，配置值以空格分隔的多个数字以数组来称说，例如 tcp_rmem[2] 示意下面第一行最初一列 16777216。）

网上能够找到很多这些系统配置项的阐明，然而往往还是让人费解，例如，tcp_rmem[2] 和 rmem_max 仿佛都跟接管缓存最大值无关，但它们却能够不统一，到底有什么区别？或者 tcp_wmem[1] 和 wmem_default 仿佛都示意发送缓存的默认值，抵触了怎么办？在用抓包软件抓到的 syn 握手包里，为什么 TCP 接管窗口大小仿佛与这些配置齐全没关系？

TCP 连贯在过程中应用的内存大小变幻无穷，通常程序较简单时可能不是间接基于 socket 编程，这时平台级的组件可能就封装了 TCP 连贯应用到的用户态内存。不同的平台、组件、中间件、网络库都大不相同。而内核态为 TCP 连贯分配内存的算法则是根本不变的，这篇文章将试图阐明 TCP 连贯在内核态中会应用多少内存，操作系统应用怎么的策略来均衡宏观的吞吐量与宏观的某个连贯传输速度。这篇文章也将判若两人的面向应用程序开发者，而不是零碎级的内核开发者，所以，不会具体的介绍为了一个 TCP 连贯、一个 TCP 报文操作系统调配了多少字节的内存，内核级的数据结构也不是本文的关注点，这些也不是利用级程序员的关注点。这篇文章次要形容 linux 内核为了 TCP 连贯上传输的数据是怎么治理读写缓存的。

一、缓存下限是什么？

（1）先从应用程序编程时能够设置的 SO_SNDBUF、SO_RCVBUF 说起。

无论何种语言，都对 TCP 连贯提供基于 setsockopt 办法实现的 SO_SNDBUF、SO_RCVBUF，怎么了解这两个属性的意义呢？

SO_SNDBUF、SO_RCVBUF 都是个体化的设置，即，只会影响到设置过的连贯，而不会对其余连贯失效。SO_SNDBUF 示意这个连贯上的内核写缓存下限。实际上，过程设置的 SO_SNDBUF 也并不是真的下限，在内核中会把这个值翻一倍再作为写缓存下限应用，咱们不须要纠结这种细节，只须要晓得，当设置了 SO_SNDBUF 时，就相当于划定了所操作的 TCP 连贯上的写缓存可能应用的最大内存。然而，这个值也不是能够由着过程随便设置的，它会受制于零碎级的上上限，当它大于下面的系统配置 wmem_max（net.core.wmem_max）时，将会被 wmem_max 代替（同样翻一倍）；而当它特地小时，例如在 2.6.18 内核中设计的写缓存最小值为 2K 字节，此时也会被间接代替为 2K。

SO_RCVBUF 示意连贯上的读缓存下限，与 SO_SNDBUF 相似，它也受制于 rmem_max 配置项，理论在内核中也是 2 倍大小作为读缓存的应用下限。SO_RCVBUF 设置时也有上限，同样在 2.6.18 内核中若这个值小于 256 字节就会被 256 所代替。

（2）那么，能够设置的 SO_SNDBUF、SO_RCVBUF 缓存应用下限与理论内存到底有怎么的关系呢？

TCP 连贯所用内存次要由读写缓存决定，而读写缓存的大小只与理论应用场景无关，在理论应用未达到下限时，SO_SNDBUF、SO_RCVBUF 是不起任何作用的。对读缓存来说，接管到一个来自连贯对端的 TCP 报文时，会导致读缓存减少，当然，如果加上报文大小后读缓存曾经超过了读缓存下限，那么这个报文会被抛弃从而读缓存大小维持不变。什么时候读缓存应用的内存会缩小呢？当过程调用 read、recv 这样的办法读取 TCP 流时，读缓存就会缩小。因而，读缓存是一个动态变化的、理论用到多少才调配多少的缓冲内存，当这个连贯十分闲暇时，且用户过程曾经把连贯上接管到的数据都生产了，那么读缓存应用内存就是 0。

写缓存也是同样情理。当用户过程调用 send 或者 write 这样的办法发送 TCP 流时，就会造成写缓存增大。当然，如果写缓存曾经达到下限，那么写缓存维持不变，向用户过程返回失败。而每当接管到 TCP 连贯对端发来的 ACK 确认了报文的胜利发送时，写缓存就会缩小，这是因为 TCP 的可靠性决定的，收回去报文后因为放心报文失落而不会销毁它，可能会由重发定时器来重发报文。因而，写缓存也是动态变化的，闲暇的失常连贯上，写缓存所用内存通常也为 0。

因而，只有当接管网络报文的速度大于应用程序读取报文的速度时，可能使读缓存达到了下限，这时这个缓存应用下限才会起作用。所起作用为：抛弃掉新收到的报文，避免这个 TCP 连贯耗费太多的服务器资源。同样，当应用程序发送报文的速度大于接管对方确认 ACK 报文的速度时，写缓存可能达到下限，从而使 send 这样的办法失败，内核不为其分配内存。

须要 C /C++ Linux 服务器架构师学习加群 812855908（材料包含 C /C++，Linux，golang 技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg 等），收费分享

二、缓存的大小与 TCP 的滑动窗口到底有什么关系？

（1）滑动窗口的大小与缓存大小必定是无关的，但却不是一一对应的关系，更不会与缓存下限具备一一对应的关系。因而，网上很多材料介绍 rmem_max 等配置设置了滑动窗口的最大值，与咱们 tcpdump 抓包时看到的 win 窗口值齐全不统一，是讲得通的。上面咱们来细探其别离在哪里。

读缓存的作用有 2 个：1、将无序的、落在接管滑动窗口内的 TCP 报文缓存起来；2、当有序的、能够供应用程序读取的报文呈现时，因为应用程序的读取是延时的，所以会把待应用程序读取的报文也保留在读缓存中。所以，读缓存一分为二，一部分缓存无序报文，一部分缓存待延时读取的有序报文。这两局部缓存大小之和因为受制于同一个上限值，所以它们是会相互影响的，当应用程序读取速率过慢时，这块过大的利用缓存将会影响到套接字缓存，使接管滑动窗口放大，从而告诉连贯的对端升高发送速度，防止无谓的网络传输。当应用程序长时间不读取数据，造成利用缓存将套接字缓存挤压到没空间，那么连贯对端会收到接管窗口为 0 的告诉，通知对方：我当初消化不了更多的报文了。

反之，接管滑动窗口也是始终在变动的，咱们用 tcpdump 抓三次握手的报文：

14:49:52.421674 IP houyi-vm02.dev.sd.aliyun.com.6400 > r14a02001.dg.tbsite.net.54073: S 2736789705:2736789705(0) ack 1609024383 win 5792 <mss 1460,sackOK,timestamp 2925954240 2940689794,nop,wscale 9>

能够看到初始的接管窗口是 5792，当然也远小于最大接管缓存（稍后介绍的 tcp_rmem[1]）。

这当然是有起因的，TCP 协定须要思考简单的网络环境，所以应用了慢启动、拥塞窗口（参见 高性能网络编程 2 —-TCP 音讯的发送），建设连贯时的初始窗口并不会依照接管缓存的最大值来初始化。这是因为，过大的初始窗口从宏观角度，对整个网络可能造成过载引发恶性循环，也就是思考到链路上各环节的诸多路由器、交换机可能扛不住压力一直的丢包（特地是广域网），而宏观的 TCP 连贯的单方却只依照本人的读缓存下限作为接管窗口，这样单方的发送窗口（对方的接管窗口）越大就对网络产生越坏的影响。慢启动就是使初始窗口尽量的小，随着接管到对方的无效报文，确认了网络的无效传输能力后，才开始增大接管窗口。

不同的 linux 内核有着不同的初始窗口，咱们以广为应用的 linux2.6.18 内核为例，在以太网里，MSS 大小为 1460，此时初始窗口大小为 4 倍的 MSS，简略列下代码（*rcv_wnd 即初始接管窗口）：

 int init_cwnd = 4;
  if (mss > 1460*3)
   init_cwnd = 2;
  else if (mss > 1460)
   init_cwnd = 3;
  if (*rcv_wnd > init_cwnd*mss)
   *rcv_wnd = init_cwnd*mss;

大家可能要问，为何下面的抓包上显示窗口其实是 5792，并不是 1460 4 为 5840 呢？这是因为 1460 想表白的意义是：将 1500 字节的 MTU 去除了 20 字节的 IP 头、20 字节的 TCP 头当前，一个最大报文可能承载的无效数据长度。但有些网络中，会在 TCP 的可选头部里，应用 12 字节作为工夫戳应用，这样，无效数据就是 MSS 再减去 12，初始窗口就是（1460-12）4=5792，这与窗口想表白的含意是统一的，即：我可能解决的无效数据长度。

在 linux3 当前的版本中，初始窗口调整到了 10 个 MSS 大小，这次要来自于 GOOGLE 的倡议。起因是这样的，接管窗口尽管常以指数形式来疾速减少窗口大小（拥塞阀值以下是指数增长的，阀值以上进入拥塞防止阶段则为线性增长，而且，拥塞阀值本身在收到 128 以上数据报文时也有机会疾速减少），若是传输视频这样的大数据，那么随着窗口减少到（靠近）最大读缓存后，就会“开足马力”传输数据，但若是通常都是几十 KB 的网页，那么过小的初始窗口还没有减少到适合的窗口时，连贯就完结了。这样相比较大的初始窗口，就使得用户须要更多的工夫（RTT）能力传输完数据，体验不好。

那么这时大家可能有疑难，当窗口从初始窗口一路扩张到最大接管窗口时，最大接管窗口就是最大读缓存吗？

不是，因为必须分一部分缓存用于应用程序的延时报文读取。到底会分多少进去呢？这是可配的零碎选项，如下：

net.ipv4.tcp_adv_win_scale = 2

这里的 tcp_adv_win_scale 意味着，将要拿出 1 /(2^ tcp_adv_win_scale) 缓存进去做利用缓存。即，默认 tcp_adv_win_scale 配置为 2 时，就是拿出至多 1 / 4 的内存用于利用读缓存，那么，最大的接管滑动窗口的大小只能达到读缓存的 3 /4。

（2）最大读缓存到底应该设置到多少为适合呢？

当利用缓存所占的份额通过 tcp_adv_win_scale 配置确定后，读缓存的下限该当由最大的 TCP 接管窗口决定。初始窗口可能只有 4 个或者 10 个 MSS，但在无丢包情景下随着报文的交互窗口就会增大，当窗口过大时，“过大”是什么意思呢？即，对于通信的两台机器的内存而言不算大，然而对于整个网络负载来说过大了，就会对网络设备引发恶性循环，一直的因为忙碌的网络设备造成丢包。而窗口过小时，就无奈充沛的利用网络资源。所以，个别会以 BDP 来设置最大接管窗口（可计算出最大读缓存）。BDP 叫做带宽时延积，也就是带宽与网络时延的乘积，例如若咱们的带宽为 2Gbps，时延为 10ms，那么带宽时延积 BDP 则为 2G/80.01=2.5MB，所以这样的网络中能够设最大接管窗口为 2.5MB，这样最大读缓存能够设为 4 /32.5MB=3.3MB。

为什么呢？因为 BDP 就示意了网络承载能力，最大接管窗口就示意了网络承载能力内能够不经确认收回的报文。如下图所示：

常常提及的所谓长肥网络，“长”就是是时缩短，“肥”就是带宽大，这两者任何一个大时，BDP 就大，都应导致最大窗口增大，进而导致读缓存下限增大。所以在长肥网络中的服务器，缓存下限都是比拟大的。（当然，TCP 原始的 16 位长度的数字示意窗口尽管有下限，但在 RFC1323 中定义的弹性滑动窗口使得滑动窗口能够扩大到足够大。）

发送窗口实际上就是 TCP 连贯对方的接管窗口，所以大家能够按接管窗口来推断，这里不再啰嗦。

三、linux 的 TCP 缓存下限主动调整策略

那么，设置好最大缓存限度后就居安思危了吗？对于一个 TCP 连贯来说，可能曾经充分利用网络资源，应用大窗口、大缓存来放弃高速传输了。比方在长肥网络中，缓存下限可能会被设置为几十兆字节，但零碎的总内存却是无限的，当每一个连贯都全速飞奔应用到最大窗口时，1 万个连贯就会占用内存到几百 G 了，这就限度了高并发场景的应用，公平性也得不到保障。咱们心愿的场景是，在并发连贯比拟少时，把缓存限度放大一些，让每一个 TCP 连贯开足马力工作；当并发连贯很多时，此时零碎内存资源有余，那么就把缓存限度放大一些，使每一个 TCP 连贯的缓存尽量的小一些，以包容更多的连贯。

linux 为了实现这种场景，引入了主动调整内存调配的性能，由 tcp_moderate_rcvbuf 配置决定，如下：

net.ipv4.tcp_moderate_rcvbuf = 1

默认 tcp_moderate_rcvbuf 配置为 1，示意关上了 TCP 内存主动调整性能。若配置为 0，这个性能将不会失效（慎用）。

另外请留神：当咱们在编程中对连贯设置了 SO_SNDBUF、SO_RCVBUF，将会使 linux 内核不再对这样的连贯执行主动调整性能！

那么，这个性能到底是怎么起作用的呢？看以下配置：

net.ipv4.tcp_rmem = 8192 87380 16777216
net.ipv4.tcp_wmem = 8192 65536 16777216
net.ipv4.tcp_mem = 8388608 12582912 16777216

tcp_rmem[3] 数组示意任何一个 TCP 连贯上的读缓存下限，其中 tcp_rmem[0] 示意最小下限，tcp_rmem[1] 示意初始下限（留神，它会笼罩实用于所有协定的 rmem_default 配置），tcp_rmem[2] 示意最大下限。

tcp_wmem[3] 数组示意写缓存，与 tcp_rmem[3] 相似，不再赘述。

tcp_mem[3] 数组就用来设定 TCP 内存的整体应用情况，所以它的值很大（它的单位也不是字节，而是页 –4K 或者 8K 等这样的单位！）。这 3 个值定义了 TCP 整体内存的无压力值、压力模式开启阀值、最大应用值。以这 3 个值为标记点则内存共有 4 种状况：

1、当 TCP 整体内存小于 tcp_mem[0] 时，示意零碎内存总体无压力。若之前内存已经超过了 tcp_mem[1] 使零碎进入内存压力模式，那么此时也会把压力模式敞开。

这种状况下，只有 TCP 连贯应用的缓存没有达到下限（留神，尽管初始下限是 tcp_rmem[1]，但这个值是可变的，下文会详述），那么新内存的调配肯定是胜利的。

2、当 TCP 内存在 tcp_mem[0] 与 tcp_mem[1] 之间时，零碎可能处于内存压力模式，例如总内存刚从 tcp_mem[1] 之上下来；也可能是在非压力模式下，例如总内存刚从 tcp_mem[0] 以下上来。

此时，无论是否在压力模式下，只有 TCP 连贯所用缓存未超过 tcp_rmem[0] 或者 tcp_wmem[0]，那么都肯定都能胜利调配新内存。否则，基本上就会面临调配失败的情况。（留神：还有一些例外场景容许分配内存胜利，因为对于咱们了解这几个配置项意义不大，故略过。）

3、当 TCP 内存在 tcp_mem[1] 与 tcp_mem[2] 之间时，零碎肯定处于零碎压力模式下。其余行为与上同。

4、当 TCP 内存在 tcp_mem[2] 之上时，毫无疑问，零碎肯定在压力模式下，而且此时所有的新 TCP 缓存调配都会失败。

下图为须要新缓存时内核的简化逻辑：

当零碎在非压力模式下，下面我所说的每个连贯的读写缓存下限，才有可能减少，当然最大也不会超过 tcp_rmem[2] 或者 tcp_wmem[2]。相同，在压力模式下，读写缓存下限则有可能缩小，尽管下限可能会小于 tcp_rmem[0] 或者 tcp_wmem[0]。

所以，粗略的总结下，对这 3 个数组能够这么看：

1、只有零碎 TCP 的总体内存超了 tcp_mem[2]，新内存调配都会失败。

2、tcp_rmem[0] 或者 tcp_wmem[0] 优先级也很高，只有条件 1 不超限，那么只有连贯内存小于这两个值，就保障新内存调配肯定胜利。

3、只有总体内存不超过 tcp_mem[0]，那么新内存在不超过连贯缓存的下限时也能保障调配胜利。

4、tcp_mem[1] 与 tcp_mem[0] 形成了开启、敞开内存压力模式的开关。在压力模式下，连贯缓存下限可能会缩小。在非压力模式下，连贯缓存下限可能会减少，最多减少到 tcp_rmem[2] 或者 tcp_wmem[2]。