TCP/IP 的 socket服务器怎么处理 高链接（1万个以上） 高并发的链接请求？

Question

开发工具是 C# ，多线程无法支持这么多的连接数，请问各位有什么好的处理方法。在线等。谢谢。

Answer 1

异步的socket操作；这样就不会有线程的问题了；但我们现在做的中大型的软件都没有达到同时在线那么大；你可以考虑负载均衡，用多台来处理这一万个连接；

Answer 2

使用线程池异步处理socket链接，你说的“多线程无法支持这么多的连接数”不知道是什么意思，这么多的链接肯定是要在线程里处理的。我也正要写这样的一个服务程序是处理Gprs链接的，希望能够有空可以交流一下，我的QQ 305744659

Answer 3

例如web服务器，人家可以支持全世界几十亿用户访问，也没有见开发者叫着说“多线程无法支持这么多的连接数”的说法。

Answer 4

静态html 图片放在一个独立的服务器

Answer 5

抱歉，我说的不是很清楚。 我做的不是Web服务器。是C/S结构的，而且只有一台服务器，必须使用同一个端口，需要写一个服务程序，与客户端进行数据交互。谢谢大家

Answer 6

可能我没说清楚。我只是写个服务器程序而已。 不是你想的那种Web服务器。

Answer 7

完成端口(IOCP)模型

Answer 8

重點不在連接數的多少，而在于工作的幷發度，也就是看每個連接是否都一直需要在線忙碌中。如果是那樣，一萬個以上的幷發度是很驚人的。
否則的話，就可以使用線程緩存的實現方式，設立一個監聽線程負責接受客戶端的鏈接請求，然後用線程池管理實際處理客戶請求，監聽線程接受到請求以後，從線程池中調度出空閒的工作線程。如果真是一萬以上高幷發工作的話，問題就不能那麼簡單了。需要考慮到硬件層面的冗餘和負載平衡。細說起來就多了。另外一般連接數比較大的話，選擇用UDP協議比較合適。自己設計連接存續的辦法，如果是tcp，網絡消耗是驚人的。當然也要考慮連接的實時性和穩定性的要求，tcp自然是更穩定的，但是代價是降低連接數，如果你是寫銀行類的系統，對這方面的要求應該比較高。如果像QQ這樣的系統，則用UDP協議比較明智。

Answer 9

瞎JB扯蛋扯到WEB上去了，WEB是短链接，而且是同步通讯，脑子有没有的，楼主是长连接处理，必须用IOCP模式来做，1W+的链接要看你的通讯数据，比如网络游戏的通讯数据，那1W+的链接用一台电脑就差不多足够了，如果是流媒体服务器的通讯，那肯定需要采用负载均衡和分布式来做

Answer 10

你先看看HTTP协议是基于什么的吧，请扎实技术，这样的东西不由得马虎，HTTP是TCP协议的一个应用，大牛举的例子没有什么不对，协议接收会有队列处理，数据量大的话可以考虑OLCP设计模式，百万处理量应该没有问题

Answer 11

当然，大牛的说法也不完全正确，2002年（大概吧，没印象了）爆发“僵尸病毒”挂掉网站服务器的事情大家还有印象吧，HTTP的特点是挂起时间长（几十亿不会在几毫秒内都来吧），这样的宽松队列可以应付，之后随着通信的即时性发展，逐步出现p2p、BT等分担服务器压力的软件，LZ应该向这方面考虑。

Answer 12

我的是必须24小时与客户端保持连接的。但每个客户端的数据量不大，一次数据传输不超过1KB，大多200B左右，除了每5到10分钟一次30B的心跳包（就是发一个数据包给服务器，确认此客户端在线）外，每小时响应一次服务器的数据抄读，在客户端有异常时，主动发一个异常信息给服务器。但是就是客户端比较多。会有1W左右。以上是我的服务器程序需要完成的工作，目前我是每个socket连接开了一个线程来处理。这样终端数量上就受到了限制。只要解决了数量问题，就算完成了。如果分不够，可以继续加，另开帖再加也可。谢谢大家。

Answer 13

你的第一种方法可行，但我们的客户端是终端设备，由于网络环境的限制，如何实现同一服务器IP和端口？
第二种方法中，由于终端设备是运行在公网上，IP是动态分配的，不可能做服务器。

Answer 14

呵呵，这个就要看你的处理队列编制了，例如，2个异地朋友组队打怪，因为网络原因，A的数据包发送流畅，而B断断续续，那就会出现处理队列上面A连续发送了多次包，而B却刚刚发送了一次，也就是说服务器上A的“抢线率”高，所以编排时候，注意安排下，本次接收后某时间段不再处理某客户端请求让他挂起等下，魔兽不是有“等待掉线玩家”么？
还有以计算机现在的速度，百万次应答是没有问题的（几个线程就循环吧，弄的来的），网游开发这个不算问题，问题是怎么简化加密的数据包，因为通信中最大的瓶颈是网络问题。