HTTP3(HTTP Over QUIC)和Websocket-ACM技术组周会

Posted Henrik-Yao

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了HTTP3(HTTP Over QUIC)和Websocket-ACM技术组周会相关的知识,希望对你有一定的参考价值。

出自neuq-acm技术部后端组(yh,wyx,wtl)

一.HTTP 3.0

1.概述

当IETF正式标准化HTTP/2时,Google正在独立构建一个新的传输协议,名为gQUIC。它后来成为新互联网草案,并被命名为QUIC。gQUIC最初的实验证明,在网络条件较差的情况下,gQUIC在增强网页浏览体验方面的效果非常好。因此,gQUIC的发展势头越来越好,IETF的大多数成员赞成建立一个在QUIC上运行的HTTP新规范。这个新的倡议被称为HTTP/3,以区别于当前的HTTP/2标准。

HTTP3.0的优化

  • HTTP/2中存在的队头阻塞问题。由于HTTP/2在单个TCP连接上使用了多路复用,受到TCP拥塞控制的影响,少量的丢包就可能导致整个TCP连接上的所有流被阻塞。(多路数据流)

  • 切换网络时的连接保持的问题基于TCP的协议。由于切换网络之后,IP会改变,因而之前的连接不可能继续保持。而基于UDP的QUIC协议,则可以内建与TCP中不同的连接标识方法,从而在网络完成切换之后,恢复之前与服务器的连接。(传输可靠性)


连接方式

首次连接
	首次连接时客户端和服务端的密钥协商和数据传输过程,其中涉及了DH算法的基本过程:
	1、客户端对于首次连接的服务端先发送client hello请求。
	2、服务端生成一个素数p和一个整数g,同时生成一个Ks_pri为私钥,	然后计算出公钥 = mod p,服务端将,p,g三个元素打包称config,后续发送给客户端。
	3、客户端随机生成一个自己的私钥,再从config中读取g和p,计算客户端公钥 = mod p。
	4、客户端使用自己的私钥和服务端发来的config中读取的服务端公钥,生成后续数据加密用的密钥K = mod p。
	5、客户端使用密钥K加密业务数据,并追加自己的公钥,都传递给服务端。
	6、服务端根据自己的私钥和客户端公钥生成客户端加密用的密钥K = mod p。
	7、为了保证数据安全,上述生成的密钥K只会生成使用1次,后续服务端会按照相同的规则生成一套全新的公钥和私钥,并使用这组公私钥生成新的密钥M8、服务端将新公钥和新密钥M加密的数据发给客户端,客户端根据新的服务端公钥和自己原来的私钥计算出本次的密钥M,进行解密。
之后的客户端和服务端数据交互都使用密钥M来完成,密钥K只使用1次。

后续连接
	前面提到客户端和服务端首次连接时服务端传递了config包,里面包含了服务端公钥和两个随机数,客户端会将config存储下来,后续再连接时可以直接使用,从而跳过这个1RTT,实现0RTT的业务数据交互。
    客户端保存config是有时间期限的,在config失效之后仍然需要进行首次连接时的密钥交换。

2.功能

  • 实现了类似TCP的流量控制、传输可靠性的功能

  • 集成了TLS(Transport Layer Security 传输层安全性协议)加密功能

  • 实现了HTTP/2.0中多路复用,其页面的加载时间为2.5 RTT时间

    不同点是QUIC实现了在同一物理连接上可以有多个独立的逻辑数据流,实现了数据流的单独传输,解决了TCP中队头阻塞问题

  • 实现了快速握手功能

    QUIC是基于UDP的,所以QUIC可以实现使用0-RTT和1-RTT来建立连接。具体来说:完成QUIC交易的连接的Session ID会缓存在浏览器内存里,如果用户再次打开该页面,无需建立TLS连接,直接使用缓存Session ID 对应的加密参数,服务器可以根据Session ID在缓存里查找对应的加密参数,并完成加密。

3.特性

QUIC 放弃了 TCP,而是使用其兄弟协议 UDP(用户数据报协议)。UDP 是 TCP 的“对立面”;它是不可靠的(从一端发送的数据可能永远不会被另一端收到,而另一端无法知道有什么东西丢失了),并且它是无序的(后发送的数据可以超过前发送的数据,到达乱七八糟)。然而,UDP 非常简单,新协议通常建立在 UDP 之上。

