Java - 网络与 IO 篇

9.0 开篇：后端为什么绕不开网络和 IO

一起复盘一下：请求从浏览器到你的 Controller，要经过这些关卡——

DNS 找 IP → TCP 三次握手 → TLS 握手 → HTTP 解析
→ 内核把数据放进 socket 缓冲区 → 你的线程把数据读出来
→ 业务处理 → 写回 socket → 四次挥手

JVM 管的是”处理”，网络与 IO 管的是”进出”。很多线上问题（接口慢、连接数打满、CPU 不高但吞吐上不去）根子都在这一段。

学习地图：

分层（数据怎么封装） → TCP（怎么保证可靠） → HTTP（应用怎么说话）
→ IO 模型（内核怎么把数据交给你）→ 零拷贝（怎么少搬几次）
→ Netty（怎么把上面这些工程化）→ 排错（线上怎么查）

站内还有两篇更深入的专题，本文是面试速查版：

• 阻塞、非阻塞、同步、异步：一次 socket 通信里到底发生了什么
• 每种技术用什么协议：DNS、TCP、TLS、HTTP、gRPC

9.1 网络分层：寄一个快递

四层模型

封装：数据从应用层往下走，每层加一个头（就像每层快递套一个袋子），到对端再一层层拆开。这个动作叫封装与解封装。

[ Ethernet 头 ][ IP 头 ][ TCP 头 ][ HTTP 数据 ][ Ethernet 尾 ]

MTU 与 MSS

• MTU（Maximum Transmission Unit）：链路层一帧最多 1500 字节（以太网）
• MSS（Maximum Segment Size）：TCP 一个报文段最多多少数据 = MTU - IP 头 20 - TCP 头 20 = 1460 字节

超过 MTU 会被分片，任何一片丢了整个包都要重传，效率很差。所以 TCP 会按 MSS 切分，尽量不分片。

9.2 TCP 三次握手与四次挥手

三次握手：确认”双方都能说、都能听”

类比：打电话。 你：“喂，能听到吗？“（SYN） 对方：“能听到，你能听到我吗？“（SYN + ACK） 你：“能听到。“（ACK）

少一次会怎样？如果你只说了”喂”就挂断，对方不知道你能否听到他——双向通道只验证了一半。

客户端                          服务端
  | -------- SYN (seq=x) -------> |   SYN_SENT → SYN_RCVD
  | <--- SYN+ACK (seq=y,ack=x+1) -|
  | -------- ACK (ack=y+1) -----> |   ESTABLISHED
  | ======== 开始传数据 ========== |

SYN 洪泛攻击：攻击者只发 SYN 不回 ACK，服务端半连接队列被占满。

注意区分两个队列：半连接队列（收到 SYN 未完成握手）和全连接队列（已完成握手、等待应用 accept）。全连接队列满了，新连接会被拒绝或丢弃，对应参数 somaxconn 和 listen() 的 backlog。

四次挥手：为什么比握手多一次

TCP 是全双工的，两个方向要分别关闭。收到对方的 FIN 只代表”他不再发数据了”，你还可以继续发——这叫半关闭。

客户端                          服务端
  | -------- FIN (seq=u) --------> |   FIN_WAIT_1 → CLOSE_WAIT
  | <---------- ACK --------------|   （我收到了，但可能还有数据要发）
  | <--------- FIN (seq=v) -------|   FIN_WAIT_2 → LAST_ACK
  | ---------- ACK --------------> |   TIME_WAIT → CLOSED

TIME_WAIT 为什么要等 2MSL

1. 保证最后一个 ACK 能到对端：ACK 丢了，对方会重发 FIN，还能再回一次
2. 让旧连接的残留报文在网络中消散，不会串到新连接里

Linux 上 MSL = 30 秒，所以 TIME_WAIT 持续 60 秒。

TIME_WAIT 太多怎么办：

net.ipv4.tcp_tw_reuse = 1        # 允许复用 TIME_WAIT 连接（仅客户端/出站连接）
net.ipv4.tcp_max_tw_buckets      # 限制数量，超了直接清
net.ipv4.ip_local_port_range     # 扩大可用端口范围

⚠️ tcp_tw_recycle 在 Linux 4.12 已移除，网上老文章还在教，别用。它会让 NAT 后面的客户端连接异常。 更好的做法是让客户端主动关闭短连接、用连接池、或者用长连接。

CLOSE_WAIT 太多 = 代码有 bug

CLOSE_WAIT 表示对方已经关了，你的程序还没调 close()。

常见原因：连接泄漏（忘记 finally 关闭）、连接池借出未归还、下游超时后没清理、线程卡死无法执行到关闭逻辑。 看到服务器上大量 CLOSE_WAIT，不要调内核参数，去查代码。

