我认识的HTTP

Myth丶恋晨 2023-05-28 15:59 86阅读 0赞

声明：本篇文章的内容来自于五分钟学算法公众号上发表的一篇文章，作者小林coding，特此表示感谢~

之前的有篇文章，介绍了一下http和https的相关知识，都是从课本上了解到的，不是很全面，也不是很透彻，当中的一些内容有点含糊不清。今天写这篇文章的目的，可以说是对之前文章的一个改进吧，这是我在一个公众号上看到的文章，特加以收藏，并以博客的形式记录，方便我后续查询使用。

首先，http与https是计算机网络学习中的一个重点，也是在找工作时面试官提问的一个重点。下面就关于http的一些问题来加以描述。

**1.http的基本概念**

HTTP（HyperText Transfer Protocol），即超文本传输协议。而对于http的详细理解则要从它的译名入手，即从超文本、传输和协议三方面去理解。

（1）协议

协议相对于传输和超文本而言，算是简单的，所以我们先从协议入手。那么，什么是协议呢。在生活中，我们经常遇到各种各样的协议，三方协议、买房协议、租房协议等等，都叫做协议。协，代表的意思是必须有两个或两个以上的参与者。议，代表的意思是对参与者的一种行为约定和规范。那么这样理解的话，**http则是一个应用在计算机世界里的协议，它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范，以及相关的各种控制和错误处理方式。**

（2）传输

所谓的传输，从字面上理解就是把一堆东西从这个点搬到另一个点。但是计算机世界中的传输可不是这么简单的，它至少包含 两项重要的信息。**http协议是一个双向协议。**我么在上网时，浏览器是请求方，百度则是应答方。双方约定好用http协议来通信，于是浏览器就把请求数据发送给网站，网站再把一些数据返回给浏览器，最后由浏览器渲染在屏幕上，便可以看到图片、视频等信息了。这样来看的话，数据虽然是在发送方和应答方之间传输，但是允许中间有中转或接力。这就像坐地铁直达和换成一样，你可以直接坐到目的地，也可以多多换乘，最后到达。在http里，需要中间人遵从http协议，只要不打扰基本的数据传输，就可以添加任意额外的东西。**http是一个在计算机世界里专门用来在两点之间传输数据的约定和规范。**

（3）超文本

**http传输的内容是超文本。**最开始的时候，文本可能只是简单的字符文字，但现在文本的含义已经扩展为图片、视频、压缩包等了，但是超文本就是超越了普通文本的文本，它是文字、图片、视频等的混合体，可能还会有超链接，能从一个超文本链接到另一个超文本。html就是最常用的超文本了，它本身只是纯文字文件，但是内部用很多标签定义了图片、视频等的链接，再经过浏览器的解释，呈现给我们的就是一个有文字、有画面的网页了。综合以上，**http是一个在计算机世界里专门在两点之间进行传输文字、图片、音频、视频等超文本数据的约定和规范。**但是需要注意的是，http并不只是服务器到浏览器之间的协议，还可以是服务器与服务器之间。

**http常见的状态码：**

<table> 
 <thead> 
  <tr> 
   <th colspan="3">五大类http状态码</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>&nbsp;</td> 
   <td style="text-align:center;vertical-align:middle;">具体含义</td> 
   <td style="text-align:center;vertical-align:middle;">常见的状态码</td> 
  </tr> 
  <tr> 
   <td style="text-align:center;vertical-align:middle;">1xx</td> 
   <td style="text-align:center;vertical-align:middle;">提示信息，表示目前是协议处理的中间状态，还需要后续的操作</td> 
   <td style="text-align:center;vertical-align:middle;">&nbsp;</td> 
  </tr> 
  <tr> 
   <td style="text-align:center;vertical-align:middle;">2xx</td> 
   <td style="text-align:center;vertical-align:middle;">成功，报文已经收到并被正确处理</td> 
   <td style="text-align:center;vertical-align:middle;">200、204、206</td> 
  </tr> 
  <tr> 
   <td style="text-align:center;vertical-align:middle;">3xx</td> 
   <td style="text-align:center;vertical-align:middle;">重定向，资源位置发生变动，需要客户端重新发送请求</td> 
   <td style="text-align:center;vertical-align:middle;">301、302、304</td> 
  </tr> 
  <tr> 
   <td style="text-align:center;vertical-align:middle;">4xx</td> 
   <td style="text-align:center;vertical-align:middle;">客户端错误，请求报文有误，服务端无法处理</td> 
   <td style="text-align:center;vertical-align:middle;">400、403、404</td> 
  </tr> 
  <tr> 
   <td style="text-align:center;vertical-align:middle;">5xx</td> 
   <td style="text-align:center;vertical-align:middle;">服务器错误，服务器在处理请求的内部发生了错误</td> 
   <td style="text-align:center;vertical-align:middle;">500、501、502、503</td> 
  </tr> 
 </tbody> 
