如何生成 CSR 文件

CSR,Certificate Signing Request,是制作 SSL 证书的必要步骤。一个 CSR 文件中描述了 SSL 证书持有人的信息(如个人姓名或公司名称)、联系地址等,用于验证 SSL 证书和域名是同一个人持有,以确保网站的合法性。

在 Linux 上生成 CSR 文件通常需要用到 OpenSSL 工具,这是一个命令行工具,参数一大堆,对于偶尔用一下的用户来说,可能不太友好。于是 DigiCert 提供了一个在线工具,用于生成 OpenSSL 的命令行,然后再拿去网站主机上运行就可以了。理论上 OpenSSL 一定要在网站所处的主机上运行,即换了主机之后要重新制作一个新的证书,但实践中并不强制这一步骤。

工具截图如下:

示例中我填写了 Google 的信息,请按实际情况修改,各项的含义如下:

  • Common Name: 你的网站域名
    • 如果你购买的是单一域名的 SSL 证名,请填写实际用到的域名,如 leonax.net 或者 www.leonax.net;在 DigiCert 购买的单一域名,填写 www 版本送裸域;
    • 如果购买的是野卡,则填写 *.leonax.net;
  • Organization: 公司名称,如果是个人用户,请填写自己的全名;
  • Department: 部门名称,可不填;
  • City: 所在城市;
  • State / Province: 所在州/省;
  • Country: 所在国家;
  • Key Size: 加密字长,目前常用的是 2048,如果对安全性要求较高,可以选择 4096;

全部填好之后,点击“Generate”即可以生成命令行,把右侧生成出来的一串命令,复制到 Linux 主机上运行即得到一个 CSR 文件。

之后要做的步骤是向 SSL 证书提供商上传这个文件,以获得最终的 SSL 证书,之后再详述。

注:OpenSSL 是一个 Linux 的工具,如果你的主机所用的是 Windows 或其它操作系统,可以在这个页面找到相应的介绍。

HHVM 中的 RepoAuthoritative 模式

HHVM 3.8 中提出了一个 RepoAuthoritative 模式,用于提升 PHP 代码的效率。

PHP 代码是解释型的,也就是每次执行的时候,PHP 引擎都会读取源代码,编译成机器代码之后再执行。这也就是为什么解释型语言比较慢的原因之一,它不能一次编译完成,而是一定要运行到哪里编译到哪里。编译的过程拖慢了整个运行的效率。而这样每次“编译”的过程显得有些多余,因为代码是基本不会变的。于是 PHP-FPM 是提出了 OpCache 来缓存编译的结果,如果代码已经被编译过,且源代码没有改动,则继续使用缓存。

而 HHVM 则更进了一步,在 RepoAuthoritative 开启之后,指定的文件夹会被编译成一个二进制文件,并同时进行优化。官方说法是,这样的优化可以在 HHVM 本身的基础上,再提升 20% 的运行效率。

开启的方法如下,其中 /var/www 是想要编译的文件夹。

关闭的方法如下:

编译的过程使用了 /var/run 做为临时文件夹,实测 WordPress 编译完成之后,要占用 175MB 的空间,如果 /var/run 太小会提示“disk is full”错误。

当然, RepoAuthoritative 也有一定的限制,比如不能使用 eval() 和 create_function() 等动态改变代码的语句。不过 WordPress 中几乎没有用到,说“几乎”是因为实际上有两处用到了,一个是在 wp-includes/pomo/po.php 中,这个文件貌似根本不会被执行到;另一处是在 wp-includes/atomlib.php 中,只要不使用 atom 作为 RSS feed 即可。另外就是编译完成之后,源代码的改动就会“失效”,要再一次编译才会使改动起作用。

然而,由于 HHVM 自身已经相当地高效了,开启 RepoAuthoritative 模式之后没有明显的变化。本站实测下来,TTFB 时间大概减少了 50ms,对于原本只有 700ms 左右的速度来说,看不出效果。我试用了一下之后就把它关闭了。不过至少说明在 WordPress 上使用这个功能是没有问题的。如果你的 WordPress 中有非常慢的功能,不妨试一下 RepoAuthoritative 模式。

在 PHP 中实现 String 的 StartsWith 和 EndsWith

和 Javascript 一样,PHP 中也没有对 String 实现 StartsWith 和 EndsWith 这两个方法。由于这两个方法很常用,我们只好自己来实现一下。

在 PHP 4 中,常见的做法和 Javascript 类似,如下:

上面的方法会使用更多的内存,并且对字符串扫描了两遍,效率不高。这种方法在 PHP 5 中已经过时了,因为 PHP 5 给出了一个 substr_compare 方法,可以直接比较子字符串,如果代码就可以简化成这样:

上述实现的效率至少快了一倍。由于历史遗留的问题,很多现存代码都没有更新,比如 WordPress 的源码中就存在了老版本的实现。如果你已经在使用 PHP 5 或者 HHVM,不妨试试第二种实现。

全站 CDN 开放测试

几个星期之前本站开始使用了 KeyCDN 作为内容分发和加速,和其它多数 CDN 一样,KeyCDN 也是可以被用于全站 CDN 的。只不过由于 WordPress 自身的一些缺陷,使得全站 CDN 配置起来非常麻烦。

全站 CDN 的好处不言而喻,就是速度快。本站的主机在台湾,亚洲的读者可能没什么大问题,但从欧洲访问过去,最快也至少要 500ms 才能得到内容(第一字节时间,TTFB)。而使用了 CDN 之后,TTFB 会下降到 50ms 以下,必要的 CSS 文件在 500ms 内下载完毕,达到了真正的秒开。

