当前位置: 代码迷 >> 综合 >> HTTP2.0和QUIC
  详细解决方案

HTTP2.0和QUIC

热度:43   发布时间:2024-01-20 06:49:51.0

最近看到腾讯云支持QUIC的文章,突然意识到还没有好好认识HTTP2、QUIC,而要认识HTTP2,就需要从HTTP1.0开始讲起,才能清楚HTTP的发展历程。

HTTP1.x

HTTP(HyperText Transfer Protocol)超文本传输协议伴随着计算机网络和浏览器的诞生,HTTP1.0也随之而来,处于计算机中的应用层。HTTP是建立在TCP协议之上,所以HTTP协议的瓶颈及其优化技巧都是基于TCP协议本身的特性,如TCP三次握手四次挥手建立连接带来的RTT延迟时间等。
HTTP建立之初,就是为了将HTML文档从Web服务器传送到客户端浏览器。
影响一个HTTP网络请求的主要因素:带宽和延迟

  • 带宽
  • 延迟
    • 浏览器阻塞(HOL blocking):浏览器对同一个域名,会限制最大连接数。
    • DNS查询(DNS Lookup):缓存DNS
    • 建立链接(Initial connection):TCP三次握手

HTTP 1.1与HTTP 1.0的区别:

  1. 缓存处理,引入更多缓存头控制缓存策略
  2. 带宽优化及网络连接的使用,增加断点续传功能
  3. 错误通知的管理:新增24个错误状态码,如409(conflict)表示请求资源与资源当前状态冲突、410(Gone)表示服务器上某个资源被永久性删除。
  4. Host头处理。随着虚拟主机技术的发展,一台物理服务器上可以存在多个虚拟主机且共享同一个IP。HTTP 1.1请求和响应都支持host头,请求消息中如果缺少host,会抱400(Bad Request)
  5. 长连接,HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少建立、关闭连接的消耗和延迟。HTTP 1.1中默认开启Connection:keep-alive。

HTTP 1.0与1.1存在的问题:

  1. HTTP传输数据,每次都要3次握手建立连接,增加了大量延迟
  2. 明文传输
  3. header携带内容过大,增加传输成本,并且每次请求header变化不大,移动端增加用户流量
  4. 虽然HTTP1.1支持了keep-alive,但是keep-alive使用多了同样给服务端带来大量的性能压力,因为文件被请求后,服务端需要保持不必要的连接很长时间。

HTTPS

HTTPS(网景1994创建)就是安全版的HTTP,与HTTP的区别如下:

  1. HTTPS协议需要到CA申请证书,免费证书很少,一般需要交费。
  2. HTTP协议运行在TCP之上,所有传输内容都是明文;HTTPS运行在SSL/TLS(Transport Layer Secure)上,SSL/TLS运行在TCP上,所有传输内容都是加密的。
  3. HTTP和HTTPS使用端口不同:HTTP默认80,HTTPS默认443。
  4. HTTPS可以有效防止运营商劫持。

一个HTTP网站全站改造为HTTPS,需要关注的点:

  1. 安装CA证书
  2. 购买证书后,在证书提供网站上配置自己的域名,将证书下载下来后,配置自己的web服务器,同时进行代码改造。
  3. HTTPS降低用户访问速度。SSL握手会一定程度降低速度。如果使用SPDY,HTTPS速度甚至还要比HTTP快。
  4. HTTPS中大量的密钥算法计算,会消耗服务端大量CPU资源。

SPDY

SPDY位于HTTP之下,TCP和SSL之上,可以轻松兼容老版本的HTTP协议,也可以使用已有的SSL功能。
SPDY是Google2012年提出,主要解决如下问题:

  1. 降低延迟。针对HTTP高延迟的问题,SPDY采取了多路复用(multiplexing)。多路复用通过多个请求stream共享一个tcp连接,解决了HOL blocking问题,降低延迟同时提高了带宽的利用率。
  2. 请求优先级(request prioritization)。多路复用的连接共享机制有可能导致关键请求被阻塞。SPDY允许给每个request设置优先级,重要请求优先得到响应。
  3. header压缩。
  4. 基于HTTPS的加密协议传输,大大提高了传输数据的可靠性。
  5. 服务端推送(Server push)

HTTP2.0

YouTube、淘宝已经支持http2.0.
HTTP2.0可以说是SPDY的升级版本,与SPDY的区别如下:

  1. HTTP2.0支持明文HTTP传输,而SPDY强制使用HTTPS。
  2. HTTP2.0消息头压缩算法使用HPACK,而SPDY使用DEFLATE。

HTTP2.0的主要目标是改进传输性能,实现低延迟和高吞吐量。

