公钥基础设施（PKI）是当今互联网世界的安全基石，它可以帮助我们确认通信双方的身份，防止数据被窃听或篡改。

简单回忆一下经典的互联网身份验证过程，浏览器向服务器请求网站的 HTTPS 证书，验证证书所代表的网站是否就是被访问的网站，如果不是则停止通信，以避免中间人攻击。

浏览器不仅要确定证书所代表的网站是否正确，也要确定证书本身是否是伪造的。所以浏览器会存储一些受信任的证书签发机构（CA），只要是他们签发的证书都被认为是可信的。

不过 CA 并不总是可信的：

• CA 可能会出于某些原因签发用于攻击证书。
• CA 被黑客控制，签发了用于攻击的证书。
• CA 因为操作失误/系统故障等原因签发了错误的证书。

比如说如果我拿到了一个网站的证书，但这个网站并不属于我，我就可以窃听，篡改这个网站的通信。

证书透明机制（Certificate Transparency）即 CT 机制可以缓解这个问题。

何为透明？

从上文来看，如果某个 CA 签发了不合规的证书，只要我们及时吊销它，就不会有被攻击的风险。所以问题的关键就是如何及时发现不合规的证书。

证书透明机制维护了一个向所有人公开的日志数据库，所有加入到 CT 机制的 CA 签发的每一个证书都会被记录到这个数据库中。所以所谓透明就是把 CA 的签发所有证书都公开，这样一旦 CA 乱搞很快就会被发现。

CT 机制下 CA 如何签发一张证书？

1. 网站所有者向 CA 请求签发一张属于自己的证书。
2. CA 机构验证申请者的身份，并首先生成一张 “预证书”（precertificate），并将这张证书提交给 CT 数据库。下文将解释什么是预证书，以及为什么需要它。
3. CT 数据库接收到预证书后，立即将 “证书签名时间戳”（signed certificate timestamp）返回给 CA，并承诺预证书会在某个时间点之后被写入到 CT 数据库。这个时间戳会被 CT 签名，确保不给伪造。
4. CA 将这个时间戳写入证书中，签名，成为最终的证书。
5. 将最终的证书返回给网站所有者。

我们首先来解释一下 “预证书”。

CT 数据库需要知道证书的全部内容才能将其写入到数据库，CA 机构需要 “证书签名时间戳” 才能生成最终的证书。但是生成最终证书需要 CT 提供 “证书签名时间戳”，CT 又需要知道证书的全部内容才返回这个时间戳，

“预证书” 可以解决这个问题，”预证书” 包含了最终证书的所有信息（除了 “证书签名时间戳”），同，时它被标记为不可用，不会被浏览器识别为有效的证书。

由于 “预证书” 包含了最终证书几乎所有的信息，所以存储这张证书依然可以建立与最终证书对应关系。所以 CT 可以放心地将 “证书签名时间戳“ 返回给 CA，并由 CA 签发最终的证书。

回到证书签发流程，我们会发现 CT 并不关心一张证书的签发是否合规，它只是如实地记录每一个被签发证书，以及签发这个证书 CA。

CT 机制如何保证安全？

为了及时发现不合规的证书，就需要有人监视这个数据库的变动。

利益相关方比如 Google，会监控数据库的变动，如果它发现有自己以外的 CA 签发了 Google 的证书，那么 Google 可以立即将这个发现公之于众，然后在自己的浏览器（Chrome）中吊销这个证书，鉴于 Chrome 的市场份额，这可以很大程度地保持安全。

同时许多浏览器（Chrome，Safari 等）会强制证书加入 CT 机制，这些浏览器会验证 “证书签名时间戳” 是否来自受信任的 CT 数据库，如果不是则中断通信。

你可能会疑惑为什么浏览器不直接去 CT 数据库查询对应的证书，一部分原因是这种做法等同于向 CT 数据库发送自己的浏览器历史记录。

为什么 CA 和浏览器要参与到 CT 机制？

CT 机制是增强安全措施，如果 CA 拒绝加入会被公众怀疑你的证书是否合规，浏览器拒绝加入则会让用户怀疑使用你的浏览器是否安全。

Google 是这项机制的重要推动者，如果 CA 不加入 CT，那么你签发的证书很可能不被市场份额极高的 Google Chrome 所信任。

谁来确保 CT 不会作恶？

整个证书签发和写入数据库的流程都由密码学提供保证，任何人都不可能篡改已经写入数据库的信息。所以 CT 作恶的唯一方式就是照常签发 “证书签名时间戳”，但是不将证书写入数据库以避免来自外部的审查。

所以要成为浏览器信任的 CT，需要满足一些条件，随便举几个例子。

• CT 能够在指定时间内将证书信息写入数据库。
• CT 服务的停机时间不能超出某个时间范围。
• ······

每个浏览器的审核标准也不同，必须满足标准才会被浏览器信任。比如你可以查看 Google Chrome 的审核标准。

CT 和 CA 依然有机会作恶

是的，CT 机制并不能解决这个问题，但是它让这个问题变好了。

参考资料

• https://certificate.transparency.dev
• What are SSL Precertificates?

2020 年 10 月 12 日部分网友称自己的手机的时间与北京时间相差较大，慢了几分钟到十几分钟不等，目前已经恢复正常。

相关新闻：部分安卓手机时间变慢 北京移动：个别基站出了问题-太平洋电脑网

有趣的是，「格林尼治国际标准时间」就是在 135 年前的 10 月 13 日诞生的，而今天又是「世界标准日」。那就来简单介绍一下机械钟、石英钟和原子钟原理吧。

机械钟

机械钟的背后是「摆的等时性原理」，简单来说就是对于一个摆，它的周期与重物的质量和数量无关。

$$
T=2 \pi \sqrt{\frac{L}{g}}，L 是摆长，g 是重力加速度。
$$

经过简单的计算可以知道当 $L=1m$ 时 $T \approx 2s$，也就是说一个摆长为 1 米的单摆它的周期大概是 2 秒。机械钟的原理就是这个。

摆钟是机械钟的一种，其中有一个结构叫做「擒纵器」，它的工作过程大概是这样的。

当重物摆动到最左端的时候擒纵器会卡住齿轮的右端，摆动到最右端的时候擒纵器会卡住齿轮的左端，无论卡住哪一端都会让齿轮停止运动、如果摆长是 1 米，那么就是大约每秒就会卡住一次齿轮，只要齿轮的转速和半径合适，就可以通过齿轮和擒纵器制作出秒针，再通过齿轮传动制作出分针和时针，然后一台摆钟的核心部分就做完了。我们听到的嘀嗒嘀嗒声就是擒纵器卡住齿轮时发出的声音。

石英钟

石英晶体本身会按照自身的「固有频率」进行震动，「固有频率」只与物体的本身属性有关，所以非常稳定，但是这个震动十分微弱，难以测量，那么我们就需要将这种震动放大。

石英钟背后的原理是「压电效应」，即某些电介质在发生形变的时候其表面会产生正电荷和负电荷，形变消失后正负电荷也会消失。当对其施加电场时，它也会发生形变，电场消失形变也随之消失。石英晶体就是具有「压电效应」的电介质之一。

有了「压电效应」后，我们可以对石英晶体施加交流电，当交流电的频率与石英晶体的「固有频率」相近时元件其震动就会变强，也就更容易测量。然后我们通过电路去测量这种震动，然后通过转换将其变为 1 Hz 的方波，用这种脉冲去驱动电机来驱动指针旋转，再通过传动装置制作出分针和时针，石英钟的核心部分就完成了。

石英钟的精度差不多 270 年才差 1 秒。

原子钟

原子是有能级的，通常都是在最低能级，处于最低能级的原子称为基态原子。如果一束光打到原子上，只要光的频率合适，就可以让原子跃迁到更高的能级，称为激发态原子。光消失后原子会自发地跃迁到最低能级，也就是回到基态，这个过程会释放光，这个光的能量与入射的光的能量是一样的。下文称能让铯原子跃迁激发态的光的频率为目标频率。

我们难以精确稳定地发出目标频率的光，但是我们可以使得光的频率稳定地在目标频率的周围变化。我们就用这种光打在铯原子团上，光的频率越接近目标频率，处于激发态的铯原子就会越多。然后我们就可以通过测量激发态原子的多少来确定当前的光的频率有多接近目标频率。

测量方式时检测激发态铯原子跃迁到基态时释放的光的强度。因为激发态的铯原子越多，回到激发态释放的光的铯原子也就越多，测量到的光强也就越大，我们会在横轴为照射频率，纵轴为光强的坐标系上看见看见峰值，这个峰值对应的光的频率就是最接近目标频率的光，下文称这个频率为 $f_0$

由于照射的频率在不断变化，新的峰值也会不断出现，这可以让我们不断地去矫正 $f_0$，$f_0$ 也会越来越接近目标频率。

然后我们将 $f_0$ 频率的光处理为电信号，通过电路去记录震荡次数，由于铯原子的振动频率时已知的，即 9192631770Hz，所以电路每振荡 9192631770 次就过了一秒。这种装置称为铯原子喷泉原子钟（Cesium Fountain Atomic Clock）。

原子钟的精度十分高。2015 年 NASA 的 Deep Space Atomic Clock，可以做到 100 亿年的误差不超过 1 秒。

本文章属于虚拟化技术系列文章，点击查看本系列的说明。

阅读本文请先阅读下面的虚拟化技术的术语以了解相关术语。

IA-32 架构面临的挑战

IA-32 架构起初并不是为了虚拟化设计的，它的目标是在处理器上运行最多一个操作系统，所以在 Intel VT 出现之前， IA-32 架构上的虚拟化解决方案就只有纯软件虚拟化了。

IA-32 架构的权限等级

Intel 处理器提供了四种权限级别，分别为 Ring0、Ring1、Ring2 和 Ring3，权限依次降低，Ring0 拥有最高权限。所以一些特权指令只能在 Ring0 下才可以正常使用。大多数 IA-32 架构的应用运行在 Ring3。

然而一些操作系统的组件必须运行在 Ring0，但是要实现纯软件的虚拟化就必须让 VMM 独占 Ring0。因为 VMM 要虚拟化出若干组硬件来供 GuestOS 使用，这就要保证 GuestOS 不能直接控制物理硬件。

特权解除和陷入模拟

因此出现了一种技术被称为“特权解除和陷入模拟”。

特权解除是指将 VMM 运行在 Ring0，而虚拟机中的操作系统运行在 Ring1。这样就可以保证 GuestOS 无法越过 VMM 去执行特权指令导致虚拟化失效。

同时由于 IA-32 架构下运行特权指令的时候如果权限不足会自动陷入权限更高的 Ring 中。所以当 GuestOS 执行特权指令的时候会陷入 Ring0，此时由 VMM 接管并模拟特权指令的执行，这就叫陷入模拟。

不幸的是整个过程没有看起来那么简单。究其根本是因为虚拟机中的软件并不是为了虚拟化而编写的。

有的指令在非 Ring0 下运行会返回一个包含当前 Ring 值的返回值，GuestOS 会去读取这个值，一旦发现自己没有运行在 Ring0 下就会出现错误。这也就导致了这类指令的调用无法被 VMM 检测到，自然也就无法模拟了。

另一个问题是操作系统在编写的时候并没有支持操作系统级的上下文切换，所以一些上下文可能会在很隐蔽的角落。当 VMM 切换上下文的时候这些信息就会丢失导致错误。

并非只有这些问题，受限于篇幅问题就不再多说了，读者有兴趣可以自行查阅资料。

纯软件解决方案

为了应对这些挑战，设计人员给出了两种软件层面的途径去开发 VMM，分别是半虚拟化（Paravirtualization）和二进制翻译（Binary Translation）。

半虚拟化（Paravirtualization）

这种方法需要修改 GuestOS 的源代码使得其可以在特定的 VMM 下运行。比如敏感指令替换为 hypercall。hypercall 直译为超级调用，可以陷入到 VMM 中以便 VMM 去模拟指令的运行。

这种方式的好处是基本没有性能损失。但是坏处也很明显，它只能用于开源的操作系统，比如 Linux。

二进制翻译（Binary Translation）

这个方法是将 GuestOS 的二进制指令翻译为另一种类指令，通常是翻译为 vCPU 可以识别的指令。它的特殊之处在于大多数情况下我们都是将源代码或者 IR（Intermediate Representation） 翻译为二进制代码，但是二进制翻译是将二进制代码翻译为另一类代码。按照翻译的时机分类又分为静态翻译和动态翻译。

静态翻译（Static Binary Translation）

即在运行 GuestOS 前一次性地将全部的代码翻译为目标指令。这样做可以最大限度地提高性能，但是这个方法实际上并不可行。

