计算机网络

• 交换技术的本质，就是让数据切换路径。因为，网络中的数据是以分组或封包（Packet）的形式传输，因此这个技术也称作封包交换技术（Packet Switch）。
• 在一定范围内的区域，离用户较近的地方还可以部署服务器，帮助用户完成计算。这相当于计算资源的下沉，称为边缘计算。相比中心化的计算，边缘计算延迟低、链路短，能够将更好的体验带给距离边缘计算集群最近的节点。从而让用户享受到更优质、延迟更低、算力更强的服务。
• TCP（Transport Control Protocol）是一个传输层协议，提供 Host-To-Host 数据的可靠传输，支持全双工，是一个连接导向的协议。TCP 要实现主机到主机通信，就需要知道主机们的网络地址（IP 地址），但是 TCP 不负责实际地址到地址（Address-To-Address）的传输，因此 TCP 协议把 IP 地址给底层的互联网层处理。互联网层，也叫网络层（Network Layer），提供地址到地址的通信，IP 协议就在这一层工作。互联网层解决地址到地址的通信，但是不负责信号在具体两个设备间传递。因此，网络层会调用下方的链路层在两个相邻设备间传递信息。当信号在两个设备间传递的时候，科学家又设计出了物理层封装最底层的物理设备、传输介质等，由最下方的物理层提供最底层的传输能力
• 什么是连接和会话？连接是通信双方的一个约定，目标是让两个在通信的程序之间产生一个默契，保证两个程序都在线，而且尽快地响应对方的请求，这就是连接（Connection）。连接是网络行为状态的记录。会话是应用的行为。比如微信里张三和你聊天，那么张三和你建立一个会话。你要和张三聊天，你们创建一个聊天窗口，这个就是会话。你开始 Typing，开始传输数据，你和微信服务器间建立一个连接。如果你们聊一段时间，各自休息了，约定先不要关微信，1 个小时后再回来。那么连接会断开，因为聊天窗口没关，所以会话还在。总结下，会话是应用层的概念，连接是传输层的概念。
• TCP 协议的基本操作TCP 协议有这样几个基本操作：如果一个 Host 主动向另一个 Host 发起连接，称为 SYN（Synchronization），请求同步；如果一个 Host 主动断开请求，称为 FIN（Finish），请求完成；如果一个 Host 给另一个 Host 发送数据，称为 PSH（Push），数据推送。以上 3 种情况，接收方收到数据后，都需要给发送方一个 ACK（Acknowledgement）响应。请求/响应的模型是可靠性的要求，如果一个请求没有响应，发送方可能会认为自己需要重发这个请求。
• 断开连接的过程（4 次挥手）继续上面的思路，如果断开连接需要几次握手？给你一些提示，你可以在脑海中这样构思。客户端要求断开连接，发送一个断开的请求，这个叫作（FIN）。服务端收到请求，然后给客户端一个 ACK，作为 FIN 的响应。这里你需要思考一个问题，可不可以像握手那样马上传 FIN 回去？其实这个时候服务端不能马上传 FIN，因为断开连接要处理的问题比较多，比如说服务端可能还有发送出去的消息没有得到 ACK；也有可能服务端自己有资源要释放。因此断开连接不能像握手那样操作——将两条消息合并。所以，服务端经过一个等待，确定可以关闭连接了，再发一条 FIN 给客户端。客户端收到服务端的 FIN，同时客户端也可能有自己的事情需要处理完，比如客户端有发送给服务端没有收到 ACK 的请求，客户端自己处理完成后，再给服务端发送一个 ACK。
• 总之，方方面面的原因：在传输层封包不能太大。这种限制，往往是以缓冲区大小为单位的。也就是 TCP 协议，会将数据拆分成不超过缓冲区大小的一个个部分。每个部分有一个独特的名词，叫作 TCP 段（TCP Segment）。在接收数据的时候，一个个 TCP 段又被重组成原来的数据。像这样，数据经过拆分，然后传输，然后在目的地重组，俗称拆包。所以拆包是将数据拆分成多个 TCP 段传输。那么粘包是什么呢？有时候，如果发往一个目的地的多个数据太小了，为了防止多次发送占用资源，TCP 协议有可能将它们合并成一个 TCP 段发送，在目的地再还原成多个数据，这个过程俗称粘包。所以粘包是将多个数据合并成一个 TCP 段发送。
• TCP Segment那么一个 TCP 段长什么样子呢？下图是一个 TCP 段的格式：

