如何做到并发10万TCP连接_百度知道多线程实现并发TCP服务器_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
多线程实现并发TCP服务器
上传于||文档简介
&&介​绍​l​i​n​u​x​下​并​发​服​务​器​,​多​线​程​,​s​o​c​k​e​t​,​t​c​p
大小：694.00KB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢1861人阅读
第四个遇到的问题：tcp_mem
在服务端，连接达到一定数量，诸如50W时，有些隐藏很深的问题，就不断的抛出来。 通过查看dmesg命令查看，发现大量TCP: too many of orphaned sockets错误，也很正常，下面到了需要调整tcp socket参数的时候了。
第一个需要调整的是tcp_rmem，即TCP读取缓冲区，单位为字节，查看默认值
cat /proc/sys/net/ipv4/tcp_rmem
默认值为87380bit ≈ 86K，最小为4096bit=4K，最大值为4064K。
第二个需要调整的是tcp_wmem，发送缓冲区，单位是字节，默认值
cat /proc/sys/net/ipv4/tcp_wmem
第三个需要调整的tcp_mem，调整TCP的内存大小，其单位是页，1页等于4096字节。系统默认值：
cat /proc/sys/net/ipv4/tcp_mem
tcp_mem(3个INTEGER变量)：low, pressure, high
low：当TCP使用了低于该值的内存页面数时，TCP不会考虑释放内存。pressure：当TCP使用了超过该值的内存页面数量时，TCP试图稳定其内存使用，进入pressure模式，当内存消耗低于low值时则退出pressure状态。high：允许所有tcp sockets用于排队缓冲数据报的页面量，当内存占用超过此值，系统拒绝分配socket，后台日志输出“TCP: too many of orphaned sockets”。
一般情况下这些值是在系统启动时根据系统内存数量计算得到的。 根据当前tcp_mem最大内存页面数是1864896，当内存为()/.75M时，系统将无法为新的socket连接分配内存，即TCP连接将被拒绝。
实际测试环境中，据观察大概在99万个连接左右的时候(零头不算)，进程被杀死，触发out of socket memory错误（dmesg命令查看获得）。每一个连接大致占用7.5K内存（下面给出计算方式），大致可算的此时内存占用情况（990000 * 7.5 / 1024K = 7251M)。
这样和tcp_mem最大页面值数量比较吻合，因此此值也需要修改。
三个TCP调整语句为:
echo &net.ipv4.tcp_mem = &&& /etc/sysctl.conf
echo &net.ipv4.tcp_rmem = 777216&&& /etc/sysctl.conf
echo &net.ipv4.tcp_wmem = 777216&&& /etc/sysctl.conf
备注： 为了节省内存，设置tcp读、写缓冲区都为4K大小，tcp_mem三个值分别为3G 8G 16G，tcp_rmem和tcp_wmem最大值也是16G。
经过若干次的尝试，最终达到目标，1024000个持久连接。1024000数字是怎么得来的呢，两台物理机器各自发出64000个请求，两个配置为6G左右的centos测试端机器(绑定7个桥接或NAT连接)各自发出640007 = 448000。也就是 1024000 = (64000) + (64000) + (640007) + (64000*7), 共使用了16个网卡（物理网卡+虚拟网卡）。&
online user 1023990
online user 1023991
online user 1023992
online user 1023993
online user 1023994
online user 1023995
online user 1023996
online user 1023997
online user 1023998
online user 1023999
online user 1024000
在线用户目标达到1024000个！
服务器状态信息
服务启动时内存占用：
&&&&&&&&&&&&&&&& total&&&&&&&used&&&&&&&free&&&&&shared&&&&buffers&&&&&cached
&&&&Mem:&&&&&&&&&10442&&&&&&&&271&&&&&&10171&&&&&&&&&&0&&&&&&&&&22&&&&&&&&&78
&&&&-/+ buffers/cache:&&&&&&&&171&&&&&&10271
&&&&Swap:&&&&&&&&&8127&&&&&&&&&&0&&&&&&&8127
系统达到1024000个连接后的内存情况（执行三次 free -m 命令，获取三次结果）：
&&&&&&&&&&&&&&&& total&&&&&&&used&&&&&&&free&&&&&shared&&&&buffers&&&&&cached
&&&&Mem:&&&&&&&&&10442&&&&&&&7781&&&&&&&2661&&&&&&&&&&0&&&&&&&&&22&&&&&&&&&78
&&&&-/+ buffers/cache:&&&&&&&7680&&&&&&&2762
&&&&Swap:&&&&&&&&&8127&&&&&&&&&&0&&&&&&&8127
&&&&&&&&&&&&&&&&&total&&&&&&&used&&&&&&&free&&&&&shared&&&&buffers&&&&&cached
&&&&Mem:&&&&&&&&&10442&&&&&&&7793&&&&&&&2649&&&&&&&&&&0&&&&&&&&&22&&&&&&&&&78
&&&&-/+ buffers/cache:&&&&&&&7692&&&&&&&2750
&&&&Swap:&&&&&&&&&8127&&&&&&&&&&0&&&&&&&8127
&&&&&&&&&&&&&&&&&total&&&&&&&used&&&&&&&free&&&&&shared&&&&buffers&&&&&cached
&&&&Mem:&&&&&&&&&10442&&&&&&&7804&&&&&&&2638&&&&&&&&&&0&&&&&&&&&22&&&&&&&&&79
&&&&-/+ buffers/cache:&&&&&&&7702&&&&&&&2740
&&&&Swap:&&&&&&&&&8127&&&&&&&&&&0&&&&&&&8127
这三次内存使用分别是02，这次不取平均值，取一个中等偏上的值，定为7701M。那么程序接收1024000个连接，共消耗了 M = 7530M内存， K / 1024000 = 7.53K， 每一个连接消耗内存在为7.5K左右，这和在连接达到512000时所计算较为吻合。&
虚拟机运行Centos内存占用，不太稳定，但一般相差不大，以上数值，仅供参考。
执行top -p&某刻输出信息：
&&& top - 17:23:17 up 18 min,&&4 users,&&load average: 0.33, 0.12, 0.11
&&&&Tasks:&&&1 total,&&&1 running,&&&0 sleeping,&&&0 stopped,&&&0 zombie
&&&&Cpu(s):&&0.2%us,&&6.3%sy,&&0.0%ni, 80.2%id,&&0.0%wa,&&4.5%hi,&&8.8%si,&&0.0%st
&&&&Mem:&&k total,&&6479980k used,&&4213600k free,&&&&22916k buffers
&&&&Swap:&&8323056k total,&&&&&&&&0k used,&&8323056k free,&&&&80360k cached
&&&&&&PID USER&&&&&&PR&&NI&&VIRT&&RES&&SHR S %CPU %MEM&&&&TIME+&&COMMAND&&&&&&&&&&&&&&&&&&&&&&
&&&&&2924 yongboy&&&20&&&0 82776&&74m&&508 R 51.3&&0.7&&&3:53.95 server&
执行vmstate：
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
获取当前socket连接状态统计信息：
cat /proc/net/sockstat
sockets: used 1024380
TCP: inuse 1024009 orphan 0 tw 0 alloc 1024014 mem 2
UDP: inuse 11 mem 1
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0
获取当前系统打开的文件句柄：
sysctl -a | grep file
fs.file-nr =
fs.file-max = 1048576
此时任何类似于下面查询操作都是一个慢，等待若干时间还不见得执行完毕。
netstat -nat|grep -i &8000&|grep ESTABLISHED|wc -l
netstat -n | grep -i &8000& | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
以上两个命令在二三十分钟过去了，还未执行完毕，只好停止。
本次从头到尾的测试，所需要有的linux系统需要调整的参数也就是那么几个，汇总一下：
echo &yongboy soft nofile 1048576& && /etc/security/limits.conf
&&&&echo &yongboy hard nofile 1048576& &&&&/etc/security/limits.conf
&&&&echo &fs.file-max = 1048576& && /etc/sysctl.conf
&&&&echo &net.ipv4.ip_local_port_range = & && /etc/sysctl.conf
&&&&echo &net.ipv4.tcp_mem = & && /etc/sysctl.conf
&&&&echo &net.ipv4.tcp_rmem = 777216& && /etc/sysctl.conf
&&&&echo &net.ipv4.tcp_wmem = 777216& && /etc/sysctl.conf
其它没有调整的参数，仅仅因为它们暂时对本次测试没有带来什么影响，实际环境中需要结合需要调整类似于SO_KEEPALIVE、tcpmax_orphans等大量参数。
本文代表一次实践，不足之处，欢迎批评指正。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：9596928次
积分：43766
积分：43766
排名：第55名
原创：672篇
转载：1951篇
评论：451条
(9)(8)(30)(19)(19)(16)(1)(9)(7)(19)(13)(9)(4)(5)(28)(12)(34)(5)(3)(13)(27)(18)(11)(3)(23)(24)(31)(42)(12)(34)(19)(37)(41)(39)(56)(146)(66)(78)(78)(6)(15)(28)(26)(17)(57)(46)(25)(41)(24)(37)(70)(73)(28)(31)(35)(49)(54)(27)(25)(16)(21)(13)(24)(26)(35)(31)(27)(6)(6)(2)(3)(3)(7)(5)(10)(4)(9)(3)(2)(12)(11)(23)(5)(1)(9)(16)(11)(14)(4)(4)(28)(17)(37)(413)(2)(7)(1)(3)(4)(7)(6)(10)(28)(9)(6)如何测试一个服务器模型的最大并发度？
这里的并发度首先指的是建立起会话的TCP长连接数量，至少要达到C20K以上，在此基础上，继续测试能同时处理多少并发请求，即同一时刻最大能满足多少客户端发送数据且能全部接收。限于条件，我想用多线程模拟大量客户端进行并发测试，与服务端建立连接后开始发送数据。但是如何能实现可控数目的并发请求呢？接连不断的发送不合常理带宽也肯定受不了；由于连接的建立有时差，全部隔一段时间发送一次可能又不算并发请求。另外，究竟多长时间之内才算是并发？
最好能根据服务类型，明确并发的定义。可以参考测试工具有很多，如上面提到的jmeter，还有我常用的curlloader， httpd里包含的ab等。如果应用场景特殊，可能需要自己实现测试工具。
自己拿4内核IBM服务器+WindowsServer服务器进行实际测试，用IOCP连接轻松上10万个，服务器0CPU0RAM使用率！后来测试过100万连接也轻松完成。
虽然测试工具很多，但是很多工具实际上是在测防火墙，协议栈，框架本身的性能，由于没有上下文，不一定能够模拟到应用与后端交互的情况。所以最好还是自己写test啊。
游戏公司，为了测试服务器的并发与承载，会雇一些公会去做测试
jmeter题主可以试试
已有帐号？
无法登录？
社交帐号登录UDP和TCP哪个并发性能更好?为什么? - 开源中国社区
当前访客身份：游客 [
当前位置：
最近做服务器程序，采用socket进行传输，预期并发量较高，那采用UDP和TCP哪个更合适?希望做过这方面的給予点指导!
---------------问题补充---------------
：live555将RTSP实现为TCP连接，而TCP在NAT穿透上太困难，如果用UDP至少比NAT简单，但是要用UDP实现一遍RTSP协议，所以为了达到最终目标有两个方案:①Tcp连接用服务器做转发，但服务器吞吐量会很大;②用UDP在NAT穿透后直连，但要保证可靠性。大神指点哪种方案较好呢?
共有18个答案
<span class="a_vote_num" id="a_vote_num_
N年以来出现N次的烂话题了.&& 如果tcp能胜任, 优先tcp.
&&&&&& udp只适合丢消息无所谓, 流畅时能快速响应的情况.&& 视频等,赛车游戏等(第一个定位包丢了, 没事, 下一个定位包能把位置定准. ).&& 细想一下, 你在UDP上再搭一套稳健的机制,那不就是把tcp能保证的事情又实现了一遍了么?(而且你肯定实现的比tcp差& ) & tcp能胜任很多情况. 不要给自己找技术上的麻烦, 产品好不好,才是更关键的; 等产品能发大财, 而tcp却严重影响了发大财, 到时候你再改.你的产品8成不会发大财, 所以别瞎折腾了. & tcp &恶心&的地方, 第一 延迟发送,所以不够实时,快速.& 第二 流式接口, 所以有沾包问题(加包头就解决了). 如果这2点对你来说 不是麻烦的话, 就选tcp吧.& 别给自己找麻烦. 大家等你出东西呢, 你还在犹豫 我是用vi写代码呢? 还是用IDE写代码. 这不胡闹么.&& 另外tcp在互联网环境下吞吐量非常好, 这一点, udp估计只能在网络极好的局域网才能远超tcp.& 路由器在不负重压的情况下, 肯定也会先照顾tcp包(反正大家都默认UDP包是可以丢的)
& & 如果最后决定UDP的话, 请使用优秀的库, 不要自己搭.
--- 共有 3 条评论 ---
大婶啊，语言浅显易懂。赞一个。
(3年前)&nbsp&
说的真的很好 赞一个！
(3年前)&nbsp&
经验之谈，真好
(3年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
谁能并发得过QQ
--- 共有 1 条评论 ---
qq支持tcp和udp
(3年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
我也觉得是UDP，可是有人告诉我是TCP，故此一问。
--- 共有 1 条评论 ---
UDP只管发，不管你收到没有收到，，TCP要经过3次握手。
(3年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
TCP有可靠性保障，但是开销大，总而言之，两者的应用场合是完全不一样的
--- 共有 2 条评论 ---
: 百度“UDP可靠通信”
(3年前)&nbsp&
我希望用UDP实现Tcp的可靠性，可不可以呢?
(3年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
引用来自“Lunar_Lin”的答案N年以来出现N次的烂话题了.&& 如果tcp能胜任, 优先tcp.
&&&&&& udp只适合丢消息无所谓, 流畅时能快速响应的情况.&& 视频等,赛车游戏等(第一个定位包丢了, 没事, 下一个定位包能把位置定准. ).&& 细想一下, 你在UDP上再搭一套稳健的机制,那不就是把tcp能保证的事情又实现了一遍了么?(而且你肯定实现的比tcp差& ) & tcp能胜任很多情况. 不要给自己找技术上的麻烦, 产品好不好,才是更关键的; 等产品能发大财, 而tcp却严重影响了发大财, 到时候你再改.你的产品8成不会发大财, 所以别瞎折腾了. & tcp &恶心&的地方, 第一 延迟发送,所以不够实时,快速.& 第二 流式接口, 所以有沾包问题(加包头就解决了). 如果这2点对你来说 不是麻烦的话, 就选tcp吧.& 别给自己找麻烦. 大家等你出东西呢, 你还在犹豫 我是用vi写代码呢? 还是用IDE写代码. 这不胡闹么.&& 另外tcp在互联网环境下吞吐量非常好, 这一点, udp估计只能在网络极好的局域网才能远超tcp.& 路由器在不负重压的情况下, 肯定也会先照顾tcp包(反正大家都默认UDP包是可以丢的)
& & 如果最后决定UDP的话, 请使用优秀的库, 不要自己搭.
TCP有些问题是很严重的，比如在低可靠网络上的重传会加剧网络性能恶化，这些是协议设计的历史问题，特殊场合还只能用自行封装的可靠UDP，不过大部分场合TCP/UDP选其一就能胜任
--- 共有 1 条评论 ---
(3年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
引用来自“Mallon”的答案引用来自“Lunar_Lin”的答案N年以来出现N次的烂话题了.&& 如果tcp能胜任, 优先tcp.
&&&&&& udp只适合丢消息无所谓, 流畅时能快速响应的情况.&& 视频等,赛车游戏等(第一个定位包丢了, 没事, 下一个定位包能把位置定准. ).&& 细想一下, 你在UDP上再搭一套稳健的机制,那不就是把tcp能保证的事情又实现了一遍了么?(而且你肯定实现的比tcp差& ) & tcp能胜任很多情况. 不要给自己找技术上的麻烦, 产品好不好,才是更关键的; 等产品能发大财, 而tcp却严重影响了发大财, 到时候你再改.你的产品8成不会发大财, 所以别瞎折腾了. & tcp &恶心&的地方, 第一 延迟发送,所以不够实时,快速.& 第二 流式接口, 所以有沾包问题(加包头就解决了). 如果这2点对你来说 不是麻烦的话, 就选tcp吧.& 别给自己找麻烦. 大家等你出东西呢, 你还在犹豫 我是用vi写代码呢? 还是用IDE写代码. 这不胡闹么.&& 另外tcp在互联网环境下吞吐量非常好, 这一点, udp估计只能在网络极好的局域网才能远超tcp.& 路由器在不负重压的情况下, 肯定也会先照顾tcp包(反正大家都默认UDP包是可以丢的)
& & 如果最后决定UDP的话, 请使用优秀的库, 不要自己搭.
TCP有些问题是很严重的，比如在低可靠网络上的重传会加剧网络性能恶化，这些是协议设计的历史问题，特殊场合还只能用自行封装的可靠UDP，不过大部分场合TCP/UDP选其一就能胜任
UDP 就像宏哥一样, 只管喊话, 听不听得懂得看自己了.
TCP 用气量简单, 实际上, 操作系统层面的TCP太即把啰嗦了
有些时候, 只能UDP
<span class="a_vote_num" id="a_vote_num_
论并发性UDP,论可靠性TCP,鱼和熊掌不可兼得,虽然有人实现了高可靠性的UDP
--- 共有 1 条评论 ---
高可靠性的UDP是怎么实现的，太神奇了。
(3年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
并发UDP 你可以通过编程来实现TCP的一些功能和检查
<span class="a_vote_num" id="a_vote_num_
可否说来听听多大的并发量啊？
--- 共有 2 条评论 ---
千万级，真的没碰过。不好乱说了
(3年前)&nbsp&
估计目前不会超过千万.
(3年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
都收了。。。管他那个。。。不就是接收数据吗？把消息处理和通信机制剥离开。。
爱用那个就用那个。。。
更多开发者职位上
有什么技术问题吗？
梁欢的其它问题
类似的话题