这是节点搭建系列的第八节

也是整个系列的最后一节

上节的话 我们探讨了一下你的节点为什么这么慢

以及怎么搭建高速的节点

给大家讲解了线路的相关知识

总结就是钱花到位了 节点速度自然就提升了

本来上节的话是节点搭建系列的最后一节

结果光线路部分的话就讲了将近30分钟

所以拆成了两节

这节的话真的就是最后一节了

给大家讲讲不用花钱的免费提升节点速度的方案

主要给大家介绍套用cloudflare提供的免费CDN

以及bbr拥塞控制算法

并且通过配合x-ui面板实现vless+ws+tls+web+cdn的节点搭建

真的没有什么东西可以加了

搭建节点的话操作难度并不大

大部分都是前面学过的内容

但是知识点比较多

并且各个知识点并不是独立的 是关联在一起的

如果前面的教程都看明白了的话 理解起来应该也会更轻松

反之的话 可能理解起来比较困难

废话不多说 我们直接开始今天的内容

2023-06-06T13:14:12.png

这个原理图相信大家都不陌生

我之前讲解的时候 已经用过很多次了

这一次的话我们搭建一个vless的节点 然后配合传输协议是ws

也就是vless+ws的节点

并且是没有配置证书的

我相信对于大家来讲是非常的简单

不过这一次我们再来降低难度

之前我们搭建的时候 都是手动去编辑这个配置文件

这一次的话 我们使用x-ui来进行搭建

x-ui的话 它是一个图形化的界面

也就是说 我们可以通过图形化的方式编辑我们的节点参数

然后由x-ui来帮我们生成这个配置文件

而不需要我们手动去填写这个配置文件 至于x-ui的话 他本身是没有FQ的功能的

我们在安装x-ui的时候 他默认会给我们安装这个xray的内核

所以说主要的FQ功能还是这个内核来进行FQ

x-ui的话主要就是对这个配置文件进行修改

那废话不多说 我们首先来搭建一个x-ui

这是x-ui面板的那个项目的官方地址

进来之后 我们

使用这个一键安装脚本来进行安装

这里的话我已经准备了一台vps 我们直接粘贴上去

然后回车就可以了

由于之前的话 这个x-ui一直是使用默认的端口 还有账号密码

导致了上万名的用户出现了被扫ip的这种情况

现在的话这个脚本需要我们强制修改端口和账号密码

我们输入y直接回车

设置我们的用户名 密码 我这里就随便设置一下

大家可以按照自己的需求去设置 设置好之后

他就会开始安装

出现这个界面的话也就相当于我们的x-ui面板安装成功了

这个时候我们看一下之前我们设置的端口是54321

也是说 我们可以通过这个ip地址和这个端口来访问我们的x-ui面板

输入一个英文的冒号54321回车

为什么进不去呢 因为我这个是新安装的系统那个防火墙忘关

这个防火墙坑了我好几次了

好 放行之后我们就可以进入了

刷新一下 输入刚才我们设置的账号和密码

ok 这就是x-ui的面板 首先的话 我们可以把xray的内核切换到最新版本

进来之后 我们点击这个入站列表来创建一个节点

点击这个加号 备注的话我们就随便写

然后协议的话就选择vless这个监听ip的话 我们默认留空

那就是监听四个零也就是说这台vps的所有ip地址 他都进行监听

端口的话 这里我们要默认设置为80 之后的话我们会说明

到期时间 像这些 我们就留默认就行了

然后传输协议的话 我们要改成ws

这个流量探测 我们在服务端就没必要启用

我们点一下添加 现在的话就创建了一条vless+ws的节点

这个时候我们点一下查看

复制一下连接 然后导入到v2rayN里面

这个时候我们就可以来尝试进行连接

可以看到已经能成功连接了 再测一下速

可以看到目前是晚上7:20

现在的话是这个速度 现在的话我们的节点就可以正常进行使用了

确认节点可以正常访问之后 我们就要开始来套cdn

但是 首先的话 我们需要先来了解一下cdn的原理

cdn中文名翻译为内容分布网络

顾名思义就是把它的内容分布到各个cdn服务器上面去

假设这是我的电脑 我现在要访问谷歌

在没有cdn的情况下 我会来到这个国际出口的位置

假设现在没有防火墙的干扰

2023-06-06T13:17:12.png

我会从这里过去 然后来到这个谷歌的服务器

谷歌会将它的响应数据从这里返回到我们的电脑

这个图的话 我们上节已经讲过了这个地方的话 它是一个瓶颈链路

到了晚高峰会非常的拥堵

所以说 我们访问谷歌的话 速度就会变得非常慢

当谷歌套了cdn之后 访问的情况就变了

我们的电脑在发起访问谷歌的请求之后会先进行dns解析

通过dns解析之后

我们会得到离我们最近的一台谷歌的cdn的服务器的ip地址

这个时候 我们发起访问谷歌的请求

