HTTP 协议

HTTP 协议构成

HTTP 请求中的内容分为三个部分，分别为：

请求行
首部
实体

请求行： GET /api/v1/antmobile/getProductList HTTP/1.1 分别是请求方法，请求 URL，请求的 HTTP 协议版本号

Get 和 Post 区别

Post 相比 Get 更安全，因为 Get 的数据会在地址栏 URL 中显示，并且会保存在浏览器历史记录中，而 POST 请求是不会显示在浏览器 URL 中
GET 能缓存数据，POST 不能
POST 请求支持更多的编码格式，且不会对数据类型做限制
URL 有长度限制，会影响 GET 请求，URL 地址栏长度根据不同浏览器有各自的规定

首部

首部分为请求首部和响应首部，两者有通用的部分，下面先介绍通用的首部

1、通用首部

通用字段	作用
`Cache-Control`	控制缓存的行为
`Connction`	浏览器想要有限的连接类型，比如`keep-alive`
`Date`	创建报文事件
`Pragma`	报文指令
`Via`	代理服务器相关信息
`Transfer-Encoding`	传输编码方式
`Upgrade`	要求客户端升级协议
`Warning`	在内容中可能存在错误

2、请求首部

请求首部	作用
`Accept`	能正确接收的媒体类型
`Accept-Charset`	能正确接收的字符集
`Accept-Encoding`	能正确接收的编码格式列表
`Accept-Language`	能正确接收的语言列表
`Expect`	期待服务端的指定行为
`From`	请求方邮箱地址
`Host`	服务器的域名
`If-Match`	两端资源标记比较
`If-Modified-Since`	本地资源未修改返回 `304`（比较时间）
`If-None-Match`	本地资源未修改返回 `304`（比较标记）
`User-Agent`	客户端信息
`Max-Forwards`	限制可被代理及网关转发的次数
`Proxy-Authorization`	向代理服务器发送验证信息
`Range`	请求某个内容的一部分
`Referer`	表示浏览器所访问的前一个页面
`TE`	传输编码方式

3、响应首部

响应首部	作用
`Accept-Ranges`	是否支持某些种类的范围
`Age`	资源在代理缓存中存在的时间
`ETag`	资源标识
`Location`	客户端重定向到某个 `URL`
`Proxy-Authenticate`	向代理服务器发送验证信息
`Server`	服务器名字
`WWW-Authenticate`	获取资源需要的验证信息

4、实体首部

`Allow`	资源的正确请求方式
`Content-Encoding`	内容的编码格式
`Content-Language`	内容使用的语言
`Content-Length`	`request body` 长度
`Content-Location`	返回数据的备用地址
`Content-MD5`	`Base64`加密格式的内容 `MD5`检验值
`Content-Range`	内容的位置范围
`Content-Type`	内容的媒体类型
`Expires`	内容的过期时间
`Last_modified`	内容的最后修改时间

HTTP2.0

HTTP/2 很好的解决了当下最常用的 HTTP/1 所存在的一些性能问题，只需要升级到该协议就可以减少很多之前需要做的性能优化工作，当然兼容问题以及如何优雅降级应该是国内还不普遍使用的原因之一。
虽然 HTTP/2 已经解决了很多问题，但是并不代表它已经是完美的了，HTTP/3 就是为了解决 HTTP/2 所存在的一些问题而被推出来的。

1、HTTP/2

HTTP/2 相比 HTTP/1，大幅提高了网页性能
在 HTTP/1 中，为了性能考虑，我们会引入雪碧图、将小图内联、使用多个域名等等的方式。这一切都是因为浏览器限制了同一个域名下的请求数量（Chrome 下一般是限制六个连接），当页面中需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求数量时，剩余的资源需要等待其他资源请求完成后才能发起请求。
在 HTTP/2 中引入了多路复用的技术，这个技术可以只通过一个 TCP 连接就可以传输所有的请求数据。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题，同时也接更容易实现全速传输，毕竟新开一个 TCP 连接都需要慢慢提升传输速度。

