哈伯，你好！ 这是Artyom ximaera Gavrichenkov的报告的抄录，他在RIT ++艺术节上于BackendConf 2018上阅读了该报告 。
你好
报告的标题包含一长串协议，我们将逐步进行讨论，但让我们从标题中未包含的内容开始。
某个博客的标题（在删节之后），在Internet上您可以看到很多这样的标题。 在那篇文章中写道，HTTP / 2并不是遥不可及的未来，这是我们的当下。 这是由Google和许多先进公司的数百名专业人员开发的现代协议，由IETF于2015年（即3年前）发布为RFC。
实际上，IETF标准已为业界所接受，例如诸如墓碑之类的钢筋混凝土文件。
他们计划确定Internet的发展并考虑所有可能的使用方案。 也就是说，如果我们有一个旧版本的协议，然后又出现了一个新版本，那么它肯定会与以前的所有用例保持兼容性，并且还解决了许多问题，优化了工作等等。
HTTP / 2必须适合高级Web，可以在现代服务和应用程序中使用，实际上，必须直接
替换旧版HTTP协议。 本来可以提高网站的性能，同时减少后端负载。
甚至SEO都说他们需要HTTP / 2。
而且似乎很容易支持。 特别是，来自BBC的Neil Craig在他的博客中写道，仅在服务器上启用它就足够了。 您仍然可以找到许多演示文稿，其中说包括HTTP / 2，如下所示：如果您拥有Nginx，则可以将配置固定在一个位置； 如果没有HTTPS，则需要另外添加证书； 但是，原则上，这只是配置文件中一个令牌的问题。
而且，当然，在注册此令牌后，您会立即开始从提高生产力，新的可用功能和机会中获得好处-总的来说，一切都会变得美好。
幻灯片链接：
1. medium.com/@DarkDrag0nite/how-http-2-reduces-server-cpu-and-bandwidth-10dbb8458feb
2.www.cloudflare.com/website-optimization/http2进一步的历史基于真实事件。 该公司有一些在线服务，每秒处理大约500-1000个HTTP请求。 该服务受Cloudflare的DDoS保护。
有许多基准测试可以确认，切换到HTTP / 2可以减少服务器的负载，这是因为切换到HTTP / 2时，浏览器不会根据计划建立7个连接，而是建立一个连接。 预计当切换到HTTP / 2时，使用的内存将减少，处理器的负载将减少。
另外，Cloudflare博客和Cloudflare网站建议一键启用HTTP / 2。 问题：为什么不这样做？
在2018年2月1日，该公司在Cloudflare中包括带有此按钮的HTTP / 2，并且在本地Nginx上也包括了该按钮。 收集月份数据。 在3月1日，将对消耗的资源进行测量，然后sysops会查看日志中通过HTTP / 2向Cloudflare后面的服务器发送的请求数。 下一张幻灯片是通过HTTP / 2到达服务器的请求的百分比。 举手，谁知道这个百分比是多少？
[听众：“ 1-2％！”]
-零 出于什么原因？
Cloudflare以及其他攻击防护服务，MSSP和云服务均以
反向代理模式运行。 如果在正常情况下浏览器直接连接到您的Nginx，即连接直接从浏览器连接到HTTP服务器，则可以使用浏览器支持的协议。
如果浏览器和服务器之间存在云，则传入的TCP连接将在云中终止，TLS也将在其中终止，并且HTTP请求首先发送至云，然后云将实际处理此请求。
云具有自己的HTTP服务器，在大多数情况下是相同的Nginx，在极少数情况下，它是“自写”服务器。 该服务器解析该请求，以某种方式处理该请求，咨询高速缓存，最终形成一个新请求，并使用其支持的协议将其发送到您的服务器。
所有声称支持HTTP / 2的现有云都在浏览器一侧支持HTTP / 2。 但不要在朝你的那一边支持他。
怎么了
一个简单但并非完全正确的答案：“因为在大多数情况下，它们已经部署了Nginx，并且Nginx无法通过HTTP / 2到达上游。” 好的，这个答案是
正确的 ，但并不
完整 。
完整的答案由Cloudflare工程师提供给我们。 实际上，2015年编写和发布的HTTP / 2规范的重点是提高特定用例（例如Google）的浏览器性能。
Google使用自己的技术，不在生产服务器前使用反向代理，因此没有人考虑过反向代理，这就是为什么不使用从云到上游的HTTP / 2的原因。 实际上，那里的利润很少，因为在反向代理模式下，例如，不支持使用HTTP / 2协议中描述的HTTP / 2协议，因为尚不清楚在进行流水线处理时应该如何工作。
HTTP / 2保存连接的事实很酷，但是仅反向代理保存它们，因为它不会为每个用户打开一个连接。 这里支持HTTP / 2毫无意义，并且开销和与此相关的问题很大。
重要的是：反向代理是一项大约在13年前开始积极使用的技术。 也就是说，这是2000年代中期的技术：我已经在使用它时去上学了。 IETF的httpbis工作组目前未在2015年发布的标准中提及该标准，也不支持该标准。
这是人们开始实施HTTP / 2时出现的问题的一个示例。 实际上，当您与已经部署并且已经有一定经验的人交谈时，您会经常听到相同的词。
最好由Badoo的Maxim Matyukhin在Habré的
一篇文章中提出，他在其中谈到了HTTP / 2 Server Push的工作方式。 他写道，他非常惊讶于此特定功能与浏览器的交互有多么不同，
因为他认为该功能是一项完全开发的功能，可以在生产中使用 。 我已经多次听到与HTTP / 2有关的这个短语：我们认为这是一个即插即用的替换协议-也就是说，您打开它，一切都很好-为什么在实践中一切都如此复杂，为什么所有这些问题都来自于此和缺陷？
让我们弄清楚。
从历史上看，Internet的体系结构看起来像这样。 在某个时候没有绿色矩形，但是随后出现了。
使用了以下协议：由于我们是在谈论Internet，而不是在谈论本地网络，因此在较低级别，我们从IPv4开始。 在其上方使用了TCP或UDP协议，但在90％的情况下（因为Internet上80-90％的流量是Web），其次是TCP，然后是SSL（然后由TLS代替），以上是HTTP超文本。 逐渐发展起来的情况是，根据该计划，到2020年，互联网的体系结构应该发生根本性的变化。
IPv6已经存在了很长时间。 TLS最近已更新，我们将继续讨论它是如何发生的。 并且HTTP / 2协议也已更新。
在飞地周期中，出色的家庭科幻小说家瓦迪姆·帕诺夫（Vadim Panov）曾说过这样
一句话 ：“您在等待未来。 你想要未来吗？ 它来了。 你不想他吗？ 无论如何它都来了。” 直到几年前，几乎没有发生变化的唯一事情就是TCP协议。
从事Internet设计的人们无法避免这种公然的不公，因此也决定抛出TCP协议。
好吧，这当然是个玩笑。 问题不只是协议太旧了。 TCP中存在缺陷。 令许多人特别担心的是，已经编写了HTTP / 2协议，已经在实施2015年标准，但它并不总是专门与TCP配合使用，最好在其下放置一些其他传输方式，更适合曾经使用的传输方式。在这些对话进行时调用SPDY，然后调用HTTP / 2。
该协议决定调用QUIC。 QUIC是当前正在开发的用于传输的协议。 它基于UDP，即
数据报协议。 该标准的初稿于2016年7月发布，当前的草案版本...
[发言人检查电话中的邮件]“ ...是的，仍然是第十二名。”
目前，QUIC还不是标准-它是积极编写的。 如果我没有记错的话-因为害怕害怕犯错，所以我没有在幻灯片上写-但在伦敦的IETF 101大会上，有人说计划在2018年11月之前将其发布为最终文件。 它是QUIC标准本身，因为在文档工作组中还有
八个文档。
也就是说，尚无标准，但积极的炒作已经在进行中。 我只列出了过去六个月来我参加过的那些会议，至少有一个关于QUIC的演讲。 关于“它有多酷”，“我们需要如何切换到它”，“为操作员做什么”，“停止过滤UDP-QUIC现在将通过它进行工作”。 所有这些炒作已经进行了相当长的时间-我已经看过很多文章，敦促游戏行业转向QUIC而不是通常的UDP。
幻灯片链接：
1. Conferences.sigcomm.org/imc/2017/papers/imc17-final39.pdf
2. blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop2017年11月，以下链接出现在QUIC工作组的邮件列表中：顶部是白皮书，底部是那些难于阅读白皮书的人-这是指向APNIC博客的摘要链接。
研究人员决定比较当前形式的TCP和QUIC的性能。 为了进行比较，为了不对谁负责，以及Windows应该在哪里负责，他们在客户端上使用了Chrome for Ubuntu，还使用了2种移动设备：一个Nexus和一些三星
（编者注： Nexus 6和MotoG）以及Android 4和6版本，他们还推出了Chrome。
在服务器端，他们安装了Apache以查看TCP服务器的工作方式，并且为了监视QUIC，他们撕下了Chromium项目中的一部分开源代码。 基准测试结果表明，尽管在所有温室条件下，QUIC的性能均确实胜过TCP，但仍有一些基石可能会丢失。
例如，如果在网络上发生数据包重新排序，也就是说，数据包以错误的顺序发送（由服务器发送），则Google的QUIC实施的效果明显比TCP差。 在2017-2018年，在移动和无线网络时代，通常无法保证该程序包原则上可以运行，更不用说以什么顺序运行了。 QUIC在有线网络上运行良好，但是谁现在使用有线网络？
通常，谷歌中此代码的开发人员显然并不喜欢手机。
QUIC是在用户空间中的UDP之上实现的协议。 以及在移动设备以及用户空间中。 根据测量结果，在正常情况下，即通过无线网络工作时，在“应用程序受限”状态下，QUIC协议的实现花费了Android中58％的时间。 这是什么情况 这是我们发送一些数据并等待确认时的状态。 作为比较，在台式机上这个数字约为7％。
只有2个用例：第一个是无线网络，第二个是移动设备；第二个是移动设备。 QUIC既可以用作TCP，也可以更糟。 很自然，这是在致力于QUIC的IETF工作组中进行的，自然，谷歌对此做出了反应。 Google的回应如下：
mailarchive.ietf.org/arch/msg/quic/QktVML_qNDfqjIGirj4t5D0JRGE好吧，我们笑了，但实际上这绝对合乎逻辑。
怎么了 因为QUIC的设计-尽管我们已经在谈论生产中的实现，但是-实际上，这是最疯狂的实验。
例如，这是一个七级ISO / OSI模型。 谁在这里记得她？ 还记得这些级别：物理，通道，网络，传输，一些废话，一些废话和应用吧？
是的，它是很久以前开发的，以某种方式我们使用了这种关卡模型。 QUIC是消除网络层系统本身的实验。 它结合了加密，传输，可靠的数据传递。 所有这些都不在层结构中，而是在合并中，其中每个组件都可以访问其他组件的API。
引用了QUIC协议的
一位设计师 Christian Guitem的话：“从架构的角度来看，QUIC的主要优势之一是没有层次结构。” 我们拥有确认，流控制，加密和所有加密功能-所有这些都完全在一种传输中，而且我们的传输创新意味着所有这些都可以直接访问网络API，因此我们不希望QUIC中有分层的体系结构。
在工作组中开始讨论此问题的原因是，在3月初，另一个QUIC协议设计者Eric Rescorla决定提议讨论一个变体，该变体通常将所有加密都从QUIC中删除。 剩下的就是在DTLS之上运行的传输功能。 反过来，DTLS是基于UDP的TLS，总的来说：基于UDP的TLS的QUIC。
这样的报价从哪里来？ 顺便说一句，Rescorla写了一个大文件，但根本没有成为标准-这是一个讨论的主题，因为在设计QUIC架构的过程中，在测试互操作性和实现的过程中，出现了很多问题。 主要与“流0”有关。
QUIC中的流0是什么？ 这与HTTP / 2中的想法相同：我们有一个连接，在内部有几个多路复用流。 我记得，通过设计QUIC，加密是由同一协议提供的。 这样做如下：打开一个“魔术”流编号0，它负责建立连接，握手和加密，此后对该流0进行加密，所有其他流也进行加密。 随之而来的是很多问题，它们列在邮件列表中，共有10个项目，我不会一一列举。 我只会选出我最喜欢的一个。
www.ietf.org/mail-archive/web/quic/current/msg03498.html线程0（其中之一）的问题是，如果丢失数据包，则需要重新发送它们。 同时，例如，在服务器端，连接可以已经标记为已加密，丢失的数据包可以追溯到未加密的时间。 在这种情况下，转发时，实现可能会随机加密数据包。
再一次：
随机加密数据包。除了讲述所有这些是如何实际设计的之外，很难对此发表评论。 QUIC开发实际上使用ersatz-agile方法。 也就是说，并不是有人编写了钢筋混凝土标准，而该标准可以在几次迭代后正式发布。 不行
工作如下：
1.标准草案开始于例如5。
2.在邮件列表以及IETF会议上-每年进行三场讨论-进行讨论，然后在黑客马拉松上进行实施，互操作性测试并收集反馈；
3. Google在自己的基础架构中实现了Chrome的某些更改，分析了后果，然后增加了计数器并显示标准6。
现在，我提醒您，版本12。
注意事项 编者：截至2018年7月10日， 已经是13日了。这里重要的是什么？
首先，我们只是看到了缺点，但也有优点。 实际上，您可以参与此过程。 收集了所有参与方的反馈：如果您参与游戏，如果您认为自己在游戏行业中可以简单地更改和更改UDP，而是设置QUIC，那么一切都会正常进行-不，不会。 但是目前您可以影响它，可以以某种方式使用它。
这实际上是一个普通的故事。 希望收到您的反馈，每个人都希望看到它。
Google正在开发一种协议，并在其中添加了一些想法-用于其自身目的。 做其他事情的公司（如果不是典型的Web，游戏或移动应用程序，则SEO相同），则默认情况下，他们不能期望该协议考虑到他们的利益：不仅因为它对任何人都不感兴趣，而且因为没有人知道这些利益。
顺便说一句，这是供认。 当然，对我来说，问题是，为什么我们（特别是
Qrator Labs）没有参与HTTP / 2协议的开发，也没有向任何人介绍反向代理。 但是相同的Cloudflare和Nginx也没有参加。
尽管该行业不参与其中，但Google，Facebook，其他一些公司和
学者正在发展。 众所周知，在接近IETF的聚会上，“学者”一词是不值得称赞的。 听起来像是“精神分裂症”和“震颤症”。 人们来往往没有任何实际目标，也没有理解真正的任务，但是却能适应其中，因为获得博士学位论文比较容易。
当然，必须参与其中，没有其他选择。
回到QUIC：因此，该协议是在用户空间中实现的，在移动设备上存在……等等。 “已在用户空间中实现。” 让我们来谈谈。
在提出QUIC之前，我们通常如何安排运输？ 现在在生产中如何运作？ 如果我们谈论的是Web，则有一个TCP协议。
在TCP中，存在
三重握手 ：SYN，SYN / ACK，ACK。 它在许多方面都是必需的：防止服务器被用来攻击其他服务器，成功过滤对TCP协议的某些攻击，例如
SYN Flood 。 只有经过三次握手的3个段之后，我们才开始发送数据。
同时，有4种动作，其中3种发生在内核中，它们非常有效地发生，并且在建立连接时数据已经进入用户空间。
在QUIC的情况下，所有这些快乐都在用户空间中。
这里有一个星号，因为那里的术语并不完全是“ SYN，SYN / ACK”，但实际上，这是一次完全移到用户空间的握手。如果在TCP之前以及之前在TCP中有20 Gbit / s的泛滥速度，它们可以在SYN cookie中在内核中进行处理，那么现在它们需要在用户空间中进行处理，因为它们通过整个上下文切换在整个内核中飞行。而且那里需要某种方式的支持。为什么要这样做？为什么QUIC是用户空间协议？尽管是运输，但对于他来说，这似乎是系统级别的某个地方。
再次因为这是Google和其他团队成员的利益。他们希望看到新的协议已实现，他们不想等到该区域中的所有操作系统都更新后。如果在用户空间中实现，则可以立即使用（特别是在浏览器中，但不仅限于此）。您需要在服务器端花费大量资源这一事实对于Google而言并不是问题。某处有句好话说，为了解决现代Internet后端的大多数性能问题，Google只需要没收一半服务器（最好是四分之三）。这并非没有常识，因为确实没有将Google换成这样的琐事。
www.ietf.org/mail-archive/web/quic/current/msg03736.html屏幕上显示的是QUIC邮件列表的文字引号，其中的讨论仅是计划在用户空间中实施该协议。这是一个字面意思：“我们希望将QUIC部署到任何没有操作系统支持的计算机上。如果有人遇到性能问题，他们将把所有问题都带到核心。” QUIC已经非常松散，以至于无法通过加密和其他所有功能将其带入核心，但是与此主题相关的工作组也并不特别担心。
以及为什么在客户端使用这种方法-我可以理解。但是在服务器端使用相同的方法。从理论上讲，在这种情况下，QUIC确实值得作为核心，但再次，这项工作仍在进行中，完成后，我们充其量只能是白发苍苍，而我也不打算永远活下去。当这种情况发生时-还不是很清楚。在谈到Linux内核时，不能不提到存在QUIC的主要原因之一是它是在轻量级UDP协议之上实现的，因此它可以更高效，更快速地工作...以及总的来说，为什么我们需要如此庞大的TCP。
vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf这是基准的另一个链接。事实证明，向Linux发送UDP数据报比发送TCP流更昂贵，更昂贵。有2个主要点（即很多点，但只有两个主要点）：1.对于UDP数据报，搜索路由表花费的时间更长；2.一块称为“大段卸载”。在TCP中，我们可以简单地将一个大数据流上传到传输中，而不必在CPU上将其拆分为多个段，而在UDP中，我们需要准备每个数据报，而没有流。目前，内核开发人员正在考虑如何处理它，但是目前，TCP基本上在发送不适合一个数据包的大数据，这比QUIC所基于的UDP更有效。
www.ietf.org/mail-archive/web/quic/current/msg03720.html再次引用Google员工的话，特别是我也问他这个问题。毕竟，我们可以尝试责怪Linux，例如在Windows下，也许一切都还不错，但是没有。据称，在Google部署QUIC的任何平台上，针对TCP流发送UDP数据包（从中央处理器的角度来看）存在成本增加的问题。也就是说，不仅是像这样的Linux，而且是通用方法。
这使我们想到了一个简单的想法。不要再谈论QUIC。够了摆脱这里的简单想法是，在实现任何新协议而不是旧协议之前：HTTP / 2与HTTP / 1.1，QUIC代替TCP，DNS加密，IPv6代替IPv4 ...在决定和布局之前要做的第一件事生产当然是基准测试。不要相信任何说协议“您可以更改/启用/按下按钮”的人- 不！这将永远不会发生-永远不会发生，将来也永远不会发生，而且没人能保证。因此，只有一个基准，当然，如果您不这样做，而只是部署一些东西，那么当然，没有人会为您提供高质量的保证。
顺便说一下，关于IPv6。事实是，在IPv6诞生之时，协议是以某种更为直接的方式开发的，也就是说，没有敏捷技术。但是他们在Internet上的适应仍然花费了大量的时间。而且，目前，它仍在进行中，对于IPv6，它仍处于10-20％的水平。而且，根据国家的不同，因为在俄罗斯甚至更低。在实施IPv6的过程中，解决了许多问题。谁知道快乐眼球是什么？通常，当现场用户抱怨时，与IPv6相关的问题很多。假设您关闭笔记本电脑，离开拥有IPv6的房子，来到没有IPv6的咖啡馆，打开笔记本电脑-没有任何效果，因为浏览器和操作系统缓存继续查看IPv6，但是没有本地连接。发明了一种称为“快乐眼球”的方法（也是IETF发行的标准）：如果在0.3秒内我们没有找到IPv6连接，则无法连接，我们回滚到IPv4。拐杖，但它似乎几乎总是起作用，但是！实施中的神秘问题不断出现。尤其是由于某种原因，iPad最受欢迎的问题之一是iPad从IPv6切换到IPv4的速度比0.3秒慢得多：大约1秒，甚至1分钟。甚至在某个时候，布拉格的IETF 99上都出现了一个疯狂的提议：“如果问题发送出一些东西，则可以通过syslog将快乐的眼球传到每个网络上的中央服务器上。”从所有连接的设备收集系统日志-当然，没有人同意这一点。但这表明存在许多问题。其他问题是与各种恶意活动作斗争，因为IPv6中的本地网络是/ 64，并且攻击者可以开始对很多地址进行分类，保护需要及时聚合它们，以及所有这些。必须以某种方式处理它，所有这些都必须实现。结果，我们仍然遇到实现问题，这不仅体现在有人在缓慢地实现IPv6的事实。不，他们开始再次关闭它。返回到IPv4。因为即使没有问题，也很难证明过渡到管理的好处，但是如果在启动后用户也开始抱怨，那就足够了。这是一个这样的例子，即使为实现而开发的协议仍然会引起最严重的实现问题，这些问题在技术部门的头疼中体现出来。想象一下，实现在其各自用例中未设计用于大规模实现的协议时会发生什么。
blog.apnic.net/2018/02/26/peak-dnssec关于此主题的另一个示例是DNSSEC。我不会要求您举手找出谁拥有它，因为我知道没有人拥有它。一方面，IPv6部署正在发展，另一方面，它存在问题，但至少它正在到来。自去年年底以来，全球DNSSEC的实施速度有所放缓，并且方向相反。在此图中，我们使用验证DNSSEC的解析器查看了每天的Internet用户数（由APNIC Labs测量）。看跌趋势在这里非常明显：从最后一个高峰开始，这个高峰是2016年10月。DNSSEC有一个目标，有正确的任务，但实际上已停止部署，并且某种反向过程已经开始，尚待研究。这个过程是从哪里来的。
datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-01通常，DNS存在很多问题。IETF dnsop工作组现在有3位主席，其中15份所谓的“运行中”草案：他们准备作为RFC发布。尤其是DNS，学会了在一切之上进行传输。在TCP之上，它工作了很长时间（但是人们仍然需要展示如何正确进行操作）。现在他们开始在TLS，HTTPS，QUIC上运行它。在人们开始意识到这一切之前，所有这些看起来都非常美妙，并且直到第五点他们才开始受到伤害。2017年3月，OpenDNS开发人员为IETF带来了一个名为“ DNS骆驼”的演示文稿或“ camel dns”。演示归结为以下想法：在下一根小树枝断裂之前，我们还能装载多少骆驼（又名DNS协议）？这是我们现在如何看待设计的通用方法。添加了功能，功能很多，它们以不同的方式相互干扰。并非总是以可预测的方式，并且实现的作者也不总是了解所有可能的干扰点。每个此类新功能的实施，实施，生产中的实施-在发生此类干扰的每个位置添加一组潜在的故障点。没有基准，就没有监控-无处可去。
为什么参与整个过程很重要？因为IETF标准-“ RFC”-仍然是标准。有这么好的统计数据：各种版本的SSL和TLS加密协议的开发时间表。请注意，SSL版本控制从2开始，因为0.9和1.0版本从未在生产中发布，因此它们的泄漏程度比Netscape所能承受的泄漏得多。因此，故事始于一年开发的SSL 2.0协议。然后一年又开发了SSL 3.0。然后TLS 1.0被开发了三年。版本1.1-7年； 1.2仅开发了2年，因为没有太大的变化；但最新的版本，发布于今年三月- 27日草案，顺便说一句-开发10年。在相应的工作组中，有时会对此话题产生很大的恐慌，因为事实证明，TLS 1.3破坏了许多用例，尤其是在金融机构中，其监控和防火墙。但是，即使像美国银行这样的大公司也无法改变这一点，因为它已经在第十八次草案阶段就已经意识到。他们没有时间对此做任何事情，因为当大家都已经收到帐单时，当您参加聚会时，您不能指望继续玩乐的提议会得到理解。因此，如果在某些协议中-这又是一个需要反馈的问题-有/将会/有些不适合您的功能，唯一的选择是及时跟踪并及时进行干预，否则它将被发布并必须围绕此建立拐杖。
实际上，在幻灯片上，这是整个过程的三个主要结论。第一：正如我所说，在“调整某些东西”配置中引入新协议并不容易。这是一个计划的实施计划，是带有强制性基准的适当性评估，因为实际上它都会起作用。第二点：协议不是由外星人开发的，它们不是从上方提供给我们的，您可以并且应该参与此过程，因为没有人会为您推广用户案例。第三，确实是：需要反馈。最重要的是，Google本身并不是邪恶的，它只是追求自己的目标，它没有为您和您开发协议的任务，只有您才能做到。因此，在一般情况下，尽管博客中有许多赞美文章，但引入新内容而不是旧内容是要从以下事实开始的：您不仅需要投资于部署，还需要在协议设计过程中进行投资，了解其工作原理，然后才做出明智的决定。谢谢你