V2Ray、Trojan、XRay
本文仅介绍 V2Ray、Trojan、XRay 之间的关系和部分协议的技术科普。
V2Ray 是 Project V 项目下的一个核心工具也就是现在的 V2Ray-Core，主要负责网络协议、路由等网络通信功能的实现。
什么是 Project V？
Project V 现在是一个自定义通信网络的工具集合。Project V 最初是 V2Ray 的项目名，因 V2Ray 大热之后由众多参与者将其拓展成一个 V2Ray 周边生态项目，所以现在的 V2Ray-Core 可以当作是最开始的 Project V（现在 V2Ray-Core 的 README.md 仍旧保留着最开始的项目名： Project V）。
因 V2Ray 优秀的设计和高度定制化能力，在自定义通信网络领域很长一段时间风头无两，当然也因此埋下了隐患。
什么是 V2Fly？
起因是 V2Ray 项目创始人 Victoria Raymond 突然失联，由于其他维护者没有完整的项目权限，于是大家创建了新的社区：V2Fly，后续关于 V2Ray 的更新都由 V2Fly 社区负责。
TLS 流量识别风波
V2Ray-Core 在 TLS 实现上有一个硬编码的 Cipher Suites 列表，导致 TLS 流量可被简单特征码匹配精准识别，点此参查看讨论。
即使成立了新的社区，V2Ray 本身的更新和维护都很稳定，主打的 VMess 协议也一直都没什么问题，协议本身不做过多介绍。
VMess 协议主动识别风波
通过重放攻击的方式就能准确判定是否为 VMess 服务，该事件对 V2Ray 的伤害可以说是致命的，点此查看讨论，此后诞生了 VMessAEAD。
VMess 本身设计是重在安全，所谓「饱暖思淫欲」，在保障安全性的前提下大家对速度和性能又有了更高的追求，于是另外一款工具以一个全新的设计思路进入了大家的视野：Trojan。
我觉得 Trojan 流行的一个很重要的外部因素是 HTTPS 的覆盖率大规模提升。
Trojan 设计的巧妙点在于它直接使用 HTTPS 通信，所以它从流量特征上看就和海量的 HTTPS 流量一样，「大隐隐于市」，点此可查看设计思路讨论。
由于它的设计很简单，只使用 TLS 做为可信通道，其他加密一概没有，在不增加附加功能的前提下，核心通信功能可以很稳定，从它的迭代周期也能看出来。
由于 Trojan 是 HTTPS 通信，所以主要性能消耗在 TLS 这块，在保障安全性的前提下 Trojan 也有相当不错的性能。
当然 Trojan 在设计上也有缺点，就是它必须直接对接流量入口，这会导致 443 端口占用的问题，不过目前已经有完整的解决方案了，点此可以查看解决方案。
优秀的模仿者 Trojan-Go
Trojan-Go 是使用 Go 实现的一个 Trojan，在功能上是 Trojan 的超集。它新增了很多功能：多路复用、自定义路由、CDN 转发等等，但是最底层协议还是原版 Trojan。
既然 Trojan 的思路是可行的，那为什么还要在 TLS 上再加一层 VMess 等自定义加密协议呢？保险箱里套保险箱，对于绝大部分用户来说除了性能损耗，都无必要，于是 V2Ray 的 VLESS 协议也应运而生。
VLESS 协议也出自 V2Fly 社区，我觉得它和 Trojan 的设计思路差不多，都是基于可信通道传输，本身不再做额外的加密处理。Trojan 的可信通道是使用 TLS，VLESS 目前看文档更通用点，不局限于 TLS，但也没给出其他可信通道的例子。
凡是「类 Trojan」的设计，都绕不开一层「可信通道」，Trojan 使用的是 TLS，目前看来也是最佳的选择，前面也说过性能损耗也在 TLS，于是关于如何提升 TLS 性能的 XTLS 协议就诞生了。
XTLS 协议的原理是将代理过程中的两条 TLS 请求合并成一条 TLS，减少一次 TLS 加密过程来达到提升性能的目的。
当我们使用基于 TLS 的代理浏览 HTTPS 网站、刷手机 APP 时，其实是两层 TLS：外层是代理的 TLS，内层是网站、APP 的 TLS。
XTLS 从第二个内层 TLS data record 开始，数据不二次加解密，直接转发，无缝拼接了两条货真价实的 TLS，从外面看还是一条连贯的普通 TLS，因此绝大多数流量无需二次加解密了。
目前关于此的资料较少官方文档暂未更新，点此查看 Release 介绍。
XTLS 协议也出自 V2Fly 社区，但是因为 License 问题从 V2Ray-Core 中被移除了，点此可查看关于 License 的讨论，实际上 Telegram 上讨论更多，最后 XTLS 协议的作者独立出来成立了 XRay 社区。
XRay 是 Project X 项目下的一个核心工具也就是现在的 XRay-Core，和 V2Ray-Core 类似主要负责网络协议、路由等网络通信功能的实现，但在功能上是 V2Ray-Core 的超集，VLESS 两者都有，但是 XTLS 只有 XRay 支持。
什么是 Project X？
XTLS 协议的作者独立出来成立了 XRay 社区，与 Project V 对应的就是 Project X。
对于个人选择，其实线路是体验最大的影响因素，垃圾线路怎么优化都是没用的。
当然没有特殊目的最好不要套 CDN 的，多一次中转，无论如何都会有损耗，即使用什么「自选 IP」。
然后 UI 工具的选择应该是平台支持全、体验好，最后才是底层通信工具的选择。
底层工具的选择应该是：安全性 > 稳定性 > 速度。
综合看下来，目前的最优选择还是「类 Trojan」方案，该类方案的缺点也说过，TLS 损耗比较大，要是 TLS 优化能最好那肯定是最优解了。毕竟 TLS 是互联网界验证、认可的协议，也是现在互联网安全传输的基石，复用前人的东西，比自创的协议要成熟稳定的多。
目前看 XTLS 有希望，但是 VLESS、XTLS 都没有出稳定版，周边生态的支持力度和稳定性都不够，所以最后的选择其实只有 Trojan、V2Ray（选用不加密 VMess 和 TLS）。
因为 XTLS 是一种自定义的交互协议，目前只能在 XRay 上使用，而我使用的 Clash 就没支持，目前看来也没有明确的支持计划，由于有较多的 Clash 自定义规则，遂放弃。
同时不断被大家提到的 V2Ray/XRay「协议回落」，其实也是新瓶装旧酒，但是如果能做稳定那还是方便很多的，因为里面的细节不少。
最后我个人使用的是 Trojan，我觉得它的设计简单、高效、稳定，充分体现了「奥卡姆剃刀原则」。
如无必要，勿增实体。
奥卡姆剃刀原则
关于开源项目，「历史总是惊人的相似」：项目大火、组建社区、创始人失联、重建社区、因故分叉、其一烂尾。
XRay 和 V2Ray 在核心功能上已然是超子集的关系，一旦丧失了独特性，独立存在的必要性如何？