谁也不希望丢失数据，但这很难避免：文件误删除、意外停电、硬盘损坏、硬盘丢失、自然灾害……以上这些都会导致数据丢失，并且很可能无法直接恢复。相信很多人都有过这样的苦恼。本文将简单介绍备份的 321 原则，以及云端备份和本地备份的最佳实践。

典型的数据丢失案例

• 比如 GitLab.com 的运维人员就曾经误删除过数据：2017 年 2 月 1 日，运维人员使用了 root 账户错误登录到了主服务器上删除了核心服务数据。更严重的是，其中有五种备份方式都失效了。但幸好还留存着一个六小时前的备份，尽管网站在几个小时内无法访问，并且丢失了在备份之后产生的的很多数据，但最终还是恢复了绝大部分的数据，事件详情。
• WannaCry 病毒导致的数据丢失：WannaCry 是一种勒索病毒，针对 Windows 系统的一个漏洞去加密系统上的用户文件，导致用户无法访问这些文件，除非向一个比特币账户转账 $300 ~ $600（相当于几千人民币）。据报道有超过 30 万台电脑受到此病毒的感染。众多企业，包括银行、医院、铁路系统因病毒而无法正常运转。在中国，众多使用教育网的高校学生电脑受此病毒攻击，导致文件丢失。

以上的数据丢失都给人们带来了巨大的损失，但倘若我们能够提前做好数据备份，那么就能够降低数据后的损失。

最佳备份原则：321 原则

在进行备份的过程中，我们应该施行 321 原则，这样才能保证备份的可靠性与有效性。

• 三份数据拷贝：除了原始的数据之外，要另存两份数据的备份。倘若这三个拷贝丢失的概率相互独立（均为 1%），那么三份拷贝同时丢失的概率就仅有 0.0001% 了，这比两个拷贝同时丢失的概率更低。
• 两种存储介质：在同一种类型的存储介质上的数据更有可能同时丢失。比如你在电脑的内置存储器上存了三份数据拷贝，但如果电脑的磁盘彻底损坏、误格式化磁盘或者丢失了电脑，那么这些数据便一同丢失了。在上述案例中，另一种类型的存储介质可以是移动硬盘、SD 卡、U 盘、CD、DVD 等。
• 一个异地备份：多个备份间的物理隔离是很重要的。如果这些备份都放在一个房间里，那么一场火灾就足以毁掉所有的备份。如果条件允许，跨城市（间隔 100km 以上）存储备份就已经很安全了。在家和公司分别存放备份也算作异地备份。

此外也应该注意备份的时效性，如果可能，要尽量缩短备份周期。比如每分钟备份的时效性就强于每小时备份。在数据丢失时，前者只会丢失最近 1 分钟的工作，而后者会丢失最近 1 小时的工作。

云端备份

通常，云端备份是非常可靠的。云端服务器都会帮你做好 321 原则，你只需要选择一家云存储服务商并将要备份的文件上传上去即可。

建议选择提供了自动化备份功能的服务商，这样可以省去手动选择文件上传的步骤。通常自动备份还会对文件进行增量备份，即每次备份只上传上一次备份后有改动的文件，这样能大大节省上传时间。

一个典型的云端备份的例子是 iOS 中的 iCloud 备份功能，开启该功能后，iOS 设备会自动将图片、通讯录、文档、聊天记录、软件存档等个人数据上传到云端。在购买新的 iOS 设备后，这些数据都能够从云端自动恢复到新设备上。

使用对象存储进行简单的备份

定期将服务器上的重要文件打包上传到对象存储，即可实现简单的备份。可以直接使用 Amazon S3、Google Cloud Storage、阿里云 OSS、腾讯云 COS 的对象存储，上述服务均提供 99.999999999% 的持久性，即文件一旦上传完毕，几乎不可能意外丢失。云服务中的对象存储通常是在一个区域内的多个可用区（通常至少三个）进行存储，每个可用区内也包含文件的多个副本。各个可用区之间有一定的距离，所以这实现了异地。关于区域和可用区，可以详细参考 AWS 的这篇文章。

云服务的对象存储一般都可以选择地区。通常选择地理位置最近的地区以获得最低的延迟。这些服务通常是按照使用量计费的，主要包括在一定时间内占用的存储空间以及传输数据所用的流量费用。比如你要备份 1GB 的数据，那么每月可能只需要几块钱或几毛钱，甚至是免费的。（不同服务商收费不一）

很多服务器上的软件已经集成了使用对象存储进行备份的功能：在服务提供商开通了对象存储后，只需要在软件中配置好授权密钥，就可以使用对象存储进行备份了。如果软件没有集成这种备份功能，那么也可以手动实现简单的备份。比如，使用 mysqldump 导出数据库文件，使用 gzip 、 tar 命令压缩、打包要备份的文件。通常对象存储的提供商也有提供命令行工具，使用这些工具可以简单的将文件上传到对象存储中。如 AWS 有 aws，支持 S3 操作；Google Cloud Storage 有 gsutil；阿里云 OSS 有 ossutil；腾讯云有 tccli，支持 COS 操作。

使用快照对服务器进行全磁盘备份

通常快照可以备份服务器磁盘上的所有数据。从快照中恢复也十分方便。这甚至都不需要服务器上的软件支持备份功能。不管是服务器磁盘损坏、系统文件丢失，还是文件删除，都可以从快照中恢复。

如果条件允许，建议同时使用对象存储备份和快照备份。

本地备份

尽管云端备份简单、持久性高，但备份大容量的数据的速度与带宽成正比。何况备份所需要的是上行带宽，这通常是运营商所标称的下行带宽的几分之一。而仅仅是使用普通的机械硬盘进行备份，其速度就已经达到了千兆网络的速度，而千兆网络普及率低且价格极其昂贵。所以，遇到数据量大、带宽受限、备份/恢复时间有限等一种或几种情况时，本地备份也许更为合适。

在本地备份则需要自己做好 321 原则。你需要将数据备份到两个硬盘上（通过局域网或有线连接），并将其中一个硬盘存放在异地。很多桌面操作系统都支持了备份，你可以在最新的 Windows 系统的控制面板中找到备份功能，在 macOS 上使用时间机器（Time Machine）进行备份。建议配置好自动备份。

如果条件允许，建议在本地备份的同时，将较重要的文件再备份到云端。

历史版本的保留

我们应该保留文件的早期版本，以便不时之需。保留多个历史版本的文件使用增量备份有助于节省存储空间。如果条件允许，应保留尽可能多的历史版本。

早期的版本可以有相对更长的时间间隔，以便节省空间：像 macOS 中的时间机器（Time Machine），它会保留过去 24 小时的每小时备份、过去一个月内的每日备份、以及过去一个月以上的尽可能多的每周备份，直到磁盘空间填满。

一些网络存储会自动保留历史版本，比如 Dropbox、Google 云端磁盘、iCloud 等。一些软件也会在本地磁盘里保留历史版本。比如 Git 就会保留每一次提交的历史。

建议首先对重要文件保留历史版本，如果可能对所有文件保留历史版本。

其他

对象存储的存储类别（Storage Class）

通常对象存储提供多种存储类别，不同存储类别有不同的定价和使用场景，合理的使用多种存储类别可以节省支出。

Amazon S3 的主要存储类型

按存储价格由高到低排序，持久性均为 99.999999999%，均为多个可用区。

• STANDARD：默认，适合频繁访问的文件
• STANDARD_IA：存储单价更低（默认的 54%），但有额外的检索费用。此外，此类型至少存储 30 天，至少 128kb。
• GLACIER：存储单价最低（默认的 17%），不可实时访问，也有额外的检索费用

大于 128kb 的且不经常访问的备份建议存储到 STANDARD_IA，几乎不会再访问的早期的历史版本可以存储到 GLACIER。

Google Cloud Storage 的主要存储类型

按存储价格由高到低排序，持久性均为 99.999999999%，均为多个可用区。

• Multi-Regional：多地区存储（比多可用区更强），此存储类型会在一个洲内的多个城市/国家存放文件。按照官网说法上传后的文件会在至少间隔 160 公里的至少两个数据中心存储。适合存放在全球频繁访问的文件
• Regional：对应 S3 的 STANDARD
• Nearline：对应 S3 的 STANDARD_IA，是 Regional 价格的 50%，没有最低文件大小限制
• Coldline：对应 S3 的 GLACIER，且至少存储 90 天，但支持实时访问，是 Regional 价格的 35%，检索费用比 Nearline 更高。

同样的，不经常访问的备份建议存储到 Nearline，几乎不会再访问的早期的历史版本可以存储到 Coldline。

阿里云 OSS 的主要存储类型

按存储价格由高到低排序，持久性均为 99.999999999%，均为多个可用区。

• 标准型：对应 S3 的 STANDARD
• 低频访问型：对应 S3 的 STANDARD_IA，是标准型价格的 67%，至少存储 30 天，至少 64kb。
• 归档型：对应 S3 的 GLACIER，是标准型价格的 28%，至少 64kb。至少存储 60 天，检索费用比低频访问型更高。

同样的，不经常访问的备份建议存储到低频访问型，几乎不会再访问的早期的历史版本可以存储到归档型。

续之前的域名解析系统详解——基础篇，DNSSEC 是一组使域名解析系统（DNS）更加安全的解决方案。1993 年，IETF 展开了一个关于如何使 DNS 更加可信的公开讨论，最终决定了一个 DNS 的扩展——DNSSEC，并于 2005 年正式发布。然而，实际推行 DNSSEC 是一件非常难的事情，本文将讨论一下现有 DNS 系统所存在的一些不安全性，以及 DNSSEC 是如何解决这些问题的。

基础

传统 DNS 的问题

从上一篇文章中已经知道，在你访问一个网站，比如 www.example.com 时，浏览器发送一个 DNS 消息到一个 DNS 缓存服务器上去查询，由于 DNS 系统的庞大，这中间还需要经过好几层 DNS 缓存服务器。想要正确访问到这个网站，就需要这所有的缓存服务器都要正确的响应。

DNS 的中间人攻击

DNS 查询是明文传输的，也就是说中间人可以在传输的过程中对其更改，甚至是去自动判断不同的域名然后去做特殊处理。即使是使用其他的 DNS 缓存服务器，如 Google 的 8.8.8.8，中间人也可以直接截获 IP 包去伪造响应内容。由于我所在的国家就面临着这个问题，所以我可以轻松的给大家演示一下被中间人攻击之后是什么个情况：

$ dig +short @4.0.0.0 facebook.com243.185.187.39

向一个没有指向任何服务器的 IP 地址：4.0.0.0 发送一个 DNS 请求，应该得不到任何响应。可是实际上在我所处的国家却返回了一个结果，很明显数据包在传输过程中“被做了手脚”。所以如果没有中间人攻击，效果是这样的：

$ dig +short @4.0.0.0 facebook.com;; connection timed out; no servers could be reached

DNS 系统就是这么脆弱，和其他任何互联网服务一样，网络服务提供商、路由器管理员等均可以充当“中间人”的角色，来对客户端与服务器之间传送的数据包进行收集，甚至替换修改，从而导致客户端得到了不正确的信息。然而，通过一定的加密手段，可以防止中间人看到在互联网上传输的数据内容，或者可以知道原始的数据数据是否被中间人修改。

从密码学开始

讲到 DNSSEC，就不得不讲到一些密码学的知识。这里从最基本的密码学开始讲起。 密码学主要分为三大类，这里也列出每一列常用的加密算法：

• 对称密码学：AES、DES
• 公钥密码学：RSA、ECC
• 数据完整性的算法：SHA、MD5

在 DNSSEC 中，主要使用到的是公钥密码学和数据完整性算法两种加密学。

公钥密码学实现数字签名

公钥密码主要是与对称密码进行区分：对称密码的加密与解密使用相同的密钥；而公钥密码使用的加密密钥叫做公钥，解密密钥叫做私钥——两种密钥相对独立，不能替代对方的位置，而且知道公钥无法推出私钥。这两种密码学都必须是可逆的（所以解密算法可以看作加密算法的逆）。以函数的形式表达的话如下：

对称密码

• 密文 = 加密算法(密钥, 原文)

• 原文 = 解密算法(密钥, 密文)

公钥密码

• 密文 = 加密算法(公钥, 原文)

• 原文 = 解密算法(私钥, 密文)

当然，如果私钥充当公钥，公钥充当私钥，那么就是这样的：

• 密文 = 加密算法(私钥, 原文)

• 原文 = 解密算法(公钥, 密文)

假如服务器要向客户端发送一段消息，服务器有私钥，客户端有公钥。服务器使用私钥对文本进行加密，然后传送给客户端，客户端使用公钥对其解密。由于只有服务器有私钥，所以只有服务器可以加密文本，因此加密后的文本可以认证是谁发的，并且能保证数据完整性，这样加密就相当于给记录增加了**数字签名**。但是需要注意的是，由于公钥是公开的，所以数据只是不能被篡改，但可以被监听。 此处的服务器如果是充当 DNS 服务器，那么就能给 DNS 服务带来这个特性，然而一个问题就出现了，如何传输公钥？如果公钥是使用明文传输，那么攻击者可以直接将公钥换成自己的，然后对数据篡改。

所以，一个解决的方法是使用一个被公认的公钥服务器，客户端的操作系统中在本地先存好这个公钥服务器自身的公钥。当与服务器通信时，客户端从这个被公认的公钥服务器通信，用户使用操作系统中内置的公钥来解密获得服务器的公钥，然后再与服务器通信。

然而 DNS 是一个庞大的系统，在这个系统中根域名服务器充当了被公认的公钥服务器，其中每一个一级域名服务器也是一个子公钥服务器。最后一张图，就是 DNSSEC 的基本雏形了。

数据完整性算法，减轻公钥密码的运算压力

在密码学中，还存在一种检查数据完整性的算法，其 “加密” 无须密钥，密文不可逆（或很难求逆），而且密文与原文不是一一对应的关系。而且，通过此算法算出的密文通常是一个固定长度的内容。通过此算法算出的密文叫做哈希值。在 DNSSEC 里所运用到它的特性是：原文一旦修改，密文就会发生变化。 公钥密码学存在的一个很重要的问题：加密和解密的速度相对于对称密码太慢了。所以想要提高性能，就需要减短需要加密和解密的文本。如果只是对文本的哈希值加密，由于长度的减短，加密速度就能大大提高。在服务器传送时，同时传送明文的文本和使用私钥加密的文本哈希值；客户端只需要先算出收到的明文文本的哈希值，然后再用公钥解密密文，验证两个值是否相等，依然能够防止篡改。 在 DNSSEC 中就运用了这种方法，无论是对密钥还是记录的加密。

DNSSEC

DNSSEC 这一个扩展可以为 DNS 记录添加验证信息，于是缓存服务器和客户端上的软件能够验证所获得的数据，可以得到 DNS 结果是真是假的结论。上一篇文章讲到过 DNS 解析是从根域名服务器开始，再一级一级向下解析，这与 DNSSEC 的信任链完全相同。所以部署 DNSSEC 也必须从根域名服务器开始。本文也就从根域名服务器讲起。

与 HTTPS 的区别

DNSSEC 和 HTTPS 是两个完全不同的东西，但是这里只是对其加密方式对比。即 DNSSEC 的加密方式与 TLS 进行对比。

信任链机制的不同

在配置 DNSSEC 的时候，如果与 HTTPS 比较，可以看出来：证书和私钥全部都是在自己的服务器上直接生成的，也就意味着这是 “自签名的”，不需要任何 “根证书颁发商”。二级域名所有者向一级域名注册商提交自己的公钥的哈希值，然后一级域名注册商就会给你的哈希值进行签名，从而也能形成一道信任链，远比 HTTPS 的信任链简单，操作系统也再不用内置那么多个 CA 证书，只需要一个根域名的 DS 记录即可。个人认为这是一个更先进的模式，但是它需要客户端一级一级的去依次解析，于是受到了速度的影响；HTTPS 则是直接由一个服务器返回整条证书链，与服务器进行 HTTPS 的连接时只需要与一个服务器通信。不过，DNS 记录是可以被缓存的，所以能够一定程度上的减少 DNSSEC 的延迟。

只签名，不加密

你发往 DNS 服务器的请求是明文的，DNS 服务器返回的请求是带签名的明文。这样 DNSSEC 只是保证了 DNS 不可被篡改，但是可以被监听，所以 DNS 不适合传输敏感信息，然而实际上的 DNS 记录几乎都不是敏感信息。HTTPS 的话会同时签名和双向加密，这样就能够传输敏感信息。 DNSSEC 的只签名，不加密主要是因为 DNSSEC 是 DNS 的一个子集，使用的是同一个端口，所以是为了兼容 DNS 而作出的东西，而 DNS 是不需要客户端与服务器建立连接的，只是客户端向服务器发一个请求，服务器再向客户端返回结果这么简单，所以 DNS 都可以使用 UDP 来传输，不需要 TCP 的握手，速度非常快。HTTPS 不是 HTTP 的子集，所以它使用的是另一个端口，为了做到加密，需要先与浏览器协商密钥，这之间进行了好几次的握手，延迟也上去了。

在哪里验证？

刚才所讲述的所有情况，都是在没有 DNS 缓存服务器的情况下。如果有 DNS 缓存服务器呢？ 实际上，一些 DNS 缓存服务器就已经完成了 DNSSEC 验证，即使客户端不支持。在缓存服务器上验证失败，就直接不返回解析结果。在缓存服务器进行 DNSSEC 验证，几乎不会增加多少延迟。 但这也存在问题，如果缓存服务器到客户端之间的线路不安全呢？所以最安全的方法是在客户端上也进行一次验证，但这就会增加延迟了。

DNSSEC 的时效性和缓存

DNSSEC 相比 HTTPS 的一个特性就是 DNSSEC 是可以被缓存的，而且即使是缓存了也能验证信息的真实性，任何中间人也无法篡改。然而，既然能够缓存，就应该规定一个缓存的时长，并且这个时长也是无法篡改的。 签名是有时效性的，这样客户端才能够知道自己获得到的是最新的记录，而不是以前的记录。假如没有时效性，你的域名解析到的 IP 从 A 换到了 B，在更换之前任何人都可以轻易拿到 A 的签名。攻击者可以将 A 的签名保存下来，当你更换了 IP 后，攻击者可以继续篡改响应的 IP 为 A，并继续使用原本 A 的签名，客户端也不会察觉，这并不是所期望的。 然而在实际的 RRSIG 签名中，会包含一个时间戳（并非 UNIX 时间戳，而是一个便于阅读的时间戳），比如 20170215044626，就代表着 UTC 2017-02-15 04:46:26，这个时间戳是指这个记录的失效时间，这意味着在这个时间之后，这个签名就是无效的了。时间戳会被加进加密内容中去参与签名的计算，这样攻击者就无法更改这个时间戳。由于时间戳的存在，就限制了一个 DNS 响应可以被缓存的时长（时长就是失效时间戳减去当前时间戳）。然而，在有 DNSSEC 之前，控制缓存时长是由 TTL 决定的，所以为了确保兼容性，这两个时长应该是完全一样的。 通过这样做，即能够兼容现有的 DNS 协议，有能够保证安全，还能够利用缓存资源加快客户端的请求速度，是一个比较完美的解决方案。

DNSSEC 的实际部署

其实，即使完全不了解，或者没看懂上面的内容，也不影响你去部署 DNSSEC，只不过你应当非常仔细的对待它，稍有不慎可能导致用户无法解析的情况。

使用第三方 DNS（Managed DNS）部署 DNSSEC

由于是使用第三方的 DNS，部署 DNSSEC 就必须需要第三方支持。常见的支持 DNSSEC 的第三方 DNS 有 Cloudflare、Rage4、Google Cloud DNS（需要申请）、DynDNS 等。开启 DNSSEC 前首先需要在第三方服务上激活 DNSSEC，这样第三方 DNS 才会返回关于 DNSSEC 的记录。 在第三方的 DNS 上激活了 DNSSEC 之后，第三方会给你一个 DS 记录，大概长这样：

tlo.xyz. 3600 IN DS 2371 13 2 913f95fd6716594b19e68352d6a76002fdfa595bb6df5caae7e671ee028ef346

此时，你就需要前往域名注册商，给你的域名提供这个 DS 记录（有些域名注册商可能不支持添加 DS 记录，此时你可以考虑转移到本站的域名注册商或者其他支持 DS 记录的注册商。此外，一些域名后缀也不支持添加 DS 记录，建议你使用主流后缀，如 .com 等，此处就以本站的域名注册商为例）：

添加然后保存，一切就 OK 了。注意关键标签（Key Tag）就是 DS 记录里的第一项（此处对应的是 2371），算法（Algorithm）就是第二项（此处对应的是 13），算法类型（Digest Type）就是第三项（此处对应的是 2），整理分类（Digest）就是最后一项。剩下的内容不需要填写。 有的第三方 DNS（比如 Rage4）会给你一下子提供多个 DS 记录（相同的关键标签但是不同的算法和算法类型），然而你不需要都填写上。我建议只填写使用算法 13 与类型 2 或者算法 8 类型与类型 2 的 DS。这两个分别是 Cloudflare 推荐的参数和根域名目前所使用的参数。填写多个 DS 记录不会给你带来多少的安全性提升，但可能会增大客户端的计算量。

使用自建 DNS 部署 DNSSEC

使用自建 DNS 首先需要先生成一对密钥对，然后将其添加到 DNS 服务中去。我已经介绍了关于 PowerDNS 的添加 DNSSEC 的方法。 在此之后，你需要生成 DS 记录，通常你生成 DS 记录也是很多个，和第三方 DNS 一样，我建议只向域名注册商提交使用算法 13 与类型 2 或者算法 8 类型与类型 2 的 DS。

参考资料

• Economical With The Truth: Making DNSSEC Answers Cheap
• RFC 5155 - DNS Security (DNSSEC) Hashed Authenticated Denial of Existence

安全性相关记录

在 DNS 中，有一些是安全性相关的记录，比如 DS、TLSA、CAA、SSHFP、IPSEC、以及一些通过 TXT 记录来实现的记录等。安全性相关的记录类型十分建议包含签名，也就是说安全性相关的记录应该使用 DNSSEC。此外，当一个域名下不包含这种记录类型时，也必须返回 NSEC 记录并签名。之前一篇文章中所介绍的 DS 就是一个例子。除了 DS 外，还有这些记录类型：

TLSA - DANE 相关

DANE 可以用于绑定某个域名下的某个服务的证书，也就是说可以让一些原本被客户端信任的证书不被信任，证书颁发商未经网站管理人授权签发的证书可以不被信任，可以实现和 Certificate Transparency 类似的效果。这容易与 HPKP Pin 混淆。HPKP Pin 后者只能使用于 HTTPS 服务，且只有成功且没有劫持的访问过才有效果（所以为了使 HPKP Pin 达到真正安全，必须需要建立一个受信任的中央服务器去 Preload 这些记录，类似 HSTS）；DANE 即使是在第一次访问也无法被劫持，而且可以用于 Mail 等域名相关的 SSL 服务，不只限于 HTTPS。 我认为 DANE 的真正有意思的地方是在于它可以让客户端去有选择的信任自签名的证书，也就是说可以让一些原本不被客户端信任的证书被信任：通过 DNS 的方式向浏览器告知这个网站自签名证书的公钥，由于包含了签名，浏览器就能够知道这是域名所有者的公钥，就能够在这个域名下信任这个自签名的证书。这打破了目前常用的 CA 机制，网站管理者也再也不用去向 CA 花钱或者是不花钱的申请证书，而是直接使用自签名证书甚至是自己管理的 CA 签发的证书，操作系统也不再需要选择去信任哪些根证书，也能避免传统证书签发商系统存在结构性缺陷（比如证书签发商通过自己签发证书来进行 HTTPS 中间人等）。然而实现这一步首先需要客户端的支持，已经开始有程序开始支持，然而却还没有看到浏览器去支持的迹象。 使用了自签名证书的 HTTPS 且配合了 DANE 的站点与常规 HTTPS 站点的信任链对比：

• DANE 自签名 （dane-self-ca.tloxygen.com）：内置的 DS 记录 -> 根域名（.）-> 一级域名（.com）-> 二级域名（tloxygen.com）-> 自签名证书（dane-self-ca.tloxygen.com）
• 证书颁发商签名（dane-trusted-ca.tloxygen.com）：内置的根证书（DST Root CA X3）-> 中间证书（Let’s Encrypt Authority X3）-> 域名证书（dane-trusted-ca.tloxygen.com）

注：域名 tloxygen.com 只是在本地环境中进行的测试，公网无法访问

实现 DANE 的方式主要是通过 TLSA 记录： TLSA 记录包含了证书的哈希值，或者是某一个中间证书的哈希值（或者也可以是完整的证书）。同时，它可以针对不同的协议和端口配置不同的 TLSA 记录。我认为，TLSA 是最安全的一种 DANE 的方式。 你可以在这个网站生成一个 TLSA 记录，我的 dane-trusted-ca.tloxygen.com 站点绑定了 Let’s Encrypt 的中间证书，设置的 TLSA 记录是这样的：

_443._tcp.dane-trusted-ca.tloxygen.com. 604800 IN TLSA 0 0 1 25847D668EB4F04FDD40B12B6B0740C567DA7D024308EB6C2C96FE41D9DE218D

这里记录中的第一项（这里是 0）代表着 PKIX-TA，TA 意味着这个根证书或是中间证书必须在这个域名所使用的证书链中，也就是说这个域名只能使用某一个证书颁发商颁发的证书。如果第一项填写 1，代表着 PKIX-EE，EE 意味着这个证书必须是域名所使用的证书，也就是说每次更换证书后都得修改这个记录。PKIX 意味着这个证书链是受操作系统信任的，在使用证书颁发商颁发的证书时（如 Let’s Encrypt），应该使用 PKIX。 当第一项为 2 和 3 时，一切就变的有意思多了，2 代表着 DANE-TA，代表着绑定一个自签名的根证书，我的 dane-self-ca.tloxygen.com 站点就绑定了一个自签名的 Root，设置的 TLSA 是这样的：

_443._tcp.dane-trusted-ca.tloxygen.com. 604800 IN TLSA 0 0 1 25847D668EB4F04FDD40B12B6B0740C567DA7D024308EB6C2C96FE41D9DE218D

所以如果客户端支持了 DANE，那么这个自签名的根证书在这个域名下就是被信任的。 当第一项为 3 时，代表着 DANE-EE，这可以直接绑定域名证书，意味着不但可以使用自签名的证书，连证书链都免去了，我的 dane-self-signed.tloxygen.com 就直接使用了一个自签名的证书，设置的 TLSA 是这样的：

_443._tcp.dane-self-signed.tloxygen.com. 604800 IN TLSA 3 0 1 BF617DDCC4F39BD0C9228FC0C1EAD5E96252F36FB3FB5AB0CBB9B9B09C3CFE21

你可以在这个网站找到更多的不同种类的支持 TLSA 的网站。 那么问题就来了，为什么现有的浏览器都不支持 TLSA 呢？我认为主要原因如下：

1. 会给浏览器带来一个额外的 DNS 查询时间，为了最高的安全性，浏览器应该在开始加载 HTTPS 页面（建立握手后）之前就先查询 TLSA 记录，这样才能够匹配证书是否该被信任，这样无疑增加了所有 HTTPS 页面的加载时长。
2. 现有的 DNS 是一个不是足够稳定的东西，何况 DNSSEC 的记录类型不被一些 DNS 递归服务器所支持等，经常会由于因为种种原因遇到查询失败的问题，按照规则，TLSA 记录查询失败的话客户端也应该不加载页面。这样无疑增加了 HTTPS 页面加载的出错率，这样无疑会导致很多原本没有被中间人的网站也无法加载。
3. DNS 污染，在一些情况下，客户端所处的是被 DNS 污染的环境，特点就是将服务器解析到了错误的 IP 地址。然而此时中间人为了仍能够让用户访问到 HTTPS 网站，会进行类似 SNI Proxy 的操作，此时的客户端访问网站仍是比较安全的。然而显然，DANE 在 DNS 被污染后，会直接拒绝加载页面，这样被 DNS 污染的环境会有大量站点无法加载。
4. DNSSEC 本身的安全性，现在仍有一些 DNSSEC 的 ZSK 或者是 KSK 在使用 1024-bit 的 RSA，在证书系统中，1024-bit 的 RSA 已经基本不被信任，而 RFC 却建议使用 1024-bit 直到 2022 年。而这不是主要问题，越来越多的域名服务器，尤其是根域名和一级域名，都已经使用了 2048-bit 的 RSA 甚至是 256 位的 ECDSA，客户端可以直接拒绝接受 1024-bit RSA。

然而我认为这些都不是什么问题。为了解决 DNS 的问题，可以使用 Google DNS-over-HTTPS，这样的话就能避免很多 DNS 污染的问题，而且由于 DNSSEC 本身包含签名，Google 是无法对返回内容篡改的。那么直至现在，TLSA 就只存在最后一个问题：为了获取 TLSA 记录而增加的加载延迟。而这也可以完美解决，OCSP 就是一个例子，现在传统的 CA 为了实现吊销机制，也都有 OCSP：

OCSP（Online Certificate Status Protocol，在线证书状态协议）是用来检验证书合法性的在线查询服务，一般由证书所属 CA 提供。为了真正的安全，客户端会在 TLS 握手阶段进一步协商时，实时查询 OCSP 接口，并在获得结果前阻塞后续流程。OCSP 查询本质是一次完整的 HTTP 请求，导致最终建立 TLS 连接时间变得更长。

• ——JerryQu

这样，在开始正式开始加载页面，客户端也需要进行一次 HTTP 请求去查询 OCSP。OCSP 也会十分影响页面加载速度，也同样会增加加载页面出错的可能。而 OCSP 有了 OCSP Stapling，这样的话 Web 服务器会预先从 CA 获取好 OCSP 的内容，在与 Web 服务器进行 HTTPS 连接时，这个内容直接返回给客户端。由于 OCSP 内容包含了签名，Web 服务器是无法造假的，所以这一整个过程是安全的。同理，TLSA 记录也可以被预存储在 Web 服务器中，在 TLS 握手阶段直接发送给客户端。这就是 DNSSEC/DANE Chain Stapling，这个想法已经被很多人提出，然而直至现在还未被列入规范。也许浏览器未来会支持 TLSA，但至少还需要很长一段时间。

传统 CA 机制所特有的优势

传统的证书配合了现在的 Certificate Transparency，即使不需要 TLSA 记录，也能一定程度上保证了证书签发的可靠性。此外，传统证书也可以使用 TLSA，其本身的安全性不比 DANE 自签名差。 此外，传统 CA 签发的证书还有自签名证书做不到的地方：

• OV 以及 EV 证书：DANE 自签名的证书其实就相当于 CA 签发的 DV 证书，只要是域名所有者，就能够拥有这种证书。然而很多 CA 同时还签发 OV 和 EV 证书，OV 证书可以在证书内看到证书颁发给的组织名称，EV 则是更突出的显示在浏览器上：在 Chrome 的地址栏左侧和 HTTPS 绿锁的右侧显示组织名称；Safari 则甚至直接不显示域名而直接显示组织名称。OV 和 EV 的特点就是，你甚至都不用去思考这个域名到底是不是某个组织的，而直接看证书就能保证域名的所有者。而 DV 证书可能需要通过可靠的途径验证一下这个域名到底是不是某个组织的。比如在你找一家企业官网的时候，有可能会碰到冒牌域名的网站，而你不能通过网站是否使用了 HTTPS 而判断网站是否是冒牌的——因为冒牌的网站也可以拿到 DV 证书。而当你发现这个企业使用了 OV 或 EV 证书后，你就不用再去考虑域名是否正确，因为冒牌的网站拿不到 OV 或 EV 证书。在申请 OV 或 EV 证书时，需要向 CA 提交来自组织的申请来验证组织名称，而由于 DANE 证书是自签发的，自然也不能有 OV 或 EV 的效果。
• IP 证书：CA 可以给 IP 颁发证书（尽管这很罕见），这样就可以直接访问 HTTPS 的 IP。而 DANE 基于域名系统，所以不能实现这一点

CAA - 证书颁发相关

CAA 比较简单，它相当于是公开声明这个域名允许了哪些证书颁发商颁发的证书。CAA 不需要 DNSSEC，写在这里只是和 TLSA 区分一下，但开启 DNSSEC 无疑能够使 CAA 更可信。 比如在域名添加了如下记录，就相当于限制了仅允许 Let’s Encrypt 签发证书，其他证书签发商则不再给这个域名签发证书。在 CAA 记录刚推出时受到以下因素限制：

