协议原理

加密方式使用AEAD，最安全，不会被破解

加密过程使用密码以及加密方式对数据进行加密，穿过防火墙之后，服务器解密就知道我们需要访问的网站了。

裸奔的ss协议的话，已经可以被防火墙精确的探测到了。他只发送了一个重放的数据包就直接可以探测到你的这个运行了shadowsocks的服务器

插件会对数据流量进行伪装，把数据伪装成http流量，会对数据加上http数据头

服务器也用插件去除http头部，然后再处理

主要起到的作用就是流量伪装

由于ss协议发送的数据他完全就是无规则的字节流，数据经过防火墙的时候他发现他完全看不懂你的数据于是他怀疑你的数据被加密了，然后的话他就会往你这个vps发送一个探测包。经过他的探测手段之后发现你运行了ss服务于是就把你跟这个端口的连接给屏蔽了当我们加了插件之后ss协议发出的无规则字节流，就会经过插件处理然后再发到互联网上，主要是把字节流伪装成正常的http流量

trojan

它是一种天生就是将数据伪装成https流量来达到科学上网的目的。

目前由于tlsintls能被探测到，因此这个协议也不安全，重点ip段还是被封。

之后引入的xtls能解决这个问题，reality也可以

因为trojan的话它完全是模仿https的流量，所以说我们要搭建trojan的话也必须要先给trojan这台服务器申请一个证书来开启https的访问

trojan的密码它并不是用来对数据进行加密的而是用来进行身份认证的。身份验证失败就会跳转到别的网址

首先对于一条请求，会使用tls进行加密：

但是这条请求不能直接发到服务器，因为sni信息是谷歌，会被直接阻断

之后来到客户端加上trojan协议头，包括trojan密码信息：

之后来到tls层，在使用我们自己的证书加密：

这样就可以通过防火墙了

trojan如果收到的数据包没有trojan协议头，他不属于trojan的流量，他也会把设定的网站的数据返回给你

注意：设置失败跳转的网站是80端口，所以是没有加密的，最终不是属于跳转，而是属于代理

VMess

VMess 使用非对称格式，即客户端发出的请求和服务器端的响应使用了不同的格式。

v2ray它是一个网络工具它原创了并支持vmess协议同时也支持shadowsocks、trojan，vless等代理通讯协议

• vmess协议为什么和系统时间有关

• 为什么加密方式可以使用自动选择

• 额外id到底是个啥

现在vmess协议的话他也是强制开启了AEAD，额外id必须是0

因为加密方式选择的是auto，它就会自动选择一种，比如说aes。同时也会生成一个随机的密钥，比如说111。

有了这个密钥和加密方式之后就可以对这一串数据进行加密了这里面还有一些其他的参数我们就不管

vmess就会用这个密钥和这个加密方式对这一串数据进行加密

做完这一步之后vmess还会用用户uuid来对这一串数据进行加密

也就是使用这个11-11-11-11对这一串进行加密，他的加密方式的话是固定的

除了这两次加密，还没完，他还会在头部插入数据，这里面插入的数据是我们当前的系统时间的一个时间戳加上用户id组成的这么一个hash字符串

最后的话我们将会在头部加上我们的服务器的IP地址6.6.6.6

服务器拿到数据：

整个数据包格式形式：

服务端拿到这个数据之后他要验证这个是不是一个合法的vmess数据，他是怎么验证的呢他验证的方式就是对比头部的这一串数据到底是不是合法的

这个hash字符串是不可逆的，所以他会寻找前后一段时间来进行计算，如果刚好能算出这个hash，那么就算合法数据。

之后就是逐级解密。

如果你的系统时间和服务器的时间相差超过了90秒，他们算出来的时间戳就不在一个范围之内时间戳不在一个范围之内的话他计算出来的hash值就不对，就没法认证通过

还有一个问题是这个额外id又有什么作用可以看到我们这里的额外id两边数字的是不一样的

我们的客户端会随机取一个+-30秒的这么一个时间戳，如果我在短时间之内发送了大量的请求的话，假设这个随机值不够用了，这两个出现了重复，这两个数据包头部计算出来的hash值是一模一样的，可能会被防火墙探测到一些特征。

