为什么HTTP/2.0似乎并不有趣¶
这是我发送给IETF HTTP工作组的电子邮件：：
From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Subject: HTTP/2 Expression of luke-warm interest: Varnish
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <41677.1342136900@critter.freebsd.dk>
Date: Thu, 12 Jul 2012 23:48:20 GMT
这是Varnish对以HTTP/2表示兴趣的呼吁的回应 [1] 。
Varnish¶
目前Varnish [2] 仅实现与其混合/双重“http-服务器”/“http-代理”角色一致的HTTP/1.1的子集。
在这一点上，我不能说太多关于Varnish将或将不会在未来实现协议的明智之处。
我们的总体政策是，只有在我们可以做得比替代方案更好的情况下才添加协议，这就是为什么我们没有实现HTTPS的原因。
如果HTTP/2.0努力的结果导致了一个获得支持的协议，Varnish可能会实现它，但考虑到目前的提议，我们不太可能成为早期实现。
为什么我不为所动¶
我已经阅读了所有提案，并参与了目前摆在桌面上的三项提案中的一项。
总体而言，我发现这三项提议都专注于解决过去的问题，而不是制定一项有机会让我们在未来20年持续下去的协议。
每一项提议都来自一个特定的“阵营”，因此似乎都受到了一定程度的狭隘眼光的影响。
我经过深思熟虑后认为，没有一个提案能够在实践中取代HTTP/1.1。
如果他们制定了一项新的协议，但没有人使用呢？¶
我们痛苦地了解到，IPv6仅略好于IPv4，并且不会为那些承担升级成本/麻烦的人带来切实的好处，它本身并不能渗透到网络中，甚至在政府的强制下也是如此。
我们还了解到，交付货物的协议几乎可以在任何时间内取代所有竞争对手。
例如，看看SSH如何在几年内取代Telnet、REXEC、RSH、SUPDUP，并在很大程度上取代Kerberos。
或者我可以补充一句，HTTP是如何取代Gopher的 [3] 。
可以说，HTTP/1.1是最常用的五种协议之一，排在IP、TCP、UDP和可悲的ICMP之后，因此应该谦虚地提出替代协议。
击败HTTP/1.1¶
幸运的是，有许多方法可以改进HTTP/1.1，它缺乏对几个广泛使用的特性的支持，并且有许多麻烦的杂草，这两种方法都已经成熟，可以用来攻击HTTP/2.0。
最值得注意的是，HTTP/1.1缺乏工作的会话/端点标识工具，人们用构思不周的Cookie黑客弥补了这一缺陷。
正如欧盟委员会正确地指出的那样，Cookie存在根本性缺陷，因为它们将潜在的敏感信息存储在用户碰巧使用的任何计算机上，并且由于各种滥用和无能，欧盟感到被迫立法对HTTP-Cookie制定“通知并宣布”政策。
但它不止于此：存储在Cookie中的信息对HTTP服务器具有潜在的非常高的价值，并且由于服务器无法控制存储的完整性，我们现在看到Cookie被加密签名，以防止伪造。
在我脑海中浮现出“低音倒退”这个词。
Cookie也是带宽的主要浪费之一，默认情况下禁用缓存，在不需要的情况下发送大量Cookie，这使得许多网站为图像内容注册单独的域，以通过避免Cookie来“节省”带宽。
“没有真正的帮助”这个词也出现在我的脑海中。
在我看来，HTTP/2.0应该扼杀Cookie这个概念，代之以会话/标识工具，这使得使用HTTP/2.0比使用HTTP/1.1更容易做正确的事情。
无论你的广告商有多大，或者你的网络开发人员有多无能，使用HTTP/2.0都能“自动合规”，这将是HTTP/2.0胜过HTTP/1.1的一大卖点。
然而，在我阅读它们时，这三个提案都没有试图解决这种情况，更不用说补救了，也没有解决HTTP/1.x的任何其他问题或麻烦。
更糟糕的是，它们都是附加提议，这增加了新的复杂性，而没有从协议中删除任何旧的复杂性。
我的结论是，HTTP/2.0实际上只是HTTP/1.2的一个夸张的名字：试图消除一些尖锐的角落，节省一点带宽，但不会接近HTTP/1.1的所有体系结构问题，并忠实地保留其考虑不周的沉积黑客的遗产。
因此，我认为当前的一批HTTP/2.0提案在采用方面不会明显好于IPv6。
HTTP路由器¶
如今，HTTP世界中的一个特别热点是“负载均衡器”，或者我更喜欢称之为“HTTP路由器”。
这些框位于DNS解析的IP编号处，并基于简单的标准(例如“主机：”、URI模式和/或服务器可用性)将客户端请求分发到HTTP服务器场，有时还会加上地理位置的变化 [4] 。
HTTP路由器具有非常高的流量密度，最高的流量密度，因为它们是DoS缓解、闪存和特殊事件流量高峰的焦点。
在HTTP2.0标准化的时间框架内，HTTPS路由器将常规地处理40Gbit/S流量，人们将开始设计1Tbit/S流量。
HTTP路由器通常只对一小部分HTTP请求感兴趣，对响应几乎不感兴趣，通常只对状态代码感兴趣。
对带宽效率的要求让这些设备的制造商采取了许多不必要的捷径，例如，假设请求总是从数据包边界开始，通过更改第一个字符来“清除”HTTP报头，等等。
无论HTTP/2.0成为什么，我强烈敦促IETF和工作组正式认识到HTTP路由器的作用，并积极设计该协议，使HTTP路由器的生活变得更容易，以便它们能够在符合标准的情况下完成工作。
对HTTP路由器的需求不会仅仅因为使用HTTPS而消失，应该认真考虑在同一个TCP连接上混合HTTP和HTTPS流量的问题，同时允许服务器端的HTTP路由器正确地将请求分发到不同的服务器。
在这一领域，以较少的成本获得大量好处的一种简单方法是分配“流标签”，每个流标签被限制为一个特定的主机：报头，允许HTTP路由器仅检查每个流上的第一个请求。
SPDY¶
SPDY已经走过了很长一段路，并且已经成为一个非常有价值的概念验证原型，用来记录下可以获得的收益。
但正如弗雷德里克·P·布鲁克斯告诫我们的那样：永远把原型扔掉，重新开始，因为你最终会把它扔掉，及早这样做可以节省时间和精力。
总体而言，我发现SPDY采用的设计方法存在严重缺陷。
例如，通过4字节长和文本名称识别标准化的HTTP报头，然后应用放气压缩器来节省带宽，这与需要快速提取主机：报头以便路由业务的HTTP路由器的工作完全不一致，优选地，不向每个请求投入大量资源。
同样不清楚的是，内置的词典是否经过了很好的研究，或者只是碰巧在当今网站的某个子集上工作得很好，而且至少应该纳入这部词典的某种版本。
对于我来说，还不清楚SPDY是否或如何在TCP端口80上使用，或者它是否需要自己的WKS分配，这将在部署期间打开大量的防火墙、过滤和代理问题。
(这是让人难以避免的一种感觉，即SPDY真的想要废除所有的“中间人”)
在我的安全分析师的帽子上，我看到了SPDY协议中的许多DoS潜力，客户端可以通过许多方式使服务器消耗资源，并预见到实现服务器端以缓解和转移恶意流量的许多复杂性。
服务器推送打破了HTTP事务模型，打开了一堆安全和隐私问题，这些问题不会在为HTTP/1+流量设计传输编码时偷偷进入，而是通常被标准化为HTTP的独立和经过良好分析的扩展。
HTTP速度+移动性¶
实际上就是下面有WebSockets的SPDY。
我真的不确定我认为这有什么好处，除了所选的编码在硬件上实现的效率略高于SPDY。
我不明白为何它的名称中有“移动性”，这个词只在身份证中出现，作为名称的一部分。
如果“移动性”一词的使用仅指带宽使用，我会把它的使用称为边界欺骗性。
如果它涵盖了移动设备的IP#变化中的会话稳定性，那么我在阅读中错过了它。
草稿-tarreau-attpbis-网络友好-00¶
我最初参与了这个草案，但它使用了一些我认为对于高性能(如1Tbit/S)实现非常有问题的概念，例如可变大小的长度字段等。
我确实认为这项提议比其他两项要好得多，从更根本的角度看待这项任务，如果没有其他原因，因为它采取了一种基于枚举和重复标记的带宽节约方法，而不是在放气后扔掉一切，希望出现奇迹。
我认为这个协议是最好的起点，但像其他两个协议一样，在它真正赢得HTTP/2.0的称号之前，它还有很长的路要走。
结论¶
总体而言，我认为这三个提案中的任何一个都不会让大多数网站发出这样的声音：“哦，我们一直在等这个！”
较大的站点将受到少量带宽节省的吸引，但如果这三个建议中的一个或多个成为HTTP/2.0，大多数HTTP用户将很少或没有真正的正面好处
考虑到对HTTP/1.1互操作的描述是多么粗略，很难估计有多麻烦(比如：“为什么这个网站不工作？”)他们的部署将导致，也不完全清楚SPDY的经验在多大程度上代表了更广泛的部署，或者仅仅是对于有兴趣拦截HTTP流量的人来说是“隐蔽的”。
考虑到HTTP/1.1在网络中的作用，我担心目前急于通过纯粹的附加手段推出HTTP/2.0是严重误导的，而且接近临界值，这将推迟或阻止其本身的采用。
归根结底，一个HTTP请求或一个HTTP响应只是一些元数据和一个可选的字节块作为主体，如果它已经需要700页来标准化，而HTTP/2.0还会再增加100页，那么我们显然是在做一些错误的事情。
我认为最好是从头开始，看看HTTP/2.0实际应该做什么，然后设计一个简单、高效和面向未来的协议来实现这一点，并将所有考虑不周的HTTP/1.1黑客的集合抛在脑后。
但只要工作组制定了人们将开始使用的HTTP/2.0协议，Varnish项目就会感兴趣。
保尔-亨宁坎普
《Varnish》的作者
[1] http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI
[2] https://www.varnish-cache.org/
[3] 是的，我就是这么老。
- [4] 这实际上是一个传输级工作，但它被排除在IPv6之外
以及其他有用的功能，不会延迟采用 [5] 。
[5] 不，我没开玩笑。