网络协议知识点汇总，巩固你的 HTTP 知识体系

约定不等于承诺〃 2022-09-10 03:23 323阅读 0赞

### 文章目录 ###

*  前言
 *  一、HTTP协议✨
 *  1. HTTP 的特点和缺点
 *  2. HTTP 报文结构是怎样的
 *  3. 常见的HTTP请求头和响应头
 *   *  HTTP Request Header 常见的请求头
     *  HTTP Responses Header 常见的响应头
 *  4. HTTP 有哪些请求方法
 *  5. GET和POST请求的区别
 *  6. PUT和POST请求的区别
 *  7. OPTIONS请求方法的使用场景
 *  8. 常见 HTTP 状态码
 *  9. 详细描述一下 301 和 302 状态码
 *  10. 304 状态码是什么意思？详细描述一下 HTTP 强缓存和协商缓存
 *  11. 从URL输入到页面展现到底发生什么
 *  12. 为什么需要 持久连接
 *  13. 持久连接 的特点
 *  14. HTTP管线化
 *  15. 对keep-alive的理解
 *  16. HTTP版本
 *   *  HTTP/1.0
     *  HTTP/1.1
     *  HTTP/2.0
     *  HTTP/3.0
 *  17. HTTP 1.0 和 HTTP 1.1 之间有哪些区别？
 *  18. HTTP 1.1 和 HTTP 2.0 之间有哪些区别？
 *  19. 页面有多张图片，HTTP是怎样的加载表现？
 *  20. HTTP协议的性能
 *   *  长连接
     *  管道网络传输
     *  队头堵塞
     *  队头阻塞的解决方案
 *  二、网络模型✨
 *  1. OSI七层模型
 *   *  应用层
     *  表示层
     *  会话层
     *  传输层
     *  网络层
     *  数据链路层
     *  物理层
 *  2. TCP/IP五层协议
 *  三、TCP 和 UDP的概念、特点和区别✨
 *  四、HTTPS协议✨
 *  五、WebSocket✨
 *   *  WebSocket 产生的背景
     *  WebSocket 的理解
     *  WebSocket 特点
     *  Websocket 的使用
 *  参考

# 前言 #

掌握网络协议可以让我们在日常项目开发过程中，定位那些在发起网络请求遇到的奇怪问题。

而且在一些比较成熟的团队面试过程中也经常会问到网络协议这方面的知识。

因此作为一名前端，我们需要掌握网络协议这方面的相关知识。

# 一、HTTP协议✨ #

# 1. HTTP 的特点和缺点 #

**特点**：`无连接`、`无状态`、`灵活`、`简单快速`

*  **无连接**：每一次请求都要连接一次，请求结束就会断掉，不会保持连接
 *  **无状态**：每一次请求都是独立的，请求结束不会记录连接的任何信息(**提起裤子就不认人的意思)**，减少了网络开销，这是`优点也是缺点`
 *  **灵活**：通过http协议中头部的`Content-Type`标记，可以传输任意数据类型的数据对象(文本、图片、视频等等)，非常灵活
 *  **简单快速**：发送请求访问某个资源时，只需传送请求方法和URL就可以了，使用简单，正由于http协议简单，使得http服务器的程序规模小，因而通信速度很快

**缺点**：`无状态`、`不安全`、`明文传输`、`队头阻塞`

*  **无状态**：请求不会记录任何连接信息，没有记忆，就无法区分多个请求发起者身份是不是同一个客户端的，意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大
 *  **不安全**：`明文传输`可能被窃听不安全，缺少`身份认证`也可能遭遇伪装，还有缺少`报文完整性验证`可能遭到篡改
 *  **明文传输**：报文(header部分)使用的是明文，直接将信息暴露给了外界，`WIFI陷阱`就是复用明文传输的特点，诱导你连上热点，然后疯狂抓取你的流量，从而拿到你的敏感信息
 *  **队头阻塞**：开启`长连接`(下面有讲)时，只建立一个TCP连接，同一时刻只能处理一个请求，那么当请求耗时过长时，其他请求就只能阻塞状态(如何解决下面有讲)

# 2. HTTP 报文结构是怎样的 #

**http报文**：由`请求报文`和`响应报文`组成

**请求报文**：由`请求行`、`请求头`、`空行`、`请求体`四部分组成