于是乎引入了这个额外id。这个额外id的作用呢就是在这个id的基础上，额外的再生成一个id比如说这个是111在这个基础上我生成了一个11-11-11-12，相当于我现在有两个id了，可以换个ID来组合，就不会出现hash值一样的情况

我们的服务器就要跟着把这个额外id设置成1或者比1大。因为大是没关系的，就是不能小。

可以看到他传输的内容其实跟ss节点是差不多的都是无规则的字节流，但是他的话比ss协议更复杂一点。另外，我们刚才讲了这么多，其实这种方式的话已经被淘汰了。被淘汰的原因是他存在被精准探测的漏洞

因为我们头部的这个数据的话他在一定时间内他是可以重复使用的

https://github.com/v2ray/v2ray-core/issues/2523

而且加密方式不是AEAD，也就是说这个数据包它可以被重放攻击

防火墙拿到我们的数据之后它可以修改这里面的数据内容，然后发动一个重放攻击的数据包到这台服务器。经过篡改后的数据包来到服务器服务器会产生一些不正常的行为，防火墙的话他就通过这个行为来判断你这个服务器里面运行了vmess的节点，所以说防火墙就把你的服务器给强了。

要解决这个问题的话就必须要引入AEAD的加密方式，防火墙就没办法对这一串数据进行修改了，经过修改后的数据包发到这个v2ray的服务器，他是可以知道数据已经被修改了于是乎会直接丢弃掉这个数据包

同时的话头部的这个md5的认证方式也取消了，改成了指令解密的话需要用到的这么一串数据放在这个头部位置这样一通操作的话就无法向下兼容了，也就是说你要么用AEAD的加密方式要么用以前的md5的认证方式，如果说这个额外id等于0的话，则表示你发送的vmess协议里面是使用AEAD的加密方式

这种MD5的认证方式在2022年1月1号也就是元旦的时候彻底被淘汰了

套上TLS是流量传输变成https流量，更难检测，更改之后的网络拓扑

主要是修改了两边都加上了tls 然后加密方式的话改成了zero 为什么要改成zero？

zero的话 也就是说对数据内容不进行加密

因为我们开启tls之后 最后会将整个vmess协议进行加密，如果说我们这里还对这一串数据进行加密的话 那就多了一层加密，效率的话就比较低，

这里不要改为none，这个none的话 他其实会对这个vmess的数据包进行一些校验

虽然说他不会对这一算数据进行加密 但是进行校验的话还是有点影响性能的

vmess协议头在任何时候都是进行加密的。这因为我们这个额外id是0也就是说它这里会使用AEAD的方式进行加密

然后头部的话还会填充一些这里面AEAD用到的 解密需要用到的那个密钥（这个密钥不是直接明文的，本身是经过加密的，加密的key就是UUID+time，然后服务端试出这个密钥就可以开始）

这一串数据的话 就是经过vmess协议处理后的数据，可以看到数据部分 它是没有进行加密的

我们的客户端就会先和这台服务器建立一个tls的连接 然后建立好连接之后就会使用tls对这一串数据进行加密

整个vmess协议都进行了加密 加密后的数据的话前面还会套一个头部

这个头部的话就是我们这个tls里面的证书里面的域名

防火墙拿到这个数据 一看看上去它就是一个正常的https流量

要注意 vmess协议只有下面的功能：

传输协议和传输安全属于v2ray的功能

v2ary可以将vmess传输协议改为ws，可以在安全上加上tls，这样就是vmess+ws+tls

这里就是使用ws协议来承载流量，tls是属于伪装，vmess是加密

传输层只有tcp和udp两种协议，其他的全是基于这两种协议

比如kcp就是基于udp，ws是基于tcp

伪装就是可以把原始数据加上一点头部信息，看起来像http流量：

这里tcp就可以进行伪装

为什么需要封装ws？

因为封装一层ws协议，那么nginx就能识别这个协议，并做转发，如果不是我们目标网址协议，就不会转发到v2ray

