07-计算机网络

TCP 和 UDP 的区别是什么？

原始问法：

• TCP和UDP的区别是什么？

来源题目：SRC-07-71-297

面试先答

TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Datagram Protocol，用户数据报协议）是 TCP/IP 协议栈传输层的两个核心协议，核心区别在于面向连接 vs 无连接、可靠 vs 不可靠、字节流 vs 数据报。TCP 面向连接，通信前需要三次握手建立连接，提供确认重传、流量控制、拥塞控制、字节流有序传输，保证数据可靠到达；UDP 无连接，直接发送数据报，不保证可靠性、不保证顺序、不进行流量控制，开销极小、延迟低。适用场景上，TCP 适合文件传输、网页浏览、数据库连接等可靠性要求高的场景；UDP 适合实时音视频、DNS 查询、游戏等对延迟敏感、可容忍少量丢包的场景。

核心结论

• TCP 面向连接、可靠传输、字节流；UDP 无连接、不可靠、数据报。
• TCP 提供确认重传、流量控制、拥塞控制、顺序保证；UDP 均不提供。
• TCP 头部最小 20 字节；UDP 头部固定 8 字节，开销更小。

1. 是什么

TCP 和 UDP 都属于 TCP/IP 协议栈中的传输层协议（对应 OSI 模型第 4 层），负责端到端的数据传输。TCP 由 IETF RFC 793 定义，UDP 由 RFC 768 定义。

2. 为什么需要它

网络传输存在丢包、延迟、乱序等问题。TCP 通过复杂机制保证可靠性，代价是较高的延迟和资源开销；UDP 追求简单高效，把可靠性保障留给应用层，适合实时性要求高的场景。

3. 底层原理与完整流程

TCP 可靠传输核心机制：

• 序列号（Sequence Number）：每个字节编号，接收方按序重组。
• 确认号（Acknowledgment Number）：接收方告诉发送方已收到的字节。
• 超时重传：发送方发送报文段后启动定时器，超时未收到确认则重传。
• 滑动窗口：接收方通告窗口大小，发送方据此控制发送速率。
• 拥塞控制：慢启动、拥塞避免、快速重传、快速恢复。

UDP 无上述机制，仅添加 8 字节头部（源端口、目标端口、长度、校验和），直接封装 IP 数据包发送。

4. 怎么使用

// Java 使用 TCP（Socket）
Socket socket = new Socket("example.com", 80);
OutputStream out = socket.getOutputStream();
out.write("Hello".getBytes());
InputStream in = socket.getInputStream();
byte[] buffer = new byte[1024];
int len = in.read(buffer);
socket.close();

// Java 使用 UDP（DatagramSocket）
DatagramSocket datagramSocket = new DatagramSocket();
byte[] sendData = "Hello".getBytes();
DatagramPacket sendPacket = new DatagramPacket(
    sendData, sendData.length, InetAddress.getByName("example.com"), 8080
);
datagramSocket.send(sendPacket);
datagramSocket.close();

5. 适用场景

• TCP：HTTP/HTTPS、FTP、SSH、数据库连接（MySQL/Redis）、邮件协议（SMTP/POP3/IMAP）。
• UDP：DNS 查询、实时音视频（RTP）、在线游戏、QUIC（HTTP/3 底层）、广播/多播。

6. 不适用场景与替代方案

• 需要可靠性保证的场景不能用 UDP，除非应用层自行实现可靠机制（如 QUIC）。
• 实时性要求极高的场景不适合 TCP（如实时游戏音视频）。
• 替代方案：QUIC（基于 UDP 实现的可靠传输协议，兼顾可靠性与低延迟）。

7. 优缺点与技术取舍

8. 常见问题及解决方案

9. 版本差异与实现边界

• TCP 拥塞算法：默认 Reno，Linux 内核可选 CUBIC（默认）、BBR（Google 提出）。
• QUIC/HTTP3：基于 UDP 实现可靠传输，是对 UDP 的增强而非替代。
• TCP 快速打开（TFO）：Linux 3.7+ 支持，可在三次握手时携带数据。

10. 常见追问

• 如何用 tcpdump/Wireshark 抓包区分 TCP 和 UDP？（看 IP 协议号 6=TCP，17=UDP；看头部端口号）
• TCP 为什么慢启动？（避免网络过载，逐步探测可用带宽）
• UDP 如何实现可靠传输？（应用层实现：序列号+ACK+重传，如 QUIC、RTP）

11. 易错点

• 认为 UDP 不可靠就完全不能用：很多场景下可容忍少量丢包。
• 混淆"面向字节流"和"数据报"：TCP 无消息边界，UDP 保留消息边界。
• 认为 TCP 一定比 UDP 快：在弱网环境下 UDP 可能更快（无重传等待）。

一句话总结

TCP 是面向连接的可靠字节流传输协议，UDP 是无连接的尽力而为数据报协议，二者在传输层互为补充，分别适用于可靠性优先和实时性优先的场景。

TCP 是如何保证可靠传输的？

原始问法：

• TCP是如何保证可靠传输的？

来源题目：SRC-07-71-298

面试先答

TCP 通过六大核心机制保证可靠传输：1）序列号机制，每个字节分配序列号，接收方按序重组数据，检测重复和丢失；2）确认应答机制，接收方收到数据后回复 ACK，告知期望的下一个序列号；3）超时重传机制，发送方发送后启动定时器，超时未收到 ACK 则重传；4）滑动窗口机制，通过接收方通告的窗口大小控制发送速率，实现流量控制；5）拥塞控制机制，通过慢启动、拥塞避免、快速重传、快速恢复避免网络过载；6）校验和机制，检测数据完整性。

核心结论

• TCP 可靠性是多层次机制协同的结果，不是单一功能。
• 序列号+ACK 是基础，超时重传是核心保障，滑动窗口+拥塞控制是速率调节。
• 通过 tcpdump -i eth0 tcp 可以抓取 TCP 报文段观察这些机制。

1. 是什么

TCP 可靠传输是指：发送方发送的数据能够按序、完整、无重复地被接收方接收。这不是通过"保证不丢"实现的，而是通过"丢了能发现、能重传"实现的。

2. 为什么需要它

IP 层是不可靠的尽力交付服务，数据包可能丢失、乱序、重复、损坏。应用层（如 HTTP、数据库）需要可靠的数据传输，必须由传输层提供保障。

3. 底层原理与完整流程

3.1 序列号与确认应答

TCP 将数据流分割为字节，每个字节有唯一序列号。建立连接时双方协商初始序列号（ISN）。

发送方 → 接收方：  SEQ=1001, DATA=[字节1001-1020]
接收方 → 发送方：  ACK=1021（期望接收的下一个字节序号）

3.2 超时重传（RTO）

发送方为每个发送的报文段启动重传定时器（RTO, Retransmission Timeout）。若在 RTO 内未收到 ACK，则重传该报文段。

RTO 计算基于往返时间（RTT）的加权移动平均（Jacobson/Karels 算法）：

SRTT = α * SRTT + (1-α) * RTT   (α = 0.125)
RTTVAR = β * RTTVAR + (1-β) * |RTT - SRTT|  (β = 0.25)
RTO = SRTT + 4 * RTTVAR

3.3 滑动窗口

接收方在 ACK 中通告窗口大小（rwnd），发送方在任何时刻最多发送 rwnd 字节而无需等待 ACK。窗口内的数据按序确认，窗口随 ACK 滑动。

3.4 拥塞控制

• 慢启动：cwnd 指数增长，直至达到 ssthresh 阈值。
• 拥塞避免：cwnd 线性增长（每个 RTT 增加 1 MSS）。
• 快速重传：连续 3 个重复 ACK，重传丢失报文段，ssthresh 减半，cwnd 设为 ssthresh，进入快速恢复。
• 快速恢复：cwnd 线性增长，收到新的 ACK 后回到拥塞避免。

4. 怎么使用

# 用 tcpdump 抓取 TCP 报文段，观察序列号和确认号
tcpdump -i eth0 tcp port 80 -nn

# 示例输出
# 10:00:00.123 IP src.54321 > dst.80: Flags [S], seq 1001, win 65535, length 0
# 10:00:00.124 IP dst.80 > src.54321: Flags [S.], seq 2001, ack 1002, win 65535
# 10:00:00.125 IP src.54321 > dst.80: Flags [.], ack 2002, win 502, length 0
# 10:00:00.126 IP src.54321 > dst.80: Flags [P.], seq 1002:1022, ack 2002, win 502, length 20

在 Wireshark 中打开 tcpdump 抓包文件，可以通过「Statistics → Flow Graph」观察 TCP 数据流，通过「Follow TCP Stream」查看重组后的数据流。

5. 适用场景

所有需要可靠数据传输的应用层协议：HTTP/HTTPS、FTP、SMTP、IMAP、MySQL、Redis 等。

6. 不适用场景与替代方案

• 实时音视频、在线游戏等对延迟敏感的场景，UDP + 应用层重传更适合。
• 极端网络环境（如卫星通信），TCP 的拥塞控制可能过于保守，可使用 TCP 代理或 QUIC。

7. 优缺点与技术取舍

优点：保证数据可靠、有序传输，自动适配网络状况。 缺点：机制复杂、延迟较高、在弱网下性能差（重传等待可能导致卡顿）。

8. 常见问题及解决方案

9. 版本差异与实现边界

• TCP 拥塞控制算法：Linux 2.6 起默认 CUBIC；Linux 4.9+ 可选 BBR。
• TCP 快速打开（TFO）：允许在 SYN 报文段中携带数据，需双方支持。
• TCP Keepalive：默认 2 小时空闲后发送探测报文，可通过 SO_KEEPALIVE 设置。

10. 常见追问

• 为什么 ACK 是期望的下一个序列号而不是已确认的序列号？（节省 1 字节，且能确认所有序号之前的字节都已收到）
• 什么是 Nagle 算法？（合并小报文段，减少网络小包数量）
• TCP 的状态机有哪些状态？（LISTEN、SYN-SENT、SYN-RECEIVED、ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、CLOSING、LAST-ACK、TIME-WAIT、CLOSE）

11. 易错点

• 认为 TCP 保证不丢包：TCP 保证的是"丢了能检测和恢复"，不保证物理传输不丢。
• 混淆流量控制和拥塞控制：流量控制是接收方限速，拥塞控制是网络限速。
• 认为 TCP 确认是逐字节确认：实际上 TCP 通过累积确认（ACK N 表示 N 之前所有字节都已收到）。

一句话总结

TCP 通过序列号+ACK实现有序检测、超时重传实现丢包恢复、滑动窗口+拥塞控制实现速率调节，三大机制协同保证端到端可靠传输。

TCP 三次握手的过程是什么？为什么不是两次？四次挥手的过程是什么？为什么需要四次挥手？

原始问法：

• TCP三次握手的过程是什么？为什么不是两次？
• TCP四次挥手的过程是什么？为什么需要四次挥手？

来源题目：SRC-07-71-300, SRC-07-71-300

面试先答

TCP 三次握手是建立连接的过程：客户端发送 SYN 报文段（seq=x）→ 服务端回复 SYN+ACK（seq=y, ack=x+1）→ 客户端再发 ACK（ack=y+1），连接建立完成。需要三次是因为：1）确认双方的发送和接收能力都正常；2）协商初始序列号（ISN）；3）防止已失效的连接请求到达服务端。两次握手无法确认客户端的接收能力，也无法处理历史重复连接。

TCP 四次挥手是断开连接的过程：客户端 FIN（seq=u）→ 服务端 ACK（ack=u+1）→ 服务端 FIN（seq=v）→ 客户端 ACK（ack=v+1）。需要四次是因为 TCP 是全双工的，客户端关闭发送方向后服务端可能还有数据要发送，所以服务端的 ACK 和 FIN 分两次发送。

核心结论

• 三次握手：确认双方收发能力、协商 ISN、防止历史连接。
• 四次挥手：TCP 全双工，关闭连接需要双向分别 FIN+ACK。
• 可用 tcpdump/Wireshark 抓包验证握手挥手过程。

1. 是什么

TCP 连接管理分为三个阶段：建立连接（三次握手）、数据传输、断开连接（四次挥手）。这些过程由 TCP 状态机驱动，涉及 SYN、FIN、ACK、RST 等标志位。

2. 为什么需要它

网络环境不可靠，需要确保双方通信能力正常后再传输数据。同时需要协商初始序列号，保证后续数据传输的有序性。

3. 底层原理与完整流程

3.1 三次握手（建立连接）

客户端                                  服务端
  |-------- SYN --------->|              ① 客户端发送 SYN，seq=x
  |                         (SYN_SENT)
  |<------- SYN+ACK ------|              ② 服务端回复 SYN+ACK，seq=y, ack=x+1
  |                         (SYN_RECEIVED → ESTABLISHED)
  |-------- ACK --------->|              ③ 客户端发送 ACK，ack=y+1
  |   (ESTABLISHED)        (ESTABLISHED)  连接建立完成

为什么不是两次？

1. 确认双方能力：两次握手只能确认服务端的收发能力，无法确认客户端是否能收到服务端的消息。
2. 协商 ISN：双方需要交换初始序列号，三次握手才能完成双向协商。
3. 防止历史重复连接：如果网络中残留了一个已失效的 SYN 报文段到达服务端，两次握手会让服务端错误地建立一个新连接；三次握手中客户端不会发送最后一个 ACK，服务端就不会建立连接。

3.2 四次挥手（断开连接）

客户端                                  服务端
  |-------- FIN --------->|              ① 客户端发送 FIN，seq=u
  |   (FIN_WAIT_1)                    (CLOSE_WAIT)
  |<------- ACK ----------|              ② 服务端回复 ACK，ack=u+1
  |   (FIN_WAIT_2)                    （服务端可能继续发送数据）
  |<------- FIN ----------|              ③ 服务端发送 FIN，seq=v
  |                                   (LAST_ACK)
  |-------- ACK --------->|              ④ 客户端发送 ACK，ack=v+1
  |   (TIME_WAIT)                     服务端关闭
  | 等待 2MSL 后关闭

为什么需要四次？

TCP 是全双工的：

• 客户端 FIN 仅表示客户端不再发送数据（关闭客户端→服务端方向）。
• 服务端可能还有数据要发送，所以先回复 ACK，等数据发完再发 FIN。
• 因此需要四次挥手才能完全关闭双向连接。

4. 怎么使用

# 用 tcpdump 抓取握手和挥手报文段
tcpdump -i eth0 host 192.168.1.100 and port 80 -nn

# 在 Wireshark 中，使用过滤条件：
# tcp.flags.syn == 1       查看 SYN 报文段
# tcp.flags.fin == 1       查看 FIN 报文段
# tcp.flags.reset == 1     查看 RST 报文段
# 用 Follow TCP Stream 重组连接

5. 适用场景