**响应报文**：由`状态行`、`响应头`、`空行`、`响应体`四部分组成

*  **请求行**：包含http方法，请求地址，http协议以及版本
 *  **请求头/响应头**：就是一些key:value来告诉服务端我要哪些内容，要注意什么类型等
 *  **空行**：用来区分首部与实体，因为请求头都是key:value的格式，当解析遇到空行时，服务端就知道下一个不再是请求头部分，就该当作请求体来解析了
 *  **请求体**：请求的参数
 *  **状态行**：包含http协议及版本、数字状态码、状态码英文名称
 *  **响应体**：服务端返回的数据

请求行：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16]

状态行：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_17_color_FFFFFF_t_70_g_se_x_16]

# 3. 常见的HTTP请求头和响应头 #

## HTTP Request Header 常见的请求头 ##

*  **Accept**: 浏览器能够处理的内容类型
 *  **Accept-Charset**:浏览器能够显示的字符集
 *  **Accept-Encoding**：浏览器能够处理的压缩编码
 *  **Accept-Language**：浏览器当前设置的语言
 *  **Connection**：浏览器与服务器之间连接的类型
 *  **Cookie**：当前页面设置的任何Cookie
 *  **Host**：发出请求的页面所在的域
 *  **Referer**：发出请求的页面的URL
 *  **User-Agent**：浏览器的用户代理字符串

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 1]

## HTTP Responses Header 常见的响应头 ##

*  **Date**：表示消息发送的时间，时间的描述格式由rfc822定义
 *  **server**: 服务器名称
 *  **Connection**：浏览器与服务器之间连接的类型
 *  **Cache-Control**：控制HTTP缓存
 *  **content-type**: 表示后面的文档属于什么MIME类型
 *  **Pragma**：只有一个属性值，就是 no-cache ，效果和 Cache-Control 中的 no-cache 一致，不使用强缓存

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 1]

# 4. HTTP 有哪些请求方法 #

`http/1.1`规定了以下请求方法(**注意，都是大写**):

*  **GET**: 通常用来获取资源
 *  **HEAD**: 获取资源的元信息
 *  **POST**: 提交数据，即上传数据
 *  **PUT**: 修改数据
 *  **DELETE**: 删除资源(几乎用不到)
 *  **CONNECT**: 建立连接隧道，用于代理服务器
 *  **OPTIONS**: 列出可对资源实行的请求方法，用来跨域请求
 *  **TRACE**: 追踪请求-响应的传输路径

# 5. GET和POST请求的区别 #

*  从**缓存**的角度，GET 请求会被浏览器主动缓存下来，留下历史记录，而 POST 默认不会。
 *  从**编码**的角度，GET 只能进行 URL 编码，只能接收 ASCII 字符，而 POST 没有限制。
 *  从**参数**的角度，GET 一般放在 URL 中，因此不安全，POST 放在`Request body`请求体中，更适合传输敏感信息。
 *  从**幂等性**的角度，`GET`是**幂等**的，而`POST`不是。(在编程中一个幂等操作的特点是其任意多次执行一个方法所产生的影响均与一次执行的影响相同)
 *  从**TCP**的角度，GET 请求会产生一个TCP数据包，把请求报文一次性发出去，而 POST 会分为两个 TCP 数据包。GET浏览器把`http header`和data一起发出去，响应成功200，POST先发送header，响应100 continue，再发送data，响应成功200。(并不是所有的浏览器都会发送两次数据包，Firefox就发送一次，它的 POST 请求只发一个 TCP 包)

# 6. PUT和POST请求的区别 #

**PUT** 和 **POST** 都有更改指定URI的语义，但PUT被定义为幂等的方法，而POST则不是，多次调用会产生不同的结果。也就是说：

PUT请求：如果两个请求相同，后一个请求会把第一个请求覆盖掉。（**所以PUT用来改资源**）

POST请求：后一个请求不会把第一个请求覆盖掉。（**所以Post用来增资源**）

# 7. OPTIONS请求方法的使用场景 #

OPTIONS请求方法的**主要用途**有两个：

*  获取服务器支持的所有HTTP请求方法；
 *  用来检查访问权限。例如：在进行 CORS 跨域资源共享时，对于复杂请求，就是使用 OPTIONS 方法发送嗅探请求，以判断是否有对指定资源的访问权限。