但是这样的话 又会存在性能问题 我们都知道加了tls之后,协议本身没有必要对数据进行额外加密了，但vmess协议 不管你加没加tls 他都会对头部数据进行加密，虽然说加密的数据量很小，但我们总是喜欢追求极致的性能体验，所以针对这种情况 出现了vless这种轻量级的协议。和trojan一样 他的出生就是为了配合tls 所以不再对协议头部数据进行加密。

加密完全交给了tls 再加上回落功能 实现伪装 可以说是非常方便

VLESS

当我们访问谷歌，加密数据通过代理：

这一段内容就会用tls的方式进行加密

vless会添加数据包头部：

可以看到vless处理后的数据的话 他是明文的，他并没有进行加密

和trojan一样会使用tls对数据进行加密，这与trojan是一模一样的。

所以我们这一次的话就换一个Xray里面独有的xtls来对这一串数据进行加密

这个经过VLESS协议处理后的数据包，要使用xtls对前进行加密，这个xtls就不会像tls一样对整个数据进行加密

这个xtls的话 他就只对前面这一段数据进行加密，因为后面已经是加密过的数据 所以说他就不再进行加密（事实上后面的数据比前面的多的多），这样就大大的提高了性能

但是 有一点需要注明的是xtls它使用的tls版本是tls1.3，而我们这一串数据加密的时候可能是tls1.2或者tls1.3

这种就有被探测的风险

所以如果你需要使用xtls的话就使用Xray

不需要使用xtls的话就可以使用v2ray或者Xray

XTLS 是 Xray 的原创黑科技, 也是使 Xray 性能一骑绝尘的核心动力

vless+xtls+回落

vless和trojan从功能上来讲是差不多的，协议本身的话都是不对数据内容进行加密的，而是交给了tls加密

硬要说点区别的话 就是vless的协议头部数据没有trojan大

Fallback 是 Xray 的最强大功能之一, 可有效防止主动探测, 自由配置常用端口多服务共享

fallback 为 Xray 提供了高强度的防主动探测性, 并且具有独创的首包回落机制.

fallback 也可以将不同类型的流量根据 path 进行分流, 从而实现一个端口, 多种服务共享.

目前您可以在使用 VLESS 或者 trojan 协议时, 通过配置 fallbacks 来使用回落这一特性, 并且创造出非常丰富的组合玩法.

RPRX 当年发明 XTLS 主要原因是为了减少额外加密，我们现在推出新流控 Vision，则是因为 XTLS 在对抗审查者有独特的能力。可以说，当传输 TLS 1.3 数据时 XTLS 99% 的数据包，拥有几乎完美的流量特征。因为它是原始数据，没有经过任何代理加工。

概念介绍

加密协议：

也就是对数据包使用的加密协议

• ss
• trojan
• vmess
• vless

传输协议：

该流量的承载协议/与服务端连接的协议

• tcp(raw)

• kcp 基于 UDP 造新的通用可靠传输协议。为什么这些新协议不直接基于 IP 协议而要基于 UDP 协议？因为前者往往需要各级运营商进行设备、系统改造来支持，这显然不太现实，所以 UDP 成了更合适的选择。

• QUIC 基于 UDP 造新的通用可靠传输协议

• HTTPUpgrade 类似ws协议，但是建立连接之后，在通道内不传输ws帧，直接传递不套ws的帧（有些cdn不允许）

• ws 与http有类似特征，能被nginx解析分流

• grpc gRPC基于HTTP/2协议传输数据

  如果套用cf的话，就需要开启cf的gRPC设置，允许CDN与节点服务器建立gRPC连接

• xhttp http流量，上下行分离

传输层安全：

• 无
• reality 彻底隐藏sni，盗用别人的sni 但是访问首页也盗用了别人的证书，导致连接不安全（但是连接过程隐藏了域名信息） 这个问题从原理上来说是符合预期的，因为访问机器时是通过直连IP+指定SNI标识进行的TLS链接，全程不包含自己的域名信息，理论上你只需要在nginx前置代理上针对IP直连的请求返回444就可以避免被追查 如果接收到的不是正确的数据，就转发到目标网站

• tls 引入tls加密变成https数据

流控：

目前只有

tls-rprx-vision和tls-rprx-vision-udp443

