TCP滑动窗口/拥塞控制/流量控制

TCP和UDP的区别

1. 有连接和无连接

二、UDP一对一, 一对多和一对全 ，TCP一对一

三、UDP面向报文，TCP面向字节流

四、可靠性

五、报文头信息

小结

滑动窗口

1. 发送方：

一个报文的状态：

• 已经发送，并且收到确认报文（已结束）（窗口外）

• 已经发送，但还未收到确认报文（等待ACK） （窗口内）

• 可以发送，但尚未发送（已就绪，等待发送）（窗口内）

• 不可以发送（受窗口限制，不允许发送） （窗口外）
  
  如果出现丢包，那么就会重复对丢包报文前的那个报文进行确认，例如在上图中，如果发送了31，32，33，34，45，其中32丢包，31，33，34，35按序号到达，那么当33到的时候，34到的时候，35到的时候，都是发的对31的确认报文，相当于多发了3次对31的确认报文（当对同一个报文重复确认3次的时候，则会触发快重传）。

  因此，在上图中，31～41一定都是未收到确认的，当31确认收到了以后，那么窗口就会向右滑动，直到最左方的首个元素是“发送了但尚未收到确认报文的” 或者“尚未发送的”。 继续上面这个例子，当31，33，34，35到达，接收方发送了3个对31号报文的ACK，就会触发“快重传”，重新传送32。

2. 接收方

接收方窗口左边为已经发送过的确认报文，右边为当前不能接收的报文。

接收方窗口：

• 最左边报文一定是尚未收到的报文
• 如果31没到，32，33先到，就先把32，33缓存在接收缓冲区中，并且会发送2个对30的确认报文，当收到了31的确认报文，那么窗口就继续滑动到34的位置.

---

拥塞控制

在理想情况下，随着请求数的增长，网络的吞吐量也会增长，当用户的请求出超出了网络所能承载的负荷时，吞吐量将保持不变。。

而实际情况是，当用户对网络资源的请求数量超过了网路所能抗住的负荷时，吞吐量会随着请求的增多而减少，直到变为0。
而拥塞控制就是为了防止这一情况的产生，其实现的方式就是，通过调整发送窗口的大小，来控制发送速率，从而起到减少网络流量的作用。

发送方需要维护3个变量( 发送窗口(cwnd), 拥塞窗口(swnd), 窗口阈值(ssthresh))：
实际上，发送方发送窗口大小 = min（拥塞窗口大小（拥塞控制）, 接收方接收窗口大小（流量控制））

拥塞控制包括了4个算法策略分别是：慢开始，拥塞避免，快重传，快恢复。

慢开始：

cwnd = 1, 每发送一轮窗口大小的数据并成功接收到确认报文，就给窗口大小乘2，
当窗口大小超过ssthresh时，使用拥塞避免算法。

拥塞避免：

每发送一轮窗口大小的数据并成功接收到确认报文，就给窗口大小加1，一旦出现超时重传，则判定网络可能出现了拥堵，将cwnd置为1，ssthresh变为原来的一半

快重传：

快重传就是：并不是等超时了才再重传，而是连续收到3个重复的ACK报文时，就开始重传！

快恢复

快恢复就是：出现了需要重传的情况，并不是把cwnd置为1，而是置成原来大小的一半,（ssthresh也置为原来的一半）。

---

流量控制

流量控制就是，让接收方的发送速率能够匹配上接收方的接收速率，具体实现体现在：控制发送方的发送窗口大小（如果发送的太快了，就把窗口调小点，如果发的太慢了，就把窗口调大点），发送方窗口的大小根据接收方窗口的大小来决定。

实际上，发送方发送窗口大小 = min（拥塞窗口大小（拥塞控制）, 接收方接收窗口大小（流量控制））

该视频的例子讲的非常棒。

• 发送方在接收到接收方的确认报文段后，会根据报文中的接收方窗口大小值，来重新调整当前的发送窗口大小。（初始大小在TCP三次握手的时候确定）

• 发送方窗口可以被设成零。 当发送方窗口大小为0时，会定时发送零窗口探测报文，询问接收方的窗口大小，如果还是0，那么就重置这个定时器，如果不是0就重新调整窗口大小。

• TCP规定，接收方接收窗口即使为0，也应接收零窗口探测报文，确认报文段，以及携带紧急数据的报文段。