计算机网络 Computer Networks

阶段总览

1. 分层模型与一次请求的完整旅程

1.1 分层：不是为了学术，而是为了定位问题

分层的实用价值只有一条：把「慢 / 不通 / 出错」定位到某一层。当你面对「页面加载慢」时，分层思维让你能在 30 秒内排出排查顺序：DNS？TCP 建连？TLS？服务端处理？还是响应传输？

python# 把头部开销算清楚：为什么小请求的网络效率极低
# 一个最小 HTTP/1.1 请求在各层的实际占用（字节）
layers = [
    ('应用层 payload', 40),        # "GET /v1/health HTTP/1.1" + Host 头
    ('TCP 头', 20),                # 无选项时 20 字节
    ('IP 头', 20),
    ('以太网头 + FCS', 14 + 4),
    ('前导码 + 帧间隙', 8 + 12),    # 链路层还要求 >=12 字节 IFG
]
total = sum(sz for _, sz in layers)
for name, sz in layers:
    print(f'{name:>18}: {sz:>3} B  ({sz/total:6.1%})')
print(f'{"合计":>18}: {total:>3} B')
print(f'应用层占比 = 40/{total} = {40/total:.1%}')

# 预期输出（逐行）：
#       应用层 payload:  40 B  ( 33.9%)
#              TCP 头:  20 B  ( 16.9%)
#               IP 头:  20 B  ( 16.9%)
#      以太网头 + FCS:  18 B  ( 15.3%)
#      前导码 + 帧间隙:  20 B  ( 16.9%)
#               合计: 118 B
# 应用层占比 = 40/118 = 33.9%

1.2 一次 HTTPS 请求的完整旅程（把延迟拆开看）

bash# 用 curl 把时间拆开看 —— 这是最快的「分层诊断」
curl -o /dev/null -s -w "\
  DNS解析:      %{time_namelookup}s\n\
  TCP建连:      %{time_connect}s\n\
  TLS握手完成:  %{time_appconnect}s\n\
  首字节到达:   %{time_starttransfer}s\n\
  全部完成:     %{time_total}s\n\
  重定向次数:   %{num_redirects}\n\
  下载字节:     %{size_download}\n" https://api.example.com/v1/chat

# 读法（这是关键）：
#   time_namelookup 大               → DNS 慢（换 DNS / 加缓存 / 预解析）
#   time_connect - time_namelookup 大 → TCP 建连慢（网络 RTT 大 / 丢包重传）
#   time_appconnect - time_connect 大 → TLS 握手慢（证书链长 / 未复用会话 / 跨地域）
#   time_starttransfer - appconnect 大 → 服务端处理慢（不是网络问题！去查服务端）
#   time_total - time_starttransfer 大 → 响应传输慢（数据量大 / 带宽受限）

# 再看一次「流式」请求的表现：TTFT 才是用户感知的等待
curl -N -s -w "\nTTFB: %{time_starttransfer}s  总计: %{time_total}s\n" \
  https://api.example.com/v1/chat/stream -d '{"q":"hi"}' | head -40

python# 用 Python 精确测量各阶段（比 curl 更细，可直接做成探针）
import socket, ssl, time
HOST, PATH = 'api.example.com', '/v1/health'
t = {}
t0 = time.perf_counter()
raw = socket.create_connection((HOST, 443), timeout=5)
t['tcp_ms'] = (time.perf_counter() - t0) * 1000          # 纯 TCP 建连
ctx = ssl.create_default_context()
t1 = time.perf_counter()
tls = ctx.wrap_socket(raw, server_hostname=HOST)
t['tls_ms'] = (time.perf_counter() - t1) * 1000          # 纯 TLS 握手
t2 = time.perf_counter()
req = f'GET {PATH} HTTP/1.1\r\nHost: {HOST}\r\nConnection: close\r\n\r\n'
tls.sendall(req.encode())
tls.recv(1)
t['ttfb_ms'] = (time.perf_counter() - t2) * 1000         # 请求到首字节
t['total_ms'] = (time.perf_counter() - t0) * 1000
print({k: round(v, 1) for k, v in t.items()})

# 典型输出（同城跨 AZ，未复用连接）：
# {'tcp_ms': 1.2, 'tls_ms': 3.8, 'ttfb_ms': 42.0, 'total_ms': 47.2}
# 判读：ttfb 远大于 tcp+tls → 瓶颈在服务端而非网络（见 7.1 分层诊断）
#       复用连接（连接池）后 tcp_ms 与 tls_ms 应接近 0

1.3 延迟的四个组成部分：别把「慢」都归给带宽

网络延迟不是一个数字，而是四部分之和。分不清它们，你就无法判断该优化什么（这是面试高频，也是排障必备）。

text总延迟 = 处理延迟 + 排队延迟 + 传输延迟 + 传播延迟

  处理延迟 (processing)：路由器/网卡查表、校验耗时。通常微秒级，可忽略。
                        但用户态协议栈（如 gRPC 的序列化）会显著增加它。

  排队延迟 (queueing)  ：在缓冲区里等待被发送。拥塞时会指数级增长！
                        这是「为什么一拥塞延迟就爆炸」的原因（见 1.3 后的排队论）。

  传输延迟 (transmission) = 数据长度 / 带宽
                        100 KB 在 1 Gbps 上 = 0.8 ms；这是「带宽」真正影响的部分。

  传播延迟 (propagation) = 距离 / 光速（约 200 km/ms 在光纤中）
                        北京→上海 1200 km ≈ 6 ms（单程），往返 12 ms（理论下限）

关键结论：
  ① 传播延迟是「物理下限」，无法通过加带宽改善。跨大西洋往返最少 ~60 ms。
  ② 带宽只影响传输延迟。把一个 1 GB 文件从 100 Mbps 升到 1 Gbps，确实快 10 倍；
     但把一次 1 KB 的 API 调用从 100 Mbps 升到 1 Gbps，几乎没变化。
  ③ 排队延迟在拥塞时主导一切——这也是拥塞控制的全部意义。

• Little 定律（排队论基石）：L = λ × W（系统中的平均请求数 = 到达率 × 平均停留时间）。工程含义：当请求到达率 λ 接近服务能力上限时，W（延迟）会非线性暴涨。所以「把 GPU 利用率压到 100%」是危险的——延迟会失控。给推理服务留 20–30% 余量不是浪费，是保证 P99 的必要成本。
• 为什么「加带宽」常常没用：AI 服务里的请求大多是小 payload，瓶颈在传播延迟、握手、排队与服务端算力上。看到「慢」就去加带宽，是最常见的错误归因。
• 「长肥管道（LFN）」问题：带宽 × RTT 很大时（跨洋高带宽链路），TCP 的窗口必须足够大才能填满管道。这是 TCP 调优与 QUIC 优化的重要场景。

python# 把 1.3 的四个延迟分量写成可复算的函数 —— 评估方案时直接用
C = 200_000_000        # 光纤中光速 2e8 m/s（约 200 km/ms）
def total_latency(payload_bytes, bandwidth_bps, distance_km,
                  hops=8, queue_ms=0.0, process_ms=0.05):
    prop  = (distance_km * 1000 / C) * 1000                 # ms（单程）
    trans = payload_bytes * 8 / bandwidth_bps * 1000        # ms
    return {'prop': prop, 'trans': trans,
            'proc': process_ms * hops, 'queue': queue_ms,
            'sum': prop + trans + process_ms * hops + queue_ms}

print('跨太平洋 1 KB 请求')
r = total_latency(1024, 1_000_000_000, 10_000)
print(f"  传播(单程) {r['prop']:.1f} ms → RTT {2*r['prop']:.1f} ms")
print(f"  传输         {r['trans']:.3f} ms  <- 1 KB 在 1 Gbps 上几乎为 0")
print(f"  处理(8 跳)   {r['proc']:.2f} ms")

print('同机房传 1 GB 模型权重')
r2 = total_latency(1024**3, 25_000_000_000, 0.01)
print(f"  传输 {r2['trans']:.0f} ms  <- 这里带宽才是主角")

# 预期输出：
#   传播(单程) 50.0 ms → RTT 100.0 ms
#   传输         0.008 ms
#   处理(8 跳)   0.40 ms
#   同机房 1 GB 传输 343 ms
# 关键推论：小请求的延迟 = 传播 + 握手，与带宽无关；
#           大传输的延迟 = 数据量/带宽。二者优化手段完全不同。

1.4 动手练习与自测

1. 分层计时：用 curl -w 与上面的 Python 探针分别测一个真实 HTTPS 站点，把 DNS/TCP/TLS/TTFB 四段填进表格。判据：两法结果同量级（误差 < 20%），并能指出瓶颈段。
2. 连接复用收益：对同一域名连续发 20 次请求，分别在「每次新建连接（Connection: close）」与「复用连接」下测总耗时。判据：复用后总耗时下降应接近握手成本 × 次数（同城可省 30–60%）。
3. 带宽 vs 传播：用上面的复算函数预测「北京↔上海 1 KB」与「同机房 1 GB」的延迟，再用 scp/curl 实测对比。判据：预测与实测同一数量级，并能解释偏差来源（排队/抖动）。
4. 头部开销：抓一次真实请求的包，量出 payload 与总包字节比。判据：能算出有效载荷占比，并说出它对你的探活/心跳设计的影响。
5. 2026 选型：给定「移动端 AI 助手、弱网、需断线续传」的场景，判断该用 HTTP/2+SSE 还是 HTTP/3+QUIC，并写出至少 2 条量化理由。判据：提到 0-RTT、连接迁移、UDP 被封的回退。

2. IP、路由与数据中心网络

2.1 IP、CIDR、NAT 与 MTU

