|
HTTP1.0、HTTP2.0、HTTP 3.0及HTTPS简要介绍 HTTP 建立之初,是为了将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。但随着CSS,Javascript的出现,以及移动互联时代的到来,我们不得不对HTTP进行不断地优化。 HTTP优化:
影响一个 HTTP 网络请求的因素主要有两个方面:带宽和延迟。
随着网络基础建设的完善,带宽因素已经不需要再考虑,仅需要考虑的就是延迟。延迟主要受三个方面影响:浏览器阻塞(HOL blocking), DNS查询(DNS Lookup),建立连接(Initial connection). 1 HTTP1.0及HTTPS(1)HTTP1.0- 请求与响应支持 HTTP 头,响应含状态行,增加了状态码,
- 支持 HEAD,POST 方法
- 支持传输 HTML 文件以外其他类型的内容
HTTP1.0 使用的是非持久连接,主要缺点是客户端必须为每一个待请求的对象建立并维护一个新的连接,即每请求一个文档就要有两倍RTT 的开销。因为同一个页面可能存在多个对象,所以非持久连接可能使一个页面的下载变得十分缓慢,而且这种 短连接增加了网络传输的负担。 注:
RTT(Round Trip Time):一个连接的往返时间,即数据发送时刻到接收到确认的时刻的差值; (2)HTTP1.1- 支持长连接。
- 在HTTP1.0的基础上引入了更多的缓存控制策略。
- 引入了请求范围设置,优化了带宽。
- 在错误通知管理中新增了错误状态响应码。
- 增加了Host头处理,可以传递主机名(hostname)。
缺点:
传输内容是明文,不够安全 (3)HTTPS- HTTPS运行在安全套接字协议(Secure Sockets Layer,SSL )或传输层安全协议(Transport Layer Security,TLS)之上,所有在TCP中传输的内容都需要经过加密。
- 连接方式不同,HTTP的端口是80,HTTPS的端口是443.
- HTTPS可以有效防止运营商劫持。
注:
SSL运行在TCP之上 (4)HTTP 1.x优化(SPDY)SPDY 并不是新的一种协议,而是在 HTTP 之前做了一层会话层。为了达到减少页面加载时间的目标,SPDY 引入了一个新的二进制分帧数据层,以实现优先次序、最小化及消除不必要的网络延迟,目的是更有效地利用底层 TCP 连接。 - 多路复用,为多路复用设立了请求优先级。
- 对header部分进行了压缩。
- 引入了HTTPS加密传输。
- 客户端可以在缓存中取到之前请求的内容。
参考博客:HTTP的前世今生 2 HTTP2.0(SPDY的升级版)- HTTP2.0支持明文传输,而HTTP 1.X强制使用SSL/TLS加密传输。
- 和HTTP 1.x使用的header压缩方法不同。
- HTTP2.0 基于二进制格式进行解析,而HTTP 1.x基于文本格式进行解析。
- 多路复用,HTTP1.1是多个请求串行化单线程处理,HTTP 2.0是并行执行,一个请求超时并不会影响其他请求。
HTTP2.0的多路复用提升了网页性能: - 在 HTTP1 中浏览器限制了同一个域名下的请求数量(Chrome下一般是六个),当在请求很多资源的时候,由于队头阻塞,当浏览器达到最大请求数量时,剩余的资源需等待当前的六个请求完成后才能发起请求。
- HTTP2 中引入了多路复用的技术,这个技术可以只通过一个 TCP连接就可以传输所有的请求数据。多路复用可以绕过浏览器限制同一个域名下的请求数量的问题,进而提高了网页的性能。
注意: - 主流浏览器只支持基于TLS部署的HTTP2.0协议,所以要将网站升级为HTTP 2.0,就需要先升级为HTTPS。
- HTTP 2.0完全兼容HTTP 1.x,所以对于部署了HTTP 2.0的网站可以自动向下兼容HTTP 1.X.
参考博客:HTTP1.0、HTTP1.1 和 HTTP2.0 的区别 3 HTTP 3.0 (QUIC)QUIC (Quick UDP Internet Connections), 快速 UDP 互联网连接。
QUIC是基于UDP协议的。 两个主要特性:
(1)线头阻塞(HOL)问题的解决更为彻底:
基于TCP的HTTP/2,尽管从逻辑上来说,不同的流之间相互独立,不会相互影响,但在实际传输方面,数据还是要一帧一帧的发送和接收,一旦某一个流的数据有丢包,则同样会阻塞在它之后传输的流数据传输。而基于UDP的QUIC协议则可以更为彻底地解决这样的问题,让不同的流之间真正的实现相互独立传输,互不干扰。
(2)切换网络时的连接保持:
当前移动端的应用环境,用户的网络可能会经常切换,比如从办公室或家里出门,WiFi断开,网络切换为3G或4G。基于TCP的协议,由于切换网络之后,IP会改变,因而之前的连接不可能继续保持。而基于UDP的QUIC协议,则可以内建与TCP中不同的连接标识方法,从而在网络完成切换之后,恢复之前与服务器的连接。
    .HTTP2.0和HTTP3.0科技永不止步。 我们都知道互联网中业务是不断迭代前进的,像HTTP这种重要的网络协议也是如此,新版本是对旧版本的扬弃。 2.1 HTTP2.0和TCP的爱恨纠葛HTTP2.0是2015年推出的,还是比较年轻的,其重要的二进制分帧协议、多路复用、头部压缩、服务端推送等重要优化使HTTP协议真正上了一个新台阶。 