# 8. 常见 HTTP 状态码 #

**`1xx`: 指示信息**——表示**请求已接收，继续处理**

**`2xx`: 成功**——表示**请求成功处理完毕**

**`3xx`: 重定向**——表示**要完成请求必须进行进一步操作**

**`4xx`: 客户端错误**——表示**请求有语法错误或请求无法实现**

**`5xx`: 服务端错误**——表示**服务器未能实现合法的请求**

常见状态码：

<table> 
 <thead> 
 <tr> 
 <th>状态码</th> 
 <th align="left">描述</th> 
 </tr> 
 </thead> 
 <tbody> 
 <tr> 
 <td>100</td> 
 <td align="left">Continue 继续。客户端应继续其请求</td> 
 </tr> 
 <tr> 
 <td>101</td> 
 <td align="left">Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议。如果服务器同意变更，就会发送状态码 101。</td> 
 </tr> 
 <tr> 
 <td>200</td> 
 <td align="left">OK 请求成功。通常在响应体中放有数据。</td> 
 </tr> 
 <tr> 
 <td>204</td> 
 <td align="left">No Content 含义与 200 相同，但响应头后没有 body 数据。</td> 
 </tr> 
 <tr> 
 <td>206</td> 
 <td align="left">Partial Content 已完成指定范围的请求(带Range头的GET请求)，场景如video,audio播放文件较大,文件分片和断点续传时</td> 
 </tr> 
 <tr> 
 <td>301</td> 
 <td align="left">Moved Permanently 永久重定向</td> 
 </tr> 
 <tr> 
 <td>302</td> 
 <td align="left">Found 临时重定向</td> 
 </tr> 
 <tr> 
 <td>304</td> 
 <td align="left">Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。可以使用缓存的资源，不用在服务器获取。当协商缓存命中时会返回这个状态码。</td> 
 </tr> 
 <tr> 
 <td>400</td> 
 <td align="left">Bad Request 请求有语法错误</td> 
 </tr> 
 <tr> 
 <td>401</td> 
 <td align="left">Unauthorized 没有权限访问</td> 
 </tr> 
 <tr> 
 <td>403</td> 
 <td align="left">Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求。这实际上并不是请求报文出错，而是服务器禁止访问，原因有很多，比如法律禁止、信息敏感。</td> 
 </tr> 
 <tr> 
 <td>404</td> 
 <td align="left">Not Found 请求资源不存在</td> 
 </tr> 
 <tr> 
 <td>408</td> 
 <td align="left">Request Time-out 服务器等待客户端发送的请求时间过长，超时</td> 
 </tr> 
 <tr> 
 <td>500</td> 
 <td align="left">Internal Server Error 服务器内部错误，无法完成请求</td> 
 </tr> 
 <tr> 
 <td>501</td> 
 <td align="left">Not Implemented 表示客户端请求的功能还不支持，无法完成请求</td> 
 </tr> 
 <tr> 
 <td>503</td> 
 <td align="left">Service Unavailable 请求未完成，因服务器过载、宕机或维护等</td> 
 </tr> 
 </tbody> 
</table>

# 9. 详细描述一下 301 和 302 状态码 #

**301 Moved Permanently 永久重定向：**

301重定向是网页更改地址后对搜索引擎友好的最好方法，只要不是暂时搬移的情况,都建议使用301来做转址。

**302 Found 临时重定向：**

302状态码应用的典型场景是服务器页面路径的重新规划。

常见场景有百度，知乎、简书等等。比如说我们要在百度进入菜鸟教程，搜索出来后有一系列的列表，我们可以选择一个去进行一个点击。点击的那个不会直接进入菜鸟教程，而是先跳转到百度设置的一个临时地址，之后再跳转到菜鸟教程真实的地址。

# 10. 304 状态码是什么意思？详细描述一下 HTTP 强缓存和协商缓存 #

该知识点重要且篇幅较长，已开新的文章：[304 状态码是什么意思？图解 HTTP 强缓存和协商缓存][304 _ HTTP]

# 11. 从URL输入到页面展现到底发生什么 #

该知识点重要且篇幅较长，已开新的文章：[从URL输入到页面展现到底发生什么？爆肝研读数十篇文章详解 TCP 三次握手 和 四次挥手！！！][URL_ TCP _ _]