• 只有在使用支持 CAA 的证书颁发商，添加 CAA 才有意义
• 证书颁发商并没有必要 CAA，也就是说即是添加了 CAA 记录后仍可能可以被其他你没有允许的证书颁发商颁发。所以这是需要其他证书颁发商自觉地不再给这个域名办法证书。

但是从 2017 年底开始，所有证书颁发商被强制要求遵守域名的 CAA 记录。来源 CAA 的副作用最小，你也可以添加多个 CAA 记录来允许多个证书颁发商去签发，以增加灵活性。 google.com 就使用了 CAA（但是没有开启 DNSSEC）：

$ dig google.com caa;; ANSWER SECTION:google.com.86399INCAA0 issue "symantec.com"

如果要将一个域名绑定在某个证书颁发商下，建议同时使用 TLSA 和 CAA。如果是长期的绑定，可以考虑一下 HPKP Pin。

SSHFP - 认证主机相关

在使用 SSH 首次连接一个主机时，SSH 通常会询问是否信任服务器的指纹（fingerprint）：

$ ssh guozeyu.comThe authenticity of host 'guozeyu.com (104.199.138.99)' can't be established.ECDSA key fingerprint is SHA256:TDDVGvTLUIYr6NTZQbXITcr7mjI5eGCpqWFpXjJLUkA.Are you sure you want to continue connecting (yes/no)?

这个指纹告诉你了你连接到的是这个服务器，而不是别的服务器。你需要确认这个指纹与自己所要连接到的服务器匹配时，才应该进行连接，不然你就会连接到别的服务器（攻击者可以让服务器允许任何来源的 SSH，于是你就成功登陆到了攻击者的服务器。这样你所执行的代码，甚至是通过 SSH 提交的 Git，都能被获取到）。 那些允许公开的 SSH 连接的服务器，如 GitHub，会在网站上公开自己的指纹，用户需到在它们的官方文档中找到指纹。而 SSHFP 则是一种更简单且通用的的公开这个指纹的方式，这个功能甚至都集成到了 SSH 中去，当检测到指纹匹配时就会自动登陆，跳过询问指纹的步骤。 然而，假如攻击者同时控制了网络中的 DNS 和 SSH，那么 SSHFP 反而是更加不安全的。所以客户端仅应该信任使用了 DNSSEC 的 SSHFP 记录。 编辑 ~/.ssh/config ，添加这一行即可实现验证 SSHFP 记录：

VerifyHostKeyDNS=ask

如果将 ask 换为 yes，那么会默认信任 SSHFP 记录。

参考资料

• RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
• RFC 6844 - DNS Certification Authority Authorization (CAA) Resource Record

具体实现

前面我们介绍了 DNSSEC 的基本原理，这一篇文章中将会介绍给你 DNSSEC 的具体实现方法，我来使用 dig 程序为大家分析 DNSSEC 的实现过程

根域名

我有一个域名 tlo.xyz 长期部署了 DNSSEC，所以本文就拿这个域名作为例子讲解。首先，需要明确的是如何让 dig 程序去显示关于 DNSSEC 的资源类型，幸运的是这很简单，只需要加上 +dnssec 参数即可。 在之前的文章中，我们已经知道了根域名公开了 13 个服务器的 IP 地址。此外，其实根域名还公开了一组 DS 记录，这段记录可以在这里获得。

.172800INDS19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5.172800INDS20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

• DS 记录：DNSSEC Delegation Signer，用于鉴定 DNSSEC 已授权_区域的签名密钥（Zone-signing-key）_，相当于公钥的哈希值。

第二条记录是 2016 年 10 月份生成，并在 2018 年 10 月完成切换。 现在我们利用这个地址查询根域名自身，结果如下（部分无关内容已经被删掉）：

$ dig @a.root-servers.net. . any +dnssec;; ANSWER SECTION:.518400INNSa.root-servers.net.;; 这里省略剩下 12 个根域名服务器.518400INRRSIGNS 8 0 518400 20170227170000 20170214160000 61045 . HnSVXyC8UZuXnpOsZOv1/GP2byJFG9Y9ch4q0eUw/6CMEJ403spJ67Oo JiAGhdiE6xlONAMQN0Q7LpA7/bgCf29mmVJDcG76b/qaVnmRjKErBwep 68K831Uph2V+Rixcw8mx5XYWuMDyKDiRWlrPyY/bT0a7Us7dTnhkNJ+D g25E0lqXNKY9XgroVoTlwc5tCIe6L8GhoDU+LTLtBySBgQa3kEAI7WUQ CT4l47BCu3zzh8sJtdKGEXnXD0e22pB4ZaYF80iVWL1cRgghn2HphlN0 1kFJr3WuuIKP9r4vZFIjKiinV1KJdBBW2fciGAx+nZbP5sSUlOdiz/56 BZKM3g==.86400INNSECaaa. NS SOA RRSIG NSEC DNSKEY.86400INRRSIGNSEC 8 0 86400 20170227170000 20170214160000 61045 . JQQEDSGFolKu38MmdvvDj7Zi2AstqZc2cwhPQE+RRwTBVl3SWQOQ4FaS Wta+CdbhbaRAKQ9dUiOif95LLarewJDF9e4O2zTDsLt5MlgXLGZr3xd4 9HhDkEzjRk4Zro2qquvWmsHUjn+fbru4FsO6sZyS/FWjfh0XImlIYfh4 D50IplgRwv6awu4mO2RzJ0VL94l4WMMnV42vPSfWiNpL+9g7PHmaWkwe EqH7RamPDzw/M3bmts5yWp+cEI4IzE25kmZAHwN9EQHNNtDL3qKtAzrY wj6e8VVw0rI/XJ3DMI5aRk3xB+ac13dQv8cWtQZRImw76A5/N6clBXJS ZpmT+w==.172800INDNSKEY256 3 8 AwEAAYvgWbYkpeGgdPKaKTJU3Us4YSTRgy7+dzvfArIhi2tKoZ/WR1Df w883SOU6Uw7tpVRkLarN0oIMK/xbOBD1DcXnyfElBwKsz4sVVWmfyr/x +igD/UjrcJ5zEBUrUmVtHyjar7ccaVc1/3ntkhZjI1hcungAlOhPhHlk MeX+5Azx6GdX//An5OgrdyH3o/JmOPMDX1mt806JI/hf0EwAp1pBwo5e 8SrSuR1tD3sgNjr6IzCdrKSgqi92z49zcdis3EaY199WFW60DCS7ydu+ +T5Xa+GyOw1quagwf/JUC/mEpeBQYWrnpkBbpDB3sy4+P2i8iCvavehb RyVm9U0MlIc=.172800INDNSKEY257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=.172800INRRSIGDNSKEY 8 0 172800 20170303000000 20170210000000 19036 . KHz7GVvg5DxUv70bUhSjRy1JO5soL+h6M08g8bSKecd+4NmZI87Sn20p uZNRuiASbnG63i89Z2S45NBAR8KtqB6N5CrRhLhfxZcRo5k3Ts6zsC1E J58upPKzFtu/sJBsPDjcRJJKbXlB4hLukQwVhn/MbsXxZdZGI57WoLFx bbR49NlFJrlrbTi2gieRR1SCLfT9aiBGsJA3T4jXap9FIsikNf1DJA8H cnQTW7hFi8l/O2ni2hbjsIE4S3GRTMypqDR/s7piy/qukfWwSknk6YZT bzld6ZgbZK+oOhRgj/W6XW78bJl0onov0F1wD0NQsec+sk2P+JNMc4xg vQmn9g==.86400INSOAa.root-servers.net. nstld.verisign-grs.com. 2017021401 1800 900 604800 86400.86400INRRSIGSOA 8 0 86400 20170227170000 20170214160000 61045 . A5CqIucYyfFTzp03EuajDjp5Vw6dd3Oxip60AI7MCs/2xfBu1red4ZvF GfIEGHstG61iAxf7S3WlycHX9xKyfIOUPmMxuvkI9/NXMUHuvjUjv9KW TTkc1HV6PuUB1sv9gsuQ6GFnHCXAgMKXZs9YofRDlBi2jxAvJVc5U7nG sd8UqQs4WcinMHNvFV9+gwfax0Cr9KFDmDUbS+S2wYmNs+SGOn+CbFrD 8gs34GiYao8i0QGw7RVGTVJiuVOuUkeYe4iSXnJjNjeIlm8liq6PRXgM nI+ndPDogA/a8JATfyzQ97VDRwe/FucoTbe5qd2cHxqh1ZxxPkA3K3Fj 8Jv3kg==;; ADDITIONAL SECTION:a.root-servers.net.518400INA198.41.0.4a.root-servers.net.518400INAAAA2001:503:ba3e::2:30;; 这里省略剩下 12 个根域名服务器

可以看到，此时没有再返回 DS 记录，因为 DS 记录总是由一个区域的上一级区域的权威服务器返回，之后还会再次提到这个问题。此处的 DNSKEY、RRSIG、NSEC 是三个关于 DNSSEC 的记录类型：

• DNSKEY 记录：用于 DNSSEC 的记录，内容是一个公钥。
• NSEC 和 NSEC3 记录：用于说明该域名下有哪些记录，从而可以用排除法证明该域名下没有哪些记录。
• RRSIG 记录：记录集的数字签名，相当于是使用私钥加密后的内容。用于给除去自身外所有的记录集签名。下文有些地方直接将此记录叫做了签名。

可以看到，上方查询的 DNSKEY 记录有两条，这两条的内容的第一项分别是 256 和 257。256 是 ZSK（zone-signing keys），257 是 KSK（key-signing keys）。其中 KSK 是专门用于签名 DNSKEY 记录集（就是 ZSK 与 KSK），而 ZSK 是用于签名该区域下的其他记录集。 仔细观察，就可以看出，每一种记录后面就对应着一个用于签名该种类记录的 RRSIG 记录，比如上面查询结果中的 NS、NSEC、DNSKEY、SOA 记录的后面都跟着一个 RRSIG 记录。 举个例子，客户端解析并验证根域名的 SOA 记录的方法大概如下：

1. 解析A：使用根域名服务器解析根域名自身下的 DNSKEY 和 SOA 记录，并要求返回签名
2. 验证1：使用已知的 DS 记录验证 DNSKEY 中的 KSK
3. 验证2：使用 KSK 及其签名验证 DNSKEY 记录集
4. 验证3：使用 ZSK 和 SOA 的签名验证 SOA 记录

但是值得注意的是，根域名服务器所返回的 Glue 记录却没有数字签名，那是因为这是不必要的。就算 Glue 记录被篡改成了别的服务器，那个服务器在解析根域名时也不能篡改任何权威记录（在 ANSWER SECTION 下）。

一级域名和二级域名

然后，我们来使用根域名服务器解析一级域名：

$ dig @a.root-servers.net. xyz. any +dnssec;; AUTHORITY SECTION:xyz.172800INNSx.nic.xyz.;; 这里省略剩下 3 个服务器xyz.86400INDS3599 8 2 B9733869BC84C86BB59D102BA5DA6B27B2088552332A39DCD54BC4E8 D66B0499xyz.86400INDS3599 8 1 3FA3B264F45DB5F38BEDEAF1A88B76AA318C2C7Fxyz.86400INRRSIGDS 8 1 86400 20170227170000 20170214160000 61045 . gXpaapTu67jlkfOeujL455lFDGLmLkFpnI+f8VNLMehozA7qWQD71oso SXJxkOB6o/ldXqoLGIo1khsYS8SMltOCMisJ6eA2cLokB7Ybzsaw8GWZ rkx64u2JbELWMbwGnY3PnZHGlBT77oAt49KNDfpxhgm3k1Yrcrua25D8 PL4fz6IQYQIMXWiHM/V2jH6E2Vu1Ynrjiu0lPEMf0TnGsK/URnCGE9uZ caT41mNz9kri/wkuQR11XtHjsN/qZgmcxZK+Tf4VQfOOdcfey4wAa1CM HRQ3Pm4mLo4LQwiESeMuqFyriizdMG4piNP7NLuI54GqWCGNSyDYbOdL X0n2Aw==;; ADDITIONAL SECTION:x.nic.xyz.172800INA194.169.218.42x.nic.xyz.172800INAAAA2001:67c:13cc::1:42;; 这里省略剩下 3 个服务器

这里返回的 DS 记录，虽然是两个，但是其 Key Tag（即第一项，为 3599）是相同的，后面两项算法有所不同，这其实就是同一个 KSK 的两种不同的哈希值算法，这个是为了提高兼容性和有限的安全性。这与刚才根域名的情况不一样，根域名下面的是完全两个不同的 KSK 的不同的 DS。 此时我们发现了不仅是 Glue 记录，NS 记录下也没有签名，这是因为这里返回的 NS 记录是属于委托记录（在 AUTHORITY SECTION 下），也不需要签名，xyz. 下 NS 记录的签名应该有 xyz. 的解析服务器来完成（而 DS 记录是例外）。我们来使用一级域名服务器来解析其自身：

$ dig @x.nic.xyz. xyz. any +dnssec;; ANSWER SECTION:xyz.172800INNSx.nic.xyz.xyz.172800INNSy.nic.xyz.xyz.172800INNSz.nic.xyz.xyz.172800INNSgenerationxyz.nic.xyz.xyz.172800INRRSIGNS 8 1 172800 20170525152637 20170425162314 47496 xyz. p57paKPWMyhwmz5IkkbZOMC/dIfxyANZ6QzRbEBiOff5JXnrdpKEX4YT zPMzF4SSNHPuK53uuJTtt2E4W3Xd2VjGVUx7V2mP7Hxs0nQblCDbQa51 zr6kYoXEOcdwVx23GyLe0baPELtEkQZHeKx5eWyZTUDCri4DBCZZv9m+ Lbk=xyz.3600INSOAns0.centralnic.net. hostmaster.centralnic.net. 3000288446 900 1800 6048000 3600xyz.3600INRRSIGSOA 8 1 3600 20170606000517 20170506113911 47496 xyz. oanexcZRLZ+NEPvSGhl0qyi6LH/3ubP+0JWjlNvcduZWUp7oQt4VWfy/ w0T2Y2/610u7mvcxRty2p6cZq1arVMLOci7ZzMpPHkNDxXHcNRxlMNL1 6mwLgKzOlxp0acEGhqQBhj/XQ2icScf8PMChC7uRsFOz9nqAxelcgJgY D9I=xyz.3600INDNSKEY257 3 8 AwEAAbYRTzkgLg4oxcFb/+oFQMvluEut45siTtLiNL7t5Fim/ZnYhkxa l6TiCUywnfgiycJyneNmtC/3eoTcz5dlrlRB5dwDehcqiZoFiqjaXGHc ykHGFBDynD0/sRcEAQL+bLMv2qA+o2L7pDPHbCGJVXlUq57oTWfS4esb GDIa+1Bs8gDVMGUZcbRmeeKkc/MH2Oq1ApE5EKjH0ZRvYWS6afsWyvlX D2NXDthS5LltVKqqjhi6dy2O02stOt41z1qwfRlU89b3HXfDghlJ/L33 DE+OcTyK0yRJ+ay4WpBgQJL8GDFKz1hnR2lOjYXLttJD7aHfcYyVO6zY sx2aeHI0OYM=xyz.3600INDNSKEY256 3 8 AwEAAaAxrInKa1BlzuJsfT/gWfrUUH5OP7IJquNOLRU7LVbKwJEv655b kBBbW53wVXmnWJfPxykrMme8a91FFqXTYepvVN5vJe9QuCfiW/C64jSo 0HNXhbSUkV1ZDcy+zgAmMriPm8g5ki7KJ7KRs+YRoL2NwCm5fJVsAchr WalFB4z3xyz.3600INDNSKEY256 3 8 AwEAAdNAEAD8rebFpKuiLr0BwTNQoECMnfJjiZ54ZCCke208h9eX7ui7 WFFz9hjmvAgIFavN5vVhR5SnDTRvD5iDsMKvefXbnz4Qeu4GILwJuTqC QAcqw6RUp1+U1KEkwRP/noqA4fSkmnInbQwW+Yq+bxohGQVatZiAiO/G ppSggZX3xyz.3600INRRSIGDNSKEY 8 1 3600 20170520002252 20170419140553 3599 xyz. h5TV5pu/QAAUal72x8Dm8tgqBzRvDSznaDrRqV0Fu8ponhfXQFjdG3p1 2/IVdkNLtLZq4I2aUMwJeTZcyq5gRcWOror0V6uChW5fgIkH7abj1CYL tSRv3M7mVBduGNIzMuITJu5Pn1BVXiF9FsTw1ks+wDjdPn2OLe5BKRmj d+6GgwwBhg4V2efFcb+peRBCRpk+i3S1dlMyILCCgAvnAaGbh3k+vaKN 2wb528jSvH0QVIXP8PTAxLw86IfFlvLm8Lxo1e8hweI+4hgECNX7UzeG epXE+LpOiZwkhf7JncytOcxw6YzSAQETYJfcK1MlMcH5zNzjhFTNoMV3 M4QTLQ==;; ADDITIONAL SECTION:x.nic.xyz.172800INA194.169.218.42y.nic.xyz.172800INA185.24.64.42z.nic.xyz.172800INA212.18.248.42generationxyz.nic.xyz.172800INA212.18.249.42x.nic.xyz.172800INAAAA2001:67c:13cc::1:42y.nic.xyz.172800INAAAA2a04:2b00:13cc::1:42z.nic.xyz.172800INAAAA2a04:2b00:13ee::42generationxyz.nic.xyz.172800INAAAA2a04:2b00:13ff::42

可以看到， xyz. 下的解析服务器就返回了 NS 记录的签名。 然而，xyz. 下却有两个 ZSK，这大概是因为 xyz. 下有两个私钥，这样的话每一个签名可以使用两个私钥中的任何一个签，灵活性更高。此外，我们也看出来了区分 KSK 和 ZSK 的意义：KSK 和 ZSK 的数量可以不相等。 然后，我们来使用一级域名的服务器来解析我的二级域名：

$ dig @x.nic.xyz. tlo.xyz. any +dnssec;; AUTHORITY SECTION:tlo.xyz.3600INNSkami.ns.cloudflare.com.tlo.xyz.3600INNSgordon.ns.cloudflare.com.tlo.xyz.3600INDS2371 13 2 913F95FD6716594B19E68352D6A76002FDFA595BB6DF5CAAE7E671EE 028EF346tlo.xyz.3600INRRSIGDS 8 2 3600 20170303035908 20170201045318 7558 xyz. b69lhRaZM8lWN44qaQCCm4+479ATwt+OlRWD770jmLJnai2ob/0CWPEZ pFQ+y/k6n/X8VPZa2IVwxB6qUTtirtOolBHVA4gmPQffXiYiTbP1dDT9 G7BwNMdOCGkH0bySW9rFpi3zKYvOieNQLlV/i61ox78AgxQeX4k800QN gEE=

由于 NS 记录属于委托记录，所以 NS 下也没有签名。 由于这个域名使用的 NS 是 kami.ns.cloudflare.com. ，不属于 xyz. 之下，所以没有任何 Glue 记录，于是这需要再按照流程再重头解析一遍 kami.ns.cloudflare.com. ，这里就省略了。 最后，我们来使用我二级域名服务器来解析二级域名自身：

$ dig @kami.ns.cloudflare.com. tlo.xyz. any +dnssec;; ANSWER SECTION:tlo.xyz.60INA52.84.21.12tlo.xyz.60INA52.84.21.243tlo.xyz.60INA52.84.21.67tlo.xyz.60INA52.84.21.107tlo.xyz.60INA52.84.21.4tlo.xyz.60INA52.84.21.46tlo.xyz.60INA52.84.21.29tlo.xyz.60INA52.84.21.224tlo.xyz.60INRRSIGA 13 2 60 20170507145606 20170505125606 35273 tlo.xyz. tcMNEbUGrnCoTK1Z7Xmo15k+pLyZJ+m28nKt/o5s+/ezrcMsgFv1C0bY ABs9M8cqjw+0Ld8DTtAwTQVwpAUe+g==tlo.xyz.60INAAAA2600:9000:203a:1000:b:fe0:fc00:93a1tlo.xyz.60INAAAA2600:9000:203a:7e00:b:fe0:fc00:93a1tlo.xyz.60INAAAA2600:9000:203a:e400:b:fe0:fc00:93a1tlo.xyz.60INAAAA2600:9000:203a:a200:b:fe0:fc00:93a1tlo.xyz.60INAAAA2600:9000:203a:4800:b:fe0:fc00:93a1tlo.xyz.60INAAAA2600:9000:203a:3000:b:fe0:fc00:93a1tlo.xyz.60INAAAA2600:9000:203a:1a00:b:fe0:fc00:93a1tlo.xyz.60INAAAA2600:9000:203a:a000:b:fe0:fc00:93a1tlo.xyz.60INRRSIGAAAA 13 2 60 20170507145630 20170505125630 35273 tlo.xyz. QV5gEUO9NK3W2G4aF/dTZrmsGURyVAiU3eyyuR4lp4YJ7jxGjmCQArPB 4CYz6laN+V6Kd78gi7v50gaf+WCeDQ==tlo.xyz.3600INSOAgordon.ns.cloudflare.com. dns.cloudflare.com. 2024522030 10000 2400 604800 3600tlo.xyz.3600INRRSIGSOA 13 2 3600 20170507145653 20170505125653 35273 tlo.xyz. KnJkiBfvb0xhw3mAjKxnWPSMptc+eoN7Qh50HJQYnmycvV1K9ADFKYyq RwhKzWEOFHXtsn8Pxh+d/EY0x4EVEw==tlo.xyz.86400INNSgordon.ns.cloudflare.com.tlo.xyz.86400INNSkami.ns.cloudflare.com.tlo.xyz.86400INRRSIGNS 13 2 86400 20170507145712 20170505125712 35273 tlo.xyz. vQDzeIteIeVdbPS7nxNXCVeGD97+ePvEHdPK263oocoDPY59tVOG6V+a s7k8GHSFJ8KKu8edoWcUayi3aNFY7g==tlo.xyz.86400INTXT"v=spf1 include:email.freshdesk.com include:\_spf.myorderbox.com include:amazonses.com -all"tlo.xyz.86400INRRSIGTXT 13 2 86400 20170507145729 20170505125729 35273 tlo.xyz. NDFDF9PHFSSvQu7oF17cNWIrQUrfaPA/019i6hCvj7JJiA21DWp0w5J3 BlxDEN6wIGq4Nzb4IVE0uf+zmdTb0w==tlo.xyz.3600INDNSKEY257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+GqJxpVXckHAeF+ KkxLbxILfDLUT0rAK9iUzy1L53eKGQ==tlo.xyz.3600INDNSKEY256 3 13 koPbw9wmYZ7ggcjnQ6ayHyhHaDNMYELKTqT+qRGrZpWSccr/lBcrm10Z 1PuQHB3Azhii+sb0PYFkH1ruxLhe5g==tlo.xyz.3600INRRSIGDNSKEY 13 2 3600 20170529092807 20170330092807 2371 tlo.xyz. SDm3eGWVamR+GIZ8TEcYDeik73gMUVyX6TGGtkir6A6TIY+2zvXwtfrN HEvkygTfiOuEn+/Ipj08o8+NyZeAZw==

下面总结一下解析并验证 tlo.xyz. 下的全部 A 记录的方法，DNS 在实际解析过程中会尝试尽可能跳过不必要的请求：

1. 解析A：使用根域名服务器解析根域名下的 DNSKEY 记录，并要求签名
2. 验证1：使用已知的根域名 DS 记录验证根域名的 KSK
3. 验证2：使用根域名的 KSK 及其签名验证 DNSKEY 记录集
4. 解析B：使用根域名服务器解析 tlo.xyz. ，返回的是 xyz. 下的 NS 和 DS 记录，包含了签名
5. 验证3：使用根域名的 ZSK 和 DS 的签名验证 xyz. 的 DS 记录
6. 解析A：使用 xyz. 服务器解析 xyz. 下的 DNSKEY 记录，并要求签名
7. 验证1：使用 xyz. 的 DS 记录验证 xyz. 的 KSK
8. 验证2：使用 xyz. 的 KSK 及其签名验证 DNSKEY 记录集
9. 解析B：使用 xyz. 服务器解析 tlo.xyz. 下的 NS 和 DS 记录，并要求签名
10. 验证3：使用 xyz. 的 ZSK 和 DS 的签名验证 tlo.xyz. 的 DS 记录
11. 解析A：使用 tlo.xyz. 服务器解析 tlo.xyz. 下的 DNSKEY 和 A 记录，并要求签名
12. 验证1：使用 tlo.xyz. 的 DS 记录验证 tlo.xyz. 的 KSK
13. 验证2：使用 tlo.xyz. 的 ZSK 和 A 的签名验证 tlo.xyz. 的 A 记录

为了做区分，我把解析分为了两类，验证分为了三类：

• 解析A：解析权威记录并要求签名
• 解析B：解析委托记录并要求 DS 记录的签名
• 验证1：根据 DS 验证 KSK
• 验证2：根据 KSK 验证 ZSK
• 验证3：根据 ZSK 验证解析记录

NSEC 记录

NSEC 记录比较特殊，所以单独的讲一下。 在全面普及 DNSSEC 之前，仍然有不少域名并不支持 DNSSEC，此时如何让已经支持 DNSSEC 的网站进行签名认证，拒绝解析签名错误的请求，又同时让没有 DNSSEC 的域名无视签名正常解析呢？HTTPS 的推进是区分了协议：以 https:// 开头的网站进行签名认证，以 http:// 开头的网站不进行签名认证，在 HSTS Preload 里的域名则强制进行签名验证。而实际上，HTTP 和 HTTPS 是两种不同的协议，而支持 DNSSEC 的 DNS 与普通的 DNS 是同一种协议，前者是后者的子集。只有域名下有 DS 记录时，才会进行签名认证，否则还是按照普通的处理。 那么试想，攻击人可以在解析 tlo.xyz. 时的第九步做手脚：删除 DS 记录以及 DS 的签名，这样不就相当于移除了这个域名的 DNSSEC 了吗？（有些类似于 HTTPS 降级攻击），或者直接删除某个域名下的 A 记录，客户端能知道这个域名下是真的没有 A 记录还是被恶意删除了？实际上这样做手脚是没用的，当开启了 DNSSEC 的权威服务器收到了一个不存在的记录的请求时（这可以是不存在的子域名，也可以是某个域名下不存在的一些记录类型），不是返回空的内容，而是返回一个 NSEC 记录去声明这个域名下没有这种记录，同时也将这个记录签名。综上所述，开启了 DNSSEC 后对于该区域下的所有的 DNS 请求都会签名，从来不会返回空的内容。 根据这里公开的数据，我们来尝试一下解析第一个不支持 DNSSEC 的一级域名：ae. 的 DS 记录的结果

$ dig @a.root-servers.net. ae. ds +dnssec;; AUTHORITY SECTION:.86400INSOAa.root-servers.net. nstld.verisign-grs.com. 2017021401 1800 900 604800 86400.86400INRRSIGSOA 8 0 86400 20170227170000 20170214160000 61045 . A5CqIucYyfFTzp03EuajDjp5Vw6dd3Oxip60AI7MCs/2xfBu1red4ZvF GfIEGHstG61iAxf7S3WlycHX9xKyfIOUPmMxuvkI9/NXMUHuvjUjv9KW TTkc1HV6PuUB1sv9gsuQ6GFnHCXAgMKXZs9YofRDlBi2jxAvJVc5U7nG sd8UqQs4WcinMHNvFV9+gwfax0Cr9KFDmDUbS+S2wYmNs+SGOn+CbFrD 8gs34GiYao8i0QGw7RVGTVJiuVOuUkeYe4iSXnJjNjeIlm8liq6PRXgM nI+ndPDogA/a8JATfyzQ97VDRwe/FucoTbe5qd2cHxqh1ZxxPkA3K3Fj 8Jv3kg==ae.86400INNSECaeg. NS RRSIG NSECae.86400INRRSIGNSEC 8 1 86400 20170227170000 20170214160000 61045 . B03J+aJuEA5r5Va8QiecBHZUucisWgdC8b14Q4MU5oGSdgmK9PmHLKMS mUiGj/OzH51P1l0G6zxG6bxU56tZ4gSME+rcpIntdKyiWU4QLpkiPa32 aApHFmu0pzugGSDWnQUmNDmCig7jJ2J61xlOzx19ni0eJazAthRtGWuK WI9bCVt9Yb7Bd21AedC0gugQWY+LKj7HR3zRhZ5dywpcTQUc78BrJDvh P8UxWprUJozcMYdVDqA5TvSlRHz8aLOnkD/olVsE5cU6qSvCX32E7WuQ IeFfhf1J940hly/3f960Dvm5kwX8l6CkNW083yLCnG8e7zArEUBRthvA a90SJw==

注意新增的 NSEC 记录，这个记录首先声明了一级域名 ae. 下只有 NS RRSIG NSEC 这三种记录，也就是说没有 DS 记录。此外，它还说明了 ae. 之后的一个一级域名是 aeg. ，所以通过这个记录，可以轻松的证明不存在 aea. 、aeb. 、aec. …… 这些一级域名。 那么，如果请求 aea. 这个不存在的一级域名，会发生什么情况？

$ dig @a.root-servers.net. aea. any +dnssec;; AUTHORITY SECTION:ae.86400INNSECaeg. NS RRSIG NSECae.86400INRRSIGNSEC 8 1 86400 20170228050000 20170215040000 61045 . U2e52sVPmIup4pSfWzg7hupPZb63NdYdsiNEqr2ygDBQrgOQ6rT2SZkP xZVvHc7ZtfggUV1iT6kels8+d3beURz0Vf58x6up+PUF6svaFOmx2Bpu 42owq6wYQH6ll8GLOKiIC/35omIXja0VFj4ueG1HsbHbWVxUcL5bsDrt UWRUU9Hp1ySp36+H7M5NE+YPNk8soH2xyANe+STkymH661m8jJqXbG2X atbCEEOtuXuplvS7Rm/YRS+UEtsamC3A9bDBnus/OiL3KS1ztuvrxQfS 6a1z45UtL0PBBQ5DzNiVd9QHHhSpsaxFUqg0iw21CB6MZaK10EB7EJCQ EWkRkg==.86400INNSECaaa. NS SOA RRSIG NSEC DNSKEY.86400INRRSIGNSEC 8 0 86400 20170228050000 20170215040000 61045 . fnA/PW3QvSzI4MXZ+ylGhv/Z+F+u6YdAWnSz1DfbwSZkcpzwZoO1/uiY QtYhYU5GF/dbTk7oGEjStA0dWVzyyf+7opW+DS1+R9pn5N/LynyqZ6Et Swk85MQl04gu5LxLrnn6Nind2ozRMha4Nn7tNlYG59GLH3hXkaQ6xYmE hD0Ya+UE6h2vcQ8Y8m3ccifDO2rBukdsUJ13dZLAScNAVJU6/2YxlyyX fYY7G0Ktqu5Tq10YvfJazZ5VraBzw+bkEzM8UEPGNNfX9FTB7zxhjyhU h1u87Z/nKMoIznzVu6Xk9AC5JM1lU/OIHyYHCp+XzMGuUdjwNZH706ND MGq/rQ==.86400INSOAa.root-servers.net. nstld.verisign-grs.com. 2017021500 1800 900 604800 86400.86400INRRSIGSOA 8 0 86400 20170228050000 20170215040000 61045 . Nj7xEVPJ5DtBFRP9Zy0GCIwY/ax3v9n9JV0EsKyAeHPYDw4PBMpXQRxa banAl7DVyytO+xLz1NxY3iYTSPtyFjbAzkipC5BJT0EFovbQJ7VJOS4P nZBFaVltjGnzzrC8+hWESyhcwn2DdsNw94JqlkVPEtbT+u6vgXbIv5lD 1/YJMRcvWR74FzBC/bYyk+s0WWVNWDenioI2F7NCRgKSYm1+6qXK4on7 MFAmJE9TYYyZFFRiQurS1wH+d3/xQTtjd93GYOhpWVND0NyN/t4nkxhT spHrofo9GvzTIcGTcwT4Pp1bdBXL6dS0P+JIDXTKQN7u/3RwoJj/6jPm FOSEKw==

通过请求 aea. ，从请求的结果可以得出两个结论：

1. ae. 和 aeg. 是两个相邻的一级域名（这也就相当于声明了不存在 aea. 这个一级域名），此外也说明了 ae. 下只有 NS SOA RRSIG NSEC DNSKEY 这些记录。
2. 根域名之后的一个一级域名是 aaa. ，此外也说明了根域名下只有 NS SOA RRSIG NSEC DNSKEY 这些记录。