所有基于 TCP 的应用层协议在通信开始和结束时自动执行，无需应用层干预。

6. 不适用场景与替代方案

• UDP 无握手挥手过程，直接发送。
• QUIC 将传输层握手和 TLS 握手合并，减少握手 RTT。

7. 优缺点与技术取舍

三次握手优点：可靠确认双方能力、协商参数。缺点：增加了连接建立延迟（至少 1 RTT）。 四次挥手优点：支持半关闭（shutdown），灵活控制。缺点：延长了断开连接的时间。

8. 常见问题及解决方案

9. 版本差异与实现边界

• TCP 快速打开（TFO）：允许在 SYN 中携带数据，三次握手变为两次 RTT。
• Linux tcp_syncookies：内核参数控制是否启用 SYN Cookie 防御。
• Nginx tcp_nopush：关闭 Nagle 算法以减少延迟。

10. 常见追问

• 什么是 SYN Cookie？（一种防御 SYN 洪水攻击的机制，使用 Cookie 代替分配连接资源）
• 为什么不用两次挥手？（因为 TCP 全双工，需要分别关闭两个方向）
• shutdown(sock, SHUT_WR) 做了什么？（仅关闭写方向，发送 FIN，但仍可接收数据）

11. 易错点

• 把三次握手当成"确认三次"：实际上是两次传输 + 一次确认。
• 忘记 ACK 也消耗序列号：FIN/ACK 报文段的 ACK 部分不消耗序列号，但 SYN 和 FIN 消耗。
• 认为四次挥手的 ACK 和 FIN 必须分开：当服务端无数据发送时可以合并为三次。

一句话总结

三次握手通过双向确认和 ISN 协商建立可靠连接，四次挥手因 TCP 全双工特性需要分别关闭双向数据流。

TIME_WAIT 状态为什么要等 2MSL？

原始问法：

• TIME_WAIT状态为什么要等2MSL？

来源题目：SRC-07-71-301

面试先答

TIME_WAIT 是 TCP 四次挥手后主动关闭一方进入的状态，持续时间为 2MSL（Maximum Segment Lifetime，最大报文段生存时间，通常 1-2 分钟）。等待 2MSL 的原因有三：1）确保最后一个 ACK 能到达对方——如果 ACK 丢失，对方会重传 FIN，TIME_WAIT 期间可以重发 ACK；2）让网络中残留的报文段自然消亡——防止新连接收到旧连接的延迟报文；3）保证可靠关闭——双方都有足够时间完成最后一步的确认。2MSL 是一个报文段从一端传到另一端的最大时间，来回需要 2MSL。

核心结论

• 2MSL = 两倍最大报文段生存时间，是报文段在网络中往返一次的最长时间。
• TIME_WAIT 是主动关闭方的状态，确保最后 ACK 不丢失。
• 2MSL 后连接自动关闭，进入 CLOSED 状态。

1. 是什么

TIME_WAIT 是 TCP 状态机中的一个状态。当主动关闭方（通常是客户端）发送最后一个 ACK 后进入此状态，等待 2MSL 时间后才完全关闭连接。MSL 由 RFC 793 定义为 2 分钟，Linux 默认 60 秒。

2. 为什么需要它

网络不可靠，最后一个 ACK 可能丢失。如果 ACK 丢失，被动关闭方会重传 FIN。主动关闭方在 TIME_WAIT 期间可以收到重传的 FIN 并重新发送 ACK。如果没有 TIME_WAIT，被动关闭方永远收不到确认，无法正常关闭。

3. 底层原理与完整流程

主动关闭方                            被动关闭方
  |-------- FIN --------->|
  |<------- ACK ----------|
  |<------- FIN ----------|
  |-------- ACK --------->|
  |   (TIME_WAIT)        |
  |   等待 2MSL           | ← 如果 ACK 丢失，对端重传 FIN
  |                     →|   （TCP 内核会重发 ACK）
  |   超时后 CLOSED

MSL 的定义：一个报文段从源端到目的端的最大生存时间，由 IP 层的 TTL（Time To Live）字段限制。典型值 60 秒 ~ 2 分钟。

4. 怎么使用

# 查看当前系统 MSL 设置
cat /proc/sys/net/ipv4/tcp_fin_timeout

# 调整 TIME_WAIT 超时时间（秒）
# 注意：此参数实际控制 FIN-WAIT-2 超时，不是直接控制 TIME_WAIT
# 真正的 TIME_WAIT 时间 = tcp_fin_timeout * 2（近似）
sysctl -w net.ipv4.tcp_fin_timeout=30

# 查看当前 TIME_WAIT 连接数
ss -s
# 或
netstat -an | grep TIME_WAIT

# 快速复用 TIME_WAIT 连接（需要开启 tcp_tw_reuse）
sysctl -w net.ipv4.tcp_tw_reuse=1

5. 适用场景

TIME_WAIT 是 TCP 协议的强制行为，对所有主动关闭的连接都生效。对于高并发短连接场景（如 HTTP/1.0），大量 TIME_WAIT 会占用端口资源。

6. 不适用场景与替代方案

• 短连接场景：大量 TIME_WAIT 占用端口，可通过长连接（HTTP/1.1 Keep-Alive）减少。
• 服务端主动关闭场景：会产生大量 TIME_WAIT，可通过 tcp_tw_reuse 或调整参数缓解。

7. 优缺点与技术取舍

优点：保证最后 ACK 可靠到达，防止旧报文干扰新连接。 缺点：占用端口资源，在高并发短连接下可能导致端口耗尽。

8. 常见问题及解决方案

9. 版本差异与实现边界

• Linux 默认 tcp_fin_timeout=60，即 TIME_WAIT 约 60 秒。
• tcp_tw_reuse：允许在 TIME_WAIT 状态下复用端口，适用于客户端主动连接场景。
• tcp_tw_recycle：更激进的复用策略（NAT 环境下可能出问题，已在内核中废弃）。
• SO_LINGER：应用层可设置 Linger 选项控制关闭行为。

10. 常见追问

• tcp_tw_reuse 和 tcp_tw_recycle 的区别？（reuse 更安全，基于时间戳；recycle 更激进，NAT 环境下不可用）
• 如果双方同时主动关闭会怎样？（双方都进入 TIME_WAIT，称为 "同时挥手"，持续 2MSL 后双方都关闭）
• MSL 和 TTL 的关系？（MSL 是 TCP 层概念，TTL 是 IP 层概念，MSL 可由 TTL 推算但不同）

11. 易错点

• 把 2MSL 误认为"两个 MSL 各等一次"：2MSL 是一个报文段往返的最大时间。
• 认为 TIME_WAIT 可以完全关闭：Linux 下 tcp_tw_reuse 开启后可复用处于 TIME_WAIT 的端口。
• 混淆 FIN_WAIT_2 和 TIME_WAIT：FIN_WAIT_2 等待对端 FIN，TIME_WAIT 是收到 FIN 后等待 2MSL。

一句话总结

TIME_WAIT 等待 2MSL 是为了确保最后 ACK 可靠到达和网络残留报文自然消亡，是 TCP 可靠性的最后一道防线。

TCP 拥塞控制的流程是什么？

原始问法：

• TCP拥塞控制的流程是什么？

来源题目：SRC-07-71-302

面试先答

TCP 拥塞控制通过四个核心阶段动态调整发送速率：1）慢启动：cwnd（拥塞窗口）从 1 MSS 开始指数增长，直到达到 ssthresh（慢启动阈值，默认 65535 字节）；2）拥塞避免：cwnd 线性增长（每个 RTT 增加 1 MSS）；3）快速重传：收到 3 个重复 ACK 时，ssthresh 减半，cwnd 设为 ssthresh，重传丢失报文段，进入快速恢复；4）快速恢复：cwnd 线性增长，收到新的 ACK 后回到拥塞避免。超时则更激进：ssthresh 和 cwnd 都重置为 1 MSS，重新慢启动。

核心结论

• 拥塞控制是发送方主动降低速率以避免网络过载的机制。
• cwnd 与接收方通告的 rwnd 共同决定发送窗口：Min(cwnd, rwnd)。
• 现代 Linux 默认使用 CUBIC 算法，Google 提出 BBR 作为替代方案。

1. 是什么

拥塞控制（Congestion Control）是 TCP 层的一套自适应机制，用于在网络出现拥塞时自动降低发送速率，在网络恢复后逐步提高速率。核心参数包括：

• cwnd（Congestion Window）：拥塞窗口，发送方基于网络状况维护。
• rwnd（Receiver Window）：接收窗口，由接收方通告。
• ssthresh（Slow Start Threshold）：慢启动阈值，区分慢启动和拥塞避免。

2. 为什么需要它

网络是共享资源，如果所有 TCP 连接都尽可能快地发送，会导致路由器缓冲区溢出、丢包，进一步触发重传，形成"拥塞崩溃"（Congestion Collapse）。拥塞控制让 TCP 连接主动探测网络容量，公平共享带宽。

3. 底层原理与完整流程

拥塞控制状态转移图：

                    丢包（超时）
    ┌──────────────────────────────────┐
    │                                  │
    ▼                                  │
 慢启动 ──(cwnd ≥ ssthresh)──▶ 拥塞避免 │
    │                              │  │
    │                              │  │ 连续3个重复ACK
    │                              │  ▼
    │                        快速重传 │
    │                              │
    │                              ▼
    │                         快速恢复
    │                              │
    │                              │(收到新ACK)
    │                              ▼
    │                         拥塞避免
    │
    └──────────────────────────────────┘

慢启动阶段：

cwnd = 1 MSS
每收到一个 ACK：cwnd += 1
cwnd 呈指数增长：1 → 2 → 4 → 8 → ... → ssthresh

拥塞避免阶段：

cwnd += 1 / cwnd  (每收到一个 ACK)
或 cwnd += 1 MSS  (每个 RTT)
cwnd 呈线性增长

丢包处理：

• 超时：ssthresh = cwnd/2，cwnd = 1 MSS，重新慢启动。
• 3 个重复 ACK：ssthresh = cwnd/2，cwnd = ssthresh，进入快速恢复。

4. 怎么使用

# 查看当前系统支持的拥塞算法
sysctl net.ipv4.tcp_available_congestion_control

# 查看当前使用的拥塞算法
sysctl net.ipv4.tcp_congestion_control

# 切换为 BBR 算法
modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr

# 用 tcpdump 观察拥塞控制行为
tcpdump -i eth0 tcp port 80 -nn -tt

# 用 ss 查看连接的拥塞状态
ss -i
# 输出示例：cubic:(taught) rttvar=1000000cwnd=10240

5. 适用场景

所有基于 TCP 的连接都自动启用拥塞控制，无需应用层配置。在长肥管道（高带宽延迟积）场景下，可通过 BBR 获得更好的性能。

6. 不适用场景与替代方案

• 极不稳定的网络（如卫星链路）：传统拥塞控制可能过于保守。
• 实时音视频：UDP + 应用层拥塞控制（如 WebTransport）。
• 替代方案：BBR（基于模型而非丢包的拥塞控制）、CUBIC（Linux 默认）。

7. 优缺点与技术取舍

8. 常见问题及解决方案

9. 版本差异与实现边界

• Linux 2.6+：默认 CUBIC。
• Linux 4.9+：BBR 成为可选模块。
• BBR v1/v2/v3：Google 持续优化，v2 改善了公平性问题。
• 拥塞控制是 TCP 实现的一部分，不同操作系统实现略有差异。

10. 常见追问

• BBR 和 CUBIC 的核心区别？（BBR 基于模型：带宽×RTT 估计；CUBIC 基于反馈：丢包=拥塞）
• 什么是长肥管道（BDP）？（带宽延迟积大的网络，如跨洋光纤）
• 为什么慢启动叫"慢"？（初始 cwnd 只有 1 MSS，但实际呈指数增长很快）

11. 易错点

• 认为拥塞控制和流量控制是同一概念：流量控制是接收方限速，拥塞控制是网络限速。
• 认为超时一定是网络拥塞：也可能是接收方处理慢或链路中断。
• 混淆 cwnd 和 rwnd：cwnd 由发送方基于网络状况维护，rwnd 由接收方通告。

一句话总结

TCP 拥塞控制通过慢启动的指数增长探测带宽、拥塞避免的线性增长稳定速率、丢包时的快速降速恢复，实现网络带宽的自适应共享。

TCP 粘包和拆包问题是什么？如何解决？

原始问法：

• TCP粘包和拆包问题是什么？如何解决？

来源题目：SRC-07-71-303

面试先答

TCP 粘包和拆包是因为 TCP 是面向字节流的协议，没有消息边界的概念。发送方连续发送的多个报文段在接收方可能被合并为一次读取（粘包），或者一个报文段被拆分为多次读取（拆包）。解决思路是在应用层自定义消息边界，主流方案有四种：1）固定长度：每条消息固定 N 字节；2）特殊分隔符：用换行符、逗号等分隔；3）长度前缀：消息头包含消息体长度（最常用）；4）协议结构体：自定义协议头+协议体。Netty、Dubbo 等框架内置了多种编码器。

核心结论

• 粘包/拆包是 TCP 字节流特性导致的应用层问题，不是 TCP 的 Bug。
• 四种解决方案中，长度前缀法最通用、最常用。
• UDP 不存在粘包拆包问题（数据报协议天然保留消息边界）。

1. 是什么

粘包：发送方发送两个报文段 M1、M2，接收方一次读取得到 M1+M2。 拆包：发送方发送一个报文段 M1，接收方分两次读取得到 M1-a 和 M1-b。

TCP 只保证数据可靠有序到达，不保证按发送方的"消息边界"交付。TCP 接收方缓冲区的数据是连续的字节流，需要应用层自己识别消息边界。

2. 为什么需要它

TCP 字节流模型简化了传输层实现，但把消息边界的处理责任交给了应用层。如果不处理，接收方无法正确还原每条消息。

3. 底层原理与完整流程

粘包示例：

发送方：send(M1) → send(M2)
TCP 发送：[M1 的数据] [M2 的数据]  （可能合并为一个 TCP 报文段）
接收方 recv：一次读出 M1+M2 → 粘包

拆包示例：

发送方：send(M1)  // M1 大小 4KB
TCP 发送：[M1 前 2KB] [M1 后 2KB]  （分两个 TCP 报文段）
接收方 recv：
  第一次读出 M1 前 2KB → 拆包
  第二次读出 M1 后 2KB → 拆包

4. 怎么使用

方案一：固定长度

// 每条消息 100 字节，不足补零
byte[] message = new byte[100];
// 填充数据
out.write(message);

方案二：特殊分隔符

// 使用 \n 分隔（类似 HTTP/1.0、FTP）
out.write("GET / HTTP/1.0\r\n\r\n".getBytes());

方案三：长度前缀（最常用）

