以下是我发送给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回复关于HTTP2[1]的呼吁意向书。
目前Varnish[2]只实现了HTTP/1.1协议一些子集，Varnish目前实现的角色是混合/双向 “http-server”/”http-proxy”一致。
暂时我还不能表述太多未来Varnish是否会实现这个功能。
如果我们比替代做的更好，我们一般的策略仅是增加协议，这就是为什么目前没有实现HTTPS。
HTTP/2.0协议努力的结果应是获得牵引力，Varnish可能就会实现这个，但是这不会成为一个较快的实施，可以在表单中给出当前的建议。
我阅读了所有，在目前的表单中实践了三项建议之一。
总体来说，我找到了三项建议专注于解决以前的问题，而不是创建一个协议，在接下来的20年落后。
每一个提出建议的特殊”阵营”，所有似乎都遭遇了一定程度的隧道视野。（个人理解指的是未能清晰理解未来的发展趋势）
这是我经过深思熟虑后考虑，没有任何建议能够改变HTTP/1.1协议的实施。
我们已经痛苦的了解到，IPv6只能是勉强比IPv4好些，IPv6对成本/问题的解决来说，没有为人们提供明显的好处。 不穿透自己网络，勉强甚至于政府的任务。
我们也了解到一个交付货物的协议，可以取代所有没有时间的比赛。（这个翻译太差，不明白什么意思）
比如看看SSH如何取代了TELNET, REXEC, RSH, SUPDUP，甚至在几年前很大程度上取代了KERBEROS。
或者我也会添加上，HTTP如何取代了GOPHER[3].
HTTP1.1可以说是排在IP/TCP/UDP/ICMP后的第五大广泛使用的协议，所以应该想出一个更接近替代者。
幸运的是，有很多方式来提升HTTP/1.1，HTTP/1.1缺少支持广泛使用功能，导致问题产生。这些都要HTTP/2.0变成熟要解决的问题。
最值得注意的是HTTP/1.1缺失一个工作模式/点终结确认设施，黑客们会利用这个漏洞进行Cookie攻击。
正如欧盟佣金正确的意识到，Cookies存在根本缺陷，因为Cookies存储的用户敏感信息可能被滥用，欧盟觉得有必要对HTTP-cookies建立干预“政策”。
但这没有停止，信息中的cookies对HTTP server有非常高的价值，因为服务器对存储的完整性上无法控制，现在我们通过设置cookies加密防止被伪造。
想到“bash ackwards”。
Cookies同时也是带宽浪费者之一，默认关闭缓存，发送一堆不需要的cookies，使需要网站区分图片域名注册，以“节省”带宽。
同时想到了“not really helping”。
我认为, HTTP/2.0应该去掉Cookies，取而代之使用session/identity模式，这样HTTP/2.0比HTTP/1.1更容易做些正确的事情。
通过使用HTTP/2.0能够自适应成“automatically in compliance”，这样不论你的广告商是多么的来头，也不论你的开发者多么无能，这都是HTTP/2.0比HTTP/1.1的很好的一个卖点。
然而，这三个方面都没有实现，几乎没有补救办法。这种情况下，也为此事任何的诸多问题或困扰HTTP/1.x。
更严重的是，这些都是附加建议，这为复杂性增加了一种新的层而不是从协议中除去一些旧的复杂性。
我的结论是HTTP/2.0实际仅仅是HTTP/1.2来说夸大的名字：尝试抹平尖角节省一些带宽，但是对HTTP/1.1架构问题，并没有接近解决， 也没有保护受黑客严重破坏的忠诚遗产（个人觉得指的是cookies）
因此，我看不出有多大的机会，当前产品HTTP/2.0的建议将会比IPv6的采用上面会有更明显的发展。
这段时间在HTTP界里的一项热点是”负载均衡”或者我更乐意加它为”HTTP router”.
这些网站通过DNS解析出IP数，然后分发请求到一组HTTP服务器上，基于简单的验证，例如”Host:”，URI样式或服务器可接受的，有时会使用geo位置处理。
HTTP路由器需要很高的流量密度，因为需要可以缓解Dos攻击，小高峰等一些特殊流量剑锋。
在时间框中，HTTP/2.0会标准化，HTTP路由器会处理40Gbit/s流量，人们会开始朝着1Tbit/s流量发展。
HTTP路由器通常仅对小部分请求有兴趣，仅仅在于响应通常状态代码。
带宽有效利用的需求已经让设备生产者采取了不必要的削减，假设请求总是现在包的边界，通过修改第一个字符让HTTP头”归零”等。
无论HTTP/2.0如何变化，我强烈忽略IETF和WG正确认识HTTP路由器角色重要，并积极设计方案使HTTP路由边的更灵活简单。使他们能够履行自己的工作，同时又符合标准。
HTTP路由器需求不会消失，仅仅因为HTTPS被使用，认真思考如何优化HTTP和HTTPS混合流量问题在同一个TCP连接上，与此同时允许HTTP路由器在服务器一次正确的分发请求到不同的服务器上。
在这个领域一个简单的方法来获得了不少好处较小的代价，将是将“流标签”，每一个限制在特定的Host:头上，允许HTTP路由器只检查每个流程的第一个请求。
SPDY已经走过了漫长的道路，并曾担任概念原型的一个非常有价值的证据，记录着它有产生收益。
但正如Frederick P. Brooks告诫我们：总是抛出原型离开并重新开始，因为你会扔掉它，最终，早做可以节省时间和精力。
总的来说，我觉得在SPDY中存在严重缺陷的设计方法。
例如识别标准的HTTP报头，由4个字节的长度和文本名称，然后使用deflate压缩器进行节约带宽，是完全不符合HTTP路由通过快速检查Host:头以便路由流量的方法，最好不为每个请求承诺广泛的资源。
如果内置字典可以很好的研究或对现今的一些网站能够很好的运行，这种情况并不是都是清晰的。那么至少应该纳入某种版本的字典。
如今对我来依然尚未清晰的是，SPDY是否或如何用于TCP的80端口，是否需要自己分配一个WKS，这将会在部署期间产生一堆的防火墙、过滤和代理问题。
（这会是一项让它避免一种SPDY真的想要破除“middle-men”的感觉。）
用我安全分析的角度看，我看了很多潜在的DoS攻击于SPDY中，有很多方法，其中客户端可以使服务器消耗资源，以及预见了很多在执行服务器端复杂性，以减轻和转移的恶意流量。
服务器推送打破了HTTP的交易模式，并打开一堆的安全和隐私问题， 这不应该潜入支持HTTP/1+流量运输编码的设计过程中，而一般应该是被标准化为一个独立的和好分析扩展的HTTP。
难道SPDY真的仅仅是WebSockets下面的吗？
我本人不确认看得出里面有什么好处，不同之处在于硬件比SPDY所选择的编码是稍微更高效的实现。
同时我也不理解为什么SPDY有“mobility”，mobility这个单词仅是ID名字里面一点闪现。
如果单词”mobility”的使用上仅与带宽的使用相关，那么我会称它的用处是边缘欺骗性。
如果它涵盖了整个移动设备的IP# 变化会议的稳定性，在我的阅读中我已经错过了它。
在方案最初我曾经参与过一点，但是她使用了一些我认为有问题的概念，比如高性能（1Tbit/s)的实现，比如variant-size长度字段等。
我认为这项建议是比其他两个要好得多，采取了更为基本的查看任务的，因为它需要一种方法来节省带宽的基础上列举并重复的标记，而不是紧缩后抛出所有并希望出现奇迹。
我认为这项建议要先从最基础的开始，但是例如另外两个来说还有很长的路要走，才能真正担当起HTTP/2.0的称号。
总之，我没有看到提供的三点建议中任何一个，会使大多数的网站表示 “哦，这是我们一直在等待的！”
大型些的网站会entised靠节省小额带宽，但是大多数HTTP用户看到很少或没有积极的效益，如果一个或更多建议变成HTTP/2.0。
考虑到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项目将也会感兴趣。
Poul-Henning Kamp
Author of Varnish
[1] http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI
[3] Yes, I’m that old.
[5] No, I’m not kidding.