TCP自时钟/拥塞控制/带宽利用之脉络半景解析

分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn.net/jiangjunshow

也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！

               

0.说明

搬家公司的人很多都穿皮鞋！Why？

这个题目不是很明确，而且这个文章比较长，也算是我的一个阶段性总结，既然是总结，就不必为题目而纠结了。在端午假期的最后来做这个总结也实属不易(假期前两天加班，没有完成预期的计划，低落)，记得很早以前写那篇《TCP协议疑难杂症全景解析》的时候跟现在一个心情。翻翻以前的记录，写那个的时候是2011年的7月初，小小才刚刚半个月，如今小小已经马上5岁了，时间过得真快啊，弹指一挥间！！回首过去的五年间，最累的时候是在2011年中到2014年初这两年半的时间，有了小小之后工作更加努力，然则一个产品做到了让人感觉遥遥无期的地步，好几次想离职换个工作，我可是个研发啊，事实上我那段时间学会了机器上架，也理解了更多的网络方面的更深的东西，付出嘛，总会有回报，这是必须的！无数个夜晚漫步在寂静的陆家嘴(陆家嘴作为整个中国的CBD怎会寂静？因为夜已深！)，打不到车，从冬天到夏天，再到冬天...公司年终评奖的时候，大家都是拿数据说话，谁的数据好看谁赢，豪言壮语高谈阔论无卵用，我的数据当然也比较帅，只是让我获奖的不是研发运维方面的数据(人家都很棒！)，而是出勤方面的，比如xx天加班，xx'次夜间出勤，xx''次节假日出勤...等等吧，我是最讨厌加班的人，却因为这个拿了个大奖，天大的笑话啊，然而这种尴尬的场景总是一再在我身上上演，也是崩溃又欲哭无泪啊！

        也是在那段时间，我学会了随时随地支起摊子就能工作这样的本事，因为我的时间在那段时间被打得很乱，一天在公司安心研发的时间几乎为0，跑用户现场，生产环境上现场编程，这压力得有多大，而且还跟内核有关，万一一个panic...上线了又要值守，之后又是各种会议，前向总结，后向计划，晚上八点从用户现场下班准备回家却又被领导叫回公司开会，开完会大半夜的又必须完成当日的决议...为此，我蹿坏了前台旁边的木头凳子...后来我占领了公司的一间会议室，起初我是在那搭测试环境的，几十台设备摆在会议桌上同时开机压测颇为壮观，我以测试修bug为由长期呆在那里，也不管什么辐射不辐射，噪音不噪音，久而久之，那里就成了我的独立办公室了，不外出的时候，呆在那里听着机器的轰鸣声敲着代码十分之惬意，外出的时候，地铁站，公交车，用户现场，机房，家里，哪里都可以展开工作，因为有项目津贴，没网络时我就用手机开热点...于是乎我忘掉了自己的工作座位，那已经成了垃圾堆，甚至有同事以为我离职了。两年多过去了，感觉自己成长了很多，虽然没有整块的时间做研发，但确实能力有了很大的提高，所以我还是很感谢那两年时间遇到的每一件事，每一个人的。
        为什么突发感慨说往事呢？可能是因为最近的工作与TCP有关，各方面场景包括来自各方的压力与那段时间类似吧，当然好处是现在不用外出了，也不会夜间出勤之类的了，最重要的是时间，比3年前充裕了很多。不管怎么说，软件硬件都在进步嘛。爆炸！
        低落中无论如何也不能让这个假期如此假惺惺地过去，所以狠下心来再搞半个夜晚，算是《 TCP协议疑难杂症全景解析》的续吧！

让我们以一个问题开始吧！
TCP依靠ACK来维持一个时钟，该时钟驱动发送端数据的发送，问题是，发送端应该发送多少数据呢？

TCP释义

TCP是一个端到端协议，其节点分布在全世界的每一个角落，彼此不知其它连接的存在，因此无法进行全局意义上的时钟同步来驱动合作式的网络行为，与之不同的是，IP层虽然是无状态无连接的，但却可以进行这种分布式合作，比如各种动态路由协议就是合作的，依靠各种交互进行同步。这就意味着，端到端的TCP协议必须完成并处理好两件事：

a).由一个自时钟来驱动自己的行为，比如发送数据，“停-等”等等，这个是通过ACK & 超时定时器(混合型自时钟)来实现的。
b).比如依靠反馈系统自适应完成与其它连接的合作关系，且这种关系必须是合作的，不能是抢占的，这个是通过拥塞控制来实现的。
本文以下的篇幅围绕上述a)和b)逐步展开。

声明

网络分析包括很多的元素，比如协议分析，性能分析，逆向，行为分析等，协议分析比较简单，性能分析则非常复杂，涉及到比如马尔科夫过程，泊松分布这类让大多数人望而却步的东西，因此本文不包括这些，仅仅分析TCP的行为以及这行为背后的原因。

