1. 从需求到方案为什么用C语言写Socket说实话现在让我带一个新人入门网络编程我还是会让他从 C 语言和 Socket 开始写。网上教程一抓一大把有 Python 的socket模块、Java 的ServerSocket上手确实快但很多底层概念会被语言框架悄悄藏起来。C 语言不一样它把socket、bind、listen、accept、send、recv这些 POSIX 接口摆在明面上你写每一行代码都得知道自己在操作什么TCP 和 UDP 的区别也不再是面试题里的两个定义而是你亲手调出来的行为差异。这篇东西不是从零讲“网络编程是什么”的教材更像是我自己踩过一圈坑之后留下的实战笔记。你会看到怎么用 C 语言写出一个能跑起来的 TCP 回显服务也会看到 UDP 收发要面对哪些“不可靠”的真相还会聊到select多路复用、粘包处理、地址被占用、read 超时这些每天都会碰到的实际问题。适合正在学 C 语言、刚接触 Linux 系统编程、或者被网络编程折磨过但还想搞清楚原理的同学。1.1 网络编程到底在解决什么问题两台机器之间要传数据最朴素的做法是直接拉一根网线一个进程往线上写电平信号另一个进程读。但真实网络不是这样中间有交换机、路由器数据要经过一次次封装和解封装还要处理丢包、乱序、拥塞。如果让每个应用自己去实现这套流程那代码就没法写了。所以操作系统把复杂协议栈封装成一组 API让应用层通过文件描述符读写网络数据这套 API 就是 Socket。Socket 在 Linux 里本质上是一个文件描述符。你open()一个普通文件拿到一个 fd可以read/write你socket()创建一个网络端点拿到的也是一个 fd同样可以read/write。这个“一切皆文件”的设计让网络编程的入口门槛降低不少但要注意TCP 的read不一定能一次读到对方发送的完整数据UDP 的recvfrom却天然按数据报划分边界。这个差异后面会重点说。理解 Socket 要从“端点”这个概念开始。一个 TCP 连接由四元组唯一确定源 IP、源端口、目的 IP、目的端口。服务端调用bind绑定自己的 IP 和端口调用listen进入监听状态然后accept取出一个已经完成握手的连接。客户端则只需要connect发起连接。这个模型很像现实中的“电话总机”服务端的监听 socket 是总机号码accept是接通后分配给话务员的独立线路。1.2 选型思路TCP还是UDP阻塞还是非阻塞我可以先把结论摆出来大多数业务协议都选 TCP因为它有重传、顺序保证、流量控制写起来心智负担小UDP 适合音视频、实时游戏同步、DNS 查询这类“可以丢几帧但不能等重传”的场景。判断标准很简单——如果数据丢了重发一遍还能接受用 TCP如果宁愿丢掉旧数据也要拿到最新的用 UDP。维度TCPUDP连接状态面向连接需三次握手无连接直接发包数据边界字节流无消息边界数据报有边界可靠性可靠丢包重传不可靠可能丢包乱序传输效率相对低相对高典型场景文件传输、HTTP、数据库实时音视频、DNS、游戏同步阻塞与非阻塞是另一个重要分叉。初学阶段先用阻塞式 socket代码线性、容易调试。但是生产环境里一个线程处理一个连接会浪费资源通常需要select、poll、epoll或者多线程。我会在第 5 章重点讲select它足够简单也足够让你理解事件驱动的核心逻辑。2. 核心 API 与底层原理网络编程的“为什么”往往藏在 API 背后的内核逻辑里。你光背函数签名没用得知道每个调用在协议栈里触发了什么。2.1 从 socket() 到 accept()一条完整生命周期一个 TCP 服务端最基本的调用链是socket()-bind()-listen()-accept()-read()/write()-close()socket(int domain, int type, int protocol)第一个参数domain填AF_INET表示 IPv4type填SOCK_STREAM就是 TCP填SOCK_DGRAM就是 UDP。第三个参数通常传0让内核根据前两个参数自动选择协议。如果你想特别指定TCP 可以传IPPROTO_TCPUDP 传IPPROTO_UDP。bind()是把 socket 地址结构绑定到 fd 上。注意端口号和 IP 都要转成网络字节序。这里有个经典坑如果服务端bind到INADDR_ANY表示监听所有网卡地址这对跑在本机的服务很友好客户端无论从127.0.0.1还是局域网 IP 都能连上。如果你绑定了具体的192.168.x.x那127.0.0.1就连不上了。listen(int fd, int backlog)的第二个参数是内核维护的连接队列长度。backlog设得太小并发连接多的时候会出现连接被拒绝的假象设得太大也没意义因为队列长度还要受内核参数somaxconn限制。开发环境填 5 或 32 都行生产环境一般会结合accept的消费速度调节。accept()返回的是已建立连接的可读写 fd注意它和监听 fd 是两回事。循环里accept一次拿一个连接然后read阻塞等待对方数据。我的第一个 TCP 服务端就是只处理一个连接就退出后来改成while(1)仍然只能串行处理一个客户端不关闭后面的客户端就得排队。这个问题就是“C10K 问题”的入门缩影解法是多线程或事件驱动。2.2 三次握手和四次挥手在代码里的位置很多教程讲三次握手喜欢画时序图但代码里的对应关系更实际。客户端调用connect()时内核会发送 SYN 报文进入 SYN_SENT 状态服务端在listen()之后内核已经能响应 SYN发送 SYNACK连接状态变为 SYN_RCVD客户端收到后再回一个 ACK双方连接进入 ESTABLISHED。也就是说当accept()返回时三次握手在应用层看来已经全部完成。写代码的时候你可能感受不到握手的开销但通过ss -tn或者netstat -tn能清楚看到状态变化。我在本机跑服务端客户端connect后立刻netstat总能看到几条ESTABLISHED如果服务端还没accept也可能看到SYN_RECV。理解这些状态对排查“连接建立了但服务端不接受”特别有帮助。四次挥手对应close()的调用。主动关闭方调用close()后进入 FIN_WAIT_1对端收到 FIN 返回 ACK进入 CLOSE_WAIT主动方进入 FIN_WAIT_2随后对端也调用close()发送 FIN主动方收到后进入 TIME_WAIT然后经过 2MSL 时间彻底关闭。TIME_WAIT 是新手最容易懵的状态我见过一堆服务端重启时报Address already in use就是因为端口还在 TIME_WAIT 里没释放。2.3 sockaddr_in、htonl/htons 和字节序struct sockaddr_in是网络编程的必修结构体需要记住三个关键字段sin_family、sin_port、sin_addr。注意端口用htons()转成网络字节序IP 可以用inet_pton()把字符串转成二进制结构也可以用htonl(INADDR_ANY)表示任意地址。字节序的问题很隐蔽。x86 机器是小端存储网络协议规定是大端所以要把主机字节序转成网络字节序。你直接用sin_port 9000不调用htons()本机测试可能侥幸能通因为回环地址上源和目的端口一致但跨机器之后端口会发生“错位”。我指导过一位网友服务端监听 9000客户端也连 9000就是连不上最后发现他只写了sin_port 9000而忘了htons改成htons(9000)立刻就好。打印地址的时候记得用inet_ntop()或旧的inet_ntoa()把它转回字符串同时用ntohs()把端口转回主机字节序。这些细节不致命但会严重影响日志可读性。3. TCP 实战搭建一个能用的回显服务理论讲再多不如直接上一段能编译、能运行、能自己验证的代码。我用 Linux 平台、gcc 编译Windows 上需要换成winsock2.h并初始化WSAStartup后续章节会专门提差异。3.1 TCP 服务端代码与运行下面这段代码实现了一个回显服务客户端发送什么服务端原样返回什么。#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h #define PORT 9000 #define BACKLOG 8 int main(void) { int lfd socket(AF_INET, SOCK_STREAM, 0); if (lfd 0) { perror(socket); exit(1); } int opt 1; setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(PORT); if (bind(lfd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); close(lfd); exit(1); } if (listen(lfd, BACKLOG) 0) { perror(listen); close(lfd); exit(1); } printf(listening on port %d\n, PORT); while (1) { struct sockaddr_in cli; socklen_t len sizeof(cli); int cfd accept(lfd, (struct sockaddr *)cli, len); if (cfd 0) { perror(accept); continue; } char peer[INET_ADDRSTRLEN]; inet_ntop(AF_INET, cli.sin_addr, peer, sizeof(peer)); printf(client %s:%d connected\n, peer, ntohs(cli.sin_port)); char buf[1024]; ssize_t n; while ((n read(cfd, buf, sizeof(buf))) 0) { write(cfd, buf, n); } close(cfd); printf(client closed\n); } close(lfd); return 0; }编译运行gcc -Wall -o tcp_server tcp_server.c ./tcp_server注意SO_REUSEADDR这段。服务端重启时如果端口还在 TIME_WAIT不加这个选项会因为Address already in use直接挂掉。这是实战中几乎必踩的坑。3.2 TCP 客户端代码与连接细节#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h #define PORT 9000 #define SERVER 127.0.0.1 int main(void) { int fd socket(AF_INET, SOCK_STREAM, 0); if (fd 0) { perror(socket); exit(1); } struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_port htons(PORT); inet_pton(AF_INET, SERVER, addr.sin_addr); if (connect(fd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(connect); close(fd); exit(1); } const char *msg hello from client; ssize_t sent write(fd, msg, strlen(msg)); printf(sent %zd bytes\n, sent); char buf[1024]; ssize_t n read(fd, buf, sizeof(buf) - 1); if (n 0) { buf[n] 0; printf(recv: %s\n, buf); } close(fd); return 0; }客户端代码比服务端短得多。connect是阻塞的如果对端地址不可达可能卡很久直到内核超时。生产代码里一般会设置SO_RCVTIMEO或者放入非阻塞模式再配合select控制连接超时。另一个细节是read很可能不是一次读完TCP 是字节流你调用一次read拿到的只是当前内核缓冲区里的部分数据所以业务上必须自己处理“包完整性”。把客户端和服务端都编译好先跑服务端再跑客户端你会看到服务端打印连接日志客户端打印recv: hello from client。这个闭环能跑通Socket 编程算是入门了。3.3 代码只能处理一个连接怎么办上面的服务端虽然能accept多次但while内串行处理一个客户端不断开后面所有客户端都阻塞在accept。要支持多个并发连接最简单的思路是fork()或pthread每个连接一个子进程或线程。但这会带来资源开销和管理复杂度。更高效的做法是用select或epoll单线程监听多个 fd我在第 5 章会展开。如果你读完 3.1 的代码觉得“这也太简单了”说明你已经开始琢磨并发问题了。网络编程的进阶路线通常就是阻塞单连接 - 多线程 - select/poll - epoll - 用户态协议栈。每走一步都要重新理解一次“数据到底怎么从网卡到应用”。4. UDP 实战无连接但有边界UDP 的 API 调用链比 TCP 简单服务端只需要socketbind然后用recvfrom/sendto客户端只需要socket然后直接sendto/recvfrom不需要connect。4.1 UDP 收发模型UDP 服务端核心代码#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h #define PORT 9001 int main(void) { int fd socket(AF_INET, SOCK_DGRAM, 0); if (fd 0) { perror(socket); exit(1); } struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(PORT); if (bind(fd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); close(fd); exit(1); } char buf[1024]; while (1) { struct sockaddr_in cli; socklen_t len sizeof(cli); ssize_t n recvfrom(fd, buf, sizeof(buf), 0, (struct sockaddr *)cli, len); if (n 0) { perror(recvfrom); continue; } printf(recv %zd bytes from %s:%d\n, n, inet_ntoa(cli.sin_addr), ntohs(cli.sin_port)); sendto(fd, buf, n, 0, (struct sockaddr *)cli, len); } close(fd); return 0; }UDP 是面向数据报的每次recvfrom读取的是一个完整的 UDP 报文。也就是说发送方调用一次sendto发送的内容接收方一次recvfrom就能完整拿到不会像 TCP 那样被切成半个包。这是 UDP 相对 TCP 在“消息边界”上的天然优势。但也别高兴太早UDP 不保证有序不保证不丢甚至一个 UDP 数据报可能损坏。服务端代码里之所以每次都要保存cli和len是因为recvfrom会把发送方地址写进去后续sendto回复时要用这个地址。有些新手在 UDP 服务端里忽略了len参数导致recvfrom返回EINVAL这个问题很典型。4.2 MTU、分片和丢包UDP 数据报大小不是任性填的。以太网默认 MTU 通常是 1500 字节IPv4 头最少 20 字节UDP 头 8 字节所以应用层最大能一次性发送的“不分片”UDP payload 一般在 1472 字节左右。如果你用sendto发送 3000 字节内核会做 IP 分片网关或操作系统会把报文拆成多个分片发出任何一个分片丢失整个 IP 数据报都被丢弃UDP 层根本收不到。实际上 UDP 能承载的 payload 上限是 65507 字节65535 - 20 - 8但超过 MTU 后整包概率性丢失会明显上升。我在用iperf3测 UDP 打流时对这个体会特别深。用iperf3 -u -c 127.0.0.1 -b 100M打本地回环看不到真实丢包但打到局域网另一台机器如果 MTU 不一致或者带宽超过链路容量马上能看到Lost Datagrams。这个现实提醒我们UDP 应用必须自己实现丢失检测、重传和乱序缓冲比如游戏同步里的状态插值本质都是在跟 UDP 的“不可靠”作斗争。如果你做的是实时音视频可以接受偶尔丢一帧如果做的是文件传输就别用 UDP 裸传。即便是 QUIC也只是在 UDP 之上加了一整套可靠传输和拥塞控制的逻辑复杂度一点不比 TCP 低。4.3 用 iperf3 模拟 UDP 打流iperf3是个非常实用的网络性能测试工具它可以测 TCP 吞吐也能测 UDP 丢包率。命令基本是这样# 服务端 iperf3 -s -p 5201 # 客户端UDP 打流 10 秒目标带宽 100Mbps iperf3 -u -c 192.168.1.100 -p 5201 -b 100M -t 10输出里会有Total Datagrams、Lost Datagrams和Jitter。如果丢包率很高先别怀疑程序要查链路带宽和网卡驱动。我在本机虚拟机上跑回环UDP 丢包为 0但跨物理网络或打 WiFi 时丢包就开始出现。这个工具特别适合验证你写的 UDP 程序在高负载下会不会出现收包瓶颈。需要注意的是iperf3的 UDP 测试默认带宽如果不加-b会维持一个很小的速率因为它是单线程发送模型。加-b 0可以尽可能快地打流但会把链路打满谨慎在生产环境使用。5. select 多路复用和粘包问题阻塞 socket 写起来简单但一旦到了“要同时处理多个 socket”或者“不想因为一个连接卡死整个进程”的阶段就必须引入多路复用。5.1 select管理多个连接select的核心思想是你先把关心的 fd 放到fd_set里然后调用select内核会阻塞等待这些 fd 中有任何一个变成可读、可写或出错。返回后你用FD_ISSET判断哪个 fd 就绪再针对性地读写。下面是一个用select管理监听 fd 和连接 fd 的简化结构fd_set rset; FD_ZERO(rset); FD_SET(listen_fd, rset); int maxfd listen_fd; while (1) { fd_set tmp rset; int ret select(maxfd 1, tmp, NULL, NULL, NULL); if (ret 0) { continue; } if (FD_ISSET(listen_fd, tmp)) { int cfd accept(listen_fd, NULL, NULL); FD_SET(cfd, rset); if (cfd maxfd) maxfd cfd; } for (int fd 0; fd maxfd; fd) { if (fd listen_fd) continue; if (FD_ISSET(fd, tmp)) { char buf[1024]; ssize_t n read(fd, buf, sizeof(buf)); if (n 0) { close(fd); FD_CLR(fd, rset); } else { write(fd, buf, n); } } } }使用select时每次都要重新把 fd 集合复制给临时集合因为内核会修改这个集合。同时要维护maxfd因为select的第一个参数是最大 fd 加一。这里的坑很多忘记把rset复制给tmp、忘记在accept后更新maxfd、把FD_ISSET放在监听 fd 处理之前错误判断都会引发诡异行为。select并不是性能最优的最多只能管理FD_SETSIZE默认 1024个 fd每次调用还要线性扫描。但它足够简单是理解epoll事件模型的最好跳板。生产环境的高并发服务通常用epoll不过思路一致注册感兴趣的事件内核告诉你哪些事件发生了。5.2 TCP粘包/拆包与自定义协议“粘包”不是 TCP 特有的毛病而是应用层的“消息边界”和 TCP 字节流特性不匹配的结果。TCP 本身没有消息边界发送方调两次send接收方可能一次read全读走也可能读一半。如果应用层没设计协议就会出现“一次读出多个消息”或者“一个消息分几次读到”的现象。解决粘包的办法是自定义协议。最简单的方式是“长度前缀法”每条消息由固定长度的头部 消息体组成头部里写清楚 body 长度。接收方先读 4 字节头部解析长度 L再循环读够 L 字节才认为是一条完整消息。uint32_t length; read(fd, length, sizeof(length)); length ntohl(length); char *msg malloc(length); ssize_t received 0; while (received length) { ssize_t n read(fd, msg received, length - received); if (n 0) break; received n; }这段代码是生产环境协议的雏形。现实中的协议还会加入 magic number、消息类型、校验字段。比如 Modbus TCP 的 MBAP 头部就是 7 字节事务处理标识符协议标识符长度单元标识符。写网络程序时设计一套清晰的帧格式比什么都重要。6. 常见问题排查与避坑实录最后这部分是我最想分享的。很多问题不看现场根本想不明白但一旦知道原理下次几秒钟就能定位。6.1 端口被占、连接拒绝、read超时启动服务端时报bind: Address already in use第一反应先跑ss -tlnp看端口被谁占了。如果是自己程序留下的 TIME_WAIT加上SO_REUSEADDR就能解决。注意SO_REUSEADDR的作用是在 TIME_WAIT 状态下允许重新绑定端口不是“同时多个进程监听同一端口”。客户端connect报Connection refused通常是服务端没启动或者listen的 backlog 满、防火墙把端口过滤了。排查顺序先ping确认网络通再telnet ip port看端口是否可达最后检查服务端日志。read阻塞超时也是高频问题。TCP 的read在没有数据时会一直阻塞如果想做一个“3 秒内没返回数据就算失败”的逻辑要用select加超时参数或者设置SO_RCVTIMEO。SO_RCVTIMEO触发后read返回 -1errno是EAGAIN或EWOULDBLOCK别误判成网络错误。6.2 为什么recv到的数据有“随机尾巴”有同学问我为什么recv收数据时明明对方只发了 5 个字节他打印出来后面却跟着一堆随机字符。这个现象九成是缓冲区没有正确终止。比如char buf[1024]; read(fd, buf, 1024); printf(%s\n, buf);如果这次read只收到 5 字节buf[5]之后是旧数据或未初始化字节你用%s打印自然输出“随机尾巴”。解决方式有两种要么用read返回值作为实际长度然后buf[n] \0要么在使用前memset(buf, 0, sizeof(buf))。我自己的习惯是read(fd, buf, sizeof(buf)-1)再手动buf[n] \0既防越界又防尾巴。还有一个隐蔽问题如果你在recvfromUDP 时传入的缓冲区比实际 UDP 报文小内核会截断多余数据导致应用层拿到的是残缺数据。所以 UDP 缓冲区要么给到 65536要么就明确知道对端不会超过某个长度。6.3 调试网络程序的小工具除了gdb我平时会用strace跟踪系统调用strace -f -e tracenetwork ./tcp_server能看到socket、bind、listen、accept的返回值比在代码里加printf快得多。检查连接状态用ss -tnp抓包用tcpdumptcpdump -i lo -nn -s 0 port 9000 -w tcp.pcap抓下来的包可以用 Wireshark 打开能直观看到三次握手、数据传输、四次挥手的过程。我第一次在 Wireshark 里看到SYN - SYNACK - ACK时才真正把课本和代码对应上。调试网络程序不是靠猜是让系统告诉你真相。另外提醒一下 Windows 平台的同学C 语言用winsock.h或winsock2.h时第一件必须做的事是WSAStartup()退出前WSACleanup()而且用closesocket()而不是close()。很多把 Linux 代码直接搬到 Windows 的编译错误根源都是平台 API 差异。网络编程这条路没有玄学。数据从网卡到协议栈再到你的read缓冲区每一层都有迹可循。我每次碰到难缠的问题都会回去问自己三个问题数据真的发了吗接收方真的读了吗读到的数据是我想的那段吗把这三个问题逐一验证大多数问题都会浮出水面。上手阶段不必急着追求高并发先把我上面给的 TCP 回显服务和 UDP 收发代码能在本机跑通再用tcpdump抓一次包然后用select把单连接改成多连接最后给自己的协议加上长度字段。顺着这条路走下来你会发现自己已经能读懂很多开源项目的网络模块了。
C语言Socket编程实战：TCP回显服务、UDP收发与select多路复用
1. 从需求到方案为什么用C语言写Socket说实话现在让我带一个新人入门网络编程我还是会让他从 C 语言和 Socket 开始写。网上教程一抓一大把有 Python 的socket模块、Java 的ServerSocket上手确实快但很多底层概念会被语言框架悄悄藏起来。C 语言不一样它把socket、bind、listen、accept、send、recv这些 POSIX 接口摆在明面上你写每一行代码都得知道自己在操作什么TCP 和 UDP 的区别也不再是面试题里的两个定义而是你亲手调出来的行为差异。这篇东西不是从零讲“网络编程是什么”的教材更像是我自己踩过一圈坑之后留下的实战笔记。你会看到怎么用 C 语言写出一个能跑起来的 TCP 回显服务也会看到 UDP 收发要面对哪些“不可靠”的真相还会聊到select多路复用、粘包处理、地址被占用、read 超时这些每天都会碰到的实际问题。适合正在学 C 语言、刚接触 Linux 系统编程、或者被网络编程折磨过但还想搞清楚原理的同学。1.1 网络编程到底在解决什么问题两台机器之间要传数据最朴素的做法是直接拉一根网线一个进程往线上写电平信号另一个进程读。但真实网络不是这样中间有交换机、路由器数据要经过一次次封装和解封装还要处理丢包、乱序、拥塞。如果让每个应用自己去实现这套流程那代码就没法写了。所以操作系统把复杂协议栈封装成一组 API让应用层通过文件描述符读写网络数据这套 API 就是 Socket。Socket 在 Linux 里本质上是一个文件描述符。你open()一个普通文件拿到一个 fd可以read/write你socket()创建一个网络端点拿到的也是一个 fd同样可以read/write。这个“一切皆文件”的设计让网络编程的入口门槛降低不少但要注意TCP 的read不一定能一次读到对方发送的完整数据UDP 的recvfrom却天然按数据报划分边界。这个差异后面会重点说。理解 Socket 要从“端点”这个概念开始。一个 TCP 连接由四元组唯一确定源 IP、源端口、目的 IP、目的端口。服务端调用bind绑定自己的 IP 和端口调用listen进入监听状态然后accept取出一个已经完成握手的连接。客户端则只需要connect发起连接。这个模型很像现实中的“电话总机”服务端的监听 socket 是总机号码accept是接通后分配给话务员的独立线路。1.2 选型思路TCP还是UDP阻塞还是非阻塞我可以先把结论摆出来大多数业务协议都选 TCP因为它有重传、顺序保证、流量控制写起来心智负担小UDP 适合音视频、实时游戏同步、DNS 查询这类“可以丢几帧但不能等重传”的场景。判断标准很简单——如果数据丢了重发一遍还能接受用 TCP如果宁愿丢掉旧数据也要拿到最新的用 UDP。维度TCPUDP连接状态面向连接需三次握手无连接直接发包数据边界字节流无消息边界数据报有边界可靠性可靠丢包重传不可靠可能丢包乱序传输效率相对低相对高典型场景文件传输、HTTP、数据库实时音视频、DNS、游戏同步阻塞与非阻塞是另一个重要分叉。初学阶段先用阻塞式 socket代码线性、容易调试。但是生产环境里一个线程处理一个连接会浪费资源通常需要select、poll、epoll或者多线程。我会在第 5 章重点讲select它足够简单也足够让你理解事件驱动的核心逻辑。2. 核心 API 与底层原理网络编程的“为什么”往往藏在 API 背后的内核逻辑里。你光背函数签名没用得知道每个调用在协议栈里触发了什么。2.1 从 socket() 到 accept()一条完整生命周期一个 TCP 服务端最基本的调用链是socket()-bind()-listen()-accept()-read()/write()-close()socket(int domain, int type, int protocol)第一个参数domain填AF_INET表示 IPv4type填SOCK_STREAM就是 TCP填SOCK_DGRAM就是 UDP。第三个参数通常传0让内核根据前两个参数自动选择协议。如果你想特别指定TCP 可以传IPPROTO_TCPUDP 传IPPROTO_UDP。bind()是把 socket 地址结构绑定到 fd 上。注意端口号和 IP 都要转成网络字节序。这里有个经典坑如果服务端bind到INADDR_ANY表示监听所有网卡地址这对跑在本机的服务很友好客户端无论从127.0.0.1还是局域网 IP 都能连上。如果你绑定了具体的192.168.x.x那127.0.0.1就连不上了。listen(int fd, int backlog)的第二个参数是内核维护的连接队列长度。backlog设得太小并发连接多的时候会出现连接被拒绝的假象设得太大也没意义因为队列长度还要受内核参数somaxconn限制。开发环境填 5 或 32 都行生产环境一般会结合accept的消费速度调节。accept()返回的是已建立连接的可读写 fd注意它和监听 fd 是两回事。循环里accept一次拿一个连接然后read阻塞等待对方数据。我的第一个 TCP 服务端就是只处理一个连接就退出后来改成while(1)仍然只能串行处理一个客户端不关闭后面的客户端就得排队。这个问题就是“C10K 问题”的入门缩影解法是多线程或事件驱动。2.2 三次握手和四次挥手在代码里的位置很多教程讲三次握手喜欢画时序图但代码里的对应关系更实际。客户端调用connect()时内核会发送 SYN 报文进入 SYN_SENT 状态服务端在listen()之后内核已经能响应 SYN发送 SYNACK连接状态变为 SYN_RCVD客户端收到后再回一个 ACK双方连接进入 ESTABLISHED。也就是说当accept()返回时三次握手在应用层看来已经全部完成。写代码的时候你可能感受不到握手的开销但通过ss -tn或者netstat -tn能清楚看到状态变化。我在本机跑服务端客户端connect后立刻netstat总能看到几条ESTABLISHED如果服务端还没accept也可能看到SYN_RECV。理解这些状态对排查“连接建立了但服务端不接受”特别有帮助。四次挥手对应close()的调用。主动关闭方调用close()后进入 FIN_WAIT_1对端收到 FIN 返回 ACK进入 CLOSE_WAIT主动方进入 FIN_WAIT_2随后对端也调用close()发送 FIN主动方收到后进入 TIME_WAIT然后经过 2MSL 时间彻底关闭。TIME_WAIT 是新手最容易懵的状态我见过一堆服务端重启时报Address already in use就是因为端口还在 TIME_WAIT 里没释放。2.3 sockaddr_in、htonl/htons 和字节序struct sockaddr_in是网络编程的必修结构体需要记住三个关键字段sin_family、sin_port、sin_addr。注意端口用htons()转成网络字节序IP 可以用inet_pton()把字符串转成二进制结构也可以用htonl(INADDR_ANY)表示任意地址。字节序的问题很隐蔽。x86 机器是小端存储网络协议规定是大端所以要把主机字节序转成网络字节序。你直接用sin_port 9000不调用htons()本机测试可能侥幸能通因为回环地址上源和目的端口一致但跨机器之后端口会发生“错位”。我指导过一位网友服务端监听 9000客户端也连 9000就是连不上最后发现他只写了sin_port 9000而忘了htons改成htons(9000)立刻就好。打印地址的时候记得用inet_ntop()或旧的inet_ntoa()把它转回字符串同时用ntohs()把端口转回主机字节序。这些细节不致命但会严重影响日志可读性。3. TCP 实战搭建一个能用的回显服务理论讲再多不如直接上一段能编译、能运行、能自己验证的代码。我用 Linux 平台、gcc 编译Windows 上需要换成winsock2.h并初始化WSAStartup后续章节会专门提差异。3.1 TCP 服务端代码与运行下面这段代码实现了一个回显服务客户端发送什么服务端原样返回什么。#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h #define PORT 9000 #define BACKLOG 8 int main(void) { int lfd socket(AF_INET, SOCK_STREAM, 0); if (lfd 0) { perror(socket); exit(1); } int opt 1; setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(PORT); if (bind(lfd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); close(lfd); exit(1); } if (listen(lfd, BACKLOG) 0) { perror(listen); close(lfd); exit(1); } printf(listening on port %d\n, PORT); while (1) { struct sockaddr_in cli; socklen_t len sizeof(cli); int cfd accept(lfd, (struct sockaddr *)cli, len); if (cfd 0) { perror(accept); continue; } char peer[INET_ADDRSTRLEN]; inet_ntop(AF_INET, cli.sin_addr, peer, sizeof(peer)); printf(client %s:%d connected\n, peer, ntohs(cli.sin_port)); char buf[1024]; ssize_t n; while ((n read(cfd, buf, sizeof(buf))) 0) { write(cfd, buf, n); } close(cfd); printf(client closed\n); } close(lfd); return 0; }编译运行gcc -Wall -o tcp_server tcp_server.c ./tcp_server注意SO_REUSEADDR这段。服务端重启时如果端口还在 TIME_WAIT不加这个选项会因为Address already in use直接挂掉。这是实战中几乎必踩的坑。3.2 TCP 客户端代码与连接细节#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h #define PORT 9000 #define SERVER 127.0.0.1 int main(void) { int fd socket(AF_INET, SOCK_STREAM, 0); if (fd 0) { perror(socket); exit(1); } struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_port htons(PORT); inet_pton(AF_INET, SERVER, addr.sin_addr); if (connect(fd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(connect); close(fd); exit(1); } const char *msg hello from client; ssize_t sent write(fd, msg, strlen(msg)); printf(sent %zd bytes\n, sent); char buf[1024]; ssize_t n read(fd, buf, sizeof(buf) - 1); if (n 0) { buf[n] 0; printf(recv: %s\n, buf); } close(fd); return 0; }客户端代码比服务端短得多。connect是阻塞的如果对端地址不可达可能卡很久直到内核超时。生产代码里一般会设置SO_RCVTIMEO或者放入非阻塞模式再配合select控制连接超时。另一个细节是read很可能不是一次读完TCP 是字节流你调用一次read拿到的只是当前内核缓冲区里的部分数据所以业务上必须自己处理“包完整性”。把客户端和服务端都编译好先跑服务端再跑客户端你会看到服务端打印连接日志客户端打印recv: hello from client。这个闭环能跑通Socket 编程算是入门了。3.3 代码只能处理一个连接怎么办上面的服务端虽然能accept多次但while内串行处理一个客户端不断开后面所有客户端都阻塞在accept。要支持多个并发连接最简单的思路是fork()或pthread每个连接一个子进程或线程。但这会带来资源开销和管理复杂度。更高效的做法是用select或epoll单线程监听多个 fd我在第 5 章会展开。如果你读完 3.1 的代码觉得“这也太简单了”说明你已经开始琢磨并发问题了。网络编程的进阶路线通常就是阻塞单连接 - 多线程 - select/poll - epoll - 用户态协议栈。每走一步都要重新理解一次“数据到底怎么从网卡到应用”。4. UDP 实战无连接但有边界UDP 的 API 调用链比 TCP 简单服务端只需要socketbind然后用recvfrom/sendto客户端只需要socket然后直接sendto/recvfrom不需要connect。4.1 UDP 收发模型UDP 服务端核心代码#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include arpa/inet.h #define PORT 9001 int main(void) { int fd socket(AF_INET, SOCK_DGRAM, 0); if (fd 0) { perror(socket); exit(1); } struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(PORT); if (bind(fd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); close(fd); exit(1); } char buf[1024]; while (1) { struct sockaddr_in cli; socklen_t len sizeof(cli); ssize_t n recvfrom(fd, buf, sizeof(buf), 0, (struct sockaddr *)cli, len); if (n 0) { perror(recvfrom); continue; } printf(recv %zd bytes from %s:%d\n, n, inet_ntoa(cli.sin_addr), ntohs(cli.sin_port)); sendto(fd, buf, n, 0, (struct sockaddr *)cli, len); } close(fd); return 0; }UDP 是面向数据报的每次recvfrom读取的是一个完整的 UDP 报文。也就是说发送方调用一次sendto发送的内容接收方一次recvfrom就能完整拿到不会像 TCP 那样被切成半个包。这是 UDP 相对 TCP 在“消息边界”上的天然优势。但也别高兴太早UDP 不保证有序不保证不丢甚至一个 UDP 数据报可能损坏。服务端代码里之所以每次都要保存cli和len是因为recvfrom会把发送方地址写进去后续sendto回复时要用这个地址。有些新手在 UDP 服务端里忽略了len参数导致recvfrom返回EINVAL这个问题很典型。4.2 MTU、分片和丢包UDP 数据报大小不是任性填的。以太网默认 MTU 通常是 1500 字节IPv4 头最少 20 字节UDP 头 8 字节所以应用层最大能一次性发送的“不分片”UDP payload 一般在 1472 字节左右。如果你用sendto发送 3000 字节内核会做 IP 分片网关或操作系统会把报文拆成多个分片发出任何一个分片丢失整个 IP 数据报都被丢弃UDP 层根本收不到。实际上 UDP 能承载的 payload 上限是 65507 字节65535 - 20 - 8但超过 MTU 后整包概率性丢失会明显上升。我在用iperf3测 UDP 打流时对这个体会特别深。用iperf3 -u -c 127.0.0.1 -b 100M打本地回环看不到真实丢包但打到局域网另一台机器如果 MTU 不一致或者带宽超过链路容量马上能看到Lost Datagrams。这个现实提醒我们UDP 应用必须自己实现丢失检测、重传和乱序缓冲比如游戏同步里的状态插值本质都是在跟 UDP 的“不可靠”作斗争。如果你做的是实时音视频可以接受偶尔丢一帧如果做的是文件传输就别用 UDP 裸传。即便是 QUIC也只是在 UDP 之上加了一整套可靠传输和拥塞控制的逻辑复杂度一点不比 TCP 低。4.3 用 iperf3 模拟 UDP 打流iperf3是个非常实用的网络性能测试工具它可以测 TCP 吞吐也能测 UDP 丢包率。命令基本是这样# 服务端 iperf3 -s -p 5201 # 客户端UDP 打流 10 秒目标带宽 100Mbps iperf3 -u -c 192.168.1.100 -p 5201 -b 100M -t 10输出里会有Total Datagrams、Lost Datagrams和Jitter。如果丢包率很高先别怀疑程序要查链路带宽和网卡驱动。我在本机虚拟机上跑回环UDP 丢包为 0但跨物理网络或打 WiFi 时丢包就开始出现。这个工具特别适合验证你写的 UDP 程序在高负载下会不会出现收包瓶颈。需要注意的是iperf3的 UDP 测试默认带宽如果不加-b会维持一个很小的速率因为它是单线程发送模型。加-b 0可以尽可能快地打流但会把链路打满谨慎在生产环境使用。5. select 多路复用和粘包问题阻塞 socket 写起来简单但一旦到了“要同时处理多个 socket”或者“不想因为一个连接卡死整个进程”的阶段就必须引入多路复用。5.1 select管理多个连接select的核心思想是你先把关心的 fd 放到fd_set里然后调用select内核会阻塞等待这些 fd 中有任何一个变成可读、可写或出错。返回后你用FD_ISSET判断哪个 fd 就绪再针对性地读写。下面是一个用select管理监听 fd 和连接 fd 的简化结构fd_set rset; FD_ZERO(rset); FD_SET(listen_fd, rset); int maxfd listen_fd; while (1) { fd_set tmp rset; int ret select(maxfd 1, tmp, NULL, NULL, NULL); if (ret 0) { continue; } if (FD_ISSET(listen_fd, tmp)) { int cfd accept(listen_fd, NULL, NULL); FD_SET(cfd, rset); if (cfd maxfd) maxfd cfd; } for (int fd 0; fd maxfd; fd) { if (fd listen_fd) continue; if (FD_ISSET(fd, tmp)) { char buf[1024]; ssize_t n read(fd, buf, sizeof(buf)); if (n 0) { close(fd); FD_CLR(fd, rset); } else { write(fd, buf, n); } } } }使用select时每次都要重新把 fd 集合复制给临时集合因为内核会修改这个集合。同时要维护maxfd因为select的第一个参数是最大 fd 加一。这里的坑很多忘记把rset复制给tmp、忘记在accept后更新maxfd、把FD_ISSET放在监听 fd 处理之前错误判断都会引发诡异行为。select并不是性能最优的最多只能管理FD_SETSIZE默认 1024个 fd每次调用还要线性扫描。但它足够简单是理解epoll事件模型的最好跳板。生产环境的高并发服务通常用epoll不过思路一致注册感兴趣的事件内核告诉你哪些事件发生了。5.2 TCP粘包/拆包与自定义协议“粘包”不是 TCP 特有的毛病而是应用层的“消息边界”和 TCP 字节流特性不匹配的结果。TCP 本身没有消息边界发送方调两次send接收方可能一次read全读走也可能读一半。如果应用层没设计协议就会出现“一次读出多个消息”或者“一个消息分几次读到”的现象。解决粘包的办法是自定义协议。最简单的方式是“长度前缀法”每条消息由固定长度的头部 消息体组成头部里写清楚 body 长度。接收方先读 4 字节头部解析长度 L再循环读够 L 字节才认为是一条完整消息。uint32_t length; read(fd, length, sizeof(length)); length ntohl(length); char *msg malloc(length); ssize_t received 0; while (received length) { ssize_t n read(fd, msg received, length - received); if (n 0) break; received n; }这段代码是生产环境协议的雏形。现实中的协议还会加入 magic number、消息类型、校验字段。比如 Modbus TCP 的 MBAP 头部就是 7 字节事务处理标识符协议标识符长度单元标识符。写网络程序时设计一套清晰的帧格式比什么都重要。6. 常见问题排查与避坑实录最后这部分是我最想分享的。很多问题不看现场根本想不明白但一旦知道原理下次几秒钟就能定位。6.1 端口被占、连接拒绝、read超时启动服务端时报bind: Address already in use第一反应先跑ss -tlnp看端口被谁占了。如果是自己程序留下的 TIME_WAIT加上SO_REUSEADDR就能解决。注意SO_REUSEADDR的作用是在 TIME_WAIT 状态下允许重新绑定端口不是“同时多个进程监听同一端口”。客户端connect报Connection refused通常是服务端没启动或者listen的 backlog 满、防火墙把端口过滤了。排查顺序先ping确认网络通再telnet ip port看端口是否可达最后检查服务端日志。read阻塞超时也是高频问题。TCP 的read在没有数据时会一直阻塞如果想做一个“3 秒内没返回数据就算失败”的逻辑要用select加超时参数或者设置SO_RCVTIMEO。SO_RCVTIMEO触发后read返回 -1errno是EAGAIN或EWOULDBLOCK别误判成网络错误。6.2 为什么recv到的数据有“随机尾巴”有同学问我为什么recv收数据时明明对方只发了 5 个字节他打印出来后面却跟着一堆随机字符。这个现象九成是缓冲区没有正确终止。比如char buf[1024]; read(fd, buf, 1024); printf(%s\n, buf);如果这次read只收到 5 字节buf[5]之后是旧数据或未初始化字节你用%s打印自然输出“随机尾巴”。解决方式有两种要么用read返回值作为实际长度然后buf[n] \0要么在使用前memset(buf, 0, sizeof(buf))。我自己的习惯是read(fd, buf, sizeof(buf)-1)再手动buf[n] \0既防越界又防尾巴。还有一个隐蔽问题如果你在recvfromUDP 时传入的缓冲区比实际 UDP 报文小内核会截断多余数据导致应用层拿到的是残缺数据。所以 UDP 缓冲区要么给到 65536要么就明确知道对端不会超过某个长度。6.3 调试网络程序的小工具除了gdb我平时会用strace跟踪系统调用strace -f -e tracenetwork ./tcp_server能看到socket、bind、listen、accept的返回值比在代码里加printf快得多。检查连接状态用ss -tnp抓包用tcpdumptcpdump -i lo -nn -s 0 port 9000 -w tcp.pcap抓下来的包可以用 Wireshark 打开能直观看到三次握手、数据传输、四次挥手的过程。我第一次在 Wireshark 里看到SYN - SYNACK - ACK时才真正把课本和代码对应上。调试网络程序不是靠猜是让系统告诉你真相。另外提醒一下 Windows 平台的同学C 语言用winsock.h或winsock2.h时第一件必须做的事是WSAStartup()退出前WSACleanup()而且用closesocket()而不是close()。很多把 Linux 代码直接搬到 Windows 的编译错误根源都是平台 API 差异。网络编程这条路没有玄学。数据从网卡到协议栈再到你的read缓冲区每一层都有迹可循。我每次碰到难缠的问题都会回去问自己三个问题数据真的发了吗接收方真的读了吗读到的数据是我想的那段吗把这三个问题逐一验证大多数问题都会浮出水面。上手阶段不必急着追求高并发先把我上面给的 TCP 回显服务和 UDP 收发代码能在本机跑通再用tcpdump抓一次包然后用select把单连接改成多连接最后给自己的协议加上长度字段。顺着这条路走下来你会发现自己已经能读懂很多开源项目的网络模块了。