// 4 字节长度 + 消息体
byte[] body = "Hello".getBytes();
ByteBuffer buffer = ByteBuffer.allocate(4 + body.length);
buffer.putInt(body.length);  // 长度前缀
buffer.put(body);            // 消息体
out.write(buffer.array());

// 接收方：先读 4 字节长度，再读对应长度的消息体

方案四：Netty LengthFieldBasedFrameDecoder

// Netty 内置的长度前缀解码器
ChannelPipeline pipeline = channel.pipeline();
// 解码器：4 字节长度 + 消息体
pipeline.addLast(new LengthFieldBasedFrameDecoder(
    1024 * 1024,  // 最大帧长度
    0,             // 长度字段偏移
    4,             // 长度字段长度
    0,             // 长度字段的调整值
    4              // 跳过的字节数（长度字段本身）
));
pipeline.addLast(new StringDecoder());
pipeline.addLast(new StringEncoder());

5. 适用场景

• 固定长度：简单但浪费带宽，适合消息格式固定的场景。
• 特殊分隔符：适合文本协议（HTTP、FTP），但二进制协议不适用。
• 长度前缀：通用、高效，适合二进制协议（Dubbo、gRPC、Thrift）。
• 协议结构体：适合 RPC 框架，包含协议版本、消息类型等元信息。

6. 不适用场景与替代方案

• 需要极高灵活性的场景：自定义完整协议（如 QUIC、HTTP/2）。
• 如果改用 UDP（数据报协议），天然保留消息边界，无需处理粘包拆包。

7. 优缺点与技术取舍

8. 常见问题及解决方案

9. 版本差异与实现边界

• TCP 协议本身不提供消息边界，这是所有 TCP 实现的共同特性。
• 应用层框架（Netty、Dubbo、gRPC）提供了现成的编解码器。
• HTTP/1.x 使用分隔符，HTTP/2 使用长度前缀，QUIC 使用显式帧结构。

10. 常见追问

• HTTP/1.1 如何解决粘包？（使用 \r\n 分隔符 + Content-Length 或 chunked 传输编码）
• Dubbo 协议如何解决粘包？（魔数 + 消息头长度 + 消息体长度）
• 为什么 UDP 没有粘包？（UDP 是数据报协议，每次发送方和接收方的数据报一一对应）

11. 易错点

• 把粘包拆包当成 TCP 的 Bug：这是 TCP 字节流特性的自然结果。
• 认为粘包只发生在发送时：粘包发生在接收方的 TCP 缓冲区。
• 忽略 TCP_NODELAY 的影响：开启 TCP_NODELAY 禁用 Nagle 算法可以减少粘包概率，但不能完全避免。

一句话总结

TCP 粘包拆包源于字节流无边界特性，应用层通过固定长度、分隔符、长度前缀等方案自行定义消息边界。

HTTP 协议的工作原理是什么？

原始问法：

• HTTP协议的工作原理是什么？

来源题目：SRC-07-72-304

面试先答

HTTP（HyperText Transfer Protocol，超文本传输协议）是应用层的请求-响应协议，基于 TCP 传输。工作流程分为四步：1）建立 TCP 连接：客户端与服务端通过三次握手建立 TCP 连接（HTTP/1.1 支持复用连接）；2）发送 HTTP 请求：客户端按照 HTTP 报文格式发送请求行、请求头、请求体；3）服务端处理：服务端解析请求，执行业务逻辑，构建 HTTP 响应；4）返回 HTTP 响应：服务端发送状态行、响应头、响应体，传输完成后关闭连接或等待下一次请求。

核心结论

• HTTP 是无状态的请求-响应协议，每次请求独立处理。
• HTTP/1.x 基于 TCP 文本协议，HTTP/2 使用二进制分帧，HTTP/3 基于 QUIC。
• 可用 curl -v 或 Wireshark 抓包查看 HTTP 请求响应过程。

1. 是什么

HTTP 是万维网的数据通信基础协议，定义了客户端（浏览器、爬虫等）与服务端（Web 服务器）之间通信的格式和规则。属于 OSI 模型第七层（应用层），默认端口 80。

2. 为什么需要它

HTTP 为 Web 应用提供了统一的通信标准，使得任何客户端都能与任何 Web 服务器交互。它的通用性和简单性是 Web 生态繁荣的基础。

3. 底层原理与完整流程

客户端                              服务端 (80端口)
  |                                   |
  |--- TCP 三次握手 ----------------->|  ① 建立 TCP 连接
  |                                   |
  |--- HTTP 请求报文 ----------------->|  ② 发送请求
  |   GET /index.html HTTP/1.1        |      请求行
  |   Host: example.com               |      请求头
  |   User-Agent: Chrome/120          |
  |                                   |
  |                                   |  ③ 处理请求
  |                                   |      (路由匹配、执行业务、查询数据库等)
  |                                   |
  |<-- HTTP 响应报文 ------------------|  ④ 返回响应
  |   HTTP/1.1 200 OK                 |      状态行
  |   Content-Type: text/html         |      响应头
  |   Content-Length: 1024           |
  |                                   |      响应体
  |   <html>...</html>               |
  |                                   |
  |--- TCP 四次挥手/复用 ------------->|  ⑤ 断开或复用连接

HTTP 请求报文结构：

请求行：方法 + URL + 版本号
请求头：键值对（Host、User-Agent、Cookie 等）
空行
请求体：POST/PUT 请求的数据

HTTP 响应报文结构：

状态行：版本号 + 状态码 + 原因短语
响应头：键值对（Content-Type、Set-Cookie 等）
空行
响应体：返回的数据（HTML、JSON、文件等）

4. 怎么使用

# curl 发送 GET 请求（详细模式可查看请求响应头）
curl -v https://example.com

# curl 发送 POST 请求
curl -X POST https://api.example.com/data \
     -H "Content-Type: application/json" \
     -d '{"name": "test", "value": 123}'

# 发送带 Cookie 的请求
curl -b "session_id=abc123" https://example.com/dashboard

# 用 Wireshark 抓 HTTP 包
# 过滤条件：http.request or http.response
# 或用 tcpdump：
tcpdump -i eth0 port 80 -A

5. 适用场景

• Web 页面浏览（浏览器 → Web 服务器）。
• RESTful API 调用（微服务间通信）。
• 文件传输、表单提交、AJAX 请求。

6. 不适用场景与替代方案

• 实时双向通信场景：WebSocket 更适合。
• 高性能内部服务调用：gRPC（基于 HTTP/2 + Protobuf）更高效。
• 需要消息队列的场景：Kafka、RabbitMQ 更合适。

7. 优缺点与技术取舍

优点：简单易用、通用性强、跨平台、生态成熟。 缺点：明文传输（HTTP）、无状态、头部冗余、性能有限。

8. 常见问题及解决方案

9. 版本差异与实现边界

• HTTP/1.0：短连接、队头阻塞。
• HTTP/1.1：长连接、管线化、Host 头。
• HTTP/2：二进制分帧、多路复用、服务器推送。
• HTTP/3：基于 QUIC，解决传输层队头阻塞。

10. 常见追问

• HTTP 和 HTTPS 的区别？（见 HTTPS 题目）
• HTTP 无状态性如何解决？（Cookie、Session、Token、JWT）
• HTTP 1.1 的长连接如何工作？（Connection: keep-alive，复用同一 TCP 连接）

11. 易错点

• 把 HTTP 当成"有状态"协议：HTTP 本身无状态，状态由应用层（Session/Cookie）维护。
• 认为 HTTP/1.1 一定使用长连接：需要双方协商（Connection: keep-alive）。
• 混淆 HTTP 方法的幂等性：GET/HEAD/PUT/DELETE 幂等，POST 非幂等。

一句话总结

HTTP 是基于 TCP 的应用层请求-响应协议，通过请求-响应模式实现 Web 数据通信，是万维网的基础。

HTTP1.0、HTTP1.1、HTTP2.0 的区别是什么？HTTP 和 HTTPS 的区别是什么？WebSocket 和 HTTP 长连接的区别是什么？

原始问法：

• HTTP1.0、HTTP1.1、HTTP2.0的区别是什么？
• HTTP和HTTPS的区别是什么？
• WebSocket和HTTP长连接的区别是什么？

来源题目：SRC-07-72-305, SRC-07-72-306, SRC-07-72-312

面试先答

HTTP 三个版本的核心区别在于连接方式、传输格式、性能优化：HTTP/1.0 使用短连接，每次请求都要建立 TCP 连接，支持队头阻塞；HTTP/1.1 引入长连接和管线化，一个 TCP 连接上可以发送多个请求，但仍存在队头阻塞；HTTP/2 采用二进制分帧层，支持多路复用、头部压缩、服务器推送，大幅提升性能。

HTTP 与 HTTPS 的核心区别是安全性：HTTP 明文传输（端口 80），HTTPS 加密传输（端口 443，基于 TLS/SSL）。HTTPS 通过证书验证身份、加密通信内容、防止中间人攻击。

WebSocket 与 HTTP 长连接的区别：HTTP 长连接是请求-响应模式，客户端主动请求，服务端被动响应；WebSocket 是全双工通信，双方随时可以发送数据，通过 HTTP 升级机制（Upgrade: websocket）建立。

核心结论

• HTTP/1.0 → HTTP/1.1：长连接 + 管线化。
• HTTP/1.1 → HTTP/2：二进制分帧 + 多路复用 + 头部压缩。
• HTTP → HTTPS：TLS 加密层，端口从 80 → 443。
• HTTP 长连接：半双工、请求-响应模式；WebSocket：全双工、双向通信。

1. 是什么

• HTTP/1.0（1996，RFC 1945）：第一个广泛使用的 HTTP 版本。
• HTTP/1.1（1999，RFC 2616）：目前最广泛使用的版本。
• HTTP/2（2015，RFC 7540）：二进制分帧协议。
• HTTPS：HTTP over TLS，加密的 HTTP。
• WebSocket（RFC 6455）：基于 HTTP 的全双工通信协议。

2. 为什么需要它

• HTTP/1.0 的短连接模型导致大量 TCP 握手开销，队头阻塞严重。
• HTTP/1.1 长连接解决了握手开销，但队头阻塞依然存在。
• HTTP/2 多路复用解决了应用层队头阻塞，二进制分帧提升效率。
• HTTPS 解决了 HTTP 明文传输的安全隐患。
• WebSocket 解决了 HTTP 无法实现服务端主动推送的问题。

3. 底层原理与完整流程

HTTP/1.0 工作流：

请求1 → TCP握手 → 发送 → 响应 → TCP挥手
请求2 → TCP握手 → 发送 → 响应 → TCP挥手
（每个请求独立，无法复用连接）

HTTP/1.1 工作流：

TCP握手 → 请求1 → 响应1 → 请求2 → 响应2 → ... → TCP挥手
                                 ↑
                          管线化：请求2可在响应1之前发送
                          但响应必须按序返回，存在队头阻塞

HTTP/2 工作流：

TCP握手 → TLS握手(HTTPS) → SETTINGS帧
→ 多路复用：请求1/2/3的帧交错传输
→ HPACK头部压缩
→ 连接复用

HTTP/2 帧类型：

• HEADERS 帧：头部信息
• DATA 帧：请求/响应体
• SETTINGS 帧：连接参数协商
• PUSH_PROMISE 帧：服务器推送承诺
• WINDOW_UPDATE 帧：流量控制

4. 怎么使用

# 查看 HTTP 版本
curl -v https://example.com 2>&1 | grep "HTTP/"

# 强制使用 HTTP/2
curl --http2 -v https://example.com

# 强制使用 HTTP/1.1
curl --http1.1 -v https://example.com

# Java HttpClient 使用 HTTP/2
// Java 11+ HttpClient 默认支持 HTTP/2
HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("https://example.com"))
    .build();
HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());

# WebSocket 客户端示例
# 使用 JavaScript
const ws = new WebSocket("wss://example.com/socket");
ws.onmessage = (event) => console.log(event.data);
ws.send("Hello");

5. 适用场景

• HTTP/1.0：几乎已淘汰，仅兼容老旧系统。
• HTTP/1.1：目前主流，适用于大多数 Web 应用和 API。
• HTTP/2：适用于高并发、多路资源加载场景（现代浏览器自动协商）。
• HTTPS：所有需要安全通信的场景，现代浏览器要求 HTTPS。
• WebSocket：实时聊天、在线协作、游戏、监控面板等需要双向通信的场景。

6. 不适用场景与替代方案

• HTTP/1.x 在高并发下性能差，建议升级 HTTP/2。
• HTTP 不应在生产环境使用，必须 HTTPS。
• WebSocket 不需要双向通信时可以用 SSE（Server-Sent Events）替代。

7. 优缺点与技术取舍

8. 常见问题及解决方案

9. 版本差异与实现边界

• HTTP/1.1：几乎所有服务器和浏览器都支持。
• HTTP/2：浏览器默认开启，需服务器支持（Nginx 1.25+、Apache 2.4+）。
• HTTP/3：基于 QUIC，Chrome、Firefox、Cloudflare 已支持。
• HTTPS：TLS 1.0/1.1 已废弃，TLS 1.2/1.3 为当前主流。

10. 常见追问

• HTTP/2 多路复用为什么还会有队头阻塞？（TCP 层队头阻塞仍存在，HTTP/3 的 QUIC 解决了这个问题）
• WebSocket 连接建立过程？（HTTP 升级：GET + Upgrade: websocket + Connection: Upgrade，服务端返回 101 Switching Protocols）
• HTTPS 和 HTTP/2 的关系？（HTTP/2 可以跑在 HTTP 或 HTTPS 上，实际部署中 HTTPS + HTTP/2 最常见）

11. 易错点

• 认为 HTTP/2 完全解决了队头阻塞：只解决了应用层队头阻塞，TCP 层队头阻塞仍在。
• 混淆 HTTP 长连接和 WebSocket：长连接仍是请求-响应模式，WebSocket 是真正的双工。
• 认为 WebSocket 是 HTTP 协议：WebSocket 是独立协议，仅通过 HTTP 升级握手建立。

一句话总结

HTTP 版本演进逐步解决连接复用和队头阻塞问题，HTTPS 在 HTTP 之上增加 TLS 加密保障安全，WebSocket 则突破 HTTP 请求-响应模式实现全双工通信。

HTTPS 的握手过程是怎样的？为什么需要三个随机数？

原始问法：

• HTTPS的握手过程是怎样的？为什么需要三个随机数？

来源题目：SRC-07-72-307

面试先答

HTTPS 握手过程（以 TLS 1.2 为例）分为五步：1）客户端→服务端：ClientHello，包含 TLS 版本、加密套件列表、随机数 Client Random；2）服务端→客户端：ServerHello，选定版本、加密套件、随机数 Server Random；3）服务端→客户端：Certificate（证书链）、ServerKeyExchange（密钥交换参数）；4）客户端→服务端：ClientKeyExchange（预主密钥 Pre-Master Secret）、ChangeCipherSpec、Finished；5）服务端→客户端：ChangeCipherSpec、Finished。三个随机数（Client Random、Server Random、Pre-Master Secret）通过 PRF 算法推导出主密钥 Master Secret，确保密钥的随机性和不可预测性，防止重放攻击。

