Linux网络编程实战：从三次握手到四次挥手的TCP状态机全解

TCP 这东西，大学课本里讲得最死的是三次握手和四次挥手那两个状态图，但等到真上了 Linux 环境，自己写 socket、抓包、扛线上连接故障的时候，才会发现当初背的图跟内核行为根本不是一回事。我接触网络编程这些年，最深的体会是：你每写一行 socket 代码，就等于在跟内核里的这套状态机打交道，只是平时它藏在系统调用后面不露面，一出问题，纠错成本就上来了。所以这次我把三次握手、四次挥手放到 Linux 网络编程的实际场景里，结合抓包、状态命令、错误码和调优参数，把协议底层那点事重新捋一遍。

这篇文章适合谁看？刚学完计算机网络、脑子里的握手流程还停留在纸面上的学生；写业务代码时遇到 Socket 超时、连接被重置、TIME_WAIT 堆积但不知道怎么下手的开发者；以及想真正搞懂 TCP 状态迁移跟 epoll 事件之间关系的人。我会尽量把每个知识点都落到可复现的命令和场景上，让你不光知道协议怎么工作，更知道怎么验证它、怎么在代码里配合它。

1. 三次握手的前提辨析：SYN 只是敲门，connect 返回不代表连接可用

很多人背三次握手背得滚瓜烂熟：客户端发 SYN，服务端回 SYN+ACK，客户端再回 ACK，连接建立。但落到代码上，一个最容易踩的坑就是混淆“connect 系统调用返回成功”和“本次握手完整结束”这两个时刻。我自己就吃过一次大亏。

1.1 三次握手的本质是两组序列号的双向同步

先回到协议本身。SYN 这个标志位，数据包里带着一个关键字段叫初始序列号。客户端发给服务端的那个 SYN，是在说“我从编号 x 开始给你发数据”；服务端回的 SYN+ACK，是在说“我收到你的 x 了，我从编号 y 开始给你发数据”；最后的 ACK，是客户端告诉服务端“收到 y 了”。

换句话说，三次握手从头到尾只干了一件事：让双方都知道对方的下一个字节序号从哪开始，同时让对方确认自己知道。为什么必须三次？因为“请求—确认”至少需要一个往返（客户端确认服务端能收），而服务端确认客户端愿意收，也必须有一个明确的信号。两次握手做不到这点——服务端发完自己的起始序号后，没法确认客户端真的收到了，一旦出现网络里滞留的旧 SYN 包，服务端可能傻乎乎地为一个早已失效的连接建立资源。三次握手则把这种误判的概率压到了极低，代价只是多一个包。

这里要插一句基础概念：序列号 ISN 并不是从 1 数起的，而是按时间随机生成。Linux 内核的 TCP 初始化序列号会随时间递增，所以你在抓包的时候看到 SYN 包里的 seq 是 3500000000 这种大数字别惊讶，这是正常现象，遵从 32 位回绕规律。

1.2 connect() 成功与握手完成之间的关系

写阻塞式 socket 时，connect() 返回成功，一般意味着对端的 SYN+ACK 已经收到了，但此时本地还有一个待发出的 ACK 没有走完整个网络往返，也就是说从协议状态机看，连接已经从 SYN_SENT 进入 ESTABLISHED，可数据包层面还没完全落地。在绝大多数场景下这个差别没法察觉，因为内核会在一个极短的时间窗口内把 ACK 发出去。

可一旦你把非阻塞 connect 引入程序逻辑，事情就微妙了。非阻塞模式下 connect() 几乎立即返回 -1，同时 errno 设置为 EINPROGRESS，表面看像调用失败了，其实握手还在后台飞。很多同学第一次写非阻塞 connect 时，直接判断返回值不等于 0 就报错，结果连一个正常启动的服务端都连不上，这就是不理解“EINPROGRESS 是正常握手中的状态”导致的。

