经验测评

Cloudflare railgun加速效果和深入解析(大坑)

nginx反代cloudflare-https

首先先安利一波本站自己的Cloudflare partners服务,可以很方便的在域名不使用Cloudflare的NS接入的情况下使用Cloudflare的cdn服务,并且可以使用Railgun节点,接入后提交域名申请即可
云喇叭CDN面板

然后呢说下Cloudflare Partners接入的域名接入Railgun加速的效果,站长其实测试很久了,说实话,效果还是有的,但是仅限于握手成功后减少TTFB值
而且条件其实很苛刻的,比如你的用户是国内电信访客居多,那么国内电信访问cf站点在不出问题的情况下都是分配到lax节点,这时候如果你使用的railgun节点在美西,那么railgun的效果就非常好,但是如果你的访客是别的用户,访问cf站点所分配的节点在其他区域,那么railgun的效果就不是很好了

说完了效果和条件,那么我们来谈谈cf railgun的超级大坑吧,这个其实很早以前就做过测试了,一直想着发文说说,但是没空啊,今天先写文,把别的事情放一放哈哈。首先先说Railgun官方介绍的是大幅度减少动态内容传输并减少带宽,但是这里有个大坑官方并没有说明

cloudfalre_railgun_about

cloudfalre_railgun_about

cloudfalre_railgun_about

什么大坑呢,也就是在大流量的站启用Railgun之后并不会减少你的服务器带宽使用,反而会大大增加,云喇叭在自己的一个小项目上启用了之后发现带宽使用增加了大概2.5-3倍,这个比例其实是很可怕的
不多说,下面我们来一个完整的流程演示吧,测试正常访问cloudflare加速后的站点和开启了railgun之后的站点,测试页面为phpinfo

首先是正常访问经过cloudflare cdn加速的站点

cloudflare_none_railgun

cloudflare_none_railgun

cloudflare_none_railgun_weblog

cloudflare_none_railgun_weblog

我们可以看到正常访问时的headers请求(因为我开着某种工具,所以cloudflare分配到了台湾节点),和源站服务器的日志文件,可以看到我们开启gzip后cloudflare的去源节点从我们的源站服务器获取了24395字节的文件

接下来我们开启railgun功能

cloudflare_railgun_open

cloudflare_railgun_open

cloudflare_railgun_open_weblog

cloudflare_railgun_open_weblog

我们可以看到在开启railgun加速功能后,浏览器的headers里可以看到railgun的特有信息,经过railgun加速后的页面只传递了原始页面13%的内容
但是我们去检查我们的源站服务器web日志会发现,流程依然是初次访问分配到cloudflare的去源节点(图中的162.158.241.34),后续访问都是经过我们的railgun节点,仔细看,你就会发现问题所在了,就是cloudflare官方所说的大幅度减少动态内容传递从而减少带宽使用其实没有完整的介绍,这个大幅度减少动态内容是指railgun节点跟cloudflare通讯传递的内容,但是railgun节点去你的源站服务器的访问读取动态内容源时,并未使用任何压缩(是的,就是这里导致了在大流量的情况下,源站服务器的带宽消耗增加数倍)
可能这时候有人会说了,是不是你设置问题,或者是你用的http,没使用cloudflare里https的brotli压缩,那个比gzip还压缩得多呢,其实我全都测试了,gzip和brotli压缩是cloudfalre节点到用户端的压缩,无论你怎么修改相关设置,railgun节点到你源站是不会使用任何压缩方式的。

至此,cloudflare的railgun加速功能深入解析完毕,感谢您的观看
我在全网搜索了,有人发现了这个问题,但是还没人说这个问题出来(也许是受众比较少拉哈哈哈)

所以假如您的站点流量不大,服务器的带宽是不限流量,或者服务器的带宽是比较大的,那么railgun开上总比不开强,有总比没有好吧哈哈哈
但是如果您的站点流量较大,服务器带宽较小或者是限制流量的话,那最好还是不要开启railgun加速了,毕竟每次动态内容访问都是去源读取非压缩的文件,这样带来的带宽和流量消耗还是非常大的

    For Share tools , Still working

关于作者

Yunlab-云喇叭-优选好物

6 条评论

留下评论