作者都是各自领域经过审查的专家,并撰写他们有经验的主题. 我们所有的内容都经过同行评审,并由同一领域的Toptal专家验证.
HTTP/3即将到来, 紧随HTTP / 2之后,它本身也很年轻. 考虑到从HTTP / 1到现在用了16年.1到HTTP / 2,如果有人真的关心HTTP/3?
简短的回答是:是的,这很重要,你应该跟上它的速度. 这就像HTTP / 2对HTTP / 1的重大改变一样.1通过从ASCII切换到二进制. HTTP/3再次做了重大改变, 这一次是通过将底层传输从TCP切换到UDP.
虽然HTTP/3仍处于设计阶段,官方规范只是草案, 它已经被部署了,很有可能今天您的网络上就运行着它的一个版本.
但是HTTP/3的工作方式带来了一些新的难题. 还有,好处是什么? 网络工程师、系统管理员和开发人员需要知道什么?
网站和应用开发者通常都希望自己的作品能被使用. 有时用户基础是有限的,但通常只是为了获得尽可能多的用户. 当然,一个网站越受欢迎,它的收入就越多.
网站加载时间延迟100毫秒会使转化率降低7%.
Akamai在线零售业绩报告:毫秒至关重要(2017)
换句话说, 销售额为40美元的电子商务网站,由于这种延误,每年将损失100万美元.
众所周知,网站的性能对网站变得更受欢迎至关重要. 网上购物研究 继续查找链接 之间的 增加弹跳率和更长的加载时间,以及 顾客忠诚度和网站在购物体验中的表现.
研究 我还发现:
这就是网上购物者的耐心状态 十多年前. 所以性能是至关重要的,HTTP / 2和HTTP/3都意味着更好的网站性能.
理解HTTP / 2协议对于理解HTTP/3至关重要. 首先,为什么需要HTTP / 2?
HTTP / 2最初是一个名为SPDY的谷歌项目, 一项研究报告了web上最大的性能问题是 延迟. 作者的结论是“更多的带宽并不重要”:
如果我们在管道和互联网之间做一个类比,我们可以考虑 带宽 互联网的直径就像水管的直径. 水管越大,水量越大, 因此你可以在两点之间输送更多的水.
同时, 不管你的烟斗有多大, 如果管道是空的, 你想让水从一点流到另一点, 水通过管道需要时间. 用网络用语来说, 水从管道的一端流到另一端再流回来所花费的时间叫做时间 往返时间, or RTT.
迈克·贝尔奇
在这项研究中,减少页面加载时间是目标. 研究表明,最初增加带宽是有帮助的, 从1mbps到2mbps可以减少一半的页面加载时间. 然而,收益很快就会趋于稳定.
相比之下,减少延迟具有恒定的好处并获得最佳结果.
HTTP / 1协议中延迟的主要原因是 head-of-line阻塞 问题. 网页(几乎总是)需要多种资源:CSS、JavaScript、字体、图像、AJAX/XMR等. 这意味着web浏览器需要向服务器发出多个请求. 然而,并不是所有的资源都是页面有用所必需的.
与HTTP / 1.浏览器必须完全完成一个请求, 包括完全接收响应, 在开始下一个请求之前. 一切都必须按顺序进行. 每个请求都会阻塞请求行,因此得名.
试图补偿HOL阻塞问题, 网络浏览器对单个服务器进行多个同时连接. 但是他们不得不随意限制这种行为:服务器, 工作站, 而且网络会因为连接过多而变得超负荷.
HTTP / 1.我介绍了一些改进来帮助解决这个问题. 最主要的是 流水线, 允许web浏览器启动新的请求,而不需要等待之前的请求完成. 这显著改善了低延迟环境中的加载时间.
但它仍然要求所有响应按照发出的顺序依次到达, 所以队伍的头仍然被挡住了. 令人惊讶的是,许多服务器仍然没有利用这个特性.
有趣的是,HTTP / 1.我也介绍过 维生, 它允许浏览器避免为每个HTTP请求创建新的TCP连接的开销. 这是解决tcp派生的性能问题的早期尝试. 它是如此无效,以至于大多数性能专家实际上都不赞成它,因为它会因为太多的非活动连接而使服务器陷入困境. 下面我们将仔细研究TCP,以及HTTP / 2是如何解决这个问题的.
HTTP / 2了 请求-响应多路复用 通过单个连接. 浏览器不仅可以在任何时候启动一个新的请求,而且 响应可以以任何顺序接收-阻塞在应用程序级别完全消除.
直接的结果是,这意味着精通HTTP / 2的web服务器可以最大限度地提高效率——稍后会详细介绍.
虽然请求-响应多路复用是HTTP / 2的主要特性, 它还包括其他几个重要特性. 读者可能会注意到它们在某种程度上是相关的.
HTTP / 2将HTTP协议标准从低效的人类可读的ASCII请求-响应模型切换到高效 二元结构. 它不再只是一个请求和一个回应:
与HTTP / 2, 浏览器通过带有多个消息的双向流与服务器通信, 每个由多个帧组成.
HTTP / 2的新 头压缩使用HPACK格式,为大多数站点节省了大量带宽. 这是因为在连接中发送的请求的大多数头是相同的.
Cloudflare报告了显著的带宽节省 多亏了HPACK:
当然,使用更少的带宽通常意味着更快的网站.
这就是HTTP / 2的多路复用真正允许服务器最大化效率的地方. 多路复用确实有助于提供更快的资源.g.(如内存缓存的JavaScript),然后才是较慢的(如JavaScript).g.、大图像、数据库生成的JSON等.). 但它也允许通过HTTP / 2的额外性能提升 流的优先级.
流优先级有助于确保页面几乎准备就绪的方面完全完成,而不必等待其他资源密集型请求完成. 这是通过加权依赖树实现的. 此树用于通知服务器应该为哪些响应分配最多的系统资源.
这对……尤其重要 渐进式web应用程序(pwa). 例如,假设一个页面有四个JavaScript文件. 两个用于页面功能,两个用于广告. 最糟糕的情况是加载一半的功能JS和一半的广告JS,然后继续加载大图, 在加载任何其他JS之前. 在这种情况下, 页面上的任何内容最初都不起作用, 因为所有东西都要等待最慢的资源.
使用流优先级, web浏览器可以指示服务器在发送任何广告JavaScript文件之前发送两个页面功能JS文件. 这样,用户就不必等到广告完全加载后才使用页面的功能. 尽管总体加载时间没有改善, 感知性能显著提高. 不幸的是, web浏览器中的这种行为主要还是算法的问题, 而不是被指定的 web开发人员.
同样,HTTP / 2的 服务器推送 特性允许服务器向浏览器发送尚未发出的请求的响应! 服务器可以利用传输中的间隙, 通过将服务器知道它将很快请求的资源预加载到浏览器中,有效地利用带宽. 这里的部分希望是消除资源内联的做法, 这只会使资源膨胀,使它们需要更长的加载时间.
不幸的是, 这两个功能都需要web开发人员仔细配置才能真正成功. 简单地启用它们 是不够的.
HTTP / 2显然带来了许多潜在的优势——其中一些优势比其他优势更便宜. 他们在现实世界中表现如何?
SPDY成立于2009年. HTTP / 2于2015年标准化. SPDY成为该代码的一个不稳定开发分支的名称, HTTP / 2将成为最终版本. 结果是SPDY已经过时了, 而HTTP / 2通常是每个人都遵循的标准.
标准化后, HTTP / 2(或“h2”)的采用率迅速增长到前1名的40%左右,000个网站. 这主要是由大型托管和云提供商代表他们的客户部署支持所驱动的. 不幸的是, 几年后, HTTP / 2的采用已经放缓,大部分互联网仍在使用HTTP / 1.
有很多人要求HTTP / 2将加密作为标准的必要部分. 相反,该标准定义了加密(h2)和明文(h2c)模式. 因此,HTTP / 2可以完全取代HTTP / 1.
尽管标准, 目前所有的浏览器都只支持HTTP / 2加密连接,并有意不实现明文模式. 相反,浏览器依赖HTTP / 1向后兼容模式来访问不安全的服务器. 这是一种将网络默认为安全的意识形态推动的直接结果.
现在HTTP / 2修复了HTTP的行头阻塞问题, 协议开发人员已经将注意力转向了下一个最大的延迟驱动因素: TCP 排队头阻塞问题.
IP(因特网协议)网络是基于计算机相互发送数据包的思想. 数据包只是一些附加在顶部的寻址信息的数据.
但应用程序通常需要处理 流 的数据. 为了实现 这个错觉,传输控制协议(TCP)提供了应用 管 数据流可以通过它流动. 和大多数管道一样, 可以保证数据以进入管道的顺序退出管道, 也被称为“先入”, 先进先出法. 这些特性使得TCP非常有用并被广泛采用.
作为TCP提供的数据传递保证的一部分, 它必须能够处理各种各样的情况. 最复杂的问题之一是如何在网络过载时传递所有数据, 不会让大家的情况变得更糟. 这个算法叫做 拥塞控制 并且是Internet规范中不断发展的一部分. 没有足够的 拥塞控制,互联网就会陷入停顿.
1986年10月,互联网出现了一系列“拥塞崩溃”中的第一次.在此期间, 从LBL到加州大学伯克利分校(两地相距400码,三个IMP跳)的数据吞吐量从32 Kbps下降到40 bps.
V. 雅各布森(1988)
这就是TCP线首阻塞问题的由来.
TCP拥塞控制通过实现 倒扣 和 重传 数据包机制,在检测到数据包丢失时使用. 退让的目的是帮助安抚网络. 重传确保数据最终被传递.
这意味着TCP数据可能会乱序到达目的地, 接收方有责任在将数据包重新组装到流中之前对其重新排序. 不幸的是, 这意味着一个丢失的数据包会导致整个TCP流暂停,而服务器等待它的重传. 因此,线的头部被阻塞.
谷歌的另一个项目旨在解决这个问题 引入一种叫做QUIC的协议.
QUIC协议是建立在UDP而不是TCP之上的,QUIC正在形成HTTP/3的基础.
用户数据报协议(UDP)是TCP的替代方案. 它不提供流的假象,也不提供TCP提供的相同保证. 而不是, 它只是提供了一种将数据放入数据包的简单方法, 把它发给另一台计算机, 然后发送出去. 它是 不可靠的, 无序,并且 不 配备任何形式的拥塞控制.
它的目的是轻量级的,并提供允许通信所需的最小功能. 这样应用程序就可以实现自己的保证. 这在实时应用程序中通常非常有用. 例如, 在电话中, 用户通常希望立即收到90%的数据, 而不是最终100%的数据.
解决TCP HOL阻塞问题需要的不仅仅是切换到UDP, 因为仍然有必要保证所有数据的传输,避免网络拥塞崩溃. QUIC协议旨在通过提供优化的HTTP over udp类型体验来实现所有这些.
由于QUIC接管了流管理、二进制帧等控制.在QUIC之上运行时,HTTP / 2要做的事情已经不多了. 这是QUIC + HTTP的新组合被标准化为HTTP/3的部分驱动因素.
注意:QUIC有很多版本, 因为该协议已经在生产环境中开发和部署了多年. 甚至还有一个谷歌专用的版本,叫做GQUIC. 像这样, 区分旧的QUIC协议和新的HTTP/3标准是很重要的.
HTTP/3包含大量借用TLS的加密,但没有直接使用它. HTTP/3的主要实现挑战之一是需要修改TLS/SSL库以添加新需要的功能.
这种变化是因为HTTP/3在加密内容方面与HTTPS不同. 使用旧的HTTPS协议, 只有数据本身受TLS保护, 留下大量可见的传输元数据. 在HTTP/3中,数据和传输协议都受到保护. 这听起来像是一种安全功能,确实如此. 但这样做是为了避免HTTP / 2中存在的大量开销. 因此, 加密传输协议和数据实际上使协议更高效.
HTTP/3并非没有争议. 主要关注的是网络基础设施.
在客户端,UDP流量受到严重速率限制和/或阻塞是很常见的. 将这些限制应用于HTTP/3违背了协议的意义.
其次,HTTP被监视和/或拦截是很常见的. 即使是HTTPS流量, 网络定期观察协议的明文传输元素,以确定是否应该断开连接,以防止从特定网络或特定区域访问某些网站. 在一些国家,法律甚至规定某些服务提供商必须这样做. HTTP/3中的强制加密使得这是不可能的.
这不仅仅是政府层面的过滤. 许多大学, 公共图书馆, 学校, 而忧心忡忡的父母会主动选择屏蔽某些网站,或者至少记录下孩子访问过的网站. HTTP/3中的强制加密使得这是不可能的.
值得注意的是,有限过滤 is 目前可能. 这是因为服务器名称指示(SNI)字段携带网站的主机名,但不携带路径, 查询参数, 等.-仍未加密. 但随着ESNI(加密SNI)的引入,这种情况将在不久的将来发生变化。, 是最近加入TLS标准的吗.
在服务器端, 最好的做法是阻止任何不需要流量的端口和协议, 这意味着服务器管理员现在需要为HTTP/3打开UDP 443, 而不是依赖于现有的TCP 443规则.
其次,网络基础设施可以建立TCP会话 黏糊糊的这意味着即使路由优先级发生变化,它们也将始终被路由到同一台服务器. 由于HTTP/3在udp(无会话)上运行,网络基础设施需要更新以跟踪HTTP/3特定的连接id, 它们没有被加密,是为了帮助粘接路由吗.
第三,对HTTP进行检查以检测滥用和监控是很常见的 常见的安全问题,检测和防止恶意软件和病毒的传播等. 由于HTTP/3的加密,这是不可能的. 仍然, 拦截设备拥有安全密钥副本的选项仍然是可能的, 假设设备实现HTTP/3支持.
最后, 很多管理员都反对管理更多的SSL证书, 不过现在的服务,比如 让我们加密 是可用的.
直到有广泛的接受, 解决这些问题的知名解决方案, 我认为很多大型网络可能会直接阻止HTTP/3.
在这方面没什么好担心的. HTTP / 2的流优先级和服务器推送功能仍然存在于HTTP/3中. 对于web开发人员来说,这是值得的 熟悉这些特性 如果他们真的想优化他们的网站性能.
谷歌Chrome浏览器的用户,或者开源的用户 铬 浏览器,已经设置为使用HTTP/3. 离生产质量的HTTP/3服务器版本还有一段路要走该规范 写这篇文章的时候还没有最终确定. 但与此同时,还有很多工具可供使用, 谷歌和Cloudflare都已经将支持推向了他们的生产环境.
最简单的方法是使用 球童 in 码头工人. 为此需要SSL证书,因此可公开访问的IP地址使事情变得容易. 步骤如下:
yourhostname.例子.com IN A 192.0.2.1
. yourhostname.例子.com
日志stdout
错误stdout
ext .html .htm .md .文本文件。
浏览
gzip
tls youremailaddress@例子.com
docker运行-v cadyfile:/等/ cadyfile -p 80:80 -p 43:443 abiosoft/caddy——quic
—or 外的码头工人, 球童——quic
.铬——enable-quic
开发人员还可以使用以下有用的工具测试他们的服务器:
感谢阅读!
HTTP / 2侧重于有效的带宽使用,以优化交付web内容所需的时间. 请求和响应在单个连接上进行多路复用,以实现最大吞吐量, 客户机和服务器都不必花费不必要的时间等待对方.
HTTP是一组使内容在全球可用的规则. 由HTTP创建的系统被称为万维网,或者通常简称为网络. 使用HTTP, web浏览器能够从web服务器检索内容. 现在,服务器也经常使用它来与其他服务器交换内容.
HTTP / 2通过引入使用更少带宽和加速数据传输的新特性来改进旧的HTTP版本. 这些协议在特性方面的主要区别在于性能. 在技术设计方面, 协议之间几乎没有相似之处,只是共享原始的抽象概念.
超文本传输协议(HTTP)允许通过网络在全球范围内发布内容. 尽管还有许多其他重要的用途, 正是这种全球覆盖和通用目的使HTTP成为一种通用的流行工具.
在统一资源定位符(URL)中, 方案是冒号之前的一部分,它允许读者知道如何解释URL的其余部分. 对于网址,这是HTTP或HTTPS. HTTPS是HTTP协议标准的安全加密变体.
TCP用于在internet上的两台设备之间建立双向先进先出(FIFO)流. 通过这个流,任何数据都可以可靠地传递. 像这样, TCP是许多其他协议的构建块, 包括web (HTTP), HTTPS, 和HTTP / 2)和电子邮件(SMTP, 流行, 和IMAP).
TCP, 通常称为TCP/IP, 是否存在一种抽象机制,允许Internet上的设备以可靠的方式相互通信, 尽管大多数互联网基础设施非常不可靠且无状态. TCP通过实现有状态会话和拥塞控制来工作.
HTTP / 2使用TCP来确保有一个可靠的连接. 在TCP, 接收方处理丢失数据的重传副本,方法是对接收到的数据重新排序,并且在释放先前的数据之后只释放最新的数据. 这种等待阻塞了队列的头部,从而降低了性能.
HTTP/3是HTTP的最新版本. 虽然尚未正式发布,但HTTP/3已经被广泛部署. HTTP的早期版本发布于2015年(HTTP / 2), 1999年(HTTP / 1).1), 1997 (http /1.1989 (HTTP/0 . 0).9).
世界级的文章,每周发一次.
世界级的文章,每周发一次.