问就是不需要。问就是爷乐意，买个玩具你也要管？

@CrazyMonkeyV 我不知道说啥好。我工作第二年就能买房买车，住在两层小别墅里，上班时间摸鱼刷个论坛（对啊，我 WFH ）。要你关心我破不破防？

俺就是一小屁民，俺没啥志气，就是想赚点工资，过得舒服点。在这一点上，码农在国外确实是更舒服的。你说什么精神啊、文化、国家战略的，俺不懂，俺只在乎自己和家入这点小钱。

外国的月亮没有特别圆，但是外国的天确实是更蓝的。

为什么直接往 master commit ？每开发一个功能就应该开一个 topic branch 。topic branch 里随便你怎么搞。搞完最后提交一个 PR ，squash merge 到 master 。保证最后 PR 看起来是干净的就行。

或者你可以在自己的 branch 上随便 commit 。最后 rebase+squash 一下，留下一个大 commit 再 cherrypick 到 master 。

@1217950746 不要纠结底座。买个支架又不贵，彻底解决问题。

Google 不懂中文
92f to c 就没问题

盲猜是内存规格变了导致原本的内存参数无法 POST 。BIOS 自动恢复到安全设置并禁用了多核心（ SMP ）。
检查 BIOS 设置看看。找 CPU 相关配置里有关多线程多核心的设置。

@lslqtz #56 这是个点对点的需求，但是通过其他服务器转发，可以把它变成多点对多点的传输，就可以绕过运营商限速。

打印机又不是只能打印。现在很多是多功能机，扫描复印都可以。
直接复印和扫描到电脑再复印还是有区别的。直接复印的精度高很多。乍一看分不清哪个是原件。
用手机、相机拍照代替不靠谱，临时存点信息可以。比较重要的文档，想要之后再打印出来的话，还是扫描最好。扫描出来的没有镜头畸变，稿台还可以保证文件压平。

其实喷墨的也完全可以用。你动手能力强的话自己注墨就好了，算下来价钱其实很便宜。
用量特别大的，可以买墨仓式喷墨或者激光
用量特别小的也别买喷墨，容易堵

我大约每月至少一两次，每次就打几张纸。这个频率就已经足够能不堵了。

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

联络他的家人，联络下家 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 并不是我的强项。但是既然这个问题也算是我分内之事，我会再研究一下，不希望误导大家。