HTTP是驱动Web的应用程序协议。1991年，它以所谓的HTTP/0.9协议的形式出现，到1999年已经发展到HTTP/1.1，它在IETF（互联网工程任务组）中被标准化。HTTP/1.1在很长一段时间内已经足够好了，但是不断变化的Web需求需要一个更适合的协议，HTTP/2出现在2015年。最近有消息称IETF打算发布一个新版本HTTP/3。对一些人来说，这是一个惊喜，并引起了一些混乱。如果你不密切关注IETF的工作，那么HTTP/3似乎突然出现了。然而，我们可以通过一系列的实验和Web协议的演变来追溯它的起源；特别是QUIC传输协议。如果你不熟悉QUIC，我的同事们在处理不同角度方面做得很好。John的博客描述了当今HTTP的一些现实烦恼，alesandro的博客讨论了传输层的细节，Nick的博客介绍了如何进行一些测试。我们在https://cloudflare-quic.com。如果这让你觉得好笑，一定要看看quiche，我们自己编写的QUIC协议的开源实现生锈.HTTP/3HTTP应用程序映射到QUIC传输层。该名称在最近的第17版草案（draft-ietf-quic-http-17）中正式提出，该草案于2018年10月底提出，11月在曼谷召开的ietf 103会议上进行了讨论并形成了初步共识。HTTP/3以前被称为HTTP over QUIC，它本身以前被称为HTTP/2 over QUIC。在此之前，我们在gQUIC上使用HTTP/2，而在很久以前，我们使用SPDY而不是gQUIC。然而，事实是，HTTP/3只是一种新的HTTP语法，适用于ietfquic，一种基于UDP的多路复用和安全机制运输。输入在这篇博客文章中，我们将探究HTTP/3以前的一些名称背后的历史，并展示最近名称更改背后的动机。我们将回到HTTP的早期，并讨论沿途发生的所有好的工作。如果您希望了解完整的情况，可以跳到文章的末尾，或者打开这个非常详细的SVG版本。在我们关注HTTP之前，有一个HTTP/3层在关注sceneJust之前，有两个协议共享QUIC这个名字。如前所述，gQUIC通常用于标识googlequic（原始协议），而QUIC通常用于表示与gQUIC不同的IETF标准进行中版本。自90年代早期以来，网络的需求已经发生了变化。我们有了新版本的HTTP，并以传输层安全性（TLS）的形式添加了用户安全性。我们只会在这篇文章中涉及TLS，我们的其他博客文章是一个很好的资源，如果你想探索这个领域的更多细节。到帮我解释一下HTTP和TLS的历史，我开始整理协议规范和日期的细节。这些信息通常以文本形式呈现，如按日期排序的文档标题的项目符号列表。但是，存在分支标准，每个分支在时间上重叠，一个简单的列表不能表达关系的真正复杂性。在HTTP中，有一些并行工作重构核心协议定义以便于使用，扩展协议以用于新的用途，并重新定义协议如何通过Internet交换数据以获得性能。当你试图将互联网历史上近30年的点点滴滴跨越不同的分支工作流程时，你需要一个可视化的形象。所以我做了一个——Cloudflare安全网络时间线。（注：从技术上讲，它是一个分支图，但时间线一词更为广为人知）。我已经申请了一些艺术许可，当创建这个，选择集中在IETF领域的成功分支。一些没有显示的东西包括W3联盟HTTP-NG工作组的努力，以及他们的作者热衷于解释如何发音的一些异国想法：HMURR（发音为"hammer"）和WAKA（发音为"wah kah"）。在接下来的几节中，我将沿着这个时间线来解释HTTP历史上的关键章节。要想从这篇文章中得到一些收获，了解为什么标准化是有益的，以及IETF是如何做到这一点的。因此，在回到时间轴之前，我们将从这个主题的一个非常简短的概述开始。如果您已经熟悉IETF.类型一般来说，标准定义了共同的职权范围、范围、约束、适用性和其他注意事项。标准有许多形状和大小，可以是非正式的（也可以是事实上的）或正式的（由IETF、ISO或MPEG等定义标准的组织同意/发布）。标准应用于很多领域，甚至有一个正式的英国泡茶标准-bs6008。早期的Web使用在IETF之外发布的HTTP和SSL协议定义，它们在安全Web时间轴上被标记为红线。客户机和服务器对这些协议的理解使它们成为事实标准。At在某种程度上，决定将这些协议正式化（一些动机的原因将在后面的章节中描述）。因特网标准通常在IETF中定义，IETF遵循"粗略共识和运行代码"的非正式原则。这是基于在互联网上开发和部署东西的经验。这与试图在真空.IETFInternet标准通常称为RFC。这是一个需要解释的复杂领域，所以我建议阅读QUIC工作组联合主席marknottingham的博客文章"如何阅读RFC"。工作组（WG）或多或少只是一个邮件列表。IETF每年举行三次会议，为所有工作组提供时间和便利，以便他们在愿意的情况下亲自开会。这几周的议程可能会变得非常拥挤，时间有限，无法深入讨论高技术领域。为了克服这一点，一些工作组选择在IETF一般性会议之间的几个月举行临时会议。这有助于保持规范开发的势头。由于2017年已经召开了几次临时会议，因此已经有了完整的临时会议清单页码。这些IETF会议还为其他IETF相关人员提供了会面的机会，例如Internet架构委员会或Internet研究工作组。近年来，IETF的黑客竞赛在IETF会议之前的周末举行。这为社区提供了一个开发运行代码的机会，更重要的是，与其他人在同一个房间里进行互操作性测试。这有助于在规范中找到可以在下面讨论的问题天。为了这个博客的目的，重要的一点是要理解rfc不仅仅是突然出现的。相反，他们要经历一个过程，通常以IETF互联网草案（I-D）格式开始，该格式被提交以供采纳。在已经发布规范的情况下，准备I-D可能只是一个简单的重新格式化练习。自发布之日起，I-D的有效寿命为6个月。为了使它们保持活动状态，需要发布新版本。实际上，让一个I-D消失并没有什么后果，而且这种情况经常发生。这些文档继续被托管在IETF文档的网站上，供任何想阅读它们的人使用。I-d在安全Web时间轴上以紫色线表示。每一个都有一个唯一的名称，其形式为draft-{author name}-{working group}-{topic}-{version}。工作组字段是可选的，它可以预测IETF WG将在工件上工作，有时会发生变化。如果IETF采用了I-D，或者如果I-D是在IETF中直接启动的，那么名称是draft IETF-{working group}-{topic}-{version}。I-D可能会在藤蔓上分枝、合并或死亡。版本从00开始，每次发布新草稿时增加1。例如，I-D的第四稿的版本是03。任何时候，当一个I-D更改名称时，它的版本将重置为00。需要注意的是，任何人都可以向IETF提交I-D；您不应将这些视为标准。但是，如果IETF的I-D标准化过程达成共识，并且最终文件通过评审，我们最终得到RFC。此阶段名称再次更改。每个RFC都有一个唯一的编号，例如RFC 7230。这些在安全网络时间轴上用蓝线表示。RFC是不可变的文档。这意味着对RFC的更改需要一个全新的编号。为了合并勘误表（发现和报告的编辑或技术错误）的修复，或者仅仅为了重构规范以改进布局，可以进行更改。RFC可能会淘汰旧版本（完全替换），或者只是更新（实质性的更改）。就我个人而言，我发现IETF数据跟踪器更加用户友好，因为它提供了从I-D到RFC的文档进度的可视化效果。下面是一个例子，展示了RFC 1945-HTTP/1.0的开发过程，它是安全Web的一个明显的灵感来源时间线.IETF有趣的是，在我的工作过程中，我发现上面的可视化是不正确的。由于某种原因，它缺少draft-ietf-http-v10-spec-05。由于I-D生命周期为6个月，因此在成为RFC之前似乎还有一个缺口，而事实上，草案05在1996年8月之前仍然有效。探索安全网络时间线，并对互联网标准文件如何实现进行一个小小的了解，我们就可以开始沿着安全网络时间线走了。在这一节中，有许多节选图表，它们显示了时间轴的重要部分。每个点代表文档或功能可用的日期。对于IETF文件，为了清楚起见，省略了草案编号。但是，如果你想看到所有这些细节，请查看com