注意，相邻的域名排序是包含该区域所有子域名的，也就是说所有的子域名都参加到了排序，刚才得出的 “ae. 和 aeg. 是两个相邻的一级域名” 其实并不准确，而应该是根域名区域下 ae. 和 aeg. 是两个相邻的子域名，因为 NSEC 结果还相当于说明了 a.ae. 这样的二级域名在根域名区域下也不存在。 如果 NSEC 是最后一个记录，那么它的下一个就又是区域自身了。 然而，可以发现，通过这个方法可以轻松的获得已经存在的记录：比如我只是试了一下 aea. 这个一级域名，却一下子就知道了根域名下还有 aaa. 、ae. 和 aeg. 三个一级域名，通过这样一直往下遍历，就能搜索到一个区域下的所有子域名。 知道所有的一级域名对于根域名服务器无所谓，因为一级域名的列表本来就是公开的。可是，这个功能也许不是我们所期望的，有的时候，想要在自己的域名下放置一些只有自己知道的子域名，这些子域名也许就是自己源站服务器的 IP，如果 DNSSEC 就这样实现的话，这就让其他人很容易就能遍历出来你所有的子域名。所以，在 DNSSEC 中，响应记录不存在的话还有两种解决方案，一种是对 NSEC 的 Hack，还有一种是 NSEC3：

NSEC 的 Hack

Cloudflare 上就使用了对于 NSEC 的 Hack，这样就能避免其他人遍历你的所有子域名。举个例子，正常的 NSEC 去解析 a.tlo.xyz 可能是这个结果（假如我只有 www 这一个子域名）：

$ dig @kami.ns.cloudflare.com. x.tlo.xyz. +dnssec;; AUTHORITY SECTION:tlo.xyz.3600INNSECwww.tlo.xyz. A MX TXT AAAA DNSKEY RRSIG NSEC; 省略一个 RRSIG 记录www.tlo.xyz.3600INNSECtlo.xyz. CNAME RRSIG NSEC; 省略一个 RRSIG 记录; 还省略了一个 SOA 以及 SOA 的 RRSIG 记录

通过观察 NSEC 记录，就可以直接看出这个域名下只有 www 一个子域名。 然而 Cloudflare 实际返回的结果是这样的：

$ dig @kami.ns.cloudflare.com. x.tlo.xyz. +dnssec;; AUTHORITY SECTION:tlo.xyz.3600INSOAgordon.ns.cloudflare.com. dns.cloudflare.com. 2023791623 10000 2400 604800 3600tlo.xyz.3600INRRSIGSOA 13 2 3600 20170216150135 20170214130135 35273 tlo.xyz. ARUYgesljY5azg1RqFgoKbTN6OOmAQUqTsLiQyTBXAMO4P/CecFGwTKY f1cVTI/s4euNahfGOvc0MnDb2R55TQ==x.tlo.xyz.3600INNSEC\\000.x.tlo.xyz. RRSIG NSECx.tlo.xyz.3600INRRSIGNSEC 13 3 3600 20170216150135 20170214130135 35273 tlo.xyz. y4g0Of3Ir/DqcbRT1ND5kwdGXlW++Zb+c9Cx0z60UAzbI+cpW2DDOmBB 4MMKi4zV9xEBg5Jq/8hwBGVo4ytDDg==

Cloudflare 这样则是告知了 x.tlo.xyz. 是存在的，但是只有 RRSIG 和 NSEC 记录，即相当于这个域名下没有任何记录。x.tlo.xyz. 之后的下一个域名是 \000.x.tlo.xyz. ，而实际上那个域名也是不存在的。这其实相当于 Cloudflare 撒了一个谎，并没有直接告知你这个域名的下一个域名。这虽然解决了问题，但是并不符合规范。

NSEC3

NSEC3 使用了在区域内的下一个记录内容的哈希值（按照哈希值的顺序排序）代替了原本的记录内容。从哈希值反推记录内容本身有一定的难度，于是就能够避免其他人遍历出所有的记录内容。（guozeyu.com 没有在生产环境中开启 DNSSEC，以下内容仅为测试结果）

$ dig @a.ns.guozeyu.com. ns.guozeyu.com +dnssec;; AUTHORITY SECTION:guozeyu.com.3600INSOAa.ns.guozeyu.com. ze3kr.icloud.com. 1 21600 3600 1209600 3600guozeyu.com.3600INRRSIGSOA 8 2 21600 20170411191942 20170403191942 52311 guozeyu.com. bHSh4a0zcaFEwS5dNEj/JT9Aosuy8Wdh+U2WaPou95iywqG6VhH85BXT EhYnjmeph/CABF5HC2OvUf9HhcnxjPF9NAQ2cfPTr6Ael9aNBGLFSejI 5VmCdp4Q1sYD6hS51k5BY22bJRyu9v8zWHNLYDRJSFBk4kR0RSV5n0CK 4pA=67uromrbachidk57be8035jf9gqnhmn1.guozeyu.com. 300IN NSEC3 1 0 1 F327CFB1FFD107F1 ENPCB7U0K7KFHLSCEOTOB7RAHS4TCH3V67uromrbachidk57be8035jf9gqnhmn1.guozeyu.com. 300IN RRSIG NSEC3 8 3 300 20170411191942 20170403191942 52311 guozeyu.com. MpV+6foWp+XQpwJnNCiIE0dqGigqX+2Z7XWuCFAd/TUS1sBHwnTRKmB5 Rl8Wf23ZMMfZh/oRHQbm4vE1RecMd78ZuvQM61iOmwAOmjIhJJh+LPSg 5KXMmYimTmtyd7/N437XYqmBREbz9EQ66ZqGucOahncPfxX2jhErvICN KDc=

标准的 NSEC 相比 NSEC3 的优点

标准的 NSEC 会暴露所有的子域名，而 NSEC3 不会，看起来 NSEC3 的优势明显。然而标准的 NSEC 相比 NSEC3 又有好处：子（Slave）DNS 服务器不需要拥有 DNS 的私钥，这样配置 Slave DNS 后就方便多了，和常规的 Slave 一样，只需要传送（Transer）整个区域即可，也能够正确的响应不存在的子域名。因为在标准的 NSEC 下 NSEC 和 RRSIG 的数量是有限的。而 NSEC3 或者 Hacked NSEC 都会根据不同的子域名返回不同的 NSEC(3) 记录，NSEC(3) 和 RRSIG 记录都是无限的。 举个例子，比如你现在可以下载到签名过的根域名的区域。其中包含了所有的 NSEC 记录，这样 RRSIG 可以在一台机器上生成，并将签名过的整个区域传送给其它子的根域名服务器上，这样能够有效的确保私钥安全。而用 NSEC3 或者 Hacked NSEC 的话，每一个子 DNS 服务器都需要有私钥。根域名服务器的数量众多，也由各种不同的组织管理着，所以很有必要保护好私钥。所以对于这种不怕被遍历到所有子域名的区域来说，使用标准的 NSEC 也未尝不可。

有了服务器监控服务，就能知道网站运行的情况以及在线时间。当服务器出现问题时，便能第一时间收到通知。个人网站运维需要这些服务来保证稳定性。但是，大量的此类服务都是面向企业，导致价格十分昂贵，而且并用不到其所提供的功能。本文就给各位站长推荐几个免费的服务器监控服务。

在线率（Uptime）监控服务

StatusCake

StatusCake 同时提供免费和付费的监控服务。免费版本可以创建无限多个 HTTP(s)、TCP、DNS、SMTP、SSH、Ping 和 Push 的协议监控，监控周期最短为 5 分钟，提醒主要支持 E-mail 和 Webhook 两种方式。免费版本不支持监控服务器配置信息，所以也无需在服务器上安装任何软件。

此外，StatusCake 支持 Public Reporting，你可以利用 StatusCake 建立一个监控页面。它还支持将在线率图像及网页嵌入在你自己的网页中，十分方便。

注册地址

UptimeRobot

UptimeRobot 也提供免费的监控服务，支持 HTTP(s)、端口检测、Ping，监控周期最短为 5 分钟。同样不支持监控服务器配置信息，所以也无需在服务器上安装任何软件。最多只能创建 50 个监控，支持 E-mail 提醒。

相比 StatusCake，它的监控功能要少，但是 Public Reporting 的页面要漂亮一些。由于 StatusCake 所多的那些功能个人站长也几乎用不到，所以 UptimeRobot 也是 StatusCake 的一个良好的替代。

注册地址

监控宝

监控宝是一家国内的监控服务，长期提供的免费版可以创建 6 个 HTTP(s)、Ping、DNS、FTP、TCP、UDP、SMTP 甚至是使用 SNMP 对服务器性能监控（需要软件），监控周期最短为 15 分钟。如果你需要检测国内到你的主机的速度，或者你的主机在国内，监控宝是一个不错的选择。它的免费监控是从中国内 3 个位置同时监控。它支持 E-mail 和手机短信告警。它不支持 Public Reporting，但是可以给分享网站的 SLA 证书。功能相当齐全，就是网站的界面设计比较欠缺。

注册地址

服务器指标监控服务

Stackdriver

最后，就要介绍我最近开始使用的强大的 Stackdriver。Stackdriver 是 Google Cloud Platform（下文简称 GCP）旗下的服务器监控服务，支持监控、调试、跟踪、日志。其中的 Uptime Check 支持 HTTP(s) 和 TCP，监控周期最短为 1 分钟。它支持 E-mail 、手机短信和 APP 内告警。它的 Uptime Check 是从全球 6 个地区同时监控，可以看到每一个地区的延迟。用来检测 CDN 的速度肯定会很不错。

如果你正在使用 Google Compute Engine（下文简称 GCE） 或者其他 GCP 的服务，那么这个服务还可以帮你记录服务器日志，每月有 5 GB 额度，超出后每 $0.5/GB。此外，它还能进行服务器性能监控，监控服务器各项指标。虽然原本 GCE 面板也能提供 CPU 等信息，但是这个是需要在服务器上安装 Agent，于是就能提供更丰富更准确的信息。安装过程如下：

curl -O https://repo.stackdriver.com/stack-install.shsudo bash stack-install.sh --write-gcmcurl -sSO https://dl.google.com/cloudagents/install-logging-agent.shsudo bash install-logging-agent.sh # 谨慎安装，见下文

毕竟是 Google 自家的服务，安装不需要任何登陆等操作。安装完毕后就会自动采集数据。它分为两个部分，Stack Monitoring 用于监控服务器指标，包括硬盘存储空间、内存占用（包括 Used、Buffered）等 GCE 默认无法监控到的数据。还有就是 Logging，它可以自动同步日志到 Google 的云端，你可以集中的执行搜索等操作。然而 Logging 这个进程会大概占用 100M 内存，小内存实例谨慎使用。需要注意的是，只有 Logging 是免费的，Monitoring 是收费的，每月 $8。 然后，你还可以为某一项指标建立告警，比如我创建了一个当磁盘空间高于 90% 的时候给我发邮件。 它可以创建公开页面分享服务器指标和 Uptime Check 延迟的图标，但是却不能显示在线率，实在是一个奇怪的设计。

Observium

Observium 通过 snmp 可以用来监控服务器的各项指标，包括内存、储存、网卡等。它可以免费安装在自己的服务器上，需要 MySQL 和 PHP 环境。官网给的是 Apache 的范例，如果你用 Nginx 就不需要安装 Apache。

它通过在服务端生成 PNG 来显示图表，所以图表很漂亮精致，但是由于不是矢量图，所以很难做到实时增量更新而且不能精细看到某一个时刻的数值。 Observium 可以轻松的管理许多个服务器。你可以体验在线 Demo。

一年之前，我发表过一篇文章：全面 HTTPS 时代即将到来。到现在，HTTPS 又有什么新变化呢？本文就来一起探索 HTTPS 在 2016 年的变化以及今后的发展可能。

SSL 和 HTTPS 简介

HTTPS 是加密了的 HTTP 协议，网址以 https:// 开头，就代表是使用了这个协议。 HTTPS 相比 HTTP，拥有全部的以下特性：

• 传输数据加密：与网站之间的通讯无法被中间人（如无线路由器所有者、运营商、在之间线路上的监听者）获取。
• 数据完整性：保证所传输数据没有被篡改。
• 身份验证：保证数据是网站所有者提供，而不是第三者提供。

由于 HTTPS 要完成身份验证，所以若需要配置 HTTPS，就必须要取得被公认的证书颁发商颁发的证书。

2016 年

Let’s Encrypt，首个真正免费的证书颁发商

部署 HTTPS 必须要拥有 SSL 证书，而 SSL 证书的价格区间在每年几百甚至上万元不等，高昂的证书价格成为了部署 HTTPS 的一个重大负担。2015 年末，Let’s Encrypt 正式开始公测，可以免费签发多域名的证书，此类证书原先的价格在百元到千元左右。即使是在测试阶段，仅仅 3 个月时间就签发了 100 多万张证书！ Let’s Encrypt 的证书使用自动化部署，验证、签发过程均通过 API 自动实现，大大缩短了申请证书所需要的时间；同时各种服务提供商也纷纷提供了自动签发 Let’s Encrypt 证书的渠道。由于 Let’s Encrypt 的出现，确实大大加快了 HTTPS 的普及。

HTTP/2，SPDY 的升级版

在 2015 年初，HTTP/2 正式成为标准，紧接着各大浏览器和操作系统纷纷支持：Firefox 36、Chrome 41、iOS 9 & macOS 10.11（Safari 9）、Windows 10（IE 11 & Edge）。紧接着，Cloudflare、CloudFront、UPYUN 这些 CDN 提供商也纷纷支持了 HTTP/2，HTTP 服务器 Nginx 和 Apache 也对其做了支持。 HTTP/2 的出现是为了取代 HTTP 1.1 和 SPDY。HTTP/2 主要是支持了多路传输，原本需要合并 CSS 和 JS 文件、为众多的图片准备多个域名的做法，使用了 HTTPS/2 之后就没什么必要了。相比 HTTP 1.1 的每一个数据需要单独的一个连接，HTTPS/2 中网站的所有数据只需要一个连接。

由于浏览器会限制连接数量，这就会导致在 HTTP 1.1 中，每次只能同时下载几个文件。多路传输可以让这些文件一块儿传输，大大减少加载时间。

然而，这些浏览器里只是针对 HTTPS 站点做了 HTTP/2 的实现。于是想到让网站提高加载速度，又不得不用 HTTPS。所以，HTTP/2 的出现也推进了 HTTPS 的发展。

2017 年

Google Chrome 放大招，对有无 HTTPS 的网站区别显示：

现在，Chrome 已经开始对使用了 HTTPS 的网站显示 “安全” 字样（EV 证书这个地方则显示企业名称）：

在未来的某一个版本中，对于无 HTTPS 的网站，最终将会这样显示（对于所有 HTTP 网站，未来不同的版本显示的过程是：灰色叹号、红色警报叹号、红色警报叹号 + “不安全字样”；有信用卡或密码提交的会先进行这类显示。下图是最终的第三阶段）：

你也可以在 Chrome 设置页面将其调整为 “一律将 HTTP 网页标为不安全”。我推荐所有人都这样设置，因为 HTTP 确实是毫无安全可言！ 相信没有公司愿意让用户看到自己的网站被标记为 “不安全” 吧？浏览器的推进起到至关重要的作用。

更新 1

在最新的 Chrome 58 版本里，非 HTTPS 的密码输入处已经显示这样的信息（此处为 weibo.com 的网站登陆窗口）：

经测试，只要主站是 HTTP，即使表单是提交到 HTTPS 页面，也会显示此信息。

Apple 强制要求使用 HTTPS 加密（ATS）

2015 年末的时候，苹果就开始实施 ATS，然而开发者仍能找到选项去关闭这个功能。而在 2017 年或之后某个时刻后（具体 deadline 苹果尚未明确给出，不过可以确定的是不开 ATS 审核会逐渐变严格，并要求提供更多的理由），所有新提交的 APP 必须开启 ATS，也就是说新提交的 APP 必须全部使用 HTTPS 内容了。这促使着众多国内厂商去做 HTTPS 支持。

cPanel 虚拟主机自动获取免费 SSL 证书方法

本站特别推荐的虚拟主机提供商 TlOxygen 现在就支持申请免费 SSL 证书了。整个过程十分简单，并且会自动续签！实现方式：自动为虚拟主机安装 acme.sh 软件，然后自动执行安装流程。此外，TlOxygen 的虚拟主机支持 SSH 访问，所以你也可以自行使用 acme.sh 或者任何其他工具操作。

Ubuntu 16.04.01 自带的软件源中的是 Nginx 1.10.0，但是这个版本的 Nginx 的 HTTP/2 模块中存在 Bug，具体见此。现在 Nginx 1.12 Stable 已经推出，直接安装 Stable 版本即可。 2018-06 更新：如果你使用 Ubuntu 18.04 或者是以后的版本，那么系统默认的软件源的 Nginx 版本（1.14）就足够了。

关于双证书，仅建议使用独立 IP 的人去使用，如果没有独立 IP，那么就需要启用 SNI 功能——然而几乎所有支持 SNI 功能的浏览器也都支持了 ECC 证书，所以可以跳过升级步骤，直接换 Let’s Encrypt 的 ECC 证书，不使用 RSA 证书。 我有不止一个服务器，如果都使用自己编译的 Nginx，那么太麻烦了，于是我决定使用添加软件源的方法，通过 apt 升级，方法如下： 首先需要先添加 Nginx mainline 的软件源：

$ sudo add-apt-repository ppa:nginx/stable # sudo apt install software-properties-common$ sudo apt update

然后移除现有 Nginx 并安装新版本：

$ sudo apt remove nginx nginx-common nginx-core$ sudo apt install nginx

安装时可能会询问是否替换原来默认的配置文件，选择 N 即可。 此时安装的 Nginx 已经包含了几乎所有的必要和常用模块，比如包括但不限于 GeoIP Module、HTTP Substitutions Filter Module、HTTP Echo Module。我安装的 Nginx 的 OpenSSL 版本是 1.0.2g-fips，所以并不支持 CHACHA20，想要支持 CHACHA20 只能使用 CloudFlare 的 Patch 然后自己编译。安装完成后就可以验证 Nginx 版本了：

$ nginx -Vnginx version: nginx/1.12.0built with OpenSSL 1.0.2g  1 Mar 2016TLS SNI support enabledconfigure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-mail=dynamic --with-mail_ssl_module --add-dynamic-module=/build/nginx-DYnRGx/nginx-1.12.0/debian/modules/nginx-auth-pam --add-dynamic-module=/build/nginx-DYnRGx/nginx-1.12.0/debian/modules/nginx-dav-ext-module --add-dynamic-module=/build/nginx-DYnRGx/nginx-1.12.0/debian/modules/nginx-echo --add-dynamic-module=/build/nginx-DYnRGx/nginx-1.12.0/debian/modules/nginx-upstream-fair --add-dynamic-module=/build/nginx-DYnRGx/nginx-1.12.0/debian/modules/ngx_http_substitutions_filter_module

此时，你的服务器就没有 Nginx 的 HTTP/2 bug 了，既然使用了最新版的 Nginx，那么就能够配置 ECDSA/RSA 双证书了。

Nginx 升级的小坑

在我升级的时候，遇到了 GeoIP 模块无法使用的问题，经研究发现是新版本将 GeoIP 改成动态调用模块的方式实现了，在 Nginx 的 http {} 配置中添加下方代码得以解决：

load_module "modules/ngx_http_geoip_module.so";

使用 Let’s Encrypt 签发免费多域名证书

Let’s Encrypt 提供完全面为免费，并且是自动化签发的证书，一张证书最多能签 100 个域名，暂不支持通配。 为了配置双证书，你首先应该签发下来两张证书，以下以 acme.sh 为例，首先先建立目录（以下所有案例均使用 example.com 作为例子，实际使用需自行替换）：

$ mkdir -p /etc/letsencrypt$ mkdir -p /etc/letsencrypt/rsa$ mkdir -p /etc/letsencrypt/ecdsa

然后修改 Nginx 配置文件，确保所有在监听 80 端口的都有 location ^~ /.well-known/acme-challenge/ 区块，本配置文件是强制跳转 HTTPS 的案例，这是源站的配置：

