（蔡维德）区块链互联网需要新协议

2019-01-14 天德信链 蔡维德等 区块链互联网系列(1)TCP 端到端设计又旧又多毛病

2019-01-15 天德信链 蔡维德等 区块链互联网系列(2)区块链互联网需要新协议

在前一篇文章[1]中，我们讨论了TCP端到端设计在基本面上的缺点。 在本文中，我们分析TCP的低性能问题以及当前改进它的一些方案。这些种改进方案仍然不够完善，新的第4层协议产生巨大进步的空间是敞开的。

许多人在设计区块链的时候都是先研究比特币或者以太坊数字代币系统，然后在上面改进。但是我们过去多次讲到，要设计金融区块链要从PFMI《金融市场基础设施建设原则》开始，这会带领出一个新一代的区块链系统。

这个新的一代的区块链系统跟传统的区块链系统不一样。PFMI是许多国家央行都认可的金融系统设计原则，包括中国人民银行，英国央行，法国央行，加拿大央行，日本央行，欧洲央行。另外加拿大央行，欧洲央行，和日本央行还使用PFMI来评估区块链在央行系统实验，在2017-2018年出台几份重要报告，指明区块链发展的方向， 同时间这些报告也给区块链信心。

根据PFMI，

• 交易是有时效的，就是说交易不能拖的太长。不能够跟数字代币一样等很久后才能结算。
• 交易也应该可以回滚的（传统数字代币不能回滚），
• 并且交易可以被监管的（现在数字代币却是逃避监管的）。

这些都是以前数字代币不需要考虑的问题。因此金融区块链和数字代币的区块链设计大不相同。

区块链互联网（链网）也必须是支持PFMI，因为上面的交易必须符合PFMI。但是按照原来TCP的RTT设计，这不会符合PFMI。

• 第一，TCP延迟跟吞吐量正好成反比（在金融市场这是不能的），

• 另外一个更加严重问题是因为在区块链上面，链与链之间是必须互相担保的，每个链必须担保它上面的资产是真实的可以做交易的。这代表链和链之间必须有共识，而现在共识必须经过TCP，现在端到端设计的TCP能支持符合PFMI的共识机制吗？如果不行，如何设计下一代的协议来支持符合PFMI的区块链？

• 另外在金融市场做交易的时候，如果发现问题，监管单位可以阻止这个交易通过。这代表说监管单位使用的监管链的性能要超过交易链的性能！

• 监管链也需要有大数据的支持，能够很快的分析出来这个交易可否被通过。监管网需要什么协议？这是一个研究问题。

如果TCP协议被改变的话，互联网基础设施将会有巨大变化，这个变化将带来一个新的互联网研究和部署的新潮流、新风口。但这只会是一个起步而已，因为除了在互联网上的改变，还有金融，法律，数字社会等的改变，这些都会带来同等级的巨大颠覆。

TCP的E2E迭代非常慢

TCP是基于最真实意义上的E2E原理设计的：发送方根据从接收方收到的反馈信号计算其“公平份额”的速率。但是TCP的计算是通过一个迭代程续来完成，而每个迭代至少需要一个往返时间（RTT）。如果需要n次迭代的TCP反馈信号，则收敛到最佳速率所需的总时间将至少为n * RTT。这是一种不可接受的时间浪费和TCP严重低性能的原因。

这种E2E迭代存在2个问题。

• 首先，TCP路径中拥塞的动态变化可能比RTT时间尺度快得多。当TCP算出“最佳”速率时，真正的拥塞情况可能已经改变。 E2E计算方法仅在路径中的拥塞比RTT长得多的时间尺度时才有用。例如，如果路径中的拥塞在1毫秒的时间范围内发生变化且RTT大约为10毫秒，那么TCP发送器总是落后于真正的拥塞情况，所以TCP发送器永远无法达到适当的TCP速率。
• 其次，E2E计算模型效率极低。从纯计算的角度来看，算法的每次迭代都应该是CPU时钟速度的函数;这样可以在CPU变得更快时更快地完成计算。但是，E2E TCP计算不是CPU时钟的函数，而是RTT的函数。 RTT与两个终端系统之间的物理距离大致成比例。由于光速是恒定的，E2E RTT不会因CPU速度而有所改变；这是一个非常糟糕的计算范式。

图1：E2E TCP迭代

网内迭代比TCP迭代快至少2n倍

一旦我们摆脱了E2E计算范式，将导致计算速度的显著提高。例如，新的算法在靠近瓶颈链路的位置计算发送方的最佳吞吐量。在瓶颈链路处或附近，可以容易地获得关于瓶颈处的拥塞的信息。该计算应该通过当地计算设备的迭代来完成。一旦计算出最佳速率，它将被传送到2个端点（发送方和接收方）。通过网络内计算，新的第4层协议将适应更快的拥塞动态。今天的CPU速度够快，与发送到2端所需的时间相比，达到最佳速率所需的计算时间可以忽略不计。因此，新速率的影响仅延迟最多 ½ RTT（可以短至 ¼ RTT），这明显快于n * RTT（其中n是TCP计算其最佳速率所需的迭代次数）。以下简单的图表说明了网内计算模型：

