网络概述

Network

 2019/10/02 

转载声明：该文章有一部分转载自CavsZhouyou。欢迎大家去原博主观看，总结的更好

概述

OSI 七层模型

应用层：为应用程序（进程）提供服务，并管理应用程序之间的通信（SMTP、HTTP、FTP、DNS）
表示层：处理数据的标识问题，比如编码、格式转化、加密解密等
会话层：负责建立管理和断开通信连接，实现数据同步
传输层：负责向两个主机中进程之间的通讯提供服务,端到端传输数据，同时处理传输错误、控制流量等（TCP UDP）
网络层：负责为分组交换网上的不同主机提供通信服务。地址管理、路由选择（IP 协议）
数据链路层：数据分割成帧，mac 寻址、差错校验、信息纠正等。（以太网）
物理层：利用传输介质为数据链路层提供物理连接
发送端从应用层 → 物理层打包发送
接收层从物理层 → 应用层解析获取

计算机网络的分类

按网络的作用范围分类，可分为广域网（WAN，几十到几千 km，跨省跨国），城域网（MAN，5-50km，城市间），局域网（LAN，1km 以内）

现代互联网的网络拓扑

如图所示（这种各层的连接组成的结构就称为拓扑）

边缘部分：eg.家庭或企业
核心部分：各 ISP（Internet Service Provider，互联网服务提供商）之前的连接（地区 ISP，主干 ISP）

客户-服务器（C/S）模式：eg. 常规的 http 请求
对等连接（P2P）模式：当两台计算机上都运行了 P2P 的时候，两台计算机可以直接连接。eg. 迅雷的 P2P 下载

物理层

通信方式

根据信息在传输线上的传送方向，分为以下三种通信方式：

单工通信：单向传输
半双工通信：双向交替传输
全双工通信：双向同时传输

比特流

比特流是物理层传递信息的方式。1 为高电频，0 为低电频，两者的变化就可以形成比特流，如下图

信道

信道是往一个方向传送信息的媒体。（一条通信电路包含一个接收信道和一个发送信道）

分类

单工信道（只有一个方向的，eg. 有线电视），半双工信道（双方都能发送和接收，但不能同时发送/同时接收），全双工信道

信道复用技术

复用技术有：频分复用、时分复用、统计时分复用、波分复用、码分复用

数据链路层

数据链路层的基本特征

封装成帧。帧是数据链路层数据的基本单位。发送端在网络层传下来的数据（IP 数据报）前后添加特定标记形成“帧”（这些标记一般是一段比特流）；接收端根据前后特定标记识别出“帧”
透明传输。“透明”在计算机领域是非常重要的一个术语，表示一个实际存在的事物看起来好像不存在一样，对链路层来说就是：即使控制字符在帧数据中，但是要当做不存在去处理。eg. 帧数据中，刚好有一段比特流长的跟帧尾部一毛一样。但是链路层会在这段比特流前加一个转义标志是，做到视而不见所以不会引起解析出错。
差错检测。9-9 最大传输单元 MTU（数据链路层）

MAC 地址

也称为物理地址、硬件地址，是链路层地址，每个设备都有唯一的 MAC 地址，长度为 6 个字节，即 48 位 bit（16 进制表示）。在命令行工具输入 ipconfig /all 可查看

以太网协议

以太网（Ethernet）是一种使用广泛的局域网技术，是应用于数据链路层的协议。使用以太网可以完成相邻设备的数据帧传输。

以太网的数据格式

MAC 地址表

存一些 MAC 地址和硬件接口的对应关系。单纯靠以太网只能完成相邻设备的传输。 eg. A-B-C （只能说 A 通过以太网传到 B，不能说 A 通过以太网直接传到 C，因为 A 的 MAC 地址表中没有 C 的地址）

网络层

