http-前端向

http 是应用层协议，在传输层使用 TCP 协议
http 发展：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
http 多个版本不同
- 在 http1.0 中每次连接传输数据完成后都会断开连接（TCP），称串行连接，但是现在的 web 动辄都几十个 http 请求，这样会很快就消耗完浏览器限定的 http 连接数，而且每次 TCP 连接都需要三次握手和四次挥手这样也极大浪费了网络资源和时间；
  - 但是 http1.0 后来改进了，可以设置 http 请求头 Connect：keep-alive，来保持不断开连接；
  - 缓存机制：http1.0 使用的缓存机制是 Expires（强缓存，记录具体时间），If-Modified-Since(协商缓存，更改的时间)
- 在 http1.1 中，默认了所有连接都是持久连接（而不必开发者主动设置），这样客户端可以发起多个 http 请求在一个 TCP 连接中，解决了 http1.0 多连接问题；注意的是，http1.1 中 TCP 连接发送多个 http 请求的时间，必须是前一个请求响应后才能发送第二个请求，没响应只能阻塞。这里也导致了一个问题，就是阻塞（常说的线性阻塞);
  - 缓存机制：http1.1 使用的缓存机制是 Cach-Control（强缓存，记录相对时间），Etag(协商缓存，hash)
  - 在 http1.0 的基础上增加了错误码
- 在 http2：【参考】
  - 更进一步，实现了多路复用，可以同时发送多个请求，不必按序和等待上一个请求响应，因为每个发送的请求都会有标记；
  - http2.0 起源于 2009 谷歌开发的 SPDY 协议，但后来又与 SPDY 不尽相同，比如头部压缩算法
  - 它的五大优势
    - 一个 web 应用在生命周期内只用一个连接，这减少多个连接建立带来的消耗，优化性能（特别是支持 https 的，TSL 的建立需要额外的消耗）
    - 多路复用，请求可以并行发送，不用阻塞
    - 头部压缩和二进制数据流，http2.0 使用 HPACK 算法对 http 头部进行压缩，减少需要传输的数据；同时 http 使用的数据是紧凑的二进制而不是普通的（明文的）文本；
    - 优先级处理，客户端可划分请求优先级；
    - SSL 加密（??)
  - HTTP2 的解释
    - 单连接多请求并发，HTTP2 有三个要素：
      - 消息（Messages），一个请求或者响应
      - 流（Streams），可以理解为一个管道，可以同时通过请求（正向）和响应（反向）的消息，HTTP2 只用一个连接这个连接被拆分为多个流，从而实现单连接多请求并发。
      - 帧（Frames），消息会被拆分为帧，分头帧（Headers Frame）和数据帧（Data Frame），作为流里面传输的单位；每一帧都包含了该帧所属的流（决定了路线）、是请求还是响应（决定了方向）
      - 多说无益，上图吧（图也是截取自《NGINX_HTTP2_White_Paper》）
        
        如图所示，一个连接 Connection 被划分为了多个流，请求和响应以帧为单位在流里面传输。
    - HPACK 算法压缩，其实大概就是在发送和接收方都维护一张静态表（Static table），约定对应的 headers 有对应索引（index），最后发送的就是这些索引不用发送哪些文本
- 同时 http/2 不打算有 http/2.1，将会直接发布 http/3，所以 2 是没有小数点的。
  - 相比 http/1.x，http/2 比较显著的是改变了 http/1.x 的头部必须是文本数据的方式，改用二进制解析，所以 http/2 的头部变成了二进制数据，同时数据体也是二进制，这是为了以后的扩展使用二进制解析会更好。
  - 头信息的压缩：http 请求无状态导致其需要很多的头数据表示信息，http/2 中可以把这些头部进行压缩。而且客户端和服务端都维护一张头信息表，把所有字段都会存进这个表，把需要用的字段读出生成一个索引号，发送的时候就发送索引号就行了
  - 出现了 server push
http 请求分为：状态行（GET url http1.1）、请求头、（中间有个空行）消息主体
http 的 get 方法提交数据有大小限制是因为 url 的长度有限制（2kb 左右），所以长的数据提交用 post 放在 body 中提交比较好
http 请求方式：http/1.0 有 3 种，http/1.1 增加 5 种
- GET：一般用作获取数据
- HEAD：一般是获取 get 方法的响应头；基本和 get 一样但是没响应体
- POST：更新服务器上的数据
- PUT
- DELETE
- CONNECT
- OPTIONS
- TRACE
- PATCH
http 响应分为：状态行（http1.1 200 OK）、响应头、响应正文
http 状态码（应答码）
- 200 OK：表示正常应答
- 301 Permanently：重定向，资源永久重定向到其它的 url
- 302 Temprorily:重定向，资源暂时重定向
- 304 Not Modify ：被缓存数据没改动，读缓存的（协商缓存有用到）
- 400 Bad Request：请求无效，提交字段和后端实体不一样
- 401 Unauthorized：客户端当前请求需要用户验证
- 403 Forbidden：服务器得到请求但拒绝执行（没权限）
- 404 Not Found：请求资源（网站）不存在
- 500 Internal Server Error：内部服务器错误
- 502 Bad Gateway：错误网关，发送了一个无效的请求（后端不存在）
- 504 Gateway Time-out：请求超时
响应头/请求头的content-length，transfer-encoding:chunked,
- 实体长度
  1
  content-length
  ：HTTP 报文实体(消息体)长度；它的出现主要是和 http1.1 中默认的
  1
  keep-alive
  有关，因为多个请求使用了一个 tcp，所以 http 需要一个信息去切分两个 http，所以
  1
  content-length
  表明了实体长度，就可以计算获取多少字节为一个 http 请求，下一个请求从哪里开始；
  - 这个字段必须准确，值与实体实际的长度一致，也即如：使用了 gzip 压缩，那 content-length 就应该是压缩后的大小。
  - ajax 的 onprogress(event)的 event.total 读取这个响应头的值，如图片、音频或者视频等就可以利用这点计算获取进度
- 传输编码
  1
  transfer-encoding:chunked
  ：表明 http 传输方式是分块传输方式；出现的主要原因是页面需要动态加载数据，而数据的长度不能确定（服务器动态不断生成数据），也即无法给出准确的 content-length，所以把实体划分为一块块的，然后逐块发送，最后以一个长度为 0 的块为结束标志。
  - 当头里有这个字段说明 content-length 是不准确的，所以一般不会有 content-length 字段，也即两个互斥
- https://my.oschina.net/ososchina/blog/666761