计算机网络部分知识八股总结

flyfishing
24 阅读32分钟

永久笔记--七层网络参考模型简述

![[Pasted image 20260119215723.png]]

7.应用层

使用最多的一层，例如ajax调用接口发送http请求，再比如域名系统DNS，邮件协议SMTP，webSocket长连接，SSH协议

6.表示层

作用：安全加密，解密。对图片文件等格式进行编码和解码，例如JPGE和ASCLL

5.会话层

是再发送方和接受方之间进行通信时创建、维持、之后终止或断开连接的地方。 会话层包含了一种称为检查点（Checkpoint）的机制来维持可靠会话，检查点定义了一个最接近成功通信的点，并定义了当发送内用丢失或损坏时需要回滚以便恢复丢失或损坏数据的点，即断电下载的原理

4.传输层

主要是定义我们的端口号，以及控流和校验 并且有两个熟知的协议TCP和UDP TCP稳定（由于三次握手和四次挥手），但这样会降低速度 UDP没有，所以不稳定，但是速度快，常用于直播和游戏

3.网络层

这一层定义了我们的ip地址 该层控制数据链路层与传输层之间的信息转发，建立，维持和终止网络的连接。 具体地说，数据链路层的数据在这一层被转换为数据包，然后通过路径选择、分段组合、顺序、进/出路由等控制，将信息从一个网络设备传送到另一个网络设备

  1. 寻址：对网络层使用IP地址来唯一标识互联网上的设备（类似数据链路层的MAC）
  2. 路由：在同一网络中的内部通信不需要网络层设备，仅仅靠数据链路层就可以完成相互通信，对于不同的网络之间的相互通信必须借助路由器等三层设备（路由器在三层工作）

2.数据链路层

进行硬件寻址。差错交验等功能。将比特组合成字节进而组合成帧，用MAC地址访介质，错误发现但不能纠正

MAC地址: 每个网卡的唯一标识，和ip地址随机组合

1.物理层

网卡网线，中继器，调制解调器

永久笔记--HTTP协议发展历程

HTTP超文本传输协议，目前的版本可以分为HTTP0.9，HTTP1.0，HTTP1.1、HTTP2.0、HTTP3.0

协议发展+强弱缓存+HTTPS加密+webSocket+sse

HTTP 0.9

被称为单行协议，由单行执行构成，以唯一可用方法GET开头，其后跟着目标资源的路径。HTTP 0.9 的响应内容不包含HTTP头，这意味着只有HTML文件可以传送，同时没有状态码和错误代码。出现异常时返回一个包含问题描述信息的HTML文件

  • 只有请求行，没有HTTP请求头和请求体
  • 服务器没有返回头信息，只返回数据信息
  • 返回的文件内容是以ASCII字符流传输的，因为都是HTML格式的文件，所以用ASCLL字节码传输合适

HTTP 1.0

HTTP 1.0，引入了以Key-Value形式保存的请求头和响应头，为了满足传输多种类型文件的需求

  • 客户端发起请求时，会把协议版本信息（比如HTTP/1.0）直接写在请求行（GET开头）里一起发送给服务器
  • 引入请求头，在发起请求时会通过HTTP请求头高数服务器它期待服务器返回什么类型的文件、采取去什么形式的压缩，提送什么语言的文件以及文件的具体编码
  • 引入响应头，服务器以请求头中的信息准备数据，并以响应头的信息高数客户端数据采用何种格式返回
  • 引入状态码，状态码会在响应开始时发送，是浏览器能了解请求执行成功或失败，然后相应调整行为
  • 引入缓存机制，通过状态码与If-Modified-Since 、 Expires 等控制更新或使用本地缓存
  • 引入了Content-Type 头，使HTTP 具备了传输除纯文本HTML文件以外其他文档的能力

HTTP 1.1