将会把请求交给这台cdn服务器

从我们用户来讲 我们认为这台cdn服务器就是谷歌的网站

但是这台cdn并不是谷歌的网站

那他怎么把数据给我们呢

这个时候 他就会检查自己的缓存列表里面有没有缓存谷歌的首页内容

发现没有缓存

他就会找他的上一级cdn服务器

比如的话 假设是这一个 而cdn之间的连接一般是通过自己拉的专线或者租用的线缆进行连接

就保证了这条链路的高速访问

那如果cdn 他也从这个拥堵的链路再访问到这台cdn的话

那他就失去了作为一个cdn的资格

因为cdn的主要作用就是加快网络中数据传输

这台cdn服务器将我们访问谷歌的请求转交到他的上一级之后

这台cdn服务器又会检查自己的缓存列表中是否有谷歌的缓存记录

如果没有的话 他就会再找他的上一级缓存服务器

如果说没有上一级了 他就会直接找到源谷歌服务器

谷歌知道我们的访问意图 之后就会把响应数据从这里返回到这台cdn服务器

cdn服务器拿到谷歌的返回数据之后将会缓存下来

然后将这个数据内容返回给这台cdn服务器

这台cdn服务器拿到数据之后也会缓存下来

然后再将响应的内容返回到我们的电脑

可以看到cdn起到的一个作用就是绕过来这条非常拥堵的链路

另外还有一个最主要的作用就是它缓存了这台服务器的内容

假设现在这个用户他也要去访问谷歌

他的访问请求通过这里来到这台cdn服务器 之后

由于这台cdn服务器刚才已经缓存过来谷歌的内容

所以说他不需要在往上一级去要数据

他直接从这里就直接把数据内容返回给你了

所以说速度的话是非常快的

这就是cdn的主要作用 做内容分发 还有网络加速的

当然这个cdn在国内段的话 这里也会有长城防火墙的

而我们代理服务器套用cdn话 主要是用到了它的网络加速功能

内容分发的话一般都是建网站才会用到

主要是缓存一些图片还有教程这些静态资源

像我们代理的话 基本上跑的都是加密的数据

它是不可能命中我们的缓存

所以说 我们主要用到的就是它的网络加速功能

但是我相信你也看到过一些段子说cdn是一个减速器

那为什么加速效果会不好呢

主要的原因是你要套国内的cdn话 你的域名就必须要备案

也就是实名制 我相信没有哪个头铁的兄弟会这么做

所以说相当于这条路被封死了

但是国外的cdn他是不需要备案的

也就是说我们可以给我们的代理服务器套国外的cdn

但是套国外的cdn 问题又来了

他要把数据传到我们的电脑的话 还是要经过这条拥堵的链路

所以说 导致的问题就是 你套cdn和没套cdn

你的瓶颈链路都是这一条

速度的话就基本上没什么区别

这就是我们套cdn之后无法提速的这么一个主要原因

另一个主要的原因就是我们现在套的

cdn基本上都是免费的 cloudflare提供的cdn服务

下面的话我们简称CF 用他家的cdn套 FQ 代理的人太多了

可能cf家的cdn ip段已经被防火墙重点关照了

会对他家的cdn进行劣化处理

所以说我们套了cdn之后速度提不起来的主要原因有 国内需要备案

这条路直接pass掉 我们套国外的cdn之后又会

经历同样的瓶颈 链路导致非常的拥堵

再者 使用免费的cdn的话 链路会被防火墙劣化

所以说套了的话可能并没有太大的提升

不过这节的话我们以学习cdn的原理为目的

所以我们这一次的话还是来套CF的cdn

来进行节点的搭建

首先的话 我们进入cf的官网

如果你没注册的话 就直接点一下这个注册就行了

注册非常简单 只需要一个邮箱 我这里有了 就直接点击登录

如果你的是英文界面的话 可以在这里切换为简体中文

CF的话 它主要提供了dns的域名解析 还有cdn服务

以及在没有服务器的情况下可以创建一些自定义脚本的workers

我们主要用到它家免费的dns服务以及cdn服务

要套cdn的话 你必须首先要拥有一个自己的域名

关于域名的注册的话 我早期的话录制了一个免费的域名注册的教程

教程的话有点久 我不知道现在的话还有没有用

但是前段时间的话 收到有用户的反馈是可以注册的

如果不行的话 大家可以自行在网上搜索 关于这方面的教程还是非常多的

我这里的话 就以这个域名为例

点进来之后 如果说你的不是和我的一样在这边排列的话 你就可以点一下这里

其中 新导航就会切换到左边排列 你的可能在顶部

都是一样的 然后我们点击dns

点击添加记录类型为a记录

然后给一个二级域名的名称 我们直接输入v

这里的话大家可以随便自行设置

ipv4的地址的话就填写我们的vps的ip地址就可以了

这个地方的话就是非常关键的

如果这里点亮了 就说明启用了cdn 也就是说

