Zby's Blog

Let’s Encrypt 是 2015 年底开放公测的一个项目，旨在为互联网上所有网站提供免费的 HTTPS 证书。为网页服务器启用 HTTPS 加密，不仅可以增强网络链接的安全性和保密性，也可以通过 SPDY 与 HTTP/2 加速网页的传输速度。很久之前我就想为我的服务器启用 HTTPS 了，但是因为从 HTTP 迁移到 HTTPS 比较麻烦，Let’s Encrypt 的服务器 BUG 不断，所以一直拖了下来。今天我为我的域名申请到了证书，并用此证书运行了一个简单的测试页面，现在可以通过 https://www.zbyzbyzby.com 测试 HTTPS 证书了。等我有时间之后，我再在把整个网站迁移到 HTTPS。

p.s. #1  从 HTTP 迁移到 HTTPS 并不像想象得那么简单，由于浏览器对混合内容的禁止策略，即使做了跳转，在很多情况下 HTTPS 的页面也不能直接引用 HTTP 内容。迁移需要改掉页面上的大多数链接，很烦人。
p.s. #2  Let’s Encrypt 项目还不稳定，而且它的证书有效期只有 90 天，需要频繁地重新申请，我决定先测试一段时间，如果没有太大的意外再迁移。
p.s. #3  Let’s Encrypt 签出的证书目前不支持 Windows XP SP3 系统（IE, Chrome, Opera 等浏览器），有一定的局限性。但 Firefox 浏览器除外，因为 Firefox 使用自己实现的加密套件，不受系统的影响。支持系统列表

网上为 Apache 启用 gzip 压缩的教程一抓一大把，然而很少有提及在启用 gzip 时需要注意 ETag 的配置的。由于 Apache 的设计原因，gzip 与 ETag 不能很好地一起工作。例如有很多本应该发送 304 Not Modified 的回应，在启用 gzip 后，会发送 200 OK 的回应。这样一来，原本无需发送数据的请求变成了需要发送数据的请求，相当于抵消一部分开启 gzip 减少网络流量的作用。当然，针对这个问题解决方案有很多，但是都不尽完美。我选择的是直接禁用对文件的 ETag，即在服务器配置文件中加入一句 FileETag None。这样一来，服务器便会用时间来判定是应该发送 304 回应还是 200 回应，避免了错误的回应消耗网络流量。

参考资料： StackOverflow 上的问答  Bug 39727  Bug 45023

最近几天，我为服务器配置了 IPv6，域名也添加了 AAAA 记录的解析，也就是说我的网站终于支持 IPv6 了。当然，由于阿里云并不支持原生的 IPv6，我采用了美国 Hurricane Electric 公司提供的隧道方式接入 IPv6，因此所有流量都要在中国与美国之间绕一圈。据我测试，以这种方式接入 IPv6 的带宽还可以，服务器 2 Mbps 的上传是可以跑满的；然而延迟方面就不乐观了，大概在 350ms 左右。

我最初尝试使用 6to4 的方式接入 IPv6，不过测试下来不论是带宽还是延迟都非常不理想，只好放弃了。后来我发现，几乎所有的教育网 IPv6 出国流量都被发往了美国 HE 公司，出于减少延迟的考虑，我便申请了它免费提供的 Tunnel Broker 服务，使用 6in4 隧道方式接入 IPv6。在 CentOS 服务器上的配置我是参考了这篇文章。

前几天，有越狱大神发布了 OdysseusOTA 工具，它可以将已越狱的 iPhone 4s 通过 OTA 方式刷写 6.1.3 版本的固件。目前，这个工具对 iPad 2 的支持还没有完成。事实上，几个月前，就有人发现了可以将 iPad 2 降级到 iOS 6.1.3 的方法，不过这种方法所需要的条件更加严苛：需要用到 4.x 固件的 shsh 以及 5.0.1 固件的 shsh；而 OdysseusOTA 工具只要求机器正在运行已越狱的固件即可，无须任何 shsh。

具体步骤：

1. 确认你拥有 iOS 4.x 以及 5.0.1 的 shsh。
2. 利用 redsnow 0.9.15b3 将 iPad 2 降级到 iOS 5.0.1。此过程需要对应的 iOS 4.x 以及 5.0.1 的固件。
3. 在 iPad 上检查 OTA 更新，它应该显示存在 6.1.3 的 OTA 更新。直接更新即可。

        2015 春节即(yi)将(jing)来(dao)临(lai)，大家都在互发短信贺新年，这时如何证明自己的信息不是群发的呢？因为我之前研究过比特币，我立刻就想到了它所用到的“工作量证明”算法。这个算法正好是用来解决这个问题的。算法大概是这样的：要寻找一个字符串，使得信息与这个字符串拼接起来的数据的某个密码学哈希值末尾有多个零。其实算法的核心原理就是利用密码学哈希的随机分布，让计算机不停工作，直到某个公认的小概率时间发生。

这看起来很抽象，下面我以这次发拜年信息为例子来说明这个算法：

• 首先要确定要发送的信息：这回我偷了个小懒，直接用名字的汉语拼音加上 2015happynewyear 就是要发送的信息了
• 然后规定一下加入的随机的字符串的格式：我选择了小写字母和数字作为随机字符串
• 之后需要选择一个合适的密码学哈希算法：我选择了 SHA1 算法
• 最后需要选择难度值：这次我选择的难度是要求哈希值末尾有 8 个零

例如我要证明 zhangboyang-2015happynewyear 不是我群发的信息，我就需要计算出消息+各种随机字符串的 SHA1 哈希值，直到遇到某个随机字符串所对应的哈希值末尾有 8 个零。
算法过程如下：

SHA1(zhangboyang-2015happynewyear/aaaaaa)
     =A9A558C5725D44C9C1A0CCD39C028DBCAF31A15C
SHA1(zhangboyang-2015happynewyear/aaaaab)
     =8F30E6253FF48D8CDD8211C778E621525D5B2A78
SHA1(zhangboyang-2015happynewyear/aaaaac)
     =6CCDC2C571D7CD9DC4078C8823DABC56A029C7BD
...more...

直到我枚举出的随机字符串为 oqkj1e，此时有

SHA1(zhangboyang-2015happynewyear/oqkj1e)
     =345EC337DADBDDBA0115669A7B7ECCF100000000

根据密码学哈希函数的特性，可以假设它产生出的哈希值是随机分布的，即可以假设产生的哈希值字符串最后 8 位十六进制数字是随机的。因此遇到 8 个数字全部是 0 的概率是 1/4294967296。此即说明算法枚举次数的期望是 4294967296。在我的计算机上，运行一次这样的算法平均消耗机时约 20 分钟。也就是说我写一条拜年信息需要约 20 分钟来计算出这个值，从而证明了我没有群发（因为要是群发的话每条消息都得花约 20 分钟，我承受不起）。

p.s. #1 要证明自己不是群发是 MHY 同学的要求 ^_^
p.s. #2 其实写一条信息平均需要的时间可以少于 20 分钟，因为我可以让它并行计算。（事实上我用了两台双核电脑来运行这个算法）
p.3. #3 羊年的第一个比特币区块大概是第 344064 号区块，它的 SHA256 哈希值前有 16 个零！