C++套接字编程实战：从TCP粘包到epoll高并发

前阵子同事问我：现在到处都是现成的网络框架，为什么还有人一头扎进C++套接字编程？我第一反应想说“因为快”，但真要把理由讲清楚，远不是两个字能打发的。从自研网关、回测行情程序到设备间点对点传输，只要你对时延、对资源占用、对数据格式有近乎固执的控制欲，最终都会绕回到伯克利套接字这套API上。这篇东西不是教科书搬运，而是我这些年写C++网络服务时沉淀下来的选型、设计、排错经验，适合想自己掌控连接、又不想被框架黑盒折磨的开发者。内容以真实的TCP服务端与客户端为重点，聊到粘包、生命周期、epool这类高频问题，顺手把排查思路也一并交代清楚。

1. 为什么现在还要拿C++写socket：选型背后的博弈

1.1 性能诉求与标准库的差距

很多语言写网络通信已经很方便，起个服务、发个请求都是一两行的事。但一到高并发、低时延、小包密集的场景，差距立刻拉开。C++能让你直接面对系统调用，自己决定缓冲区大小、是否合并发送、线程怎么调度、内存什么时候释放。这些都是可以量化的收益，不是玄学。

特别要提一点：C++标准库至今没有官方的网络库。虽然社区里不断有提案，但std::net迟迟没有进入标准，所以你看到的“C++套接字编程”基本都是直接基于系统API封装出来的。这听起来像缺点，实际上是一种自由。没有框架替你决定线程模型，没有抽象层给你的数据多拷贝一次，你需要做的只是把socket fd管理好。像Linux上的accept4、recvmmsg这类系统调用，裸socket反而最容易吃到全部特性。

我之前做过一个模拟行情网关，单机需要消化每秒几十万个小消息。用带GC的语言跑了一会儿，停顿一多，客户端立刻反馈时延毛刺。换回C++，把收发缓冲改成自管理的环形队列，同样环境下p99时延能稳定在几十微秒。这种差异不是语言宗教，是实打实的资源控制边界。

1.2 C++在“框架包围圈”里的生态位置

既然有Boost.Asio、libuv、Poco这些成熟库，为什么还要亲自写socket？我的观点是：要看你想控制到哪里。如果只是搭一个内部RPC，用框架一点问题没有。但你的核心链路一旦出现诡异现象，框架层反而成了黑盒，你不知道它在哪一次收包后调了回调，也不知道那个线程池为什么被占满。

另外，依赖控制也很现实。嵌入式设备、金融内网、国产化环境里，不是到处都能引入一堆第三方库。有些场合甚至要求只能基于系统原始头文件开发，这时候直接写socket，反而最稳妥。哪怕只是做中间层，你也要能读懂socket层面的收发包逻辑，不然框架出了问题你根本无从下手。

我自己有一个习惯：凡是超过两周寿命的网络模块，不管外面套了多少框架，底层一定要有一层自己维护的socket封装。这不是重复造轮子，是为了在出问题时可以顺着数据流从应用层一路看到内核套接字排队情况。

2. 动手前必须想清楚的三件事：协议、生命周期与错误边界

2.1 协议定长与粘包问题：先定框架再写代码

很多人一开始写C++套接字，最容易踩的就是粘包。稍微想一下TCP传输的本质就明白了：TCP是字节流，不是消息流。内核不管你的应用层消息边界，它只知道把缓冲里的字节按序送出去。所以你send两次，对端recv一次可能把两段都收到；也可能你send一次，对端分三次才收完。

因此写代码前第一件事，是先把应用层协议定下来。常用方案无非三种：定长报文、长度前缀、分隔符。我在多数项目里都用长度前缀：报文头固定放4字节网络字节序长度，后面跟消息体。长度字段本身就是边界，解析时先读够4字节，算出body长度再继续读指定字节数，就可以完整还原消息。这里有个细节——一定要用htonl转成网络字节序，否则不同大小端设备之间通信直接乱套。定长报文在固定业务场景下最简单，但如果字段以后要扩展，定长就是给自己挖坑。

下面给一个简单的拆包思路：

// 假设头部固定2字节长度，表示后续有效载荷长度 uint8_t header[2]; if (!ReadFully(fd, header, 2)) return false; uint16_t payload_len = (header[0] << 8) | header[1]; std::vector<uint8_t> payload(payload_len); if (!ReadFully(fd, payload.data(), payload_len)) return false;

