HTTP2vs。HTTP3前世今生！

　　大家好，很高兴又见面了，我是高级前端进阶，由我带着大家一起关注前端前沿、深入前端底层技术，大家一起进步，也欢迎大家关注、点赞、收藏、转发！
　　高级前端进阶前言
　　HTTP（超文本传输协议）是万维网所基于的应用层传输协议。最初在80年代后期构思为基于单行文本的协议，最初记录为HTTP0。9，其第一个全功能迭代（v。1。0）于1996年在RFC1945中记录。
　　随着互联网的使用和期望的增长，改进HTTP本身的需求也在增长。1。1版在1997年的RFC2068和1999年的RFC2616中记录，随后在2014年的RFC（72307235）中记录了整整十年半之后！记录消息语法路由；语义内容；条件和范围请求；缓存；和认证。
　　当前的HTTP版本是HTTP2。它基于Google的SPDY项目，是该协议的第一次大修，于2015年在RFC7540中标准化，同年RFC7541引入了HeaderCompression（HPACK）。
　　在HTTP2推出仅仅四年之后，一个基于Google实验性QUIC协议的新标准开始出现：HTTP3。其目的：提高用户与网站和API交互的速度和安全性。
　　2020年10月，在进入RFC阶段之前，描述HTTP3（和QUIC）的文档进入了InternetDraft阶段的IETFLastCall阶段。然而，一旦HTTP3最终确定为标准，HTTP2是否还有一席之地？本文描述并比较了协议的两个版本，并就每个版本在哪里找到合适的应用程序提供了一些建议。
　　HTTP协议栈转换与比较
　　HTTP协议栈比较从HTTP1。1到HTTP3的变化HTTP2的背景
　　创建HTTP2是为了解决HTTP1。1的非结构化演进过程中出现的许多问题，其中大部分与性能相关。
　　许多问题是由于HTTP1。1的固有限制而出现的，归结为响应时间随着流量的增加而增加：HTTP线头阻塞（HTTPHoL）当一系列数据包被阻塞前方动脉的慢大数据包阻塞时，HTTPHoL会导致响应时间增加。协议开销服务器和客户端交换额外的请求和响应元数据，重复传输标头和cookie会增加响应速度并减慢响应速度。TCP慢启动作为拥塞控制措施，协议反复探测网络以找出可用容量；在设法达到满负荷之前，多次小额转移可能会导致滞后。
　　开发人员试图通过域分片、流水线和使用无cookie域等变通方法来解决这些问题和限制，但这些通常会导致兼容性和互操作性问题。显然，老化的HTTP1。1标准需要更新。
　　2009年，Google宣布了SPDY，一个实验性协议，作为解决HTTP1。x问题的结构化方法。HTTP工作组注意到Google在使用SPDY实现更高的性能目标方面取得的成功。2012年11月，发起了对HTTP2的提案征集，并以SPDY规范为起点。
　　在接下来的几年里，HTTP2和SPDY与SPDY作为实验分支共同发展。HTTP2作为国际标准于2015年5月作为RFC7540发布。对HTTP3的需求
　　多年来，HTTP不断发展，从0。9版5年，1。0版一年，到1。1版大约15年，最终在2014年到达第2版。在每次迭代中，都添加了新功能解决多种需求的协议，例如应用层要求、安全考虑、会话处理和媒体类型。如需深入了解HTTP2及其从HTTP1。0的演变，请阅读我们的HTTP演变HTTP2深入探讨中的HTTP不起眼的起源部分。
　　在这个演变过程中，HTTP的底层传输机制大体上保持不变。然而，随着公众对移动设备技术的大量采用，互联网流量激增，新开箱的HTTP2一直在努力提供流畅、透明的Web浏览体验。它承受着现代互联网流量的数量和速度，尤其是在实时应用程序及其用户不断增长的需求下。这导致在使用此版本的协议时出现许多警告，从而暴露出明显的改进机会。多路复用、负载峰值和请求优先级
　　曾几何时，实时白板图表公司Lucidchart在其负载均衡器（LB）上启用HTTP2后遇到了一个意想不到的问题。
　　长话短说：他们注意到这些LB后面的服务器上的CPU负载更高，响应时间更慢。HTTP2吹捧提高了带宽效率、减少了延迟和请求优先级，因此没有加起来。但是什么？乍一看，流量看起来很正常，并且没有代码更改可以归咎于奇怪的行为。但是，虽然请求的平均数量是正常的，但流本身包含许多同时请求的高峰值。以前的供应模型未能考虑到这种情况，结果是对请求的响应超时或延迟。
　　实际原因是，只要用户的浏览器使用HTTP1。1，由于HTTP1。1的串行请求处理性质，这有效地限制了并发请求的数量，使流量保持有序并在可预测的范围内。开启HTTP2可能会出现不可预知的峰值，因为它具有多路复用功能，即使用单个连接发送并发请求。批处理请求对客户端来说非常有用，但是同时请求的开始时间和数量让Lucidchart的服务器非常头疼。
　　最后，能够在LucidChart的服务器上使用HTTP2需要实施非平凡的解决方案，例如限制平衡器和重新构建应用程序。HTTP2软件的成熟度和对HTTP优先级的服务器支持的缺乏是额外的问题。一些应用程序仅通过安全套接字（HTTPS）支持HTTP2对于安全的内部网络来说，这是一种不必要且繁重的架构复杂性。服务器推送变得复杂
　　如果不小心使用，HTTP2推送功能弊大于利。例如，回访者可能有文件的缓存副本，在这种情况下，服务器不应该推送资源。使推送缓存感知可以解决这个问题，但这有它自己的警告，并且很快就会变得复杂。那个讨厌的线阻塞头
　　HTTP2解决了HTTP级别的线头阻塞问题，它允许资源在同一连接上被多路复用、同时分解成块。但是，由于数据包丢失并且必须重新以正确的顺序重新发送，TCP级别的线路阻塞仍然可能发生。HTTP2与HTTP3有何不同？
　　HTTP3的目标是通过解决HTTP2的传输相关问题，在所有形式的设备上提供快速、可靠和安全的Web连接。为此，它使用了一种名为QUIC的不同传输层网络协议，该协议最初由Google开发。
　　HTTP2和HTTP3的根本区别在于HTTP3在QUIC上运行，而QUIC在无连接UDP上运行，而不是面向连接的TCP（所有以前版本的HTTP都使用）。
　　QUIC中使用的面向连接的TCP与无连接UDP的比较
　　在语法和语义结构方面，HTTP3与HTTP2类似。HTTP3参与相同类型的请求响应消息交换，其数据格式包含方法、标头、状态代码和正文。但是，HTTP3引入的一个显着差异在于UDP之上协议层的堆叠顺序，如下图所示。
　　HTTP3中的堆叠顺序显示QUIC包含安全层和部分传输层
　　下表比较了HTTP2和HTTP3的特性和功能：
　　HTTP2和HTTP3Part12特性和能力对比表
　　HTTP2和HTTP3Part22特性和能力对比表HTTP2概述
　　HTTP2是HTTP1。1的扩展，而不是替代它。应用程序语义保持不变，具有相同的HTTP方法、状态代码、URI和标头字段。
　　每个HTTP2连接都以HTTP1。1开始，如果客户端支持HTTP2，则连接会升级。HTTP2在客户端和服务器之间使用单个TCP连接，该连接在交互期间保持打开状态。
　　客户端和服务器之间通过TCP（HTTP2底层传输协议）的请求和响应。
　　HTTP2引入了许多旨在提高性能的特性：创建交错通信流的二进制帧层。完全多路复用而不是强制排序并因此阻塞（这意味着它可以使用一个连接进行并行）。标头压缩以减少开销。从服务器主动推送响应到客户端缓存。
　　HTTP2：优点和缺点优点通过安装SSL证书，所有浏览器都支持基于HTTPS的HTTP2协议。HTTP2允许客户端通过单个TCP连接同时发送所有请求。理论上，客户端应该更快地接收资源。TCP是一种可靠、稳定的连接协议。缺点并发请求会增加服务器的负载。HTTP2服务器可以大批量接收请求，这会导致请求超时。服务器负载峰值问题可以通过插入负载均衡器或代理服务器来解决，这可以限制请求。服务器对HTTP2优先级的支持还不成熟。软件支持仍在不断发展。某些CDN或负载均衡器可能无法正确支持优先级。HTTP2推送功能可能很难正确实现。HTTP2解决了HTTP行头阻塞，但TCP级别的阻塞仍然会导致问题。HTTP2适合哪些用例？
　　HTTP2支持HTTP1。x的所有用例，无论它是在浏览器中实现的什么地方，包括桌面Web浏览器、移动Web浏览器、WebAPI和Web服务器。但是，它也可以用于代理服务器、反向代理服务器、防火墙和内容分发网络，以及以下情况：对于响应时间不重要的应用程序。对于时间关键型应用程序，例如实时消息传递或流应用程序，只有在使用合适的自适应技术（例如WebSockets、服务器发送事件（SSE）、发布订阅（pubsub）消息传递）的情况下。需要可靠连接的地方（TCP的优势）使用受限的物联网设备。HTTP3概述
　　HTTP3支持快速、可靠和安全的连接。它默认使用Google的QUIC协议加密Internet传输。
　　HTTP3：优点和缺点优点引入在UDP上运行的新（不同）传输协议QUIC意味着在理论上和目前实验上都减少了延迟。因为UDP不在协议栈中执行错误检查和纠正，所以它适用于不需要或在应用程序中执行这些的用例。这意味着UDP避免了任何相关的开销。UDP通常用于对时间敏感的应用程序，例如实时系统，这些应用程序不能等待数据包重传，因此可以容忍一些丢弃的数据包缺点传输层分支。过渡到HTTP3不仅涉及应用层的变化，还涉及底层传输层的变化。因此，与其前身相比，采用HTTP3更具挑战性。可靠性问题。UDP应用程序往往缺乏可靠性，因此必须接受一定程度的数据包丢失、重新排序、错误或重复。由最终用户应用程序提供任何必要的握手，例如实时确认消息已被接收。HTTP3尚未标准化。HTTP3适合哪些用例？实时应用程序，例如在线游戏、广告竞价和IP语音，以及使用实时流协议的地方。广播信息如多种服务发现和共享信息如精确时间协议和路由信息协议。这是因为UDP支持多播。物联网。HTTP3可以解决物联网用例（例如从连接的传感器收集数据的移动设备）的无线连接丢失问题。大数据。随着HTTP3变得足够强大，托管的API服务将能够进行流式传输，然后随着数据转换为商业智能而货币化。基于网络的虚拟现实。VR应用程序需要更多带宽来渲染虚拟场景的复杂细节，并且肯定会从迁移到由QUIC提供支持的HTTP3中受益。微服务：更快（或没有）握手意味着更快地遍历微服务网格。HTTP3入门：HTTP3的开源解决方案
　　IETF的HTTP工作组仍在致力于发布HTTP3。所以它还没有被NGINX和Apache等Web服务器正式支持。但是，有几个软件库可用于试验此新协议，并且还提供非官方补丁。
　　以下是支持HTTP3和QUIC传输的软件库列表。请注意，这些实现基于互联网草案标准版本之一，该版本可能会被更高版本所取代，最终标准在RFC中发布。quiche（https：github。comcloudflarequiche）：quiche提供了一个低级编程接口，用于通过QUIC协议发送和接收数据包。它还支持HTTP3模块，用于通过其QUIC协议实现发送HTTP数据包。它还为NGINX服务器提供了一个非官方补丁，用于安装和托管能够运行HTTP3的Web服务器。除此之外，还有其他包装器可用于在Android和iOS移动应用程序上支持HTTP3。Aioquic（https：github。comaiortcaioquic）：Aioquic是QUIC的Python实现。它还支持HTTP3的内置测试服务器和客户端库。Aioquic建立在asyncio模块之上，这是Python的标准异步IO框架。Neqo（https：github。commozillaneqo）：Neqo是Mozilla使用Rust实现的QUIC和HTTP3。
　　如果您想玩转QUIC，请访问QUIC协议的开源实现页面，由QUIC工作组维护。
　　注意：浏览器默认不启用HTTP3，必须自己启用。实现HTTP3的难点
　　过渡到HTTP3不仅涉及应用层的变化，还涉及底层传输层的变化。传输层协议的变化可能证明是有问题的。安全服务通常是基于应用程序流量（大部分是HTTP）将通过TCP（可靠的、面向连接的协议）传输的前提而构建的。因此，采用HTTP3比采用HTTP2更具挑战性，后者仅需要更改应用程序层。
　　传输层经过网络中的中间盒的严格审查。这些中间盒，例如防火墙、代理、NAT设备，执行大量深度数据包检查以满足其功能需求。用于主要（或仅）TCP流量的防火墙默认数据包过滤策略有时会降低或阻止长时间的UDP会话。
　　此外，将传输从TCP更改为UDP可能会对安全基础设施解析和分析应用程序流量的能力产生重大影响，因为UDP是基于数据报（数据包）的协议，并且根据定义可能不可靠。因此，新传输机制的引入给IT基础架构和运营团队带来了一些复杂性。
　　随着IETF正在进行的标准化工作，这些问题最终将得到解决。鉴于谷歌早期对QUIC的实验所显示的积极结果，对HTTP3的支持是压倒性的，这最终将迫使供应商进行标准化。参考资料中文译文链接：https：blog。p2hp。comarchives9773
　　英文作者：MartinFietkiewicz
　　英文链接：https：ably。comtopichttp2vshttp3