HTTP
参考资料：
HTTP基础
HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。
HTTP 错误码分类：
HTTP 常见字段：
- Host 指定域名
- Content-Lentgh 数据长度
- HTTP 协议通过设置回车符、换行符作为 HTTP header 的边界，
- 通过 Content-Length 字段作为 HTTP body 的边界，这两个方式都是为了解决“粘包”的问题。
- Connection 常用于客户端要求服务器使用「HTTP 长连接」机制， 一般填 “Keep Alive”
- Content-Type 数据格式
- Content-Encoding 数据压缩格式
GET,POST
根据 RFC 规范。
- GET 的语义是从服务器获取指定的资源
- POST 的语义是根据请求负荷（报文body）对指定的资源做出处理
安全与幂等
- 在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。——GET
- 所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。——GET
- POST 由于会修改服务器上的资源不满足上述条件
HTTP 缓存
对于重复性的 HTTP 请求，可以把请求缓存在本地，立刻响应结果
强制缓存
利用下面这两个 HTTP 响应头部字段实现的，它们都用来表示资源在客户端缓存的有效期：
- Cache-Control， 是一个相对时间；
- Expires，是一个绝对时间；
浏览器再次发出请求访问时查本地缓存，优先使用 Cache-Control，每次相应刷新字段。
协商缓存
协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存。
前端喜欢问这玩意--，懒得看了
HTTP 1.1
优点：
- 简单，HTTP 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛。
- 灵活和易于扩展，HTTP 协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。
- 应用广泛和跨平台
- 管道传输，批量请求，解决了请求的队头阻塞，但是没有解决响应的队头阻塞。(默认不开启)
缺点：
- 无状态，如例如登录->添加购物车->下单->结算->支付，每次都需要验证用户身份
- 不安全
- 通信使用明文（不加密），内容可能会被窃听。
- 不验证通信方的身份，因此有可能遭遇伪装。
- 无法证明报文的完整性（正确性），所以有可能已遭篡改。
性能瓶颈
- Header未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；（http2.0）
- 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；（http2.0）
- 响应队头阻塞，服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据；（http3.0 QUIC）
- 没有请求优先级控制；
- 请求只能从客户端开始，服务器只能被动响应。（服务器不能主动推送，http2.0 solved）
HTTP2.0
基于 https， 安全性有保障。
性能上的改进：
- 头部压缩，如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。
HPACK: 在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。
- 二进制格式，HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式。
- 头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧（Headers Frame）和数据帧（Data Frame）。
- 收到报文后直接解析二进制，比如 200 原来用
'2','0','0'三个字节来表示，压缩以后是10001000即 200 在静态表中表示（在http2.0中出现），只需要 1 个字节即可！
- 并发传输，引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接。
- 针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。
- 客户端收到后，会根据相同的 Stream ID 有序组装成 HTTP 消息。
- 服务器推送，可以主动向客户端发送消息。
- 客户端和服务器双方都可以建立 Stream， Stream ID 也是有区别的，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。
缺点：
- 由于基于TCP协议，存在 TCP 协议上的队头阻塞。
- 一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。