高速网络拥塞控制之端到端

hritian

                                                这篇文章很短，类似与一个引言，先从一个真实的“笑话”说起。国内某个大型网站，有钱的一B的政府网站，有一条几十Mb的专线，但是用tcp传 2-3Mb。这个一方面是因为TCP对高带宽时延积网络的不适应性，其实更主要的原因还是系统管理员不懂得去配系统参数。其实只要抓抓包就能发现并且解决掉的。
其实88年第一个tcp拥塞控制算法做出来的时候，网络带宽和时延都是很小的，到底有多小不知道。反正很小。所以当时AIMD，一个时延增加一个拥塞窗口，丢包降一半的策略在当时还是很有效的。
但是到了2000年以后，情况就大不一样了。现在G级别的带宽，已经是家常便饭，200ms的时延也见怪不怪了，比如我们前面那个“笑话”的时延，在这种高带宽时延积网络的情况下，200ms增加一个拥塞窗口，还合适吗？就算不丢包，1s才增加几十KB，太慢了吧。但是更要命的是据说物理层还有一个自然错误率，就是说，即使网络不拥塞，也会由于物理层的错误导致丢包都会使得网络的利用率不高。
面对这样的新的网络环境，就出现了不同的研究思路，一个是显式拥塞控制，另一个是端到端的解决方案，还有一个叫做并行tcp的思路，听说很久了，不过很可惜太懒的我一直都没有花时间去学习它。
虽然端到端的方案有诸多的缺陷，但是不得不承认他是部署最容易的，现在linux内核上默认部署的bic/cubic都是这个方案的产物，windows内核的compound tcp也是这个方案的产物。
说了半天，还没有说端到端的解决方案大概是个什么思路，端到端的解决方案，总体思想就是认为在high BDP网络里，传统的算法，加的太保守，减的太激进。那么怎么加不保守，怎么加不激进呢？在没有任何路由器反馈信息的条件下，怎样做决策更合理呢？
最原始的hstcp，它的思想很简单，网络利用率不高，是由于物理层的错误导致的，那我就防止这种情况，结果做出了一个，类似于MI的机制，还有一个Scalable TCP，也是那种MI的思路，我最讨厌的就是MI，网络不仅需要效率，还要公平的，以我的观点，拥塞避免阶段的MI都是不可取的。
还有一种思路是利用RTT做为决策依据，代表性的是FAST，FAST曾经号称是最快的算法，可是我依然觉得RTT这个数据还是有非常大的不确定性，和稳定性，我不看好它。
我比较看好的（其实也是整个学术界公认的几个算法，嘿嘿，我的眼光还不是太差哦）是BIC/CUBIC、 HTCP和Compound tcp。
这就算开了个头吧，后面有空，把BIC/CUBIC 、HTCP和Compound tcp，一个个拿出来说。
               
               
               
               
               
               
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/93004/showart_1854613.html