标准化的协议，消除歧义内容并引入多项改进

  • 缓存处理，HTTP 1.1 引入了更多的缓存控制策略，例如Entity tag、If-Unmodified-Since 、If-None-Match 等可供选择的缓存头来控制缓存策略
  • 新增在请求头中引入了rang, 其允许只请求资源的某一部分，即返回206 状态码，方便开发者充分利用链接和宽带。
  • 新增可以使用Range 和 Content-Range 制作断点续传功能
  • 新增错误通知的管理，在HTTP 1.1中新增了24个错误状态码
  • 新增Host 请求头,可以使不同的域名配置在同一个IP地址的服务器上
  • 支持长连接 ,在一个TCP连接上可以纯属多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在 HTTP 1.1中默认开启 Connection:keep-alive ,一般浏览器对于同一个域名允许同时建立6个长连接
  • 增加管线话技术，允许在第一个应答被完全发送之前就发送第二个请求，来改善队头阻塞问题，但是相应的顺序还是会按照请求的顺序返回
  • 支持响应分块，通过设置Transfer-Encoding:chunked 进行分块响应，允许香型数据可分为多个部分，配合服务端尽早释放缓冲加快相应速度

HTTP 2.0

HTTP 2.0在网络效率方面做了大量的优化

  • 二进制分帧，HTTP2.0采用的是二进制协议而不是文本协议，会将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码
  • 多路复用，并行的请求能在同一个链接中处理，在同一域名下所用访问都是从同一个TCP连接中走，HTTP消息被分解为独立的帧，服务端根据标识符和首部将消息重新组装起来，同时移除了HTTP 1.1中顺序和阻塞的约束
  • 压缩header, header在一系列请求中常常非常相似，其移除了重复和传输重复数据的成本
  • 服务端推送，服务器可以主动的向客户端推送字眼，而无需客户端明确的请求

HTTP 3.0

不是2.0的拓展，是一个全新的协议，会运行在QUIC协议上，是在UDP的基础上实现可靠传输。

永久笔记--HTTPS加密传输

HTTPS全称为Hyper Text Transfer Protocol over SecureSocket Layer，在HTTP基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS在HTTP的基础上加入SSL层

通常来说，HTTP直接与TCP进行通信，当我们使用SSL时，则就会变成HTTP先和SSL通信，SSL再与TCP进行通信，也就是中间人。所谓的HTTPS实际上就是身披SSL协议这层外壳的HTTP

HTTP

应用层协议，默认运行在80端口，传输未加密的明文数据，风险大

HTTPS

应用层协议，默认运行在433 端口，通过在HTTP层与运输层直接直接加入一个加密身份验证层

SSL

SSL安全套接层，全称Secure Socket Layer，位于TCP/IP协议与各种应用层协议之间，SSL协议可分为两层：

  • SSL 记录协议 SSL Record Protocol：其建立在可靠的传输协议如TCP上，为高层协议提供数据封装、压缩、加密等基本功能支持
  • SSL 握手协议 SSL Handshake Protocol：其建立在SSL记录协议之上，用于在实际数据传输开始前，通选双方进行身份认证1，协商加密算法，交换加密秘钥

TLS

TLS传输层安全协议 Transport Layer Security 用于在两个通信应用程序之间提供保密性和数据完整性，其由TLS记录协议和TLS握手协议组成。TLS1.0 就是SSL3.0的标准化版本，SSL最初由网景提出研发，在SSL3.0是有国际互联网工程任务组IETF进行标准化并添加少量机制，更名为TLS1.0

对称加密

简单来说对称加密的加密秘钥和解密密钥是相同的，对称加密的效率比非对称的效率高

非对称加密

加密秘钥与解密密钥不同，需要一把公钥和一把私钥，私钥不能被其他人知道，公钥可以公开。公钥加密，私钥解密；私钥数据签名，公钥验证

CA

由于公钥放在服务器，在建立链接的过程中将公钥传输到用户，但是如何避免传输公钥过程中劫持？ 引入了第三方权威认证机构CA ,大多数操作系统的CA证书是默认安装，其也有一个公钥和私钥。 证书包括持有者的公钥，身份信息，CA数字签名，证书有效信息，CA的身份信息等 任何人可得到CA的证书，其中包含公钥用以验证它签发的证书。 ![[image.png]] 核心流程（3 步）

  • 服务器向 CA 申请证书 → CA 核实身份后，把服务器公钥 + 身份信息绑定，用自己的私钥 “签字” 生成证书。
  • 客户端访问服务器 → 服务器发送证书（不直接发公钥）。
  • 客户端用系统预装的 CA 公钥验证证书签名 → 验证通过 = 公钥可信，失败 = 拦截风险。

