精华内容：难道说，GFW 通过参考了一篇 GFW Report 研究分析 GFW 识别 FET 的手段和行为的 paper、才实现了识别 FET 的功能、在代码实现过程中还 参考/借鉴/移植 了 AperNet 团队参考 GFW Report 那篇论文 实现并 开源在 GitHub 上的 OpenGFW 代码？
发一个暴论，考虑到比较暴论，所以就只丢我的 TG 频道和 Mastodon 上好了。
这次积至泄漏的疑似 GFW 相关文件 一石激起千层浪，闹得沸沸扬扬，并且可以肯定的是，积至确实开发了一个类似 GFW 的网络审查工具（在下文中，我将其称之为「积至 GFW」），可以按照一定的误伤率支持识别部分 VPN 和隧道协议、并且有主动发现 VPN 的能力（暴论：这个功能一听就像是海外一些国家的定制需求）。
从积至泄漏的源码中关于 FET（即 Fully Encrypted Traffic，Shadowsocks 流量即是 FET 的一个典型且著名的 example）识别功能的实现代码（CPP-based）、存在一段注释、包含下述两个 URL：
- GFW Report 为二作的这篇 paper： https://www.usenix.org/conference/usenixsecurity23/presentation/wu-mingshi
- AperNet 团队（ https://apernet.io ，他们也是 Hysteria 和 Hysteria2 协议背后的开发者）的 玩具 IDS/IPS/DPI 项目 OpenGFW 中基于上述 paper 而实现的 FET 识别功能 https://github.com/apernet/OpenGFW/blob/278d731b6f0df6665e00987fa9e8afa99244d5f6/analyzer/tcp/fet.go
感兴趣的观众可以在积至泄漏文件中找到
/decoders/session_flags/fet.cpp 文件，即可在文件开头看到我所说的包含两个 URL 的代码注释。难道说，GFW 通过参考了一篇 GFW Report 研究分析 GFW 识别 FET 的手段和行为的 paper、才实现了识别 FET 的功能、在代码实现过程中还 参考/借鉴/移植 了 AperNet 团队参考 GFW Report 那篇论文 实现并 开源在 GitHub 上的 OpenGFW 代码？
先有鸡还是先有蛋的问题 听着非常匪夷所思，但是让我们做一个思维实验：如果我们把 2015 年起部署在国际出口和北京根 DNS 镜像上、并历经多年升级迭代至今的 GFW 称作「The True Original GFW（原初 GFW）」；积至根本无法获取到「The True Original GFW」的源码、不得不在开发「积至 GFW」的过程中进行 cleanroom 净室开发，在开发过程中甚至 参考/借鉴/移植 了 AperNet 在 GitHub 上的开源的 OpenGFW 的代码。进一步暴论，积志这套「积至 GFW」和「The True Original GFW」可能 除了都是网络审查工具之外，没有任何其他关系。
我们可以进一步推测：中央控制的网络审查手段可能仍只有「The True Original GFW」一个、且仍只部署在 DNS 和国际出口；地方政府、地方运营商分公司，为了满足各种 KPI（反诈、对异见人士的识别和抓捕、地方网安/网警的行政诉求），向积至和其他厂商招标、定制、采购「GFW 类似物」。这也解释了为什么江苏虽然向积至采购了「积至 GFW」产品，却只用于反诈拦截。
这个暴论完全可以自圆其说，并且也能够解释为什么「GFW 呈现去中心化和边缘计算的趋势」。「The True Original GFW」本身并没有去中心化，可能也没有在多地大量部署；真相可能是，在「中央集权+地方分权」的政治大背景下，整个网络审查制度自发地、自下而上地 实现了去中心化，「边缘计算」只不过是相应的错觉罢了。
然而，网络审查制度的去中心化，只会 让 审查对抗手段 面临更多挑战。