核心结论

• HTTPS 握手基于 TLS 协议，TLS 1.3 将握手从 2-RTT 降为 1-RTT。
• 三个随机数共同推导主密钥，保证密钥安全。
• 可用 openssl s_client 或 Wireshark 抓包分析 TLS 握手。

1. 是什么

HTTPS = HTTP + TLS/SSL。TLS（Transport Layer Security）是 SSL 的继任者，由 IETF 维护。TLS 握手是协商加密参数和会话密钥的过程。

2. 为什么需要它

HTTP 明文传输存在三大风险：窃听（内容被偷看）、篡改（内容被修改）、冒充（假服务端伪装）。TLS 通过加密解决窃听，通过消息认证解决篡改，通过证书认证解决冒充。

3. 底层原理与完整流程

TLS 1.2 握手流程：

客户端                                  服务端
  |--- ClientHello ----------------->|  ① 版本、加密套件、Client Random
  |                                   |
  |<-- ServerHello -------------------|  ② 选定参数、Server Random
  |<-- Certificate -------------------|  ③ 服务端证书
  |<-- ServerKeyExchange -------------|     密钥交换参数
  |<-- CertificateRequest ------------|     (可选，客户端证书)
  |<-- ServerHelloDone ---------------|
  |                                   |
  |--- Certificate ------------------->|  ④ 客户端证书(可选)
  |--- ClientKeyExchange ------------->|     Pre-Master Secret
  |--- ChangeCipherSpec ------------->|     切换到加密通信
  |--- Finished (加密) --------------->|
  |                                   |
  |<-- ChangeCipherSpec ---------------|  ⑤ 切换到加密通信
  |<-- Finished (加密) ----------------|
  |                                   |
  |==== 加密通信开始 =================|

三个随机数的作用：

1. Client Random：客户端生成的 32 字节随机数，用于防止重放攻击。
2. Server Random：服务端生成的 32 字节随机数，与 Client Random 配合。
3. Pre-Master Secret：客户端生成的 46 字节密钥，用服务端公钥加密传输。

主密钥推导：

Master Secret = PRF(Pre-Master Secret, Client Random + Server Random)

TLS 1.3 的改进：

• 握手从 2-RTT 降为 1-RTT（客户端在 ClientHello 中携带密钥）。
• 废弃了不安全的加密算法。
• 0-RTT 模式：恢复会话时实现零往返。

4. 怎么使用

# 用 openssl 测试 TLS 握手
openssl s_client -connect example.com:443 -tls1_2

# 查看 TLS 握手详细过程
openssl s_client -connect example.com:443 -brief

# 用 curl 测试 HTTPS
curl -v https://example.com

# Java HTTPS 连接
// 默认信任系统证书
URL url = new URL("https://example.com");
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
conn.setRequestMethod("GET");
InputStream is = conn.getInputStream();

# Wireshark 抓 TLS 包
# 需要配置 SSLKEYLOGFILE 才能解密
# 过滤条件：tls.handshake.type == 1 (ClientHello)

5. 适用场景

• 所有需要安全传输的 HTTP 通信（网银、电商、社交等）。
• API 接口安全通信。
• 邮件、IMAP、SMTP 的安全版本。

6. 不适用场景与替代方案

• 内网完全可信环境：HTTP 可接受但仍推荐 HTTPS。
• 对延迟极端敏感的场景：QUIC（HTTP/3）减少握手 RTT。
• 替代方案：SSH（用于远程登录）、VPN（用于网络层加密）。

7. 优缺点与技术取舍

优点：加密、认证、完整性保护。 缺点：增加握手延迟（TLS 1.2 需 2-RTT）、CPU 开销、证书管理成本。

8. 常见问题及解决方案

9. 版本差异与实现边界

• SSL 3.0：已废弃，存在 POODLE 漏洞。
• TLS 1.0/1.1：已由 RFC 8996 废弃。
• TLS 1.2：当前主流，握手机制如上。
• TLS 1.3：1-RTT 握手，0-RTT 恢复，移除不安全算法。
• TLS 1.3 仍在逐步部署中。

10. 常见追问

• TLS 1.3 为什么能减少 RTT？（客户端在 ClientHello 中预先生成密钥）
• 0-RTT 的安全风险？（重放攻击，需要应用层去重）
• 证书链验证过程？（从叶子证书到根证书逐级验证签名）

11. 易错点

• 把 SSL 和 TLS 当成不同协议：TLS 是 SSL 的继承者，名称 TLS 1.0 = SSL 3.1。
• 认为 HTTPS 完全防止中间人攻击：SSL 剥离攻击仍可能降级为 HTTP。
• 混淆对称加密和非对称加密的使用阶段：握手阶段用非对称加密交换密钥，通信阶段用对称加密。

一句话总结

HTTPS 通过 TLS 握手协商加密参数和会话密钥，三个随机数共同推导主密钥保证安全，TLS 1.3 将握手优化为 1-RTT。

HTTPS 的性能开销在哪里？

原始问法：

• HTTPS的性能开销在哪里？

来源题目：SRC-07-72-308

面试先答

HTTPS 的性能开销主要体现在四个方面：1）握手延迟：TLS 1.2 需要 2-RTT，TLS 1.3 需要 1-RTT；2）加密解密计算：非对称加密（RSA/ECC）在握手阶段计算量大，对称加密（AES）在通信阶段持续消耗 CPU；3）证书验证：客户端需要验证证书链，涉及签名校验；4）TLS 记录开销：每个数据块增加 TLS 头部和 MAC（消息认证码）。但现代硬件和 TLS 优化已大幅降低这些开销，TLS 1.3 的 1-RTT 握手和硬件加速的 AES 使 HTTPS 性能已接近 HTTP。

核心结论

• TLS 握手的 RTT 开销是最大的延迟来源。
• 非对称加密的 CPU 开销在握手阶段最显著。
• 硬件加速（AES-NI、ECC）和 TLS 1.3 大幅降低了 HTTPS 开销。

1. 是什么

HTTPS 性能开销是指 TLS/SSL 协议在提供安全保障的同时引入的额外计算和延迟。主要包括：握手阶段的密钥协商、证书验证、加解密运算、协议开销。

2. 为什么需要它

理解 HTTPS 的性能开销有助于做出正确的架构决策，如选择合适的 TLS 版本、配置会话复用、使用硬件加速等。

3. 底层原理与完整流程

3.1 握手延迟开销

TLS 1.2：2-RTT（ClientHello → ServerHello → Certificate → ClientKeyExchange → Finished） TLS 1.3：1-RTT（ClientHello → ServerHello + Certificate + Finished） TLS 会话复用：0-RTT（使用会话 ID 或会话票据）

RTT 开销示例（假设 RTT = 50ms）：

• TLS 1.2 首次握手：100ms
• TLS 1.3 首次握手：50ms
• TLS 会话复用：0-5ms

3.2 加解密计算开销

• 握手阶段：非对称加密（RSA 2048/ECC P-256），CPU 密集
  • RSA 2048 签名验证：约 0.1ms
  • ECC P-256：比 RSA 快 10-100 倍
• 通信阶段：对称加密（AES-GCM），CPU 密集但可硬件加速
  • AES-NI（CPU 指令集加速）：几乎零开销
  • 软件 AES：约 100MB/s（单核）

3.3 TLS 记录开销

每个 TLS 记录增加：

• TLS 头部：5 字节
• MAC（消息认证码）：20 字节（SHA-1）或 32 字节（SHA-256）
• 总计：25-37 字节/包

4. 怎么使用

# 测试 TLS 握手耗时
openssl s_client -connect example.com:443 -timing

# 查看服务器支持的 TLS 版本和加密套件
nmap --script ssl-enum-ciphers -p 443 example.com

# 使用 TLS 会话复用
curl -v --tlsv1.3 https://example.com

# Java 启用 TLS 1.3
System.setProperty("jdk.tls.client.protocols", "TLSv1.3");

# 启用 OCSP Stapling（减少证书验证开销）
# Nginx 配置：
# ssl_stapling on;
# ssl_stapling_verify on;

5. 适用场景

• 对延迟敏感的 API 服务：使用 TLS 1.3、会话复用。
• 高并发 Web 服务：使用硬件加速（AES-NI）、TLS 卸载（负载均衡器处理 TLS）。
• 移动端应用：优先 TLS 1.3，减少握手 RTT。

6. 不适用场景与替代方案

• 完全内网且无安全要求：HTTP 可接受但不安全。
• 对安全要求极高且延迟极端敏感：QUIC（HTTP/3）可作为替代。

7. 优缺点与技术取舍

8. 常见问题及解决方案

9. 版本差异与实现边界

• TLS 1.3：大幅优化握手流程，0-RTT 会话恢复。
• QUIC（HTTP/3）：将传输层握手和 TLS 握手合并，1-RTT 建立连接。
• 硬件加速：现代 CPU（Intel Westmere+、ARM Crypto Extensions）支持 AES-NI。

10. 常见追问

• 什么是 TLS 会话复用？（Session ID、Session Ticket 两种机制）
• OCSP Stapling 的作用？（服务端代替客户端查询 OCSP，减少延迟）
• ECC 相比 RSA 的优势？（密钥更短、计算更快、安全性相当）

11. 易错点

• 认为 HTTPS 一定比 HTTP 慢：TLS 1.3 + AES-NI 下性能差距可忽略。
• 混淆对称和非对称加密的使用阶段：握手用非对称加密密钥，通信用对称加密数据。
• 忽略证书验证开销：客户端 OCSP 查询可能成为瓶颈。

一句话总结

HTTPS 的主要性能开销在于 TLS 握手 RTT 和加解密计算，TLS 1.3、会话复用和硬件加速已大幅缩小与 HTTP 的性能差距。

什么是中间人攻击？HTTPS 如何防御？

原始问法：

• 什么是中间人攻击？HTTPS如何防御？

来源题目：SRC-07-72-309

面试先答

中间人攻击（MITM，Man-in-the-Middle Attack）是指攻击者在通信双方之间截获并篡改数据的攻击方式。有两种变体：1）被动窃听：攻击者只是偷看通信内容（HTTP 明文传输易受此攻击）；2）主动篡改：攻击者修改转发的数据（如 SSL 剥离攻击）。

HTTPS 通过三重防御机制对抗中间人攻击：1）证书认证：客户端验证服务端证书是否由受信任 CA 签发，确保连接的是真正的服务端；2）密钥协商：通过 ECDHE 等密钥交换算法，即使私钥泄露也无法解密历史通信（前向保密）；3）消息认证：TLS 记录使用 HMAC 校验数据完整性，防止篡改。

核心结论

• 中间人攻击的核心是攻击者能冒充通信的一方。
• HTTPS 通过证书链验证确保身份真实性。
• 即使使用 HTTPS，仍可能遭受 SSL 剥离等降级攻击。

1. 是什么

中间人攻击是一种攻击模型，攻击者位于通信双方之间，可以窃听、修改、伪造通信内容。分为：

• IP 欺骗：伪造 IP 地址。
• ARP 欺骗：在局域网中劫持通信。
• SSL 剥离：将 HTTPS 降级为 HTTP。
• HTTPS 劫持：使用自签名证书冒充合法站点。

2. 为什么需要它

HTTP 明文传输，攻击者可以轻松窃听和篡改。HTTPS 通过加密和认证机制提供安全保障。

3. 底层原理与完整流程

HTTP 下的中间人攻击：

客户端 ←→ 攻击者 ←→ 服务端
              ↑
         窃听/篡改所有数据

HTTPS 防御流程：

客户端                        攻击者                     服务端
  |--- ClientHello ----------->|                          |
  |                           |--- ClientHello --------->|
  |                           |                          |
  |<-- ServerHello+Cert -------|<-- ServerHello+Cert -----|
  |    (攻击者的假证书)         |   (真正的证书)            |
  |                           |                          |
  | 客户端验证证书：            |                          |
  | 发现证书不是由受信CA签发    |                          |
  | → 拒绝连接 ✓               |                          |

关键防御机制：

1. 证书链验证：

   • 浏览器内置受信任根 CA 列表。
   • 验证服务端证书的签名链是否有效。
   • 检查证书域名是否匹配访问的域名。
   • 检查证书是否在有效期内。
   • 检查证书是否已吊销（OCSP/CRL）。

2. 前向保密（Forward Secrecy）：

   • TLS 使用 ECDHE 密钥交换。
   • 即使服务端私钥被泄露，历史通信仍无法解密。
   • 每次握手生成新的会话密钥。

3. HSTS（HTTP Strict Transport Security）：

   • 服务端通过响应头 Strict-Transport-Security 告诉浏览器始终使用 HTTPS。
   • 防止 SSL 剥离攻击。
   • 浏览器在收到 HSTS 头后，一段时间内自动升级 HTTP 请求为 HTTPS。

4. 怎么使用

# 检查证书链
openssl s_client -connect example.com:443 -verifyCAfile ca-bundle.crt

# 查看证书详情
openssl x509 -in cert.pem -text -noout

# 检查 HSTS 是否启用
curl -I https://example.com | grep -i strict

# Java 信任管理
KeyStore trustStore = KeyStore.getInstance("JKS");
trustStore.load(new FileInputStream("truststore.jks"), "password".toCharArray());
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(null, new TrustManager[]{new X509TrustManager(trustStore)}, null);

5. 适用场景

所有 HTTPS 通信都自动防御中间人攻击。HSTS 需要服务端显式开启。

6. 不适用场景与替代方案

• 证书本身可能被钓鱼：用户点击"继续前往"绕过警告。
• 企业内网 MITM：企业可能用自签名证书解密 HTTPS 流量（需在客户端安装证书）。
• 替代方案：证书透明度（Certificate Transparency）检测恶意证书。

7. 优缺点与技术取舍

HTTPS 防御完善但依赖证书体系，证书颁发机构的信任链是根本假设。HSTS 有效但首次连接仍可能被降级。

8. 常见问题及解决方案

9. 版本差异与实现边界

• TLS 1.3：默认启用前向保密，移除 RSA 密钥交换。
• HSTS：Chrome 44+ 支持，max-age 建议至少 6 个月。
• 证书透明度：Chrome、Safari 已强制要求。

10. 常见追问

• SSL 剥离攻击如何防御？（HSTS + HTTP 重定向到 HTTPS + HSTS preload 列表）
• 证书吊销列表（CRL）和在线证书状态协议（OCSP）的区别？
• 什么是 HSTS preload 列表？（浏览器内置的强制 HTTPS 域名列表）

11. 易错点

