ECH 在网络审查环境下的实战表现：一个有趣的对比实验

最近在折腾一些网络协议，无意间做了一个关于 ECH（Encrypted Client Hello）的小实验，结果还挺有意思的，分享给各位技术党。

背景设定

这次测试的环境很简单：目标服务器部署在国内。为了测试不同客户端在加密握手时的表现，我分别从国内和海外两个节点发起访问请求。核心目的是看看在现有的网络环境下，标准的 ECH 握手包能不能“活”下来。

测试结果大相径庭

一开始我预想可能大家都差不多，但现实打脸了。

1. 国内发起： 毫无悬念，因为流量根本不出境，无论是啥请求，响应都一切正常。

2. 海外发起（普通工具）： 当我在海外节点使用 gocurl 这类命令行工具发起请求时，情况突变。链接直接被 RST（复位）了，连个像样的握手都没谈拢。

3. 海外发起（主流浏览器）： 换成 Firefox 或 Chrome 后，画风突变。竟然能正常打开页面，响应完全正常。

这就有意思了，同样是发 ECH，怎么浏览器就能“幸免于难”？

深入抓包分析：细节藏着魔鬼

为了搞清楚原因，我祭出了 tcpdump 进行抓包分析，这一看就明白区别在哪了。

gocurl 的遭遇： 当 gocurl 发出标准的 ECH Client Hello 包时，这个“特征”太过明显。发出之后，紧接着网络侧就回馈了 3 个 RST 包。这说明中间设备识别到了 ECH 的特征指纹，然后无情地把连接掐断了。对于常规的工具库来说，TCP 发包往往比较老实，讲究有序、完整，结果反倒成了活靶子。

浏览器的“鸡贼”策略： 再来看 Firefox 和 Chrome 的抓包记录。你会发现它们的包到达时是乱序的，甚至是被切片的。这可不是网络环境不好，而是现代浏览器的主动防御策略。

为了对抗各类深度包检测（DPI），主流浏览器在发送 TLS Client Hello（尤其是包含 ECH 这种高级特性）时，往往会利用 TCP 的特性，故意把握手包拆分成多个小段，并且打乱顺序发送。这样一来，审查设备在收到第一个分片时，拿不到完整的握手特征，很难实时判断这是不是 ECH 流量。等所有分片重组完成时，连接往往已经建立起来了。

总结与思考

这个实验其实给我们在搞网络穿透或者是部署服务时提了个醒：

• 工具的选择很重要： 如果你直接用普通的 HTTP 库或者命令行工具去跑 ECH，很可能分分钟被墙。因为它们缺乏针对 DPI 抗性设计的发包逻辑。
• 流量特征要伪装： 真正的“黑科技”不仅仅是加密内容，还要在传输层的“姿态”上下功夫。浏览器那种 TCP 分片加乱序的手法，虽然简单，但在对抗识别上非常有效。

如果你也在研究类似的网络技术，建议多关注一下发包层面的细节。单纯协议层面的加密，在现在这个环境下往往是不够的。