server {    listen 80 default_server;    listen [::]:80 default_server;    location ^~ /.well-known/acme-challenge/ {        root /var/www/html;    }    location / {        # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.        return 301 https://$host$request_uri;    }}

在签发之前，确保所有要签发的域名都指向了你自己的服务器！ 然后签发 RSA 证书（如果需要多域名证书，只需要多个 -d 即可，下同，不过保存的文件目录以及证书显示名称均为第一个域名）：

$ acme.sh –issue –reloadcmd “nginx -s reload” -w /var/www/html -d example.com –certhome /etc/letsencrypt/rsa

然后再签发 ECDSA 证书：

$ acme.sh –issue –reloadcmd “nginx -s reload” -w /var/www/html -d example.com -k ec-256 –certhome /etc/letsencrypt/ecdsa

卸载 acme.sh 自带的 cron，自己重新配置：

$ acme.sh –uninstallcronjob
$ vim /etc/cron.d/renew-letsencrypt

输入以下内容，注意替换 acme.sh 的路径为你安装的绝对路径：

15 02 * * * root /path/to/acme.sh --cron --certhome /etc/letsencrypt/rsa20 02 * * * root /path/to/acme.sh --cron --ecc --certhome /etc/letsencrypt/ecdsa

然后就完成了，证书会自动续签。

给证书添加或删除域名

因为 Let’s Encrypt 使用的不是通配符域名，所以会经常遇到有新的子域的情况，此时就需要给证书添加域名，一张证书最多可以添加 100 个域名。最简单的添加方法如下： 首先，修改证书的配置文件，两个证书的配置文件都要修改：

$ vim /etc/letsencrypt/rsa/example.com/example.com.conf$ vim /etc/letsencrypt/ecdsa/example.com\_ecc/example.com.conf

找到 Le_Alt 一行，将新的域名添加进后面（每个域名用逗号隔开，总共不能超过 100 个）。然后开始重新签发这个证书，需要添加 -f。

$ acme.sh --renew -d example.com --certhome /etc/letsencrypt/rsa -f$ acme.sh --renew -d example.com --ecc --certhome /etc/letsencrypt/ecdsa -f

要注意的一点是，目前 Let’s Encrypt 签发的 ECC 证书的中间证书和根证书暂且不是 ECC 证书，这将会在以后支持，详情见 Upcoming Features。

配置 Nginx

首先需要生成几个 Key：

$ openssl rand 48 > /etc/nginx/ticket.key$ openssl dhparam -out /etc/nginx/dhparam.pem 2048

然后添加以下内容进 Nginx，放在 http 或 server 区块下，虽然不支持 CHACHA20，但是添加进去也没影响。

### SSL Settings##ssl_certificate /etc/letsencrypt/rsa/example.com/fullchain.cer;ssl_certificate_key /etc/letsencrypt/rsa/tlo.xyz/example.com.key;ssl_certificate /etc/letsencrypt/ecdsa/example.com_ecc/fullchain.cer;ssl_certificate_key /etc/letsencrypt/ecdsa/example.com_ecc/example.com.key;ssl_session_timeout 1d;ssl_session_cache shared:SSL:50m;ssl_session_tickets off;ssl_dhparam dhparam.pem;ssl_protocols TLSv1 TLSv1.1 TLSv1.2;ssl_prefer_server_ciphers on;ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';ssl_stapling on;ssl_stapling_verify on;

最后不要忘了 nginx -s reload，然后 前往 SSL Labs 检查配置，可以看到旧的浏览器使用了 RSA 证书（我的服务器有独立 IP，所以无 SNI 支持的也能访问）：

至此，ECDSA/RSA 双证书配置完成，你可以在浏览器里查看到证书类型：

我的服务器上部署的代码、配置文件等内容大多是使用 Git 进行版本控制。为了能够使用、配置起来更方便，通常使用一整套系统去管理。很显然，在一些代码和配置文件里会有一些机密的内容，如一些密钥什么的，所以必须不能公开。GitHub.com 虽然提供了 Private 存放处功能，但是由于此功能是付费的，而且对于 Organization 的 Plan 还是极贵，并不十分划算；就算能有免费的 Private 存放处，把自己的很多重要的密钥放在第三方服务器上还是很不安全，所以能够 Host 在自己的主机上的，并且能够替代 GitHub.com 的软件/服务就是不错的选择。 本文将讲一下我在自己服务器上安装 GitLab 遇到的坑，进阶使用，包括使用 .gitlab-ci.yml 文件实现自动 Build，实时同步镜像到 GitHub。

能够 Host 在自己的服务器上的软件/服务其实有很多，比如 GitHub Enterprise，Bitbucket Server。不过再此还是推荐完全开源、免费、由社区维护的 GitLab Community Edition，没有任何限制，只是相比 Enterprise Edition 少了些本来也用不着的功能。

安装及遇到的坑

具体安装方法见文档，目前官方推荐的系统环境是 Ubuntu 16.04 LTS，安装起来非常简便，整个 Web 环境都会配置好。安装后的更多配置请参见文档。如果你的主机上跑了不只一个 Web 程序，那就需要对现有的 Web 软件做修改，需要参见官方的 Nginx 的配置文档。我的代码中使用了 sub_filter 来实现替换默认的标题，实现更好的 SEO，更加品牌化。 然后为了能达到更好的使用效果，还应该配置 SMTP 发件服务器，我使用的是 AWS SES；然后还需要一个支持 IMAP 的收件服务器实现 Reply by email，我使用的是 Gmail，收邮件的限制总比发邮件的限制少吧～这些的具体设置方法官方文档里都有。 安装后默认是允许注册的，如果你不想让外人注册，你需要直接去 Web 后台禁用。如果你想要开放注册，那么最好先想好新注册用户能干什么，比如和我一样：只允许新用户创建 Issues 和 Snippets，那就在 Web 后台将 Default projects limit 设置为 0，然后编辑后台的配置文件，禁止新用户创建 Group。同时建议在 Web 后台启用 reCAPTCHA 和 Akismet，防止恶意注册和恶意发 Issues。既然允许注册，那么也建议使用 OmniAuth 来支持第三方 OAuth 的方式登陆。

GitLab Runner

GitLab Runner 十分强大，但是并不是内置的，它可以极其方便的实现自动部署等非常有用的功能。安装配置好 Runner 后，在项目根目录下添加一个名为 .gitlab-ci.yml 的文件，以 master 分支为例，为了实现每次 commit 到 master 都将文件部署到 /var/gitlab/myapp ，那么文件内容应该是这样的：

pages:stage: deployscript:- mkdir -p /var/gitlab/myapp- git --work-tree=/var/gitlab/myapp checkout -fonly:- master

注意，你需要先创建 /var/gitlab 文件夹，并设置这个文件夹的用户组为 gitlab-runner:gitlab-runner

$ sudo chown -R gitlab-runner:gitlab-runner /var/gitlab

.gitlab-ci.yml 核心的部分就是 script: ，这里的脚本都是由用户 gitlab-runner 执行的，你可以根据需要修改，后文中也给了几种范例。 然后 commit，去设置页面里里激活这个项目的 Runner。建议在设置里设置 Builds 为 git clone 而不是 git fetch ，因为后者常常出现奇奇怪怪的问题，前者的速度瓶颈主要在于网络传输。

部署 Runner 在同一个主机上，Or not？

官方的文档里强烈不推荐把 Runner 部署在同一个主机上，其实这种说法并不正确。官方不推荐这样做是因为一些 build 会花费很长时间，占用很多的 CPU 和内存资源。但是如果你执行的 build 脚本并不会这样，那么安装在同一个主机上也未尝不可。

常见的部署范例

这几种部署是我比较常用的，大家可以当作范例，具体根据自己的需要弄各种不同的部署。 以下几种 Web 的部署方式所消耗的系统资源都不多，而且由于使用了 nice ，并不会阻塞其他任务，可以部署在同一台主机上。

Jekyll

修改之前那个 .gitlab-ci.yml 文件的 git checkout 一行，替换为：

jekyll build --incremental -d /var/gitlab/myapp

检查 PHP 的编译错误

也是添加以下代码到 .gitlab-ci.yml 即可自动检查所有 PHP 文件的编译错误，编译通过的文件不会显示，只会显示编译错误的：

if find . -type f -name "*.php" -exec nice php -l {} \;  grep -v "No syntax errors"; then false; else echo "No syntax errors"; fi

自动与 GitHub 同步

以下过程需要 root 权限登陆到主机，或者在每行命令前添加 sudo。 首先，需要先给 gitlab-runner 用户一个单独的 SSH Key：

$ ssh-keygen -f /home/gitlab-runner/.ssh/id_rsa

然后，创建 /home/gitlab-runner/.ssh/known_hosts ，内容是：

github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==

之后，获取 /home/gitlab-runner/.ssh/id_rsa.pub 文件内容，在 GitHub 上添加这个 SSH Key。 由于是使用 root 帐号，弄完了之后不要忘了修改用户组：

$ sudo chown -R gitlab-runner:gitlab-runner /home/gitlab-runner/.ssh

然后，同样是通过 .gitlab-ci.yml 实现自动同步：

git push --force --mirror git@github.com:[Organization]/[Project].git

修改 [Organization] 和 [Project] 为你自己的名称即可。

谈谈安装在自己服务器上的 GitLab 的好处

文件都存储在自己的服务器里，安全性比较有保障，自己有最高权限，不会遇到项目被删的情况。部署时延迟极低，可靠性也高，不会遇到自己服务器没问题但是第三方服务宕机导致无法部署的窘况。 可以根据情况部署到离自己最近的服务器，或者是内部服务器，像 GitHub 的服务器就在美国东岸，亚洲这边连接并不快，国内也不稳定。 最关键的是，如果你本来就有个 VPS 什么的，也有很大的空闲，那么相当于你可以免费获得私有存放处，但是要注意性能需求，没有足够的空闲还是不要启用。 由于能够配置好实时同步镜像到 GitHub，GitLab 还有那么多 GitHub 没有的功能，其实已经可以完全使用 GitLab 作为主要的版本控制工具，GitHub 只是存一份镜像备用。

HTTPS 是一种网络安全传输协议，网址以 https:// 开头，就代表是使用了这个协议。 苹果最新发布的移动端操作系统 iOS 9，除了带来了许多新的功能之外，还提升了整个系统安全性，正如iOS 开发者资源所说

If you’re developing a new app, you should use HTTPS exclusively. If you have an existing app, you should use HTTPS as much as you can right now, and create a plan for migrating the rest of your app as soon as possible. In addition, your communication through higher-level APIs needs to be encrypted using TLS version 1.2 with forward secrecy. If you try to make a connection that doesn’t follow this requirement, an error is thrown. 如果你正在开发一个新的程序，你仅应该使用 HTTPS。如果你已经有一个程序，你现在就应该尽可能多的使用 HTTPS，并准备好对剩下部分迁移的计划。另外，如果你的程序使用更高层级的 API 进行通信，则需要使用 TLS 1.2 或以上的版本。如果你试图建立一个不遵守这些需求的通信，就会引发错误。

没错，从 iOS 9 开始，将逐步禁用非 HTTPS 请求！ 即使现在已有的程序在 iOS 9 中仍可以在非 HTTPS 情况下工作。但是相信在不久的将来，所有程序都会使用 HTTPS，而且 HTTP 将会完全淘汰。 那么为什么要使用 HTTPS？那些情况下要使用HTTPS呢？

使用 HTTPS 原因

HTTPS 能够加密数据传输，防止中间人截取或是修改。能够实现加密用户信息和网站内容。 比如使用大众所说的 “不安全的免费 Wi-Fi”，如果用户访问的网页全部是 HTTPS 的，那么这个 Wi-Fi 对用户没有任何影响。也就是说，媒体报道的 “免费 Wi-Fi 不安全” 纯属造谣，没有任何道理。当启用了 HTTPS 和 HSTS 后，免费 Wi-Fi 完全不能截获到用户密码等任何信息，用户可以安心的进行付款等操作。显然央视 315 没有任何专业知识及解释就在骗大家 “免费 Wi-Fi 不安全”，完全就是恐吓观众。之所以微信朋友圈所有照片都能被获取，是因为微信朋友圈的上传是明文的，这分明是微信自己的问题，显然并不是所有的软件都存在这样的问题。随着 iOS 9 的发布以及强制 HTTPS 措施，这一类问题将不复存在了。 其次，使用 HTTPS 不仅仅是为了防止信息被盗窃，还可以防止信息被中途修改。比如中国联通和中国移动会修改网站内容，投放自己的广告让用户升级产品，而这些广告并不是网站主准备的，网站主事先也不知道。虽然它们这样做就是没有行业道德底线，但是我们仅需要使用 HTTPS，这些运营商就统统无能为力了。 包括小米路由器的 “404错误页面优化” 也是利用了同样的原理，对非 HTTPS 页面进行篡改，给用户提供自己的广告从而谋取利益。其本身就是劫持，绝没有夸大之言。除此之外，有的用户还发现就算是正常页面，也有小米通过劫持网页代码注入而加入的广告信息。但当 HTTPS 普及之后，这一切都会无影无踪。然而在 HTTPS 普及之前，一些不支持 HTTPS 的网站主只能忍受被运营商、路由器的劫持了。

使用 HTTPS 的地方

我认为，所有的网页以及程序都有必要全部且强制的使用 HTTPS，可以避免上述情况的发生。包括个人网站在内，也应该全面启用 HTTPS，防止因为被篡改植入的广告而流失读者。 使用 HTTPS 并不会增加太多的成本，还可以让页面速度变得更快。SPDY 协议可以最小化网络延迟，提升网络速度，优化用户的网络使用体验，然而 SPDY 协议只支持 HTTPS。 随着现在的趋势，越来越多的站长会主动或被迫的使用 HTTPS，HTTPS 即将成为主流。中国是 HTTPS 普及程度最小的国家，但是随着百度全站 HTTPS 以及 UPYUN 支持自定义域名的 HTTPS，将推动整个行业 HTTPS 的发展。

使用 HTTPS 的优点

加密传输

如果一个网页没有使用 HTTPS，那么就意味着页面上的内容，你正在搜索的关键词，甚至是用户名和密码都没有加密，“中间人”可以进行读取、篡改这些没有加密的内容。比如说你连接的免费 Wi-Fi、运营商等都可能会对网页内容进行修改。这些中间人会在你未经允许的情况下在网页上添加他们的广告、修改 404 页面样式、读取你微信朋友圈的图片。 但当这个网页启用了 HTTPS 之后，页面的数据就会被加密，正常情况下中间人就不能获取到你的数据，但是如果中间人替换掉了原有的 HTTPS 后，攻击依然是可能的，所以 HTTPS 站点必须包含一个证书用于验证。

验证

由于 HTTPS 站点必须包含一个证书用于验证，那么就可以验证这个服务器是否被域名所有者许可（以防止连接到中间人的服务器）。通常浏览器都会检验这个证书，如果证书错误会警告用户正在访问的网站有问题。假如用户的 DNS 服务被污染，那么就可能伪造身份，到另一个主机（IP 地址），这个甚至比中间人攻击更可怕，能做到更多的事。当用户使用 HTTPS 访问时，浏览器会验证这个网站的证书，如果证书报错则会警告，甚至无法访问。 但是假如用户访问的时候使用的是 HTTP，那么就不会对服务器进行验证。只有网站进行强制 HTTPS （也就是禁用 HTTP 链接）并启用了 HSTS，那么才能够进行全面的认证。一旦启用 HSTS，那么这个域名的所有页面在设定的有效期内就只能通过 HTTPS 访问。

加密提示

对于站点下所有资源都使用 HTTPS 协议的页面，很多浏览器都会有加密提示，以告知用户这个站点是加密的，让整个网站更高大上。不过我想在此提醒用户，并不是所有使用 HTTPS 的页面就是安全的，任何网站都能轻易申请到 SSL 证书，所以仍然需要辨别域名本身。但是对于直接显示其公司名称的 HTTPS 站点就更值得被信任，因为这种证书是需要纸质证明材料的验证的。下方为使用 Mac 版 Chrome 访问一些 HTTPS 站点的加密提示，Chrome 的加密提示菜单中分为两部分，前一部分验证，后一部分是加密，通常可以分为以下 4 种：

其中第一种和第二种情况代表使用了足够安全的加密方式（但是第二种没有提供任何 Certificate Transparency 信息），只是证书的签名等级不同，与加密方式以及验证的安全性无关，这两种情况下都能保证证书不是伪造的。

第三种情况是包含不安全资源，网站的外观可能会被改变，但 HTML 文本本身是可靠的。

第四种情况是使用了 SHA-1 签名的证书，由于 SHA-1 不是足够的安全，也就是说验证的安全性不够，由于这种证书伪造的成本越来越低，所以可能不安全。这种站点的加密仍然是足够的。

第五种情况代表当前可能正在被中间人攻击（因为没有提供任何 Certificate Transparency 信息，而且还使用了 SHA-1）。

第六种情况表示这个网站使用不被信任的根证书签发的证书（或者证书中不包含当前域名）。 关于 Chrome 的加密提示 无论如何，我都不推荐你使用 SHA-1 签名的证书，值得注意的是最新版 Safari 也可以选择不信任 SHA-1 签名的证书了，SHA-1 即将淘汰。

搜索引擎

Google 对 HTTPS 站点的抓取很友好，官方说使用 HTTPS 还会提高排名。Google 也支持使用 SNI 协议的 HTTPS 站点。 百度近期支持了对 HTTPS 站点的抓取，并会相应提高排名，经测试并不是所有证书都支持，但是也支持 SNI 协议。

使用 HTTPS 的缺点

更慢的加载速度

不得不说使用 HTTPS 的确会增大延迟，这种延迟主要体现在加载首个页面，进入下一个页面就会快很多了。在我这里测试启用 HTTPS 后会多出 2~5 倍的延迟。如果还有资源在别的域，那么这些资源也会多出这么多的延迟。

兼容性问题

SNI 协议已经被大量的使用，但是仍然有一些设备是不兼容的，比如 Windows XP 的 IE8 及以前的浏览器都不兼容。截止到目前，中国支持 SNI 的浏览器使用率已经达到了 95%。

搜索引擎

有些搜索引擎对 HTTPS 很好，但是也有一些搜索引擎不支持它。不过目前越来越多的搜索引擎都在逐步支持 HTTPS，我觉得不必担心。

成本

使用 HTTPS 必须需要得到一个证书。现在已经有越来越多的免费 SSL 证书了，总体来说实现 HTTPS 的成本越来越低了。但是随着证书颁发的成本越来越低，HTTPS 作为验证的功能将会变的更小，但是作为加密的功能还是存在的。

其它

HTTPS 只能在一定程度上防止篡改，但是并不能抵制一些强大的网络封锁。 目前一些“流氓”浏览器竟然不验证证书，大大减弱安全性。如果不验证证书，虽然还有加密的效果，但是如果 DNS 被污染，中间人攻击依然可行。 如果 DNS 被污染，但仍需要使用 HTTPS，那么就将无法访问站点。所以 DNS 也是十分需要加密的。如果能早日支持 DNSSEC 或者是 “HTTPS DNS”（即使用 HTTPS 协议解析 DNS），那么 HTTPS 作为验证则显得不那么重要，完全没有中间人攻击的日子指日可待（但是没有网络封锁还是不可能的）。 或许以后的浏览器只能访问 HTTPS 站点，就像 iOS 9 大力推动 HTTPS 一样，这样就能大大提高安全性，抵制中间人攻击。

使用 .htaccess 强制 HTTPS

下方为在 Apache 里的 .htaccess 中配置

RewriteEngine onRewriteCond %{HTTP:X-Forwarded-Proto} =httpRewriteRule ^ https://%{HTTP\_HOST}%{REQUEST\_URI} \[L,R=301\] # 禁用 HTTP 协议

HSTS 以及 HSTS Preload List

HSTS（HTTP Strict Transport Security, HTTP 严格传输安全）是一种让浏览器强制 HTTPS 的方法，当用户访问 HTTPS 站点时，由服务器返回一个 Header，告知浏览器在这个域名下必须强制 HTTPS，在有效期内，浏览器访问此域名将只使用 HTTPS，下方为在 Apache 里的 .htaccess 中配置。

Header set Strict-Transport-Security "max-age=315360000; preload; includeSubDomains" env=HTTPS

比如首次访问 http://tlo.xyz 时，浏览器会被 301 跳转到 https://tlo.xyz 下，然后就会收到这个 Header，在 10 年内，tlo.xyz 下所有的域名都只会使用 HTTPS，包括二级域名 ze3kr.tlo.xyz。 但这一切还没有结束，假如浏览器第一次访问时，网站就已经被 HTTPS 劫持攻击了，那么这样做是毫无意义的，所以需要在启动 HSTS 后，包含 preload 参数，然后去提交，注意好要求。 当你提交了之后，一段时间后就能在各大浏览器的源码里看到你的域名了。

• Chromium 源码
• FireFox 源码

检查你的 SSL 配置

前往 SSL Server Test，就能给你的服务器的 SSL 配置给出一个评分。 哎，这差距

小提示

• 一旦设置了强制 HTTPS 协议或者启用了 HSTS 后很难再退回 HTTP 协议（尤其是后者），如果突然关闭了 HTTPS 协议，用户可能在很长一段时间内无法访问网站，或者证书报错，大量流失用户。所以决定强制 HTTPS 前请仔细做好考虑。

　　又到了每季度的安全新闻汇总。今天这篇比较长，有些俺认为不那么重要的新闻，就没有放进来了。

★隐私保护

◇【输入法】的隐私风险

《输入法会“背叛”我们吗？ @ 南方周末》

一位受访者对南方周末记者描述，几天前朋友家要换马桶，她微信回信息说了自家用的牌子，下次打开手机 WPS 时，开屏广告就成了京东马桶。“这种 N 年不提的话题，不可能这么巧吧？”她怀疑是输入法泄密。
根据 Mob 研究院数据，2020年搜狗、讯飞和百度三家输入法占据了国内市场九成的活跃用户，其中搜狗占有率最高，54%。2020年9月，腾讯全资收购了搜狗。
易观一组数据表明，中国第三方输入法的活跃用户在2019年达到7.71亿。输入法已成网民刚需。

输入法会获取哪些信息

......
梳理三份隐私政策，输入法软件可能收集的用户信息有11类，涉及调用的手机权限有12项。

◇大规模用户数据泄漏

《谁在倒卖我的简历？ @ 新浪》

　　编程随想注：
　　今年315晚会曝光的丑闻里面，据说热度最高的是【简历泄露】。简历包含的信息量非常大，也难怪大伙儿很关注此事。
　　上述这篇挺长的，俺把小标题列一下：

你的简历是怎么泄露出去的？
　　1）注册假公司骗取简历
　　2）与招聘网站“内外勾结”
　　3）利用爬虫技术抓取（招聘网站的）简历

买你的简历用来干嘛？
　　1）网赚营销与兼职招聘
　　2）博彩、彩票和棋牌骗局
　　3）房地产、保险、教育培训的营销

《Facebook 超5亿用户数据泄露，事件与功能误用有关 @ cnBeta》

北京时间4月7日早间消息，据报道，此前，美国社交媒体平台 Facebook 被曝有5.33亿用户数据遭泄露，其中包含一些知名人士的信息。媒体报道称，泄露的信息包括用户手机号码、名字、位置、出生年月日、电子邮件地址等。对此，Facebook 今日回应称，报道中的数据泄露事件与数据窃取有关，而不是被黑客入侵系统。
Facebook 表示，2019年因为一个功能遭到误用，导致信息出现泄露，可能影响用户约5.3亿；发现问题之后，Facebook 第一时间堵住漏洞。
根据 Facebook 的解释，2019年9月之前，恶意破坏者利用 Facebook 同步联系人工具存在的漏洞窃取数据。随后公司发现漏洞并修复。

......

《巴西几乎所有人的信息泄露 @ Solidot》

巴西几乎所有人的信息泄露。泄露的数据为 14GB，包含了1.04亿车辆和4000万家企业详细信息，潜在受影响人数2.2亿。巴西人口2.1亿，这意味着巴西所有人的信息都被泄露（还有部分在巴西生活的外籍居民）。泄露的信息包含了姓名、出生日期和 CPF 号码。CPF 号码是巴西税务局分配给居民和需要纳税的外籍居民的数字。网络安全公司对钓鱼骗局发出了警告。

◇信息时代的【数字军阀】

《Google、苹果、Facebook、微软——数字时代的军阀 @ Solidot》

去年11月，苹果用户在一次影响广泛的宕机事故后才知道：苹果监视了用户打开和启动的每一个应用程序（编程随想注：上一期谈过这个重大丑闻【OCSP 事件】）
苹果为什么要这么做？最为善意的猜测是：此举旨在更早发现恶意程序。在一个充斥着恶意的网络世界里，这么做是必要的。安全专家 Bruce Schneier 将这种现象形容为“封建式安全”。
生活在21世纪的我们，面临各种数字强盗的围攻。从身份窃贼，到跟踪者，到企业和政府间谍，到骚扰者。我们是没有办法自保的。即使是身经百战的专家也无法和强盗相抗衡。为了抵抗强盗，你必须做到完美，不犯任何错误。而强盗只要抓住一个错误就能逮住你。因此为了安全起见，你必须和数字军阀结盟。苹果、Google、Facebook 和微软等建立了庞大的要塞，它们投入了大量金钱招募了最强的雇佣兵来保护要塞，为客户（包括你）抵御攻击者。
但如果军阀们转向了你，你对它们而言将是赤裸裸的。这种敌我难辨的情况在与军阀打交道的过程中一直发生着。比如 Google 调整 Chrome 以阻止商业监视（但不阻止它自己的商业监视）。Google 会努力阻止其他人监视你，但如果他们付钱了，Google 就会允许他们监视你。
如果你不在乎被 Google 监视，如果你信任由 Google 判断谁是骗子谁不是，那么这没问题。但如果你们之间存在不一致的意见，那么输的肯定是你。苹果在2017年按中国要求从其应用商店下架了保护隐私的工具。原因是苹果必须遵守中国的法律，它在中国有公司，有制造基地。军阀自身的安全是远甚于客户的。

　　编程随想注：
　　俺的观点是：要善于【扬长避短】——既要利用大公司提供的某些优质服务，同时又不让大公司窥探你的隐私。
　　当然啦，要做到这点，需要一些经验＆技巧。
　　就拿本人的亲身经历举例——
一方面，俺用着 Google 的博客平台 Blogspot（它的安全性足够好，而且能抵御【国家级】的 DDOS 攻击）。
另一方面，俺不用 Google 搜索（俺用的是 Startpage，其搜索质量等同 Google）；另外，俺也不使用 Google 开发的 Chrome 浏览器。

◇QQ 在偷窥你的上网历史

《QQ 被发现扫描并上传用户的浏览器历史 @ Solidot》

腾讯消息应用 QQ 以及 QQ 办公版 TIM 被发现会扫描用户的浏览器历史，搜索购物记录，选择性上传。用户报告，QQ 在登陆10分钟之后开始扫描 Appdata\Local\ 下的所有文件夹，对其中 User Data\Default\History 进行进一步的扫描，User Data\Default\History 是基于 Chrome/Chromium 的浏览器默认历史纪录存放位置，Firefox 的浏览历史存放位置不同，因此目前看来不受影响。不过 Firefox 市场份额不高，而基于 Chrome/Chromium 的浏览器占据了九成以上的份额。

　　编程随想注：
　　疼逊官方在知乎发了一篇声明（这里），进行辩解。
　　有必要提醒诸位：不管上述丑闻是“有意 or 无意”，疼逊官方声明肯定都会说是“无意”。因此，对这类官方回应，不必太当真。

◇疼逊如何看待“微信好友关系”？

《微信好友关系，是否属于个人隐私？ @ Solidot》

腾讯总部所在地深圳市南山区法院上个月判决，微信好友关系不属于个人隐私。
本案的原告在2019年发现，使用微信或 QQ 登录腾讯“微视”APP后，微视会获取其全部微信或 QQ 好友信息。他认为，腾讯公司未经其授权将他的微信、QQ 好友关系提供给其他 APP，侵犯了他的隐私权。
但南山法院认为：“隐私是指用户对其生活领域不愿公开的信息享有不被他人知悉的权利。原告主张的性别和地区属于公开信息，不构成隐私。”
北京师范大学法学院教授袁治杰认为：腾讯并没有权利将微信好友关系披露给第三人，“即使我同意微信可以将我的好友关系提供给他人，微信也不得提供。因为好友关系是双向的，要想有权提供，微信必须同时获得了我的好友们的同意才行。换句话说，必须获得双向同意才行。”

◇【聊天工具/IM】的选型

《Mark Zuckerberg 被发现使用 Signal @ Solidot》

Facebook CEO Mark Zuckerberg 使用加密消息应用 Signal，他的电话号码包含在泄露的5.33亿 Facebook 用户数据中间（编程随想注：这个“用户数据泄漏事件”，前面已经提到了），除此之外还有他的名字、地址、婚姻状况、出生日期和 Facebook ID。
一位安全研究人员说：又一次大转折，Mark Zuckerberg 注重他自己的隐私，使用不属于 @facebook 的端对端加密聊天应用。
......

　　编程随想注：
　　俺经常说：“观其行”比“听其言”更重要。大伙儿来看看，Facebook 的老板，放着自家的 WhatsApp 不用，非要用别家的 Signal。WhatsApp 的隐私风险，昭然若揭。

《WhatsApp 的隐私友好替代 @ Solidot》

WhatsApp 的服务条款变更引发了很多争议，加密邮件服务 Proton 官方博客介绍了多个隐私友好的替代服务：
Signal，开源端对端加密，缺点是注册需要手机号；
Telegram 的缺点是私聊才端对端加密，没有群聊；（编程随想注：这款也要用手机号注册）
Threema，开源端对端加密，但应用本身不免费；
Wickr Me，不开源；
Wire，注册需要手机号或电邮，记录大量元数据；
Element，使用 Matrix 通信协议，基于去中心化联邦架构；
Keybase，已被 Zoom 收购，记录元数据。（编程随想注：Zoom 是商业公司）

　　编程随想注：
　　最近几年，不止一个读者在博客评论区问俺，理想中的 IM 工具是啥样？今天借这个机会聊一聊。
　　俺认为：【至少】要达到如下的【每个】要求，才算及格。

1. 开源（不光客户端要开源；如果有服务端，服务端也要开源）
2. 依靠【社区 or 非营利组织】进行维护（俺信不过商业公司）
3. 能够以【隐匿】的方式注册帐号（这也就意味着：凡是要“绑定手机号”的，都不符合）
4. 能运行在【桌面】操作系统（“桌面系统”比“手机系统”更有利于安全加固——关于这点，俺已经唠叨很多次了）
5. 采用【去中心化】的架构（“P2P or 联邦式”都可以，有助于对抗政府的审查和封锁）
6. 免费（一旦涉及到付费，容易暴露个人身份信息）
7. 支持“端到端加密”（这点无需解释）

　　顺便说一下：
　　开博十多年，俺【从来不用】IM 工具与读者交流。俺更倾向于用“邮件 or 博客留言”的方式与读者交流。
其一，（相比 IM 而言）这两种方式暴露的信息量更小。
其二，这两种方式都是【纯 Web】，无需安装任何软件（请注意：每当你新装一个软件，都潜在地增加了系统的攻击面）


《为什么俄罗斯网络犯罪分子流行用 Jabber？ @ Solidot》

俄罗斯网络犯罪世界充斥着谜团，但有一种技术充当了主要的通信工具：有18年历史的分布式开源即时通讯协议 Jabber。根据安全公司 Flashpoint 的研究，黑客做交易、分享情报和对恶意程序提供技术支持都是通过 Jabber 完成。该公司资深研究员 Leroy Terrelonge III 称，在网络犯罪经济中，Jabber 是通信的黄金标准。Jabber（或又叫 XMPP）通信系统由数千个独立服务器构成，在全世界有大约一千万用户。有10亿用户的 WhatsApp 使用的是一个 XMPP 变体。ICQ 曾经统治了俄罗斯 IM 市场长达20年，当 Edward Snowden 在2013年披露美国的大规模监视之后，俄罗斯人开始转向了 Jabber。Jabber 加上它的加密插件 OTR（off-the-record）能为通信提供强加密支持。Jabber 的联邦式架构允许任何人运营服务器，这对犯罪分子有巨大的吸引力，他们担心企业与政府之间合作过于紧密。

　　编程随想注：
　　俄罗斯网络黑帮偏爱的 Jabber/XMPP，严格来讲只是一个【IM 协议】，而不是一款 IM 软件。已经有很多软件（包括开源软件）实现了该协议。
　　XMPP 采用【联邦式】架构。通俗地讲，其架构类似于“电子邮件”。对于电邮而言，假设张三用 A 公司的邮箱，李四用 B 公司的邮箱。他俩依然可以相互收发邮件，而且两人可以使用完全不同的邮件客户端软件。XMPP 的原理也差不多。
　　如果你想挑选一款 XMPP 的聊天软件，可以参考俺在上一段点评中列出的“理想的 IM 应具备哪些要素”。
　　除了 XMPP，还有一个【Matrix 协议】也值得推荐。俺在《近期安全动态和点评（2019年2季度）》简单介绍过它。Matrix 与 XMPP 有诸多相似之处——都是开放的 IM 协议，都采用“联邦式”的架构，都有多种软件实现 ...

◇【中国版】的 Flash 插件

《安全公司称：Flash 中国版会安装广告程序 @ Solidot》

Adobe 在2020年12月31日之后停止更新和分发 Flash Player，之后重庆重橙网络科技有限公司通过网站 flash.cn 独家在中国大陆分发和维护 Flash Player。
安全公司 Minerva Labs 在收到多次与 Flash 中国版相关的安全警告之后对其进行了分析，发现 Flash 中国版除了安装 Flash 之外还会下载和运行名叫 nt.dll 的文件，其主要功能类似广告程序，但不排除它可以用于其它恶意目的。Flash 中国版主要影响中国用户。

◇Email 里面的【跟踪像素】

《电邮中的跟踪像素日益流行 @ Solidot》

在电邮中使用跟踪技术正日益常见。被称为“跟踪像素”的技术可记录邮件是否打开，以及何时打开；邮件被打开了多少次；打开邮件的设备类型；用户的粗略位置。这项技术可被用于判断一个特定电邮推广活动的影响，以及记录下更多的客户肖像细节。
跟踪像素通常是只有 1x1 像素的 .GIF 或 .PNG 文件，被插入到插入到电邮的页眉、页脚或正文中，用户的裸眼是无法识别出它的。用户可以使用电邮程序的免费插件剥离掉大部分跟踪像素。

　　编程随想注：
　　对付这种“跟踪像素”，一种简单有效的方法是——用 Web 方式收邮件，同时在浏览器中【禁用图片】。
　　有些同学会担心：一旦浏览器禁用图片，访问别的网站也看不到图片了。
　　俺的解决方法是——设置多个【隔离的】浏览器环境，其中一个【专用于】俺的 Gmail 邮箱。在这个浏览器环境中【禁用图片】。
　　这么干【至少】有如下几个安全优势：
其一，因为这个浏览器环境是【专用】滴，只访问 Gmail 相关域名，降低了各种“跨站攻击”的风险；
其二，既然只访问固定的域名，可以在该环境中搞【CA 证书白名单】，降低“流氓 CA”的风险（关于【证书白名单】这种安全加固方法，参见“这篇博文”的介绍）；
其三，规避了“跟踪像素”；
其四，因为禁用图片，规避了“浏览器的图片引擎”潜在的安全漏洞。
　　至于如何设置多个【隔离的】浏览器环境，在如下几个系列教程中都有介绍：
《如何防止黑客入侵》（系列）
《如何保护隐私》（系列）

◇访问邮箱的方式——“Web 方式” VS “软件方式”

　　（本文发出后，与热心读者在评论区交流“邮件访问方式”；俺再补充一个小节，汇总相关的讨论结果）
　　访问邮箱，常见的方式有两种——
其一，如果电子邮件服务商提供“Web 界面”，那么用户就可以通过【浏览器】访问该界面（在本小节，这称之为“Web 方式”）；
其二，如果电子邮件服务商提供 SMTP/POP3 或诸如此类的协议支持，用户可以通过【邮件客户端软件】操作邮箱（在本小节，这称之为“软件方式”）。
　　这两种方式各有优缺点，俺简单总结如下：

　　【Web 方式】的优点
1. 服务器的限制
如果邮件服务器只提供 web 界面（不提供其它邮件协议的支持）；那么你只能用“Web 方式”
2. 避免额外安装软件
一般来说，大部分网民的系统中都已经有浏览器。用“Web 方式”，你就【无需】额外安装邮件客户端软件。
俺经常唠叨的一个安全原则是——系统中安装的软件尽可能少（可以降低【攻击面】）
3. 【网络隐匿性】的考虑
（这点是针对安全性要求较高的网友）
有些邮件用户不希望邮件服务器知道自己的公网 IP，因此需要采用某种“网络隐匿术”。这方面，Tor 当然是首选。
如果用“Web 方式”，要走 Tor 代理会比较容易（直接使用【Tor Browser】即可）
反之，如果用邮件客户端，还需要额外对其进行配置；万一配置错误，导致客户端【没有】走 Tor 网络，会是潜在的隐患。
4. 【本地无痕】的考虑
（这点是针对安全性要求较高的网友）
“Web 方式”【无需】把邮件同步到本地，就有可能做到【本地无痕】。
比如说：先在虚拟机中创建快照，然后用“Web 方式”查看邮件；看完之后回退到快照——这就可以做到【本地无痕】。

　　【软件方式】的优点
1. 服务器的限制
如果邮件服务器只提供邮件协议（SMTP、POP3、等），不提供“Web 界面”；那么你只能用“软件方式”
2. 攻击面的考虑
随着 Web 的相关标准越来越多，如今的 Web 浏览器也越来越复杂。一般来说，软件越复杂，则攻击面就越大。
相反，如果你选择某款【轻量级】的邮件客户端，它的攻击面就有可能【远小于】浏览器。
3. 【纯文本】的邮件客户端
（这点是针对安全性要求较高的网友）
有些邮件客户端是【纯文本】软件，那么它天生就可以防范（上一个小节所说的）“跟踪像素”。
而且这类邮件客户端还有一个好处——可以用在【纯文本】的操作系统环境中（【没】安装图形界面的系统）。
【纯文本】的操作系统环境，因为少掉了图形界面，有助于降低攻击面；但“使用门槛”会比较高，不适合技术菜鸟。
作为对比，主流的浏览器都依赖“图形界面”。虽然也有少数【纯文本】的浏览器，但这些浏览器的功能太弱（比如：缺乏 JS 引擎），通常【无法】操作邮箱的 Web 界面。

◇【智能坐垫】的隐私问题

《杭州公司用智能坐垫记录员工离座时间 @ Solidot》

杭州荷博物联公司设计了一款智能坐垫，作为产品研发的一部分，发给员工放在他们的办公椅上进行测试。这些坐垫号称是用于检测员工健康状况，指出可能是疲劳迹象的不良坐姿，测量心率，统计员工在办工桌前坐了多久。
但当该公司的人力资源经理开始询问员工，为什么长时间离开座椅或提前下班时，人们很快明白了，这些坐垫也记录了员工最不想让老板知道的事情：他们什么时候不在自己的办公桌前，这可能会给员工带来麻烦。
......

　　编程随想注：
　　今年春节前（2021年1月底），俺刚刚发了一篇《每周转载：内卷的天朝，各阶层的众生相（网文17篇）》，其中提到了各种“内卷”，包括“白领的内卷”。
　　在“996”已经成为常态之后，公司的 HR 开始监控员工“离开坐位的时间”。真是越来越变态了。
　　引申阅读：
　　《“996工作制”只不过是【劫贫济富】的缩影——“马云奇葩言论”随想》
　　顺便说一下：在如下博文中，俺介绍了“如何跳出996怪圈”。
　　《学习与人生——700篇博文之感悟》

★高危漏洞

◇Windows 的远程执行漏洞

《Google shares PoC exploit for critical Windows 10 Graphics RCE bug @ Bleeping Computer》

　　编程随想注：
　　该漏洞编号 CVE-2021-24093，影响 Windows 10 ＆ Windows Server 2016。这是 Google 安全研究人员在去年11月发现并报告给微软。而微软直到今年（2021）2月的例行更新才修复。
　　漏洞位于 DirectWrite API 进行字体渲染的代码中（缓冲区溢出）。Windows 平台上的浏览器（Chrome、Firefox、Edge、IE）都会使用系统提供的 API 进行字体渲染，因此都会受此影响。
　　为了利用这个漏洞，攻击者可以创建一个 Web 页面，其中包含精心构造的字体，然后诱导受害者访问该页面。当受害者的浏览器打开该页面时，就中招了。由于此漏洞针对“字体渲染”，与 JS【无关】。因此，即使浏览器禁用了 JS 脚本，还是会中招。
　　在上一期的《近期安全动态和点评（2020年4季度）》中，俺介绍过另一个漏洞 CVE-2020-15999，与这个很类似。CVE-2020-15999 位于“FreeType 字体渲染库”。也是利用“Web 页面的字体”来实现远程代码执行。
　　在上一期，俺说过如下这句，今天再次贴出来：

假如你很注重安全性，为了更彻底地消除【字体】导致的攻击面，你可以定制浏览器，禁止在 Web 页面中加载外来的字体。
对 Firefox 的深度定制，可以参考教程《扫盲 Firefox 定制——从“user.js”到“omni.ja”》；对其它浏览器的深度定制，俺暂时还没写过教程。

《Multiple Security Updates Affecting TCP/IP: CVE-2021-24074, CVE-2021-24094 and CVE-2021-24086 @ 微软安全响应中心》

　　编程随想注：
　　微软在2月的例行安全更新中修复了3个【协议栈】的漏洞。
　　半个月前（2021年3月），俺正好发了一篇《计算机网络通讯的【系统性】扫盲——从“基本概念”到“OSI 模型”》，介绍了“协议栈”相关的概念。其中有如下这张图：
　　这3个漏洞就位于图中的【操作系统协议栈】那一坨。更具体地说：是“操作系统协议栈”中处理“IP 协议”的那部分代码。这3个漏洞中，有2个的类型是【远程代码执行】，还有1个属于【拒绝服务】
　　一般来说，“协议栈”的漏洞是很少见滴，而且也很危险。其危险性在于——攻击者可以发送某个精心构造的数据包，当这个数据包到达目标系统（受害者系统），会立即被操作系统的协议栈处理。如果协议栈有漏洞，系统直接就中招了。假如协议栈的漏洞可用于“远程执行代码”，理论上就可以用来构造快速传播的【蠕虫】。
　　好在这次的2个远程执行漏洞，利用的难度比较大。但攻击者要想利用这3个漏洞进行“拒绝服务”（让系统蓝屏），还是比较容易滴。以下是微软官网的原话：

The two RCE（注：Remote Code Execution）vulnerabilities are complex which make it difficult to create functional exploits, so they are not likely in the short term. We believe attackers will be able to create DoS exploits much more quickly and expect all three issues might be exploited with a DoS attack shortly after release.

◇Zoom（视频聊天）的远程执行漏洞

《Critical Zoom vulnerability triggers remote code execution without user input @ ZDNet》

　　编程随想注：
　　全球疫情之后，Zoom 这款视频聊天工具很流行。前不久的 Pwn2Own 大赛（黑客有奖竞赛）中曝光了 Zoom 的一个高危漏洞，可以实现【远程代码执行】，而且无需用户互动——也就是说，在受害者没做任何动作的情况下，攻击者就可以在系统中运行攻击代码。
　　目前已经确定：影响 Windows ＆ MacOS 版本的 Zoom Chat。手机版的 Zoom Chat 是否受影响，还不确定。由于该漏洞是前几天（4月7日）才曝光；截止俺写本文时，Zoom 公司尚未修复该漏洞。

◇“茄子快传”的远程执行漏洞

《茄子快传发现多个安全漏洞 @ Solidot》

安全公司趋势科技报告：在茄子快传中发现多个安全漏洞，漏洞能导致远程代码执行。
茄子快传是下载量最高的传输应用，曾跻身全球应用下载排行榜前十。它最早由联想开发，一度预装在联想手机上，后从联想独立出去。
茄子快传索取的权限相当广，其中包括访问所有本地存储和媒体，摄像头、麦克风、通讯录、位置，甚至还可以删除应用。趋势科技称，茄子快传的漏洞能被用于泄露用户的敏感数据，以及远程执行代码。

◇Chrome 的高危漏洞

《新 Chrome 0day 漏洞正被利用 @ Solidot》

Google 本周释出了 Chrome 的安全更新 v89.0.4389.72，修复了47个漏洞，其中包括正被利用 0day 漏洞。
编号为 CVE-2021-21166 的漏洞是微软安全研究员 Alison Huffman 在2月11日报告的，Google 没有披露漏洞细节，只是表示它知道漏洞正被利用。
这是 Google 在今年修复的第二个 0day，上一个是2月4日修复的 V8 堆溢出漏洞 CVE-2021-21148。

◇Exchange Server 高危漏洞

　　编程随想注：
　　普通网民可能对这个漏洞没啥感觉，但对于使用 Exchange 的诸多企业，已经搞得鸡飞狗跳了。

《至少三万家机构由于微软电邮软件（Exchange Server）漏洞被入侵 @ Solidot》

KrebsOnSecurity 援引消息来源报道，至少三万家美国机构——包括大量的小企业和各级政府被黑客组织利用微软电邮软件 Microsoft Exchange Server 的漏洞入侵。
微软本周披露，黑客正在利用 Exchange Server v2013 到 v2019 中的四个 0day 漏洞。在漏洞披露的三天内，安全专家称：同一黑客组织增加了对尚未修补的 Exchange 服务器的攻击，在入侵之后攻击者留下一个可以后续访问的 web shell。微软表示正与美国网络安全和基础设施安全局密切合作，为客户提供最佳的指南和缓解措施。

《微软 Exchange 软件出现漏洞，至少遭10个黑客组织利用 @ 路透社》

路透华盛顿3月10日 - 网路安全公司 ESET 周三在博客贴文中表示，至少有10个不同的黑客组织正利用近期发现的微软邮件服务器软件漏洞来入侵全球各地目标。
漏洞遭到利用的广泛程度，使得美国与欧洲监管者就微软 Exchange 软件漏洞发出的警告更形迫切。
微软这套用户众多的电邮与日程软件的安全漏洞，等于为商业级的网络间谍活动开启大门，使得不怀好意者能够从易于入侵的服务器中任意窃取电邮。路透上周报导，已有数万个公司遭到波及，每天都有新的受害者出现。
虽然微软发布修补措施，但许多客户更新速度缓慢，意味着这方面至少还有部分对各类黑客而言是门户洞开的。专家将更新缓慢部分归因于 Exchange 架构的复杂性。
微软对客户更新速度缓慢不予置评。在先前有关此漏洞的声明中，微软已强调立即修补所有受影响系统的重要性。

◇sudo 的本地提权漏洞

《10-year-old Sudo bug lets Linux users gain root-level access @ ZDNet》

《Recent Root-Giving Sudo Bug Also Impacts macOS @ Slashdot》

《sudo 漏洞让用户能获得 root 权限 @ Solidot》

安全审计公司 Qualys 发现了一个有10年历史的 Sudo 严重漏洞，允许 Linux 用户获得 root 级别的权限。
该漏洞被称为 Baron Samedit，编号 CVE-2021-3156，Sudo 团队已经释出了补丁。该漏洞允许已经获得低权限账号的攻击者获得 root 权限，即使账号没有列入控制账号访问的配置文件 /etc/sudoers 中。

　　编程随想注：
　　这已经是俺第三次谈“sudo 高危漏洞”。
　　最近两年，sudo 出了好几个高危漏洞。俺在《近期安全动态和点评（2020年1季度）》已经警告过大伙儿。以下是俺当时的原话：

3个月前（2020年1月）的那篇《近期安全动态和点评》，俺已经聊过 sudo 的另一个高危漏洞。
在不到半年时间内，sudo 连续爆了两个非常致命的漏洞——对攻击者而言，这2个漏洞很容易利用，而且都能实现【提权】。
这样的苗头挺危险，很可能预示着——sudo 这个软件包内部还有其它一些高危漏洞没被发现。
有鉴于此，你或许要考虑：【不装或卸载】这个软件包。在需要切换用户权限时，改用 su 命令。当然啦，sudo 命令在很多场合比 su 命令更方便。因此，你需要作出一些取舍。

◇Linux 内核本地提权漏洞

《Linux 内核发现3个提权漏洞，已存在15年之久 @ cnBeta》

......
这些漏洞（CVE-2021-27363、CVE-2021-27364 和 CVE-2021-27365）存在于内核的 iSCSI 模块中。虽然在默认情况下该模块是没有被加载的，但是 Linux 内核对模块“按需加载的特性”意味着它可以很容易地被本地触发。安全专家在 Red Hat 所有已测试版本和其他发行版本中发现这些漏洞。
在 GRIMM 博客上，安全研究员 Adam Nichols 表示：“我们在 Linux mainline 内核的一个被遗忘的角落里发现了3个 BUG，这些 BUG 已经有15年的历史了。与我们发现的大多数积满灰尘的东西不同，这些 BUG 依然存在影响，其中一个可以作为本地权限升级（LPE）在多个 Linux 环境中使用”。
......

这些漏洞已经在以下内核版本中得到修复：5.11.4、5.10.21、5.4.103、4.19.179、4.14.224、4.9.260 和 4.4.260。而其他已经停止支持的内核将不会收到本次安全修复。

　　编程随想注：
　　详细的技术分析参见“报告漏洞的 GRIMM 博客”。
　　一般来说，普通用户的 Linux 环境，默认【没】加载 iSCSI 相关的内核模块。此时，如果攻击者要利用这个漏洞，得依赖于【rdma-core】这个软件包，来诱导内核加载 iSCSI 相关模块。也就是说：如果你的 Linux 默认【未】加载 iSCSI 相关的内核模块，也【没】装这个软件包，应该问题不大。
　　这个案例给大伙儿的教训是——
1. 系统中安装的软件包越少越好——安装的软件包越少，系统的攻击面就越小。
2. 系统中安装的驱动（内核模块）越少越好——驱动越少，系统的攻击面就越小。
3. 善于使用虚拟化软件（虚拟机），有助于达成上述两条（相关教程）
3.1 你可以根据自己的使用场景，装多个虚拟机（比如说：一个用来办公，一个用来娱乐...）；如此一来，每个虚拟机装的软件都比较少。
3.2 虚拟机（Guest OS）看不到真实的硬件，当然就省掉了很多硬件驱动。
3.3 物理系统（Host OS）能看到真实的硬件，驱动会有点多；但如果你把日常操作都放到“虚拟机”，有助于保持物理系统的【极简】。

◇Windows Defender 本地提权漏洞

《Windows Defender 漏洞竟存在12年，近期终于得到修复 @ cnBeta》

据外媒报道，Windows Defender 的一个严重漏洞在约12年的时间里都没有被攻击者和防御者发现，直到去年秋天它才被修复。值得一提的是，对于一个主流操作系统的生命周期来说，12年是相当长的一段时间，对于这样一个关键的漏洞来说，其隐藏的时真的是太长了。

　　编程随想注：
　　结合前一个小节（潜伏十五年的 Linux 内核漏洞），大伙儿可以看出——有些漏洞能潜伏十多年。

◇GnuPG 加密库（Libgcrypt）的缓冲区溢出漏洞

《GnuPG 加密库发现严重 bug @ Solidot》

GnuPG（GNU Privacy Guard）主开发警告：使用1.9版本加密库 Libgcrypt 的用户应立即更新。
Libgcrypt 1.9 版本是在1月19日释出的，Google Project Zero 研究员 Tavis Ormandy 在该版本中发现了一个堆缓冲区溢出漏洞，会在解密部分数据时发生溢出。问题与块缓冲区管理代码中的错误假设有关，利用该漏洞非常简单，使用1.9版本的用户需要立即去更新加密库。

　　编程随想注：
　　GnuPG 1.x 采用单一的可执行文件，命令行界面和加密功能都放在一起；从 GnuPG 2.x 开始，改用更加模块化的设计，加密相关的功能单独拆分成一个动态库，也就是 Libgcrypt。
　　这样的设计有一个好处，如果某个第三方软件需要使用 GnuPG 的加密功能，只需要调用 Libgcrypt 这个模块。
　　俺为啥要说这些捏？
　　因为，即使你从来不用 GnuPG，但在你的系统中，可能有某些软件会使用 Libgcrypt 这个库。
　　此漏洞存在 Libgcrypt 的【解密代码】中。因此，攻击者可以精心构造一个 GPG 的加密文件并把攻击代码嵌入其中。然后想办法让目标系统（受害者系统）中的 Libgcrypt 去解密这个文件，解密过程产生缓冲区溢出，有可能触发攻击代码。

◇DNS 转发客户端（Dnsmasq）的漏洞

《Dnsmasq 漏洞让攻击者能发动 DNS 缓存中毒攻击 @ Solidot》

安全专家披露了流行 DNS 转发客户端 Dnsmasq 的7个漏洞，被统称为 DNSpooq 的漏洞允许攻击者发动 DNS 缓存记录中毒攻击。
存在漏洞的 Dnsmasq 软件被数百万设备使用，其中包括思科设备、Android 智能手机、路由器、防火墙、访问点和 VPN 等网络设备。如果攻击者能利用漏洞对企业路由器成功发送缓存中毒攻击，那么他们可以将企业雇员对 Gmail 账号的访问重定向到钓鱼网站。Dnsmasq 项目已经释出了补丁修复漏洞，网络管理员需要尽可能快的给设备打上补丁。

★言论审查 ＆ 网络屏蔽

◇美国在任总统川普的 SNS 帐号被全面封杀

　　编程随想注：
　　1月中旬，川普的各种社交帐号被全面封杀。关于这事儿，列位看官应该都知道，俺就不贴相关的新闻报道链接了。
　　讨论此事之前，先说一下相关的背景知识：

1. 关于“言论自由”的基本概念，参见博文《政治常识扫盲：澄清【言论自由】的各种误区》。
2. 在美国，《宪法第一修正案》是“言论自由”的法律基础。
3. 《宪法第一修正案》是用来限制【政府】的权力，而不是针对私营公司。
4. 因此，几大 IT 巨头封杀川普的帐号，从法律上讲【没】违反《宪法第一修正案》。

　　俺猜到：肯定有读者想问俺的态度。
　　在谈此问题之前，先要抛开“川普”这个人——因为川普的争议很大（有很多川粉，也有很多川黑）。你不要因为自己对川普的态度，而影响对这个问题的判断。
　　了解俺的读者，应该比较清楚俺的态度——

1. 俺一直强调：要警惕各种类型的【政客】（不论是独裁体制里的政客，还是民主体制中的政客）；
2. 俺一直强调：要警惕各种类型的【政府】（不论是独裁政府，还是民主政府）；
3. 俺一直强调：要警惕各种类型的【大公司】（不论是独裁国家的大公司，还是民主国家的大公司）；
4. 对于“大公司”，【IT 行业】的大公司（相比传统行业而言）更危险——因为如今是信息时代，【信息技术】正在成为人类社会的基础设施。虽然 IT 大公司不具备“公权力”，但他们的影响力将非常接近于政府的“公权力”。

　　引申阅读：
　　《人类自由的三大死敌——谈谈“共产运动、纳粹主义、政教合一”的共性》
　　《“对抗专制、捍卫自由”的 N 种技术力量》
　　《每周转载：EFF 创始人约翰·佩里·巴洛和他的【赛博空间独立宣言】》

◇香港警方援引《国安法》，封锁政治网站

《香港当局首次引用＜国安法＞封锁网站，引发全面审查担忧 @ BBC/英国广播公司》

香港多家网络公司据报按当地警方依据香港《国安法》的要求，封锁为用户连结到一个称为“香港编年史”的网站，这个网站载有大量参加处理2019年香港示威期间的部分警察和一些亲建制人士的个人资料，是《国安法》去年生效以来，香港当局首次引用这部法例封锁网站。

目前“香港编年史”的网站已经被多个网络供应商封锁，但网站本身仍然在运作，香港境外的人仍然可以使用网站，香港境内使用虚拟私人网络（VPN）也可以正常使用网站。香港媒体引述当地其中一家主要网络供应商“香港宽频”表示，已经按《国安法》要求停止连线至“香港编年史”网站，其他网络供应商就没有回应传媒查询。
......

除了“香港编年史”，一个称为“香港解密”的网站也刊载了一些民主派人士、示威者和记者的资料。虽然两个都是“起底”网站，“香港解密”至今仍然可以正常运作，令外界质疑香港当局的做法有“双重标准”。
......

　　编程随想注：
　　如今，香港已经是【一国一制】了。“香港编年史”网站被香港警方封杀，只不过再次印证了这点。
　　考虑到本博客也有香港读者，提醒一下：
　　（如果你人在香港）甚至要考虑到更坏的情况——或许有一天，香港网络被纳入【墙内】。
　　从技术上讲，这一点都不难——只需在香港的国际出口部署 GFW 系统。之所以现在还没这么干，应该是基于其它方面（比如经济/金融）的考虑。

◇GFW 封杀 DoH 服务器

《防火墙屏蔽了多个 DoH 服务器 @ Solidot》

DNS-over-HTTPS（DoH）加密了 DNS 请求, 被用于规避 DNS 污染。
根据 greatfire.org 的测试结果：NextDNS、Quad9、AdGuard 在近日被屏蔽。防火墙对这些域名没有使用 DNS 污染, 而是使用检测 SNI 和 IP 黑洞的方法。Cloudflare 的 DoH 服务器还没有被屏蔽。

◇Github 处于“半封锁”状态

　　编程随想注：
　　最近2个月，有不止一位读者在博客留言，反馈说：直接访问 Github，网络传输质量很差（注：如果翻墙访问，就感觉不到）。
　　俺要提醒一下大伙儿：当年 Gmail 是墙内广泛使用的邮件服务。大约10年前，GFW 开始对 Gmail 的 HTTPS 流量进行【随机丢包】（也就是“人为劣化传输质量”）。在这个阶段，网民还是可以打开 Gmail 的 Web 界面，但会感觉网络很不稳定。
　　在之后的几年，GFW 对 Gmail 的干扰（随机丢包）越来越严重。一直到了2014年“六四纪念日”的前几天，GFW 彻底阻断了 Gmail 的 HTTPS 流量。
　　俺猜测：GFW 对付 Github，可能也会是这样。
　　引申阅读：
《每周转载：关于“Gmail 彻底被墙”的网友评论》

◇天朝进一步严控“自媒体”

《中国社交平台要求：公众号提供互联网新闻信息，需获资质 @ 新浪》

微信公众平台、搜狐号、百家号等平台近期相继发布通知，要求公众账号提供互联网新闻信息服务，应取得《互联网新闻信息服务许可证》，如不具备相关资质，不得发布或建议不要发布时政类新闻。
......

《中国突袭查禁大量军事自媒体 @ RFI/法广》

中国网络时政论坛“猫眼看人”在3月底突然关闭后，多个中国军事自媒体近期也陆续被封。不少中国网友感叹言论再趋紧缩，但也有人认为当局是在防止泄密、清除“造爱国谣”。
中国大量军事自媒体被封。据中央社称，此为莫谈国事又一桩。根据社群平台新浪微博的相关讨论，中国当局这波对军事自媒体的清洗可追溯至3月22日。
消息说，中国大型军事论坛“超级大本营”当天下午突然公告，将于3月23日凌晨起永久关闭海军、空军、陆军、航太及新概念武器等4个讨论版，实际上是关闭了军事装备讨论版。随后，“新浪军事”、“军武次位面”等军事类微信公众号近日也因“违规”被关，甚至连微信母公司腾讯旗下的腾讯网军事频道微信公众号“讲武堂”也没能幸免。其中，“军武次位面”迄今未解封。于此同时，中国知名时事政治论坛“猫眼看人”也在3月30日突然关闭。
据该报道，关于这波时政、军事论坛、自媒体被关闭，不少中国网友在微博留言感叹言论越趋紧缩，认为当局有意引导舆论“莫谈国事，只谈风月”等。不过，也有人指出，常有军事迷在军事论坛刊载拍摄到的新型军机或正在建造中的军舰等，且被封锁的军事论坛多是涉及武器讨论，很可能是当局为了防止泄密所致。
此外，也有中国网友列举上述自媒体过去的错误文章指出，这类自媒体常常“造爱国谣”煽动网友情绪，导致“战狼情绪”被境外报导放大，“增大了外事处理的难度，终于被集中治理了一次”。
......

◇政变之后，缅甸军方断网

《用步枪和钢丝钳断网——缅甸积极建设数字防火墙 @ 纽约时报》

《3月15日起，缅甸全国范围内移动通信网络无限期关闭 @ 搜狐》

◇俄国政府开始对付“卫星上网”

《俄罗斯议会考虑：惩罚使用西方卫星宽带的公民 @ Solidot》

俄罗斯国家杜马正在讨论一项立法，阻止国民使用西方的卫星宽带，违反者将会面临罚款。个人用户面临的罚款金额从1万到3万卢布，而企业的罚款金额从50万到100万卢布。
美国公司 SpaceX 和英国公司 OneWeb 都在发射各自的宽带卫星，计划在不久的未来提供高速的卫星宽带服务。但俄罗斯杜马议员认为使用西方卫星宽带将会绕过该国的通信监视系统 System of Operational Search Measures。作为加强对媒体和通信控制的一部分，所有俄罗斯的互联网流量都必须通过一家俄罗斯通信服务商。

★Web ＆ 浏览器

◇Firefox 开始支持 TLS 协议的【ECH 功能】

《Firefox 将用 Encrypted Client Hello 替换 ESNI @ Solidot》

随着越来越多的网站普及 HTTPS，明文的服务器名称指示（Server Name Indication，SNI）成为新的隐私漏洞。通过明文 SNI，ISP 或任何网络中间人将会知道你访问了哪个网站。两年前，Mozilla 宣布 Firefox Nightly 加入了对加密 SNI 的支持（编程随想注：“加密 SNI”称作 ESNI）。
但自 ESNI 规格草案发布以来，分析显示只加密 SNI 扩展所提供的保护是不完整的。举例来说，在会话重用过程中，Pre-Shared Key 扩展会包含 ESNI 加密的服务器名称的明文副本。为了解决 ESNI 的不足之处，较新版本的规格不再只加密 SNI，而是加密整个 Client Hello 信息。因此规格的名字也从 ESNI 改为 ECH。
从 Firefox 85 起，浏览器用 ECH 取代了 ESNI，about:config 也不再展示 ESNI 选项。该功能尚未默认启用，如果用户想要默认启用可以进入 about:config 将设置 network.dns.echconfig.enabled 和 network.dns.use_https_rr_as_altsvc 设为 true。

　　编程随想注：
　　HTTPS 本质上是“HTTP over TLS/SSL”，其中的 TLS/SSL 协议用于加密。为了支持“多个域名共享同一个 IP 地址”，TLS/SSL 引入了 SNI（Server Name Indication）机制。请注意：这个 SNI 机制本身是【明文】滴。
　　如果你访问的网站属于“多域名共享 IP”，那么 ISP 就有可能偷窥 SNI，从而知道你访问了哪个域名（但无法知道你访问的网页内容）。同样的道理，天朝的 GFW 也可以通过监视 SNI，以进行针对性的封锁——通过监视 SNI，一旦发现你访问的是【不和谐】的网站，就把 TLS/SSL 连接阻断。
　　为了解决 SNI 的缺陷，后来 TLS/SSL 协议中引入了 ESNI；但 ESNI 的加密还是不够严谨（如上述文章所说），于是又升级为 ECH（全称是“Encrypted Client Hello ”）。关于这方面的协议细节，俺会在《扫盲 HTTPS 和 SSL/TLS 协议》（系列）的后续博文中介绍。

◇【超级 cookie】的隐私风险，及其防范措施

《Browser 'Favicons' Can Be Used as Undeletable 'Supercookies' To Track You Online @ Slashdot》

　　编程随想注：
　　上述这篇洋文介绍了：如何用 favicon 构造 Supercookies。考虑到很多读者看不懂洋文，俺稍微费点口水解释一下：

　　原理——
　　所谓的【favicon】就是网站的小图标，也就是显示在浏览器标签页上的那个图标（每个网站都不同）。
　　浏览器会在本地维护一个 favicon 的缓存（favicon cache）。当你【第一次】访问某网站，缓存中没有该网站的小图标，浏览器会从该网站抓取，并保存在 favicon cache 中；反之，如果 favicon cache 中已经有对应的小图标，则无需抓取。
　　一般来说，浏览器提供了“清除历史”的功能，可以清除“浏览历史、下载历史、cookie、HTML 缓存、等等”。但【不包括】这个“favicon cache”。也就是说，（在浏览器界面上）【没有】简单的操作可以清除这个缓存。
　　因此，某些网站（比如在线广告商）就可以利用 favicon cache 的这个特点，构造出某种【持久的指纹】。这个指纹的特色在于——不管你是否开启“隐私模式”、不管你是否清除过历史、不管你是否走代理。这个指纹都是唯一不变滴。
　　更详细的技术原理，参见“这个链接”。

　　测试——
　　你的浏览器是否能对抗 Supercookie 捏？可以通过“这个页面”进行测试。
　　顺便说一下：这个测试页面在【禁用 JS】的情况下依然可用。也就是说，Supercookie 使用的技术【无需】依赖 JS 脚本。

　　解决方法——
　　Firefox 从85版本开始，解决了 Supercookie 带来的隐私风险。具体参见 Mozilla 官网的如下文章。
《Firefox 85 Cracks Down on Supercookies @ Mozilla》

　　如果你用的是老版本的 Firefox，或者是其它类型的浏览器，还可以考虑用另外一招——【定期删除】“favicon 缓存”。
　　不同类型的浏览器，“favicon 缓存”的文件位置也不同。对于 Firefox 而言，它位于：实例目录下的 favicons.sqlite 文件。
　　对于使用虚拟机的同学：只要你能确保：当你创建虚拟机快照的时候，浏览器环境是【纯洁】的（所有相关缓存都是【空】的）；那么，当你把虚拟机回退到这个快照，浏览器中的 supercookie 自然就消失了。
　　另外，
　　如果你听从了俺多年来的建议，创建【多个浏览器环境】（多实例 or 多用户 or 多虚拟机）。可以在一定程度上缓解“supercookies 的隐私风险”。因为 supercookies【无法】跨浏览器环境；因此，网站也就【无法】判断出：操作多个浏览器环境的，是同一个自然人。
　　（注：“多浏览器环境”只是“缓解”这个风险，而不是“根治”）

◇Google 想要终结 cookie 技术

《Google 表示它可能找到了 cookies 的隐私友好替代 @ Solidot》

Google 周一宣布它可能找到了 cookies 的隐私友好替代。它测试了名为 Federated Learning of Cohorts（FLoC）的新 API，其源代码发布在 GitHub 上。
测试显示，相比基于 cookies 的广告，FLoC 广告的转化率至少达到 95%。FLoC 使用机器学习算法分析用户数据，然后根据用户访问的网站，将数千用户分成一组。数据是浏览器在本地收集的不会分享出去，但这群用户的数据会共享并被用于定向广告。也就是说 FLoC 广告是根据人们的普遍兴趣进行针对性展示。

　　编程随想注：
　　这个玩意儿到底是不是“隐私友好”？目前俺了解有限，暂时无法从技术角度发表意见。
　　考虑到 Google 的商业模式（主要利润来自于【在线广告收入】），俺不太相信所谓的“隐私友好”。

《Google 淘汰 Cookies 的计划引来反垄断调查 @ Solidot》

Google 在今年初宣布了 Cookies 的替代 Federated Learning of Cohorts (FLoC)，声称它对用户隐私更为友好。但这一计划引发了美国司法部调查人员的关切，调查人员一直在问询广告行业的高管，以了解 Google 此举是否会妨碍规模较小的竞争对手。
消息人士表示，司法部调查人员的询问涉及到 Chrome 的各种政策，包括与 cookies 相关的规定，对于广告和新闻产业产生哪些影响。
Chrome 浏览器的全球市占率约 60%。消息人士并指出，调查人员正询问 Google 是否利用 Chrome 来避免对手广告公司通过 cookies 追踪用户，同时留下漏洞供自己用 cookies、分析工具、以及其他资源来收集资料，从而降低竞争。

◇Firefox 开始禁用 HTTP 协议的【referer 字段】

《Firefox 87 trims HTTP Referrers by default to protect user privacy @ Mozilla》

　　编程随想注：
　　“HTTP referer”会有隐私风险，尤其当你在使用【搜索引擎】时。如下这篇博文的其中一个章节，扫盲了“HTTP referer”相关的知识。
《Startpage——保护隐私的搜索引擎，搜索质量等同 Google》

◇微软开始清理【旧版】Edge

《Windows 10 强制性更新将彻底杀死旧 Edge @ Solidot》

微软将在4月份释出的 Windows 10 例行更新中移除旧的 Edge 浏览器。
微软目前在 Windows 10 上有三种不同的浏览器：旧 Edge，新的基于 Chromium 的 Edge，以及 IE。为了减少混乱和改进安全，微软准备从操作系统移除旧的浏览器。软件巨人公布了杀死 旧 Edge 的计划：2021年4月释出的例行安全更新。
Chromium Edge 将成为微软希望用户唯一使用的浏览器。

◇终于有浏览器支持【IPFS】啦

《Brave 浏览器支持 IPFS 点对点协议 @ Solidot》

由 Mozilla 联合创始人 Brendan Eich 所创公司开发的 Brave 成为首个支持 IPFS 点对点协议的浏览器。
IPFS 代表 InterPlanetary File System，类似 BitTorrent 的点对点协议，设计作为去中心化储存系统，允许用户在数百甚至数千个节点之间共享不受审查的内容。当 Brave 探测到用户试图访问 IPFS 内容或使用原生地址如 ipfs:// 或 ipns://，浏览器会提示用户安装和启用 IPFS 节点，或使用一个 HTTP 网关。

　　编程随想注：
　　IPFS 是基于 P2P 方式的分布式文件系统。你可以通俗地理解为：IPFS 构建了一个【全球性的网盘】，该网盘上的每个文件都会存储在多个不同的节点。上传到该网盘的每个文件都分配了唯一的“磁力链接”（洋文叫“magnet link”，相当于“网址”）。只要拿到某个文件的“磁力链接”，就可以下载到该文件。下载的时候，你无需关心这个文件存储在哪里。
　　IPFS 已经诞生了很多年，可惜推广度依然【不够】。主要原因在于——缺乏重量级的软件支持。如果有足够多的浏览器软件支持 IPFS，那它的前途就很光明。如今，Brave 浏览器迈出了第一步。接下来就看 Chrome 与 Firefox 是否跟进了。
　　俺的网盘分享了《IPFS 白皮书》感兴趣的同学，可以去看看。

◇Google 的 Chromium 团队与 Linux 社区闹僵

《多个 Linux 发行版考虑移除 Chromium 软件包 @ Solidot》

Google Chrome Team 团队向 Linux 发行版开发者发去邮件通知，从3月15日起，在构建配置中使用 google_default_client_id 和 google_default_client_secret 的第三方 Chromium 版本，它们的终端用户将无法再登陆其 Google Accounts 账号。
Google 称，他们在最近的审计中发现部分基于 Chromium 的浏览器使用了原本只给 Google 使用的 Google API 和服务，其中最主要的是同步账号的 Chrome Sync API，它决定移除这些 API 的访问，声称这是为了改进用户数据安全。
Linux 发行版开发者表示过去十年他们一直这么做的，如果无法使用 Google 的同步功能，那么继续维护 Chromium 软件包也没有什么价值了。Chrome 的工程总监 Jochen Eisinger 在回复中表示他们的决定不会改变。Slackware Linux 和 Arch Linux 都表示考虑从仓库移除 Chromium。

★移动设备

◇警方破解手机，比你想象的容易

《How law enforcement gets around your smartphone's encryption @ Ars Technica》

......

When an iPhone has been off and boots up, all the data is in a state Apple calls 【Complete Protection】. The user must unlock the device before anything else can really happen, and the device's privacy protections are very high. You could still be forced to unlock your phone, of course, but existing forensic tools would have a difficult time pulling any readable data off it. Once you've unlocked your phone that first time after reboot, though, a lot of data moves into a different mode—Apple calls it "Protected Until First User Authentication", but researchers often simply call it 【After First Unlock】（注：简称 AFU）.

If you think about it, your phone is almost always in the AFU state. You probably don't restart your smartphone for days or weeks at a time, and most people certainly don't power it down after each use. (For most, that would mean hundreds of times a day.) So how effective is AFU security? That's where the researchers started to have concerns.

The main difference between Complete Protection and AFU relates to how quick and easy it is for applications to access the keys to decrypt data. When data is in the Complete Protection state, the keys to decrypt it are stored deep within the operating system and encrypted themselves. But once you unlock your device the first time after reboot, lots of encryption keys start getting stored in quick access memory, even while the phone is locked. At this point an attacker could find and exploit certain types of security vulnerabilities in iOS to grab encryption keys that are accessible in memory and decrypt big chunks of data from the phone.

......

　　编程随想注：
　　关于“手机的危险性”，本博客已经唠叨过无数次了。俺反复告诫大伙儿（尤其是政治敏感人士），【不要】使用手机进行敏感的活动。
　　上述这篇洋文会告诉你，政府执法机构（警方 or 国安部门）破解手机其实比多数人想象的更容易，不论是 iOS 或 Android，都容易。
　　俺特意摘出上述三段洋文，其大意是：在【开机且解锁过一次】的状态下，即使手机屏幕已锁定，也很容易破解。关键在于，开机第一次解锁之后，全盘加密的【密钥】就会位于【内存】中。此时，“手机取证软件”只要能利用某种系统漏洞 or 软件漏洞，拿到内存中的“全盘加密密钥”，就 OK 啦。
　　作为对比，如果是在【关机】状态下，破解的难度就大得多（但依然有可能破解）。
　　假如你看不懂洋文，可以去看系列教程《TrueCrypt 使用经验》的第3篇——专门谈“加密盘的破解与防范”，其中有介绍【盗取密钥】这招的原理。

◇对比遥测数据——Android VS iOS

《Google 从 Android 设备上收集的遥测数据二十倍于苹果 @ Solidot》

都柏林大学圣三一学院的 Douglas J. Leith 教授跟踪了（PDF）iOS 和 Android 设备向苹果和 Google 服务器发送的遥测数据，发现 Google 收集的数据二十倍于苹果。
Leith 教授称，研究考虑了操作系统本身收集的数据以及操作系统供应商提供的默认应用收集的数据，云端存储，地图/位置服务等，只计算遥测数据。
Leith 教授指出，即使用户选择退出遥测，iOS 和 Android 仍然会发送遥测数据。苹果收集了更多的信息数据类型，但 Google 收集的数据量要多得多。开机10分钟内，Pixel 手机向 Google 发送了 1MB 数据，而 iPhone 发送了 42KB；在闲置状态下，Pixel 手机每12小时向 Google 发送 1MB 数据，相比之下 iPhone 只向苹果发送 52KB 数据。
当新的 SIM 卡插入到设备中，相关信息会立即与苹果和 Google 共享。设备上预装的应用被发现在未启动或使用前就会连接苹果和 Google 服务器。Google 发言人用汽车收集数据为它收集数据辩护。

◇移动设备的木马

《安全公司发现完整间谍软件功能的 Android 恶意程序 @ Solidot》

安全公司 Zimperium 的研究人员发现了包含完整间谍软件功能的先进 Android 恶意程序。恶意程序伪装成系统更新，通过第三方应用商店传播。它的功能包括：
窃取 IM 消息，
窃取 IM 数据库文件（如果可以 root），
检查默认浏览器的书签和搜索，
检查 Google Chrome、 Mozilla Firefox 和 Samsung Internet Browser 的书签和搜索历史，
搜索特定扩展名（.pdf .doc .docx .xls .xlsx）的文件，
检查剪贴板数据，
检查通知内容，
记录音频，
记录电话呼叫，
利用前置或后置摄像头定期拍照，
窃取照片和视频，
跟踪 GPS 位置，
窃取短信，
......

　　编程随想注：
　　分享这篇报道，是想让诸位见识一下手机木马（尤其是功能完善的手机木马）能做到何种程度。

★网络攻击

◇基于【依赖混淆】的供应链攻击

　　编程随想注：
　　这类攻击主要针对【企业】，而且与软件开发相关。不懂编程的读者，可直接跳过本小节。

《揭秘新的供应链攻击，一研究员靠它成功入侵微软、苹果等35家科技公司 @ InfoQ》

最近，一名安全研究员利用一种新颖的软件供应链攻击成功入侵了35家大型科技公司的内部系统，这些公司包括：微软、苹果、PayPal、特斯拉、Uber、Yelp、Shopify、Netflix。在向这些公司提交安全报告后，他获得超过13万美元的奖金。
据悉，此类攻击利用了开源生态系统的一个设计缺陷：依赖关系混乱。攻击者先把恶意软件上传到开源存储库中，比如 PyPI、npm 和 RubyGems，此后它们会自动地分发到下游的公司的内部应用中。
与传统的误植域名攻击（typosquatting attacks）不同，这种特殊的供应链攻击更复杂，并且无需攻击者进行其他操作。
去年，安全研究者 Alex Birsan 在与另一名研究者 Justin Gardner 一起工作时冒出一个想法。当时，Gardner 向 Birsan 分享了一个清单文件（manifest file）package.json，它来自一个 npm 包，而它正被 PayPal 内部所使用。
Birsan 注意到一些清单文件包并没有出现在公共的 npm 存储库，但是，它却代替了 PayPal 创建的私有 npm 包。于是，他产生一个疑问：如果创建一个同名的公开 npm 包，那么软件在构建时，开发人员是优先使用私有的，还是公开的版本？

为测试这一假说，Birsan 开始搜索私有内部包的名称。这些私有的内部的包可以从 GitHub 存储库的清单文件或公司的 CDN 中找到，但却不在公共开源存储库中。
此后，这名研究员开始在开源存储库（比如 npm、PyPI 和 RubyGems）中创建同名的冒牌项目。这些冒牌项目都位于 Birsan 的 GitHub 真实账户下，并且有一个清晰的免责声明，解释“软件包不包含任何有用的代码，只是用于安全研究目的”。
他很快意识到，公开的软件包会比私有的软件包优先度更高。Birsan 还注意到，某些情况下，像 PyPI 包，版本更高的软件包，优先度也更高，无论它是私有的还是公开的。
利用这一方法，他通过发布公司内部在用的同名的公开软件包，实施了一系列成功的供应链攻击，轻松地入侵微软、苹果、PayPal、特斯拉、Uber、Yelp、Shopify、Netflix。
Birsan 说：“与误植域名或品牌劫持不同，依赖关系混乱不需要攻击者进行任何的手工操作。”
......

《最近披露的“依赖混淆供应链攻击”开始大量增加 @ Solidot》

◇针对【安全研究人员】的攻击

《Google 警告针对安全研究员的攻击行动 @ Solidot》

Google 警告，过去几个月，朝鲜黑客组织对安全研究员发动了针对性攻击。
为了建立信誉和联系安全研究员，黑客首先创建了安全博客和 Twitter 账号，与潜在目标进行互动，然后发帖发视频声称完成了某个漏洞利用。Google 表示它没有验证所有漏洞利用的可信度，但至少有一例所谓成功的漏洞利用被指是伪造的。在与目标建立初步联系之后，黑客会询问目标：是否愿意共同研究漏洞，然后提供一个 Visual Studio 项目，其中包含了一个定制的恶意程序 DLL。
除了社会工程攻击外，黑客还成功入侵了访问他们博客的安全研究员的计算机系统。当时受害者的系统打了最新的补丁，Google 表示他们暂时还不知道入侵机制。

　　编程随想注：
　　“安全公司的研究人员”本身是高价值目标，因为他们手头有可能掌握了一些“未公开漏洞”。这类漏洞的价值很高（比“零日漏洞”更值钱），俗称“数字化军火”。
　　有很多安全研究人员擅长“攻击”，但却【不】擅长“防御”。因此，他们会成为其它攻击者的目标（有点像“黑吃黑”）。

◇针对【Android 模拟器】的供应链攻击

《针对手游玩家的供应链攻击 @ Solidot》

安全研究人员发现了针对手游玩家的供应链攻击。未知攻击者入侵了开发 NoxPlayer 的 BigNox，NoxPlayer 被用于在 PC 和 Mac 上模拟 Android 系统，用户主要用它玩 Android 手游。它非常受欢迎，在全世界有1.5亿用户。
攻击者在入侵了 BigNox 的软件分发系统之后对部分用户推送了恶意更新，操纵了两个文件：BigNox 的主二进制程序 Nox.exe 和更新程序 NoxPack.exe。恶意更新是在去年9月推送的，攻击者在去年年底和今年初向特定受害者推送了后续恶意更新。研究人员认为这些恶意程序主要用于监视目标，受害者位于台湾、香港和斯里兰卡。

★新冷战 ＆ 网络战

◇中美科技脱钩

《美国传唤多家中国电信企业，开始撤销两家中企在美经营权 @ RFI/法广》

《美国拜登政府修订供货华为许可证，对可用于 5G 设备的产品实施新限制 @ 路透社》

《比特朗普还要狠，拜登对华为 5G 禁令加码，新的限制条件更严格 @ 网易》

《美国将飞腾/申威等七家中国超算实体列入黑名单，称其协助中国军方 @ 路透社》

◇针对“超微服务器”的供应链攻击

《The Long Hack——How China Exploited a U.S. Tech Supplier @ Bloomberg》

　　编程随想注：
　　早在2018年，彭博社已经报道过类似案例——天朝利用代工的机会，在超微公司（Supermicro）的服务器 BIOS 中植入恶意代码，从而进行供应链攻击。
　　2018年的那篇报道引发了很多争议。今年2月份的这篇报道，是对2018年那篇的补充。全文很长，下面这篇 RFI 的中文报道是其简述。

《彭博社：中国通过科技供应商收集情报，成为全球供应链的广泛风险 @ RFI/法广》

据彭博社（2020年2月）12日的文章介绍：2010年，美国国防部发现旗下数以千计的电脑伺服器将军方网路资料送到中国，后来发现这是因为执行开机程序的晶片中隐藏恶意程式码。2014年，半导体巨头英特尔（Intel）发现中国骇客集团利用一台伺服器入侵英特尔网路，而这台伺服器从一家提供更新的供应商网站下载到恶意软体。2015年，美国联邦调查局警告多家公司，中国特务在一家製造商的伺服器中隐藏了一个另外载有后们程式码的晶片。而这些事件都牵涉两个共同点：中国和设在加州的美超微公司（Supermicro）。此外，美国情报单位都对此知情，但秘而不宣，试图进行反情报工作，以摸清楚中国的底细。
在彭博社文章中，前 FBI 资深官员泰布（Jay Tabb）指出，美超微事件凸显了全球供应链的广泛风险。“完美说明了美国企业若选择在中国制造任何产品，容易受到潜在的恶意窜改。对产品制造地点若无法完整地监督，这是最糟情况的例子。”“中国政府这种行径已有很长一段时间，企业必须明白中国还在这么做。硅谷尤其不能佯装这种情况现在没有发生。”
该报导也指出，美超微或它旗下员工都未被指控任何非法的行为，报导中受访的前美国官员强调，美超微本身不是任何反情报调查的目标。
美超微回应彭博询问时表示，美国政府或公司的客户从未就这些所谓的调查和他们联系。彭博汇集一些迥异和不准确的指控，做出了牵强的结论。美国联邦机构，包括报导中在调查的机构，仍继续採购美超微产品。
中国外交部发言人则表示，文中的指控是对中国的攻击，试图“诋毁中国和中国企业”，并指控美国官员捏造事实炒作“中国威胁论”。

◇“SolarWinds 攻击事件”的后续报道

　　编程随想注：
　　在上一期的《近期安全动态和点评（2020年4季度）》，详细介绍了去年（2020）曝光的“SolarWinds 攻击事件”——号称【史上最严重的供应链攻击】。
　　当时俺分析了：至少有【两波】攻击者。第1波攻击者，俄国佬的嫌疑最大；那么，第2波攻击者会是谁捏？以下是今年1季度的后续报道。目前看来，第2波攻击者很大可能是天朝的御用骇客。

《疑似中国黑客利用 SolarWinds 软件漏洞入侵美国政府 @ Solidot》

在俄罗斯黑客之后，疑似中国黑客去年利用 SolarWinds 公司软件中的缺陷侵入美国政府电脑。知情人士称，FBI 调查人员最近发现，美国农业部内的联邦薪资处理机构国家财务中心是受到此次黑客行动影响的组织之一，这令人担忧成千上万联邦政府雇员的数据可能泄露。这次疑似中国黑客所利用的软件缺陷不同于美国指控的俄罗斯政府特工所利用的软件缺陷。
中国外交部表示，追究网络攻击的来源是一个“复杂的技术问题”，任何指控都应该有证据支持。中国外交部在声明中称，中方坚决反对并打击任何形式的网络攻击和窃密活动。

《研究称：中国黑客也对 SolarWinds 客户发动了攻击 @ Solidot》

安全公司 Secureworks 周一发表报告，除了俄罗斯黑客，中国黑客组织也在同一时间内对 SolarWinds 的客户发动了攻击。
在俄罗斯黑客发动供应链攻击的同时，安全研究人员去年12月披露还有黑客利用了 SolarWinds 公司软件 Orion 的一个漏洞，在该公司客户的网络中安装了名为 Supernova 的 web shell。但当时还不知道是谁发动了攻击。根据其使用的技术、策略和程序，研究人员现在将该黑客组织命名为 Spiral，该组织此前还利用了 ManageEngine ServiceDesk 的漏洞入侵企业网络。

《微软总裁布拉德·史密斯称：SolarWinds 黑客事件是有史以来最大、最复杂的 @ cnBeta》

《NASA and the FAA were also breached by the SolarWinds hackers @ Bleeping Computer》

◇【水厂】成为网络战的目标

《Hacker Increased Chemical Level At Florida City's Water Supply, Police Say @ Slashdot》

《佛罗里达州水处理系统遭黑客攻击，万幸没有居民受到伤害 @ cnBeta》

《坦帕湾时报》报道称，有黑客成功渗透了控制佛罗里达州奥尔德斯马市水处理设施的计算机系统。通过篡改可远程控制的计算机数据，攻击者改变了当地供水中的化学品含量（上调了氢氧化钠碱液的水平）。庆幸的是，设施管理者和警方均表示，目前暂无居民受到伤害的报告。
......

即便如此，意图不明的攻击者将黑手伸向公共基础设施一事，还是引发了许多居民的恐慌情绪。目前当地正在与联邦调查局（FBI）和特勤局（Secret Service）联手展开调查，附近城镇也受到有关潜在威胁的警报。
需要指出的是，佛罗里达州奥尔德斯马市（Oldsmar）发生的事件并非孤例。去年11月的时候，伊利诺伊州的一家水务公司也被疑似与俄方有关的攻击者给盯上。
此外，据《华盛顿邮报》报道，以色列情报官员声称：去年发生了一起未遂的网络攻击事件，指责伊朗方面试图对该国的水处理设施展开攻击。
......

　　编程随想注：
　　在《近期安全动态和点评（2019年3季度）》中已经提到：【供电系统 ＆ 供水系统】将会成为网络战的目标。如今应验了。

★操作系统

◇注重安全及隐私——Linux 发行版的选型

《Best Secure Linux Distros for Enhanced Privacy ＆ Security @ Linux Security》

　　编程随想注：
　　这篇洋文推荐了六款强化安全和隐私的 Linux 发行版。对于 Linux 用户而言，不同的人有不同的技能水平、使用场景、操作习惯。很难给出某种普适的排名。因此，上述这篇文章也仅仅是作为某种参考。
　　全文很长，俺只摘录一部分（如下）

Qubes OS
Why We Love Qubes OS:

• Its "Security by Isolation" approach using containers - aka "Qubes" - eliminates the concern of compromised programs.
• All of these Qubes are integrated into one common desktop environment and color-coded to help users stay organized.
• Sandboxing protects system components.
• Qubes OS offers full-disk encryption for maximum file protection.

Tails
Why We Love Tails:

• Its tight integration with the Tor network ensures anonymity online.
• The included web browser is pre-configured for maximum security and includes add-ons like NoScript, Ublock Origin, and HTTPS Everywhere.
• Users get access to Onion Circuits, a valuable tool that allows them to view how their PC traverses through the Tor network.
• Tails comes with the Aircrack-NG wireless network auditing tool.
• The OS is encrypted and designed to run with full functionality on a USB drive.
• The distro features a built-in Bitcoin wallet ideal for users looking to make secure cryptocurrency transactions.

Kali Linux
Why We Love Kali Linux:

• Kali Linux uses LUKS full-disk encryption to protect sensitive pentesting data from loss, tampering and theft.
• This flexible distro offers full customization with live-build.
• Users can automate and customize their Kali Linux installations over the network.
• "Forensics" mode makes this distro perfect for forensics work.
• There's a Kaili Linux training suite available called Kali Linux Dojo, where users can learn how to customize their own Kali ISO and learn the basics of pentesting. All of these resources are available on Kali's website, free of charge. Kali Linux also boasts a paid-for pentesting course that can be taken online, with a 24-hour certification exam. Once you pass this exam, you're a qualified pentester!

Parrot OS
Why We Love Parrot OS:

• The distro provides pentesters and digital forensics experts with the best of both worlds - a state-of-the-art "laboratory" with a full suite of tools accompanied by standard privacy and security features.
• Applications that run on Parrot OS are fully sandboxed and protected.
• Parrot OS is fast, lightweight and compatible with most devices.

BlackArch Linux
Why We Love BlackArch Linux:

• BlackArch Linux offers a large selection of hacking tools and preconfigured Window Managers.
• The distro provides an installer with the ability to build from source.
• Users can install tools either individually or in groups with the modular package feature.

Whonix
Why We Love Whonix:

• Whonix comes with the Tor Browser and the Tox privacy instant messenger application - ensuring fully-anonymous web browsing and instant messaging.
• The OS employs an innovative Host/Guest design to conceal users' identity behind the anonymous proxy and prevent IP and DNS leaks.
• The distro features pre-setup Mozilla Thunderbird PGP email.
• Linux Kernel Runtime Guard (LKRG), a kernel module that performs runtime integrity checking of the Linux kernel to detect security vulnerabilities and exploits, can be easily installed on Whonix.

◇华为的鸿蒙——连哄带蒙

《Ars 尝试华为的鸿蒙操作系统 @ Solidot》

中国最大智能手机制造商华为在遭到美国的出口禁令之后宣布了自己的操作系统鸿蒙，去年12月释出了 V2 版本。华为消费者业务 CEO 余承东宣称：鸿蒙是与 Android 和 iOS 完全不同的操作系统。华为消费者业务软件部总裁王成录上个月再次表示，鸿蒙不是 Android 或 iOS 的拷贝。
美国科技网站 Ars 对华为鸿蒙进行了一番测试，记者首先试着下载 Harmony SDK，结果迎面一击：他被告知需要接受两天的背景检查，要求注册账号通过身份验证，包括递交名字、地址、电邮、电话号码和护照照片。即使你试图绕过注册流程，下载“盗版”的版本，SDK 也需要你登陆账号之后才会运行。
出于研究的目的，记者牺牲了自己的隐私，下载了 SDK，开始进行测试。他发现模拟手机使用的是中国 SIM 卡，进入的网络叫“华为内网”。进一步研究发现，Harmony 的应用页面基本上全是类似 Android Services Library、Android Shared Librar 之类的，以及指示 Android 10 的信息。
作者认为现阶段的 Harmony 本质上就是换了皮肤的 Android，华为甚至连 Android 的名字都没有替换掉。作者还阅读了 Harmony 的文档，认为这些文档都是胡扯，没有多少意义。

　　编程随想注：
　　“鸿蒙系统”被调侃为【连哄带蒙】，果然名不虚传 :)
　　不过这篇报道已经不新鲜了。去年9月底，俺发了如下这篇博文，作为“国庆献礼”。在这个排行榜上就有“鸿蒙系统”。
《二十年目睹之怪现状——中国学术界、科技界的“奇葩排行榜”》

《华为高管声称：鸿蒙 V3 将不再基于 Android @ Solidot》

华为消费者业务软件部总裁王成录今年初曾表示，鸿蒙不是 Android 或 iOS 的拷贝。但对鸿蒙 V2 的分析表明，它事实上是 Android 的拷贝，华为甚至连 Android 的名字都没有从系统中替换掉。
对此王成录在接受采访时回应称：“并不是所有 Android 代码都是 Google 开发的，绝大部分代码来自开源社区。鸿蒙也会吸收社区的优秀技术和代码，用了 AOSP（Android 开源项目）的开源代码，就判断鸿蒙是 Android 换了皮，说明这类吐槽者没有太准确理解什么是开源。今年10月，鸿蒙第三阶段的开源代码会上线，来自 AOSP 社区的、由 Google 贡献的代码几乎没有了。”

　　编程随想注：
　　华为高管的辩解，属于“偷换概念”（稻草人谬误）。
　　之前网民指责“鸿蒙是安卓换皮”，因为鸿蒙大量使用了 AOSP（Android Open Source Project）的代码。在【源代码】层面，“鸿蒙系统”与“安卓系统”实在太相似了。
　　华为高管的忽悠在于——先把命题“鸿蒙使用安卓（AOSP）的代码”偷偷替换为“鸿蒙使用谷歌（Google）的代码”。然后再针对后一个命题进行反驳。这就是典型的【稻草人谬误】。
　　华为高管采用这种诡辨式的逻辑把戏，反而让人觉得：他们心虚。

★硬件 ＆ 物理安全

◇物联网 ＆ 法拉第笼

《不请自来的物联网时代 @ Solidot》

不管你需不需要，几乎所有家电都能联网的时代正在我们走来。没有冠以“智能”的电视机早就销声匿迹，而大部分所谓的智能电视机还有广告，部分品牌则将没有开屏广告作为卖点。配备了摄像头和麦克风的智能电视容易遭到滥用已是众所周知，它们会将收集的信息发送到厂商的服务器，你根本不知道它们收集了哪些信息。
好消息是，大部分物联网设备使用的是 Wifi 连接，我们至少还可以通过路由器控制它们的行为。但厂商也有应变之道：直接嵌入蜂窝调制解调器和 SIM 卡，解决不在线的问题。这种现象将会越来越多，它们将会完全脱离用户的有限控制。除了将它们关在【法拉第笼】内，消费者将无能为力。
隐私、监视、跟踪将会无处不在，这就是不请自来的物联网时代。

　　编程随想注：
　　上述文章中提到的【法拉第笼】，洋文叫做“Faraday cage”。是用导体（通常是金属）做成的笼子或网袋。它利用物理学的【静电屏蔽原理】，使得电子设备无法与外界通讯。

（用柔性金属面料制成的法拉第笼）
　　顺便说一下：
　　专业的警方取证人员，都会随身携带这个玩意儿。当他们收缴了你的手机，直接丢入“法拉第笼”——使得你再也无法远程操控手机（自然也就无法“远程刷机”）。
　　有些同学可能会问：如果要防止手机的主人远程操控，为啥警方在收缴了手机之后，不使用“关机 or 拔电池”这2招捏？
　　俺的回答是：
　　每个想问此问题的读者，都属于“看博文太粗心”。在前面“移动设备”的那个章节中，俺已经解释了：手机在【开机】的状态下，更容易破解。

◇Meltdown ＆ Spectre

《First Fully Weaponized Spectre Exploit Discovered Online @ Slashdot》

　　编程随想注：
　　关于 Meltdown ＆ Spectre 漏洞，去年和前年的《近期安全动态和点评》都有聊过。
　　在今年（2021）之前，对这俩漏洞还停留在“理论”阶段；到了今年2月份，在线查毒引擎 VirusTotal 首次发现与这两个漏洞相关的攻击代码，分别针对 Windows ＆ Linux。这也就意味着：对这两个漏洞的研究，已经从“理论”上升到“实践”。
　　这两个漏洞源于 CPU 硬件的设计缺陷，很难根治；而且受影响的 CPU 很多，波及面从 x86 系列到 ARM 系列。
　　俺在《近期安全动态和点评（2019年1季度）》提到如下这段话：

一年前（2018年初）曝光的 Spectre 和 Meltdown 在信息安全界可以称得上是【划时代】滴！因为其利用的是 CPU 的【设计缺陷】（而且还是【根本性】缺陷）。
......
由于这两个漏洞涉及到 CPU 的【根本性】缺陷，极难搞定（就像两个幽灵，会在未来几年不断困扰 IT 行业）。

《A Spectre proof-of-concept for a Spectre-proof web @ Google 安全博客》

《Google 演示 Spectre 概念验证攻击 @ Solidot》

Google 演示了实用的 Spectre 概念验证攻击，代码发布在 GitHub 上，演示发布在网站 leaky.page 上。
2018年1月，Google Project Zero 和奥地利格拉茨技术大学的研究人员披露了与预测执行相关的处理器漏洞 Spectre，利用基于时间的旁路攻击，允许恶意进程获得其他程序在内存中的数据。Google 的概念验证攻击针对的是运行在 Linux 系统上的 Chrome 88 的 V8 JS 引擎，使用的 CPU 是英特尔的 Core i7-6500U Skylake。Google 表示，可以进行微调，让攻击能工作在不同的 CPU、浏览器版本和操作系统上，包括苹果的 M1 ARM CPU。概念验证攻击能以 1kB/s 的速度泄露数据。Google 称，虽然浏览器开发商已经实现了网站隔离等缓解措施，但这并不能阻止 Spectre 的漏洞利用，只是防止保存在内存中的敏感数据被攻击者读取。预防 Spectre 攻击还需要 Web 开发者部署应用程序级别的缓解措施。

◇新的 CPU 攻击手法——Lord of the Ring(s)

《英特尔新侧信道攻击——Lord of the Ring(s) @ Solidot》

伊利诺伊香槟的三位研究人员在预印本网站 arXiv 发表论文，披露了针对英特尔 CPU 的最新侧信道攻击，该攻击被命名为 Lord of the Ring(s)。
随着芯片上的功能模块越来越多，英特尔为其 CPU 引入了片内总线，以实现各个模块之间的高速通信，它先后引入了 Ring Bus 和 Mesh Bus。最新侧信道攻击针对的就是 Ring Bus 的环形总线。研究人员首先逆向工程了 Ring Bus 的通信协议，设法构建了一个跨核心的隐蔽信道，利用环争用的细粒度时态模式去推动应用程序的秘密。从有漏洞的 EdDSA 和 RSA 实现中提取出密钥比特。对于 AMD 的 Zen 架构使用的片内总线 Infinity Fabric，研究人员表示需要进一步的研究，但相信他们的技术能应用于其它平台。

◇家用监控探头，反而坑了自己

《安装家庭监控探头的技工承认，偷窥客户做爱 @ Solidot》

家庭和小型办公安保公司 ADT 的雇员 Telesforo Aviles 承认在五年时间里超过9,600次未经许可访问了200名客户的家庭监控探头。
Aviles 称：如果客户家中有吸引力的女性，他会在安装时将自己的邮件地址加入到可访问客户 ADT Pulse 账号的名单中，之后会浏览探头观看性方面的活动。他称会在客户做爱时观看裸女。他承认了一项计算机欺诈罪名，一项侵入性可视化记录罪名，面临最高5年徒刑。

★安全编程

◇Google 开始拥抱 Rust

　　编程随想注：
　　在上一期的《近期安全动态和点评（2020年4季度）》，俺还在吐槽：云计算三大巨头中，只有 Google 对 Rust 的热情不高。
　　没想到才过了一个季度，Google 的态度就有了明显变化。具体请看如下几篇报道。

《Google 宣布它正致力于用 Rust 重实现关键安全软件 @ Solidot》

Google Security Blog 宣布：它正致力于用 Rust 语言重新实现关键安全软件组件。Google 称，内存安全相关的漏洞在安全领域一直占主要位置。
微软的研究显示，通过安全更新修复的漏洞七成是内存安全问题。对 curl 安全问题的分析显示，95个 bug 中的53个可以通过使用内存安全语言防止。
Google 正与 Internet Security Research Group 合作用 Rust 语言重新实现安全组件，包括用 Rust 为 curl 开发 HTTP 和 TLS 后端，为 Apache httpd 项目开发 TLS 库。

《Rust in the Android platform @ Google 安全博客》

《Android 加入了对 Rust 语言的支持 @ Solidot》

Google 官方安全博客宣布：Android 加入了对 Rust 语言的支持。Google 称，七成的 Android 高危漏洞与内存相关，而内存安全语言是解决这一问题的最有效方法。Google 宣布 Android Open Source Project（AOSP）现在支持用 Rust 语言开发操作系统。
Java 和 Kotlin 是开发 Android 应用的最佳选择，但 Java 和 Kotlin 无法用于开发操作系统底层。操作系统的底层需要用系统级编程语言 C、C++ 和 Rust 来开发。对 C 和 C++ 来说，开发者负责管理内存，但管理内存时因代码库的复杂性开发者很容易犯错。Rust 语言利用编译时检查和运行时检查确保内存安全，同时它还提供了比拟 C 和 C++ 语言的性能。
Google 称：用 Rust 重写数千万行 C/C++ 代码是不可行的。对内存相关 bug 的分析显示，大部分 bug 都是近一两年内引入的，因此 Rust 将主要用于新的开发而不是重写成熟的 C/C++ 代码。

《Google 资助用 Rust 语言，为 Apache HTTP 开发安全模块 mod_tls @ Solidot》

Google 资助了 Internet Security Research Group（ISRG）的一个项目：用 Rust 语言为 Apache HTTP web server 项目开发安全模块 mod_tls。
在 Apache web server 中，mod_ssl 用于支持建立 HTTPS 连接所需的加密操作，它是用 C 语言开发的。
新的 mod_tls 模块将使用 Rust 语言开发，领导该项目开发的是软件咨询公司 Greenbytes 的创始人和 Apache HTTP Server 开发者 Stefan Eissing。ISRG 希望，在完成开发之后 Apache HTTP web server 团队将采用 mod_tls 作为默认模块，取代年代悠久且不安全的 mod_ssl。

◇Linux 内核正逐步支持 Rust

《对 Rust 的初步支持登录 Linux-Next @ 开源中国》

近日，Linux 邮件列表中的 Rust-for-linux 上公布了 Rust 支持登陆 Linux-Next 的消息。
Rust 是一个注重安全和性能的语言，并且在今年初成立了新的 Rust 基金会以支持其发展。而在 Linux 内核开发者中，关于使用 Rust 来编写新的设备驱动程序的讨论已经持续了很长时间。本周，对于 Rust 的初步支持终于登陆 Linux-Next 分支。虽然目前还没有一个完整的 Rust 内核驱动，但已经可以在 Linux-Next 分支上看到关于 Rust 的文档、Rust 代码目录和一个用 Rust 实现的字符驱动程序例子。
这种支持需要系统上存在 Rust 编译器（rustc），因此，当前重点关注的体系结构应该是 ARM64 和 x86_64。此外，内核支持也需要一个最新的构建 Rust 的工具链。
虽然 Rust 支持现在已经登录 Linux-Next 分支，但尚不清楚何时并入主线。一般来说，Linux-Next 中的工作会一直持续到下一个周期，但如果其仍是一个正在进行中的工作，也有可能在 Linux-Next 中停留更长时间。

俺博客上，和本文相关的帖子（需翻墙）：
《计算机网络通讯的【系统性】扫盲——从“基本概念”到“OSI 模型”》
《如何防止黑客入侵》（系列）
《如何保护隐私》（系列）
《扫盲操作系统虚拟机》（系列）
《TrueCrypt 使用经验》（系列）
《Startpage——保护隐私的搜索引擎，搜索质量等同 Google》
《扫盲 Firefox 定制——从“user.js”到“omni.ja”》
《扫盲 HTTPS 和 SSL/TLS 协议》（系列）
《“对抗专制、捍卫自由”的 N 种技术力量》
《近期安全动态和点评（2020年4季度）》
《近期安全动态和点评（2020年1季度）》
《近期安全动态和点评（2019年3季度）》
《近期安全动态和点评（2019年2季度）》

　　近期老是在写政治博文，又有两个月左右没写技术博文了。某些技术型的读者，背地里肯定骂俺太懒。今天搞了一篇内容特别长，信息量特别多的。喜欢看技术博文的读者，可以慢慢消化。

★本文的目标读者

　　今天这篇的标题是“扫盲”，也就是说：即使那些完全不懂 IT 领域，也不懂通讯领域的读者，依然能看懂（至少能看懂一部分）。为了做到这点，俺会尽量使用通俗的比喻，并适当加一些示意图。
　　另外，就算你已经比较了解网络通讯领域，本文中提到的某些部分，也可能是你所不知道的。也就是说：懂行的同学，看看此文，也会有帮助。
　　本文的标题特地强调了【系统性】——俺希望这篇教程能帮助读者对“计算机网络”这个领域进行系统性学习（何为“系统性学习”？请看这篇教程）
　　为了做到【系统性】这个目的，这篇教程很长。俺开博12年，这篇的长度估计能排到前5名。建议大伙儿慢慢看，不要着急。

★基本概念

　　为了足够通俗，俺先要介绍一些基本概念。

◇信道（channel）

　　这是通讯领域非常基本的概念，肯定要先聊聊它。
　　通俗地说，信道就是“传送信息的通道”。

◇信道的类型

　　首先，信道可以从广义上分为“物理信道 ＆ 逻辑信道”。
　　顾名思义，“物理信道”就是直接使用某种【物理介质】来传送信息；至于“逻辑信道”——是基于“物理信道”之上抽象出来的玩意儿（待会儿讲到“协议栈”的时候再聊）。

◇信道的带宽

　　“带宽”指的是：某个信道在单位时间内最大能传输多少比特的信息。
　　请注意：
　　电气领域 ＆ 计算机领域都有“带宽”这个概念，但两者的定义不太一样。电气领域所说的“带宽”指的是“模拟带宽”，单位是“赫兹/Hz”；计算机领域所说的“带宽”指“数字带宽”，单位是“比特率”或“字节率”。
　　后续章节提到“带宽”，都是指计算机领域的术语。

◇带宽的单位——容易把外行绕晕

　　“比特率”或“字节率”很容易搞混淆。用英文表示的话——大写字母 B 表示【字节】；小写字母 b 表示【比特】。

　　由于带宽的数字通常很大，要引入“K、M、G”之类的字母表示数量级，于是又引出一个很扯蛋的差异——“10进制”与“2进制”的差异。
　　【10进制】的 K 表示 1000；M 表示 1000x1000（1百万）
　　【2进制】的 K 表示 1024（2的10次方）；M 表示 1024x1024（2的20次方）
　　为了避免扯皮，后来国际上约定了一个规矩：对【2进制】的数量级要加一个小写字母 i。比如说：Ki 表示 1024；Mi 表示 1024x1024 ...... 以此类推。
　　举例：
　　1Kbps 表示“1000比特每秒”
　　1KiBps 表示“1024字节每秒”

◇信道的工作模式：单工 VS 半双工 VS 全双工

　　再来说说信道的工作模式。大致可以分为如下三种。为了让大伙儿比较好理解，俺对每一种都举相应的例子。

　　单工（simplex）
　　比如“电台广播”就是典型的【单工】。“电台”可以发信号给“收音机”，但“收音机”【不能】发信号给“电台”。

　　半双工（half-duplex）
　　比如“单条铁路轨道”，就是典型的【半双工】。火车在单条铁轨上，可以有两种运行方向；但对于同一个瞬间，只能选其中一个方向（否则就撞车了）。

　　全双工（full-duplex）
　　比如“光纤”就是典型的【全双工】。在同一根光导纤维中，可以有多个光束【同时相向】传播，互相不会干扰对方。

◇端点

　　为了叙述方便，俺把参与通讯的对象（主体）称作“通讯端点”，简称“端点”。
　　这里的“端点”是广义的，可以是硬件（比如某个网卡），也可以是软件（比如某个应用程序）。

◇单播、组播/多播、广播、选播

　　对于“网络通讯”，至少得有 N 个端点参与，并且【N ≥ 2】才有意义。
　　当 N 个端点构成一个网络，这时候就会涉及到“单播、组播、广播”这几个概念。
　　通俗地说：
单播（unicast）——发送给网络中的指定的【单个】端点
组播/多播（multicast）——发送给网络中的指定的【多个】端点
广播（broadcast）——发送给网络中的【所有】端点
选播（anycast）——发送给网络中随机选择的【单个】端点

◇通讯协议（protocol）

　　所谓的“通讯协议”就是：参与通讯的各方所采用的某种【约定】。只有大家都遵守这个约定，才有可能相互传递信息。
　　打个比方：如果两个人要用自然语言交流，前提是：双方使用相同（或相互兼容）的自然语言。
　　“通讯协议”就类似某种自然语言，参与通讯的多个端点，都必须能理解这个语言。

★从“分层”到“参考模型”

◇分层

　　在聊“分层”之前，先说说“分工”。比如在一个公司中，通常设有不同的工种/岗位，这就【分工】。
　　对于网络通讯也是如此，不太可能用一种通讯协议完成所有的信息传递任务（注：对于特别简单的网络，或许有可能只用单一协议；但如今的网络通讯已经很复杂，用【单个】通讯协议包办所有事情，已经不太可能）
　　一旦采用了多种通讯协议，这几种协议之间，该如何配合捏？
　　在网络通讯领域，采用的是【分层】的设计思路。多个层次的协议在一起协同工作，技术上称作“协议栈”（洋文叫做“protocol stack”）。

◇协议栈的原理

　　对于多层次的协议栈。每个层次都有各自的“端点”（进行通讯的主体）。处于【同一层次】的两个端点会使用该层次的协议进行通讯（注：同一个层次的协议，可能只有一个，也可能有多个）。
　　除了最顶层，每个层次的端点会向其【直接】上层提供“服务”；除了最底层，每个层次的端点会调用【直接】下层提供的“服务”（这里所说的“服务”指某种“编程接口”，技术行话叫 API）。


（“协议栈”的示意图）

（“服务”与“协议”之间的关系）

◇逻辑信道

　　（前一个小节说了）每个层次会向上一个层次提供服务（API 调用）。对上层而言，调用下层提供的 API 发送信息，其效果相当于在使用某种【信道】进行通讯，这也就是俺在 ★基本概念 那个章节所说的“逻辑信道”。


（“逻辑信道”示意图）

◇数据格式的原理

　　大部分协议会把要传送的数据切割为 N 份，每一份就是一个数据包。
　　通常来说，数据包的格式有如下三部分：

头部
身体（也称作“有效载荷”）
尾部（注：很多协议没有尾部）

　　如果你收过快递，可以把“网络数据包”与“快递包裹”作一个对照——
数据包的“头/尾”，就类似于快递包裹的【包装袋】。数据包的“身体”，就类似于快递包裹里面的东西。

　　对于【相邻】两层的协议，【下】层包含【上】层。也就是说：下层协议的【载荷】就是上层协议的【整体】。
　　还是以快递举例：
　　假设你从网上买了一台笔记本电脑。电脑出厂时，电脑厂商肯定会提供一个包装盒。快递公司在寄送这台笔记本的时候，又会在笔记本的盒子外面再加一个包装袋。对应到网络协议——“快递公司的包装袋”相当于【下层】协议；“电脑厂商的包装盒”，相当于【上层】协议。


（上下层协议的格式及包含关系）

◇网络分层的参考模型

　　上述所说的“分层 ＆ 协议栈”只是一个抽象的（笼统的）思路。具体要分几层？每一层要干啥事儿？这些都是很有讲究滴！网络技术发展了几十年，已经有很多牛人提出了各种不同的划分方案，称之为“网络分层的参考模型”（为了打字省力，以下简称“模型”）。
　　在各种模型中，名气最大的当然是“OSI 模型”（洋文称作“OSI model”）。在后续的章节中，俺会以这个模型为主体，进行介绍。
　　除了“OSI 模型”还有一个很出名的模型是“TCP/IP 模型”（因为互联网很成功，它才跟着出名）。
　　对“TCP/IP 模型”的分层，不同的文章或书籍，说法不太一样（“3层、4层、5层”皆有），这就引发了一些争议。包括几位热心读者也在博客留言，表达不同意见。为了避免一家之言，贴出维基百科的“这个链接”，其中给出了几种比较有名的说法。
　　另外，俺想提醒一下：
　　由于本文是基于【OSI 模型】进行展开。对于 TCP/IP 模型到底算几层，这方面的争论【不】影响本文后续的内容。

★OSI 概述

◇OSI 的历史

　　“OSI”的全称是“Open System Interconnection”。先说说它的历史。
　　上世纪70年代，“国际电信联盟”（ITU）想对各国的电信系统（电话/电报）建立标准化的规格；与此同时，“国际标准化组织”（ISO）想要建立某种统一的标准，使得不同公司制造的大型主机可以相互联网。
　　后来，这两个国际组织意识到：“电信系统互联”与“电脑主机互联”的性质差不多。于是 ISO 与 ITU 就决定合作，两家一起干。这2个组织的2套班子，从上世纪70年代开始搞，搞来搞去，搞了很多年，一直到1984年才终于正式发布 OSI 标准。

◇OSI 标准的两个组成部分

　　严格来讲，OSI 包括两大部分——
其一，抽象的概念模型，也就是前面提到的【OSI model】；
其二，针对这个概念模型的具体实现（具体的通讯协议），洋文叫做【OSI protocols】。

　　（前面说了）OSI 是由 ISO ＆ ITU 联手搞出来滴。这两个国际组织里面的人，要么是来自各国的电信部门，要么是来自各国的高校学者。总而言之，既有严重的官僚风气，又有明显的学究风气。（正是因为这两种风气叠加，所以搞了很多年，才搞出 OSI）
　　OSI 的协议实现（OSI protocols），不客气地说，就是一堆垃圾——据说把 OSI protocols 所有的协议文档，全部打印成 A4 纸，摞起来得有一米多高！是不是很吓人？协议搞得如此复杂，严重违背了 IT 设计领域的 KISS 原则。
　　由于 OSI protocols 实在太复杂，后来基本没人用。但 OSI model 反而广为流传，并且成为“网络分层模型”中名气最大，影响力最广的一个。
　　因此，本文后续章节中，凡是提到 OSI，指的是【OSI model】。

◇OSI 模型的7层

　　OSI 模型总共分7层，示意图参见如下表格：

层次	中文名	洋文名
第7层	应用层	Application Layer
第6层	表示层	Presentation Layer
第5层	会话层	Session Layer
第4层	传输层	Transport Layer
第3层	网络层	Network Layer
第2层	数据链路层	Data Link Layer
第1层	物理层	Physical Layer

（注：为了打字省力，在后续章节把“数据链路层”直接称为“链路层”）
　　考虑到本文是针对一般性读者的【扫盲教程】，俺重点聊第1~4层。搞明白这几个层次之后，有助于你更好地理解网络的很多概念，也有助于你更好地理解很多信息安全的概念。
　　网上已经有很多关于 OSI 的文章，可惜大部分写得粗糙——很多文章只是在照抄定义。
　　俺曾经写过一篇《学习技术的三部曲：WHAT、HOW、WHY》，其中提到【理解技术】的不同层次。要想更好地理解 OSI 模型，你得搞明白：为啥需要引入某某层？（请注意：这是一个 WHY 型的问题）
　　接下来在讨论 OSI 的每个层次时，俺都会专门写一个小节，谈该层次的【必要性】。搞明白【必要性】，你就知道为啥要引入这个层次。

★物理层：概述

◇物理层的必要性

　　通俗地说：直接与物理介质打交道的层次，就是物理层。这一层的必要性比较明显。
　　因为所有的通讯，归根结底都要依赖于【物理介质】。与物理介质打交道，需要牵涉到很多与【物理学】相关的东东。比如：“无线电通讯”需要关心“频率/波长”；电缆通讯需要跟“电压”打交道；“光纤通讯”需要关心“玻璃的折射率＆光线的入射角” ......
　　“物理层”的主要职责是：屏蔽这些细节，使得“物理层”之上的层次不用再去操心物理学。

◇物理信道的类型

　　何为“物理信道”，在本文开篇的“基本概念”已经提到了。
　　对于“物理信道”，还可以进一步细分为如下三大类：
1. 有线信道（比如：双绞线、同轴电缆、光纤、等等）
2. 无线信道（比如：微波通讯、电台广播、卫星通讯、等等）
3. 存储信道

　　“存储信道”比较少见，很多人没听说过，稍微解释一下。
　　假设你要把一大坨信息传送给另一个人，除了用“有线 or 无线”这两种通讯方式，还可以把信息先保存到某种【存储介质】（比如硬盘），然后再把存储介质用某种方式（比如快递）转交给对方。这就是所谓的“存储信道”。

◇信噪比（Signal-to-noise ratio）

　　俺在很多篇关于“学习＆心理学”的博文中提到过【信噪比】这个概念。其实这个概念是从通讯领域借用的术语。
　　对于“物理信道”，总是会存在某些环境干扰，称之为“噪声”（Noise）。“信道传输的有用信息”与“无用的干扰噪声”，这两者的比值就是“信噪比”。
　　“信噪比”单位是【分贝】。“分贝”洋文叫做“decibel”（简写为 dB）。“deci”表示“十进制”；“bel”是为了纪念大名鼎鼎的贝尔（电话它爹）。

◇带宽的限制因素

　　“物理信道”要依赖于物理传输介质。不管使用何种物理介质，都要受限于某些基本的物理学定律（比如“光速上限”）。另外，不管何种物理介质，总是会有或多或少的环境干扰（噪声）。这两个因素导致了：任何“物理信道”的最大传输率总是有限滴。
　　由于物理层是最底下的一层，物理层之上的其它层次总是要直接或间接地依赖【物理信道】。因此，其它层次建立的“逻辑信道”，其带宽只会比“物理信道”的最大带宽更小。换句话说：“物理信道”的带宽上限也就是整个协议栈的带宽上限。

◇多路复用（Multiplexing）

　　一般来说，凡是能实现【长距离】通讯的“物理信道”，都有相当的经济成本。比如铺设“光纤、同轴电缆”都要花钱。无线电通讯虽然免去了铺设线路的成本，但需要竞标购买频段。因此，物理信道非常强调“多路复用”。
　　所谓的“多路复用”，通俗地说就是：尽可能地共享物理信道，不要浪费了。
　　“多路复用”有很多种类型；不同的类型，原理也不同。为了展示各种不同的原理，俺拿【无线通信】来说事儿。
　　无线通信领域的“多路复用”，【至少】有如下几种：

　　频分多路复用/FDM（Frequency-Division Multiplexing）
　　这个最简单，就是根据频率拆分。不同的线路占用不同的频段，互不干扰。（电台广播用的就是这个思路）
　　但这个思路的缺点很明显——
其一，要依赖足够宽的频段（频段是稀缺资源）；
其二，不同线路的流量可能会动态变化。如果某个线路空闲，其占用的频段就浪费了。
　　（注：光纤通讯中有个“波分多路复用/WDM”，本质上就是 FDM）

　　时分多路复用/TDM（Time-Division Multiplexing）
　　这种思路只用一个很窄的频段。为了在同一个频道发送多个信道，采用【分时机制】，把时间切割成很小的时间片，每个线路占用一个时间片。周而往复。
　　这个思路有点像十字路口的红绿灯——每隔一段时间，其中一条路可以通行。
　　这个思路的优点是：可以只使用一个很窄的频段。缺点是：线路越多，每条线路等待越久；即使某个线路空闲，依然会占用时间片（浪费了资源）。

　　码分多路复用/CDM（Code-Division Multiplexing）
　　这种思路采用某种【编码】的技巧，使得多个端点可以在同一个时间点使用同一频段发送数据；由于他们采用不同的编码方式，不会相互干扰。
　　一般来说，CDM 要依赖于“扩频技术”（spread spectrum），需占用一个比较宽的频道范围。这算是缺点。但其优点很明显——
其一，可以支持 N 个线路（N 动态变化）；
其二，即使任何一个线路的流量动态变化，也不会浪费物理信道的资源。
　　显然，这种思路明显优于 FDM ＆ TDM。如今在移动通讯领域大名鼎鼎的 CDMA（码分多址），采用的就是这个思路。

★物理层：具体实例

◇物理层的【协议】

　　物理层的协议主要有如下：
USB 协议
蓝牙协议的一部分
IEEE 802.11 的一部分（Wi-Fi）
IEEE 802.16（WiMAX）
IEEE 1394（火线接口）
RS-232 协议（串行接口/串口）
......
（考虑到篇幅）俺不可能具体细聊这些协议，只是贴出每个的维基百科链接，感兴趣的同学自己点进去看。

◇物理层的【协议实现】

　　对于电脑主机（含移动设备），“网卡硬件”包含了物理层的协议实现（参见如下示意图）
　　另外，还有一些专门的【1层】网络设备，也提供物理层的功能（参见下一个小节）。


（OSI 模型中，不同层次的协议实现）

◇物理层相关的【网络设备】

　　调制解调器（modem）
　　通俗地说，“调制解调器”就是用来翻译“数字信号 ＆ 模拟信号”。
　　在发送信息时，modem 把电脑要发送的“字节流”（数字信号）翻译成“模拟信号”，然后通过物理介质发送出去；当它从物理介质收到“模拟信号”，再翻译成“数字信号”，传回给电脑。
　　早期的拨号上网，modem 面对的物理介质是“固话线路”；如今家庭宽带普及，光纤入户，modem 面对的物理介质是“光纤线路”。


（老式 modem，用于固定电话线路）
　　中继器（repeater）
　　信号在物理介质中传输，会出现【衰减】（不论是“有线 or 无线”都有可能衰减）。“中继器”的作用是【信号增益】，使得信号能传得更远。
　　另外，比如“微波通讯”是直线传播，而地球表面有弧度，还有地形的起伏。所以每隔一定距离要建“微波塔”。这玩意儿也相当于“中继器”。


（微波塔示意图）
　　集线器（hub）
　　可以把“集线器”视作更牛逼的“中继器”——“中继器”只有两个口（只能连接两个通讯端点），而“集线器”有多个口（同时连接多个通讯端点）。
　　通常所说的“集线器”是指“以太网集线器”。这种设备如今已经逐步淘汰，很少见到了。


（老式的10兆以太网集线器）
　　另外，很多同学应该都用过“USB hub”，就是针对 USB 线的“集线器”（“USB 线”也可以视作某种通讯介质）。

★链路层：概述

◇链路层的必要性

　　对信息的打包
　　物理层传输的信息，通俗地说就是【比特流】（也就是一长串比特）。但是对于计算机来说，“比特流”太低级啦，处理起来极不方便。“链路层”要干的第一个事情，就是把“比特流”打包成更大的一坨，以方便更上层的协议进行处理。在 OSI 模型中，链路层的一坨，称之为“帧”（frame）。

　　差错控制
　　物理介质的传输，可能受到环境的影响。这种影响不仅仅体现为“噪声”，有时候会出现严重的干扰，导致物理层传输的“比特流”出错（某个比特“从0变1”或“从1变0”）。因此，链路层还需要负责检查物理层的传输是否出错。在 IT 行话中，检测是否出错，称之为“差错控制机制”（后面有一个小节会简单说一下这个话题）。

　　流量控制
　　假设两个端点通过同一个物理信道进行通讯，这两个端点处理信息的速度可能不同。如果发送方输出信息的速度超过接收方处理信息的速度，通讯就会出问题。于是就需要有某种机制来协调，确保发送方的发送速度不会超出接收方的处理速度。在技术行话中，这称之为“流量控制”，简称“流控”。

　　信道复用
　　在上一个章节已经讲到：用于远距离通讯的“物理介质”，总是有成本。因此需要对物理信道进行“多路复用”，就会导致多个端点共用同一个物理信道。如果同时存在多个发送者和多个接收者。接收者如何知道某个信息是发给自己而不是别人？
　　另外，某些物理介质可能不支持并发（无法同时发送信息）。某些物理介质可能是【半双工】，所有这些物理层的限制，都使得“多路复用”变得复杂。为了解决这些问题，链路层需要提供了某种相应的机制（协议），术语叫做“介质访问控制”（洋文是“Media Access Control”，简称 MAC）。后续小节会聊它。

◇差错控制

　　为了发现传输的信息是否出错，设计了很多相应的数学算法。这些算法大体分为两类：“检错算法 ＆ 纠错算法”。
　　简而言之，“检错算法”只能检测出错误，而“纠错算法”不但能检测出错误，还能纠正错误。很显然，“纠错算法”更牛逼，但是它也更复杂。
　　常见的“检错算法”对传输的数据计算出一个【校验值】，接收方收到数据会重新计算校验和，如果算出来不对，就把收到的数据丢弃，让对方重发。“校验算法”的原理类似于《扫盲文件完整性校验——关于散列值和数字签名》一文中提到的“散列算法/哈希算法”。
　　“纠错算法”更高级，由于涉及到更多数学，俺就不展开啦。
　　对于【无线】物理信道，由于出错的概率更高，并且重新传输数据的成本也更高。所以【无线】通讯的链路层协议，更倾向于用【纠错】机制；作为对比，【有线】通讯的链路层协议，更倾向于用【检错】机制。

◇MAC 协议

　　“MAC 协议”用来确保对下层物理介质的使用，不会出现冲突。为了形象，俺拿“铁路系统”来比喻，说明“MAC 协议”的用途。
　　假设有一条【单轨】铁路连接 A/B 两地。有很多火车想从 A 开到 B，同时还有很多火车想从 B 开到 A。
　　首先，要确保不发生撞车（如果已经有车在 A 开往 B 的途中，那么 B 就不能再发车）；其次，即使是同一个方向的车，出发时间也要错开一个时间间隔。
　　所有这些协调工作，都是靠“MAC 协议”来搞定。

◇MAC 地址

　　为了完成上述任务，光有“MAC 协议”还不够，还需要为每一个端点引入【惟一的】标识。这个标识就称作“MAC 地址”。
　　通俗地说，每个网卡都内置了一个“MAC 地址”。这个地址是网卡在出厂的时候就已经设置好的，并且用某种机制确保该地址【全球唯一】。

　　如何保证 MAC 地址全球唯一捏？简单说一下：
　　MAC 地址包含6个字节（48个比特），分为两半。第一部分称作【OUI】，OUI 的24个比特中，其中2个比特有特殊含义，其它22个比特，用来作为网卡厂商的唯一编号。这个编号由国际组织 IEEE 统一分配。
　　MAC 地址第二部分的24比特，由网卡厂商自己决定如何分配。每个厂商只要确保自己生产的网卡，后面这24比特是唯一的，就行啦。

（MAC 地址的构成）
　　由于俺在很多安全教程中鼓吹大伙儿使用“操作系统虚拟机”，再顺便说说【虚拟网卡】的 MAC 地址。
　　“虚拟网卡”是由【虚拟化软件】创建滴。IEEE 也给每个虚拟化软件的厂商（含开源社区）分配了唯一的 OUI。因此，虚拟化软件在创建“虚拟网卡”时，会使用自己的 OUI 生成前面24个比特；后面的24比特，会采用某种算法使之尽可能【随机化】。由于“2的24次方”很大（224 = 16777216），碰巧一样的概率很低。
　　（注：如果手工修改 MAC 地址，故意把两块网卡的 MAC 地址搞成一样，那确实就做不到唯一性了。并且会导致链路层的通讯出问题）

★链路层：具体实例

◇链路层的【协议】

　　链路层的协议主要有如下：
MAC 协议（介质访问控制）
LLC 协议（逻辑链路控制）
ARP 协议（解析 MAC 地址）
IEEE 802.3（以太网）
IEEE 802.11 的一部分（Wi-Fi）
L2TP 协议（2层VPN）
PPP 协议（拨号上网）
SLIP 协议（拨号上网）
......
（考虑到篇幅）俺不可能具体细聊这些协议，只是贴出每个的维基百科链接，感兴趣的同学自己点进去看。

◇链路层的【协议实现】

　　对于电脑主机（含移动设备），“网卡硬件 ＆ 网卡驱动”会包含链路层协议的实现（参见如下示意图）。
　　另外，还有一些专门的【2层】网络设备，也提供链路层的功能（参见下一个小节）。


（OSI 模型中，不同层次的协议实现）

◇链路层相关的【网络设备】

　　网络交换机（network switch）
　　（注：一般提到“网络交换机”，如果不加定语，指的就是“2层交换机”；此外还有更高层的交换机，在后续章节介绍）
　　为啥要有交换机捏？俺拿“以太网的发展史”来说事儿。
　　以太网刚诞生的时候，称之为“经典以太网”，电脑是通过【集线器】相连。“集线器”前面提到过，工作在【1层】（物理层），并不理解链路层的协议。因此，集线器的原理是【广播】模式——它从某个网线接口收到的数据，会复制 N 份，发送到其它【每个】网线接口。假设有4台电脑（A、B、C、D）都连在集线器上，A 发数据给 B，其实 C ＆ D 也都收到 A 发出的数据。显然，这种工作模式很傻逼（低效）。由于“经典以太网”的工作模式才“10兆”，所以集线器虽然低效，还能忍受。
　　后来要发展“百兆以太网”，再用这种傻逼的广播模式，就不能忍啦。于是“经典以太网”就发展为“交换式以太网”。用【交换机】代替“集线器”。
　　交换机是工作在2层（链路层）的设备，能够理解链路层协议。当交换机从某个网线接口收到一份数据（链路层的“帧”），它可以识别出“链路帧”里面包含的目标地址（接收方的 MAC 地址），然后只把这份数据转发给“目标 MAC 地址相关的网线接口”。
　　由于交换机能识别2层协议，它不光比集线器的性能高，而且功能也强得多。比如（稍微高级点的）交换机可以实现“MAC 地址过滤、VLAN、QoS”等多种额外功能。

　　网桥/桥接器（network bridge）
　　“交换机”通常用来连接【同一种】网络的设备。有时候，需要让两台不同网络类型的电脑相连，就会用到【网桥】。
　　下面以“操作系统虚拟机”来举例（完全没用过虚拟机的同学，请跳过这个举例）。
　　在这篇博文，俺介绍了虚拟机的几种“网卡模式”，其中有一种模式叫做【bridge 模式】。一旦设置了这种模式，Guest OS 的虚拟网卡，对于 Host OS 所在的外部网络，是【双向】可见滴。也就是说，物理主机所在的外部网络，也可以看见这块虚拟网卡。
　　现在，假设你的物理电脑（Host OS）只安装了【无线网卡】（WiFi），而虚拟化软件给 Guest OS 配置的通常是【以太网卡】。显然，这是两种【不同】的网络。为啥 Guest OS 的以太网卡设置为“bridge 模式”之后，外部 WiFi 网络可以看到它捏？
　　奥妙在于——虚拟化软件在内部悄悄地帮你实现了一个“网桥”。这个网桥把“Host OS 的 WiFi 网卡”与“Guest OS 的以太网卡”关联起来。WiFi 网卡收到了链路层数据之后，如果接收方的 MAC 地址对应的是 Guest OS，网桥会把这份数据丢给 Guest OS 的网卡。
　　这种网卡模式之所以称作“bridge 模式”，原因就在于此。

◇链路层相关的【软件工具】

　　嗅探抓包工具（Sniffer）
　　要了解链路层的数据包结构，需要用到“嗅探工具”。这类工具能捕获流经你网卡的所有【链路层】数据包。前面聊“协议栈”的时候说过：下层数据包的载荷就是上层数据包的整体。因此，拿到【链路层】数据包也就意味着：你已经拿到2层之上的所有数据包的信息了。
　　有些抓包工具自带图形界面，可以直接显示数据包的内容给你看。还有些只提供命令行（只是把获取的数据包保存为文件），然后要搭配其它图形化的工具来展示数据包的内容。
　　抓包的工具有很多，名气最大的是 Wireshark（原先叫做 Ethereal）。

　　ARP 命令
　　首先，ARP 是“MAC 地址解析协议”的洋文名称。该协议根据“IP 地址”解析“MAC 地址”。
　　Windows 自带一个同名的 arp 命令，可以用来诊断与“MAC 地址”相关的信息。比如：列出当前子网中其它主机的 IP 地址以及对应的 MAC 地址。这个命令在 Linux ＆ Mac OS 上也有。

★网络层：概述

◇网络层的必要性

　　路由机制（routing）
　　在 OSI 模型中，链路层本身【不】提供路由功能。你可以通俗地理解为：链路层只处理【直接相连】的两个端点（注：这么说不完全严密，只是帮助外行理解）
　　对于某个复杂网络，可能有很多端点，有很复杂的拓扑结构。当拓扑足够复杂，总有一些端点之间【没有直连】。那么，如何在这些【没有直连】的端点之间建立通讯捏？此时就需要提供某种机制，让其它端点帮忙转发数据。这就需要引入“路由机制”。
　　为了避免把“链路层”搞得太复杂，路由机制放到“链路层”之上来实现，也就是“网络层”。

　　基于【路由】的地址编码方式
　　链路层已经提供了某种全球唯一的地址编码方式（MAC 地址）。但“MAC 地址”有如下几个问题：
其一，它是固定的（虽然可以用技术手段去修改 MAC 地址，但很少这么干）
其二，MAC 地址的编码是基于【厂商】，无法体现网络拓扑结构。或者说，“MAC 地址”对于“路由机制”是不够友好滴。
　　因此，需要引入一种更抽象（更高层）的地址，也就是“网络层地址”。咱们常说的“IP 地址”，是“网络层地址”的实现方式之一。

　　为了帮你理解，举个例子：
　　每个人都有身份证号（这就类似于“MAC 地址”）。当某人加入了某个公司，公司会为此人再分配一个“员工号”（这就类似于“网络地址”）。既然有身份证号，为啥公司还要另搞一套“员工编号”捏？因为“员工编号”有额外的好处。比如说：可以把员工号划分为不同的区间，对应不同的部门。这样一来，只要看到员工号，就知道此人来自哪个部门。
　　类似道理，每个网卡都有自己固定的 MAC 地址，当这个网卡接入到不同的网络，每次都可以再分配不同的“网络地址”。通过“网络地址”可以看出这个网卡属于哪个网络（对路由比较方便）。

　　网际互联（internetwork）
　　引入“网络层”的另一个目的是：屏蔽不同类型的网络之间的差异，从而有利于【网际互联】（也就是建立“网络的网络”）。
　　一般来说，要想联通【异种】网络，就要求每个网络中都有一台主机充当【网关】（gateway）。【网关】起到“中介/翻译”的作用——帮不同的网络翻译协议，使得不同的网络可以互相联通。
　　假设【没有】统一的网络层，网关的工作就很难做。就好比说：如果全球没有某种通用的自然语言，就需要培养非常多不同类型的翻译人才（假设有30种主要语言，任意两种互译，就需要几百种不同的翻译人才）。
　　反之，如果有了某种统一的网络层标准，问题就好办多了（还是假设有30种主要语言，只要选定某种作为通用语，然后培养29种翻译人才，就可以实现任意两种语言互译）。
　　如今的互联网时代，【IP 协议】就是那个充当统一标准的网络层协议。


（互联网整合了各种类型的网络）

◇网络拓扑（network topology）

　　网络的拓扑结构有很多种，有简单的，有复杂的。一般来说，再复杂的拓扑，也可以逐步分解为若干简单拓扑的组合。
　　对拓扑的研究，有专门一个数学分支（拓扑学）。考虑到本文只是扫盲，俺不可能再去聊“拓扑学”。因此，只挑几种简单的拓扑结构，让大伙儿有个直观的印象。


（常见的网状拓扑结构：星形拓扑、环形拓扑、总线拓扑、网状拓扑、等等）
　　如今的互联网，整体的拓扑结构超级复杂。但还是可以逐步分解为上述几种基本的拓扑结构。


（互联网的复杂拓扑，右下角是图中某个小点的放大。
为节省大伙儿的翻墙流量，俺贴的是缩小图。点“这里”看原始图）

◇互联网的拓扑——从“历史”的角度看其健壮性

　　从上面那张图可以看出：互联网拓扑的【局部】有很多是“星形拓扑”（当然也有其它的）。但从【宏观】上看，更像是“网状拓扑”。
　　在现实生活中，对于复杂结构，通常都会采用“树状层次结构”，以便于管理。比如：域名系统、公司组织结构、官僚系统 ...... 那为啥互联网的【宏观】拓扑结构是“网状”捏？这就要说到互联网的历史。

　　在上世纪50年代（冷战高峰期），美国军方的指挥系统高度依赖于电信公司提供的电话网络。当时的电话网络大致如下——
在基层，每个地区有电话交换局，每一部电话都连入当地的交换局。
在全国，设有若干个长途局，每个交换局都接入某个特定的长途局（不同地区的交换局通过长途局中转）。
　　简而言之，当时美国的电话网络是典型的【多级星形拓扑】。这种拓扑的优点是：简单、高效、便于管理；但缺点是：健壮性很差。从这个案例中，大伙儿可以再次体会到“效率”与“健壮性”之间的矛盾。俺写过一篇很重要的博文（这里）深入讨论了这个话题。
　　话说1957年的时候，苏联成功试射第一颗洲际弹道导弹（ICBM），美国军方开始担心：一旦苏联先用洲际导弹攻击美国，只要把少数几个长途局轰掉，军方的指挥系统就会瘫痪。也就是说，“长途局”已经成为美国军方的【单点故障】（何为“单点故障”？参见这篇博文）。
　　1960年，美国国防部找来大名鼎鼎的兰德公司进行咨询，要求提供一个应对核打击的方案。该公司的研究员 Paul Baran 设计了一个方案，把“星形拓扑”改为【网状拓扑】。采用【网状拓扑】的好处在于：即使发生全面核大战，大量骨干节点被摧毁，整个网络也不会被分隔成几个孤岛，军方的指挥系统依然能正常运作。


（左边：互联网诞生前——美国的电话网络　　右边：兰德公司的“Baran 方案”）
　　有了兰德公司的方案，美国军方找到当时最大的电信公司 AT＆T，想要实现这个系统，结果被否决了。AT＆T 高层认为：搞这样一种系统根本不切实际。于是 Baran 的方案中途夭折。
　　为啥 AT＆T 反对这个方案捏？一方面，成功的大公司总是有很强的思维定势（关于这点，参见这篇文章）；另一方面，Baran 的设计方案确实很超前——其前瞻性不仅包括“拓扑结构”，而且把当时电信行业的几大核心观念完全颠覆掉了（具体如何颠覆，后续章节还会再聊）。
　　时间一晃又过了好多年，到了60年代末，由于一系列机缘巧合，英国佬发现了“Baran 方案”的价值，并据此搞了一个小型的 NPL 网络（NPL 是“国家物理实验室”的缩写）。然后在某次 ACM 会议上，美国佬看到英国佬的论文，才意识到：Baran 方案完全可行。经历了“出口转内销”的命运之后，该方案重新被美国国防部重视。之后，（国防部下属的）“高级计划研究局”（ARPA）开始筹建“阿帕网”（ARPANET），才有了如今的互联网。

◇路由的大致原理

　　聊完“拓扑”，再来聊“路由”。
　　当主机 A 向主机 B 发送网络层的数据时，大致会经历如下步骤：
1.
A 主机的协议栈先判断“A B 两个地址”是否在同一个子网（“子网掩码”就是用来干这事儿滴）。
如果是同一个子网，直接发给对方；如果不是同一个子网，发给本子网的【默认网关】。
（此处所说的“网关”指“3层网关/网络层网关”）
2.
对于“默认网关”，有可能自己就是路由器；也可能自己不是路由器，但与其它路由器相连。
也就是说，“默认网关”要么自己对数据包进行路由，要么丢给能进行路由的另一台设备。
（万一找不到能路由的设备，这个数据就被丢弃，于是网络通讯出错）
3.
当数据到达某个路由器之后，有如下几种可能——
3.1
该路由器正好是 B 所在子网的网关（与 B 直连），那就把数据包丢给 B，路由过程就结束啦；
3.2
亦或者，路由器会把数据包丢给另一个路由器（另一个路由器再丢给另一个路由器） ...... 如此循环往复，最终到达目的地 B。
3.3
还存在一种可能性：始终找不到“主机 B”（有可能该主机“断线 or 关机 or 根本不存在”）。为了避免数据包长时间在网络上闲逛，还需要引入某种【数据包存活机制】（洋文叫做“Time To Live”，简称 TTL）。
通常会采用某个整数（TTL 计数）表示数据包能活多久。当主机 A 发出这个数据包的时候，这个“TTL 计数”就已经设置好了。每当这个数据包被路由器转发一次，“TTL 记数”就减一。当 TTL 变为零，这个数据包就死了（被丢弃）。

　　对于某些大型的复杂网络（比如互联网），每个路由器可能与其它 N 个路由器相连（N 可能很大）。对于上述的 3.2 情形，它如何判断：该转发给谁捏？
　　这时候，“路由算法”就体现出价值啦——
一般来说，路由器内部会维护一张【路由表】。每当收到一个网络层的数据包，先取出数据包中的【目标地址】，然后去查这张路由表，看谁距离目标最近，就把数据包转发给谁。
　　上面这段话看起来好像很简单，其实路由算法挺复杂滴。考虑到本文是“扫盲性质”，而且篇幅已经很长，不可能再去聊“路由算法”的细节。对此感兴趣的同学，可以去看《计算机网络》的第5章。

◇路由算法的演变史（以互联网为例）

　　（技术菜鸟可以跳过这个小节）
　　由于互联网的 IP 协议已经成为“网络层协议”的事实标准，俺简单聊一下互联网的路由机制是如何进化滴。

　　第1阶段：静态全局路由表
　　（前面说了）互联网的前身是“阿帕网/ARPANET”。在阿帕网诞生初期（上世纪70年代），全球的主机很少。因此，早期的路由表很简单，既是“全局”滴，又是“静态”滴。简而言之，每个路由器内部都维护一张“全局路由表”，这个“路由表”包含了全球所有其它路由器的关联信息。每当来了一个数据包，查一下这张全局路由表，自然就清楚要转发给谁，才能最快到达目的地。
　　早期的阿帕网，主机的变化比较少，也很少增加路由器。每当出现一个新的路由器，其它路由器的管理员就手工编辑各自的“全局路由表”。
　　为了加深大伙儿印象，特意找来两张70年代初的阿帕网拓扑图（注：图中的 IMP 是“Interface Message Processor”的缩写，也就是如今所说的“路由器”）。


（1973年的阿帕网）

（1977年的阿帕网）
　　第2阶段：动态全局路由表
　　后来，“阿帕网/互联网”的规模猛增，路由器数量也跟着猛增，隔三差五都有新的路由器冒出来。再用“静态路由表”这种机制，（编辑路由表的）管理员会被活活累死。于是改用“动态路由表”，并引入某种“路由发现机制”。但“路由表”依然是【全局】滴。

　　第3阶段：动态分级路由表
　　再到后来，全球的路由器越来越多，成千上万，再搞“全局路由表”已经不太现实了——
一方面，“全局路由表”越来越大（查询的速度就越来越慢）
另一方面，由于互联网的流量越来越大，每来一个数据包都要查表，查询越来越频繁。
　　于是，路由器开始吃不消了。为了解决困境，想出一个新招数：引入“分级路由”（hierarchical routing）。所谓的“分级路由”就是：把整个互联网分为多个大区域，每个大区域内部再分小区域，小区域内部再分小小区域 ...... 看到这里，熟悉“数据结构与算法”的同学就会意识到——这相当于构造了一个【树状】层次结构。
　　有了这个层次结构，每个路由器重点关注：自己所在的那个最小化区域里面的网络拓扑。如此一来，每个路由器的“路由表”都会大幅度减小。


（全局路由表 VS 分级路由表）

◇互联网的路由——从“CAS”的角度看其健壮性

　　去年（2020）俺写了一篇博文《“政治体制”与“系统健壮性”——基于“复杂性科学”的思考》，其中介绍了“CAS”（复杂自适应系统）的概念。互联网的路由机制，就是一个典型的 CAS。
　　如果把互联网视作一个系统，每个公网上的路由器都是一个自适应的主体。假如某个地区的网络流量突然暴涨，骨干网路由器会自动分流；假如因为地震或战争，导致某个地区的骨干网路由器全部下线，周边地区的路由器也会自动避开这个区域 .....
　　所有这些工作，【不需要】依靠任何最高指挥中枢，去进行协调。
　　相反，如果互联网的路由系统中，设立了某种“中央委员会”进行实时调度，那互联网早就完蛋了，根本无法成长为今天这种规模。

◇网络层的两种交换技术——电路交换（circuit switching） VS 分组交换（packet switching）

　　（技术菜鸟可以跳过这个小节）
　　前面聊“互联网诞生”，说到兰德公司的“Baran 方案”。该方案对当时的电信系统提出几大革命性的变化，其中之一就是“分组交换”技术（也称“数据包交换”or“封包交换”）。
　　一般来说，网络层的设计有两种截然不同的风格：【电路交换 VS 分组交换】。有时候也分别称之为“有连接的网络层 VS 无连接的网络层”。此处所说的“连接”指的是某种“虚电路”（洋文叫做“virtual circuit”，简称 VC）。

　　要理解“虚电路”，首先要从老式的电话系统说起。
　　最早期的电话，既没有拨号盘也没有按键，全靠一张嘴。当你拿起电话，先告诉接线员你要打给谁，接线员会用一根跳接线，插入电话交换设备的某个插孔，从而把你的电话机与对方的电话机相连。于是建立了一条两人之间的电话通路，也就是“电路”。你可以把“接线员”想象成某种“人肉路由器” :)


