开放系统互联网络的经典愿景¶

《纽约时报时尚杂志》上周发表了一篇文章 about the Italian town Ivrea ，这可能是你从未听说过的。

30多年前，当我作为欧洲议会从OSI协议迁移到TCP/IP的项目的一部分被派到那里时，我也没有。

什么？你认为OSI协议只是一种理论？

没有什么比这更离谱的了。

我们一直被印度的“微软支持”困扰的一个主要原因是，全球电话网络运行在7号信令系统(“SS7”)上，这在很大程度上是一种OSI协议。

您的电表很可能使用DLMS(/cosem)，这也是一种OSI协议。

在这两种情况下，仅仅阅读相关标准就需要花费大量资金，这就是为什么他们可以在几十年内不受干扰地坚持这种疯狂的行为。

几年前，ITU-T终于看到了曙光，所以现在你真的可以阅读了 Q.700 如果你不相信我。

无论如何，回到20世纪80年代末的卢森堡，欧洲议会运行的是OSI协议，它很糟糕，我越深入地研究红色/黄色/蓝色 Book"[1], 更明显的是，这些协议完全不适合在局域网上使用。

我们提议将欧洲议会迁移到使用tcp/IP协议，我们做到了，这让我在伊夫雷亚度过了难忘的一年，但我们只能在欧盟委员会强加的明确条件下才能做到这一点，即议会将迁移回来，“…一旦与开放系统互连协议的问题得到解决。”

他们从来没有把它们分类，因为OSI协议是由只考虑不同建筑、城市、国家和大陆之间的通信的人设计和建立的，而不是考虑每一栋建筑内部发生的事情 [2].

看过这篇咆哮的标题后，你可能已经知道我要说的是什么了，你基本上是对的。

好消息是，IETF吸取了教训，因此Quic不会像HTTP/2那样被强行通过和橡皮图章盖章，事实上，人们可以争辩说，IETF通过将Quic交给他们的死对头来报复： The Transport Area 。

我认为这是一件好事，因为我几乎所有关于H2的预测都成真了，因为缺乏好处，因为在其中设计了DoS暴露。

之所以会出现这些问题，是因为推动“H2协议(以前称为SPDY)”的人只是从一家拥有地理位置各异的数据中心的大公司的角度来考虑世界，对这些公司来说，丢包是其他人会遇到的事情，拥塞问题可以通过向带宽采购部门发送电子邮件来解决。

但这些担忧恰恰是运输区的“恐龙”们关心的，也是他们几十年来一直研究和研究的，所以有充分的理由预计，Quic在运输区的表现将比它进入运输区时要好得多。

虽然我很确定H2将会失败，但我更难看到Quic会走向何方。

从积极的方面来看，Quic是一个更好的协议，它看起来像是我们在日益移动的互联网中需要的那种协议，在这个互联网上，IP号码是短暂的属性。这是胡萝卜，它又大又多汁。

在中性领域，Quic不是一个简单的协议，它是一个完整的传输协议，这意味着丢失检测、重传、拥塞控制和所有这些，但如果不解决TCP解决的问题，你就不会比TCP更好，这些都是真实而困难的问题。

从负面来看，Quic在突破权威障碍方面有很大的进步，不仅是通过将其置于UDP之上以通过防火墙，而且还通过与TLS1.3的非常牢固的结合，TLS1.3将隐私最高拨到11：除了Quic包的第一个字节之外，所有东西都是加密的。

当局不会喜欢这样的，我很容易看到更多的专制国家彻底禁止Quic，为了让这一禁令生效，他们甚至可能从“如果不禁止就允许”过渡到“如果不允许就禁止”防火墙。

当然，如果你足够大，可以与七国集团规模的政府谈判，那么Quic仍然是一个问题，如果Quic最终成为一个可行的协议，只适用于那些可以指出他们的数据中心提供的“创造就业”的公司，我也不会感到惊讶。

我们其余的人将不得不拭目以待，看看这会把我们带到哪里。

Quic和Varnish¶

我可以肯定地说，从头开始编写Quic实现(包括TLS 1.3)是不可能的，这根本不可能发生。

这基本上只剩下三个选择：

将TLS库链接到Varnishd的前提条件是私钥/证书仍然隔离在不同的地址空间中，目前称为“无密钥TLS”。

好消息是，Quic正是为实现这一目标而设计的 [3] 。坏消息是，据我所知，没有一个可用的Quic实现可以做到这一点，至少现在还没有。

我们可以采用的Quic实现的实际选择非常短，由于我不太倾向于使Go或Rust成为Varnish的依赖项，它很快就会变得更短。

目前，H2O项目 quicly 可能是我们最明显的候选者，但即使这样也会有大量的工作，而且在他们设置代码质量标准和我们设置我们的代码质量标准之间存在一些空间。

然而，选择编写我们自己的Quic而不是采用一个Quic是一项大量的工作，至少对于必要的测试来说是如此，所以在其他条件相同的情况下，采用听起来更可行。

如果Quic/H3真的成为新的黑色，我们将放弃在第三条线上的能力，我们将有责任确保我们使用更丰富的代理协议或可能的“裸体”Quic来尽可能好地使用这些“前置”设备，以保持功能。

置身事外的一个理由是，我们的“在瓦尼什不使用TLS”政策看起来是正确的决定。

虽然小型站点不得不运行两个进程是不方便的，但一旦站点增长，反馈就变成了对TLS与策略/缓存的解耦的赞赏，并且一旦站点变得更大，或者更多地暴露在GDPR中，使用不同的TLS减载器的能力被视为一大好处。

最后，还有测试的小细节：Varnishtest，它有自己的 VTest project 现在，我需要学习HTTP3，Quic，可能还有TLS。

当然，当我们问Varnish的用户时，他们说 "Ohhh... they all sound delicious, can we have the buffet ?" ：-)

phk

脚注