3

我试图了解在 Linux 上为我们的流式网络应用程序增加套接字缓冲区大小的正确方法。应用程序在多个 UDP 套接字上接收流向它的可变比特率数据。在流开始时数据量要大得多,我使用过:

# sar -n UDP 1 200

表明 UDP 堆栈正在丢弃数据包,并且

# ss -un -pa

表明每个套接字 Recv-Q 长度在sysctl net.core.rmem_default丢弃数据包之前增长到接近极限(124928. from )。这意味着应用程序根本无法跟上流的开始。在丢弃足够多的初始数据包后,数据速率会减慢,应用程序会赶上。Recv-Q 趋向于 0 并在此期间保持不变。

我可以通过大幅增加 rmem_default 值来解决数据包丢失问题,这会增加套接字缓冲区的大小,并让应用程序有时间从大的初始突发中恢复。我的理解是,这会更改系统上所有套接字的默认分配。我宁愿只增加特定 UDP 套接字的分配而不修改全局默认值。

我最初的策略是修改 rmem_max 并在每个单独的套接字上使用 setsockopt(SO_RCVBUF)。但是,这个问题让我担心禁用所有套接字的 Linux 自动调整,而不仅仅是 UDP。

udp(7)描述了 udp_mem 设置,但我很困惑这些值如何与 rmem_default 和 rmem_max 值交互。它使用的语言是“所有套接字”,所以我怀疑这些设置适用于完整的 UDP 堆栈,而不是单个 UDP 套接字。

udp_rmem_min 是我正在寻找的设置吗?它似乎适用于单个套接字,但适用于系统上的所有 UDP 套接字。

有没有办法在不修改任何全局设置的情况下安全地增加我的应用程序中使用的特定 UDP 端口的套接字缓冲区长度?

谢谢。

4

1 回答 1

0

吉姆·盖蒂斯全副武装,为你而来。不要去睡觉。

网络数据包泛滥的解决方案几乎从不增加缓冲。为什么你的协议的排队策略没有退缩?如果您试图在流中发送如此多的数据(这是 TCP 的设计目的),为什么不能只使用 TCP。

于 2012-04-30T03:18:42.050 回答