flow: string

流控模式，用于选择 XTLS 的算法。

目前出站协议中有以下流控模式可选：

• 无 flow 或者 空字符： 使用普通 TLS 代理
• xtls-rprx-vision：使用新 XTLS 模式 包含内层握手随机填充 支持 uTLS 模拟客户端指纹
• xtls-rprx-vision-udp443：同 xtls-rprx-vision, 但是不会拦截目标为 443 端口的 UDP 流量

此外，目前 XTLS 仅支持 TCP+TLS/Reality。

关于 xtls-rprx-*-udp443 流控模式

启用了 Xray-core 的 XTLS 时，通往 UDP 443 端口的流量默认会被拦截（一般情况下为 QUIC），这样应用就不会使用 QUIC 而会使用 TLS，XTLS 才会真正生效。实际上，QUIC 本身也不适合被代理，因为 QUIC 自带了 TCP 的功能，它作为 UDP 流量在通过 VLESS 协议传输时，底层协议为 TCP，就相当于两层阻塞控制了。

若不需要拦截，请在客户端填写 xtls-rprx-*-udp443，服务端不变。

链式代理/二级代理/机场加速/中转

中转就是我们不直连我们的节点。

中专就是解决绕路的问题，因为我们的流量走的路线可能是比较拥堵的，就需要使用中转机来调节优化线路

现在大部分机场的话都是提供了中转节点

他给你分配几个端口，让你使用它提供的这几个端口对数据进行转发，给我们提供端口转发或者隧道中转的服务

有的地方也叫NAT转发、隧道转发、隧道中转

隧道转发的话，说白了其实就是对数据的再封装和再加密，其他的表现的话就和端口转发是一模一样的

比如你的vmess数据从这里发出来之后来到这台中转机

中转机会对你的vmess数据再次进行加密

然后再转发到你的代理服务器。这里的话就会出现两种情况

• 要么你自己在代理服务器上，配置好隧道 对他加密的数据进行解密
• 要么他这个隧道的话已经做好了落地解密，这样的话你的代理就不用配置隧道

有的时候 你会看到一些中转机场，服务器的ip地址都是一样的，只是换了一个不同的端口。这种机场的话就是使用了端口转发

其他优化速度方式

TCP拥塞控制

BBR拥塞控制

我们可以使用这条语句来查看一下当前使用的tcp拥塞控制算法

cat /proc/sys/net/ipv4/tcp_congestion_control

查看支持的算法

cat /proc/sys/net/ipv4/tcp_available_congestion_control

#启用BBR TCP拥塞控制算法
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

开启 BBR 加速

以下 BBR 加速，请自选一种

1、系统自带 BBR 加速

echo "net.core.default_qdisc=fq" >> /etc/sysctl.confecho "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.confsysctl -p

2、BBRplus 加速

wget -N --no-check-certificate "https://raw.githubusercontent.com/chiakge/Linux-NetSpeed/master/tcp.sh" && chmod +x tcp.sh && ./tcp.sh

改成bbr拥塞控制算法之后 我们的带宽利用率就会提高很多

而且如果别人用cubic算法的话 你用bbr算法的话.你会比他获得更多一点的带宽

hysteria提速垃圾线路原理

他的话是基于QUIC协议，并且QUIC的话他是基于udp的，udp协议是没有拥塞控制算法的，也就是 udp的话，他一直都是全速发送数据的

但是udp是不可靠传输的，所以基于udp的QUIC协议 它实现了可靠传输，里面也封装了拥塞控制来控制udp的发送速率

QUIC的出现的话 它主要是解决了tcp存在的队头阻塞的问题

由于QUIC它是在应用层的，tcp的拥塞控制算法的话 它是在系统级别的。你要改系统里的拥塞控制算法是比较麻烦的，但是如果说改QUIC协议里面的拥塞控制算法是比较容易的

hysteria实现的拥塞控制算法的逻辑就是最大化吞吐量

免费的CDN服务CF

如果想传输协议使用grpc或者http/2的话，这一段的话就需要使用这个tls进行加密。因为那个http/2的话 它是默认需要tls，而grpc协议的话 是基于http/2