（1900年法国巴黎的电话交换局，可以看到接线员在操作电话交换设备）
　　后来发明了“自动电话交换机”，导致“接线员”全体下岗。虽然自动化了，但原理还是一样——当你在电话上拨了某人的号码，电话局的交换机会自动选择一条线路。只有当这条线路建立起来，对方的电话才会响。一旦双方开始通话，双方之间的语音都是通过这条线路传输。并且这条线路是独占的——只要通话不挂断，这条线路就不会再分配给其他人使用。

　　前面提到“互联网诞生的历史”，当时军方推动的“Baran 方案”被 AT＆T 断然拒绝。因为这个方案完全颠覆了传统的电话系统——
颠覆之1：把“模拟信号”颠覆为“数字信号”（这点比较好理解，俺就不解释了）
颠覆之2：把“星形拓扑”颠覆为“网状拓扑”（关于这点，前面的小节已经讨论了）
颠覆之3：把“电路交换”颠覆为“分组交换”（这就是本小节的重点）

　　为了帮大伙儿理解上述第3点，举个例子：
　　假设主机 A 要向主机 B 发送一大坨数据。因为数据太多，肯定要分成好几坨小一点的（分成多个数据包）。如何把这些数据包发送给对方捏？

　　“电路交换”的实现方式
在发送数据之前，要先建立连接通道（通过路由算法，找出 A ＆ B 之间的某条通路）。这条通路就是所谓的“虚电路/VC”。一旦 VC 建立，每一个数据包都是从这条拓扑路径进行路由。