• CIDR 记法：10.0.0.0/8 里的 8 表示前 8 位是网络位，因此可容纳 2²⁴ 个地址。子网划分的本质是「用掩码切分地址空间」。工程上你必须能算清：/24 有多少可用地址（254）、两个网段是否同子网（掩码与运算）。
• NAT：把私有地址映射到公网地址。它解决了 IPv4 地址耗尽，但带来了副作用——外部无法主动连接 NAT 后的主机。这就是 WebSocket / SSE / gRPC streaming 都依赖「客户端先发起连接」的根本原因，也是 P2P、WebRTC 需要 STUN/TURN 打洞的原因。
• MTU 与分片：以太网 MTU 通常 1500 字节。IP 层超长会分片，而分片有严重性能问题（任一分片丢失则整包重传）。PMTUD（路径 MTU 发现）被防火墙阻断时会出现「小请求正常、大请求卡死」的诡异现象——这是真实世界里非常常见的坑（尤其是在 VPN / K8s overlay 网络里）。
• K8s 与 overlay 网络：VXLAN / IPIP 等隧道封装会额外消耗字节（VXLAN 加 50 字节），使有效 MTU 从 1500 降到 1450。如果你的 AI 应用在 K8s 里出现「大 payload 超时」，第一反应应该是 MTU 而不是代码。

bash# 排查 MTU 问题的标准手法
# 逐步加大包大小做「不分片」测试，看从多大开始失败
for sz in 1472 1442 1400 1372 1200; do
  echo -n "payload=$sz: "
  ping -c 1 -M do -s $sz 10.0.1.5 >/dev/null 2>&1 && echo OK || echo "失败（超过 MTU）"
done
# 注意 -s 是 payload 大小，实际包大小 = payload + 28（IP 20 + ICMP 8）
# 所以 1472 + 28 = 1500 是标准以太网；若 1442 就失败，说明有效 MTU 是 1470（隧道封装）

# 查看接口 MTU
ip link show | grep mtu

# 若是 K8s，检查 CNI 的 MTU 配置是否与宿主网络匹配
kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo}' | head -c 200

python# CIDR / 子网计算：面试与排障都要手算
import ipaddress as ip
net = ip.ip_network('10.12.0.0/22')
print('网络地址     :', net.network_address)      # 10.12.0.0
print('广播地址     :', net.broadcast_address)    # 10.12.3.255
print('可用主机数   :', net.num_addresses - 2)    # 1022
print('子网掩码     :', net.netmask)              # 255.255.252.0
print('是否含该 IP  :', ip.ip_address('10.12.3.7') in net)   # True
print('10.12.4.1 in?', ip.ip_address('10.12.4.1') in net)    # False
# 预期输出首三行：10.12.0.0 / 10.12.3.255 / 1022

# K8s overlay（VXLAN）MTU 推导：宿主 1500 - VXLAN 50
# => Pod 有效 MTU 1450；若再叠 IPsec/WireGuard，常见降到 1400 甚至 1380
print('建议 Pod MTU =', 1500 - 50)   # 1450

2.2 数据中心网络与 RDMA：AI 训练的真实瓶颈

这一节是「计算机网络」在 AI 领域最有增量的部分。分布式训练的性能极限往往不在算力，而在梯度同步的网络带宽。

• 为什么 RDMA 重要：传统 TCP/IP 协议栈要经过内核、多次内存拷贝、CPU 参与，延迟几十微秒且 CPU 占用高。RDMA（远程直接内存访问）让网卡直接读写对端内存，绕过内核、零拷贝、CPU 几乎不参与，延迟降到 1–2 微秒。训练中每秒要同步几百次梯度，这个差异被放大成分钟级的差距。
• 拓扑感知（topology-aware）：NCCL 会探测机器的 GPU 拓扑（哪些卡在同一 NVLink 域、哪些跨 NUMA、哪些走 PCIe）并选择最优的通信算法。所以「同一批卡，换一种 GPU 插法，训练速度能差 30%」不是玄学。
• 集合通信的两种算法：Ring AllReduce（环形，通信量 2(N−1)/N × 数据量，随卡数趋于饱和）与 Tree AllReduce（树形，延迟更低，适合小消息）。NCCL 会按消息大小与拓扑自动选择。
• 通信与计算重叠（overlap）：梯度同步不必等全部算完才开始——可以按层（layer-wise）计算完梯度就立刻发起该层的 all-reduce，让网络传输与后续层的反向传播并行。这是分布式训练的一项核心优化，能把通信开销几乎隐藏掉。

text算一下 all-reduce 的通信量 —— 这是评估分布式训练可行性的第一步

Ring AllReduce 总通信量（每张卡）= 2 × (N−1)/N × S
   其中 N = 卡数，S = 模型参数字节数

例子：70B 模型，bf16（2 字节/参数），S = 140 GB
  单卡通信量 = 2 × (N−1)/N × 140 GB ≈ 280 GB（N 很大时）

  用 400 Gbps RDMA（= 50 GB/s）互联：
     理论最短耗时 = 280 GB / 50 GB/s = 5.6 秒  ← 每训练一步！
  用 25 GbE（= 3.1 GB/s）：
     理论最短耗时 = 280 / 3.1 = 90 秒        ← 完全不可行

反推：若希望通信耗时不超过计算的 20%，而单步计算耗时 2 秒，
     则要求通信 < 0.4 秒 → 需要带宽 ≥ 280/0.4 = 700 GB/s → 必须用 NVLink + IB 组合

这个计算解释了为什么：
  ① 大模型训练必须用高带宽互联（RDMA / IB），普通以太网不可行；
  ② 张量并行（TP）通信量大，只在节点内（NVLink）做；数据并行（DP）通信量小，可跨节点；
  ③ ZeRO / FSDP 通过分片优化器状态来降低通信量，是「用通信换显存」的精心权衡。

bash# 在真实 GPU 机器上验证互联拓扑与带宽（NCCL 自带工具）
nvidia-smi topo -m
#   输出是一张 8x8 矩阵：NV4/NV5 表示 NVLink，SYS 表示跨 NUMA（慢），
#   PIX/PXB/PHB 表示经 PCIe 交换机/桥。看到 SYS 出现在关键路径就要调插卡。

# 官方 all-reduce 带宽测试（8 卡）：
./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8
#   关注输出列：algbw（算法带宽）与 busbw（总线带宽）。
#   预期（NVLink 4，8×H100）：busbw 可达约 400 GB/s；纯 PCIe 5 仅约 50 GB/s。
#   若实测远低于此，先查 nvidia-smi topo -m 的拓扑，再查 NCCL_IB_* 环境变量。

# 查 RDMA 设备与端口状态
ibv_devinfo | grep -E 'hca_id|state|rate'
#   期望：state: PORT_ACTIVE，rate: 400 Gb/sec（NDR）
export NCCL_DEBUG=INFO   # 打印 NCCL 选择的算法与通道数

2.3 动手练习与自测

1. 手算子网：给定 172.16.0.0/20，写出网络地址、广播地址、可用主机数与掩码；再判断 172.16.15.5 是否同网段。判据：答案为 172.16.0.0 / 172.16.15.255 / 4094 / 255.255.240.0，且判断为是。
2. MTU 复现：在 K8s 里（或本地 mock）用 ping -M do -s 逐步探测，找出有效 MTU。判据：能测出失败阈值并解释隧道封装扣了多少字节。
3. 拓扑检查：在有 GPU 的机器上跑 nvidia-smi topo -m，指出哪些卡在同一 NVLink 域。判据：能读懂矩阵并说出 TP 应限制在哪个范围。
4. 通信量核算：70B 模型 bf16、128 卡 DP，算每步 all-reduce 通信量与 400 Gbps 下的理论耗时。判据：约 280 GB / 5.6 s（N 大时）。
5. 总线带宽判读：跑 all_reduce_perf 8 卡，记录 busbw 并与预期（NVLink 约 400 GB/s、PCIe 约 50 GB/s）对比。判据：能解释实测值偏低时的首个排查动作。

3. TCP：可靠传输的代价与拥塞控制

3.1 三次握手、四次挥手与 TIME_WAIT

text三次握手（建立连接）
  Client ── SYN(seq=x) ────────────────► Server      客户端说：我想连，我的初始序号是 x
  Client ◄─ SYN(seq=y) + ACK(x+1) ───── Server      服务端说：好，我的序号是 y，确认你的 x
  Client ── ACK(y+1) ──────────────────► Server      客户端说：收到你的 y
  ─────────────────────────────────────────────────
  为什么必须三次？因为要让「双方的收发能力」都得到确认：
    第 1 次：服务端确认「客户端能发」
    第 2 次：客户端确认「服务端能收能发」
    第 3 次：服务端确认「客户端能收」
  两次不够（服务端无法确认客户端收到了自己的 SYN）；
  四次多余（第 2、3 步可以合并）。

四次挥手（关闭连接）
  Client ── FIN ───────────────────────► Server
  Client ◄─ ACK ───────────────────────  Server       半关闭：客户端不再发，但还能收
  Client ◄─ FIN ───────────────────────  Server
  Client ── ACK ───────────────────────► Server
  ─────────────────────────────────────────────────
  为什么必须四次？因为 TCP 是全双工的，两个方向要分别关闭。
  服务端收到 FIN 后可能还有数据要发，所以 ACK 与自己的 FIN 不能合并。

TIME_WAIT：主动关闭方在发完最后一个 ACK 后要等 2×MSL（通常 60 秒）
  两个原因：
    ① 确保最后的 ACK 能到达（若丢失，对端会重发 FIN，此时还有连接上下文可响应）
    ② 让本次连接的旧报文在网络中彻底消散，避免「串味」到新连接（同四元组复用）

• 服务端看到大量 TIME_WAIT 是最常见的线上现象：如果你的服务是主动关闭方（比如 HTTP 客户端用了短连接、或代理主动断开），就会出现。大量 TIME_WAIT 会占用本地端口，极端情况导致「无法建立新连接」。解法优先级：① 用长连接 / 连接池（最根本）；② 让客户端主动关闭；③ 调 tcp_tw_reuse（谨慎，需配合时间戳）；④ 绝不要用 tcp_tw_recycle（已被移除，NAT 环境下会误杀）。
• 大量 CLOSE_WAIT 是代码 bug 的信号：它表示「对端已经关闭，但本端还没调用 close()」。通常是你的代码在异常路径上忘了释放连接（没有 try-finally 或没有用连接池的上下文管理器）。看到 CLOSE_WAIT 堆积，去查代码里哪里漏了 close。
• SYN Flood 与 backlog：net.core.somaxconn 与 listen() 的 backlog 参数决定半连接队列大小。高并发服务要调大，否则新连接会被丢弃（表现为客户端超时重试、服务端看不到请求日志）。

