海量设备接入场景下，TCP长连接资源占用的核心矛盾不在“连接数”本身，而在于每个连接背后占据的句柄、内存、CPU中断与内核网络缓冲区的叠加效应。
先认清：一条TCP长连接在服务器上“吃”了什么
许多团队在设备规模突破万级时才开始排查资源占用,但往往只盯着CPU和内存，忽略了更隐蔽的瓶颈，从Linux服务器视角看，一条存活的长连接至少占用四类资源。
文件描述符（fd）:第一个触顶的硬门槛
每条TCP连接都是一个Socket文件,对应一个fd，Linux默认的ulimit -n通常是1024，生产环境就算调到65535，5万设备同时在线就会吃掉绝大部分fd额度，这还没算服务器自身需要的日志文件、管道和监听Socket，行业共识是：fd配额按设备数的1.5倍预留才安全。
内核内存：被“缓冲区”悄悄吃掉的部分
每条连接都有收发缓冲区,默认rmem_max和wmem_max往往达到几MB，若按默认值计算，5万连接的理论缓冲区上限就可能突破200GB，实际运行中不会满额占用，但即使平均只用几百KB，5万连接也意味着几个GB的内核内存，这里还没算struct sock和struct tcp_sock本身，Linux 5.x内核中每个连接的控制结构体合计约2-3KB，统计下来同样过GB。
CPU开销：活跃度比连接数更能决定生死
长连接并非零成本,即使静默，也要处理 TCP Keepalive 探测包；一旦有业务心跳或消息推送，每个包都会触发一次中断和软中断，业内专家指出，CPU的瓶颈往往先于内存出现，尤其是在大量连接同时活跃的场景下，软中断占比会迅速攀升。
端口与四元组：连接数天花板的隐性约束
服务端接受连接不占用自身端口数量,但源端口耗尽是客户端常见问题，一个连接由<源IP,源端口,目标IP,目标端口>唯一确定，当服务器使用单IP承接海量设备，且设备来自少数NAT网关后时，如果服务器主动外连其他服务，端口耗尽会让新连接直接失败。
服务器并发连接数不够怎么办：先查这三个内核参数
当监控显示EMFILE（打开文件数超限）或ENOBUFS（缓冲区不足）报错，别急着加机器，先按顺序检查三处配置。
第一步：调高用户级fd限制
ulimit -n 1000000 # 永久生效需写入 /etc/security/limits.conf
同时检查sysctl fs.file-max，这个系统级上限通常远高于个人限制，但也要一并确认。
第二步：调整TCP内核参数
# 降低TIME_WAIT对端口的影响，同时开启复用 sysctl -w net.ipv4.tcp_tw_reuse=1 sysctl -w net.ipv4.tcp_fin_timeout=15 sysctl -w net.ipv4.tcp_timestamps=1 # 调整接收/发送缓冲区，按业务包大小收敛 sysctl -w net.ipv4.tcp_rmem='4096 8192 16777216' sysctl -w net.ipv4.tcp_wmem='4096 8192 16777216'
把net.core.rmem_max降低到实际包体大小会牺牲瞬时吞吐，但能大幅压低每条连接的闲置内存，实践中需要压测找到平衡点。
第三步：确认epoll模型而非select/poll
高并发IO必须使用epoll，且epoll_wait的超时时间不宜过大，若使用ET边缘触发模式，需注意业务层是否完整读完缓冲，否则会饿死后续事件这是实践中比内核参数更常见的问题。
TCP长连接和短连接怎么选：其实只有三条判断标准
“长连接省握手开销，短连接省资源”是最常见的认知误区，选型判断依据只有三条。
按报文频率选
- 设备每5秒以上才上报一次数据，且每次数据量小于几KB：短连接足够，每次握手开销约1个RTT，在公网延迟50ms下也就多耗50ms，多数场景无感。
- 设备每秒多次指令交互，比如实时控制、状态同步：必须长连接，否则握手开销会占掉有效负载的一半。
按连接复用度选
长连接的资源代价是“连接数×单连接成本”，短连接的资源代价是“每秒新建连接数×握手开销”，当单机每秒新建超过2000个连接时，即便每个连接只存活几秒，SYN队列和TIME_WAIT状态也会成为新瓶颈，此时长连接反而更省CPU。
按网关与NAT穿透约束选
NAT超时时间短的场景（如部分运营商仅存活30-60秒），长连接若没有心跳保活，会被网关悄然回收，比短连接更不可靠，这种情况下，建议采用“低频长连接+协议层重连”策略，而不是退回短连接。
TCP长连接最多支持多少设备：从理论值到可验证的压测方法
这是一个没有标准答案但可以自测的问题,网上流传的“单机百万连接”在特定环境中可行，但业务真实场景中
5万到10万设备已经是分水岭，以下是可落地的测算路径。
第一步：预算单连接内存成本
ss -m -tn state established | head -20
输出中的skmem字段会直接显示收发缓冲区实际占用，统计1000条连接取平均，乘以目标设备数，得到内存预算，注意观察/proc/net/sockstat中的TCP内存总量。
第二步：压测工具选型与操作路径
禁止用Jmeter直接压TCP长连接,推荐使用tcploop或golang封装的自定义压测工具，操作路径如下：
- 准备两台同机房机器,一台充当网关，模拟设备侧发起连接，并维持心跳。
- 服务端使用
perf stat -e task-clock,context-switches,cs观察每秒上下文切换量。 - 以每2秒500连接的速度递增,观察
ss -s中total和estab指标。 - 当
si（软中断）CPU占比超过30%，或上下文切换超过每秒5万次，即为本机实际承载上限。
第三步：留意三个“虚假繁荣”陷阱
- 连接建立成功≠业务可用，大量连接只建立不发数据，压测价值为零。
- 短报文高频率最伤CPU，同样的连接数，每秒一条心跳和每秒十条指令，CPU开销差了一个数量级。
- 单机网卡队列数限制软中断分布，如果
/proc/interrupts显示所有收发中断集中在CPU0，需要通过setsockopt或网卡多队列特性做RSS分流。
物联网设备TCP长连接服务器资源占用的降本增效路径
当设备量增长到必须优化资源时,方向远比堆机器重要，以下三条路径按性价比从高到低排列。
第一优先：心跳合并与推送分离
将设备心跳从“每N秒上报一次”改为“按需上报+服务端下行探测”，一次下行探测的TCP开销远小于设备频繁上行带来的CPU中断。把80%的活跃连接切换为低频静默状态，CPU占用能直接下降一个量级。
第二优先：前置网关接入层
在海量设备和业务服务器之间加一层无状态网关（如基于DPDK或内核旁路技术），由网关承接连接保活和协议解析，业务服务器只处理有效消息，这一层至少可以承担10倍于单机业务处理的连接规模，对比方案时，
本地自建裸金属网关和云厂商的接入网关服务，其每连接成本差距可达到数十倍。
第三优先：协议层瘦身
将JSON替换为二进制协议（如Protobuf或自定义TLV），不仅缩小每个包的字节数，还减少解析所需的CPU指令数，对于每活跃时长连接每秒占用CPU 0.05%的服务而言，协议瘦身后这个数字可以降到0.01%以下。
常见问题排查速查表
| 现象 | 首要排查点 | 应急操作 |
|---|---|---|
| 新连接拒绝建立 | fd耗尽或tcp_max_syn_backlog溢出 |
ss -lnt 查LISTEN队列，调大backlog |
| 内存增长但连接数稳定 | 收发缓冲区不断膨胀 | 缩小tcp_rmem/wmem上限 |
| CPU软中断飙高 | 网卡队列不均或Keepalive间隔过短 | 调大tcp_keepalive_time至1800秒 |
常见问题解答
海量设备用TCP长连接还是MQTT协议更好？
MQTT基于TCP实现,但增加了QoS和主题路由，适合弱网设备，如果只是纯粹的数据上报，裸TCP长连接减少一层协议解析，CPU占用更低，需要级联订阅和消息推送时，MQTT的运维便利性会覆盖掉这点性能差异。
单台云服务器能撑住1万台设备的长连接吗？
大多数情况下可以,但需要提前调大fd限制和降低缓冲区默认值，一台2核4G的云主机，在纯心跳场景下能稳定支撑1万连接，但若每台设备每秒上报一条100字节的报文，连接数上限应下调至5000以下。若使用默认内核参数配置运行，通常在3000连接时就开始出现丢包。
TCP长连接的心跳间隔设为多少秒最优？
取决于设备所在网络的NAT超时时间和服务器Keepalive配置,行业实践中以90秒为一个保守基准值，若运营商NAT映射超过180秒无流量就回收，则心跳需快于这个阈值，考虑到每5分钟才上报一次数据的设备，心跳间隔设为120-180秒比90秒更节省CPU和电量，最简单的验证方法是抓包查看服务器Keepalive探测频率与设备响应间的关系，以丢线率低于0.1%为可接受边界，找到该网络环境下最长的安全心跳间隔。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/730279.html
