做 Linux 网络编程这件事，最劝退人的从来不是 API 有多长，而是你打开一个 socket 教程，第一段就甩出"协议族""字节序""五元组"这些词，然后直接给你一段能跑但看不懂的代码。我在带新人的时候反复见过这个场面：代码抄下来能连上，一旦出问题就完全懵——因为底下那层东西从来没建立起来。这篇聊的是 Linux 网络编程里套接字（socket）的预备知识，属于动手写第一行socket()之前必须补齐的那块地基。它不教你怎么写出一个高并发服务器，而是回答几个更靠前的问题：套接字到底是个什么东西，它凭什么能让两个进程隔着网线说话，IP 和端口在中间扮演什么角色，为什么一个端口号会在你的机器上莫名变成一个奇怪的数字。适合刚接触网络编程、写过一点 C 或者 Python、但对"连接"这件事只有模糊印象的读者，也适合写了半年代码却始终没把底层概念串起来的人。

1. 把"套接字"这个词拆开：它到底解决了什么问题

1.1 从本机管道到跨主机：进程间通信的天花板在哪

我们先从一个最朴素的场景说起。同一台机器上两个进程要交换数据，办法有很多：管道、消息队列、共享内存、信号，这些统称为进程间通信（IPC）。它们有一个共同的前提——双方活在同一台机器上，共享同一块内存空间、同一个内核。管道的本质是内核里的一块缓冲区，写端往里塞，读端从里取，快得离谱，因为数据根本没离开过内存。

但这个前提一旦被打破，整套机制就失效了。你的浏览器进程在 A 机器上，Web 服务进程在 B 机器上，两者之间隔着网卡、交换机、路由器，中间还可能有若干跳。这时候"共享内存"无从谈起，内核也不是同一个内核了。跨主机通信必须解决三个新问题：怎么找到对方、怎么在不可靠的介质上把数据搬过去、怎么让两边的应用层不用关心底下是网线还是无线。

套接字就是这三件事的统一答案。它在操作系统内核里提供了一套抽象的通信端点，应用程序只管往这个端点上读写，至于数据怎么被打包、怎么寻址、路上丢没丢，全部交给内核和协议栈。你在应用层看到的仍然是一个"可以 read 和 write 的东西"，跟操作文件的手感几乎一样，这就是它设计上最成功的地方。

1.2 套接字不是协议，是协议之上的统一接口

这里有个特别容易混淆的点，我见过不少人把 socket 和 TCP 当成同一个层级的东西。实际上它们不在一个层面上：TCP、UDP 是传输层协议，规定数据怎么发、怎么确认、怎么重传；而套接字是一套编程接口（API），是应用和协议栈之间的门。同一套 socket API，你传SOCK_STREAM就走 TCP，传SOCK_DGRAM就走 UDP，传SOCK_RAW甚至能自己造 IP 包。

打个比方，套接字像是快递柜的取件口，你不需要知道快递是走航空还是走陆运，只要知道在这个口子递单子、取包裹就行。协议是物流公司内部的事，接口是你和物流之间的约定。理解这一层，你后面看到socket()的第一个参数是"协议族"、第二个参数是"类型"、第三个参数是"协议"，就不会觉得它莫名其妙了——这三者本来就是在描述"用哪套地址体系、走哪种传输方式、具体用哪个协议"。

提示：初学者最常见的误区是把AF_INET和SOCK_STREAM记成"TCP 的两个参数"。它们分别描述地址族和套接字类型，跟 TCP 没有直接绑定关系，AF_INET+SOCK_DGRAM就是 IPv4 的 UDP。

1.3 预备知识该预备到什么程度

我把这块地基拆成四块：分层模型（知道数据包每层加什么头）、寻址体系（IP、端口、五元组）、字节序（一个害人无数的坑）、以及套接字地址结构体（那堆看着眼晕的类型转换）。这四块不需要你背下来，但需要在脑子里形成一个能自洽的图景，出问题时能顺着图景往回推。

举个我自己的例子。早期写服务端，客户端连不上，我第一反应是防火墙，查了半天发现是bind的地址填了127.0.0.1，只有本机能连。这种问题如果你脑子里有"地址绑定的是哪块网卡"这个概念，三十秒就能定位；没有的话，能查一晚上。预备知识的价值不在于让你显得专业，而在于缩短你从"出错了"到"知道错在哪"的距离。