HTTP2.0新特性:

  1. 新的二进制(Binary Format)分帧层。HTTP1.x的解析基于文本,文本的展现形式多样,要做到健壮性考虑的场景必然很多,二进制则只有0和1,更高效健壮
  2. 多路复用(MultiPlexing),即连接共享,每一个request都是用作连接共享机制的。每一个request对应一个id,一个连接上可以有多个request,每个连接的request可以随机的混杂在一起,接收方根据request的id将request再归属到不同服务端请求里面。客户端只需要一个连接就可以加载一个页面。
  3. header压缩。避免了重复header的传输,又减少了需要传输的大小。
    1. HTTP2.0会压缩首部元数据,在client和server使用首部表跟踪和存储之前发送的健值对,对于相同数据,不需要每次请求响应都发送。首部表在HTTP2.0的连接有效期内始终存在,由client、server共同渐进地更新,每个新的首部健值对要么更新已有值要么append到表尾。
    2. 所有header必须全部小写,而且请求行要独立为健值对(即header 值)。
  4. 服务端推送(server push)。服务端可以对一个客户端请求发送多个响应。server push通过推送那些它认为客户端将会需要使用到的内容到客户端缓存中,以此避免往返的延迟。
    1. 客户端可以限定推送流的数量,也可以设置为0而完全禁用server push
    2. 所有推送都遵守同源策略,即服务器不能随便将第三方资源推送给客户端,而必须是经过双方确认的。
    3. PUSH_PROMISE帧:所有服务器推送流都通过PUSH_PROMISE发送,服务端发出有意push所述资源的信号,客户端接收到PUSH_PROMISE帧后,也可以拒绝这个流。
    4. 服务端必须遵循请求-响应的循环,只能借着对请求的响应推送资源。
    5. PUSH_PROMISE帧必须在返回响应之前发送,否则客户端会出现竞态条件。

HTTP2.0的升级改造需要考虑的点:

  1. HTTP2.0其实可以支持非HTTPS的,但是主流浏览器如chrome、Firefox还是只支持基于TLS部署的HTTP2.0协议,所以要升级HTTP2.0还是先升级HTTPS好。
  2. 升级HTTPS后,如果使用NGINX,只需要在配置文件中启动相应的协议就可以。
  3. HTTP2.0完全兼容HTTP1.x,对于不支持HTTP2.0的浏览器,NGINX会自动向下兼容。

QUIC协议

QUIC(Quick UDP Internet Connections)是由Google提出的一种基于UDP改进的低时延的互联网传输层(其实有疑义,QUIC基于UDP,其实更像应用层协议)协议。
优点:具有SPDY的所有优点;0-RTT连接;减少丢包;前向纠错,减少重传时延;自适应拥赛控制,减少重新连接;相当于TLS加密。

  1. QUIC主要目标是减少连接延迟,客户端第一次连接服务器时,QUIC只需要1RTT的延迟就可以建立可靠安全的连接,相对于TCP TLS的1~3次RTT要更加快捷。之后客户端可以在本地缓存加密的认证信息,再次与服务端建立连接时可以实现0RTT的连接建立延迟。
  2. QUIC同时复用了HTTP2.0的多路复用(Multiplexing)功能,但由于QUIC基于UDP,避免了HTTP/2的Head-of-Line Bolcking问题。
  3. QUIC基于UDP,运行在用户域而不是系统内核,使得QUIC协议可以快速部署和更新。
  4. 重传与恢复
    与TCP类似,QUIC每发送一个包后,都会等待回复一个确认包。当丢包率超过协议的纠错阀值,会显示与隐式进行重传。
    对于某些重要的数据包,在确认丢失前就会进行重传。这样在网络中会有若干个相同包同时传输,任何一个成功抵达就完成了连接,通过这样降低丢包率。接收方对于关键数据包的多次发送和普通数据包的超时重传,都采用相同的重复包处理机制。
    QUIC在拥塞避免算法上还加入了心跳机包,用于减少丢包率。
    QUIC使用FEC(前向纠错)来恢复数据,FEC采用简单的异或方式。每次发送一组数据,包含若干个数据包后,并对这些数据包依次做异或运算,最后结果作为一个FEC包再发送出去。接收方收到一组数据后,根据数据包和FEC包即可以进行考验和纠错。
  5. 安全性
    QUIC对每个散装的UDP包都进行了加密和认证的保护,并且避免使用前向依赖(如CBC模式)的方法,这样每个UDP包可以独立地根据IV进行加密或者认证处理。
    QUIC使用了两级密钥机制:初始密钥和会话密钥。初次连接时不加密,并协商初始密钥。初始密钥协商完毕后再马上协商会话密钥,这样可以保证密钥的前向安全性,之后通信过程还可以实现密钥的更新。接收方收到密钥更新时,需要用新旧两种密钥对数据进行解密,直到成功才会正式使用新密钥。
  6. 0RTT握手过程
    QUIC握手过程需要一次数据交互,0RTT即可以完成握手过程的密钥协商,比TLS相比效率提供了5倍。
    QUIC在握手过程使用Diffie-Hellman算法协商初始密钥,初始化密钥依赖于服务器存储的一组配置参数,该参数会周期性更新。初始密钥协商成果后,服务端会提供一个临时随机数,双方根据这个随机数再生成会话密钥。
    client具体握手过程如下:

更多专业前端知识,请上 【猿2048】www.mk2048.com