@tool2dx 正常流程是客户提供信息，机房在设备加白。不过黑产直接利用了设备检测漏洞绕过了这个正常流程。没有 80 端口 TCP 阻断。

@COW 是的

认同上面关于协议开销其实可以忽略不计, 个人认为主要的 PPPoE 问题是在很多实现上都是单线程的。

上面各位提到的 cgo 开销问题可以用魔法缓解下

https://github.com/petermattis/fastcgo

前几年用 TypeScript 实现的 SSTAP, 包含了 TUN 操作、 精简 TCP 协议栈。
https://github.com/Srar/node-tap

猜测可能是硬件多次中断在短时间内会合并成一个中断来通知，这个是 intel 网卡关于中断合并的表述:

```
When an event occurs, the adapter generates an interrupt, which allows the driver to handle the packet. At greater link speeds, more interrupts are created, and CPU rates also increase. This results in poor system performance. When you use a higher ITR setting, the interrupt rate is lower, and the result is better system performance.
```

看下 /ipv6/settings 的 Disable IPv6 是不是勾着

尝试下 runtime.KeepAlive? 可能是被 gc 收走了

ARP 代理尝试下，可能是广播域问题

@Fu4ng 是的，当然这还要看应用场景。例如使用用户态接管网卡的应用大部分是作为数据包转发(NFV 场景)，就没上下文切换啥事情了。如果是用作均衡负载、重小包场景(例如游戏服务器)，就可以省去上下文切换这个步骤了。

@Fu4ng 数据包被多次复制只是性能受影响的其中之一，还有别的因素也会影响例如上下文切换、处理流程造成的 Cache Miss 等