TCP：握手、挥手、TIME_WAIT 与粘包。连接只是两端内核各记的一份账，数据是一条没有边界的字节流

客户端 write 5 次，每次 32 字节的一条请求
服务端晚 100 ms 才去读：
  第 1 次 read 拿到 160 字节：5 条粘在一起

客户端 write 1 次，200 KB
服务端用 64 KB 的数组读：
  read 了 4 次：65536 + 65536 + 65536 + 8192

订单服务调库存 500 次，每次新建连接、先 close
用 ss 数一数：
  TIME-WAIT  订单服务这边 500 条
             库存服务那边   0 条
  其中一条 timer:(timewait,59sec,0)

不懂精华时的典型误用：看到 TIME_WAIT 多，就去改内核参数“让它快点消失”（调小 tcp_fin_timeout、打开早已删除的 tcp_tw_recycle），或者给每次调用的 read 加 sleep 等数据“到齐”。前者改错了地方（⑥第三圈），后者只是把粘包变得不那么常见。正确的方向是：边界自己标，连接要复用。

[32 字节][32 字节][32 字节]

reserve 9527 88 2\n reserve …\n

[00 00 00 07][7 字节][00 00 00 1f][31 字节]

选择规则：服务之间的调用，默认用长度前缀 + 长连接；这正是全景里 gRPC 做的：每个库存实例一条 HTTP/2 长连接（第 3 站），每条消息前面 5 字节（第 5 站）。本页学的是它脚下那一层：TCP 怎么建立、怎么关闭，为什么会粘包，为什么非得自己标边界。

④-1 连接不在网线上，在两端内核的账本里

所以“建立连接”就是两边把账本开起来、对上起始编号；“关闭连接”就是两边把账本销掉。下面每一步都是在问：怎样开、怎样销，才不会记错账。

④-2 三次握手：两个起始编号，各要一次“报出”和一次“确认”

每一方都要报出自己的起始序列号（ISN，随机挑的，防止被猜中伪造），并且亲眼看到对方确认收到了。两个方向各一发一确认，本来是 4 个段；库存服务的“确认你的”和“报出我的”可以塞进同一个段（SYN-ACK），所以是 3 个。

决定胜负的约束：网络会让旧包迟到。只有让每一方的起始编号都被对方确认过，双方才知道后面每个字节的编号算的是同一本账；做到这一点最少要 3 个段，再多就是浪费。

握手由内核完成，不用 Java 代码参与：accept() 只是从“已建好的连接”队列（accept 队列）里取一条。队列长度受 new ServerSocket(port, backlog) 的 backlog 和内核 somaxconn 两个值里较小的那个限制，满了会怎样放到 ⑥ 第三圈。

④-3 挥手：两个方向各关各的，所以通常是四段

账本有两个方向：我→你、你→我。FIN 的意思只是“我这个方向不再发了”，对面照样可以继续发。对方收到 FIN，应用 read() 返回 -1；等对方的应用也调了 close()，才发出它那个方向的 FIN。两个方向各一个 FIN、各一个 ACK，就是四次挥手。

两个推论，⑥ 第一圈会用到：CLOSE_WAIT 只能由本端应用结束（它在等你调 close()，内核不会替你关），所以 CLOSE_WAIT 堆积几乎总是代码漏了 close；先发 FIN 的一方（主动关闭方）最后要发那个 ACK，所以 TIME_WAIT 落在它身上，和谁是客户端无关。Java 里只关一个方向用 socket.shutdownOutput()，这就是“半关闭”。

④-4 TIME_WAIT：最后一个 ACK 没人确认，旧包可能还在路上

主动关闭方发出最后一个 ACK 后，不马上销账，而是进 TIME_WAIT 等 2MSL（MSL 是一个段在网络里最多能活多久）。Linux 把它定成 60 秒，本机 ss 看到的计时器正是从 59sec 开始倒数。等这么久有两个理由：

决定胜负的约束：最后一个 ACK 没有人能确认它（再确认就无穷无尽了），网络又可能把旧段扣留一阵再放出来。只能让发最后一个 ACK 的那一方多留一会儿账本，等到“对方的重传”和“路上的旧段”都不可能再出现。代价是一个四元组在 60 秒里不能复用，这就是短连接的天花板。

④-5 账上记的是字节：边界会丢，小包会被攒

write 只是把字节拷进发送缓冲区，什么时候发、切成几段，由内核按窗口、MSS 和 Nagle 算法决定；read 只是把接收缓冲区里当时有的字节拷出来，最多拷满你给的数组。两端都没有地方记“这几个字节是一条”。

Nagle 算法（1984 年）是为 telnet 这类“一次敲一个键”的程序设计的：有小段没被确认时，后面的小段先攒着，等 ACK 回来一起发，省掉大量只带一两个字节的包。延迟 ACK 则是接收方等一会儿，希望把 ACK 捎在回复里。各自都合理，碰上“写、写、读”这种请求格式就互相卡住。比喻和真机制对不上的地方：Nagle 不是按时间攒，是按“有没有未确认的小段”攒；延迟 ACK 的 40 ms 是 Linux 的下限，不同系统不一样。

最少的 API

// 服务端：backlog 是 accept 队列长度的上限之一，不写就是 50
ServerSocket server = new ServerSocket(9090, 1024);
Socket s = server.accept();                 // 握手早已由内核做完
// 客户端
Socket c = new Socket();
c.connect(new InetSocketAddress("inventory", 9090), 1000);  // 连接超时：握手最多等 1 s
c.setSoTimeout(300);                        // 读超时
c.setTcpNoDelay(true);                      // 关掉 Nagle（默认 false）
c.setKeepAlive(true);                       // 空闲探活（默认 false，开了也要 2 小时后才探）
// 按长度前缀收发
DataOutputStream out = new DataOutputStream(new BufferedOutputStream(c.getOutputStream()));
out.writeInt(body.length); out.write(body); out.flush();     // 拼好一次发出
DataInputStream in = new DataInputStream(c.getInputStream());
int len = in.readInt(); byte[] resp = new byte[len]; in.readFully(resp);  // 读够为止
c.shutdownOutput();                         // 半关闭：只发我这个方向的 FIN
c.close();                                  // 两个方向都关；先调的这一方进 TIME_WAIT

