Linux服务端最大并发数是多少？

灰太狼 2023-01-15 11:22 115阅读 0赞

## 1. 开场白 ##

在开始今天的文章之前，先抛一个面试题出来：

> 你接触过的单机最大并发数是多少？  
> 你认为当前正常配置的服务器物理机最大并发数可以到多少？  
> 说说你的理解和分析。

思考几分钟，如果你可以**有理有据地说出答案**，那确实就不用再往下看了，关上手机去陪陪家人是个不错的选择。

思考几分钟，如果你**没有头绪或者对答案不确定**，那么你先不用着急关闭页面去玩耍，你应该继续往下看，因为这个问题很不错。

![6120fb0369257e6831084d3fb7903315.png][]

对于后端开发人员来说，并发数往往和技术难度是呈正相关的，实际上也确实如此：**体量决定架构**。

服务端根据不同业务场景会有不同的侧重点，单纯追求高并发其实并不是根本目的，**高可用&稳定性更重要**。

所以最终我们的目的是：**保证高可用高稳定的基础上追求高并发，降本增效**。

高可用&高并发是我们直观感受到的，本质上这是个**复杂的系统工程**，每个环节都会影响结果，每一块都值得研究和深入。

![1533c21704be303f1970f790f6351535.png][]

## 2. C10K问题和C10M问题 ##

在2000年初的时候，全球互联网的规模并不大，但是当时就已经提出了C10K问题，所谓**C10K就是单机1w并发问题**，虽然现在不觉得是个难题了，但是这在当初是很有远见和挑战的问题。

![707912315868d1957f25bcc91aad0653.png][]

C10K问题最早由**Dan Kegel**发布于其个人站点，原文链接如下:

> **[http://www.kegel.com/c10k.html][http_www.kegel.com_c10k.html]**

相关资料显示Dan Kegel目前工作于**Google**，从1978年起开始接触计算机编程，是Winetricks和Crosstool的作者，大佬年轻时的照片：

![7c29c36c4a6bf815df5e776dfb460047.png][]

Dan Kegel这篇文章阅读难度并不大，大白建议从事服务端开发或者对高性能网络开发有兴趣的读者尝试读一读。

在APUE第三版都没有提到epoll，所以**我们解决C10K问题的时间并不长**，其中IO复用epoll/kqueue/iocp等技术对于C10k问题的解决起到了非常重要的作用。

开源大神们基于epoll/kqueue等开发了诸如libevent/libuv等网络库，从而大幅提高了高并发网络的开发效率，对于C/C++程序员来说并不陌生。

![e09e3b6f0c9b5f90ee2cbd4f55289c1c.png][]

这里简单提一下针对下一个10年的展望和挑战：**C10M问题**。

站在浪尖的那一批人早就开始思考**让单机达到1000w并发**，现在听起来感觉不可思议，但是要达到这个目标，除了硬件上的提升，更重要的是**对系统软件和协议栈的改造**。

![a6dc4a409e5f3c59c2c62864c03de239.png][]

Errata Security的CEO Robert Graham在Shmoocon 2013大会上的演讲，大佬重要的观点是：

> **不要让OS内核执行所有繁重的任务：将数据包处理、内存管理、处理器调度等任务从内核转移到应用程序高效地完成，让诸如Linux这样的OS只处理控制层，数据层完全交给应用程序来处理。**

确实也是如此，**难道你不觉得Linux内核做了太多不该自己做的事情了吗**？

近几年出现的DPDK、PFRING、NETMAP等技术也是类似的思想，现在流行的协处理器+CPU的架构也是这样的：

![2f73775597bac7dd14ae8f578296c9f8.png][]

## 3. 服务器最大并发数分析 ##

前面提到的C10K和C10M问题都是围绕着提升服务器并发能力展开的，但是难免要问：**服务器最大的并发上限是多少**？

![f8446df13154629b9190a5b479dd877e.png][]

### 3.1 五元组 ###

做过通信的盆友们一定听过**五元组**这个概念，一个五元组可以唯一标记一个网络连接，所以要理解和分析最大并发数，就必须理解五元组：

![77966cd514ffd705cf06e33d4ef1cae5.png][]

这样的话，就可以基本认为：**理论最大并发数 = 服务端唯一五元组数**。

### 3.2 端口&IP组合数 ###

那么对于服务器来说，服务端唯一五元组数最大是多少呢？

**有人说是65535**，显然不是，但是之所以会有这类答案是因为当前Linux的端口号是2字节大小的short类型，总计2^16个端口，除去一些系统占用的端口，可用端口确实只剩下64000多了。

对于服务端本身来说，DestPort数量确实有限，假定有多张网卡，每个网卡绑定多个IP，**服务端的Port端口数和IP数的组合类型也是有限的**。

对于客户端来说，本身的端口和IP也是一样有限的，虽然这是个**组合问题**，但是数量还是有限的：

![c6799e68d4935917d1ba192c70353001.png][]

### 3.3 并发数理论极限 ###

看了前面的端口&IP的组合数计算，好像并发数并不会特别大。

**错了，是真的会很大。**

分析一下，前面的计算都是针对单个服务器或者客户端的，但是**实际上每个服务器会应对全网的所有客户端**，那么从服务端看，源IP和源Port的数量是非常大的。

**理论上服务端可以接受的客户端IP是2^32(按照IPv4计算）,端口数是2^16，目前端口号仍然是16bit的，所有这个理论最大值是2^48**，果然很大！

![bba0f149b9602404dbbfc9a0b76677b1.png][]

3.4 实际情况

天下没有免费的午餐。

**每一条连接都是要消耗系统资源的**，所以实际中可能会设置最大并发数来保证服务器的安全和稳定，所以**这个理论最大并发数是不可能达到的**。

**实际中并发数和业务是直接相关的**，像Redis这种内存型的服务端并发十几万都是没问题的，大部分来讲几十/几百/几千/几万等是存在的。

## 4. 客户端最大连接数 ##

理解了服务器的最大并发数是2^48，那么**客户端最多可以连接多少服务器呢**？

![f8446df13154629b9190a5b479dd877e.png][]

对于客户端来说，当然可以借助于多网卡多IP来增加连接能力，我们仍然假定客户端只有1张网卡1个IP，由于端口数的限制到2^16，再去掉系统占用的端口，剩下可用的差不多64000。

![5f8944c90d58f0061f7dc2bc97cc084f.png][]

也就是说，客户端虽然可以连接任意的目的IP和目的端口，但是客户端自身端口是有限的，所以**客户端的理论最大连接数是2^16**，含系统占用端口。

## 5. NAT环境下的客户端 ##

解决前面的两个问题之后，来看另外一个问题：

> **一个公网出口NAT服务设备最多可同时支持多少内网IP并发访问外网服务？**

毕竟公网IP都是有限并且要花钱的，我们大部分机器都是在局域网中结合NAT来进行外网访问的，所以这个场景还是很熟悉的。

来看下**内网机器访问外网时的IP&端口替换和映射还原的过程**，就明白了：

![3d819ac3b5deb071cd69ec3ad9132ee4.png][]

因为这时的客户端是NAT设备，所以NAT环境下最多支持65535个并发访问外网。

## 6.小结 ##

本文通过一道面试题切入，先描述了C10K和C10M问题，进而详细说明了客户端的最大访问数和服务端的最大并发数计算和原理，最后描述了NAT场景下的访问并发数。

虽然理论服务端并发数非常大，但是我们也没有必要觉得并发数高就厉害，服务复杂程度不一样，**切忌唯并发数来判断业务和开发者水平**。

试想echo服务和订单交易服务显然是不一样的，我们**应该做的是在服务稳定和高可用的前提下去从缓存/网络/数据库等多个角度来优化提高性能**。

最后感谢各位老铁的倾情阅读。

[6120fb0369257e6831084d3fb7903315.png]: /images/20221022/268269e44aa34321877b1d805bd5a7c8.png
[1533c21704be303f1970f790f6351535.png]: /images/20221022/e4db49680b0144f49b99243aae312aab.png
[707912315868d1957f25bcc91aad0653.png]: /images/20221022/4b1dff496a8b44c0b39d9b0804e23c71.png
[http_www.kegel.com_c10k.html]: https://link.zhihu.com/?target=http%3A//www.kegel.com/c10k.html
[7c29c36c4a6bf815df5e776dfb460047.png]: /images/20221022/e9ee3f57a9794fb6ae42bdb1cc016168.png
[e09e3b6f0c9b5f90ee2cbd4f55289c1c.png]: /images/20221022/07cdf3ab8fd34dcca25fe7461cec867a.png
[a6dc4a409e5f3c59c2c62864c03de239.png]: /images/20221022/67b7fe6fd10a41c792351efc41ea71ff.png
[2f73775597bac7dd14ae8f578296c9f8.png]: /images/20221022/96b1b14aba744f36880c94aed98d7c43.png
[f8446df13154629b9190a5b479dd877e.png]: /images/20221022/24ee63e6f873424bbaa88e42e8073d13.png
[77966cd514ffd705cf06e33d4ef1cae5.png]: /images/20221022/112b244bb11645a888cc56b84496ef63.png
[c6799e68d4935917d1ba192c70353001.png]: /images/20221022/83adab056c8844d1a3667dfbfbdac344.png
[bba0f149b9602404dbbfc9a0b76677b1.png]: /images/20221022/88d23f4bc78948f79e4596301548e8bc.png
[5f8944c90d58f0061f7dc2bc97cc084f.png]: /images/20221022/50c6c3b84a5040bbb13f0c2ce001a174.png
[3d819ac3b5deb071cd69ec3ad9132ee4.png]: /images/20221022/1912067b7f7f4dacb7a1c74a6daf17d1.png