@FabricPath
@tkl
@heiher
找到了这封邮件： https://www.spinics.net/lists/netdev/msg107539.html
可见 LRO 在特定情况下是有性能优势的，也可见 iptables 无法使用 LRO 。
但是我忽略了 GRO 的影响。有 GRO 的情况下，LRO 的“边际收益”并不大，更不用说内存拷贝的开销了。
所以 iptables 更快是对的。但原因并不是 iptables 更简单所以一定更快这么简单。

昨天上班时和 Stephen Hemminger 聊了一下这个问题，结论如下：
1. 如果网络不稳定，带宽不太高，那 nginx 等 L4 代理能改善 timing 和 congestion control ，throughput 会更好一点。
2. 这封邮件说的情况可能存在，但肯定是个非常少见的 corner case 。支持 LRO 的设备本来就少，Linux 社区也倾向于废弃 LRO 改用 GRO 。
3. 所以如果是比较干净的网络，那还是用 iptables 更快。
4. 如果想要 nginx 的灵活性，但又想要 iptables 的性能，可以考虑 BPF/XDP 。

@FabricPath
“如果哪家云还在用 iptables 或者 iptables 类似物做产品，最好别买”
我说的就是 Azure 。Azure 使用 VFP 处理数据包。就算单纯匹配 5 元组，但是因为还有各种封包 /解封包操作。单连接带宽是过不了 10G 的。你想要满血网络，就必定要靠硬件加速。Azure 用的是 FPGA 。多连接当然可以靠堆 CPU 靠 RSS 硬抗，但是那就贵了。
AWS 虽然是以 smartnic 为主，但是碰到复杂情况硬件不支持就只能靠软件扛了。
GCP 是以 DPDK/自研软件处理，但是 GCP 单连接是跑不满线速的。
这是当年的性能比较： https://blog.acolyer.org/2018/05/01/azure-accelerated-networking-smartnics-in-the-public-cloud/
当然这里 Azure 取巧了：比的是单线程带宽


言归正传，楼主的问题是基于原版 netfilter vs nginx 的情况，扯 dpdk 那就是完全两回事了。咱们先把 dpdk 放下。

“网络加速能力是内核态用不了，而只能用户态能用”
我从来没说过这话。理论上当然 iptables 干什么都行。魔改内核干什么都行。但是原版内核还是有一些原则需要遵守。
iptables nat 转发不能使用 LRO 是因为 LRO 破坏了 end-to-end 原则。L3 的 ip_forwarding 不应该去修改 L4 的内容。GRO 保留了包边界，因此应当是可以使用的。但是 GRO 的效果和硬件支持的 LRO 比，哪个更好还未可知。

说实话，我近年都是搞 Windows 网络为主，Linux 并不是我的强项。但是既然这个问题也算是我分内之事，我会再研究一下，不希望误导大家。

@tkl 根本问题不在多一层少一层，而在于能否充分利用硬件 offload 。高性能网络早已不是 CPU 加高频率硬扛可以扛下来的。而是要靠 offload 为主。
如果 iptables 同样能充分利用硬件，那当然 iptables 会快。
问题就在于这个如果是否成立，在多大程度上成立。
纯靠 iptables 的路由器有没有，有，但是用的是魔改内核和 netfilter 。比如博通的 ctf 。后来博通也开始搞硬件的 offload ，也就是 flow accelerator 。

如果你送 xss ，那你最好带上 3 年西瓜皮一起送
送其他游戏机也最好配上常见的游戏卡带
好人做到底嘛

@FabricPath 找到了两个 reporte bug：
https://support.hpe.com/hpesc/public/docDisplay?docId=c03168563&docLocale=en_US
http://ehaselwanter.com/en/blog/2014/11/02/mtu-issue--nope-it-is-lro-with-bridge-and-bond/

GRO LRO 导致 ip_forwarding 出问题，说明了 LRO 对 iptables 和后续的转发是有效的。或者说预期上应当有效。
但是由于某些驱动的 bug ，导致出错进而不得不关闭 GRO LRO ，这是另一回事了。

@geeglo
“用户态程序做的事情更多，CPU 反而能省下？”
我上面着一大段就是在解释，为什么 L4 代理可以比 L3 代理更快。
L4 代理并不是改每个包的地址，而是在建立了两个 TCP 连接，分别收发。这种情况下，两侧连接都可以充分利用硬件加速。
L3 代理因为不经过 TCP 协议栈，tso lro 都是用不了的。就要修改每个包的地址。

家用路由器为什么需要硬件 nat 加速？说白了就是 SoC 性能不足以处理每个包。软路由所需的 CPU 的性能 vs 硬路由的 SoC 的性能，这没法比。硬路由可以用更弱的 SoC 实现同样的性能（在有限的功能范围内），恰恰是说明了，硬件加速对于网络处理的重要性。

以上是对于比较稳定的高性能网络。瓶颈在硬件性能。

对于不稳定的网络，L4 代理可以减少重传和延迟，因此能提高单个连接的 throughput ，准确的说是 goodput 。对于这类网络，瓶颈在于 TCP 流控和重传。连接处理性能不是瓶颈。


以上是我原本的观点。

但是楼下 @FabricPath 说 nf 在 driver 上层，而 gro/lro 是对所有 TCP 包都有效，因此 nf 也可以享受到硬件加速。如果是这样的话，那 nf 的转发能力肯定是要比 Nginx 要强的。

