TCP/IP场景下tc（流量控制）处理的是Packets还是Frames？

假设我们当前处于TCP/IP连接场景下。根据Linux内核网络流程相关文档的说明，tc工作在第二层，但互联网上其他资料都使用“packet”一词来描述tc处理的数据单元。请问tc实际处理的到底是Packets还是Frames？

两种表述都没有错误，差异来自术语的使用场景和tc的实际工作逻辑：

• 先明确两个术语的标准定义：OSI网络模型中，第二层（数据链路层）的协议数据单元为帧（Frame），第三层（网络层）及以上的协议数据单元为包（Packet），二者的核心区别是对应网络层级的不同。
• 内核文档中说tc工作在第二层的表述是准确的：tc默认挂载在网卡的排队规则（qdisc）路径上，此时处理的是已经封装好二层头部的完整数据帧，这种场景下它的操作对象本质就是Frames。
• 业界资料常用Packet指代也符合使用习惯：
  1. 日常技术交流中大部分开发者不会严格区分二层、三层的协议数据单元，会把网络栈中传递的所有数据块泛称为“包”；
  2. 当使用tc的过滤器（filter）匹配IP地址、端口号等三层、四层特征时，tc会主动解析二层帧的payload，获取三层包内容做匹配规则判断，这类场景下用Packet指代处理对象也完全合理。

日常使用时可以通过上下文判断具体指代：如果文档提到tc做VLAN匹配、二层流量整形等操作，对应的就是处理Frames；如果提到基于IP/端口做限速、流量分类，指代的就是解析后的Packets。

内容的提问来源于stack exchange，提问作者Hadarelv