备战前端面试–服务端与网络篇

HTTP/HTTPS

HTTP

  1. HTTP 1.0 有什么缺陷？HTTP 1.1 做了哪些改进？

    http 1.0 依赖 TCP 来提供从客户端到服务器端之间的连接，但无法复用连接，发送完成即断开，如果要请求额外资源，必须新建一个连接。建立连接的成本很高(TCP 三次握手)，并且新的 TCP 连接开始时发送速率较慢(慢启动)。

    另外，存在队头阻塞(head-of-line blocking)，当同一个 TCP 长连接中，前面的请求没有得到响应，后面的请求就会被阻塞。也就是每一次请求都必须得到响应。每次请求之间互相影响，其中任一个受到阻塞会使所有请求陷入等待。

    http 1.1 使用长连接(keep-alive)的重用机制，在 http 1.1 中默认开启。同时新增了一些功能：

    host 字段：指定一个虚拟主机(同一 IP 可能对应多个域名)，作为本次连接的访问目标。

    断点续传：分块传输，将任务划分为几部分，每个部分都采用一个线程来上传/下载。遇到网络故障，可以从已经上传/下载的部分继续。比较重要的头部字段：Range(申明本次需要续传的片段) 和 Content-Range、If-Range(文件校验)。

    身份认证：使用较多的是基于JWT(JSON Web Tokens) 的 Token 认证法。

    cache 缓存：http 1.0 时期，强缓存检查的字段是 Expires，约定一个具体时间点。而 1.1 改用 Cache-Control，用一个过期时限来控制缓存。同时在强缓存失效后进入协商缓存，比较重要的头部字段：Last-Modified 和 Etag。

  2. HTTP 2.0 中新增了哪些功能？

    **新的二进制格式(Binary Format)**：http 1.x 的解析是基于文本，由于文本的表现形式多样，格式解析存在缺陷，为了健壮性需要考虑很多种情况。http 2.0 采用二进制格式解析，实现方便且健壮。

    多路复用(MultiPlexing)：即连接共享，引入了流的机制，为每一个请求分配一个 streamID，这样一个连接上可以有多个请求，每个连接内的请求可以随机地混杂在一起。彻底解决了 http 1.x 中存在的队头阻塞问题。

    header 压缩：http 1.x 带有大量头部信息，且每次都要重新发送，在头部上花费了过多流量。http 2.0 通过头部压缩避免了重复 header 的传输，又减小了需要传输的大小。具体而言，在客户端和服务端之间共同维护了一个静态字典和动态字典，使得每次传输的请求头可以由查表获得。且采用哈夫曼编码压缩，根据字符出现的频率建立二叉排序树，确保出现频率最多的字符足够短。

    服务器推送：在 http 2.0 中，服务器不再是被动地接收请求，响应请求，同样地，服务器也可以主动向客户端发送消息。在 TCP 连接建立之后，服务器就可以在客户端请求 HTML 的同时，把 HTML 文件中引用的其他资源也一起返回给客户端，减少等待时间。

  3. 说说多路复用是如何实现的？为什么HTTP 1.1不能实现？

    简单来说，http 2.0 是支持二进制帧的协议，http 1.1 是基于文本分割解析的协议。

    http 1.1 服务端需要不断地读取字节，直到遇到分割符(换行/n)，在此期间不能停止解析，并且无法预知解析需要消耗的内存。因此，也就产生了队头阻塞问题。

    http 2.0 将原先的文本格式转变为二进制格式，headers 和 body 的报文被拆分成一个个二进制帧，比如 Headers 帧存放头部字段，Data 帧存放请求体数据。帧的字节中保存了不同的信息，服务器解析时只需要根据这些字节信息，就可以知道整个帧期望多少字节数来进行处理。为了能够发送不同的数据信息，http 2.0 定义了 10 种帧类型。http 2.0 中的流量控制和优先级管理就是基于其实现的。

    通信双方都可以给对方发送二进制帧，这种二进制帧双向传输的序列，就构成了流(stream)，每个二进制帧都存储着其对应的 streamID。不同的 stream 是乱序传输的基础，不过每个 stream 中的二进制帧一定是按顺序传输的。

  4. GET 和 POST 有什么区别？

    语义角度上，GET 通常用于获取资源。POST 通常是上传资源。

    缓存角度上，GET 请求默认会将资源缓存到本地，GET 不会。

    编码角度上，GET 请求只能使用 URL 编码，接受 ASCII 字符，POST 无限制。

    参数角度上，GET 一般放在 URL 中，因此不安全，POST 放在请求体中，更适合敏感数据传输。

    幂等性角度上，GET 遵循相同操作相同结果，POST 不是。

    TCP 角度上，GET 请求会把请求报文一次性发出去，而 POST 请求会分为两个 TCP 数据包，先发送 Header 部分，如果服务器响应 100(continue)，则继续发送 Body 部分。

  5. 如何理解 HTTP 状态码？

    RFC 规定 HTTP 的状态码为三位数，被分为五类：

    • 1xx：表示目前处于中间状态，需要等待后续处理。

      101：Switching Protocols，在由 HTTP 升级至 WebSocket 时，服务端同意变更，就会发送。

    • 2xx：表示成功状态。

      200：最常见的成功状态。表示响应体中有数据。

      204：NO Content，与 200 含义相同，表示响应体无数据。

      206：Partial Content，表示有部分数据。使用场景为断点续传，会带上响应头 Content-Range。

    • 3xx：重定向状态，表示资源定位发生变化，需要重新请求。

      301： Moved Permanently，永久重定向。

      302：Found，临时重定向。

      304：Not Modified，表示命中协商缓存。

    • 4xx：请求报文有误。

      400：Bad Request，请求有未知错误。

      403：Forbidden，服务器禁止访问。

      404：Not Found，服务器上未找到对应资源。

      405：Method Not Allowed，请求方法不允许。

      406：Not Acceptable，资源不满足客户端条件。

      408：Request Timeout，服务器等待时间过长。

      409：Conflict，多个请求冲突。

      413：Request Entity Too Large，请求体数据过大。

      414：Request-URI Too Long，请求行里的 URI 太大。

      429：Too Many Request，客户端发送的请求过多。

      431：Request Header Fields Too Large，请求头的字段内容太大。

    • 5xx：服务端发生错误。

      500：Internal Server Error，服务器出现未知错误。

      501：Not Implemented，表示客户端请求的功能还不支持。

      502：Bad Gateway，服务器自身是正常的，但访问的时候出错了。

      503：Service Unavailable，表示服务器当前很忙，暂时无法响应服务。

  6. 简要概括一下 HTTP 的特点？HTTP 有哪些缺点？

    特点：

    1. 灵活可扩展。语义上自由，只规定了基本格式，没有严格语法限制。传输形式多样，支持图片、视频、文本数据。
    2. 可靠传输。基于 TCP/IP，因此也能确保发送方和接收方准确、精准地传输。
    3. 请求-应答机制。一发一收，请求必须得到响应。
    4. 无状态。每次 HTTP 请求都是独立的，无上下文，默认不保留状态信息。

    缺点：

    1. 无状态。在需要长连接的情景中，需要保存大量的上下文信息，避免重复传输。不考虑网络开销，无状态反而成为缺陷。
    2. 明文传输。HTTP 以文本格式的报文传输，容易被窃取篡改。
    3. 队头阻塞问题。当共用一个 TCP 连接时，由于请求-应答机制，每次的请求都必须等待响应，同一时间只能处理一个请求，其他的请求都会处于阻塞状态，并发也是如此。

  7. HTTP 如何处理大文件的传输？

    HTTP 采用范围请求的解决方案。其前提是服务端支持。在响应头中加上 Accept-Ranges: bytes，来告诉客户端支持范围请求。

    Range 字段：对于客户端而言，是指定从哪一部分开始请求。其格式为 bytes = x - y。

    服务器收到请求后，首先检查范围是否合法。越界了，返回 416，否则读取相应片段，返回 206。同时，服务端在响应中添加 Content-Range字段。如果在服务端的资源发生了变动，会检查客户端发送的请求头字段 If-Range。字段值既可以用 Last-Modified 时间点用于验证，也可以使用 Etag标记作为验证。但两者不能同时使用。

  8. HTTP 2.0 中的二进制帧是如何设计的？

    每个帧分为两部分，帧头和帧体。帧头的前三位字节表示帧体的长度。然后是帧类型，分为数据帧和控制帧，数据帧存放报文信息，控制帧用来管理流的传输。接下来是一个字节的帧标志，有 8 个标志位。常用的有 END_HEADERS表示头数据结束，END_STREAM表示单方向数据发送结束。后四个字节是 streamID，也就是流标识符，接收方根据其选出 ID 相同的帧，将其组装成请求、响应报文。新建流时，此 ID 会自增，不可重用，达到长度上限后会新开一个 TCP 连接。

