通俗易懂讲解TCP流量控制机制，了解一下
上篇文章讲了TCP拥塞控制机制的原理，没看过的不妨看下：5分钟读懂拥塞控制，这篇文章讲讲TCP流量控制机制。
一、为什么需要流量控制?
双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来，这时候接收方只能把处理不过来的数据存在缓存区里（失序的数据包也会被存放在缓存区里）。
如果缓存区满了发送方还在疯狂着发送数据，接收方只能把收到的数据包丢掉，大量的丢包会极大着浪费网络资源，因此，我们需要控制发送方的发送速率，让接收方与发送方处于一种动态平衡才好。
对发送方发送速率的控制，我们称之为流量控制。
二、如何控制?
接收方每次收到数据包，可以在发送确定报文的时候，同时告诉发送方自己的缓存区还剩余多少是空闲的，我们也把缓存区的剩余大小称之为接收窗口大小，用变量win来表示接收窗口的大小。
发送方收到之后，便会调整自己的发送速率，也就是调整自己发送窗口的大小，当发送方收到接收窗口的大小为0时，发送方就会停止发送数据，防止出现大量丢包情况的发生。
三、发送方何时再继续发送数据?
当发送方停止发送数据后，该怎样才能知道自己可以继续发送数据？
我们可以采用这样的策略：当接收方处理好数据，接受窗口 win > 0 时，接收方发个通知报文去通知发送方，告诉他可以继续发送数据了。当发送方收到窗口大于0的报文时，就继续发送数据。
不过这时候可能会遇到一个问题，假如接收方发送的通知报文，由于某种网络原因，这个报文丢失了，这时候就会引发一个问题：接收方发了通知报文后，继续等待发送方发送数据，而发送方则在等待接收方的通知报文，此时双方会陷入一种僵局。
为了解决这种问题，我们采用了另外一种策略：当发送方收到接受窗口 win = 0 时，这时发送方停止发送报文，并且同时开启一个定时器，每隔一段时间就发个测试报文去询问接收方，打听是否可以继续发送数据了，如果可以，接收方就告诉他此时接受窗口的大小；如果接受窗口大小还是为0，则发送方再次刷新启动定时器。
四、一些术语及其注意点说明
1、这里说明下，由于TCP/IP支持全双工传输，因此通信的双方都拥有两个滑动窗口，一个用于接受数据，称之为接收窗口；一个用于发送数据，称之为拥塞窗口(即发送窗口)。指出接受窗口大小的通知我们称之为窗口通告。
2、接收窗口的大小固定吗？
在早期的TCP协议中，接受接受窗口的大小确实是固定的，不过随着网络的快速发展，固定大小的窗口太不灵活了，成为TCP性能瓶颈之一，也就是说，在现在的TCP协议中，接受窗口的大小是根据某种算法动态调整的。
3、接受窗口越大越好吗？
接受窗口如果太小的话，显然这是不行的，这会严重浪费链路利用率，增加丢包率。那是否越大越好呢？答否，当接收窗口达到某个值的时候，再增大的话也不怎么会减少丢包率的了，而且还会更加消耗内存。所以接收窗口的大小必须根据网络环境以及发送发的的拥塞窗口来动态调整。
4、发送窗口和接受窗口相等吗？
接收方在发送确认报文的时候，会告诉发送发自己的接收窗口大小，而发送方的发送窗口会据此来设置自己的发送窗口，但这并不意味着他们就会相等。首先接收方把确认报文发出去的那一刻，就已经在一边处理堆在自己缓存区的数据了，所以一般情况下接收窗口 >= 发送窗口。
我这篇文章算是可以让你知道流量控制的大致原理，如果你想知道更多细节，可以参考TCP/IP详解这本书，挺不错。文章若有错误，还望后台留言指点下，谢谢。
推荐阅读：
更多原创文章可以关注我的公众号：苦逼的码农(ID:201805)
最新文章
- ASP.NET 5 Beta 7 版本
- 关于redis启动流程介绍
- EntityFramework Core 学习笔记 —— 包含与排除属性
- c++ 概念及学习/c++ concept&learning(三)
- 【每日一摩斯】-Index Skip Scan Feature (212391.1)
- 不允许从数据类型 nvarchar 到 varbinary 的隐式转换
- 【转】Apache配置中ProxyPassReverse指令的含义
- bridge pattern
- 控制结构(3) 状态机(state machine)
- linux 下查看有当前文件夹有多少个文件
- WaitForSingleObject函数
- RPA基础
- Ubuntu修改Apache默认Web端口
- Hybrid App 原理解析
- Grafana展示報表數據的配置（二）
- P3834 【模板】可持久化线段树 1（主席树）
- SDN课程作业总结
- XmlSerializer 对象序列化成XML 自定义编码格式(gb2312)
- Atitit 软件体系的进化，是否需要一个处理中心
- react-router-dom Link search 传参