大话TCP:TCP的流控

Mon 07 August 2017 / In categories Networking Protocols

TCP

TCP带有流控功能,英文叫flow control。这是因为在现实情况下,TCP接收端处理数据的能力是有限的,所以TCP发送的数据最好不要超过接收端的处理能力,否则会有悲剧发生。轻则多余的无法处理的数据会被丢弃,重则会导致接收端的TCP协议栈崩溃。

TCP的流控采用“允许制”的,简单地说发送端所能发送的字节数,必须在接收端允许的窗口大小之内。

一些相应的名词:

  • 接收窗口:接收端可以接收的字节数
  • 发送窗口:允许发送端发送的字节数

稍微思考一下就知道流控的过程有以下步骤:

  1. 接收端:计算接收窗口大小
  2. 接收端:把接收窗口大小通告发送端
  3. 发送端:使用发送窗口控制发送的数据大小,使其不超过接收窗口大小

计算接收窗口大小

RFC793搬来的接收窗口的图,假设接收窗口大小为1:

       1          2          3
   ----------|----------|----------
          RCV.NXT    RCV.NXT
                    +RCV.WND

接收窗口由两个变量表示: * RCV.NXT 下一个待接收的字节的序列号,在上图的例子中为2 * RCV.WND 接收窗口的大小,在上图的例子中为1

所以接收窗口是一个半开半闭区间[RCV.NXT, RCV.NXT+RCV.WND),以上图为例,是[2, 3)

把接收窗口大小通告发送端

TCP的头部定义一个16bit的字段,用于通告接收窗口的大小:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

16bit的Window字段最多可以表示65535个字节的接收窗口大小。如果在带宽很大的情况下,传输速率会受接收窗口大小的影响,那时候就要想办法对窗口大小进行扩张了。一个办法是使用RFC7323定义的“TCP Window Scale Option”对Window字段进行乘数扩展。

使用发送窗口控制发送的数据大小

RFC793搬来的发送窗口的图,

           1         2          3          4
      ----------|----------|----------|----------
             SND.UNA    SND.NXT    SND.UNA
                                  +SND.WND

发送窗口由三个变量控制: * SND.UNA 首个已发送,但是未被应答的序列号,在上图中是2 * SND.NXT 下一个待发送的序列号,在上图中是3 * SND.WND 发送窗口的大小,根据RCV.WND的大小来更新,在上图中是2

由上图可知,发送窗口也是一个半开半闭区间[SND.UNA, SND.UNA+SND.WND),以上图为例,是[2, 4)。发送窗口中已经发送的数据用半开半闭区间[SND.UNA, SND.NXT)表示,此处的规则是 SND.NXT <= SND.UNA+SND.WND,以此来限制发送速率。

窗口滑动的一些问题

可以看到不管是接收窗口还是发送窗口,都是以[A, B)的形式来定义的。随着数据的交互,A随着数据的交互往前推进,向B靠拢,这样窗口就变小了。对于发送窗口而言,需要接收端发来Window字段来更新B。但有时候如果接收端先发来了一个很大Window值,然后又发来一个很小的Window值,可能会导致B朝左边移动,使发送窗口紧缩(shrink)。TCP标准强烈不建议接收端这么做,于此同时又建议发送端要做好准备,即使出现这种情况也要很好处理。

Load Disqus Comments