访问这个域名将会套用cdn 如果说关闭了的话

就是仅限dns 也就是说这个域名直接指向了我们vps的ip地址

我们现在的话要套CDN 所以说我们把它点亮

然后我们点一下保存 这个时候就已经配置好了

我们只需要等待个几分钟让他生效 没错 套用cdn就是这么简单

确认他生效 我们可以在命令行这里输入cmd

然后ping一下我们刚才生成的这个

域名v.nicename.tk 回车

可以看到解析之后这个ip地址 并不是我们vps的ip地址

我们vps的ip地址是这一个 在套了cdn的情况下 这是一种正常的表现

同时我们也可以看到它出现了丢包的情况

四个包丢了两个包 这种情况的话

我们可以认为是防火墙对我们的连接进行了劣化

我们再试一次吧

可以看到 目前的话又没有丢包

ok 确定解析生效之后 我们就可以把这个域名复制一下

然后塞到这里去

直接确定

这个时候我们的节点就已经套了cdn 这是最简单的一种方法

这个时候我们再来测试一下下载速度

可以看到还是有点提升的 目前来看 这个时候我们

把原来的那个节点恢复一下

直接复制我们的ip地址

第一个的话 就是没套cdn的情况下

第二个的话是套了cdn的情况 我们测一下第一个

再测一下第二个

可以看到还是有提升的

因为我们没套cdn的时候 我们的链路可能是走这条

但是套了cdn之后 CF给我们分配的cdn可能是这一个

我们就可能会走这条链路过去

这条链路的话可能就稍微好一点

就可以实现加速的这么一种情况

也就是说 它可以改变我们原来的路由情况

接下来的话 我们先来看一下最简单的套cdn之后的原理

其他地方我们都没动 只是在这里加了一层cdn套

cdn非常简单 我们只需要把我们的ip地址填上去 然后把它的代理勾选起来

就相当于我们在这里插了一个cdn服务器

并且我们的域名已经绑定到了这台cdn服务器

同时我们这里的ip地址就要改成这个dns服务器的ip地址

首先 我们这边的数据经过防火墙之后 它会发到这个cdn服务器

cdn服务器就会根据你配置的这个

ip地址是一个域名 他会检查一下他的域名列表里面有没有这个域名

如果有的话 他就会检查你这个域名 他绑定了什么ip地址

确定了ip之后 他就会把我们发送过来的数据转交给这台服务器

相当于这个cdn扮演了一个中转的角色

但是他的应用场景没有中转大 他只能帮我们转发特定的端口以及特定的协议的数据

比如 我们为什么要指定他的端口是80

因为cdn服务器规定了你走80的端口的数据 我就帮你转发

只有你的端口是80的时候 以及你传送的数据是

http协议的数据我才会帮你转发

因为我这个cdn的主要工作就是干这个的

如果说我任何数据都去帮你转发 那我就成了一个端口转发的中转服务器了

这个时候我们就可以来解释一下 为什么我们的传输协议要改成ws

因为ws协议是通过http升级来的

你可以把它想象为 它是http中的一员

所以我们传过的数据 这台cdn服务器它就接受

那如果你这里传输协议是tcp的话 你传过去的数据的话 这台cdn他是不认的

他只接受http协议相关的数据

这台cdn服务器拿到我们的ws数据之后

也会使用ws的方式去访问我们的节点服务器

这台节点服务器返回数据的时候 也是使用ws协议来进行封装

然后交给这台cdn服务器

这边服务器他是认这个ws的数据了

所以说他就会把我们的数据转发到我们的本机电脑

这就是套了cdn的情况

另外 cdn还有一个重要的功能就是它可以防止你的节点服务器被墙

以及拯救被墙的节点服务器 假设你这个节点服务器现在已经被墙了

但是我们套了cdn之后 我们的请求是直接发给这个cdn服务器的

而这个cdn服务器 它没有被墙 所以说防火墙就会放行通过 来到这里之后

cdn和节点服务器之间是没有防火墙的

所以这一天他也可以正常的访问到节点服务器

节点服务器返回数据的时候是先将数据交给cdn服务器

cdn服务器在将数据转回到我们的本机电脑

所以防火墙完全不知道节点服务器的存在

这就是拯救被墙的节点服务器的这么一种情况

预防节点服务器被墙也很好理解 就是我们发过来的数据是交给cdn服务器

即使防火墙知道了你传送的数据内容是在进行FQ 把cdn服务器墙掉了

但是你的节点服务器并没有被墙

这时候你只需要换一个cdn或者把cdn给拿掉

你的服务器又恢复正常了

这就是预防被墙的这么一种情况

这里的话就有一个专业的名词 叫做反向代理(简称反代)

而我们这边配置的这个xray的话是一个正向代理

如果说这台cdn被墙了 或者说你觉得这个速度太慢了

那我们怎么换一个cdn服务器呢