传输过程详解

  1. 首先TCP三次握手建立链接，这是数据传输基础，在此之上开始SSL
  2. 客户端先发送 Client Hello ？开始SSL通信，包稳重包含客户端支持的SSL版本、随机值Random1、加密算法以及密钥长度
  3. 服务器发送Server Hello，和客户端一样在报文中包含SSL版本，随机值Random2 以及加密组件， 此后服务端将证书也发送到客户端
  4. 此时客户端需要对服务端发送的证书进行验证，通过操作系统内置的CA证书，将服务器发送的证书的数字签名惊醒解密，并将证书的公钥进行相同算法的HASH与解密的数字签名解密的内容进行对比，验证证书是否合法有效
  5. 客户端验证证书合法，然后生成一个随机值Random3，用公钥对Random3进行加密，生成Pre-Master Key，客户端以Client Key Exchange报文将Pre-Master Key发送到服务端，此后发送Change Cipher Spec报文表示此后数据传输进行加密传输。
  6. 服务端将Pre-Master Key用自己的私钥解密为Random3,服务端发送Change Cipher Spec报文表示此后数据传输进行加密传输。
  7. 此时客户端与服务端都拥有三个随机字符串，且Random3是密文传输的，是安全状态的，此时则可以使用这三个字符串进行对称加密传输。由于非对称加密慢，不能每次传输数据都进行非对称加密，所以使用非对称加密将密钥协商好然后使用对称加密进行数据传输。
  8. 此时便正常进行HTTP数据传输，但是由于SSL加密的作用，此时的HTTP传输便是安全的，此为HTTPS的传输过程，其中2、3、5、6也被称为SSL四次握手。

下面是详细解释：

一、 前置步骤：TCP 三次握手（建立基础通信通道）

HTTPS 是基于 TCP 传输的，所以第一步必须先建立可靠的 TCP 连接，就像你去银行必须先和柜员搭上线：

  1. 你（客户端）：“你好，能办业务吗？”（SYN 报文）

  2. 银行（服务端）：“可以，你来吧！”（SYN+ACK 报文）

  3. 你：“好的，我来了！”（ACK 报文）

    结果：你和柜员的 “沟通管道” 通了，接下来才能谈正事（SSL 握手）。

二、 核心步骤：SSL/TLS 握手（协商加密规则 + 验证身份，共 4 步）

这一步是 HTTPS 安全的关键，目的是 “验明银行真身”+“约定安全暗号”，防止中间人冒充银行骗你。

步骤 1：客户端打招呼（Client Hello）

你主动对柜员说：

“我支持的加密规则有 A/B/C 这几种，这是我的随机码 Random1，咱们按规则来！”

  • 技术动作：客户端发送支持的 TLS 版本、加密套件（比如 AES 对称加密、RSA 非对称加密）、随机值 Random1。

步骤 2：服务端回应 + 亮身份（Server Hello + 发证书）

柜员回应你，同时掏出营业执照（CA 证书）：

“好的，咱们用 A 规则！这是我的随机码 Random2。另外，给你看我的营业执照，证明我是真银行！”

  • 技术动作：

    1. 服务端确认 TLS 版本和加密套件，返回 Random2；
    2. 把 CA 签发的服务器证书 发给客户端（证书里包含：服务器公钥 + 网站身份信息 + CA 的数字签名）。

步骤 3：客户端验证证书 + 发加密密钥（验证证书 + Client Key Exchange）

这一步是防中间人攻击的核心，你要做两件事：

  1. 验营业执照真假：

    你掏出手机里的 CA 公钥（公章模板），去核对银行营业执照上的 CA 签名：

    • ✅ 验证通过：证书是真的 → 证书里的服务器公钥也是真的；
    • ❌ 验证失败：浏览器弹出警告 → 你直接跑路（拒绝访问）。

  2. 生成暗号并加密发送：

    你生成一个关键随机值 Random3（这个就是后续对称加密的 “暗号本”），用证书里的服务器公钥加密，生成 Pre-Master Key，发给柜员：

    “我确认你是真银行！这是我加密后的暗号本，只有你能打开！”

  • 技术动作：

    客户端验证证书合法性 → 生成 Random3 → 用服务器公钥加密得到 Pre-Master Key → 发送给服务端；

    同时发送 Change Cipher Spec 报文：“接下来咱们说话都用暗号加密！”

步骤 4：服务端解密 + 确认加密通信（解密密钥 + 确认）

