然而，技术的发展总是让人眼花缭乱。 2018年10月，HTTP/3发布。虽然有些中国技术媒体报道过，但大多数都是翻译过来的，内容也很相似。最近，我专门学习HTTP/3。把它写在这里并与大家分享。
让我们简要回顾一下HTTP/2。自从1999年发布HTTP 1.1以来，Web一直在快速增长，但HTTP协议尚未更新。不能等待谷歌做一个SPDY（发音是“快速”），并依靠Chrome浏览器来推广。看到SPDY真的很好（可以带来近50％的性能提升），IETF推动了HTTP/2的开发。 SPDY和HTTP/2的主要功能如下所示
HTTP/3即将到来，让我先看一下我的解释。
现在HTTP/2不是新的。根据2019年2月访问量最大的1000万网站的统计数据，33.5％已经支持HTTP/2。在中国，如果你打开浏览器看到调试模式，你会发现主要的制造商已广泛使用HTTP/2，特别是放置css，js和图像的资源站。 HTTP/2基本上是标准的。这也很容易理解，基本上什么都不做，可以直接享受多路复用的好处，为什么不呢？
在传统的HTTP中，概念模型非常简单：底层TCP通信不与上层HTTP重叠，但TTP和TCP之间的“连接”是一致的。 TCP传输的单位是数据包，HTTP的模型使用请求 - 响应。
在HTTP/2中，概念模型已经改变，HTTP/2中的基本传输单元是帧。与HTTP 1.1的明文传输不同，HTTP/2帧是二进制的，TCP携带的“逻辑连接”称为流。所有状态流，流控制，优先级等都在数据流上实现。 HTTP/2是每个人都在谈论的“多路复用”。简而言之，数据流被分解为多个帧。多个数据流的帧被混合并由相同的TCP连接发送。
值得注意的是，HTTP具有1.0和1.1的区别，因此编写HTTP 1.0，HTTP 1.1，但HTTP/2不会有其他次要版本，因此不要编写HTTP 2.0，而是将其写为HTTP/2。尽管HTTP/2带来了巨大的性能提升，但每个人对性能的渴望都是无穷无尽的。解决了应用层的许多问题后，下一个优化重点是传输层。无论SPDY还是HTTP/2，传输层协议都是TCP。 TCP有一些由母亲引起的问题，比如启动慢。如果拥塞窗口大小设置不合理，TCP的性能将急剧下降。互联网上有很多关于这个问题的讨论，所以我不会在这里详细介绍。
另一个重要问题是HTTP/2多路复用的效果不如您想象的那么好。虽然HTTP/2中的传输连接可以多路复用，但仍然无法避免线头阻塞。由于TCP需要保证有序，如果单个TCP连接同时携带四个逻辑连接，并且其中一个逻辑连接丢失，则其他三个路径将受到影响，并且所有路径都必须从数据包丢失。毫无疑问是一个很大的浪费。测试表明，如果丢包率超过2％，HTTP/2甚至不如HTTP 1.1，因为HTTP 1.1中的连接是物理隔离的，不会相互影响。
HTTP/3即将到来，让我先看一下我的解释。
因此，这个想法自然是“用TCP来解决这些问题”。考虑到实际上已经存在数千个网络设备，它们只能识别TCP和UDP，软件不会发展，并且更新TCP协议肯定是不可行的。——虽然TCP的快速开放于2014年12月发布，但实际应用情况并不令人满意。因此，只有UDP可用。顺便说一句，有些人考虑过SCTP，但是SCTP在团队头部阻塞，TLS和四次握手方面仍然存在缺陷。它仍然不尽如人意。
有些人听说过QUIC（快速），知道它基于UDP HTTP，并且知道它仍然是谷歌提出的第一个。事实上，谷歌是第一个提出SPDY的人，这次谷歌是第一个提出QUIC的人。根据谷歌的初衷，QUIC用UDP代替传统的HTTP/TCP/IP协议栈中的TCP（当然需要加密），并且可以通过加密的UDP传输HTTP/2帧。
据Google称，它有很多优点。例如，UDP建立连接的延迟要低得多，并且可以避免阻塞队列。此外，谷歌还提供了一个非常有吸引力的功能FEC（前向纠错）。简单地说，它想要做的是，一旦数据包丢失，接收器就可以根据先前和后续数据包推断丢失数据包的数据，从而避免重传。但这不可避免地需要增加冗余负载，或者说网络协议中的RAID 5。根据目前看到的数据，冗余率约为10％，即每10个pakcet冗余信息，就可以重建一个数据包。虽然谷歌的QUIC非常先进，但QUIC不仅仅是这一款，IETF也有QUIC，现在它已经改名为HTTP/3，因此谷歌的QUIC有时会写gQUIC。与仅基于传输层的Google不同，应用层基本上使用HTTP/2。 IETF的QUIC是一种混合解决方案，包括传输层更改和HTTP层更改（例如全新的标头压缩）。从另一个角度来看，它更“完整”。虽然QUIC理论上可以支持除HTTP以外的其他上层应用程序，但这只是一个计划。 QUIC的第一个版本不包含此内容。
在2018年11月，IETF正式宣布将HTTP-over-QUIC重命名为HTTP/3。
HTTP/3即将到来，让我先看一下我的解释。
本文讨论了QUET的IETF版本。谷歌已宣布将逐步将IETF规范纳入其自己的协议版本，以实现相同的规范。
尽管TCP存在各种问题，但如果切换到UDP，TCP的许多功能都需要按原样进行移植。很多人都知道TCP是一种可靠的传输协议，UDP并不可靠。当然，HTTP/3不可靠，因此它必须实现自己的功能，如命令，错误检测，重传，拥塞控制和传输节奏调整。
HTTP/2“似乎”必须使用HTTPS，但规范并不强制HTTP/2使用HTTPS，这意味着如果使用HTTP运行HTTP/2，理论上可以建立它，尽管这有点奇怪。
相反，所有QUIC连接都是加密的，目前使用的是TLS 1.3。如果仔细查看上图，您会发现TLS 1.3在QUIC中“包含”，即在QUIC连接建立的握手过程中完成握手握手。 HTTP/3握手速度非常快。如果建立了两个主机之间的连接并缓存了先前的密码，只要客户端验证以前缓存的服务器配置，就可以直接建立连接，这相当于0-RTT，否则只需要1 -RTT可以建立连接。此外，QUIC允许在0-RTT的情况下从头开始搭载数据。传统的“建立连接 - 加密握手 - 发送数据”现在可以分三步完成（这个0-RTT和1-RTT实现都非常有趣，如果你有兴趣，你应该查找信息）。
虽然QUIC也有连接（Connection），但它也基于IP和端口建立，但它不直接对应TCP连接，并且与HTTP/2中的连接不同。原因是QUIC完成了传统的传输握手，并在建立连接时完成加密握手。——您可以认为分层责任不明确，但确实提高了效率。 QUIC连接类似于HTTP/2，物理连接也可以承载多个逻辑连接（即数据流）。但是，与HTTP/2不同，QUIC中的逻辑连接彼此独立，因此避免了“逻辑连接丢失是由逻辑连接引起，逻辑连接B，C和D需要重传”的情况。QUIC连接的另一个特性是每个连接都有一组连接ID。连接每一端以设置您自己的连接ID并识别另一方的连接ID。连接ID的目的是逻辑地标识当前连接。因此，如果用户的IP改变并且连接ID没有改变，因为该分组包含网络ID标识符，所以仅需要继续发送数据分组以重新建立连接。目前，如果用户的设备具有网络交换机，例如从Wi-Fi切换到4G，则必须断开所有连接并重新连接。
如果您已经详细研究过HTTP/2，那么您应该知道用于其头压缩的HPACK，因为gzip会进行头压缩并且存在安全风险。 HTTP/3还提供标头压缩，但不能直接使用HPACK。原因是HPACK大致是一个动态表，由请求 - 响应维护。前一个标题不会完全重复上一个条目，但会引用前一个条目。 TCP保证的顺序。必须首先修改它然后读取，即先编码然后解码。
但是，如果使用HPACK，则无法保证多个流的顺序，这可能导致解析错误。 QUIC的解决方案是QPACK，原理很简单：所有标头必须通过相同的数据流传输，并且必须严格排序。但是，结果，再次出现了从HTTP 1.1阻止的长期HTTP头。因此，QUIC的长期目标之一是解决报头的报头阻塞问题。
任何进行过在线升级的人都知道，在线升级的一个重要组成部分是提供降级以确保“降级”兼容性。 HTTP/2和HTTP/3都不能逃避这部分工作量。虽然可以通过升级此标头来升级HTTP/2，但在TLS握手期间有一种更简单的方式来协商HTTP版本。例如，Nginx具有NPN（Nginx协议协商）扩展，自动协商协议，并已被IETF采用。成为ALPN（应用层协议协商）。
如果Web服务器具有此类功能，则应用程序服务代码不必为HTTP 1.1和HTTP/2兼容性做太多工作。但是，如果您在应用程序中使用Push等新功能，则仍需要做很多事情。在业界，谷歌，Youtube，维基百科等大公司已经提供了完整的服务，HTTP/2和HTTP 1.1无缝切换，客户端完全没有感知，而且他们的经验值得借鉴。与HTTP/2不同，HTTP/3中定义了一个新标头，可用于指示客户端“在另一个端口上提供专用的HTTP/3服务”。
Alt-Svc: h3=': 20003'
此标头显示在此主机的端口20003上启用了HTTP/3服务。因此，客户端可以尝试与此端口建立纯HTTP/3连接。
在谈到这么多QUIC的好处之后，让我们谈谈它的问题。一些意见来自我个人。它们可能不够准确和客观。欢迎讨论。
虽然QUIC有很多好处，但可以看出它的变化与HTTP/2相比非常大，因此没有太多问题。
第一个问题是与传统网络设备的兼容性。
基于当前的应用，许多网络设备具有相当固定的TCP和UDP策略。 TCP仅限于公共端口，而UDP可能只有53个端口（DNS）打开。因此，如果HTTP/3使用UDP，则兼容性可能存在很多问题。
但是，如果这个问题可以解决，将来可能不会再出现这个问题，因为未来会考虑HTTP/3的设计思想，并且应用层和传输层是严格隔离的，避免重新出现“运输层看港口”。我知道应用程序层正在做什么。“
第二个问题是QUIC的性能问题。
虽然TCP也是一种非常古老的协议，但它被广泛使用，并且在操作系统内核中有相应的处理代码。 BBR等新功能还可以大大提高TCP的性能。但是QUIC放弃了TCP。根据谷歌的文档，正是因为TCP太稳定了，内核中的代码更新特别麻烦。另外，由于Linux内核设计一开始并没有考虑多核扩展问题，在多核（核心）的情况下，会导致重复陷阱，导致进程阻塞，严重影响性能。
针对上述问题，许多新的解决方案已将网络协议栈置于用户模式处理中，而QUIC也遵循这一趋势。唯一的问题是UDP协议栈似乎没有现成的，令人满意的解决方案。也许我们必须等待一段时间才能使用可靠有效的解决方案。
第三个问题是服务器推送。
虽然很多人真的想要这个功能，而HTTP/2确实包含它，但是关于它的应用仍然存在很多争议。简而言之，HTTP/2推送打破了HTTP传统的“一问一答”通信模式。当客户端没有请求时，服务器可以向客户端发送数据，这不可避免地被滥用（想想到处都是）那些最喜欢“商务谈话”的人，不喜欢谈论“道德”消息，尽管Chrome开发者说他们会检查推送和阻止恶意内容，它也是在收到推送数据后，这个计划并不完美。同时，无论客户端的高速缓存如何，服务器也可以拒绝推送客户端，从而导致带宽浪费。 HTTP/3保留推送，但机制不同。客户端需要先同意，服务器才能推送。此外，客户端可以设置服务器推送限制，超出限制的推送将是错误的。尽管如此，对如何正确使用推送还没有公认的答案。
最后一个问题来自调试和支持的工具。
任何需要大规模工程应用的技术，依赖于“标准实现”单打，绝对是不可接受的，因为它不能被切片而且不能细化。在传统的HTTP技术堆栈中，每个层都有相应的工具，例如IP层中的ping和traceroute，传输层中的telnet以及应用层中的curl。这些工具是集群的，开发人员可以轻松找到它们。问题的级别和细节。虽然HTTP/2已经改变，但是有很多调试工具，curl可以支持它，而nghttp2和h2c等工具构成了一个完整的系统。 HTTP/3更改非常大。如果没有相应的调试支持工具，您可以想象部署和迁移并不容易。
中文
电话咨询
微信咨询
公众号
