HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3的区别
1. HTTP 基本知识
1.1 HTTP是什么？
HTTP是超文本传输协议，也就是HyperText Transfer Protocol。HTTP的名字「超文本传输协议」，它可以拆成三个部分：
- 超文本
- 传输
- 协议
1.2 HTTP 常见的状态码有哪些？
五大类HTTP状态码
| 大类 | 具体含义 | 常见的状态码 |
|---|---|---|
| 1×× | 提示信息，表示目前协议处理的中间状态，还需要后续的操作 | |
| 2×× | 成功，报文已经收到并被正确处理 | 200、204、206 |
| 3×× | 重定向，资源位置发生变动，需要客户端重新发送请求； | 301、302、304 |
| 4×× | 客户端错误，请求报文有误，服务器无法处理 | 400、403、404 |
| 5×× | 服务器错误，服务器在处理请求时内部发生了错误 |
1××
1××类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。
2××
2××类状态码表示服务器成功处理了客户端的请求，也就是我们最愿意看到的状态。
「200 OK」是最常见的成功状态码，表示一切正常。如果是非HEAD请求，服务器返回的响应头都会有body数据。
「204 No Content」也是常见的成功状态码，与200OK基本相同，但是响应头没有body数据。
「206 Partial Content」是应用于HTTP分块下载或断电续传，表示响应返回的body数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。
3××
3××类状态状态码表示客户端请求的资源发生了变动，需要客户端用新的URL重新发送请求获取资源，也就是重定向。
「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的URL再次访问。
「302 Moved Temporarily」表示临时重定向，说明请求的资源还在，但暂时需要用另一个URL来访问。
301和302都会在响应头里面使用字段Location，指明后续需要跳转的URL,浏览器会自动重定向新的URL.
「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。
4××
4××类状态码表示客户端发送的报文有误，服务器无法处理。
「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。
「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求错误。
「404 Not Found」表示请求的资源在服务器器上不存在或未找到，所以无法提供给客户端。
5××
5××类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。
「500 Internal Server Error」与400类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。
「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。
「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
「503 Service Unavailabe」表示服务器当前很忙，暂时无法响应服务器，类似“网络服务很忙，请稍后重试”的意思。
1.3 HTTP常见字段有哪些？
- Host
客户端发送请求时，用来指定服务器的域名。
比如：Host:A.com
- Content-Length
服务器在返回数据时，会有Content-Length字段，表明本次回应的数据长度。
比如：Content-Length: 1000
表示本次服务器返回的数据长度是1000个字段。
- Connection
Connection字段最常用语客户端要求服务器使用TCP持久化连接，以便其他请求复用。
HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的HTTP，需要指定Connection首部字段的值为Keep-Alive.
比如：Connection:keep-alive
一个可以复用的TCP连接就建立了，直到客户端或服务器主动关闭连接。
- Content-Type
Content-Type字段主要用于服务器回应时，告诉客户端，本次数据是什么格式。
比如：Content-Type：text/html;charset=utf-8
上面的类型表明，发送的是网页，而且编码是UTF-8。客户端请求的时候，可以使用Accept字段声明自己可以接受哪些数据格式。
Accept: /
上面代码中，客户端声明自己可以接受任何格式的数据。
- Content-Encoding 字段
Content-Encoding字段说明数据的压缩方法。表示服务器返回的数据使用什么压缩格式。
比如：Content-Encoding：gzip
上面表示服务器返回的数据采用gzip方式压缩，告知客户端需要用此方式解压。
客户端在请求时，用Accept-Encoding字段说明自己可以接受哪些压缩方法。
Accept-Encoding：gzip，deflate
2. GET和POST
2.1 含义
GET方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等。
POST方法则是相反操作，它向URI指定的资源提交数据，数据就放在报文的body里。
2.2 GET 和POST方法是安全和幂等的吗？
安全和幂等的概念：
- 在HTTP协议中，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。
- 所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。
GET 方法是安全且幂等的
POST方法是不安全的也不是幂等的
3. HTTP特性
1996/5 HTTP/1.0
1997/1 HTTP/1.1
1.1 版本最大变化，就是引入了持久连接（persistent conncetion），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive
客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close,明确要求服务器关闭连接。
Connection: close
目前，对于同一个域名，大多数浏览器允许同时建立6个持久连接。
举例：
GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Machintosh; Intel Mac OS X 10_10_5)
Accept: */*
说明：第一行是请求命令，必须是在尾部添加协议版本（HTTPP/1.0）。后面是多行头信息，描述客户端的情况。
服务器的响应格式：
HTTP/1.O 200 OK
Content-Type: text/plain
Content-Length: 13784
Expires: Thu, 05 DEC 1997 15:55:28 GMT
Server: Apache 0.8.4
Hello Word
说明：第一行是“协议版本 + 状态码（status code） + 状态描述”
HTTP 是「无状态、明文传输」
- 对于无状态的问题，解决方案有很多种，其中比较简单的方式是用Cookie技术。Cookie通过再请求和响应报文中写入Cookie信息来控制客户端的状态。相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户请求服务器的时候，带上「小贴纸」，服务器就知道了。
- HTTP的安全问题，可以用HTTPS的方式解决，也就是通过引入SSL/TLS层。
早期HTTP/1.0 性能上的一个很大问题，那就是每发起一个请求，都要建立一次TCP连接（三次握手），而且是串行请求，做了无畏的TCP连接建立和断开，增加了通信开销。
为了解决上述TCP连接问题，HTTP/1.1提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了TCP连接的重复建立和断开造成的额外开销，减轻了服务器的负载。
持久连接的特点是，只要任意一端没有明确剔除断开连接，则保持TCP连接状态。
HTTP/1.1 版本引入了管道机制（pipelining）,即在同一个TCP连接里面，客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率。
举例来说，客户端需要请求两个资源。以前的做法是，在同一个TCP连接里面，发送A请求，然后等待服务器做出回应，收到后再发出B请求。管道机制是允许浏览器同时发出A请求和B请求，但是服务器还是按照顺序，先回应A请求，完成后再回应B请求。问题，要是前面的回应特别慢，后面就会有许多请求排毒等着。这称为「队头阻塞」。(注意：现代浏览器默认是不开启 HTTP Pipelining )
「队头阻塞」的模式加剧了HTTP的性能问题。总之HTTP/1.1 的性能一般般，后续的HTTP/2 和HTTP/3 就是在优化HTTP的性能。
容易混淆的概念
TCP的keep alive和HTTP的Keep-alive是不同层次的概念：
- TCP的keep alive是检查当前TCP连接是否活着；
- HTTP的Keep-alive是要让一个TCP连接活久一点
TCP keep alive的表现：
当一个连接“一段时间”没有通讯数据时，一方会发出一个心跳包（Keep Alive包），如果对方有回应，则表明当前连接有效，继续监控。这个“一段时间”可以设置，具体做法google。如下：
4. HTTP与HTTPS
- HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS则解决HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输。
- HTTP连接建立相对简单，TCP三次握手之后便可进行HTTP的报文传输。HTTPS在TCP三次握手之后，还需要进行SSL/TLS的握手过程，才可以加密报文传输。
- HTTP的端口号是80，HTTPS的端口号是443.
- HTTPS协议需要向CA(证书权威机构)申请数字证书，来保证服务器的身份是可信的。
HTTPS建立一个连接，要花费6次交互，先是建立三次握手，然后是TLS/1.3 的三次握手。QUIC直接把以往的TCP和TLS/1.3 的6次交互合并成3次，减少了交互次数。QUIC是在UDP之上的伪TCP+TLS+HTTP/2的多路复用协议。
5. HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3演变
HTTP/1.1相比HTTP/1.0性能上的改进：
- 使用TCP长连接的方式改善了HTTP/1.0短连接造成性能开销
- 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间
HTTP/1.1 自身的性能瓶颈：
- 请求/响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩Body的部分
- 发送冗长的首部。每次互相发送相同的首部造成的浪费较多
- 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞
- 没有请求优先级控制
- 请求只能从客户端开始，服务器只能被动响应
HTTP/2协议是基于HTTPS的，所以HTTP/2的安全性是有保障的。
HTTP/2相比HTTP/1.1性能上的改进：
-
HTTP/2会压缩头（Header），如果你同时发送多个请求，他们的头是一样的或者是相似的，那么协议会帮你消除重复的部分。
-
HTTP/2不再像HTTP/1.1里的纯文本的报文，而是全面采用了二进制格式。头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。
-
HTTP/2的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。客户端还可以指定数据流的优先级。
-
HTTP/2的连接可以并发多个请求（多路复用），而不用按照顺序一一对应。移除了HTTP/1.1中的串行请求，不需要排队等待，不会再出现「队头阻塞」问题。
比如：在一个TCP连接里，服务器收到了客户端A和B的两个请求，如果发现A处理过程非常耗时，于是就回应A请求已经处理好的部分，接着回应B请求，完成后，再回应A请求剩下的部分。
-
服务器推送，HTTP/2在一定程度上改善了传统的「请求-应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。
比如：在浏览器刚请求HTML的时候，就提前把可能用到的JS、CSS文件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫Cache Push）
HTTP/2有哪些缺陷？HTTP/3做了哪些优化？
- HTTP/2主要的问题在于：多个HTTP请求在复用一个TCP连接，下层的TCP协议是不知道有多少个HTTP请求。所以一旦发生了丢包现象，就会触发TCP的重传机制，这样在一个TCP连接中的所有的HTTP请求都必须等待这个丢了包被重传回来。（区别：HTTP/1.1 的管道传输中，如果有一个请求阻塞，那么队列请求也统统被阻塞住了）
- HTTP/3 把HTTP下层的TCP协议改成了UDP