ReadFully要循环读，直到读满指定字节数，因为一次read不一定把数据读完。读不满就继续，读返回0说明对端关闭，返回-1且errno为EINTR要重试，为EAGAIN说明非阻塞下暂时没数据。这套逻辑是所有自定义协议的地基。

2.2 socket对象的生命周期归谁管

C++写socket最容易翻车的地方不是系统调用本身，而是资源生命周期。裸的int fd一旦在代码里传丢，连接就泄漏。多线程环境更恶心：一个线程正在读fd，另一个线程把fd关闭了，下一个新的fd可能复用这个编号，老线程莫名其妙读到别人的数据。

我的办法是坚持RAII。写一个小的连接类，构造时负责accept或connect拿到的fd，析构时无条件close。防止拷贝，所有权用unique_ptr或shared_ptr传递。多线程下如果担心连接被并发操作，就在这个类里面放一个互斥锁，所有收发操作都走统一入口。

一个最小封装大概是这种感觉：

class TcpConnection { public: explicit TcpConnection(int fd) : fd_(fd) {} ~TcpConnection() { if (fd_ >= 0) ::close(fd_); } TcpConnection(const TcpConnection&) = delete; TcpConnection& operator=(const TcpConnection&) = delete; ssize_t Send(const void* data, size_t len) { return ::send(fd_, data, len, 0); } private: int fd_ = -1; };

你可能会觉得这只是个壳，但就是这个壳，能让异常路径下的资源释放变得非常可靠。某个函数中途抛异常，栈上的连接对象析构，fd自然关闭，不会等到进程重启才还回去。

2.3 错误处理方式：返回值、异常与日志

C++套接字编程的错误处理要刻意选择。我见过有些人喜欢把所有错误都抛异常，但系统调用频繁时异常的开销和阅读成本都不划算。更重要的是，很多错误不是“异常情况”，而是常态。比如非阻塞socket的EAGAIN，表示缓冲区暂时没数据，这根本不是错误，只是“现在不该处理”。异步模式下收到EWOULDBLOCK，按业务逻辑继续等事件就好。

比较靠谱的方式是：核心收发接口全部返回ssize_t或bool，失败时记录errno，再用日志把上下文打印清楚。日志至少要包含：fd编号、对端IP和端口、操作类型、errno对应的strerror信息。没有这些信息，事后定位一个偶发断连会非常痛苦。

有几个errno一定要刻在脑子里：

• EINTR：系统调用被信号打断，通常是收包时来了信号，不要当错误处理，重启调用即可。
• EAGAIN/EWOULDBLOCK：非阻塞模式下暂时无数据，不是失败。
• ECONNRESET：对端没正常关闭，直接发了个RST包，常见于对端进程崩溃或你往已关闭的连接写数据。
• EPIPE：对端关闭后你还在写，并且没有收到RST，write会触发SIGPIPE。进程默认会被这个信号杀掉，所以要么忽略SIGPIPE，要么用send(..., MSG_NOSIGNAL)。

我自己的服务里都会统一处理错误码，再映射成内部状态。比如ECONNRESET直接标记连接死亡，EAGAIN则继续等待事件。这样业务层不需要关心内核细节，只要根据状态机推进就可以。

3. 一段能跑起来的TCP长连接服务：代码逐行拆解

3.1 服务端骨架：socket、bind、listen、accept的调用顺序

下面这段是服务端的核心骨架，我用C++17风格写，省略了日志封装和异常处理外壳，但每步的意图都在注释里。

