1 利用滑动窗口实现流量控制
流量控制就是让发送方的发送速率不要太快,要让接收方来得及接收。即发送方的发送速率和接收方应用程序的读取速率相匹配。
TCP利用滑动窗口机制实现对发送方的流量控制。在建立连接的三次握手过程中通信双方协商一些参数,其中就有窗口值rwnd,接收方会将自己的接收能力存放字窗口值字段中传送给发送方,发送方根据这个窗口值设置发送窗口的大小。因此发送方发送窗口不能超过接收方给出的接收窗口的数值。
TCP的窗口单位是字节。
如下图所示,现假设接收方在建立连接告知发送方自己的接收窗口值是400,数据报文段的序号是从1开始的。ACK表示确认位,ack表示确认字段的值。一个报文段的长度是100字节,图中发送窗口中一个窗口表示100字节。
(1) 开始时刻的窗口状态如下图所示。
(2) ① ~ ③表示发送方发送了300个字节,但是序号为201~300的字节丢失,发送方发送完之后的窗口状态如下图所示。
(3) ④接收端返回确认报文段,其中ack = 201,表示下一个期望收到的报文段序号为201。其中确认报文段中携带者接收方给发送方的接收窗口值为300,此时发送窗口的状态如下图所示。
(4) ⑤ ~ ⑦分别发送了序号301-500的数据,其中丢失的数据由于计时器超时,进行了重传,此时窗口已满,状态如下图所示。
(5) ⑧接收方返回对序号201-500的数据的确认,并再次将发送窗口大小设置为100个字节。发送窗口状态如下图所示。
(6) ⑨发送方发送序号为501-600的数据,窗口已满,不能在发送了,此时状态如下。
(7) ⑩接收方返回确认,并将窗口大小设置为0,即不让发送方发送数据了。
上述过程中,接收方一共进行了3次流量控制,第一次将窗口大小减小至300,第二次将窗口大小减小至100,最后一次将窗口大小设置为0。
现在考虑这样一种情况,接收方在发送了零窗口的报文段不久之后,接收方的缓存又有了一些空间,于是接收方就向发送方发送了一个报文段,其中的窗口值为400,表示发送方又可以发送数据,然而这个报文段在传送的过程中丢失了,发送方一直在等待接收方的非零窗口的通知,而接收方一直在等待发送方的数据。如果没有其他措施,这种相互等待的死锁局面一致延续下去。
为了解决这个问题,TCP为每个连接设有一个持续计时器(persistence timer)。只要TCP连接的一方收到了对方的零窗口通知,就启动持续计时器。若持续计时器设置时间到期,就发送一个探测报文段(仅携带1字节的数据),而对方就在确认这个探测报文段时给出了现在的窗口值,如果窗口值仍然是零,那么收到报文段的一方就重新设置持续计时器。如果窗口不是零,则死锁的僵局就打破了。
TCP规定,即使设置窗口为零,也必须接收以下报文段:零窗口探测报文段、确认报文段和携带紧急数据的报文段。
2 TCP的传输效率
应用进程将数据传送到TCP的发送缓存后,剩下的发送任务就由TCP来控制了。可以用不同的机制来控制TCP报文段的发送时机。
(1) 第一种机制:TCP维持一个变量,它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节,就组装成一个TCP报文段发送出去。
(2) 第二种机制:由发送方的应用进程指明要求发送报文段,即TCP支持推送(push)操作。
(3) 第三种机制:发送方的一个计时器时限到了,这时就把当前已有的缓存数据装入报文段(但长度不能超过MSS)发送出去。
前面说过,如果发送方仅发送一个字节数据,那么在传输过程中对数据组装到网络层至少需要41字节,当在线路带宽不富裕时,这种传送方法的效率的确不高。
在TCP的实现中广泛使用Nagle算法。Nagle算法要求,当一个TCP连接中有在传数据(即那些已发送但还未经确认的数据),小的报文段(长度小于MSS)就不能发送,将这些小数据放入发送缓存中,直到所有的在传数据都收到了ACK.。并且,在收到ACK后,TCP需要将缓存中的小数据整合到一个报文段中发送。这种方法迫使TCP遵循停等协议——只有在收到所有在传数据的ACK后才能继续发送。该算法的优点在于它实现了自时钟控制:ACK返回的越快,数据传输的也就越快。
Nagle算法还规定:当发送缓存中的数据达到发送窗口大小的一半或已达到报文段的最大长度时,就立即发送下一个报文段。
在相对高延迟的广域网中,更需要减少小报文段的数目,该算法使得单位时间内发送报文段数目更少。也就是说RTT控制着发包速率。
3 糊涂窗口综合症
基于窗口的流量控制机制,尤其是不使用大小固定的报文段的情况,可能会出现称为糊涂窗口综合症SWS(Silly Window Syndrome,SWS)
TCP连接的两端都有可能导致SWS的出现:接收端的通告窗口较小(没有等到窗口变大才通知),或者发送端发送的数据段较小(没有等待将其他数据组合成一个更大的报文段)。
例如,TCP接收缓存已满,而交互式应用进程一次只从接收缓存中读取1个字节(这样就使接收缓存仅腾出1个字节),然后向发送方发送确认,并把窗口设置为1个字节。接着,发送方又发来1个字节的数据。接收方发回确认,仍然将窗口设置为1个字节。这样下去,是网络的效率很低。
要解决这个问题,需要遵循以下规则:
(1) 对于接收端来说,可以让接收方等待一个段时间,使得接收缓存已有足够的空间容纳一个MSS,或者等待接收缓存已有一半的空闲空间。
(2) 对于发送方来说,不应发送小的报文段,而且需由Nagle算法控制何时发送,为避免SWS问题,只有至少满足以下条件之一时才能传输报文段:
1) 全长(发送MSS字节)的报文段可以发送。
2) 数据段长度 ≥ 接收端通告过的窗口值的一半的,可以发送。
3) 满足以下任一条件的都可以发送:i) 某一ACK不是目前期盼的(即没有未被确认的在传数据);ii) 该连接禁用Nagle算法。
条件 1) 最直接地避免了高耗费的报文段传输问题。条件 2) 针对通知窗口较小,可能小于要传输的报文段的情况。条件3) 防止TCP在数据被确认以及Nagle算法启用的情况下发送小的报文段。若发送端应用在执行某些小的写操作(如小于报文段大小)。条件3) 可以有效避免SWS。