bash# 连接状态一览 —— 排障的第一步
ss -s                                  # 汇总：各状态连接数
ss -tan state time-wait | wc -l        # 有多少 TIME_WAIT
ss -tan state close-wait | head -20    # CLOSE_WAIT 堆积（代码 bug 信号）
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

# 内核可调参数（了解即可，生产改前先压测）
sysctl net.ipv4.tcp_tw_reuse=1              # 允许复用 TIME_WAIT 连接（需 timestamps）
sysctl net.core.somaxconn=32768             # accept 队列上限
sysctl net.ipv4.tcp_max_syn_backlog=8192    # 半连接队列上限
sysctl net.ipv4.ip_local_port_range="10240 65535"   # 本地端口范围

# 应用层最有效的三招（优先级高于调内核参数）
#  ① 连接池：复用连接，把「握手成本」摊掉
#  ② 客户端主动关闭（通过配置 http 客户端的 keepalive 策略与超时）
#  ③ 正确的超时与重试（避免僵尸连接长期占位）

bash# TIME_WAIT 与端口耗尽的定量判断
ss -s                                  # 看 timewait 总数
ss -tan state time-wait | wc -l        # 逐条计数
# 可用本地端口数 = 65535 - ip_local_port_range 起点（常见 10240）= 约 55295
# 每条 TIME_WAIT 占用 1 个端口 60 秒：
#   若 QPS=1000 个短连接 -> 60 秒窗口需 1000*60 = 60000 个端口
#   > 55295 可用 -> 必然出现 "Cannot assign requested address"
# 结论：短连接 + 高 QPS = 端口必然耗尽。
# 换成长连接后，端口占用从「每请求 1 个」降到「每后端 1–2 个」。

3.2 滑动窗口、拥塞控制与 BBR

这是 TCP 最核心的机制，也是「为什么网络慢」的最主要答案之一。流量控制是「别把接收方撑爆」（接收窗口 rwnd），拥塞控制是「别把网络撑爆」（拥塞窗口 cwnd）。实际发送窗口 = min(rwnd, cwnd)。

bash# 弱网实验：亲手看拥塞控制的影响（Linux 用 tc netem 模拟）
# 查看当前算法
sysctl net.ipv4.tcp_congestion_control

# 模拟「跨洋 + 丢包」链路：100ms 延迟、1% 丢包、限速 50Mbps
sudo tc qdisc add dev eth0 root netem delay 100ms loss 1% rate 50mbit

# 用 CUBIC 下载
sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
curl -o /dev/null -w "CUBIC 用时 %{time_total}s  平均速度 %{speed_download} B/s\n" \
     https://speed.example.com/100mb.bin

# 切换到 BBR（需内核支持，需先加载模块）
sudo modprobe tcp_bbr
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
curl -o /dev/null -w "BBR   用时 %{time_total}s  平均速度 %{speed_download} B/s\n" \
     https://speed.example.com/100mb.bin

# 清理
sudo tc qdisc del dev eth0 root
# 在 1% 丢包 / 100ms RTT 的链路上，BBR 的吞吐通常能比 CUBIC 高 2–5 倍，
# 因为它不会把丢包当成「拥塞必须退让」的唯一信号。

把拥塞控制的公式写出来，你就能定量判断「这条链路理论上能跑多快」，也能解释 BBR 与 CUBIC 的行为差异。

python# 吞吐上限公式 + CUBIC / BBR 的行为模拟
def tcp_throughput(window_bytes, rtt_s):
    """丢包前的稳态吞吐 = 窗口 / RTT（Mathis 公式的简化形式）"""
    return window_bytes / rtt_s
print('窗口 64 KB、RTT 100 ms ->',
      round(tcp_throughput(64*1024, 0.1) / 1024, 1), 'KB/s')
# 预期 640.0 KB/s 约等于 5.2 Mbps —— 跨洋链路上老默认窗口完全跑不满带宽

def bdp(bw_bps, rtt_s):
    """带宽时延积：填满管道所需的最小窗口（字节）"""
    return bw_bps * rtt_s
print('1 Gbps x 100 ms 的 BDP =',
      round(bdp(1e9, 0.1) / 1024 / 1024, 1), 'MB')
# 预期 95.4 MB —— 窗口必须 >= 此值才可能跑满 1 Gbps

# CUBIC 的窗口增长是三次函数 W(t) = C*(t-K)^3 + W_max，且与 RTT 无关
C, W_max = 0.4, 100
K = (W_max * 0.3 / C) ** (1/3)
print('CUBIC 参数 K =', round(K, 2), ' -> 从 W_max 恢复到 W_max 附近约需 K 个往返')
# 预期 K = 4.22 —— 与 RTT 解耦是 CUBIC 在长肥管道上胜过 Reno 的关键

# BBR 核心：用「最大带宽估计 x 最小 RTT」建模，而不是等丢包
def bbr_estimate(bw_samples, rtt_samples):
    return max(bw_samples), min(rtt_samples)
print('BBR 估计 (带宽, 最小RTT) =', bbr_estimate([100, 250, 900], [0.1, 0.12, 0.25]))
# 预期 (900, 0.1) —— 用最大带宽与最小 RTT 算 BDP，主动探测瓶颈

3.3 Nagle 算法、延迟确认与 TCP_NODELAY

这两个机制是流式输出的经典杀手。如果你实现过 SSE 或 WebSocket 推送，一定会遇到「服务端明明立刻写了，客户端却等了几十毫秒才收到」——根源就在这里。

• Nagle 算法：把小包攒起来合并成一个更大的包再发，目的是减少「小包满天飞」的网络低效。规则是「如果还有未被 ACK 的数据，就先把新数据缓存起来」。代价就是延迟：小的流式 chunk 会被攒着等前一个的 ACK。
• 延迟确认（Delayed ACK）：接收方不立即回 ACK，而是等最多 40 ms（Linux 通常 40 ms 上限）看看有没有数据可以捎带确认。
• 两者叠加 = 灾难：发送方等 ACK 才发下一个包（Nagle），接收方等 40 ms 才发 ACK（延迟确认）—— 每个小块都可能被延迟 40 ms。对逐 token 流式输出来说，这是致命的。
• 解法：流式服务必须设置 TCP_NODELAY，禁用 Nagle。Python：sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)；asyncio/aiohttp/httpx 通常默认已开启或可配置。另外，把 chunk 合并成合理大小（如 20–50 ms 一批）比逐字节写更高效——这是「不关 Nagle 但自己控制批大小」的另一种解法。

python# 流式输出：正确的批处理与 TCP_NODELAY 设置
import socket, time

async def stream_tokens(ws, tokens, batch_ms=25, max_batch=16):
    """把逐 token 输出聚成小批再发：
       既避免 Nagle 造成的 40ms 延迟，也避免每个 token 一个包的开销。
       这是生产流式服务的标准做法。"""
    import asyncio
    buf, last = [], time.monotonic()

    async def flush():
        nonlocal buf, last
        if not buf: return
        await ws.send(''.join(buf))
        buf, last = [], time.monotonic()

    async for tok in tokens:
        buf.append(tok)
        now = time.monotonic()
        # 触发条件：攒够一批 或 超过时间窗
        if len(buf) >= max_batch or (now - last) * 1000 >= batch_ms:
            await flush()
    await flush()

# 服务端 socket 层禁用 Nagle（如果框架允许直接操作 socket）
def disable_nagle(sock: socket.socket):
    sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
# 大多数 ASGI 服务器（uvicorn/uvloop）已默认启用 TCP_NODELAY，
# 但如果你自己写 asyncio server 或走代理，一定要确认这一点。

python# 实测 Nagle + 延迟确认带来的约 40 ms 卡顿（本地回环即可复现）
import socket, time
def run(nodelay):
    s = socket.socket(); s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind(('127.0.0.1', 0)); s.listen(1); port = s.getsockname()[1]
    c = socket.socket(); c.connect(('127.0.0.1', port))
    conn, _ = s.accept()
    if nodelay:
        conn.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
    t0 = time.perf_counter(); gaps = []
    for i in range(3):
        time.sleep(0.001); c.send(b'x' * 10)
        conn.recv(10); gaps.append((time.perf_counter() - t0) * 1000)
    for x in (s, c, conn): x.close()
    return gaps

print('未设 NODELAY:', [round(x, 1) for x in run(False)])
print('已设 NODELAY:', [round(x, 1) for x in run(True)])
# 典型输出：
#   未设 NODELAY: [1.2, 41.5, 42.0]   <- 第 2、3 个包被延迟确认卡住约 40 ms
#   已设 NODELAY: [1.1, 2.3, 3.4]     <- 逐个小包立即发出
# 结论：逐 token 流式输出必须 TCP_NODELAY，或按 20–50 ms 批量聚合。

3.4 动手练习与自测

1. 画握手：手绘三次握手/四次挥手，标出 seq/ack 变化与两个方向的状态机。判据：能解释为什么第 2、3 步不能合并。
2. TIME_WAIT 定量：给定 QPS=1000 的短连接服务，估算端口耗尽时间。判据：60×1000=60000 > 约 55295，判定必然耗尽，并给出连接池方案。
3. 吞吐公式：窗口 64 KB、RTT 100 ms，算理论吞吐；再算 1 Gbps×100 ms 所需 BDP。判据：约 640 KB/s 与约 95.4 MB。
4. 弱网对比：用 tc netem 造 100 ms+1% 丢包，对比 CUBIC/BBR 下载同一文件的用时与吞吐。判据：BBR 吞吐通常高 2–5 倍，并能解释原因。
5. NODELAY 实验：跑上面的 Python 脚本，复现 40 ms 间隔。判据：能观察到未设 NODELAY 时第 2 个 chunk 延迟约 40 ms。
6. 拥塞窗口观察：在真机用 ss -tin 观察 cwnd 随传输的变化，解释它为何在丢包时刻骤降。判据：能关联到 CUBIC 的乘性减小。

