码厩开发者笔记

#27 批量测试卡死问题排查：路径 MTU 黑洞与超时机制缺陷

今天生产测试机执行批量测试时发生卡死，1252 条用例全部处于等待状态，执行数为 0。进程持续运行但 CPU 占用为 0，日志停在资源清理阶段的 8 个并发 HTTP 请求，此后不再产生响应。

根因是网络路径 MTU 黑洞与程序缺少超时保护共同作用。 测试机访问土耳其区域的两个边缘 IP 时，TCP 三次握手正常，但 TLS 握手始终无法完成。抓包与 DF Ping 测试表明，该路径 MTU 约为 1483 字节，而双方仍按 1500 字节通信；中间设备静默丢弃超限报文，且未返回 ICMP 分片所需错误信息。由于服务端 TLS 响应报文丢失，连接持续重传，客户端始终收不到完整数据。

程序层面，HTTP 请求未配置 timeout_ms 时显式传入 timeout=None，关闭了 httpx 默认超时机制；同时，PLAN SETUP 钩子缺少看门狗，导致资源清理请求无限等待，整个批次无法进入用例阶段。排查未发现本地代码或网络配置变更，问题大概率来自外部链路，具体责任节点尚待云厂商确认。

修复采取网络止血与代码防御两条路径。 网络侧针对两个故障 IP 将 TCP MSS 限制为 1400，并通过 systemd 实现持久化及定时更新。修改后，两条链路的 TLS 握手分别在 0.577 秒和 0.394 秒内完成，HTTP 返回 401，证明连接已恢复。代码侧补充默认 60 秒请求超时、钩子超时看门狗、区域连通性预检，以及 PLAN HOOK 非阻塞失败机制；129 项单元测试全部通过。

截至记录时，MSS 修复已生效，代码已提交，但尚未部署到生产目录，旧批次仍未终止，新批次也尚未重跑。后续需完成部署与回归验收，并向运维部门和阿里云反馈路径 MTU 问题。

经验总结： 网络故障不可避免，但请求必须有超时、任务必须有隔离与降级机制，前置检查应尽早暴露区域故障，避免单个依赖异常拖垮整批任务。

技术原理：PMTU 黑洞与 TCP MSS 钳制

PMTU（Path Maximum Transmission Unit，路径最大传输单元） 是网络路径上能够传输的最大 IP 报文长度。以太网常见 MTU 为 1500 字节，但跨境网络、隧道或中间设备可能将实际路径 MTU 降低至 1483 字节。如果发送端仍按 1500 字节发送报文，而中间设备静默丢弃超限报文，又未返回 ICMP“需要分片”消息，双方就无法正确调整报文大小，形成 PMTU 黑洞。

TCP 的 MSS（Maximum Segment Size，最大报文段长度）用于限制单个 TCP 段的数据载荷，不包含 IP 和 TCP 头部。IPv4 无选项时，两者通常合计占用 40 字节。因此，MSS 设为 1400 时，单个 IP 报文通常不超过 1440 字节，低于本次实测的 1483 字节路径 MTU，可以避开超限丢包。

# 检查规则是否存在；如果不存在，则追加规则。
iptables -t mangle -C OUTPUT -p tcp --syn -d 100.100.100.100 -j TCPMSS --set-mss 1400 2>/dev/null || \
iptables -t mangle -A OUTPUT -p tcp --syn -d 100.100.100.100 -j TCPMSS --set-mss 1400

Linux 使用 iptables 的 TCPMSS --set-mss 1400 修改本机发出的 SYN 报文中的 MSS 通告值，使对端在后续发送数据时采用更小的 TCP 段。该规则只影响新建连接，不会修复已经建立的卡死连接。需要注意，MSS 是 TCP 载荷上限，并非绝对报文长度保证；TCP 选项、封装开销等因素仍需考虑。

本次实测中，修复前 TCP 连接成功但 TLS 握手超时；钳制 MSS 后，两个故障 IP 均返回 HTTP 401，且 TLS 握手恢复，证明网络连接已恢复。401 表示请求到达应用层但缺少有效鉴权，并不代表业务请求成功。

#26 网络代理与隧道技术的本质关系

网络代理、反向代理、负载均衡、SSH 隧道、VPN 以及各类加密代理协议，本质上都属于同一类问题：如何在不同网络约束下转发通信流量。其差异主要来自工作层级与封装方式不同。

代理（HTTP Proxy、SOCKS5）运行在应用层，客户端显式通过代理发起请求，由代理服务器代为连接目标。它解决的是“替我访问目标”的问题，典型特点是协议感知强、应用可控性高，但覆盖范围有限。

反向代理（如 Nginx、HAProxy）则站在服务端入口，接收外部请求后分发到内部服务，核心价值是负载均衡、安全隔离、缓存与流量治理，本质是“统一入口调度后端资源”。