• 认为 HTTPS 完全防止中间人攻击：如果用户接受了不受信任的证书，HTTPS 就被攻破。
• 混淆"加密"和"认证"：加密防止窃听，认证防止冒充。
• 忽略 HSTS 的作用：首次 HTTP 请求仍可能被降级攻击。

一句话总结

中间人攻击是在通信双方之间截获篡改数据，HTTPS 通过证书认证确保身份真实、密钥协商保证前向保密、消息认证防止篡改来防御此类攻击。

HTTP3 和 QUIC 了解吗？

原始问法：

• HTTP3和QUIC了解吗？

来源题目：SRC-07-72-310

面试先答

HTTP/3 是 HTTP 的最新版本，底层基于 QUIC 协议而非 TCP。QUIC（Quick UDP Internet Connections）是 Google 提出的基于 UDP 的可靠传输协议，核心优势在于：1）连接建立更快：将传输层握手和 TLS 握手合并为 1-RTT（传统 TCP + TLS 需要 2-RTT），0-RTT 恢复会话；2）无队头阻塞：基于 UDP 实现，解决了 TCP 层的队头阻塞问题；3）多路复用：原生支持多路复用，每条流独立可靠传输；4）连接迁移：基于 Connection ID 而非四元组，支持网络切换（WiFi→4G）。HTTP/3 保留了 HTTP/2 的多路复用、头部压缩等特性，但将传输层从 TCP 换为 QUIC。

核心结论

• HTTP/3 = HTTP 语义 + QUIC 传输层。
• QUIC 基于 UDP，实现了可靠传输、加密、多路复用。
• HTTP/3 解决了 TCP 层队头阻塞，延迟显著降低。

1. 是什么

• QUIC：基于 UDP 的可靠传输协议，由 Google 设计，IETF 正在标准化。
• HTTP/3：使用 QUIC 作为底层传输协议的 HTTP 版本，由 IETF 制定。

2. 为什么需要它

TCP 在设计时未考虑现代网络场景（移动网络、高延迟网络、多路复用需求），存在天然缺陷：队头阻塞、握手慢、连接迁移困难。QUIC 基于 UDP 重新设计传输层，解决了这些问题。

3. 底层原理与完整流程

HTTP/2 vs HTTP/3 协议栈对比：

HTTP/2 协议栈：
┌─────────────────────┐
│     HTTP/2          │  应用层
├─────────────────────┤
│   TLS 1.2/1.3       │  加密层
├─────────────────────┤
│      TCP             │  传输层（存在队头阻塞）
├─────────────────────┤
│       IP             │  网络层
└─────────────────────┘

HTTP/3 协议栈：
┌─────────────────────┐
│     HTTP/3          │  应用层
├─────────────────────┤
│   QUIC (含 TLS 1.3)  │  传输层（无队头阻塞）
├─────────────────────┤
│       UDP            │  基础传输
├─────────────────────┤
│       IP             │  网络层
└─────────────────────┘

QUIC 连接建立过程：

客户端                                  服务端
  |--- Initial (含 TLS 1.3 Hello) ----->|  ① 1-RTT 建立连接
  |<-- Initial (含 TLS 1.3 Hello) ------|
  |--- Handshake Done ----------------->|
  |<-- Handshake Done ------------------|
  |                                   |
  |==== 0-RTT 恢复会话 =================|  （使用之前的会话票据）
  |--- 0-RTT Data -------------------->|

QUIC 核心特性：

• Stream 级别的可靠传输，一个 Stream 丢包不影响其他 Stream。
• 基于 Connection ID 的连接标识，支持网络切换。
• 内置 TLS 1.3 加密。
• 用户态实现（可快速迭代优化）。

4. 怎么使用

# curl 使用 HTTP/3
curl --http3 -v https://example.com

# 检查服务器是否支持 HTTP/3
curl -v https://example.com 2>&1 | grep -i "HTTP/3"
# 或通过 Alt-Svc 响应头检测

# Chrome 启用 HTTP/3
# chrome://flags 中启用 "enable-quic"

# Nginx 支持 HTTP/3 (1.25+)
# 配置：
# listen 443 quic reuseport;
# add_header Alt-Svc 'h3=":443"; ma=86400';

5. 适用场景

• 移动端 Web 应用（网络切换频繁、延迟敏感）。
• 跨洋服务（RTT 高，1-RTT 握手优势明显）。
• 实时应用（实时聊天、协作）。

6. 不适用场景与替代方案

• 企业内网可能限制 UDP 端口，影响 QUIC。
• 需要可靠有序传输且无法容忍丢包的场景（QUIC 的可靠传输需要应用层配合）。
• 替代方案：HTTP/2 over TCP 仍是当前最兼容的选择。

7. 优缺点与技术取舍

8. 常见问题及解决方案

9. 版本差异与实现边界

• HTTP/3：RFC 9114，2022 年正式发布。
• QUIC：RFC 9000，2021 年正式发布。
• 浏览器支持：Chrome、Firefox、Safari 已支持。
• 服务器支持：Nginx 1.25+、Cloudflare、Envoy。

10. 常见追问

• QUIC 和 HTTP/3 的关系？（QUIC 是传输层，HTTP/3 使用 QUIC）
• HTTP/3 仍有队头阻塞吗？（传输层无队头阻塞，但应用层仍可能有）
• 0-RTT 的安全风险？（重放攻击，需要应用层去重）

11. 易错点

• 认为 HTTP/3 解决了所有队头阻塞：只解决了传输层的。
• 混淆 QUIC 和 HTTP/3：QUIC 是通用传输层，HTTP/3 只是基于它的一个应用。
• 认为 HTTP/3 已完全替代 HTTP/2：目前 HTTP/2 仍是主流。

一句话总结

HTTP/3 基于 QUIC 协议，以 UDP 为基础实现可靠传输，解决了 TCP 队头阻塞和握手慢的问题，是下一代 Web 协议的方向。

常见的 HTTP 状态码有哪些？301/302/403 等状态码的含义？

原始问法：

• 常见的HTTP状态码有哪些？301/302/403等状态码的含义？

来源题目：SRC-07-72-311

面试先答

HTTP 状态码分为五大类：1xx 信息响应、2xx 成功响应、3xx 重定向、4xx 客户端错误、5xx 服务端错误。最常考的有：200（成功）、301（永久重定向，浏览器会缓存，下次直接访问新地址）、302（临时重定向，浏览器每次都先访问原地址）、304（资源未修改，使用缓存）、400（请求格式错误）、401（需要认证）、403（无权限访问）、404（资源不存在）、500（服务端内部错误）、502（网关错误）、503（服务不可用）、504（网关超时）。

核心结论

• 状态码首位数字定义类别：1xx-信息、2xx-成功、3xx-重定向、4xx-客户端错误、5xx-服务端错误。
• 301 永久重定向 vs 302 临时重定向的关键区别在于浏览器是否缓存。
• 304 状态码是缓存机制的核心，配合 ETag 和 Last-Modified 使用。

1. 是什么

HTTP 状态码由三位数字组成，定义在 RFC 7231 等规范中，用于表示 HTTP 响应的结果。

2. 为什么需要它

状态码让客户端能够了解请求的处理结果，做出相应的后续操作（如跳转、重试、显示错误等）。

3. 底层原理与完整流程

状态码分类与常见值：

高频状态码详解：

• 200 OK：请求成功，返回对应资源。
• 301 Moved Permanently：永久重定向，资源已分配新 URL，浏览器会缓存。
• 302 Found：临时重定向，资源临时转移，浏览器每次仍先访问原 URL。
• 304 Not Modified：资源未修改，直接使用浏览器缓存（协商缓存）。
• 400 Bad Request：请求格式错误，服务端无法解析。
• 401 Unauthorized：需要认证（未登录或 Token 无效）。
• 403 Forbidden：服务端理解请求但拒绝执行（权限不足、IP 黑名单等）。
• 404 Not Found：资源不存在或已删除。
• 500 Internal Server Error：服务端内部错误（代码异常、数据库连接失败等）。
• 502 Bad Gateway：网关/反向代理从上游收到无效响应。
• 503 Service Unavailable：服务暂时不可用（过载、维护中）。
• 504 Gateway Timeout：网关/反向代理等待上游超时。

4. 怎么使用

# curl 查看状态码
curl -I https://example.com
# 输出：HTTP/1.1 200 OK

# curl 只看状态码
curl -s -o /dev/null -w "%{http_code}" https://example.com

# Java 中处理状态码
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
int statusCode = conn.getResponseCode();
if (statusCode == HttpURLConnection.HTTP_OK) {  // 200
    // 处理成功
} else if (statusCode == HttpURLConnection.HTTP_NOT_FOUND) {  // 404
    // 处理资源不存在
}

5. 适用场景

• RESTful API 设计：正确使用状态码（200 成功、201 创建、400 错误、401 未认证、403 禁止、404 不存在）。
• Web 开发：重定向（301/302）、缓存（304）、错误处理。

6. 不适用场景与替代方案

• 自定义业务状态码：建议使用 HTTP 标准状态码 + 业务错误码响应体。
• 所有错误都返回 200：不符合 RESTful 规范，给客户端处理带来困难。

7. 优缺点与技术取舍

• 301 vs 302：301 利于 SEO 但缓存导致更改困难，302 灵活但每次都要跳转。
• 304：提升性能但可能导致缓存不一致。
• 4xx vs 5xx：4xx 表示客户端问题，5xx 表示服务端问题，准确分类有助于排查。

8. 常见问题及解决方案

9. 版本差异与实现边界

• HTTP/1.0 定义了 200、301、302、400、404、500。
• HTTP/1.1 扩展了 303、307、401、403、405、408、409、501、502、503、504。
• RFC 7231（2014）整合规范，新增 422、429 等。
• 状态码是 HTTP 规范的一部分，所有实现应遵循。

10. 常见追问

• 301 和 302 对 SEO 的影响？（301 传递权重，302 不传递）
• 307 和 302 的区别？（307 要求保持请求方法和请求体）
• 401 和 403 的区别？（401 是"未认证"，403 是"已认证但无权限"）
• 304 缓存如何工作？（协商缓存：ETag/Last-Modified → If-None-Match/If-Modified-Since）

11. 易错点

• 混淆 301 和 302 的缓存行为：301 被浏览器缓存，302 通常不缓存。
• 401 和 403 混淆：401 是身份认证问题，403 是权限问题。
• 认为 404 只表示页面不存在：API 中也常用于表示资源不存在。

一句话总结

HTTP 状态码分为五大类，正确使用状态码能让客户端准确理解服务端响应并做出正确处理。

在浏览器输入 URL 到页面加载完成的完整流程是什么？

原始问法：

• 在浏览器输入URL到页面加载完成的完整流程是什么？

来源题目：SRC-07-73-313

面试先答

浏览器输入 URL 到页面加载完成经历以下流程：1）URL 解析：浏览器解析 URL 的协议、域名、路径、端口等部分；2）DNS 解析：将域名转换为 IP 地址（缓存查询 → 根 DNS → 权威 DNS）；3）建立 TCP 连接：三次握手与服务端建立 TCP 连接（HTTPS 还需 TLS 握手）；4）发送 HTTP 请求：浏览器按照 HTTP 协议格式发送请求；5）服务端处理并返回响应：包括 HTTP 响应头和响应体；6）浏览器解析渲染：解析 HTML 构建 DOM，解析 CSS 构建 CSSOM，合并为渲染树，布局绘制；7）加载子资源：并行加载 JS、CSS、图片等，JS 可能修改 DOM。整个过程涉及 OSI 七层模型的应用层、表示层、会话层、传输层、网络层、链路层的协同工作。

核心结论

• 网络请求全流程涉及 DNS、TCP、TLS、HTTP 等多种协议。
• 浏览器渲染涉及 DOM、CSSOM、JavaScript 引擎协同。
• 可用 Chrome DevTools Network 面板或 curl/tcpdump 分析各阶段耗时。

1. 是什么

这个过程是浏览器从用户输入 URL 到页面完全展示的端到端流程，涉及浏览器、操作系统、网络、服务端的多层协作。是前端性能优化的核心关注领域。

2. 为什么需要它

理解完整流程有助于：1）排查网络问题（DNS 解析慢？TCP 连接失败？）；2）前端性能优化（减少 HTTP 请求、启用缓存、CDN 加速）；3）服务端调优（连接复用、压缩、HTTP/2）。

3. 底层原理与完整流程

用户输入 URL: https://www.example.com/page?key=value#section

┌─────────────────────────────────────────────────────────────┐
│ 阶段 1: URL 解析                                            │
│ - 协议: https                                               │
│ - 域名: www.example.com                                     │
│ - 端口: 443 (默认)                                          │
│ - 路径: /page                                               │
│ - 查询参数: key=value                                       │
│ - 锚点: #section                                            │
└─────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段 2: DNS 解析                                            │
│ 浏览器缓存 → OS 缓存 → 根 DNS → 权威 DNS                    │
│ → 获取 IP 地址（如 93.184.216.34）                          │
└─────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段 3: TCP + TLS 握手                                      │
│ TCP 三次握手 → TLS 握手（HTTPS）                            │
│ 建立安全可靠的传输通道                                       │
└─────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段 4: HTTP 请求/响应                                      │
│ 浏览器发送 HTTP GET 请求                                    │
│ 服务端返回 HTML 响应                                        │
└─────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段 5: 浏览器渲染                                          │
│ 解析 HTML → DOM                                            │
│ 解析 CSS → CSSOM                                           │
│ 合并 → 渲染树 (Render Tree)                                │
│ 布局 (Layout) → 绘制 (Paint) → 合成 (Composite)            │
└─────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────┐
│ 阶段 6: 加载子资源                                          │
│ 并行加载: JS、CSS、图片、字体等                              │
│ JS 执行可能修改 DOM → 重新布局/绘制                         │
└─────────────────────────────────────────────────────────────┘

各阶段涉及的协议/层次：

4. 怎么使用

# 用 curl 模拟浏览器请求（查看完整请求响应）
curl -v https://www.example.com/page

# 用 Chrome DevTools Network 面板分析
# 1. F12 打开开发者工具
# 2. 切换到 Network 面板
# 3. 勾选 "Preserve log" 保留日志
# 4. 输入 URL 回车
# 5. 查看各阶段耗时：DNS、TCP、TLS、TTFB、下载

# 用 tcpdump 抓包分析网络流程
tcpdump -i eth0 host www.example.com -nn

# 用 dig/nslookup 测试 DNS 解析时间
dig www.example.com
# 输出包含查询时间

# 用 traceroute 查看路由路径
traceroute www.example.com

5. 适用场景

• 前端性能优化：分析各阶段耗时，针对性优化。
• 网络问题排查：确定问题出在 DNS、TCP、TLS 还是 HTTP。
• 学习网络协议栈：理解各层协议的协作方式。

6. 不适用场景与替代方案

