作者：James Snell

翻译：疯狂的技术宅

https://www.nearform.com/blog...

在2019年3月，受到 NearForm 和 Protocol Labs 的反对，我开始为 Node.js 实现 QUIC 协定 反对。这个基于 UDP 的新传输协定旨在最终代替所有应用 TCP 的 HTTP 通信。

相熟 UDP 的人可能会产生质疑。家喻户晓 UDP 是不牢靠的，数据包常常会有失落、乱序、反复等状况。 UDP 不保障高级协定（例如 HTTP）严格要求的 TCP 所反对的可靠性和程序。那就是 QUIC 进来的中央。

QUIC 协定在 UDP 之上定义了一层，该层为 UDP 引入了错误处理、可靠性、流控制和内置安全性（通过 TLS 1.3）。实际上它在 UDP 之上从新实现了大多数 TCP 的特效，然而有一个要害的区别：与 TCP 不同，依然能够不按程序传输数据包。理解这一点对于了解 QUIC 为什么优于 TCP 至关重要。

QUIC 打消了队首阻塞的本源

在 HTTP 1 中，客户端和服务器之间所替换的所有音讯都是间断的、不间断的数据块模式。尽管能够通过单个 TCP 连贯发送多个申请或响应，然而在发送下一条残缺音讯之前，必须先等上一条音讯残缺的传输结束。这意味着，如果要发送一个 10 兆字节的文件，而后发送一个 2 兆字节的文件，则前者必须齐全传输结束，而后能力启动后者。这就是所谓的队首阻塞，是造成大量提早和不良应用网络带宽的本源。

HTTP 2 尝试通过引入多路复用来解决此问题。 HTTP 2 不是将申请和响应作为间断的流传输，而是将申请和响应分成了被称为帧的离散块，这些块能够与其余帧交错。一个 TCP 连贯实践上能够解决有限数量的并发申请和响应流。只管从实践上讲这是可行的，然而 HTTP 2 的设计没有思考 TCP 层呈现队首阻塞的可能性。

TCP 自身是严格排序的协定。数据包被序列化并依照固定程序通过网络发送。如果数据包未能达到其目的地，则会阻止整个数据包流，直到能够从新传输失落的数据包为止。无效的程序是：发送数据包1，期待确认，发送数据包2，期待确认，发送数据包3……。应用 HTTP 1，在任何给定工夫只能传输一个 HTTP 音讯，如果单个 TCP 数据包失落，那么重传只会影响单个 HTTP 申请/响应流。然而应用 HTTP 2，则会在失落单个 TCP 数据包的状况下阻止有限数量的并发 HTTP 申请/响应流的传输。在通过高提早、低可靠性网络进行 HTTP 2 通信时，与 HTTP 1 相比，整体性能和网络吞吐量会急剧下降。

在 HTTP 1 中，该申请会被阻塞，因为一次只能发送一条残缺的音讯。

在 HTTP 2 中，当单个 TCP 数据包失落或损坏时，该申请将被阻塞。

在QUIC中，数据包彼此独立，可能以任何程序发送（或从新发送）。

侥幸的是有了 QUIC 状况就不同了。当数据流被打包到离散的 UDP 数据包中传输时，任何单个数据包都可能以任意程序发送（或从新发送），而不会影响到其余已发送的数据包。换句话说，线路阻塞问题在很大水平上失去解决。

QUIC 引入了灵活性、安全性和低提早

QUIC 还引入了许多其余重要性能：

  • QUIC 连贯的运行独立于网络拓扑构造。在建设了 QUIC 连贯后，源 IP 地址和指标 IP 地址和端口都能够更改，而无需从新建设连贯。这对于常常进行网络切换（例如 LTE 到 WiFi）的挪动设施特地有用。
  • 默认 QUIC 连贯是平安的并加密的。 TLS 1.3 反对间接蕴含在协定中，并且所有 QUIC 通信都通过加密。
  • QUIC 为 UDP 增加了要害的流控制和错误处理，并包含重要的平安机制以避免一系列拒绝服务攻打。
  • QUIC 增加了对零行程 HTTP 申请的反对，这与基于 TCP 的 TLS 之上的 HTTP 不同，后者要求客户端和服务器之间进行屡次数据交换来建设 TLS 会话，而后能力传输 HTTP 申请数据，QUIC 容许 HTTP 申请头作为 TLS 握手的一部分发送，从而大大减少了新连贯的初始提早。

为 Node.js 内核实现 QUIC

为 Node.js 内核实现 QUIC 的工作从 2019 年 3 月开始，并由 NearForm 和 Protocol Labs 独特资助。咱们利用杰出的 ngtcp2 库来提供大量的低层实现。因为 QUIC 是许多 TCP 个性的从新实现，所以对 Node.js 意义重大，并且与 Node.js 中以后的 TCP 和 HTTP 相比可能反对更多个性。同时对用户暗藏了大量的复杂性。

“quic” 模块

在实现新的 QUIC 反对的同时，咱们用了新的顶级内置 quic 模块来公开 API。当该性能在 Node.js 外围中落地时，是否仍将应用这个顶级模块，将在当前确定。不过当在开发中应用实验性反对时，你能够通过 require('quic') 应用这个 API。

