运输层6——TCP流量控制
为什么有流量控制？
因为发送方发送的数据太多太快，接收方来不及接收，从而导致数据丢失
因此，流量控制就是：不要让发送方发的太快，让接收方来得及接收
目录
1、滑动窗口实现流量控制
2、死锁问题
3、TCP传输效率
1）Nagle算法
2）糊涂窗口综合征
1、滑动窗口实现流量控制
下面我们以一个图为例，其中：
rwnd表示：B的接收窗口
seq表示：发送数据的开始位置
ACK表示：确认位为1
ack表示：确认字段的值，表示期望收到的值
如图：
要了解上图中所有的交互过程
将整个过程推一遍
注意一个细节，对于该过程：
A的实际发送窗口是301-500，大小为200
因为在B的确认报文没有到达A之前，
A的201-300已经发送了，只是没有收到确认而已
但是，在RTO前是不会重传201-300的
2、死锁问题
B的接收窗口为0
于是B发送给A的确定报文的rwnd=0；即不允许A发数据
此时A只能暂停发送，直到B有新的可用窗口
发送新的确定报文，携带新的窗口值给A，A才能重传
可是，如果该确定报文丢失
就导致：
A在等B的允许
B在等A的发送
谁也不吱声，没完没了，就这么干瞪着
陷入死循环
这就是死锁
如何解决？
增加一个持续计时器，类似于重传计时器的机制
方法：
接收方一旦接收到一个零窗口通知，即启动持续计时器
时间到，就发送一个零窗口探测报
该零窗口探测报的特点是：仅携带1个字节的数据
注意TCP首部20+IP首部20+1字节数据
因此，在TCP层传输是21字节，在IP层是41字节
而，一旦对方收到该探测报
立马回应，给出当前的窗口值
如果窗口依旧为0，则发送方重新设置持续计时器
否则，窗口值不为0，则打破死锁。
3、TCP传输效率
TCP报文什么时候发送？
有三种方法：
第一，TCP设置一个变量，等于最大报文段长度MSS。数据达到该值，发送
第二，应用层指定发送某个数据段，如推送操作，尽快发送
第三，设置计时器，达到时间，发送（数据小于MSS）
但是还需要注意一个问题：数据不能太小，否则传输效率太低
1）Nagle算法
发送进程将数据逐个字节发送给TCP缓存
怎么办？
1、发送方先发送数据的第一个字节
2、等待接收方的确认
3、一旦收到接收方的确认，立即发送所有缓存数据
4、继续对随后数据进行缓存
5、之后的发送，只有收到前一个确定报文才可以发送下一个报文
同时，Nagle规定：发送方缓存的数据一旦达到发送窗口的一半 或 报文段的最大长度，立即发送
2）糊涂窗口综合征
接收方B缓存满了，但是该死的接受应用进程只读取一个字节的数据
于是，接收方B向发送A发送确认报文，窗口值为1
于是A就像B发送1字节的数据
如此反复，没完没了
可是每一次只发送一个字节，效率极其低下
怎么办？
1、接收方的可用窗口不要太小，积累到接收一半 / 能够收纳一整个最长报文段再通知发送方
2、发送方也不要太着急，同样积累到发送窗口一半 / 足够大的报文段再发