看 MTU ，正常 1492
如果是 1442 的话，欢迎来到 PCDN 流量竞技场

@allegory 追热点去搞 AI 吧，infra 最近两年没啥新活了

苹果滑了一下正常，你是目录里面文档太多了？我最大的一个目录里面只有 40 几个文档

DPDK 和 RDMA 都不建议，建议远离网络。
对于 DPDK：
1. DPDK 太成熟了，成熟到每个会用 DPDK 的公司都一堆 DPDK 的开发
2. DPDK 大部分场景都是和虚拟机、L4LB 、NAT 相关，这些场景都有低性能的现成的替代品，DPDK 只适合对性能有要求的场景（比如 L4LB ，小规模场景 ipvs 跑个几十 Gbps 妥妥没问题）
3. 随着容器化推进，随着虚拟机场景的收缩，DPDK 会集中在 L4LB 之类的集中式网关场景，容器化场景无法使用 DPDK （浪费 CPU 、相比 ebpf 没有带来性能优势、ebpf 吊打 vduse 这种强行在容器场景上 dpdk 的方案）

对于 RDMA：
1. 纯硬件实现，你在其中能做的事情不多，大量的时间会用在性能测试、拥塞控制测试、监控开发、配置脚本开发
2. RDMA 中短期场景有限，对于小公司来说，只有 AI 和存储场景有优势；在 rpc 场景是负向收益（或者说收益是否值得全网采购 mellanox 的网卡）；在低于 100Gbps 的带宽下 RDMA 相比 tcp 没有优势（ rdma 延迟稍微低一点，但是你真的需要低这几 us 的延迟？）
3. rdma 领域，mellanox 一家独大，mellanox 在 20 年前开始搞 infiniband ，被以太网压了 20 几年，这两年终于出头了，那不大赚特赚一波；再加上 nvidia 收购 mellanox 之后 GPU+网卡的强绑定，导致 RoCE 生态被 mellanox 独占
4. 最近几年 mellanox 吹他的 ProgrammableCC ，但是真的用 PCC 的公司屈指可数，DCQCN 能满足 99%的场景
5. RDMA 的应用层开发如上所说，AI 和存储场景有优势，但是存储领域，现在 kernel 的 nvme-of 很成熟，SPDK 也很成熟； AI 领域，NCCL 虽然 bug 很多，但是也能用，而且一般公司也不会选择去大规模修改 NCCL


你还想听我能给你扯一堆理由，简单学学可以，要变现很难；当成兴趣爱好学习一下没啥问题。
RDMA 和 DPDK 都可以闲鱼买 mellanox cx4 （几十块钱）、cx5 （几百块钱）来入门

@pdf01 海外的都行，阿里云偶尔会打骚扰电话，烦

阿里云买 9 年，转到狗大爹去，转移要付 1 年，刚好 10 年

网络层的权限管理能力太弱了，只能控制通和不通；
建议你直接用 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 已经失效了