@heiher 理论上是这么个情况，实际上恰恰相反
用户态收发 TCP 数据高度依赖硬件加速。tso/lro
而 3 层转发需要修改每一个数据包，还不能碰 payload 。所以 3 层包处理是个很费 CPU 的工作。

这也是为什么云平台的虚拟防火墙的性能上不去。高效能网络都是要靠硬件加速。把虚拟化网络相关的操作也下放到专有硬件上。

不靠 sriov ，不靠 dpdk ，一般操作系统的单线程包转发性能也就 10G-20G 最多了。用好 RSS 可以更多，但那成本就高了。而且对单个连接无效。

jumbo frame 也是个办法，但那也属于硬件支持了。

但是普通的 CPU 收发 40G ，100G ，其实都不是什么难事。因为操作系统此时收发的实际上是 65535 字节的超大包。网卡 tso 会拆分成 1500 的普通包发出。接收时也同理。

一个是 3 层，一个是 4 层，根本不是一回事
3 层的性能可能比 4 层差，但有专有硬件时可能比 4 层好。但是说回来大多数人应该接触不到这个级别的带宽。

4 层会处理好 TCP 超时和重传（ terminate connection ），对于延迟高、不稳定的网络来说能提速。简单假设就是延迟和丢包率都减半，那 TCP 的流控自然会稳定很多。

@kesichen89 笔记本是不存在独显输出的。都是集显输出。独显渲染画面再交给集显输出。所以笔记本能带多少分辨率完全取决于集显能力。

“小型团队一样直接开发给用户侧的东西，或者自己负责一大块业务”
直接对用户的产品压力只会更大。后端的开发周期长，不会随便上新功能。只要老板不坑，懂得挑活，能怼得动产品，手下的码农并不辛苦。

你一个新毕业的就别想什么负责业务了，能负责一个模块就算很好了。

“因为我大学期间做了快 2k 同学用过的项目，在维护项目的过程中觉得很酷很有成就感”
我大学时做的还日活上万呢。
2k 用户得成就感和多 2k 工资，你说你选哪个？

我也有一堆信用卡，授信额度加起来超过 25 万美元。

和楼主的区别在于，我从来不给银行交一分钱利息，从不用超前消费。信用卡当借记卡用，消费转返现。我一年从信用卡的净收益几千美元。

基本上每个账单都还清，不还清的情况只有免息或者免息分期。不是因为我没钱还，而是免息不借白不借。

信用卡是非常好的工具，但是你得会用。用法错了就会被反撸。

单看这两行其实问题真不大……
可读性还更好了

不知道 java 如何，反正在 C 里，这样写是不会影响性能的。编译器全都给你优化掉。

“log4j2 可以跟各种信息平台对接，比如 kafka ，也可以直接配置写入数据库，各种 appender ”
所以呢？你用得到这些功能吗？
用得到，见第二条。
用不到，那你不需要知道这些功能。

“log4j2 可以直接把数据记录成 CSV 文件，各种 layout ，以前我都会自己写代码来实现这个功能”
这个问题不在于你是不是 log4j2 大师。而在于你在重新发明轮子。在写代码实现这个功能之前，先问问自己，这个功能别人用不用得到。如果别人有可能用到，那别人很可能已经发明过这个轮子。然后再有的放矢地搜索： https://lmgtfy.app/?q=log4j2+csv

学海无涯。搞学术的需要格物致理，不懂的一定要搞懂。搞工程的一定不要这样，你的工作是有什么工具能用就用什么，重点是花最小的成本把问题解决掉。你的时间也是成本，所以在开干之前，先想一想，你在干什么，你为什么要干这个，有没有别人已经干过这个，能不能利用现成的工具？

润可解…………
独栋大豪斯，suburb 安静又方便

能用，但是升级的时候会很卡
我用的是 64G 的垃圾 SSD ，再垃圾也比 U 盘好

铅酸蓄电池稳定得很，注意买个塑料桶以防漏液

3D 加速不是勾选了就有效的。如果显示感叹号就是没装扩展包用不了。

也可能只是虚拟显示驱动的问题，那么 VNC 可解。

另一个办法是 X11 转发。渲染交给终端系统，虚拟机内不渲染也就不需要 3D 。

1. 不必要。你已经有多重备份。RAID 是保护可用性的，不是保护数据留存的。
2. ups 比 raid 1 更重要。没有 ups 的话意外断电可以导致文件系统错误，这是 raid 1 也无法解决的。而且参见 1.
3. 不大。SMR 用于顺序读写问题不大。但不能用于基于文件系统的 RAID ，比如 ZFS 。
SMR 可以用于普通的、文件系统无关的 raid ，比如硬 raid 或者 md 。因为这类 RAID 重建时是顺序写入。

其实 SMR 用于 ZFS 也完全可以，前提是你有 CMR 的等容量磁盘可以用于重建写入。ZFS 重建写入不能写到 SMR 盘上，因为是高强度随机写入。
我目前 SMR 盘和 CMR 盘都有，另外有一块 CMR 盘备用。如果需要重建，我会先插入 CMR 盘重建，同时购买新的 SMR 盘，然后把用 dd 顺序复制重建好的 CMR 盘内容到 SMR 盘。分区 ID 不变，直接用 SMR 再原位替换 CMR 盘。最后再校验一遍错误。