摘要:对端,通过增加内存修改最大文件描述符个数等参数,单机最大并发连接数超过万甚至上百万是没问题的,国外公司在产品环境中已做到万并发
[TOC]
前言曾几何时我们还在寻求网络编程中C10K问题的解决方案,但是现在从硬件和操作系统支持来看单台服务器支持上万并发连接已经没有多少挑战性了。
我们先假设单台服务器最多只能支持万级并发连接,其实对绝大多数应用来说已经远远足够了,但是对于一些拥有很大用户基数的互联网公司,往往面临的并发连接数是百万,千万,甚至腾讯的上亿(注:QQ默认用的UDP协议)。
虽然现在的集群,分布式技术可以为我们将并发负载分担在多台服务器上,那我们只需要扩展出数十台电脑就可以解决问题,但是我们更希望能更大的挖掘单台服务器的资源,先努力垂直扩展,再进行水平扩展,这样可以有效的节省服务器相关的开支(硬件资源,机房,运维,电力其实也是一笔不小的开支)。
那么到底一台服务器能够支持多少TCP并发连接呢?
文件句柄限制在linux下编写网络服务器程序的朋友肯定都知道每一个tcp连接都要占一个文件描述符,一旦这个文件描述符使用完了,新的连接到来返回给我们的错误是:
“Socket/File:Can"t open so many files”
这时你需要明白操作系统对可以打开的最大文件数的限制。
进程限制执行 ulimit -n输出 1024,说明对于一个进程而言最多只能打开1024个文件,所以你要采用此默认配置最多也就可以并发上千个TCP连接。
临时修改:ulimit -n 1000000,但是这种临时修改只对当前登录用户目前的使用环境有效,系统重启或用户退出后就会失效。
重启后失效的修改(不过我在CentOS 6.5下测试,重启后未发现失效):编辑 /etc/security/limits.conf 文件, 修改后内容为
soft nofile 1000000
hard nofile 1000000
永久修改:编辑/etc/rc.local,在其后添加如下内容
ulimit -SHn 1000000
全局限制执行 cat /proc/sys/fs/file-nr 输出 9344 0 592026,分别为:
1.已经分配的文件句柄数
2.已经分配但没有使用的文件句柄数
3.最大文件句柄数。
但在kernel 2.6版本中第二项的值总为0,这并不是一个错误,它实际上意味着已经分配的文件描述符无一浪费的都已经被使用了 。
我们可以把这个数值改大些,用 root 权限修改 /etc/sysctl.conf 文件:
fs.file-max = 1000000 net.ipv4.ip_conntrack_max = 1000000 net.ipv4.netfilter.ip_conntrack_max = 1000000端口号范围限制?
操作系统上端口号1024以下是系统保留的,从1024-65535是用户使用的。
由于每个TCP连接都要占一个端口号,所以我们最多可以有60000多个并发连接。我想有这种错误思路朋友不在少数吧?(其中我过去就一直这么认为)
我们来分析一下吧
其实65535这个数字,只是决定了服务器端最多可以拥有65535个Bind的Socket。
也就是说,最多可以开65535个服务器进程,但是你要知道这个能够连接客户端的数量没有任何关系,Accept过来的Socket是不需要Bind任何IP地址的,也没有端口占用这一说。作为Server端的Socket本身只负责监听和接受连接操作
如何标识一个TCP连接:系统用一个4四元组来唯一标识一个TCP连接:{local ip, local port,remote ip,remote port}。
我们作为服务端实际只使用了bind时这一个端口,说明端口号65535并不是并发量的限制。
server最大tcp连接数:server通常固定在某个本地端口上监听,等待client的连接请求。
不考虑地址重用(unix的SO_REUSEADDR选项)的情况下,即使server端有多个ip,本地监听端口也是独占的,因此server端tcp连接4元组中只有remote ip(也就是client ip)和remote port(客户端port)是可变的,
因此最大tcp连接为客户端ip数×客户端port数,对IPV4,不考虑ip地址分类等因素,最大tcp连接数约为2的32次方(ip数)×2的16次方(port数),
也就是server端单机最大tcp连接数约为2的48次方。
TCP连出受端口限制,连入仅受内存限制
总结上面给出的结论都是理论上的单机TCP并发连接数,实际上单机并发连接数肯定要受硬件资源(内存)、网络资源(带宽)的限制。
对server端,通过增加内存、修改最大文件描述符个数等参数,单机最大并发TCP连接数超过10万,甚至上百万 是没问题的,国外 Urban Airship 公司在产品环境中已做到 50 万并发
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/72526.html
摘要:问题任一文件句柄的不成功会阻塞住整个应用。主要解决的前两个问题通过一个数组向内核传递需要关注的事件消除文件句柄上限,同时使用不同字段分别标注关注事件和发生事件,来避免重复初始化。问题逐个排查所有文件句柄状态效率不高。 C10K问题思维导图 showImg(https://segmentfault.com/img/bVbkrKe?w=1818&h=1276); C10K问题出现前期 大家...
摘要:缺点每个连接需要独立的进程线程单独处理,当并发请求量大时为了维护程序,内存线程切换开销较大,这种模型在实际生产中很少使用。而在系统下,才引入,目前并不完善,因此在下实现高并发网络编程时都是以复用模型模式为主。 思维导图 showImg(https://segmentfault.com/img/bVbkrNz?w=1766&h=994); 互联网服务端处理网络请求的原理 首先看看一个典型...
摘要:如需了解更多物联网网络编程知识请点击物联网云端开发武器库物联网高并发编程之网络编程中的线程模型值得说明的是,具体选择线程还是进程,更多是与平台及编程语言相关。 如需了解更多物联网网络编程知识请点击:物联网云端开发武器库 物联网高并发编程之网络编程中的线程模型 值得说明的是,具体选择线程还是进程,更多是与平台及编程语言相关。例如 C 语言使用线程和进程都可以(例如 Nginx 使用进程...
摘要:前言这篇文章的主题是记录一次程序的性能优化,在优化的过程中遇到的问题,以及如何去解决的。因为我们的连接数只有,一旦请求过多,势必会导致数据库瓶颈。我们再次压测,结果显示万,服务器数据库连接正常,连接正常,响应时间平均为,错误率为。 前言 这篇文章的主题是记录一次Python程序的性能优化,在优化的过程中遇到的问题,以及如何去解决的。为大家提供一个优化的思路,首先要声明的一点是,我的方式...
阅读 2920·2023-04-25 19:20
阅读 767·2021-11-24 09:38
阅读 2008·2021-09-26 09:55
阅读 2415·2021-09-02 15:11
阅读 1888·2019-08-30 15:55
阅读 3590·2019-08-30 15:54
阅读 3131·2019-08-30 14:03
阅读 2945·2019-08-29 17:11