4. TLS 与安全传输

4.1 TLS 1.3 握手：为什么只需 1 个 RTT

textTLS 1.3 完整握手（1-RTT）
  Client ── ClientHello ─────────────────► Server
           （支持的套件 + key_share + 随机数）
  Client ◄─ ServerHello + {证书} + {Finished}  Server
           （选定的套件 + 自己的 key_share + 签名证书）
  Client ── {Finished} + 应用数据 ───────► Server
  ─────────────────────────────────────────────
  特点：服务端在第二个消息里就把证书、密钥交换参数、Finished 一起发过来，
        把 TLS 1.2 的两次往返压到一次。

TLS 1.3 会话复用 / PSK（0-RTT）
  Client ── ClientHello + 早期数据 ───────► Server     ← 0 往返即可发数据
  ─────────────────────────────────────────────
  代价：早期数据可被重放攻击！所以只能用于「幂等」请求（GET）；
        非幂等操作（下单、写入）绝不能放进 0-RTT 数据里。

TLS 1.2（对比）
  ClientHello → ← ServerHello+证书+ServerKeyExchange+ServerHelloDone
  → ClientKeyExchange+ChangeCipherSpec+Finished → ← Finished
  共 2 个 RTT，且密钥协商与证书验证分两部分，需要更多次交互。

• 证书链验证：客户端拿到的是叶子证书（你的域名），需要沿签发链（中间 CA → 根 CA）验证到本地信任的根证书。证书链不完整是最常见的 TLS 故障——服务端只发叶子证书、不发中间证书，在浏览器上可能正常（浏览器会自己补全），但在某些客户端上直接失败。排查：openssl s_client -connect host:443 -showcerts 看链是否完整。
• SNI（Server Name Indication）：ClientHello 里会带上目标域名（明文），让一台服务器托管多个 HTTPS 站点。但明文 SNI 泄露了用户访问的域名，因此有了 ECH（Encrypted Client Hello）来加密它。
• mTLS（双向认证）：不仅服务端出示证书，客户端也要。用于服务间调用（微服务、Agent 调用工具服务）。在 Hamauls Orion 里，gRPC 内部服务用 mTLS 是最佳实践。
• 证书自动化：用 certbot / ACME 自动续期。「证书过期」是运维事故排行榜前列，必须自动化。监控上要做「证书剩余天数 < 30 天」的告警。

bash# 手工完成一次 TLS 握手并解读（这是最好的学习方式）
openssl s_client -connect api.example.com:443 -servername api.example.com -tls1_3

# 在输出里重点看这几行：
#   Protocol    : TLSv1.3
#   Cipher      : TLS_AES_128_GCM_SHA256        ← 套件（1.3 已移除不安全的算法）
#   Verify return code: 0 (ok)                  ← 证书链验证结果，0 才是 ok
#   Server Temp Key: X25519, 253 bits           ← 密钥交换（1.3 常用 ECDHE）
#   ---
#   Certificate chain                           ← 是否有完整的中间证书
#     0 s:CN = api.example.com
#     1 i:C = US, O = Let's Encrypt, CN = R3     ← 中间 CA（重要！）
#     2 i:O = ISRG, CN = ISRG Root X1            ← 根 CA

# 测量握手耗时（1.3 应明显小于 1.2）
for v in tls1_2 tls1_3; do
  echo -n "$v: "
  for i in 1 2 3; do
    openssl s_client -connect api.example.com:443 -$v </dev/null 2>/dev/null >/dev/null
  done
  # 用 time 或 curl -w "%{time_appconnect}" 得到具体数字
done

# 检查证书剩余有效期（放进监控）
echo | openssl s_client -connect api.example.com:443 2>/dev/null \
  | openssl x509 -noout -dates -subject

python# 会话复用：把 TLS 握手从 1 RTT 降到 0 RTT（Python 标准库即可验证）
import ssl, socket, time
ctx = ssl.create_default_context()
sess = None
for i in range(2):
    with socket.create_connection(('api.example.com', 443)) as s:
        t0 = time.perf_counter()
        with ctx.wrap_socket(s, server_hostname='api.example.com',
                             session=sess) as ts:
            sess = ts.session                 # 保存会话票据，下次复用
            reused = ts.session_reused
        print(f'第 {i+1} 次: reused={reused}  耗时={(time.perf_counter()-t0)*1000:.1f} ms')

# 预期输出（同城）：
#   第 1 次: reused=False  耗时=118.4 ms   <- 完整 1-RTT 握手
#   第 2 次: reused=True   耗时=  1.9 ms   <- PSK 恢复，省掉证书交换与密钥计算
# 关键：把 session 缓存起来（连接池/进程级），跨请求复用可省约 1 个 RTT。
# 注意 0-RTT 早数据有重放风险，只对幂等请求启用。

4.2 动手练习与自测

1. 手工握手：用 openssl s_client -tls1_3 连一个真实站点，读出协议、套件、临时公钥类型、证书链层数与 Verify 结果。判据：4 个字段全对，且 Verify code = 0。
2. 1.2 vs 1.3：同一站点分别用 -tls1_2/-tls1_3 测 time_appconnect。判据：1.3 明显小于 1.2（同城可差 1 个 RTT）。
3. 会话复用：跑上面的 Python 脚本，观察 session_reused 从 False 到 True 与耗时骤降。判据：第 2 次耗时降到 5 ms 以内。
4. 0-RTT 风险：写出 3 个绝不能放进 0-RTT 早数据的操作，并说明重放后果。判据：下单/写入/转账等非幂等操作，重放会造成重复副作用。
5. 证书链诊断：人为只配叶子证书（去掉中间证书），用 s_client 观察验证失败。判据：能复现验证错误并说明浏览器为何可能「看起来正常」。

5. HTTP 演进与流式协议选型

5.1 HTTP/1.1 → HTTP/2 → HTTP/3 的演进逻辑

• HTTP/1.1 的困境：一个连接同一时刻只能处理一个请求。浏览器于是对同一域名开 6 个连接——但每个连接都要握手，而且 6 个并发仍有上限。域名分片（把静态资源放不同域名）就是这么来的 hack。
• HTTP/2 的多路复用：一个 TCP 连接上并发多个 stream，每个 stream 有独立 id，数据被切成帧（frame）交错发送。这解决了应用层的队头阻塞，也省掉了多次握手。但 TCP 层仍有 HOL：一旦有包丢失，TCP 必须等重传，所有 stream 都被阻塞。
• HTTP/3 用 QUIC 解决 TCP HOL：QUIC 在 UDP 之上实现可靠传输，但每个 stream 独立处理丢失与重传——stream A 丢包不影响 stream B。此外 QUIC 把 TLS 1.3 集成进握手（1-RTT 甚至 0-RTT），并支持连接迁移（换网络不断连，对移动端极有价值）。
• HTTP/2 的一个反直觉效果：多路复用让「把小资源合并成大文件」的老优化变成反模式。因为合并文件会降低缓存粒度、并可能阻塞首个字节。优化手段会随协议版本变化——这是「懂原理」比「记技巧」更重要的例证。

bash# 一句话验证服务端到底支持哪个版本（含 h2 协商）
curl -sI --http2 https://api.example.com/health | head -1
#   HTTP/2 200              <- Upgrade 协商成功
curl -sI --http2-prior-knowledge https://api.example.com/health | head -1
#   HTTP/2 200              <- 跳过 Upgrade，直接 h2c/h2（服务端需支持）
curl -sI --http3 https://api.example.com/health | head -1
#   HTTP/3 200              <- 走 UDP/QUIC（curl 需编译 ngtcp2/quiche）
# 若 --http3 报 "HTTP/3 not supported"，说明本地 curl 未编译 QUIC 支持。

# 看 ALPN 协商出的协议
openssl s_client -connect api.example.com:443 -alpn h2,http/1.1 </dev/null 2>/dev/null | grep ALPN
#   ALPN protocol: h2       <- 服务端优先 h2

# 验证 HTTP/2 是否真的单连接多路复用（两条请求复用同一连接）
curl -s --http2 -o /dev/null -w 'connects=%{num_connects}\n' \
  https://api.example.com/a https://api.example.com/b
#   connects=1              <- HTTP/2 多路复用生效

5.2 SSE / WebSocket / gRPC streaming / 长轮询：怎么选

python# SSE 服务端最小实现（含心跳、断点续传、正确头部）
from fastapi import FastAPI, Request
from fastapi.responses import StreamingResponse
import asyncio, json, time

app = FastAPI()

@app.get('/v1/chat/stream')
async def stream(req: Request, q: str):
    async def gen():
        last_id = req.headers.get('Last-Event-ID')
        start = int(last_id) + 1 if last_id else 0
        # 说明：真实实现要能从 start 处续传（依赖服务端保存生成进度或从缓存重放）
        try:
            for i, tok in enumerate(generate(q)):
                if i < start: continue
                # SSE 格式：id / event / data / 空行分帧
                yield f'id: {i}\n'
                yield 'event: token\n'
                yield f'data: {json.dumps({"t": tok}, ensure_ascii=False)}\n\n'
                if i % 8 == 0:
                    yield ': ping\n\n'          # 注释行充当心跳，防代理超时断开
        except asyncio.CancelledError:
            raise                                # 客户端断开 → 正确清理
        yield 'event: done\ndata: {}\n\n'

    return StreamingResponse(gen(), media_type='text/event-stream', headers={
        'Cache-Control': 'no-cache, no-transform',   # no-transform 阻止代理改内容
        'X-Accel-Buffering': 'no',                   # 关键：让 Nginx 不缓冲
        'Connection': 'keep-alive',
    })