这时候我们再回到这张图

我们刚才说过套了cdn的谷歌的话 我们要去访问他

就会接入就近的cdn服务器

然后通过这台服务器再去寻找他的上一级的缓存服务器

然后一层一层的 然后到达这个谷歌的源服务器

那我可不可以不接入最近的这台cdn服务器

我直接去找这台cdn服务器可不可以

其实是可以的

也就是说我们绕过了就近的cdn服务器 我

们直接从这里过去直接找他

要谷歌的数据 他也可以帮我们去访问谷歌的源服务器

或者说这条链路太堵了

我不想找这台cdn 我想找这台cdn 可不可以

那也可以 我们从这里过去 找到这台cdn

让这台cdn去帮我们访问谷歌也是可以的

当我们在这里配置好了cdn代理之后

cf会帮我们默认配置一个cdn服务器

也就是刚才我们查询到的这个ip地址

这是他帮我们分配的默认的cdn服务

器 那我们要手动换成其他的cdn服务器的话 我们就可以到这个网址

他已经把他家所有的cdn服务器的ip地址已经列出来了

我们可以看到他的ip范围

他这里已经列出来了他所有的cdn服务器的ip地址

我们可以点击这个查看当前可用的cdn服务器的ip段

斜线后面的话表示这个当前ip地址的网络号有多少位

这样子的话看的不是特别的直观

我们可以使用cidr计算器

把这个填写进去 我们就可以查看它的

范围 起始ip是这个 结束ip是这一个

也就是说他这个ip段里面总共有4096台cdn服务器

这个时候我们可以随便在这个范围内

挑一台cdn服务器来ping一下 看通不通

可以看到这台是不通的 我们可以换一下

还是不通 随便找一个

还是不通 可能这整个ip段的话已经被长城防火墙墙掉了

这个时候我们可以尝试去这个ping.pe这个网址

把这个ip段随便输一个进去

看一下到底世界范围内通不通

看样子这个ip段它是不工作的 并不是说我们中国把它墙了

这个时候 我们换一个ip段

可以看到这个的话是可以的

那我们在本地ping一下试一下

可以看到这个cdn服务器是可以正常使用的

挑出来之后 我们就可以把我们当前这个默认的cdn服务器给它换掉

具体怎么换呢

我们双击打开这一个地址栏 这里我们要输入的是刚才

挑出来的cdn服务器的ip地址

这一段的话 我们要放到这个伪装域名这里

为什么要把域名放在这里呢

因为我们这里的话

我们的数据从这里发出去的时候必须要携带cdn绑定的域名

也就是说 我们在

这个地方配置好的域名才行 因为我们数据到这里之后 他会检查你发过来的域名有没有在cdn服务器里面配置好

如果说你不填的话 他这个列表找不到那个域名的话 就会无法发送成功

ok 配置好之后我们点下确认 然后再来重新进行测速

可以看到是通了

但是说速度的话不怎么样 还没刚才那个默认的好

这样的话 我们就换了一个cdn服务器了

但是这样子的话 跟我刚才一样一个一个的去挑选这个ip是非常繁琐的

而且挑出来的ip速度可能也不好

这个时候就出现了优选ip这么一个东西

优选ip的主要工作原理就是在他家的所有的cdn中随机挑选一些ip地址出来

先跟我们一样 先ping一下 看看通不通

然后如果通的话 就按延迟来进行排序

排序完成之后再连接这个cdn服务器

去下载一个文件

看看它的下载速度是多少

把下载速度最快的cdn服务器的ip地址

返回给我们 因为下载的时候是用我们本地的网络去进行下载

所以它的下载速度的话就基本上反映了我们本地连接这台cdn服务器的下载速度

这个速度的话就是比较准确的

优选ip的话我们可以在github上面找到这个项目

来点击这里release

下载一个最新的版本

我这里下载windows版

下载之后将其解压出来

可以看到他这里有个

这个的话就是CF家的所有的cdn服务器的ip地址

这个时候 我们要做的就是直接双击运行这个程序

他就会开始测延迟 我们这里要耐心等待一下

2023-06-06T13:28:58.png

现在的话在测试下载速度

刚才的话 他在这个ip地址里面随机选了4931个cdn服务器的ip地址

然后进行了延迟测试 最终的话挑选十个延迟最低的节点

然后进行下载速度的测试

这个时候我们再耐心等待一下

ok 测试结果已经出来了

他出现了这么一些ip地址 并且进行了排序

也就是说 我的本机电脑通过这个cdn服务器的ip地址去下载文件

它的下载速度是1.9兆每秒 是最快的一个

后面的话就是越来越慢

这个时候我们要做的就是把这个cdn服务器的ip地址

替换掉我们原来的这个节点的ip地址

其他的地方就不用改了

确认 那这时候我们再来测试一下下载速度

可以看到它并没有想象中提升到多

基本上没什么变化 这是因为网络的话 它是有抖动的

