UDP 两种丢包处理策略：丢包重传（ARQ） 和 前向纠错（FEC）

最新推荐文章于 2025-08-23 16:00:00 发布
转载 最新推荐文章于 2025-08-23 16:00:00 发布 · 2.9k 阅读 · 9 ·
CC 4.0 BY-SA版权
原文链接：http://www.cnblogs.com/sxiszero/p/11532554.html
文章标签：

#网络 #游戏 #java

本文探讨了UDP协议下处理丢包的两种策略：前向纠错（FEC）和丢包重传（ARQ）。FEC通过发送冗余数据实现单向传输下的丢包恢复，适合低丢包率场景；ARQ则依赖接收方反馈请求重传，适合对实时性要求较高的应用，但可能导致网络拥塞。

目录

1. 两种丢包处理策略

为了保证实时性，通常适应UDP协议来针对RTP数据进行传输，而UDP无法保证数据传输的质量，所以在网络环境不好的时候，丢包是经常出现的问题，有什么策略来改善这个问题吗?
常用的方法有: 丢包重传（ARQ）和前向纠错（FEC）。

611089-20190917111913654-1086368371.png

通常抗丢包有两种方式，FEC和ARQ。FEC是前向冗余，举个例子，发送数据A和B，增加发送一个数据C等于A和B的异或。接收方接到这3个包的任意2个包，异或一下就可以得到第3个包。当然，实际的FEC没这么简单，通常会有比较复杂的矩阵运算。ARQ就是接收