负责传输的 IP 协议,作用是把数据包传输给对方(根据 IP 地址和 Mac 地址)
互联网中的传输是路由选择机制的，经过多台计算机和网络设备中转才连接到对方，并且我们只能知道起点和终点，过程无法悉知。

虚拟互连网络

使用 IP 协议，可以把异构的物理网络连接起来，使得在网络层看起来好像是一个统一的网络

IP 地址

IP 地址是节点被分配到的地址（可换）。长度为 32 位，常分为 4 个 8 位。常使用点分十进制来表示（每一位是 0~255）。eg. 255.111.11.71。
根据 ARP 协议能从 IP 地址查到 Mac 地址。Mac 地址才是通信目的地

路由

交换机是在数据链路层，路由在网络层

路由器转发流程

有如下的网络拓扑结构

如计算机 A 想发信息给计算机 C，则流程为：

A 发出目的地为 C 的 IP 数据报，查询路由表发现下一跳为 E，于是 A 将数据发给 E
E查询路由表发现下一跳为 F，于是 E 将数据发给 F
F查询路由表发现目的地 C直接连接，于是发给 C

路由器选择协议

互联网可以划分为许多较小的自治系统 AS，一个 AS 可以使用一种和别的 AS 不同的路由选择协议
路由器是连接因特网中各局域网、广域网的设备，它会根据信道的情况自动选择和设定路由，以最佳路径，先后顺序发送信号。确定最佳路径方法就是路由选择协议。可以把路由选择协议划分为两大类：

自治系统内部的路由选择：RIP 和 OSPF
自治系统间的路由选择：BGP

传输层

UDP 与 TCP 的区别

UDP 协议是面向无连接的，不需要在正式传递数据之前先连接起双方；UDP 协议只是数据报文的搬运工，不保证有序（面向报文，即对传下来的报文只是加 UDP 首部）且不丢失的传递到对端；并且 UDP 协议也没有任何控制流量的算法；（支持一对一、一对多、多对一和多对多的交互通信；）总的来说 UDP 相较于 TCP 更加的轻便高效。一般可以用于直播、即时通讯、即时游戏等。
TCP 无论是建立连接还是断开连接都需要先需要进行握手。在传输数据的过程中，通过各种算法(通过序号、确认号、定时重传、检验和等机制，来提供可靠的数据传输服务)保证数据的可靠性，有序性（面向字节流，将大块数据分割成以报文段位单位的数据包进行传输）。每一条 TCP 连接只能是点对点的（一对一）。TCP 提供了拥塞控制机制，在网络拥塞的时候会控制发送数据的速率，有助于减少数据包的丢失和减轻网络中的拥塞程度。TCP 提供了流量控制机制，保证了通信双方的发送和接收速率相同。如果接收方可接收的缓存很小时，发送方会降低发送速率，避免因为缓存填满而造成的数据包的丢失。当然带来的问题就是相比 UDP 来说不那么的高效

TCP 报文段的的首部格式

序号：对报文段的编号，例如序号为 301
确认号：期望收到的下一个报文段的序号，eg. 302
*数据偏移：数据部分距离报文段起始处的偏移量，实际上指的是首部的长度
确认 ACK：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
同步 SYN：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
终止 FIN：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。
窗口：表示当前允许对方发送的最大数据量，单位是字节

TCP 的三次握手

起初，两端都为 CLOSED 状态。在通信开始前，双方都会创建 TCP 连接（因为 HTTP 只有请求和相应）。服务器创建完 TCP 连接后便进入 LISTEN 状态，此时开始等待客户端发送数据。

第一次：客户端向服务器端发送连接请求报文，会包含 SYN=1（标志位），Seq=X（初始序号，某个数），进入 SYN-SENT 状态；
第二次：服务端收到请求报文后，发送应答：SYN=1，Seq=Y（初始序号），ACK（确认号）=X+1，进入 SYN-RECEIVED 状态；
第三次：客户端收到同意连接的应答后，发确认报文：ACK=Y+1。进入 ESTABLISHED 状态。服务端收到受也进入 ESTABLISHED 状态。

