社区应用 最新帖子 精华区 社区服务 会员列表 统计排行 银行

  • 23927阅读
  • 4回复

cloudflare免费CDN加速详细介绍与用法

级别: 管理员
发帖
8532
金币
2762
威望
3231
贡献值
0
元宝
0
网站用CloudFlare做免费加速



前不久在我的怂恿下同事也想选择 来作为其服务器,可惜国内用网通的朋友报告说打开网站的速度极慢,在不换VPS的情况下唯有启用CDN,于是想起了曾经了解过的CloudFlare。


什么是CloudFlare


根据其官方说法,CloudFlare(CF)用于加速网站,以及保障网站可用率。其原理为:通过设置新的DNS,将用户访问服务器的request转发到CF,然后CF直接访问服务器取得response之后回复用户;同时,CF会缓存服务器的内容,以便在服务器不可用的情况下继续提供网站在线。下面这个官方涂鸦描述了其原理


据称CF还提供安全措施防止DOS等攻击。CloudFlare号称全球拥有14个数据中心,会选用最优线路为就近用户加速,而离中国最近的就是香港和东京节点了


如何使用


1. 先到其主页https://www.cloudflare.com注册帐号,在提交帐号密码后会有40秒的等待,期间会播放一个tutorial说明CF是如何工作(其实就是宣传片),40秒后点击继续。


2. 接着会进入第二步,检测原有的DNS记录,此步骤用于检查DNS记录是否正确,如果不变,默认即可。对于二级域名指向不同服务器的童鞋,可以将CF服务关闭,直接点击类似CF logo的云将其变灰即可


3. 第三步是选择套餐,因为默认是免费帐号,所以默认即可。


4. 最后一步,设置DNS。根据其提示,到域名注册商那里将DNS改成CF的DNS服务器即可。修改完后点击继续,之后CloudFlare就会开始为你加速。


注意事项


说到底,CF其实就是一个反向代理,其加速原理只不过是利用其分布全球的节点来选择快速线路接入服务器而已。在不修改源码的基础上,普通网站可能无法获取用户真是的IP地址。如果是wordpress用户,可以使用官方提供的插件,这样用户留言就会保留原始IP。


上图可以看出,所有访问的IP都是CloudFlare发出。


另外,使用CF其实可以防止被墙,因为用户访问的只是CF的地址,当然,前提是域名没有被墙、域名DNS没有被污染、以及CF没有被墙。

QQ: 378890364 微信:wwtree(省短信费) 紧急事宜发短信到0061432027638  本站微博:http://t.qq.com/wwtree QQ群:122538123
级别: 管理员
发帖
8532
金币
2762
威望
3231
贡献值
0
元宝
0
只看该作者 沙发  发表于: 2013-07-02
停用了Cloudflare的免费CDN
人间四月天,四月的春天果然是个躁动的季节,昨天晚上兴兴然使用了Cloudflare的免费CDN,但事实是经过1天的详细使用后发现,不妥,为啥不妥呢,我也不知道,也许是只仅仅使用24小时不到的缘故吧,但是,反正,我已经果断决定停用了Cloudflare,套用一句外交辞令:这次停用是无限期的停用,可能明天我又会启用(基本不可能),又或许永远不回归,谁知道呢?天知道!




经过测试发现,其实对于本博客来说Cloudflare作用不大,有图为证:










上面两图是没有启用Cloudflare后的测试结果,下面再上两张启用Clouflare后的测试结果(测试结果来自Webkaka.com):










两种情况的对比结果并不能说明Cloudflare给我带来了多给力的提升,通过比较发现,Cloudflare给了我两个ip地址:173.245.61.122和199.27.135.44,两个都是米国加州的Cloudflare地址,对我们墙内人来说其实区别不甚大啊,那么那么多人不是说Cloudflare在亚洲的日本、东京、新加坡设有节点可以就近访问的么?而且我们也都是冲着这三个点才使用Cloudflare的啊,那么事实是怎么样的呢?


