即将尺度化的 HTTP/3 协议杂谈

HTTP/3 协议即将尺度化。作为一个老协议行使者，我想我该写一些观点了。

Google(pbuh) 公司拥有最风行的 web 赏识器(Chrome)和两个最风行的网站(#1 Google.com #2 Youtube.com)。因此谷歌可以节制 web 协议的成长。他们的第一次进级称之为 SPDY (发音"speedy"),这次更新最终成为 HTTP 协议第二版尺度，即 HTTP/2 。他们的第二次进级称之为 QUIC(发音"quick"),将成为 HTTP/3 协议尺度。

SPDY (HTTP/2)已经获得了主流web赏识器(Chrome、Firefox、Edge、Safari)和主流web处事器(Apache、Nginx、IIS、CloudFlare)的支持。很多最风行的网站都支持它(纵然长短google站点)，尽量您不太也许在网上看到它(行使Wireshark或tcpdump举办嗅探)，由于它老是行使SSL加密的。固然尺度应承HTTP/2在TCP上运行raw，可是全部实现都是SSL上行使它。

这里有一个关于尺度很好的一课。在互联网之外，尺度凡是是法令上的，由当局打点，由全部首要好处相干者在一个房间里接头，然后行使法则迫使人们回收它。在互联网上，人们起首实现对象，然后假如其他人喜好它，他们也会开始行使它。尺度凡是是究竟上的，rfc是为已经在互联网上运行精采的内容，记录人们已经在行使的内容。赏识器/处事器回收SPDY并不是由于它是尺度化的，而是由于首要的参加者只是简朴地开始添加它。同样的环境也产生在QUIC上:它被尺度化为HTTP/3的究竟是它已经被行使，而不是人们可以开始行使它的尺度化里程碑。

QUIC现实上更像是TCP (TCP/2???)的新版本，而不是HTTP (HTTP/3)的新版本。它并没有真正改变HTTP/2的成果，而是改变了传输的事变方法。因此，我下面的评述齐集在传输题目上，而不是HTTP题目。

首要的问题特征是更快的毗连配置和耽误。TCP要求在成立毗连之前去返发送大量数据包。SSL同样必要在成立加密之前去返发送大量数据包。假如收集延时很大，好比人们行使半秒ping时刻的卫星互联网，成立毗连必要相等长的时刻。通过镌汰来回，毗连可以更快地成立，这样当您单击链接时，链接的资源就会当即弹出

下一个首要特征是带宽。收集毗连的源和目标之间老是存在带脱期制，这险些老是因为拥塞。两边都必要行使这个速率，以便他们可以或许以恰当的速率发送数据包。假如发送数据包太快，那么它们就会被扬弃，这会在不进步传输速度的环境下给其他数据包造成更大的拥塞。发送数据包太慢意味着不能最优地行使收集。

HTTP 传统上这一点做得很糟糕。 行使单个 TCP 毗连不合用于 HTTP，由于与网站的交互必要同时传输多个内容，因此赏识器打开了与 Web 处事器的多个毗连(凡是为 6 个)。可是，这会冲破对带宽的预计，由于每个 TCP 毗连都实行独立完成，就像其他毗连不存在一样。SPDY 通过其多路复用成果办理了这个题目，该成果将赏识器/处事器之间的多个交互与单个带宽计较相团结。

QUIC 扩展了这种多路复用，使得处理赏罚赏识器/处事器之间的多个交互变得越发轻易，而没有任何一个交互阻止另一个交互，且具有配合带宽。 从用户的角度来看，这将使交互越发顺畅，同时镌汰路由器碰着的拥塞。

我们此刻来谈谈用户模式栈。 出格是在处事器上，TCP毗连由操纵体系内核处理赏罚，而处事自己在用户模式中运行。跨内核/用户模式界线移动会导致机能低落。追踪大量TCP毗连会导致扩展性题目。有些人实行将处事放入内核来停止转换，这并不行取，由于它粉碎了操纵体系的不变性。我的办理方案是用BlackICE IPS和masscan，，行使自界说TCP栈，操作硬件的用户模式驱动措施，将数据包从收集芯片直接传送到用户模式历程，绕过内核(拜见PoC || GTFO#15)。连年来，DPDK套件已经变得风行。

可是，从TCP迁徙到UDP可以在没有效户模式驱动措施的环境下得到沟通的机能。您可以挪用recvmmsg()一次吸取一堆UDP数据包，而不是挪用众所周知的recv()函数来一次吸取一个数据包。它如故是内核/用户模式转换，可是一次性收到的一百个数据包分摊，而不是每个数据包的转换。

在我本身的测试中，行使典范的recv()函数限定为约莫500,000 UDP数据包 /秒，但行使recvmmsg()和其他一些优化(行使RSS的多核)，可以在低端四查处事器上得到5,000,000 UDP数据包/秒。因为每个焦点的扩展性很好，因此迁徙到具有64个焦点的强盛处事器可以进一步进步。

BTW，“RSS”是收集硬件的一个特点，它将传入的数据包分成多个吸取行列。多核扩展性的最大题目是两个CPU焦点必要同时读取/修改统一个对象，因此共享沟通的UDP行列成为最大的瓶颈。因此，起首英特尔和其他以太网供给商添加了RSS，为每个焦点提供了本身的非共享数据包行列。 Linux和其他操纵体系进级UDP以支持单个套接字(SO_REUSEPORT)的多个文件描写符来处理赏罚多个行列。此刻，QUIC行使这些改造使得每个焦点打点本身的UDP数据包流，不会有与其他CPU焦点共享内容的导致可扩展性题目。之以是提到这一点，是由于在2000年，我亲身与英特尔硬件工程师接头过有多个数据包行列题目。这个题目很广泛，也有对应的办理方案，在HTTP / 3呈现之前，看看在已往二十年中的成长也是很故意思。假如没有收集硬件中的RSS，QUIC就不太也许成为尺度。

QUIC 的另一个美妙的办理方案是对移动的支持。当你带着你的条记本电脑到处移动到差异的 WIFI 收集时，可能带着你的手机到处移动时，你装备的 IP 地点会产生变革的。操纵体系以及协议不会优雅的封锁掉老的毗连而打开新的毗连。然而，QUIC，收集毗连的标识符并不是传统观念上的一个“socket”(源/方针 端口/地点 协议的绑定)，而是一个64位的赋值到毗连上的标识符。

这意味着当你移动时，纵然 IP 地点改变了，你依然可以或许和 YouTube 继承保持一个一连不中断的视频流，可能继承拨打一个视频电话而不被非常间断。收集工程师们已经和“移动IP”的技能题目攻关了几十年，试图想出一个有用的办理方案。他们专注于端到端原则，也就是在你移动时以某种方法保持一个恒定的 IP 地点，这不是一个现实的办理方案。很兴奋看到 QUIC / HTTP/3 最终办理了这个题目。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!