于此同时,之前的一些问题,比如留言之后 CDN 刷新不及时,都已经修复。目前已经没有已知的阻碍正常阅读的使用问题了。想体验一下的同学,可以在左上角目录中选择“使用 CDN”。如果你没有看到这个链接,则说明要么你已经在使用 CDN 了;要么,本站的 CDN 已被墙。

节点分布图可以看出,离大陆最近的节点在香港,除了主机所在地台湾之外,各大主要网络区域都有节点覆盖。也就是说,除了来自台湾的读者可能感受不到 CDN 的优势之外,世界上大多数地区的读者的访问速度都会有提升。

由于 KeyCDN 并不是针对全站 CDN 来设计,它使用起来或多或少还是有些不方便,没有 CloudFlare 那样的完美。但作为一个每月只需要不到一美元的服务,KeyCDN 真是物超所值。继续测试一段时间之后,如果没有太大的问题,站点将全面切换至 CDN 模式,进一步保护主机的安全。

使用 font-face 定义字体

最近在看中文字体,顺便也研究了一下 CSS 中关于字体的内容。

在 CSS 中设置文字的字体,需要使用 font-family 属性,比如下面的代码指定了段落(p)中使用 Helvetia 字体,如果系统中没有 Helvetia,则退一步使用 Arial 字体,再没有的话,则使用系统默认的无衬线(sans-serif)字体。

如果你想加载一种新的字体,则需要使用 @font-face 指令。@font-face 用于定义一个新的 font-family,并指定它的源文件。如下:

上面这段代码定义了 Genericons 字体,它的源文件有 4 种可选,eot、woff、ttf、svg。其中 eot 是为了兼容 IE 6 而单独存在的,其它三种则广泛被现代的浏览器支持。实际上,如果不考虑 IE 6,单 woff 一种格式就足够了,没有必要提供其它三种。

定义完之后,就可以在 font-family 中使用 Genericons 了。

@font-face 的另一个作用是统一同一字体的不同名称,比如本站所用的 Noto Sans CJK SC,在 Adobe 那边的定义为 source-han-sans-simplified-c,如果不想每次都在 font-family 中写两个,可以把它们写进 @font-face,如下:

这样定义了之后,在 font-family 中只要写 Noto Sans CJK SC 就可以了,系统会自动在本地查找两种字体,找到任何一种,都可被用来渲染页面。

另外在 @font-face 中还可以指定字重(weight)和样式(style),具体可以参考 MDN 的相关介绍

本站被强制 HTTPS

坛子兄的提醒,才猛然发现本站已经“被” HTTPS 了。在使用最新版本的 Chrome、Firefox 和 IE 11 访问本站时,浏览器将不允许你使用未加密的链接来访问本站。

原因?因为 Chrome 和 Firefox 分别维护了一份网站列表,当用户访问列表中的网站时,Chrome 和 Firefox 会自动使用 HTTPS 来访问。这项技术被称为 HSTS(HTTP Strict Transport Security)。我在使用 HSTS 之初就知道这个列表的存在,本来以为它们只是针对一些大的热门网站,毕竟收集互联网上所有的网站是不太可能的事情。但很荣幸的是,本站被两份列表都收录了:

Chrome(文件较大,谨慎打开)

Firefox

微软也表示,IE 11 将使用 Chrome 所提供的列表。于是,三大浏览器都将安全地访问本站。

如果想要使用 HSTS,只要在服务器的 HTTPS 输出中添加如下报头(Header)。注意一定要在 HTTPS 中才有效果,在 HTTP 中输出是无效的。

启用 HTTPS 的好处不言而喻,但这份静态的列表不禁让我担心某一天要是本站不支持 HTTPS 了,要撤销也是一件很麻烦的事情。不过现在还不用过分关注这件事,毕竟 HTTPS 是大趋势。

欢迎来到 HTTP/2 的世界

直到几个月前,本博客一直在使用 SPDY,后来 Apache 升级到了 2.4,Google 的 SPDY 库却不能用了。这个蛋疼的设定是因为 Google 把 mod_spdy 捐献给了 Apache 项目,此后自己就去专心做 HTTP/2 了。而 Apache 项目组自己却不知道在干啥,几个月都没有新代码提交,就让 mod_spdy 烂在自己的代码库里。

今年二月,在 Google 的努力推动下,HTTP/2 成为下一代 HTTP 通信标准,而它的前身,正是 SPDY 协议。SPDY 的最新版本是 3.1,目前已经较为流行,比如 KeyCDN 和 CloudFlare 都默认提供这项支持。HTTP/2 实际上是 SDPY 4.0,目前还没有广泛流行,预计到今年年底,Apache 和 nginx 才可能提供支持。

相较于 HTTP/1.1,HTTP/2 加载 SSL 的速度更快,对于多文件/资源的加载速度也有所提高,还有对流式传输的支持(本站不怎么用得到)。

由于本站使用了 Google 的网络支持,自动获得了 HTTP/2 的支持。如果你想体验一下 HTTP/2,请安装最新版本的 Chrome 或 Firefox,开启 HTTP/2 支持,然后访问本站即可。Chrome 中开启的方法是在 chrome://flags 找到 SPDY/4 的选项并启用。在访问的同时,打开 chrome://net-internals/#spdy,即可验证本站已活在 HTTP/2 的世界中。