</table>

1xx类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2xx类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

200 ok：请求被正常处理。最常见的成功状态码，表示一切正常，如果是非head请求，服务器返回的响应头都会有body数据。

204 No Content：请求被受理但没有资源可以返回。也是最常见的成功状态码，与200基本相同，但响应头没有body数据。

206 Partial Content：客户端只是请求资源的一部分，服务器只对请求的部分资源执行get方法，相应报文中通过Content-Range指定范围的资源。是应用于http分块下载或断点续传，表示响应返回的body数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3xx类状态码表示客户端请求的资源发生了变动，需要客户端用新的URL重新发送请求获取资源，即重定向。

301 Moved Permanently：永久重定向，说明请求的资源已经不在了，需改用新的URL再次访问。

302 Found：临时重定向，说明请求的资源还在，但是暂时需要用另一个URL来访问。

301和302都会在响应头里使用字段Location，指明后续要跳转的URL，浏览器会自动重定向新的URL。

303：与302相似，只不过它希望客户端在请求一个URL的时候，能通过get方法重定向到另一个URL上。

304 Not Modified：发送附带条件的请求时，条件不满足时返回，与重定向无关。不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。

307：临时重定向，与302相似，只是强制要求使用post方法

4xx类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

400 Bad Request：客户端请求报文语法有误，但只是个笼统的错误，服务器无法识别。

401：请求需要认证

403 Forbidden：请求的对应资源禁止被访问，并不是客户端的请求出错。

404 Not Found：请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务端的错误码。

500 Internal Server Error：与400类似，是个笼统的通用的错误码，服务器发生了什么错误我们并不知道，只知道是服务器内部错误。

501 Not Implemented：表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。

502 Bad Gateway：通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。

503 Service Unavailable：服务器正忙，暂时无法响应服务器，类似于“网络服务正忙，请稍后重试”的意思。

**http的常见字段：**

（1）Host字段：客户端发送请求时，用来指定服务器的域名。有了Host字段，就可以将请求发往同一台服务器上的不同网站。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70][]

（2）Content-Length字段：服务器在返回数据时，会有Content-Length字段，表明本次回应的数据长度。

![20200315172729604.png][]

如上所示则是服务器告诉浏览器，本次回应的数据长度是1000个字节。

（3）Connection字段：最常用于客户端要求服务器使用TCP持久连接，以便其他请求复用。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 1][]

HTTP1.1版本的默认连接都是持久连接，但为了兼容老版本的http，需要指定Connection首部字段的值为Keep-Alive。这样一个可以复用的TCP连接就建立了，直到客户端或服务器主动关闭连接，但是这不是标准字段。

（4）Content-Type字段：用于服务器回应时，告诉客户端本次数据的格式。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 2][]

Content-Type:text/html;charset=utf-8表明发送的是网页，而且是utf-8编码。

Accept:\*/\*表明客户端声明自己可以接受任何类型的数据。

（5）Content-Encoding：说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 3][]

Content-Encoding:gzip表示服务器返回的数据采用了gzip方式压缩，告知客户端需要用此方式解压。客户端在请求时，可以使用Accept-Encoding字段说明自己可以接受的压缩方法。

**2.Get与Post**

在面试中，最常见的关于Get与Post的问题无非是Get与Post的区别。

**说一下Get与Post的区别？**

