二月回顾

今天是三月二日,周一,天气非常好,春意盎然,好多地方的樱花都开了。

这是早晨用手机拍的照片,没有加任何一点点ps。

morning-sunshine.jpg

现在来回顾一下,过去的一个月,一共发布了十四篇文章,比一月的十篇文章要多一点,而二月只有28天,那么就是平均两天一篇文章。

对于这一个月的流量,因为只有28天,又因为中国新年的缘故,预期流量会有所减少,哪怕发布的文章数量上增加了40%,也会有流量上的损失,毕竟这是一个偏向技术的Blog。

之前一篇对于 SSL 优化的部分,谈到了去掉 RC4 算法的支持,把总评分提高到了 A-。但是还是有一项警告内容让我注意到了。

The server does not support Forward Secrecy with the reference browsers.

这里的 Forward Secrecy 是什麽呢?

维基百科上有该条目,可以去看看,下面是我的理解。

forward secrecy 也称之为 perfect forward secrecy,或者 PFS。称之为完美远期加密。是在HTTPS基础上进一步保护用户电脑同服务器之间的加密通讯。

其解决的一个安全场景就是,如果服务器同用户间的加密通讯内容被窃听,也被储存下来,这些被加密的内容虽然当时无法被解密,被破解,但是当日后,服务器的SSL密钥被取得后(不管是何种原因被取得密钥),这些过往的内容是可以用这个密钥来解密的。这样虽然时效性可能差些,但是仍然是会有被破解的危险存在。


而采用 完美远期加密 的 SSL 或者 HTTPS 通讯,加密钥匙只是短暂性的,而且不能从服务器的 SSL 密钥中推算出来,这样即使日后 SSL 密钥被第三方取得,过去和未来的 HTTPS 通讯仍然安全,窃听者始终无法破解所窃听的内容(以目前的技术而言)。


目前只有用  ephemeral Diffie-Hellman 的算法才算是 完美远期加密

比如 Google 搜索网站的加密就是。查看的方法是,点击网址栏中在网址前的那个绿色锁,在 connection tab 中可以看到使用的加密算法,这里看到的是 ECDHE_ECDSA ,这里的ECDHE就代表的是这个。

google-ecdhe-ssl.jpg

SSL Labs的报告中,RC4已经不是一个安全的算法了,WhoVPN原先使用的加密算法中包括了RC4,SSL Labs的检测报告只有B。
最主要的因素之一就是因为网站的加密算法用到了RC4。

RC4是在1987年被设计出来的密钥长度可变的流加密算法。它加密解密使用相同的密钥,所以就是一种对称加密算法。但是因为这种算法被发现存在弱点,在2015年2月,于RFC 7466规定中禁止在 TLS 中使用该加密算法。现在微软和Mozilla都已经建议尽可能的不要使用RC4算法了。

ssllabs-b-rc4.jpg

因此,在服务器的 Apache 设置中禁止使用 RC4 算法。具体的方法就是在SSL算法套件参数中添加了 :!RC4

之后,再做了一次测试,结果如下:

Google AdWords 客服不错

使用 Google AdWords 有一些年份了,只是最近有一段时间没有用,前些日子登录后台,看到账户系统改版了,点进去一看,过去存着的一些钱不见了,大概3百多吧,现在余额为0了。于是通过客服支持的表单提交了有关的疑问,大概两三天的时间,Google 的客服回复email,告知已经查到原来的credit,并且会在24小时内到帐,过了一两天,我再次登录后台,在Billing页面,看到余额显示正确了,这些钱还在。

又过了一天,Google 的客服服务调查的 Email过来了,我也很高兴的填了表,表示满意。

这个小小故事,只是说明,再大的公司都会出现差错,但只要服务到位,用户总会买账的。

本次的一周更新,其数据就没有上周的好,原因比较简单,大家都去过年了,我也不例外,内容发布也少了。

从Google Analytics的统计数据来看,19,20,21三天的流量很低,最少的是20日。符合预期,大年三十,年初一的谁还有时间上网,做网站啊,都去抢红包了。


有一个星期过去,这又是一个周一,是很多省份的家庭日,也是休息的日子。
不过还有几个省份没有家庭日这个假日。
long-weekends.jpg二月份也就只有这一个假日。BC省也是从2013年才有的。

看看CloudFlare的统计,是最近七天的。

traffic-week2.jpg

根据Google Analytics的统计,过去7天同之前的七天相比,流量减少了5%。

看看百度抓取错误的页面,过去一周也没有出现抓取错误。

好很多了。

这样看来,采用 CloudFlare 云加速的效果还是很明显的。也的确满足了多线路不同ISP服务商都能顺利抓取的需求。

最近在用Baidu,百度站长平台,因此也有更多的机会体会到连接重置的问题。
过去很多在国内的网友上网,在输入网址后,有相当多的网站会出现下面这张图:
connection-reset.png
这就是连接重置,原因不是网站的问题,也不是网友电脑的问题,而是众所周知的国内网络管理方对于这些网站屏蔽的缘故,被称为GFW,伟大的防火墙。具体的细节就不解释了,很多文章解释的非常专业,非常详细。

这里我想谈的是GFW是双向的,特别是当该防火墙是针对域名,或者URL中的关键词的时候,那么使用该关键词的网址,即使是在国内,从海外访问国内的这个网站,都会被重置。
在百度站长平台上操作的时候,如果某个网站的域名恰好在那个黑名单中,就会被重置,而且在较短的一段时间内,访问该站长平台都会被重置。
比如在有一个网站已经被添加在了百度站长平台,它提示我该网站服务器不稳,具体是百度蜘蛛在过去24小时尝试连接网站发生错误率为50%,下面还提到了常见的原因,当然最有可能的原因它没有放上去,那就是被伟大的防火墙阻止了访问。
connection-error.png
那么当我在站长平台选择该网站想看看具体数据的时候,就出现了下面这个状况。

这是一个对于要想做好移动交互的网站站长而言非常重要的问题。什么样的网站算是移动交互不友好,这是怎样的呢?

说说最近我看到的一些网站,一些不好的例子吧。
比如有些网站需要用手指在手机上左右水平移动才能看到完整内容。
shanghai-online-iphone.jpg蓝色箭头指着的就是移动条,要左右拖动才能看到右侧的内容。

还有一种情况是要双击屏幕上的某个区块,该区块才会放大,能看清,有些即使放大了还不够,需要在用双指放大多些才能看清。那就是字太小了。

某些网页上可以点击的链接相互之间的距离太小,太近,手指的大小相对而言太大,按上去很容易就点错或者点击多个链接。

一周更新

今天周一,但是我们BC省是家庭日,法定假日,孩子们都在家,本想出去走走,下雨,就算了,还是在家好了。

看看过去一周用CloudFlare的情况好了。差不多是2月2日开始用CloudFlare的,也七天了。
cloudflare-traffice-sample.jpg

24270PV,其中有不到六分之一的是来自蜘蛛的抓取。而网络攻击它挡下来的有18个。

那么这些攻击的大致来源可以看看这个:

cloudflare-threat-origins.jpg大多数来自国内,剩下的来自乌克兰(这个比较奇怪)。

Archives