• 不需要深入网络细节的前端开发：关注渲染阶段即可。
• 后端开发重点：关注 HTTP 协议和服务端处理。

7. 优缺点与技术取舍

整个流程设计合理但存在性能瓶颈：DNS 解析延迟、TCP 握手延迟、TLS 握手延迟。优化手段包括：DNS 预解析、TCP 预连接、TLS 会话复用、HTTP/2 多路复用、HTTP/3 1-RTT 握手。

8. 常见问题及解决方案

9. 版本差异与实现边界

• HTTP/1.1：每个请求需要 TCP 连接（可复用但有限制）。
• HTTP/2：多路复用，一个 TCP 连接承载多个请求。
• HTTP/3：基于 QUIC，1-RTT 连接建立，无队头阻塞。
• 浏览器实现：Chrome、Firefox、Safari 渲染引擎不同（Blink、Gecko、WebKit）。

10. 常见追问

• TTFB（Time To First Byte）是什么？（从发送请求到收到第一个响应字节的时间）
• DNS 预解析和预连接如何实现？（<link rel="dns-prefetch">、<link rel="preconnect">）
• 关键渲染路径（Critical Rendering Path）如何优化？
• Service Worker 在这个流程中的作用？（拦截请求、离线缓存）

11. 易错点

• 认为输入 URL 后立即发送 HTTP 请求：中间还有 DNS、TCP、TLS 握手。
• 忽略渲染阶段的性能：前端渲染也可能是瓶颈。
• 混淆各协议所在层次：HTTP（应用层）、TCP（传输层）、IP（网络层）。

一句话总结

浏览器从 URL 到页面展示经历 URL 解析→DNS 查询→TCP/TLS 握手→HTTP 请求/响应→渲染解析→子资源加载的完整链路，涉及 OSI 七层模型的多层协作。

DNS 解析的核心作用是什么？完整的 DNS 解析过程是怎样的？

原始问法：

• DNS解析的核心作用是什么？完整的DNS解析过程是怎样的？

来源题目：SRC-07-73-314

面试先答

DNS（Domain Name System，域名系统）的核心作用是将人类可读的域名转换为机器可识别的 IP 地址，是互联网最重要的基础设施之一。完整的 DNS 解析过程遵循递归+迭代的查询模式：1）浏览器检查浏览器缓存（最近解析过的域名）；2）检查操作系统缓存（OS 缓存文件如 /etc/hosts）；3）发送 DNS 请求到本地 DNS 服务器（通常是路由器或 ISP DNS，如 8.8.8.8）；4）本地 DNS 服务器若缓存未命中，迭代查询根 DNS（13 个根服务器）→ 顶级域 DNS（如 .com 的顶级域）→ 权威 DNS（如 example.com 的权威 DNS）；5）权威 DNS 返回最终 IP，逐级回传缓存至浏览器。

核心结论

• DNS 是全球分布式层级数据库，不是单一服务器。
• 解析过程采用递归（客户端→本地 DNS）+ 迭代（本地 DNS→根→顶级域→权威）模式。
• DNS 使用 UDP 53 端口（响应超 512 字节时使用 TCP）。

1. 是什么

DNS 是一个分布式的、层级结构的全球数据库，用于域名和 IP 地址的相互映射。由 Paul Mockapetris 于 1983 年设计（RFC 882/883），是互联网核心基础设施。

DNS 层级结构：

根域 (.)
├── .com
│   ├── example.com
│   │   └── www.example.com → 93.184.216.34
│   └── google.com
│       └── www.google.com → 172.217.160.110
├── .cn
│   ├── baidu.com
│   └── alibaba.com
├── .org
└── .net

DNS 记录类型：

• A 记录：域名 → IPv4 地址
• AAAA 记录：域名 → IPv6 地址
• CNAME 记录：域名别名
• MX 记录：邮件服务器
• NS 记录：权威 DNS 服务器
• TXT 记录：文本记录（SPF、DKIM 等）
• SRV 记录：服务定位

2. 为什么需要它

人类难以记忆 IP 地址（如 93.184.216.34），而域名（www.example.com）易于记忆。DNS 实现了域名到 IP 的自动转换，是互联网通信的前提。如果没有 DNS，人类必须记住所有服务的 IP 地址。

3. 底层原理与完整流程

完整 DNS 解析流程：

浏览器缓存（TTL 内） → 直接返回

操作系统缓存（/etc/hosts 或 hosts 文件）→ 直接返回

本地 DNS 服务器（如 8.8.8.8、114.114.114.114）：
  ↓ 缓存命中？
  是 → 直接返回
  否 → 迭代查询：
    1. 向根 DNS 查询：". 根域"
       根 DNS 返回 .com 顶级域 DNS 地址
    2. 向 .com 顶级域 DNS 查询："example.com"
       顶级域返回 example.com 的权威 DNS 地址
    3. 向权威 DNS 查询："www.example.com"
       权威 DNS 返回 IP 地址
    4. 逐级返回结果，各级缓存

DNS 报文结构：

12字节头部:
  - Transaction ID（事务 ID，匹配请求响应）
  - Flags（标志位：请求/响应、递归/迭代、截断等）
  - Questions（问题数，通常 1）
  - Answer RRs（回答资源记录数）
  - Authority RRs（权威资源记录数）
  - Additional RRs（附加资源记录数）

问题部分:
  - QNAME（查询域名）
  - QTYPE（查询类型：A、AAAA、MX 等）
  - QCLASS（查询类别：IN=Internet）

资源记录（回答/权威/附加）:
  - NAME（域名）
  - TYPE（记录类型）
  - CLASS（类别）
  - TTL（生存时间，秒）
  - RDLENGTH（记录数据长度）
  - RDATA（记录数据）

4. 怎么使用

# 用 dig 查询 DNS
dig www.example.com

# 指定 DNS 服务器查询
dig @8.8.8.8 www.example.com

# 查询 AAAA 记录
dig AAAA www.example.com

# 查询 MX 记录
dig MX gmail.com

# 查询 CNAME 记录
dig CNAME www.github.com

# 显示详细查询过程
dig +trace www.example.com

# 用 nslookup 查询
nslookup www.example.com

# 查看本地 DNS 缓存
# Windows:
ipconfig /displaydns
# Linux:
# systemd-resolve --statistics

# 清除本地 DNS 缓存
# Windows:
ipconfig /flushdns
# Linux (nscd):
# nscd -i hosts

5. 适用场景

• 所有需要域名解析的网络通信（HTTP、HTTPS、FTP、邮件等）。
• CDN 调度（通过 DNS 返回不同 IP 实现就近访问）。
• 全局负载均衡（GSLB）。
• 邮件路由（MX 记录）。

6. 不适用场景与替代方案

• 纯 IP 网络通信：不需要 DNS。
• 本地开发：可通过 /etc/hosts 直接映射。
• 替代方案：DNS over HTTPS（DoH）、DNS over TLS（DoT）加密 DNS 查询。

7. 优缺点与技术取舍

优点：分布式、可扩展、全球统一、易于使用。 缺点：明文传输（传统 DNS）、存在 DNS 劫持/污染风险、查询延迟。

8. 常见问题及解决方案

9. 版本差异与实现边界

• 传统 DNS：UDP 53 端口，明文传输。
• DNS over HTTPS（DoH）：RFC 8484，使用 HTTPS 加密 DNS 查询。
• DNS over TLS（DoT）：RFC 7858，使用 TLS 加密 DNS 查询。
• DNSSEC：DNS 安全扩展，使用数字签名验证 DNS 响应。
• 公共 DNS：Google（8.8.8.8）、Cloudflare（1.1.1.1）、114 DNS（114.114.114.114）。

10. 常见追问

• DNS 递归查询和迭代查询的区别？（递归：客户端→本地 DNS，本地 DNS 负责全链路查询；迭代：本地 DNS→根→顶级域→权威，逐级查询）
• DNS 劫持如何检测？（对比不同 DNS 结果、使用 dig +trace 追踪）
• CDN 调度如何利用 DNS？（智能 DNS 根据请求来源返回最近的服务器 IP）
• DNS 报文超过 512 字节怎么办？（使用 TCP 传输或 EDNS0 扩展）

11. 易错点

• 认为 DNS 是单一服务器：DNS 是全球分布式层级数据库。
• 混淆递归和迭代查询方向：递归是客户端向本地 DNS 发递归请求，迭代是本地 DNS 向各层服务器发迭代请求。
• 忽略 TTL 的影响：TTL 决定缓存时间，影响域名切换速度。

一句话总结

DNS 将人类可读的域名映射为机器可识别的 IP 地址，通过层级分布式结构实现全球可扩展的自动解析，是互联网通信的基础。

Socket 编程了解吗？

原始问法：

• Socket编程了解吗？

来源题目：SRC-07-74-315

面试先答

Socket 是操作系统提供的网络编程接口（API），是应用层与传输层之间的桥梁。基于 TCP 的 Socket 编程流程：服务端创建 ServerSocket → 绑定端口 → 监听连接 → accept 接受客户端连接 → 通信；客户端创建 Socket → 连接服务端 → 通信。基于 UDP 的 Socket 更简单，直接发送/接收数据报即可。Java 中对应 java.net.Socket（TCP）、java.net.ServerSocket（TCP 服务端）、java.net.DatagramSocket（UDP）。核心要点：TCP Socket 涉及三次握手、阻塞 IO、流的读写；UDP Socket 基于数据报、无连接。

核心结论

• Socket 是操作系统级别的网络编程 API，不是 Java 独有的概念。
• TCP Socket 面向连接、可靠、字节流；UDP Socket 无连接、不可靠、数据报。
• Java NIO（New IO）提供了非阻塞 Socket 编程能力。

1. 是什么

Socket 是操作系统提供的一组系统调用（API），用于实现网络上两个进程之间的通信。它是网络通信的端点（Endpoint），由 IP 地址 + 端口号 + 协议三元组唯一标识。

Socket 类型：

• 流式 Socket（SOCK_STREAM）：基于 TCP，面向连接、可靠传输。
• 数据报 Socket（SOCK_DGRAM）：基于 UDP，无连接、不可靠。
• 原始 Socket（SOCK_RAW）：直接访问 IP 层，可自定义协议。

2. 为什么需要它

操作系统将网络操作抽象为文件操作（"一切皆文件"哲学），Socket 让开发者可以像读写文件一样进行网络通信，无需关心底层协议实现。

3. 底层原理与完整流程

TCP Socket 编程流程：

服务端                                    客户端
  Socket() → 创建 Socket                   Socket() → 创建 Socket
  bind()   → 绑定地址和端口                 connect() → 连接服务端
  listen() → 开始监听                       ↓
  accept() → 接受连接（返回新 Socket）      ↓
  ↓                                        ↓
  recv()/send() → 数据交互                 recv()/send() → 数据交互
  ↓                                        ↓
  close()  → 关闭连接                       close() → 关闭连接

状态转换：

• 服务端 bind() 后进入 LISTEN 状态。
• accept() 阻塞直到有连接，返回已连接的 Socket（进入 ESTABLISHED）。
• 数据传输通过 read()/write()（或 recv()/send()）完成。
• 关闭时发送 FIN，经历四次挥手。

4. 怎么使用

Java TCP 服务端示例：

