Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >Linux服务端最大并发数是多少?

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

作者头像
Bug开发工程师
发布于 2020-06-29 08:16:00
发布于 2020-06-29 08:16:00
3.6K0
举报
文章被收录于专栏:码农沉思录码农沉思录

1. 开场白

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

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

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

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

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

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

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

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

2. C10K问题和C10M问题

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

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

http://www.kegel.com/c10k.html

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

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

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

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

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

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

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

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

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

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

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

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

3.1 五元组

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

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

3.2 端口&IP组合数

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

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

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

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

3.3 并发数理论极限

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

错了,是真的会很大。

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

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

3.4 实际情况

天下没有免费的午餐。

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

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

4. 客户端最大连接数

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

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

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

5. NAT环境下的客户端

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

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

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

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

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

6.小结

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

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

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-06-22,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 码农沉思录 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
高并发的那些事
"高并发"对后台开发同学来说,既熟悉又陌生。熟悉是因为面试和工作经常会提及它。陌生的原由是服务器因高并发导致出现各位问题的情况少之又少。同时,想收获这方面的经验也是"摸着石头过河", 需要大量学习理论知识,再去探索。
猴哥yuri
2018/10/18
2.1K1
高并发的那些事
高性能网络编程(二):上一个10年,著名的C10K并发连接问题1、前言 2、学习交流3、C10K问题系列文章4、C10K问题的提出者5、C10K问题的由来6、技术解读C10K问题7、C10K问题的本质
对于高性能即时通讯技术(或者说互联网编程)比较关注的开发者,对C10K问题(即单机1万个并发连接问题)应该都有所了解。“C10K”概念最早由Dan Kegel发布于其个人站点,即出自其经典的《The C10K problem(英文PDF版、中文译文)》一文。
JackJiang
2018/08/23
1.5K0
高性能网络编程(二):上一个10年,著名的C10K并发连接问题1、前言
2、学习交流3、C10K问题系列文章4、C10K问题的提出者5、C10K问题的由来6、技术解读C10K问题7、C10K问题的本质
套接字Socket编程
Socket,原意插座、插口。写软件程序时,可以想象成一根网线,一头插在客户端,一头插在服务端,然后进行通信。所以通信前,双方都要建立一个Socket。
JavaEdge
2021/10/18
1.5K0
网络协议 10 - Socket 编程(上):实践是检验真理的唯一标准
    前面一直在说各种协议,偏理论方面的知识,这次咱们就来认识下基于 TCP 和 UDP 协议这些理论知识的 Socket 编程。