要三次握手的原因：防止出现失效的连接请求报文段被服务端接收的情况，从而产生错误。
客户端发送了一个连接请求 A，但是因为网络原因造成了超时，这时 TCP 会启动超时重传的机制再次发送一个连接请求 B。此时请求顺利到达服务端，服务端应答完就建立了请求，然后接收数据后释放了连接。
假设这时候连接请求 A 在两端关闭后终于抵达了服务端，那么此时服务端会认为客户端又需要建立 TCP 连接，从而应答了该请求并进入 ESTABLISHED 状态。但是客户端其实是 CLOSED 的状态，那么就会导致服务端一直等待，造成资源的浪费。

TCP 断开连接的四次挥手

TCP 是全双工的，在断开连接时两端都需要发送 FIN 和 ACK。
第一次握手：若客户端 A 认为数据发送完成，则它需要向服务端 B 发送连接释放请求。
第二次握手：B 收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明 A 到 B 的连接已经释放，不再接收 A 发的数据了。但是因为 TCP 连接是双向的，所以 B 仍旧可以发送数据给 A。
第三次握手：B 如果此时还有没发完的数据会继续发送，完毕后会向 A 发送连接释放请求，然后 B 便进入 LAST-ACK 状态。
第四次握手：A 收到释放请求后，向 B 发送确认应答，此时 A 进入 TIME-WAIT 状态。该状态会持续 2MSL（报文最大生存时间，指报文段在网络中生存的时间，超时会被抛弃）时间，若该时间段内没有 B 的重发请求的话，就进入 CLOSED 状态。当 B 收到确认应答后，也便进入 CLOSED 状态。

PS：通过延迟确认的技术（通常有时间限制，否则对方会误认为需要重传），可以将第二次和第三次握手合并，延迟 ACK 包的发送。
为什么客户端 A 要进入 TIME-WAIT 状态，等待 2MSL 时间后才进入 CLOSED 状态？
为了保证 B 能收到 A 的确认应答。若 A 发完确认应答后直接进入 CLOSED 状态，如果确认应答因为网络问题一直没有到达，那么会造成 B 不能正常关闭。（B 若 1MSL 后没收到，会重新发送 FIN 包。所以来回是 2MSL）

TCP 的流量控制

流量控制是为了控制发送方发送速率，保证接收方来得及接收。是通过滑动窗口和拥堵窗口实现的

滑动窗口主要是用于接收方，保证接收方能够接受数据。接收方通过报文告知发送方当前接收窗口剩余大小，发送窗口根据该值提调整自身窗口来控制发送速率。（将窗口字段设置为 0，则发送方不能发送数据）
*拥堵窗口，主要用于网络，防止过多的数据拥堵网络，避免负载过大的情况

连续 ARQ 协议

连续 ARQ 协议是为了解决停止等待 ARQ 协议对于信道的利用率过低的问题。它通过连续发送一组分组，然后再等待对分组的确认回答，对于如何处理分组中可能出现的差错恢复情况，一般可以使用滑动窗口协议和选择重传协议来实现。

滑动窗口协议

使用滑动窗口协议，在发送方维持了一个发送窗口，发送窗口以前的分组是已经发送并确认了的分组，发送窗口中包含了已经发送但未确认的分组和允许发送但还未发送的分组，发送窗口以后的分组是缓存中还不允许发送的分组。当发送方向接收方发送分组时，会依次发送窗口内的所有分组，并且设置一个定时器，这个定时器可以理解为是最早发送但未收到确认的分组。如果在定时器的时间内收到某一个分组的确认回答，则滑动窗口，将窗口的首部移动到确认分组的后一个位置，此时如果还有已发送但没有确认的分组，则重新设置定时器，如果没有了则关闭定时器。如果定时器超时，则重新发送所有已经发送但还未收到确认的分组。

