TCP/IP卷一:81---TCP数据流与窗口管理之(流量控制与窗口管理)

一、交互式通信模型

  • TCP客户端和服务器交互作用,互相提供数据流的相关信息,包括报文段序列号、ACK号和窗口大小(即接收端的可用空间)

窗口通告与窗口大小

  • 在前面的ssh示例中,我们看到的窗口通告都是固定的,有8320字节、 4220字节,还有32900字节。这些数值表示发送该窗口信息的通信方为即将到来的新数据预留的存储空间
  • 当TCP应用程序空闲时,就会排队处理这些数据,致使窗口大小字段保持不变
  • 当系统处理速度较慢,或者程序忙于执行其他操作,到来的数据返回ACK后,就需要排队等待被读取或“消耗”。若这种排队状况持续,新数据的可用存储空间就会减小,窗口大小值也随之减小。最终,若应用程序一直不处理这些数据,TCP必须采取策略使得发送端完全停止新数据的发送,因为可能没有空间来存储新数据。此时就可以将窗口通告设为0(没有空间)
  • 窗口通告参阅:https://blog.csdn.net/qq_41453285/article/details/104014872

窗口大小字段、窗口缩放选项

  • TCP连接的每一端都可收发数据。连接的收发数据量是通过一组窗口结构来维护的。每个TCP活动连接的两端都维护一个发送窗口结构和接收窗口结构

二、发送窗口

  • TCP以字节(而非包)为单位维护其窗口结构
  • 在图中,我们已标号为2 - 11字节:
    • 由接收端通告的窗口称为提供窗口包含4 - 9字节
    • 接收端已成功确认包括第3字节在内的之前的数据,并通告了一个6字节大小的窗口
    • 回顾前面介绍的文章,窗口大小字段相对ACK号有一个字节的偏移量。发送端计算其可用窗口,即它可以立即发送的数据量。可用窗口计算值为提供窗口大小减去在传(已发送但未得到确认)的数据值
  • 变量SND.UNA和SND.WND分别记录窗口左边界和提供窗口值。SND.NXT则记录下次发送的数据序列号,因此可用窗口值等于(SND.UNA+ SND.WND - SND.NXT)
  • 随着时间的推移,当接收到返回的数据ACK,滑动窗口也随之右移。窗口两端的相对运动使得窗口增大或减小。可用三个术语来描述窗口左右边界的运动:
    • 关闭(cIose):即窗口左边界右移。当已发送数据得到ACK确认时,窗口会减小
    • 打开(open):即窗口右边界右移,使得可发送数据量增大。当已确认数据得到处理,接收端可用缓存变大,窗口也随之变大
    • 收缩(shrink):即窗口右边界左移。主机需求RFC并不支持这一做法,但 TCP必须能处理这一问题。见后面文章介绍的糊涂窗口综合征中举了一个例子,一端试图将右边界左移使窗口收缩,但没有成功

窗口调节

  • 每个TCP报文段都包含ACK号和窗口通告信息,TCP发送端可以据此调节窗口结构
  • 窗口左边界不能左移,因为它控制的是已确认的ACK号,具有累积性,不能返回
  • 当得到的ACK号增大而窗口大小保持不变时(通常如此),我们就说窗口向前“滑动”
  • 若随着ACK号增大窗口却减小,则左右边界距离减小。当左右边界相等时,称之为零窗口。此时发送端不能再发送新数据。这种情况下,TCP发送端开始探测(probe)对方窗口(见下面的零窗口与TCP连续计时器演示案例),伺机增大提供窗口

三、接收窗口

  • 接收端也维护一个窗口结构,但比发送端窗口简单。该窗口结构记录了已接收并确认的数据,以及它能够接收的最大序列号。该窗口可以保证其接收数据的正确性。特别是,接收端希望避免存储重复的已接收和确认的数据,以及避免存储不应接收的数据(超过发送方右窗口边界的数据)
  • 与发送端窗口一样,该窗口结构也包含一个左边界和右边界,但窗口内的字节(图中的4 - 9字节)并没有区分:
    • 对接收端来说,到达序列号小于左窗口边界(称为RCV.NXT),被认为是重复数据而丢弃
    • 超过右边界(RCV.WND + RCV.NXT)的则超出处理范围,也被丢弃
  • 注意到由于TCP的累积ACK结构,只有当到达数据序列号等于左边界时,数据才不会被丢弃,窗口才能向前滑动。对选择确认TCP来说,使用SACK选项,窗口内的其他报文段也可以被接收确认,但只有在接收到等于左边界的序列号数据时,窗口才能前移
发布了1397 篇原创文章 · 获赞 957 · 访问量 31万+

猜你喜欢

转载自blog.csdn.net/qq_41453285/article/details/104131897