# 12. 为什么需要 持久连接 #

\*\*HTTP协议的初始版本中，每进行一次HTTP通信就要断开一次TCP连接。\*\*以当年的通信情况来说，因为都是些容量很小的文本传输，所以即使这样也没有多大问题。可随着 HTTP 的 普及，文档中包含大量图片的情况多了起来。比如，使用浏览器浏览一个包含多张图片的 HTML 页面时，在发送请求访问 HTML 页面资源的同时，也会请 求该 HTML 页面里包含的其他资源。因此，**每次的请求都会造成无谓的 TCP 连接建立和断开，增加通信量的 开销。**  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 2]

# 13. 持久连接 的特点 #

为解决上述 TCP 连接的问题，HTTP/1.1 和一部分的 HTTP/1.0 想出了持久连接（HTTP Persistent Connections，也称为 HTTP keep-alive 或 HTTP connection reuse）的方法。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 3]  
**持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。另外， 减少开销的那部分时间，使 HTTP 请求和响应能够更早地结束，这样 Web 页面的显示速度也就相应提高了。** 在 HTTP/1.1 中，所有的连接默认都是持久连接，但在 HTTP/1.0 内并未标准化。虽然有一部分服务器通过非 标准的手段实现了持久连接，但服务器端不一定能够支持持久连接。毫无疑问，除了服务器端，客户端也需 要支持持久连接。

# 14. HTTP管线化 #

持久连接使得多数请求以管线化（pipelining）方式发送成为可能。

HTTP管线化是将多个HTTP要求（request）整批提交的技术，而在传送过程中不需先等待服务端的回应。管线化机制须通过永久连接（persistent connection）完成，仅HTTP/1.1支持此技术（HTTP/1.0不支持），并且只有GET和HEAD要求可以进行管线化，而POST则有所限制。此外，初次创建连接时也不应启动管线机制，因为对方（服务器）不一定支持HTTP/1.1版本的协议。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 4]

# 15. 对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的优点：**

*  较少的CPU和内存的使⽤（由于同时打开的连接的减少了）；
 *  允许请求和应答的HTTP管线化；
 *  降低拥塞控制 （TCP连接减少了）；
 *  减少了后续请求的延迟（⽆需再进⾏握⼿）；
 *  报告错误⽆需关闭TCP连；

**开启Keep-Alive的缺点：**

*  长时间的Tcp连接容易导致系统资源无效占用，浪费系统资源。

# 16. HTTP版本 #

## HTTP/1.0 ##

最早的http只是使用在一些较为简单的网页上和网络请求上，所以比较简单，每次请求都打开一个新的TCP链接，收到响应之后立即断开连接。

## HTTP/1.1 ##

*  HTTP/1.1 引入了更多的缓存控制策略，如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等
 *  HTTP/1.1 允许范围请求，即在请求头中加入Range头部
 *  HTTP/1.1 的请求消息和响应消息都必须包含Host头部，以区分同一个物理主机中的不同虚拟主机的域名
 *  HTTP/1.1 默认开启持久连接，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。

## HTTP/2.0 ##

在 HTTP/2 中，有两个非常重要的概念，分别是帧（frame）和流（stream），理解这两个概念是理解下面多路复用的前提。帧代表数据传输的最小的单位，每个帧都有序列标识表明该帧属于哪个流，流也就是多个帧组成的数据流，每个流表示一个请求。这里有个chrome扩展程序，可以方便的查看当前网站的HTTP请求版本（安装后在chrome开发工具-Network-在Name/Size/Time表格头右键选择Procotol，即可查看协议版本）。

*  **新的二进制格式**： HTTP/1.x的解析是基于文本的。基于文本协议的解析存在天然缺陷，文本的表现形式有多样性，要做到全面性考虑的场景必然很多。二进制则不同，只识别0和1的组合。基于这种考虑HTTP/2.0的协议解析采用二进制格式，方便且强大。
 *  **多路复用**： HTTP/2.0支持多路复用，这是HTTP/1.1持久连接的升级版。多路复用，就是在一个 TCP 连接中可以存在多条流，也就是可以发送多个请求，服务端则可以通过帧中的标识知道该帧属于哪个流（即请求），通过重新排序还原请求。多路复用允许并发的发起多个请求，每个请求及该请求的响应不需要等待其他的请求或响应，避免了线头阻塞问题。这样某个请求任务耗时严重，不会影响到其它连接的正常执行,极大的提高传输性能。
 *  **头部压缩**： HTTP/1.x的请求和响应头部带有大量信息，而且每次请求都要重复发送，HTTP/2.0使用encoder来减少需要传输的头部大小，通讯双方各自cache一份头部 fields表，既避免了重复头部的传输，又减小了需要传输的大小。
 *  **服务端推送**： 这里的服务端推送指把客户端所需要的css/js/img资源伴随着index.html一起发送到客户端，省去了客户端重复请求的步骤（从缓存中取）。