最大的难题是冯·诺依曼体系结构下指令和数据存储在一个存储器上，并未区分指令存储器和数据存储器。也就是说对于一堆静态的二进制数据，我们无法确定它到底是代码还是数据。这也就导致静态翻译可能错误地将数据翻译为代码从而导致错误。

还有一个问题是有些程序会在运行时修改自己，而静态翻译是一次性的，这也会导致错误。

动态翻译（Dynamic Binary Translation）

动态翻译就是在运行时以一种类似按需翻译的方式去翻译 GuestOS 的二进制指令。这可以很好地解决静态翻译带来的问题。

因为只会翻译被执行的部分，所以不会错误地将数据翻译为二进制代码。同时由于翻译并不是一次性地工作，也可以解决程序修改自身所带来的问题。

不过实际实现起来会有很多问题，比如何时启动翻译、翻译什么和翻译多少。这也是本系列的后续任务，将会简单地介绍一些实现动态翻译中遇到的问题和解决方法。本文在这一点不做过多讨论。

参考资料

• An Introduction to Virtualization
• CSE 598 Binary Translation Report
• Dynamic Binary Translation

本文章属于虚拟化技术系列文章，点击查看本系列的说明。

宿主机（Host Machine）

宿主机是运行虚拟机的物理机，是真实地存在于物理世界的机器。它包含如 CPU，内存和网卡等物理资源。

虚拟机（Virtual Machine）

虚拟机是对物理机虚拟化后的结果，并由虚拟化软件运行和维护。

客机操作系统（GuestOS: Guest Operating System）

指运行在虚拟机中的操作系统。

虚拟机管理程序/虚拟机监视器（Hypervisor/VMM）

实际上就是管理虚拟机和实现虚拟化的程序。在比较老的资料里这两个名词可能是不同的概念，即 Hypervisor 是直接运行在硬件上的，而 VMM 是运行在软件上的，但貌似目前这两个名词已经差不多一样了，不需要去可以区分了。

半虚拟化（Paravirtualization）

通过修改操作系统的源代码实现的虚拟化，比如将一些敏感指令（可能导致虚拟化出错的指令）修改为 hypercall 使 VMM 可以模拟这类执行的执行以避免错误。

全虚拟化（Full virtualization）

即不修改操作系统的源代码就可以实现的虚拟化。

虚拟 CPU（vCPU）

指 VMM 虚拟出来的供虚拟机使用的 CPU，并不存在于物理世界中。

参考资料

• An Introduction to Virtualization

本文章属于虚拟化技术系列文章，点击查看本系列的说明。

在我们了解如今成熟稳定的虚拟化技术之前，有必要去了解一下它的发展史。因为虚拟化并不是一项全新的技术，而是基于之前的努力。

1950年 – 1990年

虚拟存储器的概念可以追溯到 20 世纪 50 年代末，当时曼彻斯特大学的一个小组在 Atlas 系统（一种晶体管计算机）中引入了自动换页功能，其原理是将分页作为一种在内存层次结构之间存储和传输数据的方法。虽然这个原理之前就有，但Atlas是第一个将这一过程自动化，从而提供了第一个虚拟存储器的工作原型。

虚拟机这个词可以追溯到20世纪60年代，最早的虚拟机系统来自 IBM。1967 年前后，IBM 推出了型号为 67 的 System/360，它是第一个带有虚拟存储器的系统。这个系统中有一个概念名为处理器虚拟化指令集，这个概念也在也在后续的型号中得到完善。起初这个系统被称为 CP-67，之后就演化成了虚拟机系统。虚拟机允许在一台处理机上运行多个操作系统。本质上来说虚拟机和硬件通过合作来启动多个操作系统，让它们可以受保护地访问完整的指令集。

20 世纪 60 年代中期，IBM 还率先推出了 M44/44X 项目，探索新兴的分时概念。系统架构的核心是一组虚拟机，每个用户可以使用其中的一个。宿主机是 IBM 7044（简称 M44），每个虚拟机是 7044 的实验镜像（简称44X）。这项工作最终促成了虚拟机/分时系统，包括 IBM 著名的 VM/370。

