HTTP与HTTPS - 悦读

一、HTTP的概念
HTTP是超文本传输协议，是一种应用层协议，是基于为浏览器/服务器间提供统一的信息交换格式而出现的，其发展历程为HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3。

1. HTTP版本区别
HTTP/1.0：HTTP/1.0为短连接，即客户端单次请求后就关闭TCP连接。这样效率显然是很低的
HTTP/1.1：HTTP/1.1默认为长连接，提升了连接的利用率，可用报文中Connecton字段控制的，取值Keep-Alive 为长连接（默认），取值Close 表示关闭长连接。并且引入了管道化技术，发送请求后不必等待响应就可以继续发送下一个请求，但是由于性能原因很少被支持。
HTTP/2：HTTP/1为半双工，只能由客户端向服务端发送请求，服务端再响应请求。并且HTTP/1.1存在应用层队头阻塞和报文头部信息重复传输的问题。HTTP/2引入了全双工，服务端也可主动发送数据。并且HTTP/2通过将报文分帧传输的方式，实现了连接的多路复用，解决了应用层面的队头阻塞问题。此外，HTTP/2通过HPACK算法对HTTP报文头部进行了压缩，提升了传输效率
HTTP/3：在HTTP/3之前，HTTP都是基于TCP传输的。HTTP/3基于UDP传输

2. HTTP2 vs HTTP1.1
HTTP1.1存在的问题，HTTP1.1引入了长连接，但仍存在一些问题：

应用层队头阻塞：在一条连接中，客户端必须等待获取完一个请求的全部响应报文才能获取下一个请求的响应报文。如果说前一个请求需要的响应时间特别久比如说是一个大文件，后面的请求响应只能被阻塞。
报文头部信息重复传输：由于HTTP本身是无状态协议，每次请求响应都需要带上全部的头部信息，并且这些头部信息中很多都是重复不变的，比如UserAgent，或者每个字段的名称。这些头部信息的重复传输就造成了资源的浪费。
半双工：不支持服务器推送消息，因此当客户端需要获取通知时，只能通过定时器不断地拉取消息，这无疑浪费大量了带宽和服务器资源。
为了应对这些问题常见的优化方案如下：

减少请求数量：将请求的资源文件内联合并为一个请求响应。
增加连接个数：可以开多个TCP连接去分别进行请求，但是浏览器对一个域名的并发TCP连接数限制为6个，因此还有一些解决方案就是不同资源类型放到不同的二级域名下面，比如像图片这种消耗比较大的资源单独放到一个域名下，这样就可以增加并发的TCP连接数。但是大量的TCP连接的创建与销毁肯定是存在性能问题的，单个TCP连接的利用率还是没有提上去。前面提到的两个问题还是没有完全解决。

HTTP2做了如下改进：

报文分帧传输：在应用层将一个报文视为一个stream流，将报文拆分为多个有序的帧，每个帧的stream流id相同，帧id不同。那么在接收方就可以通过流id区分一个报文，并通过帧id将报文按序组装起来。因此在一个连接中就可以同时传输多个请求或者响应，就是多个报文的帧混合传输，接收端根据id在应用层进行组装，这样实现了连接的多路复用，有效提升了TCP连接的利用率。
报文头部压缩算法：使用HPACK算法对报文头部进行压缩。使用静态表存储常见的HTTP字段和值，用动态表存储请求过程中动态的字段和值，并且使用哈夫曼编码压缩字符串值。那么在传输过程中只需要用对应的表索引来替代实际的值，这样就大大减少了报文头部的大小。
支持全双工：服务器支持主动推送资源，大大提升了消息的传输性能，服务器推送资源时，会先发送 PUSH_PROMISE 帧，告诉客户端接下来在哪个 Stream 发送资源，然后用偶数号 Stream 发送资源给客户端。

参考：

https://www.bilibili.com/video/BV1vv4y1U77y
https://www.bilibili.com/video/BV1Jz4y1B7st
https://zhuanlan.zhihu.com/p/330300133
2. HTTP3 vs HTTP2
HTTP2是基于TCP进行传输的，但是基于TCP具有以下局限性：

TCP队头阻塞：TCP要保证数据包按序到达给到应用层，因此可能会出现一个报文stream的帧都到达了，要是等待前面丢失的重传，没办法给到应用层读取。
连接握手延迟与连接迁移： HTTPS 请求前需要经过 TCP 三次握手和 TLS 四次握手（TLS 1.2）建立连接，并且用户IP地址变动时又要重新建立连接，比如手机在4G网络和WiFi之间切换时。
慢启动：发送速率先要有个慢启动的过程。
HTTP3基于QUIC协议，其传输层为UDP：

无队头阻塞：UDP不关心数据包顺序，一个报文的帧都到达后由QUIC协议组装给应用层，丢失了由QUIC协议控制重传。
更快的连接握手与连接迁移：QUIC 协议握手，这个握手过程只需要 1 RTT，握手的目的是为确认双方的「连接 ID」。QUIC 协议的通信双方连接关系就是基于这个连接 ID确定的，而不是IP端口四元组，因此在用户网络发生变化时仍然可以基于连接 ID 继续通信，无需重新建立连接。
二、HTTP报文格式
作为一种应用层协议，其规定的信息交换格式如下：

1. 请求报文
请求报文为主动发送一个http请求的报文，格式说明:

请求行(request line)：包括请求方法，资源的URL，以及HTTP协议版本。
请求头(header)：包括请求服务器所需要的附加信息。
空行(CRLF)：请求头部后面必须是空行,即使请求数据为空,也要有空行。
请求数据(body)：也称为请求体，可以添加任意类型的数据，通过请求头中的Content-Length字段确定请求数据的长度。