## HTTP/3.0 ##

HTTP/2.0 使用了多路复用，一般来说同一域名下只需要使用一个 TCP 连接。但当这个连接中出现了丢包的情况，那就会导致整个 TCP 都要开始等待重传，也就导致了后面的所有数据都被阻塞了。反而对于 HTTP/1.0 来说，可以开启多个 TCP 连接，出现丢包反倒只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据。出现包阻塞的原因是因为底层TCP协议导致的问题，但是修改TCP协议是不现实的问题，就像typeof null === 'object’一样，修改这个问题会导致出现更多的问题。既然不能修改你，那就另起一个协议取代你。Google 基于 UDP 协议推出了一个的 QUIC 协议，并且使用在了 HTTP/3 上。

QUIC 基于 UDP，但是UDP本身存在不稳定性等诸多问题，所以QUIC在UDP的基础上新增了很多功能，比如多路复用、0-RTT、使用 TLS1.3 加密、流量控制、有序交付、重传等等功能。优点诸多，参考这里：

*  **避免包阻塞**： 多个流的数据包在TCP连接上传输时，若一个流中的数据包传输出现问题，TCP需要等待该包重传后，才能继续传输其它流的数据包。但在基于UDP的QUIC协议中，不同的流之间的数据传输真正实现了相互独立互不干扰，某个流的数据包在出问题需要重传时，并不会对其他流的数据包传输产生影响。
 *  **快速重启会话**： 普通基于tcp的连接，是基于两端的ip和端口和协议来建立的。在网络切换场景，例如手机端切换了无线网，使用4G网络，会改变本身的ip，这就导致tcp连接必须重新创建。而QUIC协议使用特有的UUID来标记每一次连接，在网络环境发生变化的时候，只要UUID不变，就能不需要握手，继续传输数据。

# 17. 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 等。

# 18. 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 规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。队列里的请求是没有优先级的，只有入队的先后顺序，排在最前面的请求会被最优先处理。如果队首的请求因为处理的太慢耽误了时间，那么队列里后面的所有请求也不得不跟着一起等待，结果就是其他的请求承担了不应有的时间成本，造成了队头堵塞的现象。

# 19. 页面有多张图片，HTTP是怎样的加载表现？ #

*  在`HTTP 1`下，浏览器对一个域名下最大TCP连接数为6，所以会请求多次。可以用多域名部署解决。这样可以提高同时请求的数目，加快页面图片的获取速度。
 *  在`HTTP 2`下，可以一瞬间加载出来很多资源，因为，HTTP2支持多路复用，可以在一个TCP连接中发送多个HTTP请求。

# 20. HTTP协议的性能 #

HTTP 协议是基于 TCP/IP，并且使用了 **请求-应答** 的通信模式，所以性能的关键就在这两点里。

## 长连接 ##

HTTP协议有两种连接模式，一种是持续连接，一种非持续连接。

（1）非持续连接指的是服务器必须为每一个请求的对象建立和维护一个全新的连接。

（2）持续连接下，TCP 连接默认不关闭，可以被多个请求复用。采用持续连接的好处是可以避免每次建立 TCP 连接三次握手时所花费的时间。

对于不同版本的采用不同的连接方式：

*  在`HTTP/1.0` 每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无畏的 TCP 连接建立和断开，增加了通信开销。该版本使用的非持续的连接，但是可以在请求时，加上 Connection: keep-a live 来要求服务器不要关闭 TCP 连接。
 *  在`HTTP/1.1` 提出了 **长连接** 的通信方式，也叫 **持久连接** 。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。该版本及以后版本默认采用的是持续的连接。**目前对于同一个域，大多数浏览器支持同时建立 6 个持久连接。**

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 5]