• TCP 协议就是依靠每一个 TCP 段工作的，所以你每认识一个 TCP 的能力，几乎都会找到在 TCP Segment 中与之对应的字段。

1. Source Port/Destination Port 描述的是发送端口号和目标端口号，代表发送数据的应用程序和接收数据的应用程序。比如 80 往往代表 HTTP 服务，22 往往是 SSH 服务……

2. Sequence Number 和 Achnowledgment Number 是保证可靠性的两个关键。具体见下文的讨论。

3. Data Offset 是一个偏移量。这个量存在的原因是 TCP Header 部分的长度是可变的，因此需要一个数值来描述数据从哪个字节开始。

4. Reserved 是很多协议设计会保留的一个区域，用于日后扩展能力。

5. URG/ACK/PSH/RST/SYN/FIN 是几个标志位，用于描述 TCP 段的行为。也就是一个 TCP 封包到底是做什么用的？

1）URG 代表这是一个紧急数据，比如远程操作的时候，用户按下了 Ctrl+C，要求终止程序，这种请求需要紧急处理。

2）ACK 代表响应，我们在“02 | 传输层协议 TCP：TCP 为什么握手是 3 次、挥手是 4 次？”讲到过，所有的消息都必须有 ACK，这是 TCP 协议确保稳定性的一环。

3）PSH 代表数据推送，也就是在传输数据的意思。

4）SYN 同步请求，也就是申请握手。

5）FIN 终止请求，也就是挥手。

特别说明一下：以上这 5 个标志位，每个占了一个比特，可以混合使用。比如 ACK 和 SYN 同时为 1，代表同步请求和响应被合并了。这也是 TCP 协议，为什么是三次握手的原因之一。

6） Window 也是 TCP 保证稳定性并进行流量控制的工具，我们会在“04 | TCP 的稳定性：滑动窗口和流速控制是怎么回事？”中详细介绍。

7）Checksum 是校验和，用于校验 TCP 段有没有损坏。

8）Urgent Pointer 指向最后一个紧急数据的序号（Sequence Number）。它存在的原因是：有时候紧急数据是连续的很多个段，所以需要提前告诉接收方进行准备。

9）Options 中存储了一些可选字段，比如接下来我们要讨论的 MSS（Maximun Segment Size）。
10）Padding 存在的意义是因为 Options 的长度不固定，需要 Pading 进行对齐。

• MSS（Maximun Segment Size）这个可选项控制了 TCP 段的大小。如果这个字段设置得非常大，就会带来一些影响。首先对方可能会拒绝，作为服务的提供方，你可能不会愿意接收太大的 TCP 段。因为大的 TCP 段，会降低性能，比如内存使用的性能。具体你可以参考《重学操作系统》课程中关于页表的讨论。

24 | 虚拟内存 ：一个程序最多能使用多少内存？

25 | 内存管理单元： 什么情况下使用大内存分页？

26 | 缓存置换算法： LRU 用什么数据结构实现更合理？

还有就是资源的占用。一个用户占用服务器太多的资源，意味着其他的用户就需要等待或者降低他们的服务质量。

其次，支持 TCP 协议工作的 IP 协议，工作效率会下降。TCP 协议不肯拆包，IP 协议就需要拆出大量的包。那么 IP 协议为什么需要拆包呢？这是因为在网络中，每次能够传输的数据不可能太大，这受限于具体的网络传输设备，也就是物理特性。但是 IP 协议，拆分太多的封包并没有意义。因为可能会导致属于同个 TCP 段的封包被不同的网络路线传输，这会加大延迟。同时，拆包，还需要消耗硬件和计算资源。

那是不是 MSS 越小越好呢？MSS 太小的情况下，会浪费传输资源（降低吞吐量）。因为数据被拆分之后，每一份数据都要增加一个头部。如果 MSS 太小，那头部的数据占比会上升，这让吞吐量成为一个灾难。所以在使用的过程当中，MSS 的配置，往往都是一个折中的方案。而根据 Unix 的哲学，不要去猜想什么样的方案是最合理的，而是要尝试去用实验证明它，一切都要用实验依据说话。