并不是说你当时测出来的是这个速度 然后你就一直会有这个速度

我们换一个试一下

那你还不如刚才那个

那我们再试一下这个没套cdn的情况下是一个什么样的速度

没套cdn还稍微快一点

所以说大家为什么会调侃cdn是一个减速器呢

主要是用CF cdn来进行FQ的人太多了

这个结果肯定是被防火墙进行了劣化

至少电信的话是这么一种情况 我测试了几天

到了晚高峰 大概都是这么一个效果

如果你是其他运营商的话 你也可以试一下

这就是套cdn以及优选ip的教程 其实设置的话是非常简单的

我们只需要把域名绑定上去就行了 基本上不要去动它

细心的朋友可能发现了我这个

节点他是没有套tls的

也就是说完全都是明文的状态

那这又是一种什么情况呢

我们回到这个图

可以看到我们的节点服务器没有套tls

而且我们的本机电脑的话也没有套tls

根据我们之前讲的原理的话 vless他是不会对数据进行加密的

也就是说我们的数据完全就是明文出去的

由于我们使用的传输协议是ws

也算是做了一层伪装 所以防火墙并没有直接丢弃我们的数据包

但是这种情况是非常不可取的 指不定哪天就被墙了

他要探测的话是非常简单的 你的访问目标在流量中就是明文的状态

这个时候 如果我想套tls的话怎么办

也就是说 让我们的数据经过防火墙的时候

把数据进行加密

在套了CF cdn的情况下 这种操作是异常的简单 我们只需要

在这里 将端口改成443

然后将传输安全改成tls确认就可以了

证书什么的完全不用我们自己去管

我们这时候再来测一下

可以看到它是通的 那这又是一种什么情况呢

我们回到这个原理图 这个时候 我们的数据和cdn之间的数据

它是加了tls的 而cdn到我们的源服务器的话

他是走明文的 但是由于这里没有防火墙 我们走明文的话也是没有关系的

所以我们的节点估计并不需要配置任何的tls 也不需要去申请证书麻烦了

这个cdn服务器默认就帮我们的域名配置好了免费的证书

所以也不用我们自己去管

至于这个端口改成443的原因是这个我们的https流量默认走的就是443端口

也就是说你走443的话 默认他就给你套上了tls

你如果走80端口的话 默认的话就没有

套tls

然后cdn服务器和你的节点服务器之间的数据 你也想进行加密的话 怎么办呢

我们可以在这个地方进行设置 来到ssl 这里

可以看到 默认的话 它是只加密我们用户到cdn服务器的数据流量

cdn到我们的源服务器之间 它是没有加密的

那这个时候你如果想加密的话 你就要把它切换到完全

或者严格 这两个的区别的话 严格的话是要找CA机构去颁发证书

完全的话 你可以使用自签的证书在这个源服务器上部署

那这个图的话也就对应了我们这个图的意思

只不过多了一个防火墙

这边的话一般我们都不需要对流量进行加密的 所以说也就不用配置那个tls的证书

但是你如果想传输协议使用grpc或者http/2的话

这一段的话就需要使用这个tls进行加密

因为那个http/2的话 它是默认需要tls

使用grpc协议的话 是基于http/2

所以说那两个传输协议的话 就都需要配置tls

关于grpc的话 我们这里还是要补充一下

我们要来到这网络 这里在这个网络设置中

如果说你的传输协议是grpc 然后要套CF的cdn的话 你就必须要把这个勾选上

他的意思是允许通过grpc连接到你的源服务器 意思就是

你这一段链路 你如果要用grpc协议进行连接的话

就需要把这个勾选起来

因为如果说你这里的传输协议是grpc的话

你的grpc的数据来到cdn服务器之后

cdn服务器 他必须也用grpc把数据交给节点服务器

但是如果说你这个没开的话

就相当于你不允许这个cdn服务器跟你的节点服务器建立grpc的连接

所以说这个数据肯定就没办法传输 就导致会连接会失败

包括这个websocket 也就是ws协议

如果说你没有允许cdn服务器与我们的源服务器建立ws的连接的话

这个传输协议为ws的数据

来到cdn服务器 之后 cdn服务器并不能和源服务器建立ws的连接

将会导致我们的连接无法建立

所以说这里我的话默认它是勾选上了

所以如果你想使用grpc的话 你就要把这个勾选上

包括这个http/2

这是应该是最近才加上的 翻译都没出来 一样的意思

这是关于回源 目前的话CF支持http/2还有grpc 还有websocket回源

回源的意思就是从这边到节点服务器支持怎么样的协议

他是不支持QUIC的 他这个QUIC是正向的

并不是一个回源的

也就是说 我们这个节点服务器到这个cdn 这里的话他可以走那个QUIC协议

但是这边到源服务器的话 他是走不了QUIC的

所以我们如果说你用的传输协议是QUIC的话

套了cdn 你是没办法进行连接的

