有损通道上的可靠数据传输
假设您在 2 个对等点之间已经有一个不可靠的有损通道。您建议采用哪些方法来可靠地传输数据并且不会造成性能损失？而且底层协议不是 TCP（它已经是可靠的）。 （我使用有损通道来概括这个问题。）
（据我所知，存在一些方法，例如 RDT (rfc-908)、Go Back-N。）
Suppose you have already an unreliable lossy channel between 2 peers. Which methods can you suggest to transfer data reliably and also without performance loss? Also the underlying protocol is not TCP (which is already reliable). (I used lossy channel to generalize the question.)
( AFAIK, some methods exist like RDT (rfc-908), Go Back-N. )
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Reliable_transmission
因为有人已经解决了有一个或十个库（TCP/IP）可以用现有的每种语言来解决这个问题。
这是一个哲学问题吗？
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Reliable_transmission
Because someone already solved the problem and there is a library (TCP/IP) or ten that does it in every language that exists.
Is this a philosophy question?
没有性能损失通常意味着减少对从接收方向发送方发送 ACK 的反向信道的依赖。这通常意味着使用数据报和某种形式的前向纠错 (FEC) 的自定义协议。请注意，FEC 是一种滑动比例，通常会造成严重的性能损失，因为根据定义，您会抢先发送额外的冗余数据，以便接收器不必请求它。
http://en.wikipedia.org/wiki/Forward_error_ Correction
http://udt.sourceforge.net/
Without performance loss typically means reducing dependency on the back channel, from the receiver sending ACKs to the sender. This usually means a custom protocol using datagrams and using some form of forward-error-correction (FEC). Note that FEC is a sliding scale that can often be a significant performance penalty because, by definition, you are preemptively sending additional redundant data so that the receiver does not have to ask for it.
http://en.wikipedia.org/wiki/Forward_error_correction
http://udt.sourceforge.net/
正如 Steve-o 所说，FEC 和 Kdansky 建议的重传都是很好的起点。重传的主要瓶颈是往返时间，这会导致接收丢失数据包的延迟。然而，FEC 是一个完全不同的主题，适用于数据包级别。正如 Steve-o 再次所说，瓶颈变成了由于生成冗余流而导致的带宽开销。虽然看起来很简单，但不同的 FEC 方案（例如 Parity FEC、Reed-Solomon、Turbo 码、Raptor Q 等）根据其参数对延迟、带宽开销等有不同的影响。 （主要取决于用于生成冗余流的编码率）
As Steve-o said, FEC and as Kdansky suggested Retransmission, are good starting points. The main bottleneck of Retransmission is round-trip times, which causes the delay in receiving a lost packet. However, FEC is a whole different subject and applicable on the packet level. As Steve-o said again, the bottleneck becomes the bandwidth overhead you cause by generating a redundant stream. Although it seems so straightforward, different FEC schemes such as, Parity FEC, Reed-Solomon, Turbo codes, Raptor Q, etc... have different effects on the delay, bandwidth overhead, etc. according to their parameters. (Mostly on the encoding rate that you use to generate the redundant stream)