HTTPS

  1. HTTPS 为什么让数据传输更安全？

    HTTPS 是加强版的 HTTP。其原理是在 HTTP 和 TCP 间建立了一个中间安全层，将数据包进行加密，传给 TCP，而 TCP 需要将其解密，才能传给 HTTP。

    HTTPS 实际上是 HTTP + SSL/TLS。负责加密的部分就是 SSL/TLS。

  2. 说说 HTTPS 的加密过程？

    首先需要理解对称加密和非对称加密的概念。对称加密是最简单的，即加密和解密使用同一个密钥。对于非对称加密，使用两个密钥分别进行加解密。服务器拥有公钥和私钥，私钥保存在服务器，而公钥是公开的，公钥加密的数据只能用私钥解密，私钥加密的数据同样也只能用公钥解密。

    HTTPS 实际上使用的是对称加密和非对称加密结合的技术。传统 RSA 流程：

    1. 客户端向服务器发送 client_random 和加密方法列表。
    2. 服务器接收到，返回 server_random、加密方法和公钥。
    3. 客户端接收到，生成另一个随机数 pre_random，并用公钥加密，返回给服务器。
    4. 服务器用私钥解密这个 pre_random。

    之后服务器和客户端混合已获得的 client_random、server_random 和 pre_random，使用加密方法生成同样的密钥。然后服务器和客户端使用这个密钥通信，也就是对称加密。

    这个过程中，中间人没有私钥，也就无法拿到 pre_random，因此无法生成最终的密钥，确保了数据传输的安全性。

  3. 为什么 HTTPS 需要添加数字证书？

    尽管通过两种加密方式的结合，能解决大部分情况下的安全问题，但黑客也可以通过 DNS 劫持，将目标地址替换成自己的服务器地址，伪造公钥和私钥，和客户端进行通信。而客户端是无法得知自己访问的是一个危险服务器的。

    于是 HTTPS 又添加了数字证书认证的步骤，目的是验证服务器的身份。

    为了获取这个数字证书，需要向 CA 证书颁发机构获取授权，然后服务器就可以在返回 server_random 的同时，携带上证书，发送给客户端。客户端接收后就开始验证，验证通过再执行之后的步骤。

  4. TLS 1.2 握手的过程是怎样的？

    跟传统 RSA 相比，在 pre_random 生成的部分不同：

    1. 客户端发送 client_random、TLS 版本、加密套件列表。
    2. 服务器接收，返回 server_random、server_params、确认 TLS 版本，加密套件列表和数字证书。
    3. 客户端接收到，先验证数字证书，通过公钥解密由哈希摘要算法计算出的证书摘要，确认证书有效后，生成 client_params 发送给服务器。
    4. 然后就可以使用 ECDHE 算法根据 server_params 和 client_params 计算出 pre_random，通过一个伪随机函数混合 server_random、client_random、pre_random，就得到了最终的密钥 secret。
    5. 客户端在生成 secret 后，向服务器发送一条收尾消息，告诉服务器以后都使用对称加密方式通信。服务器生成 secret 后同样也会向客户端发送收尾消息。

  5. TLS 1.3 做了哪些改进？

    强化安全，废除了很多加密算法，其中就包括经典的 RSA。最后只保留五个加密套件：

    • TLS_AES_128_GCM_SHA256
    • TLS_AES_256_GCM_SHA384
    • TLS_CHACHA20_POLY1305_SHA256
    • TLS_AES_128_GCM_SHA256
    • TLS_AES_128_GCM_8_SHA256

    可以看到，最后剩下的对称加密算法只有 AES 和 CHACHA20，分组模式也只剩下 GCM 和 POLY1305，哈希摘要算法只剩下了 SHA256 和 SHA384。

    在 TLS 1.3 中，ECDHE 彻底取代了 RSA。

    提升性能，改进了握手流程：

    1. 客户端发送 client_params、client_random、TLS 版本、加密套件列表。
    2. 服务器收到，返回 server_params、server_random、确认 TLS 版本，加密套件列表和数字证书。使用 ECDHE 计算 pre_random，然后混合 server_random、client_random、pre_random 得到 secret。
    3. 客户端验证证书通过，立刻使用 ECDHE 计算 pre_random，然后混合 server_random、client_random、pre_random 得到 secret。
    4. 客户端在生成 secret 后，向服务器发送一条收尾消息，告诉服务器以后都使用对称加密方式通信。服务器生成 secret 后同样也会向客户端发送收尾消息。

    和 TLS 1.2 相比，少了一个 RTT。这种 TLS 1.3 握手方式也被叫做1-RTT 握手。通过优化，可以达到 0-RTT。