2. 分层模型不是考试题：数据从 write() 到网线要脱几层皮

2.1 四层与七层的对应关系，用一句话记住

教科书上的 OSI 七层模型（物理、数据链路、网络、传输、会话、表示、应用）在实际工程里用得不多，真正落地的是 TCP/IP 四层模型：网络接口层、网络层、传输层、应用层。两者的对应关系不需要死记，你只要抓住一个核心：每一层只跟对端的同一层对话，逻辑上如此，物理上数据要一层层往下走。

具体到我们写代码的场景，你的程序处在应用层，调用的send()属于传输层的接口，传进去的 IP 地址是网络层的东西，而最终帧怎么发出去由网卡驱动管。这种"我在应用层，但我在操作传输层"的错位感，恰恰是 socket 接口设计的高明之处：它把底下三层全部封装了，只留一个文件描述符给你。

2.2 封装与解封装：每下一层就贴一张快递单

数据往下走的过程叫封装。应用层的数据到了传输层，前面加一个 TCP 头（源端口、目的端口、序号、确认号、标志位等，最小 20 字节）；到了网络层，整个 TCP 段前面再加一个 IP 头（源 IP、目的 IP、协议号、TTL 等，最小 20 字节）；到了数据链路层，再加一个以太网头（源 MAC、目的 MAC、类型，14 字节）和一个 4 字节的帧尾校验。

所以你在应用层写 100 字节，实际在网线上跑的是 100 + 20 + 20 + 14 + 4 = 158 字节，这还是最简单的 IPv4 无选项情况。对方收到后反向剥掉这些头，一层层往上递，最后把 100 字节还给应用层。整个过程你能感知到的只有"我写了 100 字节"，其余全是内核代劳。

理解了封装，你就能解释很多现象。为什么小包传输效率低？因为每个包都要背 40 多字节的头，你发 1 个字节，实际开销是 40 多倍，这叫"头部开销"。这也是为什么批量发送、合并小包在性能优化里是常见手段。

2.3 MTU、MSS 与分片：为什么大包会莫名消失

以太网的 MTU（最大传输单元）通常是 1500 字节，指的是一个帧能承载的最大数据量，扣掉 IP 头和 TCP 头，TCP 能塞进去的有效载荷（MSS）大约 1460 字节。你的应用层一次写 10000 字节，传输层会把它切成若干段，每段不超过 MSS。

这里有个坑：如果 IP 层发现包太大而路径上又不允许分片，包会被直接丢弃，而且不一定给你明确反馈。UDP 尤其容易踩，因为 UDP 没有分段机制，一次发 2000 字节的 UDP 数据，在 MTU 1500 的链路上就会被 IP 层分片，任何一片丢了整个包就废了，而 UDP 本身不重传。

所以我给新人的建议很直接：UDP 单包控制在 1400 字节以内，避开分片；TCP 不用你操心，内核会按 MSS 切，但你要意识到"一次 write 不等于对方一次 read"，这个认知后面讲粘包的时候还会用到。

3. IP、端口、五元组：给通信双方定位的三层坐标

3.1 IP 地址定位的是主机，但不是"这一台机器"

IPv4 地址是 32 位，写成点分十进制就是192.168.1.10这种形式。很多人下意识认为一个 IP 对应一台机器，这在早期成立，现在不太准确了。一台机器可以有多块网卡、多个 IP；一个 IP 也可能通过 NAT 被多台机器共享；容器化之后，一个物理机上跑几十个网络命名空间，每个都有自己的 IP。

对写代码的人来说，更要紧的是理解"地址绑定在哪块网卡上"。服务端调bind的时候指定的地址，决定了这个套接字监听哪块网卡的流量。填127.0.0.1就只监听回环，外面进不来；填0.0.0.0表示监听所有网卡；填具体的内网地址就只监听那一块。这个细节我在 1.3 节提过一次，因为它是新手排障时最高频的坑之一。

3.2 端口不是硬件，是内核里的一张映射表