接收方使用的是累计确认的机制，对于所有按序到达的分组，接收方返回一个分组的肯定回答。如果收到了一个乱序的分组，那么接方会直接丢弃，并返回一个最近的按序到达的分组的肯定回答。使用累计确认保证了确认号以前的分组都已经按序到达了，所以发送窗口可以移动到已确认分组的后面。

滑动窗口协议的缺点是因为使用了累计确认的机制，如果出现了只是窗口中的第一个分组丢失，而后面的分组都按序到达的情况的话，那么滑动窗口协议会重新发送所有的分组，这样就造成了大量不必要分组的丢弃和重传。

选择重传协议

因为滑动窗口使用累计确认的方式，所以会造成很多不必要分组的重传。使用选择重传协议可以解决这个问题。

选择重传协议在发送方维护了一个发送窗口。发送窗口的以前是已经发送并确认的分组，窗口内包含了已发送但未被确认的分组，已确认的乱序分组，和允许发送但还未发送的分组，发送窗口以后的是缓存中还不允许发送的分组。选择重传协议与滑动窗口协议最大的不同是，发送方发送分组时，为一个分组都创建了一个定时器。当发送方接受到一个分组的确认应答后，取消该分组的定时器，并判断接受该分组后，是否存在由窗口首部为首的连续的确认分组，如果有则向后移动窗口的位置，如果没有则将该分组标识为已接收的乱序分组。当某一个分组定时器到时后，则重新传递这个分组。

在接收方，它会确认每一个正确接收的分组，不管这个分组是按序的还是乱序的，乱序的分组将被缓存下来，直到所有的乱序分组都到达形成一个有序序列后，再将这一段分组交付给上层。对于不能被正确接收的分组，接收方直接忽略该分组。

详细资料可以参考：《TCP 连续 ARQ 协议和滑动窗口协议》

TCP 的可靠运输机制

TCP 的可靠运输机制是基于连续 ARQ 协议和滑动窗口协议的。

TCP 协议在发送方维持了一个发送窗口，发送窗口以前的报文段是已经发送并确认了的报文段，发送窗口中包含了已经发送但未确认的报文段和允许发送但还未发送的报文段，发送窗口以后的报文段是缓存中还不允许发送的报文段。当发送方向接收方发送报文时，会依次发送窗口内的所有报文段，并且设置一个定时器，这个定时器可以理解为是最早发送但未收到确认的报文段。如果在定时器的时间内收到某一个报文段的确认回答，则滑动窗口，将窗口的首部向后滑动到确认报文段的后一个位置，此时如果还有已发送但没有确认的报文段，则重新设置定时器，如果没有了则关闭定时器。如果定时器超时，则重新发送所有已经发送但还未收到确认的报文段，并将超时的间隔设置为以前的两倍。当发送方收到接收方的三个冗余的确认应答后，这是一种指示，说明该报文段以后的报文段很有可能发生丢失了，那么发送方会启用快速重传的机制，就是当前定时器结束前，发送所有的已发送但确认的报文段。

接收方使用的是累计确认的机制，对于所有按序到达的报文段，接收方返回一个报文段的肯定回答。如果收到了一个乱序的报文段，那么接方会直接丢弃，并返回一个最近的按序到达的报文段的肯定回答。使用累计确认保证了返回的确认号之前的报文段都已经按序到达了，所以发送窗口可以移动到已确认报文段的后面。

发送窗口的大小是变化的，它是由接收窗口剩余大小和网络中拥塞程度来决定的，TCP 就是通过控制发送窗口的长度来控制报文段的发送速率。

但是 TCP 协议并不完全和滑动窗口协议相同，因为许多的 TCP 实现会将失序的报文段给缓存起来，并且发生重传时，只会重传一个报文段，因此 TCP 协议的可靠传输机制更像是窗口滑动协议和选择重传协议的一个混合体。制）