• 为什么 LLM 流式首选 SSE：① 单向推送足够（模型只往外吐 token）；② 基于普通 HTTP，代理、CDN、网关兼容性最好；③ 浏览器 EventSource 与 fetch+ReadableStream 都原生支持；④ 自带 Last-Event-ID 重连语义。WebSocket 的双向能力在纯流式输出场景是浪费，而它的代理兼容性与重连复杂度是额外成本。
• SSE 的三个必踩坑：① Nginx / 网关缓冲——必须设置 X-Accel-Buffering: no 或 proxy_buffering off，否则你会看到「内容一次性全部出现」；② 中间设备超时——长时间无数据会被断开，必须发心跳（注释行或 event）；③ HTTP/1.1 的 6 连接上限——同一域名下并发过多流式请求会被排队（HTTP/2 可缓解）。
• 什么时候必须用 WebSocket：需要客户端持续上传（语音输入、实时协作编辑、游戏）、或需要极低延迟的双向交互时。此时 SSE + 一个独立的上行 HTTP 接口也可以替代，但会多一次往返。
• gRPC streaming 的定位：它是服务间的最佳选择（protobuf 高效、四种模式齐全、原生流控），但浏览器直连需要 gRPC-Web + 代理，因此对外一般用 SSE/HTTP，对内用 gRPC。Hamauls Orion 的架构就是「对外 SSE、对内 gRPC」。

javascript// 浏览器端 SSE：断线自动续传 + 心跳看门狗 + 错误降级
function connect(url, onToken) {
  let lastId = localStorage.getItem('sse-last-id') || '';
  const es = new EventSource(url + (lastId ? '?last_event_id=' + lastId : ''));
  let lastMsg = Date.now();
  es.addEventListener('token', (e) => {
    lastMsg = Date.now();
    const { t } = JSON.parse(e.data);
    lastId = e.lastEventId;                 // 服务端发的 id: 字段
    localStorage.setItem('sse-last-id', lastId);
    onToken(t);
  });
  // 心跳看门狗：超过 30 s 无任何事件就主动重连（防中间设备静默断连）
  const wd = setInterval(() => {
    if (Date.now() - lastMsg > 30000) { es.close(); clearInterval(wd); connect(url, onToken); }
  }, 5000);
  es.addEventListener('done', () => { es.close(); clearInterval(wd); });
  es.onerror = () => { /* EventSource 会自动重连；持续失败则降级到轮询 */ };
  return es;
}
// 关键数字：EventSource 默认重连约 3 s，可用服务端 retry: 字段改为 1000–2000 ms；
// 服务端每 8–15 s 发一次注释心跳（": ping"），网关 60 s 空闲超时不会误断。

5.3 HTTP 缓存与条件请求：省钱的直接手段

• 强缓存（Cache-Control / Expires）：在有效期内浏览器/代理直接使用本地副本，不发请求。max-age 是相对时间（推荐），Expires 是绝对时间（受时钟影响，不推荐）。
• 协商缓存（ETag / Last-Modified）：过期后带 If-None-Match / If-Modified-Since 询问服务端，未变则返回 304（无 body）。省的是带宽，不是往返。
• no-transform 对 AI 流式至关重要：有些代理会压缩或改写响应体，导致 SSE 分帧被破坏。加这个指令能阻止。
• 在 AI 服务里的应用：① 对确定性请求（相同 prompt + 相同参数 + temperature=0）做响应缓存，直接省一次模型调用——这是成本优化里最直接的一块；② 对 embedding 请求做缓存（同一文本的向量是确定的）；③ 语义缓存（用相似度判断是否可复用），需要谨慎设阈值并做安全评估。

python# 确定性请求缓存 + 语义缓存的骨架（Hamauls Orion 的成本优化组件之一）
import hashlib, json, time

def cache_key(model, messages, **params):
    """确定性请求的缓存键：模型 + 消息 + 影响输出的所有参数都必须进键
       注意：temperature > 0 的请求本质是随机的，缓存会改变语义，
             所以只对 temperature == 0 做严格缓存。"""
    if params.get('temperature', 0) != 0:
        return None                      # 非确定性请求不进严格缓存
    blob = json.dumps({'m': model, 'msg': messages,
                       'p': {k: params[k] for k in sorted(params)}},
                      sort_keys=True, ensure_ascii=False)
    return 'llm:' + hashlib.sha256(blob.encode()).hexdigest()

class TTLRedisCache:
    """带 TTL 与命中率统计的缓存包装（配合第 3 阶段的 LRU 使用）"""
    def __init__(self, redis, ttl=86400):
        self.r, self.ttl, self.hits, self.total = redis, ttl, 0, 0
    def get(self, key):
        if key is None: return None
        self.total += 1
        v = self.r.get(key)
        if v is not None: self.hits += 1
        return v
    def set(self, key, val):
        if key: self.r.setex(key, self.ttl, val)
    @property
    def hit_rate(self): return self.hits / self.total if self.total else 0.0

bash# 条件请求（协商缓存）实测：第二次响应应为 304 且无 body
curl -sI https://api.example.com/config | grep -i etag
#   ETag: "abc123"                    <- 记下这个值
curl -s -o /dev/null -w 'status=%{http_code} size=%{size_download}\n' \
  -H 'If-None-Match: "abc123"' https://api.example.com/config
#   预期输出：status=304 size=0        <- 省带宽，但仍有一次往返
# 对比强缓存 Cache-Control: max-age=86400：第二次请求根本不到服务端。

# 对 LLM：temperature=0 + 相同输入的响应可强缓存（用确定性缓存键）
curl -s -o /dev/null -w 'status=%{http_code} time=%{time_total}\n' \
  -H 'X-LLM-Cache-Key: sha256:...' https://api.example.com/v1/chat
#   命中缓存时 time_total 通常 < 10 ms；未命中（真调模型）为 500–3000 ms。

5.4 动手练习与自测

1. 版本探测：对一个真实站点用 curl 分别测 --http2/--http3，并看 ALPN。判据：能报出协商出的协议，判断是否支持 HTTP/3。
2. 多路复用验证：用 --http2 一次请求两个 URL，看 num_connects 是否为 1。判据：HTTP/2 下应为 1（复用）。
3. 流式被缓冲诊断：写一个最小 SSE 服务，前面套 Nginx 默认配置，观察内容是否被攒批；再加 X-Accel-Buffering: no 对比。判据：能复现并修复「一次性全部出现」。
4. 断线续传：用浏览器脚本模拟中断（关闭再重连），确认从 Last-Event-ID 之后续传。判据：重复 token 数为 0 或可容忍 1 个。
5. 缓存收益：为 temperature=0 的接口加确定性缓存，压测命中率与 P50 延迟。判据：命中时延 < 10 ms，报告命中率。
6. 选型对比：同一场景分别用短轮询/长轮询/SSE 实现，测首字延迟。判据：SSE 首字不劣于长轮询，且空请求数为 0。

6. RPC、序列化与可靠调用的工程学

6.1 序列化与 gRPC 的四种流式模式

protobuf// Hamauls Orion 的内部服务契约（节选）：注意字段号一旦发布就不能改用途
syntax = "proto3";
package hamauls_orion.v1;

service Retriever {
  // 一元：单次查询
  rpc Search (SearchRequest) returns (SearchResponse);
  // 服务端流：边检索边推送候选（降低首字节延迟）
  rpc SearchStream (SearchRequest) returns (stream ScoredDoc);
  // 客户端流：批量上传文档（大文件分片）
  rpc Ingest (stream DocChunk) returns (IngestSummary);
  // 双向流：交互式调试（一边发查询一边收中间结果）
  rpc Debug (stream DebugCmd) returns (stream DebugEvent);
}

message SearchRequest {
  string query = 1;
  int32 top_k = 2;
  repeated string filters = 3;         // 新增字段必须用新编号，永不复用旧编号
}

message ScoredDoc {
  string doc_id = 1;
  float score = 2;
  string snippet = 3;
}

python# 量一量 protobuf vs JSON 的真实体积差（决定内部 RPC 用什么）
import json
obj = {'doc_id': 'd-000123', 'score': 0.87,
       'snippet': 'Hamauls Orion 检索结果片段',
       'tags': ['rag', 'vector', 'rerank'], 'ts': 1730000000}
js = json.dumps(obj, ensure_ascii=False)
print('JSON 字节数   :', len(js.encode()))
# protobuf 近似：字段名不传输，只有 tag + 值（varint/length-delimited）
proto_approx = (2 + 7) + (1 + 4) + (1 + len('Hamauls Orion 检索结果片段'.encode())) \
             + (3 * 5) + (1 + 4)
print('proto 近似字节:', proto_approx)
print('压缩比        :', round(len(js.encode()) / proto_approx, 1), 'x')
# 预期：JSON 约 155 字节，proto 约 40 字节，压缩比约 3.5x
# 结论：高 QPS 内部调用用 protobuf；对外（浏览器/调试）用 JSON。

6.2 连接池、负载均衡与服务发现

• 连接池的必要性：建连成本（TCP + TLS）在跨地域场景可达数百毫秒。池化后这部分成本被摊薄到接近零。池大小不是越大越好——过大会占用服务端连接资源、增加排队，并且向下游暴露更多并发。经验起点：并发请求数 = 池大小 × 单连接吞吐，先测出单连接吞吐再定池大小。
• HTTP/2 场景的特殊性：一个 HTTP/2 连接可以承载数百个并发 stream，所以「池」的意义变了——从「并发度」变成「多后端负载分担」。常见做法是「每后端 1–2 条连接 + 轮询/最少连接负载均衡」。
• 负载均衡的三个层次：① L4（传输层，如 LVS / NLB，按连接转发，不理解协议内容）；② L7（应用层，如 Nginx / Envoy / ALB，能按路径/头部路由、做超时与重试）；③ 客户端侧（SDK 内做负载均衡 + 服务发现，如 gRPC 的 resolver + pick_first/round_robin）。AI 服务因为请求耗时长、差异大，客户端侧 LB（最小连接数 / 最少延迟）通常优于简单轮询。
• 服务发现：静态配置（配置文件）→ 注册中心（Consul / etcd / Nacos）→ 平台原生（K8s Service + Endpoints）。K8s 环境注意 kube-proxy 的 iptables/ipvs 模式差异，以及 headless service 用于客户端侧 LB。
• 长连接的负载均衡难题：连接建立后就固定到某个后端了，扩容时新实例拿不到流量（除非断连重连）。解法：定期主动重连（带抖动）、用 L7 代理做连接迁移、或改用短连接 + 高效建连（QUIC 0-RTT）。

