在甲板上--HTTP/2的椅子

上周，一些人发现，当涉及到拒绝服务攻击时，HTTP/2协议并不是那么出色。

有趣的是。

上周发现的DoS漏洞，并在超级DevOps-ness的英雄传奇中自豪地宣布为“零日”，可以在RFC7540第38页底部的6.5.2节中找到，从2015年开始：

SETTINGS_MAX_CONCURRENT_STREAMS (0x3):  Indicates the maximum number
   of concurrent streams that the sender will allow.  This limit is
   directional: it applies to the number of streams that the sender
   permits the receiver to create.  Initially, there is no limit to
   this value.  It is recommended that this value be no smaller than
   100, so as to not unnecessarily limit parallelism.

早在RFC正式成立之前，我们中的一些人就警告说 there is no limit ，但这不是问题，因为“我们有足够的CPU来做这件事”，我们被告知，主要是来自一家非常大的公司的人，他们把H2灌输给了我们。

总体而言，HTTP/2一直令人失望，至少如果你相信任何用来推销它的崇高承诺和炒作的话。

是的，我们有更少的TCP连接，当只有六千多个端口号可用时，这是很好的，是的，我们得到了一些并行的每个TCP连接。

当然，这种并行性的代价是丢弃的包不再延迟单个资源：现在它延迟了 everything 。

在批准期间，这项服务被戏称为“队头屏蔽”或“Hol-屏蔽”，但这也不是问题，因为“互联网服务提供商将被迫(最终)解决这个问题”--一位通过谷歌光纤连接到他在傻瓜谷的家的人说。

但正如人们上周“发现”的那样，我们对DoS攻击也变得更加敏感--这是故意的--因为H2的全部目的是尽快完成尽可能多的工作。

然后是H2 RFC中关于“流优先”的整个部分，旨在降低人们阅读文章中的字词的风险，直到所有的“货币化”到位。

据我所知，没有人能做到任何有用的事情，除非有人24*7全天候地站着，用鼻子指着不断移动的月亮，同时背诵乔叟的记忆。我想现在所有的浏览器都忽略它了。

哦，…和“推”：违反所有原则的反向原语，这样服务器就可以告诉浏览器，无论是地狱还是高潮，你都会立即需要这些广告。

也没有人让它起作用。

但我个人一直最喜欢的是这一条：

静态HPACK压缩表包含标头条目 proxy-authentication 和 proxy-authorization 根据定义，它永远不会出现在H2连接中。但它们位于某人用来构建表的某个随机数据集中，“现在要改变这一点已经太晚了”，因为我们急于部署H2。

我们在丹麦语中有一句话：Hastværk er lastværk？，大致翻译为？匆忙和抱歉？，嗯，是的……

(如果你想读我当时的想法，这是一份我从未完成的草稿，因为我意识到H2只会是一个橡皮图章练习：https://phk.freebsd.dk/sagas/httpbis/)

一旦知道H2将会发生，DoS漏洞等等，我就减少了对DoS问题的抱怨，部分原因是我认为没有理由积极地告诉脚本孩子和罪犯该做什么，但主要是因为显然没有人在听：“这是一个旁路。你必须建立旁路。”

我们不太情愿地在Varnish中实现了H2，因为人们告诉我们他们真的、真的需要这个，一旦他们在《华尔街日报》上读到它，它将成为C团队的一个复选框项，而所有酷的孩子都已经拥有它了。

我们做得不差，但如果我们觉得值得的话，我们可能会做得更好。

但考虑到H2上的墨水在推出Quic来取代它之前刚刚干透，而且DoS漏洞确实被写入了标准，我们认为H2不太可能取代热板和深水，成为世纪的发明，并相应地节省了我们的资源。

令我惊喜的是，坏人花了这么长时间才将H2武器化。是的，主RFC有100页，海明威和普拉切特都不在球队里，但八年了？当然，我们不知道它在某个国家的“网络武器”武器库中已经成为秘密武器多久了。

但现在坏人发现了它，并将其武器化，我们该怎么办？

我的建议是：

除非你有确凿的数字表明，H2确实在改善你和你的客户的状况，否则你应该干脆把它关掉。记住也要从Hitch中的ALPN字符串或使用的任何TLS减载器中删除它。

如果由于某些原因您无法关闭H2，我们正在实施一些参数来帮助缓解DoS攻击，我们将推出新的版本来为您提供这些参数。

但除此之外，请不要期望我们花费大量时间来重新安排HTTP/2的躺椅。

/phk