的核心问题之一并且随着互联网和数据中心流量的爆炸式增长相关算法和机制出现了很多创新本系列是免费电子书《TCP

Congestion

Approach》的中文版完整介绍了拥塞控制的概念、原理、算法和实现方式。

原文:

TCP

随着对拥塞控制的探索不断深入出现了许多新的算法和协议与我们前几章中所介绍方法的主要不同之处在于它们大多数都针对特定用例优化而不是TCP所支持的任意复杂度的异构网络环境。

QUIC可能是个例外其最初目标是提升HTTP的性能但现在已经发展成为一种通用的TCP替代方案。

本章将介绍其中某些具体用例但并没有详尽包含所有可能选项。

这些用例包括数据中心TCP性能调优在较长时间段内仅用剩余容量传输背景流量非TCP兼容的基于HTTP的web流量优化以TCP友好的方式支持实时流支持多路径传输协议以及具有独特无线电诱导行为的移动蜂窝网络。

7.1

有一些针对云数据中心的TCP优化工作其中之一是数据中心TCP(Data

Center

数据中心环境的几个特点使我们可以采用不同于传统TCP的方法这些特点包括:

这些流量与高带宽流竞争

应该注意的是DCTCP不仅仅是TCP的一个版本而是一种改变交换机行为和终端主机对从交换机接收到的拥塞信息的响应的系统设计。

DCTCP的核心观点是在数据中心环境中使用丢包作为拥塞的主要信号是不够的。

当队列已经积累到足以溢出时低延迟流量已经无法满足其最低需求因此会对性能产生负面影响。

DCTCP使用ECN的一个版本来提供拥塞的早期信号。

但是ECN的原始设计将ECN标记处理得很像一个丢包并将拥塞窗口缩短一半而DCTCP采用了一种更精细的方法。

DCTCP试图估算遇到拥塞的字节比例而不是简单判断拥塞是否发生。

然后根据这个估算缩放拥塞窗口。

同时标准TCP算法仍然在数据包实际丢失的情况下发挥作用。

该方法的设计目的是通过提前对拥塞做出反应来保持队列较短同时不对空队列做出过度反应避免牺牲吞吐量。

该方法的关键挑战是估算遇到拥塞的字节比例。

对于每个交换机来说计算都很简单如果一个包到达并且交换机看到队列长度(K)超过某个阈值例如,

其中C是每秒数据包的链路速率然后交换机设置IP报头中的CE位。

该算法避免了RED的复杂性。

然后接收器为每个流维护一个布尔变量我们将其表示为DCTCP.CE并将其初始值设置为false。

当发送ACK报文时如果DCTCP.CE为true接收端会在TCP报头中设置ECE

(Echo

Experienced)标志并且实现了以下状态机来响应每一个收到的数据包:

DCTCP.CEFalse,

其他情况的非明显后果是只要收到CE值固定的数据包流接收端就会每n个数据包发送一次延迟ACK延迟ACK已被证明对保持高性能非常重要。

在每个观察窗口(通常选择近似于RTT的周期)结束时发送端计算在该窗口期间遇到拥塞的字节的比例即标记为CE的字节与总传输字节的比率。

DCTCP以与标准算法完全相同的方式增加拥塞窗口但减小窗口的方式与上次观察窗口期间遇到拥塞的字节数成正比。

具体来说引入一个名为DCTCP.Alpha的新变量并初始化为1在观察窗口的最后更新如下:

M是标记的字节组g是估算增益为常数(由实现设置)决定了DCTCP.Alpha随数据包的标记而变化的速度。

当出现持续拥塞时DCTCP.Alpha接近1如果持续通畅(没有阻塞)DCTCP.Alpha衰减到0。

这样对新拥堵反应较小对持续拥堵反应较大拥堵窗口的计算如下:

综上所述CE标记表明早期且频繁发生的拥塞但对这种标记的反应比标准TCP更慎重以避免过度反应导致队列空。

阐述了DCTCP的论文包括推动其设计的数据中心流量特性的研究获得了SIGCOMM的test

延伸阅读:

自DCTCP以来已经有相当多关于数据中心TCP优化的研究一般方法是从网络中引入更复杂的信号发送方可以使用这些信号来管理拥塞。

我们通过详细介绍最近的一项成果On-Ramp来结束对这一用例的讨论它侧重于所有拥塞控制算法面临的根本问题:

平衡长期流量与瞬态突发流量。

On-Ramp采用模块化设计直接解决了这一冲突而且不需要依赖来自网络的额外反馈。

其主要的观点是当处于平衡状态的拥塞控制算法遇到严重拥塞并大幅减少窗口(或速率)时必须决定是否记住之前的均衡状态。

这是一个困难的选择因为这取决于拥堵的持续时间而拥堵的持续时间很难预测。

如果拥塞是暂时的算法应该记住之前的状态这样一旦突发流量结束就可以迅速恢复到原来的均衡状态避免浪费网络资源。

如果由于一个或多个新流的到来造成了持续的拥塞算法应该忽略之前的状态以便迅速找到新的均衡。

图41.

On-Ramp对数据包传输进行配速以避免由于突发流量导致的网络排队补充了传统拥塞控制算法保持长期稳定性和公平性的努力。

其思想是将拥塞控制机制分成两部分每一部分只关注长期/瞬时流量平衡的一个方面。

具体来说On-Ramp被实现为位于传统TCP拥塞控制算法之下的垫片(shim)如图41所示。

On-Ramp处理突发流量(临时填充网络队列)当测量到单向延迟(OWD,

One-Way

增长过大(在OWD大于某个阈值)时在发送端临时缓存数据包(而不是占用网络内缓冲区)来试图快速减少排队时延。

然后On-Ramp与现有拥塞控制算法合作努力达成长期流量的平衡。

On-Ramp已经被证明可以与包括DCTCP在内的几种拥塞控制算法一起工作。

On-Ramp的关键设计是使两个控制决策在各自的时间尺度上独立运行。

但为了正常工作On-Ramp需要精确测量OWD而OWD又依赖发送方和接收方之间的同步时钟。

由于数据中心延迟可以小于几十微秒发送方和接收方的时钟必须同步到几微秒内。

这种高精度的时钟同步传统上需要硬件密集型协议但On-Ramp利用了一种新的方法利用协作节点网格中的网络效应来实现纳秒级的时钟同步而不需要特殊硬件这使得On-Ramp很容易部署。

延伸阅读:

与低延迟数据中心环境形成鲜明对比的是许多应用程序需要在很长一段时间内传输大量数据BitTorrent和软件更新等文件共享协议就是类似例子。

LEDBAT(Low

Extra

改进TCP拥塞控制算法的各种努力的共同主题之一是与标准TCP共存。

众所周知算法可以通过更积极的响应拥塞而超越TCP。

因此隐含的假设是新的拥塞控制算法应该与标准TCP一起评估以确保不只是从不那么激进的TCP实现中窃取带宽。

LEDBAT采用了相反的思路它创建了一个故意不像TCP那么咄咄逼人的拥塞控制协议。

其思想是利用链路不拥塞时可用的带宽但在其他标准流到达时迅速收回流量并将带宽留给其他流。

此外顾名思义与TCP填充瓶颈链路时的典型行为不同LEDBAT尽量不触发明显的排队延迟。

与TCP

Vegas一样LEDBAT的目标是在拥塞严重到足以造成丢包之前检测到它的发生。

然而LEDBAT采用了一种不同的方法来进行即通过单向延迟测量作为主要输入参数。

这是一个相对新颖的方法在一个具有合理精度但不完全同步的时钟被认为是常态的时代是有意义的。

为了计算单向延迟发送方在每个传输包中放入时间戳接收方将其与本地系统时间进行比较以测量包所经历的延迟然后将这个计算值发送回发送方。

即使时钟不是精确同步的这种延迟的变化也可以用来推断队列的堆积。

假设时钟没有较大的相对偏差即它们的相对偏移量不会变化太快这在实践中是一个合理的假设。

发送端监测测量到的延迟并估算固定组件(可能是由于光速和其他固定延迟)是在某一(可配置的)时间间隔内看到的最低值。

排除时间最久的估算从而允许改变路由路径并改变固定延迟。

任何超过这个最小值的延迟都被认为是由于排队引起的延迟。

建立基础延迟后发送方从测量延迟中减去该延迟以获得排队延迟并可以选择性的使用滤波算法来减少估算中的短期噪声。

然后将这个估计的排队延迟与目标延迟进行比较当延迟低于目标时允许增大拥塞窗口当延迟高于目标时减小拥塞窗口其增大和减小的速度与距离目标的距离成正比增大速度被限制为不超过标准TCP窗口在增长阶段的增长速度。

LEDBAT在收到ACK时设置CongestionWindow的算法总结如下:

其中GAIN取值为0到1的配置参数off_target是测量的排队延迟和目标之间的差距表示为目标的一个分数bytes_newly_acked是当前ACK中确认的数据包字节数。

因此测量延迟相对目标越低拥塞窗口增长越快但绝不会超过每个RTT一个MSS。

减小速度与队列长度超过目标的距离成正比。

CongestionWindow在响应丢包、超时和长空闲期时也会有所减少这与TCP非常相似。

因此LEDBAT可以很好的利用空闲的可用带宽同时避免创建长队列其目标是将时延保持在目标附近(这是一个可配置的数字建议在100毫秒量级)。

如果其他流量开始与LEDBAT流竞争LEDBAT将会后退从而防止队列变长。

LEDBAT被IETF定义为实验协议允许相当大程度的实现灵活性例如根据延迟估算和一系列配置参数可以在RFC中找到更多细节。

延伸阅读:

HTTP自20世纪90年代万维网发明以来就一直存在一开始就运行在TCP上。

最初版本HTTP/1.0由于使用TCP的方式存在大量性能问题例如每个对象的请求都需要建立新的TCP连接然后在返回应答后关闭。

早期提出的HTTP/1.1的目的是更好的利用TCP。

TCP继续被HTTP使用了20多年。

事实上TCP作为一种支持Web的协议仍然存在问题特别是因为可靠、有序的字节流并不完全是Web流量的正确模型。

特别是由于大多数网页包含许多对象因此能够并行请求许多对象是有意义的但TCP只提供单一字节流。

如果一个包丢失TCP会等待重传这个数据包然后再继续然而HTTP可以很高兴的接收其他不受单个丢包影响的对象。

多TCP连接似乎是一个解决方案但也有其自身缺陷包括缺乏连接之间拥塞的共享信息。

高延迟无线网络的兴起等其他因素使得单一设备有可能使用多个网络(例如Wi-Fi和蜂窝网络)。

同时加密、身份验证等越来越多被使用也促使人们认识到HTTP的传输层将从新方法中受益。

为满足这一需求而出现的协议是QUIC。

QUIC由谷歌在2012年提出随后被提议为IETF标准。

它已经得到了大量的部署出现在大多数Web浏览器和流行网站中甚至开始用于非HTTP应用程序。

可部署性是协议设计者考虑的关键因素。

在QUIC中有很多可选部分其规范跨越了三个RFC长达几百页但在这里主要关注其拥塞控制方法其中包含了我们在本书中看到的许多观点。

和TCP一样QUIC在传输中建立拥塞控制但它认识到没有完美的拥塞控制算法。

相反它假设不同的发送者可能使用不同的算法。

QUIC规范中的基准算法类似于TCP

NewReno但发送方可以单方面选择不同的算法如CUBIC。

QUIC提供了所有的机制来检测丢包以支持各种拥塞控制算法。

与TCP相比QUIC的许多设计特性使丢包和拥塞检测更加健壮。

例如无论是第一次发送还是重传TCP对一个数据包使用相同的序列号而QUIC序列号(称为包号)是严格递增的。

序列号越大表示报文发送的时间越晚越低表示报文发送的时间越早这意味着始终有可能区分第一次传输的数据包和由于丢包或超时重传的数据包。

还要注意TCP序列号指的是传输字节流中的字节而QUIC序列号指的是整个包。

由于QUIC序列号空间足够大(高达2^62

QUIC协议支持选择性确认在TCP

SACK选项中可以支持确认三个以上数据包范围从而提高了高丢包环境性能只要成功接收了部分包就可以向前推进。

与TCP快速恢复所依赖的重复ACK相比QUIC采用了一种更可靠的方法来判断丢包。

该方法是独立于QUIC开发的名为RACK-TLP:

最近确认和尾丢包探针(Recent

Probes)。

其关键观点为当发送方在丢包之后没有发送足够的数据来触发重复ACK时或者当重传的数据包本身丢失时重复ACK无法触发丢包恢复。

相反如果实际上没有丢包包的重排序也可能触发快速恢复。

QUIC采用了RACK-TLP的思想通过两个机制来解决这个问题:

收到包的时候如果一个序列号更高的包已经被确认并且这个包在过去足够长的时间被发送或者在确认包之前有K个包(K是一个参数)那么这个包被认为是丢失的。

在等待ACK到达的探测超时时间间隔之后发送探测包以触发ACK从而提供关于丢失包的信息。

第一个机制是确保少量包被重新排序不会被解释为丢包事件。

K建议初始设置为3但如果有更严重的无序情况可以更新K。

过去足够长的时间的定义比测量的RTT稍微长一点。

第二个机制是确保即使数据包没有生成重复ACK也会发送探测数据包来引出进一步的ACK从而暴露接收到的数据包流中的缺口。

通过使用估算RTT及其方差将探测超时间隔计算为足以解释ACK可能遇到的所有延迟。

QUIC是传输协议领域最有趣的发展。

TCP的许多限制几十年来一直为人所知但QUIC代表了迄今为止最成功的努力之一它在设计空间中指明了一个不同的点基于几十年来的宝贵经验将TCP拥塞控制提炼为基准规范。

因为QUIC的灵感来自于HTTP和Web的经验(在TCP出现很久之后才出现)提供了关于分层设计和互联网演变中不可预见后果的有趣案例研究。

还有更多内容可以介绍关于QUIC的权威参考是RFC

延伸阅读:

正如本书提到的因为TCP在检测到拥塞时以各种形式退出因此很容易构建出性能优于TCP的传输协议。

任何不通过降低发送速率来响应拥塞的协议最终都会比它竞争的任何TCP或TCP类流量获得更大的瓶颈链路份额。

在有限资源下这可能会导致拥塞崩溃而在TCP拥塞控制刚被开发出来时拥塞崩溃开始变得很普遍。

因此业界有强烈的兴趣确保互联网上的绝大多数流量在某种意义上是TCP友好的。

当我们使用TCP友好这个术语时是在说我们期望得到与TCP类似的拥塞响应。

LEDBAT可以被认为比TCP友好因为在第一个延迟提示时就减少窗口大小它比TCP更积极的在拥塞时退后。

但是有一类应用对于TCP友好需要更多的思考因为它们不使用基于窗口的拥塞方案这就是包括流媒体在内的典型实时应用。

如视频流和电话等多媒体应用可以通过改变编码参数来调整发送速率在带宽和质量之间进行权衡。

但是不可能突然大幅降低发送速率而不影响质量而且它们通常需要在有限的质量级别中进行选择。

如3.1节所讨论的这些考虑导致其采用基于速率的方法而不是基于窗口的方法。

对于这些应用来说TCP友好的方法是尝试选择一个与TCP在类似条件下实现的发送速率相似的发送速率但要以一种防止速率波动太大的方式进行。

支持这一想法的是多年来对TCP吞吐量建模的研究。

在定义TFRC标准的RFC

5348中给出了TCP吞吐量方程的简化版本其中一些变量设置为推荐值目标传输速率X(比特/秒)的方程为:

其中:

虽然这个公式的推导本身就很有趣(参见下面的第二个参考)但这里的关键思想是如果我们知道RTT和路径的丢包率就能很好的知道TCP连接能够提供多少带宽。

因此TFRC试图引导无法实现基于窗口的拥塞控制算法的应用程序在相同的条件下达到与TCP相同的吞吐量。

唯一需要解决的问题是p和R的度量然后决定应用程序应该如何响应X的变化。

与其他协议一样TFRC使用时间戳来比TCP最初更准确的度量RTT。

包序列号用于确定接收端丢包连续丢包被分组为单个丢包事件。

从这些信息中可以计算出损包事件概率p然后由接收端反馈给发送端。

对速率变化的确切响应方式当然取决于应用程序本身其基本思想是应用程序可以在一组编码速率中选择能够适应TFRC规定的速率的最高质量。

虽然TFRC的概念可靠但由于若干原因其部署很有限。

一个原因是以DASH(Dynamic

Adaptive

出现了针对某些类型的流通信的更简单的解决方案。

DASH只适用于非实时媒体(例如看电影)但事实证明这在整个互联网上的媒体流量中占很大比例事实上在所有互联网流量中占比也很大。

DASH让TCP(或者QUIC)负责拥塞控制应用程序测量TCP正在交付的吞吐量然后相应调整视频流的质量以避免接收端饥饿。

这种方法已经被证明适合于视频娱乐但是由于依赖于接收端有适度的大量缓冲来平滑TCP吞吐量的波动并不真正适合于交互式音视频领域。

DASH的关键实现之一是可以对不同带宽要求的视频进行多质量级编码并提前存储在流媒体服务器上。

然后一旦观察到的网络吞吐量下降服务器就会下降到较低质量的流然后在条件允许的情况下再上升到较高质量的流。

客户端可以向服务器发送信息比如它还有多少缓冲视频等待播放以帮助服务器选择合适的质量和带宽流。

这种方法的成本是服务器上额外的媒体存储但在现代流媒体视频时代这种成本已经变得相当廉价。

请注意这里的服务器可能是CDN(内容分发网络)中的一个节点。

因此视频流可以利用客户端和服务它的CDN节点之间可用带宽的任何改进从而传输更高质量级别的媒体。

TFRC的另一个限制是它使用丢包作为主要拥塞信号但不响应丢包之前的延迟。

虽然在TFRC的研究中这是最先进的技术但TCP拥塞控制领域现在已经把延迟考虑在内了比如TCP

Vegas和BBR(参见第5章)。

当我们考虑到真正需要一些别的支持(不是DASH)的多媒体应用程序正是那些对延迟敏感的应用程序时这就特别有问题了。

由于这个原因在撰写本文时仍在继续为实时流量定义TCP友好的拥塞控制标准。

IETF

RMCAT

Techniques)工作组是这项工作的中心。

因此下面的TFRC规范并不是最后的工作但为如何实现TCP友好协议提供了有用的参考。

延伸阅读:

虽然连接到互联网的早期主机只有一个网络接口但现在在一个设备上有至少两个不同网络的接口很常见最常见的例子是具有蜂窝和WiFi接口的移动电话。

另一个例子是数据中心服务器经常会分配多个网络接口以提高容错能力。

许多应用程序一次只使用一个可用的网络但同时使用多个接口可以提高性能。

这种多路径通信的思想已经存在了几十年并导致了IETF对TCP扩展的标准化以支持利用成对主机之间的多路径的端到端连接这被称为MPTCP(Multipath

TCP)

一对主机同时通过两条或多条路径发送流量对拥塞控制来说有重要意义。

例如如果两条路径共享一个瓶颈链接那么每个路径一个TCP连接的简单实现将获得两倍于标准TCP连接的瓶颈带宽份额MPTCP的设计者在保持多路径好处的同时正着手解决这种潜在的不公平。

MPTCP提出的拥塞控制方法同样适用于其他传输协议如QUIC。

多路径传输拥塞控制的高级目标是:

值得注意的是对其他TCP流公平的想法有一些微妙之处我们在第3.2节中讨论过。

虽然多路径算法的细节涉及到复杂的计算但所采取的总体方法比较简单。

拥塞控制算法在每个子流的基础上大致模拟TCP同时试图确保上述三个目标都得到满足。

该算法的核心是使用以下公式在子流上接收到ACK时增加每个子流的拥塞窗口大小。

CongestionWindowTotal是所有子流拥塞窗口的总和

是子流i的拥塞窗口。

MIN的第二个参数模拟了标准TCP将获得的增量从而确保子流不会比TCP更激进(目标2)。

第一个参数使用变量α来确保总体上多路径流获得与使用其最佳可用路径(目标1)相同的吞吐量。

RFC

6356介绍了计算α的细节。

需要注意的是因为没有丢包因此非拥塞路径能够比拥塞路径增加更多的拥塞窗口随着时间的推移更多流量会移动到非拥塞路径上(目标3)。

虽然回头看这很简单但正如Wischik和他的同事在NSDI的一篇论文中介绍的那样正是基于许多有趣的分析才帮助他们找到了正确的方法。

延伸阅读:

拥塞控制和移动蜂窝网络之间的相互作用。

从历史上看TCP/IP互联网和移动蜂窝网络是独立发展的自3G宽带服务引入以来后者充当了端到端TCP连接的最后一英里。

随着5G的推出我们可以预期移动网络将在提供互联网连接方面发挥越来越重要的作用其如何影响拥塞控制将会受到越来越多的关注。

虽然移动无线连接可以被视为与通过互联网的端到端路径上的任何其他跳没有什么不同但由于历史原因它被视为一种特殊情况端到端路径在逻辑上被划分为图42所示的两个段:

通过互联网的有线段和通过无线接入网(RAN)的无线最后一跳。

这种特殊情况的观点是有理由的因为(1)由于无线电频谱的稀缺无线链路通常是瓶颈(2)由于设备移动性和无线电干扰的综合效果RAN中可用带宽可能是高度可变的并且(3)当设备从一个蜂窝移动到另一个蜂窝时由给定基站提供服务的设备数量会波动。

图42.

包括最后一跳无线链路的端到端路径其中基站缓冲数据包等待通过无线接入网(RAN)传输。

虽然RAN内部很大程度上是封闭和专有的但研究人员通过实验观察到在边缘有明显的缓冲这可能是为了吸收预期的无线电链路争用同时在容量打开时保持足够的工作负载。

正如Haiqing

Jiang和他的同事在2012年CellNet研讨会论文中指出的那样这种大缓冲区对于TCP拥塞控制是有问题的会导致发送端超出无线电链路上的实际可用带宽并且在这个过程中会引入显著的延迟和抖动。

这是第6.3节中确定的缓冲膨胀问题的另一个示例。

延伸阅读:

Jiang的论文提出了可能的解决方案并普遍观察到像Vegas这样基于延迟的方法比Reno或CUBIC这样基于丢包的方法表现更好但近十年来这个问题在很大程度上一直没有得到解决。

随着基于开源软件的RAN实现的承诺正在逐步兴起可能很快就可以采取跨层方法由RAN提供接口使基站内部发生的事情对更高层次的协议栈(例如在第6章中描述的AQM机制)可见。

Xie

Yi和Jamieson最近的研究表明这种方法可能是有效的尽管他们的实现使用终端设备反馈而不是让RAN直接参与。

无论如何实现其想法是让接收方明确告诉发送方在最后一跳上有多少带宽可用然后发送方必须判断实际瓶颈是在最后一跳还是互联网路径上的其他点上。

延伸阅读:

蜂窝网络成为TCP拥塞控制新挑战的另一个方面是链路带宽不是恒定的而是随每个接收端所经历的信噪比的函数而变化。

正如BBR作者所指出的这个无线链路的调度器(目前是不透明的)可以使用给定客户端的队列数据包数量作为其调度算法的输入因此构建队列的好处可以增加调度器提供的带宽。

BBR试图在其设计中解决这一问题确保具有足够的侵略性至少在无线链路缓冲区中缓存一些包。

撇开过去的研究不谈一个很有趣的问题是无线连接未来是否仍将保持其独特性。

如果从移动网络运营商的角度看那么目标始终是在大范围变化的条件下最大限度利用稀缺的无线电频谱使用深度队列将工作负载保持在尽可能高的水平是一种经过验证的方法。

当宽带连接是新的服务语音和文本是主要用例时这当然是有意义的但今天的5G需要提供良好的TCP性能重点应该放在端到端goodput和最大化吞吐量/延迟比(即在第3.2节讨论的功率曲线)。

但是有改进的机会吗

我们相信这个问题的答案是肯定的。

除了提供对前面提到的RAN调度器和队列的更多可见性之外还有三个其他因素可能会改变这个领域。

首先5G部署可能会支持网络切片这是一种隔离不同类别流量的机制意味着每个切片都有自己的队列可以按照特定于流量的方式进行调整和调度。

其次小型基站的普及可能会减少在给定基站上争夺带宽的流量数量这将如何影响调度器最大化频谱利用率还有待观察。

第三通过附近的边缘云而不是互联网为5G连接设备提供服务将变得越来越普遍这意味着端到端TCP连接将有更短的往返时间将使拥塞控制算法对RAN中可用容量的变化更敏感。

当然没人能保证未来如何发展但所有这些因素都应该为未来调整拥塞控制算法提供充足的机会。

关于拥塞控制的研究论文非常广泛本书只引用了一小部分。

这里收集了更全面的参考书目(目前)根据书中涉及的主要主题组织。

我们邀请社区帮助保持书目的完整和更新。

如果提供额外的引用或修复错误请提交Pull

Request到GitHub[2]。

如果对如何改进书目的组织方式提出建议请向GitHub发布Issue[3]。

队列分析

4.0)许可条款提供。

邀请社区在相同的条件下提供更正、改进、更新和新材料。

虽然本授权并不自动授予制作衍生作品的权利但我们非常希望与感兴趣的各方讨论衍生作品(如翻译)。

请联系discusssystemsapproach.org。

Title:

https://github.com/SystemsApproach/tcpcc

License:

本书是系统方法系列的一部分其在线版本发布在https://tcpcc.systemsapproach.org。

要跟踪进度并接收新版本通知可以在Facebook[4]和Twitter[5]上关注本项目。

要阅读关于互联网发展的实时评论请订阅Systems

Approach

https://github.com/SystemsApproach/tcpcc.git$

tcpcc

构建过程实现在Makefile中并且需要安装Python。

Makefile将创建一个虚拟环境(venv-docs)用于安装文档生成工具集可能还需要使用系统的包管理器安装enchant

请运行make

spelling检查拼写。

如果有拼写正确但字典中没有的单词、名称或首字母缩写词请添加到dict.txt文件中。

向本书投稿

如果你使用这些材料希望也愿意给出回馈。

如果你是开放源码的新手可以查看How

Contribute

如果你想投稿并且正在寻找一些需要关注的内容请查看wiki[6]上的当前待办事项列表。

关于作者

Kahn名誉教授并从2003年到2009年担任主席。

Peterson教授的研究主要集中在互联网大规模分布式系统的设计、实现和操作包括广泛使用的PlanetLab和MeasurementLab平台。

他目前正在为开放网络基金会(ONF)的Ae***r接入边缘云项目做出贡献并担任首席科学家。

Peterson是美国国家工程院院士ACM和IEEE院士2010年IEEE

Lawrence

Brakmo目前在Facebook的Kernel小组工作。

在加入Facebook之前他是谷歌主机网络组的成员在此之前是DoCoMo美国实验室操作系统组的研究员和项目经理。

Brakmo致力于TCP增强以提高网络性能包括TCP

Vegas和TCP-NV拥塞控制算法的设计。

他还开发了操作系统技术以提高系统的可靠性、性能和能耗。

Brakmo在亚利桑那大学获得计算机科学博士学位。

Bruce

Davie是计算机科学家因其在网络领域的贡献而闻名。

他是VMware亚太区的前副总裁兼首席技术官在VMware收购SDN初创公司Nicira期间加入VMware。

在此之前他是Cisco

Systems研究员领导一个架构师团队负责多协议标签交换(MPLS)。

Davie拥有超过30年的网络行业经验并合著了17个RFC。

他于2009年成为ACM研究员并于2009年至2013年担任ACM

SIGCOMM主席。

他还在麻省理工学院做了五年的访问讲师。

Davie是多本书的作者拥有40多项美国专利。

你好我是俞凡在Motorola做过研发现在在Mavenir做技术工作对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣平时喜欢阅读、思考相信持续学习、终身成长欢迎一起交流学习。

微信公众号DeepNoMind

https://tcpcc.systemsapproach.org/index.html

[2]

https://github.com/SystemsApproach/tcpcc

[3]

https://github.com/SystemsApproach/tcpcc/issues

[4]

https://www.facebook.com/Computer-Networks-A-Systems-Approach-110933578952503

[5]

https://twitter.com/SystemsAppr

[6]

https://github.com/SystemsApproach/tcpcc/wiki

END