是否可以保证在 Node.js 上使用 UDP 传递消息? [英] Is it possible to guarantee delivery of messages using UDP on Node.js?

问题描述

如何保证在 Node.js 上使用 UDP 传递消息?例如，如果数据包失败，我可以重新发送数据包 - 但是有没有办法识别失败的时间?另外，丢包的情况有多普遍?

How is it possible to guarantee delivery of messages using UDP on Node.js? For example, I could just resend the packet if it failed - but is there a way to identify when it failed? Also, how common is the loss of a packet?

推荐答案

如果您真正想知道的是我如何检测丢失的数据包"?然后一般的技术是让接收器为每个发送的数据包发送一个确认.如果发送器没有收到确认，则它必须重新发送数据包.如果接收方收到重复的数据包，那么它应该丢弃重复的数据包.

If what you're really wondering is "how do I detect lost packets"? Then the general technique is to have the receiver send an acknowledgement for each packet sent. If the transmitter does not receive an acknowledgement then it must resend the packet. If the receiver gets duplicate packets then it should discard the duplicate.

基本方案是这样的:

TX                               RX
 ╷           data
 ╰──────────────────────────────▶

              ack               ╷
 ◄──────────────────────────────╯

 ╷           data
 ╰────────────────────── - - -         loss of data packet
               .
               .
               . timeout
               .
 ╷       data retransmit
 ╰──────────────────────────────▶

              ack               ╷
 ◄──────────────────────────────╯

 ╷           data
 ╰──────────────────────────────▶

              ack               ╷
      - - - ────────────────────╯      loss of ack packet
               .
               . timeout
               .

 ╷       data retransmit
 ╰──────────────────────────────▶

              ack               ╷
 ◄──────────────────────────────╯

这本质上是所有形式的丢包检测的基础.可以实施多种改进来改进该技术，但基本原理大致相同:如果接收方没有告诉您数据包已到达，则数据包丢失.

This is essentially the basis of all forms of packet loss detection. There are several refinements that can be implemented to improve the technique but the basics is generally the same: if the receiver does not tell you that the packet has arrived then the packet is lost.

通常对算法进行的第一个改进之一是检查 ack 是否确实是适当的 ack，而不仅仅是路由器发送的某些回声、信号交叉干扰或软件错误.解决方案是实现一个切换位.数据包在切换位设置为一个值的情况下传输，ack 包需要以适当的值(通常是相同的值)进行回复.如果切换位错误，则表示 ack 数据包与最后一个数据包不匹配，这意味着它与前一个数据包匹配.这意味着最后一个数据包还没有被确认，这意味着出现了严重的错误，应该重新发送数据包，直到收到正确的确认.

One of the first improvement generally done to the algorithm is to check that the ack is really the appropriate ack and not just some echo sent by the router or by signal cross inteference or by a software bug. The solution is to implement a toggle bit. The data packet is transmitted with the toggle bit set to a value and the ack packet needs to reply with the appropriate value (usually the same value). If the toggle bit is wrong then it means that the ack packet doesn't match the last data packet which implies that it matches the previous data packet. This implies that the last data packet hasn't been acknowledged which means that something has seriously gone wrong and the packet should be retransmitted until the correct ack is received.

TX                               RX
 ╷           data[0]
 ╰──────────────────────────────▶

              ack[0]            ╷
 ◄──────────────────────────────╯

 ╷           data[1]
 ╰──────────────────────────────▶

              ack[0]            ╷
 ◄──────────────────────────────╯     ack mismatch!

 ╷       data[1] retransmit
 ╰──────────────────────────────▶

一些现实世界的协议使用这种技术，包括用于控制工业设备和机器人的大多数协议.

Several real world protocols use this technique including most protocols used to control industrial equipment and robots.

下一步实际上是对上述想法的扩展.为什么不发送一个数字，而不是发送一点.这样，您可以更明确地将 ack 与数据包匹配，从而更准确地检测哪个数据包丢失并需要重新传输.这种技术通常被称为滑动窗口技术，因为在某些时候数字会滚动并滑回到零.因此，在无法检测到数据包丢失之前，您可以传输的最大数据包数是滑动窗口大小.

The next step is actually an expansion of the above idea. Instead of sending just a bit why not send a number. That way you can more definitely match the ack to the data packet and so more accurately detect which packet was lost and needs retransmission. This technique is often referred to as the sliding window technique because at some point the number rolls over and slides back to zero. And so the maximum number of packets you can transmit before you're unable to detect packet loss is the sliding window size.

滑动窗口技术的一大优点是您可以发送大量数据包而无需等待 ack.这显着提高了吞吐量:

The big advantage of the sliding window technique is that you can send lots of data packets without waiting for the ack. This significantly improves throughput:

TX                             RX
 ╷           data[1]
 ╰──────────────────────────────▶
 ╷           data[2]
 ╰──────────────────────────────▶
 ╷           data[3]
 ╰──────────────────────────────▶


              ack[1]            ╷
 ◄──────────────────────────────╯
              ack[2]            ╷
 ◄──────────────────────────────╯

 ╷           data[4]
 ╰──────────────────────────────▶
 ╷           data[5]
 ╰──────────────────────────────▶

              ack[3]            ╷
 ◄──────────────────────────────╯
              ack[5]            ╷
 ◄──────────────────────────────╯     ack[4] missing!
               .
               . timeout
               .

 ╷       data[4] retransmit
 ╰──────────────────────────────▶

以上是检测丢包的基本技术的简短总结.如果您希望所有 UDP 数据包都到达目的地，这就是您需要实现的.

So the above is a short summary of the basic technique for detecting packet loss. That's what you need to implement if you want all your UDP packets to arrive at their destination.

您应该知道 TCP 已经实现了这一点，因此如果您不想重新发明轮子，您应该真正使用 TCP.创建 UDP 是因为在某些情况下丢包是正常的(想想音频/视频流).

You should know though that TCP already implements this so you should really use TCP if you don't want to reinvent the wheel. UDP was created because in some cases packet loss is OK (think audio/video streaming).

这篇关于是否可以保证在 Node.js 上使用 UDP 传递消息?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！