UDP的可靠性传输2

系列文章目录

第一章 UDP的可靠性传输-理论篇(一)
第二章 UDP的可靠性传输-理论篇(二)



三、流量控制

RTO

RTO (Retransmission TimeOut) 即重传超时时间

RTT

RTT(Round Trip Time) 往返时延 。 表示从发送端发送数据开始 到发送端收到来自接收端的确认 接收端收到数据后便立即发送确认 总共经历的时延;
由三部分组成:

  1. 链路的传播时间 (propagation delay)
  2. 末端系统的处理时间
  3. 路由器缓存中的排队和处理时间 (queuing delay)

其中前两个部分的值对于一个 TCP 连接相对固定 路由器缓存中的排队和处理时间会随着整个网络拥塞程度的变化而变化 。 所以 RTT 的变化 在一定程度上 反应网络的拥塞程度

流量控制

  1. 双方在通信的时候,发送方的速率与接收方的速率是不一定相等, 如果发送方的发送速率太快 会导致接收方处理不过来,这时候接收方只能把处理不过来的数据存在缓存区里 (失序的数据包也会被存放在缓存区里)。
  2. 如果缓存区满了发送方还在疯狂着发送数据,接收方只能把收到的数据包丢掉,大量的丢包会极大着浪费网络资源 因此 我们需要 控制发送方的发送速率让接收方与发送方处于一种动态平衡才好.

对发送方发送速率的控制 称之为流量控制

1.如何控制流量

  1. 接收方每次收到数据包可以在发送确定报文的时候, 同时告诉发送方自己的缓存区还剩余多少是空闲的 我们也把缓存区的剩余大小称之为接收窗口大小 ,用变量 win 来表示接收窗口的大小
  2. 发送方收到之后,便会调整自己的发送速率 ,也就是调整自己发送窗口的大小, 当发送方收到接收窗口的大小为 0 时发送方就会停止发送数据, 防止出现大量丢包情况的发生.

2. 发送方何时在发送数据

当发送方停止发送数据后,该怎样才能知道自己可以继续发送数据?

  1. 当接收方处理好数据,当接收方处理好数据,接受窗口win > 0 时, 接收方发个通知报文去通知发送方 ,告诉他可以继续发送数据了。当发送方收到窗口大于 0 的报文时,就继续发送数据。
  2. 当发送方收到接受窗口win = 0 时,这时发送方停止发送报文,并且同时开启一个定时器每隔一段时间就发个测试报文去询问接收方 ,打听是否可以继续发送数据了,如果可以,接收方就告诉他此时接受窗口的大小;如果接受窗口大小还是为 0 ,则发送方再次刷新启动定时器。

3.流程图

在这里插入图片描述

拥塞控制

1.慢启动

拥塞控制图

在这里插入图片描述

在这里插入图片描述


总结

提示:这里对文章进行总结:

1.拥塞控制和流量控制总结

  1. 拥塞控制和流量控制采取的动作相似;
  2. 拥塞控制与网络的拥堵情况相关联
  3. 流量控制与接收方的缓存状态相关联;

2.流量控制

通信的双方都拥有两个滑动窗口,一个用于接受数据,称之为接收窗口;一个用于发送数据,称之为拥塞窗口 即发送窗口指出接受窗口大小的通知我们称之为窗口通告。

3. 接收窗口的大小固定吗?

接受窗口的大小是根据某种算法动态调整的。

4. 接收窗口越大越好吗?

当接收窗口达到某个值的时候,再增大的话也不怎么会减少丢包率的了,而且还会更加消耗内存。所以接收窗口的大小必须根据网络环境以及发送发的的拥塞窗口来动态调整。

5.发送窗口和接受窗口相等吗?

接收方在发送确认报文的时候,会告诉发送发自己的接收窗口大小,而发送方的发送窗口会据此来设置自己的发送窗口,但这并不意味着他们就会相等。首先接收方把确认报文发出去的那一刻,就已经在一边处理堆在自己缓存区的数据了,所以一般情况下 接收窗口 >= 发送窗口

体验入口

推荐一个不错的学习地址体验:体验入口

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

技术鱼

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值