int listen_fd = ::socket(AF_INET, SOCK_STREAM, 0); if (listen_fd < 0) { /* 处理错误 */ } int opt = 1; ::setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); sockaddr_in addr; std::memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_addr.s_addr = htonl(INADDR_ANY); addr.sin_port = htons(9527); if (::bind(listen_fd, (sockaddr*)&addr, sizeof(addr)) < 0) { /* 处理错误 */ } if (::listen(listen_fd, 128) < 0) { /* 处理错误 */ } while (running) { sockaddr_in peer; socklen_t peer_len = sizeof(peer); int conn_fd = ::accept(listen_fd, (sockaddr*)&peer, &peer_len); if (conn_fd < 0) continue; // 把 conn_fd 交给连接对象去管理 }

SO_REUSEADDR这行几乎是必须的。如果不设置，服务重启时如果上一个进程还有连接处于TIME_WAIT状态，bind会失败。很多新手第一次部署服务，改完代码重启发现端口起不来，就是少了这个选项。listen第二个参数是已完成握手的队列长度，不用填太大，现在很多内核都会做动态调整，但完全没有队列也不行。

accept返回的是一个新的fd，这个fd才代表与客户端的连接。监听fd只负责接受连接，不参与数据收发。处理新连接时，我习惯立刻把conn_fd设置成非阻塞，放入事件循环，而不是直接用阻塞模式起一个线程。原因是连接很可能长时间空闲，每连接一条线程会浪费无谓资源。

3.2 客户端视角：connect的阻塞与慢启动观察

客户端的套路相对简单：socket拿到fd，connect到服务端地址。但connect在阻塞模式下会一直卡到握手完成或超时，如果对端IP是黑洞，可能几十秒才返回。所以需要给连接过程设置超时，尤其是做批量任务时，不能让一个不可达地址把整个调度拖死。

一个常用的技巧是先设置非阻塞，再发起connect，然后调用poll或epoll等待这个fd变得可写。fd可写之后，再用getsockopt(SO_ERROR)确认是否真的连接成功。

int fd = ::socket(AF_INET, SOCK_STREAM, 0); int flags = ::fcntl(fd, F_GETFL, 0); ::fcntl(fd, F_SETFL, flags | O_NONBLOCK); int ret = ::connect(fd, (sockaddr*)&addr, sizeof(addr)); if (ret != 0 && errno != EINPROGRESS) { /* 连接失败 */ } pollfd pfd{fd, POLLOUT, 0}; int pr = ::poll(&pfd, 1, 3000); // 3秒超时 if (pr == 0) { /* 超时 */ } if (pr < 0) { /* 错误 */ } int err = 0; socklen_t err_len = sizeof(err); ::getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &err_len); if (err != 0) { /* 连接失败 */ }

EINPROGRESS表示内核开始处理三次握手，但还没完成，需要等待通知。这个技巧在爬虫、批量探测、分布式节点互连时特别实用。另一个客户端经常要开的是TCP_NODELAY，关掉Nagle算法。因为Nagle会攒小包，交互式的请求响应被它合并后，时延会无谓升高。对于低频小包通信，这个选项基本都要开。

4. 高并发编不了？从select到epoll的迁移笔记

4.1 多线程模型与IO多路复用怎么选

不少初学者喜欢一连接一线程，逻辑简单直接，但连接一多就吃不消。每条线程默认栈空间可能就几兆，一万个连接意味着内存首先扛不住，更不说线程切换的CPU损耗。所以正经高并发服务，要么用IO多路复用单线程或少量线程，要么做线程池+事件驱动混合。

可以用一张表对比常见模型：

我目前主力是最后一种：一个事件线程跑epoll_wait，收到完整消息后丢到工作线程池里处理；响应再丢回事件线程负责发送。这样做的好处是CPU密集的计算不会阻塞事件循环，网络层始终在第一时间把消息收进来。吞吐量能上去，同时又不会出现一个慢客户端把其他连接全部拖死。

4.2 epoll边缘触发vs水平触发：我的血泪教训

epoll有两种事件模型，水平触发（LT）和边缘触发（ET）。LT是默认的，只要缓冲区还有数据，每次epoll_wait都会通知你。ET则是只在状态变化的那一刻通知一次，如果这次没把数据读干净，后面可能等不到通知，数据就“漏”在缓冲区里。

听起来ET性能更好，因为减少重复通知，但代价是应用层必须在一次通知里尽量把数据读完。我犯过的错就是图省事，在ET模式下只读了一次缓冲区就去处理逻辑，结果大量连接出现“读不到完整消息”的诡异问题。后来老老实实改成循环读：

while (true) { char buf[4096]; ssize_t n = ::recv(fd, buf, sizeof(buf), 0); if (n > 0) { AppendToBuffer(buf, n); } else if (n == 0) { // 对端关闭 CloseConnection(); break; } else { if (errno == EAGAIN || errno == EWOULDBLOCK) { break; // 数据已读净，退出循环 } if (errno == EINTR) continue; HandleError(); break; } }

ET模式下accept也要注意，最好把accept也放在循环里一直accpet到返回EAGAIN，否则同一时间多个连接完成握手，只触发了一次事件，剩下的连接就一直留在队列里。另一个容易踩的是多线程下EPOLLONESHOT：同一fd上的事件只触发一次，手动重新注册前不再推送。这样能避免多个线程同时操作一个fd，但记得处理完要重新epoll_ctl，否则连接直接“失声”。

5. 调试与验证：网络编程最容易被忽略的环节

5.1 本地回环测试不等于联调

本地回环127.0.0.1测起来非常顺，快、稳、不丢包，几乎没有任何链路波动。正因为这样，它掩盖了一堆问题。真实网卡有MTU限制、有拥塞、有偶发丢包，甚至不同网段之间还要经过防火墙。很多模块本地压测没问题，一上服务器就出现“偶发超时”“数据错乱”，原因就在这里。

我自己有个习惯：本地负责测逻辑正确性，链路特性一定放到两台机器上验证。没有条件的话，可以用tc命令在Linux上模拟丢包和延迟，比如给回环接口加一点延迟：

tc qdisc add dev lo root netem delay 50ms loss 2%

测完之后记得删掉：

tc qdisc del dev lo root

没有验证条件时，至少要故意把对端进程杀掉，看服务端能不能快速感知连接断开；再拔掉网线，观察超时路径是否和预期一致。这些异常路径在回环测试里根本走不到。

5.2 抓包与故障复现思路

处理网络问题，我最不推荐的做法是闭眼盲改代码。先抓包，让数据自己说话。抓包工具我常用tcpdump，直接抓指定端口：

tcpdump -i eth0 -nn -s0 port 9527 -w capture.pcap

抓到之后用Wireshark打开，重点看三次握手有没有完成，SYN重传了几次，RST是什么时候出现的，数据段有没有触发零窗口。有一次我排查一个卡死问题：客户端连上后发了一个请求，服务端完全不响应。抓包一看，服务端回了一个RST，应用日志里却没有任何报错。继续查才发现，服务进程在启动时根本没有真正监听那个业务端口，bind的IP地址写错，流量到了另一个进程手里。如果没有抓包，靠看代码不知道要翻到什么时候。

简单归纳抓包时常见的时序特征：

• SYN发送后不断重传，说明网络层路由不通或对端丢弃。
• SYN有回应，ACK发不出去，多半是防火墙拦截回包。
• 数据收发中看到RST，排查顺序是对端进程是否崩溃、协议是否非法、端口是否被回收。
• FIN后收不到对方的FIN，连接处于半关闭状态，业务层要考虑心跳来兜底。

6. 网络问题排查清单与我的几个操作习惯

6.1 连接重置、端口未监听与半关闭状态

实际运维里最常遇到几类错误，我列一个排查清单，方便你和同事对表：

很多服务的“假死”其实不是网络断开，而是某个连接一直占着资源，数据却没有流动。这时候我习惯给长连接加心跳，普通业务30秒一跳足够。心跳包不要单独占用线程，挂在事件循环里做定时器即可。

6.2 排查思路与日常习惯

顺手分享几个我一直在用的习惯，简单但有效。

第一，日志里永远记录收发的字节数，不要只打“发送成功”。有一次排查一个乱序问题，对比双方日志发现有一方一个包只发了前半段逻辑，后半段因为接收缓存不够丢在了应用层，这类问题不看字节数根本发现不了。

第二，所有fd都要有名字。在连接对象里保存对端IP、端口、最近活动时间。排查问题时能立刻回答“这个连接是谁、什么时候建立的、最后一次通信是什么时候”。

第三，非阻塞化之后一定要处理EAGAIN，但不要用while(true)死扛。该加超时的地方加超时，不管是epoll_wait超时还是业务定时器。系统调用没有死循环兜底那一说，所有等待最终都要回到事件循环。

第四，重报文别用close，用shutdown(fd, SHUT_WR)先关闭写端，等对端读到EOF后自然关闭读端。shutdown能让你把“我发完了”和“我不读了”分开，有些协议报文需要这个语义，直接从close换成shutdown可能整个交互模式就对了。

回顾这些年写C++套接字编程的经历，最深刻的体会是：网络编程的难点从来不在API，而在你如何设计边界。协议边界定了，粘包就控制住了；生命周期边界定了，内存和fd就控制住了；错误处理边界定了，故障响应速度就控制住了。剩下的事情，无非是在recv和send之间耐心地把状态机一节一节填完整。遇到问题别慌，抓包、看日志、确认内核状态，三步走，大多数疑难杂症都能落地。