不知道你实际情况如何，按照我身边仅有的一个案例来说，碘 131 做完之后，每天吃优甲乐，除了精力稍差，其他和正常人一样（按照目前已有的资料，因为新陈代谢速度降低，还会稍微延长寿命）

好吃好用的东西如果淘宝买不到，要么不符合当地人的习惯，要么就是不是真的好吃、好用

@fat00119 很稳，不过最近有大事件，套了 cf 保平安，日常感知不出来，网飞 4k 很流畅

我一直没感受到各大运营商的网络有啥差异。现在骨干网建设得很完善，三大运营商网络质量都很好。
不过我这里上海联通到日本 aws 是直连，不到 40ms ，晚上 iperf 也能打到 500Mbps

自如，非自如租户也能用，通马桶大约 80 （自如租户名义上要收钱，实际上每次小哥都会免单，对他来说收入没区别）。通马桶要啥药剂？我通马桶来就是一根软的铁链子+电钻暴力钻通。

如果一个普通后台开发，还需要接触到 container 或 kubernetes ，那是公司基建太差的问题。
如果只是兴趣的话，minikube 拉一个 k8s 起来，能从 0 开始写一个 HTTP hello 部署进去，能用 Service 访问其他服务，能用 Ingress 把服务暴露出去，就差不多了

因为写 C 和写 Go 的程序员都比较有钱

不知道 lol 的延迟算法是啥，但是延迟低 != 不丢包，先看看丢包率是否正常

windows: ping www.baidu.com -t
unix: ping www.baidu.com -i 0.1

这可能是百度最有用的时候

如果到公网不正常，再 ping 路由器地址，确定问题出在哪一段
如果到公网的 ping 和丢包都正常，但是游戏就是卡，这原因太多，只能 case by case 分析了

随便搞个 n5105 的 4*2.5G 的软路由，这上传速度，软路由这一千多块钱不就几天就搞回来了

本质上类似买股票，你买股票亏了钱找交易所赔么？
如果上市了翻了 100 倍你还会在这里发帖吗？
本身就是赌，期权相比股票的风险很大、收益也更大；愿意承担风险就买，不愿意就不买。

iptables-save 检查 iptables 规则，你的这个场景，软中断消耗基本上只有 netfilter 。
如果没啥异常，perf top 看看是在干啥，不知道 openwrt 有 perf 没

关联的两个 iptables action 是 -j CONNMARK --save-mark （把 skb-mark 复制到 ct-mark ），-j CONNMARK --restore-mark （把 ct-mark 复制到 skb-mark ）

因为 linux route 是工作在 L3 的组件，对于 route 系统来说，是 per-packet 处理的，不关注你的连接。如楼上所说，如果你需要让他从哪儿进来从哪儿出去，那就需要在创建 ct 的时候，设置 ct-mark ，在出向的时候把 ct-mark copy 到 skb mark ，再通过 ip rule 配置不同的 skb mark 走不同的接口出来。

Singularity has been EOL'ed, see Apptainer

出门小米 65w ，小巧方便。
问题是玩游戏的时候两三个小时电池就用光了，轻度使用电池不耗电。
充电功率对电池寿命没有影响。

@ryd994 在 L4LB 场景下，如果能测出 nginx 能比 ipvs 更快，我也想学习一下这到底是什么样的条件和场景，无论是 latency 还是 throughput

@ryd994 不知道说的是哪家的防火墙有性能问题。云平台的防火墙的性能，不知道你是指 nfv 版的防火墙，还是普通的安全组。如果是安全组，各家公有云都是在 Host 侧的 dpdk 实现的，本来 Host 的 dpdk 就一定会有 ct ，连接一旦连接之后，都是在快路径匹配五元组转发，不会遍历流表，所以性能上不去是不存在的，至少目前没听说过国内国外那家公有云的安全组会影响影响。ACL 是无状态的，无 ct 的功能更不可能影响性能。唯一可能就是 nfv 的边界防火墙，或者入侵检测，对应阿里云的云防火墙，这种都是 dpdk 实现的 dpi ，如果说有的云厂商初期会选择用 x86 的 server 来用 iptables 做防火墙，那是有可能会有性能问题，不过迟早都会走向 dpdk 。
iptables 已经在云网络绝迹了，如果哪家云还在用 iptables 或者 iptables 类似物做产品，最好别买。

此外有什么“网络加速能力是内核态用不了，而只能用户态能用”，我理解是不存在这样特性的，如果有的话可以贴一下，我也学习一下。
iptables offload 这个事情社区推进很久了，但是 iptables 本身也即将退出历史舞台，而无论是 iptables 还是 nftables ，绝大部分场景都是用来做有状态服务，而有状态服务要做 offload 最难的地方就是要管理 ct ，网卡无法完成 ct offload 的闭环，需要将带 sync 、rst 、fin 等 flag 的报文送到内核来变更 ct 状态，并决定是否插入或删除硬件的 entry ，带来的问题就是对短连接性能影响较大，家用场景因为连接数少（ 16k 以内），所以是没啥问题的。
关于网卡 offload 能力的 feature ，比如可以搜 NETIF_F_TSO ，来看哪些地方和 TSO 有关，理论上有它出现的地方都是在网卡 driver 。

@ryd994 lro 应该已经被 gro 淘汰了，没用过 lro ，这块儿不是很了解。nf 大部分钩子是夹在协议栈和 driver 之间的，协议栈不会去检查 dev 的 features ，所以 nf+协议栈+用户态看到的报文内容是相同。 区别是用户态在收发包的时候需要多一次内存拷贝，所以要实现相同的功能，任何情况下内核态的 iptables 都会比用户态的 nginx 性能要好。
比如都是做 L4 代理，在 rx 收到包之后，首包做完 dnat 后建 ct ，后续报文 nat 表的 hook 直接匹配 ct 就修改报文转发出去了，不会经过协议栈；同一个报文，nginx 是 rx->link->network->protocol->copy 到用户态->nginx 解析->把 data 发送到到 rs 的 socket->copy 到内核态->protocol->network->link->tx 。
另外关于硬件加速这部分，对于 x86 服务器来说，通常情况下只关注 csum offload 、tso 、tls offload ，只有这几个是真正硬件在做的，其他如 gso 、gro 都是纯软件实现。家用路由器的 nat 加速是针对特定场景定制的处理器，具体我不是很清楚它的实现方式，盲猜应该是快慢路径，iptables 处理建联过程，ct 建好后通过 sdk 下发到转发芯片上。
至于说要实现真正的硬件 offload ，目前有且仅有 mellanox 的 cx5 、cx6 的 switchdev sriov+tc flower offload 是在生产环境大规模使用过，当 tc flower 是 in_hw ，那 tcpdump 都看不到报文，全部在 eswitch 处理了（带 ct 的规则除外，ct offload 比较特殊）。