　　“分组交换”的实现方式
在发送数据之前，【不需要】建立通道，让每个数据包独立进行路由。这种情况下，这几个数据包可能会走【不同的】拓扑路径。因此，数据包到达的顺序与发送的顺序【不一定】相同。接收方收到所有数据包之后，还要自己进行排序。
　　维基百科上有一个 GIF 动画（这个链接），比较直观地演示“分组交换/封包交换”的效果。由于这个动画稍微有点大（超过 1MB），俺就不贴到博文中了。

　　当时的电话系统主要承载语音传输，“电路交换”显然性能更高。那为啥 Baran 的设计要采用“分组交换”捏？俺又要再次提到【效率 VS 健壮性】之间的矛盾与均衡。
　　对于“电路交换”，一旦建立连接，同一个连接的所有数据都走相同的路径（会经过完全相同的路由器）。也就是说，传输的过程中，如果某个路由器挂掉了（网络掉线 or 硬件当机 or 软件崩溃）。那么，该路由器正在处理的 N 个连接全都要报废。而“分组交换”则更加灵活——即使某个路由器挂掉了，后续的数据包会自动转向另外的路由器，损失很小。
　　“Baran 方案”之所以采用“分组交换”的设计，因为人家这个方案是提交给军方用来应对【全面核战争】滴，当然要考虑健壮性啦。

