流量控制与拥塞控制学习小结

相同点：都要对发送方进行限制。目的都是提高网络性能。这个没什么好说的。

下面说说不同点：

拿说话举例子。流量控制是控制你说话速度。而拥塞控制是不允许太多人同时说话。为什么呢？

1.流量控制（控制速度）：你说得太快了，我有可能漏听。

在点对点的传送过程中，由于发送方和接收方对数据的发送/接收的处理能力不相同，可能会导致发送方发的太快，接收方漏接了/丢弃了许多数据。

2：拥塞控制（控制数量）：太多人说话了，我处理不过来。而且同时说话声音会有干扰。我听不懂你们还得重新再说一遍。

注意：拥塞控制不只是点对点，而是通信子网,这是个全局性的过程。

多条流入线路有分组到达，并需要同一输出线路，此时，如果 路由器没有足够的内存来存放所有这些分组，那么有的分组就会丢失。

本来网络就很不好了！！分组丢失了会重传，让网络更加不堪，甚至有可能死锁。真糟糕。

下面是详细的资料：

1.流量控制：



这张神图非常犀利~几乎每个相关资料都会贴上这张图

A应该是发送方，B是接收方。

刚开始，A和B协商好，窗口值rwnd是400字节，意思是，我的容量就是这么大，你别发太快了我装不下。

A想了想，那我可以一口气发4份数据小片段。（假设每个数据小片段是100字节）

第四行箭头是从B到A的，（ack=201）意思是，我收到了201之前的所有数据（我现在想接受201及其之后的数据），(rwnd=300)意思是我现在容量是300，你可以一口气发三个报文给我。

果真，A就给B发送了编号分别是 301， 401， 201的三个报文段。其中201是因为丢失而重传。

2.拥塞控制

拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。


不要被复杂的图片所迷惑。

重要的就两点：

1.一旦我发现有拥塞出现了，我就让拥塞窗口狠狠狠狠地变小。这就是所谓的乘性减。

2.我发现好像拥塞稍微好点了，那我就慢慢慢慢的增大拥塞窗口。 这就是所谓加性增。

以下是摘录的资料：

TCP是Internet上通用的传输层协议之一，是目前应用最广泛的传输控制协议，其核心是拥塞控制机制。基于Internet的交换机的通信信道、处理速度及缓冲存储空间通常是网上所有主机共享的资源，也是网络系统潜在的瓶颈。随着信源主机数以及信源业务端业务量的不断增多，瓶颈处就有可能发生资源竞争，从而导致网络拥塞。TCP的一个重要组成部分是执行拥塞控制和拥塞恢复的算法集合。TCP拥塞控制算法的目标是最大限度利用网络带宽，同时不产生数据流传输中的拥塞现象。因此，自从上个世纪80年代出现第一次拥塞崩溃以来，TCP拥塞控制策略就在不断地进行完善和改进。

2. 传统的TCP拥塞控制机制

传统的TCP中的拥塞控制机制主要是基于Van Jacobson提出的"慢启动"算法、"拥塞避免"算法和一个用于估计周转RTT(round trip time)的算法。

慢启动算法通过观察到新分组进入网络的速率应该与另一端返回确认的速率相同而进行工作。慢启动为发送方的TCP增加了另一个窗口：拥塞窗口(congestion window)， 记为cwnd。当与另一个网络的主机建立TCP连接时，拥塞窗口被初始化为1个报文段（即另一端通告的报文段大小）。每收到一个ACK，拥塞窗口就增加一个报文段（cwnd以字节为单位，但是慢启动以报文段大小为单位进行增加）。发送方取拥塞窗口与通告窗口中的最小值作为发送上限。拥塞窗口是发送方使用的流量控制，而通告窗口则是接收方使用的流量控制。发送方开始时发送一个报文段，然后等待ACK。当收到该ACK时，拥塞窗口从1增加为2，即可以发送两个报文段。当收到这两个报文段的ACK时，拥塞窗口就增加为4，这是一种指数增加的关系。在某些点上可能达到了互联网的容量，于是中间路由器开始丢弃分组。拥塞避免算法是一种处理丢失分组的方法。该算法假定由于分组受到损坏引起的丢失是非常少的（远小于1%），因此分组丢失就意味着在源主机和目的主机之间的某处网络上发生了拥塞。有两种分组丢失的指示：发生超时和接收到重复的确认。拥塞避免算法和慢启动算法是两个目的不同、独立的算法。但是当拥塞发生时，我们希望降低分组进入网络的传输速率，于是可以调用慢启动来作到这一点。在实际中这两个算法通常在一起实现。1990年出现的TCP
Reno版本增加了"快速重传"算法、"快速恢复"算法，避免了当网络拥塞不够严重时采用"慢启动"算法而造成过大地减小发送窗口尺寸的现象。

3. 拥塞控制的四个阶段

a．慢启动阶段(slow start)：发送方一开始便向网络发送多个报文段，直至达到接收方通告的窗口大小为止。当发送方和接收方处于同一个局域网时，这种方式是可以的。但是如果在发送方和接收方之间存在多个路由器和速率较慢的链路时，就有可能出现一些问题。一些中间路由器必须缓存分组，并有可能耗尽存储器的空间。