python# HTTP 客户端连接池的工程配置（httpx 示例，aiohttp/requests 思路一致）
import httpx
limits = httpx.Limits(
    max_connections=200,          # 全局并发上限（保护自己与下游）
    max_keepalive_connections=50, # 保活连接数（探查后按单连接吞吐调）
    keepalive_expiry=30.0,        # 空闲 30 s 回收，避免被对端/LB 静默断开
)
timeout = httpx.Timeout(connect=1.0, read=30.0, write=5.0, pool=2.0)
client = httpx.AsyncClient(limits=limits, timeout=timeout, http2=True)

# 为什么这些数字要分开设：
#   connect=1.0s  -> 建连慢就直接失败（不要拖到 read 超时）
#   pool=2.0s     -> 连接池排队超时，防止请求无声堆积（背压的一种）
#   keepalive_expiry 要 < 负载均衡的空闲超时（常见 60 s，但要留余量）
# 经验起点：池大小 约等于 目标 QPS x 单请求平均耗时(s)，再乘 1.5 安全系数。
#   例：200 QPS x 0.05 s = 10 并发 -> 池取 15–30 足够；盲目设 500 只会压垮下游。

6.3 超时、重试、幂等、熔断、限流、背压：AI 服务的可靠性六件套

这一节是本阶段最实用的部分。你的 Java 经验在这里高度可迁移，但 AI 服务有它自己的特点：单次请求耗时长（秒级到分钟级）、成本高（每次调用真金白银）、且天然不确定（可能超时也可能慢而有结果）。这三点让传统的「短超时 + 激进重试」策略完全失效。

（1）超时预算：自上而下分配，而不是各自随便设

text超时预算的正确设计方式（Hamauls Orion 的端到端链路）

  用户请求总 SLA：P99 < 8 s
  ├─ 网关鉴权 + 限流                    50 ms
  ├─ 查询改写（小模型 / 规则）          300 ms   ← 预算必须显式分配
  ├─ 检索（向量 + BM25 + 融合 + 重排）  800 ms
  │    ├─ 向量召回                     200 ms
  │    ├─ BM25 召回                    100 ms
  │    └─ 交叉编码器重排              500 ms
  ├─ 工具调用（Agent 场景，可多次）    2000 ms   ← 每次调用单独限时
  ├─ 模型生成（TTFT + 流式）           4000 ms
  └─ 余量（应对抖动）                   850 ms

规则：
 ① 下游超时之和 + 余量 ≤ 上游超时。绝不允许「下游比上游还长」——
    那会导致上游已经放弃、下游还在白白计算，浪费算力。
 ② 每层都设超时，且越靠内层越短（因为外层要留时间处理失败与降级）。
 ③ 超时值基于实测分布设定（P99 的 1.5–2 倍），而不是拍脑袋。
 ④ 超时必须能「真正取消」下游工作。Python 里注意 asyncio.CancelledError
    的传播，以及在同步阻塞调用上是无法取消的（要换成 async 或子进程）。

（2）重试：只重试该重试的，且必须带退避与抖动

pythonimport asyncio, random, httpx

# 可重试 vs 不可重试 —— 这个分类是重试逻辑的全部基础
RETRYABLE_STATUS = {408, 429, 500, 502, 503, 504}
NON_RETRYABLE_STATUS = {400, 401, 403, 404, 409, 422}      # 重试只会浪费配额

class Budget:                     # 重试预算：防止重试风暴放大故障
    def __init__(self, ratio=0.1):
        self.ratio, self.total, self.failed = ratio, 0, 0
    def allow(self):
        return self.total == 0 or self.failed / self.total < self.ratio
    def record(self, ok):
        self.total += 1
        if not ok: self.failed += 1

async def call_with_retry(fn, budget: Budget, tries=3, base=0.5, cap=8.0):
    """要点：① 只重试可重试错误 ② 指数退避 + 抖动（避免惊群同步重试）
             ③ 尊重 Retry-After 头 ④ 有全局重试预算，防止雪崩放大"""
    last = None
    for i in range(tries):
        try:
            r = await fn()
            if r.status_code in NON_RETRYABLE_STATUS:
                budget.record(False); return r              # 不重试，直接返回
            if r.status_code in RETRYABLE_STATUS:
                if not budget.allow():
                    return r                                 # 预算用尽，放弃重试
                last = r
                wait = min(cap, base * 2 ** i) * (0.5 + random.random() * 0.5)
                ra = r.headers.get('Retry-After')            # 服务端显式指示优先
                if ra and ra.isdigit(): wait = max(wait, float(ra))
                await asyncio.sleep(wait)
                continue
            budget.record(True); return r
        except (httpx.ConnectError, httpx.ReadTimeout, httpx.RemoteProtocolError) as e:
            last = e
            if not budget.allow(): break
            await asyncio.sleep(min(cap, base * 2 ** i) * (0.5 + random.random() * 0.5))
    raise RuntimeError(f'调用失败，已重试 {tries} 次: {last}')

# ⚠️ 最关键的一条：不可重试的错误绝不重试
#   401/403 是凭证问题；400/422 是参数问题；409 是状态冲突。
#   重试它们只会放大故障、烧掉配额。

（3）幂等性：让重试是安全的

• 幂等键（idempotency key）：客户端为每个逻辑操作生成唯一 ID（如 UUID），服务端把它映射到「已处理结果」。同一个键重复到达时直接返回缓存结果，不重复执行。这是「至少一次投递 + 幂等处理」= 事实上恰好一次的标准做法。
• 在 Agent 场景尤其重要：Agent 会调工具（下单、发邮件、写数据库）。如果调用超时后重试，而第一次其实成功了，就会重复下单。所以所有有副作用的工具调用必须携带幂等键，服务端必须去重。这是 M14 里程碑里的硬性要求。
• 幂等的设计位置：① 数据库层——唯一索引 / UPSERT（最简单可靠）；② 缓存层——用 idempotency key 存「处理中 / 已完成 + 结果」；③ 业务层——状态机（只允许特定状态迁移）。优先用数据库唯一约束，它是最不会出错的一层。

（4）熔断、限流与背压

pythonimport asyncio, time

class CircuitBreaker:
    """熔断器：closed → open → half-open 三态
       目的是「快速失败」，避免把请求都压在已经坏掉的下游上（那会让它更坏）"""
    def __init__(self, fail_threshold=5, window=10.0, cool_down=30.0, half_open_trials=3):
        self.fail_threshold, self.window = fail_threshold, window
        self.cool_down, self.trials = cool_down, half_open_trials
        self.state, self.fails, self.opened_at = 'closed', 0, 0.0
        self.trial_ok = 0

    def allow(self) -> bool:
        if self.state == 'closed': return True
        if self.state == 'open':
            if time.monotonic() - self.opened_at >= self.cool_down:
                self.state, self.trial_ok = 'half-open', 0
                return True
            return False
        return True                                  # half-open：放少量请求试探

    def record(self, ok: bool):
        if self.state == 'closed':
            self.fails = 0 if ok else self.fails + 1
            if self.fails >= self.fail_threshold:
                self.state, self.opened_at = 'open', time.monotonic()
        elif self.state == 'half-open':
            if ok:
                self.trial_ok += 1
                if self.trial_ok >= self.trials: self.reset()
            else:
                self.state, self.opened_at = 'open', time.monotonic()

    def reset(self):
        self.state, self.fails, self.trial_ok = 'closed', 0, 0

class TokenBucket:
    """令牌桶限流：平均速率 + 突发容量。AI 场景建议按 token 数而非请求数限流"""
    def __init__(self, rate, burst):
        self.rate, self.burst = rate, burst
        self.tokens, self.ts = burst, time.monotonic()
    def take(self, n=1.0) -> bool:
        now = time.monotonic()
        self.tokens = min(self.burst, self.tokens + (now - self.ts) * self.rate)
        self.ts = now
        if self.tokens >= n:
            self.tokens -= n
            return True
        return False

class BoundedQueue:
    """背压：队列满时不是无限堆积，而是明确拒绝或阻塞
       无限队列 = 延迟无限增长 + 内存爆掉，是最常见的设计错误"""
    def __init__(self, cap, reject_when_full=True):
        self.q, self.cap, self.reject = asyncio.Queue(maxsize=cap), cap, reject_when_full
        self.rejected = 0
    async def put(self, item):
        if self.q.full() and self.reject:
            self.rejected += 1
            raise RuntimeError('queue full: 触发背压，请客户端退避重试')
        await self.q.put(item)

（5）把超时预算变成会真正取消的代码

python# 分层的超时预算：外层时间到，内层必须真的被取消（而不是继续空算）
import asyncio, time

async def fake_io(sec):
    await asyncio.sleep(sec); return f'ok({sec})'

async def retrieve(q, budget_ms):
    # 内部再拆预算：向量 200、BM25 100、重排 500，用整体截止时间约束
    deadline = time.monotonic() + budget_ms / 1000
    async def stage(name, ms, coro):
        left = deadline - time.monotonic()
        if left <= 0: raise asyncio.TimeoutError(name)
        return await asyncio.wait_for(coro, timeout=min(ms / 1000, left))
    parts = await asyncio.gather(
        stage('vector', 200, fake_io(0.12)),
        stage('bm25',   100, fake_io(0.08)),
        return_exceptions=True,      # 单路失败不拖垮整体
    )
    return [p for p in parts if not isinstance(p, Exception)]

