Linux上的C ++：设置socket＆amp;数据包的最小RTP流延迟

Question

我有一个Linux设备应该通过RTP / UDP从各种实时音频源流向多个客户端，并希望实现尽可能低的延迟。它的工作方式是从各种ALSA接口检索帧，并使用通用C套接字将它们转发为RTP流。

我已经使用Wireshark进行了一些测试，我很确定我正在IP_TOS字段中正确设置套接字的DSCP字段以便正确加速转发，据我所知，这可以确保最大程度地减少前面的延迟

但是，我担心我没有做任何事情将数据包标记为VoIP，以便在网络上的每个节点（使用802.11e标准）中实施最佳可能的QoS，这可能导致更少 - 比最佳延迟。让我最大可疑的是，根据我的Wireshark日志，我的数据包被标记为视频数据包而不是音频/ VoIP：

所以，这是我的问题：

1. DSCP如何与802.11e相关？我在想的是，他们在网络的不同层面做不同的事情，但我不是那么知识渊博，可能不在此。

2. 上面的图片是否显示了有关数据包和/或我用于在DSCP或802.11e前端发送RTP流的UDP套接字的任何非最佳设置的任何内容？

3. 如何使用C ++上的标准套接字标记数据包的VoIP优先级（如果可能）？

4. 关于路由器上的802.11e，我应该注意哪些特殊配置？我应该寻找支持802.11e的路由器还是已成定局？我假设802.11e不是关于特定数据包而是关于路由器配置。

再一次，我有点失落，我想我可能需要有人来打击我的头脑并告诉我这一切是如何运作的。我在网上找到的所有内容似乎与CISCO有关，我不确定它对我的目的有多大用处，如此处所述。

Answer 1

1. 我的理解是QoS（ToS / DS）八位字节是IP头的第二个八位字节。 802.11e专门用于无线网络，并且位于比IP更低的层。
2. 对于DiffServ中的加速转发，我认为八位字节应该是0xb8。我不确定这张照片是什么...... 2个八位字节？
3. 我对Windows更熟悉，操作系统限制了QoS标记。对于那些发现这篇文章的人，请查看qwave和QOSCreateHandle。在Linux上，我猜你可以使用具有适当权限的原始套接字。
4. 路由器可以通过几种不同的方式来转换IP QoS八位字节...选择一个满足您需求的方法; DSCP应该是常见的。请再次注意，这与802.11e不同。

其他说明：所有这一切只对您的传输机和本地网络有用。如果数据包离开您的网络，则很可能会忽略所有QoS工作（例如，您的ISP）。因此，除非您的本地网络拥塞，或出口路由器拥塞，或者机器本身出现I / O问题，否则您的努力都是徒劳的。

Answer 2

我认为您没有设置正确的值。

在Linux（相对于Windows）中，您可以直接在套接字上设置DSCP值：

const int IPTOS_EXPEDITED_FORWARDING = 0xb8;
const int serviceType = IPTOS_EXPEDITED_FORWARDING;      
setsockopt(sock, IPPROTO_IP, IP_TOS, (const char*)&serviceType, sizeof(serviceType));

然后您可以在Wireshark的IP级别对其进行检查：

尽管正如mark所指出的那样，但由于它经常被忽略或剥离，因此可能并不十分有用。

更糟的是，正如我在追踪某些神秘行为时所发现的那样，它会使事情变得更糟。我的网络路径中的某个奇怪的路由器丢弃了EF数据包的5-10％，而DSCP值为空的数据包就可以了。

添加了此回复以供参考，因为即使很多年前Google仍然提出此问题，它仍然可以找到它。