端口号是 16 位无符号整数，范围 0 到 65535。它唯一的作用是在同一台主机上区分不同的进程——IP 负责找到主机，端口负责找到主机上的哪个程序。0 到 1023 是特权端口，普通用户绑定需要权限；1024 到 49151 是注册端口，通常分配给常见服务；49152 以上是动态端口，客户端连接时由内核自动分配源端口。

有个概念值得说清楚：端口不是物理存在的东西，它只是内核协议栈里的一张表。当你bind一个端口，本质是在内核的结构里登记了一条"这个端口归这个套接字管"的记录。所以端口冲突报Address already in use，不是端口被什么硬件占了，是内核里那条记录还在。这也是为什么TIME_WAIT状态会让重启的服务起不来——连接关了，但那条登记还在等 2MSL。

3.3 五元组：一条连接的唯一身份证

单独一个 IP 加端口还不够唯一标识一条连接，因为同一台主机可能同时跟同一个服务端建立多条连接。真正唯一的标识是五元组：源 IP、源端口、目的 IP、目的端口、传输层协议。这五个值组合起来，在内核的连接表里唯一确定一条连接。

这个认知能解释一个常被问到的问题：为什么客户端连同一个服务器，源端口每次都不一样？因为如果源端口固定，五元组就固定了，你没法同时开两条连接。内核分配动态源端口，就是为了让五元组保持唯一。反过来，服务端只用监听一个端口就能服务成千上万个客户端，靠的也是五元组区分——目的端口都一样，但源 IP 和源端口不同，所以是不同的连接。

3.4 127.0.0.1、0.0.0.0、INADDR_ANY 到底差在哪

这三个东西经常被混用，我把它们的实际含义列清楚：

INADDR_ANY在代码里是个宏，值是 0，通过htonl(INADDR_ANY)转换后赋给sin_addr.s_addr。这里要注意，INADDR_ANY本身已经是主机字节序的值 0，转换之后还是 0，所以很多代码直接写addr.sin_addr.s_addr = htonl(INADDR_ANY)或者干脆写INADDR_ANY，结果碰巧都能跑，但语义上不严谨。我建议养成写htonl(INADDR_ANY)的习惯，虽然结果一样，但至少说明你清楚自己在处理字节序。

4. 字节序：一个让新手调试到凌晨的经典坑

4.1 大端和小端，本质是"先放高位还是先放低位"

一个多字节整数在内存里怎么排，不同 CPU 架构有不同约定。大端（big-endian）把最高有效字节放在低地址，小端（little-endian）反过来。举个具体例子，十六进制数0x12345678：

• 大端内存布局：12 34 56 78
• 小端内存布局：78 56 34 12

x86 和常见 ARM 都是小端，网络传输约定用大端，也就是所谓的"网络字节序"。这个约定不是技术上的必然，纯粹是历史选择，但因为早期主流机器是大端架构，就定下来了，后面所有设备都得遵守。

4.2 端口号必须转换，IP 地址也一样

你在代码里写addr.sin_port = 8080，看起来天经地义，但在小端机器上，这个 8080（0x1F90）在内存里存成90 1F，如果直接发出去，对面按大端解析就变成了0x901F，也就是 36895。这就是"端口莫名其妙变了"的完整成因。

所以所有进出协议栈的整数字段都要转换：端口用htons（host to network short，16 位），IP 地址这类 32 位字段用htonl（host to network long）。反过来，从accept拿到的客户端地址、从recvfrom拿到的源端口，都要用ntohs、ntohl转回来才能正确显示。IP 地址如果用的是inet_pton这类函数，它们内部已经处理了字节序，不需要你再转；但如果直接给sin_addr.s_addr赋值一个整数，就必须转。

4.3 记忆方法和一组常用函数

记法很简单：h 是 host，n 是 network，s 是 short（16 位），l 是 long（32 位）。htons就是 host to network short，用于端口；htonl用于 IPv4 地址这种 32 位值；ntohs、ntohl是反方向。

需要包含的头文件是<arpa/inet.h>（在部分系统上是<netinet/in.h>）。这四个函数在大端机器上是空操作，在小端机器上做字节翻转，所以代码里永远要写，不能因为"我这台机器测着没问题"就省掉——换一台架构不同的机器（比如某些嵌入式设备），问题立刻暴露。

4.4 用十行代码验证你手上的机器

光看概念容易飘，直接跑一段验证最实在：