async def handle():
    t0 = time.monotonic()
    try:
        docs = await asyncio.wait_for(retrieve('q', 800), timeout=0.8)
        print('检索完成', round((time.monotonic() - t0) * 1000, 1), 'ms', docs)
    except asyncio.TimeoutError:
        print('整体超时 -> 走降级（用缓存 / 仅 BM25）')

asyncio.run(handle())
# 预期输出：检索完成 120.x ms ['ok(0.08)', 'ok(0.12)']
# 关键点：① wait_for 会真正 cancel 内部协程（IO 必须是 async 的，
#   同步阻塞调用无法被取消）；② gather(return_exceptions=True) 做部分降级；
#   ③ 预算要留余量，别把各层之和写成上限（见 6.3 超时预算表）。

6.4 动手练习与自测

1. 超时预算表：为你的链路写出自上而下的预算表，并断言「下游之和 + 余量 ≤ 上游」。判据：每层有数字，且代码里可取消。
2. 分类重试：实现只重试 408/429/5xx、带指数退避+抖动+全局预算的调用器，注入 500 验证行为。判据：不可重试错误不重试；重试有上限与抖动。
3. 幂等键：给一个写操作加 idempotency key + DB 唯一索引，重复提交返回相同结果。判据：并发重复请求只产生 1 条副作用记录。
4. 熔断验证：注入下游连续失败，观察熔断器从 closed→open→half-open→closed。判据：熔断期间请求快速失败（5 ms 内），恢复后放量试探。
5. 按 token 限流：令牌桶按 token 数计费，验证长请求比短请求更受约束。判据：相同请求数下，长请求的拒绝率更高。
6. 背压：有界队列满时返回 429 + Retry-After，压测观察延迟有界、内存稳定。判据：队列满后 P99 不随负载增长而爆炸。

7. 网络诊断与可观测

7.1 抓包与诊断：从「猜」到「看」

bash# 一套可复制的网络诊断流程

# ① 先用 curl 分段，判断问题在哪一层
curl -w "@-" -o /dev/null -s https://api.example.com/health <<'FMT'
    dns: %{time_namelookup}  conn: %{time_connect}  tls: %{time_appconnect}
    ttfb: %{time_starttransfer}  total: %{time_total}
FMT

# ② 判断是否丢包/重传（重传率高说明链路质量差）
ss -tin state established '( dport = :443 )' | grep -E 'retrans|rtt|cwnd'
#   retrans:x/y  → 重传数 / 总包数
#   cwnd         → 拥塞窗口大小（长期很小说明在持续退让）

# ③ 抓包（只抓关键包，避免文件爆炸）
sudo tcpdump -i eth0 -nn -s 0 -c 200 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0)'
# 导出 pcap 后用 Wireshark 看：Follow → TCP Stream，能看到完整交互

# ④ 看 TCP 层统计（内核视角的全局信息）
netstat -s | grep -iE 'retrans|timeout|overflow|drop'

# ⑤ 检查 TLS 与证书
echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
  | openssl x509 -noout -dates -issuer -subject

# ⑥ 最后才看应用日志 —— 但前五步能排除掉「其实是网络问题」的误判

bash# tcpdump/tshark 常用过滤配方（直接抄）
# 只看握手与挥手（快速确认建连是否有重传）
sudo tcpdump -i any -nn 'tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0 and port 443'
# 抓重传（同一序号重复出现）—— 最直接的质量指标
sudo tcpdump -i any -nn 'tcp port 443' -w retrans.pcap
tshark -r retrans.pcap -q -z io,stat,1 -Y 'tcp.analysis.retransmission'
#   输出按秒的重传计数；重传率 > 0.5% 就该查链路或换 BBR

# 统计 TLS 握手告警（协议层问题）
tshark -r t.pcap -Y 'tls.alert_message' -T fields -e tls.alert_message.desc
#   关注：handshake_failure / unrecognized_name / certificate_expired

# 观察 RTT 随时间膨胀（bufferbloat 的指纹）
tshark -r t.pcap -T fields -e tcp.analysis.ack_rtt | sort -n | tail -5
#   若 RTT 从 20 ms 持续爬到 200 ms 而吞吐不变 -> 缓冲膨胀（见 3.2）

7.2 AI 服务的核心指标与排队论直觉

• 为什么 TTFT 和 TPOT 要分开看：它们由不同阶段决定（预填充 vs 解码），优化手段完全不同。TTFT 受排队 + 预填充影响（优化：批处理调度、前缀缓存、更快的 prefill kernel），TPOT 受解码速度影响（优化：量化、投机解码、更大的 batch 摊薄权重读取）。只看「平均响应时间」会把两者混在一起，导致优化方向错误。
• 排队时间是最灵敏的拥塞指标：当系统接近饱和时，排队时间先于延迟暴涨（Little 定律）。把「排队时间 P95」作为扩容触发条件，比等错误率上升要早得多。
• 按输出长度分桶统计延迟：LLM 的延迟与输出 token 数是线性关系。把长短请求混在一起算平均，会得到毫无意义的数字（长回答拉高均值、短回答被淹没）。正确做法是 P50/P95 都按输出长度分桶。
• 成本也要作为一级指标：每千次请求的 token 成本、缓存命中率、按模型分层的成本分布。没有成本指标，你就不知道一个「优化」到底省了钱还是花了钱。

python# 用 OpenTelemetry 给 Hamauls Orion 的关键路径打点（骨架）
from opentelemetry import trace, metrics
tracer = trace.get_tracer('hamauls_orion')
meter = metrics.get_meter('hamauls_orion')

ttft = meter.create_histogram('hamauls_orion.llm.ttft_ms', unit='ms')
tpot = meter.create_histogram('hamauls_orion.llm.tpot_ms', unit='ms')
tokens = meter.create_counter('hamauls_orion.llm.tokens_total')
queue_wait = meter.create_histogram('hamauls_orion.queue.wait_ms', unit='ms')