9.3 可靠传输、拥塞控制与粘包

TCP 怎么保证不丢不重不乱

拥塞控制四阶段

慢启动     ：窗口指数增长（1 → 2 → 4 → 8 …），直到阈值
拥塞避免   ：过了阈值，窗口线性增长（每次 +1）
快重传     ：收到 3 个重复 ACK，立即重传丢失段
快恢复     ：不回到慢启动，窗口减半后继续线性增长

算法现状（2026）：

面试答法：默认 CUBIC，高丢包长肥管道（LFN）场景考虑 BBR。切换用 net.ipv4.tcp_congestion_control=bbr。

粘包与拆包

先说结论：TCP 是字节流，没有”消息边界”这个概念。 所谓粘包，不是 TCP 的 bug，是你把字节流当成了消息队列。

发送方发了三条消息： [A][B][C]
接收方可能收到：    [AB][C]  或  [A][BC]  或  [ABC]

// Netty：长度字段解码器
pipeline.addLast(new LengthFieldBasedFrameDecoder(
    1024 * 1024,  // 最大帧长
    0,            // 长度字段偏移
    4,            // 长度字段本身占 4 字节
    0,            // 长度调整值
    4             // 跳过 4 字节长度字段
));

UDP 不存在粘包：它保留消息边界，一次 send 对应一次 receive。代价是可能丢包、乱序、重复。

Nagle 算法与 40ms 延迟

Nagle：小包先攒着，等收到 ACK 或攒够一个 MSS 再发——减少网络上的小包。

延迟 ACK：接收方不立刻回 ACK，等一会儿（通常 40ms）看能不能捎带数据。

两个”好人”凑一起就出事：发送方等 ACK 才发，接收方等数据才回 ACK，互相等，平白多出 40ms 延迟。

socket.setTcpNoDelay(true);   // 关闭 Nagle，实时性要求高的场景必开

游戏、IM、RPC 一般开 TCP_NODELAY；大文件传输可以保留 Nagle。

心跳：TCP keepalive 还是应用层心跳

生产环境用应用层心跳，TCP keepalive 只作为兜底。

9.4 HTTP 的演进：三次队头阻塞

HTTP/1.0 → 1.1

队头阻塞：同一个连接上，前一个请求没响应完，后面的请求只能排队。

浏览器只能给同一域名开 6 个左右连接，于是大家发明了域名分片、雪碧图、资源合并——全是为了绕开这个问题。

HTTP/2

但 HTTP/2 没解决 TCP 层的队头阻塞：所有 Stream 共用一条 TCP 连接，一旦丢包，TCP 要等重传，所有 Stream 一起卡住。这就是”第二次队头阻塞”。

HTTP/3 与 QUIC

代价：UDP 在部分企业网络被限速或封禁；服务端实现复杂度高。

HTTPS / TLS

核心思路：非对称加密换钥匙，对称加密传数据。

类比：先用保险箱（公钥）把一把只有双方知道的一次性钥匙送过去，之后就用这把钥匙快速通信。非对称安全但慢，对称快但需要先共享密钥。

前向保密：私钥以后泄露了，以前抓的包也解不开——因为每次会话的密钥是临时生成的。

常见状态码

长连接、SSE、WebSocket

SSE 就是 text/event-stream，浏览器原生 EventSource 支持，AI 应用的流式输出基本都用它。

9.5 IO 模型：点外卖的五种姿势

先记住一个前提：一次网络读取分两个阶段——

1. 等数据就绪：数据从网卡 → 内核缓冲区
2. 拷贝数据：内核缓冲区 → 用户空间（你的程序）

类比：点外卖。

1. 等餐做好（数据到内核）
2. 把餐拿到手（拷贝到用户空间）

五种模型就是”等餐”和”取餐”的不同方式。

五种模型对比

⚠️ 最容易考的一句话：前四种都是同步 IO（数据拷贝阶段要自己参与），只有 AIO 是真正的异步。

select / poll / epoll

都是”IO 多路复用”的具体实现，区别在于怎么知道谁就绪了。

epoll 为什么快：

epoll_create  → 内核里建一棵红黑树 + 一个就绪链表
epoll_ctl     → 把 fd 挂到红黑树上，注册回调
epoll_wait    → 有事件时，回调把 fd 放进就绪链表，直接返回链表

类比：select/poll 是每次挨个敲门问”有人吗”；epoll 是在每家门口装了个门铃，有人回来按铃，前台只需要看铃响了几个。

LT vs ET：

类比：LT 是”水没关就一直报警”；ET 是”水位第一次超过线时响一次”。ET 性能更好，但必须配合非阻塞 IO 循环读干净。

Java 三种 IO

9.6 零拷贝：少搬几次家

普通 read() + write() 有多浪费

