某个周一上午，办公网一台出口路由（倍控+爱快3.7.11）与核心的lan大量口丢包，CPU毛刺，出现问题时连接数异常飙升，相关用户断网，持续几分钟后可自行恢复。

疑问：连接数异常是因还是果？是因为性能异常导致的连接数处理不及时而堆积吗？

检查核心相关端口，未观察到明显突发流量。

第二天，又出现。

之前爱快设备出现过假死（无法恢复），配合假死时间的日志发现有wan口在拨号。 之前运营商光猫偶尔会假死，端口不down，所以我们在上光猫配置了周期性重启。怀疑是多个wan口状态变化+端口分流内策略较多，触发了策略计算的bug，导致异常，重新调整分配了多个wan口的重启时刻，避免同时触发。

疑问：是不是某运营商线路异常，导致wan口线路检测频繁失败，从而触发爱快策略计算，某些代码bug导致cpu异常？

删除了部分端口分流策略。 关闭运营商wan口线路检查，观察，又出现了，连接数有突发，但是cpu 峰值下降，影响稍微减弱。

网络设备没任何变更，哪里有变化？检查日志发现爱快更新了协议库。是不是协议库的问题，某些类似正则的规则异常？例如cloudflare 之前的正则表达式引发cpu耗尽的故障

协议库似乎没法回滚。决定关闭协议库特征库更新，升级爱快版本，删除协议分流策略。

删除协议分流策略之后，关闭增强分流，CPU同比骤减50%。但是没几天，连接数突发又来了。不过cpu 起伏不大。至此得到2个结论：

1. 连接数突增是因，不是果；
2. 协议分流极其耗费CPU；

和官方反馈后，提示关闭增强分流。 另外查到增强分流另外一个问题：iKuai爱快拨号下，所有tcping对端无法正常返回FINACK #464。我们之前内网确实遇到过某个服务长时间上传数据之后，tcp会话拿不到 finack包，导致业务逻辑异常，一直以为是哪个地方NAT表过期淘汰的问题。

后来，连接数又突增了，这次在IDS系统中查看（之前几次也看过，由于头部几个常见的高连接数ip，忽略了），取对应时间连接数top10，发现有一个办公设备段的异常IP：35.223.238.178，一分钟几万条新建连接。在ti中查到是codeium的ip，联系对应设备负责人发现是使用了windsurf，最近有更新版本。 倒查该IP在IDS系统中的连接活动情况，与故障时间吻合。至此，确定是最新版本windsurf 的bug 导致连接数异常。

在codeium的discord 提了issue，然而官方在实锤证据面前，还要我配合提取各种日志。费劲，直接drop 了这个ip完事。

结论：

1. 谨慎开启协议分流
   1. 收益不高，消耗较大；
   2. 猜测panabit 和fortinet 性能估计更好一点。
2. 谨慎开启协议库与特征库更新
   1. 由于是官方自动更新，等于随时对网络设备进行变更，我们都知道网络设备更新是要有严格变更流程，如果引入异常数据导致异常，无法预计无法回滚。
   2. 是不是因噎废食，就看场景了。
3. 关闭增强分流
   1. 官方提出的建议思路，说明客户中出现过导致性能异常的case；
   2. 存在finack 回包丢失问题；
4. 对客户端连接数限制？还在考虑，但是听说又有bug。