## 一、HTTP协议
### 1. GET和POST请求的差异
无论是POST还是GET请求都是基于的**超文本传输协议**（**HTTP**）的，而HTTP协议是TCP/IP协议家族的应用层协议。 HTTP协议客户端请求request新闻包括以下格式：`请求行（request line）、请求头部（header）、空行，请求数据`； 
服务端响应response它还由四个部分组成：`响应行、响应头、空行、响应体`。
##### 请求参数：GET请求参数是通过URL多个参数以传输为准&连接，POST请求放在request body中。GET请求长度最多1024kb，POST对请求数据没有限制。
##### POST比GET安全性高:这里的安全是相对的，通过GET提交的数据将显示URL页面将被浏览器缓存，其他人将在查看历史记录时看到提交的数据POST不会。另外GET提交数据也可能导致CSRF攻击。
##### **收藏为书签**：GET请求支持，POST请求不支持。 **数据类型的参数**：GET只接受ASCII字符，而POST没有限制。
### 2. POST和PUT请求的区别
- PUT请求是将数据发送到服务器端修改数据内容，但不会增加数据类型，也就是说，无论多少次PUT操作，其结果并没有不同。（可以理解为时**更新数据**） - POST请求是将数据发送到服务器端，它将改变数据和其他资源，创建新内容。(可以理解为是**创建数据**）
### 3. 常见的HTTP请求头和响应头
**HTTP Request Header 常见请求头：**
- Accept:浏览器可以处理的内容类型 - Accept-Charset:浏览器可以显示的字符集 - Accept-Encoding：浏览器可以处理的压缩编码 - Accept-Language：目前浏览器设置的语言 - Connection：连接浏览器和服务器的类型 - Cookie：任何当前页面设置Cookie - Host：页面所在的域 - Referer：发布请求页面URL - User-Agent：浏览器的用户代理字符串
**HTTP Responses Header 常见响应头：**
- Date：时间的描述格式表示消息发送的时间rfc822定义 - server:服务器名称 - Connection：连接浏览器和服务器的类型 - Cache-Control：控制HTTP缓存 - content-type:后面的文档属于什么？MIME类型
常见的 Content-Type 有四种属性值：
（1）application/x-www-form-urlencoded：本地浏览器 form 如果不设置表单 enctype 属性最终会是 application/x-www-form-urlencoded 提交数据的方式。这这种方式提交的数据放在这里 body 内部，按数据 key1=val1&key2=val2 编码的方式，key 和 val 都进行了 URL转码。
（2）multipart/form-data：这种方法也很常见 POST 这种方式通常用于表单上传文件。
（3）application/json：服务器消息主体是序列化的 JSON 字符串。
（4）text/xml：该方法主要用于提交 XML 格式数据。
### 4. HTTP状态码304有多好还是少好？
为了提高网站访问速度，服务器指定了以前访问的一些页面的缓存机制。当客户端在此要求这些页面时，服务器将根据缓存内容判断页面是否与以前相同。如果相同，则直接返回304。此时，客户调用缓存内容，无需二次下载。
状态码304不应该被视为错误，而应该被视为客户端**有缓存**服务端的响应。
搜索引擎蜘蛛更喜欢内容源更新频繁的网站。通过在特定时间内捕获网站返回的状态代码来调整网站的捕获频率。如果该网站在一定时间内处于304状态，蜘蛛可能会减少对该网站的捕获次数。相反，如果网站变化频率非常快，每次捕获都可以获得新内容，那么随着时间的推移，回访率也会增加。
**产生较多304状态码的原因：**
- 页面更新周期长或不更新 - 纯静态页面或强制静态页面html
**304状态码出现过多会造成以下问题：**
- 停止网站快照； - 收录减少； - 权重下降。
### 5. 常见的HTTP请求方法
- GET: 向服务器获取数据； - POST：将实体提交到指定的资源，通常会造成服务器资源的修改； - PUT：上传文件，更新数据； - DELETE：删除服务器上的对象； - HEAD：第一篇报文，和GET相比之下，不返回报文主体； - OPTIONS：询问跨域请求支持的请求方法； - CONNECT：在与代理服务器通信时，需要建立隧道TCP通信； - TRACE: 回显服务器收到的请求主要是测试或诊断。
### 6. OPTIONS请求方法及使用场景
OPTIONS是除了GET和POST其他一个 HTTP请求方法。
OPTIONS该方法用于获得请求`Request-URI`在请求/响应通信过程中可以使用标识资源的功能选项。通过这种方法，客户端可以**在采取具体资源请求之前，决定采取哪些必要措施，或了解服务器的性能**。请求方法的响应不能缓存。
OPTIONS请求方法的**主要用途**有两个：
- 所有获得服务器支持的服务器HTTP请求方法； - 用于检查访问权限。例如：正在进行中 CORS 在跨域资源共享中，复杂的要求是使用 OPTIONS 方法发送嗅探请求，以判断是否有对指定资源的访问权限。
### 7. HTTP 1.0 和 HTTP 1.1 两者有什么区别？
**HTTP 1.0和 HTTP 1.1 有以下区别**：
- **连接方面**，http1.0 默认使用非持久连接， http1.1 持久连接默认使用。http1.1 使用持久连接使多个连接 http 同一个请求复用 TCP 为避免使用非持久连接时每次都需要建立连接延迟。 - **资源请求**，在 http1.0 有一些浪费带宽的现象，比如客户端只需要某个对象的一部分，而服务器发送整个对象，不支持断点续传功能，http1.1 引入请求头 range 头域允许只要求资源的某一部分，即返回码 206（Partial Content），便于开发者自由选择，充分利用带宽和连接。 - **缓存方面**，在 http1.0 中主要使用 header 里的 If-Modified-Since、Expires 作为缓存判断的标准，http1.1 引入了更多的缓存控制策略，例如 Etag、If-Unmodified-Since、If-Match、If-None-Match 等待更多可供选择的缓存头来控制缓存策略。 - http1.1 中**新增了 host 字段**，用于指定服务器域名。http1.0 认为每个服务器都绑定了唯一的服务器 IP 因此，请求消息中的地址 URL 主机名没有传输（hostname）。然而，随着虚拟主机技术的发展，物理服务器上可以有多个虚拟主机，并共享一个IP地址。因此有了 host 这样，请求就可以发送到同一个服务器上的不同网站。 - http1.1 相对于 http1.0 还增加了很多**请求方法**，如 PUT、HEAD、OPTIONS 等。
### 8. HTTP 1.1 和 HTTP 2.0 的区别
- **二进制协议**：HTTP/2 是二进制协议。在 HTTP/1.1 在版本中，报纸的头信息必须是文本（ASCII 编码)，数据体可以是文本，也可以是二进制。HTTP/2 它是一个完整的二进制协议，头部信息和数据体是二进制，统称为"帧"，可分为头信息帧和数据帧。 帧的概念是实现多路复用的基础。 - **多路复用：** HTTP/2 实现多路复用，HTTP/2 仍然复用 TCP 但接，但在连接中，客户端和服务器可以同时发送多个请求或响应，而无需按顺序逐一发送，以避免"队头堵塞"1问题。 - **数据流：** HTTP/2 由于数据流的概念，使用了数据流的概念 HTTP/2 不按顺序发送数据包，同一连接中的连续数据包，可能属于不同的要求。因此，必须标记数据包，并指出它属于哪个请求。HTTP/2 将每个请求或响应的所有数据包称为数据流。每个数据流都有一个独特的编号。数据包发送时，必须标记数据流 ID ，用来区分它属于哪个数据流。 - **头信息压缩：** HTTP/2 由于头部信息压缩的实现， HTTP 1.1 协议没有状态，所有信息必须附在每个请求上。因此，请求的许多字段都是重复的，例如 Cookie 和 User Agent ，每一个请求都必须附带相同的内容，这会浪费大量的带宽，影响速度。HTTP/2 优化了这一点，引入了头信息压缩机制。一方面，使用头信息 gzip 或 compress 压缩后发送；另一方面，客户端和服务器同时维护头部信息表，所有字段都存储在表中，生成索引号，以后不发送相同的字段，只发送索引号，以提高速度。 - **服务器推送：** HTTP/2 未经要求，允许服务器主动向客户端发送资源，称为服务器推送。使用服务器提前向客户端推送必要的资源，以减少一些延迟。这里需要注意的是 http2 下服务器主动推送静态资源和 WebSocket 以及使用 SSE 以不同的方式向客户端发送即时数据。
**1队头堵塞：**
> 队头阻塞是由的 HTTP 基本的请求 - 应答模型。HTTP 规定报纸必须一发一收，形成先进先出的串行队列。队列中没有要求先级的，只有入队的先后顺序，排在最前面的请求会被最优先处理。如果队首的请求因为处理的太慢耽误了时间，那么队列里后面的所有请求也不得不跟着一起等待，结果就是其他的请求承担了不应有的时间成本，造成了队头堵塞的现象。
### 9. HTTP和HTTPS协议的区别
HTTP和HTTPS协议的主要区别如下：
- HTTPS协议需要CA证书，费用较高；而HTTP协议不需要； - HTTP协议是超文本传输协议，信息是明文传输的，HTTPS则是具有安全性的SSL加密传输协议； - 使用不同的连接方式，端口也不同，HTTP协议端口是80，HTTPS协议端口是443； - HTTP协议连接很简单，是无状态的；HTTPS协议是有SSL和HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP更加安全。
### 10. GET方法URL长度限制的原因
实际上HTTP协议规范并没有对get方法请求的url长度进行限制，这个限制是特定的浏览器及服务器对它的限制。 IE对URL长度的限制是2083字节(2K+35)。由于IE浏览器对URL长度的允许值是最小的，所以开发过程中，只要URL不超过2083字节，那么在所有浏览器中工作都不会有问题。
```javascript GET的长度值 = URL（2083）- （你的Domain+Path）-2（2是get请求中?=两个字符的长度） 复制代码 ```
下面看一下主流浏览器对get方法中url的长度限制范围：
- Microsoft Internet Explorer (Browser)：IE浏览器对URL的最大限制为2083个字符，如果超过这个数字，提交按钮没有任何反应。 - Firefox (Browser)：对于Firefox浏览器URL的长度限制为 65,536 个字符。 - Safari (Browser)：URL最大长度限制为 80,000 个字符。 - Opera (Browser)：URL最大长度限制为 190,000 个字符。 - Google (chrome)：URL最大长度限制为 8182 个字符。
主流的服务器对get方法中url的长度限制范围：
- Apache (Server)：能接受最大url长度为8192个字符。 - Microsoft Internet Information Server(IIS)：能接受最大url的长度为16384个字符。
根据上面的数据，可以知道，get方法中的URL长度最长不超过2083个字符，这样所有的浏览器和服务器都可能正常工作。
### 11. 当在浏览器中输入 Google.com 并且按下回车之后发生了什么？
（1）**解析URL：** 首先会对 URL 进行解析，分析所需要使用的传输协议和请求的资源的路径。如果输入的 URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。如果没有问题，浏览器会检查 URL 中是否出现了非法字符，如果存在非法字符，则对非法字符进行转义后再进行下一过程。
（2）**缓存判断：** 浏览器会判断所请求的资源是否在缓存里，如果请求的资源在缓存里并且没有失效，那么就直接使用，否则向服务器发起新的请求。
（3）**DNS解析：** 下一步首先需要获取的是输入的 URL 中的域名的 IP 地址，首先会判断本地是否有该域名的 IP 地址的缓存，如果有则使用，如果没有则向本地 DNS 服务器发起请求。本地 DNS 服务器也会先检查是否存在缓存，如果没有就会先向根域名服务器发起请求，获得负责的顶级域名服务器的地址后，再向顶级域名服务器请求，然后获得负责的权威域名服务器的地址后，再向权威域名服务器发起请求，最终获得域名的 IP 地址后，本地 DNS 服务器再将这个 IP 地址返回给请求的用户。用户向本地 DNS 服务器发起请求属于递归请求，本地 DNS 服务器向各级域名服务器发起请求属于迭代请求。
（4）**获取MAC地址：** 当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址，因为应用层下发数据给传输层，TCP 协议会指定源端口号和目的端口号，然后下发给网络层。网络层会将本机地址作为源地址，获取的 IP 地址作为目的地址。然后将下发给数据链路层，数据链路层的发送需要加入通信双方的 MAC 地址，本机的 MAC 地址作为源 MAC 地址，目的 MAC 地址需要分情况处理。通过将 IP 地址与本机的子网掩码相与，可以判断是否与请求主机在同一个子网里，如果在同一个子网里，可以使用 APR 协议获取到目的主机的 MAC 地址，如果不在一个子网里，那么请求应该转发给网关，由它代为转发，此时同样可以通过 ARP 协议来获取网关的 MAC 地址，此时目的主机的 MAC 地址应该为网关的地址。
（5）**TCP三次握手：** 下面是 TCP 建立连接的三次握手的过程，首先客户端向服务器发送一个 SYN 连接请求报文段和一个随机序号，服务端接收到请求后向服务器端发送一个 SYN ACK报文段，确认连接请求，并且也向客户端发送一个随机序号。客户端接收服务器的确认应答后，进入连接建立的状态，同时向服务器也发送一个ACK 确认报文段，服务器端接收到确认后，也进入连接建立状态，此时双方的连接就建立起来了。
（6）**HTTPS握手：** 如果使用的是 HTTPS 协议，在通信前还存在 TLS 的一个四次握手的过程。首先由客户端向服务器端发送使用的协议的版本号、一个随机数和可以使用的加密方法。服务器端收到后，确认加密的方法，也向客户端发送一个随机数和自己的数字证书。客户端收到后，首先检查数字证书是否有效，如果有效，则再生成一个随机数，并使用证书中的公钥对随机数加密，然后发送给服务器端，并且还会提供一个前面所有内容的 hash 值供服务器端检验。服务器端接收后，使用自己的私钥对数据解密，同时向客户端发送一个前面所有内容的 hash 值供客户端检验。这个时候双方都有了三个随机数，按照之前所约定的加密方法，使用这三个随机数生成一把秘钥，以后双方通信前，就使用这个秘钥对数据进行加密后再传输。
（7）**返回数据：** 当页面请求发送到服务器端后，服务器端会返回一个 html 文件作为响应，浏览器接收到响应后，开始对 html 文件进行解析，开始页面的渲染过程。
（8）**页面渲染：** 浏览器首先会根据 html 文件构建 DOM 树，根据解析到的 css 文件构建 CSSOM 树，如果遇到 script 标签，则判端是否含有 defer 或者 async 属性，要不然 script 的加载和执行会造成页面的渲染的阻塞。当 DOM 树和 CSSOM 树建立好后，根据它们来构建渲染树。渲染树构建好后，会根据渲染树来进行布局。布局完成后，最后使用浏览器的 UI 接口对页面进行绘制。这个时候整个页面就显示出来了。
（9）**TCP四次挥手：** 最后一步是 TCP 断开连接的四次挥手过程。若客户端认为数据发送完成，则它需要向服务端发送连接释放请求。服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。但是因为 TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入 LAST-ACK 状态。客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。当服务端收到确认应答后，也便进入 CLOSED 状态。
### 12. 对keep-alive的理解
HTTP1.0 中默认是在每次请求/应答，客户端和服务器都要新建一个连接，完成之后立即断开连接，这就是**短连接**。当使用Keep-Alive模式时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接，这就是**长连接**。其使用方法如下：
- HTTP1.0版本是默认没有Keep-alive的（也就是默认会发送keep-alive），所以要想连接得到保持，必须手动配置发送`Connection: keep-alive`字段。若想断开keep-alive连接，需发送`Connection:close`字段； - HTTP1.1规定了默认保持长连接，数据传输完成了保持TCP连接不断开，等待在同域名下继续用这个通道传输数据。如果需要关闭，需要客户端发送`Connection：close`首部字段。
Keep-Alive的**建立过程**：
- 客户端向服务器在发送请求报文同时在首部添加发送Connection字段 - 服务器收到请求并处理 Connection字段 - 服务器回送Connection:Keep-Alive字段给客户端 - 客户端接收到Connection字段 - Keep-Alive连接建立成功
**服务端自动断开过程（也就是没有keep-alive）**：
- 客户端向服务器只是发送内容报文（不包含Connection字段） - 服务器收到请求并处理 - 服务器返回客户端请求的资源并关闭连接 - 客户端接收资源，发现没有Connection字段，断开连接
**客户端请求断开连接过程**：
- 客户端向服务器发送Connection:close字段 - 服务器收到请求并处理connection字段 - 服务器回送响应资源并断开连接 - 客户端接收资源并断开连接
开启Keep-Alive的**优点：**
- 较少的CPU和内存的使⽤（由于同时打开的连接的减少了）； - 允许请求和应答的HTTP管线化； - 降低拥塞控制 （TCP连接减少了）； - 减少了后续请求的延迟（⽆需再进⾏握⼿）； - 报告错误⽆需关闭TCP连；
开启Keep-Alive的**缺点**：
- 长时间的Tcp连接容易导致系统资源无效占用，浪费系统资源。
### 13. 页面有多张图片，HTTP是怎样的加载表现？
- 在`HTTP 1`下，浏览器对一个域名下最大TCP连接数为6，所以会请求多次。可以用**多域名部署**解决。这样可以提高同时请求的数目，加快页面图片的获取速度。 - 在`HTTP 2`下，可以一瞬间加载出来很多资源，因为，HTTP2支持多路复用，可以在一个TCP连接中发送多个HTTP请求。
### 14. HTTP2的头部压缩算法是怎样的？
HTTP2的头部压缩是HPACK算法。在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，采用哈夫曼编码来压缩整数和字符串，可以达到50%~90%的高压缩率。
具体来说:
- 在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送； - 首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新； - 每个新的首部键值对要么被追加到当前表的末尾，要么替换表中之前的值。
例如下图中的两个请求， 请求一发送了所有的头部字段，第二个请求则只需要发送差异数据，这样可以减少冗余数据，降低开销。 
### 15. HTTP请求报文的是什么样的？
请求报⽂有4部分组成:
- 请求⾏ - 请求头部 - 空⾏ - 请求体
 **其中：** （1）请求⾏包括：请求⽅法字段、URL字段、HTTP协议版本字段。它们⽤空格分隔。例如，GET /index.html HTTP/1.1。 （2）请求头部:请求头部由关键字/值对组成，每⾏⼀对，关键字和值⽤英⽂冒号“:”分隔
