---

TCP核心机制

前一篇文章 JavaEE: 深入探索TCP网络编程的奇妙世界(四)
书接上文~

TCP核心机制六: 拥塞控制

为什么要有拥塞控制?

虽然有了TCP滑动窗口这个大杀器,能够高效可靠的发送大量数据,但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题.

因为网络上有很多的计算机,可能当前的网络状态就已经比较拥堵,在不清楚当前网络的状态下,贸然发送大量的数据,可能导致雪上加霜.

动态调整的拥塞控制

流量控制可以使用接收方接收缓冲区剩余空间来进行衡量.

但是拥塞控制就比较复杂了.需要考虑中间节点的情况.比如:

1. 中间的节点非常多.
2. 每次传输的数据,走的路线还都不一样.
3. 中间哪个节点遇到瓶颈了,都不好说.
4. 中间节点传输数据不止有你A的数据,还有其他设备的数据.

虽然问题看起来更复杂了,但是不打紧,聪明的程序员总有办法.

我们可以通过"做实验"的方式,来找到一个合适的发送速度.

1. 先按照一个比较小的速度,发送数据.
2. 数据非常畅通,没有丢包,说明在网络上传输数据整体上是比较通畅的,此时就可以加快传输数据的速度~
3. 增大到一定的速度之后,发现丢包了,说明网络上可能存在拥堵了,此时就可以减慢传输数据的速度.
4. 减速之后,发现又不丢包了,继续再加速.
5. 加速之后发现又丢包了,继续减速.

发送速度是会一直持续的动态变化的~
毕竟网络环境也是一直变化的.

流量控制,会限制发送窗口
拥塞控制,也会限制发送窗口
这两个机制,会同时起作用,最终实际的发送窗口大小,取决于上述两个机制得到的发送窗口的较小值~

拥塞控制中,窗口大小具体的变化过程

1. 刚开始传输数据,拥塞窗口会非常小,用一个很小的速度来发送数据

   当前网络是否拥堵?未知.
   刚启动的时候,发数据的速度很慢~

2. 不丢包,增大窗口大小(指数增长)

   增长速度特别快,短时间内达到很大的窗口大小.

3. 增长到一定程度,达到某个指定的阈值,此时,即使没丢包,也会停止指数增删,变成线性增长.

   不至于太快的进入到丢包的节奏

4. 线性增长,也会持续地使发送速度越来越快,达到某个情况下,就会出现丢包.

   一旦出现丢包,接下来就需要减少发送的速度,减小窗口大小.
   此时有以下两种出来方式:

   1. 经典的方案,回归到开始非常小的初始值,之后指数增长,线性增长~
   2. 现在的方案,回归到新的阈值上,线性增长(以后都不会指数增长了).

拥塞控制,归根结底是TCP协议想尽可能快的把数据传输给对方,但是又要避免给网络造成太大压力的折中方案.

流量控制和拥塞控制,实际上都是在对"可靠传输"进行补充~

TCP核心机制七: 延时应答

如果接收数据的主机立刻返回ACK应答,这时候返回的窗口可能比较小.

• 假设接收端缓冲区为1M,一次收到了500K的数据,如果立刻应答,返回的窗口就是500K.
• 但实际上可能处理端处理的速度很快,10ms之内就把500K数据从缓冲区消费掉了.
• 在这种情况下,接收端处理还远没有达到自己的极限,即使窗口再放大一些,也能处理过来.
• 如果接收端稍微等一会再应答,比如等待200ms再应答,那么这个时候返回的窗口大小就是1M.

一定要记得,窗口越大,网络吞吐量就越大,传输效率就越高,我们的目标是在保证网络不拥塞的情况下尽量提高传输效率~

所有的包都可以延迟应答吗?肯定也不是~

• 数量限制: 每隔N个包就应答一次.
• 时间限制: 超过最大延迟时间就应答一次.

具体的数量和超时时间,不同的操作系统有不同的差异,一般N取2,超时时间取200ms.

TCP核心机制八: 捎带应答

捎带应答是在延时应答的基础上,引入的提升效率的机制,它可以把返回的业务数据,和ACK两者合二为一.

在实际网络通信中,大部分的情况,都是"一问一答"这样的形式~

ack是内核返回的,是收到请求之后,立即就返回ack.

响应,则是应用程序返回的.在代码中,根据请求计算得到响应,再把响应写回到客户端.

正常情况下,ack和响应,是不同的时机返回的,无法合并.
但是,ack涉及到"延时应答".
延时应答就会使ack返回的时间,被往后拖.
这样一延时,就可能赶上接下来要发送响应数据的操作了.

于是就可以在发送响应的时候,把刚才ack的信息也带上.

本身ack报文,不需要载荷,ack报文主要设置以下内容

• ack这一位为1
  设置窗口大小的值,设置确认序号…

相应数据主要是设置载荷,和ack不冲突.
这俩是可以共存的~

四次挥手,也涉及到类似的情况.

延时应答,捎带应答,都是TCP提升性能的机制.

TCP之所以复杂,不仅仅在考虑可靠传输,还要考虑在可靠传输的基础上,尽可能的提高效率~

本文到这里就结束啦~