隧道技术（SSH Tunnel、VLESS、OpenVPN、WireGuard 等）则更抽象，其核心是将一种网络流量封装进另一种连接中传输，在另一端解封还原通信。它强调“透明传输”，不关心上层协议内容，目标是穿越网络限制或构建虚拟通道。

VPN 属于隧道的系统级实现，在网络层建立虚拟网卡，使所有流量透明进入远端网络；而 SSH、TLS-based proxy、V2Ray/Xray 等属于应用或传输层隧道实现，通过不同协议组合增强隐蔽性与适应性。

现代代理体系（如 sing-box、Xray）本质是“协议编排框架”，将代理、隧道、加密、传输层解耦组合，实现灵活网络接入能力。

总体来看：代理强调“代为连接”，反向代理强调“流量治理”，隧道强调“封装传输”，VPN强调“网络重构”。它们共同构成从应用层到网络层的完整通信抽象体系。

#25 防火墙技术演进 [编辑中]

:) 本文正在编辑中，暂时不提供浏览...

#24 systemd-networkd 网络管理工具

#23 Wi-Fi 6 还没用上，Wi-Fi 7 又来了

• 802.11a 其实早于 802.11b 提出，只是因为一些非技术原因，推广滞后
• 2000 年，Wi-Fi 这个词被提出，无线以太网兼容性联盟（WECA）更名为 Wi-Fi 联盟（Wi-Fi Alliance，缩写 WFA）
• Wi-Fi 一词，国内通常读作 歪fai，有一些人引经据典提出过不同看法引发争议
• Wi-Fi 0、1、2、3 不是官方认定的名称
• WEP：有线等效加密（Wired Equivalent Privacy），又称无线加密协议（Wireless Encryption Protocol）
• WPA：Wi-Fi Protected Access （Wi-Fi 访问保护）

现状

市面上大部分路由器都是支持 Wi-Fi 1 - 5，常常可以在广告上看到 IEEE 802.11a/b/g/n/ac 字样。
旗舰型，贵一点的（至少 300+），支持 Wi-Fi 6。

我没有做过这方面研究和对比，只能说理论上：

1. Wi-Fi 6 速率上限有了提升，网络质量也有优化，同时能耗降低（TWT），能够同时支持更多终端连接（OFDMA），同时支持更多并发数据传输（MU-MIMO）。
2. Wi-Fi 6E 引入了 6GHz 频段，能支持更高的速度和更低的延迟。

目前我家的路由器，手机，其他设备大多还不支持 Wi-Fi 6。
我家的有线网络用的 5 类线，所以我家理论上最高网速也就 100Mbps（12MB/s）。

Wi-Fi 7

1. 支持最大 320MHz 带宽（Wi-Fi 6 是 160MHz）
   新的带宽模式：连续 240MHz、非连续 160+80MHz、连续 320 MHz、非连续 160+160MHz
   主要作用是提升 QoS（减少延迟，降低丢包率）
2. 支持 Multi-RU 机制
3. 引入更高阶的 4096-QAM 调制技术（Wi-Fi 6 是 1024-QAM）
4. 引入 Multi-Link 多链路机制
5. 支持多 AP 间的协同调度
   网络漫游问题

我不太懂。
场景应该是一些工业和商业场景。家用的话，可能只有土豪的游戏设备（VR 游戏？）才能用得上，或者发烧友自己搭建的家庭网络设施。
想必和 Wi-Fi 6 / 5G 一样，对绝大多数普通人来说，只是一个新的营销噱头。

参考资料与拓展阅读

• 维基百科，Wi-Fi

Wi-Fi（发音： /ˈwaɪfaɪ/），又称“无线网络”，是 Wi-Fi 联盟的商标，一个基于 IEEE 802.11 标准的无线局域网技术。“Wi-Fi”常写作“WiFi”或“Wifi”，但是这些写法并没有被 Wi-Fi 联盟认可。

1999 年，几家富有远见的公司联合起来组成了一个全球性非营利性协会——无线以太网兼容性联盟（Wireless Ethernet Compatibility Alliance, WECA），其目标是使用一种新的无线网络技术，无论品牌如何，都能带来最佳的用户体验。在 2000 年，该小组采用术语“Wi-Fi”作为其技术工作的专有名称，并宣布了正式名称：Wi-Fi Alliance。

• 百度百科，Wi-Fi 7

第七代 WiFi 无线网络，速度可高达 30Gbps，是 WiFi 6 最高 9.6Gbps 速率的三倍之多。相比于 Wi-Fi 6，WiFi 7 将引入 CMU-MIMO 技术最多可支持 16 条数据流，8 车道变 16 车道，妥妥的星际高速公路，其次 WiFi 7 除传统的 2.4GHz 和 5GHz 两个频段，还将新增支持 6 GHz 频段，并且三个频段能同时工作。
2021 年 12 月，联发科宣布 2022 年初将推出 WiFi 7 网络，此前数据显示其网速是 Wi-Fi 6 的 3 倍多。在 2022 年世界移动通信大会（MWC 2022）上，中兴推出 WiFi 7 标准的产品。

