UDP的可靠性传输

UDP系列文章目录

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



前言

传输层协议TCP协议和UDP协议,协议的特点分析如下
TCP协议(Transmission Control Protocol,传输控制协议)为应用层提供可靠的、面向连接的和基于流(stream)的服务。使用超时重传、序
号、数据确认等方式来确保数据包被正确发送至目的地

UDP(User Datagram Protocaol 用户数据包协议) 是无连接的面向消息的数据传输协议。
缺点:
1.数据包容易丢失; 数据确认,超时重传机制;
2.数据包无序; 重排机制

必须制定上层协议,包括 流控机制、超时机制、重排机制、重传机制

选项TCPUDP
是否连接无连接面向连接
是否可靠不可靠传输,不使用流量控制和拥塞控制可靠传输,使用流量控制和拥塞控制
连接对象个数支持一对一,一对多,多对一和多对多交互通信只能是一对一通信
传输方式面向报文面向字节流
首部开销首部开销小,仅8 字节首部最小20 字节,最大 60 字节
适用场景适用于实时应用(IP 电话、视频会议、直播等)游戏行业、物联网行业适用于要求可靠传输的应用,例如文件传输

1.TCP 和UDP格式对比

在这里插入图片描述
网络特点: 在网络中,我们认为传输是不可靠的,而在很多场景下我们需要的是可靠的数据,
所谓的可靠,指的是数据能够正常收到,且能够顺序收到,于是就有了 ARQ 协议,TCP 之所以可靠就是基于此。

UDP 使用场景
1.传输效率: 传输实时性比较高
2. 资源考虑 消耗资源比较少 (DNS)

UDP 没有粘包的情况,UDP 用户数据报文,在收取报文的时候一次性收取一个完整的用户数据报,否则如果收取部分报文,剩下的报文就丢弃了。

2.UDP分片原理

UDP分片原理

  1. 对应用层的数据进行分片,以满足MTU传输的要求
  2. 在发送端给分片编号,在接收端重组分片,解决乱序数据包重组的问题

3.UDP 传输层应该注意问题

1.数据包确认机制; 类比TCP的ack 机制;
2.数据包重发机制; tcp 也有重传机制
3.不发送大于路径 MTU的数据包
4.处理数据包重排 IP报文传输不一定按需到达

4.MTU

MTU:以太网(Ethernet) 数据帧的长度必须在46-1500字节之间,这是由以太网的物理特性决定的. 这个1500字节被称为链路层的MTU(最大传输单元)。

单个UDP传输的最大内容 1472(1500-20-8, 如果有可选字节>28)字节,但由于不同的网络中转设备设置的MTU值并不相同。Internet上的标准MTU值为576字节,建议在进行Internet的UDP编程时.最好将UDP的数据长度控制在548字节(576-20-8)以内(腾讯游戏 MTU 500+)。

推荐的MTU 设计为 500+字节,应用逻辑保证数据包大小不超过 MTU,避免拆包。
局域网:1400 公网:500+(腾讯游戏推荐), 音视频: 140

5.UDP 分片机制设计重点

在这里插入图片描述
在这里插入图片描述


一、ARQ协议

ARQ协议 (Automatic Repeat reQuest )),即 自动重传请求 ,是传输层的错误纠正协议之一,它通过使用确认和超时两个机制,在不可靠的网络上实现可靠的信息传输。

什么是滑动窗口

发送方和接收方都会维护一个数据帧的序列,这个序列被称作窗口。 发送方的窗口大小由接收方确定 ,目的在于控制发送速度,以免接收方的缓存不够大,而导致溢出,同时控制流量也可以避免网络拥塞。协议中规定,对于窗口内未经确认的分组需要重传。

模式

ARQ协议 主要有 3 种模式:
1.即停等式(stop and wait)ARQ
2.回退n 帧 (go back n)ARQ
3.选择性重传(selective repeat)ARQ

1.停等式(stop and wait)

停等协议的工作原理如下:

  1. 发送方对接收方发送数据包,然后等待接收方回复 ACK 并且开始计时。
  2. 在等待过程中,发送方停止发送新的数据包。
  3. 当数据包没有成功被接收方接收,接收方不会发送 ACK. 这样发送方在等待一 定时间后,重新发送数据包。
  4. 反复以上步骤直到收到从接收方发送的 ACK.

