因为你没看第四条：违法合同无效。
不接受不签字，找仲裁，找律师。

联络他的家人，联络下家 HR ，这些行为都可能违反隐私相关法规。建议在咨询法务部门之后由专门的 collection 公司执行。

你司法务呢？财务呢？
有什么必要，到论坛上问一群码农？

1. 如果你想挡住非浏览器用户，你应该用反爬技术 /图灵测试。鉴权的目的是确认请求来源掌握这个密码。而不是确认请求来源是特定真人。
2. HTTP basic/digest authentication 一般配合 HTTPS 使用。脱离 HTTPS/CA 的鉴权很容易被中间人。
3. “即便吧 abcdefg 加密成任何形式的密钥，但始终能在请求标头中看到加密后的密钥，用这个密钥发送请求依然可以成功”
这就是我反对用户侧密码 hash 代替 HTTPS 的原因。用户侧密码 hash 只不过是把 hash 结果变成了实质上的密码。
4. 你这个需求，一般通过限时 /限次数的 token 控制。网页中嵌入 token 。API 请求时带上 token 。就算有人能从网页源码中找到 token ，token 也会过期被服务器拒绝。

@clearc 有，无线 kvm
但是要么效果不行，要么价钱还不如买个游戏机
毕竟 xss 和 switch 也没多贵

1. 有无线 hdmi 或光纤 hdmi 。价钱不便宜，而且控制是问题。
2. 有线网络串流其实效果很好。比如 steamlink 。Xbox 也有类似的 remote play 功能。
3. 如果不是已有网线的话，重走线的成本很可能比再买一套更贵。

测速能跑满千兆和 BT 能跑满千兆是两回事。
你的问题可能是连接数太多，徒增 CPU 开销。尝试减少线程数 /连接数，看看效果。
然后，BT 是随机读写。瓶颈也可能是硬盘。如果你连接数太多的话又会打乱读写，又加剧这个问题。
如果内存够大的话，软件可以在内存里缓存到一定量再一次写入，减少随机读写。群晖的内存又不大。

@FabricPath 如果耍赖，不给用 GRO ，那就有可能。
nginx 可以用 LRO ，iptables 不行。也不一定是 Nginx ，可以是其他能更好利用 0 copy/1 copy 的用户态软件。

用 iptables 实现的是 L3 代理。L3 代理受到 end-to-end 限制，而 L4 代理不受。如果能在内核态实现 L4 代理或者允许 L3 代理放宽 end-to-end 限制，那当然可能得到更高的性能。

上面的邮件就是有人忽略限制硬开 LRO ，获得了比 GRO 更好的性能。
但是这个案例能否在用户态重现，那就很难讲了。因为 Linux 在 socket 到 socket 的情况下，并没有 0 copy API ，splice 也用不了。

@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 工资，你说你选哪个？