ok cdn这一块的话 基本上所有要讲的都已经讲过了

接下来我们的节点的话貌似还差一点意思

比如我们在这里直接去访问这个域名的话

他返回的是bed request

目前的话我们在套了cdn的情况下

怎么和之前一样套一个伪装站点上去 和之前一样

我们要借助nginx

再做一个反向代理

我们要套伪装站点的话 就需要把

nginx引入进来

这个时候 负责和cdn对接的是这个nginx

而nginx在收到/ray的目录的流量的话 就会转交到本机的8388端口

这时候我们要将端口这里改成8388

监听ip的话我们要改成

127.0.0.1 这些的话我们在之前都已经讲解过了

另外的话 我们再配置一个/xui的路径

访问的话就转交到54321的端口

因为你在套了cdn的情况下 我们根本就没办法访问x-ui

这个时候 我们先把nginx搭建起来

搭建nginx的话 之前已经说过很多次了

我们这里就不再重复了

我们要做的就是把这个配置文件修改一下

打开这个默认的配置文件

将整个配置文件的信息拷贝过去

直接全部替换掉

这里的意思呢 就是接到/ray目录的流量

我们就直接转接到8388端口

这是ws的数据 然后接到/xui目录的话

我们就直接转接到9999这里的话我们改成54321

就会访问到那个x-ui的面板 伪装地址的话就改成bing这三个地方

并且的话同样的也不需要配置任何证书

点一下保存

保存之后 我们使用这条命令来

重新加载一下

nginx的配置文件

他这里说没有启动 为什么呢

因为现在的80端口已经被我们的节点服务器

节点给占用了

这个时候我们要先把x-ui停止

我们输入这个x-ui

可以看到 他的一些选项

选择9 先把x-ui停止

那这个时候的话

我们就可以来尝试启动nginx

这个时候我们再来查看一下的运行状态

看 他现在已经启动成功了

同时我们也可以在浏览器直接访问来验证一下

可以看到 他现在已经伪装到我们的bing上面 这个时候 我们尝试访问xui

他显示错误 那为什么呢 因为我们这x-ui还没有启动

启动成功之后我们再刷新一下

xray没有启动

我知道为什么进不去了 因为我们这里的话还需要设置一下

在面板设置里面把那个根路径改成 /xui/

保存一下 然后重启面板

这个时候 我们在这里通过cdn去访问的话就可以进行

登录了

现在x-ui的话他是没办法启动的

因为那个80的端口已经被占用了

所以说我们这个节点的话已经不需要了 不需要启用

现在我们要创建一个交给nginx处理的节点

选择vless 监听ip 127.0.0.1

端口的话我们就改成8388

传输协议的话改成ws

路径的话改成/ray

这个关掉

确定没问题 点一下添加

2023-06-06T13:36:14.png

这个时候我们点一下查看复制一下

是下面这个搞错了 复制一下 粘贴

节点添加过来了 但是他现在是不能用的 因为这个地址的话是

本地的环回地址 我们要改成我们的域名

当然你也可以自己去优选ip

这个的话已经套过cdn了 然后端口的话要么给80要么给443

80的话就是不加这个tls

我写443把tls给加上 其他就没什么改了 我们点一下确认 直接测速

2023-06-06T13:37:17.png

可以看到他

是没通吗

这个xray好像没启动了

已经启动

这种情况的话我们可以看一下这个ip地址是不是

分配给我们的cdn ip地址被墙了

那可以看到确实是没办法进行正常访问的 这个时候我们就看下

上面这个ip地址刚才选出来的应该还可以用吧

我们把填进去之后把这个

域名给他塞到这里去测试一下

那这个是可以正常使用的

可以看到那目前的话就是可以正常进行使用

那这是套了tls的情况下 那你可以不套tls

就是直接把这个tls给关掉

然后将端口改成80

这就是不套tls的情况

也是没问题的 可以正常访问

都是同一个域名 当我们去访问这个域名的时候

他就会跳到bing上面去

当我们去访问这个xui的时候

就是进入x-ui的面板

除了使用免费的cdn来提升我们的节点速度之外

我们也可以通过修改

节点服务器的拥塞控制算法

来提升我们本机电脑与这个代理服务器之间传送数据的速率

来达到提升节点速度的这么一个效果

讲到拥塞控制算法的话 我们就要来讲一下为什么需要拥塞控制算法

这条链路的话 我们假设它每秒钟只能传输三百兆比特的数据

这是一个吞吐量

而我家里的拉的宽带的话 他每秒钟能传送一百兆比特的数据

如果有十个用户同时拉了一百兆

并且同时全速的向这条链路发送数据的话

那这里根本就没办法工作

为了防止用户发送数据的速率太快

而导致网络链路崩溃

所以要引入拥塞控制算法

目的就是控制我们电脑发送数据的快慢

比如十个拉了一百兆宽带的人往这条链路发送数据