硬件虚拟化的概念也是在这个时期出现的，VMM 可以在一个隔离和保护的环境中运行虚拟机。因为 VMM 对运行在虚拟机中的软件来说是透明的，软件认为它独占控制权。随着时间的推移，这一概念得到了完善，最终 VMM 只会消耗较少的性能和资源。

20 世纪 70 年代中期，虚拟化技术已经在各个操作系统被用户所接受。在这几十年中，虚拟化技术解决了许多重要问题，例如应用还在大规模操作系统中虚拟存储器使得应用程序的编程变得简单，因为程序员不需要像以前那么关心内存不足的问题。

虚拟出来资源是很便宜的，但是真实的物理资源却很贵，虚拟资源可以让我们按需分配这些昂贵的物理资源以获取最大的利益。比如现在厂商可以将多余的算力虚拟化成一个个的云服务器出售给客户。

虽然在 20 世纪 60 年代和 70 年代，硬件级虚拟机在研究和商业市场上都很流行，但在 20 世纪 80 年代和 90 年代，它们基本上消失了。因为低成本的微型计算机和 PC 进入市场导致了虚拟化的需求在总体上有所下降。

顺便一提，另一种类型的虚拟机在历史上仍有一席之地，典型的代表就是 JVM 和 微软的 CLR。这一类型的虚拟机不是本文所要介绍的虚拟机，它们并不虚拟化出一个硬件平台，而是为编程语言提供可移植性。所以请不要混淆概念。

虚拟化的重新兴起

20 世纪 90 年代，企业部署的服务器数量越来越多，但是服务器资源的利用效率却越来越低。

一个服务器仅仅部署一个应用会大量浪费服务器的硬件资源。一个服务器部署多个应用则会遇到更为严重的问题，比如其中一个应用崩溃了可能会带着整个服务器崩溃，那么这台服务器上所有的应用都会停止。又比如某个应用更新后需要重启服务器，但是这台服务器上还有别的应用，所以其它应用也被迫重启。

服务器数量的激增带来了部署、更新和支持方面的挑战，以及安全和灾难恢复方面的问题。

虚拟化技术很好地解决这一问题。可以在一台宿主机上虚拟出多个虚拟机，每个虚拟机仅部署一个应用。由于每个虚拟机时互相隔离的，所以崩溃一个其它的依然可以正常运行，上面的问题也就迎刃而解了。

虽然虚拟化技术重新兴起，但是开发用于虚拟化的操作系统和软件是一件十分复杂的事情。Intel VT 的出现消除或大大减少了其中的一些复杂因素。Intel 开始与 VMM 的开发者合作，在 Intel 处理器和芯片组中实现硬件辅助虚拟化，并推动相关规范的制定以促进虚拟化在未来的发展。

参考资料

• An Introduction to Virtualization

出于利益等原因，许多校园网采取一机一号的管理方式。即一个宽带账号只能由一台规定的设备使用。同时检测共享上网以避免使用路由器或类似方式实现共享。那么这些限制背后的原理是什么呢？

一机一号的原理

目前大多数校园网的拨号协议依然是 PPPoE，所以要知道一机一号的原理就要先粗略了解一下 PPPoE 。

PPPoE 的全称是（Point-to-Point Protocol Over Ethernet），即以太网上的点对点协议。以太网本身不具有身份验证功能 但是 PPP 可以，所以将 PPP 引入以太网可以满足 ISP 对用户身份的验证需求。

PPPoE 运行在 OSI 的数据链路层，TCP/IP 体系结构的网络接口层，同时由于它只在拨号时起作用，所以此时没有 IP 地址起作用，由此可以推测如果要实现一机一号，关键的信息之一是 MAC 地址。事实上也确实如此。

PPPoE 拨号时会在「发现」阶段向以太网中发送广播，表示自己想要找到一个可以提供网络服务的节点，并在广播中说明自己的 MAC 地址。ISP 的节点接收到消息后会回应这个广播并说明自己的 MAC 地址，然后两个节点就建立了会话。此后便使用 PPP 通信，通信过程中就包含了身份认证过程。

注意到此时 ISP 的节点只有拨号设备的 MAC 地址和宽带的账号和密码。看来答案已经出现了。ISP 通过维护宽带账号和 MAC 地址的一一对应的关系来实现一机一号。只要发现 MAC 地址和宽带账号不匹配直接报错就行了。

共享上网检测的原理