• 滑动窗口

• 快速重传

在 TCP 协议中，如果接收方想丢弃某个段，可以选择不发 ACK。发送端超时后，会重发这个 TCP 段。而有时候，接收方希望催促发送方尽快补发某个 TCP 段，这个时候可以使用快速重传能力。

例如段 1、段 2、段 4 到了，但是段 3 没有到。 接收方可以发送多次段 3 的 ACK。如果发送方收到多个段 3 的 ACK，就会重发段 3。这个机制称为快速重传。这和超时重发不同，是一种催促的机制。

为了不让发送方误以为段 3 已经收到了，在快速重传的情况下，接收方即便收到发来的段 4，依然会发段 3 的 ACK（不发段 4 的 ACK），直到发送方把段 3 重传。

• 流速控制

发送、接收窗口的大小可以用来控制 TCP 协议的流速。窗口越大，同时可以发送、接收的数据就越多，支持的吞吐量也就越大。当然，窗口越大，如果数据发生错误，损失也就越大，因为需要重传越多的数据。

• 滑动窗口和流速控制是怎么回事？

滑动窗口是 TCP 协议控制可靠性的核心。发送方将数据拆包，变成多个分组。然后将数据放入一个拥有滑动窗口的数组，依次发出，仍然遵循先入先出（FIFO）的顺序，但是窗口中的分组会一次性发送。窗口中序号最小的分组如果收到 ACK，窗口就会发生滑动；如果最小序号的分组长时间没有收到 ACK，就会触发整个窗口的数据重新发送。另一方面，在多次传输中，网络的平均延迟往往是相对固定的，这样 TCP 协议可以通过双方协商窗口大小控制流速。补充下，上面我们说的分组和 TCP 段是一个意思。

• UDP 协议

UDP（User Datagram Protocol），目标是在传输层提供直接发送报文（Datagram）的能力。Datagram 是数据传输的最小单位。UDP 协议不会帮助拆分数据，它的目标只有一个，就是发送报文。

• UDP 的封包格式

UDP 的设计目标就是在允许用户直接发送报文的情况下，最大限度地简化应用的设计。下图是 UDP 的报文格式。

• UDP与TCP的区别

1. 目的差异
首先，这两个协议的目的不同：TCP 协议的核心目标是提供可靠的网络传输，而 UDP 的目标是在提供报文交换能力基础上尽可能地简化协议轻装上阵。
2. 可靠性差异
TCP 核心是要在保证可靠性提供更好的服务。TCP 会有握手的过程，需要建立连接，保证双方同时在线。而且TCP 有时间窗口持续收集无序的数据，直到这一批数据都可以合理地排序组成连续的结果。
UDP 并不具备以上这些特性，它只管发送数据封包，而且 UDP 不需要 ACK，这意味着消息发送出去成功与否 UDP 是不管的。
3. 连接 vs 无连接
TCP 是一个面向连接的协议（Connection-oriented Protocol），传输数据必须先建立连接。 UDP 是一个无连接协议（Connection-less Protocol），数据随时都可以发送，只提供发送封包（Datagram）的能力。
4. 流控技术（Flow Control）
TCP 使用了流控技术来确保发送方不会因为一次发送过多的数据包而使接收方不堪重负。TCP 在发送缓冲区中存储数据，并在接收缓冲区中接收数据。当应用程序准备就绪时，它将从接收缓冲区读取数据。如果接收缓冲区已满，接收方将无法处理更多数据，并将其丢弃。UDP 没有提供类似的能力。
5. 传输速度
UDP 协议简化，封包小，没有连接、可靠性检查等，因此单纯从传输速度上讲，UDP 更快。
6. 场景差异
TCP 每个数据封包都需要确认，因此天然不适应高速数据传输场景，比如观看视频（流媒体应用）、网络游戏（TCP 有延迟）等。具体来说，如果网络游戏用 TCP，每个封包都需要确认，可能会造成一定的延迟；再比如音、视频传输天生就允许一定的丢包率；Ping 和 DNSLookup，这类型的操作只需要一次简单的请求/返回，不需要建立连接，用 UDP 就足够了。

