做高性能TCP服务器很多人第一反应是“把epoll用好”可真正上线跑起来才发现吞吐上不去、连接一多就抖、偶尔还有莫名超时。我前后做过好几个基于TCP的网关类服务从单机十万连接到跨机房多活都趟过今天这篇就把设计时最容易忽略、也最值得抠的细节打包讲清楚。内容主要围绕Linux平台、C/C或Go这类适合写网络服务的语言不管是刚入门还是已经在调优阶段都能找到可落地的思路。1. 高性能TCP服务器设计先从搞懂“性能”开始高性能这几个字特别容易让人一头扎进代码里但代码只是最后一步。更要命的是很多人对“性能好”的定义本身就是模糊的于是优化方向全跑偏。我见过有人疯狂压榨CPU使用率结果业务请求的P99时延一点没降也有人拼命调内核参数结果连接数上去了内存先爆了。所以动工之前一定要把性能目标拆清楚。1.1 你追求的到底是并发、吞吐还是时延在TCP服务器这个语境下常被挂在嘴边的指标无非三个并发连接数、吞吐量、请求时延。它们彼此关联但优化手段经常互相打架。并发连接数服务器能同时维持多少条TCP连接。它主要受文件描述符上限、内存、内核连接表大小影响和CPU关系不大。C10K问题本质是“用阻塞IO模型时连接多了线程/进程切换不过来”而不是内核扛不住。吞吐量单位时间内成功传输的数据量通常看每秒字节数或每秒请求数。它考验的是数据通路效率比如是否频繁拷贝、是否触发过多系统调用。时延从请求发出到响应返回的时间。它最敏感内核调度抖动、锁竞争、GC暂停甚至网卡中断不均都会让P99时延恶化。这三个指标之间经常要取舍。比如为了提升吞吐把单个TCP连接上堆积大量小请求批量处理吞吐好看但单请求时延上去了为了扛百万连接把每个连接的内存压到极低一旦业务有突发数据要发送又容易触发内存分配抖动。所以第一步不是选框架而是明确这个TCP服务器主要承担什么角色是网关代理、消息推送通道、实时数据采集还是通用RPC底座。角色的不同决定了你把优化重心放在哪。1.2 业务形态决定模型计算密集、IO密集与连接密集我把TCP服务器粗暴分成三种形态设计路数完全不同。连接密集型典型的是物联网设备接入、IM长连接、消息推送。特征是连接数量大、单连接流量低、大部分时间空闲。设计重点是降低每个连接的内存占用、减少线程数量、精细管理空闲超时。IO密集型典型的是文件传输、日志采集、数据同步。特征是数据量大、单次读写长、CPU主要花在数据拷贝和系统调用上。设计重点是减少数据拷贝、合理设置读写缓冲区、用异步IO或直接IO。计算密集型典型的是网关里做加解密、协议转换、实时风控。特征是网络只是入口真正开销在业务计算。设计重点是线程池大小匹配CPU核数避免线程过多导致上下文切换吃掉CPU。很多人拿到需求就开始叠技术栈epoll、线程池、协程、零拷贝全上。但连接密集型场景最怕线程池开得过大计算密集型场景最怕IO线程和计算线程混在一起相互拖累。我习惯先在一张纸上把“连接到达—数据读取—业务处理—响应写出”的完整数据流画出来标出每个环节的预期耗时和资源消耗再决定哪些环节需要独立线程/协程哪些可以串行处理。这比抄别人的架构模板靠谱得多。2. 网络IO模型选型从阻塞IO到多线程Reactor说到TCP服务器的核心模型绕不开Reactor。它不是一个具体框架而是一套思想把“等待事件”和“处理事件”拆开用一个事件循环统一监听所有连接的读写事件事件到了再分发给对应处理器。高性能服务器基本都长这样从nginx到Netty再到Redis的单线程Reactor本质一致。2.1 高并发的起点非阻塞IO IO多路复用要理解Reactor关键在“非阻塞”。如果调用read时没数据就卡住一个线程就只能伺候一个连接并发上不去。改成非阻塞后read会立刻返回“暂无数据”线程就可以继续检查别的连接——但怎么做才能同时知道一堆连接里谁有数据这就需要IO多路复用。Linux下主流是epoll把一批文件描述符注册进内核然后阻塞等待内核告诉你“哪些fd可读、可写、出错”。相比之下select和poll每次调用都要把全部fd从用户态拷到内核态fd多了以后每次调用的O(n)遍历和拷贝开销非常可观。epoll在注册和等待时批量操作、事件就绪时才通知效率高很多。一个最简Reactor事件循环长这样while (1) { int n epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i 0; i n; i) { if (events[i].events EPOLLIN) { handle_read(events[i].data.fd); } if (events[i].events EPOLLOUT) { handle_write(events[i].data.fd); } } }这套循环本身不复杂复杂的全是细节每个fd要用什么数据结构关联业务上下文、读写事件怎么注册和取消、返回EAGAIN之后怎么处理、事件处理耗时太长阻塞了循环怎么办。一个常见误区是epoll_wait的timeout传很短比如1毫秒觉得这样能降低响应延迟。实际上事件就绪时内核会立刻唤醒短超时只会让线程空转白白烧CPU。除非有定时任务要处理否则传-1就行。2.2 epoll的ET和LT怎么选epoll提供两种触发模式很多人在这里纠结很久。水平触发LT是默认模式只要fd上有数据没读完每次epoll_wait都会重复通知边缘触发ET只在状态变化时通知一次比如缓冲从无到有、从有到多之后哪怕还有数据也不再通知。因此ET模式下每次必须把数据读到EAGAIN为止否则会漏数据。我在工程里一般选ET加非阻塞读。原因有两个第一LT模式下一次epoll_wait返回后如果没读完下一轮循环又会立刻通知同一个fd如果同一时刻活跃连接很多这个fd可能一直霸占处理机会其他连接饿肚子。ET只通知一次逼着你在一次事件里尽量读完事件分配更公平。第二ET配合非阻塞IO代码路径更统一读一直读到EAGAIN写一直写到EAGAIN逻辑清晰也更容易避免LT那种“读了部分数据又得在下个循环重新注册”的奇怪状态。代价是ET的代码对处理要求更高。比如监听socket的acceptET模式下必须用循环accept到EAGAIN否则多个连接同时到达时只处理一个是常事。这个后面讲Accept时再细说。2.3 多线程Reactor的线程分工单事件循环处理所有事件确实优雅但有两个硬约束一个CPU核只能跑一个线程事件循环里有任何耗时操作所有连接一起被拖慢。所以单线程Reactor适合Redis那种逻辑极短、内存操作的任务对于业务处理耗时长的TCP服务器必须有线程拆解。常见做法是主从Reactor主Reactor只负责监听新连接accept后把连接fd分发给多个子Reactor子Reactor每个跑一个事件循环负责已建立连接的读写事件。业务处理可以继续下沉到独立线程池避免IO线程被算法或数据库查询卡住。线程分工时最该小心的是“锁竞争”。多个子Reactor共享一个业务线程池时任务队列是所有IO线程一起写入、所有业务线程一起取出的这个队列很容易成为热点。我习惯给每个子Reactor配一个独立的任务队列业务线程池也从“全局竞争”改成“按队列绑定”让IO线程只往自己队列塞任务业务线程只消费固定队列锁粒度小了吞吐能明显提升。这里多说一句千万不要在IO线程里做同步阻塞操作别说是数据库查询、RPC调用就是一次磁盘同步写都可能让整个事件循环堵死。真遇到需要等待外部资源的情况要么异步化要么干脆把它丢到专门的慢操作线程池里。这也是很多自称高性能的服务实际一压测就拉胯的主因——模型本身没错用错了地方。3. 连接生命周期中的隐藏瓶颈握手、Accept与粘包模型定好之后代码写起来其实不难难的是连接从建立到关闭的整个生命周期里藏着很多不需要业务逻辑参与的隐性成本。我经常跟团队说做TCP服务器不只是写业务处理函数更要管好连接本身。3.1 三次握手和连接队列半连接队列与全连接队列TCP三次握手的过程大家都熟客户端发SYN、服务端回SYNACK、客户端再回ACK。但对服务器来说握手需要两个队列配合。第一个是半连接队列存的是已经收到SYN但还没完成握手的连接也叫SYN队列。它的大小与内核参数tcp_max_syn_backlog网卡队列相关主要防御SYN洪水。第二个是全连接队列存的是完成握手、等待应用调用accept取走的连接大小由监听socket的backlog参数决定实际还会受net.core.somaxconn和net.ipv4.tcp_max_syn_backlog限制。容易踩的坑是你把listen(fd, 1024)传了很大的backlog但内核net.core.somaxconn默认只有4096如果业务期望十万级别瞬时突发必须同步调大内核参数。否则当全连接队列满了内核会直接丢弃客户端的ACK或按照tcp_abort_on_overflow的策略处理表现就是客户端明明握手成功却迟迟连不上、偶尔超时、偶尔重置。高并发下我还会关注“握手过程本身能不能偷懒”。如果业务要求低时延、且能容忍某些非关键重试可以打开tcp_defer_accept让内核在接收到真实数据后才唤醒应用accept省掉一次无谓唤醒同时配合TCP_DEFER_ACCEPT的socket选项。但要注意它会让服务端误以为客户端还活着空闲检测要额外处理。3.2 Accept与多进程/多线程的惊群问题当多个线程或进程同时阻塞在accept上新连接来临时它们可能全被唤醒但只有一个能成功这就是惊群。早期Linux上这个问题确实存在后来内核加入EPOLLEXCLUSIVE和SO_REUSEPORT两把武器。SO_REUSEPORT允许多个socket监听同一个端口内核按哈希或四元组把连接分发到不同socket相当于在协议栈层就把负载分担了。我在多核机器上常用它每个核绑一个监听socket各自跑一个Reactor避免跨核锁和中断分发不均。缺点是连接数少时可能分布不均极端情况某个核的队列堆积其他核空闲需要观察实测效果再决定要不要开。如果不用SO_REUSEPORT而是多个线程共享一个监听fd建议用EPOLLEXCLUSIVE修饰事件避免一个连接唤醒全部线程。还有一个细节监听socket最好单独由一个线程或主Reactor处理不要和业务fd混在同一个epoll里否则高峰时accept事件会被大量业务事件挤掉处理时机连接建立延迟会异常偏高。3.3 拆包粘包问题为什么不能直接用recv返回当完整消息TCP是流协议没有消息边界。你发送方调一次send发了100字节接收方recv可能一次拿到20字节、也可能一次拿到200字节包含了下一包。这就是粘包/拆包问题的根源。任何基于TCP的自定义协议都必须自己定义消息边界。常见的解法有三种固定长度每条消息定长收满一个长度就处理一条最简单但浪费带宽。分隔符比如用\r\n或特殊字节结尾适合文本协议但正文里不能出现相同的分隔符。长度前缀消息头先写入总长度通常用4字节或变长编码收齐头再按长度收全消息。这是二进制RPC和许多网关的默认做法。我推荐用长度前缀。实现时要特别小心“半包”状态读到的数据不够一个完整头、或者够头但不够体都必须先把数据暂存到缓冲区等攒够了再解析。很多人图省事把还没凑齐的消息直接丢弃或只处理其中一部分这就会出现诡异的错位而且很难排查。缓冲区也别用std::string反复拼接。高并发下推荐预分配环形缓冲区或分片内存池读取时先用栈上临时数组接收再把有效部分拷入环形区解析时尽量做到“零拷贝”——直接从环形区取指针判断避免每处理一个包就做一次内存分配。这块虽然琐碎但热路径上的性能差距非常显著。4. 内核参数与零拷贝系统层面的性能调优代码逻辑写到一定程度后性能瓶颈会从用户态转移到内核态。TCP服务器调优至少要过一遍网络子系统参数同时掌握几项减少数据拷贝的技术。这块内容看起来像运维的活但开发懂了对架构设计非常有帮助。4.1 关键sysctl参数调整我一般在部署前设置这样一组参数具体值按机器内存和业务调整# 文件描述符和连接表 fs.file-max 2000000 net.core.somaxconn 65535 net.ipv4.tcp_max_syn_backlog 65535 # 端口和连接复用 net.ipv4.ip_local_port_range 1024 65535 net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_fin_timeout 15 # 增大缓冲区 net.core.rmem_max 16777216 net.core.wmem_max 16777216 net.ipv4.tcp_rmem 4096 87380 16777216 net.ipv4.tcp_wmem 4096 16384 16777216somaxconn直接决定应用listen的队列上限前面说过。tcp_tw_reuse让客户端主动断开时四元组能更快复用TIME_WAIT状态的端口对高并发短连接至关重要。但它只对“发起连接的一端”生效服务端TIME_WAIT通常还是要靠协议设计和连接复用去消化。tcp_fin_timeout调短能加速释放不再用的连接但不能调太低否则被动关闭方的数据可能还没传输完就被销毁。缓冲区调大有利于大流量传输但注意每连接占用内存也会变大百万连接场景下要算清楚内存账避免缓冲区变成内存炸弹。还有一个经常被忽视的点是网卡多队列。现代网卡支持RSSReceive Side Scaling但默认可能只开一个队列导致所有中断集中到一个CPU核。检查/proc/interrupts如果某个核的中断数特别高需要开启网卡多队列并把不同队列绑定到不同CPU否则CPU瓶颈会先于网络瓶颈出现。4.2 减少数据拷贝sendfile/splice与写缓冲区的使用传统send流程大概是用户态数据 → 内核socket发送缓冲区 → 网卡。涉及几次拷贝。如果业务是转发文件或大块数据用sendfile可以让数据直接从文件描述符进内核缓冲区跳过用户态拷贝。做TCP代理转发时splice可以把两个fd在内核里对接同样减少拷贝。不过这些优化有前提数据必须是整块转发、不需要在用户态做协议加工。如果每个包都要改头部、加签名就没有零拷贝的必要老老实实拼好再发。处理大量小包时另一个重点是“批量写”。每个小包单独调用一次write意味着每个包都有一轮系统调用和可能的锁开销。我习惯在Reactor写出逻辑里攒数据先写进用户态发送缓冲区在一个可写事件里尽量一次writev把多个包一起交给内核。这样既能减少系统调用次数也能降低小包导致的TCP分片开销。4.3 压测工具与验证方法不压测的调优都是瞎猜。我常用的工具是wrk和h2load但TCP长连接自定义协议场景下这些通用工具经常不适用我会直接用ab或者用Go写一个简单的压测客户端保持N条长连接按业务协议灌包。压测时要注意几个点客户端机器和服务端机器要分开最好用万兆网卡否则瓶颈可能在客户端。关注指标不能只看平均值至少要看P99、P99.9时延。TCP服务器偶发的长尾对用户体验影响很大平均值好看不代表系统稳定。压测时要同时看服务端CPU、软中断、内存、连接队列drop情况。如果cat /proc/net/netstat里ListenOverflows持续增长说明全连接队列在丢包先查内核参数而不是代码。我遇到过最典型的案例代码用epoll完全没问题压测吞吐上不去最后发现是压测客户端所在的机器端口不够用TIME_WAIT状态把本地端口耗尽了。换到高并发端口复用后服务端性能翻倍。这种问题如果不看全局很容易误判成服务端代码差。5. 从能跑到稳定工程化设计的几个关键点性能做到位只是起点线上稳定运行才是真正拉开差距的地方。一个TCP服务器如果连优雅退出都做不好会在发版时丢连接如果限流做不好一个突发流量就能把集群打崩。我把这些不太起眼但极其重要的设计集中说一下。5.1 优雅退出与连接排空服务发版时要重启进程如果直接kill -9所有连接瞬间断开客户端会收到ECONNRESET对实时业务影响非常大。好的做法是先停止接受新连接。如果用SO_REUSEPORT多实例先把这个实例从负载均衡摘掉单实例场景先关闭监听fd或不再accept。给现有连接一段排空时间让正在处理的请求自然完成新到的请求则返回一个明确的“服务正在重启”或者直接关闭。超过排空时间还未结束的连接再强制关闭。排空时间的设置需要取舍太短会导致部分请求失败太长会让升级过程又慢又拖。我通常设置30到60秒并在服务状态里暴露“排空中、剩余连接数”指标发布系统等指标归零后再完成进程退出。5.2 连接超时、心跳与空闲连接回收TCP本身是一个“不活跃就沉默”的协议。客户端拔网线、断电、宕机服务端可能要很久才能发现连接已经死了。因此应用层必须有自己的生死机制。最简单的方案是心跳客户端每隔一段时间发一个ping服务端超过N秒没收到任何包就判定超时。但心跳包本身也是带宽和CPU开销连接密集场景下上万条连接每秒都在发心跳也是不小的压力。我常用“阶梯式超时”最近一次收到数据的时间记为last_active周期扫描时只要当前时间减last_active超过阈值就关闭。阈值不一定全局统一可以根据连接状态调整。比如刚建连的连接给更严格的握手超时已经正常通信很久的连接放宽一些。扫描动作不一定要用独立线程频繁全表扫可以借助epoll自带的超时机制叠加一个小根堆按最小超时时间唤醒减少无效轮询。同时记得设置TCP keepalive作为兜底虽然默认两小时太长了但把它调成“应用心跳失效后的最后一道防线”是合理的。5.3 限流、过载保护与可观测性高并发TCP服务器最怕的不是性能不够而是“性能不够时系统进入恶性循环”。比如业务线程池满了任务队列无限堆积内存增长GC/分配变慢吞吐更低任务积压更严重。所以一定要有过载保护。常见的保护手段有几种连接数上限超过上限时直接拒绝新连接返回明确的错误码或直接关闭。这防止缓慢的连接耗尽导致全部服务不可用。消息速率限流对单连接或单用户的请求速率做限制比如令牌桶。网关场景下防止某个异常客户端把整个带宽吃光。任务队列水位线线程池队列超过阈值时对新请求直接返回“繁忙”而不是继续接纳。避免堆积和雪崩。可观测性这块我建议每个TCP服务器至少要暴露以下指标当前连接数、每秒新建连接数、每秒关闭连接数、消息吞吐、IO线程队列深度、业务线程池活跃度、P99/P99.9处理时延、全连接队列溢出计数。有了这些线上出问题时你才有据可查而不是靠猜。另外我在实际项目里越来越倾向于把“连接管理”和“业务逻辑”彻底分层。底层网络库只负责收包、解包、分发业务层只面对完整消息。这样无论是做压测、做协议升级、还是后期接入服务网格都更顺手。TCP高性能听起来很高深但本质上就是“把每一层的浪费降到最低并且在最坏情况下系统仍然可控”——这比单纯追求某个压测数字重要得多。最后再分享一个细节线上长期运行后哪怕没有业务故障也要偶尔观察一下服务的内存碎片情况和fd泄漏趋势。很多TCP服务器是在运行几周后突然崩溃的原因不是高峰压垮而是缓慢泄漏。给每个连接加上退出日志在测试环境做连接反复建立/关闭的压力跑上一整夜能排查出绝大多数这类问题。