走完三种方式对比一下：谁先 close，TIME_WAIT 就在谁那边；FIN 和 SYN 一样占一个序列号，所以对 FIN 的确认号要加 1；SO_LINGER=0 用 RST 直接销账，两边都不留状态，代价见 ⑥ 第三圈。

在本机跑出来：粘包、长度前缀、40 ms、TIME_WAIT 在谁那边

三个类都在同一个目录里，不依赖任何库，--release 8 编译。机器：2 核 ARM，Linux 6.8，OpenJDK 17.0.20.1，全部走 127.0.0.1。完整代码：study-labs/java/network/tcp-handshake-timewait-framing →

$ cd study-labs/java && mvn -q -pl network/tcp-handshake-timewait-framing compile
$ CP=network/tcp-handshake-timewait-framing/target/classes; P=labs.network.tcp_handshake_timewait_framing
$ java -cp $CP $P.Framing
== 1) 粘包：客户端 write 5 次，每次一条 ==
   服务端第 1 次 read 拿到 160 字节: reserve order=9527 sku=88 qty=2⏎reserve order=9528 …⏎
== 2) 拆包：客户端 write 1 次，200 KB ==
   服务端 read 了 4 次: 65536 + 65536 + 65536 + 8192 = 204800 字节
== 3) 长度前缀：每条前面加 4 字节长度 ==
   第 1 条 (31 字节): reserve order=9527 sku=88 qty=2
   …
   第 5 条 (31 字节): reserve order=9531 sku=88 qty=3     # 同样晚读、同样粘在一起，照样切得开

$ java -cp $CP $P.NagleDelayedAck                 # 一次请求分两次 write：5 字节前缀 + 7 字节消息
TCP_NODELAY=false  200 次调用（统计后 100 次）  p50 41.00 ms  p99 41.15 ms  前 5 次: 1.6 41.8 41.0 41.0 41.0
TCP_NODELAY=true   200 次调用（统计后 100 次）  p50 0.06 ms   p99 0.11 ms   前 5 次: 0.2 0.1 0.1 0.1 0.1

$ java -cp $CP $P.TimeWait client 500           # 订单服务先 close
   TIME-WAIT  客户端（订单服务） 500 条   服务端（库存服务）   0 条
   其中一条: TIME-WAIT 0 0 [::ffff:127.0.0.1]:46472 [::ffff:127.0.0.1]:41385 timer:(timewait,59sec,0)
$ java -cp $CP $P.TimeWait server 500           # 库存服务先 close
   TIME-WAIT  客户端（订单服务）   0 条   服务端（库存服务） 500 条
$ java -cp $CP $P.TimeWait linger0 500          # SO_LINGER=0，发 RST
   和这个端口有关的连接一条都没留下
$ java -cp $CP $P.TimeWait leak 500             # 库存服务读到 -1 却忘了 close
   CLOSE-WAIT 客户端（订单服务）   0 条   服务端（库存服务） 500 条
   FIN-WAIT-2 客户端（订单服务） 500 条   服务端（库存服务）   0 条

NagleDelayedAck 的第 1 次只有 1.6 ms：Linux 在连接刚建好时处于“快速 ACK”模式，头几个段立刻确认，之后才开始延迟 ACK。这也是为什么这个坑在“调一次试试”时常常看不出来。

TIME_WAIT 能不能缩短：60 秒是写死的，能动的是“复用”

⑤ 的回环实验因为 tcp_tw_reuse=2，就算建满 28232 条也不一定报错；跨机器时这个值等于关闭，坑 3 才会原样出现。这一点是按内核文档的推论，本机没有跨机器复现。

SO_LINGER=0：用 RST 代替 FIN，没有 TIME_WAIT，也没有体面

setSoLinger(true, 0) 后 close() 不走挥手，直接发 RST：⑤ 的抓包里最后一段是 [R.]，ss 里一条都没留下。代价有三个：发送缓冲区里没发完的数据直接丢掉；对方的 read 抛 Connection reset；最后几个字节到底有没有送达，谁都不知道。所以它只适合“这条连接已经坏了，立刻中止”的场景，比如协议解析出错、心跳超时，不适合拿来消灭 TIME_WAIT。

两个队列：半连接和全连接

版本差异：Linux 5.4 起 somaxconn 默认从 128 提到 4096，老内核上 backlog 设多大都会被截到 128；Java 这边 ServerSocket 不写 backlog 时是 50。JDK 13 用 NIO 重写了 Socket 的实现（JEP 353），对外行为不变；JDK 11 起可以用 jdk.net.ExtendedSocketOptions 按连接设 TCP_KEEPIDLE 等 keepalive 参数，不用改全局 sysctl。

• 重传和 RTO：丢了一个段，等多久重发，为什么 p99 会出现 200 ms、1 s 的台阶
• 滑动窗口和拥塞控制（慢启动、CUBIC、BBR）：长连接为什么比新连接快
• SYN 洪水和 SYN cookie 的原理
• TCP Fast Open、QUIC：把握手的往返再省掉
• Netty 怎么分帧：ByteToMessageDecoder 的累积缓冲（J04 Netty 那一页）
• tcpdump、Wireshark 读包的完整方法：重传、窗口满、零窗口