• IP 协议的工作原理

IP 协议接收 IP 协议上方的 Host-To-Host 协议传来的数据，然后进行拆分，这个能力叫作分片（Fragmentation）。然后 IP 协议为每个片段（Fragment）增加一个 IP 头（Header），组成一个IP 封包（Datagram）。之后，IP 协议调用底层的局域网（数据链路层）传送数据。最后 IP 协议通过寻址和路由能力最终把封包送达目的地。首先 IP 协议会进行分片，将上游数据拆成一个个的封包（Datagram），然后为封包增加 IP 头部。封包发送出去后，就开始了寻址过程。寻址就是找到 IP 地址对应的设备。在局域网内，如果找不到设备，就需要路由。路由就是找到数据应该往哪里发送。最后通过层层路由定位到具体的设备。

1. 最重要的是原地址和目标地址。IPv4 的地址是 4 组 8 位的数字，总共是 32 位。具体地址的作用我们在下面的“寻址部分”介绍。
2. Type Of Service 服务的类型，是为了响应不同的用户诉求，用来选择延迟、吞吐量和丢包率之间的关系。
3. IHL（Internet Header Length）用来描述 IP 协议头的大小。所以 IP 协议头的大小是可变的。IHL 只有 4 位，最大值 1111 = 15。最大是 15 个双字（15*4 字节 = 60 字节）。
4. Total Length 定义报文（封包 Datagram）的长度。
5. Identification（报文的 ID），发送方分配，代表顺序。
6. Fragment offset 描述要不要分包（拆分），以及如何拆分。
7. Time To Live 描述封包存活的时间。因此每个 IP 封包发送出去后，就开始销毁倒计时。如果倒计时为 0，就会销毁。比如中间的路由器看到一个 TTL 为 0 的封包，就直接丢弃。
8. Protocol 是描述上层的协议，比如 TCP = 6，UDP = 17。
9. Options 代表可选项。
10. Checksum 用来检验封包的正确性，具体原理我们在“05 | UDP 协议：TCP 协议和 UDP 协议的优势和劣势？”中已经介绍过了，如果 Checksum 对不上，就需要选择丢弃这个封包。

 

• 路由和寻址的区别是什么？

寻址（Addressing）就是通过地址找设备。和现实生活中的寻址是一样的，比如根据地址找到一个公寓。在 IPv4 协议中，寻址找到的是一个设备所在的位置。

路由（Routing）本质是路径的选择。就好像知道地址，但是到了每个十字路口，还需要选择具体的路径。

所以，要做路由，就必须能够理解地址，也就是需要借助寻址的能力。要通过寻址找到最终的设备，又要借助路由在每个节点选择数据传输的线路。因此，路由和寻址，是相辅相成的关系。

• IPv6 的寻址

• • 全局单播寻址（和 IPv4 地址作用差不多，在互联网中通过地址查找一个设备，简单来说，单播就是 1 对 1）；

• • 本地单播（类似 IPv4 里的一个内部网络，要求地址必须以fe80开头，类似我们 IPv4 中127开头的地址）；

    

  • 分组多播（Group Multicast），类似今天我们说的广播，将消息发送给多个接收者；当 IP 地址以 8 个 1 开头，也就是ff00开头，后面会跟上一个分组的编号时，就是在进行分组多播。

  • 任意播（Anycast）本质是将消息发送给多个接收方，并选择一条最优的路径。这样说有点抽象，接下来我具体解释一下。

    比如说在一个网络中有多个授时服务，这些授时服务都共享了一个任播地址。当一个客户端想要获取时间，就可以将请求发送到这个任播地址。客户端的请求扩散出去后，可能会找到授时服务中的一个或者多个，但是距离最近的往往会先被发现。这个时候，客户端就使用它第一次收到的授时信息修正自己的时间。

• 链路层发送数据靠的是 MAC 地址，MAC 地址就好像人的身份证一样。

• 地址解析协议（ARP）

