文章内容概览
TCP 协定的流量管制
流量管制是 TCP 协定特有的性能，对于 UDP 或者其它的一些协定，是没有流量管制
流量管制，简略的来说就是，接管方心愿发送方将数据发送的慢一些。一般来说，咱们是心愿越快越好，然而，还是须要思考一些理论的状况。比方接管方不能那么快的去接管很大的流量，所以心愿发送方的流量慢一些。这就是流量管制
- 流量管制指 让发送方发送速率不要太快
- 流量管制是应用 滑动窗口 来实现的
在 TCP 首部中有 窗口 这个字段，它占 16 个比特位，用来指明容许对方发送的数据量 。在牢靠传输的基本原理这篇文章中有联合确认号和窗口进行了一个运算。比如说，假如确认号是 501，窗口大小是 1000，就示意说，发送方能够发送 501~1500 这个范畴的 1000 个字节的数据，这个就是窗口所起到的作用。 那滑动窗口是怎么做到流量管制的？
假如当初有一个发送方计算机和一个接管方计算机，从上往下是它们之间交互的时间轴
- 假如发送方发送了一个序列号为 1 的数据，发送数据的大小是 100 个字节
- 发送方还能够进行第二次发送，此时发送的数据的序列号就应该是 101，也假如发送数据的大小是 100 字节
- 此时接管方曾经接管到了 200 个字节的数据，假如此时接管方发送了一个确认音讯，确认号是 201，201 示意的就是期待接管到的下一个字节的序号，并且发送的确认音讯中还有一个窗口的大小，假如是 300，示意告知发送方还能够发送 300 个字节的数据。确认音讯中的 ACK 标记为 1
- 发送方在晓得了窗口大小为 300 之后，它就能够持续发送 300 个字节的数据。首先它可能就会发送序列号为 201 的 100 个字节的数据，此时发送方还能再发 200 个字节的数据
- 假如此时发送方发送了序列号为 301 的 200 个字节的数据，此时接管方就能够进行确认了，确认说，它曾经接管到了 601 序列号之前的所有数据了，此时窗口大小为 0，也就是说发送方不能再进行数据发送了
以上就是 通过窗口大小管制对方发送速率
如果接管方发送了窗口为 0 的音讯之后，它马上对接管到的数据进行解决，解决之后交给应用层，一段时间之后，接管方就又能够接管信息的音讯了。此时，接管方就会向发送方发送一个音讯，通知它说，以后我的窗口是 1000，也就是能够接管 1000 个字节的数据。发送方在收到这个音讯之后，发送方又会进行数据的封装，并且将数据发送给接管方。这个就是接管方通过调整窗口的大小来告知发送方能够持续的发送数据
思考一个非凡状况
假如接管方在告诉发送方，它的窗口为 1000 的音讯在传输过程中失落了。这种状况会导致什么样的结果？
对于发送方：发送方会始终期待，因为它还是认为接管方的窗口为 0，所以它始终期待接管方的窗口调大
对于接管方：接管方曾经将窗口调大的音讯通知发送方了，实践上，发送方在收到音讯之后，会将信息的音讯发送给接管方。因而，接管方也会始终期待
所以，因为窗口数据报文的失落，导致发送方和接管方都会始终的在期待，造成 死锁 的场面。此时可能就会有疑难，TCP 不是牢靠传输的吗？这个音讯为什么会失落呢？
其实在探讨 TCP 的牢靠传输时，次要是从数据的角度去思考的。也就是说，对于 TCP 的牢靠传输，都是对数据的确认。比方序列号、以及确认号都是对数据的字节进行确认的，对于非凡的音讯，比方窗口的大小，其实是没有超时重传机制的。因而就会呈现上边提到的死锁场面
保持定时器
要解决上边呈现的死锁状况，就须要 TCP 中的第二个定时器，保持定时器
- 当发送方接管到窗口为 0 的音讯，则启动保持定时器
- 保持定时器每隔一段时间发送一个 窗口探测报文（用来询问窗口有没有增大，这样就能够解决因发送窗口大小的音讯失落导致的死锁场面）