仅仅一机一号还不够，因为可以通过路由器实现多人共用同一个宽带。路由器通过 NAT 让多个内网 IP 共用一个 IP 与 ISP 节点通信，这给共享上网的检测带来的困难，但依然有一些方法。

检测 IP 报文头 identification 字段

上图就是 IP 报文头的结构，第二行的左边就是需要被检测的字段，下面是该字段的说明。

An identifying value assigned by the sender to aid in assembling the fragments of a datagram.

RFC-791

看起来似乎不能用来检测共享上网？单单这样看确实不能，但是 Windows 网络协议栈在实现的时候这个值是随着 IP 报文的发送数量的增加而增加的，且初始值是一个随机数。所以对于使用 Windows 的设备来说，它们的 identification 的初始值通常是差距很大的，所以可以用来检测共享上网。

值得一提的是这并不适用于 Linux、Unix，因为它们的 identification 的值是完全随机的，没有规律可循。

TTL 检测

TTL是 Time To Live的缩写，该字段指定IP包被路由器丢弃之前允许通过的最大网段数量。

TTL（生存时间值）_百度百科

不同的操作系统的 TTL 可能是不同的，所以如果检测到两个不同的 TTL 则可以断定网络中有两台设备。

时间戳检测

不同物理机的时钟偏移通常是不同的，这也就使得物理时钟会与协议栈时钟之间存在一种通常不同于其它设备的特殊的联系。同时主机发送报文的频率与时钟又存在统计上的关系，所以可以通过这一点来检测出又几种不同的时钟偏移从而检测网络中的设备数量。

深度报文检测（DPI）

DPI（Deep Packet Inspection）是一种基于数据包的深度检测技术，针对不同的网络应用层载荷（例如HTTP、DNS等）进行深度检测，通过对报文的有效载荷检测决定其合法性。

DPI（深度报文检测）_百度百科

主要通过检测应用层的报文来判断设备数量。

比如通过检测 Http.UserAgent 字段来判断。一个用户使用的浏览器通常是固定的，而浏览器发送请求时所使用的 UserAgent 也是相对固定的。在排除一个用户设备上的许多客户端应用也使用 HTTP 协议的情况下，如果一个网络中的 Http.UserAgent 有许多不同的值，则可以怀疑这个网络中有许多不同的设备在上网。

参考资料

• RFC 2516 – A Method for Transmitting PPP Over Ethernet (PPPoE)
• RFC 791 – Internet Protocol
• 电信是怎样查出多台电脑共享上网的？ – 稍有常识的人的回答 – 知乎

不讨论细节，旨在勾勒出区块链的轮廓。由于是以介绍为主，所以不会涉及细节，而且**肯定会有一些错误**。如果有兴趣的话可以自行查询资料。

故事

我们先讲个故事：张三是一个三年级的学生，他的父母是做生意的。有一天管帐本的妈妈把账本弄丢了，付出了很大的代价才搞清楚资金的来龙去脉，于是父母商量了一下决定，爸爸和张三每次收支都要告诉妈妈，由妈妈记录这一笔帐，并每天晚上将账本公布，账本开头写上昨日三人的期初余额，结尾写上三人的期末余额。爸爸和张三检查无误后各自抄走一份，如果公布的账本有误则认为是假账，则选择昨日公认的账本作为今天的账本，今日的所有支出作废，损失由妈妈承担。

检查账本时都要检查下列项目：

• 每笔交易是否有资金支出者的签名
• 资金支出者是否有足够的钱支付
• 今日的收支是否计算得出账本结尾声明的三人的期末余额
• 今日账本三人的期初余额和昨日账本三人的期末余额一致

Q：妈妈是否可以记录一些虚假的交易，比如妈妈擅自记录一笔爸爸转给妈妈 100 块钱的账？

A：不可能，因为这笔转账必须由爸爸的签名才行，如果没有签名则晚上爸爸和张三检查账本的时候会被认为是假账，而损失却由妈妈自己承担。

Q：张三是否可以假装爸爸发给妈妈一笔给自己买零食的交替？

A：不能，因为没有爸爸的签名。

时间一长，妈妈发现记账很累，于是要求每记一笔账都要求支出放支付一块钱给妈妈。后续爸爸和张三发现妈妈记账很赚钱，于是想要自己来记账。一家人商量后达成一致，每个人都将自己的交易发送给其它两人，到了晚上汇总的时候，通过抽签选择采用谁的账本，并给予记账人报酬