对于一个网络接口，它如何能知道目标接口的 MAC 地址呢？我们在使用传输层协议的时候，清楚地知道目的地的 IP 地址，但是我们不知道 MAC 地址。这个时候，就需要一个中间服务帮助根据 IP 地址找到 MAC 地址——这就是地址解析协议

• 网络地址转换协议是如何工作的？

【解析】网络地址解析协议（NAT）解决的是内外网通信的问题。NAT 通常发生在内网和外网衔接的路由器中，由路由器中的 NAT 模块提供网络地址转换能力。从设计上看，NAT 最核心的能力，就是能够将内网中某个 IP 地址映射到外网 IP，然后再把数据发送给外网的服务器。当服务器返回数据的时候，NAT 又能够准确地判断外网服务器的数据返回给哪个内网 IP。

你可以思考下 NAT 是如何做到这点的呢？需要做两件事。

NAT 需要作为一个中间层替换 IP 地址。 发送的时候，NAT 替换源 IP 地址（也就是将内网 IP 替换为出口 IP）；接收的时候，NAT 替换目标 IP 地址（也就是将出口 IP 替换回内网 IP 地址）。
NAT 需要缓存内网 IP 地址和出口 IP 地址 + 端口的对应关系。也就是说，发送的时候，NAT 要为每个替换的内网 IP 地址分配不同的端口，确保出口 IP 地址+ 端口的唯一性，这样当服务器返回数据的时候，就可以根据出口 IP 地址 + 端口找到内网 IP。

• epoll为什么用红黑树？

select 是一个主动模型，需要线程自己通过一个集合存放所有的 Socket，然后发生 I/O 变化的时候遍历。在 select 模型下，操作系统不知道哪个线程应该响应哪个事件，而是由线程自己去操作系统看有没有发生网络 I/O 事件，然后再遍历自己管理的所有 Socket，看看这些 Socket 有没有发生变化。

poll 提供了更优质的编程接口，但是本质和 select 模型相同。因此千级并发以下的 I/O，你可以考虑 select 和 poll，但是如果出现更大的并发量，就需要用 epoll 模型。

epoll 模型在操作系统内核中提供了一个中间数据结构，这个中间数据结构会提供事件监听注册，以及快速判断消息关联到哪个线程的能力（红黑树实现）。因此在高并发 I/O 下，可以考虑 epoll 模型，它的速度更快，开销更小。

•  BIO、NIO 和 AIO 的区别

在运用数据结构的时候，还要思考 I/O 的多路复用用什么模型。

假设你在处理一个高并发的网站，每秒有大量的请求打到你的服务器上，你用多少个线程去处理 I/O 呢？对于没有需要压缩解压的场景，处理 I/O 的主要开销还是数据的拷贝。那么一个 CPU 核心每秒可以完成多少次数据拷贝呢？

拷贝，其实就是将内存中的数据从一个地址拷贝到另一个地址。再加上有 DMA，内存映射等技术，拷贝是非常快的。不考虑 DMA 和内存映射，一个 3GHz 主频的 CPU 每秒可以拷贝的数据也是百兆级别的。当然，速度还受限于内存本身的速度。因此总的来说，I/O 并不需要很大的计算资源。通常我们在处理高并发的时候，也不需要大量的线程去进行 I/O 处理。

对于多数应用来说，处理 I/O 的成本小于处理业务的成本。处理高并发的业务，可能需要大量的计算资源。每笔业务也可能会需要更多的 I/O，比如远程的 RPC 调用等。

因此我们在处理高并发的时候，一种常见的 I/O 多路复用模式就是由少量的线程处理大量的网络接收、发送工作。然后再由更多的线程，通常是一个线程池处理具体的业务工作。在这样一个模式下，有一个核心问题需要解决，就是当操作系统内核监测到一次 I/O 操作发生，它如何具体地通知到哪个线程调用哪段程序呢？

这时，一种高效的模型会要求我们将线程、线程监听的事件类型，以及响应的程序注册到内核。具体来说，比如某个客户端发送消息到服务器的时候，我们需要尽快知道哪个线程关心这条消息（处理这个数据）。例如 epoll 就是这样的模型，内部是红黑树。我们可以具体地看到文件描述符构成了一棵红黑树，而红黑树的节点上挂着文件描述符对应的线程、线程监听事件类型以及相应程序。