## 管道网络传输 ##

HTTP/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。

管道（pipeline）网络传输是指：可以在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。但是服务器还是按照顺序回应请求。如果前面的回应特别慢，后面就会有许多请求排队等着。这称为队头堵塞。

## 队头堵塞 ##

HTTP 传输的报文必须是一发一收，但是，里面的任务被放在一个任务队列中串行执行，一旦队首的请求处理太慢，就会阻塞后面请求的处理。这就是HTTP队头阻塞问题。

## 队头阻塞的解决方案 ##

（1）并发连接：对于一个域名允许分配多个长连接，那么相当于增加了任务队列，不至于一个队伍的任务阻塞其它所有任务。

（2）域名分片：将域名分出很多二级域名，它们都指向同样的一台服务器，能够并发的长连接数变多，解决了队头阻塞的问题。

# 二、网络模型✨ #

# 1. OSI七层模型 #

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 6]  
七层模型传输数据过程：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 7]

## 应用层 ##

OSI参考模型中最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有：`HTTP`，`HTTPS`，`FTP`，`POP3`、`SMTP`等。

*  客户端与服务器中经常会有数据的请求，这个时候就是会用到`http(hyper text transfer protocol)(超文本传输协议)`或者`https`。在后端设计数据接口时，我们常常使用到这个协议。
 *  `FTP`是文件传输协议，在开发过程中，个人并没有涉及到，但是我想，在一些资源网站，比如`百度网盘`、`迅雷`应该是基于此协议的。
 *  `SMTP`是`simple mail transfer protocol（简单邮件传输协议）`。在一个项目中，在用户邮箱验证码登录的功能时，使用到了这个协议。

## 表示层 ##

表示层提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。如果必要，该层可提供一种标准表示形式，用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩和加密也是表示层可提供的转换功能之一。

在项目开发中，为了方便数据传输，可以使用`base64`对数据进行编解码。如果按功能来划分，`base64`应该是工作在表示层。

## 会话层 ##

会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。

## 传输层 ##

传输层建立了主机端到端的链接，传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务，包括处理差错控制和流量控制等问题。该层向高层屏蔽了下层数据通信的细节，使高层用户看到的只是在两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。我们通常说的，`TCP` `UDP`就是在这一层。端口号既是这里的“端”。

## 网络层 ##

本层通过`IP`寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。就是通常说的`IP`层。这一层就是我们经常说的`IP`协议层。`IP`协议是`Internet`的基础。我们可以这样理解，网络层规定了数据包的传输路线，而传输层则规定了数据包的传输方式。

## 数据链路层 ##

将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用MAC地址)来访问介质,并进行差错检测。

网络层与数据链路层的对比，通过上面的描述，我们或许可以这样理解，网络层是规划了数据包的传输路线，而数据链路层就是传输路线。不过，在数据链路层上还增加了差错控制的功能。

## 物理层 ##

实际最终信号的传输是通过物理层实现的。通过物理介质传输比特流。规定了电平、速度和电缆针脚。常用设备有（各种物理设备）集线器、中继器、调制解调器、网线、双绞线、同轴电缆。这些都是物理层的传输介质。

# 2. TCP/IP五层协议 #

`TCP/IP`五层协议和`OSI`的七层协议对应关系如下：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 8]  
在每一层实现的协议也各不同，即每一层的服务也不同，下图列出了每层主要的传输协议：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 9]  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 10]

# 三、TCP 和 UDP的概念、特点和区别✨ #

该知识点重要且篇幅较长，已开新的文章：[详解 TCP 和 UDP的概念、特点和区别][TCP _ UDP]

# 四、HTTPS协议✨ #

该知识点重要且篇幅较长，已开新的文章：[深入理解 HTTPS 工作原理，一文帮你搞懂 HTTPS 加密、解密、验证及数据传输过程！！！][HTTPS _ HTTPS]

# 五、WebSocket✨ #

## WebSocket 产生的背景 ##

很多网站为了实现推送技术，所用的技术都是轮询。轮询是在特定的的时间间隔（如每1秒），由浏览器对服务器发出HTTP请求，然后由服务器返回最新的数据给客户端的浏览器。这种传统的模式带来很明显的缺点，即浏览器需要不断的向服务器发出请求，然而HTTP请求可能包含较长的头部，其中真正有效的数据可能只是很小的一部分，显然这样会浪费很多的带宽等资源。

