# http2/http3 协议有什么优劣
# HTTP2 的主要特性
http2.0
是一个二进制协议,http1
是超文本协议.传输的内容都不是一样的。http2.0
遵循多路复用即,代替同一 host 下的内容,只建立一次连接.http1
不是。http2.0
可以使用HPACK
进行头部的压缩,http1
则不论什么请求都会发送。http2.0
允许服务器,预先将网页所需要的资源PUSH
到浏览器的内存当中。
# HTTP2 的多路复用
- 在
HTTP1.1
的协议中,我们传输的 request 和 response 都是基本于文本的,这样就会引发一个问题:所有的数据必须按顺序传输,比如需要传输:hello world
,那么只能从 h 到 d 一个一个的传输,不能并行传输,因为接收端并不知道这些字符的顺序,所以并行传输在HTTP1.1
是不能实现的。 - 在
HTTP2.0
引入二进制数据帧和流的概念,其中帧对数据进行顺序标识,这样浏览器收到数据之后,就可以按照序列对数据进行合并,而不会出现合并后数据错乱的情况。同样是因为有了序列,服务器就可以并行的传输数据,这就是流所做的事情。 - 在
HTTP2.0
对同一域名下所有请求都是基于流,也就是说同一域名不管访问多少文件,也只建立一次连接。
# HTTP2 的新特性
# 新的二进制格式(Binary Format)
HTTP1.x
的解析是基于文本。基于文本协议的格式解析存在天然缺陷,文本的表现形式有多样性,要做到健壮性考虑的场景必然很多,二进制则不同,只认 0 和 1 的组合。基于这种考虑 HTTP2.0 的协议解析决定采用二进制格式,实现方便且健壮。
# 多路复用 (MultiPlexing)
即连接共享,即每一个request
都是是用作连接共享机制的。一个request
对应一个 id,这样一个连接上可以有多个request
,每个连接的request
可以随机的混杂在一起,接收方可以根据request
的 id 将request
再归属到各自不同的服务端请求里面。
# header 压缩
HTTP1.x
的header
带有大量信息,而且每次都要重复发送,HTTP2.0
使用encoder
来减少需要传输的header
大小,通讯双方各自cache
一份header
fields
表,既避免了重复header
的传输,又减小了需要传输的大小。
# 服务端推送 (server push)
同 SPDY 一样,HTTP2.0
也具有 server push 功能。目前,有大多数网站已经启用HTTP2.0
,例如 YouTuBe
,淘宝网等网站,可以利用chrome
控制台可以查看是否启用Http2.0
# SPDY
2012 年 google 如一声惊雷提出了SPDY
的方案,大家才开始从正面看待和解决老版本 HTTP 协议本身的问题,SPDY
可以说是综合了 HTTPS 和 HTTP 两者优点于一体的传输协议,主要解决:
降低延迟
针对 HTTP 高延迟的问题,
SPDY
优雅的采取了多路复用(multiplexing)。多路复用通过多个请求stream
共享一个tcp
连接的方式,解决了HOL blocking
的问题,降低了延迟同时提高了带宽的利用率。请求优先级(request prioritization)
多路复用带来一个新的问题是,在连接共享的基础之上有可能会导致关键请求被阻塞。
SPDY
允许给每个 request 设置优先级,这样重要的请求就会优先得到响应。比如浏览器加载首页,首页的 html 内容应该优先展示,之后才是各种静态资源文件,脚本文件等加载,这样可以保证用户能第一时间看到网页内容。header 压缩 前面提到
HTTP1.x
的header
很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。基于
HTTPS
的加密协议传输 这大大提高了传输数据的可靠性。服务端推送(server push) 采用了
SPDY
的网页,例如我的网页有一个style.css
的请求,在客户端收到style.css
数据的同时,服务端会将style.js
的文件推送给客户端,当客户端再次尝试获取style.js
时就可以直接从缓存中获取到,不用再发请求了。
SPDY
位于HTTP
之下,TCP
和SSL
之上,这样可以轻松兼容老版本的HTTP
协议(将HTTP1.x
的内容封装成一种新的 frame 格式),同时可以使用已有的SSL
功能。
# SPDY 与 HTTP2 的区别
- 头部压缩算法,
SPDY
,通用的deflate
算法[注 1];HTTP2
,专门为压缩头部设计的HPACK
算法 SPDY
必须在TLS
上运行,HTTP2
可在TCP
上直接使用,因为增加了HTTP1.1
的Upgrade
机制- 更加完善的协议商讨和确认流程
- 更加完善的
Server Push
流程 - 增加控制帧的种类,并对帧的格式考虑的更细致
# HTTP2 的缺点
TCP
以及TCP+TLS
建立连接的延时,HTTP2.0
使用TCP
协议来传输的,而如果使用HTTPS
的话,还需要使用TLS
协议进行安全传输,而使用TLS
也需要一个握手过程,在传输数据之前,导致我们需要花掉 3 ~ 4 个RTT
。TCP
的队头阻塞并没有彻底解决。在HTTP2.0
中,多个请求是跑在一个TCP
管道中的。但当 HTTP/2 出现丢包时,整个TCP
都要开始等待重传,那么就会阻塞该TCP
连接中的所有请求。
# HTTP3
Google 在推···的时候就已经意识到了这些问题,于是就另起炉灶搞了一个基于 UDP
协议的QUIC
协议,让HTTP
跑在QUIC
上而不是TCP
上。主要特性如下:
- 实现了类似
TCP
的流量控制、传输可靠性的功能。虽然UDP
不提供可靠性的传输,但QUIC
在UDP
的基础之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些TCP
中存在的特性 - 实现了快速握手功能。由于
QUIC
是基于UDP
的,所以QUIC
可以实现使用 0-RTT 或者 1-RTT 来建立连接,这意味着QUIC
可以用最快的速度来发送和接收数据。 - 集成了 TLS 加密功能。目前
QUIC
使用的是 TLS1.3,相较于早期版本 TLS1.3 有更多的优点,其中最重要的一点是减少了握手所花费的RTT
个数。 - 多路复用,彻底解决
TCP
中队头阻塞的问题
# 最后
文中若有不准确或错误的地方,欢迎指出,有兴趣可以的关注下Github,一起学习呀~~