TCP缓存区与窗口的关系

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/yxccc_914/article/details/52515558

网上大多错误的理解

  1. 滑动窗口大小=接受缓存区大小
  2. 接收方通告窗口大小=发送方缓存区大小

注意:以上两个结论都是错误的

我们在学习网络编程时,通常会参考两本很经典的书《UNIX网络编程 卷1》和《TCP/IP 卷1》。然而,我在看与缓存区与窗口相关模块知识点时,通常会犯迷糊。感觉这两本书对其的描述很少,描述得有点模糊。

《TCP/IP详解 卷1》第1版的一句重要的描述,因为在小字处,很容易被忽略。

插口API允许进程设置发送和接收缓存的大小。接收缓存的大小是该连接上所能够通告的最大窗口大小。

说明接收缓存 >= 接收方通告窗口大小。
侧面说明发送缓存区、发送窗口、接收缓存区、接收窗口的大小是不同的

《UNIX网络编程 卷1》第3版只用了2.11一个小节描述TCP缓存区,重要信息是(图2-15):
应用进程缓存区(任意大小)
套接字发送缓存区(SO_SNDBUF)

知识点:应用进程缓存区和套接字发送缓存区是分开的两个东西。TCP发送方分为两个过程。
1. 应用进程write数据到套接字缓存区。
2. TCP套接字从套接字缓存区读取数据,发送出去。

TCP缓存区与窗口关系结论

  1. 发送窗口不是发送方通告的窗口,而是接收方通告的窗口。
  2. 接收方通告的窗口大小=发送方窗口大小。
  3. 接收方通告的窗口大小也=自己的窗口大小(即接收方窗口大小)
  4. 发送缓存>发送方窗口>已发送字节
  5. 接收缓存>接收窗口>接收未确认字节
  6. TCP通信过程中,发送缓存和接收缓存大小不变,发送窗口和接收窗口可能会改变。

预备知识:窗口位置变化

这里写图片描述

发送窗口后沿的变化情况2种可能:
1. 不动:没有收到确认ACK。
2. 前移:收到确认ACK。

发送窗口前沿的变化情况2种可能:
1. 不动:
* 没有收到新的确认,对方通知的窗口大小不变。
* 收到新的确认,但对方通知的窗口缩小。
2. 前移:普遍情况。
3. 后缩:对方通知窗口缩小。但是TCP不赞成这样子做。

TCP缓存区与窗口关系理解

理解发送方缓存区与发送窗口的关系

这里写图片描述
由图可知,发送缓存暂时存放:
1. 发送应用程序传给发送TCP准备发送的数据。
2. TCP已发送出但尚未收到确认的数据。

发送窗口只是发送缓存的一部分。已发送但未被确认数据大小<=发送窗口的大小。已被确认的数据会从发送缓存中删除。发送缓存和发送窗口后沿(这里的左边)是重合的,因为一被确认就会删除。删除后发送缓存和发送窗口的后沿同时向左移。发送应用程序必须控制写入缓存的速率,不能太快,否则发送缓存会没有存放数据的空间。

理解接收方缓存区和窗口关系

这里写图片描述
由图可知,接收缓存暂时存放:
1. 按序到达、但尚未被接收应用程序读取的数据。
2. 未按序到达的数据。

如果接收应用程序来不及读取收到的数据,接收缓存最终会被填满,使接收窗口减少到0.反之,如果接收应用程序能够及时从接收缓存中读取收到的数据,接收窗口可以增大,但最大不能超过接收缓存的大小。接收缓存和接收窗口的前沿(图的右)是重合的。因为等应用程序读取数据后,可能向前沿移动。如果接收窗口<通告时指定大小,则同时向前移。如果接收窗口不能扩大了,则不移动,接收缓存有空闲区域。记住数据只能填充接收窗口,并不是正个接收缓存。

几个模糊问题

  1. 接收方通告的窗口=发送窗口,那么接收窗口=发送窗口吗?
    在同一时刻,发送窗口与接收窗口的大小并不一定相同。这是因为通过网络传送窗口值需要经历一定的时间滞后。另外,发送方还可能根据网络当时的拥塞情况适当减少自己的发送窗口数值(即慢启动和拥塞避免)。

  2. 发送窗口包含着以发送未接收确认ACK的数据,那么接收窗口包含按序到达但未被应用程序读取的数据吗?
    接收窗口包含的是未按序到达的和按序到达,但是将在未来不久后发送确认ACK的数据(累积确认)。不包含按序到达的,已发送了确认的数据。

  3. 接收窗口为什么会缩小?
    接收缓存由按序到达数据、接收窗口数据和空白区域组成。如果接收窗口发送确认ACK,则按序到达数据会增加,假设填满了空白区域,但是应用程序还是来不及读取,接收窗口大小只能减小。减小原来还包括太多未按序到达的数据霸占。

  4. 再补充。。。

展开阅读全文

没有更多推荐了,返回首页