柜员拿到你发的加密暗号本，用自己的私钥解密，得到 Random3：

“收到！我解密出暗号本了，接下来咱们都用暗号聊天！”

  • 技术动作：

    服务端用私钥解密 Pre-Master Key → 得到 Random3；

    发送 Change Cipher Spec 报文：“我也准备好加密通信了！”

三、 最终步骤：对称加密传输 HTTP 数据

此时，客户端和服务端都有了 3 个随机值：Random1 + Random2 + Random3。

双方用这 3 个随机值，生成同一个对称加密密钥（就是之前说的 “暗号”）。

接下来的 HTTP 数据传输：

  • 客户端把 HTTP 请求（比如 “查余额”）用对称密钥加密 → 发给服务端；
  • 服务端用同一个对称密钥解密 → 处理请求；
  • 服务端把响应（比如 “余额 1000 元”）加密 → 发回客户端；
  • 客户端解密 → 显示内容。

为什么不用非对称加密传数据？

非对称加密速度慢，像 “用快递寄信”；对称加密速度快，像 “俩人私下说暗号”。所以只在握手时用非对称加密传 “暗号本”，真正传数据用对称加密。

四、 一句话总结 HTTPS 完整流程

先 TCP 三次握手建通道 → 再 SSL 四次握手验身份 + 协商加密密钥 → 最后用对称加密传 HTTP 数据

永久笔记--TCP三次握手

名词 1.seq(sequence number),随机生成序列号，指当前数据包的序列号 2.ack（acknowledagement number) 确认号 ack = seq + 1，回应之前的包 3.ACK （acknowledgement）确认序列号有效 4.SYN（synchronous）发起新链接

客户端(Client)                             服务器(Server)
   |                                           |
   |              SYN, Seq=X                   |
   |-----------------------------------------> |
   |                                           |
   |             SYN-ACK, Seq=Y, Ack=X+1       |
   |<----------------------------------------- |
   |                                           |
   |              ACK, Seq=X+1, Ack=Y+1        |
   |-----------------------------------------> |
   |                                           |

第一次握手：客户端选择一个初始序列号，然后向服务器发送一个SYN包，包里无数据，只为了初始化序列号（举例：客户端发送了一个SYN包，其序列号为X）

第二次握手：服务端收到SYN包后，返回一个确认系列号有效的包，同时返回自己的Seq序列号和收到的客户端序列号+1 （服务器收到客户端的SYN包后，会发送一个SYN-ACK包作为应答，这个包中的ACK号设为X+1，表示服务器已经收到了客户端的SYN包，同时，服务器也会选择自己的初始序列号，假设为Y，并将该序列号放在SYN包内发送给客户端）

第三次握手: 客户端接收到服务器的SYN-ACK包后，会发送一个ACK包给服务器，这个包的序列号为X+1，确认号Ack为Y+1，表示客户端已经接受到了服务器的SYN包

三次握手结束，TCP建立完毕，数据传输开始

三次握手的意义是什么？

综合来讲是因为服务端和客户端都需要知道对方是否都可接受和发送，所以需要三次握手

  • 第一次握手成功让服务器知道客户端有发送功能
  • 第二次握手让客户端知道服务器有发送和接受功能呢，但是此时服务器并不知道刻度段是否能接受到自己发送的信息（如果此时服务端立刻给客户端发送数据，客户端肯能还没有准备好接受数据）
  • 第三次握手让服务器知道客户端能接受到自己的消息并且已经做好了接受自己消息的准备

为什么会是三次握手，而不是两次

  • 为了防止出现失效的链接请求报文段被服务单接受到的情况，导致错误（没有第三次的确认）

三次握手都能携带数据吗？

第一次第二次都不能，此时没建立连接，会让服务器受到攻击 第三次握手时客户端已处于链接状态，且知道服务器的接受和发送能力都正常，所以可携带

永久笔记--TCP四次挥手

为什么需要四次挥手？

TCP 连接是全双工的，这意味着需要双方分别关闭各自的发送通道，且需确认对方已接收所有剩余数据，最后等待一段时间后才能彻底关闭连接，以确保最后一个 ACK 的可靠性。

客户端(Client)                             服务器(Server)
   |                                          |
   |              FIN, Seq=Z                  |
   |----------------------------------------->|
   |               ACK, Ack=Z+1               |
   |<-----------------------------------------|
   |                                          |
   |              FIN, Seq=W                  |
   |<-----------------------------------------|
   |              ACK, Ack=W+1                |
   |----------------------------------------->|
   |                                          |

