相较于传统 HTTP,HTTP 3 到底有哪些改进?

2021-05-27 00:00:00 客户端 连接 传输 协议 建立


上一篇文章阶段性总结(一):HTTP 协议,从1.0到2.0梳理了一下HTTP协议。本文将重点介绍,在通信协议中HTTP2的前身,具有开拓性意义的SPDY,以及具有颠覆性的QUIC协议。

一、开拓者:SPDY

1. 简介:

spdy 是由google推行的,改进版本的HTTP1.1 (那时候还没有HTTP2)。它基于TCP协议,在HTTP的基础上,结合HTTP1.X的多个痛点进行改进和升级的产物。它的出现使web的加载速度有极大的提高。HTTP2也借鉴了很多spdy的特性。

2. 特性:

上一篇文章中有介绍,基本和HTTP2差不多,这里就不赘述了:

  • 多路复用
  • 头部压缩
  • 服务器推送
  • 请求优先级
  • spdy的架构图:

3. 现状:

在HTTP2未推出之前,spdy在业界内已经有一定的市场占用量,并且它的成绩也是不容忽视的,因此在很长一段时间,市场上可能会见到spdy和h2同时使用的场景。

二、颠覆者:QUIC

1. 前置知识:

TCP 与 UDP

TCP(Transmission Control Protocol 传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议。
1)提供IP环境下的数据可靠传输(一台计算机发出的字节流会无差错的发往网络上的其他计算机,而且计算机A接收数据包的时候,也会向计算机B回发数据包,这也会产生部分通信量),有效流控,全双工操作(数据在两个方向上能同时传递),多路复用服务,是面向连接,端到端的传输;
2)面向连接:正式通信前必须要与对方建立连接。事先为所发送的数据开辟出连接好的通道,然后再进行数据发送,像打电话。
3)TCP支持的应用协议:Telnet(远程登录)、FTP(文件传输协议)、SMTP(简单邮件传输协议)。TCP用于传输数据量大,可靠性要求高的应用。
UDP(User Datagram Protocol用户数据报协议)是OSI(Open System Interconnection,开放式系统互联) 参考模型中一种无连接的传输层协议,提供面向事务的简单不可靠信息传送服务。
1) 面向非连接的(正式通信前不必与对方建立连接,不管对方状态就直接发送,像短信,QQ),不能提供可靠性、流控、差错恢复功能。UDP用于一次只传送少量数据,可靠性要求低、传输经济等应用。
2) UDP支持的应用协议:NFS(网络文件系统)、SNMP(简单网络管理系统)、DNS(主域名称系统)、TFTP(通用文件传输协议)等。
总的来说:
TCP:面向连接、传输可靠(保证数据正确性,保证数据顺序)、用于传输大量数据(流模式)、速度慢,建立连接需要开销较多(时间,系统资源)。
UDP:面向非连接、传输不可靠、用于传输少量数据(数据包模式)、速度快。

Diffie-Hellman 算法

D-H算法的数学基础是离散对数的数学难题,其加密过程如下:
(1)客户端与服务端确定两个大素数 n和 g,这两个数不用保密
(2)客户端选择另一个大随机数x,并计算A如下:A = g^x mod n
(3)客户端将 A 发给服务端
(4)服务端选择另一个大随机数y,并计算B如下:B = g^y mod n
(5)服务端将B发给客户端
(7)计算秘密密钥K1如下:K1=B^2 mod n , 计算秘密密钥K2如下:K2=A^y mod n , K1=K2,因此服务端和客户端可以用其进行加解密
攻击者知道n和g,并且截获了A和B,但是当它们都是非常大的数的时候,依靠这四个数来计算k1和k2非常困难,这就是离散对数数学难题。

2. 什么是QUIC?

quic 是google推出的,基于UDP的高效可靠协议。quic在UDP的基础上实现了TCP的一些特性,而由于底层使用的是UDP,所以传输效率比TCP高效。

3. 特性