　　话说这两种交换机制，各有很多支持者，并分裂为两大阵营，分别是：“电信阵营 VS 互联网阵营”。两大阵营的口水战持续了 N 年，都无法说服对方。到了后来设计 OSI 模型的时候，为了保持中立性与通用性，OSI 模型本身并没有强制要求网络层采用哪一种风格。
　　经过几十年之后，咱们已经可以看出来：“互联网阵营”占据主导地位。如今，连电信系统都是架构在互联网之上。

★网络层：具体实例

◇网络层的【协议】

　　网络层的协议有很多。由于“互联网”已经成为全球的事实标准，因此俺只列出属于“互联网协议族”的那些“网络层协议”：
IP 协议（含 IPv4 ＆ IPv6）
ICMP
IGMP
IPSec
......
（考虑到篇幅）俺不可能具体细聊这些协议，只是贴出每个的维基百科链接，感兴趣的同学自己点进去看。
　　对上述这些协议，最重要的当然是 IP 协议。如果你想要深入了解 IP 协议，可以参考如下这本书。关于 IP 协议的书，此书的影响力最大。这本书共3卷，通常只需看第1卷。
《TCP-IP 详解》

◇网络层的【协议实现】

　　对于电脑主机（含移动设备），网络层的协议实现通常包含在操作系统自带的网络模块中（也就是“操作系统协议栈”）。具体参见如下示意图。
　　另外，还有一些专门的【3层】网络设备，也提供网络层的功能（参见本章节的后续小节）。


