最近一段时间，针对网络连接的战争愈演愈烈，双方都在尝试不同的策略。以至于对于新人来说，很难理解哪些已经发生过，哪些还在尝试中。于是我打算写篇文章来简单介绍一下整个故事的来龙去脉。

![](https://steemitimages.com/DQmfZQPcjvrMyxudBgTcv2MjCUbzQ9cQkn15ZF2kNwsbtJ2/image.png)

## 史前时代

最早的封锁大约是 DNS 投毒和 IP 黑名单。具体细节这里不表，简单来说就是 1) 对于特定域名比如 google.com，你的浏览器解析不到正确的 IP 地址； 2) 即使碰巧解析到了正确的 IP 地址，由于 Google 在亚洲地区的 IP 地址就那么几个，发往这几个 IP 地址的数据包被全部丢弃（或 TCP Reset），也就导致了用户死活访问不到 google.com。

## 攻防战 1.0

由于被封的 IP 依然是少数，而 Google 在全球的 IP 数量庞大，于是网友们很快想到了解决方案，就是使用 hosts 文件指定 IP 地址。虽然亚洲地区的 IP 被封了，但美国、欧洲甚至是南美洲依然有可以访问的地址，速度慢是慢了点，但总比上不去的好。于是 hosts 文件这个方案流行了那么一段时间。

后来封锁升级了，不是针对 IP 地址的了，而是针对每一个网络连接。受限于为数不多的几个出入境节点，网民的每一个出境网络连接实际上都被扫描过一遍。于是网络协议最初设计时，并未考虑封锁这回事，无论是 HTTP 还是 HTTPS，只需要扫描每个连接的前几十个字节，就可以得到其目标地址（域名）。HTTP 是通过其 [Host 头](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host)，而 HTTPS 是通过 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication)。

至此，针对域名，没有封不掉的，只有不想封的。

在直线连接几乎不可能的之后，那就只能绕路了，也就是代理。代理的主要三种模式是 Socks、HTTP 和 VPN。三种模式各有利弊：

* Socks 可以代理 TCP 和 UDP 连接，但其数据包是明文的，依然逃不过上述检测；
* HTTP 可以有 TLS 加持，但只能代理 TCP 连接，对 UDP 无效；
* VPN 可以代理包含 TCP / UDP 在内的各种连接，但 VPN 会转发几乎所有的数据，在可以访问 Google 的同时，可能就不能访问优酷了（地区限制）。

然后 Shadowsocks 横空出世。

Shadowsocks 本质上是 Socks 的加密版本，可选择多种加密方式。一旦加了密，其传输的数据就无法被第三方检测了。并且 Shadowsocks 在转发数据之前，可以对其目的地进行判断，比如可以只转发去往 Google 的流量，而优酷的流量依然直连。在经常一段时间的优化之后，Shadowsocks 可以达到一个全局较快的连接速度，比上述的几个代理方式都要好。

由于 Shadowsocks 太过火爆，其作者被公安机关约谈，勒令不得继续参于相关项目的开发。

## 攻防战 2.0

中国那么多人，要把相关人员一一找出来喝茶，也不是一件容易的事。封锁这事，还得从网络连接着手。

对于一台国内的机器往一个国外的服务器发送数据的网络连接，有两种检测方式，被动式和主动式。

被动式是指检测方只观察连接中传输的内容，当内容符合某种模式（比如关键字）的时候，就把连接中断，或者服务器 IP 列入黑名单。上述的所有封锁方式均为被动式。

而主动式指的是，当观察到一个不可识别的连接时，检测方主动发起一个去往服务器的连接，通过一些编造的数据，探测出服务器是不是一台代理服务器。

Shadowsocks 协议曾被指出一个[严重的安全性问题](https://breakwa11.blogspot.ch/2016/09/shadowsocks.html)。只需要不到 16 次主动探测，就可以 100% 断定服务器是否在运行 Shadowsocks。具体来说，初版 Shadowsocks 协议依赖于连接头部的某一个字节来读取目标地址，这个字节的取值只有三种。当这个字节的取值不合法时，Shadowsocks 会快速中断连接，否则继续读取剩下的内容。于是这一特征可被用于探测一个服务器是否为 Shadowsocks 代理。

为了应对这一探测方式，Shadowsocks 对其加密方式升级了两次（OTA 和 AEAD）。目前看来这一漏洞，以及其它可能的主动探测方式，都被避免了。

同时期还有多个流行的翻墙工具，其原理和 Shadowsocks 大同小异，这里略过。

## 番外篇 1.0

既然代理工具有漏洞，那么检测工具也一会有漏洞。只要发现并利用这些漏洞，一样可以突破封锁。

曾经有一个项目“西厢计划”，就是利用了检测工具的漏洞，伪造了一些数据包，使它在检测方看上去上一个网络连接，但在目的服务器看来又是另一回事。检测方以为自己已经封锁了该连接，但实际上并没有。

和 Shadowsocks 的升级一样，检测方的算法也一样可以升级。升级之后，西厢计划便失效了。

## 攻防战 3.0

从信息学的角度来说，Shadowsocks 协议是一个近乎完美的协议。它的数据完全随机，无法 100% 确定这个网络连接是否为 Shadowsocks。但从另一方面来说，网络数据并不是均匀分布的，保守来说，HTTP 和 HTTPS 流量占据了 70% 以上。而如果一个服务器接收的流量 90% 是杂乱无章的，那么它就很可疑了。虽然检测方不能严格证明那就是 Shadowsocks，但秀才遇到兵啊……

既然随机数据可疑，那我们就把数据伪装成 HTTP 或者 HTTPS 好了。由于 HTTPS 是大势所趋，并且 HTTPS 传输的内容天生不可能被破解，把代理数据伪装成 HTTPS 也是一个比较合理的选择。

由于检测方无法判断一个   HTTPS 连接是正常的网站流量，还是代理。如果封锁所有的 HTTPS 流量，那无疑是一个杀敌五百，自损一千的昏招。当然急病乱投医也是有可能的……

## 第二战场 1.0

所有的代理工具都不是系统自带的，用户使用代理工具之前，需要先下载和安装。于是封锁下载途径也是一种封锁。Apple 就按要求移除了所有 VPN 应用。此战场防御方完败 😂

**目前明面上的攻防到此为止，接下来说说一些想法和揣测**

## 攻防战 4.0

虽然流量经过了加密，但加密的只是内容，不能排除还有其它的特征。比如 TLS (HTTPS 所用的加密协议）的握手环节，客户端和服务器互相发送的数据是有规律的。比如握手三次，每一次的数据量大致是固定的。如果有一个连接，也有三次握手，每一次的数据量和 TLS 相当，但是内容是混乱的，那么这个连接是不是 Shadowsocks 连接呢？当然 Shadowsocks 有一些额外的数据，这个另说。

目前翻墙圈在这一问题上有很大的争论。对于检测方是否足够强的技术做类似的检测，以及是否有足够的把握只封代理都存在疑惑。但毫无疑问，这将是下一个值得研究的领域。

另一个热点是分布式或者P2P。

这一领域已经被 Tor 证明为成功或者失败了（取决于你怎么看待 Tor）。我个人不喜欢 Tor 因为它速度太慢。虽然 P2P 这一术语最近很热，听上去也很有希望，但实际上它并不适用于翻墙。翻墙的过程需要【墙内的P】2【墙外的P】，并不是任意两个 P 都可以自由组合的。

目前对翻墙 P2P 的研究和应用都比较少，前景不明朗，观望中。

以上是对翻墙历史的简单总结，希望对新人有帮助。