(本文原发于 V2Ray.com，由于结构调整，博客内容全部移到了 SteemIt)。
上一篇文章介绍了从用户的角度如何理解翻墙工具，这次我们来讨论一下从工程的角度如何理解翻墙协议，每个翻墙协议有什么差别。
首先，我们来设定一个概念：一个代理（翻墙）协议可能具备的三要素。
一、传输：能在 A、B 两个主机之间建立一条安全可靠的通信通道，用于传输数据；
二、协议：对于将要传输的数据，能将这些数据的目的地告知代理服务器；
三、内容：可以对传输的数据进行优化，比如压缩、合并等。
任何一个翻墙协议都具备以上三要素中的几个或全部。
文字可能较难理解，我们来举一个简单的例子：Socks 协议。Socks 只具备协议要素，即告知代理服务器要把数据发送到哪里去，以达到代理的目的。但众所周知单纯的 Socks 不具备翻墙能力，因为它不能建立可靠的通道（即会被墙）。于是就有了 Shadowsocks。Shadowsocks 在 Socks 的基础上增加了传输要素，对数据加了密，使墙无法分析其内容。而 Shadowsocks 不具备内容要素，因为对于客户端的发来的内容，Shadowsocks 不进行任何修改，直接发送给了代理服务器。
在翻墙过程中，我们可能会使用几个协议的组合，比如 Shadowsocks + KcpTun。无论我们怎么组合，所产生的结果，必须包含传输要素和协议要素，才可以进行可靠的翻墙。
为什么不能单独使用 KcpTun 来翻墙，因为 KcpTun 只有传输+内容要素。KcpTun 只能建立连接，对内容进行一定的处理，比如加密以及其内置的 mux 模式。但它不能发送数据的实际目的地，导致了一定要再套一个其它协议才可以用于翻墙。
而在 Shadowsocks (传输+协议) + KcpTun (传输+内容) 的场景中，由于两者都有传输要素，重复了，以至于 Shadowsocks 的加密在这个场景中多余。因为 KcpTun 已经有加密了，Shadowsocks 再多加一层也没用。
这也就是 ShadowsocksR 最近的几个协议推荐使用不加密的原因。
ShadowsocksR 本质上是对 Shadowsocks 进行了一层封装，即 Shadowsocks + X。这个 X 包含了对协议要素的扩（单端口多用户多种加密方式），加强了传输要素（伪装和其它的加密方式）。和 Shadowsocks + KcpTun 同理，Shadowsocks 本身的传输要素就显得不那么重要了。
而 Shadowsocks 最近也加强了传输要素，即 obfs plugin。两者在要素这一层面相差无几，这也是为什么很多人不认为 ShadowsocksR 之于 Shadowsocks 有很大改进的原因。
顺便整理一下常用协议所具备的要素，仅供参考：
当然，一个翻墙协议的效率和它具备几个要素没有半点关系。以上这些内容只是帮助大家理解每个翻墙协议的侧重点，哪些组合是有意义的，哪些是没有意义的。一个协议组合首先要有意义，其次才能探讨它的效率。