有一次爸爸妈妈一起出差了，抽签抽到爸爸记账，但是爸爸很忙，没时间把账本给张三看，导致张三无法抄写今天的账本。后来一家人商量后达成一致，当允许抄写记账人以外的账本。比如爸爸很忙，但是妈妈有空，妈妈抄完后可以让张三抄。

解释

这个故事描述了区块链的大致工作流程和特点。
区块链中的就是故事中的账本，每天产生一个账本就是每天产生一个「区块」。「链」对应的就是昨日账本的期末余额和今日账本的期初余额，两种余额将两个账本连接在一起，对应将「区块」连接依赖的「链」。

区块链的特点

• 分布式：对应故事中账本并不是只有记账人有，其它人也有一份。对应现实中数据不只有一份，而是有很多份，在不同的地方存储。
• 去中心化：对应故事中对账本起决定作用的人不是记账人，只有一家三口都认同的账本才是有效账本。对应现实中一份数据的内容究竟是什么不是一个人或者一个组织能够决定的，而是要大多数参与者达成共识才能决定。
• 点对点：对应故事中抄写账本时可以从任何持有账本的人手中抄写一份，而不是必须从记账人手中抄写。对应现实中一个节点请求数组不是请求中心节点，而是请求任意一个节点即可。
• 难以篡改：对应故事中任何人都无法伪造账本中的交易记录，因为必须要有签名。对应现实中依靠密码学保证的防篡改功能。

区块链的工作流程

1. 利用共识选择出一定时间段内的数据的管理员：对应故事中一家三口通过抽签决定记账人。
2. 当数据发生改动时要对所有的节点进行广播：对应故事中一家三口在晚上决定记账人钱必须将自己的交易告知其余两人。
3. 对于数据管理员公布的数据要进行检查：对应故事中要对账本进行的四种检查。
4. 如果检查错误则回滚数据：对应故事中如果检查有误，则选择昨日公认的账本作为今天的账本，今日的所有支出作废。
5. 如果检查无误则复制一份保存在本地：对应故事中没人都会抄写一份账本。

写在最后

本文是指介绍了一下区块链的特点时大致工作流程，并未涉及细节问题，如果有兴趣的话可以自行查询资料。

你可能在电视剧中看到坏人威胁主角的时候会拿出作为人质的亲人写的信，而主角一看笔迹就知道是亲人所写的了。

在这里笔迹起到了两个作用：

• 证明信的内容确实是亲人所写
• 证明内容没有被篡改过

在计算机的世界中，我们同样需要对信息一样的验证。

例子

下面是一段在线聊天对话：

• 小明：小红，借我 30w 呗，我去买点水喝。
• 小红：可以，不过你要给我打一个欠条，拍照发过来。
• 小明：没问题，发给你了。
• 小红：好的，明天我把带给你。

此时，这笔借款交易的安全性如何？

• 小红可能会 PS 照片修改借款数字。
• 小明事后可能会抵赖说照片是修改过的。
• 照片可能在传输过程中阴差阳错地出现错误导致欠条内容改变。
• 其它。

这时需要解决的问题就是：

• 如何证明这个照片是小明发给小红的。
• 如何证明这个照片没有被修改过。

此时我们就需要对照片进行数字签名。

前置知识

哈希函数

哈希函数是可以将一段任意长度的信息转化为固定长度信息，这个固定长度的信息称为哈希值。

哈希函数有两个特点：

• 任何长度的原始信息经过哈希函数后都会变成等长度的信息。
• 一旦输入给给哈希函数的信息发生了改变（哪怕是一点点的改变），最终的哈希值就会面目全非。

下面我们用一种叫做`SHA256`的哈希函数举个例子：

原始信息：100000000000000
哈希值：7186c3316577cf7ee0568c6ff7f3227b5b3e4b498e7eabba4f6e3d908e2162f4

原始信息：100000000000001
哈希值：11d77ab50791e10caffb01cb6ff851f4929edfb0ad79808111d78182b0048540

结果很明显，仅仅做一点点改动哈希值都会发生巨大的变化。

非对称加密