无论是哪种 I/O 模型，都要将数据从网卡拷贝到用户程序（接收），或者将数据从用户程序传输到网卡（发送）。另一方面，有的数据需要编码解码，比如 JSON 格式的数据。还有的数据需要压缩和解压。数据从网卡到内核再到用户程序是 2 次传输。注意，将数据从内存中的一个区域拷贝到另一个区域，这是一个 CPU 密集型操作。数据的拷贝归根结底要一个字节一个字节去做。

从网卡到内核空间的这步操作，可以用 DMA（Direct Memory Access）技术控制。DMA 是一种小型设备，用 DMA 拷贝数据可以不使用 CPU，从而节省计算资源。遗憾的是，通常我们写程序的时候，不能直接控制 DMA，因此 DMA 仅仅用于设备传输数据到内存中。不过，从内核到用户空间这次拷贝，可以用内存映射技术，将内核空间的数据映射到用户空间。

• • 第一个是编程模型，阻塞、非阻塞、异步 3 者 API 的设计会有比较大的差异。通常情况下我们说的异步编程是异步转同步。异步转同步最大的价值，就是提升代码的可读性。可读，就意味着维护成本的下降以及扩展性的提升。

  • 第二个在设计系统的 I/O 时，另一件需要考虑的就是数据传输以及转化的成本。传输主要是拷贝，比如可以使用内存映射来减少数据的传输。但是这里要注意一点，内存映射使用的内存是内核空间的缓冲区，因此千万不要忘记回收。因为这一部分内存往往不在我们所使用的语言提供的内存回收机制的管控范围之内。

  • 最后是关于数据结构的运用，针对不同的场景使用不同的缓冲区，以及选择不同的消息通知机制，也是处理高并发的一个核心问题。

从上面几个角度去看 I/O 的模型，你会发现，编程模型是编程模型、数据的传输是数据的传输、消息的通知是消息的通知，它们是不同的模块，完全可以解耦，也可以根据自己不同的业务特性进行选择。虽然在一个完整的系统设计中，往往提出的是一套完整的解决方案（这也是很多网上的博文会将者 3 者混为一谈的原因），但实际上我们还是应该将它们分开去思考，这样可以产生更好的设计思路。

• 如何实现RPC框架？

总结下，设计一个 RPC 框架最基础的能力就是实现远程方法的调用。这里需要一个调用约定，比如怎么描述一个远程的方法，发送端怎么传递参数，接收方如何解析参数？如果发生异常应该如何处理？具体来说，这些事情都不难实现，只是比较烦琐。其实不仅仅在 RPC 调用时有调用约定，编译器在实现函数调用的时候，也会有调用约定。另外，还有一些在 RPC 基础上建立起来的更复杂、更体系化的约定，比如说面向服务架构（SOA）。

在实现了基本调用能力的基础上，接下来就是提供服务的注册、发现能力。有了这两个能力，就可以向客户端完全屏蔽服务的部署细节，并衍生出容灾、负载均衡的设计。

当然，程序员还需要思考底层具体网络的传输问题。如果用 TCP 要思考多路复用以及连接数量的问题；如果是 UDP，需要增加对于可靠性保证的思考。如果使用了消息队列，还需要考虑服务的幂等性设计等。

• DNS 和统一资源你定位符（URL）

域名系统本质是定位资源。互联网中有各种各样的资源，比如视频、图片、文件、网页……为了准确地定位资源，人们发明了统一资源定位符（URL，Uniform Resource Locator），这样我们就可以通过字符串定位一个互联网的资源。

下图是一个 URL 的示例：

Scheme 部分代表协议，不只有 https，还有 ftp、ssh 等。不同协议代表着不同类型的应用在提供资源。
Host 部分代表站点，我们今天介绍的 DNS 主要作用就是根据 Host 查找 IP 地址。
Port 是端口，代表提供服务的应用。
Path 是路径，代表资源在服务中的路径。
Query 是查询条件，代表需要的是资源中的某一个部分。
Fragment 是二级查询条件，通常不在服务端响应，而是用于前端展示定位内容。

• DNS查询过程