缺点:较长的等待时间导致低的数据传输速度
在这里插入图片描述

2.回退 n 帧 (go back n)ARQ 1

为了克服停等协议长时间等待ACK 的缺陷,连续 ARQ 协议会连续发送一组数据包,然后再等待这些数据包的 ACK.

回退N 步 (Go Back N,GBN) GBN): 回退 N 步协议允许发送方在等待超时的间歇 可以继续发送分组 。 所有发送的分组 都带有序号 。 在 GBN 协议中 发送方需响应以下三种事件:

  1. 上层的调用 。 上层调用相应 send() 时 发送方首先要检查发送窗口是否已满
  2. 接收 ACK 。 在该协议中 对序号为 n 的分组的确认采取累积确认的方式 表明接收方已正确接收到序号 n 以前 包括 n) 的所有分组 。
  3. 超时 。 若出现超时 发送方将重传所有已发出但还未被确认的分组

所有分组共用一个计时器

回退n帧详解

TCP 协议栈采用此种机制

对于接收方来说,若一个序号为n 的分组被正确接收,并且按序,则接收方会为该分组返回一个 ACK 给发送方,并将该分组中的数据交付给上层。在其他情况下,接收方都会丢弃分组。若分组 n 已接收并交付,那么所有序号比 n 小的分组也已完成了交付。因此 GBN 采用累积确认是一个很自然的选择。发送方在发完一个窗口里的所有分组后,会检查最大的有效确认,然后从最大有效确认的后一个分组开始重传。
在这里插入图片描述
如上图所示序号为 2 的分组丢失 因此 分组 2 及之后的分组都将被重传
总结:
GBN 采用的技术包括序号 、 累积确认 、 检验和以及计时 重传

缺点:
1.重传的数目比较多,重传率较高;
2.受到窗口大小影响,当窗口长度很大的时候 会使效率大大降低。

3. 选择重传 (Selective repeat)

虽然GBN 改善了停等协议中时间等待较长的缺陷 但它依旧存在着性能问题 。 特别是当窗口长度很大的时候 会使效率大大降低 。 而 SR 协议通过让发送方仅重传在接收方丢失或损坏了的分组 从而避免了不必要的重传 提高了效率 。

在SR 协议下 发送方需响应以下三种事件:
1、 从上层收到数据 。 当从上层收到数据后 发送方需检查下一个可用于该分组的序号 。 若序号在窗口中则将数据发送 。
2、 接收 ACK 。 若收到 ACK 且该分组在窗口内 则发送方将那个被确认的分组标记为已接收 。 若该分组序号等于基序号 则窗口序号向前移动到具有最小序号的未确认分组处 。 若窗口移动后并且有序号落在窗口内的未发送分组 则发送这些分组 。
3、 超时 。 若出现超时 发送方将重传已发出但还未确认的分组 。 与 GBN 不同的是SR 协议中的每个分组都有 独立的计时器

选择重传详解

在SR 协议下 接收方需响应以下三种事件:(假设接收窗口的基序号为 4 分组长度也为 4)
1、 序号在 4 7 内的分组被正确接收 。 该情况下 收到的分组落在接收方的窗口内 一个 ACK将发送给发送方 。 若该分组是以前没收到的分组 则被缓存 。 若该分组的序号等于基序号 4则该分组以及以前缓存的序号连续的分组都交付给上层 然后 接收窗口将向前移动 。
2、 序号在 0 3 内的分组被正确接收 。 在该情况下 必须产生一个 ACK 尽管该分组是接收方以前已确认过的分组 。 若接收方不确认该分组 发送方窗口将不能向前移动 。
3、 其他情况 。 忽略该分组对于接收方来说若一个分组正确接收而不管其是否按序 则接收方会为该分组返回一个 ACK给发送方 。 失序的分组将被缓存 直到所有丢失的分组都被收到 这时才可以将一批分组按序交付给上层 。
在这里插入图片描述

二、网络中如何做到可靠性传输

常用机制如下:

  1. ACK机制;
  2. 重传机制,重传策略(UDP 可以定制自己的重传策略);
  3. 序号机制;
  4. 重排机制;
  5. 窗口机制;

总结

提示:这里对文章进行总结:
UDP 基础理论总结: UDP的特性; UDP如何实现可靠性传输

在这里插入图片描述

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

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

技术鱼

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

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

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

打赏作者

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

抵扣说明:

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

余额充值