4. IP层性能优化

IP层是转发路径上最“薄”的一层，但它决定了每个报文能否被快速送出接口。很多看起来是“带宽不够”的问题，实际瓶颈在IP层的五个处理环节：分片与重组、TTL处理、路由查找、ICMP限速、IP选项解析。理解它们各自消耗什么资源、在什么条件下被触发，才能判断优化该从哪里下手。

分片与重组：代价在“重组”而不在“分片”

当报文长度超过出接口MTU且DF位为0时，路由器执行分片：把原始IP数据报切成若干片，每片复制原IP头并修改总长度、片偏移、MF标志，同时重新计算首部校验和。分片本身开销有限，真正的代价在目的端的重组：需要维护重组队列、按偏移排序、等待最后一片到达，并设置重组超时（Linux默认ipfrag_time=30s）。

重组队列是有上限的，Linux中由net.ipv4.ipfrag_high_thresh（默认约4MB）和ipfrag_low_thresh控制。当分片流量突增、队列被占满时，新到的分片会被丢弃，触发大量重组超时，表现为“丢包但链路不拥塞”。更隐蔽的问题是分片攻击：攻击者发送大量不完整分片占满队列，正常业务的分片无法重组。

工程上的处理原则是：能不分片就不分片。在路径两端启用PMTUD（Path MTU Discovery），让发送方根据ICMP“需要分片”消息调整报文大小；对必须承载大报文的隧道，把隧道接口MTU调小并配合MSS Clamping，避免隧道内再分片。若业务确实依赖分片，应监控/proc/net/snmp中的ReasmReqds、ReasmFails和FragFails，一旦ReasmFails持续增长，说明重组队列或超时参数需要调整。

TTL处理：一次减法与一次判断

每台路由器转发前把TTL减1，若结果为0则丢弃并回送ICMP超时消息。这个动作本身极快，但有两个性能相关点：一是TTL=0时生成ICMP需要消耗CPU并可能被限速；二是traceroute类工具会故意构造TTL递增的报文，若被滥用会形成ICMP生成压力。正常情况下TTL处理不构成瓶颈，但在环路或错误路由导致报文反复转发时，TTL递减是防止报文永久循环的最后防线，此时大量ICMP超时消息会成为CPU负担。

路由查找：从线性匹配到最长前缀匹配

路由查找要在转发表中找到与目的地址匹配的最长前缀。早期实现用线性遍历，路由表大时性能急剧下降；现代实现使用LC-trie、多比特trie或基于硬件的TCAM。软件转发路径上，Linux的FIB查找已高度优化，但仍有几个影响性能的因素：

• 路由表规模：全表路由（约95万条IPv4前缀）下，缓存命中率下降，查找延迟上升；
• 路由缓存失效：频繁的路由抖动导致缓存反复重建；
• 策略路由：多条规则链式匹配，规则越多，单包处理时间越长。

优化方向是减少不必要的路由条目、合并策略规则、在边界设备上使用硬件卸载。对软件转发设备，可通过ip route show cache（旧内核）或perf分析确认查找耗时占比。

ICMP限速：保护CPU的阀门

ICMP消息（目的不可达、超时、需要分片）由转发平面异常触发，需要CPU生成。若不加限制，攻击者可用大量触发ICMP的报文打满CPU。Linux提供net.ipv4.icmp_ratelimit（默认1000ms）和icmp_ratemask控制哪些ICMP类型被限速。限速过严会导致PMTUD失败、traceroute结果缺失；限速过松则CPU易被打满。合理做法是对“需要分片”和“超时”类消息保留足够配额，对“目的不可达”类适度收紧，并结合icmp_msgs_per_sec（默认1000）设置全局上限。

IP选项处理：慢路径的典型触发条件

带IP选项的报文（如记录路由、时间戳、源路由）无法走快速转发路径，必须交给慢路径处理。原因在于选项改变了首部长度和语义，硬件或快速路径通常不解析选项。源路由选项尤其危险，它允许发送方指定转发路径，可能被用于绕过安全策略。多数运营商和云环境直接在边界丢弃带选项的报文。若业务不需要IP选项，应在入口ACL中丢弃，避免慢路径被异常流量占用。

综合优化建议

把五个环节放在一起看，优化优先级通常是：先消除分片（启用PMTUD、调整MTU/MSS），再控制ICMP生成速率，然后精简路由表与策略规则，最后在边界丢弃带IP选项的报文。TTL处理本身无需优化，但它是环路检测的兜底机制，不应被关闭。

一个可直接参考的检查清单如下：

IP层优化的核心判断逻辑是：让报文走快路径，让异常走慢路径但受控。分片、选项、ICMP生成都是把报文从快路径拉向慢路径的触发条件，减少这些触发、并对无法避免的触发设置合理上限，就能在不大幅增加硬件成本的前提下提升转发性能。