正确的判断方式，是将这个 socket 交给 select 或 epoll，关注可写事件，然后通过 getsockopt 取 SO_ERROR，值为 0 才代表握手完成。这个细节后面我会单独展开讲。

1.3 用命令亲眼观察半连接和完成状态

在一切动手之前，建议先在 Linux 上做一次最直观的观察实验。

第一步，开一个简单的服务端端口，例如用 nc 监听 8080：

nc -l 8080

第二步，在另一个终端发起连接：

telnet 127.0.0.1 8080

第三步，立刻在第三个终端执行ss -tna（老系统用netstat -tna），你会看到一列状态：

State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* SYN-SENT ESTABLISHED

LISTEN 状态对应服务端刚启动；SYN-SENT 是客户端发出 SYN 后还没等到回应；ESTABLISHED 代表这组连接已经完成握手。在实际实验中，SYN-SENT 往往一闪而过，可能压根来不及捕捉，这是正常的。如果抓不到，可以人为制造一次失败连接，比如连一个没人监听的端口，然后立刻执行ss -tna | grep SYN-SENT，大概率能看到那个卡住的 SYN 状态。

这个命令的价值在于：它让你直观认识到，TCP 状态机不是书上的示意图，而是内核里真实存在的一组连接对象，每个对象都带一个状态字段。你代码里写的 socket 只是这条连接对象的一个用户态句柄。

2. 在 Linux 上把三次握手的每个包抓出来看

光看连接状态不够直观，理解协议还得靠抓包。这里我用 tcpdump 给你演示一次完整的握手，并详细解释看到的每一行数据意味着什么。

2.1 一次完整的 tcpdump 抓包全流程

准备两个终端，一个运行监听：

nc -l 8080

另一个终端运行 tcpdump 抓包：

sudo tcpdump -i lo tcp port 8080 -S -nn

然后找一个地方执行：

curl http://127.0.0.1:8080/

抓到的输出大致长这样：

14:23:01.123456 IP 127.0.0.1.51234 > 127.0.0.1.8080: Flags [S], seq 3500000000, win 65495 14:23:01.123457 IP 127.0.0.1.8080 > 127.0.0.1.51234: Flags [S.], seq 1200000000, ack 3500000001, win 65483 14:23:01.123458 IP 127.0.0.1.51234 > 127.0.0.1.8080: Flags [.], ack 1200000001, win 65483

这里几个字段需要解释清楚。

Flags [S]表示 SYN 包，seq 3500000000是客户端选的初始序号。Flags [S.]表示 SYN+ACK，一箭双雕，seq 1200000000是服务端自己的初始序号，ack 3500000001则表示“我已经收到你的序号 3500000000，下一条数据你应该从 3500000001 开始发给我”。Flags [.]是纯 ACK，ack 1200000001告诉服务端“你的序号我收到了”。

注意，抓包时我特意用了-S参数，很多入门教程会漏掉这个参数。不加它，tcpdump 默认显示相对序列号，即抓包文件中第一个包的 seq 按 0 或 1 处理，方便阅读但不严谨。用绝对序列号才能看到 ISN 的真实值，也更容易理解 TCP 序号换算规则。

2.2 理解网卡回环接口、MTU 与窗口字段

上例中用的是-i lo，即回环接口。因为客户端和服务端都在本机，报文不经过真实网卡，回环接口的 MTU 通常为 65536，所以这里看到的 win 字段接近 65535 是很正常的。win 是接收窗口，是接收方当前能收下多少字节的承诺，双方在握手阶段交换一下各自的缓冲区能力，为后续滑动窗口、流量控制打个底。这个肯定是后话，先记在这里。

如果你换到真实网卡抓包，比如-i eth0，客户端和服务端跨机，MTU 一般只有 1500，win 字段也会体现链路层协商的结果。这也是初学者容易困惑的一点：同样的服务、同样的抓包命令，回环口和实体接口看到的窗口大小居然不同。原因就是链路层 MTU 和收发队列大小不一样，协议栈在处理时会把通告窗口截断到合理范围。

