一、滑动窗口
上篇博客我们介绍了TCP报文结构、确认应答机制、超时重传机制、连接管理机制。
TCP保证了可靠传输，但是失去了效率。那么怎么样尽可能提高传输效率呢？？？
我们讨论了确认应答策略：对每一个发送的数据段，都要给一个ACK确认应答，收到ACK后再发送下一个数据段。
这样做有一个比较大的缺点，就是性能较差，尤其是数据往返的时间较长的时候。
主机A大量的时间都消耗在了等待ACK上！
既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能 (其实是将多个段的等待时间重叠在一起了) ！
- 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节 (四个段)。
- 发送前四个段的时候，不需要等待任何ACK，直接发送；
- 收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；
- 操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答；只有确认应答过的数据才能从缓冲区删掉；
- 窗口越大，则网络的吞吐率就越高；
那么如果出现了丢包，如何进行重传？这里分两种情况讨论。
情况一： 数据包已经抵达，ACK被丢了。
这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认！
情况二： 数据包就直接丢了。
2001 – 7000 接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中。
这种搭配滑动窗口的机制被称为”高速重发控制” (也叫”快重传”)。
二、流量控制
窗口大小越大，确实发送速度会更快~~ 但是窗口能无限大吗？
接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。
因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制 (Flow Control) ！
接收方的接收速率如何进行量化？
接收方使用接收缓冲区的剩余空间大小来作为发送方发送速率(窗口大小)的参考数值！
如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。
接收端如何把窗口大小告诉发送端呢？回忆我们的TCP首部中，有一个16位窗口字段，就是存放了窗口大小信息：
16位数字最大表示65535，那么TCP窗口最大就是65535字节么？
实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位~~
三、拥塞控制
流量控制是通过接收方的处理能力来衡量发送方的速率的。
难道只需要考虑接收方的处理速率吗？显然不是，还得考虑中间的这些转发节点的情况！
网络的环境是复杂的，网络环境也不是一成不变的~~
这就是拥塞控制！
流量控制是在控制发送方的窗口大小；拥塞控制也是在控制发送方的窗口大小。
那么有分歧的时候听谁的？谁小听谁的！！！(木桶原理)
TCP实现拥塞控制的具体方式是什么呢？
TCP引入慢启动机制，先发少量的数据探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。
拥塞控制，归根结底是TCP协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案~~
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由半码博客整理，本文链接：https://www.bmabk.com/index.php/post/118572.html
