早年写过一篇关于常用图床的介绍，时过境迁，连当时最稳定的微博图床都已经不能简单地正常使用了。后来改用了一段时间 Github 图床，虽然一共没几张图片，但总感觉这是在滥用 Github 提供的免费服务，正好最近在折腾其他项目，干脆就自建了一个图床服务。这里就借机讲讲自建图床的思路。

图床的主要功能是图片的持久化存储和外部通过链接访问，由于图片的大小通常在几十 KB 到几 MB 不等，因此我们必须着重考虑以下几个因素：

最近入手了个软银线路的某工的日本机器，此线路是联通友好线路，可惜机器低配高价，性价比很一般。 入手的主要原因是为了能给家里的 NAS 建立个稳定的穿透链路，由于宽带和移动网络使用的都是联通，所以其实整体体验还不错，这里贴一下相关测试，给大家个参考。

前言

AirPods 已经重度使用了一段时间了，这篇文章来评一评这款耳机在我心中的优缺点。

优点

1. 充电快速、便捷：AirPods 本身的电量与同类产品相比已经很有优势了。而在大部分场景下，我们都很少能一次性用尽 AirPods 的电量，随手放入收纳盒后不久 AirPods 的又满电复活，收纳盒与 AirPods 的搭配简直不要太完美，做到了一次充电，数倍续航。
2. 音质尚可：AirPods 作为一款主打功能和便携性的蓝牙耳机，我们实在不应苛求其能拥有卓越的音质。但以个人体验而言，其音质与 EarPods 不相上下，甚至还在低音方面有一定的优势，还是比较让人满意的。
3. 稳定易用：本人过去使用过一些蓝牙耳机，连接的设备主要是 PC 和 Android 手机，偶尔会遇到蓝牙设置中搜索不到耳机而需要重启设备、耳机没电后 PC 没有暂停播放而是使用音响继续播放造成室友困扰等问题，即使没有上述的问题，每次要到设置界面手动选择耳机进行连接的体验在有些时候很是扫兴。而在购入 AirPods 后，这些「连接困难」、「连接不稳定」之类的问题从来没有遇到过，使用蓝牙耳机的步骤简单到「取出」、「带上」和「双击」，摘下和戴上耳机也会自动切换播放状态，体验非常棒！
4. 质量优异：购买至今已经摔落了将近十次了，无论是地板还是柏油路，AirPods 都毫发无伤。
5. 通话音质优秀：AirPods 采用的 W1 芯片确如官网介绍中所写的那样，很好地过滤掉了背景噪音，通话音质十分出色。

缺点

1. 无降噪功能：诚然，AirPods 或是大部分的纯无线耳机都明确标示自身没有降噪功能，但在地铁、食堂等嘈杂的场景下，尤其是仅仅途径嘈杂场所时，用户常常不得不多次调节播放设备的音量，体验令人崩溃。不过作为所有非降噪耳机的通病，这显然也是对 AirPods 的苛求了。
2. 轻易不掉，但掉了要命：由于个人的耳形问题，在之前使用 EarPods 时经常会出现掉落的情况，这也是我一直犹豫是否要购买 AirPods 的主要原因。好在入手后发现即使是我这样的耳形，摇头晃脑也不会使 AirPods 掉落。目前为止，唯一的掉落原因就是无意触碰。虽然在大部分场景下，这都不是问题，但本人曾经在雨天搭乘出租车时，在上车收伞的过程中不小心碰落了一只 AirPod ，直到车启动后我才后知后觉，好在最后还是即使寻到，但这的确是件令人后怕的事。
3. 不能直接调节音量：目前 AirPods 支持的手势有限，只能实现诸如「播放_暂停」、「上一首_下一首」和召唤 Siri 等功能，没有直接通过耳机调节音量的方法。
4. 无线连接距离不足：由于没有使用新的蓝牙协议，AirPods 的无线连接距离很有限，在公司接杯水的距离还尚可，想要戴着耳机去稍远点的卫生间可就必须要带着手机了，这是一个很令人遗憾的缺点。

背景

去年看到 Let’s Encrypt 宣布将在 2018 年支持 wildcard SSL 证书的消息时就一阵兴奋，虽然后来跳票了一次，但最终还是于前段时间正式支持了。本文将使用 acme.sh 这个小工具来体验下此项特性。

前言

最近写了个简单的 chrome 插件来简化工作流程，其中一个功能就是对当前页面的 URL 进行监控以根据 URL 中的参数发起网络请求获取数据，本文主要记录本功能相关逻辑的实现。

监控 URL

通过 window.location.href 就可以轻松获取到当前页面的 URL ，然而想要响应当前页面的 URL 变化则需要对相应事件进行处理。

弹出页获取页面 URL

首先在 manifest.json 中添加对 tab 的操作权限：

1
2
3

"permissions": [ 
  "tabs"
]

编码格式

PEM

• 内容：以 -----BEGIN xxx----- 作为开头，以 -----END xxx----- 作为结尾，主体部分使用 base64 对 ACII 进行编码。可以储存公钥证书（服务器证书及中检证书，「xxx」为 「CERTIFICATE」）和私钥（「xxx」为「RSA等加密算法名称 PRIVATE KEY」），也可以储存两者的联合，但通常情况下，Apache 等软件都会要求将公钥和私钥分开存储到不同的文件。
• 场景：*NIX 操作系统下普遍倾向于使用这一编码格式。
• 扩展名：.pem 、.key 、.csr 、.cer 、.crt
• 生成：openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 扩展名参照上文
• 查看：openssl x509 -in certificate.pem -text -noout 扩展名参照上文

