是什么？

（Hyper Text Transfer Protocol）超文本传输协议 基于TCP/IP套件的 应用层协议
HTTP在客户端-服务器模型中充当请求-响应协议，是万维网（WWW）通信的基础
他的底层假定是可靠传输协议，因此传输控制协议（TCP）是常用的，HTTP也可适用于不可靠协议，比如UDP。

历史

HTTP/0.9

第一个web服务器于1990年上线，所使用的协议只有一种，即get请求，它从服务器请求一个页面，最终返回一个html。
只有一个get命令，没有header等信息，服务端发送完毕，就关闭tcp链接。

HTTP/1.0

1996年 RFC)1945作为 HTTP/1.0 /的最终修订版发布，该修订版在前 4 年中被用作许多 Web 浏览器和 Web 服务器已经使用的预标准 HTTP/1.0 草案。

请求方式

新增 post 和 head

文本格式

新增可发送任何文本格式内容，文字，视频，图片，二进制文件等

Header

对于请求和相应的header，每次 请求 和 返回 都必须包含 header，描述数据内容。
其他的新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等

HTTP/1.1

1997 年，为了解决1.0的遗留问题，发布了1.1

解决队头阻塞，解决复用

但是1.1复用和队头阻塞还是有一些问题，另外目前header很大

http/2.0

2015 年5 月，HTTP/2作为RFC)7540发布，支持SPYD
SPYD

优化

请求响应过程

0.9

每一次请求都要经历tcp连接，三次握手，服务端发完数据就关闭了连接

缺陷

  • 无法复用造成的请求延迟

每次客户端与服务端通信后tcp连接就由服务端会断开，服务端不会记录通信状态，如果需要再次请求需要重新建立连接。
我客户端还想再请求呢，你就关了，还要三次握手才能连接，

  • 队头阻塞

head of line blocking
请求过程遵循先进先出（FIFO）队头阻塞是指一系列请求，因为第一个包被阻塞，后面的健康请求都被阻塞了，导致带宽无法被充分利用

1.1（长连接，管道）

长连接解决复用

增加长连接机制：connection：keep-alive，请求和相应可以在同一个tcp连接中完成
好处：减少了由于三次握手建立连接造成的请求延迟
缺陷：在浏览器使用域名分片（简单说就是浏览器把同一域名下的请求拆分到多个子域下）请求的时候，仍然会建立多个connection

http-pipelining解决队头阻塞

增加http-pipelining管道：
image.png

客户端可以同时发送多个请求，将客户端的FIFO转移到了服务端，服务端处理完所有请求后同时返回给客户端，同样遵循FIFO，但是如果使用代理服务器，则会对返回结果造成影响，只有幂等的请求才能被管线化，现在都用http2的多路复用了
比如，A请求是去修改用户的操作，b请求是获取修改的结果，但代理服务器上有b请求的缓存，结果客户端就不会拿到最新的数据。

缺陷

  • pipelining只解决了队头阻塞，但是对于一个耗时的请求，比如请求一个很大的图片，客户端仍然要等待这一组请求之后才能进行下一组请求
  • 只能支持幂等的请求
  • 大多数代理服务器不支持pipelining
  • 可能会有新的队头阻塞的问题

    2.0（SPDY）

    二进制分帧

    http1.x 是文本协议的二进制，http2 用二进制的方式把传输数据封装成frame的形式，header frame 和body frame
    二进制解析起来更加的高效，具有更高的压缩率（二进制协议和文本协议都是二进制，但二进制协议没有格式定义的内容，二进制协议的内容更小）
    多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装。
    偷两个图
    image.pngimage.png

多路复用

在同一个tcp连接上建立全双工通道，复用一个连接进行数据传输。由于tcp有慢启动的特性，所以所有的连接复用都比重连好

  1. 2.0 的tcp 连接复用 和 1.1 keep-alive的区别
  2. keep-alive是在应用层的，是串行的，也就是说，一个文件传输结束才能等待下一个传输
  3. tcp连接复用是发生在传输层的，不同文件的传输帧可以在一个TCP 连接中 同时进行流式传输

压缩报头

去掉了报头中重复传输的字段，并对其进行了压缩 （cookie,host,user-agent,）
HTTP/2 使用了专门为首部压缩而设计的 HPACK 算法
http2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表（字典），既避免了重复header的传输，又减小了需要传输的大小。

服务端推送？

通过报头 X-Associated-Content 通知客户端要推送内容

传输流优先级控制和流量控制

http2 中每个文件传输流都有自己的传输优先级，可以通过服务器来动态改变。
例如可以通过服务器来设置在 script 之前先 发送css到客户端，保证客户端的页面正常渲染。或者根据不同类型的用户去推送不同的页面样式，内容解析等。都可以通过服务端去进行定制化。

缺陷

  • 阻塞 在数据传输过程中丢包的时候，tcp必须等重传才能继续，就会阻塞tcp中所有的请求。这是tcp本身的性质造成的
  • 如果需要请求的资源分布在不同的域名下，那么请求资源依然需要建立多个tcp连接
  • http无法解决css会阻塞文档加载的问题，也无法预知css中需要加载的图片文字的资源
  • TCP 和 TLS 握手时延，TCL 三次握手和 TLS 四次握手，共有 3-RTT 的时延；
  • 连接迁移需要重新连接，移动设备从 4G 网络环境切换到 WIFI 时，由于 TCP 是基于四元组来确认一条 TCP 连接的，那么网络环境变化后，就会导致 IP 地址或端口变化，于是 TCP 只能断开连接，然后再重新建立连接，切换网络环境的成本高；

3.0（QUIC）

QUIC（Quick UDP Internet Connection）是谷歌制定的一种基于 UDP 的低时延的互联网传输层协议

队头阻塞问题

QUIC协议是基于UDP协议实现的，在一条链接上可以有多个流，流与流之间是互不影响的，当一个流出现丢包影响范围非常小，从而解决队头阻塞问题。

0RTT（round-trip time）建链

首次连接
使用QUIC协议的客户端和服务端要使用1RTT进行密钥交换，使用的交换算法是DH(Diffie-Hellman)迪菲-赫尔曼算法。
非首次连接
前面提到客户端和服务端首次连接时服务端传递了config包，里面包含了服务端公钥和两个随机数，客户端会将config存储下来，后续再连接时可以直接使用，从而跳过这个1RTT，实现0RTT的业务数据交互。

前向安全问题？

前向纠错？

这两个都是对http2中tls的改进，是基于DH算法的新的安全机制，具体的。。。先搁置吧—-

实施

http3底层使用的udp，服务端的迁移的成本非常高

目前问题

  • 浏览器阻塞（HOL blocking）：浏览器会因为一些原因阻塞请求。浏览器对于同一个域名，同时只能有 4 个连接（这个根据浏览器内核不同可能会有所差异），超过浏览器最大连接数限制，后续请求就会被阻塞。
  • DNS 查询（DNS Lookup）：浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用 DNS 缓存结果来达到减少这个时间的目的。

ConnectionConnectionconnect