b．拥塞避免阶段（congestion avoidance）：当发现超时或收到3个相同ACK确认帧时，则表示有丢包事件，此时网络已发生拥塞现象，此时要进行相应的拥塞控制。将慢启动阈值设置为当前拥塞窗口的一半；如检测到超时，拥塞窗口就被置为l。如果拥塞窗口小于或等于慢启动阈值，TCP重新进人慢启动阶段；如果拥塞窗口大于慢启动阈值，TCP执行拥塞避免算法。

c．快速重传阶段(fast retransmit)：当TCP源端收到到三个相同的ACK副本时，即认为有数据包丢失，则源端重传丢失的数据包，而不必等待RTO超时。同时将ssthresh设置为当前cwnd值的一半，并且将cwnd减为原先的一半。

d．快速恢复阶段(fast recovery) ：当"旧"数据包离开网络后，才能发送"新"数据包进入网络，即同一时刻在网络中传输的数据包数量是恒定的。如果发送方收到一个重复的ACK，则认为已经有一个数据包离开了网络，于是将拥塞窗口加1。

4. 对传统TCP拥塞控制机制的发展及改进

4.1 对慢启动的改进　　

慢启动(slow start)算法通过逐渐增加cwnd的大小来探测可用的网络容量，防止连接开始时采用不合适的发送量导致网络拥塞。然而有时该算法也会浪费可用的网络容量，因为慢启动算法总是从cwnd＝l开始，每收到一个ACK，cwnd增加l，对RTT时间长的网络，为使cwnd达到一个合适的值，需要花很长的时间，特别是网络实际容量很大时，会造成浪费。为此可采用大的初始窗口，大的初始窗口避免了延迟ACK机制下单个报文段初始窗口的等待超时问题，缩短了小TCP流的传输时间和大延迟链路上的慢启动时间。

在慢启动阶段，在每个RTT时间内，cwnd增加一倍，这样当cwnd增加到一定的值时，就可能导致以网络能够处理的最大容量的2倍来发送数据，从而淹没网络。Hoe建议使用packet-pair算法和测量RTT来为ssthresh估计合适值，以此来适时地结束慢启动阶段。但是由于受各方面干扰，估算合理的ssthresh值并不容易，因此这个方法的效果是有限的。而Smooth-start较为平滑地从慢启动过渡到拥塞避免阶段，减少了报文段丢失和突发通讯量，提高了TCP拥塞控制的性能。

4.2 对重传与恢复的改进

为了避免不必要的重传超时，有人提出了一种受限传输机制：如果接收方的广播窗口允许的话，发送方接收到一个或者两个重复的ACK(acknowledgment)后，继续传输新的数据报文段。受限的传输机制允许具有较小窗口的TCP连接进行错误恢复，而且避免了不必要的重传。

有很多情况下，数据报文段并没有丢失，但TCP发送方可能会误判数据报文段丢失，然后调用拥塞控制规程减少拥塞窗口的大小。比如当重传定时器过早溢出时，发送方在重传数据报文段时不必要地减少了拥塞窗口，而这时并没有数据报文段丢失。如果是由于数据报文段的重新组织而不是数据报文段丢失，而导致3个重复的确认，同样会导致发送方不必要地在快速重传数据报文段后减少拥塞窗口。

如果TCP的发送方在重传数据报文段一个RTT后发现接收方接收到了重传数据报文段的两个拷贝，则可以推断重传是不必要的。这时，TCP的发送方可以撤销对拥塞窗口的减少。发送方可以通过将慢启动门限增加到原始值，调用慢启动规程使拥塞窗口恢复原先值。除了恢复拥塞窗口，TCP发送方还可以调整重复确认门限或者重传超时参数来避免由于多次不必要的重传而浪费带宽。

4.3 对公平性的改进

在拥塞避免阶段，如果没有发生丢包事件，则TCP发送方的cwnd在每个RTT时间内大约可以增加一个报文段大小，但这样会造成具有不同RTT时间或窗口尺寸的多个连接在瓶颈处对带宽竞争的不公平性，RTT时间或窗口小的连接，相应的cwnd增长速度也相对缓慢，所以只能得到很小一部分带宽。

要解决上述问题，可以通过在路由器处使用公平队列和TCP友好缓存管理来进行控制以增加公平性。然而如没有路由器的参与，要增加公平性，就要求TCP发送端的拥塞控制进行相应的改变，在拥塞避免阶段使共享同一资源的各个TCP连接以相同速度发送数据，从而确保了各个连接间的公平性。

5. 结论

该文在研究和分析各种基于TCP的数据流拥塞控制算法和参考有关文档的基础上，对以TCP为核心的拥塞控制机制进行了发展和改进，这些改进将使TCP的性能在不同的网络中取得更好的性能。其中避免不必要的重传超时、撤销不必要的拥塞控制等是随着网络技术的发展而对TCP的改进，它们通过不同的方式改进了TCP的性能，具有更广泛的适应性。

参考资料：http://blog.sina.com.cn/s/blog_6988593e01015wu0.html