日志

拥抱潮流，不要固步自封

最近博客做了一系小改动，摒弃了之前单纯为了性能而做的不必要的优化：

  • 重新开启转发功能：之前不用是因为第三方插件不好用，且性能差，现在已从技术上解决；
  • 重新打开 Gravatar 头像：之前不用是因为 Gravatar 访问不顺畅，也已从技术上解决；
  • 使用了 WordPress 4.2 的绘文字功能：之前的表情功能是被关闭的，因为有性能损失，但这不应该成为不用它的理由。

做出这些改动的原因是：我们应该紧跟潮流，否则会被科技抛弃。

WordPress 在 4.2 版本中强推 Emoji 表情功能，受到了一众非议，主要原因是 1) 引入了新的 Javascript 代码，增加了页面复杂度 2) 破坏了某些老旧的插件功能。于是就有人在第一时间做出了“禁用 Emoji”的插件。多数人选择禁用的原因是 2)，这自然是 WordPress 开发团队做得不好，但实际上没有多少团队可以把向后兼容做到完美，我们不必特别指责 WordPress。从另一个角度来看，向移动端看齐是一个必然的趋势。在移动热潮的大背景下，几乎所有的一线 IT 公司都在发力移动市场，WordPress 中增加一些相应的功能，是完全可以理解的。

当然，新功能总会造成一些人的厌恶，比如 iOS 7 的扁平化设计和 Windows 8 的 Metro UI，使得这两个系统刚开始的时候，装机量非常少。但这不代表这些抵制有就成效了，毕竟 Apple 和微软都是有能力领导潮流的公司，推动一个新生事物的发展并不特别依赖于用户，于是这些新功能最终还是被广大用户接受了。当然，在这种状况下，还是有相当一部分用户，至今还停留在 iOS 6、Windows 7 甚至是 XP。这种行为对以后的生活会造成什么样的影响，目前还不得而知，但我可以用另一个例子来打个比方。

大约在 40 年前，出租车在新中国重新兴起。以上海为例，大众出租汽车公司于 1988 年开始运营，之后的几十年，扬招打车的模式一直没有改进；到了 2000 年前后，电话叫车的方式开始普及，但电话叫车对于搭乘出租车的方式并没有本质的改善。

2003 年之后，在线电子商务开始发展，在线支付逐渐成为潮流，以支付宝为首的支付工具，把付钱的风险和痛苦减到了最低。当然，刚开始的时候，在线支付没有那么完美，存在各种漏洞或者不人性化的地方，于是就有人抵制，不开设在线支付的帐号、不网购。其实这也没什么，线下物流也很发达，不网购几乎感觉不到任何问题。

2008 年前后，智能手机开始普及。相对于传统的手机，智能手机可以自由得安装软件，软件质量也比传统手机好了很多；并且智能手机可以联网，通讯功能得到极大增强。当然智能手机也是有人抵制的，比如耗电量大、操作繁琐等缺点，使得一些人继续使用老式的手机。

在那之后，大约 2013 年时候，以 Uber 为首的手机打车模式开始风靡全国。由于一些运营商的补贴，直接造成了部分城市只能使用手机打车，而传统的打车模式叫不到车的情况。

然后那些不使用智能手机或者不会在线支付的人们就傻眼了，对于他们来说，手机打车是一个非常复杂的事物。既要会下载并操作手机应用，还要有支付帐号，如果之前没有经验，那将会是一个非常陡峭的学习曲线。会用手机打车的同学们，想要理解这个学习曲线，请自行购买一个 Dvorak 键盘聊 QQ。大多数人就直接放弃了学习手机打车，对他们的生活造成了很大的不便。

科技总是在不经意间进步的，最初拒绝在线支付的人们，肯定不会想到这还会影响他们的出行。而当年提出在线支付的公司，也不会想到这种方式会给人们的日常生活提供这样的便利。这些的确实实在在地发生了。

对于那些还在使用 iOS 6 或者 Windows XP 的人们，这些工具的确目前还可以满足你们的日常所需，就像当年的老式手机和线下购物。这些老旧的科技什么时候会影响人们的生活，或是产生怎样的影响，现在还不得而知。但历史的经验告诉我们，摒弃潮流，也会被潮流摒弃。

添加了社交网络的转发功能

已经有热心的网友注意到，本站最近增加了转发功能，就是在文章底部有一个下拉列表，提供了把文章转发到各个社交网络的功能。

之所以增加这样一个功能，是因为最近看到有来自其它社交网络的引用流量，看上去有发展的空间，于是就增加了这么一个功能，看看对流量有没有进一步的提高。总体来说我不喜欢把其它网站的图标放在自己的博客中，这些图标对于多数读者都没什么意义，但它们对想转发的读者来说，却又非常方便。于是我就折衷一下，放了一个不太显眼的下拉列表。