#include <stdio.h> #include <stdint.h> #include <arpa/inet.h> int main(void) { uint16_t port = 8080; uint16_t net = htons(port); printf("原始端口 : 0x%04x\n", port); printf("网络字节序: 0x%04x\n", net); unsigned char *p = (unsigned char *)&net; printf("内存布局 : %02x %02x\n", p[0], p[1]); return 0; }

在 x86 上跑，你会看到原始端口是0x1f90，转换后是0x901f，内存布局是90 1f，说明高字节被放到了低地址，也就是大端。这段代码我建议每个刚学网络编程的人都跑一遍，比看十页书管用。

注意：调试时如果用printf打印端口发现是 36895、1280 这种怪数，先别怀疑代码逻辑，八成是漏了ntohs。我见过最离谱的一次是有人把 36895 当成"服务端返回的随机端口"，查了两天。

5. sockaddr 系列结构体：那堆让人眼晕的类型转换

5.1 为什么 API 里到处都是(struct sockaddr *)

bind、connect、accept这些函数的参数类型是struct sockaddr *，但你实际填的往往是struct sockaddr_in，所以每次都要强转。这个设计看着别扭，其实是为了通用性：套接字要支持多种地址族（IPv4、IPv6、Unix 域），如果每个函数都针对每种地址族提供一套接口，API 数量会爆炸。用一个通用的sockaddr指针加一个长度参数，运行时根据sa_family判断具体类型，就能用一套接口覆盖所有情况。

这属于典型的"为了扩展性牺牲一点类型安全"的设计。你只要记住：传参时强转成struct sockaddr *，同时传结构体的实际大小，就不会出错。长度参数不能传sizeof(struct sockaddr)，因为那个结构体本身只有 16 字节，装不下 IPv6 的地址，必须传你实际用的那个结构体的大小。

5.2 几个结构体的关系和字段含义

sockaddr_in里有个sin_zero[8]字段，纯粹是为了让结构体大小跟sockaddr对齐，填不填都行，但建议用memset把整个结构体清零，避免残留脏数据导致一些玄学问题。我个人的习惯是struct sockaddr_in addr; memset(&addr, 0, sizeof(addr));两行连着写，从来不出错。

sin_family填AF_INET，注意不是PF_INET。虽然两者数值相同、历史上区分过"协议族"和"地址族"，现在混用一般没事，但规范写法是AF_。

5.3 IP 地址的两种填法，以及为什么别再用了 inet_addr

填 IPv4 地址常见两种方式。第一种是直接赋值整数：addr.sin_addr.s_addr = htonl(0xC0A8010A)，可读性极差，只适合做实验。第二种是用字符串转换函数，早期流行inet_addr("192.168.1.10")，但它有个致命缺陷：转换失败时返回INADDR_NONE（也就是255.255.255.255），而这个值本身也是合法地址，你没法区分"出错了"和"真的填了广播地址"。

现在推荐用inet_pton，返回值明确：1 表示成功，0 表示格式不对，-1 表示地址族不支持。反向转换用inet_ntop，比老的inet_ntoa安全，因为inet_ntoa返回的是静态缓冲区，多线程下会互相覆盖。

struct sockaddr_in addr; memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(8080); if (inet_pton(AF_INET, "192.168.1.10", &addr.sin_addr) != 1) { fprintf(stderr, "地址格式错误\n"); return -1; }

这段代码我基本是肌肉记忆，写服务端的时候闭着眼都能敲出来。唯一需要提醒的是，inet_pton处理的地址已经是网络字节序，不要再套一层htonl，否则会转两次等于没转。

6. TCP 和 UDP 的预备认知：先想清楚要可靠还是要轻快

6.1 面向连接与无连接，落到代码上是什么差别

TCP 是面向连接的：通信前要先建立连接，过程中维护状态（序号、窗口、重传计时器），结束时按规矩拆除。UDP 是无连接的：每个包独立发送，不建立状态，不保证到达，不保证顺序。

落到代码上，差别非常直观。TCP 服务端要走socket → bind → listen → accept → read/write → close这一长串，客户端要走socket → connect → write/read → close。UDP 服务端只需要socket → bind → recvfrom/sendto，客户端连connect都可以省（虽然调用了也不算错，只是不产生握手）。这也是为什么很多人拿 UDP 做局域网发现、做心跳，代码短、开销小。