当用户在浏览器中输入一个网址，就会触发 DNS 查询。这个时候在上述的 3 个层级中，还会增加本地 DNS 服务器层级。本地 DNS 服务器包括用户自己路由器中的 DNS 缓存、小区的 DNS 服务器、ISP 的 DNS 服务器等。

 

1. 用户输入网址，查询本地 DNS。本地 DNS 是一系列 DNS 的合集，比如 ISP 提供的 DNS、公司网络提供的 DNS。本地 DNS 是一个代理，将 DNS 请求转发到 DNS 网络中。如果本地 DNS 中已经存在需要的记录，也就是本地 DNS 缓存中找到了对应的 DNS 条目，就会直接返回，而跳过之后的步骤。

2. 客户端请求根 DNS 服务器。如果本地 DNS 中没有对应的记录，那么请求会被转发到根 DNS 服务器。根 DNS 服务器只解析顶级域，以“www.lagou.com”为例，根 DNS 服务器只看 com 部分。

3. 根 DNS 服务器返回顶级 DNS 服务器的 IP。

4. 客户端请求顶级 DNS 服务器，顶级 DNS 服务器中是具体域名的目录。

5. 顶级 DNS 服务器返回权威 DNS 服务器的 IP。

6. 客户端请求权威 DNS 服务器。在权威 DNS 服务器上存有具体的 DNS 记录。以 lagou 为例，权威 DNS 服务器中可能有和 lagou.com 相关的上百条甚至更多的 DNS 记录，会根据不同的 DNS 查询条件返回。

7. 权威 DNS 服务器返回 DNS 记录到本地 DNS 服务器。

8. 本地 DNS 服务器返回具体的 DNS 记录给客户端。

• HTTP 协议还设计了协商缓存。协商缓存启用后，第一次获取接口数据，会将数据缓存到本地，并存储下数据的摘要。第二次请求时，浏览器检查到本地有缓存，将摘要发送给服务端。服务端会检查服务端数据的摘要和浏览器发送来的是否一致。如果不一致，说明服务端数据发生了更新，服务端会回传全部数据。如果一致，说明数据没有更新，服务端不需要回传数据。从这个角度看，协商缓存的方式节省了流量。对于小明开发的这个接口，多数情况下协商缓存会生效。当小明更新了数据后，协商缓存失效，客户端数据可以马上更新。和强制缓存相比，协商缓存的代价是需要多发一次请求。
• DNS记录类型

CNAME（Canonical Name Record）用于定义域名的别名，A 记录是域名和 IPv4 地址的映射关系。和 A 记录类似，AAAA 记录则是域名和 IPv6 地址的映射关系。MX 记录是邮件记录，用来描述邮件服务器的域名。NS（Name Server）记录是描述 DNS 服务器网址。从 DNS 的存储结构上说，Name Server 中含有权威 DNS 服务的目录。也就是说，NS 记录指定哪台 Server 是回答 DNS 查询的权威域名服务器。

• CDN

  

用户的请求先到达缓存层，如果缓存被穿透，才到达最终的存储层。缓存的设计必须是分布式的，因为绝大多数的资源使用都会发生在缓存上，只有极少数的请求才会穿透到底层的存储。通常这种设计，我们期望缓存层至少需要帮挡住 99% 的流量。既然缓存层能挡住 99% 的流量，那么实际的数据存储就可以交由源站点完成。

• CDN的回源

整个过程是 4 个层级。用户请求静态资源通常用自己的域名（防止跨域和一些安全问题）。为了让用户请求的是自己的网站，而使用的是 CDN 的服务，这里会使用 CNAME 让自己的域名作为 CDN 域名的一个别名。当请求到 CDN 服务的时候，会首先由 CDN 的 DNS 服务帮助用户选择一个最优的节点，这个 DNS 服务还充当了负载均衡的作用。接下来，用户开始向 CDN 节点请求资源。如果这个时候资源已经过期或者还没有在 CDN 节点上，就会从源站读取数据，这个步骤称为CDN 的回源。

 

24、对称加密用同样的密钥，安全系数不够。非对称加密，用公钥 + 私钥的方式加强了安全系数。那么是不是我们所有的加密的应用都应该用非对称加密呢？通常情况，非对称加密需要更多的运算资源。因此很多协议使用非对称加密解决最核心的安全问题，再用对称加密解决其他问题。