2.3 SYN 重传与半连接队列

理解了正常握手，再说异常情况。如果客户端发出的 SYN 没有回应，内核不会立刻放弃，而是启动重传。Linux 默认至少重传 6 次，每次间隔指数退避：1 秒、2 秒、4 秒、8 秒、16 秒、32 秒……一共等约 63 秒才会返回 ETIMEDOUT。这就是为什么你 connect 一个不通的 IP 时，程序会卡一整分钟。

如果服务端收到的 SYN 太多，来不及处理，会先放进半连接队列，也就是 SYN Queue。这个队列的长度由net.ipv4.tcp_max_syn_backlog和somaxconn共同约束。队列溢出时，内核有两种做法：一种是直接丢弃 SYN，客户端表现为 SYN 重传超时；另一种是返回 RST，告诉客户端“别发了，我不收”。对攻击者来说，用海量 SYN 填满队列，就是最经典的 SYN Flood 攻击，受害服务表现为“端口活着但谁都连不上”。

我在排查一个模拟项目 X 的线上超时问题时，就遇到过这种队列打满的情况，现象很迷惑：ss -tna看到 LISTEN 端口还在，本地发起连接也偶有成功，但成功率极低。后来执行：

ss -ltn

观察 Send-Q 满载，同时看内核统计：

netstat -st | grep -i overflow

发现有 SYN 丢弃计数，才确认是半连接队列溢出。这提醒我们：队列的存在不是为了好看，它是真实制约并发连接上限的物理瓶颈。

3. 四个挥手未必是四次：主动关闭方视角下的 FIN、ACK 与 TIME_WAIT

三次握手是建立，四次挥手是拆除。教科书说“四次挥手”是因为理论上需要：主动方发 FIN，被动方回 ACK，被动方再发 FIN，主动方再回 ACK。但真实场景往往不是四个包，有时候只有三个包，很多文章不去解释这种差异，导致读者实操时对不上号。

3.1 为什么会看到“三个包”

回到代码层。被动方收到 FIN 后，应用层会收到一个读取返回 0 的标记。如果被动方程序正确地调用了 close，内核会立即发 FIN；但如果被动方本来就在调用 close 之前已经把所有数据发完了，那么它的 ACK 和 FIN 很可能合并在同一个数据包里发出，于是你抓包就看到：

发起方 -> 接收方: Flags [F.], seq 100, ack 200 接收方 -> 发起方: Flags [F.], seq 200, ack 101 发起方 -> 接收方: Flags [.], ack 201

等于握手三个包，挥手也是三个包。所以以后抓包看到“三次关闭”，不要急着怀疑协议异常，先判断是否发生了 ACK+FIN 合并。合并的关键条件是被动方在回 ACK 的同时已经准备好关闭本端到对端的半连接，常见于数据都发完、业务判定无后续流量的场景。

还有一种常见变体：主动关闭方发送 FIN 后，被动方并不会立刻回 FIN，而是继续保持另一端继续收发——这叫半关闭。TCP 协议允许单方向关闭，shutdown(SHUT_WR)就是这个用途。如果双方都用shutdown做优雅关闭，抓包才能看到教科书上那种完美的四次挥手序列。

3.2 用 shutdown 和 close 区分关闭语义

很多初级开发者以为 close 就是一切。实际上 close 会把 fd 引用计数减一，只有引用计数归零时才真正关闭连接；而 shutdown 则直接对这条连接本身操作，与 fd 引用计数无关。区别极大。

具体来说：shutdown(fd, SHUT_WR)发送 FIN，但这个 fd 仍然能读数据；shutdown(fd, SHUT_RD)则反过来，禁止对端继续给你发数据，内核会丢弃后续传入数据。如果想实现“我发完了但还准备收对端最后的消息”这种半关闭语义，只有 shutdown 能做到，close 做不到。

实际写服务端时，我建议在需要优雅关闭时，优先考虑：