至于为什么不用第三方插件，比如 AddThis（国外）和 JiaThis（国内）？因为它们需要加载它们网站的文件，对于网络不太好的读者们，会有反作用。另外，无论是哪一个工具，都会把统计信息放在自己的网站，而我更倾向于使用 Google Analytics 统计插件的使用情况。于是我就选择了自己写这段代码，反正也不是特别复杂，而且可以根据实际情况，来动态调整，甚至是由程序自动调整这个列表，非常方便。

目前这个功能还是调试过程中，如果有任何问题，请留言。

已知问题：

  1. 在 Safari 中，不能在新窗口中转发；
  2. 在手机浏览器中，无法直接跳转到手机应用中；

使用独立的 Name Server

近日有一些读者反映，本站的 DNS 解析失败，出现网页打不开的现象。这主要是因为本站使用了 Google Cloud DNS 的缘故。

由于众所周知的原因，Google 的各种服务在国内并不能流畅访问。如果你在访问本站的时候，你所使用的 DNS 服务器恰好没有本站的 IP 数据，它就会向 Google Cloud DNS 发送请求，查询本站的 IP。这时候，邪恶的墙就会跳出来，把请求阻断了，于是你就会看到诸如 “DNS 查询失败”之类的错误信息。DNS 的具体工作原理可参考这篇文章。

由于墙已经严重干扰了用户的正常浏览，我只好放弃了 Google Cloud DNS，自建了一个 Name Server，用于解析本站的 IP。Name Server 和博客放在同一个服务器上，要么一起被墙，要么都能访问，很方便。

在调整 DNS 设置的这段时间内，博客可能会出现间歇性不可访问的情况，过几天会自动恢复。希望这样可以减少墙带来的干扰。

强制使用 HTTPS

Github 再一次受到攻击，和之前的攻击方式不一样，这一次，Github 被普通网民给 DDos 了。

攻击的大致原理是这样的，百度广告联盟所使用的一个 Javascript 文件被篡改，其中嵌入了一段代码，会每两秒钟给 Github 发送一次请求。由于国内很多网站都使用了百度广告联盟，一旦用户访问这些网站，这些用户的浏览器就开始自动攻击 Github。这一度造成了 Github 的服务瘫痪，一天之后才采取措施修复。具体细节可以查看乌云的一篇文章。

至于这是谁干的？大家应该都知道的吧。百度自己是不会砸自己场子的，而对 Github 有仇的，只有我们可爱的防火墙了。

之前我们印象中的 GFW 只是一个屏蔽工具，使得我们无法访问一些网站，而这一次 GFW 的升级可谓是令人恐惧的，因为它具备了修改文件的能力。这种攻击方式为称为“中间人攻击”，比方说，你在和朋友聊天的时候，并没有直接和他对话，而是通过一个中间人传话，那么这个中间人，就有了篡改你们对话能力。这次对于百度广告联盟的修改，表面上并没有让用户察觉到被墙了，但实际却发动了一次前所未有的 DDos 攻击。GFW 可以修改百度的文件，也自然可以修改其它网站的文件。如果下次它直接修改了 jQuery 的源文件，以 jQuery 普及程度，这种 DDos 的强度是大多数网站承受不了的。

作为对策之一，本站开启了 HSTS 以应对可能的中间人攻击。HSTS 是一项浏览器技术，网站通过一个特殊的报头（Header）告诉浏览器，建议浏览器使用 HTTPS 进行访问，在极大程度上避免了中间人攻击。在使用了 HTTPS 之后，你和本站的通讯，只有网站服务器和你的浏览器知道，网络上的各种路由器，包括墙，都无法得知，从而也就不能进行攻击了。

另外我也建议，上网的时候请尽可能地选择 HTTPS 的网站，即地址栏前面有一个小锁，表示当前浏览的网站是安全的。

即日起 RSS 将只输出标题

RSS 已经过时了，就让它平静地死去吧，继续坚持这项技术没有太大的意义。

RSS 诞生于 1999 年，那个年代，互联网还处于 1.0 的时代。那个时候，大家上网主要是看看新闻，查查资料。网站的设计非常老土，没有炫丽的特效，更别提社交功能了。与此同时，腾讯 QQ 也在 1999 年发布第一版，还没有普及。所以说当年的互联网，是一个单向的媒体，上网像看电视一样，纯属接收信息。基于当年粗浅的网页制作技术，RSS 诞生了，既然大伙的网页都不怎么好看，我们就把信息聚合在一起，方便读者采集和阅读。

十多年过去了，互联网技术已经摆脱 2.0，迈向 3.0 时代，而 RSS 技术却基本没有发展。它还是单纯的信息收集协议，不支持交互，也无法扩展。在科技日新月异的今天，RSS 没有未来。

具体来说，RSS 有哪些缺陷？

RSS 的主要问题是，没有给予原作者足够的名誉（Credit）。一篇文章，全文输出到 RSS，有心之人使用工具即可全部抓取下来，再贴到自己的网站/论坛上，就变成了自己的文章。这一过程可以完全自动化，后者无需过多精力，即可盗取原作者的全部功劳。由于搜索引擎的问题，转发的文章可能比原文的排名更高；并且由于 RSS 没有反馈的功能，转发的文章有了评论，原作者也看不到，没办法和读者交流，失去了进一步提升影响力的机会。

