第九天：TCP流量控制-拥塞控制

回顾

如果一个包重传了N次还是失败，会一直持续重传到成功吗?

这个取决于系统的设置，比如有些系统，重传5次还未成功就会发送RESET报文，断开TCP连接

如果接收窗口最多能接收四个包，但是发送方只发了两个包，接收方如何确定后面还有没有包呢？

服务端会等待，等待一定时间后确认没有第三个包，就发送确认收到两个包的信息

为什么选择再传输层将数据大卸八块，而不是等到网络层再分片传递给数据链路层？

因为可以提高重传的性能。

需要明确的是：可靠传输在传输层进行控制的

如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传

如果在传输层分了段，一旦出现数据错误，只需要重传丢失的哪些段即可

流量控制

如果接收方的缓存区满了，发送方还在疯狂着发送数据
接收方只能把收到的数据包丢掉，大量的丢包会极大着浪费网络资源l所以要进行流量控制

什么是流量控制？

让发送方的发送率不要太快，让发送方来得及处理

原理

通过确认报文中窗口字段来控制发送方的发送速率发送方的发送窗口大小不能超过接收方给出窗口大小
当发送方收到接收窗口的大小为0时，发送方就会停止发送数据

特殊情况

rwnd 窗口

rwnd 窗口，每次传输过来的窗口大小都会改变

有一种特殊情况
一开始，接收方给发送方发送了0窗口的报文段
后面，接收方又有了一些存储空间，给发送方发送的非O窗口的报文段丢失了发送方的发送窗口一直为零，双方陷入僵局
心

解决方案
心
当发送方收到0窗口通知时，这时发送方停止发送报文
并且同时开启一个定时器，隔一段时间就发个测试报文去询问接收方最新的窗口大小如果接收的窗口大小还是为0，则发送方再次刷新启动定时器

拥塞控制

从这个图来看，在理想情况下，当传输速率达到带宽时，它就会一直保持最大带宽1000，而在现实情况下，并不会，他只会达到700-800左右，到包再多时，速率就会下降甚至死锁，彻底不能工作，就和开车一样，当车辆过多时们就会堵车

所谓的拥塞控制就是防止过多的数据注入到网络，避免网络中的路由器或链路过载

拥塞控制是一个全局性的过程

涉及到所有的主机、路由器
以及与降低网络传输性能有关的所有因素是大家共同努力的结果

而流量控制是点对点的控制

几个缩写

MSS（max segment size）：每个段最大的数据部分大小

在建立连接时确认

但是在实际过程中，一个包发多大，发多少都是需要双方确认的，

三次握手的时候就会确认这些信息，这个就是在建立连接的时候发发送的数据包

到底使用多大的窗口，取二者的最小值

如何解决拥塞—方法

慢开始

这个图是什么意思呢，MSS=100，rwnd=3000，意味着我一次最大可以发30个数据包，但是它会不会一次就发30个呢？

答案是不会，它一开始会发的比较慢，然后逐渐加快，这就是慢开始，一开始发1个包，确认了就发2个，再发4个、8个、16个，成指数增长

下面的这个图是cwnd（拥塞窗口）

一开始的时候发一个，再发2个、4个、8个等

拥塞避免

惩罚减小，只要出现拥塞，把ssthresh减半，于此同时，执行慢开始算法（cwnd又恢复到初始值）

快重传

接收方
每收到一个失序的分组后就立即发出重复确认使发送方及时知道有分组没有到达
而不要等待自己发送数据时才进行确认

快恢复

快重传+快恢复

一开始执行慢开始算法，当到达阈值的初始值后开始加法增大，成线性增大，出现拥塞后，减小阈值，但是不执行之前的慢开始，是从这个阈值开始继续实现加法增大，成线性增加

发送窗口的最大值

发送窗口的最大值：swnd=min(cwnd,rwnd)