主页 / 问题 / 1590975
Accepted
gth-other
Asked:2024-08-16 23:41:36 +0000 UTC2024-08-16 23:41:36 +0000 UTC

复制 UDP 数据包以最大程度地减少数据包丢失的可能性是一个好习惯吗？

  • 772

例如，客户端向服务器发送单击的鼠标坐标。如果服务器因为数据包丢失而简单地忽略其操作，那么客户端显然不会喜欢它。我认为我可以通过将包裹编号添加到数据包的开头（随机的，因此，几乎在任何方面都是唯一的大数字）并一次发送多个具有相同编号的数据包来轻松解决这个问题。在这种情况下，当接收到数据包时，服务器将在某个哈希表中查找接收到的数据包的编号，如果不存在，则对其进行处理并将该编号标记为已处理。这样的解决方案有什么陷阱吗？他们在任何地方都这样做吗？

ip

1 个回答

  1. Best Answer

    您所描述的实际上是这样工作的протокол SIP，因为它通常位于 UDP 之上。我将使用他的例子来回答，因为我和他一起工作了很多，但这些原则也可以用于通过 UDP 运行的类似协议。

    由于 UDP 不保证数据包的传送（与 TCP 不同），SIP 本身提供传送机制。然而，通过UDP传输数据本身并不意味着应用层协议必须实现丢失保护机制。 SIP 是一种信令协议，通过它建立通信会话 -每个请求和响应在其中都很重要，因为如果不遵循完整的过程，就无法建立通信。您的情况与 SIP 的描述类似 - 您需要确保传递有关每次鼠标单击的信息。

    但在用于媒体传输的协议中RTP，没有对数据包传送的控制。对于实时语音（SIP 和 RTP 用于呼叫），牺牲一些丢失的数据包比尝试监控每个数据包更有意义。一个单独的 RTP 数据包通常携带大约 20-30 ms 的音频信息（取决于参数ptime）——在一次对话中数百人中丢失一两个数据包将不会被注意到。标准被认为是数据包丢失高达 5%，并且用户之间的传输延迟高达 150 毫秒 - 达到这些值时，语音感觉正常。例如，如果您需要实现屏幕流而无法与之交互，那么这种方法将适合您 - 这里的图片只需要不断更新，并且传递的帧不再具有价值。

    谈到确保传送的机制，实际上，SIP 设备通常会同时发送 2-3 个带有相同请求（例如 INVITE）的数据包。每个数据包都有一个标头CSeq（订阅者之间的会话中请求的序列号）和branch标头中的标签Via（事务标识符）。接收方看到相同的数据包几乎在同一时刻到达，并将它们视为一个请求，而不是将它们视为 3 个不同的请求。在这种情况下，如果任何请求未到达，则剩余的包裹将确保交付。

    另外，对于 INVITE 请求，SIP 本身实现了三次握手的过程（如 TCP 中）：

    INVITE（请求）-> 200 OK（响应）-> ACK（确认收到响应）

    如果 INVITE 在一定时间内没有收到响应（200 OK 或其他），设备将重新发送未送达的请求（在通信尝试超时到期之前）。

    • 2

相关问题