另一方面，RSS 只支持纯文本输出，而今天的互联网，或多或少都会有 Javascript 等动态脚本参与，比如本站就使用了大量的 Javascript 和 CSS 做效果，如果没有 Javascript 和 CSS，博客的阅读体验会下降非常多；而这些效果，在 RSS 中完全无法实现。RSS 中能看到的，只是粗糙的未经处理的文章，无法表达博主的全部意图。

与其让读者误会，还不如不输出，鼓励大家来博客上看原文。相比起 RSS 的全文输出，我更喜欢 Reddit 和 Hacker News 的只转标题和链接的方式，保留了文章的出处，也鼓励读者去原网站评论；对搜索引擎也很友好，增加了原文章的权重。这是一个双赢的模式。

基于这种想法，本站将不再输出任何博文的内容，只输标题和链接。看文章请点击 RSS 阅读器中的链接。

HHVM 崩溃后自动重启

不知为何 HHVM 不具备进程保护的能力，也就是说，HHVM 启动之后，只有一个进程，并且崩溃之后没有自主恢复的机制。大概是因为 Facebook 的服务器中有统一的方式来保护各种服务进程，也就没有在 HHVM 中单独做一份。但对于普通用户来说，HHVM 的稳定性有点弱。

今天一早，有位朋友提醒我博客没法留言了，现象是连接中断。后来我排查了一下发现原因是 HHVM 崩溃了，具体的表现有人在 Github 上已经反映过。好在我之前就有所准备，写了一个 Cron Job 定时检查 HHVM 进程，如果进程不在了，就自动重启 HHVM。这个脚本每两分钟运行一次，看来那位朋友不巧，正好撞在那两分钟的枪口上。

检查的脚本是从 Stackoverflow 上抄来的，代码如下：

虽然两分钟的间隔不算完美，但配合上 WP Super Cache 的纯净态支持，可以极大程度上避免博客下线的窘境。真正完美的方式，是开启两个（或多个）HHVM 进程，然后在 Apache 端做一个负载均衡，这样的话，即使有一个 HHVM 进程挂了，也不会影响到博客的使用。网上有人这样试过，但看上去很麻烦的样子，我还是等 HHVM 更新吧。

话说 Facebook 宣布这个月底有一个重大更新，HHVM 3.6，其中包含了很多稳定性方面的修复，值得期待。

投靠 Ubuntu

经过一番纠结之后，我还是把博客换到了 Ubuntu 之上。

之前提到过，从 AWS 转到 GCE 的时候，被迫选择了 RHEL 7（Redhat Enterprise Linux），因为只是 RHEL 7 是完全兼容 AmazonLinux 的。虽然 RHEL 需要另外付费，但为了平滑过渡，我还是以谨慎为先。

RHEL 有非常完善的商业支持，文档很齐全，有什么问题一查就可以明白。唯一的问题是，它的收费太高了，GCE 上面用一个月需要 50 刀以上，且不像主机一样用的时间长会打折，这样算下来，年费和一个 Radhat 的订阅差不多价格。但是我并不需要什么客户支持，技术问题都可以靠 Stackoverflow 搞定，这个订阅费用就白白浪费了。这也是我转向 Ubuntu 的主要原因。

还有一个原因是 HHVM。HHVM 是 Facebook 的 PHP 引擎实现，完全兼容 PHP 5.5 （及以上）。WordPress 从 3.9 开始，完整兼容 HHVM。

HHVM 的响应时间，据说是 PHP-FPM 的一半，也就是提升了一倍的吞吐量。原生 PHP 要做到这个效果，需要等 PHP 7 发布才行。看着各种发行版对于新软件的保守程度，不知道 PHP 7 要到什么时候才能成为主流。另一方面，Facebook 的研发能力肯定要比 Zend 来得强，等 PHP 7 发布了，HHVM 的性能肯定会更强。于是我就抛弃了原生 PHP，转投 HHVM。

当然，我也可以在 RHEL 上自己编译安装 HHVM。我试过，GCE 的机器编译了一个小时，我都快睡着了才编译完成，但安装（make install）的时候，告诉我某个文件不存在 -_-。我还是老老实实用官方的安装包吧，而 HHVM 官方只提供了 Debian 系列的安装包。

为什么没有选 Debian？Debian 保守到现在还只提供了 Apache 2.2，无语。

那也可以转投 Nginx 呀？我不高兴重写那一堆的 RewriteRule，并且 PageSpeed 在 Nginx 上也需要自己编译安装，不想再重蹈 HHVM 的覆辙。

由于 HHVM 和 PHP-FPM 的用法几乎一模一样，转换过程没出现任何问题，我做的唯一的工作就是重新设置了 Apache。花了几个小时，不过没什么难度，转换过程很顺利。

现在博客已经运行在 Ubuntu 14.04 + Apache 2.4 + HHVM 3.5 + MySQL 5.6 之上，欢迎测试，有问题请留言。