HTTP 协议面试通关
请求响应和长连接
HTTP的请求和响应都是文本，可以简单认为HTT协议利用TCP协议传输文本
是不是每次发送一个请求，都建立一个TCP连接呢？
当然不是，为了节省握手、挥手时间，当浏览器发送一个请求到web服务器的时候，it set a 定时器，在一定范围的时间内，如果客户端发送请求，it will reset the 定时器。如果在定时器超时了，服务器还没有收到请求，就会将连接断开。
这样既防止了浪费握手、挥手的资源，又避免了一个连接占用时间过长，无法回收导致内存效率下降
定时器可以通过Keep Alive timeout = 5s这样类似的请求头进行配置
HTTP2.0 的多路复用
当一个网站需要加载的资源较多时，浏览器会尝试并发发送请求（利用多线程技术）
浏览器会限制同时发送并发请求的数量，通常是6个
这样做一方面是对本地用户体验的一种保护，防止浏览器抢占过多的网络资源
另一方面也是对站点服务的保护，防止瞬时流量过大
在HTTP2.0之后添加了多路复用能力， 类似RFC框架下提到的多路复用。请求返回会被拆分成切片，然后混合传输，这样请求与返回之间就不会阻塞。在HTTP1.1的Keep Alive设计中，HTTP基于TCP的传输，第二个请求必须等待第一个请求的返回，如果第一个请求阻塞了，后续的请求都会阻塞。HTTP2.0的多路复用将请求都拆分成小片，这样利用一个连接，相当于并发地发出了请求，相互之间不会有干扰。
HTTP方法和 RestFul架构
RE：Representational St：State Ful：Transfer
在Restful状态中，状态仅仅存在于服务端，前端无状态
目前服务端倡导的无状态指的是容器中的无状态
前端（浏览器、应用等）没有业务状态，却又要展示内容，因此前端拥有的是状态的表示，也就是Representation
Restful可以让前后端的职责清晰，前端负责渲染，后端负责业务，前端不需要业务状态，只需要展示，服务端除了关心状态还要提供状态转换的接口
HTTP方法
GET PUT POST DELETE
缓存
协商缓存 和强制缓存相比，协商缓存的代价是需要多发一次请求
强制缓存优先于协商缓存，若强制缓存生效则直接使用缓存，若不生效则进行协商缓存，协商缓存由服务器决定是否使用缓存，若协商缓存失效，那么代表该请求的缓存失效，重新获取请求结果，在存入浏览器缓存中，生效则返回304，继续使用缓存。
总结
目前HTTP协议已经发展到了2.0版本，不少网站都更新到HTTP2.0，大部分浏览器、CDN也支持HTTP2.0
HTTP3.0协议也在建设当中
HTTP3.0对HTTP2.0兼容，主要调整发生在网络层