- User-Agent：产⽣请求的浏览器类型。 - Accept：客户端可识别的内容类型列表。 - Host：请求的主机名，允许多个域名同处⼀个IP地址，即虚拟主机。
（3）请求体: post put等请求携带的数据 
### 16. HTTP响应报文的是什么样的？
请求报⽂有4部分组成:
- 响应⾏ - 响应头 - 空⾏ - 响应体
- 响应⾏：由网络协议版本，状态码和状态码的原因短语组成，例如 HTTP/1.1 200 OK 。 - 响应头：响应部⾸组成 - 响应体：服务器响应的数据
### 17. HTTP协议的优点和缺点
HTTP 是超文本传输协议，它定义了客户端和服务器之间交换报文的格式和方式，默认使用 80 端口。它使用 TCP 作为传输层协议，保证了数据传输的可靠性。
HTTP协议具有以下**优点**：
- 支持客户端/服务器模式 - **简单快速**：客户向服务器请求服务时，只需传送请求方法和路径。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。 - **无连接**：无连接就是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。 - **无状态**：HTTP 协议是无状态协议，这里的状态是指通信过程的上下文信息。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能会导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就比较快。 - **灵活**：HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。
HTTP协议具有以下**缺点**：
- **无状态：** HTTP 是一个无状态的协议，HTTP 服务器不会保存关于客户的任何信息。 - **明文传输：** 协议中的报文使用的是文本形式，这就直接暴露给外界，不安全。 - **不安全**
（1）通信使用明文（不加密），内容可能会被窃听； （2）不验证通信方的身份，因此有可能遭遇伪装； （3）无法证明报文的完整性，所以有可能已遭篡改；
### 18. 说一下HTTP 3.0
HTTP/3基于UDP协议实现了类似于TCP的多路复用数据流、传输可靠性等功能，这套功能被称为QUIC协议。 
1. 流量控制、传输可靠性功能：QUIC在UDP的基础上增加了一层来保证数据传输可靠性，它提供了数据包重传、拥塞控制、以及其他一些TCP中的特性。 2. 集成TLS加密功能：目前QUIC使用TLS1.3，减少了握手所花费的RTT数。 3. 多路复用：同一物理连接上可以有多个独立的逻辑数据流，实现了数据流的单独传输，解决了TCP的队头阻塞问题。
1. 快速握手：由于基于UDP，可以实现使用0 ~ 1个RTT来建立连接。
### 19. HTTP协议的性能怎么样
HTTP 协议是基于 TCP/IP，并且使用了**请求-应答**的通信模式，所以性能的关键就在这两点里。
- **长连接**
HTTP协议有两种连接模式，一种是持续连接，一种非持续连接。 （1）非持续连接指的是服务器必须为每一个请求的对象建立和维护一个全新的连接。 （2）持续连接下，TCP 连接默认不关闭，可以被多个请求复用。采用持续连接的好处是可以避免每次建立 TCP 连接三次握手时所花费的时间。
对于不同版本的采用不同的连接方式：
- 在HTTP/1.0 每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无畏的 TCP 连接建立和断开，增加了通信开销。该版本使用的非持续的连接，但是可以在请求时，加上 Connection: keep-a live 来要求服务器不要关闭 TCP 连接。 - 在HTTP/1.1 提出了**长连接**的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。该版本及以后版本默认采用的是持续的连接。目前对于同一个域，大多数浏览器支持同时建立 6 个持久连接。
- **管道网络传输**
HTTP/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。
管道（pipeline）网络传输是指：可以在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。但是服务器还是按照顺序回应请求。如果前面的回应特别慢，后面就会有许多请求排队等着。这称为队头堵塞。
- **队头堵塞**
HTTP 传输的报文必须是一发一收，但是，里面的任务被放在一个任务队列中串行执行，一旦队首的请求处理太慢，就会阻塞后面请求的处理。这就是HTTP队头阻塞问题。
**队头阻塞的解决方案：** （1）并发连接：对于一个域名允许分配多个长连接，那么相当于增加了任务队列，不至于一个队伍的任务阻塞其它所有任务。 （2）域名分片：将域名分出很多二级域名，它们都指向同样的一台服务器，能够并发的长连接数变多，解决了队头阻塞的问题。
### 20. URL有哪些组成部分
以下面的URL为例：**[www.aspxfans.com:8080/news/index.…](https://link.juejin.cn?target=http%3A%2F%2Fwww.aspxfans.com%3A8080%2Fnews%2Findex.asp%3FboardID%3D5%26ID%3D24618%26page%3D1%23name)**
从上面的URL可以看出，一个完整的URL包括以下几部分：
- **协议部分**：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符； - **域名部分**：该URL的域名部分为“[www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用](https://link.juejin.cn?target=http%3A%2F%2Fwww.aspxfans.com%E2%80%9D%E3%80%82%E4%B8%80%E4%B8%AAURL%E4%B8%AD%EF%BC%8C%E4%B9%9F%E5%8F%AF%E4%BB%A5%E4%BD%BF%E7%94%A8IP%E5%9C%B0%E5%9D%80%E4%BD%9C%E4%B8%BA%E5%9F%9F%E5%90%8D%E4%BD%BF%E7%94%A8) - **端口部分**：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口（HTTP协议默认端口是80，HTTPS协议默认端口是443）； - **虚拟目录部分**：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”； - **文件名部分**：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名； - **锚部分**：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分； - **参数部分**：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。
### 21. 与缓存相关的HTTP请求头有哪些
强缓存：
- Expires - Cache-Control
协商缓存：
- Etag、If-None-Match - Last-Modified、If-Modified-Since
## 二、HTTPS协议
### 1. 什么是HTTPS协议？
超文本传输安全协议（Hypertext Transfer Protocol Secure，简称：HTTPS）是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，利用SSL/TLS来加密数据包。HTTPS的主要目的是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。  HTTP协议采用**明文传输**信息，存在**信息窃听**、**信息篡改**和**信息劫持**的风险，而协议TLS/SSL具有**身份验证**、**信息加密**和**完整性校验**的功能，可以避免此类问题发生。
安全层的主要职责就是**对发起的HTTP请求的数据进行加密操作** 和 **对接收到的HTTP的内容进行解密操作**。
### 2. TLS/SSL的工作原理
**TLS/SSL**全称**安全传输层协议**（Transport Layer Security）, 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。
TLS/SSL的功能实现主要依赖三类基本算法：**散列函数hash**、**对称加密**、**非对称加密**。这三类算法的作用如下：
- 基于散列函数验证信息的完整性 - 对称加密算法采用协商的秘钥对数据加密 - 非对称加密实现身份认证和秘钥协商
#### （1）散列函数hash
常见的散列函数有MD5、SHA1、SHA256。该函数的特点是单向不可逆，对输入数据非常敏感，输出的长度固定，任何数据的修改都会改变散列函数的结果，可以用于防止信息篡改并验证数据的完整性。
**特点：** 在信息传输过程中，散列函数不能三都实现信息防篡改，由于传输是明文传输，中间人可以修改信息后重新计算信息的摘要，所以需要对传输的信息和信息摘要进行加密。
#### （2）对称加密
对称加密的方法是，双方使用同一个秘钥对数据进行加密和解密。但是对称加密的存在一个问题，就是如何保证秘钥传输的安全性，因为秘钥还是会通过网络传输的，一旦秘钥被其他人获取到，那么整个加密过程就毫无作用了。 这就要用到非对称加密的方法。
常见的对称加密算法有AES-CBC、DES、3DES、AES-GCM等。相同的秘钥可以用于信息的加密和解密。掌握秘钥才能获取信息，防止信息窃听，其通讯方式是一对一。
**特点：** 对称加密的优势就是信息传输使用一对一，需要共享相同的密码，密码的安全是保证信息安全的基础，服务器和N个客户端通信，需要维持N个密码记录且不能修改密码。
#### （3）非对称加密
非对称加密的方法是，我们拥有两个秘钥，一个是公钥，一个是私钥。公钥是公开的，私钥是保密的。用私钥加密的数据，只有对应的公钥才能解密，用公钥加密的数据，只有对应的私钥才能解密。我们可以将公钥公布出去，任何想和我们通信的客户， 都可以使用我们提供的公钥对数据进行加密，这样我们就可以使用私钥进行解密，这样就能保证数据的安全了。但是非对称加密有一个缺点就是加密的过程很慢，因此如果每次通信都使用非对称加密的方式的话，反而会造成等待时间过长的问题。
常见的非对称加密算法有RSA、ECC、DH等。秘钥成对出现，一般称为公钥（公开）和私钥（保密）。公钥加密的信息只有私钥可以解开，私钥加密的信息只能公钥解开，因此掌握公钥的不同客户端之间不能相互解密信息，只能和服务器进行加密通信，服务器可以实现一对多的的通信，客户端也可以用来验证掌握私钥的服务器的身份。
**特点：** 非对称加密的特点就是信息一对多，服务器只需要维持一个私钥就可以和多个客户端进行通信，但服务器发出的信息能够被所有的客户端解密，且该算法的计算复杂，加密的速度慢。
综合上述算法特点，TLS/SSL的工作方式就是客户端使用非对称加密与服务器进行通信，实现身份的验证并协商对称加密使用的秘钥。对称加密算法采用协商秘钥对信息以及信息摘要进行加密通信，不同节点之间采用的对称秘钥不同，从而保证信息只能通信双方获取。这样就解决了两个方法各自存在的问题。
### 3. 数字证书是什么？
现在的方法也不一定是安全的，因为没有办法确定得到的公钥就一定是安全的公钥。可能存在一个中间人，截取了对方发给我们的公钥，然后将他自己的公钥发送给我们，当我们使用他的公钥加密后发送的信息，就可以被他用自己的私钥解密。然后他伪装成我们以同样的方法向对方发送信息，这样我们的信息就被窃取了，然而自己还不知道。为了解决这样的问题，可以使用数字证书。
首先使用一种 Hash 算法来对公钥和其他信息进行加密，生成一个信息摘要，然后让有公信力的认证中心（简称 CA ）用它的私钥对消息摘要加密，形成签名。最后将原始的信息和签名合在一起，称为数字证书。当接收方收到数字证书的时候，先根据原始信息使用同样的 Hash 算法生成一个摘要，然后使用公证处的公钥来对数字证书中的摘要进行解密，最后将解密的摘要和生成的摘要进行对比，就能发现得到的信息是否被更改了。
这个方法最要的是认证中心的可靠性，一般浏览器里会内置一些顶层的认证中心的证书，相当于我们自动信任了他们，只有这样才能保证数据的安全。 
### 4. HTTPS通信（握手）过程
HTTPS的通信过程如下：
1. 客户端向服务器发起请求，请求中包含使用的协议版本号、生成的一个随机数、以及客户端支持的加密方法。 2. 服务器端接收到请求后，确认双方使用的加密方法、并给出服务器的证书、以及一个服务器生成的随机数。 3. 客户端确认服务器证书有效后，生成一个新的随机数，并使用数字证书中的公钥，加密这个随机数，然后发给服 务器。并且还会提供一个前面所有内容的 hash 的值，用来供服务器检验。 4. 服务器使用自己的私钥，来解密客户端发送过来的随机数。并提供前面所有内容的 hash 值来供客户端检验。 5. 客户端和服务器端根据约定的加密方法使用前面的三个随机数，生成对话秘钥，以后的对话过程都使用这个秘钥来加密信息。
### 5. HTTPS的特点
HTTPS的**优点**如下：
- 使用HTTPS协议可以认证用户和服务器，确保数据发送到正确的客户端和服务器； - 使用HTTPS协议可以进行加密传输、身份认证，通信更加安全，防止数据在传输过程中被窃取、修改，确保数据安全性； - HTTPS是现行架构下最安全的解决方案，虽然不是绝对的安全，但是大幅增加了中间人攻击的成本；
HTTPS的**缺点**如下：
- HTTPS需要做服务器和客户端双方的加密个解密处理，耗费更多服务器资源，过程复杂； - HTTPS协议握手阶段比较费时，增加页面的加载时间； - SSL证书是收费的，功能越强大的证书费用越高； - HTTPS连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本； - SSL证书需要绑定IP，不能再同一个IP上绑定多个域名。
### 6. **HTTPS**是如何保证安全的？
先理解两个概念：
- 对称加密：即通信的双⽅都使⽤同⼀个秘钥进⾏加解密，对称加密虽然很简单性能也好，但是⽆法解决⾸次把秘钥发给对⽅的问题，很容易被⿊客拦截秘钥。 - ⾮对称加密：
1. 私钥 + 公钥= 密钥对 2. 即⽤私钥加密的数据,只有对应的公钥才能解密,⽤公钥加密的数据,只有对应的私钥才能解密 3. 因为通信双⽅的⼿⾥都有⼀套⾃⼰的密钥对,通信之前双⽅会先把⾃⼰的公钥都先发给对⽅ 4. 然后对⽅再拿着这个公钥来加密数据响应给对⽅,等到到了对⽅那⾥,对⽅再⽤⾃⼰的私钥进⾏解密
⾮对称加密虽然安全性更⾼，但是带来的问题就是速度很慢，影响性能。
**解决⽅案：**
结合两种加密⽅式，将对称加密的密钥使⽤⾮对称加密的公钥进⾏加密，然后发送出去，接收⽅使⽤私钥进⾏解密得到对称加密的密钥，然后双⽅可以使⽤对称加密来进⾏沟通。
此时⼜带来⼀个问题，中间⼈问题： 如果此时在客户端和服务器之间存在⼀个中间⼈,这个中间⼈只需要把原本双⽅通信互发的公钥,换成⾃⼰的公钥,这样中间⼈就可以轻松解密通信双⽅所发送的所有数据。
所以这个时候需要⼀个安全的第三⽅颁发证书（CA），证明身份的身份，防⽌被中间⼈攻击。 证书中包括：签发者、证书⽤途、使⽤者公钥、使⽤者私钥、使⽤者的HASH算法、证书到期时间等。
但是问题来了，如果中间⼈篡改了证书，那么身份证明是不是就⽆效了？这个证明就⽩买了，这个时候需要⼀个新的技术，数字签名。
数字签名就是⽤CA⾃带的HASH算法对证书的内容进⾏HASH得到⼀个摘要，再⽤CA的私钥加密，最终组成数字签名。当别⼈把他的证书发过来的时候,我再⽤同样的Hash算法,再次⽣成消息摘要，然后⽤CA的公钥对数字签名解密,得到CA创建的消息摘要,两者⼀⽐,就知道中间有没有被⼈篡改了。这个时候就能最⼤程度保证通信的安全了。
## 三、HTTP状态码
状态码的类别：
| **类别** | **原因** | **描述** | | -------- | ------------------------------- | -------------------------- | | 1xx | Informational(信息性状态码) | 接受的请求正在处理 | | 2xx | Success(成功状态码) | 请求正常处理完毕 | | 3xx | Redirection(重定向状态码) | 需要进行附加操作一完成请求 | | 4xx | Client Error (客户端错误状态码) | 服务器无法处理请求 | | 5xx | Server Error(服务器错误状态码) | 服务器处理请求出错 |
### 1. 2XX (Success 成功状态码)
状态码2XX表示请求被正常处理了。
#### （1）200 OK
200 OK表示客户端发来的请求被服务器端正常处理了。
#### （2）204 No Content
该状态码表示客户端发送的请求已经在服务器端正常处理了，但是没有返回的内容，响应报文中不包含实体的主体部分。一般在只需要从客户端往服务器端发送信息，而服务器端不需要往客户端发送内容时使用。
#### （3）206 Partial Content
该状态码表示客户端进行了范围请求，而服务器端执行了这部分的 GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。
### 2. 3XX (Redirection 重定向状态码)
3XX 响应结果表明浏览器需要执行某些特殊的处理以正确处理请求。
#### （1）301 Moved Permanently
**永久重定向。** 该状态码表示请求的资源已经被分配了新的 URI，以后应使用资源指定的 URI。新的 URI 会在 HTTP 响应头中的 Location 首部字段指定。若用户已经把原来的URI保存为书签，此时会按照 Location 中新的URI重新保存该书签。同时，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。
**使用场景：**
- 当我们想换个域名，旧的域名不再使用时，用户访问旧域名时用301就重定向到新的域名。其实也是告诉搜索引擎收录的域名需要对新的域名进行收录。 - 在搜索引擎的搜索结果中出现了不带www的域名，而带www的域名却没有收录，这个时候可以用301重定向来告诉搜索引擎我们目标的域名是哪一个。
#### （2）302 Found
**临时重定向。** 该状态码表示请求的资源被分配到了新的 URI，希望用户（本次）能使用新的 URI 访问资源。和 301 Moved Permanently 状态码相似，但是 302 代表的资源不是被永久重定向，只是临时性质的。也就是说已移动的资源对应的 URI 将来还有可能发生改变。若用户把 URI 保存成书签，但不会像 301 状态码出现时那样去更新书签，而是仍旧保留返回 302 状态码的页面对应的 URI。同时，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回302代码，搜索引擎认为新的网址只是暂时的。
**使用场景：**
- 当我们在做活动时，登录到首页自动重定向，进入活动页面。 - 未登陆的用户访问用户中心重定向到登录页面。 - 访问404页面重新定向到首页。
#### （3）303 See Other
该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源。 303 状态码和 302 Found 状态码有着相似的功能，但是 303 状态码明确表示客户端应当采用 GET 方法获取资源。
303 状态码通常作为 PUT 或 POST 操作的返回结果，它表示重定向链接指向的不是新上传的资源，而是另外一个页面，比如消息确认页面或上传进度页面。而请求重定向页面的方法要总是使用 GET。
注意：
- 当 301、302、303 响应状态码返回时，几乎所有的浏览器都会把 POST 改成GET，并删除请求报文内的主体，之后请求会再次自动发送。 - 301、302 标准是禁止将 POST 方法变成 GET方法的，但实际大家都会这么做。
#### （4）304 Not Modified
**浏览器缓存相关。** 该状态码表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况。304 状态码返回时，不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中，但是和重定向没有关系。
带条件的请求（Http 条件请求）：使用 Get方法 请求，请求报文中包含（`if-match`、`if-none-match`、`if-modified-since`、`if-unmodified-since`、`if-range`）中任意首部。
状态码304并不是一种错误，而是告诉客户端有缓存，直接使用缓存中的数据。返回页面的只有头部信息，是没有内容部分的，这样在一定程度上提高了网页的性能。
#### （5）307 Temporary Redirect
**307表示临时重定向。** 该状态码与 302 Found 有着相同含义，尽管 302 标准禁止 POST 变成 GET，但是实际使用时还是这样做了。
307 会遵守浏览器标准，**不会从 POST 变成 GET**。但是对于处理请求的行为时，不同浏览器还是会出现不同的情况。规范要求浏览器继续向 Location 的地址 POST 内容。规范要求浏览器继续向 Location 的地址 POST 内容。
### 3. 4XX (Client Error 客户端错误状态码)
4XX 的响应结果表明客户端是发生错误的原因所在。
#### （1）400 Bad Request
该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像 200 OK 一样对待该状态码。
#### （2）401 Unauthorized
该状态码表示发送的请求需要有通过 HTTP 认证(BASIC 认证、DIGEST 认证)的认证信息。若之前已进行过一次请求，则表示用户认证失败
返回含有 401 的响应必须包含一个适用于被请求资源的 WWW-Authenticate 首部用以质询(challenge)用户信息。当浏览器初次接收到 401 响应，会弹出认证用的对话窗口。
以下情况会出现401：
- 401.1 - 登录失败。 - 401.2 - 服务器配置导致登录失败。 - 401.3 - 由于 ACL 对资源的限制而未获得授权。 - 401.4 - 筛选器授权失败。 - 401.5 - ISAPI/CGI 应用程序授权失败。 - 401.7 - 访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。
#### （3）403 Forbidden
该状态码表明请求资源的访问被服务器拒绝了，服务器端没有必要给出详细理由，但是可以在响应报文实体的主体中进行说明。进入该状态后，不能再继续进行验证。该访问是永久禁止的，并且与应用逻辑密切相关。
IIS 定义了许多不同的 403 错误，它们指明更为具体的错误原因：
- 403.1 - 执行访问被禁止。 - 403.2 - 读访问被禁止。 - 403.3 - 写访问被禁止。 - 403.4 - 要求 SSL。 - 403.5 - 要求 SSL 128。 - 403.6 - IP 地址被拒绝。 - 403.7 - 要求客户端证书。 - 403.8 - 站点访问被拒绝。 - 403.9 - 用户数过多。 - 403.10 - 配置无效。 - 403.11 - 密码更改。 - 403.12 - 拒绝访问映射表。 - 403.13 - 客户端证书被吊销。 - 403.14 - 拒绝目录列表。 - 403.15 - 超出客户端访问许可。 - 403.16 - 客户端证书不受信任或无效。 - 403.17 - 客户端证书已过期或尚未生效 - 403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。 - 403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。 - 403.20 - Passport 登录失败。这个错误代码为 IIS 6.0 所专用。
#### （4）404 Not Found
该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。 以下情况会出现404：
- 404.0 -（无） – 没有找到文件或目录。 - 404.1 - 无法在所请求的端口上访问 Web 站点。 - 404.2 - Web 服务扩展锁定策略阻止本请求。 - 404.3 - MIME 映射策略阻止本请求。
#### （5）405 Method Not Allowed
该状态码表示客户端请求的方法虽然能被服务器识别，但是服务器禁止使用该方法。GET 和 HEAD 方法，服务器应该总是允许客户端进行访问。客户端可以通过 OPTIONS 方法（预检）来查看服务器允许的访问方法, 如下
```javascript Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE 复制代码 ```
### 4. 5XX (Server Error 服务器错误状态码)
5XX 的响应结果表明服务器本身发生错误.
#### （1）500 Internal Server Error
该状态码表明服务器端在执行请求时发生了错误。也有可能是 Web 应用存在的 bug 或某些临时的故障。
#### （2）502 Bad Gateway
该状态码表明扮演网关或代理角色的服务器，从上游服务器中接收到的响应是无效的。注意，502 错误通常不是客户端能够修复的，而是需要由途经的 Web 服务器或者代理服务器对其进行修复。以下情况会出现502：
- 502.1 - CGI （通用网关接口）应用程序超时。 - 502.2 - CGI （通用网关接口）应用程序出错。
#### （3）503 Service Unavailable
该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入 RetryAfter 首部字段再返回给客户端。
**使用场景：**
- 服务器停机维护时，主动用503响应请求； - nginx 设置限速，超过限速，会返回503。
#### （4）504 Gateway Timeout
该状态码表示网关或者代理的服务器无法在规定的时间内获得想要的响应。他是HTTP 1.1中新加入的。
使用场景：代码执行时间超时，或者发生了死循环。
### 5. 总结
**（1）2XX 成功**
- 200 OK，表示从客户端发来的请求在服务器端被正确处理 - 204 No content，表示请求成功，但响应报文不含实体的主体部分 - 205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容 - 206 Partial Content，进行范围请求
**（2）3XX 重定向**
- 301 moved permanently，永久性重定向，表示资源已被分配了新的 URL - 302 found，临时性重定向，表示资源临时被分配了新的 URL - 303 see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源 - 304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况 - 307 temporary redirect，临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求
**（3）4XX 客户端错误**
- 400 bad request，请求报文存在语法错误 - 401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息 - 403 forbidden，表示对请求资源的访问被服务器拒绝 - 404 not found，表示在服务器上没有找到请求的资源
**（4）5XX 服务器错误**
- 500 internal sever error，表示服务器端在执行请求时发生了错误 - 501 Not Implemented，表示服务器不支持当前请求所需要的某个功能 - 503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求
### 6. 同样是重定向，**307**，**303**，**302**的区别？
302是http1.0的协议状态码，在http1.1版本的时候为了细化302状态码⼜出来了两个303和307。 303明确表示客户端应当采⽤get⽅法获取资源，他会把POST请求变为GET请求进⾏重定向。 307会遵照浏览器标准，不会从post变为get。
## 四、DNS协议介绍
### 1. DNS 协议是什么
**概念**： DNS 是域名系统 (Domain Name System) 的缩写，提供的是一种主机名到 IP 地址的转换服务，就是我们常说的域名系统。它是一个由分层的 DNS 服务器组成的分布式数据库，是定义了主机如何查询这个分布式数据库的方式的应用层协议。能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。
**作用**： 将域名解析为IP地址，客户端向DNS服务器（DNS服务器有自己的IP地址）发送域名查询请求，DNS服务器告知客户机Web服务器的 IP 地址。
### 2. DNS同时使用TCP和UDP协议？
**DNS占用53号端口，同时使用TCP和UDP协议。** （1）在区域传输的时候使用TCP协议
- 辅域名服务器会定时（一般3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送使用TCP而不是UDP，因为数据同步传送的数据量比一个请求应答的数据量要多得多。 - TCP是一种可靠连接，保证了数据的准确性。
（2）在域名解析的时候使用UDP协议
- 客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过三次握手，这样DNS服务器负载更低，响应更快。理论上说，客户端也可以指定向DNS服务器查询时用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。
### 3. DNS完整的查询过程
DNS服务器解析域名的过程：
- 首先会在**浏览器的缓存**中查找对应的IP地址，如果查找到直接返回，若找不到继续下一步 - 将请求发送给**本地DNS服务器**，在本地域名服务器缓存中查询，如果查找到，就直接将查找结果返回，若找不到继续下一步 - 本地DNS服务器向**根域名服务器**发送请求，根域名服务器会返回一个所查询域的顶级域名服务器地址 - 本地DNS服务器向**顶级域名服务器**发送请求，接受请求的服务器查询自己的缓存，如果有记录，就返回查询结果，如果没有就返回相关的下一级的权威域名服务器的地址 - 本地DNS服务器向**权威域名服务器**发送请求，域名服务器返回对应的结果 - 本地DNS服务器将返回结果保存在缓存中，便于下次使用 - 本地DNS服务器将返回结果返回给浏览器
比如要查询 [www.baidu.com](https://link.juejin.cn?target=http%3A%2F%2Fwww.baidu.com%2F) 的 IP 地址，首先会在浏览器的缓存中查找是否有该域名的缓存，如果不存在就将请求发送到本地的 DNS 服务器中，本地DNS服务器会判断是否存在该域名的缓存，如果不存在，则向根域名服务器发送一个请求，根域名服务器返回负责 .com 的顶级域名服务器的 IP 地址的列表。然后本地 DNS 服务器再向其中一个负责 .com 的顶级域名服务器发送一个请求，负责 .com 的顶级域名服务器返回负责 .baidu 的权威域名服务器的 IP 地址列表。然后本地 DNS 服务器再向其中一个权威域名服务器发送一个请求，最后权威域名服务器返回一个对应的主机名的 IP 地址列表。
### 4. 迭代查询与递归查询
实际上，DNS解析是一个包含迭代查询和递归查询的过程。
- **递归查询**指的是查询请求发出后，域名服务器代为向下一级域名服务器发出请求，最后向用户返回查询的最终结果。使用递归 查询，用户只需要发出一次查询请求。 - **迭代查询**指的是查询请求后，域名服务器返回单次查询的结果。下一级的查询由用户自己请求。使用迭代查询，用户需要发出 多次的查询请求。
一般我们向本地 DNS 服务器发送请求的方式就是递归查询，因为我们只需要发出一次请求，然后本地 DNS 服务器返回给我 们最终的请求结果。而本地 DNS 服务器向其他域名服务器请求的过程是迭代查询的过程，因为每一次域名服务器只返回单次 查询的结果，下一级的查询由本地 DNS 服务器自己进行。
### 5. DNS 记录和报文
DNS 服务器中以资源记录的形式存储信息，每一个 DNS 响应报文一般包含多条资源记录。一条资源记录的具体的格式为
```http （Name，Value，Type，TTL） 复制代码 ```
其中 TTL 是资源记录的生存时间，它定义了资源记录能够被其他的 DNS 服务器缓存多长时间。
常用的一共有四种 Type 的值，分别是 A、NS、CNAME 和 MX ，不同 Type 的值，对应资源记录代表的意义不同：
- 如果 Type = A，则 Name 是主机名，Value 是主机名对应的 IP 地址。因此一条记录为 A 的资源记录，提供了标 准的主机名到 IP 地址的映射。 - 如果 Type = NS，则 Name 是个域名，Value 是负责该域名的 DNS 服务器的主机名。这个记录主要用于 DNS 链式 查询时，返回下一级需要查询的 DNS 服务器的信息。 - 如果 Type = CNAME，则 Name 为别名，Value 为该主机的规范主机名。该条记录用于向查询的主机返回一个主机名 对应的规范主机名，从而告诉查询主机去查询这个主机名的 IP 地址。主机别名主要是为了通过给一些复杂的主机名提供 一个便于记忆的简单的别名。 - 如果 Type = MX，则 Name 为一个邮件服务器的别名，Value 为邮件服务器的规范主机名。它的作用和 CNAME 是一 样的，都是为了解决规范主机名不利于记忆的缺点。
## 五、网络模型
### 1. OSI七层模型
`ISO`为了更好的使网络应用更为普及，推出了`OSI`参考模型。 
#### （1）应用层
`OSI`参考模型中最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有：`HTTP`，`HTTPS`，`FTP`，`POP3`、`SMTP`等。
- 在客户端与服务器中经常会有数据的请求，这个时候就是会用到`http(hyper text transfer protocol)(超文本传输协议)`或者`https`.在后端设计数据接口时，我们常常使用到这个协议。 - `FTP`是文件传输协议，在开发过程中，个人并没有涉及到，但是我想，在一些资源网站，比如`百度网盘``迅雷`应该是基于此协议的。 - `SMTP`是`simple mail transfer protocol（简单邮件传输协议）`。在一个项目中，在用户邮箱验证码登录的功能时，使用到了这个协议。
#### （2）表示层
表示层提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。如果必要，该层可提供一种标准表示形式，用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩和加密也是表示层可提供的转换功能之一。
在项目开发中，为了方便数据传输，可以使用`base64`对数据进行编解码。如果按功能来划分，`base64`应该是工作在表示层。
#### （3）会话层
会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。
#### （4）传输层
传输层建立了主机端到端的链接，传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务，包括处理差错控制和流量控制等问题。该层向高层屏蔽了下层数据通信的细节，使高层用户看到的只是在两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。我们通常说的，`TCP` `UDP`就是在这一层。端口号既是这里的“端”。
#### （5）网络层
本层通过`IP`寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。就是通常说的`IP`层。这一层就是我们经常说的`IP`协议层。`IP`协议是`Internet`的基础。我们可以这样理解，网络层规定了数据包的传输路线，而传输层则规定了数据包的传输方式。
#### （6）数据链路层
将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用MAC地址)来访问介质,并进行差错检测。 网络层与数据链路层的对比，通过上面的描述，我们或许可以这样理解，网络层是规划了数据包的传输路线，而数据链路层就是传输路线。不过，在数据链路层上还增加了差错控制的功能。
#### （7）物理层
实际最终信号的传输是通过物理层实现的。通过物理介质传输比特流。规定了电平、速度和电缆针脚。常用设备有（各种物理设备）集线器、中继器、调制解调器、网线、双绞线、同轴电缆。这些都是物理层的传输介质。
**OSI七层模型通信特点：对等通信** 对等通信，为了使数据分组从源传送到目的地，源端OSI模型的每一层都必须与目的端的对等层进行通信，这种通信方式称为对等层通信。在每一层通信过程中，使用本层自己协议进行通信。
### 2. TCP/IP五层协议
`TCP/IP`五层协议和`OSI`的七层协议对应关系如下： ![img](https: