sockets - Linux : checking of incoming UDP datagrams

Question

我正在使用连接在 10G 以太网链路上的专用硬件。我有一些关于处理传入数据报的问题，如下:

如果 NIC 发现不正确的链路级以太网 CRC 会怎样？一些搜索表明错误可能不会被可靠地报告(例如 here)。我能否期望从更新的内核(2.6 - 3.10？)

中获得更好的统计数据？

在决定是否将数据包返回到 recv 之前，内核实际上会检查什么？ ?我猜对于 IPv4，IPv4 header 校验和必须是正确的，但是可选的 UDP header 校验和呢？

可以recv曾经为 UDP/SOCK_DGRAM 返回 0 ?

对于非阻塞 SOCK_DGRAM socket ，做recv当数据可用时总是返回整个数据包？我想它必须这样做，但从文档中并不明显。

谢谢。

Answer 1

我的知识在这里可能已经过时了，但是从历史上看，带有 FCS 错误的数据包根本没有传递，并且不计入接口(interface)统计信息。以太网层错误计数通常由 ethtool -S <interface> 报告。 .问题一直是接口(interface)统计信息保持在驱动程序级别之上，并且内部没有标准的 API 供网络驱动程序报告这些统计信息。 (当然，在过去的 10Mb 半双工时代，冲突发生得非常频繁，以太网层的统计信息对于您自己的适配器的行为并不能提供非常丰富的信息。)

如果 IP header 校验和错误，或者在提供校验和时 UDP 校验和错误(即非零)，您不应该接收数据包。

是的。如果您提供零长度缓冲区，您将收到下一个传入的数据报，但整个内容将被截断，导致返回值为零。此外，UDP 允许长度为零的数据报:因此，如果您收到没有内容的数据报，则返回值也将为零。除了这两种情况，我不相信你会得到零的返回值。

是的，如果缓冲区中有空间，您应该获取整个数据报。否则，没有。如果您没有提供足够的空间来保存整个数据报，那么不适合的部分将被丢弃(即您的下一个 recv 将获得后续数据包，而不是截断的数据包的结尾)。