Get方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等。比如，当你打开某个页面时，浏览器就会发送GET请求给服务器，服务器就会返回页面的所有文字或图像资源。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 4][]

而这个Post方法则是相反操作，它向URL指定的资源提交数据，数据就放在报文的body里。比如，当你浏览完一篇文章准备留言评论时，键入留言之后点击了提交按钮，浏览器就会执行一次POST请求，把留言放进了报文body里，然后拼接好Post请求头，之后通过TCP协议发送给服务器。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 5][]

**GET和POST方法都是安全和幂等的吗？**

安全：在HTTP协议里，所谓的安全 是指请求方法不会破坏服务器上的资源。

幂等：所谓的幂等就是多次执行相同的操作，结果都是相同的。

那么，GET方法就是安全且幂等的，因为它是只读操作，无论操作多少次，服务器上的数据都是安全的，且每次的执行结果都是相同的。POST因为是新增或提交数据的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。

**3.http的特性**

**HTTP的优点有哪些，是怎么体现的？缺点有哪些？**

通常关于HTTP的优点，针对的只是HTTP1.1来说的。**HTTP最突出的优点就是简单、灵活和易于扩展、应用广泛和跨平台。**

（1）简单

HTTP的基本报文格式是header + body，头部信息也是key-value简单文本的形式，易于理解，降低了学习和使用的门槛。

（2）灵活和易于扩展

HTTP协议里的各种请求方法、URL/URI、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。同时HTTP由于是工作在应用层，则它的下层可以随意变化。HTTPS也就是在HTTP与TCP层之间增加了SSL/TLS安全传输层，HTTP/3甚至把TCP层换成了基于UDP的QUIC。

（3）应用广泛和跨平台

互联网发展至今，HTTP的应用范围非常的广泛，从台式机的浏览器到手机上的各种APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP的应用遍地开花，同时天然具有跨平台的优越性。

**HTTP协议里有优缺点一体的双刃剑，分别是无状态、明文传输，同时还有一大缺点就是不安全。**

（1）无状态

无状态的好处在于服务器不会去记忆HTTP的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的CPU和内存用来对外提供服务。无状态的好处在于服务器既然没有记忆功能，它在完成有关联性的操作时会非常麻烦。例如，逛淘宝时，加入购物车和结算等操作都需要知道用户的身份才行，但是服务器不知道这些请求是有关联的，每次都需要确认身份信息。

对于无状态的问题，解决方案有很多种，其中比较简单的方法便是使用cookie技术。cookie通过在请求和响应报文中写入cookie信息来控制客户端的状态。相当于在客户端第一次请求后，服务器会下发一个装有客户信息的小贴纸，后续客户端请求服务器的时候带上小贴纸，服务器就能认得了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 6][] 没有cookie信息状态的请求

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 7][] 客户端保存了cookie的请求

（2）明文传输

明文意味着在传输过程中的信息是可方便阅读的，通过浏览器的F12控制台或抓包工具都可以直接肉眼观看。但是正是这样，HTTP的所有信息都暴露了出来，相当于信息裸奔。在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就被窃取，如果里面有你的账号密码信息，那么恭喜你，你的账号可能被盗了。

（3）不安全

HTTP最严重的缺点就是不安全，其不安全性主要体现在以下几个方面：通信使用明文，内容可能会被窃听，比如，账号信息泄露，导致账号被盗；不验证通信方式的身份，因此有可能遭遇伪装，比如，访问假的淘宝，那么可能会造成经济损失；无法证明报文的完整性，所以有可能报文已经被篡改，比如，网页上植入垃圾广告。

HTTP的安全问题可以用HTTPS的方式解决，也就是通过引入SSL/TLS层，使得在安全上达到极致。

**HTTP/1.1的性能如何？**

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

（1）长连接

早期HTTP/1.0性能上的一个很大的问题就是每发起一个请求都要新建一次TCP连接，即完成一次TCP三次握手，而且是串行请求，做了无谓的TCP连接的建立和断开，增加了通信开销。为了解决上述TCP连接问题，HTTP/1.1提出了长连接的通信方式，也叫持久连接，这种方式的好处在于减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。

持久连接的特点是只要任意一端没有明确提出断开连接，则TCP保持连接状态。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 8][] 短连接与长连接

