https://v2ex.com/t/972245 你看看这个，我没用过，但是他这个思路是正确的，要看能“稳定发送数据”的“长连接”数量

@Bullpen3891 他这个是一直在新建连接，并且新建之后就关闭了，对于 bras 来说，会直接靠 fin 或者 reset 释放连接，所以不会占用“连接数”。
ikuai 的连接数来自 netfilter 的 conntrack ，conntrack 的条目是靠报文触发创建，靠 timeout 来 gc ，他和 bras 的连接数没有必然关系。ikuai 的连接数主要来自下面这些超时时间；调大下面的 timeout 可以让 ikuai 的连接数显示得更大
$ sysctl -a |grep conntrack|grep timeout
net.netfilter.nf_conntrack_dccp_timeout_closereq = 64
net.netfilter.nf_conntrack_dccp_timeout_closing = 64
net.netfilter.nf_conntrack_dccp_timeout_open = 43200
net.netfilter.nf_conntrack_dccp_timeout_partopen = 480
net.netfilter.nf_conntrack_dccp_timeout_request = 240
net.netfilter.nf_conntrack_dccp_timeout_respond = 480
net.netfilter.nf_conntrack_dccp_timeout_timewait = 240
net.netfilter.nf_conntrack_frag6_timeout = 60
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_gre_timeout = 30
net.netfilter.nf_conntrack_gre_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_icmpv6_timeout = 30
net.netfilter.nf_conntrack_sctp_timeout_closed = 10
net.netfilter.nf_conntrack_sctp_timeout_cookie_echoed = 3
net.netfilter.nf_conntrack_sctp_timeout_cookie_wait = 3
net.netfilter.nf_conntrack_sctp_timeout_established = 432000
net.netfilter.nf_conntrack_sctp_timeout_heartbeat_acked = 210
net.netfilter.nf_conntrack_sctp_timeout_heartbeat_sent = 30
net.netfilter.nf_conntrack_sctp_timeout_shutdown_ack_sent = 3
net.netfilter.nf_conntrack_sctp_timeout_shutdown_recd = 0
net.netfilter.nf_conntrack_sctp_timeout_shutdown_sent = 0
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 3600
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120

@Bullpen3891 ikuai 如果都只有 1000 多，那你连接数大概率被限制到 500 了。bras 的连接数限制是 lru 置换，你的 pt 一直在新建连接，所以你其他应用的 tcp 连接就被置换出去，就不通了

连接数限制，找一下连接数测试工具测试一下。

对新增的 API 或者字段没有需求的情况下，为啥要更新 proto...
如果整个经常需要所有引用方更新 proto ，那先问一下改 proto 的人为什么不能做到前后兼容。

所以，直接复制一份也没啥问题，你现在的痛苦不是“复制 proto”带来的

让小工再拉根光纤，easy

@tutugreen 卧槽？咋双拨的，cmcc 已经失效了

很好，不会
只是不能双拨了

没遇到这个问题，10G EPON 聚合下行 5Gbps 稳稳的。
大概率是你设备的问题，比如某些神奇的光猫桥接的时候需要勾选绑定 lan 口

可以用来增进技术，作为 ebpf 入门。
calico 和 flannel 这种用 netfilter 实现的方案太古老了，不够酷。
出事故不用你背锅的无脑上 Cilium ，要背锅的选你熟悉的方案

租车就俩选择，需要异地还车选一嗨，需要高端体验选神州。
一嗨要买第二档保险，新手时期剐蹭多次，刮爆过轮胎，掉过后备箱壳子，都不扯皮直接走

看你连接数，连接数低于 16k （大部分支持 netfilter 加速的路由器的 conntrack 上限）硬路由的吞吐和转发延迟完爆软路由。
如果连接数大于 16k ，硬路由没有体验可言，频繁置换 conntrack 会导致延迟抖动

我感觉你还不如换一个 4 口 2.5G N100 的软路由 + 2.5G 交换机
软路由装 openwrt ，性能、功能都比你现在的方案好。
wifi 用便宜的 AP ，AP 就好好做 AP 。
fortigate 的防火墙都是 dpdk 实现的，性能不会比内核转发快多少，60E 标称也才 3Gbps ，实际跑 2Gbps 不到。

内存小了，内存便宜，加到 64G
SSD 小了，1T 不够看，加两根 2T
电源可能小了，850W 满载可能会不够，考虑矿老板甄选 1200W 长城巨龙

主板不值得投入钱，供电够的情况下，主板不影响性能

内存太少了，我每个 IDE 给 16G 内存，完全没感觉到卡