TCP/IP

  1. 能不能说一说 TCP 和 UDP 的区别？

    TCP 有三大核心特性：

    1. 面向连接

      在通信之前，客户端和服务端需要三次握手来建立连接。

    2. 可靠性

      超时重传机制。TCP 会记录每次传输的数据的具体状态，以保证数据包按序到达。如果丢包或者网络不佳，TCP 会调整自己的行为，控制发送速度或者重发。

    3. 面向字节流

      UDP 的传输是基于数据报的，继承了 IP 层的特性。而 TCP 为了维护状态，将 IP 包变为字节流。

    相比之下，UDP 是一个面向无连接的传输层协议。

  2. 说说 TCP 三次握手？

    最开始双方都处于 CLOSED 状态。然后服务端监听某个端口，进入 LISTEN 状态。

    第一次握手：客户端向服务端发送一个 SYN(序列号 seq = x)，进入 SYN-SENT 状态。

    第二次握手：服务端接收到，消耗 SYN 序列号进行对端确认，返回 ACK(ack = x + 1，每发送一个 SYN，序列号就会加 1，如果有丢失的情况，则会重传) 和 SYN(seq = y)，进入 SYN-RCVD 状态。

    第三次握手：客户端接收到，消耗 SYN 序列号进行对端确认，返回 ACK (ack = y + 1)，进入 ESTABLISHED 状态。服务端接收到，也进入 ESTABLISHED 状态。

    双方已建立连接，可以开始传输数据。

    为什么不是两次？

    原因：无法确认客户端的接收能力、服务端的发送能力。避免无效连接，浪费资源。

    为什么不是四次？

    理论上四次以上都可以，三次就可以解决问题的情况下没必要。

  3. 说说 TCP 四次挥手？

    刚开始双方处于 ESTABLISHED 状态。

    第一次挥手：客户端即将断开，向服务端发送 FIN(seq = p)，进入 FIN-WAIT-1 状态。此时客户端处于半关闭状态，无法发送报文。

    第二次挥手：服务端接收到，向客户端返回 ACK 确认(ack = p + 1)，进入 CLOSED-WAIT 状态。客户端收到，进入 FIN-WAIT-2 状态。

    第三次挥手：服务端在发送完最后的数据之后，向客户端发送 FIN(seq = q)，进入 LAST-ACK 状态。

    第四次挥手：客户端收到服务端的 FIN，进入 TIME-WAIT 状态，返回 ACK(ack = q + 1)，并等待 2 MSL 时间后，进入 CLOSED 状态。服务端接收到 ACK，立即进入 CLOSED 状态。

    为什么最后客户端还要等待 2MSL 的时间？

    MSL 表示报文最大存活时间。1 个 MSL 时间确保 ACK 能到达服务端，因为这个 ACK 可能丢失，导致服务端又重发一次 FIN，这样就需要再用 1 个 MSL 时间等待服务端。再次收到服务端的 FIN 后，会重置等待时间。

    为什么是四次挥手而不是三次？

    因为服务端在收到客户端的 FIN 后，并不能直接发送 FIN，而是要等待最后的数据全部发送完毕。因此先返回一个 ACK，避免客户端误以为 FIN 没有到达，又重新发送。

  4. 说说半连接队列和 SYN Flood 攻击的关系？

    三次握手前，服务端的状态从CLOSED变为LISTEN，同时在内部创建了两个队列：半连接队列和全连接队列，即SYN队列和ACCEPT队列。

    当客户端发送SYN到服务端，服务端收到以后回复ACK和SYN，状态由LISTEN变为SYN_RCVD，此时这个连接就被推入了SYN队列，也就是半连接队列。

    当客户端返回ACK，服务端接收后，三次握手完成。这个时候连接等待被具体的应用取走，在被取走之前，它会被推入另外一个 TCP 维护的队列，也就是全连接队列。

    SYN Flood 属于典型的 DoS/DDoS 攻击。其原理就是利用客户端短时间内伪造大量不存在的 IP，一直向服务器发送SYN，目的是使服务器拒绝服务从而瘫痪。

    此时服务端要处理大量 SYN 并返回 ACK，有大量连接处于 SYN_RCVD 状态，导致半连接队列被占满，无法处理正常请求。

    由于客户端的 IP 地址实际不存在，收不到客户端返回的 ACK，服务端将会一直重复发送数据，直到耗尽资源。

    如何应对？

    1. 增加 SYN 容量。
    2. 减少 SYN + ACK 重试次数，避免大量重发。
    3. 利用 SYN Cookie 技术，在服务端接收到 SYN 后不立即分配一个专门的数据区，而是根据这个 SYN 计算出一个 Cookie，连同第二次握手回复给客户端，在客户端回复 ACK 的时候带上这个 Cookie 值，服务端验证 Cookie 合法之后才分配连接资源。

  5. 能不能说一说 TCP 的流量控制？

    对于发送端和接收端，TCP 需要把发送的数据放到发送缓冲区，接收的数据放到接收缓冲区。

    流量控制是使用滑动窗口实现的。窗口大小指的是可以无需等待应答一次性发送的数据的最大长度。接收端将自己可以接受的缓冲区大小放入 TCP 报文头部中的窗口大小字段，通过 ACK 通知发送端。

    如果接收端的缓冲区已满，就会将窗口大小置 0，此时发送端将不再发送数据，但需要定期发送一个窗口探测数据段，以便接收端调整窗口大小后能通知到发送端。

  6. 能不能说说 TCP 的拥塞控制？

    拥塞控制主要是针对网络进行控制。对于拥塞控制来说，每个 TCP 连接都需要维护一个拥塞窗口和一个慢启动阈值。

    拥塞窗口：

    是指发送端目前还能继续传输的数据大小。当同时存在接收端给出的窗口限制和发送端自身的拥塞窗口限制时，发送窗口取其中的最小值。

    慢启动：

    拥塞控制采用一种保守的策略来适应网络环境，这种算法就是慢启动。运行过程：

    1. 三次握手，双方宣示自己的接收窗口大小。，
    2. 双方初始化自己的拥塞窗口大小。
    3. 在开始传输后的一段时间，每当发送端收到一个 ACK，拥塞窗口大小加 1，因此，每经过一个 RTT，拥塞窗口大小翻倍，直到达到慢启动阈值。

    拥塞避免：

    当达到慢启动阈值后，采用拥塞避免算法来减缓窗口的增长速度。

    快速重传：

    在 TCP 传输的过程中，如果出现丢包，即接收端发现数据段不是按序到达，就会立刻重发之前的 ACK。当发送端收到三个重复的 ACK，就会意识到丢包了，于是马上进行重传。

    选择性重传：

    在接到发送端传来的报文后，接收端回复一个 ACK 报文，可以在其头部的可选项中加上 sack 这个字段，通过 leftedge 和 rightedge 来告诉发送端已经收到了哪些区间内的报文。发送端根据这一信息就可以选择性重传。

    快速恢复：

    发送端在收到三次重复 ACK 后，发现丢包，意识到现在的网络拥塞，但也不必回到慢启动。于是会进入快速恢复状态。此时，拥塞阈值降低为拥塞窗口的一半，拥塞窗口调整到拥塞阈值的大小，并且线性增加。

  7. 说说 TCP/IP 四层模型？每层具体有哪些协议？

    链路层：

    对应 OSI 七层模型的数据链路层和物理层。数据传输的单位主要是数据帧。负责监测数据在主机到网络之间的交换。

    地址解析协议(ARP)工作在此层。将 IP 地址翻译为 MAC 地址，同一局域网内的主机通过交换机来传输数据，而交换机只能识别 MAC 地址。

    网络层：

    对应 OSI 七层模型的网络层。数据传输的单位是数据包。解决主机与主机之间的通信。

    该层主要有三个协议：网际协议(IP)、互联网组管理协议(IGMP)、互联网控制报文协议(ICMP)。

    传输层：

    对应 OSI 七层模型的传输层。数据传输的单位是报文段。为应用层实体提供端到端的通信功能，保证了数据包的顺序传送及数据的完整性。该层定义了两个主要的协议：传输控制协议(TCP)、用户数据报协议(UDP)。

    应用层：

    对应 OSI 七层模型的会话层、表示层、应用层。为用户提供所需要的各种服务。

    基于 TCP 的协议：

    文件传输协议(FTP)、超文本传输协议(HTTP)、安全套接层(SSL)、安全文件传送协议(SFTP)、简单邮件传输协议(SMTP)。

    基于 UDP 的协议：

    简单文件传输协议(TFTP)、域名解析系统(DNS)、动态主机配置协议(DHCP)、简单网络管理协议(SNMP)。

