【问题标题】:How safe is UDP?UDP有多安全?
【发布时间】:2015-11-20 04:47:39
【问题描述】:

我正在考虑是否使用 TCP 或 UDP 进行我正在处理的一些非常简单的通信。以下是基本细节:

  • 所有消息都放在一个 1500 字节的数据包中(因此排序无关紧要)
  • 这些消息的接收者将被来自多个不同来源的数据包轰炸。 TCP 会处理拥塞,但是从数十或数百个来源同时到达同一端口的 UDP 数据包会相互破坏吗?
  • 丢失/损坏的消息不是什么大问题。只要它们仍然是少数,并且被正确识别为无效,它们就可以被忽略
  • 数据包以波的形式到达,几秒钟内每秒几个,然后在几分之一秒内到达数万个。网络应该能够处理这些峰值中的带宽

您是否认为为此使用 UDP 有任何问题,请记住排序无关紧要,丢失/损坏的数据包可以安全地忽略,并且这些数据包峰值可能会同时到达数以万计的数据包?

【问题讨论】:

  • 我不是专家,但听起来您需要使用 UDP。 UDP 具有较少的开销(意味着较小的包大小)非常适合快速交付;可能会发生包裹丢失,但听起来不会有问题。

标签: sockets networking tcp udp


【解决方案1】:

所有消息都放在一个 1500 字节的数据包中(因此排序无关紧要)

1500 是本地网络中通常使用的 MTU。它在 Internet 上可能更低,并且 DNS 等协议假定至少 512 字节可以工作。但即使 MTU 较低,数据包也只会在最后被分片和重组,因此没有一半的消息到达应用程序。

.. 但是从数十或数百个来源同时到达同一端口的 UDP 数据包会相互破坏吗?

他们不会互相腐蚀。如果它们到达得太快,而您的应用程序无法及时从套接字缓冲区中读取它们以致套接字缓冲区被填满,那么数据包就会丢失。

丢失/损坏的消息不是什么大问题。只要它们仍然是少数,并且被正确识别为无效,它们就可以被忽略

大多数情况下都会使用 UDP 的可选校验和。如果校验和不适合数据包将被丢弃,即未交付给应用程序。校验和确实考虑了简单的位翻转,但无法检测到每一个损坏。但这对于所有校验和以及 TCP 都是一样的。

数据包以波的形式到达,几秒钟内每秒几个,然后在几分之一秒内到达数万个。网络应该能够处理这些峰值中的带宽

如果网络中的带宽可以处理它,那么网络就可以处理它。但问题是您的本地机器,尤其是您的应用程序是否能够应对这种波,即处理数据包的速度快到网卡缓冲区和套接字缓冲区不会溢出。您可能应该增加接收缓冲区大小以更好地处理此类波。

【讨论】:

    【解决方案2】:

    所有消息都放在一个 1500 字节的数据包中(因此排序无关紧要)

    不合理。普遍接受的 UDP 数据报有效负载限制为 534 字节,所有消息都适合一个数据报这一事实并不意味着顺序无关紧要,除非 em> messages 的顺序无关紧要,你没有说明。

    从数十或数百个来源同时到达同一端口的 UDP 数据包会相互破坏吗?

    没有。

    丢失/损坏的消息不是什么大问题。只要它们仍然是少数,并且它们被正确识别为无效,它们就可以被忽略。

    如果您不禁用 UDP 校验和检查,它们将被丢弃,而不是被忽略。

    数据包以波的形式到达,几秒钟内每秒几个,然后在几分之一秒内到达数万个。网络应该能够处理这些峰值中的带宽。

    不会的。 UDP 数据包可以随时丢弃,尤其是在这样的情况下。但正如您已经说过的,错过消息不是什么大问题,也不是什么大问题。

    您是否认为为此使用 UDP 有任何问题,请记住排序无关紧要,丢失/损坏的数据包可以安全地忽略,并且这些数据包峰值可能会同时到达数以万计的数据包?

    假设它们是正确的,则不在您所说的条件下。

    【讨论】:

    • 消息的顺序无关紧要,任何一条消息都适合一个 1500 字节的数据包。接受的有效负载说明了可以填充到 UDP 中的所有额外标头,而我几乎不打算使用这些标头。否则消息有效负载小于 1472 字节。此外,丢弃和忽略之间似乎没有实际区别,除了校验和检查和丢弃允许硬件和操作系统优化,而将校验和计算移动到应用程序层并忽略会导致轻微的性能损失。同样重要的是,丢弃的数据包必须是极少数。
    • 标头不是有效负载的一部分。 “极少数”在术语上是矛盾的,而“必须是”似乎与“没什么大不了的”相矛盾。无论出于何种原因,UDP 都会丢弃数据包,包括但不限于路由器队列溢出、接收缓冲区溢出……
    • 很公平。我的意思是,只要约 80%+ 能够通过,丢弃的数据包就不是问题,并且丢弃的数据包的分布是相对随机的,即不是每次都丢弃数据包的相同节点。显然标头不是有效负载的一部分,但我的意思是更多的标头意味着更小的可能有效负载。很抱歉造成混乱。
    猜你喜欢
    • 2013-03-18
    • 2015-05-20
    • 1970-01-01
    • 2011-05-06
    • 2016-09-16
    • 2016-03-26
    • 1970-01-01
    • 2011-06-11
    • 1970-01-01
    相关资源
    最近更新 更多