• WiFi 革新！WiFi 6 和 WiFi 6E 详解
• 20 Years of Wi-Fi
• 华为，什么是 WiFi 7？

#22 IP 地址的其他写法

There’s more than one way to write an IP address 介绍了 IP 地址的另外几种不常用表示方法。

#21 VPN 与 NAT（续）

2021/05/09，VPN 与 NAT 讲了我使用 Windows route 命令和 Linux iptables 命令做 NAT，实现 Windows 机器的 VPN 流量走 Linux 的指定网络设备。
现在情况可能会发生一些新的变化，所以这里记录一下我的几点思路。

#20 ping github.com 得到 127.0.0.1 问题

git clone git@github.com:tornado/tornado
Cloning into 'tornado'...
ssh: connect to host github.com port 22: Connection refused
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

ping github.com

正在 Ping github.com [::1] 具有 32 字节的数据:
来自 ::1 的回复: 时间<1ms
来自 ::1 的回复: 时间<1ms
来自 ::1 的回复: 时间<1ms

::1 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 3，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 0ms，最长 = 0ms，平均 = 0ms
Control-C

ping -4 github.com

正在 Ping github.com [127.0.0.1] 具有 32 字节的数据:
来自 127.0.0.1 的回复: 字节=32 时间<1ms TTL=64
来自 127.0.0.1 的回复: 字节=32 时间<1ms TTL=64
来自 127.0.0.1 的回复: 字节=32 时间<1ms TTL=64

127.0.0.1 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 3，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 0ms，最长 = 0ms，平均 = 0ms
Control-C

nslookup github.com
Server:         192.168.31.1
Address:        192.168.31.1#53

Non-authoritative answer:
Name:   github.com
Address: 127.0.0.1
Name:   github.com
Address: ::1

配置 DNS 为 AliDNS 223.5.5.5，233.6.6.6：

nslookup github.com
Server:         223.5.5.5
Address:        223.5.5.5#53

Non-authoritative answer:
Name:   github.com
Address: 20.205.243.166

问题依旧。

ping 20.205.243.166

正在 Ping 20.205.243.166 具有 32 字节的数据:
请求超时。
请求超时。
请求超时。

20.205.243.166 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 0，丢失 = 3 (100% 丢失)，
Control-C

ping baidu.com

正在 Ping baidu.com [39.156.66.10] 具有 32 字节的数据:
来自 39.156.66.10 的回复: 字节=32 时间=23ms TTL=52
来自 39.156.66.10 的回复: 字节=32 时间=24ms TTL=52
来自 39.156.66.10 的回复: 字节=32 时间=23ms TTL=52

39.156.66.10 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 3，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 23ms，最长 = 24ms，平均 = 23ms
Control-C

总结：

1. hosts 没有特殊配置
2. 改成可用 DNS，问题没有修复
3. ipconfig /flushdns 也不管用
4. 重启也没有好

那就奇怪了，这个 ping 里面的本地回环地址是哪里来的呢？

最后，

ipconfig /displaydns 可以看到，还是用的回环地址
ipconfig /all 发现还有一个 DNSv6 配置。。。

DNSv6 设置成 AliDNS 的 IPv6 地址：2400:3200::1，2400:3200:baba::1 再试，

ping github.com

正在 Ping github.com [20.205.243.166] 具有 32 字节的数据:
请求超时。
请求超时。
请求超时。
请求超时。

20.205.243.166 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 0，丢失 = 4 (100% 丢失)，

终于好了。😂

事情的起源是 git clone 失败，最后 git clone 可以了。
ping 不通，可能是网络问题，也可能是 github 网络配置。
这就不管了。

#19 办公网络中的安全问题

同事发来消息，说是我的电脑经过安全扫描，判断有风险。提了以下几条改进意见：

1. SMB 共享，风险高，希望限制访问，并强制执行消息签名。
   改进：其实现在我很少使用 SMB 共享了，直接关闭了事。
   PS: 其实在用 SMB 共享，所以重新开启 smbd 并禁止匿名访问。

2. 开启了 IP 转发，风险中，建议关闭。
   IP 转发功能对我的工作是非常必要的，不能关闭
   之前的文章, 2021/05/09, VPN 与 NAT 有讲过这个问题。
   改进：调整 iptables 规则，only ACCEPT 指定链路 FORWARD

3. 3Proxy HTTP 代理（端口 10809）只做透明请求远程溢出，风险高，建议升级 3Proxy 版本。
   我没有安装什么 3Proxy, 这个端口是其他 HTTP 代理服务的端口（不排除底层使用了 3Proxy）
   改进：我直接将其改成监听 127.0.0.1 了事

#18 转载：防火墙的原理

每一个中国开发者都必须去了解这个我们无法避开的网络特性。