非对称加密有两个密钥，一个称为私钥，一个称为公钥。
经过公钥加密的信息只能被相匹配的私钥解密，也就是说同一个公钥不能解密自己加密的信息。私钥加密的信息只有公钥可以解密，也就是说私钥不能解密自己的信息。同时也可以用公钥验证加密的信息是否是相匹配的私钥加密的。

数字签名

签名过程

1. 小明自己生成一对公私钥。
2. 小明计算出欠条照片的哈希值。
3. 小明用私钥对哈希值进行加密形成签名。

签名的过程就完成了。此时小明需要将照片，公钥以及签名发给小红。

验证过程

• 小红用公钥解密签名得到照片的哈希值。
• 小红用公钥验证得到解密出来的哈希值确实是小明的私钥加密的。
• 小红计算出欠条照片的哈希值。
• 将两个哈希值进行对比，如果一样则验证成功，反之则失败。

可见验证成功需要同时满足两个条件：

• 解密出的哈希值与收到的照片的哈希值一致。
• 用公钥证明了哈希值确实是小明的私钥加密的。

第一个条件保证了照片没有被修改过。第二个条件则保证了借款双方都无法抵赖。

你可能会想，如果小明表示小红的公钥不是自己的，或者小红表示自己的公钥不是小明的岂不是还能抵赖？

证书机构

此时我们需要第三方来做公正。小明需要将自己的公钥交给证书机构，证书机构审核后会颁发证书，证明这个公钥是小明的。而且这个证书是公开的，也就是说小红也可以拿到。
此时假如抵赖小明说你的公钥是假的，那么小红就可以指着证书对他：说睁大你的X眼看看，这是你颁发给你的证书，上面已经说了这个公钥是你的。当小红抵赖的时候也可以这么干。

总结

数字签名可以切实有效地地保证双方的信息是没有被修改过的，并且可以明确消息来源。

本文简要介绍HTTPS协议是如何保证数据在传输过程中的安全的。
由于是以介绍为主，所以不会涉及细节，而且肯定会有一些错误。如果想要详细了解可自行查阅资料。

正文

在HTTPS协议出现前大家用的都是HTTP协议，这种协议传输的都是明文信息，任何人都可以窃取并篡改，毫无安全性可言。

HTTP协议的简要通信流程如下图：

由于传输的信息都是明文的，所以攻击者就可以窃取并篡改信息，如下图：

你可能会想，我们把信息加密不就可以了么，比如像下图一样

对称加密：双方持有同一个对称密钥，任何一方通过对称密钥加密的信息，对方可以通过相同的对称密钥解密出原文。

但是攻击者依然可以通过各种方式获取到对称密钥：

• 如果密钥是通过服务器下发给客户端，则直接截取服务器的消息就行了。
• 如果对称密钥是提前保存在双方的电脑上，那就可以通过某种手段入侵客户端或者服务器来窃取对称密钥。
• 其它方式。

截取到密钥后攻击者仍然可以进行攻击

那么我们就需要对“对称密钥”进行保护了，如下图

非对称加密：一方持有私钥，一方持有公钥，使用公钥加密的信息只能被私钥解密。私钥不会用于加密，不过通常会用于加一段签名代表信息是完整，即信息是否丢失了一部分或者因为某种原因而发生的改变。

这次攻击者看似无法通过截取信息来获得对称密钥了，但是攻击者依然有机会发起攻击。

不过先说明一点，目前公钥都是通过服务器下发的证书获得的，所以更接近下图相对来说更接近真实的通信流程

那么攻击者会怎样攻击呢？如下图（图片如果看不清可以右键图片选择“在新的标签页中打开图像”或类似选项）

这时显然不能对公钥再次加密了，因为无法判断客户端得到的证书是真的，还是攻击者伪造的。
这时就需要第三方介入了

1. 合法服务器的证书都是经过审核机构审核的，服务器在下发证书的时候就会下发经过审核的证书
2. 客户端会存有经过审核的证书的列表。
3. 客户端收到服务器下发的证书后会验证收到的证书是否经过了审核。
4. 如果经过了审核则继续通信，反之断开连接或者弹出警告。

现在的通信流程图下图，也是HTTPS的大致通信流程

不过HTTPS的一大软肋就是第三方证书审核机构，如果审核不严将攻击者的证书列入了合法证书列表，那么HTTPS所作的努力将全部白费。

总的来说，HTTPS增加了攻击者的攻击成本，使得数据的传输过程变得更加完全。