1.端到端的滑动窗口机制

TCP是一个端到端的协议，它在设计上不考虑数据经由的中间网络，你可以将中间的网络抽象成一个以太构成的管道，拥有无限的容量，拥有极限的速度，那么理论上只需要在发送端和接收端之间进行交互即可，TCP采用了滑动窗口机制来做流量控制，这个我不再解释，能看到此文并且看完的，都是懂TCP/IP的，而滑动窗口则是TCP的基础中的基础。

2.现实的网络状况

这里说的现实指的是两种现实，一种是历史的现实，一种是当前的现实，或者还有未来的现实。在TCP/IP早期，带宽几乎是独享的，除了有些链路噪声之外，你可以将其想象成完全的以太。因此网络中不会存在拥塞，因此TCP作为一个纯粹的端到端协议，工作的非常好。
        时间进入到了20世纪80年代末，网络出现了拥塞，或者仅仅是有先见之明的猛人意识到了互联网将爆发，网络将遭遇拥塞，因此TCP不能再保持端到端的纯粹性了，它必须处理拥塞，即它必须可以意识到拥塞，并对拥塞做出反应，好吧，就是在这个时候，TCP引入了拥塞控制机制，并且全世界对这一机制的研究持续了将近30年。
        进入21世纪，几乎所有的大城市都遭遇了大城市病，其中最令人不爽的就是道路拥堵导致的各种限，限外牌，限号，...伴随各种限的就是人们的各种抢，抢什么呢？当然是资源！实际上，此时的互联网上遭遇了同样的情形，我记得很早之前在一本杂志上看到过有人预测互联网即将崩溃的文章，但事实上它依然在如此拥堵的环境下工作的很好。原因就在于TCP的拥塞控制机制是自适应收敛的，不需要任何机构的管理，就可以保持互联网的恒稳。总之，目前，TCP一切安好！
        时间即将进入未来，TCP在中国获取不再那么令人乐观，伴随运营商的限限限，以及BAT等巨头互联网厂商的各种垄断，人们连抢抢抢的权利都没有了，事实上，带宽都被巨头们抢光了。
        在我们的土地上，任何美好的约定都可以不被遵守，任何契约都可以打破。TCP在中国也同样。
        人们不必再遵守TCP的公平收敛约定，于是出现了超级多的暴力方案，这就好像在高速公路上我发现有人比我跑得快或者拥堵的时候，我任意变道并直接开车把前车撞了,然后打个电话再弄来一辆车就好了，因为我有钱，我有很多车，我不在乎成本，然而被撞的车可能是人家几年的积蓄...这难道不是一个道理吗？什么一个数据包发两遍甚至三遍，发生拥塞时保持大窗口，甚至忽略拥塞控制机制直接暴力发送...因为这是在中国，所以这种军备竞赛如火如荼的进行着，人们不需要懂什么TCP协议，甚至都不需要懂网络的基本概念，完全可以把这事做的很黄很暴力，因此，美国的作者所谓的互联网崩溃，应该说的就是我们国家吧...

3.平稳的ACK时钟

我们知道，TCP是一个持续的数据流，就像是水流一样，起码在设计上，理想情况下应该如此。如本文之首所述，TCP流的发送依靠ACK来驱动，如果TCP流的发送想保持连续，就依赖ACK会持续的到来，持续的ACK导致持续的TCP数据流，持续的数据流在接收端产生持续的ACK...
        从最简单情况开始，请忽略掉窗口，假设这个时候我只想设计一个持续的数据流发送的机制，没有端到端的流控，也没有网络拥塞控制，仅仅是一个持续的流，该是个什么样子呢？

我觉得应该是下面的样子：

我将其看作是平稳的ACK时钟。这是本质的东西。为什么我说构造这个自时钟机制是本质的呢？因为任何事都依赖一个心跳来驱动进展，这是最基本的，就连胚胎也是先有的心跳，后发育的大脑。所以，我认为要想理解TCP，首先理解这个自时钟十分必要。

        在接下来的篇幅中，我会逐步解释控制拥塞窗口的慢启动是如何加到TCP标准中的，以及它后来是如何导致平稳的ACK时钟发展成现在实际的样子的。

4.TCP慢启动与拥塞控制释义

4.1.说明

写文章之前，提纲这么列的，现在感觉没什么好说明的。

4.2.ACK时钟启动的问题

如上一节所述，如果有一个平稳的ACK时钟，TCP发送端将会由该时钟驱动将数据流源源不断地送进网络中，这些数据流在被接收端收到后会产生ACK，这些ACK作为时钟信号反馈到发送端，循环不止。
        然