图2：网内迭代

与RTT成比例的TCP速率降低是不可接受的

在E2E设计下，TCP允许发送器在从接收器接收到ACK（确认）包之后才发送数据包。由于这种机制，TCP的吞吐量与发送方和接收方之间的RTT成比例下降。TCP的缓冲区控制就是仅当接收方有可用的缓冲区空间时，才允许发送方发送数据包。这种缓冲区控制太过于保守：仅当接收器确认将释放缓冲空间时，才确保发送器能发送数据包。 然而今天的接收器处的缓冲区管理是一个复杂的过程，并且通常有足够的空间来接收新的数据包。

理想的第4层协议应该如此设计：无论发送方和接收方之间的RTT大小如何，2端系统的速率都能够使用全线速度。 理想情况如下图3所示：

图3：第4层会话的理想吞吐量

但是，众所周知，TCP吞吐量与RTT成比例下降[2]。

通过不当使用控制理论改进TCP

最近改进TCP的方法是由谷歌提的BBR算法。 BBR是由谷歌的TCP团队与TCP的传奇人物Van Jacobson一起设计的。BBR的吞吐量可以达到CUBIC（目前TCP 的标准变种）的2到25倍。但是，BBR 并没有摆脱E2E反馈，因此，其吞吐量仍然决定于RTT。它的改进是基于控制理论中的确定性等价原理，这是一个50年前的老旧理论。 在确定性等价方法中，随机变量由它们的平均值代替。BBR算法将瓶颈处的队列建模为确定性队列，队列的输入和输出均表示为恒定速率进程。由於忽略实际系统中的随机性，BBR的重大缺陷是过度重传，正如Tierney和Hanford所示：BBR过度重传[4]

图4：BBR过度重传

从该表中，BBR的重传可以是HTCP（H-TCP;TCP的另外的变种）重传的320倍（对于远程主机ps1.jpl.net）。 这种过度的重传是不可接受的，并且导致带宽被大规模浪费。

适当使用控制理论改进TCP

虽然谷歌的BBR是对TCP的一个不错的改进，但它使用了不正确的控制方法设计。更好的方法是在TCP的缓冲区控制中摆脱E2E反馈。

图5：FileCatalyst吞吐量与RTT 无关

图5：FileCatalyst吞吐量与RTT 无关 [5]

FileCatalyst[5] 是开发了TCP的代替协议的少数几家公司之一。这些公司摆脱了TCP的E2E缓冲控制，而并没有在路径中添加中间节点。一个明显的结果是它们的文件传输时间与发送方和接收方之间的距离无关。这表明E2E缓冲区控制是TCP吞吐量依赖于RTT的原因。FileCatalyst[5] 结果表明，新的协议可以胜过TCP 1000倍以上：例如，从伦敦到悉尼，改进大约是2500倍。

但是以上这些出色的改进结果，只有当路径具有最小的背景流量时才能获得。如果发送方和接收方不通过专用线路进行通信，那么这些改进就不存在了。根本问题是当路径通过常规互联网时，这些供应商仍然使用类似TCP的拥塞控制。

理论上，一个使用真正的控制理论的第4层协议应该能平衡得分开缓冲控制和拥塞控制。完成此操作后，即使路径与互联网中的众多流量流共享，也可以获得FileCatlayst结果。

这表示传统TCP是可以大大改进的！这表示我们是有可能设计新协议来支持新的互联网应用。

问题是这些改进的TCP还是不足够支持链网。链网需要的技术比改进的TCP（例如有限制的FileCatalyst 协议）还要难的多，困难的地方在于链网需要支持区块链服务（包括跨链服务）和高性能传输，而目前改进的TCP只能提高某些网络传输的速度。最主要的是，如果需要设计一个新协议，需要一个新的思考框架，而不是在以前的框架上提出改进的方法。

参考文献

[1].蔡维德等,“区块链互联网需要新网络协议”, 2019.1.14，https://mp.weixin.qq.com/s/NtM7jHfxq1rsIAO0i7cEBg

[2].Mathis, Semke, Mahdavi & Ott, “The Macroscopic Behavior of TCP Congestion Avoidance Algorithm,” Computer Communication Review,27(3), July 1997

https://www.slac.stanford.edu/comp/net/wan-mon/thru-vs-loss.html

[3].Cardwell, Cheng, Gunn, Yeganeh, Van Jacobson,” BBR: Congestion-Based Congestion Control,” ACM Queue,vol.,Sept-Oct 2016

https://queue.acm.org/detail.cfm?id=3022184

[4].Tierney, Hanford, “Recent Linux TCP updates, and how to Tune your 100G Host,” Nov 2016

https://scinet.supercomputing.org/workshop/sites/default/files/100G-Tuning-INDIS.tierney.pdf

[5].FileCatalyst white paper: “Accelerating File Transfers,” Jan 2019

https://filecatalyst.com/wp-content/uploads/2018/07/Accelerating_File_Transfers.pdf