UDP的可靠性传输(上)

一、知识储备:

1. RTT

发送方请求包到接收到应答包的时间差, 如下图所示,RTT = T2- T1
在这里插入图片描述

2. 流量控制:

  • 概念:控制发送方的发送速率,称之为流量控制。

  • 出现原因: 是发送方的发送数据的速率和接收方接收数据的速率不一定是一致的。发送方出现速率大于接收方接收的速率,会导致未被未被处理的数据丢弃掉,丢弃掉又会导致发送进行重传。

  • 控制方式:通过窗口机制去控制。接收方每次收到数据包后,可以在发送ACK报文的时候,同时告诉发送方自己的缓存区还剩余多少是空闲的,把缓冲区的剩余大小称之为接收窗口大小,用变量win来表示的接收窗口的大小;发送方收到之后,便会调整自己的发送速率,也就是调整自己的发送窗口的大小,发送方收到窗口大小为0时,发送方就会停止发送数据,防止大量丢包情况发生。

在这里插入图片描述

  • 问题:
    1. 发送方何时在继续发送数据?
      答:
      当接收方处理好数据,接收窗口win > 0 时,接收方发个通知报文通知发送方;
      当发送方收到接收窗口win = 0时,发送方停止发送报文,同时开启一个定时器,每隔一段时间发送测试报文进行询问接收方,打听是否可以继续发送数据了。
      在这里插入图片描述
  1. 接收窗口的大小是固定的吗?
    答:不是固定的,需要根据网络情况动态调整的。丢包多的情况需要减小接收窗口

  2. 接收窗口越大越好吗?
    答:接收窗口过大容易导致丢包

  3. 发送窗口和接收窗口相等吗?
    答:一般接收窗口 >= 发送窗口

3. ACK机制

请求端发送数据给应答方,请求端需要确认应答方是否已经收到数据包。因此需要应答方发送ACK报文,请求端收到数据包后,知道数据发送成功,准备下一次的数据包发送

4. 停等式

客户端发送数据后,需要接收服务端发送的ACK报文,才进行下一次发送。这种方式比较浪费时间,客户端需要花费时间等待ACK报文.。与之相对应的是非停等式的,可以连续发送几条请求包。

5. 重传机制,重传策略

客户端向服务端发送数据,在RTT内,如何没有收到服务端的应答包,客户端认定为数据发送失败,需要重传;

  • 回退n帧:
    如下图所示,序号2分组丢失,该分组及之后的分组都将被重传
    在这里插入图片描述

  • 选择性重传:
    如下图所示,分组2丢失后,只需要重传2分组
    在这里插入图片描述

6. 序号机制

数据发送端给对端发送多个数据包,接收端需要依据数据包的序号,对报文进行排序。如果没有按照序号排序,数据就会乱序

8. 拥塞控制

网络出现拥塞后,如何恢复发包的速率,首先经历满开始,慢启动,快恢复三个阶段去抢占带宽,如下图所示。

在这里插入图片描述

思考:拥塞控制和流量控制虽然采取的动作很相似,但拥塞控制与网络的拥塞情况相关联,而流量控制与接收方的缓存状态相关联。拥塞控制是根据丢包情况调整发送窗口,调整发送数据的速率

9. 快速重传

发送端发送1,2,3,4,5 几个包,接收端只接收到1,3,4,5,接收端发送ack = 3 的报文给发送端,发送端知道seq= 2的包被丢失一次,如果收到ACK=4的包知道seq=4的包,知道seq=2的包被丢失2次,不用等待超时,直接重传seq=2的包。

10. 非延迟应答与延迟应答

如下图所示,请求和应答是同步的情况

在这里插入图片描述
如下图所示,只应答seq =2的报文,表明seq=1,seq=2的报文已经被接收端接收
在这里插入图片描述

三、UDP如何可靠,KCP协议在哪些方面有优势

UDP是不可靠性传输协议,借鉴TCP 的可靠性传输的原理, 在用户层进行协议设计。KCP 协议由此诞生,它在用户层采用选择性重传,只传丢失的数据包,同时也允许存在丢包情况。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值