最多能创建多少个 TCP 连接？( 二 ) _TCP

哎不对，建立一个 TCP 连接，需要将通信两端的套接字（socket）进行绑定，如下：
源 IP 地址：源端口号 <----> 目标 IP 地址：目标端口号
只要这套绑定关系构成的四元组不重复即可，刚刚端口号不够用了，是因为我一直对同一个目标IP和端口建立连接，那我换一个目标端口号试试。

文章插图

文章插图

看来成功了，只要源端口号不用够用了，就不断变换目标 IP 和目标端口号，保证四元组不重复，我就能创建好多好多 TCP 连接啦！
这也证明了有人说最多只能创建 65535 个TCP连接是多么荒唐。

文件描述符
找到了突破端口号限制的办法，我不断找老操建立TCP连接，老操也拿我没有办法。
直到有一次，我又收到了一张特殊的纸条，上面写的不是文件描述符。

文章插图

我又没好气地问老操，"这又是咋回事？"
老操幸灾乐祸地告诉我，"呵呵，你小子以为突破端口号限制就无法无天了？现在文件描述符不够用啦！"
"怎么啥啥都有限制啊？你们操作系统给我们的限制也太多了吧？"
"废话，你看看你都建了多少个TCP连接了！每建立一个TCP连接，我就得分配给你一个文件描述符，linux 对可打开的文件描述符的数量分别作了三个方面的限制。"
系统级：当前系统可打开的最大数量，通过 cat /proc/sys/fs/file-max 查看
用户级：指定用户可打开的最大数量，通过 cat /etc/security/limits.conf 查看
进程级：单个进程可打开的最大数量，通过 cat /proc/sys/fs/nr_open 查看

文章插图

天呢，真是人在屋檐下呀，我赶紧看了看这些具体的限制。
[root ~]# cat /proc/sys/fs/file-max
100000
[root ~]# cat /proc/sys/fs/nr_open
100000
[root ~]# cat /etc/security/limits.conf
...
* soft nproc 100000
* hard nproc 100000
原来如此，我记得刚刚收到的最后一张纸条是。

文章插图

再之后就收到文件描述符不够的错误了。
我又请教老操，"老操，那这个限制可以修改么？"
老操仍然耐心地告诉我，"当然可以，比如你想修改单个进程可打开的最大文件描述符限制为100，可以这样。"
echo 100 > /proc/sys/fs/nr_open
"原来如此，我这就去把各种文件描述符限制都改大一点，也不多，就在后面加个0吧"
"额，早知道不告诉你小子了。"老操再次用鄙视的眼睛看着我。

线程
突破了文件描述符限制，我又开始肆无忌惮地创建起了TCP连接。
但我发现，老操的办事效率越来越慢，建立一个TCP连接花的时间越来越久。
有一次，我忍不住责问老操，"你是不是在偷懒啊？之前找你建一个TCP连接就花不到一分钟时间，你看看最近我哪次不是等一个多小时你才搞好？"
老操也忍不住了，"小进啊你还好意思说我，你知不知道你每建一个TCP连接都需要消耗一个线程来为你服务？现在我和CPU老大那里都忙得不可开交了，一直在为你这好几十万个线程不停地进行上下文切换，我们精力有限啊，自然就没法像以前那么快为你服务了。"

文章插图

听完老操的抱怨，我想起了之前似乎有人跟我说过 C10K 问题，就是当服务器连接数达到 1 万且每个连接都需要消耗一个线程资源时，操作系统就会不停地忙于线程的上下文切换，最终导致系统崩溃，这可不是闹着玩的。
我赶紧像操作系统老大请教，"老操，实在不好意思，一直以为你强大无比，没想到也有忙得不可开交的时候呀，那我们现在应该怎么办呀？"
老操无奈地说，"我劝你还是别再继续玩了，没什么意义，不过我想你也不会听我的，那我跟你说两句吧。"
你现在这种每建一个TCP连接就创建一个线程的方式，是最传统的多线程并发模型，早期的操作系统也只支持这种方式。但现在我进化了，我还支持 IO 多路复用的方式，简单说就是一个线程可以管理多个 TCP 连接的资源，这样你就可以用少量的线程来管理大量的 TCP 连接了。