从HTTP/3的演进看web优化
原创
本文介绍http协议各个版本的问题，及改进优化点
1、HTTP发展时间线
2、Http/0.x 特点及问题
1963年 http雏形阶段，Ted Nelson创建了第一个http基础架构
1991年HTTP 0.9 Tim Berners-Lee提交了草案，0.x版本开始记录在RFC 1945 1996年HTTP 1.0 对0.9版本进行了改进
- 不支持多种类型文件下载：只能获取html文件（没有请求和响应头，浏览器只能按照协议规定视为html解析）
- 限定了数据传输方式：简单的ASCII字节码传输方式（因为服务端返回都是html格式文件）
- 不需要考虑连接复用问题（每次请求只有一个html）
随着浏览器诞生更新，推动http协议首要解决的问题是多种文件类型的支持
3、http/1.0改进及问题
- 最大改进是增加了请求头和响应头（有了头部kv的标识，就可以约定和协商）
- 对于头部信息的利用（增加了POST/HEAD方法、主动声明keep-alive、状态码、支持文件压缩、文件编码、用户代理、缓存机制…）
http/1.0的问题分析
- TCP链接不能共用（创建和断开tcp连接的开销大，每次通信独占一个连接，每个请求都需要经过创建、断开TCP连接过程，连续的两个请求至少浪费3个RTT耗时，http1.0如果共用连接需要在请求和响应头同时设置Connection: keep-alive）
- 不能够支持服务端虚拟主机技术（一个服务器多个host）
- 动态内容支持不友好（浏览器接收数据需要依赖服务端响应头的Content-Length字段，服务端必须提前知道内容长度，否则导致浏览器不知道何时结束)
- http队头阻塞问题（只支持串联通信，每个http请求必须等待前一个请求结束在开始，如果前一个请求丢包或其他原因没有响应，下一个请求必须等待）
4、http/1.1的改进及问题
1997年1月 HTTP1.1 1999年6月 补充修正记录在RFC 2068 RFC 2616
针对以上问题http1.1做了如下改进
- 增加了tcp持久连接和同域名连接共享（默认开启keep-alive，多个请求可共用连接，浏览器为同域名允许同时创建6个tcp持久连接）
- 请求头增加了HOST标识（用于标识当前请求的主机名）
- 使用Chunk transfer 机制解决动态内容支持（服务器会将数据分割若干任意大小的数据块，发送每个数据块时附上上个数据块的长度，最后用零长度的块作为发送数据完成的标志。这样就提供了对动态内容的支持。）
- 尝试使用管线化技术（pipelining）解决队头阻塞问题（在同一个tcp连接中并发发起多个请求，但是服务端依然要按照顺序接收）
额外的优化：
- 引入了安全策略
- 引入了cookie机制等
对于链接共用和域名分片
http/1.1的问题分析：
- 不能充分利用带宽资源
- 由于TCP的网络拥塞控制策略（为了保护减少网络拥塞，tcp采用慢启动发送数据，导致带宽不能被最大化利用）
- 由于TCP的流量控制(滑动窗口)导致多条tcp连接带宽资源抢占问题（虽然增加了持久连接，同域名连接共享来使用cdn域名分片加速，但同一时间连接个数的也将抢占固定的带宽）
- http队头阻塞问题（虽然1尝试使用管线技术解决并发问题，但是服务端依然按照顺序接收，所以最终放弃，选择建立6个连接，但是同连接下的请求依然是阻塞排队发送）
- 多个请求阻塞问题（同域名可以连接共享，但请求数量大于6个时，请求依然需要队列等待）
- 资源加载优先级问题（队头阻塞问题也会导致关键资源的加载滞后问题，影响首次渲染）
5、http/2的改进
2015年5月HTTP2上线，对HTTP1.1版本进行了优化改进，记录在RFC2754 RFC2754
对于带宽利用率、队头阻塞、请求优先级问题，引入了二进制分帧层做了如下实现：
- 多路复用multiplexing（在应用层和传输层之间添加了二进制分帧层实现同域一个连接共享，二进制分帧层将请求头请求体编号分帧处理，服务端接收帧后按编号合并处理返回）
- 请求优先级的设置（由于二进制分帧层的灵活性，可以标记额外帧信息，服务端也可以根据接收的关键资源顺序进行响应）
额外的优化
- 数据加密传输
- 添加了服务端推送能力
- 头部压缩
http2 的问题分析
- 单个TCP+TLS建立连接RTT耗时问题依然存在（3个RTT）
- TCP队头阻塞依然存在（tcp的数据丢失重传机制导致）
6、http3的改进
2018年11月7日 HTTP-over-QUIC 更名为HTTP3，基于UDP传输层协议QUIC
对以上问题，面临的tcp协议的修改，由于tcp协议应用广泛，中间设备和操作系统的协议僵化，http3使用基于UDP实现了传输层协议QUIC(quick udp internet connection)
- 优化了创建连接，减少RTT个数（0个或1个RTT，基于QUIC减少了 TCP 三次握手及 TLS 握手时间）
- 改进的拥塞控制（QUIC使用了TCP 协议的 Cubic 拥塞控制算法，具体看参照QUCI原理分析文章）
- 共享连接并发（实现了同一物理连接上的多个逻辑数据流并行）
- Quic的丢包重传机制（数据包编号严格递增保证唯一+stream offset保证有序传输）
参考资料
HTTP0.9 docs：https://www.w3.org/Protocols/HTTP/AsImplemented.html
HTTP1.0 RFC1945：https://tools.ietf.org/html/rfc1945
HTTP1.1 RFC2068：https://www.ietf.org/rfc/rfc2068.txt
HTTP1.1 RFC2616：https://www.ietf.org/rfc/rfc2616.txt
HTTP2 RFC7540：https://tools.ietf.org/html/rfc7540
HTTP2 HPACK RFC7541：https://tools.ietf.org/html/rfc7541
HTTP2：https://http2.github.io/
SPDY：https://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00
HTTP2 akamai demo：https://http2.akamai.com/
QUIC：https://datatracker.ietf.org/wg/quic/about/
QUIC-org：https://quicwg.org/
QUIC draft：https://tools.ietf.org/wg/quic/
Google QUIC：https://www.chromium.org/quic
QUIC docs：https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit
QUIC原理分析：https://baijiahao.baidu.com/s?id=1588818989895632410&wfr=spider&for=pc
没有更多了。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。