（2）管道网络传输

HTTP/1.1采用了长连接的方式，这使得管道网络传输成为了可能。即可在同一个TCP连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以继续发送第二个请求，可以减少整体的响应时间。举例来说的话，加入客户端需要请求两个资源。以前的做法是在同一个TCP连接里面，先发送A请求，然后等待服务器做出回应，收到后再发送B请求。管道机制则是允许浏览器同时发出A请求和B请求。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 9][] 管道网络传输

虽然说客户端可以发送多个请求，但是服务器还是会按照顺序来先响应客户端的A请求，完成后再响应B请求。要是前面的响应特别慢，后面就会有许多请求排队等待，此时称为队头阻塞。

（3）队头阻塞

请求-应答的模式加剧了HTTP的性能问题。因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会导致客户端一直请求不到数据，这就是队头阻塞。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 10][] 队头阻塞

**4.http与https**

**HTTP与HTTPS有哪些区别？**

（1）HTTP是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS则解决HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL／TLS安全协议，使得报文能够加密传输。

（2）HTTP连接建立过程相对简单，TCP三次握手之后便可进行HTTP的报文传输。而HTTPS在TCP三次握手之后还需要进行SSL/TLS的握手过程，才可进入加密报文传输阶段。

（3）HTTP的端口号是80，HTTPS的端口号是43。

（4）HTTPS协议需要向证书权威机构CA申请数字证书来保证服务器的身份是可信的。

**HTTPS解决了HTTP的哪些问题？**

HTTP由于是明文传输，所以安全上存在以下三个风险：

（1）窃听风险：比如通信链路上可以获取通信内容，用户账号容易被盗。

（2）篡改风险：比如强制植入垃圾广告。

（3）冒充风险：比如冒充淘宝网站，易造成经济损失。

HTTPS在HTTP与TCP层之间加入了SSL/TLS协议。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 11][] HTTP与HTTPS

**HTTPS是如何解决HTTP的风险的？**

（1）信息加密：保证交互信息无法被窃取，但是个人账号可能会因为自身原因而忘记。

（2）校验机制：保证无法篡改通信内容，篡改了就不能正常显示。

（3）身份证书：证明网站是真的网站。

除此之外，HTTPS通过混合加密的方式来实现信息的机密性，解决了被窃听的风险；还使用摘要算法的方式来实现内容的完整性，它能够为数据生成独一无二的类似于指纹的东西，用于验证数据的完整性，解决了被篡改的风险；同时也将服务器公钥放到数字证书中，解决了被冒充的风险。

**混合加密：**通过混合加密的方式来实现信息的机密性，解决了被窃听的风险。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 12][] 混合加密

HTTPS采用的是对称加密和非对称加密结合的混合加密模式。在通信建立前采用非对称加密的方式交换会话密钥，后续就不再使用非对称加密了；在通信过程中全部使用对称加密的会话密钥的方式加密明文数据。

采用混合加密的原因：对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换；非对称加密使用两个密钥，即公钥和私钥，公钥可以任意分发，而私钥是保密的，解决了密钥交换问题，但是速度慢。

**摘要算法：**实现内容的完整性，它能够为数据生成独一无二的类似于指纹的东西，用于验证数据的完整性，解决了被篡改的风险。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 13][] 校验完整性

客户端在发送明文之前会通过摘要算法算出明文的指纹（摘要），发送的时候把明文和摘要一同加密成密文后再发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的摘要和当前算出的摘要，若摘要相同，说明数据是完整的。

**数字证书：**将服务器公钥放到数字证书中，解决了被冒充的风险。

客户端先向服务器索要公钥，然后用公钥加密信息，服务器收到密文后用自己的私钥解密。但是这样的话，就存在一个问题，即如何保证公钥不被篡改和如何保证公钥的信任度？这里呢，就需要借助第三方权威机构CA（数字证书认证机构），将服务器公钥放在数字证书中，只要证书是可信的，公钥就是可信的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 14][] 数字证书工作流程

通过数字证书的方式保证服务器公钥的身份，解决被冒充的风险。

**HTTPS是如何建立连接的？交互了什么？**

