一.目的
http协议属于应用层协议。
主要是为了解决c/s结构的通讯，简化通信的开发，统一协议，将一些如缓存协议，双方字符编码等进行规范约定。
二.请求与响应
http1.1 请求：
http协议的请求，主要是承载了当前的请求方法(Get或Post)，URL（就是域名url），以及一些功能性的约定（如缓存约定Cache-control，If-Modified-Since；可接受字符Accept-Charset，双方通信的消息格式Content-Type）。最后一个就是请求的实体内容了。
http1.1响应：
响应里面核心是状态码，如200，404.
剩下的就是首部里会返回content-type，last-modified等双方约定协议数据。
附：
expires是绝对时间(2021-03-10 14:00:00)，Cache-control(HTTP1.1才有)是相对秒数，这2个都是服务端告诉浏览器，然后浏览器自行判断是否过期。
ETag则是用特征值来进行决定，基本就是第一次响应服务器会返回资源的tag(比如可以是hashCode算法)，然后浏览器缓存。之后第二次请求的时候浏览器带上。服务器会做判断，如果相等则返回304 not modify，否则返回200并带上服务器资源数据。
Etag的优点是解决了If-Modified-Since及last-modify-time(这2个配对使用)之类的用资源修改时间去做判断，而这个修改时间一方面可能有些服务资源未变但更新了时间，还有一些则是同一秒修改了n次。但个人觉得看应用场景，如果对秒级别能接受内容不一致的，使用If-Modified-Since及last-modify-time即可。
Etag缺点是在集群环境每台机子生成的etag可能不同导致资源未变重新加载的问题。
三.各版本发展
整体http从1.0到1.1，以及后续的2.0，每个阶段都有相应的问题，也都是不断迭代进化。
1.协议1.1
主要是解决1.0的性能问题，从以下几个维度：
a.缓存约定
如If-Modified-Since等
b.长连接
避免每次请求都是一个连接。
有一个keep alive属性。
c.pipeline机制
共用一个tcp连接，但服务器及客户端处理请求与响应的顺序，还是以客户端发送为准。
如客户端发送a,b两个请求，则服务端实际按a,b的顺序处理请求并返回。
因此如果a请求处理慢，就会阻塞在这里。
2.协议2.0
2.0解决：
a.1.1中对于一个tcp中多个请求队首阻塞的问题(即请求a,b发送，响应必须是a,b)
b.1.1中性能问题，通过压缩请求header的内容
? ? ? ? 两端建立索引表，第一次请求才需要发送header，后面发送对应索引(如队首中的content-type，如果没变就不用发送对应完整值了，直接一个索引id就可以)即可。
2.0的核心策略是给请求加id，逻辑隔离，分成多个流。其次流又按header头及正文消息体分为header帧及数据帧。
2.0的解法是给每个请求加一个id，这样服务端是可以并行处理a,b的。然后返回的时候浏览器再根据请求的id进行分组独立组装即可。
但这种方式还是受限于tcp的包顺序性，如果流1的包a丢了，就会导致流2的包被阻塞。
请求流：
3.QUIC协议
todo