磁盘/网卡 → 内核缓冲区 → 用户缓冲区 → socket 缓冲区 → 网卡
              ①DMA          ②CPU          ③CPU        ④DMA

一次文件传输：4 次拷贝 + 4 次上下文切换，其中 2 次 CPU 拷贝完全没必要——数据只是路过用户空间。

类比：你要把仓库 A 的货搬到仓库 B，规定必须先搬到你家客厅再搬过去。零拷贝就是把这条规定取消。

三种优化

// Java 里的零拷贝
FileChannel in = new FileInputStream("a.txt").getChannel();
SocketChannel out = SocketChannel.open(addr);
in.transferTo(0, in.size(), out);   // 底层走 sendfile

注意：零拷贝不是”不拷贝”，而是不经过用户空间。DMA 拷贝和必要的协议头处理仍然存在。

Netty 的”零拷贝”

Netty 说的零拷贝是另一层意思：减少 JVM 堆内/堆外的数据复制。

9.7 Reactor 与 Netty

Reactor 三种模式

Netty 用的是主从 Reactor：bossGroup 接收连接，workerGroup 处理读写。

Netty 核心组件

Netty 为什么快

1. 主从 Reactor + 多路复用：少量线程扛大量连接
2. 池化 ByteBuf：减少 GC 和内存分配
3. 堆外内存：减少一次复制
4. 无锁串行化：一个 Channel 的所有事件都在同一个 EventLoop 线程里处理，天然无并发竞争
5. 零拷贝：CompositeByteBuf、slice、FileRegion
6. 可调背压：写缓冲高水位线（WRITE_BUFFER_WATER_MARK）自动切换 autoRead，防止内存被打爆

ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup)
 .channel(NioServerSocketChannel.class)
 .childHandler(new ChannelInitializer<SocketChannel>() {
     protected void initChannel(SocketChannel ch) {
         ch.pipeline()
           .addLast(new LengthFieldBasedFrameDecoder(1024 * 1024, 0, 4, 0, 4))
           .addLast(new StringDecoder())
           .addLast(new BusinessHandler());
     }
 });

关键设计：一个连接的全部 IO 事件由同一个 EventLoop 线程串行处理，业务 Handler 里不要做阻塞操作（数据库、HTTP 调用），否则会卡住这个线程上的所有连接。耗时逻辑扔到业务线程池。

2026 年的新选择：虚拟线程

Netty 的复杂度来自”用少量线程扛大量连接”。JDK 21 的虚拟线程改变了这个前提：

// 每个请求一个虚拟线程，代码是阻塞写法
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    server.handle((req, res) -> executor.submit(() -> {
        var data = jdbc.query(sql);   // 阻塞调用，但会释放载体线程
        res.write(data);
    }));
}

结论：新项目如果不是网关/推送这类超高连接数场景，虚拟线程 + 阻塞式代码往往是更划算的选择。Netty 仍然不可替代（协议定制、极致性能、海量长连接）。

9.8 线上排错手册

问题一：连接超时 vs 读超时

排查顺序：先确认是哪一种超时，别一上来就调大超时时间——那只是把问题藏起来。

问题二：端口耗尽

# 报错：Cannot assign requested address
ss -s                      # 看 timewait 数量
ss -tan state time-wait | wc -l
cat /proc/sys/net/ipv4/ip_local_port_range   # 默认 32768 60999，约 2.8 万个

• 短连接 + 高 QPS → 本地端口被 TIME_WAIT 占满
• 解决：用连接池/长连接、tcp_tw_reuse=1、扩大端口范围

问题三：文件句柄耗尽

ulimit -n                  # 进程可打开的文件数
lsof -p <pid> | wc -l      # 当前打开数
cat /proc/<pid>/limits

报错通常是 Too many open files。每个 socket 都是一个 fd，连接数 + 文件数 + 管道都要算进去。

问题四：accept 队列溢出

netstat -s | grep -i listen        # "listen queue of a socket overflowed"
ss -lnt                             # Send-Q 列是 backlog
cat /proc/sys/net/core/somaxconn

• 应用 accept 太慢（比如在 accept 线程里做业务）
• backlog 太小
• 解决：加大 somaxconn、把业务处理移出 accept 线程

抓包三板斧

tcpdump -i eth0 -nn port 8080 -w /tmp/cap.pcap   # 抓包
tcpdump -i eth0 -nn -A port 8080                  # 直接看内容
# 用 Wireshark 分析：看三次握手、重传、RST、窗口大小

常用内核参数

# /etc/sysctl.conf
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 10240 65000
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_fin_timeout = 30

9.9 面试速查

到这里，Java 面试笔记的骨架就补齐了：基础 → 集合 → 多线程 → JVM → Redis → MySQL → Spring → 微服务 → MQ → 网络与 IO。