HTTP 是超⽂本传输协议，也就是HyperText Transfer Protocol
我们从后往前理解什么叫做超文本传输协议。
1.协议
作为一个协议，HTTP规定了两个以上参与者交流通信的规范，以及一些控制和错误处理方式。
2.传输
HTTP是一个双向协议，用在两点之间传输数据。
3.超文本
超越普通文字，包含文字图片视频等，有超链接，从一个超文本跳到另一个文本。
HTML就是超文本。
总结：HTTP是一个用于在 两点之间 传输 超文本 得约定和规范
状态码- 1开头，表示提示信息
- 2开头，表示成功报文正确收到
- 3开头，表示客户端请求的资源发生了变动，需要客户端用新的URL重新发送请求，重定向
- 4开头，表示错误，400表示客户端请求报文错误，403表示服务器禁止访问资源 404表示请求的资源在服务器上不存在或未找到，无法提供
- 5开头，表示服务器内部错误
- Host字段：客户端发送请求，指定服务器域名。Host=www.xxxx.com.通过host就可以将请求发往同一服务器上不同网站。
- Content-Length字段：服务器返回数据，表明本次回复数据长度。
- Connection字段：客户端要求服务器使用TCP持久连接。以便复用TCP连接。HTTP/1.1版本默认连接是持久连接。但为了兼容⽼版本的 HTTP，需要指定Connection ⾸部字段的值为Keep-Alive。
- Content-Type 字段：用于服务器告诉客户端数据类型。
- Accept字段：用于客户端请求时告知自己可以接受的数据类型。
- Content-Encoding 字段：说明数据的压缩⽅法。表示服务器返回的数据使⽤了什么压缩格式
GET方法请求从服务器获取资源。
比如我们用浏览器浏览页面，就会发送GET请求给服务器，服务器收到请求就会返回对应的资源。
POST方法时向URL指定的资源提交数据，数据内容放在报文body中。
比如在浏览器中留言：
点击提交，就会把文字放在报文body中，然后添加POST请求头部，通过TCP协议发送给服务器。
安全指：请求方法不会破坏服务器上的资源
幂等指多次同样操作得到的结果相同
显然，GET方法是安全且幂等的。而POST不安全也不幂等
HTTP/1.1的优缺点优点：
- 简单：报文格式header+body，头部信息也是key-value形式。
- 灵活和易于扩展：HTTP1.1协议中各类请求方法、URI URL、状态码，头部 都允许自定义。因为HTTP在第七层应用层，所以下层可随意变化。
由于HTTP有无状态、明文传输的特性，带来了不安全的特点。
1.无状态：
- 无状态的好处：服务器不需要额外资源来记录HTTP当前的状态。减轻服务器的负担。
- 无状态的坏处：无状态使得服务器没有记忆能力，完成关联性操作非常麻烦。比如购物：登录->添加购物⻋->下单->结算->⽀付，这些过程每一步都需要知道用户身份，但是服务器本身依靠HTTP1.1不具有记忆能力。所以每次都需要询问身份信息。
cookie可以解决无状态问题
cookie在请求和响应报文中写入cookie信息来控制客户端状态，即在客户端第一次请求之后。服务器会下发一个带有客户端信息的小标签，这样后续所有操作服务器看见小标签就能认识是之前的客户端。
2.明文传输
- 明文传输好处：方便调试与阅读
- 坏处不言而喻
3.不安全
- 明文传输，易被窃听
- 不验证身份，易被冒充
- 无法验证报文完整性，易被篡改。
HTTP是基于TCP/IP的，使用请求-应答的通信模式。
相较于1.0的改进
早期HTTP1.0性能的问题主要在每个请求都要建立一次TCP三次握手的连接。
为了解决TCP无谓的多次连接与断开，HTTP1.1提出了使⽤ KeepAlive 的长连接/持久连接的通信方式，只要没有一方明确提出断开连接的四次握手，则一直保持TCP连接状态。
管道网络传输：在同一个TCP连接中，客户端可以发起多个请求，只要第一个请求发出去了，不必等到ACK就可发送第二个请求。
即管道网络传输允许浏览器同时发出AB两个不同的请求，这和传输层TCP的滑动窗口机制很像。
- 冗长的头部未经压缩就发送，只能压缩body部分
- 队头堵塞：服务器按顺序响应，当某一个请求因为某种原因被阻塞之后，后续所有请求都被阻塞，这样客户端一直都收不到数据，这就是队头堵塞。
- 没有优先级控制
- 请求只能从客户端开始，然后服务器端被动响应
- 因为HTTP是明文传输，HTTPS为了解决这一问题。在TCP和HTTP应用层之间加入了SSL/TLS安全协议，使得报文加密传输
- 由于加入了新的SSL/TLS协议，HTTPS建立连接时，在TCP三次握手之后还需进行SSL/TLS握手，进入加密传输。
- 端口不同：HTTP是80端口，而HTTPS是443端口。
- **身份验证：**为了实现服务器身份的验证，HTTPS需要向CA（证书权威机构）申请数字证书以确认服务器身份可靠。
由此HTTPS解决了HTTP1.1的以下问题：
- 窃听问题：由于HTTP是明文传输的，到了HTTPS这里混合加密交互信息。这里混合加密指采用对称加密和非对称加密结合。通信建立之前非对称加密，通信过程中对称加密
- 身份校验问题：HTTPS 客户端向CA申请数字证书以确认服务器身份，避免冒充。
- 报文完整问题：用摘要算法生成摘要附加在明文之后，然后加密传输，对方解密后可用相同摘要算法验证数据完整性。避免数据篡改。
基于HTTPS，HTTP2做了以下改进：
- 头部压缩：如果多个请求的头部是一样或者相似的，HTTP2会消除重复头部部分。这就是所谓的HPACK算法：在客户端和服务器端同时维护一张头部信息表，所有字段都存入这个表，建立索引，以后就不发重复的头部了，就发个索引。以此提高速度。
- 二进制格式：头部和body全面采用二进制表示统称为帧。这样可以让计算机直接解析，增加数据传输效率。
- 数据流：不按序发送，每个请求或回应都称为一个数据流，每个数据流有唯一的编号，规定客户端发出的数据流编号为奇数，而服务器端发出的数据流编号为偶数。数据流还可指定优先级。优先级高的先响应请求。
- 多路复用：可以一个连接发送多个请求或回应，不按顺序一一对应。
- 服务器主动：可以让服务器主动向客户端发送消息。举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会⽤到的 JS、CSS 文件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。
问题：
多个HTTP包复用一个TCP连接，下层TCP不知道，一旦丢包，TCP触发重传机制之后，在一个TCP连接中所有HTTP请求都得等待这个丢了的包重传回来。
（因为HTTP1.1管道是串行的，所以有队头阻塞问题，但是是按顺序阻塞）
这里复用了TCP连接之后，丢包就阻塞所有HTTP请求。
因此HTTP3直接把下层的TCP协议改成了UDP
四.HTTP/3
又因为UDP不可靠，所以UDP需要基于UDP的QUIC协议可以实现类似TCP的可靠传输
- QUIC保证某个流丢包，只阻塞这个流，不影响其他流。
- TLS升级成了1.3版本，头部压缩算法升级成了QPack
- HTTPS建立一个连接需要TCP3次+SSL/TLS三次一共6次。QUIC把TCP和TLS/1.3的握手合并成了三次。