SSL/TLS协议工作的基本流程：客户端先向服务器索要并验证服务器的公钥；之后双方协商生产会话密钥；然后双方采用会话密钥进行加密通信。

前两步即是SSL/TLS的建立过程，也就是握手阶段。其握手阶段涉及四次通信：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 15][] HTTPS连接建立过程

（1）ClientHello

首先，客户端向服务器发起加密通信请求，也就是ClientHello请求。这一步，客户端主要向服务器发送以下信息：客户端支持的SSL/TLS协议版本，如TLS1.2版本；客户端生产的随机数ClientRandom，用于后续生产会话密钥；客户端支持的密码套件列表，如RSA加密算法。

（2）ServerHello

服务器收到客户端请求后，向客户端发出响应，也就是ServerHello。服务器回应的内容有以下信息：确认SSL/TLS协议版本，如果浏览器不支持，则关闭加密通信；服务器生产的随机数ServerRandom，用于后续生产会话密钥；确认的密码套件列表，如RSA加密算法；服务器的数字证书。

（3）客户端回应

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的CA公钥，确认服务器的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送以下信息：一个随机数（pre-master key），且该随机数会被服务器公钥加密，同时这个随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通话的会话密钥；加密通信算法改变通知，表示随后的信息都将用会话密钥加密通信；客户端握手结束通知，表示客户端的握手阶段已经结束，这一项同时把之前所有内容的发生的数据做个摘要，用来供服务器校验。

（4）服务器的最后回应

服务器收到客户端的第三个随机数之后，通过协商的加密算法，计算出本次通信的会话密钥，然后，向客户端发出最后的信息：加密通信算法改变通知，表示随后的信息都将用会话密钥加密通信；服务器握手结束通知，表示服务器的握手阶段已经结束，这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

至此，整个SSL/TLS的握手阶段已经结束，接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用会话密钥加密内容而已。

**5.http1.1、http2、http3的演变**

**HTTP/1.1相比HTTP/1.0提高了什么性能？**

HTTP/1.1相比于HTTP/1.0有如下改进：（1）使用TCP长连接的方式改善了HTTP/1.0短连接造成的性能开销；（2）支持管道网络传输，只要第一个请求发出去了，不必等其回来，就可以发送第二个请求，可以减少整体的响应时间。

但是，HTTP/1.1也仍然有自身的缺点：（1）请求/响应头部未经压缩就发送，首部信息越多延迟越大，只能压缩body部分；（2）发送冗长的首部，每次互相发送相同的首部造成的浪费较多；（3）服务器是按请求的顺序来响应的，如果服务器响应慢，会导致一直请求不到数据，也就是队头阻塞；（4）没有请求优先级控制；（5）请求只能从客户端开始，服务器只能被动响应。

**HTTP/2针对于HTTP/1.1的缺点做了哪些改进？**

HTTP/2协议是基于HTTPS的，所以，HTTP/2的安全性是有保障的，其相对于HTTP/1.1有如下改进：

（1）头部压缩

HTTP/2会压缩 头部，如果你同时发出多个请求，它们的头部是一样的或者说是相似的，那么，协议就会帮助我们消除重复的部分。这就是所谓的HPACK算法，即在客户端和服务器同时维护一张头部信息表，所有字段都会存入这个表，生成一个索引号，以后就不用发送同样字段了，只发送索引号，这样就提高了速度。

（2）二进制格式

HTTP/2不再像HTTP/1.1里的纯文本形式的报文，而是全面采用了二进制格式。头部信息和数据体都是二进制，并且统称为帧，头信息帧和数据帧。这样虽然对人不友好，但是对计算机非常友好，因为只有计算机懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这样就增加了数据传输的效率。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 16][] 报文区别

（3）数据流

HTTP/2的数据包不是按顺序发送的，同一个连接里面连续的数据包可能属于不同的回应，因此，必须要对数据包做标记，指出它属于哪个回应。每个请求或回应的所有数据包称为一个数据流。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流为奇数，服务器发出的数据流为偶数。客户端还可以指定数据流的优先级，优先级高的请求，服务器就先响应。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 17][]

（4）多路复用