DER

• 内容：由0、1组成的二进制数据，可以储存任何类型的公钥证书和私钥，不可读。
• 使用场景：Windows 系统 及 Java 平台倾向于使用这一编码格式。
• 扩展名：.der 、.key 、.csr 、.cer 、.crt
• 生成：openssl req -x509 -newkey rsa:4096 -keyout key.der -outform der -out cert.der -days 365 扩展名参照上文
• 查看：openssl x509 -in certificate.der -inform der -text -noout 扩展名参照上文

扩展名总结

前言

尽管相对于 HTTP ，HTTPS 在安全性上已经有了质的飞跃，然而简单的设置 HTTPS 仍无法避免类似于中间人攻击这样的恶意行为，而本文所要介绍的 OCSP Stapling 和 下篇文章将要介绍的 Certification Transparency 就是用来防范这些恶意行为的。

什么是 OCSP Stapling

OCSP (Online Certificate Status Protocol) 通常由 CA 提供，用于在线实时验证证书是否合法有效，这样客户端就可以根据证书中的 OCSP 信息，发送查询请求到 CA 的验证地址，来检查此证书是否有效。

然而这些默认查询 OCSP 的客户端在获得查询结果的响应前势必会一直阻塞后续的事件，在网络情况堪忧的情况下（尤其是大陆地区）会造成较长时间的页面空白。

而 OCSP Stapling ，顾名思义，是将查询 OCSP 接口的工作交给服务器来做，服务器除了可以直接查询 OCSP 信息，还可以仅进行少数次查询并将响应缓存起来。当有客户端向服务器发起 TLS 握手请求时，服务器将证书的 OCSP 信息随证书链一同发送给客户端，从而避免了客户端验证会产生的阻塞问题。由于 OCSP 响应是无法伪造的，因此这一过程也不会产生额外的安全问题。

前言

同步、异步与阻塞、非阻塞这四个概念在多线程、多进程、I/O 相关编程中非常常见。然而在不同的场景下，定义中给不同框架、操作系统功能所打上的标签常常让不熟悉这四个概念区别的人疑惑不已。本文就从许多应用层框架所依赖的 Unix 中的 5 个 I/O 模型来理解这四个概念。

Unix 5 大 I/O 模型简述

在 Unix 中，有 5 种 I/O 模型：

• 阻塞式 I/O
• 非阻塞式 I/O
• I/O 多路复用
• 信号驱动 I/O
• 异步 I/O

在类 Unix 系统中，I/O 操作总是分为两个阶段：

• 阶段一：内核等待数据到达，并在数据到达后内核将其拷贝到内核的缓冲区
• 阶段二：内核将内核缓冲区中的相应数据拷贝到进程缓冲区

同步与异步

结合生活理解这一对概念，我们假设一个场景：

前言

由于 Disqus 在国内访问困难，Hexo NexT 主题每每尝试加载文章评论数时都会严重拖慢页面加载速度。除了期望读者能够使用一些其他的方法访问网站，其实站长和博主们还可以主动采取一些措施来解决这一问题。本文另辟蹊径，不借助 Nginx 的反向代理，而是使用 Disqus 和 LeanCloud 的公共 API 来曲径救国。使用 LeanCloud 的原因是 Hexo NexT 主题可以很方便地设置使用 LeanCloud 来统计访问数，所以从减少访问数、减轻服务器负载和资源合理利用等角度，再进一步地使用 LeanCloud 来存储评论数量数据。

准备

注册并初始化 LeanCloud

参见 《Hexo的NexT主题个性化：添加文章阅读量》 一文中的 配置 LeanCloud 部分 ，注册 LeanCloud 并初始化应用。此后，我们的博客中每篇文章的信息已经通过参考文章中的方法保存到了同一张表中，因此我们只需要对这张表添加几个字段，就可以在实现本文目的的同时，避免使用 LeanCloud API 分别查询两个表的数据所带来的不必要的请求。Counter 表的字段如下图：

什么是 Brotli 压缩算法

Brotli最初发布于2015年，用于网络字体的离线压缩。Google软件工程师在2015年9月发布了包含通用无损数据压缩的Brotli增强版本，特别侧重于HTTP压缩。其中的编码器被部分改写以提高压缩比，编码器和解码器都提高了速度，流式API已被改进，增加更多压缩质量级别。新版本还展现了跨平台的性能改进，以及减少解码所需的内存。

与常见的通用压缩算法不同，Brotli使用一个预定义的120千字节字典。该字典包含超过13000个常用单词、短语和其他子字符串，这些来自一个文本和HTML文档的大型语料库。预定义的算法可以提升较小文件的压缩密度。

使用brotli替换deflate来对文本文件压缩通常可以增加20%的压缩密度，而压缩与解压缩速度则大致不变。使用Brotli进行流压缩的内容编码类型已被提议使用“br”。

摘自：https://zh.wikipedia.org/wiki/Brotli

另附 Brotli 算法和其他算法的性能比较：

• https://cran.r-project.org/web/packages/brotli/vignettes/benchmarks.html
• https://hacks.mozilla.org/2015/11/better-than-gzip-compression-with-brotli/

兼容性

• Google Chrome supported Brotli from version 49.
• Microsoft Edge has Brotli in Development.
• Mozilla Firefox implemented Brotli in version 44. 
• Opera supports Brotli since version 36.
• Safari, no public commitment as of October 2016.

摘自：https://en.wikipedia.org/wiki/Brotli

安装 Brotli 所需模块

首先安装 bagder/libbrotli