我有一个 Linux 设备，该设备应该通过 RTP/UDP 从各种实时音频源流式传输到多个客户端，并且希望实现尽可能低的延迟。它的工作方式是从各种 ALSA 接口(interface)检索帧，并使用通用 C 套接字将它们作为 RTP 流转发。
我已经使用 Wireshark 进行了一些测试，并且非常确定我正在 IP_TOS 字段中正确设置套接字的 DSCP 字段以进行快速转发，据我所知，这可以确保最大程度地减少这方面的延迟.
但是，我担心我没有采取任何措施将数据包标记为 VoIP，以在网络上的每个节点(使用 802.11e 标准)中实现最佳的 QoS，这可能会导致更少的-低于最佳延迟。最让我怀疑的是，根据我的 Wireshark 日志，我的数据包被标记为视频数据包，而不是音频/VoIP:
所以，这是我的问题:
DSCP 与 802.11e 有何关系？我的想法是，他们在网络的不同层中做不同的事情，但我对此了解不多，可能对此不以为然。
上图是否揭示了我用于在 DSCP 或 802.11e 前端发送 RTP 流的数据包和/或 UDP 套接字的任何非最佳设置？
<如何使用 C++ 上的标准套接字(如果可能)为数据包标记 VoIP 优先级？
关于路由器上的 802.11e，我应该注意什么特定配置吗？我应该寻找支持 802.11e 的路由器还是这已成定局？我假设 802.11e 可能与特定数据包无关，而是与路由器配置有关。
再一次，我有点迷失了，我想我可能需要有人敲打我的头并告诉我这一切是如何运作的。我在网上能找到的所有内容似乎都与 CISCO 相关，我不确定它对我的目的有多大用处，如此处所述。
最佳答案
- 我的理解是 QoS (ToS/DS) 八位字节是 IP header 的第二个八位字节。 802.11e 专门用于无线网络，位于比 IP 更低的层。
- 对于 DiffServ 中的加急转发，我认为八位字节应该是 0xb8。我不确定这张图片是什么...2 个八位字节？
- 我更熟悉 Windows，该操作系统对 QoS 标记有限制。对于那些找到这篇文章的人，请查看 qwave 和
QOSCreateHandle。在 Linux 上，我猜你可以使用具有适当权限的原始套接字。 - 路由器可以通过多种不同的方式转换 IP QoS 八位字节...选择一种适合您需要的方式； DSCP 应该很常见。再次注意，这与 802.11e 不同。
其他注意事项:所有这些实际上只对您的传输机器和本地网络重要。如果数据包离开您的网络，很可能所有 QoS 工作都会被忽略(例如，您的 ISP)。因此，除非您的本地网络出现拥塞，或者导出路由器出现拥塞，或者机器本身出现 I/O 问题，否则您的努力都是徒劳的。
关于Linux 上的 C++ : Setting up socket & packets for minimum RTP stream latency，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19117993/