LWN：更好地理解为何会丢弃网络包！

关注了就能看到更多这么棒的文章哦～

Better visibility into packet-dropping decisions

By Jonathan Corbet
February 25, 2022
DeepL assisted translation
https://lwn.net/Articles/885729/

丢弃数据包在网络中是无法完全避免的一个情况。数据包无法到达最终目的地的原因可能有很多种。其实有很多方法可以让数据包消亡，以至于管理员都很难知道为什么某个数据包会被丢弃。因此，在用户抱怨丢包率高的时候，这么多种可能也导致很难确定如何解决用户的问题。从 5.17 版本开始，内核得到了一些改进过的工具，应该可以告诉人们为什么内核会决定要将数据包抛弃掉。

这个问题存在很久了，因此也一直有尝试方案希望能解决它。内核目前包含一个 "drop_monitor" 功能，该功能早在 2009 年的 2.6.30 内核中引入。多年来，它已经具备了一些功能，但是仍然是彻底没有文档说明的状态。这个功能似乎支持一个 netlink API，可以在数据包被丢弃时提供通知。这些通知中包括了在内核里的一个地址数据，标记了是哪个地方决定丢弃数据包的，并且可以选择也包含所放弃的数据包本身。用户空间的代码就可以将这些地址转化为函数名，然后正在无助中的管理员就可以通过内核的源代码来试图弄清楚发生了什么事。

看起来应该有什么更好的方法。碰巧的是，Menglong Dong 为 5.17 版贡献了一些可以有助于提供更好方法的基础结构。内核内部用来释放数据包存放内存的函数是 kfree_skb()，在 5.17 中，这个函数变成了：

void kfree_skb_reason(struct sk_buff *skb, enum skb_drop_reason reason);

reason 参数是新增的，用来说明为什么这个 skb 所传递的数据包已经不再需要了。这个信息实际上对内核没有什么用处，但是它已经被添加到现有的 kfree_skb tracepoint 中，使得所有连接到该 tracepoint 的程序都可以拿到这个数据。用来分析的脚本就可以快速打印出数据包被丢弃的原因，管理员还可以比如说挂上 BPF 程序，来创建出一个根据丢弃数据包原因绘制的直方图。

他还增加了一个新版本的 kfree_skb()，会简单地调用 kfree_skb_reason()，将 "unspecified" 作为原因。

在 5.17 中，这个基础设施的使用还是相对比较局限的。有几处 TCP 处理中丢包的位置已经换上用新的函数了，包括因为数据包小于 TCP 头的大小、没有与现有的 TCP socket 相关联、校验失败、或者被相应的 socket 过滤程序明确要求丢弃等情况。UDP 子系统也改进成可以支持类似的丢包原因 。

这种情况在 5.18 中会有很大的改善。linux-next 中的 patch 已经增加了一些新的 reason，记录了被 netfilter 子系统丢弃的数据包，包括 IP header 错误，或者被反向路径过滤器（rp_filter，reverse-path filter）机制识别为欺骗数据包的情况。管理员将能够看到由于不支持更上层协议而被丢弃的 IP 数据包了。还增加了因 IPSec XFRM 策略或内核内内存不足而丢弃 UDP 数据包的原因。

还有一组 reason 注释已经被接受，但还没有进入 linux-next。这些 reason 有可能也会出现在 5.18 中。它们将 XFRM-policy annotation 扩展到了 TCP，标注那些由于丢失或不正确的 MD5 哈希值（显然在 2022 年 MD5 hash 仍然在用）而丢弃的数据包，以及那些包含了无效的 TCP flag 或当前 TCP window 之外的 sequence 序号的数据包。这些 patch 还增加了上述其他 reason 的新的检测位置，因为有些情况可以在多个地方被检测到。

虽然上述一组 reason 看起来已经很多了，但这项工作可以看作是刚刚开始。在当前的 linux-next 中，有超过 2700 个对 kfree_skb() 的调用，而对 kfree_skb_reason() 的调用只有 18 个。这表明很多数据包仍然会因为不明原因而被丢弃。尽管如此，这项工作仍然代表了一个有用的改进，它应该会使系统管理员更容易获得丢包的原因。

当然，仍然缺少用户空间方面的支持。目前的 reason 代码都是在<linux/skbuff.h>中定义的，这并不是外部可用的内核 API 的一部分。把它们移到 uapi 目录下的一个单独的文件中就可以使它们更容易被开发者访问到。当然，有一些关于这个机制以及如何使用它（并进行说明）的文档也会很有帮助，但是即使是编者本人这么乐观的人，也不认为这会很快出现。

不过这样还是会让内核网络功能中的重要一部分可以对用户变得更加透明。这应该会使系统管理员的生活更容易，他们将能够花更少的时间来弄清楚为什么数据包会在系统中消失。但不幸的是，这项工作没有为那些想知道为什么他们的数据包会在互联网的某个地方消失的用户提供帮助。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～