那肯定不能按全速进行发送

通过拥塞控制算法

每个人的话大概能分到三十兆比特的发送速率

所以说并不是你家拉了一百兆的宽带

你平时上网的速率就永远都是一百兆

有时候你在进行宽带测速的时候

你发现你根本就跑不满你拉的这个一百兆的带宽

那就是因为有拥塞控制

并且网络中已经出现了拥堵

具体的话 怎么样才能控制我们电脑的发送速率

这个的话就是由我们电脑的操作系统自带的 拥塞控制算法来进行控制

拥塞控制算法的话就是来感知网络中已经出现了拥堵

通过他的算法来提升或者降低你的数据发送速率来防止网络中出现拥堵

常见的拥塞控制算法有Reno和cubic等一些比较经典的拥塞控制算法

另外还有近些年

由谷歌开发的bbr拥塞控制算法

而bbr拥塞控制算法区别于传统的Reno cubic的拥塞控制算法

Reno和cubic的话 他是基于丢失的拥塞控制算法

而bbr的话 他是基于模型的拥塞控制算法

这里的话我们通过一个图简单的了解一下

横轴的话是时间 纵轴的话 是我们发送数据包的个数

传统的基于丢包的拥塞控制算法的话 他发送数据的时候

他会先假设一个阈值

假设这里是8个数据包

我们的客户端向服务器发送了一个数据包

tcp的话 服务器收到了数据包的话要给我们回一个确认

我们使用tcp的方式往这台服务器发送了一个数据包

服务器收到数据包之后 要给我们回一个确认

代表他收到了数据包 如果说发过去的数据包超过一定时间

我们没有收到服务器的确认的话

就表示这个数数据包丢失了

所以我们这里说的拥塞控制算法的话

都是基于tcp的 udp的话 他是没有拥塞控制的

我们待会再讲

我们的客户端收到服务器的确认之后

也就确定了他收到了这个数据包 然后会尝试

一次性发两个数据包过去

接着服务器给我们回来两个确认

也就是说 两个数据包都收到了

客户端将会尝试一次性发送四个数据包

这时候服务器回了四个确认 也就四个包都收到了

接着在一次性发送八个数据包给服务器

服务器也同时回了八个数据包给我们

这个时候已经到了这个阈值了

前面的话我们是倍数增加 也就是每次翻倍

后面的话我们认为网络中 你再继续这么发的话不行 会出现拥堵

于是就进入了拥塞避免的阶段

这个时候 发送数据包就会一个一个加

比如说我下一次我发九个

服务器也回来九个确认

再发10个11个12个13个这样子一直发下去

比如我这里发到16个

但是这个时候出现了丢包 只回了15个确认

超过一段时间后并没有回复第16个确认

这个时候 我们的客户端就认为网络中出现了拥堵 导致了数据包的丢失

那发送速度的话马上会降下来

中间的话还会有快速重传和快速恢复的这么一些状态

我们就不涉及多了 假设就跌到底了

然后又会反复的进行 这样子的发送状态慢慢升上去

然后出现了丢包又降下来

慢慢慢慢提升上去 丢包了又下来 再上去再下来

基于丢包的拥塞控制算法的话 大概就是这么一个原理

这种的话有个问题就是假设我的丢包并不是因为网络拥堵而造成的

可能传送的时候出现了误码 或者其他一些原因

导致数据包的丢失 那他也认为网络出现了拥堵

直接会把发送速率降下来 这样的话就导致了这个整个带宽的利用率不高

所以就出现了另一种基于模型的拥塞控制算法

也就是谷歌开发的bbr拥塞控制算法

bbr的拥塞控制算法的工作原理呢

首先 他把发送数据的速率保持到一个阈值

一直保持这个发送速率

它会动态的观察你的延迟是否有增加

因为增加延迟的原因是我们在这里出现了排队

数据包 如果在这个路由器这里排队的话 将会导致延迟增加

所以bbr的话他就是监测这一个延迟

如果说延迟一直没有增加的话 那我保持这个发送速率的话是没有问题的

过了一段时间我会尝试的

加大我的发送速率 然后马上回来 看一下我的延迟是否有变化

如果说延迟跟着一起提升了

那说明你增加的这部分数据的话 他会进行排队

也就是说会出现拥堵 那就不进行增加

然还是保持这个发送速率

隔一段时间 他又会尝试提升他的发送速率 然后马上下来

如果说这个时候 你提升了你的发送速率

但是你的延迟没有增加

这说明有人退出了竞争

这个时候你就可以把发送速率提升到这个阶段 然后再发送数据

在这个阶段的时候 他又会隔段时间往上探一下

如果延迟又没增加的话 他又会把发送速率提升到这个状态

那如果说发着发着延迟突然增加了

隔一段时间之后 他会把他的发送速率降下来

这个的话就是bbr的拥塞控制算法的基本工作原理

可以看到 他的带宽利用率是很高的