shutdown(client_fd, SHUT_WR);

然后把读取循环继续跑，直到对端返回 0，最后再 close。这样能避免自己发完 FIN 后还有数据没读走导致的 RST 问题。如果直接 close，本地的接收缓冲区可能还有对方最后发来的数据没被读取，内核会暂时不回 FIN，而是继续等，甚至触发 RST，导致对方收到 ECONNRESET，表现就是“服务端关得挺干脆，客户端却报错”。

3.3 TIME_WAIT 为什么踢不掉

主动关闭方发出最后一个 ACK 后，连接就进入 TIME_WAIT，默认等待 2 个 MSL（Linux 下 MSL 取 60 秒，因此 TIME_WAIT 通常是 60 秒）。网上大量文章建议“调小 TIME_WAIT”“开启 tcp_tw_reuse 来规避”，我实际运维中却觉得这事得冷静看待。

TIME_WAIT 存在的意义有两个：一是让最后那个 ACK 有机会重传，防止它丢失后对端超时重发 FIN；二是保证网络中所有旧延迟包在连接生命周期内彻底消失，避免新连接被旧数据污染。它的存在是协议正确性的基石。对绝大多数服务端来说，TIME_WAIT 属于正常现象，只要总量没导致文件描述符或端口耗尽，根本不用管。

对于主动发起大量短连接的客户端，TIME_WAIT 消耗的是“本地端口”资源。如果一秒内向同一个目标端口发起几千次短连接，可能出现端口耗尽、connect 报 EADDRNOTAVAIL。此时先检查代码能不能复用连接，比在系统参数上折腾更有效。

另外提醒一句：tcp_tw_reuse只对客户端出方向生效，而且内核文档明确建议不要在服务端开启tcp_tw_recycle（老内核版本），这个参数在 NAT 环境下会导致分片、乱序数据被误判丢包，问题很隐蔽。谁再让你用 tcp_tw_recycle 解决 TIME_WAIT，你得掂量一下后果。

4. Linux 网络编程里的错误码，是协议状态机的一面镜子

写 TCP 程序时，报错信息里那些 errno 经常让人一头雾水。其实每个错误码都对应了内核协议栈里某个具体状态的异常分支。把状态机搞懂之后，看到这些错误码就不再是瞎猜了。

4.1 核心错误码与协议阶段对照表

下面这个表是我在实际项目排查中总结的，适合先存后看：

4.2 非阻塞 connect 的完成判断细节

非阻塞 connect 的 EINPROGRESS 是最容易写错的一段。不少人拿到 socket 后，调用 connect 判断 errno，然后直奔 write，结果第一次 write 就失败，或连接一直没建立。

正确的流程我建议按这个模板走：