其他

  1. 简单解释下 Websocket 的概念？

    Websocket 是一种数据传输协议，通过 TCP 建立的持久连接，使得客户端和服务端可以随时交换数据。

    常用的使用场景是聊天室、弹幕、协同编辑、股票基金报价。

    Websocket 的特点有：

    全双工：通信允许在两个方向上同时传输，相当于两个单工通信方式的结合。

    二进制帧：采用了二进制帧的结构，语法语义与 HTTP 2.0 不同，Websocket 倾向于实时通信，而 HTTP 2.0 侧重于传输效率。

    协议名：引入 ws、wss 分别代表明文和密文的 websocket 协议。默认端口为 80 或 443，与 HTTP 一致。

  2. DNS 协议是什么？说说完整的查询过程？

    DNS，即域名解析系统，是互联网一项服务，是进行域名和与之相对应的 IP 地址进行转换的服务器。

    域名是一个具有层次的结构，从上到下一次为根域名、顶级域名、二级域名、三级域名…

    比如：www.xxx.com，www 为三级域名，xxx 为二级域名，com为顶级域名。系统为用户做了兼容，尾部的 . 根域名一般不需要输入。在域名的每一层都有一个域名服务器。

    DNS 查询方式有三种：

    递归查询：如果 A 请求 B，那么 B 一定要给出答案。比如主机向本地域名服务器发起请求，如果查询不到，本地域名服务器会向其他根域名服务器转发请求，直到找到为止或者返回错误。

    迭代查询：如果 B 没有 A 想要的内容，B 不自己发出请求，而是告诉 A 如何获得这个内容。比如本地域名服务器向根域名服务器发起请求，根域名服务器不知道请求所需的内容，就给请求方指定另一个域名服务器，让其自己去查询。

    非递归查询：B 上有 A 需要的内容，或者知道 A 需要的内容如何获得。分为两种情况，一种是本地域名服务器缓存了对应的 IP，直接返回。另一种是本地域名服务器中缓存了对应域名的权威服务器，那么再查询一次，将结果返回。

    在域名服务器解析的时候，使用缓存保存域名和IP地址的映射。分两种缓存方式：

    浏览器缓存：浏览器在获取网站域名的实际 IP 地址后会对其进行缓存，减少网络请求的损耗。

    操作系统缓存：用户自己配置的 hosts 文件。

    解析域名的过程如下：

    1. 首先搜索浏览器的缓存。
    2. 没有命中，继续搜索操作系统的 DNS 缓存。
    3. 仍然未命中，操作系统将域名发送给本地域名服务器，本地域名服务器采用递归方式查询自己的 DNS 缓存。
    4. 本地域名服务器的 DNS 缓存未命中，向上级域名服务器进行迭代查询。
    5. 首先本地域名服务器请求根域名服务器，根域名服务器返回对应的顶级域名服务器的地址。
    6. 本地域名向顶级域名服务器发起请求，获取权限域名服务器的地址。
    7. 本地域名服务器根据权限域名服务器的地址向其发起请求，最终得到该域名对应的 IP 地址。
    8. 本地域名服务器将得到的 IP 地址返回给操作系统，同时自己将 IP 地址缓存起来。
    9. 操作系统将 IP 地址返回给浏览器，同时自己也将 IP 地址缓存。
    10. 浏览器得到了域名对应的 IP 地址，并将 IP 地址缓存。

  3. 如何理解CDN？说说实现原理？

    CDN，即内容分发网络。构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN 的关键技术主要有内容存储和分发技术。

    简单来讲，CDN就是根据用户位置分配最近的资源。于是，用户在上网的时候不用直接访问源站，而是访问离他最近的一个 CDN 节点，边缘节点，其实就是缓存了源站内容的代理服务器。

    应用CDN后，DNS 返回的不再是 IP 地址，而是一个CNAME(Canonical Name ) 别名记录，指向CDN的全局负载均衡。CNAME实际上在域名解析的过程中承担了中间人的角色，这是CDN实现的关键。

    由于没有返回IP地址，于是本地DNS会向负载均衡系统再发送请求 ，则进入到CDN的全局负载均衡系统进行智能调度：

    • 查找用户的 IP 地址，查表得知地理位置，查找相对最近的边缘节点。
    • 看用户的网络运营商，查找相同网络的边缘节点。
    • 检测边缘节点的负载状态，找负载较轻的节点。
    • 比较节点的健康状况、服务能力、带宽。

    综合得出最适合的边缘节点，返回给用户，用户就能就近访问 CDN 的缓存代理。

    缓存系统是 CDN 中另一个重要组成部分。缓存系统会尽量缓存常用的资源。

    通过 CDN 的负载均衡系统，智能调度边缘节点提供服务，相当于 CDN 服务的大脑，而缓存系统相当于CDN的心脏，缓存命中直接返回给用户，否则回源站查找。