（OSI 模型中，不同层次的协议实现）

◇IP 地址的格式及含义

　　当年设计阿帕网的时候，采用了【4字节】（32比特）来表示“网络层地址”（也就是 IP 地址）。
　　“IP 地址”的含义很重要，俺有必要解释一下：
　　咱们平时所说的 IP 地址，采用【点分十进制】来表示。就是把地址的4个字节，先翻译为十进制，然后每个字节用一个小数点分隔开（参见如下示意图）：

（4字节 IP 地址：“二进制”与“点分十进制”的对照示意图）
　　“IP 地址”的32比特，分为两部分：第1部分用来标识【子网】，第2部分用来标识该子网中的【主机】。
　　这两部分各占用多少比特，是不确定的。在这种情况下，“操作系统协议栈”如何知道哪些比特标识“子网”，哪些比特标识“主机”捏？奥妙在于【子网掩码】。所以，大伙儿在给系统配置 IP 地址的时候，通常都需要再设置一个【子网掩码】，就这个用途。

◇IP 地址枯竭，及其解决方法

　　前一个小节提到：IP地址包含【4字节】（32比特）。因此，最多只能表示【2的32次方】（42亿左右）的不同地址。考虑到还有很多地址保留给特殊用途，实际可用地址远远不到42亿。
　　到了如今，全球网民都已经几十亿了，IP 地址开始枯竭。咋办捏？为了解决这个问题，发展出若干技术手段。简单说一下最常见的几种手段：

　　IPv6
　　名气最大（最多人知道）的技术手段，大概是 IPv6 了。这招想要一劳永逸地解决地址枯竭的问题，采用了16字节（128比特）来表示 IP 地址。
　　设计 IPv6 的人自豪地宣称：即使给地球上的每一粒沙子分配一个 IPv6 地址，依然绰绰有余（确实没有吹牛，“2的128次方”是天文数字）。
　　但 IPv6 的缺点在于，【无法】向下兼容原有的 IP 协议（原有的协议叫“IPv4”）。IPv6 的普及一直比较慢，这是主要原因。

　　代理服务器（proxy）
　　一看到代理，很多人就想到翻墙。其实它也可以用来解决“地址枯竭”的问题。
　　比如说，某个公司有100人，100台电脑。如果每台电脑都分配公网 IP 地址，就要消耗100个公网地址（太浪费啦）。
　　可以只申请一个公网 IP，然后在内网搞一个代理服务器，公网 IP 分配给它（代理服务器有两个网卡，一个接内网，一个接公网）。然后在其它电脑上设置代理，指向这台代理服务器，就都可以上外网啦。
　　（注：在本文的末尾有一个 ★杂项 的章节，会专门聊一下“代理”这个话题）

　　网络地址转换（NAT）
　　前面 proxy 那招有个缺点：内网的每台电脑里面的每个上网软件，都要单独设置代理。实在太麻烦啦！
　　后来就发明了某种更牛逼的招数——网络地址转换（洋文是“Network Address Translation”，简称 NAT）。
　　用了这招，还是只要申请一个公网 IP，分配给内网的网关（网关有两个网卡，一个接内网，一个接公网）。然后在内网的网关配置 NAT 功能，自动就可以让内网的每台电脑访问外网。
　　在这篇博文，俺介绍了虚拟机的几种“网卡模式”，其中有一种模式叫做【NAT 模式】，就是指这个玩意儿。
　　采用了 NAT 技术之后，可能会对某些应用软件（尤其是 P2P 类型的）造成兼容性问题，于是又发明了一些“NAT 穿透技术”（NAT traversal）。这类技术有好几种，如果有空的话，俺会单独写教程介绍。

　　其它解决方法
　　关于“IPv4 地址空间耗尽”，解决方法肯定不止上面这几招。限于篇幅，就此打住。更多的讨论参见维基百科的“这个链接”。

◇网络层相关的【网络设备】

　　路由器（router）
　　（前面章节聊“路由原理”的时候，已经介绍过它；这里就不再浪费口水啦）

　　3层交换机（Layer 3 switching）
　　“3层交换机”是在“2层交换机”的基础上，增加了对网络层的处理。因此，它可以做到类似路由器的效果——在几个子网之间转发数据。
　　与路由器的差别在于——“3层交换机”链接的几个子网是【同种】网络；而路由器可以连接【异种】网络。
　　从上面这句话看，“3层交换机”的能力显然不如“路由器”。既然已经有“路由器”，为啥还要发明“3层交换机”捏？这就要说到【单臂路由器】的弊端。
　　对于企业内网的“2层交换机”，通常都支持 VLAN 功能。通俗地说：可以在交换机中划分多个【虚拟子网】。其实这些子网的中所有的电脑，都还是接入这台交换机，只不过这些子网配置了不同的网络地址。对于同一个 VLAN 内部的通讯，“2层交换机”自己就可以搞定（只需要用到2层协议）；但对于【跨】VLAN 主机之间的通讯，“2层交换机”就没戏啦（它没有路由功能）。因此，就必须在它旁边外加一个路由器，形成如下拓扑结构。在这个拓扑中，路由器只与单个设备（2层交换机）相连，所以称之为“单臂”。
　　请注意：如下示意图只画了两台电脑，位于两个 VLAN。实际上可能有很多个 VLAN，每个里面有几十台电脑。于是，交换机与路由器之间的传输通道就会成为瓶颈——【跨】VLAN 的任意两台电脑通讯，数据包都要到路由器那里兜一圈。为了消除这种瓶颈，才发明了“3层交换机”——把路由功能直接集成到交换机内部。


（“单臂路由器”的拓扑结构）
　　无线热点（Wireless Access Point）
　　“无线热点”通常用来提供无线接入，使得某个【无线】设备能接入到某个【有线】网络中。一般来说，热点都内置了路由功能，那么它就是“无线路由器”，对应到“3层”（网络层）。反之，如果没有路由功能，它就是“网桥”，属于“2层”（链路层）。

◇网络层相关的【软件工具】

　　ping
　　这个命令，很多人应该都知道。早在 Win9x 就有这个命令了。它使用（网络层的）ICMP 协议来测试某个远程主机是否可达。
　　提醒一下：
　　如果 ping 命令显示某个 IP 地址不可达，有很多种情况。比如说：

这个 IP 地址对应的主机已经关机
这个 IP 地址对应的主机已经断线
这个 IP 地址对应的主机拒绝响应 ICMP 协议
从你本机到这个 IP 地址之间，有某个防火墙拦截了 ICMP 协议
......

　　traceroute
　　这是一个通用的工具，用来测试路由。很早以前的 Windows 就已经内置了它，命令是 tracert。在 POSIX（Linux＆UNIX）上通常叫 traceroute
　　你可以用这个命令，测试你本机与互联网另一台主机之间的路由（也就是：从你本机到对方主机，要经过哪些路由器）

★传输层：概述

◇传输层的必要性

　　屏蔽“有连接 or 无连接”的差异
　　（上一个章节提到）网络层本身已经屏蔽了【异种网络】的差异（比如“以太网、ATM、帧中继”之间的差异），而且网络层也屏蔽了路由的细节。但网络层本身还有一个差异，也就是网络层的两种交换技术：电路交换（有连接） VS 分组交换（无连接）。
　　前面章节也提到了：上述两种交换技术各有很多支持者，并分裂为两大阵营。当年设计 OSI 模型的时候，为了保持中立性与通用性，并没有强制规定“网络层”必须采用何种交换机制。
　　对于开发网络软件的程序员来说，当然不想操心“网络层用的是哪一种交换机制”。因此，需要对网络层的上述差异再加一个抽象层（也就是“传输层”）。

　　从“主机”到“进程”
　　前面介绍的“网络层”，其设计是面向主机（电脑）。“网络层地址”也就是某个主机的地址。
　　而“传输层”是面向【进程】滴！因为传输层要提供给【网络软件】使用，而网络软件打交道的对象是【另一个网络软件】。因此，传输层必须在“网络层地址”的基础上，再引入某种新的标识，用来区分同一台主机上的不同【进程】。

◇传输层的特殊性

　　在 OSI 7层模型中，传输层正好居中。这是一个很特殊的位置。
　　OSI 模型最下面3层，与【网络设备】比较密切。这里面所说的“网络设备”，既包括那些独立的主机（比如“路由器、交换机、等”），也包括电脑上的硬件（比如“网卡”）。
　　OSI 模型最上面3层，与【网络软件】比较密切（或者说，与“用户的业务逻辑”比较密切）。
　　而中间的传输层，正好是承上启下。对于开发应用软件的程序猿/程序媛，“传输层”是他们能感知的最低一层。

◇传输层的【端口】

　　刚才谈“传输层的必要性”，提到说——“网络层地址”只能标识【主机】，而传输层必须要能标识【进程】。为了达到这个目的，于是就引入了“传输层端口”这个概念（为了打字省力，后续讨论简称为“端口”）。
　　在 OSI 模型中，“端口”的官方称呼是“传输服务访问点”（洋文缩写 TSAP）。但是作为程序员，俺已经习惯于“端口”这个称呼。后续介绍依然用“端口”一词。
　　当程序员使用传输层提供的 API 开发网络软件时，通常把“端口”与“网络地址”一起使用（构成“二元组”），就可以定位到某个主机上的某个进程。

★传输层：具体实例

◇传输层的【协议】

　　为了让程序员可以更爽地使用传输层来开发网络软件，传输层既要提供“有连接”的风格，也要提供“无连接”的风格。关于这两种风格的对比，前面已经聊过，这里不再浪费口水。
　　具体到“互联网协议族”，有两个主要的传输层实现，分别是 TCP ＆ UDP（前者是“有连接”，后者是“无连接”）。
　　除了 TCP ＆ UDP，“互联网协议族”还提供了其它一些传输层协议。因为比较冷门，俺就不介绍啦。

◇传输层的【协议实现】

　　对于电脑主机（含移动设备），传输层的协议实现通常包含在操作系统自带的网络模块中（也就是“操作系统协议栈”）。具体参见如下示意图。
　　另外，还有一些专门的【4层】网络设备，也提供传输层的功能（参见后续的小节）。


（OSI 模型中，不同层次的协议实现）

◇套接字（socket API）

　　前面说了：传输层是面向程序员（让他们可以更方便地开发网络软件）。因此，就需要提供一些封装传输层的【库】（API）。程序员只需要调用这些【库】，就可以使用传输层的协议进行通讯啦。
　　影响力最大的传输层封装库，当然是 socket API。它来自加州大学伯克利分校。
　　在互联网诞生初期，伯克利分校开发了一个 UNIX 操作系统的的变种，叫做“伯克利 UNIX 发行版”（BSD Unix），也就是如今 BSD 操作系统的前身。伯克利发行版内置了一套用来进行网络编程的 API，当时叫做“伯克利套接字”（Berkeley sockets）。由于这套 API 用起来很方便，很多其它的 UNIX 变种也移植了这套 API，于是就逐渐成了业界的事实标准。到了上世纪90年代，Windows ＆ Linux 也都提供了这套 API。
　　由于大部分读者不是程序员，“套接字”这个话题就到此为止。如果你是个程序员，并且对网络编程感兴趣，可以参考俺的电子书清单，其中有一个分类目录是【IT 类 / 软件开发 / 网络相关】。

◇传输层相关的【网络设备】

　　4层交换机（Layer 4 switching）
　　前面已经介绍了“3层交换机”，“4层交换机”是其进一步的改良，可以识别传输层的协议，获取 TCP or UDP 的端口号。
　　有了这个能力，网管就可以在这种交换机上配置一些管理策略。比如说：（根据传输层端口号）过滤掉某种流量，或者对某种流量设置转发的优先级。

　　状态防火墙（stateful firewall）
　　网络防火墙分好几种，大部分属于这种。它能完全处理 TCP 协议的状态，显然它属于“4层”（传输层）。

◇传输层相关的【软件工具】

　　netcat 家族——传输层的“瑞士军刀”
　　关于 netcat，俺已经写过一篇比较详细的教程：《扫盲 netcat（网猫）的 N 种用法——从“网络诊断”到“系统入侵”》。看完这篇教程，你肯定能体会它功能的强大——很多与 TCP/UDP 相关的事情，都可以用 netcat 搞定。
　　另外，netcat 还有很多衍生品（衍生的开源项目），构成一个丰富的 netcat 家族。在上述教程也有介绍。

　　netstat ＆ ss
　　Windows 和 POSIX（Linux＆UNIX）都有一个 netstat 命令，可以查看当前系统的 TCP/UDP 状态（包括当前系统开启了哪些监听端口）。
　　另外，Linux 上还有一个 ss 命令，功能更强（但这个命令在 Windows 上默认没有）

　　nmap
　　这是最著名的开源的扫描器，可以扫描远程主机监听了哪些传输层端口（注：前面提到的“netcat 家族”也可以干这事儿）
　　nmap 的功能很强，“端口扫描”只是其功能之一。

★业务层（OSI 上三层）：概述

　　一不小心，这篇教程已经写了这么长。为了照顾那些有“阅读障碍”的读者，俺要稍微控制一下篇幅，就把 OSI 的【上三层】合在一起讨论。
　　前面的章节说过：【上三层】更接近于“网络软件”，对应的是应用软件的业务逻辑，因此俺统称为“业务层”。
　　注：有些书（比如《计算机网络》）会把 OSI 的上三层统称为“应用层”。由于 OSI 模型中本来就有一个“应用层”，俺认为这样容易搞混（尤其不利于技术菜鸟），所以另外起了一个“业务层”的名称。

◇业务层的必要性

　　业务层显然是必要滴。因为传输层位于操作系统，它不可能去了解网络软件的业务逻辑。为了让网络软件能够相互通讯，肯定要在传输层之上再定义更高层的协议。
　　问题在于：网络软件千奇百怪，其业务逻辑各不相同，因此，“业务层如何设计”，【无】一定之规。有些软件只用一个协议来搞定所有的业务逻辑（只有一层）；有些软件会参考 OSI，把业务逻辑的协议分为三层；还有些软件可能会分出更多的层次。
　　再强调一下：业务层的协议如何分层，完全看具体的业务逻辑，不要生搬硬套任何现有的参考模型。

◇会话层 ＆ 表示层 ＆ 应用层

　　对于大部分读者来说，【没必要】花时间去了解 OSI 最上面三层之间的区别。你只需把最上面三层视作【一坨】——他们都是与网络软件的业务逻辑密切相关滴。
　　那么，哪些人需要详细了解“这三层的差异”捏？
　　如果你是个程序员，并且你正好是开发【网络】软件，俺建议你了解一下 OSI 模型的最上面三层，有助于你更深刻地思考某些网络协议的设计。所谓的“更深刻”指的是：你不能光停留在 WHAT 层面，要提升到 HOW 甚至 WHY 层面（参见《学习技术的三部曲：WHAT、HOW、WHY》）

★业务层（OSI 上三层）：具体实例

◇业务层的【协议】

　　业务层的协议非常多。即使光把各种协议的名称列出来，也很费劲。所以俺就偷懒一下，只点评几个特别重要的协议。

　　HTTP 协议
　　如果让俺评选最重要的业务层协议，俺首推 HTTP 协议。互联网的普及推动了 Web 的普及，而 Web 的普及使得 HTTP 成为信息时代的重要支柱。当你上网的时候，你看到的网页（HTML 页面）就是通过 HTTP 协议传输到你的浏览器上。
　　如今 HTTP 已经不仅仅用来展示网页，还有很多业务层的协议是建立在 HTTP 协议之上。比如说：如果你用 RSS 订阅俺的博客，RSS 阅读器需要调用 blogspot 博客平台提供的 RSS 接口，这些 RSS 接口就是基于 HTTP 协议传输滴。
　　考虑到本文的篇幅，俺不可能在这里细聊 HTTP 协议的规格，有兴趣的同学可以去看《HTTP 权威指南》这本书。

　　SSL/TLS 协议
　　最早的 HTTP 协议是【明文】滴；为了强化安全性，后来又设计了 SSL 协议，用来【加密】HTTP 流量；再后来，SSL 升级为 TLS（这俩是同义词）。如今经常看到的 HTTPS 相当于“HTTP over TLS”。
　　SSL/TLS 设计得比较优雅（很灵活），使得其它业务层的协议可以很方便地架构在 SSL/TLS 之上。这样的好处是：其它协议就不用自己再设计一套加密机制＆认证机制。
　　SSL/TLS 对于安全性很重要，因此俺专门写了一个系列教程（如下），详细介绍该协议的技术细节。
《扫盲 HTTPS 和 SSL／TLS 协议》（系列）

　　域名相关的协议（DNS 及其它）
　　域名相关的协议，也很重要。因为域名系统是整个互联网的基础设施。最早的域名查询协议是“DNS 协议”，由于这个协议【没有】加密，导致了一些安全隐患。比如 GFW 就利用 DNS 的这个弱点，搞“域名污染/域名投毒”。因此，后来又设计了一系列新的域名协议，引入了加密的机制。
　　关于这些协议的扫盲教程，可以参考如下几篇博文：
《扫盲 DNS 原理，兼谈“域名劫持”和“域名欺骗／域名污染”》
《对比4种强化域名安全的协议——DNSSEC，DNSCrypt，DNS over TLS，DNS over HTTPS》

◇业务层相关的【网络设备】

　　应用层防火墙（application firewall）
　　前面提到了：大多数网络防火墙处于4层（状态防火墙），另外还有少数处于7层，也就是“应用层防火墙”（有时候也称之为“7层防火墙”）。
　　一般来说，这类防火墙具备了【深度包检测】（deep packet inspection，简称 DPI）的能力，可以分析应用层协议的【内容】。
　　简单说一下“深度包检测”：
　　如果某个网络设备，仅仅分析“应用层协议”本身，它还【不够格】称之为 DPI。为了做到 DPI，还要能理解应用层协议所承载的【内容】。
　　比如说：某人通过【明文】的 HTTP 协议从网上下载了一个 zip 压缩包。对于这个下载行为，那些做得好的 DPI 设备不光能识别出“HTTP 协议的内容是 ZIP 压缩包”，而且还能从 ZIP 压缩包中提取出里面的文件。

　　入侵检测（intrusion detection system）
　　一般来说，“入侵检测”如果不加定语，通常指“【网络】入侵检测”（洋文叫 NIDS）；另外还有一种“【主机】入侵检测”（洋文叫 HIDS）。HIDS 与本文无关。
　　“入侵检测”是一种网络安全设备，它通过嗅探（sniffer）的方式抓取网上的数据包，然后进行分析，尝试发现网络中是否存在黑客/骇客的入侵的行为。故名“入侵检测”。
　　由于 IDS 需要理解【应用层】（7层）的内容，因此它与“应用层防火墙”有个共同点，需要具备某种程度的 DPI（深度包检测）能力。它俩的一大差异是【部署方式】。
　　考虑到很多读者是 IT 外行，简单说一下“旁路部署”——
如果你学过中学物理，应该知道电路有“串联 ＆ 并联”。所谓的“旁路部署”类似于电路中的【并联】。通俗地说：IDS 是【并联】部署，防火墙是【串联】部署。

　　GFW（Great Firewall）
　　本博客已经写了很多翻墙教程，大伙儿肯定都知道 GFW 了。
　　由于“Great Firewall”中有“Firewall”字样，很多天朝网民【误以为】GFW 是防火墙，其实不然！GFW 本质上就是 IDS——其部署方式类似于 IDS（旁路部署），其工作方式有很大一部分也类似于 IDS（当然啦，GFW 的功能比 IDS 更多）。
　　大约七八年前，就有热心读者建议俺写一篇技术博文，介绍 GFW 的工作原理。由于俺比较懒，拖到今年（2021）都没动手，很惭愧 :(

★杂项

　　有些概念，并不属于某个特定的层次，单独放到这个章节。

◇VPN（virtual private network）

　　咱们天朝的网民使用 VPN，一多半是为了翻墙。其实 VPN 的本意（如其名称所示）是为了提供某种虚拟化的私有的网络，让身处异地的多个人，可以用 VPN 构建出一个虚拟的内网，从而能在这个内网中协同工作。
　　VPN 的类型很多，使用的技术也各不相同，因此 VPN 对应的 OSI 层次很宽（“1层”到“6层”）。俺到维基百科剽窃了如下这张图，让你见识一下 VPN 的多样性。


（名目繁多的 VPN，分类示意图）

◇代理（proxy）

　　那些经常翻墙的同学，对“代理”应该都很熟悉了。“代理”与 VPN 类似，一开始并不是用来翻墙滴，“翻墙”只是这俩的副业。

　　代理服务器（proxy server）
　　“代理服务器”部署在“客户端 ＆ 服务端”之间，起到某种“中介”的作用。“代理服务器”的类型有很多，干的事情各不相同。


（“代理服务器”的简单示意图）
　　代理客户端（proxy client）
　　早期的代理服务器，【不】需要“代理客户端”。因为早期的“代理服务器”支持的是【标准协议】。比如“HTTP proxy server”支持的是标准 HTTP协议，而用户的电脑上，已经有浏览器（原生支持 HTTP 协议）。这种情况下，自然不需要再有“代理客户端”。
　　后来，为了满足某些特殊需求（比如翻墙），“代理服务器”必须使用某种特殊的（非标准的）协议。因此，就必须在用户的环境中安装“代理客户端”。对于翻墙来说，你装的翻墙软件，相当于“代理客户端”。

　　代理的层次
　　“代理”也分不同的层次。比较常见的有如下几种：

TCP 代理（TCP 端口转发）——4层（传输层）
SOCKS 代理——5层（会话层）
HTTP 代理——7层（应用层）
......

◇网关（gateway）

　　前面的某些章节，已经稍微提及了“网关”这个概念，但还没有具体介绍它。
　　严格来讲，“网关”是一个逻辑概念，【不要】把它当成具体的网络设备。充当“网关”的东东，可能是：路由器 or XX层交换机 or XX层防火墙 or 代理服务器 ......
　　“网关”也分不同的层次。如果不加定语，通常指的是“3层网关”（网络层网关）。列几种比较常见的，供参考：

路由器充当网关——3层（网络层）
3层交换机充当网关——3层（网络层）
4层交换机充当网关——4层（传输层）
应用层防火墙充当网关——7层（应用层）
代理服务器充当网关——（取决于代理的层次，参见前一个小节）
......

◇隧道协议（tunneling protocol）

　　所谓的“隧道协议”，通俗地说就是：用某种协议包裹另一种协议，以满足某些特殊的需求。
　　看到这里，估计某些同学会感到纳闷——因为俺在本文开头介绍“协议栈”的时候提到说：相邻的两层协议，下层会包裹上层。“隧道协议的包裹”与“上下层协议的包裹”，差别在哪捏？
　　俺来解释一下：
　　“隧道协议”可以做到更灵活的包裹——既可以对层次相隔很远的协议进行包裹，也可以对同一层的协议进行包裹，甚至可以“倒挂”——所谓的“倒挂”就是让【上】层反过来包裹【下】层。
　　举例：
　　俺曾经写过一篇《如何让【不支持】代理的网络软件，通过代理进行联网（不同平台的 N 种方法）》，其中介绍了“HTTP 代理”的两种模式：“转发模式 ＆ 隧道模式”。对于“HTTP 代理”的隧道模式，可以实现【TCP over HTTP】（把 TCP 协议打包到 HTTP 协议内部），这就是刚才所说的“倒挂”。
　　另外，VPN 小节的那张图中，有些类型的 VPN 就是用“隧道协议”的机制实现。

◇（其它杂项）

　　可能还有一些杂七杂八的东东，没来得及聊。如果你觉得有些【网络相关】的概念，不太明白，欢迎到博客留言，进行反馈。
　　俺会根据大伙儿的反馈，再对这篇教程进行补充。

★参考书目

　　如下几本书，都在俺的网盘上分享了电子版。

中文书名	英文书名	作者
《计算机网络》	《Computer Networks》	Andrew Tanenbaum David Wetherall
《计算机网络——自顶向下方法》	《Computer Networking——A Top-Down Approach》	James Kurose Keith Ross
《TCP-IP 详解》	《TCP-IP Illustrated》	Richard Stevens
《UNIX 网络编程》	《UNIX Network Programming》	Richard Stevens
《HTTP 权威指南》	《HTTP——The Definitive Guide》	David Gourley Brian Totty Marjorie Sayer Sailu Reddy Anshu Aggarwal

俺博客上，和本文相关的帖子（需翻墙）：
《扫盲 HTTPS 和 SSL／TLS 协议》（系列）
《扫盲 DNS 原理，兼谈“域名劫持”和“域名欺骗／域名污染”》
《对比4种强化域名安全的协议——DNSSEC，DNSCrypt，DNS over TLS，DNS over HTTPS》
《如何隐藏你的踪迹，避免跨省追捕》（系列）
《扫盲 netcat（网猫）的 N 种用法——从“网络诊断”到“系统入侵”》
《如何让【不支持】代理的网络软件，通过代理进行联网（不同平台的 N 种方法）》
《聊聊分布式散列表（DHT）的原理——以 Kademlia（Kad） 和 Chord 为例》
《扫盲操作系统虚拟机》（系列）
《扫盲 Linux＆UNIX 命令行——从“电传打字机”聊到“shell 脚本编程”》
《如何【系统性学习】——从“媒介形态”聊到“DIKW 模型”》
《学习技术的三部曲：WHAT、HOW、WHY》