HTTP/2是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。移除了HTTP/1.1中的串行请求，不需要排队等待，也就不会再出现队头阻塞的问题，降低了延迟，大幅度提高了连接的利用率。举例来说的话，就是在一个TCP连接里，服务器收到了客户端A和B的两个请求，如果发现A处理过程非常耗时，于是就回应A请求已经处理好的部分，接着回应B请求，完成后，再回应A请求剩下的部分。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 18][]

（5）服务器推送

HTTP/2还在一定程度上改善了传统的请求-应答的工作模式，服务不再是被动地响应，也可以主动向客户端发送信息。比如，在浏览器请求HTML的时候，就提前把可能会用到的JS、CSS文件等静态资源主动发给客户端，减少延时等待，也就是服务器推送。

**HTTP/2有哪些缺陷？HTTP/3做了什么优化？**

HTTP/2主要的问题就是多个HTTP请求在复用一个TCP连接，下层的TCP协议是不知道有多少个HTTP请求的。所以一旦发生了丢包问题，就会触发TCP的重传机制，这样在一个TCP连接中所有的HTTP请求都必须等待这个丢了的包被重传回来。HTTP/1.1中的管道传输中如果有一个请求被阻塞了，那么队列请求也统统被阻塞住了。HTTP/2多路请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的HTTP请求。这都是基于TCP传输层的问题，所以HTTP/3把HTTP下层的TCP协议改成了UDP。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 19][]

UDP是不管顺序，也不管丢包的，所以不会出现HTTP/1.1的队头阻塞和HTTP/2的丢包与重传问题。因为UDP是不可靠传输，但是基于UDP的QUIC协议可以实现类似TCP的可靠性传输。QUIC有自己的一套机制可以保证传输的可靠性的，当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响。TLS3升级成了最新的1.3版本，头部压缩算法也升级成了QPACK。HTTPS要建立一个连接需要6次交互，先是建立三次握手，然后是TLS/1.3的三次握手，QUIC直接把以往的TCP和TLS/1.3的6次 交互合并成了3次，减少了交互次数。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 20][]

所以，QUIC是一个在UDP协议之上的伪TCP+TLS+HTTP/2的多路复用协议。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70]: /images/20230528/8cc5e6e6857543f8b9f58b4c2e47eb2e.png
[20200315172729604.png]: /images/20230528/36f8f304bf7d4eb9bca80909ebf29ac8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 1]: /images/20230528/48173bef4cc94134b8d695349a7c8506.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 2]: /images/20230528/d796dc1b0e144e038e61e805ff5faf1a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 3]: /images/20230528/e4f82d922b9b4ded912e08c9f719de39.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 4]: /images/20230528/016d93853099412180f83004bcd55bef.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 5]: /images/20230528/2742f1d6c94c433bbbde764c83a03e52.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 6]: /images/20230528/6d186c32a2ec43dd94d30bbc9fcdcfa1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 7]: /images/20230528/04597f2291be48dea8a9adf7b412bdca.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 8]: /images/20230528/e118f8d7bb1b49a88c84eef319d30211.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 9]: /images/20230528/c3ac41fb368643dabe44cc55551f1877.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 10]: /images/20230528/b202bbd7df004abe9a1d8ca8024ee84d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 11]: /images/20230528/f1816dae50844e60bb5cb98142b46ef7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 12]: /images/20230528/b67e8f8a605546e1a13b5393820be2f6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 13]: /images/20230528/b1d6d98ffe1b4854a83e728f15f7caba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 14]: /images/20230528/46764dc02240462d8298658850f74854.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 15]: /images/20230528/ee1153c6ee7a472eb7e7eacfdb210a16.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 16]: /images/20230528/1c754072fcf7424087f2fcb4dc9b7489.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 17]: /images/20230528/7fae0e5fa03844c183324349aa9829b5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 18]: /images/20230528/14baa7b5c446444eb05f3f0d42cc71ee.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 19]: /images/20230528/68bc172d152249b4890c5c407676e3db.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW9tdWJhaQ_size_16_color_FFFFFF_t_70 20]: /images/20230528/897e819ad6c84f8ea2858b251e9bb117.png