什么时候对数据包来说前向纠错是个好主意？
系统可以使用 UDP 并采用前向纠错来传输整个消息，而无需重传，即使丢失了一些数据包。 这在实践中是否有效，或者额外的开销是否太浪费了？
Systems could use UDP and employ forward error correction to transmit the whole message, without retransmits, even if a few packets are lost. Does this ever work well in practice or is the extra overhead too much of a waste?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这对于硬盘和光盘等存储介质也很有意义，因为您不能只是返回源来获取未损坏的数据。 事实上，硬盘驱动器和光盘都相当广泛地使用前向纠错。
前向纠错也广泛用于无线通信，其中错误往往一次只会消除几个比特。 前向纠错用于修复损坏的位，而不是因单个位错误而丢失整个数据包。
It also makes sense for storage medium, such as hard drives and optical disks, where you can't just go back to the source to get the uncorrupted data. In fact, both hard drives and optical disks use forward error correction quite extensively.
Forward error correction is also used extensively in wireless communications, where errors tend to knock out just a few bits at a time. Rather than lose the whole packet to a single bit error, forward error correction is used to fix the corrupted bits.
取决于应用程序。
对于游戏等应用程序，错误纠正始终是必要的，因为即使丢失一点数据也不会产生太大影响。
但是，如果应用程序需要特定的有序数据，则需要某种错误纠正。
这不是“开销”的问题，更多的是“应用”的问题。
Depends on the application.
For applications such as games, error corrections are always necessary as it wont make a big difference if you lose a bit of data.
However, if the application requires specific, in-order data, then some sort of error correction is necessary.
It's not a question of "overhead", it's more about "application".
简单的答案是，如果您通过高带宽高延迟（意思是“长距离”）链路发送，则前向纠错是有意义的。 否则，可能不会。
The simple answer is if you're sending over a high-bandwidth high-delay (meaning "long distance") link, forward error correction makes sense. Otherwise, it probably doesn't.
当重传的“价格”高于您愿意支付的价格时。
例如，卫星的传播时间很长，最好多发送几个字节，然后再次发送数据包。
When the "price" of retransmission is higher than what you are willing to pay.
Satellite for instance has a very long propagation time, it is better to send a few more bytes then to send a packet again.
我认为它对于诸如语音 (VoIP) 之类的某些应用程序很有用，在这些应用程序中您希望避免错误，并且您永远不想停止（重新传输 NAKed 数据包）并等待（直到重新传输）。
因此，它可能是在 UDP 的实时传输协议风格之上实现的。
您是想问前向纠错是否会增加端到端延迟？ 如果是这样，我认为答案是“否”，但它确实增加了所需的带宽。
我相信您总是需要一些延迟，以避免抖动； 例如，您可能会说“让我们将整个语音通道延迟 200 毫秒，这样任何/每个数据包都需要 0 到 200 毫秒才能穿过互联网，并通过位于另一端。”
给定这些数字，那么没有前向纠错可能意味着，在每 200 毫秒的周期内，您发送 10 个数据包，每个数据包包含 20 毫秒的数据……如果一个数据包丢失，那么另一个数据包就会出现间隙（故障）结尾。
然而，进行一些前向纠错可能意味着，在每 200 毫秒的周期内，您仍然发送 10 个数据包...每个数据包包含 20 毫秒的数据，加上已经在另一个数据包中传输的 10 毫秒的数据（或者，也许您发送 30 个数据包而不是 20 个）。 然后，如果任何单个数据包丢失，则其携带的数据将被冗余传送（其他两个数据包各占一半），这避免了解码输出中的任何故障。
I think it's useful for some applications like Voice (VoIP), where you want to avoid errors, and where you never want stop (to retransmit a NAKed packet) and wait (until it's retransmitted).
So it might be implemented on top of the Real-time Transport Protocol flavour of UDP.
Are you asking whether forward error correction increases end-to-end delay? If so, I think the answer is "no", but it does increase the needed bandwidth.
I believe you always already need some latency, to avoid jitter; so for example, you might say "let's delay the whole voice channel by 200 msec, so any/every packet can take from 0 to 200 msec to cross the internet, and be reassembled and sent through the D-to-A converter at the other end."
Given those numbers, then having no forward error correction might mean that, in each 200 msec period, you send 10 packets each containing 20 msec of data ... and if one is lost, then that's a gap (a glitch) at the other end.
Whereas, having some forward error correction might mean that, in each 200 msec period, you still send 10 packets ... each packet contains 20 msec of data, plus 10 msec of data that's already been transmitted in another packet (or, maybe you send 30 packets instead of 20). Then, if any single packet is lost, the data which it carried was delivered redundently (half in each of two other packets), which avoids any glitch in the decoded output.