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

╰+攻爆jí腚メ 2021-09-08 08:20 531阅读 0赞

> 出自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标准。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70]

**HTTP3.0的优化**

*  HTTP/2中存在的队头阻塞问题。由于HTTP/2在单个TCP连接上使用了多路复用，受到TCP拥塞控制的影响，少量的丢包就可能导致整个TCP连接上的所有流被阻塞。(多路数据流)
 *  切换网络时的连接保持的问题基于TCP的协议。由于切换网络之后，IP会改变，因而之前的连接不可能继续保持。而基于UDP的QUIC协议，则可以内建与TCP中不同的连接标识方法，从而在网络完成切换之后，恢复之前与服务器的连接。(传输可靠性)

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 1]  
**连接方式**

首次连接
    	首次连接时客户端和服务端的密钥协商和数据传输过程，其中涉及了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失效之后仍然需要进行首次连接时的密钥交换。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 2]

## 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在缓存里查找对应的加密参数，并完成加密。
    
    ![在这里插入图片描述][20210613151551651.gif]

## 3.特性 ##

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

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 3]

# 二.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框架下桌面系统的即时通讯能力

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 4]

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

### 纵向分析 ###

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 5][]

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 6]

### 横向分析 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 7]

## 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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 8]

## 5.WebSocket的优点 ##

*  较少的控制开销。在连接创建后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小。在不包含扩展的情况下，对于服务器到客户端的内容，此头部大小只有2至10字节（和数据包长度有关）；对于客户端到服务器的内容，此头部还需要加上额外的4字节的掩码。相对于HTTP请求每次都要携带完整的头部，此项开销显著减少了。
 *  更强的实时性。由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。相对于HTTP请求需要等待客户端发起请求服务端才能响应，延迟明显更少；即使是和Comet等类似的长轮询比较，其也能在短时间内更多次地传递数据。
 *  保持连接状态。与HTTP不同的是，Websocket需要先创建连接，这就使得其成为一种有状态的协议，之后通信时可以省略部分状态信息。而HTTP请求可能需要在每个请求都携带状态信息（如身份认证等）。
 *  更好的二进制支持。Websocket定义了二进制帧，相对HTTP，可以更轻松地处理二进制内容。
 *  可以支持扩展。Websocket定义了扩展，用户可以扩展协议、实现部分自定义的子协议。如部分浏览器支持压缩等。
 *  更好的压缩效果。相对于HTTP压缩，Websocket在适当的扩展支持下，可以沿用之前内容的上下文，在传递类似的数据时，可以显著地提高压缩率。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70]: /images/20210827/ce310fd803e64c398371b064fd77127a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 1]: /images/20210827/fe87d2aef3294fdfacb8e3dd38928e1b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 2]: /images/20210827/48ffc7ab46974903bfecc3e1de85091a.png
[20210613151551651.gif]: /images/20210827/50c7dc94e7384f70baadf1d4457e40dd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 3]: /images/20210827/46fc8ee0775c433a8d97576f3ac69a80.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 4]: /images/20210827/d0e76a3a30d5450d9a487100494abfb3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 5]: /images/20210827/91d4a67f927547eb8a62cfd9b495d21d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 6]: /images/20210827/b18d574797f3484297bb6427aefbd061.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 7]: /images/20210827/569dbe9fd6c54534962d603782f304cd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzUwMjE2Mjcw_size_16_color_FFFFFF_t_70 8]: /images/20210827/6e64b4c81e29465baa338a20fa7b5b39.png