二进制传输

HTTP/2 中所有加强性能的核心点在于此。在之前的 HTTP 版本中，我们是通过文本的方式传输数据。在 HTTP/2 中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码。

多路复用

在 HTTP/2 中，有两个非常重要的概念，分别是帧（frame）和流（stream）。
帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。
多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能。

在 HTTP/1 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。
在 HTTP / 2中，使用了 HPACK 压缩格式对传输的 header 进行编码，减少了 header 的大小。并在两端维护了索引表，用于记录出现过的 header ，后面在传输过程中就可以传输已经记录过的 header 的键名，对端收到数据后就可以通过键名找到对应的值。

服务端 Push

在 HTTP/2 中，服务端可以在客户端某个请求后，主动推送其他资源。
可以想象以下情况，某些资源客户端是一定会请求的，这时就可以采取服务端 push 的技术，提前给客户端推送必要的资源，这样就可以相对减少一点延迟时间。当然在浏览器兼容的情况下你也可以使用 prefetch

HTTP/3

虽然 HTTP/2 解决了很多之前旧版本的问题，但是它还是存在一个巨大的问题，虽然这个问题并不是它本身造成的，而是底层支撑的 TCP 协议的问题。
因为 HTTP/2 使用了多路复用，一般来说同一域名下只需要使用一个 TCP 连接。当这个连接中出现了丢包的情况，那就会导致 HTTP/2 的表现情况反倒不如 HTTP/1 了。
因为在出现丢包的情况下，整个 TCP 都要开始等待重传，也就导致了后面的所有数据都被阻塞了。但是对于 HTTP/1 来说，可以开启多个 TCP 连接，出现这种情况反到只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据。
那么可能就会有人考虑到去修改 TCP 协议，其实这已经是一件不可能完成的任务了。因为 TCP 存在的时间实在太长，已经充斥在各种设备中，并且这个协议是由操作系统实现的，更新起来不大现实。
基于这个原因，Google 就更起炉灶搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上，当然 HTTP/3 之前名为 HTTP-over-QUIC，从这个名字中我们也可以发现，HTTP/3 最大的改造就是使用了 QUIC，接下来我们就来学习关于这个协议的内容。

QUIC

之前我们学习过 UDP 协议的内容，知道这个协议虽然效率很高，但是并不是那么的可靠。QUIC 虽然基于 UDP，但是在原本的基础上新增了很多功能，比如多路复用、0-RTT、使用 TLS1.3 加密、流量控制、有序交付、重传等等功能。这里我们就挑选几个重要的功能学习下这个协议的内容

多路复用

虽然 HTTP/2 支持了多路复用，但是 TCP 协议终究是没有这个功能的。QUIC 原生就实现了这个功能，并且传输的单个数据流可以保证有序交付且不会影响其他的数据流，这样的技术就解决了之前 TCP 存在的问题。

并且 QUIC 在移动端的表现也会比 TCP 好。因为 TCP 是基于 IP 和端口去识别连接的，这种方式在多变的移动端网络环境下是很脆弱的。但是 QUIC 是通过 ID** 的方式去识别一个连接，不管你网络环境如何变化，只要 ID 不变，就能迅速重连上。

0-RTT

通过使用类似 TCP 快速打开的技术，缓存当前会话的上下文，在下次恢复会话的时候，只需要将之前的缓存传递给服务端验证通过就可以进行传输了。

纠错机制

假如说这次我要发送三个包，那么协议会算出这三个包的异或值并单独发出一个校验包，也就是总共发出了四个包。
当出现其中的非校验包丢包的情况时，可以通过另外三个包计算出丢失的数据包的内容。
当然这种技术只能使用在丢失一个包的情况下，如果出现丢失多个包就不能使用纠错机制了，只能使用重传的方式了

HTTP协议介绍