最近一段时间，针对网络连接的战争愈演愈烈，双方都在尝试不同的策略。以至于对于新人来说，很难理解哪些已经发生过，哪些还在尝试中。于是我打算写篇文章来简单介绍一下整个故事的来龙去脉。
史前时代
最早的封锁大约是 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 是通过 SNI。
至此，针对域名，没有封不掉的，只有不想封的。
在直线连接几乎不可能的之后，那就只能绕路了，也就是代理。代理的主要三种模式是 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 协议曾被指出一个严重的安全性问题。 只需要不到 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 的研究和应用都比较少，前景不明朗，观望中。
以上是对翻墙历史的简单总结，希望对新人有帮助。
来自https://cnsteem.com/cn/@v2ray/6knmmb
