5.7 TCP流量控制

思维导图： 

 

 

笔记：5.7 TCP的流量控制

5.7.1 利用滑动窗口实现流量控制

核心概念： 流量控制是为了防止发送方发送数据过快，使得接收方来不及处理，从而避免数据丢失。TCP使用滑动窗口机制来实现流量控制。

滑动窗口机制：

• 发送窗口：发送方基于接收方的接收能力来决定其发送窗口的大小。
• 接收窗口（rwnd）：接收方根据自己的缓冲区空间，告知发送方其可接收的最大数据量。

流程解析（参考图5-22）：

1. 窗口大小协商：连接建立时，B告知A其接收窗口大小（rwnd=400字节）。
2. 数据传输：A根据B提供的窗口大小发送数据，确保不超过rwnd。
3. 窗口调整：B根据自身缓冲区的变化，动态调整rwnd的大小（例如：300，100，到0）。
4. 窗口为0时的特殊情况：
   • 当rwnd为0，A停止发送数据。
   • 如果B的窗口大小从0变为非0，但更新窗口的报文段丢失，会发生死锁。

死锁解决 - 持续计时器：

• 零窗口探测：A收到rwnd=0时，启动持续计时器。
• 持续计时器到期：A发送探测报文段（1字节数据）。
• 窗口更新：B在确认探测报文段时，告知当前窗口大小。

关键注意点：

• ACK位与确认号：ACK=1时，确认号字段才有效。
• 窗口大小的字节单位：TCP的窗口大小以字节为单位，与报文段无关。
• 零窗口的探测和恢复：持续计时器和零窗口探测保证了即使在rwnd更新丢失时也不会发生永久的死锁。

应用场景：

• 高延迟网络：确保接收方有足够时间处理数据。
• 快速发送者与慢速接收者：适应接收方的处理能力，避免溢出。

易错点提示：

• 不要忘记窗口大小是动态变化的，需要根据反馈实时调整。
• 确保理解持续计时器的作用和如何防止死锁。
• 注意窗口大小和序号的单位都是字节。

可以对TCP的流量控制有一个清晰、结构化的理解，并记住实现时的关键点和潜在的陷阱。

 我的理解：

TCP（传输控制协议）的流量控制是一种基本机制，它旨在防止发送方过快地发送数据，从而导致接收方处理不过来。这是一种保证发送方和接收方速率匹配的机制，防止网络拥塞和数据丢失。可以通过以下几个方面来理解TCP的流量控制：

1. 发送方和接收方速度匹配：

   • 如果发送方发送数据太快，接收方可能因为缓冲区满了而无法处理新数据，导致数据包丢失。
   • 如果接收方的处理能力不足，它可以通过控制窗口的大小来限制发送方的发送速率。

2. 滑动窗口协议：

   • TCP使用滑动窗口协议作为流量控制的手段。
   • 窗口大小是动态调整的，接收方根据自己的缓冲区空间动态告知发送方它的窗口大小（即它能接收的最大数据量）。

3. 接收窗口（rwnd）：

   • 接收窗口是接收方根据当前可用的缓冲区大小动态设置的，它告诉发送方可以发送的数据量。
   • 发送方必须尊重这个窗口大小，不得发送超过窗口所允许的数据。

4. 反压机制：

   • 当接收方处理不过来时，它会减少窗口的大小，有时甚至设置窗口为0，此时发送方就不得不停止发送数据。
   • 这就是一种反压机制，确保发送方不会溢出接收方的缓冲区。

5. 零窗口和持续计时器：

   • 当发送方收到一个零窗口通知时，它会启动一个持续计时器，并周期性地发送零窗口探测报文段。
   • 这些探测报文段允许发送方检测接收方的窗口是否已经开放，从而恢复数据传输。

6. 数据流动性和公平性：

   • TCP流量控制不仅保证了数据的流动性（即数据可以持续地流动），还保证了网络中不同连接的公平性。
   • 网络内的每个TCP连接都会根据其对方的能力来调整自己的发送速度。

理解TCP的流量控制需要注意的是，这不仅仅是为了防止网络拥塞，而且是为了在发送方和接收方之间建立一种沟通，确保数据传输的可靠性和效率。

5.7.2 TCP的传输效率

发送时机控制

• 基于MSS: 当TCP发送缓存累积数据达到最大报文段长度(MSS)时自动发送。
• 推送操作: 应用进程直接指示TCP发送数据，无论大小。
• 计时器: 发送缓存中的数据在计时器到期时发送，不超过MSS。

发送控制的复杂性

• 发送时机控制因素多样，如交互式应用中小数据包的高开销。

交互式数据传输效率问题

• 小数据包（如单个字符）发送效率低下，例如，TELNET连接，一次键击可能导致多个小数据包往返，浪费带宽。

解决策略

• 延迟确认: 合并多个确认以减少通信量。
• 捎带确认: 附带数据的确认，减少单独确认包的需要。

Nagle算法

• 防止网络被零星小数据包淹没。
• 发送第一个字节，缓存随后字节，等待确认后再发送累积的数据。
• 在数据达到发送窗口的一半或MSS时，立即发送报文段。

糊涂窗口综合征(SWS)

• 接收方缓存问题，一次只读取一个字节，导致效率低下的确认往返。
• 解决方案：等待缓存足够或有一半空间后再发送确认，通知窗口大小。

接收窗口(rwnd)注解

• 应被译为“接收方窗口”，在上下文清晰时可称为“接收窗口”。

窗口大小和报文段

• 避免零窗口状态下无法接收的问题，某些报文段（如零窗口探测报文段、确认报文段和紧急数据）必须被接收。

优化传输

• 接收方和发送方应避免发送过小的报文段。
• 接收方不应在有限的空间释放后就发送窗口更新，应等待更大的缓冲区空间或半满。

我的理解：

假设TCP是一家邮递公司，而数据包就像是要寄送的信件。

1. 最大报文段长度（MSS）： 比如邮递公司的规定是一次可以送一个大包裹而不是多个小包裹。如果你要寄许多小信件，公司会等信件积累到足够装一个大包裹（即MSS大小）才出发，这样可以减少路上的来回次数，提高运输效率。

2. 推送操作： 这就像是如果你急需立即发送一个重要的信件，你可以告诉邮递员不用等积累成大包裹了，即使是单独的一个小信件也要立即寄出。

3. 计时器： 如果邮局里的信件很久都没有积累到足够一个大包裹的量，邮递公司会设置一个时间限制，比如每天下午3点，不管有多少信件都要发出去，避免信件在仓库里堆积太久。

4. Nagle算法： 想象一个客户每写完一句话就想发一个信件。邮递公司采用Nagle算法，就会建议客户等写完好几句甚至是整封信再发，这样可以有效减少运输成本和次数。

5. 糊涂窗口综合征（SWS）： 现在假设有些客户很急躁，每写一句话就想寄出一个信件。邮局工作人员每收到一句话就要处理寄送，这就导致邮递员来来回回只为了传递很少量的信息。这就好比邮递公司不停地只为了送一张明信片而跑一趟，极其浪费时间和资源。

6. 优化确认和窗口大小： 邮局和客户之间有一个协议：客户告诉邮局他们的“信箱大小”，邮局只有在确保客户的“信箱”有足够空间时才会发送邮件。如果邮局发现客户正在慢慢处理邮件，那么它会等到积累了足够多的邮件，或者客户准备好接收更多邮件时，才会再次寄出，这样可以确保邮递效率和客户的处理能力都得到优化。