实验 3.5：跨网络部署 — 延迟增量来自哪些层？
所属 Day：Day 3 短连接 vs 长连接 前置依赖：实验 3.1 长连接 QPS 对比 更新时间：2026-08-20（重构拆分自原 Day 3 文档，本实验回答 Q4） 环境要求：需要一台公网云主机（本实验用 124.221.142.185，同地域）
一、本实验要回答的问题
前面 4 个实验都在 localhost 上完成——内核协议栈的延迟只有几十微秒，优化空间极有限。但真实部署在公网上：
同一套代码从 localhost 移到公网跨网络后，延迟增加了多少？增加的部分来自哪一层？长连接省下的那 1 个 RTT 在公网下还值不值钱？
本实验要回答的唯一问题：
Q4：localhost → 跨网络部署后，延迟增加了多少、来自哪些层？
这是本项目第一次面对真实网络，也是理解"吞吐优化"与"延迟下限"区别的关键实验。
二、实验设计
2.1 方案
同一套 echo 服务端部署到公网云主机，用同一把尺子分别在**服务器内（localhost）和本地 macOS（远程）**压测：
场景对比：
localhost 短连接 ──┐
localhost 长连接 ──┤ 同一把尺子: bench_py.py
远程 短连接 ──┤ 同一服务端: echo server
远程 长连接 ──┘2.2 为什么换 Python 压测客户端？
C 版 echo-kp-bench 用了 pthread_barrier_t，在 macOS 上无法编译。而远程压测需要在本地 macOS 上运行，于是改用 Python 版 [bench_py.py](/projects/echo/day-03/bench_py.py)——它实现完全相同的短/长连接双模式逻辑。
代价：Python 解释器开销使 localhost 基线（P50 9.9ms）远高于 C 版的 ~55μs。但本实验的结论建立在"同一尺子下的相对增量（远程 − localhost）"之上，增量分解（≈1~2 个网络 RTT）不受工具绝对开销影响。
2.3 操作步骤
# ① 部署服务端到云主机（本地执行）
make deploy REMOTE_IP=124.221.142.185
# ② 云主机启动（ssh 终端）
ssh root@124.221.142.185 /opt/echo/echo-epoll-lt-server
# ③ 服务器内 localhost 基线（云主机 ssh 终端，结果 → results34/lo-*.txt）
for m in short long; do
for i in 1 2 3; do
PYTHONIOENCODING=utf-8 python3 bench_py.py 127.0.0.1 9988 100 10 --mode $m \
> results34/lo-$m-r$i.txt
done
done
# ④ 本地 macOS 远程压测（本地终端，结果 → results34/rm-*.txt，已回传服务器留档）
for m in short long; do
for i in 1 2 3; do
PYTHONIOENCODING=utf-8 python3 bench_py.py 124.221.142.185 9988 100 10 --mode $m \
> results34/rm-$m-r$i.txt
done
done
# ⑤ 前置：公网端口放行（安全组 + firewalld）
firewall-cmd --permanent --add-port=9988/tcp && firewall-cmd --reload
# ⑥ RTT 基线
ping -c 10 124.221.142.185 # 实测 ≈ 9.1ms三、实验数据
数据来源：localhost 基线
/root/echo-day03/results34/lo-{short,long}-r{1,2,3}.txt（2026-08-12 23:30，服务器内自测）；远程/root/echo-day03/results34/rm-{short,long}-r{1,2,3}.txt（2026-08-12 23:39，本地 macOS → 公网，已回传留档）。RTT 实测 ping ≈ 9.1ms。
| 场景 | QPS | P50(μs) | P99(μs) | min(μs) |
|---|---|---|---|---|
| localhost 短连接 | 6876 | 9937 | 30149 | 77 |
| localhost 长连接 | 13912 | 3336 | 14466 | 24 |
| 远程 短连接 | 1391 | 38573 | 380575 | 18785 |
| 远程 长连接 | 2117 | 14442 | 469189 | 7942 |
| 远程延迟增量 | — | 短 +28636 / 长 +11106 | 短 +350426 / 长 +454723 | 短 +18708 / 长 +7918 |
四、实验分析
4.1 min 值是最干净的证据：增量精确等于 1-2 个 RTT
| 指标 | localhost | 远程 | 增量 | 解释 |
|---|---|---|---|---|
| 短连接 min | 77μs | 18785μs | ≈18.2ms | 2×RTT（connect 握手 1 RTT + 应用往返 1 RTT） |
| 长连接 min | 24μs | 7942μs | ≈9.1ms | 1×RTT（纯应用往返） |
远程短连接 min=18.8ms ≈ 2×9.4ms；远程长连接 min=7.9ms ≈ 1×9.4ms。两者之差恰为一个 RTT（9.1ms）——这就是短连接每请求多付的那次额外网络往返。
min 值不受排队、抖动、工具开销污染（取所有请求的最小值），是延迟下限最干净的度量。
4.2 P50 增量分解：长连接 ≈ 1 RTT + 少量抖动
| 指标 | localhost 长 | 远程长 | 增量 |
|---|---|---|---|
| P50 | 3336μs | 14442μs | 11106μs ≈ 1×RTT(9.1ms) + 少量网络栈抖动 |
短连接 P50 增量 28636μs ≈ 2×RTT 再加排队。跨网络后，延迟下限从内核协议栈（~50μs 量级）切换为物理 RTT（~9ms 量级），放大近 200 倍——此时长连接消除的那 1 个 RTT（9ms）远大于 localhost 下 close() 的微秒级开销，长连接的相对收益被放大。
4.3 QPS 波动 vs P50 稳定：公网评估必须双指标
| 指标 | 三轮波动 | 稳定性 |
|---|---|---|
| 远程短 QPS | 154-2095 | 剧烈波动（14×） |
| 远程长 QPS | 898-3691 | 剧烈波动（4×） |
| 远程短 P50 | 36.8-39.9ms | 稳定 |
| 远程长 P50 | 14.1-14.6ms | 稳定 |
原因：P50 由 RTT 下限决定——任何单请求至少 1 个 RTT，抖动无法低于该值；QPS 却被公网突发拥塞、TCP 重传放大——100 并发里只要几十个请求卡顿，总完成时间就翻倍。这解释了为何公网性能评估必须同时看延迟分位数和吞吐，不能只看均值。
4.4 延迟增量的来源分层
| 来源 | 量级 | 本实验证据 |
|---|---|---|
| 物理网络 RTT（主导） | ~9.1ms | min 增量 ≈ 1-2×RTT |
| 远程 NIC 中断/软中断 | 亚毫秒 | 远程 P50 − min ≈ 6.5ms（长连接） |
| 公网拥塞/排队抖动 | 毫秒级随机 | QPS 三轮波动 4-14× |
| 本地内核协议栈 | ~50μs | localhost min 24-77μs |
五、实验结论
- P50 延迟增加约 4 倍：长连接 3336μs → 14442μs；短连接 9937μs → 38573μs。
- 增量可精确分解为网络 RTT：短连接 min 增量 ≈ 2×RTT（connect 握手 + 应用往返），长连接 min 增量 ≈ 1×RTT（纯应用往返），RTT 实测 9.1ms——两模式之差恰好 1 个 RTT。
- 延迟下限从内核栈（μs）切换到网络 RTT（ms）：放大近 200 倍；此时长连接省 1 个 RTT 的价值放大 200 倍，收益从"可感知"变为"决定性"。
- 公网评估要双指标：P50 稳定（RTT 决定下限）但 QPS 波动剧烈（拥塞放大），不能只看均值。
六、回答开头的问题
Q4：localhost → 跨网络部署后，延迟增加了多少、来自哪些层？
答：P50 延迟增加约 4 倍（长连接 3336μs → 14442μs；短连接 9937μs → 38573μs）。增量可精确分解：远程短连接 min=18.8ms ≈ 2×网络 RTT（connect 握手 + 应用往返），远程长连接 min=7.9ms ≈ 1×网络 RTT（纯应用往返），RTT 实测 9.1ms。来源：物理网络 RTT（9.1ms，占绝对主导）+ 远程 NIC 中断/软中断 + 公网排队抖动——本地内核协议栈的 μs 级延迟在公网下几乎可以忽略；也因此长连接在公网下的相对收益被放大（省 1 个 RTT = 省 9.1ms）。
一句话总结：跨网络后延迟下限从 μs 级内核栈跳到 ms 级网络 RTT——增量精确等于 1~2 个 RTT，长连接省下的那 1 个 RTT 在公网下价值放大 200 倍。