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

Posted 2021-06-27 Henrik-Yao

出自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次，后续服务端会按照相同的规则生成一套全新的公钥和私钥，并使用这组公私钥生成新的密钥M。
	8、服务端将新公钥和新密钥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在适当的扩展支持下，可以沿用之前内容的上下文，在传递类似的数据时，可以显著地提高压缩率。