1. 网络编程第一步TCP 到底帮你做了什么1.1 我刚开始写 TCP 代码时最困惑的事我刚接触网络编程的时候最大的困惑不是TCP 是什么而是TCP 帮我做了那么多事情我怎么完全没感觉到。第一次用 C 写 socket 程序服务端 bind 之后 listen然后 accept 就卡住了。客户端 connect 一下两边就通了。然后我往里面发了一行字符串服务端 recv 收到了。整个过程很顺顺到我甚至怀疑自己是不是根本没用上 TCP——我明明没有写任何握手的代码啊为什么连接就建立起来了后来才明白三次握手、滑动窗口、超时重传、流量控制这些东西全都被操作系统里的 TCP 协议栈自动处理了。你用 socket API 写网络程序本质上是在跟操作系统提供的网络接口打交道而不是真的在手工摆弄每一个报文。这个理解相当关键因为很多人一听到TCP 网络编程就觉得一定要把协议栈里面每一个字段都背下来才能动手其实不是这样的。1.2 你真正需要关心的只有四件事如果把 TCP 编程这一整块浓缩成几句话我觉得核心就四件事建立连接客户端发起 connect服务端 accept 接进来。发送数据往 socket 里 write/send。接收数据从 socket 里 read/recv。断开连接一方 close双方进入挥手流程。这四件事背后的细节可以无限深挖但作为初识网络编程的第一站先把它们跑通就足够了。我后来带人的时候也一直是这个思路先写一个能跑的 demo让连接建立、数据收发、断开这几个动作肉眼可见再去补协议细节。否则你在没有感性认识的情况下去啃 RFC 文档很容易越看越懵。当然TCP 编程的难点从来不在跑通而在于稳定。单连接收发数据很简单十并发也还行但一到高并发、弱网环境、半包粘包、连接假死、TIME_WAIT 堆积这些问题才是真正检验功力的地方。这篇我来把从跑通到稳定这条路径上最容易踩的坑和对应的处理思路一步一步讲清楚。简单来说你要学会的其实是两套东西一套是 socket API 的用法另一套是基于字节流设计应用层协议的方法。前者帮你把连接建起来后者帮你在连接之上正确地传业务数据。2. TCP 和 UDP 的选择写代码之前必须先想清楚2.1 TCP 与 UDP 的核心差异很多人写网络程序时并没有认真想过到底该用 TCP 还是 UDP。我之前遇到过一个做实时数据采集的朋友需求是每秒钟上报几百条传感器数据丢一两条影响不大但他坚持用 TCP结果高峰期经常因为网络抖动出现重传积压数据反而更不及时了。反过来我也见过有人把所有业务都堆在 UDP 上结果日志查询时发现数据缺了一大片定位了半天才发现是报文丢了。TCP 和 UDP 的差异先用一句话概括TCP 是面向连接的可靠字节流协议UDP 是无连接的不可靠数据报协议。这里的不可靠不是贬义词而是它的设计特性——UDP 不保证到达、不保证顺序、不重传但换来的是低延迟和极小的协议开销。对比维度TCPUDP连接状态需要三次握手建立连接无连接直接发可靠性可靠传输有确认和重传尽力而为可能丢包消息边界字节流无边界数据报有边界顺序保障保证接收顺序不保证顺序协议开销头部较大有 ACK 反馈头部小开销低典型场景文件传输、HTTP、数据库直播、游戏、DNS2.2 字节流和数据报对代码的影响最直接表格里最值得你留意的是字节流和数据报这一行。因为这是最直接影响代码写法的差异。TCP 是字节流意味着你调一次 send() 发送 100 个字节对端可能一次 recv() 全部收到也可能分两次、三次才收完。反过来你连续两次 send() 的数据对端可能在同一次 recv() 里就都读到了。TCP 不管你的消息边界在哪它只保证字节的先后顺序。所以程序员必须自己设计消息边界——这就是后面要讲的粘包问题。UDP 就不一样它有天然的消息边界。你一次 sendto() 发了什么对端一次 recvfrom() 收到的就是一个完整报文只要缓冲区够大。如果你做的是一个发一条、收一条的简单协议UDP 反而省事。但没有可靠保障业务上就得自己接受丢了就丢了这个现实。我的选型经验是如果业务对数据完整性要求极高——比如文件传输、远程命令、数据库复制——就用 TCP哪怕你需要在应用层处理粘包这个代价是值得的。如果业务能容忍偶发丢包但延迟必须低——比如语音通话、游戏动作同步——就用 UDP。至于初学者除非你有非常明确的 UDP 场景否则一律先用 TCP。先把可靠性问题交给协议栈你才有精力去理解其他机制。3. 三次握手和四次挥手面试常考但代码里也看得见3.1 握手为什么必须是三次三次握手这个知识点基本上是所有网络编程学习者都绕不过去的。我理解它的方式比较实用主义我把它看成客户端和服务端互相确认双方收发能力的过程。第一次客户端发 SYN告诉服务端我想建立连接我的初始序列号是 X。 第二次服务端回 SYNACK意思是收到你的请求我的初始序列号是 Y并且确认收到了你的 X。 第三次客户端再回一个 ACK意思是我确认收到了你的 Y。为什么是三次而不是两次因为只有双方都确认了我的发送你能收到你的发送我也能收到连接才算建立。如果是两次握手服务端收到 SYN 就认为连接已建立万一客户端那边实际没有收到服务端的 SYNACK服务端就会白等资源也浪费了。三次握手让双方都拿到一个明确的事实对方确实活着并且确实收到了我的序列号。在代码层面这个过程对程序员几乎是透明的。你写 connect()内核自动帮你完成三次握手服务端的 listen() 背后有个半连接队列和全连接队列握手完成的连接会排到全连接队列里accept() 只是从队列里取一个已就绪的连接。搞清楚这个对应关系你后面调试并发连接问题时能省不少力气。3.2 挥手为什么比握手多一次四次挥手的过程也很常见主动关闭方发 FIN对端回 ACK对端再发 FIN主动方再回 ACK。为什么比握手多一次因为 TCP 连接是全双工的——每个方向都可以独立关闭。主动方说我不再发数据了所以发 FIN但对端可能还有数据要发所以它先回一个 ACK 表示我确认你要关了等自己的数据发完了再发自己的 FIN。这就把一次挥手拆成了两个阶段你把你的门关了我把我的东西搬完也关门。这个知识在实际编程里有一个直接体现如果你在服务端 close() 的时机不对可能会导致半关闭状态。比如客户端已经关了服务端还在 recv这时候 recv 会返回 0再往后 send 就可能触发 SIGPIPE 信号导致进程退出。我在写网络程序时养成了一个习惯服务端 recv 返回 0 就说明对端已关闭这时应该主动 close而不是继续等数据。3.3 从代码看连接生命周期把握手和挥手的知识映射到 socket API 上连接的生命周期大概是这样的socket() 创建一个管道入口。bind() 给管道绑定一个本地地址和端口。listen() 把 socket 变成被动监听状态。accept() 从已完成握手的队列里取出一个连接。connect() 在客户端主动发起握手。send/recv 在连接建立后双向传数据。close() 触发挥手释放资源。很多初学者容易混淆 bind 和 listen。我打个比方bind 相当于在服务器大楼门口挂了个门牌号listen 相当于把门打开开始等顾客accept 相当于正式接待一个客人。没有 bind别人不知道去哪找你没有 listen你挂了门牌也不接待。这些 API 的调用顺序是固定的一旦颠倒要么报错要么行为不符合预期。4. 用 C 语言写一个 TCP 通信 Demo从零到能跑4.1 服务端骨架socket → bind → listen → accept讲完理论真正上手写一个可以跑起来的 TCP demo。我用 C 语言写因为 C 的 socket API 最接近内核你在其他语言里看到的封装底层都是这一套。先看服务端。这段代码做的事情是监听本机 8080 端口收到一个连接后读取客户端发来的数据原样回传然后关闭这个连接。#include stdio.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h int main() { int lfd socket(AF_INET, SOCK_STREAM, 0); if (lfd 0) { perror(socket); return 1; } struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_port htons(8080); addr.sin_addr.s_addr htonl(INADDR_ANY); if (bind(lfd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); return 1; } if (listen(lfd, 10) 0) { perror(listen); return 1; } printf(server listening on 8080...\n); while (1) { struct sockaddr_in client_addr; socklen_t addr_len sizeof(client_addr); int cfd accept(lfd, (struct sockaddr *)client_addr, addr_len); if (cfd 0) { perror(accept); continue; } printf(client connected: %s:%d\n, inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port)); char buf[1024]; int n recv(cfd, buf, sizeof(buf) - 1, 0); if (n 0) { buf[n] \0; printf(recv: %s\n, buf); send(cfd, buf, n, 0); } close(cfd); } close(lfd); return 0; }这里有几个细节值得说一下。SOCK_STREAM 表示面向流的 TCPAF_INET 表示 IPv4。htons 和 htonl 是把主机字节序转成网络字节序这是初学者最容易忽略的地方——端口号和 IP 地址在网络传输时必须是大端序。INADDR_ANY 表示监听所有网卡的地址这样客户端既可以用 127.0.0.1 连本机也可以用局域网 IP 连这台机器。4.2 客户端骨架socket → connect → send → recv客户端更简单创建 socket 后直接 connect然后发一条消息等回显。#include stdio.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h int main() { int fd socket(AF_INET, SOCK_STREAM, 0); if (fd 0) { perror(socket); return 1; } struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_port htons(8080); inet_pton(AF_INET, 127.0.0.1, addr.sin_addr); if (connect(fd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(connect); return 1; } printf(connected to server\n); const char *msg hello tcp; send(fd, msg, strlen(msg), 0); char buf[1024]; int n recv(fd, buf, sizeof(buf) - 1, 0); if (n 0) { buf[n] \0; printf(echo: %s\n, buf); } close(fd); return 0; }编译运行的时候注意用 gcc 编译后先启动服务端再启动客户端两边都会打印对应的日志。我建议你把两段代码分别编译开两个终端窗口跑亲眼看一下这个交互过程。没有这一步后面所有的调试经验你都没法真正体会。4.3 跑通之后记得验证这几个点demo 能跑起来只是万里长征第一步。我建议你接下来按这几个方向做点小实验因为这些都是实际开发中一定会遇到的问题把服务端 mess 改成每次只 recv 一个字节看看客户端发一条长消息时会收到什么。客户端连续 send 十次服务端一次 recv 看能读到多少。先关服务端再关客户端看看 connect 或 recv 会报什么错。这些实验会把你对TCP 是字节流的感性认识彻底建立起来。尤其是第二个实验做完你就理解什么是粘包了。5. 粘包和拆包TCP 编程第一道实战难关5.1 粘包为什么会出现很多刚写完 demo 的人第一次写正式项目时都会遇到一个诡异现象客户端明明发了三条业务消息服务端一次 recv 居然全部读出来了或者只读出了半条。这就是粘包和拆包。粘包不是 TCP 协议本身的问题而是因为 TCP 是字节流没有消息边界。发送端可能因为 Nagle 算法把多个小包合并发送接收端也可能因为调度原因把多条数据合并到一次 recv。拆包更常见你发了一条 10KB 的消息但接收缓冲区只有 4KBrecv 只返回了前 4KB剩下 6KB 还留在内核里。我见过不少新手在这里卡了好几天他们总以为是数据丢了。其实数据没丢只是被拆开了或者合并了。TCP 保证的是字节顺序和完整性不保证每次 recv 恰好对应一次 send。理解这一点你就明白为什么所有基于 TCP 的应用层协议都必须自己解决消息边界问题。5.2 最常用的封包方案长度字段 载荷解决粘包拆包的标准做法有两种一是固定长度比如每条消息都是 100 字节不够就填充对端每次都精确读 100 字节二是长度字段在消息头部加 4 字节uint32表示后续载荷的长度对端先读长度再按长度读取载荷。固定长度方案实现简单但浪费带宽适合消息本身大小很稳定的场景。长度字段方案更通用几乎所有主流应用层协议都采用类似设计包括 HTTP 的 Content-Length。长度字段的封包格式一般长这样第 0~3 字节载荷长度网络字节序即大端第 4~N 字节业务数据发送端逻辑很简单先发送 4 字节长度再发送数据。但要注意发送端也不一定一次 send 就能发完整个数据包特别是在大包场景下你需要循环发送直到全部写入。接收端则需要一个循环读取的过程先攒够 4 字节头部解析出载荷长度再循环读取直到收够载荷。读完后重新进入读头部状态循环往复。5.3 封包和解包的参考实现我给出一个非常朴素但能用的参考实现。发送端uint32_t len htonl((uint32_t)payload_len); send_all(fd, len, 4); send_all(fd, payload, payload_len);其中 send_all 要做循环发送因为 send 返回的是本次实际写入的字节数可能小于你要发的长度int send_all(int fd, const void *buf, size_t len) { size_t sent 0; while (sent len) { ssize_t n send(fd, (const char *)buf sent, len - sent, 0); if (n 0) return -1; sent n; } return (int)sent; }接收端更复杂因为要处理头部不完整头部完整但载荷只到一半这几种情况。最简单的方式是维护一个接收缓冲区每次 recv 后追加进去然后循环检查缓冲区里有没有至少 4 字节如果有解析出载荷长度再检查缓冲区里载荷是否已经攒够。攒够就取走继续处理下一条消息。typedef struct { uint8_t buf[65536]; size_t len; } recv_buffer; int handle_stream_recv(recv_buffer *rb, int fd) { ssize_t n recv(fd, rb-buf rb-len, sizeof(rb-buf) - rb-len, 0); if (n 0) return 0; rb-len n; // 循环拆包 while (rb-len 4) { uint32_t msg_len ntohl(*(uint32_t *)rb-buf); if (msg_len sizeof(rb-buf) - 4) { printf(message too large\n); return -1; } if (rb-len 4 msg_len) break; // 载荷还没到齐 // 处理一条完整消息 handle_message(rb-buf 4, msg_len); // 移除已处理的数据 memmove(rb-buf, rb-buf 4 msg_len, rb-len - 4 - msg_len); rb-len - 4 msg_len; } return 1; }这段代码演示的是核心思路实际工程里你还要处理缓冲区扩容、大包保护、半包残留等问题。但理解了长度字段 循环拆包这个模型再去看任何成熟的协议栈源码都会觉得亲民很多。6. 用 Wireshark 看到 TCP从三次握手到重传6.1 Wireshark 过滤技巧学习 TCP 有个很有效的办法就是抓包。Wireshark 几乎是必备工具它能让你直观看到三次握手、四次挥手、重传、RST 这些协议动作比你空看文档强十倍。启动 Wireshark 后选择环回接口loopback再在过滤器栏输入tcp.port 8080只看 8080 端口的流量。tcp.flags.syn 1 tcp.flags.ack 0只看 SYN 包。tcp.flags.fin 1只看 FIN 包。tcp.analysis.retransmission直接标记出重传包。tcp.analysis.flags显示所有可疑的 TCP 行为。如果你抓的是本地回环127.0.0.1的流量记得用tcp.flags.syn 1 tcp.flags.ack 1过滤 SYN-ACK 包因为回环接口上这些行为同样完整可见。6.2 三次握手的真实样子跑第 4 节的 demo然后在 Wireshark 里过滤tcp.port 8080你会看到一个非常清晰的序列包 1客户端 → 服务端SYNseq 某个值。包 2服务端 → 客户端SYNACKseq 服务端的初始序列号ack 客户端 seq 1。包 3客户端 → 服务端ACKseq 客户端 seq 1ack 服务端 seq 1。看到这三个包你对为什么 connect 会阻塞一会儿就完全理解了——因为在另外两台机器之间这至少需要一次网络往返时间RTT。线上服务如果连接建立慢很多时候就是 RTT 大或者中间有丢包导致握手重传。我处理过很多连接卡住的问题第一件事就是抓包看有没有 SYN 重传一次就能定位问题方向。挥手阶段的四个包也类似FIN、ACK、FIN、ACK。抓包时你会看到前两个包有非常短的间隔后两个包可能隔得比较久这说明对端在收到 FIN 后还要把剩余数据发完才再发 FIN。6.3 重传、乱序和 RSTWireshark 最能体现背后问题的地方是重传。当你模拟网络丢包——比如用tc netem loss 10%在 Linux 上制造丢包——你会看到 Wireshark 用高亮标出重传包。重传意味着 RTT 延长业务方感知到的就是延迟增加。如果重传太频繁说明网络质量差或者你的发送缓冲区太小。还有一个值得关注的包是 RST重置。RST 表示连接被异常终止。最常见的场景是一端已经 close另一端还在发数据收到数据的那端回了一个 RST。我经常看到新手在服务端 recv 返回 0 后没有及时 close然后继续 send结果触发 SIGPIPE 进程直接退出。如果你在 Wireshark 里看到 RST基本能断定是连接生命周期管理出问题了。7. 调试 TCP 服务时这些经验帮我省了不少时间7.1 TIME_WAIT 和端口复用TCP 四层挥手之后主动关闭方会进入 TIME_WAIT 状态默认持续约 2 个 MSL最大报文存活时间Linux 上是 60 秒左右。TIME_WAIT 存在的目的是防止旧连接的延迟报文干扰新连接但代价是端口被占用。如果你写的是短连接型服务——每来一个请求就 accept 一个连接、处理完就关——在一段时间内大量连接涌入你可能会发现 bind 报 Address already in use。这就是 TIME_WAIT 把端口占了。解决方案有几个一是服务端不要频繁主动关闭尽量复用连接二是设置 SO_REUSEADDR 选项让处于 TIME_WAIT 的端口可以重新绑定三是在较高负载场景下做连接池。SO_REUSEADDR 的用法很简单bind 之前加一行int opt 1; setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt));7.2 Backlog 队列与连接积压listen() 的第二个参数叫 backlog很多人理解成最大并发连接数其实是已完成握手的连接队列长度。客户端 connect 成功不代表服务端 accept 了只是内核完成了握手并把它放进队列。如果应用层处理不过来队列满了新的连接就会被丢弃或被客户端 side 感知为连不上。线上调优时除了调大 listen 的 backlog 参数还要注意内核参数net.core.somaxconn和net.ipv4.tcp_max_syn_backlog它们分别限制队列的最大值和半连接队列长度。我之前遇到过服务端并发稍高就出现连接超时的 case最后发现是 somaxconn 默认 128而应用层 backlog 写到了 512超过部分被无声地限制了。7.3 MSS/MTU为什么大包发不过去TCP 在建立连接时会协商 MSS最大分段大小一般等于路径 MTU 减去 IP 头和 TCP 头常见的以太网是 1460 字节。如果你应用层一次 send 了 10KB协议栈会把它拆成多个 MSS 大小的分段发出。实际工作中MSS 问题通常表现为小包能通大包不通或很慢。一个典型的场景是网络中间设备 MTU 设置不一致导致超过某个大小的报文被丢弃而 TCP 又没有快速重传足够触发表现为连接卡死。排查方式就是抓包看有没有TCP segment of a reassembled PDU大量出现结合 ping 探测不同包大小的连通性来定位 MTU 值。这种问题在嵌入式和路由组网环境里尤其常见。7.4 缓冲区设置和超时控制不少人在写 TCP 程序时对缓冲区设置完全随缘。实际上SO_SNDBUF 和 SO_RCVBUF 都会影响性能。发送缓冲区太小send 会阻塞接收缓冲区太小会导致对端滑动窗口变小吞吐量下降。如果你在做大文件传输或高吞吐场景我建议用 getsockopt 先读出默认值再按需调大。超时控制是另一个容易忽略的点。默认情况下 TCP 的 recv 是阻塞的如果对端一直不发数据也不断开你的 recv 会一直等下去。生产环境里必须给 recv 设置超时方式有两种一是用 SO_RCVTIMEO 设置接收超时二是把 socket 设为非阻塞配合 select/poll/epoll 做超时管理。我的建议是凡是涉及对外服务的程序一律不能允许 recv 无限期阻塞否则一个异常客户端就可以耗尽你的线程资源。我在这条路上踩过最多的坑其实都不是协议本身的复杂度而是我以为内核帮我处理了的那部分边界情况。TCP 把可靠性做得很完善但前提是你得正确使用它给的接口、合理设计应用层协议、并且在调试时肯花时间去抓包验证。把上面这几点都跑通一遍你对初识网络编程这个阶段的内容基本就有完整感知了。最后再说一个小技巧如果你在本地测试 TCP 程序记得用netstat -an | grep 8080看看连接状态是 ESTABLISHED 还是 TIME_WAIT一眼就能判断连接生命周期是否正常。这个命令在线上排查时也很好用配合 Wireshark 抓包大部分问题都能快速定位。