计算机网络 | TCP流量控制及拥塞控制 | 参考自湖科大 | 无知的我费曼笔记(图文排版无水印)

无知的我正在复盘计算机网络。。。
笔记特点是

  • 重新整理了涉及资料的一些语言描述、排版而使用了自己更容易理解的描述。。
  • 提升了总结归纳性
  • 同样是回答了一些常见关键问题。。。

TCP的流量控制

TCP的流量控制机制及问题

问题 一般来说,我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快,接收方就可能来不及接收,这就会造成数据的丢失

解决办法 使用流量控制(flow control)让发送方的发送速率不要太快,要让接收方来得及接收

利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制

  • TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小
  • TCP发送方收到接收方的零窗口通知后,应启动持续计时器。持续计时器超时后,向接收方发送零窗口探测报文

滑动窗口 特点

在一次发送/接收中,只能一次性发送/接收设置好数量的数据

如果想继续发送/接收数据,则必须等待接收/发送方响应后才能继续

每一次的发送,都会“向前”滑动窗口来移出已发送、已确认的数据

滑动窗口在每次传输中,会根据对方发来的ack调整自己窗口大小,然后再发送数据

举例说明 主机B对主机A的流量控制

每个发送的TCP报文段可以携带100字节,所以图中的小格子代表100个字节的序号

在双方建立TCP连接时,B告诉A“我的接收窗口为400”,所以主机A将自己的发送窗口也设置为400

=>这意味着,在主机A没收到主机B的确认信息时,可以把处在发送窗口的所有字节发送出去

image-20220509235610447

@seq是 TCP报文段首部中的序号字段;取值1表示TCP报文段数据载荷的第一个字节的序号是1

@DATA 表示TCP数据报文段

@ACK是 TCP报文段首部中的标志位;取值为1表示这是一个TCP确认报文段

@ack是 TCP报文段首部中的确认号字段;取值201表示序号201之前的数据已经全部正确接收,现在希望收到201及其后的数据

@rwnd是 TCP报文段首部中的窗口字段;取值为300表示自己的接收窗口大小为300

数据丢失后,接收方的发送的ack值为201后,会发生什么?

根据接收方发送给来的ack的值确定了自己发送窗口要发送了数据序号区间(如上图是 重新包含了已经发送的201~300序号的字节数据);若重传计时器超时,那么这些数据会被重新传送

根据ack的值主机A确定了已经发送成功的字节数据(如上图是 1~200),然后将它们全部删除

引出问题 流量控制中出现死锁的情况。如下

image-20220510002448033

解决办法是 使用持续计数器

持续计时器 作用

记录每次发送请求的时长

  • 若超时,则发送一个零窗口探测报文,携带1字节数据
  • 对方收到报文后,发送携带窗口大小的报文,解除死锁

引出问题 既然接收方的接收窗口是0,那怎么接收零窗口探测报文?

按照TCP规定,即使是这样,接收方依旧要接收该报文(比如还有确认报文段、携带有紧急数据的报文段)

引出问题 如果零窗口探测报文也丢失了,还能打破死锁吗?

能。这是因为它也有重传计时器

举例说明。如图

image-20220510003347734

2010 题39

image-20220510003515653

TCP的拥塞控制

TCP的拥塞控制的定义及作用

网络拥塞 原因

  1. 点缓存的容量太小;
  2. 链路的容量不足;
  3. 处理机处理的速率太慢;
  4. 拥塞本身会进一步加剧拥塞;

如何知道网络拥塞?

以下这些指标的上升都标志着拥塞的增长。

  1. 由于缺少缓存空间而被丢弃的分组的百分数;
  2. 平均队列长度;
  3. 超时重传的分组数;
  4. 平均分组时延;
  5. 分组时延的标准差,等等。

拥塞控制 是什么

在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络性能就要变坏的情况

@网络资源包括 计算机网络中的链路容量(即带宽)、交换结点中的缓存和处理机等等

拥塞控制的一般原理

  • 拥塞控制的前提:网络能够承受现有的网络负荷。
  • 实践证明,拥塞控制是很难设计的,因为它是一个动态问题
  • 分组的丢失是网络发生拥塞的征兆而不是原因。
  • 在许多情况下,甚至正是拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因。

TCP的拥塞控制 作用。如图举例说明

若出现拥塞而不进行控制,整个网络的吞吐量将随输入负荷的增大而下降

  • 输入负载代表 单位时间内输入给网络的分组数量
  • 吞吐量代表 单位时间内从网络输出的分组数量

image-20220510103938860

TCP四种拥塞算法

慢开始和拥塞避免

慢开始算法 机制

发送方每收到一个对新报文段的确认时,就把拥塞窗口值加倍,然后开始下一轮的传输

当拥塞窗口值增长到慢开始门限值时,就改为执行拥塞避免算法。

拥塞避免 机制

发送方每收到一个对新报文段的确认时,仅仅把拥塞窗口值+1,然后开始下一轮的传输

当重传计时器超时,将慢开始门限值更新为当前拥塞窗口值的一半;将拥塞窗口值重置为1。这就意味着重新开始了慢算法

慢开始算法和拥塞避免 特点

image-20220510105050952

如下举例说明它们的机制

  • 横坐标为传输轮次,传输轮次是指发送方给接收方发送数据报文段后,接收方给发送方发回相应的确认报文段,一个传输轮次所经历的时间,其实就是往返时间。

  • 请注意,往返时间并非是恒定的数值。使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去,并收到了对已发送的最后一个报文段的确认。

  • 纵坐标是拥塞窗口,它会随网络拥塞程度以及所使用的拥塞控制算法动态变化。在TCP 双方建立逻辑连接关系时,拥塞窗口的值被设置为一。

image-20220510105720971

=>慢开始是 指一开始向网络注入的报文段少,并不是指拥塞窗口cwnd增长速度慢

=>拥塞避免并非完全指能够避免拥塞,只是使得网络比较不容易出现拥塞

快重传和快恢复

快重传 作用

对于个别丢失的报文段,发送方不会出现超时重传,也就不会误认为出现了拥塞。使用快重传可以使整个网络的吞吐量提高约20%

快重传 定义&机制

是使发送方尽快进行重传,而不是等待超时重传计时器超时再重传

要求接收方不用等待自己发送数据时才进行捎带确认,而是要立即发送确认

即使收到了失序的报文段(说明有一段丢失了)也要立即发出对已收到的报文段的重复确认

发送方一旦收到3个连续的重复确认,就将相应的报文段立即重传,而不是等该报文段的超时重传计时器超时再重传

快重传机制 如图

image-20220510111233367

快恢复 定义&机制

发送方一旦收到3个重复确认,就知道现在只是丢失了个别报文段。也是不启动慢开始算法,而执行快恢复算法

  • 发送方将慢开始门限ssthresh值和拥塞窗口cwnd值调整为当前窗口的一半,开始执行拥塞避免算法
  • 也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些,即等于新的ssthresh+3

这是因为

  • 既然发送方收到3个重复的确认,就表明有3个数据报文段已经离开了网络
  • 这三个报文段不再消耗网络资源而是停留在接收方的接收缓存中
  • 可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些

算法机制 对比图如下

image-20220510111633708

2009 题39

image-20220510112010504

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值