网络层的权限管理能力太弱了，只能控制通和不通；
建议你直接用 ServiceMesh 去解决权限问题

@0x5c0f 你自建没有问题，他这个问题是因为 redis 在公共服务区，他给你的是一个 1：1 nat 的访问地址

跨 Vpc 访问底层数据库这个方案设计得不好。
你如果两个 Vpc 本来就属于同一业务，那直接建 peer ，无 nat 直接访问；如果本来就属于不同业务，那应该暴露 API 而不应该暴露 Redis 。

@bzw875 你都翻墙出来了。。。放眼看看全世界好吗

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 会导致延迟抖动

有一说一，上海联通有一大好处是，当你有合约又想要无责销户的时候，挂个 BT 疯狂上传，宽带被噶了就能免费销户了

@wanghaiping009 你可以永远相信上海联通的技术能力，摄像头被噶的又不是少数，上海联通没有能力分辨出“PCDN”和“PT 用户”和”网络摄像头“的区别

“合理上网需求” == 网络摄像头也被噶，哈哈哈哈哈哈，“谢绝家里有摄像头的用户办理”
现在开上海联通宽带的还不如开移动，又便宜、带宽又高，还不会担心被噶