多个客户端同时连接服务器时，单线程socket服务端一次只能处理一个客户端的请求，要想实现真正的并发处理，主流方案是多线程/多进程模型配合非阻塞I/O或事件驱动机制，其中Linux下首选epoll，Windows下首选IOCP。
socket多客户端连接怎么实现：从阻塞到并发
先看一个最基础的场景,你写了一个socket服务端，代码里是accept()等待客户端接入，然后recv()接收数据，这个流程在单个客户端时完全没问题，但一旦第二个客户端连上来，服务端正卡在第一个客户端的recv()里，第二个客户端只能在连接队列里干等。
问题出在阻塞式I/O上。recv()在没有数据时会让出CPU，线程挂起，服务端只有一个线程，它挂起了，其他客户端自然没人搭理。
用多线程处理每个客户端连接
最简单的改造思路：每来一个客户端，就开一个线程专门伺候它。
while (1) {
client_fd = accept(server_fd, NULL, NULL);
pthread_create(&tid, NULL, handle_client, &client_fd);
}
这段代码的逻辑很直观,accept()每返回一个客户端套接字，就创建一个新线程去处理读写，各客户端之间互不干扰，一个客户端卡住了，不影响其他人。
但这种方式有个隐患：如果同时有几千个客户端在线，就要创建几千个线程，线程切换开销大，内存占用高，服务器分分钟被拖垮，业内专家指出，线程数超过一定阈值后，吞吐量反而会下降。
用I/O多路复用监听所有连接
与其给每个客户端分配一个线程,不如让一个线程监管所有连接，这就是select、poll、epoll这些I/O多路复用机制做的事。
select模型的工作方式：把一批文件描述符交给内核，内核轮询这些fd，一旦有数据到达就通知用户程序去处理，它的问题在于fd数量上限，默认是1024个，而且每次调用都要把整个fd集合从用户态拷贝到内核态，性能堪忧。
poll解决了fd数量限制,但仍然是遍历式的，连接数过万时效率明显下降。
epoll是Linux下的事实标准,它注册一组fd到内核，内核只把有事件发生的fd通知回来，不需要遍历全部连接，活跃连接占比越低，epoll的效率优势越明显。
epoll_fd = epoll_create(1);
epoll_ctl(epoll_fd, EPOLL_CTL_ADD, server_fd, &ev);
while (1) {
n = epoll_wait(epoll_fd, events, MAX_EVENTS, -1);
for (i = 0; i < n; i++) {
// 处理新连接或读写事件
}
}
事件驱动框架隐藏了这些细节
实际项目里很少直接手写epoll,大多数情况用的是Netty、libevent、Go的goroutine模型，Netty基于Java NIO封装了reactor模式，libevent把select、poll、epoll统一成了同一套API，Go语言则从语言层面把并发连接变成了”每个连接一个goroutine”的简单姿势。
对于游戏服务器、聊天室这类高并发场景，事件驱动框架基本是标配，选型时要考虑语言的生态和自己的熟悉程度，Netty在Java领域一家独大，Go则胜在部署简单、内存占用低。
socket保活机制：客户端掉线怎么及时发现
多客户端场景下,一个绕不开的问题是：客户端拔了网线或者断电，服务端怎么知道？
TCP本身有keepalive机制，但默认参数是两个小时才探测一次，对大多数业务来说太慢了，行业共识认为，应用层心跳是更靠谱的方案。
设计一套心跳协议
客户端每隔一段时间（比如30秒）发一个心跳包，服务端收到后更新该连接的最后活跃时间，服务端另起一个定时任务，扫描所有连接，超过90秒没收到心跳包的，直接判定为掉线，关闭连接释放资源。
心跳包格式不用复杂,几个字节就够，比如一个固定的魔法数字加上客户端ID，做游戏开发的同行习惯把心跳和业务数据分开，心跳走独立的短连接，业务走长连接，这样能避免心跳包被业务数据阻塞。
服务端主动探测的兜底方案
有些场景下客户端不主动发心跳,而是由服务端定时发送探测包，比如向客户端发一个Ping，如果在规定时间内没收到Pong，就重试几次，连续失败则断开连接。
这种方案适合客户端逻辑简单、不方便维护心跳定时器的场景，比如物联网设备，固件里实现心跳逻辑比较麻烦，服务端主动探测反而更省事。
保活参数要结合具体场景调
- 局域网内部署,网络质量好，心跳间隔可以放宽到60秒以上
- 公网环境,尤其是移动网络，客户端IP会频繁变化，心跳间隔建议15到30秒
- 游戏对战场景,延迟敏感，心跳间隔5到10秒，超时时间也要相应缩短
socket连接数限制：一台服务器到底能撑多少客户端
这是很多开发者关心的问题,先说结论：一台普通的Linux服务器，跑一个基于epoll的服务端，挂5万个长连接是可行的，前提是内存和文件描述符数量跟得上。
文件描述符上限是第一个瓶颈
每个socket连接占用一个文件描述符,Linux默认的fd上限是1024，不调整的话，超过1024个连接就报Too many open files。
用root用户执行下面的命令查看当前限制：
ulimit -n
临时修改：
ulimit -n 100000
永久修改需要编辑/etc/security/limits.conf，加入：
soft nofile 100000
hard nofile 100000注意,改了之后要重新登录终端才生效。
内存占用是第二个瓶颈
每个TCP连接的内核缓冲区默认大约是几十KB，加上应用层为每个连接维护的缓存区、业务数据、连接对象，一个空闲连接大概占用
2到5MB内存是常见情况，按5万连接算，光内存就需要100GB以上，所以实际上连接数上限更多的是被内存卡住，而不是协议本身。
端口号并不是限制因素
有一种说法是”客户端端口只有65535个，所以最多65535个连接”，这其实是误解，服务端监听一个端口，可以接受来自任意客户端IP和端口组合的连接，如果客户端来自不同的IP，连接数可以轻松超过六万，如果只有一台客户端机器，那确实受限于它的端口数上限，但那是客户端侧的限制，不是服务端的。
多客户端通信的几种典型架构
广播模式
服务端收到一个客户端的消息,原样转发给所有其他客户端，聊天室就是这种模式，实现上就是一个连接列表，遍历发送即可，要注意的是，如果一个客户端发送慢，会拖累整个广播循环，实践中通常给每个连接配一个发送队列，发送操作异步化。
分组模式
按房间或频道把客户端分组,消息只发给组内成员，游戏中的公会频道、在线教育的小班课都属于这种，实现上是一个Map<房间ID, List<连接>>的结构，加锁要小心，用读写锁或者并发HashMap避免并发问题。
点对点转发
客户端A要给客户端B发消息,服务端根据B的ID查找到对应连接，直接转发，这种模式需要维护一个连接ID到socket的映射表，一般用ConcurrentHashMap这种结构。
消息推送模式
服务端主动向客户端推送数据,客户端只负责接收，这种场景下客户端和服务端之间的连接保活就特别重要，推送系统的连接掉线意味着用户收不到通知。
| 场景 | 推荐方案 | 关键点 |
|---|---|---|
| 在线聊天室 | select/epoll + 广播 | 发送队列要异步化 |
| 游戏服务器 | epoll + 分组广播 | 帧同步和状态同步要分开 |
| 物联网设备 | 服务端主动探测保活 | 设备资源有限，心跳间隔要长 |
| 金融行情推送 | 多线程 + 独立发送线程 | 延迟敏感，不能阻塞 |
实际部署中容易踩的坑
Nagle算法和延迟确认的冲突
TCP默认开启Nagle算法,它会合并小数据包，减少网络包数量，但如果同时开启了TCP延迟确认，就会出现40毫秒级别的延迟，做实时性要求高的应用，考虑关闭Nagle算法：
int flag = 1; setsockopt(client_fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));
半关闭状态的清理
客户端没有正常关闭,而是直接断开物理连接，服务端的连接会处于半开状态，TCP keepalive默认要两小时才能发现，所以应用层心跳不仅是为了保活，也是在加速无效连接的回收。
广播风暴的规避
广播模式下,如果一个客户端的消息频率特别高，比如每秒发100条，服务端要转发给N个客户端，那就是每秒100×N条消息，这种放大效应很容易打爆带宽，实践中一般对每个客户端的发言频率做限制，比如每秒最多5条。
多线程下共享连接集合的并发问题
多个线程同时操作客户端的连接集合,增删改查都要加锁，但锁的粒度要控制好，持锁时间过长会阻塞其他线程的读写，常见做法是用分段锁或者读写锁，读多写少的场景用读写锁能显著提升并发度。
从一个echo服务端到能扛住上万连接的完整路径
假设你从零开始写一个socket服务端,按照下面的步骤递进：
- 单线程阻塞模型：先跑通基本收发逻辑，理解socket的accept、recv、send流程
- 多线程模型：每个客户端一个线程，解决并发问题，但注意线程数上限
- select模型：单线程管理多个连接，突破线程数限制，但fd上限1024
- poll模型：解除fd数量限制，但仍然是线性遍历
- epoll模型：事件驱动，只处理有事件的fd，支持万级连接
- 在此基础上加心跳、加超时重连、加消息队列，逐步完善
每一步都有明确的上限和瓶颈,理解这些瓶颈的成因，你就知道为什么大厂的服务端框架要设计得那么复杂。
对于绝大多数业务场景,epoll + 事件循环 + 应用层心跳这套组合已经足够，如果连接数真的到了几十万上百万，那就要考虑分布式部署，用网关做负载均衡把连接分散到多台机器上，每台机器管一部分连接，机器之间用消息队列同步数据。
服务器和多个客户端socket常见问题解答
服务端accept之后，原来的监听socket还能继续接收新连接吗？
能,accept函数返回的是新创建的已连接socket，服务端的监听socket始终在监听状态，专用于接收新连接请求，一个服务端可以同时有多个已连接socket和一个监听socket，它们互不干扰。
客户端断开连接后，服务端怎么感知到？
正常断开时,服务端调用recv会返回0，表示对方已关闭，异常断开时，比如断电或拔网线，recv不会立即返回，需要依赖心跳机制或TCP keepalive来定时检测，应用层心跳间隔越短，感知掉线就越快，但心跳本身也会消耗网络资源，需要根据业务场景权衡。
socket连接数上限受什么因素影响？
主要受三方面限制：操作系统文件描述符上限（可用ulimit调整）、物理内存大小（每个连接都占用内核缓冲区和用户态缓冲区）、以及业务逻辑中每个连接对象的内存占用，在64位Linux系统上，单个进程管理数万个连接是可行的，但实践中建议单机控制在一两万个连接以内，超过这个量级考虑横向扩展。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e6%9c%8d%e5%8a%a1%e5%99%a8%e5%92%8c%e5%a4%9a%e4%b8%aa%e5%ae%a2%e6%88%b7%e7%ab%afsocket%e5%a6%82%e4%bd%95%e9%80%9a%e4%bf%a1%ef%bc%8c%e6%80%8e%e4%b9%88%e5%ae%9e%e7%8e%b0/