6.2 三次握手和四次挥手，套接字在哪个节点进入可用状态

TCP 建连接的三次握手，对写代码的人来说最关键的一点是：connect返回成功，说明三次握手完成了；accept返回的 fd，才代表一条真正可用的连接。

服务端调用listen之后，套接字进入监听状态，内核为它维护两个队列：未完成队列（收到 SYN、还没完成握手）和已完成队列（握手完成、等着被accept取走）。accept做的事情就是从已完成队列里取一条出来，返回一个新的文件描述符。这里有两点容易误解：一是listen的 backlog 参数，在 Linux 上主要限制已完成队列的长度，不是"最大连接数"；二是监听套接字本身不承载数据，它只负责接客，真正干活的是accept返回的那个新 fd。

关闭时的四次挥手，对应的状态变化是FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT（主动关闭方）和CLOSE_WAIT → LAST_ACK → CLOSED（被动关闭方）。其中TIME_WAIT会持续 2MSL（通常 60 秒左右），目的是确保最后一个 ACK 能到达对方，同时让旧连接的残留包在网络里消散。这个状态是服务端重启时"端口被占用"的最常见原因。

6.3 粘包不是 TCP 的错，是字节流的本性

"TCP 粘包"这个词流传很广，但严格说它不是 TCP 的缺陷。TCP 是字节流协议，它只保证字节按序到达，不保留你write的边界。你连着写三次 100 字节，对方可能一次read到 300 字节，也可能分十次读到，完全取决于内核缓冲区和网络状况。

解决办法是在应用层自己定边界，常见三种：固定长度、分隔符（比如换行）、长度前缀（先发 4 字节表示后续长度）。我一般推荐长度前缀，解析稳定、不怕数据里出现分隔符，实现也就多几行代码。UDP 不存在这个问题，因为它保留消息边界，一次sendto对应一次recvfrom，代价是包可能丢、可能乱序、可能重复。

6.4 选型对照表：别在动手前就选错

选型的原则不复杂：数据不能错、不能丢，选 TCP；延迟敏感、偶尔丢一两个包无所谓，选 UDP。真正难的是有些场景两者都要，比如实时游戏，那就得在 UDP 上自己实现一套轻量可靠机制，这属于进阶话题，预备阶段先不用碰。

7. 环境与工具：动手之前先把"眼睛"装上

7.1 编译环境和一个最小骨架

Linux 下写 C 的网络程序，编译命令通常是gcc server.c -o server，基本不需要额外链接库，因为 socket 相关函数都在 libc 里。头文件至少要包含<sys/socket.h>、<netinet/in.h>、<arpa/inet.h>、<unistd.h>，前三个管套接字和地址结构，最后一个管close。

一个能通过编译的最小骨架长这样：

#include <string.h> #include <stdio.h> #include <unistd.h> #include <arpa/inet.h> #include <netinet/in.h> #include <sys/socket.h> int main(void) { 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); addr.sin_addr.s_addr = htonl(INADDR_ANY); if (bind(fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) { perror("bind"); close(fd); return 1; } if (listen(fd, 128) < 0) { perror("listen"); close(fd); return 1; } printf("listening on 0.0.0.0:8080\n"); pause(); close(fd); return 0; }

这段代码不会处理连接，只是把监听建起来，用来验证环境和概念足够了。注意perror的用法——每个系统调用失败后立刻打印，能省掉大量猜测。

7.2 用 ss 看连接状态，比 netstat 快得多

程序跑起来之后，你需要确认它真的在监听。ss -tnlp是最常用的命令：t表示 TCP，n表示数字形式显示端口，l表示监听状态，p显示进程。输出里能看到LISTEN状态和对应的进程名，一眼就知道端口有没有起来。

连上之后，用ss -tn能看到ESTABLISHED的连接，包括双方的 IP 和端口。这时候你可以对照五元组的概念看一眼，会发现每条连接的源端口都不一样，正好印证前面讲的"动态源端口保证五元组唯一"。

netstat也能用，但机器上连接多了会明显变慢，因为它读的是/proc下的全量文件，而ss直接走内核的 netlink 接口。我现在基本只用ss。

7.3 抓包是验证理解的最快方式

