UDP是一个比TCP简单得多的协议。 由于UDP不包含会话可靠性，因此应用程序有责任识别和重新传输丢弃的数据包。 没有窗口大小的概念，并且协议不恢复丢失的数据。 唯一可用的调谐包括增加接收缓冲区大小。 但是，如果netstat -us报告错误，另一个潜在的问题可能会阻止应用程序排空其接收队列。 如果netstat -us显示“数据包接收错误”，请尝试增加接收缓冲区并重新测试。 该统计量还可以由于其他原因而递增，诸如有效载荷数据小于UDP报头建议的短分组或者其校验和计算失败的损坏分组，因此如果缓冲区调谐不需要，则可能需要更深入的调查 解决UDP接收错误。 UDP缓冲区可以以类似于最大TCP缓冲区的方式调整：
# sysctl net.core.rmem_max
124928
# sysctl -w net.core.rmem_max=16777216
更改最大大小后，需要重新启动应用程序以使新设置生效。
RSS: Receive Side Scaling
RSS由许多常见的网络接口卡支持。 在接收数据时，NIC可以将数据发送到多个队列。 每个队列可以由不同的CPU服务，允许有效的数据检索。 RSS充当驱动程序和卡固件之间的API，以确定数据包如何跨CPU核心分布，其想法是将流量引导到不同CPU的多个队列允许更快的吞吐量和更低的延迟。 RSS控制哪些接收队列获得任何给定的分组，无论卡是否侦听特定的单播以太网地址，它侦听的多播地址，哪个队列对或以太网队列获得多播分组的副本等。
RSS Considerations
驱动程序是否允许配置队列数量
某些驱动程序将根据硬件资源自动生成引导期间的队列数。 对于其他，它可以通过ethtool -L进行配置。
•系统有多少个内核应配置RSS，以便每个队列转到不同的CPU内核。
RPS: Receive Packet Steering
接收数据包转向是RSS的内核级软件实现。 它驻留在驱动程序上方的网络堆栈的较高层。 RSS或RPS应该是互斥的。 默认情况下禁用RPS。 RPS使用保存在数据包定义的rxhash字段中的2元组或4元组哈希，用于确定应该处理给定数据包的CPU队列。
RFS: Receive Flow Steering
接收流转向在引导分组时考虑应用局部性。 这避免了当流量到达运行应用程序的不同CPU核心时的高速缓存未命中。
