Linux性能优化实战学习笔记：第四十五讲

1、上节回顾

专栏更新至今，四大基础模块的最后一个模块——网络篇，咱们就已经学完了。很开心你尚未掉队，仍然在积极学习思考和实践操做，热情地留言和互动。还有很多同窗分享了
在实际生产环境中，碰到各类性能问题的分析思路和优化方法，这里也谢谢大家。

今天是性能优化答疑的第五期。照例，我从网络模块的留言中，摘出了一些典型问题，做为今天的答疑内容，集中回复。一样的，为了便于你学习理解，它们并非严格按照文章
顺序排列的。

每一个问题，我都附上了留言区提问的截屏。若是你须要回顾内容原文，能够扫描每一个问题右下方的二维码查看。

2、网络收发过程当中缓冲区的位置

一、问题：

二、解答：

第一点，是网络收发过程当中，收发队列和缓冲区位置的疑问。在 关于 Linux 网络，你必需要知道这些 中，我曾介绍过 Linux 网络的收发流程。这个流
程涉及到了多个队列和缓冲区，包括：

• 网卡收发网络包时，经过 DMA 方式交互的环形缓冲区；
• 网卡中断处理程序为网络帧分配的，内核数据结构 sk_buff 缓冲区；
• 应用程序经过套接字接口，与网络协议栈交互时的套接字缓冲区。

不过相应的，就会有两个问题。

首先，这些缓冲区的位置在哪儿？是在网卡硬件中，仍是在内存中？这个问题其实仔细想一下，就很容易明白——这些缓冲区都处于内核管理的内存中。

其中，环形缓冲区，因为须要 DMA 与网卡交互，理应属于网卡设备驱动的范围。

sk_buff 缓冲区，是一个维护网络帧结构的双线链表，链表中的每个元素都是一个网络帧（Packet）。虽然 TCP/IP 协议栈分了好几层，但上下不一样层之间的传递，实际上只需
要操做这个数据结构中的指针，而无需进行数据复制。

套接字缓冲区，则容许应用程序，给每一个套接字配置不一样大小的接收或发送缓冲区。应用程序发送数据，实际上就是将数据写入缓冲区；而接收数据，其实就是从缓冲区中读取。
至于缓冲区中数据的进一步处理，则由传输层的 TCP 或 UDP 协议来完成。

其次，这些缓冲区，跟前面内存部分讲到的 Buffer 和 Cache 有什么关联吗？

这个问题其实也不难回答。我在内存模块曾提到过，内存中提到的 Buffer ，都跟块设备直接相关；而其余的都是 Cache。

实际上，sk_buff、套接字缓冲、链接跟踪等，都经过 slab 分配器来管理。你能够直接经过 /proc/slabinfo，来查看它们占用的内存大小。

3、问题 2：内核协议栈，是经过一个内核线程的方式来运行的吗

一、问题：

第二个问题，内核协议栈的运行，是按照一个内核线程的方式吗？在内核中，又是如何执行网络协议栈的呢？

二、解答：

说到网络收发，在中断处理文章中我曾讲过，其中的软中断处理，就有专门的内核线程ksoftirqd。每一个 CPU 都会绑定一个 ksoftirqd 内核线程，好比， 2 个 CPU 时，就会有
ksoftirqd/0 和 ksoftirqd/1 这两个内核线程。

不过要注意，并不是全部网络功能，都在软中断内核线程中处理。内核中还有不少其余机制（好比硬中断、kworker、slab 等），这些机制一块儿协同工做，才能保证整个网络协议栈
的正常运行。

关于内核中网络协议栈的工做原理，以及如何动态跟踪内核的执行流程，专栏后续还有专门的文章来说。若是对这部分感兴趣，你能够先用咱们提到过的 perf、systemtap、bcc-
tools 等，试着来分析一下。

4、问题 3：最大链接数是否是受限于 65535 个端口

一、问题：

 

 

二、解答：

咱们知道，不管 TCP 仍是 UDP，端口号都只占 16 位，也就说其最大值也只有 65535。是否是说，若是使用 TCP 协议，在单台机器、单个 IP 地址时，并发链接数最大也只有
那65535 呢？

对于这个问题，首先你要知道，Linux 协议栈，经过五元组来标志一个链接（即协议，源IP、源端口、目的 IP、目的端口)。

明白了这一点，这个问题其实就有了思路。咱们应该分客户端和服务器端，这两种场景来分析。

对客户端来讲，每次发起 TCP 链接请求时，都须要分配一个空闲的本地端口，去链接远端的服务器。因为这个本地端口是独占的，因此客户端最多只能发起 65535 个链接。

对服务器端来讲，其一般监听在固定端口上（好比 80 端口），等待客户端的链接。根据五元组结构，咱们知道，客户端的 IP 和端口都是可变的。若是不考虑 IP 地址分类以及资
源限制，服务器端的理论最大链接数，能够达到 2 的 48 次方（IP 为 32 位，端口号为 16位），远大于 65535。

因此，综合来看，客户端最大支持 65535 个链接，而服务器端可支持的链接数是海量的。固然，因为 Linux 协议栈自己的性能，以及各类物理和软件的资源限制等，这么大的链接
数，仍是远远达不到的（实际上，C10M 就已经很难了）。

5、问题 4： “如何优化 NAT 性能”课后思考

一、问题：

二、解答：

在 如何优化 NAT 性能 的最后， 我给你留了两个思考题。

MASQUERADE 是最经常使用的 SNAT 规则之一，一般用来为多个内网 IP 地址，提供共享的出口 IP。假设如今有一台 Linux 服务器，用了 MASQUERADE 方式，为内网全部 IP 提供
出口访问功能。那么，

• 当多个内网 IP 地址的端口号相同时，MASQUERADE 还能正常工做吗？
• 内网 IP 地址数量或者请求数比较多的时候，这种使用方式有没有什么潜在问题呢？

对于这两个思考题，我来也、ninuxer 等同窗，都给出了不错的答案：

 

 

 

 

先看第一点，当多个内网 IP 地址的端口号相同时，MASQUERADE 固然仍能够正常工做。不过，你确定也据说过，配置 MASQUERADE 后，须要各个应用程序去手动配置修
改端口号。

实际上，MASQUERADE 经过 conntrack 机制，记录了每一个链接的信息。而在刚才第三个问题 中，我提到过，标志一个链接须要五元组，只要这五元组不是同时相同，网络链接就
能够正常进行。

再看第二点，在内网 IP 地址和链接数比较小时，这种方式的问题不大。但在 IP 地址或并发链接数特别大的状况下，就可能碰到各类各样的资源限制。

好比，MASQUERADE 既然把内部多个 IP ，转换成了相同的外网 IP（即 SNAT），那么，为了确保发送出去的源端口不重复，原来网络包的源端口也可能会被从新分配。这样
的话，转换后的外网 IP 的端口号，就成了限制链接数的一个重要因素。

除此以外，链接跟踪、MASQUERADE 机器的网络带宽等，都是潜在的瓶颈，而且还存在单点的问题。这些状况，在咱们实际使用中都须要特别注意。

今天主要回答这些问题，同时也欢迎你继续在留言区写下疑问和感想，我会持续不断地解答。但愿借助每一次的答疑，能够和你一块儿，把文章知识内化为你的能力，咱们不只在实战中演练，也要在交流中进步。