http1.0到http3.0的介绍，常见的http的请求方式介绍，常见状态码

HTTP 建立之初，是为了将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。但随着CSS,Javascript的出现，以及移动互联时代的到来，我们不得不对HTTP进行不断地优化。
目前影响http请求的只有延迟，浏览器阻塞（HOL blocking）, DNS查询（DNS Lookup）,建立连接（Initial connection）
参考文章1
参考文章2
1. http1.0
三种请求方法： GET, POST 和 HEAD方法。
特点：
无状态：服务器不跟踪不记录请求过的状态
无连接：浏览器每次请求都需要建立tcp连接
导致问题：（无法使用cookie/session机制，无法复用链接，导致网络利用率低，请求响应慢，可能导致阻塞）
无状态导致的问题可以借助cookie/session机制来做身份认证和状态记录解决。
无连接：
无法复用连接。每次发送请求的时候，都需要进行一次TCP连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会导致网络的利用率非常低。
队头堵塞(head of line blocking)。由于HTTP/1.0规定下一个请求必须在前一个请求响应到达之前才能发送。假设一个请求响应一直不到达，那么下一个请求就不发送，就到导致阻塞后面的请求。

2. http1.1
新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法
OPTIONS：这个方法很有趣，但极少使用。它用于获取当前URL所支持的方法。若请求成功，则它会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET, POST”。
POST：向服务器提交数据。这个方法用途广泛，几乎目前所有的提交操作都是靠这个完成。
GET：GET可以说是最常见的了，它本质就是发送一个请求来取得服务器上的某一资源。资源通过一组HTTP头和呈现数据（如HTML文本，或者图片或者视频等）返回给客户端。GET请求中，永远不会包含呈现数据。
HEAD：HEAD和GET本质是一样的，区别在于HEAD不含有呈现数据，而仅仅是HTTP头信息。有的人可能觉得这个方法没什么用，其实不是这样的。想象一个业务情景：欲判断某个资源是否存在，我们通常使用GET，但这里用HEAD则意义更加明确
PUT：这个方法比较少见。HTML表单也不支持这个。本质上来讲， PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的存放位置，而POST则没有，POST的数据存放位置由服务器自己决定。举个例子：如一个用于提交博文的URL，/addBlog。如果用PUT，则提交的URL会是像这样的”/addBlog/abc123”，其中abc123就是这个博文的地址。而如果用POST，则这个地址会在提交后由服务器告知客户端。目前大部分博客都是这样的。显然，PUT和POST用途是不一样的。具体用哪个还取决于当前的业务场景。

长连接
HTTP1.1增加Connection字段，通过设置Keep-Alive保持HTTP连接不断卡。避免每次客户端与服务器请求都要重复建立释放建立TCP连接。提高了网络的利用率。
如果客户端想关闭HTTP连接，可以在请求头中携带Connection:false来告知服务器关闭请求。
管道化（pipelining）
基于HTTP1.1的长连接，使得请求管线化成为可能。 管线化使得请求能够“并行”传输。
但是并不是真的实现并行：HTTP管道化可以让我们把客户端（请求队列）迁移到服务端（响应队列），服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。
缓存处理 — 强缓存、协商缓存，启发式缓存（新增）
HTTP1.1还加入了缓存处理（强缓存和协商缓存），新的字段如cache-control，支持断点传输，以及增加了Host字段（使得一个服务器能够用来创建多个Web站点）

3. http2.0
二进制分帧
HTTP2.0通过在应用层和传输层之间增加一个二进制分层帧，突破了HTTP1.1的性能限制，改进传输性能。
多路复用（链接共享）— 真并行传输
流（stream）：已建立连接上的双向字节流。
消息：与逻辑消息对应的完整的一系列数据帧。
帧（frame）：HTTP2.0通信的最小单位，每个帧包含头部，至少也会标识出当前所属的流（stream_id）
每个数据流以消息的形式发送，而消息由一或多个帧组成。这些帧可以乱序发送，然后再根据每个帧头部的流标识符（Stream_id）重新封装。
HTTP2.0通过多路复用实现了真正的并行传输，同一个域名下能够在一个TCP上进行任意数量的HTTP请求。而这个强大的功能基于“二级制分帧”的特性
头部压缩

服务器推送

3. http3.0(QUIC)
QUIC (Quick UDP Internet Connections), 快速 UDP 互联网连接
相比于http2.0最大的优势是使用了UDP建立链接，而不是使用tcp，减少了RTT(往返延迟时间)时间。
多路复用，队头阻塞(HOL)问题的解决更为彻底
基于TCP的HTTP/2，尽管从逻辑上来说，不同的流之间相互独立，不会相互影响，但在实际传输方面，数据还是要一帧一帧的发送和接收，一旦某一个流的数据有丢包，则同样会阻塞在它之后传输的流数据传输。而基于UDP的QUIC协议则可以更为彻底地解决这样的问题，让不同的流之间真正的实现相互独立传输，互不干扰。
QUIC基于UDP，一个连接上的多个stream之间没有依赖，即使丢包，只需要重发丢失的包即可，不需要重传整个连接。

更好的移动端表现，切换网络时的连接保持，：
QUIC在移动端的表现比TCP好，因为TCP是基于IP识别连接，而QUIC是通过ID识别链接。 无论网络环境如何变化，只要ID不便，就能迅速重新连上。
当前移动端的应用环境，用户的网络可能会经常切换，比如从办公室或家里出门，WiFi断开，网络切换为3G或4G。基于TCP的协议，由于切换网络之后，IP会改变，因而之前的连接不可能继续保持。而基于UDP的QUIC协议，则可以内建与TCP中不同的连接标识方法，从而在网络完成切换之后，恢复之前与服务器的连接。

加密报文头部和body内容
只要对 QUIC 做任何更改，接收端都能及时发现，有效地降低了安全风险。
向前纠错机制
少量的丢包可以通过其他包的冗余数据直接组装而无需重传。

常见状态码：
状态码
200：返回数据成功
201：已经成功创建连接，等待响应
301：永久重定向
302：临时重定向
304：读取缓存资源
401：需要身份认证
403：禁止访问（原因：通常是由客户端浏览器UA设置不正确，或所在IP不允许访问该服务器。UA 是“UserAgent”（用户代理）的简写，一般用来区分不同的浏览器）
500：程序错误
501：服务器不支持的请求方法
503：程序临时错误，可能需要等一会就好了
502：网关未相应
504：网关超时