最低0.47元/天 解锁文章
bill_live
关注
C#UDP通讯组件,支持拆包组包,丢包重发
Dice的学习笔记
12-25 4432
自己仿照某商业组件开发的通讯模块,简单的调用便可实现传文件,即时通讯等内容. 如图,只需要绑定ip便可以通讯 组件下载地址:点击打开链接 调用的方法: class Program { public static DataDispatcher dd; static void Main(string[] args)
会议投屏直播：UDP通讯方案的探索（四. FEC分片数据生成及向前纠错处理）
08-28 637
文章目录XOR-FEC分片分组XOR-FEC分片还原 与TCP数据传输机制不同，采用UDP向目标地址发送报文时。从理论上说，数据的接收顺序有可能是乱序的，更令人头痛的是UDP其发出后不管的特性使到数据是否已经到达无法感知，而丢包问题又经常发生，所以采用UDP进行数据传输时，基本上一直围绕着丢包处理这件事展开。 那么当丢包事情发生的时个，一般的处理办法如下： NACK机制 当接收端发现数据包丢失...
TCP传输问题深度剖析：乱序、丢包、重传机制与优化
最新发布
苦哈哈的 C++ 程序员，写这个技术博客不是为了装逼，也不是为了立人设，是为了收割流量
08-23 950
问题检测方法解决机制优化技术丢包RTO超时/重复ACK重传快速重传、SACK乱序序列号检查缓存重组乱序容忍、RACK拥塞丢包/延迟增加降低发送速率BBR、CUBIC重复序列号检查丢弃去重缓存超时定时器指数退避精确RTO计算。
使用FEC改善UDP（RTP）音视频传输效果
mediapro的博客
12-24 2万+
实时音视频领域UDP才是王道               在 Internet 上进行音视频实时互动采用的传输层方案有TCP（如：RTMP）和UDP（如：RTP）两种。TCP协议能为两个端点间的数据传输提供相对可靠的保障，这种保障是通过一个握手机制实现的。当数据传给接收者时，接收者要检查数据的正确性。发送者只有接到接收者的正确性认可才能发送下一个数据块。如果没有接到确认报文，这个数据块就得重传。
UDP丢包重传
游戏码农的专栏
12-16 6900
    最近写了两UDP服务器之间的文件传输,遇到一个问题就是丢包严重,心想搞个丢包处理机制,但又不想搞得太麻烦或者像TCP那种算法,后来才想到用定时器来做,简单的说就是把传包的时间记住,收到包后就把这个时间清0,然后定时去查这个时间,如果这个时间大于某个值,就说明服务器没有收到包,这样就需要重传,你可以用一个全局的变量记住它,当然还要记住文件的偏移和大小什么的,以便与重传时把这些消息传过去,还要
UDP视频传输中的丢包和播放花屏处理方法
深之JohnChen的专栏
03-27 1452
优先选择支持抗丢包特性的编码器（如H.265的NAL单元分片、AV1的帧内刷新）。动态调整码率（如WebRTC的GCC算法），根据网络状况降低分辨率或帧率。：FEC（10%冗余） + 短GOP（30帧） + 接收端错误隐藏。：在发送数据时附加冗余包，接收方通过冗余信息恢复丢失的数据包。：减少关键帧（I帧）间隔，避免因丢失关键帧导致后续帧无法解码。使用Wireshark分析丢包模式（突发丢包或持续丢包）。设置合理的冗余比例（如每5个数据包附加1个冗余包）。：对延迟不敏感的场景（如直播时延允许1~2秒）。
也就是说RTP协议底层如果采用UDP协议, 任然会存在丢包问题, 需要在应用层处理FEC和重传等逻辑对吗
05-11
FEC（前向纠错）和重传是常见的解决方案。FEC通过添加冗余数据来恢复丢失的包，而重传则需要请求发送方重新发送丢失的数据包，但可能增加延迟。 然后，用户的问题是关于是否需要应用层处理。答案是肯定的，因为RTP...
NACK机制在音视频直播丢包重传中的应用与优化
程序猿老樊的博客
06-21 754
NACK机制作为实时音视频传输中丢包恢复的核心技术，在保障媒体质量方面发挥着不可替代的作用。通过深入理解其工作原理、精心设计实现细节并结合具体应用场景进行优化，可以显著提升直播系统的抗丢包能力和用户体验。
Wi-Fi信号波动下ESP32 UDP丢包实测报告：7种补偿机制效果对比与推荐
本章将从物理层信号衰减与MAC层重传机制耦合关系入手，深入剖析信号波动如何通过降低物理层调制效率（如从64-QAM降为QPSK）和触发底层帧重传来间接加剧UDP报文乱序与丢失，建立“信号质量→链路层稳定性→传
UDP丢包和无序 问题的解决方法
weixin_30911451的博客
07-17 1768
最近在做一个项目,在这之前,做了个验证程序.发现客户端连续发来1000个1024字节的包,服务器端出现了丢包现象.纠其原因,是服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了.我用过sleep(10),暂时解决这个问题,但是这不是根本解决办法,如果数据量大而多,网络情况不太好的话,还是有可能丢失. 你试着用阻塞模式吧...select...我开始的时候好像也遇到过..不过改为阻...
udpfec:用于易错连接的前向纠错隧道 TCP over UDP 的实现
07-12
UDPFEC 用于易错连接的前向纠错隧道 TCP over UDP 的实现
udp丢包率统计
07-17
udp丢包率统计
UDP丢包检测工具
01-04
这是一款测试网络的丢包的软件，该软件具有收发软件测试包的功能。
【Socket】解决UDP丢包问题
Ctrl + C / Ctrl + V 人生
06-07 3200
UDP是一种不可靠的、无连接的、基于数据报的传输层协议。相比于TCP就比较简单，像写信一样，直接打包丢过去，就不用管了，而不用TCP这样的反复确认。所以UDP的优势就是速度快，开销小。
TCP可靠传输：ARQ协议（停止等待、超时重传、滑动窗口、回退N帧、选择重传）
热门推荐
阿花的博客
08-29 4万+
ARQ协议，即自动重传请求（Automatic Repeat-reQuest），是OSI模型中的错误纠正协议之一，它通过使用确认和重传这两个机制，在不可靠服务的基础上实现可靠的信息传输。
mediasoup丢包重传机制的实现
椛茶的博客
12-21 2778
在音视频通话中，我们常常使用 RTP 协议包荷载音视频数据，底层经常使用 UDP 作为其传输层协议，而 UDP 并不保证数据可靠性，因此当 RTP 产生丢包时，接收端需要告知源端哪些序号的包认为丢失了，请重传一遍过来。
UDP如何实现可靠传输
yiyiyuebing的博客
11-27 724
概述 UDP不属于连接协议，具有资源消耗少，处理速度快的优点，所以通常音频，视频和普通数据在传送时，使用UDP较多，因为即使丢失少量的包，也不会对接受结果产生较大的影响。 传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。 最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。 1、添加seq/ack机制，确保数据发送到对端 2、添加发送和接收缓冲区，主要是用户超时重传。 3、添加超
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值