int ret = connect(fd, (struct sockaddr*)&addr, sizeof(addr)); if (ret < 0) { if (errno == EINPROGRESS) { // 连接尚未完成，等待可写事件 } else { return -1; // 真的出错了 } } // 注册到 epoll/reactor，等待 EPOLLOUT // 事件触发后执行： int err = 0; socklen_t len = sizeof(err); getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, &len); if (err == 0) { // 握手已经完整结束，此时可以正常读写了 } else { // 握手失败，err 里就是上文那个表里的错误码 }

这个流程的关键，是不要用“能不能 write”来判断 connect 成功。因为即使对端尚未回复 SYN+ACK，内核也会先把你的写入请求排进发送队列，不报错。等到真正传出去被 RST 打回来，错误才以 SIGPIPE 或 EPIPE 的形式冒出来，届时就晚了。

4.3 服务端视角的 RST 是如何产生的

RST 是 TCP 里最容易被忽略又最能搞心态的包。服务端close(fd)后，内核会发 FIN 还是 RST，取决于接收缓冲区里还有没有数据。如果调用 close 时接收缓冲区中还积压着对端发来的数据，内核不会发 FIN，直接发 RST，强制放弃连接。对端随后任何 read 都会拿到 ECONNRESET，write 则可能触发 SIGPIPE。

因此，服务端想优雅关连接，推荐先循环读到底：

while (1) { int n = read(fd, buf, sizeof(buf)); if (n == 0) break; // 对端已关闭写方向 if (n < 0) { if (errno == EINTR) continue; break; // 真正出错，仍走关闭 } // 处理 n > 0 的残包 } close(fd);

这个细节在写压测工具或网关转发层时尤其重要。我发现很多人写的 C++ 或 Go 服务器，在关闭连接时直接conn.Close()，不考虑残余读缓冲，压测时就会出现大量 RST，却不理解为什么客户端总报 connection reset。其实根子就在一个 close 时机的选择。

5. 从握手的窗口看 TCP 的流量控制与拥塞控制

状态机的东西讲完了，如果只看链路建立，不算完整理解了 TCP。真正吞吞吐吐的数据链路层还有两套独立的节奏系统：流量控制管“我能不能收”，基于接收窗口；拥塞控制管“我敢不敢发”，基于拥塞窗口。两套机制互相制约，Linux 编程里不少性能问题都出在这里。

5.1 两个窗口的差别：一个看对端，一个看路况

流量控制的“窗口”是接收方在 ACK 里携带的 win 字段，它代表接收方还有多少缓冲区能收新数据。如果你的接收缓冲区只有 128KB，对端即使有 1GB 数据准备给你发，它也只能先发 128KB 后停下来等你 ACK 更新窗口。有人搞不理解的怪现象：大文件传输中途突然停止，过几秒又继续，大概率是接收方应用没有及时读走数据，窗口被压到 0，双方进入零窗口探测状态。

拥塞控制的“窗口”是发送方根据网络状况自己算的。慢启动阶段每收到一个 ACK，拥塞窗口加一。丢包触发拥塞窗口减半或重置，经历快速重传、快速恢复。这部分算法的实现太深，业务代码层面你不需要改算法，但你要知道为什么延迟高的链路吞吐上不去——大概率拥塞窗口一直没机会撑大。

5.2 用 nc 和 sysctl 实测接收窗口

在 Linux 上，默认接收缓冲区大小可以通过 sysctl 查看：

sysctl net.ipv4.tcp_rmem

典型输出：

net.ipv4.tcp_rmem = 4096 87380 6291456

三个值分别是最小值、默认值、最大值。默认值 87KB 左右，这是很多连接在握手阶段通告的窗口规模来源。如果这个值偏小，大带宽链路能用的窗口就小，吞吐上不去；调大则消耗内存。调优时要对服务的单连接缓存需求做评估，别盲目拉大，否则内存全被 socket 缓冲区吃掉。

想直观看到窗口变化，可以用一个简单的发包程序，服务端不断向客户端发 10MB 数据，同时用 tcpdump 抓包，观察 ACK 包里的 win 值。你会发现一个规律：客户端应用读取越慢，通告的 win 越小；读取越快，窗口越接近缓冲区上限。这个现象，就是滑动窗口机制在真实链路中的纹理。

5.3 Nagle 算法与延迟确认之间的一场隐仗

Nagle 算法的本意，是把小数据包合并成大包再发，减少网络里大量小包占用的带宽。代价是会引入延迟：一个字节的写入可能要等前一个 ACK 回来，或者攒到足够大的包才发。它在批量传输时挺好，但对时延敏感、交互式小包极多的场景，比如 RPC、游戏、实时信令，就是灾难。

更麻烦的是它还会跟“延迟确认”相互打架。延迟确认是接收方为了减少 ACK 数量，故意等 40ms 才回 ACK。一边发送方因为 Nagle 等着 ACK 才发下一个包，一边接收方因为延迟确认等着下一个包才回 ACK，双方就卡成了死局，40ms 级延迟就出来了。

如果业务对时延敏感、又有很多小于 MSS 的报文，那么应该在 socket 层显式禁用 Nagle：

int flag = 1; setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));

不过这个开关不能无脑开。如果你做的是批量大文件传输，包都是满 MSS，Nagle 几乎不生效，开不开无所谓；如果你做的是密集小包交互网关，又比如数据库代理转发数十万条查询指令，TCP_NODELAY 可能直接避免掉大量莫名 40ms 毛刺。

我自己就遇到过一次诡异的现象：压测一个消息推送服务，发小包能跑到 10 万 QPS，但每一次个别的响应延迟毛刺高达 40ms 以上，排查到最后，内核标志位一看，Nagle 开着，客户端延迟确认的节奏一撞，整个链路的尾部延迟就飘了。关掉之后毛刺消失，p99 从 40ms 降到个位数。从那以后，凡是做低延迟 IO 的项目，我都会提醒一句：先用 tcpdump 看一下有没有奇怪的等待间隙，再决定 TCP_NODELAY 要不要开。

6. 连接队列饱和与 keepalive：容易被忽略但高发的问题

前面梳理的是握手、挥手、窗口这些“正史”，还想再说两个 Linux 网络编程里高频踩到的旁支问题，因为它们直接跟连接生命周期和状态机挂钩，错过可惜。

6.1 accept 队列满了后会发生什么

很多人写服务端，上来就是 listen + accept 循环，从没关心过 listen 的第二个参数 backlog。backlog 设小了，即使在多线程 epoll 模型下，新连接也会失败。前面半连接队列是挑战方握手之前的事，全连接队列则在握手完成后、accept 调用之前排队。握手完但还没被 accept 的连接，就在这个全连接队列里等着。

Linux 2.2 之后，backlog 参数只控制全连接队列长度，具体值是 backlog 和net.core.somaxconn的最小值。比如你传 listen(fd, 1024)，但 somaxconn=512，实际队列只有 512。想调大：

sysctl -w net.core.somaxconn=4096

但注意，应用程序里 listen 的 backlog 也要改，只改内核参数没用。这里有个经验：如果服务突然出现“客户端 connect 成功，但发请求无响应”的情况，优先查全连接队列有没有溢出，用ss -ltn看 Send-Q 打满没，再netstat -st | grep -i listen看有没有 overflow 计数。

6.2 keepalive 不是应用层保活手段

Linux socket 默认启用了 TCP keepalive，但参数极其保守：默认 7200 秒才探测一次，探测失败重试 9 次。你写代码想要“检测死连接”，靠默认 keepalive 能在半天之后才有反应，完全没法用。

要调也是套接字级别去调：

int keepidle = 60; // 60 秒没动静开始探测 int keepintvl = 10; // 探测间隔 10 秒 int keepcnt = 3; // 探测 3 次无回应就断开 setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE, &keepidle, sizeof(keepidle)); setsockopt(fd, IPPROTO_TCP, TCP_KEEPINTVL, &keepintvl, sizeof(keepintvl)); setsockopt(fd, IPPROTO_TCP, TCP_KEEPCNT, &keepcnt, sizeof(keepcnt));

但就算调了，keepalive 也只能保证“连接没有被静默切断”，不能用来探活业务状态。对长连接服务，更常见的是在应用层自己做心跳机制，比如每 15 秒发一个 ping 帧、60 秒收不到 pong 就断开重连。链路空闲太久被中间设备回收，这种问题在移动网络环境尤其常见，光靠内核参数的体验并不好。

一点点个人经验总结

网上讲 TCP 原理的教程汗牛充栋，但真正值钱的永远是你在 Linux 环境里亲手验证过的那部分。我现在养成了两个习惯：第一，凡是涉及连接异常的排障，第一件事就是 tcpdump 抓包 + ss 看状态，拒绝凭空猜；第二，每次调大某个 socket 相关内核参数之前，先问自己“这个参数解决了我的哪一层问题，会不会引入别的问题”。很多时候，那些看起来玄学的网络故障，拆到底都是状态机某个环节没走对，用这套思路逐层拆，基本都能收干净。