像谷歌这种重要的公司并没有满足于此,而且想继续提升HTTP的性能,花最少的时间和资源获取极致体验。 那么肯定要问HTTP2.0虽然性能已经不错了,还有什么不足吗? 建立连接时间长(本质上是TCP的问题) 队头阻塞问题 移动互联网领域表现不佳(弱网环境) ......
熟悉HTTP2.0协议的同学应该知道,这些缺点基本都是由于TCP协议引起的,水能载舟亦能覆舟,其实TCP也很无辜呀! 
在我们眼里,TCP是面向连接、可靠的传输层协议,当前几乎所有重要的协议和应用都是基于TCP来实现的。 网络环境的改变速度很快,但是TCP协议相对缓慢,正是这种矛盾促使谷歌做出了一个看似出乎意料的决定-基于UDP来开发新一代HTTP协议。 2.2 谷歌为什么选择UDP上文提到,谷歌选择UDP是看似出乎意料的,仔细想一想其实很有道理。 我们单纯地看看TCP协议的不足和UDP的一些优点: 从上面的对比可以知道,谷歌要想从TCP上进行改造升级绝非易事,但是UDP虽然没有TCP为了保证可靠连接而引发的问题,但是UDP本身不可靠,又不能直接用。 
综合而知,谷歌决定在UDP基础上改造一个具备TCP协议优点的新协议也就顺理成章了,这个新协议就是QUIC协议。 2.3 QUIC协议和HTTP3.0QUIC其实是Quick UDP Internet Connections的缩写,直译为快速UDP互联网连接。 
我们来看看维基百科对于QUIC协议的一些介绍: QUIC协议最初由Google的Jim Roskind设计,实施并于2012年部署,在2013年随着实验的扩大而公开宣布,并向IETF进行了描述。
QUIC提高了当前正在使用TCP的面向连接的Web应用程序的性能。它在两个端点之间使用用户数据报协议(UDP)建立多个复用连接来实现此目的。
QUIC的次要目标包括减少连接和传输延迟,在每个方向进行带宽估计以避免拥塞。它还将拥塞控制算法移动到用户空间,而不是内核空间,此外使用前向纠错(FEC)进行扩展,以在出现错误时进一步提高性能。
HTTP3.0又称为HTTP Over QUIC,其弃用TCP协议,改为使用基于UDP协议的QUIC协议来实现。  3. QUIC协议详解择其善者而从之,其不善者而改之。 HTTP3.0既然选择了QUIC协议,也就意味着HTTP3.0基本继承了HTTP2.0的强大功能,并且进一步解决了HTTP2.0存在的一些问题,同时必然引入了新的问题。 
QUIC协议必须要实现HTTP2.0在TCP协议上的重要功能,同时解决遗留问题,我们来看看QUIC是如何实现的。 3.1 队头阻塞问题队头阻塞 Head-of-line blocking(缩写为HOL blocking)是计算机网络中是一种性能受限的现象,通俗来说就是:一个数据包影响了一堆数据包,它不来大家都走不了。 队头阻塞问题可能存在于HTTP层和TCP层,在HTTP1.x时两个层次都存在该问题。 
HTTP2.0协议的多路复用机制解决了HTTP层的队头阻塞问题,但是在TCP层仍然存在队头阻塞问题。 TCP协议在收到数据包之后,这部分数据可能是乱序到达的,但是TCP必须将所有数据收集排序整合后给上层使用,如果其中某个包丢失了,就必须等待重传,从而出现某个丢包数据阻塞整个连接的数据使用。 QUIC协议是基于UDP协议实现的,在一条链接上可以有多个流,流与流之间是互不影响的,当一个流出现丢包影响范围非常小,从而解决队头阻塞问题。 3.2 0RTT 建链衡量网络建链的常用指标是RTT Round-Trip Time,也就是数据包一来一回的时间消耗。 
RTT包括三部分:往返传播时延、网络设备内排队时延、应用程序数据处理时延。 
一般来说HTTPS协议要建立完整链接包括:TCP握手和TLS握手,总计需要至少2-3个RTT,普通的HTTP协议也需要至少1个RTT才可以完成握手。 然而,QUIC协议可以实现在第一个包就可以包含有效的应用数据,从而实现0RTT,但这也是有条件的。 
简单来说,基于TCP协议和TLS协议的HTTP2.0在真正发送数据包之前需要花费一些时间来完成握手和加密协商,完成之后才可以真正传输业务数据。 但是QUIC则第一个数据包就可以发业务数据,从而在连接延时有很大优势,可以节约数百毫秒的时间。 
QUIC的0RTT也是需要条件的,对于第一次交互的客户端和服务端0RTT也是做不到的,毕竟双方完全陌生。 因此,QUIC协议可以分为首次连接和非首次连接,两种情况进行讨论。 3.3 首次连接和非首次连接使用QUIC协议的客户端和服务端要使用1RTT进行密钥交换,使用的交换算法是DH(Diffie-Hellman)迪菲-赫尔曼算法。 DH算法开辟了密钥交换的新思路,在之前的文章中提到的RSA算法也是基于这种思想实现的,但是DH算法和RSA的密钥交换不完全一样,感兴趣的读者可以看看DH算法的数学原理。 DH算法开辟了密钥交换的新思路,在之前的文章中提到的RSA算法也是基于这种思想实现的,但是DH算法和RSA的密钥交换不完全一样,感兴趣的读者可以看看DH算法的数学原理。 3.3.1 首次连接 简单来说一下,首次连接时客户端和服务端的密钥协商和数据传输过程,其中涉及了DH算法的基本过程: 客户端对于首次连接的服务端先发送client hello请求。 服务端生成一个素数p和一个整数g,同时生成一个随机数 (笔误-此处应该是Ks_pri)为私钥,然后计算出公钥 = mod p,服务端将,p,g三个元素打包称为config,后续发送给客户端。 客户端随机生成一个自己的私钥,再从config中读取g和p,计算客户端公钥 = mod p。 客户端使用自己的私钥和服务端发来的config中读取的服务端公钥,生成后续数据加密用的密钥K = mod p。 客户端使用密钥K加密业务数据,并追加自己的公钥,都传递给服务端。 服务端根据自己的私钥和客户端公钥生成客户端加密用的密钥K = mod p。 为了保证数据安全,上述生成的密钥K只会生成使用1次,后续服务端会按照相同的规则生成一套全新的公钥和私钥,并使用这组公私钥生成新的密钥M。 服务端将新公钥和新密钥M加密的数据发给客户端,客户端根据新的服务端公钥和自己原来的私钥计算出本次的密钥M,进行解密。 之后的客户端和服务端数据交互都使用密钥M来完成,密钥K只使用1次。

