1976 年以前，所有的加密都是如下方式：

• A 使用某种规则对信息进行处理
• B 使用同样的规则对处理过的信息进行复原

这个方式很好理解，不论是非常简单的 ROT13 还是目前广泛使用的 AES，都是这种对称加密方式。

但是这种方式有一个巨大的缺点，那就是 A 需要将对信息进行处理的规则（也就是秘钥）告诉给 B。怎样安全地传输秘钥就成了一个非常棘手的问题。

那么存不存在一种方式，加密和解密使用不同的秘钥，彻底规避掉传输秘钥的问题？

答案是存在的，感谢数学家和计算机科学家，RSA 就是这样一种非对称加密方式，也就是：

• 使用算法可以生成两把钥匙 A 和 B
• 使用 A 加密的信息，使用 B 可以解开
• 使用 B 加密的信息，使用 A 可以解开

日常使用中，我们把一把作为公钥，公开发布。一把作为私钥，自己保留。这样，任何人都可以使用我们的公钥加密信息发给我们，我们则可以使用自己的私钥解开。

只要把私钥保存好，这个通信系统就非常安全。

之前用 Go 编写过一个简单的服务器和客户端，用来测试 Go 的 HTTP 性能，无意中发现了一个奇怪的问题。

在我的 Mac 上客户端程序会非常稳定地遇到 Connection Reset 的错误，让人一头雾水。

图片是大部分网页的重要组成部分，一般情况下，我们不会太关注这方面的问题，需要显示图片直接一个 img 标签搞定。

但实际上，无论是对于提高加载速度，还是对于优化用户体验，优化图片都是一个重要的手段。

图片优化分成两个方面：

第一，图片压缩。在保证视觉效果的情况下，减少图片的体积。这个很有效，1M 和 100K 的图片，肉眼看起来几乎差不多，但却省了 90% 的流量，大大提高了加载速度。

第二，响应式图片。根据客户端的情况，选择最合适的图片返回给用户。用户是一个 500px 的设备，那么返回 1000px 的图给他就是浪费（假设物理像素和 CSS 像素是一比一）。

我们先来看图片压缩。

代理的英文叫做 *Proxy*，是计算机中的常用软件。

简单来说，代理的功能犹如它的名字所示：代替某人来处理某事。

常见的代理分两种，正向代理和反向代理。不管哪种代理，它们都位于客户端和服务器之间，将我们传统的 客户端 <-> 服务器 通信变成了 客户端 <-> 代理 <-> 服务器 通信。

字符串是任何一个编程语言中的重要概念，同时也是一个非常复杂的问题。

日常编码中可能并不一定能见到它的复杂性，下面是几个字符串操作，使用你最熟悉的编程语言，看看结果如何。

• 逆转字符串 "noël"，正确结果应该是 "lëon"
• 获取字符串 "noël" 前三个字符，正确结果应该是 "noë"
• 获取字符串 "😸😾" 的长度，正确答案应该是 2
• 字符串 "noël" 和字符串 "noël" 规整化以后应该相等（他们看起来一样，但是内部表示不一样，一个 6 字节，一个 5 字节，这里涉及到 Unicode 的规整化）

对于大部分编程语言，包括 Ruby，Python，JS，C#，Java 等，上面的问题都无法全部返回正确结果（但是，拥有超强 Unicode 支持的 Elixir 可以）。

DNS 全称 Domain Name System，是我们每天都在使用的基础互联网设施。

它被发明出来的原因很简单，计算机之间的通信用的是 IP 地址，是一串数字，人类记忆起来十分不方便，因此，我们给地址起个名字，然后将名字和 IP 之间的关系记录起来，这样，我们只用记住名字就行了。

从上面可以看出，DNS 系统类似我们日常使用的电话本，只不过里面存储的是域名和 IP 之间的关系。和人与电话之间的关系一样，一个域名可以有多个 IP，一个 IP 也可以有多个域名。

HTTP Basic Auth 是 HTTP 提供的一种验证方式，因为明文传输用户名和密码，非 HTTPS 环境下很不安全，一般用的非常少。但是在某些情况下用一用还是非常方便的，比如，一些静态站点例如文档系统可以使用 HTTP Basic Auth 进行简单的权限验证。

最近这段时间一直在忙着迁移博客，把原本基于 Jekyll 的博客迁移到了 Hugo 上。

之所以从 Jekyll 迁移的原因并不复杂，就是一个字：慢。Jekyll 的速度实在是太慢了，我只有几十篇文章，在 Watch 模式下，每次改动，重新生成都要花费 3 秒钟，实在是太慢了。

Regenerating: 1 file(s) changed at 2017-05-14 10:37:16 ...done in 3.085089 seconds.
Regenerating: 1 file(s) changed at 2017-05-14 10:37:20 ...done in 3.121783 seconds.

diff 是我们每天都要使用的一个功能，每次提交时，我都习惯先用 git diff --cached 看看这次提交更改了些什么，确定没问题，然后再 git commit。git 生成的 diff 非常直观，直观到我从来都没有去思考过 diff 是怎么生成的，觉得这应该是很简单的一件事，两个文件做个对比，不就行了。

最近一直在思考如何对线上服务做深度监控。基础的服务可用性监控很简单，定期 Ping 即可。但是怎样才能监控服务器的一些更加关键的数据呢？比如，每一个 API Point 的请求次数（QPS），最大响应时间，平均响应时间等。最终我希望实现的效果是有一个 Dashboard，我可以清楚地看到各种参数曲线，对服务器的运行情况了然于胸。

绘制 Dashboard 不难，目前提供数据可视化的工具很多，随便选一个都能满足需要。关键问题是，怎样将整个流程打通？

• 服务器该以怎样的形式暴露出数据？
• 数据怎样被收集和存储起来？
• 存储起来的数据怎样提供给数据可视化工具？
• 怎样做到足够灵活，可以可视化自己感兴趣的任意数据？