const { createSocket } = require('quic')

quic 模块公开了一个导出：createSocket 函数。这个函数用来创立 QuicSocket 对象实例，该对象可用于 QUIC 服务器和客户端。

QUIC 的所有工作都在一个独自的 GitHub 存储库 中进行，该库 fork 于 Node.js master 分支并与之并行开发。如果你想应用新模块，或者奉献本人的代码，能够从那里获取源代码，请参阅 Node.js 构建阐明。不过它当初依然是一项尚在进行中的工作，你肯定会遇到 bug 的。

创立QUIC服务器

QUIC 服务器是一个 QuicSocket 实例，被配置为期待近程客户端启动新的 QUIC 连贯。这是通过绑定到本地 UDP 端口并期待从对等方接管初始 QUIC 数据包来实现的。在收到 QUIC 数据包后，QuicSocket 将会查看是否存在可能用于解决该数据包的服务器 QuicSession 对象，如果不存在将会创立一个新的对象。一旦服务器的 QuicSession 对象可用，则该数据包将被解决，并调用用户提供的回调。这里有一点很重要，解决 QUIC 协定的所有细节都由 Node.js 在其外部解决。

const { createSocket } = require('quic')const { readFileSync } = require('fs')const key = readFileSync('./key.pem')const cert = readFileSync('./cert.pem')const ca = readFileSync('./ca.pem')const requestCert = trueconst alpn = 'echo'const server = createSocket({  // 绑定到本地 UDP 5678 端口  endpoint: { port: 5678 },  // 为新的 QuicServer Session 实例创立默认配置  server: {    key,    cert,    ca,    requestCert    alpn   }})server.listen()server.on('ready', () => {  console.log(`QUIC server is listening on ${server.address.port}`)})server.on('session', (session) => {  session.on('stream', (stream) => {    // Echo server!    stream.pipe(stream)   })  const stream = session.openStream()  stream.end('hello from the server')})

如前所述，QUIC 协定内置并要求反对 TLS 1.3。这意味着每个 QUIC 连贯必须有与其关联的 TLS 密钥和证书。与传统的基于 TCP 的 TLS 连贯相比，QUIC 的独特之处在于 QUIC 中的 TLS 上下文与 QuicSession 相关联，而不是 QuicSocket。如果你相熟 Node.js 中 TLSSocket 的用法，那么你肯定留神到这里的区别。

QuicSocket（和 QuicSession）的另一个要害区别是，与 Node.js 公开的现有 net.Socket 和 tls.TLSSocket 对象不同，QuicSocket 和 QuicSession 都不是 Readable 或 Writable的流。即不能用一个对象间接向连贯的对等方发送数据或从其接收数据，所以必须应用 QuicStream 对象。

在下面的例子中创立了一个 QuicSocket 并将其绑定到本地 UDP 的 5678 端口。而后通知这个 QuicSocket 侦听要启动的新 QUIC 连贯。一旦 QuicSocket 开始侦听，将会收回 ready 事件。

当启动新的 QUIC 连贯并创立了对应服务器的 QuicSession 对象后，将会收回 session 事件。创立的 QuicSession 对象可用于侦听新的客户端服务器端所启动的 QuicStream 实例。

QUIC 协定的更重要特色之一是客户端能够在不关上初始流的状况下启动与服务器的新连贯，并且服务器能够在不期待来自客户端的初始流的状况下先启动其本人的流。这个性能提供了许多十分乏味的玩法，而这在以后 Node.js 内核中的 HTTP 1 和 HTTP 2 是不可能提供的。

创立QUIC客户端

QUIC 客户端和服务器之间简直没有什么区别：

const { createSocket } = require('quic')const fs = require('fs')const key = readFileSync('./key.pem')const cert = readFileSync('./cert.pem')const ca = readFileSync('./ca.pem')const requestCert = trueconst alpn = 'echo'const servername = 'localhost'const socket = createSocket({  endpoint: { port: 8765 },  client: {    key,    cert,    ca,    requestCert    alpn,    servername  }})const req = socket.connect({  address: 'localhost',  port: 5678,})req.on('stream', (stream) => {  stream.on('data', (chunk) => { /.../ })  stream.on('end', () => { /.../ })})req.on('secure', () => {  const stream = req.openStream()  const file = fs.createReadStream(__filename)  file.pipe(stream)  stream.on('data', (chunk) => { /.../ })  stream.on('end', () => { /.../ })  stream.on('close', () => {    // Graceful shutdown    socket.close()  })  stream.on('error', (err) => { /.../ })})

对于服务器和客户端，createSocket() 函数用于创立绑定到本地 UDP 端口的 QuicSocket 实例。对于 QUIC 客户端来说，仅在应用客户端身份验证时才须要提供 TLS 密钥和证书。

在 QuicSocket 上调用 connect() 办法将新创建一个客户端 QuicSession 对象，并与对应地址和端口的服务器创立新的 QUIC 连贯。启动连贯后进行 TLS 1.3 握手。握手实现后，客户端 QuicSession 对象会收回 secure 事件，表明当初能够应用了。

与服务器端相似，一旦创立了客户端 QuicSession 对象，就能够用 stream 事件监听服务器启动的新 QuicStream 实例，并能够调用 openStream() 办法来启动新的流。

单向流和双向流

所有的 QuicStream 实例都是双工流对象，这意味着它们都实现了 Readable 和 Writable 流 Node.js API。然而，在 QUIC 中，每个流都能够是双向的，也能够是单向的。

双向流在两个方向上都是可读写的，而不论该流是由客户端还是由服务器启动的。单向流只能在一个方向上读写。客户端发动的单向流只能由客户端写入，并且只能由服务器读取；客户端上不会收回任何数据事件。服务器发动的单向流只能由服务器写入，并且只能由客户端读取；服务器上不会收回任何数据事件。

// 创立双向流const stream = req.openStream()// 创立单向流const stream = req.openStream({ halfOpen: true })

每当近程对等方启动流时，无论是服务器还是客户端的 QuicSession 对象都会收回提供 QuicStream 对象的 stream 事件。能够用来查看这个对象确定其起源（客户端或服务器）及其方向（单向或双向）

session.on('stream', (stream) => {  if (stream.clientInitiated)    console.log('client initiated stream')  if (stream.serverInitiated)    console.log('server initiated stream')  if (stream.bidirectional)    console.log('bidirectional stream')  if (stream.unidirectional)    console.log(‘’unidirectional stream')})

由本地发动的单向 QuicStream 的 Readable 端在创立 QuicStream 对象时总会立刻敞开，所以永远不会收回数据事件。同样，近程发动的单向 QuicStream 的 Writable 端将在创立后立刻敞开，因而对 write() 的调用也会始终失败。

就是这样

从下面的例子能够分明地看出，从用户的角度来看，创立和应用 QUIC 是绝对简略的。只管协定自身很简单，但这种复杂性简直不会回升到面向用户的 API。实现中蕴含一些高级性能和配置选项，这些性能和配置项在下面的例子中没有阐明，在通常状况下，它们在很大水平上是可选的。

在示例中没有对 HTTP 3 的反对进行阐明。在根本 QUIC 协定实现的根底上实现 HTTP 3 语义的工作正在进行中，并将在当前的文章中介绍。

QUIC 协定的实现还远远没有实现。在撰写本文时，IETF 工作组仍在迭代 QUIC 标准，咱们在 Node.js 中用于实现大多数 QUIC 的第三方依赖也在一直倒退，并且咱们的实现还远未实现，短少测试、基准、文档和案例。然而作为 Node.js v14 中的一项实验性新性能，这项工作正在逐渐着手进行。心愿 QUIC 和 HTTP 3 反对在 Node.js v15 中可能失去齐全反对。咱们心愿你的帮忙！如果你有趣味参加，请分割 https://www.nearform.com/cont... ！

鸣谢

在完结本文时，我要感激 NearForm 和 Protocol Labs 在财政上提供的资助，使我可能全身心投入于对 QUIC 的实现。两家公司都对 QUIC 和 HTTP 3 将如何倒退对等和传统 Web 利用开发特地感兴趣。一旦实现靠近实现，我将会再写一文章来论述 QUIC 协定的一些微妙的用例，以及应用 QUIC 与 HTTP 1、HTTP 2、WebSockets 以及其余办法相比的劣势。

James Snell（ @jasnell）是 NearForm Research 的负责人，该团队致力于钻研和开发 Node.js 在性能和安全性方面的次要新性能，以及物联网和机器学习的提高。 James 在软件行业领有 20 多年的教训，并且是 Node.js 社区中的出名人物。他曾是多个 W3C 语义 web 和 IETF 互联网规范的作者、合著者、撰稿人和编辑。他是 Node.js 我的项目的外围贡献者，是 Node.js 技术领导委员会（TSC）的成员，并曾作为 TSC 代表在 Node.js Foundation 董事会任职。

本文首发微信公众号：前端先锋

欢送扫描二维码关注公众号，每天都给你推送陈腐的前端技术文章

欢送持续浏览本专栏其它高赞文章：

  • 深刻了解Shadow DOM v1
  • 一步步教你用 WebVR 实现虚拟现实游戏
  • 13个帮你进步开发效率的古代CSS框架
  • 疾速上手BootstrapVue
  • JavaScript引擎是如何工作的？从调用栈到Promise你须要晓得的所有
  • WebSocket实战：在 Node 和 React 之间进行实时通信
  • 对于 Git 的 20 个面试题
  • 深刻解析 Node.js 的 console.log
  • Node.js 到底是什么？
  • 30分钟用Node.js构建一个API服务器
  • Javascript的对象拷贝
  • 程序员30岁前月薪达不到30K，该何去何从
  • 14个最好的 JavaScript 数据可视化库
  • 8 个给前端的顶级 VS Code 扩大插件
  • Node.js 多线程齐全指南
  • 把HTML转成PDF的4个计划及实现
  • 更多文章...