而比较新的技术去做轮询的效果是Comet。这种技术虽然可以双向通信，但依然需要反复发出请求。而且在Comet中，普遍采用的长链接，也会消耗服务器资源。

在这种情况下，HTML5定义了WebSocket协议，能更好的节省服务器资源和带宽，并且能够更实时地进行通讯。

## WebSocket 的理解 ##

WebSocket是HTML5提供的一种浏览器与服务器进行 **全双工通讯** 的网络技术，属于应用层协议。它基于TCP传输协议，并复用HTTP的握手通道。浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接， 并进行双向数据传输。

WebSocket 的出现就解决了半双工通信的弊端。它最大的特点是：**服务器可以向客户端主动推动消息，客户端也可以主动向服务器推送消息。**

**WebSocket原理**：客户端向 WebSocket 服务器通知（notify）一个带有所有接收者ID（recipients IDs）的事件（event），服务器接收后立即通知所有活跃的（active）客户端，只有ID在接收者ID序列中的客户端才会处理这个事件。

## WebSocket 特点 ##

*  支持双向通信，实时性更强
 *  可以发送文本，也可以发送二进制数据‘’
 *  建立在TCP协议之上，服务端的实现比较容易
 *  数据格式比较轻量，性能开销小，通信高效
 *  没有同源限制，客户端可以与任意服务器通信
 *  协议标识符是ws（如果加密，则为wss），服务器网址就是 URL
 *  与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。

## Websocket 的使用 ##

Websocket的使用方法如下：

在客户端中：

// 在index.html中直接写WebSocket，设置服务端的端口号为 9999
    let ws = new WebSocket('ws://localhost:9999');
    // 在客户端与服务端建立连接后触发
    ws.onopen = function() { 
        console.log("Connection open."); 
        ws.send('hello');
    };
    // 在服务端给客户端发来消息的时候触发
    ws.onmessage = function(res) { 
        console.log(res);       // 打印的是MessageEvent对象
        console.log(res.data);  // 打印的是收到的消息
    };
    // 在客户端与服务端建立关闭后触发
    ws.onclose = function(evt) { 
      console.log("Connection closed.");
    };

# 参考 #

*  https://juejin.cn/post/6994629873985650696\#comment
 *  https://juejin.cn/post/6844904100035821575
 *  https://mp.weixin.qq.com/s/PdY5fXKOmTN1idiCYSJisw
 *  https://www.w3cschool.cn/http/g9prxfmx.html
 *  https://juejin.cn/post/6844903844216832007
 *  https://juejin.cn/post/6844903619343581191\#heading-9
 *  https://www.cnblogs.com/dongzhiquan/archive/2011/01/03/1994525.html
 *  https://mp.weixin.qq.com/s/PdY5fXKOmTN1idiCYSJisw
 *  https://baike.baidu.com/item/WebSocket/1953845

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/3928ec818a4e4d0ba53d18fba4cd5171.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_17_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/f4516f6675b640e5860de6a146e03d84.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220829/85f33ff3263e45539f17c9c33da63ac9.png
[304 _ HTTP]: https://blog.csdn.net/weixin_45844049/article/details/120107080
[URL_ TCP _ _]: https://blog.csdn.net/weixin_45844049/article/details/120147141
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220829/94898fb9ac2744a0b7527ed5c25549ca.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220829/6b863bee249a4e64ab4674dcdaeb8a5b.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220829/e7148f4a2db8482db01efed274562716.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 5]: /images/20220829/0630e84455dc4b37b058fa8c821d6d12.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 6]: /images/20220829/42c8a09554e2440d85509a3fd5df1725.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 7]: /images/20220829/d1eacf1e8dde4d999a223daebe61310b.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 8]: /images/20220829/0e57c0cd1b114b8da5b45ee513af0042.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 9]: /images/20220829/f7a0288cfb8b474ba21ddac465023566.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 10]: /images/20220829/5509df375a744983a0b7d11528633de3.png
[TCP _ UDP]: https://blog.csdn.net/weixin_45844049/article/details/120213668
[HTTPS _ HTTPS]: https://blog.csdn.net/weixin_45844049/article/details/120257693