TCP 的拥塞控制机制

TCP 的拥塞控制主要是根据网络中的拥塞情况来控制发送方数据的发送速率，如果网络处于拥塞的状态，发送方就减小发送的速率，这样一方面是为了避免继续增加网络中的拥塞程度，另一方面也是为了避免网络拥塞可能造成的报文段丢失。

TCP 的拥塞控制主要使用了四个机制，分别是慢启动、拥塞避免、快速重传和快速恢复。

慢启动的基本思想是，因为在发送方刚开始发送数据的时候，并不知道网络中的拥塞程度，所以先以较低的速率发送，进行试探，每次收到一个确认报文，就将发动窗口的长度加一，这样每个 RTT 时间后，发送窗口的长度就会加倍。当发送窗口的大小达到一个阈值的时候就进入拥塞避免算法。

拥塞避免算法是为了避免可能发生的拥塞，将发送窗口的大小由每过一个 RTT 增长一倍，变为每过一个 RTT ，长度只加一。这样将窗口的增长速率由指数增长，变为加法线性增长。

快速重传指的是，当发送方收到三个冗余的确认应答时，因为 TCP 使用的是累计确认的机制，所以很有可能是发生了报文段的丢失，因此采用立即重传的机制，在定时器结束前发送所有已发送但还未接收到确认应答的报文段。

快速恢复是对快速重传的后续处理，因为网络中可能已经出现了拥塞情况，所以会将慢启动的阀值减小为原来的一半，然后将拥塞窗口的值置为减半后的阀值，然后开始执行拥塞避免算法，使得拥塞窗口缓慢地加性增大。简单来理解就是，乘性减，加性增。

TCP 认为网络拥塞的主要依据是报文段的重传次数，它会根据网络中的拥塞程度，通过调整慢启动的阀值，然后交替使用上面四种机制来达到拥塞控制的目的。

详细资料可以参考：《TCP 的拥塞控制机制》《网络基本功：TCP 拥塞控制机制》
《搞定计算机网络面试，看这篇就够了（补充版）》

应用层

常用端口

输入 URL 到页面渲染的整个流程

首先浏览器主进程接管，开了一个下载线程
DNS 寻址
然后进行 HTTP 请求：先 DNS 查询获取 IP 地址，接着是 TCP 三次握手，如果是 https 的话，还会 TCP 握手结束后就会进行 TLS 握手，然后就开始正式的传输数据
接收到响应的文件之后，首先浏览器会判断状态码是什么，如果是 200 那就继续解析，如果 400 或 500 的话就会报错，如果 300 的话会进行重定向
拿到文件后浏览器开始解析文件，通过文件的编码格式正确地去解码文件
将解析完的内容转交给渲染进程管理（见浏览器这篇博文）。解析 DOM 时，解析绘制过程中，当浏览器遇到 link 标签或者 script、img 等标签，浏览器会去下载这些内容，遇到时候缓存的使用缓存，不适用缓存的重新下载资源
绘制结束后，关闭 TCP 连接，会有四次挥手

DNS 协议

DNS 是一个分布式数据库（每个站点只保留它自己的那部分数据），提供了主机名和 IP 地址之间相互转换的服务

域名的层级结构

DNS 系统采用的是分布式的解析方案，整个 DNS 架构是一种层次树状结构（树的根节点是根域名），这个树状结构称为 DNS 域名空间。

域名具有层次结构，从上到下（从右往左）依次为：根域名（.root, 一般情况下都是省略不写的）；顶级域名，top-level domain，缩写为 TLD（.com，.cn，.net 等）；次级域名，second-level domain，缩写为 SLD（.baidu，.gooele 等）；主机名，host / 三级域名（www, mial 等）

根据域名的层级结构，管理不同层级域名的服务器，可以分为根域名服务器、顶级域名服务器和权威域名服务器

DNS 的查询过程

DNS 是基于 UDP 做的查询。DNS 的查询过程一般为，我们首先将 DNS 请求发送到本地 DNS 服务器，由本地 DNS 服务器来代为请求。

从”根域名服务器”查到”顶级域名服务器”的 NS 记录（Name Server，负责管理该域名的服务器地址）和 A 记录（address，即 IP 地址）。
从”顶级域名服务器”查到”次级域名服务器”的 NS 记录和 A 记录。
从”次级域名服务器”查出”主机名”的 IP 地址。

比如我们如果想要查询 www.google.com 的 IP 地址，我们首先会将请求发送到本地的 DNS 服务器中，本地 DNS 服务器会判断是否存在该域名的缓存；如果不存在，则向根域名服务器发送一个请求，它会返回负责 .com 的顶级域名服务器的 IP 地址的列表；然后本地 DNS 服务器再向其中一个负责 .com 的顶级域名服务器发送一个请求，它会返回负责 .baidu 的权威域名服务器的 IP 地址列表。然后本地 DNS 服务器再向其中一个权威域名服务器发送一个请求，它会返回一个对应的主机名的 IP 地址列表。（一个域名可能有多个 IP 地址，所以返回的是一个列表)

详细步骤见阮一峰-DNS 原理入门，阮一峰-根域名的知识

DNS 记录和报文

DNS 服务器中以资源记录的形式存储信息，每一个 DNS 响应报文一般包含多条资源记录。一条资源记录的具体的格式为

（Name，Value，Type，TTL）

其中 TTL 是资源记录的生存时间，它定义了资源记录能够被其他的 DNS 服务器缓存多长时间。

常用的一共有四种 Type 的值，分别是 A、NS、CNAME 和 MX ，不同 Type 的值，对应资源记录代表的意义不同。

如果 Type = A（Address），则 Name 是主机名，Value 是主机名对应的 IP 地址。因此一条记录为 A 的资源记录，提供了标准的主机名到 IP 地址的映射。
如果 Type = NS（Name Server），则 Name 是个域名，Value 是负责该域名的 DNS 服务器的主机名。这个记录主要用于 DNS 链式查询时，返回下一级需要查询的 DNS 服务器的信息。
如果 Type = CNAME（Canonical Name），则 Name 为别名，Value 为该主机的规范主机名。该条记录用于向查询的主机返回一个主机名对应的规范主机名，从而告诉查询主机去查询这个主机名的 IP 地址。主机别名主要是为了通过给一些复杂的主机名提供一个便于记忆的简单的别名。
如果 Type = MX（Mail eXchange），则 Name 为一个邮件服务器的别名，Value 为邮件服务器的规范主机名。它的作用和 CNAME 是一样的，都是为了解决规范主机名不利于记忆的缺点。

递归查询和迭代查询

递归查询指的是查询请求发出后，域名服务器代为向下一级域名服务器发出请求，最后向用户返回查询的最终结果。使用递归查询，用户只需要发出一次查询请求。

迭代查询指的是查询请求后，域名服务器返回单次查询的结果。下一级的查询由用户自己请求。使用迭代查询，用户需要发出多次的查询请求。

一般我们向本地 DNS 服务器发送请求的方式就是递归查询，因为我们只需要发出一次请求，然后本地 DNS 服务器返回给我们最终的请求结果。而本地 DNS 服务器向其他域名服务器请求的过程是迭代查询的过程，因为每一次域名服务器只返回单次查询的结果，下一级的查询由本地 DNS 服务器自己进行。

DNS 缓存

在一个请求中，当某个 DNS 服务器接收到一个 DNS 回答后，它能够将回答中的信息缓存在本地存储器中。返回的资源记录中的 TTL 代表了该条记录的缓存的时间。

负载均衡

负载均衡的概念

在分布式系统中，负载均衡（Load Balancing）是一种将任务分派到多个服务端进程的方法，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。能用于HTTP，HTTPS，DNS，TCP，UDP等的转发

实现负载均衡主要有两个目的。第一个目的是将任务的处理负载均摊到不同的进程，以减少单一进程的负载，以达到处理能力水平扩容的目的。第二个目的则是提高容错能力

负载均衡器如何选择要转发的后端服务器？

负载均衡器一般根据两个因素来决定要将请求转发到哪个服务器。首先，确保所选择的服务器能够对请求做出响应，然后根据预先配置的规则从健康服务器池（healthy pool）中进行选择。

因为，负载均衡器应当只选择能正常做出响应的后端服务器，因此就需要有一种判断后端服务器是否「健康」的方法。为了监视后台服务器的运行状况，运行状态检查服务会定期尝试使用转发规则定义的协议和端口去连接后端服务器。如果，服务器无法通过健康检查，就会从池中剔除，保证流量不会被转发到该服务器，直到其再次通过健康检查为止。

负载均衡算法

负载均衡算法决定了后端的哪些健康服务器会被选中。几个常用的算法：

Round Robin（轮询）：为第一个请求选择列表中的第一个服务器，然后按顺序向下移动列表直到结尾，然后循环。
Least Connections（最小连接）：优先选择连接数最少的服务器，在普遍会话较长的情况下推荐使用。
Source：根据请求源的 IP 的散列（hash）来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器。

DNS 实现负载均衡

DNS 可以用于在冗余的服务器上实现负载平衡。因为现在一般的大型网站使用多台服务器提供服务，因此一个域名可能会对应多个服务器地址。当用户发起网站域名的 DNS 请求的时候，DNS 服务器返回这个域名所对应的服务器 IP 地址的集合，但在每个回答中，会循环这些 IP 地址的顺序，用户一般会选择排在前面的地址发送请求。以此将用户的请求均衡的分配到各个不同的服务器上，这样来实现负载均衡

DNS 为什么使用 UDP 协议作为传输层协议

DNS 使用 UDP 协议作为传输层协议的主要原因是为了避免使用 TCP 协议时造成的连接时延。因为为了得到一个域名的 IP 地
址，往往会向多个域名服务器查询，如果使用 TCP 协议，那么每次请求都会存在连接时延，这样使 DNS 服务变得很慢，因为大
多数的地址查询请求，都是浏览器请求页面时发出的，这样会造成网页的等待时间过长。

使用 UDP 协议作为 DNS 协议会有一个问题，由于历史原因，物理链路的最小 MTU = 576，所以为了限制报文长度不超过 576，
UDP 的报文段的长度被限制在 512 个字节以内，这样一旦 DNS 的查询或者应答报文，超过了 512 字节，那么基于 UDP 的
DNS 协议就会被截断为 512 字节，那么有可能用户得到的 DNS 应答就是不完整的。这里 DNS 报文的长度一旦超过限制，并不
会像 TCP 协议那样被拆分成多个报文段传输，因为 UDP 协议不会维护连接状态，所以我们没有办法确定那几个报文段属于同一
个数据，UDP 只会将多余的数据给截取掉。为了解决这个问题，我们可以使用 TCP 协议去请求报文。

DNS 还存在的一个问题是安全问题，就是我们没有办法确定我们得到的应答，一定是一个安全的应答，因为应答可以被他人伪造，
所以现在有了 DNS over HTTPS 来解决这个问题

详细资料可参考：为什么 DNS 使用 UDP 而不是 TCP

CDN

概念

CDN 是一个内容分发网络，通过对源网站资源的缓存，利用本身多台位于不同地域、不同运营商的服务器，向用户提供资就近访问的
功能。也就是说，用户的请求并不是直接发送给源网站，而是发送给 CDN 服务器，由 CND 服务器将请求定位到最近的含有该资源
的服务器上去请求。这样有利于提高网站的访问速度，同时通过这种方式也减轻了源服务器的访问压力。