比传统的基于丢包的拥塞控制算法带宽利用率要高很多

这也是为什么我们把tcp拥塞控制算法改成bbr之后

你的节点会有提速的这么一个效果

那为什么我这个系列录了这么久之前从来没有教大家去安装bbr呢

因为我每次讲的这个系统的话 他默认使用的拥塞控制算法就是bbr

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

2023-06-06T13:42:57.png

那可以看到他默认的话他就是用bbr

那我也可以在这里直接把它改成cubic

那这样的话 拥塞控制算法 就变成了cubic了

那如果你的系统和我不一样的话 你输入这条语句查询到的

如果不是bbr 而是cubic或者其他的Reno的一些拥塞控制算法的话

你就可以把它切换为

bbr拥塞控制算法

切换的方式也非常简单 我们只需要执行这三行代码就可以进行切换了

我们直接粘贴上去 最后一行是让他生效

我们直接回车 他现在就已经切换为bbr了

我们再尝试

查看一下当前的拥塞控制算法 就是bbr

如果说你的linux系统的内核版本低于4.9的话 就

没有内置这个bbr

可以输入这条语句来查看当前的linux版本

那我的版本是5.15

比4.9要高出不少

那如果你的是比4.9要低的话 建议你更换操作系统

大部分用户的话应该都是比4.9要高的

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

而且如果别人用cubic算法的话 你用bbr算法的话

你会比他获得更多一点的带宽

因为他检测到丢包之后 他会直接把发送速率降下来

bbr的话他不会马上把速率降下来

所以说你降下来的部分他就可以先去抢占他

所以说拥塞控制算法的话也要讲究公平性

你不能像个流氓一样去把这个带宽全部抢过来

比如锐速的多倍发包

你这个网络太堵了 我的数据发给你的话会出现丢包的情况

那我就发好几份给你

那总有一份 我的服务器能收到

这种的话就比较流氓

如果大家都这样干的话

这是非常浪费资源的

还有一种是最近比较火的歇斯底里

我之前的话也录制过他的搭建教程

他的话是基于QUIC协议

并且QUIC的话他是基于udp的

udp协议的话 他是没有拥塞控制算法的

也就是 udp的话 他一直都是全速发送数据的

但是udp的话 他是一个不可靠的传输协议

他发过去的数据 他丢了就丢了 他不管

不会像tcp一样有一个确认来确认对方是否收到了这个数据

所以基于udp的QUIC协议 它实现了可靠传输

里面也封装了拥塞控制来控制udp的发送速率

QUIC的出现的话 它主要是解决了tcp存在的

队头阻塞的问题 这个的话要讲明白的话又比较麻烦 大家感兴趣的话可以自行搜一下

2023-06-06T13:45:10.png

由于QUIC它是在应用层的

tcp的拥塞控制算法的话 它是在系统级别的

你要改系统里的拥塞控制算法是比较麻烦的

但是如果说改QUIC协议里面的拥塞控制算法是比较容易的

QUIC里面的拥塞控制算法可以用cubic 也可以用bbr

也可以自己实现拥塞控制算法

歇斯底里它是自己实现的拥塞控制算法

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

我们可以在官方文档中看到它的描述

也就是说 他会像udp一样按照最大的传输数据来发送数据

不管你网络中堵不堵 我就按我最大的数据来发

至于拥堵的情况下 造成数据包的丢失 我不管

由于没有队头阻塞的情况 就会疯狂的发送数据过去

这边的话 如果出现了丢包

会一次性返回已经丢失了的数据包给这个客户端

客户端知道哪些数据包丢失之后再补发过去就行了

所以说他也是一种不管别人死活的这么一种协议

所以歇斯底里的话可能不会成为主流

因为大家都这样做的话 这条链路就会根本就没办法正常工作

而且udp的数据的话也不受运营商待见

大量的发送肯定会被QoS

所以如果使用歇斯底里的话并不是一个很好的选择

但是从另一个角度来讲

如果你的线路好一点 不要这么烂的话

谁还会去用歇斯底里

你不扩容 我们只有跟大家抢带宽

才能维持得了生活这样子

所以说并不是说这个协议不好 而是具体要看大家怎么用

经过我之前的测试的话 也确实能给你的垃圾vps带来比较惊艳的提升

ok 以上就是本期给大家分享的全部内容了

这也是关于节点搭建系列的最后一节

如果说再有人问你怎么搭建节点的话

你可以直接把这个系列的链接甩给他

关于节点搭建的多数问题都能在其中找到答案

感谢大家一直以来的支持

可以看到我的更新速度是非常慢的

主要是我并没有太多时间去录制教程

而且这种原理性的东西要讲清楚的话也很费劲

如果没有大家的支持和鼓励 我可能都没有动力更新完成

再次感谢大家的包容与理解

往后我也会继续加强自身的学习

给大家提供更好的内容,我们下次再见

标签: 节点搭建系列

评论已关闭