// 服务端
try (ServerSocket serverSocket = new ServerSocket(8080)) {
    System.out.println("服务器启动，等待客户端连接...");
    while (true) {
        try {
            Socket clientSocket = serverSocket.accept();
            new Thread(() -> handleClient(clientSocket)).start();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

private static void handleClient(Socket client) throws IOException {
    InputStream in = client.getInputStream();
    OutputStream out = client.getOutputStream();
    byte[] buffer = new byte[1024];
    int len = in.read(buffer);
    String msg = new String(buffer, 0, len);
    out.write("服务器收到: ".getBytes());
    out.write(msg.getBytes());
    out.flush();
    client.close();
}

Java TCP 客户端示例：

// 客户端
try (Socket socket = new Socket("127.0.0.1", 8080)) {
    OutputStream out = socket.getOutputStream();
    InputStream in = socket.getInputStream();
    out.write("Hello Server".getBytes());
    out.flush();
    byte[] buffer = new byte[1024];
    int len = in.read(buffer);
    System.out.println("收到: " + new String(buffer, 0, len));
}

Java UDP 示例：

// UDP 服务端
try (DatagramSocket serverSocket = new DatagramSocket(8080)) {
    byte[] buffer = new byte[1024];
    DatagramPacket packet = new DatagramPacket(buffer, buffer.length);
    serverSocket.receive(packet);
    String msg = new String(packet.getData(), 0, packet.getLength());
    System.out.println("收到: " + msg);
}

// UDP 客户端
try (DatagramSocket clientSocket = new DatagramSocket()) {
    byte[] data = "Hello".getBytes();
    DatagramPacket packet = new DatagramPacket(
        data, data.length, InetAddress.getByName("127.0.0.1"), 8080
    );
    clientSocket.send(packet);
}

5. 适用场景

• 网络通信的底层实现（HTTP、FTP、SMTP 等协议均基于 Socket）。
• 自定义协议开发（游戏协议、IM 协议）。
• 微服务间通信（Dubbo、gRPC 底层均使用 Socket）。

6. 不适用场景与替代方案

• 直接操作 Socket 开发 HTTP 应用：使用现成框架（Spring MVC、Netty）。
• 高性能高并发场景：使用 NIO（Netty、gRPC）替代传统 BIO。
• 需要安全通信：Socket 层需叠加 TLS（SSLSocket）。

7. 优缺点与技术取舍

传统 BIO Socket 优点：简单易用、阻塞模型直观。缺点：一线程一连接、资源消耗大、不适合高并发。 NIO Socket 优点：非阻塞、多路复用、高并发。缺点：编程复杂。

8. 常见问题及解决方案

9. 版本差异与实现边界

• Java 1.0 引入 Socket、ServerSocket。
• Java 1.4 引入 NIO（java.nio.channels.SocketChannel）。
• Java 7 引入 NIO.2（AsynchronousSocketChannel）。
• 实现依赖操作系统 Socket API（Berkeley Sockets）。

10. 常见追问

• Socket 和 ServerSocket 的区别？（ServerSocket 用于服务端监听，accept() 返回 Socket 用于通信）
• SO_REUSEADDR 的作用？（允许绑定处于 TIME_WAIT 的端口）
• Nagle 算法的作用？（合并小报文段，通过 TCP_NODELAY 禁用）

11. 易错点

• 认为 Socket 是 Java 特有的：Socket 是操作系统概念，所有语言都支持。
• 忘记关闭 Socket：可能导致资源泄漏和端口占用。
• 混淆 InputStream.read() 和 BufferedReader.readLine()：前者按字节读取，后者按行读取。

一句话总结

Socket 是操作系统提供的网络编程接口，让应用层能够像操作文件一样进行网络通信，是所有网络协议的底层基础。

长连接和短连接的区别是什么？

原始问法：

• 长连接和短连接的区别是什么？

来源题目：SRC-07-74-316

面试先答

长连接和短连接的核心区别在于连接的复用方式：短连接每次请求都建立和关闭一个新的 TCP 连接（三次握手 + 传输 + 四次挥手），开销大；长连接在同一个 TCP 连接上发送多个请求，复用连接避免了反复握手的开销。HTTP/1.0 默认短连接，HTTP/1.1 默认长连接（Connection: keep-alive）。长连接的好处是减少握手延迟、降低服务器压力，但需要注意：服务端需要维护连接状态、空闲连接有超时机制、HTTP/1.1 长连接仍存在队头阻塞。HTTP/2 的多路复用在此基础上进一步优化。

核心结论

• 短连接：每次请求独立 TCP 连接，简单但开销大。
• 长连接：复用 TCP 连接，高效但需管理连接状态。
• HTTP/1.1 默认长连接，HTTP/2 多路复用实现多请求并发。

1. 是什么

• 短连接：每次 HTTP 请求都新建一个 TCP 连接，请求完成后立即关闭。
• 长连接：多个 HTTP 请求复用同一个 TCP 连接，通过 Connection: keep-alive 头协商保持连接。

2. 为什么需要它

• 短连接频繁创建销毁 TCP 连接，三次握手+四次挥手开销巨大（至少 2-RTT），在高并发下会导致端口耗尽。
• 长连接复用连接，消除了反复握手的延迟和资源开销。

3. 底层原理与完整流程

短连接流程：

请求1: SYN→SYN/ACK→ACK→HTTP请求→HTTP响应→FIN→ACK
请求2: SYN→SYN/ACK→ACK→HTTP请求→HTTP响应→FIN→ACK
（每个请求需要 2-RTT 握手 + 数据传输 + 2-RTT 挥手）

长连接流程：

握手: SYN→SYN/ACK→ACK（仅一次）
请求1: HTTP请求→HTTP响应
请求2: HTTP请求→HTTP响应（复用同一连接）
...
最后关闭: FIN→ACK→FIN→ACK
（N 个请求只需 1 次握手 + 1 次挥手）

HTTP/1.1 长连接管理：

• 服务端通过 Keep-Alive 响应头设置超时时间和最大请求数。
• 空闲连接在超时后自动关闭。
• 通过 Content-Length 或 Transfer-Encoding: chunked 确定响应体长度。
• 管线化（Pipelining）允许在等待前一个响应时发送下一个请求。

4. 怎么使用

// Java HttpClient 默认使用长连接
// Java 11+ HttpClient 自动管理连接池

// curl 控制长连接
# 默认使用长连接
curl -v http://example.com

# 强制短连接
curl -v -H "Connection: close" http://example.com

# 查看连接复用情况
curl -v http://example.com http://example.com/page2
# 如果使用长连接，第二次请求会在同一连接上

// Java 设置连接超时和保活
Socket socket = new Socket();
socket.setKeepAlive(true);          // 开启 TCP Keepalive
socket.setSoTimeout(30000);         // 读取超时 30s
socket.connect(new InetSocketAddress("host", 8080), 5000);  // 连接超时 5s

5. 适用场景

• 长连接：HTTP/1.1/2/3 通信、数据库连接池、RPC 框架、WebSocket。
• 短连接：一次性请求、无状态 API、无需会话保持的场景。

6. 不适用场景与替代方案

• 大量短时间请求：长连接更高效。
• 状态敏感场景：短连接可避免状态泄漏。
• 需要更高并发：HTTP/2 多路复用比 HTTP/1.1 长连接更优。

7. 优缺点与技术取舍

8. 常见问题及解决方案

9. 版本差异与实现边界

• HTTP/1.0：默认短连接，需 Connection: keep-alive 才能长连接。
• HTTP/1.1：默认长连接，除非 Connection: close。
• HTTP/2：多路复用，一个连接承载多个流。
• TCP Keepalive：默认 2 小时空闲探测，可调整参数。

10. 常见追问

• HTTP/1.1 长连接和 HTTP/2 多路复用的区别？（长连接仍需按序响应，多路复用支持并发）
• 长连接如何检测对端存活？（TCP Keepalive、应用层心跳）
• 数据库连接池的本质？（复用长连接，避免反复建立 TCP + 认证）

11. 易错点

• 认为长连接一定比短连接好：空闲长连接浪费资源，短连接在低并发下更简单。
• 混淆 HTTP 长连接和 WebSocket：长连接仍是请求-响应模式，WebSocket 是双工通信。
• 忽略 HTTP/1.1 长连接的队头阻塞：请求可以管线化，但响应必须按序返回。

一句话总结

长连接通过复用 TCP 连接消除反复握手开销，是 HTTP/1.1 的默认行为；短连接每次独立但简单，二者各有适用场景。

select、poll、epoll 的区别是什么？

原始问法：

• select、poll、epoll的区别是什么？

来源题目：SRC-07-74-317

面试先答

select、poll、epoll 都是 Linux 的 IO 多路复用机制，用于同时监听多个文件描述符的就绪状态。核心区别在于数据结构、切换方式、可扩展性：select 使用位图（fd_set）存储监听的 fd，数组大小固定（1024），每次调用需将 fd 集合从用户态拷贝到内核态，遍历所有 fd 检查就绪状态，时间复杂度 O(n)；poll 使用链表（struct pollfd），无 fd 数量限制，但仍需每次遍历所有 fd；epoll 使用红黑树存储 fd、回调机制返回就绪 fd，只需遍历就绪的 fd，时间复杂度 O(1)，无数量限制。epoll 是 Linux 高性能网络编程的核心。

核心结论

• select：位图、固定 1024 fd、O(n)、每次拷贝数据。
• poll：链表、无数量限制、O(n)、每次拷贝数据。
• epoll：红黑树+回调、无数量限制、O(1) 就绪通知、内存共享。

1. 是什么

IO 多路复用是一种机制，允许一个线程同时监听多个文件描述符，当任意一个 fd 就绪时通知应用程序进行 IO 操作。select、poll、epoll 是 Linux 提供的三种实现。

2. 为什么需要它

传统 BIO（阻塞 IO）一个连接需要一个线程，高并发下线程数过多导致上下文切换开销巨大。IO 多路复用允许单线程处理多个连接，大幅提升并发能力。

3. 底层原理与完整流程

3.1 select

应用层调用 select(nfds, readfds, writefds, errorfds, timeout):
  1. 将 fd_set 从用户态拷贝到内核态（3 个集合）
  2. 内核遍历所有 fd，检查就绪状态
  3. 将就绪的 fd 设置到 fd_set（返回时覆盖原集合）
  4. 拷贝结果回用户态
  5. 用户态遍历结果，找到就绪的 fd

// select API
int select(int nfds,
           fd_set *readfds,   // 可读 fd 集合
           fd_set *writefds,  // 可写 fd 集合
           fd_set *exceptfds, // 异常 fd 集合
           struct timeval *timeout);

// fd_set 最大 1024 位
#define FD_SETSIZE 1024

3.2 poll

// poll API
int poll(struct pollfd *fds, nfds_t nfds, int timeout);

struct pollfd {
    int fd;        // 文件描述符
    short events;  // 关注的事件（POLLIN、POLLOUT 等）
    short revents; // 实际发生的事件
};

• 使用链表替代位图，无数量限制。
• 每个 pollfd 结构体包含 fd 和事件类型。
• 内核仍需遍历所有 pollfd 检查就绪状态。

3.3 epoll

// epoll API
int epoll_create(int size);              // 创建 epoll 实例
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

struct epoll_event {
    uint32_t events;  // 事件类型
    epoll_data_t data; // 用户数据
};

epoll 工作流程：

1. epoll_create: 创建红黑树和就绪队列
2. epoll_ctl(EPOLL_CTL_ADD):
   - 将 fd 添加到红黑树（共享内存，无需每次拷贝）
   - 注册 fd 对应的回调函数
3. epoll_wait:
   - 调用进程睡眠
   - 当 fd 就绪时，内核触发回调
   - 将就绪 fd 添加到就绪队列（双向链表）
   - 唤醒进程，返回就绪事件列表
4. 用户态直接处理就绪的 fd（无需遍历所有 fd）

4. 怎么使用

// epoll 使用示例
int epfd = epoll_create(1024);

struct epoll_event ev, events[10];
ev.events = EPOLLIN;
ev.data.fd = listenfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, &ev);

while (true) {
    int nfds = epoll_wait(epfd, events, 10, -1);
    for (int i = 0; i < nfds; i++) {
        if (events[i].data.fd == listenfd) {
            // 接受新连接
            int clientfd = accept(listenfd, ...);
            ev.events = EPOLLIN;
            ev.data.fd = clientfd;
            epoll_ctl(epfd, EPOLL_CTL_ADD, clientfd, &ev);
        } else {
            // 处理数据
            read(events[i].data.fd, buf, sizeof(buf));
        }
    }
}

// Java NIO 使用 Selector（底层使用 epoll）
Selector selector = Selector.open();
SocketChannel channel = SocketChannel.open();
channel.configureBlocking(false);
channel.register(selector, SelectionKey.OP_READ);

while (selector.select() > 0) {
    Set<SelectionKey> keys = selector.selectedKeys();
    for (SelectionKey key : keys) {
        if (key.isReadable()) {
            // 处理读取
        }
    }
    keys.clear();
}

5. 适用场景

• select：fd 数量少（<1024）、跨平台（Windows 支持较好）。
• poll：fd 数量中等、需要精细事件类型。
• epoll：Linux 高并发服务器（Nginx、Redis、Node.js、Netty 均使用 epoll）。

6. 不适用场景与替代方案

• 大量并发连接：epoll 是 Linux 上的最优选择。
• Windows 平台：IOCP（完成端口）是 Windows 的高效方案。
• macOS：kqueue 是 macOS 的高效方案。

7. 优缺点与技术取舍

8. 常见问题及解决方案

9. 版本差异与实现边界

• select：POSIX 标准，所有平台支持。
• poll：POSIX 标准，Linux 2.1.30+。
• epoll：Linux 2.5.44+ 特有，非 POSIX 标准。
• Netty 在 Linux 下自动使用 epoll，在 macOS 下使用 kqueue。

10. 常见追问

• epoll 的 ET（边缘触发）和 LT（水平触发）的区别？
• 为什么 epoll 比 select/poll 快？（共享内存 + 回调机制，避免遍历和内存拷贝）
• epoll 使用红黑树而不是哈希表的原因？（红黑树增删查 O(log n)，且支持 fd 有序）

11. 易错点

• 认为 epoll 一定比 select 快：fd 数量少时 select 反而更快。
• 混淆 epoll 水平触发和边缘触发的使用：ET 必须配合非阻塞 IO。
• 忽略 epoll 的创建参数：epoll_create 的 size 参数在新版本中已忽略。

一句话总结

三者都是 IO 多路复用机制，select/poll 采用轮询模式 O(n)，epoll 采用事件通知模式 O(1)，epoll 是 Linux 高并发网络编程的核心。

Epoll 的底层实现原理是什么？为什么比 select/poll 快？

原始问法：

• Epoll的底层实现原理是什么？为什么比select/poll快？

来源题目：SRC-07-74-318

面试先答

epoll 的底层实现涉及三个核心数据结构：1）红黑树：存储所有注册的 fd，通过 epoll_ctl(EPOLL_CTL_ADD) 添加，增删查时间复杂度 O(log n)；2）就绪队列（双向链表）：存储已就绪的 fd，当 fd 就绪时由内核回调添加，epoll_wait 直接从队列取就绪事件，时间复杂度 O(1)；3）epitem：每个 fd 对应一个 epitem，包含红黑树节点、就绪队列节点、回调函数等。epoll 比 select/poll 快的原因：1）内存共享：fd 注册通过共享内存，无需每次调用拷贝；2）回调通知：fd 就绪时通过回调添加到就绪队列，无需轮询所有 fd；3）O(1) 返回：epoll_wait 只返回就绪的 fd，无需遍历。

核心结论

• epoll 通过红黑树管理 fd、回调机制通知就绪、就绪队列 O(1) 获取结果。
• 相比 select/poll 的轮询模式，epoll 是事件驱动模式。
• epoll 适合高并发场景（数万连接）。

1. 是什么

epoll 是 Linux 内核 2.5.44+ 引入的事件通知机制，是对 select/poll 的增强。它将"监听"和"等待"分离：通过 epoll_ctl 注册关注的 fd，通过 epoll_wait 等待就绪事件。

2. 为什么需要它

select/poll 在高并发场景下存在性能瓶颈：每次调用需遍历所有 fd（O(n)）、用户态到内核态的数据拷贝、返回结果后仍需遍历。epoll 针对这些问题进行了优化。

3. 底层原理与完整流程

3.1 核心数据结构

epoll 实例 (struct eventpoll)
├── rbr (红黑树根节点)      ← 存储所有注册的 epitem
├── rdllist (就绪队列头)    ← 存储已就绪的 epitem
└── wq (等待队列头)         ← 存储等待的进程

epitem (每个 fd 一个)
├── rbn (红黑树节点)        ← 将 epitem 链接到红黑树
├── rdln (就绪队列节点)     ← 将 epitem 链接到就绪队列
├── fd (文件描述符)
├── events (关注的事件)
├── fddata (用户数据)
└── ep_poll_callback (回调函数)

3.2 工作流程

① epoll_create:
   - 创建 struct eventpoll 结构体
   - 初始化红黑树和就绪队列

② epoll_ctl(EPOLL_CTL_ADD):
   - 分配 epitem，设置 fd、关注事件、回调
   - 将 epitem 插入红黑树 O(log n)
   - 设置 fd 的 epoll 回调为 ep_poll_callback

③ epoll_wait:
   - 检查就绪队列是否非空
     - 非空：直接返回就绪事件 O(1)
     - 为空：将当前进程加入等待队列，睡眠

④ fd 就绪时（如数据到达）:
   - 内核调用 ep_poll_callback 回调
   - 回调将 epitem 添加到就绪队列 O(1)
   - 唤醒 epoll_wait 睡眠的进程

⑤ epoll_wait 返回:
   - 将就绪事件拷贝到用户态
   - 清空就绪队列
   - 返回就绪事件数量

3.3 为什么比 select/poll 快

4. 怎么使用

# 查看系统 epoll 支持
cat /proc/sys/fs/file-max
# 查看当前打开的文件描述符
cat /proc/sys/fs/file-nr

# Java NIO 配置 epoll
-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.EPollSelectorProvider
# 默认 Linux 下 Java NIO 自动使用 epoll

// 完整 epoll 服务端示例
int main() {
    int listenfd = socket(AF_INET, SOCK_STREAM, 0);
    bind(listenfd, ...);
    listen(listenfd, 10);

    int epfd = epoll_create1(0);  // 创建 epoll 实例

    struct epoll_event ev;
    ev.events = EPOLLIN;
    ev.data.fd = listenfd;
    epoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, &ev);

    struct epoll_event events[1024];
    while (true) {
        int n = epoll_wait(epfd, events, 1024, -1);
        for (int i = 0; i < n; i++) {
            if (events[i].data.fd == listenfd) {
                // 接受新连接
                int clientfd = accept(listenfd, ...);
                ev.events = EPOLLIN | EPOLLET;  // 边缘触发
                ev.data.fd = clientfd;
                epoll_ctl(epfd, EPOLL_CTL_ADD, clientfd, &ev);
            } else {
                // 边缘触发：必须循环读取
                char buf[1024];
                while (true) {
                    int ret = read(events[i].data.fd, buf, sizeof(buf));
                    if (ret <= 0) break;
                    // 处理数据
                }
            }
        }
    }
}

5. 适用场景

• 高并发 Web 服务器（Nginx 可处理数万并发连接）。
• 高性能网络框架（Netty、gRPC、Node.js）。
• 任何需要高并发 IO 的 Linux 应用。

6. 不适用场景与替代方案

• fd 数量少（<100）：select 更简单高效。
• 非 Linux 平台：使用 kqueue（macOS/BSD）、IOCP（Windows）。

7. 优缺点与技术取舍

优点：高并发性能好、无 fd 数量限制、内存效率高。 缺点：仅 Linux 支持、编程复杂、边缘触发易出错。

8. 常见问题及解决方案

9. 版本差异与实现边界

• Linux 2.5.44+：epoll 引入。
• Linux 2.6.27+：EPOLLEXCLUSIVE 标志（排他触发）。
• Linux 4.5+：epoll_pwait（信号安全等待）。
• 不同平台的替代：kqueue（macOS）、IOCP（Windows）、port（Solaris）。

10. 常见追问

• epoll 的 LT 和 ET 模式区别？（见下一题）
• epoll 的惊群效应？（epoll 通过回调机制避免了传统 select 的惊群）
• 为什么红黑树比哈希表适合管理 fd？（有序性、O(log n) 增删查）

11. 易错点

• 认为 epoll_wait 必须遍历所有就绪 fd：是的，但就绪 fd 数量远少于总 fd。
• 边缘触发忘记循环读取：ET 模式下如果只读取一次，剩余数据将不会被通知。
• 忽略 epoll 的内存开销：每个 epitem 占用内存，海量连接时需注意。

一句话总结

epoll 通过红黑树管理 fd、回调机制通知就绪、就绪队列 O(1) 返回，从根本上解决了 select/poll 的性能瓶颈，是 Linux 高并发网络编程的核心。

Epoll 的 ET 和 LT 模式有什么区别？

原始问法：

• Epoll的ET和LT模式有什么区别？

来源题目：SRC-07-74-319

面试先答

epoll 的 LT（Level Trigger，水平触发）和 ET（Edge Trigger，边缘触发）是两种事件通知模式，核心区别在于通知策略：LT 模式下，只要 fd 上有数据可读（缓冲区非空），epoll_wait 就会持续通知；ET 模式下，只有 fd 状态发生变化时（从无数据到有数据的边缘）才通知一次。LT 更安全但可能导致重复通知和"惊群"（大量就绪 fd 通知），ET 效率更高但要求必须使用非阻塞 IO 并一次性读完所有数据。实践中建议使用 LT + 非阻塞 IO 作为首选方案。

核心结论

• LT：缓冲区非空就通知，安全但可能重复通知。
• ET：状态变化才通知一次，高效但易漏数据。
• LT 适合入门和大多数场景，ET 适合高性能场景。

1. 是什么

• LT（Level Trigger）：默认模式，只要 fd 处于就绪状态（可读/可写），epoll_wait 就返回该 fd。
• ET（Edge Trigger）：边缘触发，只有 fd 状态从未就绪变为就绪时（边缘）才通知一次。

2. 为什么需要它

• LT 模式简单可靠，但在高并发下，大量 fd 处于就绪状态时会导致频繁的 epoll_wait 返回。
• ET 模式只在状态变化时通知一次，减少重复通知和 epoll_wait 调用，提升效率。

3. 底层原理与完整流程

LT 模式工作流程：

场景：fd 缓冲区有数据 [D1, D2, D3]

1. epoll_wait → 返回 fd，就绪事件
2. read() 读取 D1
3. epoll_wait → 返回 fd，就绪事件（缓冲区仍有 D2, D3）
4. read() 读取 D2
5. epoll_wait → 返回 fd，就绪事件（缓冲区仍有 D3）
6. read() 读取 D3
7. epoll_wait → 不返回（缓冲区为空）

ET 模式工作流程：

场景：fd 缓冲区有数据 [D1, D2, D3]

1. 数据到达（边缘触发）
2. epoll_wait → 返回 fd，就绪事件
3. read() 读取 D1
4. epoll_wait → 不返回（状态未变化）
5. read() 读取 D2
6. epoll_wait → 不返回
7. read() 读取 D3
8. 数据再次到达（新的边缘触发）
9. epoll_wait → 返回 fd

关键差异：

• LT：每次调用 epoll_wait 都会返回就绪的 fd，不管上次是否处理完。
• ET：只在 fd 状态变化时返回一次，如果上次没读完，下次可能不再通知。

4. 怎么使用

// LT 模式（默认）
struct epoll_event ev;
ev.events = EPOLLIN;  // 默认 LT
ev.data.fd = clientfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, clientfd, &ev);