以 HTTPS 协议为例，客户端和服务器之间会先用非对称加密交换临时对称加密密钥，然后之后的通信会以对称加密执行，直到连接结束。也就是非对称加密仅仅存在于 HTTPS 连接建立后，用于交换密钥（对称加密密钥）的少数几次传输中。这样用非对称加密解决最核心的安全问题：交换对称加密密钥；然后利用对称加密进行数据的传输。

25、信用链的验证
现在问题来了，张三把证书给了李四，李四拿到张三的证书，并看到某权威机构的签名。李四的第一反应就是——这个签名是权威机构的吗？比如上图中拉勾的签名，当你打开拉勾教育的时候，你相信这个证书是 GlobalSign 签发的吗？大部分同学都不知道 GlobalSign吧？ 其实我也不知道这家机构。但是这不重要，用户甚至不需要理解 GlobalSign，计算机产业的底层建筑帮助大家解决了这个问题——这个被称作信用链。

当我们用 HTTPS 协议打开拉勾教育的页面时，这个证书会随着 HTTPS 的握手被下载到本地。浏览器打开证书，发现提供方式 GlobalSign。GlobalSign（Certificate Authority，CA）是一家证书颁发机构。

浏览器并不需要理解 GlobalSign 是谁，在验证过程中，浏览器会查找操作系统中，是否已经安装了 GlobalSign 的证书。如果已经安装了，浏览器就会相信这个证书。操作系统的提供商，比如微软、苹果、谷歌总不会恶意安装非法证书砸自己的招牌。只要用户本机安装了 GlobalSign 证书，那么 GlobalSign 证书的公钥就应该可以解密网站证书的签名，得到网站证书的摘要，那么就可以信任 GlobalSign 签发的这张拉勾的证书。

如果操作系统中没有安装 GlobalSign 的证书该怎么办呢？不要着急，这个时候，浏览器会去 GlobalSign 的网站下载证书，拿到 GlobalSign 证书后，浏览器也不确定 GlobalSign 是一个权威机构，这个时候浏览器会看 GlobalSign 证书上有没有签发方。如果有，递归进行检查签发方的证书是否安装在操作系统本地，直到找到根证书。根证书的特点是，这个机构的证书没有其他机构为它签名。只要操作系统中有根证书，那么 GlobalSign 就值得信任，因此拉勾值得信任。

在上述过程中，操作系统的提供商起到重要的作用。操作系统安装的时候，会预装一些证书。这些证书我们称为根证书，能签发根证书的机构就是根证书提供商。根证书提供商在全球很少，通常只有信誉非常棒的机构才能担当。而且成为根证书要得到很多资质，如果中间出现问题，还会被取消资格，特别是还需要和多家操作系统提供商达成合作，比如微软、苹果、谷歌等。

26、信任链的具体形式
以上的层层证明形式，构成了一个信任链。

一般的，信任链有 3 层。最顶层是根证书和根证书机构（Root Certificate，Root CA）。前面我们提到，根证书往往是随着操作系统安装的，特殊情况需要用户自己安装。比如说一些抓包工具，会要求用户自己安装一个根证书。

中间的是中间证书机构，它们自己的证书是由 Root CA 签名颁发的，同时它们向最底层的终端机构提供证书。

 

根证书是自签名，中间证书是根证机构书签名，终端证书（比如拉勾网）是中间证书机构签名。这样就构成了一个信任链，并且也增加了犯罪的成本。犯罪分子如果想要冒充证书，那么它的证书就需要获得中间证书提供商的签名，而获得签名需要购买证书。犯罪分子就算购买了证书，也只能购买自己域名的证书，因此无法伪装成其他网站。但要特别注意的是，如果犯罪分子设法在你的个人电脑上安装了它的根证书，那后果就严重了，它可以冒充成任何网站。

27、作为一个过来人，希望你在工作中不要忘记生活，学习中也不要失去韧性。要知道，功夫在诗外。如果感觉自己处于瓶颈期，静下心来去旅旅游，回家乡小住一段时间都是不错的选择。