HTTP协议各版本比较

HTTP 优点

1. 简单

　　HTTP 基本的报文格式为 header + body，头部信息也是 key-value 简单文本的形式。

2. 灵活和易于扩展

　　HTTP协议里的请求方法、状态码、头字段等都允许自定义和扩充；HTTP 由于是工作在应用层，它的下层可以随意变化，HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层，HTTP/3 甚至把 TCP 换成了UDP 的。

3. 应用广泛和跨平台

　　HTTP 的应用范围非常的广泛，具有跨平台的优越性。

 

HTTP的缺点

1. 无状态双刃剑

　　无状态的好处，服务器不记忆 HTTP 的状态，不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务；

　　无状态的坏处，服务器没有记忆能力，在完成有关联性的操作时会非常麻烦。例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。对于无状态的问题可以用 Cookie 技术来解决，通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了。

2. 明文传输双刃剑

　　明文意味着在传输过程中的信息是可阅读的，通过浏览器的 F12 控制台或 Wireshark 抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。

　　在传输的漫长的过程中，信息的内容很容易就能被窃取。

3. 不安全

　　通信使用明文，内容可能会被窃听；不验证通信方的身份，可能遭冒充；无法证明报文的完整性，可能遭篡改。

 

HTTP1.1的性能

 

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

1. 长连接

　　早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接，增加了通信开销。为了解决上述 TCP 连接问题，HTTP/1.1 提出了长连接的通信方式，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

2. 管道网络传输

　　HTTP/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。可以在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。管道机制则是允许浏览器同时发出 A ，B请求，但是服务器还是按照顺序，先回应 A 请求，完成后再回应 B 请求。

3. 队头阻塞

　　当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「队头阻塞」。

 

HTTP/1.1 对 HTTP/1.0 的优化

　　使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。

　　支持 管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

性能瓶颈：

　　请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大，只能压缩Body 的部分；

　　服务器是按请求的顺序响应的，没有请求优先级控制，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；

　　请求只能从客户端开始，服务器只能被动响应。

 

HTTP/2 对 HTTP/1.1 的优化

　　头部压缩，HTTP/2 会压缩头（Header），在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

　　 二进制格式，HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，计算机收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。

　　数据流，每个请求或回应的所有数据包，称为一个数据流（Stream），每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数，客户端还可以指定数据流的优先级。

　　多路复用，HTTP/2 是可以在一个连接中并发多个请求或回应。举例来说，在一个 TCP 连接里，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程非常耗时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。

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

性能瓶颈：

　　HTTP/2 多请求复用一个TCP连接，一旦发生丢包，就会阻塞所有的 HTTP 请求。

 

HTTP/3 对 HTTP/2 的优化

　　HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP，UDP 发生是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的一个丢包阻塞所有的 HTTP 请求的问题。

　　基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

 

HTTP请求/响应的步骤 https://www.cnblogs.com/yongjin-hou/p/14370315.html

HTTP协议常见状态码 https://www.cnblogs.com/yongjin-hou/p/14513713.html

原文链接 https://mp.weixin.qq.com/s/bUy220-ect00N4gnO0697A