a. 基于UDP建立的连接:
我们知道,基于TCP的协议,如http2,在建立连接的时候需要进行三次握手,即至少需要3个ntt,而考虑安全HTTPS的TLS层,又需要至少次的通信才能协商出密钥。这在短连接的场景中极大的增加了网络延迟,而这种延迟是无法避免的。

而基于UDP的quic协议,则不需要3次握手的过程,甚至在安全协商阶段只需要进行1~2次的协商通信,即可建立安全稳定的连接,极大的减少了网络延迟。

b. 基于Diffie-Hellman的加密算法:
HTTPS 使用的是 TLS + SSL 的加密手段,在交换证书、协商密钥的过程中,至少需要2次ntt进行协商通信。而quic使用了Diffie-Hellman算法,算法的原理使得客户端和浏览器之间只需要1次的协商就能获得通信密钥,quic建立安全链接的详细过程:

  • 客户端发起Inchoate client hello

  • 服务器返回Rejection,包括密钥交换算法的公钥信息,算法信息,证书信息等被放到server config中传给客户端

  • 客户端发起client hello,包括客户端公钥信息

c. 改进的多路复用
我们知道,无论是HTTP2还是SPDY,基于TCP的协议尽管实现了多路复用,但仍然没有避免队头阻塞的问题,这个问题是由于TCP底层的实现造成的,即TCP的包有严格的顺序控制,前序包如果丢失,则后续包即使返回了也不会通知到应用层协议,从而导致了前序包阻塞。而quic基于UDP则天然的避免了这个问题,由于UDP没有严格的包顺序,一个包的阻塞只会影响它自身,并不会影响到其他资源,且quic也实现了类似HTTP2的多路复用,这种没有队头阻塞的多路复用对延迟的降低是显而易见的。
d. 连接的迁移
在以往的基于TCP的协议中,往往使用四元组(源IP,源端口,目的IP,目的端口)来标识一条连接,当四元组中的IP或端口任一个发生变化了连接就需要重新建立,从而不具备连接迁移的能力。
而QUIC使用了connection id对连接进行标识。即使网络从4G变成了wifi,只要两次连接中的connection id不变,并且客户端或者服务器能通过校验,就不需要重新建立连接,连接迁移就能成功。
这在移动端场景的优势极为明显,因为手机经常会在wifi和4g中切换,使用quic协议降低了重建连接的成本。
e. 协商的升级
在chorme浏览器中,发起一个TCP请求,这个请求会同时与服务器开始建立tcp 和 quic 的连接(前提是服务器支持),如果quic连接先建立成功,则使用quic建立的连接通信,反之,则使用tcp建立的连接进行通信。具体步骤如下:
  • 1、客户端发出tcp请求
  • 2、服务端如果支持quic可以通过响应头alt-svc告知客户端
  • 3、客户端同时发起tcp连接和quic连接竞赛
  • 4、一旦quic建立连接获胜则采用quic协议发送请求
  • 5、如遇网络或服务器不支持quic/udp,客户端标记quic为broken
  • 6、传输中的请求通过tcp重发
  • 7、5min后尝试重试quic,下一次尝试增大到10min
  • 8、一旦再次成功采用quic并把broken标记取消

其中,支持quic的alt-svc头部信息如下图示:

d. 其他特性:
  • 改进的拥塞控制
  • 丢包恢复
  • 底层的连接持久化
  • head stream 保证包顺序
  • 双级别流量控制

三、总结与思考

在web通信协议的演进中,SPDY是不可或缺的角色,在没有HTTP2的时代,它的出现极大的提升了网页加载速度,甚至HTTP2也是吸取了它很多的特性而制定的,是当之无愧的开拓者。而在有HTTP2的今天,quic协议的出现无异于对TCP的颠覆,它在底层抛弃了传统的TCP,而使用高效的UDP,并实现了TCP的特性,并且没有修改到应用层协议,我们可以无缝的基于原有的规范去开发。后,这两东西居然都是google提出并推行的。只能说google真的牛叉~
来源:https://segmentfault.com/a/1190000016265991

相关文章