@iTYC Surveillance Station 有版本要求吧。有条件的可以提交工单问问，没条件等待 Device Pack 更新通道下发吧。

@KATTEN 不太清楚这个

@KATTEN 群晖技术支持回复如下：

1.将摄影机的编码格式调整为 H.264

请先透过摄影机的网页管理介面或官方 App ，将影像编码格式由 H.265 改为 H.264 。
（目前遇到此问题的摄影机在 H.265 相关功能上可能无法正常建立连线。）

2.手动安装附件中的 Device Pack

请前往 Surveillance Station > 应用程式中心 > 手动安装，并安装附件中提供的 Device Pack 版本。
重新新增摄影机

3.安装完成后，请再次尝试于 Surveillance Station 中新增摄影机，确认是否可以正常完成设定。

-----

实际测试使用 H.265 配合最新的 Device Pack (6.2.7-6722) 已经可以正常添加摄像头。

Device Pack (6.2.7-6722)：
https://drive.google.com/file/d/16wVHGxmRmCDW1Zeep2f8GAIgxAmFbsu3/view?usp=sharing

@KATTEN "您的问题已经提交给相关工程师查看，一般需要 1~2 个工作天，烦请您耐心等待。"

@KATTEN 已经提交工单了，等待回复。

有同样的问题，型号也是 IPC48DW

@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 等