北国风光
2019/04/11
1.1K0
网络协议 10 - Socket 编程(上):实践是检验真理的唯一标准
这次答应我,一举拿下 I/O 多路复用!
要想客户端和服务器能在网络中通信,那必须得使用 Socket 编程,它是进程间通信里比较特别的方式,特别之处在于它是可以跨主机间通信。
小林coding
2021/03/30
7530
这次答应我,一举拿下 I/O 多路复用!
Linux IO 模型
先抛出一个问题,基于此问题引出文章的主题:1999 年 Dan Kegel 在其个人站点提出了 C10K问题,首字母 C 是 Client 的缩写,C10K 即单机同时处理 1 万个连接的问题。C10K 表示处理 10000 个并发连接,注意这里的并发连接和每秒请求数不同,虽然它们是相似的,每秒处理许多请求需要很高的吞吐量(快速处理它们),但是更大数量的并发连接需要高效的连接调度,即 I/O 模型的问题。
政采云前端团队
2023/11/14
3690
Linux IO 模型
高性能网络编程(七):到底什么是高并发?一文即懂!
本文由小米信息技术团队研发工程师陈刚原创,原题“当我们在谈论高并发的时候究竟在谈什么?”,为了更好的内容呈现,即时通讯网收录时有修订和改动。 1、引言 在即时通讯网社区里,多是做IM、消息推送、客服系
JackJiang
2020/09/03
1.3K0
腾讯三面:一台服务器,最大支持的TCP连接数是多少?
很多同学第一反应就是端口的限制,端口号最多是 65536个,那就最多只能支持 65536 条 TCP 连接。
小林coding
2024/01/20
3.7K1
腾讯三面:一台服务器,最大支持的TCP连接数是多少?
详解Linux服务器最大tcp连接数
网络编程 在tcp应用中,server事先在某个固定端口监听,client主动发起连接,经过三路握手后建立tcp连接。那么对单机,其最大并发tcp连接数是多少?
zero000
2019/04/08
22.5K0
详解Linux服务器最大tcp连接数
深入单机TCP服务器最大连接数
在确定最大连接数之前,先来看看系统如何标识一个tcp连接。系统用一个4四元组来唯一标识一个TCP连接:{local ip, local port,remote ip,remote port}。
sunsky
2021/01/07
10.8K0
网络基础篇-网络编程
在内核中,为每个socket维护两个队列,一个是已建立连接的队列,也就是完成了三次握手,处于established状态,一个是还没有完全建立连接的队列,处于sync_rcvd状态。
Check King
2021/08/09
7720
高性能网络编程 - The C10K problem 以及 网络编程技术角度的解决思路
中文地址: https://www.oschina.net/translate/c10k
小小工匠
2023/11/09
3560
高性能网络编程 - The C10K problem 以及 网络编程技术角度的解决思路
以网游服务端的网络接入层设计为例,理解实时通信的技术挑战
以现在主流的即时通讯应用形态来讲,一个完整的即时通讯IM应用其实是即时通信(英文简写:IM=Instant messaging)和实时通信(英文简写:RTC=Real-time communication)2种技术组合在一起的一整套网络通信系统。之所以以IM这个简写代称整个即时通讯软件,其实是历史原因了(因为早期的诸如ICQ这样的即时通讯工具,也就是文字聊天,并没有加入实时音视频这样的实时通信技术),对这个话题有兴趣的可以到网上查一查IM的发展历史。
JackJiang
2018/08/29
1.9K0
百万并发连接挑战:wrk的高并发测试深度解析
当下性能测试已成为确保软件质量的关键环节。其中,wrk作为一款轻量级、高性能的HTTP基准测试工具,以其简洁的命令行界面和出色的性能著称。wrk通过-c参数能够模拟高并发的网络请求,帮助我们评估服务器在极端负载下的表现。如果你打算做C10K数万并发连接这个量级的测试,wrk是合适的(相比ab/jmeter等工具),然而,如果你想尝试进行数百万级别的高并发测试时,官方wrk就无能为力了。
陶辉
2024/06/12
7630
百万并发连接挑战:wrk的高并发测试深度解析
单服100w长连接报告笔记
建议直接看参考的原版报告,这篇为我大致记录的一些配置,部分还为理解,后续进行修改补充。
solate
2019/07/22
7050
了解一波经典的 I/O 模型
上图以 UDP 的 Socket 调用为例,进程调用 recvfrom 后,系统调用直到数据报到达且被复制到用户空间中或发生错误才返回。进程从调用开始到它返回的整段时间内是被阻塞的。recvfrom 成功返回后,应用进程开始处理数据报。
Cloud-Cloudys
2020/07/06
6000
高并发架构的TCP知识介绍
做为一个有追求的程序员,不能只满足增删改查,我们要对系统全方面无死角掌控。掌握了这些基本的网络知识后,相信一方面日常排错中会事半功倍,另一方面日常架构中不得不考虑的高并发问题,理解了这些底层协议也是会如虎添翼。
大愚
2019/05/15
1K0
Golang适合高并发场景的原因分析
典型的两个现实案例: 我们先看两个用Go做消息推送的案例实际处理能力。 360消息推送的数据: 16台机器,标配:24个硬件线程,64GB内存 Linux Kernel 2.6.32 x86_64 单机80万并发连接,load 0.2~0.4,CPU 总使用率 7%~10%,内存占用20GB (res) 目前接入的产品约1280万在线用户 2分钟一次GC,停顿2秒 (1.0.3 的 GC 不给力,直接升级到 tip,再次吃螃蟹) 15亿个心跳包/天,占大多数。 京东云消息推送系统 (团队人数:4)
李海彬
2018/03/21
2.6K0
Golang适合高并发场景的原因分析
Epoll技术补充及扩展
在之前的文章中分别详细讲解网络IO模型以及IO复用模型技术实现的本质,关于epoll的技术分析,发现存在部分知识点不够严谨且也有些混乱,即epoll技术在linux底层内核源码实现中暂时没有看到有使用虚拟内存分配的技术实现,因此对此知识点持有怀疑但保留网络上的技术资料观点;其次关于epoll技术实现上,正是通过使用中间层的设计思想来解决本身select/poll无法扩展的局限性,同时借助分散的设计思想来解决select/poll存在的性能,最后我们会关注与epoll相关的其他高级轮询技术以及在早期中C10K问题是如何解决的,同时互联网技术发展至今,又出现C10M问题,解决思路有哪些可以借鉴的.
小坤探游架构笔记
2020/03/25
5700
性能之网络篇
如果我们站在本机机器作为参考物的话,应该拆分成下面三个阶段: 1.消息入口流量部分的处理流程
灰子学技术
2022/06/25
8520
性能之网络篇
推荐阅读
相关推荐
高并发的那些事
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档