导语 | 如今通过网络进行实时音视频通话已经越来越流行，对于音视频领域的技术要求也越来越高，许多网络技术应运而生，如WebRTC，QUIC，HTTP3，WebTransport，WebAssembly，WebCodecs等。想必很多人有疑问，这些技术为什么会产生？有哪些发展历史？这些问题在本文都能找到参考。
QUIC简析
1. 什么是QUICQUIC(Quick UDP Internet Connections)是一种新的“更快”的通用网络传输协议。相比于TCP和TLS，QUIC提供了许多改进来提升网络传输的性能。随着QUIC协议的标准化，QUIC之上的HTTP/3协议已经被众多浏览器所支持，其中包括Chrome、Microsoft Edge(Chrome内核版本)、Firefox和Safari，除了浏览器，也有不少客户端App也开始支持和使用HTTP/3
2. QUIC协议发展
QUIC协议的相关草案在2016年7月被提出，历经接近40个版本，到2021年5月正式成文RFC9000（QUIC: A UDP-Based Multiplexed and Secure Transport | https://www.rfc-editor.org/rfc/rfc9000.html）
3. QUIC的特性
用户态构建：QUIC是在用户层构建的，所以不需要每次协议升级时进行内核修改。同时由于用户态可构建，QUIC的开源项目十分之多（具体可参见QUIC 开源实现列表 - 知乎 | https://zhuanlan.zhihu.com/p/270628018）。
流复用和流控：QUIC引入了连接上的多路流复用的概念。QUIC通过设计实现了单独的、针对每个流的流控，解决了整个连接的队头阻塞问题。
灵活的拥塞控制机制：TCP的拥塞控制机制是刚性的。该协议每次检测到拥塞时，都会将拥塞窗口大小减少一半。相比之下，QUIC的拥塞控制设计得更加灵活，可以更有效地利用可用的网络带宽，从而获得更好的吞吐量。
链接迁移：当客户端IP或端口发生变化时（这在移动端比较常见），TCP连接基于两端的ip:port四元组标示，因此会重新握手，而UDP不面向连接，不用握手。其上层的QUIC链路由于使用了64位Connection id作为唯一标识，四元组变化不影响链路的标示，也不用重新握手。
更好的错误处理能力：QUIC使用增强的丢失恢复机制和转发纠错功能，以更好地处理错误数据包。该功能对于那些只能通过缓慢的无线网络访问互联网的用户来说是一个福音，因为这些网络用户在传输过程中经常出现高错误率。
更快的握手：QUIC使用相同的TLS模块进行安全连接。然而，与TCP不同的是，QUIC的握手机制经过优化，避免了每次两个已知的对等者之间建立通信时的冗余协议交换，甚至可以做到0RTT握手。
更灵活的传输方式：QUIC具有重传功能，可以提供可靠传输（stream），又因为基于UDP，也可提供非可靠传输（datagram）
HTTP简析
1. HTTP的发展历史
2. HTTP各版本特性
2.1 HTTP/1.0
短连接：每次发送请求都要重新建立tcp请求，即三次握手，性能较差；无host头：也就是http请求头里的host；
传输策略：不允许断点续传，而且不能只传输对象的一部分，要求传输整个对象。
2.2 HTTP/1.1
更多的缓存策略：http1.0中主要使用header里的If-Modified-Since, Expires来作为判断缓存的标准，http1.1则引入更多的缓存策略，如Entity tag, If-Unmodified-Since, If-Match, If-None-Match等；在请求头引入range头域：允许只请求资源的某部分，即返回码为206（Partial Content），这样就方便了开发者自由选择以便充分利用带宽和连接；host头处理：在http1.0中每台服务器绑定一个ip地址，但随着虚拟主机技术的发展，在一台服务器上可以存在多个虚拟主机，并且共享同一个ip地址。http1.1的请求和响应消息都应支持host头域，且请求头信息中如果没有host头域会报404 Bad Request；
长连接支持：http1.1支持长连接和请求的流水线处理，在一个tcp连接上可以传输多个http请求（串行）和响应，减少了建立和关闭连接的消耗和延迟，在http1.1中默认开启Connection: keep alive，一定程度上弥补了http1.0每次请求都要创建连接的缺点。
2.3 HTTP/2.0
新的二进制格式(Binary Format)：HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮；多路复用(MultiPlexing)：即连接共享，一个连接上可以有多个request，一个request对应一个id，每个连接的request可以随机的混杂在一起，接收方可以根据request的id将request再归属到各自不同的服务端请求里面；header压缩：HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小；
服务端推送(server push)：同SPDY(Google开发的基于TCP的会话层协议，对HTTP的增强)一样，HTTP2.0也具有server push功能。
2.4 HTTP/3.0
基于QUIC协议：天然复用QUIC的各种优势；
新的HTTP头压缩机制：QPACK，是对HTTP/2中使用的HPACK的增强。在QPACK下，HTTP头可以在不同的QUIC流中不按顺序到达。
3. HTTP3协议发展
2016年7月被提出，截止到2021年2月，共有34个版本，目前仍是草案状态。
WebTransport简析
前面我们知道了QUIC和HTTP3，下面来谈一谈浏览器的一个重磅级特性——WebTransport。
1. 什么是WebTransport
WebTransport 是一个协议框架，该协议使客户端与远程服务器在安全模型下通信，并且采用安全多路复用传输技术。最新版的WebTransport草案中，该协议是基于HTTP3的，即WebTransport可天然复用QUIC和HTTP3的特性。
2. WebTransport协议发展
2019年5月被提出，截止到到2021年10月，共7个版本，较为年轻，是一个潜力巨大的协议。谷歌浏览器M97版本已支持draft-ietf-webtrans-http3-02草案，读者可以通过谷歌官方给出的WebTransport server demo来测试（https://github.com/GoogleChrome/samples/tree/gh-pages/webtransport）。
3. 为什么用WebTransport
首先我们看一下当今互联网的网络堆栈，其囊括了全网99%的流量
下面来考虑几个场景：云游戏：在这些游戏中，指令会从客户端发送到基于云的服务器，其中有些指令对时间属性十分敏感；低延迟实时直播：Web端直播基于http-flv/hls，典型的场景包括体育赛事、新闻和娱乐竞猜节目的一对多单向直播流，我们希望视频画面能够支持高清、高帧率、高动态范围、低延迟和卡顿、宽色域以及DRM（数字版权管理），但现实是其中很多都无法实现；远程桌面管理：这是一个企业使用场景，有用户使用物联网传感器和数据分析传输，我们能够使用小型功耗敏感物联网设备，非常有效地向云端发送少量的数据；自定义RTC传输：WebRTC作为浏览器的一个标准， 在浏览器中我们无法控制WebRTC的内部工作机制，然而某些场景下需要进行定制化的RTC传输；
WebOBS：OBS是直播推流与视频录制常用的工具，随着我们有了WebCodecs的直接编码能力，如果有一个有力的Web端推流能力的协议，Web端OBS产品条件就已经成熟。
从上述场景我们可以提取出几个核心需求：我们希望继承现代Web的安全保护技术，换句话说，我们需要TLS（安全传输层协议）加密；我们想要某种类型的拥塞控制；我们仍想要客户端-服务器体系结构，我们不希望它建立在p2p的模型上，因为p2p连接体系结构会话的启动难度不小；我们在大多数应用程序中也想使用双向通信，我们需要发送可靠和有序的数据，我们将这种数据称为“流”。流遵循先进先出的模式，因此在此过程中不会丢失任何内容；我们还希望以最小的延迟来实现流，但同时我们还需要发送非可靠和无序的数据报文，这和UDP报文非常相似，它们都是小数据包，关键在于传输的速度，如果速度太慢，其中一些数据可能会丢失，但只要我们能够实现高速传输，就能解决这个问题；我们还需要持续地给发送端提供反馈，我们不能漫无目的地发射接收无法处理的数据。并且它们应该使用URI进行资源定位，因为Web中的URI和URL是我们定位Internet内容的核心中枢，所以我们不想改变这种机制，我们想要一些符合URI机制的东西；
我们想要进行定制化的RTC传输，自己可以自定义传输协议，有更多自由发挥的空间。
当今Web技术能否满足？
WebTransport基于HTTP3实现，是一个非常理想的传输协议，可以很好地满足上述场景需求
4. 编程样例
使用如下的web端简单编程样例即可和支持WebTransport的后台服务进行通信。更多的用法可以查看W3C的文档：https://www.w3.org/TR/webtransport/
let transport = new WebTransport("https://x.x.x.x");await transport.ready;let stream = await transport.createBidirectionalStream();let encoder = new TextEncoder();let writer = stream.writable.getWriter();await writer.write(encoder.encode("Hello, world! What's your name?"))writer.close();console.log(await new Response(stream.readable).text());未来展望
1. WebTransport Gateway
我们团队在WebTransport上作出了许多努力，研发的WebTransport Gateway可以支持接入用户转发的可靠和非可靠信息，将其转发给后台服务，同样也可以回送给用户。
借助WebTransport底层的HTTP3和QUIC，我们可以对WebTransport Gateway进行特定场景（例如音视频）的深度优化，举个很简单的例子来说，可以区分不同帧的优先级来进行传输，优化用户体验。
2. RTC engine
WebTransport WebCodecs WebAssembly 可以让我们自定义一套RTC引擎，WebTransport的传输能力，WebCodecs的编解码能力，WebAssembly的高效执行能力，对于有深厚积累的音视频团队，完全可以进行更高效的定制化开发，在Web端定义自己的RTC协议栈。
参考文献
[1][RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport](https://www.rfc-editor.org/rfc/rfc9000.html)[2][WebTransport over HTTP/3](https://www.ietf.org/archive/id/draft-ietf-webtrans-http3-02.html)[3][Hypertext Transfer Protocol Version 3 (HTTP/3)](https://www.ietf.org/archive/id/draft-ietf-quic-http-34.html)
[4][一文看懂WebTransport]https://zhuanlan.zhihu.com/p/359781074
腾讯云音视频在音视频领域已有超过21年的技术积累，持续支持国内90%的音视频客户实现云上创新，独家具备 RT-ONE™ 全球网络，在此基础上，构建了业界最完整的 PaaS 产品家族，并通过腾讯云视立方 RT-Cube™ 提供All in One 的终端SDK，助力客户一键获取众多腾讯云音视频能力。腾讯云音视频为全真互联时代，提供坚实的数字化助力。