3.3.2 非首次连接 前面提到客户端和服务端首次连接时服务端传递了config包,里面包含了服务端公钥和两个随机数,客户端会将config存储下来,后续再连接时可以直接使用,从而跳过这个1RTT,实现0RTT的业务数据交互。 客户端保存config是有时间期限的,在config失效之后仍然需要进行首次连接时的密钥交换。 3.4 前向安全问题前向安全是密码学领域的专业术语,看下百度上的解释: 前向安全或前向保密Forward Secrecy是密码学中通讯协议的安全属性,指的是长期使用的主密钥泄漏不会导致过去的会话密钥泄漏。
前向安全能够保护过去进行的通讯不受密码或密钥在未来暴露的威胁,如果系统具有前向安全性,就可以保证在主密钥泄露时历史通讯的安全,即使系统遭到主动攻击也是如此。
通俗来说,前向安全指的是密钥泄漏也不会让之前加密的数据被泄漏,影响的只有当前,对之前的数据无影响。 前面提到QUIC协议首次连接时先后生成了两个加密密钥,由于config被客户端存储了,如果期间服务端私钥泄漏,那么可以根据K = mod p计算出密钥K。 如果一直使用这个密钥进行加解密,那么就可以用K解密所有历史消息,因此后续又生成了新密钥,使用其进行加解密,当时完成交互时则销毁,从而实现了前向安全。  3.5 前向纠错前向纠错是通信领域的术语,看下百科的解释: 前向纠错也叫前向纠错码Forward Error Correction 简称FEC 是增加数据通讯可信度的方法,在单向通讯信道中,一旦错误被发现,其接收器将无权再请求传输。
FEC 是利用数据进行传输冗余信息的方法,当传输中出现错误,将允许接收器再建数据。
听这段描述就是做校验的,看看QUIC协议是如何实现的: QUIC每发送一组数据就对这组数据进行异或运算,并将结果作为一个FEC包发送出去,接收方收到这一组数据后根据数据包和FEC包即可进行校验和纠错。 3.6 连接迁移网络切换几乎无时无刻不在发生。 TCP协议使用五元组来表示一条唯一的连接,当我们从4G环境切换到wifi环境时,手机的IP地址就会发生变化,这时必须创建新的TCP连接才能继续传输数据。 QUIC协议基于UDP实现摒弃了五元组的概念,使用64位的随机数作为连接的ID,并使用该ID表示连接。 基于QUIC协议之下,我们在日常wifi和4G切换时,或者不同基站之间切换都不会重连,从而提高业务层的体验。  4. QUIC的应用和前景通过前面的一些介绍我们看出来QUIC协议虽然是基于UDP来实现的,但是它将TCP的重要功能都进行了实现和优化,否则使用者是不会买账的。 QUIC协议的核心思想是将TCP协议在内核实现的诸如可靠传输、流量控制、拥塞控制等功能转移到用户态来实现,同时在加密传输方向的尝试也推动了TLS1.3的发展。 但是TCP协议的势力过于强大,很多网络设备甚至对于UDP数据包做了很多不友好的策略,进行拦截从而导致成功连接率下降。 主导者谷歌在自家产品做了很多尝试,国内腾讯公司也做了很多关于QUIC协议的尝试。 其中腾讯云对QUIC协议表现了很大的兴趣,并做了一些优化然后在一些重点产品中对连接迁移、QUIC成功率、弱网环境耗时等进行了实验,给出了来自生产环境的诸多宝贵数据。 简单看一组腾讯云在移动互联网场景下的不同丢包率下的请求耗时分布: 

|