诸位看官可以查阅下博客《留点后路》的博文《Cloudflare的亚洲节点问题》(http://www.citydog.me/1180.html),里面说到:按理说,从中国访问,无论地理位置还是网络位置,日本都是最近的,我们访问托管在Cloudflare上的站点时,东亚/东南亚地区的访客应该走日本节点才对,但事实上走的却是美国San Jose(圣何塞/圣荷西)。这里就很值得我们寻味一番了,各位需自行判断了。


另外,网上也有人说是不是装了那个Cloudflare出的Wordpress插件就能加速的问题,经过我的思考和小小的判断,这个插件的功能仅仅是显示访客的真实IP而非Cloudflare的节点IP以及优化数据库而已,至少目前是这样,与是否能加速的确是没有一毛钱的关系,因为访客的浏览器只是认你DNS给的IP地址来索取资源的。


还有,启用Cloudflare后,似乎对搜索引擎有那么一丝丝的影响的,可能对谷哥还好,但对于墙内的那个婊子引擎,网上的人说了,9成9的利空,对引擎和SEO相当感冒的同学必须要重视,采取额外手段来修补哦,博主我的脑袋里自认为没有多少真材实料,故而不打算继续牺牲脑细胞的。


最最最重要的是听说Cloudflare的IP经常会遭受一些很特殊的对待,这个我们暂且按下不表,大家都懂的。


以上就是我决定果断停用Cloudflare的原因啦,要不怎么古语云免费的没啥好东东,咱不是某督,一会儿红一会儿黑的,不是那意思,也没想着怎么怎么样,纯粹就是瞎折腾,也没啥网站的具体技术实力,因此也许肯定有不对的地方,就这样啦~
QQ: 378890364 微信:wwtree(省短信费) 紧急事宜发短信到0061432027638  本站微博:http://t.qq.com/wwtree QQ群:122538123
级别: 管理员
发帖
8532
金币
2762
威望
3231
贡献值
0
元宝
0
只看该作者 板凳  发表于: 2013-07-02
Cloudflare的亚洲节点
CloudFlare对于服务器在海外的个人博客来说,是款相当不错的免费CDN,依靠其分布于欧、美、亚三地的数据中心,在世界范围内免费为你的站点进行加速。其中,Cloudflare的亚洲节点在日本东京,按理说,从中国访问,无论地理位置还是网络位置,日本都是最近的,我们访问托管在Cloudflare上的站点时,东亚/东南亚地区的访客应该走日本节点才对,但事实上走的却是美国San Jose(圣何塞/圣荷西)。


网上有人说这是Cloudflare针对免费/收费用户加以区别的例证,或许购买其收费服务后,方可对日本节点进行访问。但通过与Cloudflare客服进行沟通,方才得知不是这么回事!以下是客服针对此问题的回复:


Are you running the traceroute from your own server or from a web hosted traceroute service? If the latter, it could be that the US datacenter is the best route.


We use anycast, which allows us to have multiple machines across the network respond to the same IP address. The routing will then find the shortest path (with the lowest latency). It looks like you’re accessing the Internet from China. While from a geography perspective it may seem like Japan is the closest path, inter-country peering in Asia can be funky and it may be that the route to San Jose is actually more efficient.


We’ll investigate further and adjust our routing if it looks like you’re getting misrouted. Be aware also that we are planning on adding a number of additional datacenters throughout the Asian region in the next few months.
看回复的意思是:对于亚洲国家来说,针对Cloudlflare服务器的访问,最佳路径是走美国San Jose,而非日本;另外Cloudflare准备在随后的几个月内,在亚洲增加服务器分布,来优化调整针对亚洲客户的访问。相信到那个时候,就真的不必访问美国服务器了吧?!


以下是经过Webkaka测试的东亚部分地区针对Cloudflare访问的Tracerout路径:






香港地区






日本






大陆


不过这其中最让人不解的是:大陆、香港地区的访问,按照客服所说,走美国还可以理解,但日本本地用户的访问,怎么也走的美国?!难道日本访问Cloudflare的速度比日本国内还快不成?!我已经就此回复客服,正在等待回答。
QQ: 378890364 微信:wwtree(省短信费) 紧急事宜发短信到0061432027638  本站微博:http://t.qq.com/wwtree QQ群:122538123
级别: 管理员
发帖
8532
金币
2762
威望
3231
贡献值
0
元宝
0
只看该作者 地板  发表于: 2013-07-02
Cloudflare使用CNAME解析方法
问题前奏


今天讨论主题是使用CNAME解析,可能很多朋友跟我一样,不想更改NS到Cloudflare,因为在Cloudflare的记录更新速度慢,最主要是不利于国内SEO。通常情况下,我使用dnspod的搜索引擎解析来提高搜索引擎抓取效率,但这点优势在更改NS后就不能继续使用了,这也是之前有相当一段时间选用Incapsula的原因(使用CNAME解析加速),后来Incapsula节点挂了又挂,无奈回到Cloudflare,结果收录什么的随之一落千丈,看来dnspod还真有不小的作用。更换过国内民间服务商提供的WDCDN,效果不明显,最近申请了配置了安全宝,发现也需要修改NS,而官方说明是可以使用CNAME,具体细节在上一篇《安全宝试用体验与CNAME解析方法》描述的很清楚。


虽然安全宝的加速不错,但还是不够稳定,单独使用安全宝恐怕会造成部分地区间歇性不能访问。于是想到之前就曾想过的CNAME指向Cloudflare,网上普遍做法是解析NS记录到Cloudflare分配的NS,激活后再改回NS,使用A记录至今指向Cloudflare的节点IP,但是这样的方法似乎现在不好用了,一旦NS记录修改,Cloudflare就会检测到,在一定时间后就会取消域名。所以这个方法是行不通了。故此,如果你有需要,请看下部分。


最新CNAME指向Cloudflare方法


方法启示:
其实这个方法也不算什么新发现,就是使用安全宝的时候联系客服询问CNAME指向的时候得出的结论。安全宝现在似乎没有提供专门的CNAME域名。有一个只是普通账号的域名,NS解析在安全宝上面,然后我联系客服加CNAME,客服就随便加了个给我,然后我将记录CNAME指向客服提供的二级域名即可。


即:客服提供xxx.abc.com形式的二级域名。而abc.com的NS记录指向了安全宝的NS,所以二级域名可以开启加速,将xxx.abc.com指向你的站点IP,再将你的域名指向xxx.abc.com,这时候等解析生效就实现了CNAME指向。


经过一天的解析指向测试,因为安全宝需要审核才能加入,所以,只针对已经审核过的域名的CNAME才会生效,其余的则会显示404错误。但是,Cloudflare使用没有什么限制,虽然需要验证NS记录,但是任何域名都可以申请,所以尝试在博客域名下添加xxx.poorren.com,指向朋友的主机IP,再用他的域名CNAME指向xxx.poorren.com,前提是他没有使用过Cloudflare,等待解析生效,发现依然有效,这样以来,相信大家都明白了吧。


解析方法:
你可以使用闲置域名修改NS到Cloudflare,然后使用任意二级域名解析到你的网站源IP,再讲你的域名CNAME到前面解析的二级域名,等待生效即可。测试证明,你也可以将你的域名直接CNAME到任何一个跟你网站使用同一IP的Cloudflare账号下的加速域名上面,CDN会根据指向的域名自动缓存。不过还是推荐使用闲置域名解析NS,做CNAME,没有的话注册个免费域名也可以(如果你愿意)。


8月8号最新更新:


看来一天的时间还是不够长,一直观察没有问题,就在写完文章没多久却发现,如果没有在Cloudflare服务器上添加过的域名,完全解析后会提示DNS Resolution Error。可能我之前设置的大多是已经添加过的域名吧。而网络慢,刷新慢。没有使用过Cloudflare的域名解析后生效也就慢了点。现在重新将出错域名在dnspod控制面板临时解析ns到Cloudflare,以激活Cloudflare,具体激活后能不能长期使用第三方的CNAME,有待明天出结果把。


8月14号最新更新:


经过一周的观察,按此设置暂时稳定,一周后cloudflare会检测到ns服务器有变动,后台显示不正常,但网站正常访问。


9月22号最新确定:


基本上,这一个月按照上文设置方法使用cloudflare没有出现问题,大家可以放开尝试喽。
QQ: 378890364 微信:wwtree(省短信费) 紧急事宜发短信到0061432027638  本站微博:http://t.qq.com/wwtree QQ群:122538123
级别: 管理员
发帖
8532
金币
2762
威望
3231
贡献值
0
元宝
0
只看该作者 4楼 发表于: 2013-07-02
CloudFlare与WebLuker比较
之前用过国内的免费CDN:WebLuker, 最近又试用了老美的CloudFlare,所以很自然地就将两者做了一次简单对比(本人不是砖家,有失偏颇之处请忍住),有需求的童鞋们可以对比参照,选择适合自己的服务商。





先说说两者的节点范围:CloudFlare在分别在美国加州的圣何塞、伊利诺伊州的芝加哥、佛吉尼亚的阿什本、日本的东京、荷兰的阿姆斯特丹,布有节点,基本上北美、东亚、西欧都做了分布,国内用户访问,基本都走的日本节点;WebLuker的节点分布在国内,电信和联通都有,海外访问基本都走的东部沿海的电信节点。


再说说上手过程:CloudFlare的操作过程跟Windows的程序安装类似,一路“Next Step”即可,该过程中CloudFlare自动读取你的当前DNS设置,且在你的确认之后,保存并提示你更改域名DNS为CloudFlare提供于你的两个,然后就是等待新DNS生效即可(很多童鞋不喜欢更改DNS,这对站点的SEO等指标不利),在设置期间,你即使不看帮助文档,也能轻松自如的做好一切工作;另外,你可以方便地开启或关闭你的域名、子域名的服务状态:是使用CloudFlare的CDN服务,还是直接使用源站服务。而WebLuker就多少有点麻烦了:添加加速频道、等待审核、完善服务信息,我当时如若不是跟客服不间断地沟通,恐怕一周之内都无法完全理解WebLuker的工作流程。这些步骤中,尤其是等待审核这一步,需要你的域名备案信息,并且要人工审核你的站点内容,多少让人觉得不舒服、慢,不过鉴于国内的形势,这么做也无可厚非!不过,WebLuker不需要你更改DNS,只要做好相关域名的CNAME设置和服务信息即可。





第三,看看两者的衍生、周边服务:WebLuker在你使用其服务的同时,还提供了智能DNS(可分运营商、大区的解析模式)、HTTP/HTTPS/SNMP/PING/端口监测、站点监测的一站式监测服务,相当方便。CloudFlare则没有提供类似的监控功能,但却有另外的两项重量级服务可用:一个是Analytics统计分析,另个是阻止攻击(Threat control)。Analytics服务不用赘述,这就是一个简版的Google Analytics;“阻止攻击服务”则比较实用,它会列出针对你的站点有危害行为的IP,并将其详细信息(Whois、运营商、物理位置、危害类型等)以报告的形式表现出来,你可以针对某一个或多个IP进行“拒绝”和“信任”的设定,另外,你还可以自己输入某个/某段/某国的IP,来进行有针对性的“拒绝访问”。除此之外,可暂停CDN的“开发者模式”、针对已缓存文件的“一键清除”、图片的防盗链功能、缓存级别、安全级别等等一系列细致周到且实用的功能,更增加了CloudFlare的吸引力!





第四,两者CDN服务带来的实际效果:CloudFlare离我们最近的毕竟只有一个东京节点,再快,Ping值也在150ms以上;而WebLuker则拥有众多的电信、联通节点,但针对国外访客,效果不甚理想;所以两者针对国内、外不同访客的服务质量上的优劣,一眼即知。


最后一个,就是服务在国内的“可持续性”:针对CloudFlare的封锁已经开始,幸好其可用IP地址众多,如果你在使用中被分配了一个“失效”IP,那么别犹豫,马上和他们的客服联系,他们会在24小时内为你更换一个新IP。也是因为这个原因,在解决问题的同时,我还因此而结交了一位美国朋友,用E-Mail聊聊天也不错!相反,作为标准的国内企业,ChinaCache旗下的WebLuker的风险则要小得多,况且在使用他们的服务之前,一系列审核步骤都已就绪。
QQ: 378890364 微信:wwtree(省短信费) 紧急事宜发短信到0061432027638  本站微博:http://t.qq.com/wwtree QQ群:122538123
描述
快速回复

您目前还是游客,请 登录注册
如果您在写长篇帖子又不马上发表,建议存为草稿