async def handle(req):
    with tracer.start_as_current_span('chat.request') as span:
        span.set_attribute('tenant', req.tenant)
        span.set_attribute('output_bucket', req.max_tokens // 256)   # 分桶标记
        # ① 排队：把「进队 → 出队」单独作为一个 span/指标
        t_enq = monotonic_ms()
        async with acquire_slot():
            queue_wait.record(monotonic_ms() - t_enq)
            # ② 检索：内部再拆子 span，才能定位到是哪个子步骤慢
            with tracer.start_as_current_span('retrieve'):
                docs = await retrieve(req.q)
            # ③ 生成：分别记录 TTFT 与 TPOT
            t0 = monotonic_ms(); first = None; n = 0
            async for tok in generate(req.q, docs):
                if first is None:
                    first = monotonic_ms()
                    ttft.record(first - t0)
                else:
                    tpot.record(monotonic_ms() - first - n * 0)   # 实际实现按上次时刻差
                n += 1
            tokens.add(n, {'model': req.model, 'tenant': req.tenant})
        span.set_attribute('output_tokens', n)

python# 容量规划：用 Little 定律反推需要多少并发槽位 / 多少张卡
def channels(lambd, service_time_s, utilization_cap=0.7):
    """所需并发槽位 c 约等于 lambda * service_time / rho，
       rho 为目标利用率上限（不要取 1.0）"""
    rho = min(utilization_cap, 0.99)
    return round(lambd * service_time_s / rho)

c70 = channels(lambd=20, service_time_s=3.0)               # 利用率 0.7
print(f'到达率 20 req/s、单请求 3 s、目标利用率 0.7 -> 需并发槽 {c70} 个')
# 预期：需并发槽 86 个（20*3/0.7 约 85.7）
# 推论：单实例 4 路并发扛不住 —— 需要足够并行度 + 排队控制。

c95 = channels(20, 3.0, utilization_cap=0.95)
print(f'利用率 0.95 时仅需 {c95} 个槽，但排队时间会非线性暴涨')
# 预期：约 63 个槽 —— 看似省资源，实则 P99 延迟失控（见 1.3 Little 定律）
# 结论：容量规划要按 cap=0.6–0.75 设计，而不是按 100% 利用率。

7.3 动手练习与自测

1. 抓包配方：用上面的过滤抓一次真实请求，导出重传率、RTT 分位、零窗口次数。判据：三个数字都能给出并解释含义。
2. 故障注入：给服务端注入 200 ms 延迟，用 curl -w 与 trace 分别定位到「服务端处理」段。判据：能证明这不是网络问题。
3. 指标打点：给一个流式接口加 TTFT/TPOT/排队时间三个 histogram，按输出长度分桶。判据：能回答「P95 慢在排队还是解码」。
4. 容量估算：给定 20 req/s、单请求 3 s，估算所需并发槽（利用率 0.7）。判据：约 86，并说明 100% 利用率的危害。
5. bufferbloat 识别：在 tc netem 下观察 RTT 随时间膨胀，用 tshark 的 ack_rtt 佐证。判据：能指出 RTT 上升而吞吐不变的特征。

8. 小结：给 Hamauls Orion 的网络层定稿（里程碑 M4）

8.1 一份可以直接落地的设计决策表

bash# M4 收口自检脚本：一条命令跑完关键验证（骨架）
set -e
echo '== 1. 连接复用 =='
curl -s -o /dev/null -w 'connects=%{num_connects} total=%{time_total}\n' \
  https://orion.example.com/v1/health https://orion.example.com/v1/health
echo '== 2. 流式未被打断（应持续输出 > 5s）=='
curl -N -s https://orion.example.com/v1/chat/stream -d '{"q":"talk"}' | head -200
echo '== 3. HTTP 版本 =='
curl -sI --http2 https://orion.example.com/ | head -1
echo '== 4. TLS 配置 =='
echo | openssl s_client -connect orion.example.com:443 -tls1_3 2>/dev/null | grep -E 'Protocol|Cipher'
echo '== 5. 证书有效期 =='
echo | openssl s_client -connect orion.example.com:443 2>/dev/null | openssl x509 -noout -enddate
echo '== 6. 重传率（需在服务端执行）=='
ss -tin state established '( dport = :443 )' | grep -o 'retrans:[0-9/]*' | head
# 期望：connects=1；流式输出平滑；Protocol=TLSv1.3；证书 > 30 天；重传率低

8.2 这一阶段真正给了你什么

python# 故障注入测试：验证六件套在"网络故障"下不雪崩（pytest 风格骨架）
import asyncio, pytest

@pytest.mark.asyncio
async def test_timeout_budget_cancels_downstream():
    # 下游故意慢 2 s，但上游预算 0.5 s
    async def slow(): await asyncio.sleep(2); return 'late'
    with pytest.raises(asyncio.TimeoutError):
        await asyncio.wait_for(slow(), timeout=0.5)
    # 判据 1：超时后下游确实被取消（计时断言整体 < 1 s 完成）
    # 判据 2：熔断器连续 5 次失败后进入 open，请求快速失败

@pytest.mark.asyncio
async def test_backpressure_rejects_when_full():
    q = asyncio.Queue(maxsize=2)
    await q.put(1); await q.put(2)
    assert q.full()
    # 判据：满队列时应拒绝（429/503 + Retry-After），而不是无限堆积

@pytest.mark.asyncio
async def test_idempotency_single_side_effect():
    # 同一 idempotency key 并发提交 10 次，DB 只应有 1 条记录
    results = await asyncio.gather(*[submit(key='k-1') for _ in range(10)])
    assert len({r['id'] for r in results}) == 1
# 运行：pytest -q  ->  期望 3 passed
# 这三个用例覆盖「故障不雪崩 / 延迟有界 / 副作用不重复」三条硬标准。

8.3 综合练习与自测

1. 时序图：画出 Hamauls Orion 从点击到流式结束的完整时序，标注每段延迟量级与协议。判据：至少 8 个阶段，含 DNS/TCP/TLS/TTFT/TPOT 数字。
2. 超时预算落地：把预算表写成代码并证明每跳可取消。判据：注入慢下游时，整体在预算内返回降级结果。
3. 故障注入三连：分别注入延迟、丢包、下游 500，验证不雪崩、能降级、能恢复。判据：三个用例全过，且有指标佐证。
4. 协议选型：为「对外聊天 + 对内部检索 + Agent 工具调用」分别选协议并给理由。判据：SSE / gRPC / MCP(HTTP+SSE) 或 Connect，理由含兼容性与流控。
5. 成本-可靠性：给出「缓存命中率上升与取消率下降」对单位成本的量化影响。判据：能算出省下的 token 比例与对应的 QPS 容量提升。

项目里程碑

阶段练习项目

常见误区

• 把「接口慢」都归因为网络，跳过「服务端排队 / 下游串联 / 慢查询」的排查。
• 只用平均延迟做指标，忽略 P95/P99 与「按输出长度分桶」——平均延迟在长尾场景下毫无意义。
• 不设连接池或池太小，跨地域每次请求都在重做 TCP + TLS 握手。
• 流式服务忘了设 TCP_NODELAY 或忘了关代理缓冲，导致 40ms 级卡顿或「内容一次性全部出现」。
• 重试不做分类：对 400/401/403 也重试，放大故障并烧掉配额；或重试不带抖动导致惊群。
• 重试没有幂等保护，Agent 重复下单、重复发邮件。
• 用无限队列「不丢请求」，实际造成延迟无限增长与 OOM。
• 限流按请求数而不按 token 数，导致长短请求的公平性完全失真。
• 超时预算上下游颠倒（下游比上游长），上游已放弃而下游还在空算。
• 忽略 K8s overlay 网络的 MTU，出现「小请求正常、大 payload 幽灵超时」。
• 看到大量 TIME_WAIT 就去调 tcp_tw_recycle（已被移除，NAT 下会误杀连接），而不是先做连接池。

面试高频问题速答

一次 HTTPS 请求的延迟由哪些部分组成？怎么优化？

按阶段拆：① DNS 解析（5–50 ms，优化：缓存、预解析、就近解析）；② TCP 三次握手 1 RTT + ③ TLS 1.3 握手 1 RTT（合计 2–3 RTT，同机房 <1 ms、跨洋可达 300–400 ms，优化：连接池/长连接、HTTP/2 多路复用、会话复用、0-RTT、就近部署）；④ 服务端处理（常常是最大的一块，但这不是网络问题，要分开归因）；⑤ 首字节传输（TTFB）；⑥ 数据回传（传输延迟 = 数据量/带宽，以及拥塞排队）。物理层还有传播延迟（距离/光速），是跨地域的硬下限。优化的优先级取决于测量结果：跨地域先解决握手成本，同机房则要去看服务端。

TCP 为什么是三次握手？四次挥手又为什么不能是三次？

三次握手是为了让双方都确认「自己的发送能力」和「对方的接收能力」：第 1 次服务端确认客户端能发，第 2 次客户端确认服务端能收能发，第 3 次服务端确认客户端能收。两次不够（服务端无法确认客户端收到了自己的 SYN，历史重复 SYN 会导致错误建连）。四次挥手是因为 TCP 是全双工的，两个方向必须分别关闭：客户端发 FIN 只表示「我不再发送」，服务端先 ACK（此时处于半关闭，仍可继续发送数据），等自己数据发完再发 FIN，客户端最后 ACK。第 2、3 步不能合并，因为服务端可能还有数据要发。

TIME_WAIT 和 CLOSE_WAIT 分别说明什么问题？

TIME_WAIT 出现在主动关闭方，等待 2×MSL（约 60 秒）。作用是：① 确保最后那个 ACK 能到达对端（若丢失，对端会重发 FIN，此时还需有连接上下文响应）；② 让旧连接的报文在网络中彻底消散，避免串到同四元组的新连接上。服务端大量 TIME_WAIT 通常说明在频繁主动关闭短连接，解法优先级是：改用连接池/长连接（根本）> 让客户端主动关闭 > 谨慎使用 tcp_tw_reuse。CLOSE_WAIT 表示「对端已关闭，但本端还没调用 close()」，堆积说明代码里有连接泄漏（异常路径没释放），这是 bug 而不是配置问题。

拥塞控制和流量控制有什么区别？BBR 相比 CUBIC 好在哪？

流量控制（rwnd）是「别把接收方撑爆」，由接收方通过窗口字段告知；拥塞控制（cwnd）是「别把网络撑爆」，由发送方根据网络反馈推断；实际发送窗口 = min(rwnd, cwnd)。拥塞控制的演进：Reno/CUBIC 以「丢包」作为拥塞信号——CUBIC 用三次函数增长、与 RTT 解耦，在有线网上表现好，但会把非拥塞原因的丢包误判为拥塞而激进退让，且在缓冲区大的链路上会填满缓冲导致延迟暴涨（bufferbloat）。BBR 不依赖丢包，而是主动测量「瓶颈带宽 × 最小 RTT」来建模管道容量，因此在高延迟、有丢包的链路（跨洋、移动网络）上吞吐显著更高，同时队列延迟更低。代价是与 CUBIC 共存的公平性存在争议。

SSE、WebSocket、gRPC streaming 分别适合什么场景？

SSE 是服务端单向推送，基于普通 HTTP（text/event-stream），代理与 CDN 兼容性最好，内建 Last-Event-ID 重连语义，是 LLM 流式输出的首选。WebSocket 是全双工，通过 HTTP Upgrade 切换到独立协议，适合需要客户端持续上传或极低延迟双向交互的场景（语音、实时协作、游戏），代价是代理兼容性与重连复杂度更高。gRPC streaming 有四种模式（一元、服务端流、客户端流、双向流），基于 HTTP/2 + protobuf，效率高、契约清晰、原生流控，适合服务间调用；浏览器直连需 gRPC-Web + 代理，所以对外通常用 SSE/HTTP、对内用 gRPC。选型判据：方向（单向还是双向）、部署环境（是否有严格的代理限制）、以及是否需要跨语言强契约。

为什么流式输出会卡顿？怎么排查和解决？

最常见的原因有三个：① Nagle 算法与延迟确认叠加——发送端攒小包等 ACK，接收端等最多 40 ms 再回 ACK，导致每个小块可能被延迟 40 ms。解法是设置 TCP_NODELAY，并把 token 聚成小批（如 20–50 ms 或 16 个 token 一批）再发送。② 中间代理缓冲——Nginx 默认会缓冲响应，导致内容被攒起来一次性下发。解法是设置 X-Accel-Buffering: no 与 proxy_buffering off，并在响应头加 Cache-Control: no-transform。③ 中间设备超时断开——长时间无数据会被判定为空闲连接，需要发心跳（SSE 的注释行 `: ping`）。此外还要注意 HTTP/1.1 单域名 6 连接上限导致的排队，以及客户端消费慢造成的反向积压（需要背压）。排查顺序：先 curl -N 直连服务端（排除代理）→ 再加代理 → 再看客户端解析逻辑。

为什么说分布式训练的性能瓶颈可能在网络？怎么算？

以数据并行为例，每次迭代都要做一次梯度 all-reduce。Ring AllReduce 的每卡通信量约为 2(N−1)/N × S（S 是模型参数字节数），N 大时趋于 2S。以 70B 模型 bf16 为例，S ≈ 140 GB，每步通信量约 280 GB；用 400 Gbps（50 GB/s）RDMA 需要 5.6 秒，用 25 GbE（3.1 GB/s）需要 90 秒——后者完全不可行。这解释了为什么大模型训练必须用 RDMA/InfiniBand 与高带宽 NVLink，为什么张量并行只在节点内（NVLink 域）做而数据并行可以跨节点，以及为什么需要通信计算重叠（按层计算完梯度立刻发起 all-reduce，把通信藏在后续反向传播里）与 ZeRO/FSDP（分片降低通信量与显存）。NCCL 还会做拓扑感知选路，所以 GPU 的插卡方式也会影响速度。

学习资源