第一次挥手：当客户端完成数据的发送后，就会发送一个FIN包给服务器代表客户端没有东西可以发了，关闭自身的发送通道，假设客户端序列号为Z

第二次挥手：服务器接收到客户端的FIN包后，会发送一个ACK包作为回应，确认号为Z+1，服务器自身的发送通道不关闭，因为可能还有数据没发完 此时服务器的接收通道、发送通道均保持开放（无接收通道关闭的操作），仅客户端的发送通道已关闭；若服务器还有未发完的数据，会继续通过自身发送通道传输，暂不发起关闭请求。

第三次挥手：服务器没有数据要发送了，会返回一个FIN包给客户端，关闭自身的发送通道，请求释放服务器到客户端的链接，假设此时的服务器序列号为W

第四次挥手：客户端收到服务器的FIN包后，会发送一个ACK包作为回应，ACK确认号为W+1。发送该ACK是为了确认服务器关闭请求（避免延迟报文干扰导致资源浪费），发送完后彻底释放连接资源

补充

  1. TCP全双工通信中，FIN包仅负责“关闭发送方自身的发送通道”，不影响接收通道，也不直接释放整个连接，需双方各自关闭发送通道并确认后，连接才彻底释放。

  2. ACK包仅用于“确认收到对方数据/请求”，不会触发任何通道关闭操作，通道关闭仅由FIN包触发。

  3. ACK包里的Seq和Ack是两个独立字段，并非同一概念。Seq是发送方自身的序列号（标记本次发送报文的位置），Ack是确认号（对应对方上一次的Seq+1，表明确认收到对方数据），二者同时存在于ACK包中，名称和功能互不混淆。

  4. Seq不是与 FIN 包分开的，而是包含在每次发送的 FIN 包中。TCP 报文（包括 FIN 包、ACK 包等）均自带 Seq（序列号）字段，用于标记发送端当前发送数据的位置。

永久笔记--TCP与UDP

传输层的两个关键协议：TCP（传输控制协议）和 UDP（用户数据报协议）

TCP提供可靠的有序的，基于字节流的传输服务。机制包括超时重传，拥塞控制

流量控制：通过控制发送这个的发送速度来缓解接受的的拥堵 拥堵控制：当网络出现拥塞是，TCP可以减小向网络指数数据的速率和数量来缓解拥塞

两者区别：

  • 流量控制是作用域接受者，他控制发送者的发送速度从而使接受者来得及接受，防止数据包丢失
  • 拥塞控制作用于网络，方式过多数据注入网络中，避免网络负载过大

流量控制和滑动窗口

  • 为了解决发送端和接收端速度不匹配的问题（发太快让接收方缓冲区慢了，导致数据丢失） 所以在发送端有发送缓冲区，接收端有接收缓冲区

  • 滑动窗口是这里的实现工具，实际运用中，接收端会计算自己接收缓冲区的剩余大小，将该数值写入TCP报文头部的 16位窗口大小字段 ，发送给发送端

    这里的剩余大小就是接收窗口（rwnd），发送端的发送窗口（swnd）会参考这个值控制发送量

滑动窗口“滑动”的含义：接收端处理完一批数据（从缓冲区取走用了），缓冲区剩余空间变大 → 窗口大小就会变大，发送端的发送窗口也跟着 “滑动扩大”，可以多发点数据

拥塞控制（全局的网络路况适应）

TCP拥塞控制靠 拥塞窗口（cwnd） 实现，该窗口代表“当前网络能承载的最大发送量” 有四个核心算法

1.慢启动：先探路暴增
  • 刚开始发送，不知道网络好坏，所以先从小窗口开始发（cwnd=1个报文段）
  • 每收到一次确认（ACK），cwnd翻倍，1248指数增长
  • 增长至 慢启动阈值 时停止，进入“拥塞避免”
2.拥塞避免：稳步增长
  • 现在不再指数翻倍，而是每经过一个往返时间（RTT），cwnd只加1，慢慢线性增长来试探网络上线
  • 如果发现网络拥塞（如超时没收到ACK），触发拥塞处理，把慢启动阈值ssthresh = 当前cwnd的一半，然后将cwnd重置为1，重新开始慢启动