// ET 模式
ev.events = EPOLLIN | EPOLLET;  // 添加 EPOLLET 标志
epoll_ctl(epfd, EPOLL_CTL_ADD, clientfd, &ev);

// LT 模式读取（简单，单次读取即可）
char buf[1024];
int n = read(fd, buf, sizeof(buf));
// 即使没读完，下次 epoll_wait 仍会通知

// ET 模式读取（必须循环读取直到无数据）
char buf[1024];
while (true) {
    int n = read(fd, buf, sizeof(buf));
    if (n > 0) {
        // 处理数据
    } else if (n == 0) {
        // 连接关闭
        break;
    } else if (errno == EAGAIN || errno == EWOULDBLOCK) {
        // 已读完所有数据
        break;
    }
}
// ET 模式必须使用非阻塞 IO
fcntl(fd, F_SETFL, O_NONBLOCK);

5. 适用场景

• LT：通用场景、入门学习、可靠性优先。
• ET：高性能服务器（Nginx 默认使用 ET + 非阻塞 IO）。

6. 不适用场景与替代方案

• ET 不适合编程新手：容易因未读完数据导致丢失。
• 需要可靠但不追求极致性能的场景：LT 更合适。

7. 优缺点与技术取舍

8. 常见问题及解决方案

9. 版本差异与实现边界

• LT 是默认模式，兼容性最好。
• ET 在 Linux 2.5.44+ 支持。
• EPOLLEXCLUSIVE（Linux 4.5+）：多个 epoll 实例监听同一 fd 时仅通知一个。
• EPOLLEPHEMERAL（Linux 5.1+）：单次触发，类似边缘触发。

10. 常见追问

• ET 模式下如何处理连接关闭？（read 返回 0 表示关闭，需移除 epoll 监听）
• LT 模式的"惊群效应"如何避免？（epoll 本身不存在经典惊群，但大量就绪 fd 仍可能造成负载）
• Nginx 使用 LT 还是 ET？（默认使用 ET + 非阻塞 IO）

11. 易错点

• ET 模式下忘记循环读取：导致数据丢失。
• ET 模式下使用阻塞 IO：read 会阻塞等待数据，导致死锁。
• 认为 ET 一定比 LT 好：ET 编程复杂，容易出错。

一句话总结

epoll 的 LT 模式在 fd 就绪时持续通知，安全但可能重复触发；ET 模式在状态变化时只通知一次，高效但必须配合非阻塞 IO 循环读取。

什么是零拷贝？原理是什么？

原始问法：

• 什么是零拷贝？原理是什么？

来源题目：SRC-07-74-320

面试先答

零拷贝（Zero-Copy）是指在数据传输过程中，数据不需要在用户空间和内核空间之间来回拷贝，直接在内核缓冲区和目标设备之间传输的技术。传统数据传输至少需要 4 次拷贝（磁盘→内核缓冲区→用户缓冲区→内核套接字缓冲区→网卡），零拷贝通过 sendfile()、mmap()、splice() 等系统调用减少甚至消除用户态参与，降低 CPU 开销和上下文切换次数。核心价值：减少 CPU 拷贝次数、降低上下文切换、提升带宽利用率。常见应用：Nginx 静态文件服务、Kafka 消息传输、Redis RDB 持久化。

核心结论

• 零拷贝不是"零次拷贝"，而是减少或消除用户态参与的拷贝。
• sendfile() 实现磁盘到网卡的零拷贝（2 次内核态拷贝）。
• mmap() 实现磁盘到用户态的内存映射。

1. 是什么

零拷贝技术是一种优化数据传输的方式，通过减少数据在内核空间和用户空间之间的拷贝次数，降低 CPU 开销，提升数据传输效率。

2. 为什么需要它

传统数据传输流程中，数据需要在内核缓冲区和用户缓冲区之间反复拷贝：

磁盘 → 内核缓冲区（DMA 拷贝）
内核缓冲区 → 用户缓冲区（CPU 拷贝）
用户缓冲区 → 内核套接字缓冲区（CPU 拷贝）
内核套接字缓冲区 → 网卡（DMA 拷贝）

4 次拷贝中，2 次 CPU 拷贝是不必要的（数据不需要被应用层处理），浪费 CPU 和内存带宽。

3. 底层原理与完整流程

3.1 传统数据传输（4 次拷贝）

read(fd, buf, len)     ← CPU 拷贝：内核→用户
write(sock, buf, len)  ← CPU 拷贝：用户→内核

磁盘 ──DMA──→ 内核读缓冲区 ──CPU──→ 用户缓冲区 ──CPU──→ 内核发送缓冲区 ──DMA──→ 网卡

3.2 sendfile() 零拷贝（2 次拷贝）

sendfile(sock, fd, offset, len)  ← 系统调用，数据直接从内核读缓冲区到内核发送缓冲区

磁盘 ──DMA──→ 内核读缓冲区 ──────────────────────────→ 内核发送缓冲区 ──DMA──→ 网卡
                        ↑                                        ↑
                    CPU 拷贝（内核内）                        DMA 拷贝

• 数据不需要经过用户空间，减少 2 次 CPU 拷贝和 2 次上下文切换。
• Linux 2.6.22+ 支持 sendfile() + splice() 组合实现真正的零拷贝（数据在内核内直接传递）。

3.3 mmap() 内存映射

mmap(NULL, len, PROT_READ, MAP_PRIVATE, fd, 0)

磁盘 ──DMA──→ 内核页缓存 ──映射为用户空间地址──→ 应用程序直接访问

• 将内核页缓存映射到用户空间，应用程序可以直接读取，无需拷贝。
• 适合随机访问场景（如数据库、内存文件系统）。

3.4 splice() + tee()

splice(fd_in, pipe, len, SPLICE_F_MORE)  ← 从 fd 到 pipe
splice(pipe, fd_out, len, SPLICE_F_MORE) ← 从 pipe 到 fd
tee(pipe_in, pipe_out, len, 0)            ← pipe 到 pipe（零拷贝）

• splice() 实现 fd 到 pipe 的零拷贝。
• tee() 实现 pipe 到 pipe 的零拷贝。
• 组合使用可实现任意两个 fd 之间的零拷贝。

4. 怎么使用

// sendfile() 使用示例（Nginx 等静态文件服务器的核心实现）
#include <sys/sendfile.h>

void send_file(int out_fd, int in_fd, off_t offset, size_t count) {
    ssize_t sent = sendfile(out_fd, in_fd, &offset, count);
    // sent 为已发送的字节数
}

// mmap() 使用示例
#include <sys/mman.h>

void* map_file(int fd, size_t size) {
    void* ptr = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
    // ptr 直接映射到内核页缓存，无需拷贝
    return ptr;
}

// splice() 使用示例
#include <fcntl.h>

void zero_copy_pipe(int fd_in, int fd_out, size_t len) {
    int pipefd[2];
    pipe(pipefd);
    splice(fd_in, NULL, pipefd[1], NULL, len, SPLICE_F_MORE);
    splice(pipefd[0], NULL, fd_out, NULL, len, SPLICE_F_MORE);
    close(pipefd[0]);
    close(pipefd[1]);
}

// Java NIO 使用零拷贝
// FileChannel.transferTo() 底层使用 sendfile()
RandomAccessFile raf = new RandomAccessFile("file.txt", "r");
FileChannel sourceChannel = raf.getChannel();
SocketChannel targetChannel = SocketChannel.open();
sourceChannel.transferTo(0, sourceChannel.size(), targetChannel);
// 底层调用 sendfile()，实现零拷贝

5. 适用场景

• 静态文件服务器（Nginx、Apache）：sendfile() 直接返回文件。
• 消息队列（Kafka、RocketMQ）：sendfile() 传输消息。
• 数据库（MySQL、Redis）：mmap() 数据访问。
• CDN、流媒体服务器：大文件传输。

6. 不适用场景与替代方案

• 数据需要被应用层处理（如加密、压缩）：零拷贝不适用，需传统 read/write。
• 通用 IO 场景：零拷贝需要特定 API，不是所有场景都支持。

7. 优缺点与技术取舍

8. 常见问题及解决方案

9. 版本差异与实现边界

• Linux 2.6.22+：sendfile() 支持 splice() 路径，实现真正的零拷贝。
• Linux 2.6.34+：splice() 和 tee() 支持任意 fd 组合。
• Linux 3.5+：sendfile() 支持 SENDFILE_SPLICE 路径。
• Java NIO：FileChannel.transferTo() 底层使用 sendfile()。

10. 常见追问

• sendfile() 和 mmap() 的区别？（sendfile 是推模式，mmap 是拉模式；sendfile 单向传输，mmap 支持随机访问）
• 零拷贝对 CPU 的影响？（减少 CPU 拷贝次数，降低 CPU 使用率，提升系统吞吐量）
• 为什么零拷贝能提升性能？（减少上下文切换、降低 CPU cache 污染、减少内存拷贝）

11. 易错点

• 认为零拷贝完全没有拷贝：DMA 拷贝仍存在，只是消除了 CPU 拷贝。
• 混淆用户态和内核态的拷贝：零拷贝减少的是用户态和内核态之间的拷贝。
• 认为零拷贝适用于所有场景：需要应用层处理数据时零拷贝不适用。

一句话总结

零拷贝通过 sendfile、mmap、splice 等技术减少或消除用户态参与的数据拷贝，降低 CPU 开销，是高性能网络编程的关键优化技术。