概念看再多，不如抓一次包。tcpdump -i lo -nn port 8080能在回环接口上抓 8080 端口的流量，-nn表示不解析主机名和服务名，输出更干净。抓三次握手的命令是tcpdump -i lo -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0'，能看到 SYN、SYN-ACK、ACK 三个包的先后顺序。

抓包的价值在于把抽象变具体。你亲眼看到 SYN 包只有 0 字节数据、看到端口号在包里是以大端形式呈现的、看到TIME_WAIT期间还有包在重传，前面那些概念立刻就从"背下来的知识"变成"见过的东西"。

7.4 端口被占用时，按这个顺序排查

写服务端最常遇到的报错就是bind: Address already in use。排查顺序我固定是三步：先用ss -tnlp | grep 端口号看是不是真有进程占着；如果没有进程但还报错，用ss -tan | grep 端口号看是不是有大量TIME_WAIT；如果确实是TIME_WAIT，要么等 60 秒，要么在代码里给监听套接字设SO_REUSEADDR。

SO_REUSEADDR的用法是在bind之前调setsockopt：

int opt = 1; setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

这个选项允许绑定处于TIME_WAIT状态的地址，是服务端代码的标准配置，建议无脑加上。它不会带来安全问题，只是让重启更顺畅。

8. 把这些概念串成一条线：从代码到网线的完整路径

8.1 一次完整的调用链，每一环对应哪个概念

我们把前面散落的知识点串一遍。你调用socket(AF_INET, SOCK_STREAM, 0)，内核创建一个套接字对象，返回文件描述符——这一步对应"套接字是协议栈的统一接口"。你填sockaddr_in结构体，把字符串 IP 用inet_pton转成二进制、端口用htons转成大端——这一步对应"寻址体系"和"字节序"。你调bind，内核登记端口归属；调listen，套接字进入监听状态并准备两个队列；客户端connect触发三次握手；accept从队列取出新连接返回新 fd。

之后你write数据，内核按 MSS 分段、加 TCP 头、加 IP 头、交给网卡驱动发出去——这一步对应"分层封装"。对方收到后逐层剥离，数据进入接收缓冲区，它的read从缓冲区取走——这一步对应"字节流没有边界"。

整条链路走通一遍，你会发现前面那些看着零散的概念，其实是同一件事的不同截面。这也是我建议新手不要跳过预备知识的原因：跳过之后你也能跑通代码，但每次出问题都得重新查一遍，而建立了这条链路，你排查问题时是有方向的。

8.2 三个我认为最值得记住的经验点

第一个是永远用memset清零地址结构体。这不是洁癖，sin_zero和对齐填充里的脏数据在某些场景下真的会影响行为，而且清零的成本几乎为零。

第二个是每个系统调用后面都跟错误处理。网络编程的错误特别隐蔽，bind失败你可能以为是端口问题，实际是地址填错；accept返回 -1 可能是被信号打断（EINTR），这种情况下应该重试而不是直接退出。养成if (ret < 0) { perror("xxx"); ... }的习惯，能省掉大量盲猜。

第三个是先用回环地址把逻辑跑通，再换真实地址。127.0.0.1不经过物理网卡，排除了防火墙、路由、交换机这些变量，出问题时范围小得多。我见过太多人一上来就用两台机器联调，结果卡在网络上，连代码本身对不对都不知道。

8.3 接下来该往哪个方向走

预备知识补齐之后，下一步自然是把最小骨架补成一个能收发数据的服务端：加accept循环、加read/write、处理客户端断开。再往后是并发模型的选择——多进程、多线程、select/poll/epoll，每一层都对应着不同的连接规模和使用场景。

我自己的路径是先写单连接的阻塞版本，把它调通、抓包看一遍，然后改成多线程，最后才碰epoll。这个顺序不是必须的，但每一步都在前一步的基础上加一个变量，出问题时容易定位。反过来，上来就抄一个epoll的框架，跑是能跑，但一旦行为不符合预期，你连从哪一层开始查都不知道。

最后分享一个小习惯：每次学一个新的网络概念，我都用tcpdump抓一次对应的包存下来，标注上时间点和当时的操作。攒到现在已经有一百多个文件，遇到不确定的行为就翻出来对照。这个方法笨，但比任何教程都可靠——因为包不会骗人。