HTTP报文结构

起始行——头部header——空行——主体body
HTTP协议基于TCP/IP，使用了请求-应答的通信方式
根据需求分为请求报文和响应报文，还是这个格式，叫法不一样而已

请求报文

1 请求行：请求方法，URL，HTTP版本，空格隔开
2 请求头：键值对格式，用冒号：隔开
3 空行
4 请求正文(get请求不需要请求正文)

请求方法：get,post,head,options,put,delete,trace,connect

响应报文

1 响应行：HTTP版本，状态码，状态说明，空格隔开
2 响应头
3 空行
4 响应正文

状态码：100,101,102,200,301,302,304,400,401,403,404,500,503

HTTP的8个请求方法

Get：获取资源
请求从服务器获取资源，那些被URL识别的资源。如果请求的资源是文本，就保持原样返回

Post：传输实体文本
向URL指定的资源提交数据，数据内容放在Post报文的body中，通常会导致服务器上的状态发生变化

Head：获取报头
类似get请求，只不过返回的响应中没有具体的内容，只用于获取报头
可以查看响应中的状态码，查看对象是否存在；测试资源是否被改动；判断类型

Put：传输文件
要求在请求报文的主题中包含文件内容，然后保存在请求URL指定的位置。自身没有验证机制，任何人都可以上传文件，存在安全问题

Options：查询性能
允许客户端查看服务器的性能

Delete：删除资源
按照URL删除指定资源，一般是客户端->服务端

Trace：追踪路径
客户端可以追踪请求信息的传输路径

Connect：使用隧道协议连接代理
在与代理服务器通讯的时候建立隧道，并使用隧道协议进行TCP通信。主要使用SSL/TLS协议加密通讯内容

安全和幂等

安全：不会破坏服务器上的资源
幂等：执行多次相同的操作后，结果都是相同的

方法对比

Get和Post区别
1 get只读，是安全幂等的，post会修改服务器上请求的资源，传输不安全需要叠加HTTPS，不安全不幂等
2 get请求可以被缓存，可以在浏览器历史记录中找到get请求并收藏到数千中，post都不行
3 get请求只能进行URL编码，post支持多种编码方式
4 get有长度限制，post没有

Get和Post共同点
1 都是使用的同一个传输层协议(TCP/UDP)，所以在传输上没有区别
2 都可以传输实体内容，但是一般不用get这么做而是post

Head和Get区别
get有实体，head无实体

HTTP状态码

1xx
提示信息，表示当前处于协议的中间状态，还需要后续操作，用不到

2xx
表示服务器成功处理了客户端的请求

200：一切正常，如果是非head请求，那么服务器返回的响应头里都会有body数据(head无实体的原因？)
204：约等于200，但是响应头里没有body数据
206：应用于HTTP分块下载或断点续传，表示响应返回的body数据并不是资源的全部，虽然成功传输了，但只是资源的一部分成功

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

301：永久重定向，请求的资源已经不在了，需要新的URL重新访问
302：临时重定向，说明资源还在，但暂时需要另一个新的URL重新访问
304：缓存重定向，用于缓存控制，重定向已经存在的缓存文件

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

4xx
表示客户端发送的报文有误，服务器无法处理

400：笼统的错误
403：服务器禁止访问资源，输出客户端的请求有误
404：请求的资源在服务器上找不到或不存在，无法提供给客户端

5xx
客户端的请求报文正确，服务器处理请求时内部发生了错误

500：笼统的错误
501：客户端请求的功能还不支持
502：服务器作为网关或代理时的错误代码，表示服务器自身工作正常，但后端服务器发生了错误
503：服务器当前很忙，暂时无法响应服务器

HTTP版本演变

HTTP/1.0

“短连接”：
每发起一个请求都要建立一次TCP连接和断开，并且是串行的
连接-请求-应答-断开-连接-请求-应答-断开-连接-请求-应答-断开，麻烦

HTTP/1.1

长连接：
只需要建立一次连接，只要任意一方没有明确提出要断开连接，就一直保持TCP连接状态，最后一次断开
连接-请求-应答-请求-应答-请求-应答-断开，避免了不必要的连接和断开

管道网络传输：
在长连接的基础上，在同一个TCP连接中，客户端可以发出多个请求，不必等其回来还可以继续发，减少了整体的响应时间
连接-请求-请求-请求-应答-应答-应答-断开，每次发送请求都不必等待上一段请求的应答被接收

队头阻塞：
在一个管道通信传输中，服务器会依次处理先后收到的请求，但如果服务器处理前面的请求太慢了，那么后面的请求就会被堆积，需要排队等着

HTTPS，加密后面再补充

1 在HTTP与TCP之间加入SSL/TLS安全协议，传输数据时，HTTPS会对数据进行对称加密
2 HTTPS需要向CA(证书权威机构)申请数字证书，来保证服务器的身份是可靠的
3 HTTPS建立连接需要6次交互，其中三次正常握手，TLS/1.3的三次握手
4 HTTP的端口号80，HTTPS的端口号443

HTTP/2，基于HTTPS

头部压缩：
如果发送多个相似请求，那么HTTP/2可以消除重复的头部，使用HPACK算法

二进制格式：
HTTP/1.1使用纯文本形式的报文，HTTP/2使用二进制格式
head和data都是二进制帧frame，分为头信息帧和数据帧，提高传输效率

数据流stream：
一条TCP连接包含多个stream，多个stream可以复用一条TCP连接，stream里可以包含多个信息，每个信息对应一个HTTP的请求或响应
每个stream都有一个唯一编号，所以数据可以乱序发送，使HTTP/2得以实现并行发送请求和响应
客户端发出的数据流编号为奇数，服务器发出的数据流编号为偶数。客户端还可以指定数据流的优先级，服务器可以优先处理

并发传输/多路复用：
通过stream的设计得以实现复用TCP，并发且乱序发送数据
可以在一个连接中并发多个请求或回应，而不是HTTP/1.1的串行发送，不需要排队等待处理，也就不会发生队头阻塞，降低了延迟，提高连接的利用率

服务器推送：
服务器不再是被动的响应，也可以主动向客户端发送信息
比如服务器推送：在浏览器刚请求HTML时，就可以提前把可能会用到的JS、CSS等静态文件主动发送给客户端，减少延迟的等待

HPACK算法：客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，后面就不会再发送相同的字段，只发送索引号了，可以提高速度

HTTP/3，无QUIC笔记

1 将HTTP/2下层的TCP改为了UDP，使用基于UDP的QUIC协议实现可靠传输
2 HTTPS建立连接需要3+3次握手，而QUIC合并成了3次
3 当某个数据流丢包时，可以只阻塞这个流而不是全部流

HTTP/1.1缺点

1 首部过长
2 因为是串行处理请求，导致队头阻塞
3 没有请求优先级控制
4 只能从客户端发起请求，服务器只能被动响应

HTTP/2缺点

TCP层的“队头阻塞”问题：
因为HTTP/2基于TCP传输，而TCP是字节流协议，必须要保证字节数据的完整
当多个HTTP请求复用一个TCP连接时，一旦发生丢包，就会阻塞所有的HTTP请求
触发TCP的重传机制，所有HTTP请求都必须要等待这个丢包被重传回来