注意：实际网络传输中，大多数稳定场景下并不会一直循环慢启动和拥塞避免，而是会长期停留在 拥塞避免 阶段；只有遇到网络拥塞触发超时，或者快速恢复后重新进入增长流程时，才会再次走慢启动→拥塞避免的路径。

3.快速重传：不等超时就补发
  • 正常情况，发送端需要等待超时计时器超时才会重传丢失的报文（太慢）
  • 快速重传：接收方收到失序的报文（如应该收3号，但是来了4），立即发送重复确认，发送端连续收到三个重复确认立即重传
4.快速恢复：丢包了不用从慢启动重新开
  • 发送端收到三个重复确认时，不把cwnd重置为1搞慢启动，而是
  • 将ssthresh = 当前cwnd的一半，然后将cwnd设置为ssthresh，直接进入拥塞避免阶段线性增长

两者传送区别

UDP 是 报文 Oriented：应用层给一个完整的消息，UDP 直接打包成一个报文发出去 → 发 1000 字节就是一个 1000 字节的 UDP 包

TCP 是 字节流 Oriented：TCP 不关心应用层的 “消息边界”，只把数据看成一串连续的字节 → 会根据 发送窗口大小 拆分字节流，分成多个 TCP 报文段发送。

UDP和TCP的区别：

  • TCP是面向连接的。UDP是无连接的（发送数据前不需要建立连接）
  • （在传输层中）TCP是可靠传输，且保证了数据的正确有序，UDP是不可靠的，肯能会丢包或乱序（TCP粘包是应用层分不清楚两个消息包边界的问题）
  • TCP面向字节流。UDP是面向报文，且没有拥塞控制模块，应用层让UDP发多少数据，UDP就按这个速率发（哪怕网已经堵了），所以容易丢包
  • TCP首部开销大，最小20字节最大60字节，而UDP首部开销小，仅8字节
  • TCP只能一对一，UDP支持多对多

永久笔记--DNS（域名系统） DNS的作用是通过域名查询到具体的IP地址。是属于应用层的协议，该协议通常运行在UDP协议上

查询流程： 以谷歌浏览器为例 当访问www.google.com时，会在客户端进行“无网络通信的本地缓存匹配”操作

  • 谷歌浏览器先查看 浏览器自身 是否具有该域名的IP缓存
  • 谷歌浏览器再查看 操作系统 是否有该域名的IP缓存
  • 谷歌浏览器再看 Host文件 中是否有该域名的解析配置

如果host文件中也没有对应的目录，浏览器就会请求本地域名服务器LDNS来解析该域名 如果LDNS也没有域名的记录，就会进行迭代查询

  • LDNS先去 DNS根域名服务器 查询，这一步会查询到负责com这一 顶级域名 的服务器
  • LDNS再去 这个服务器 查询google.com这个二级域名
  • LDNS再去查询www.google.com的地址，“www” 是主机名
  • LDNS最后返回给服务器并缓存起来