QUIC 恢复了 TCP 的可靠性和顺序,但没有引入相同数量的往返和延迟。例如,如果客户端重新连接到服务器,客户端可以在第一个数据包中发送重要的加密数据,使服务器能够使用与先前协商的相同加密来恢复旧连接,而无需任何额外的往返。

二.WebSocket

1.概述

  • WebSocket协议是基于TCP的一种新的html5网络协议,它实现了浏览器与服务器全双工通信–允许服务器主动发送信息给客户端

  • 握手主要需要借助HTTP/1.1 协议的101状态码进行请求完成

  • 而WebSocket是一种持久协议,http是非持久协议

  • WebSocket通信协议于2011年被IETF(国际互联网工程任务组)定为标准RFC 6455

  • WebSocket API被W3C定为标准

现在很多网站都有实时推送的需求,比如聊天,客服咨询等

2.开发背景

  • HTTP协议是一种无状态、无连接的、单向的应用层协议。它采用请求/相应模型。通信请求只能由客户端发起,服务器对请求做出应答处理。

  • 如果需要实现服务器主动向客户端发起消息,HTTP协议的弊端就显现出来了。

  • 早期没有WebSocket时,通过频繁的异步ajax请求实现长轮询,由于http请求,服务器无法给浏览器主动发送数据,因此需要浏览器定时的给服务器发送请求(比如1s一次),服务器把最新的数据相应给浏览器。这种模式的缺点在于浪费性能和资源,效率十分低。(因为需要不停连接或HTTP连接始终打开)

  • 目的:取代轮询和长连接,使客户端浏览器具备像C/S框架下桌面系统的即时通讯能力

3.HTTP协议与WebSocket协议的图解对比

纵向分析

HTTP协议:定时的发送请求给服务器

WebSocket协议:主要发送请求给服务器

横向分析

4.WebSocket协议规范

WebSocket 使得客户端和服务器之间的数据交换变得更加简单,允许服务端主动向客户端推送数据。在 WebSocket API 中,浏览器和服务器只需要完成一次握手,两者之间就直接可以创建持久性的连接,并进行双向数据传输

请求头信息

ws是WebSocket的表示

GET ws://localhost/chat HTTP/1.1 
Host: server.example.com 
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 
Origin: http://example.com 
Sec-WebSocket-Protocol: chat, superchat 
Sec-WebSocket-Version: 13

返回头信息

101状态码表示服务器响应客户端升级协议的请求对协议进行切换

HTTP/1.1 101 
Switching Protocols 
Upgrade: websocket 
Connection: Upgrade 
Sec-WebSocket-Accept:s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 
Sec-WebSocket-Protocol: chat

5.WebSocket的优点

  • 较少的控制开销。在连接创建后,服务器和客户端之间交换数据时,用于协议控制的数据包头部相对较小。在不包含扩展的情况下,对于服务器到客户端的内容,此头部大小只有2至10字节(和数据包长度有关);对于客户端到服务器的内容,此头部还需要加上额外的4字节的掩码。相对于HTTP请求每次都要携带完整的头部,此项开销显著减少了。

  • 更强的实时性。由于协议是全双工的,所以服务器可以随时主动给客户端下发数据。相对于HTTP请求需要等待客户端发起请求服务端才能响应,延迟明显更少;即使是和Comet等类似的长轮询比较,其也能在短时间内更多次地传递数据。

  • 保持连接状态。与HTTP不同的是,Websocket需要先创建连接,这就使得其成为一种有状态的协议,之后通信时可以省略部分状态信息。而HTTP请求可能需要在每个请求都携带状态信息(如身份认证等)。

  • 更好的二进制支持。Websocket定义了二进制帧,相对HTTP,可以更轻松地处理二进制内容。

  • 可以支持扩展。Websocket定义了扩展,用户可以扩展协议、实现部分自定义的子协议。如部分浏览器支持压缩等。

  • 更好的压缩效果。相对于HTTP压缩,Websocket在适当的扩展支持下,可以沿用之前内容的上下文,在传递类似的数据时,可以显著地提高压缩率。

以上是关于HTTP3(HTTP Over QUIC)和Websocket-ACM技术组周会的主要内容,如果未能解决你的问题,请参考以下文章

地推HTTP3和QUIC

地推HTTP3和QUIC

QUIC/HTTP3 协议简析

QUIC/HTTP3 协议简析

QUIC/HTTP3 协议简析

HTTP2还没用上,HTTP3就出来了