正确层级为：根域（.）→顶级域（.com）→二级域（[google.com](https://google.com)）→主机名（www） ![[Pasted image 20260119230750.png]]

DNS负载均衡

问题：当大型网站里使用了多台服务器，一个域名可能会对应多个服务器地址，这该怎么办？

  • 当用户发起网站域名的DNS请求后，DNS服务器会返回这个域名所对应的服务器的IP地址的部分集合响应。用户设备的操作系统接收 DNS 响应后，会按响应中 IP 的顺序尝试建立 TCP 连接，成功建立连接的 IP 即为最终通信的服务器 IP。
  • 权威DNS服务器会动态调整每次的ip顺序和组合，来确保不同用户额的请求分配到不同的真实服务器，实现负载均衡

反向代理均衡负载

通过“中间代理”屏蔽真实服务器，来是先对真实服务器的负载均衡和保护，具体流程为：

  • 网站的DNS解析近返回代理服务器的IP（真实服务器的ip不对外暴露），用户请求直接发送到反向代理服务器。反向代理服务器接收请求后，根据预设的负载均衡策略，将请求转发到后端集群中的某一台真实服务器

永久笔记--CDN（内容分发网络）

CDN核心作用是通过全球分布式节点，将网络静态资源（图片，视频，JS/CSS，静态页面等）缓存到用户就近的服务器上。 CDN属于应用层，依赖DNS解析，HTTP缓存等技术，核心基于“缓存”和“就近分发”

工作流程

（以访问www.example.com上的一张图片logo.png为例）

1. 普通场景（无 CDN）的迭代查询完整流程
  1. 客户端请求 www.example.com → 先查本地缓存（浏览器 / 系统 / Hosts），无结果则问 LDNS；
  2. LDNS 先查根域服务器（.）→ 根域返回 .com 顶级域服务器 IP；
  3. LDNS 查 .com 顶级域服务器 → 顶级域返回 example.com 的权威 DNS 服务器 IP；
  4. LDNS 查 example.com 的权威 DNS 服务器 → 权威 DNS 直接返回源服务器 IP（1.2.3.4）；
  5. LDNS 缓存该结果，返回给客户端 → 客户端直接连源服务器。

此时，权威 DNS 是迭代查询的最后一步，且返回源 IP。

2. CDN 场景的迭代查询完整流程（核心差异在第 4 步）

  1. 客户端请求 www.example.com/logo.png → 本地缓存无结果，问 LDNS；

  2. LDNS 先查根域服务器（.）→ 根域返回 .com 顶级域服务器 IP；

  3. LDNS 查 .com 顶级域服务器 → 顶级域返回 example.com 的权威 DNS 服务器 IP；

  4. LDNS 查 example.com 的权威 DNS 服务器 → 权威 DNS 不返回源 IP，而是返回 CDN 的 GSLB 节点 IP（如 5.6.7.8）；

  5. LDNS 缓存该 GSLB IP，返回给客户端；

  6. 客户端再向 GSLB 节点请求 → GSLB 调度到就近的 CDN 边缘节点 → 后续走 CDN 缓存流程。

  7. 边缘节点先检查自身缓存： 若缓存中有该图片（且未过期），直接将图片返回给用户（全程无需访问源服务器，速度最快）。 若缓存中没有（或已过期），边缘节点会向网站的 “源服务器” 发起请求，获取 logo.png。

  8. 缓存并返回资源：CDN 边缘节点从源服务器拿到 logo.png 后，会先将其缓存（按预设的缓存策略，如 1 天过期），再将图片返回给用户。后续其他北京电信用户访问该图片时，会直接从这个边缘节点获取缓存，无需重复请求源服务器

技术细节包括：缓存策略（TTL，Cache Key），智能调度（GSLB），源站保护和回源策略

应用场景：

  • 大型网站电商,淘宝京东将商品图片，视频等缓存到CDN保证全国用户访问速度一致
  • 视频：B站通过CDN分发视频流，避免卡顿（直播用CDN推送流到边缘节点）
  • 静态网站：个人网站全程CDN托管

强缓存和和协商缓存

浏览器缓存是浏览器在本地磁盘对用户最近请求过的资源进行存储，当访问者再次访问同一资源时，浏览器就可以直接从本地磁盘加载资源。 通过缓存的方式可以减少与服务器的数据传输，减少服务器的负担，加快页面响应速度

概述

通常浏览器缓存策略可分为强缓存和协商缓存。常见的HTTP缓存只能存储GET响应，对于其他类型的响应者不会进行缓存。

理论上讲一个资源被缓存，会永久存储在缓存中，但是由于空间有限，需要“缓存驱逐”来清理空间。

注意：一个陈旧的资源缓存副本是不会直接被清除或忽略。

当客户端发起一个请求时，缓存检索到已有一个对应的陈旧资源缓存副本，则缓存会先将此请求附加一个If-None-Match头，然后发给目标服务器，以此来检查该资源副本是否是依然还是算新鲜的。 若服务器返回了304 (Not Modified)，则表示此资源副本是新鲜的，注意该响应不会有带有实体信息，通过这种方式，可以节省一些带宽。 若服务器通过If-None-Match或If-Modified-Since判断后发现已过期，那么会带有该资源的实体内容返回。

以上的过程可以总结为：

  • 浏览器发起对资源的请求是，会首先检查本地是否存在缓存，如果存在缓存，则通过expires 和cache-control 来检查缓存是否过期。如果命中缓存且缓存未过期，则直接使用本地缓存
  • 本地缓存未命中，这浏览器想服务器发送一个协商请求，通过last-modified和etag 来验证资源是否命中协商缓存，如果命中则服务器会讲这个请求响应为 304 ,但是不是返回这个资源的数据，依然是从缓存中读取资源，如果为命中则会携带资源返回且响应为 200

强缓存

强缓存是通过Expires 与 Cache-Control 来控制缓存在本地的有效期

Expires

Expires 是 HTTP 1.0 提出的一个表示资源过期时间的 Header ，它描述的是一个绝对时间，有服务器返回。Expires受限于本地时间，如果修改了本地时间，可能会造成缓存失效，对于资源的请求，如果在Expires之内，这浏览器会直接读取缓存，不再请求服务器

Expires: Sun, 14 Jun 2020 02:50:57 GMT

Cache-Control

Cache-Control 出现于 HTTP 1.1 ,优先级高于 Expires，表示的是相对时间，请求头和响应头都支持这个属性，通过它提供的不同的值来定义缓存策略

Cache-Control: max-age=300

  • Cache-Control: no-store:缓存中不得存储任何关于客户端请求和服务端响应的内容，每次由客户端发起的请求到会下载完整的响应内容

  • Cache-Control: no-cache: 缓存中会存储服务端响应的内容，知识在与服务端进行新鲜度再验证之前，该缓存不能够提供给浏览器使用。简单来说，就是浏览器会将服务端响应的资源进行缓存，但是在每次请求时，缓存都要向服务端评估缓存响应的有效性，协商缓存是否可用，根据响应式304还是200来判断是使用本地缓存资源还是使用服务器响应的资源

  • Cache-Control:public || private: public 表示该响应可以被任何中间人比如中间代理，CDN等缓存。默认响应为private，private表示该响应式专用的，中间人不能缓存次响应，该响应只能应用于浏览器私有缓存中。

  • Cache-Control: max-age=3153600:响应为最大的过期时间，其指令s是max-age=<seconds>，表示资源能被缓存即保持新鲜的最大时间，max-age是距离请求发起的时间的秒数

  • Cache-Control: must-revalidate: 当使用了must-revalidate指令，那就意味着缓存在考虑使用一个陈旧的资源时，必须先验证它的状态，已过期的缓存将不被使用。

    （在正常情况下是没有必要使用这个指令的，因为在强缓存过期的情况下会进行协商缓存，但是HTTP规范是允许客户端在某些特殊情况下直接使用过期缓存的，比如校验请求发送失败的时候，还比如有配置一些特殊指令stale-while-revalidate、stale-if-error等的时候，must-revalidate指令就是让缓存在过期后的任何情况下都必须重新验证。）

协商缓存

当浏览器对某个资源的请求没有命中强缓存，就会发送一个请求到服务器，验证协商缓存是否命中。

  • 如果协商缓存命中，请求响应返回的HTTP状态码为304(not Modified),该请求不带数据（资源未修改，使用本地缓存即可）
  • 如果未命中，则返回200并携带资源实体数据。（资源过期了，给你瓶新的） 协商缓存是理由Last-Modified, If-Modified-Since 和 Etag、If-None-Match这两对Header来管理的

Last-Modified, If-Modified-Since

Last-Modified，If-Modified-Since是HTTP 1.0引入的，Last-Modified表示本地文件最后修改日期，浏览器会在请求头加上If-Modified-Since即上次响应的Last-Modified的值，询问服务器在该日期后资源是否有更新，有更新的话就会将新的资源发送回来，但是如果在本地打开缓存文件，就会造成Last-Modified被修改，所以在HTTP 1.1出现了ETag。

ETag If-None-Match]

Etag就像一个指纹，资源变化都会导致ETag变化，跟最后修改时间没有关系，ETag可以保证每一个资源是唯一的，If-None-Match的请求头字段会将上次返回的Etag发送给服务器，询问该资源的Etag是否有更新，有变动就会发送新的资源回来。ETag的优先级比Last-Modified更高，具体使用ETag主要出于下面几种情况考虑：

  • 一些文件也许会周期性的更改，但是他的内容并不改变，比如仅仅改变的修改时间，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET。
  • 某些文件修改非常频繁，比如在秒以下的时间内进行修改，例如1s内修改了N次，If-Modified-Since能检查到的粒度是秒级的，这种修改无法判断。
  • 某些服务器不能精确的得到文件的最后修改时间。
avatar
文章
阅读
粉丝