硬件选择楼上已经说了，显存要够大才能跑大模型。

如果你在生产机器之外需要一个开发验证平台，现在 4060 移动版的笔记本非常合适。相对台式显卡溢价低，8GB 对于验证程序来说够用了。关键是 40 系的能效比很高，而且价格非常卷。

NO

Chromebook 最大的优势是它内置了 Android 系统，同时有着非常长的官方支持。

至于 Linux 的硬件选择，同价格的笔记本选择要多得多。

“接收端做不到有能力处理重复消息或保证消息幂等”

换个表述方式，意思是不是

"接收端只接收，不响应"？

很多工控系统是这样设计的，设计的时候就没有“协议”这个概念，接收端“无脑”执行所有指令，默认输入信令永远正确且实时。（因为它可能就是一台单独的设备，从来没考虑过远程控制）

即使有响应，也不代表能正确处理“重复”指令。很多“响应”的意思是收到指令而已，并不代表指令的执行结果。（因为这类工控系统的指令执行结果是肉眼可见的）

建议用 wireshark/tcpdump 这种先看一眼，看看走了哪些流量，是不是 udp 协议的。

对于 tcp 来说，抓不到一般是两个方向，一个是非 http/https 这种，另一个是流量没走代理。

一端是 Ai 帮人写简历润色，一端是 Ai 帮人自动打分，突出一个赛博朋克。

反正对抗都上强度了，应该很快就能迭代到人机验证码水平，想想都觉得酸爽。

咸鱼上的秒解锁挺离谱的，连账号都不用登录，新机器激活完就能直接解了。

不过客户这边看不到是怎么做的，就是通过一个软件把本地 usb 挂载到商家的机器上了，大概率是售后渠道才能这么干。

Linux/Windows/macOS 上都有软件实现 QMK/via 的方案。原理都是在内核/驱动层拦截设备输入事件，根据用户规则重映射后再传递给对应的窗口管理器。甚至可以做到重映射 Win+L 这样硬编码的按键组合，和类似 AHK 可以判断输入焦点所在应用来切换配置的功能。

Linux 上早期基于 x11 的改键方案可以全淘汰了，基于 evdev/uinput 的方案可以提供对 wayland 的支持。相关的开源项目很多，比如 hawck/kbct/keyd 等等。

Windows 和 macOS 涉及到加载（未签名）内核驱动的问题，相关实现会比较少。Windows 可以考虑 interception+capsicain 组合，macOS 似乎 Karabiner 比较成熟。

看到 130kb 我的第一反应是 128KiB 或者 131072 字节，有少部分平台是 128000/124928 这样，大概率是某个参数限制了 128KiB 。

如果你是用 wireshark 之类抓包的话，TCP WINDOW FULL 有可能是 false positive 的误报。Wireshark 的判断逻辑是，收方那边说我的 TCP Window 是 xxx ，然后发方开始发送，这中间如果没有收方的 ACK 的话，发送超过 xxx 之后，wireshark 会认为 TCP WINDOW FULL 。换句话说，你的 TCP 底层实现没有特殊处理的话，是无法在发送方真正发送超过 xxx 的。

加上你说抓包发现前端能够正确发包，那说明是后端的限制而非 TCP 层面的。

我估计应该是 netty websocket 某个与 frame size 相关的参数限制了 128KiB ，另外还应该有个 message 层面的限制。

防破解确实是个成本收益的问题，但是你如果认为 hook 就能拦住 99% 那就太理想化了。由于逆向工具的进步，学习 hook 的门槛非常低。你有正向开发的能力，半个小时学习一下 frida 甚至脚本都不用自己写，就能绕过绝大部分不设防的应用。

从知己知彼的角度上说，还是要了解逆向是怎么做的。精力放在抵御那些高度自动化的逆向方案上。

静态方面，一般防御手段是混淆和加壳。混淆可以某种程度上避免反编译后你自己的程序逻辑被分析，但是涉及到的系统 api 调用是不好藏的，所以聊胜于无。加壳对于大部分开发者来说门槛过高，选择加壳的时候，顺便搜一下对应的脱壳工具，大致上可以防技术不过硬的选手了。

动态方面，核心思路是将关键代码 native 化。同时 native 接口要采用互操作的形式，否则很容易被当作黑盒来直接调用。通常 hook native 只有在 onEnter/onLeave 环节能做一些记录入参，修改返回值的操作，所以拆解 native 逻辑避开这种利用方式也能防住很大一部分。

另外就是所有你认为的“检测”结果都不可信，这个事情哲学上就是你不可能判断自己是不是生活在虚拟世界是一个意思。相关的检测还是可以做的，但这种检测必然依赖 api 和特征，在 hook 环境中都可能是假象。检测到了随机插入假结果给逆向的人带来迷惑，远比粗暴禁用等手段有意义。这也是多数大厂的做法，用风控替代对抗。

抓包层面，大部分人都说了，除非你像 fb 一样自己实现 tls 库，不然都有自动化的解决方案。另外 ecapture 还是 hook 方案，知道的人少，被检测的几率小。如果项目合适，可以考虑用 protobuf 之类替代 http 。

我不确定你说的是具体哪个型号，如果没猜错的话，应该是纯平的 34WK95U 。微星有一款用了同样面板的 PS341WU 。其他的带鱼屏都是曲面。这两款我都有，LG/MSI 这两款的区别是 LG 内置一个 tb3 hub ，微星那款没有，所以微星稍微便宜一点。微星那边可以支持 PBP 拆四个 1920x1080 ，LG 只能拆两个。做工支架方面微星略好于 LG 。

以剪视频的需求来说，垂直分辨率在 2160 是有质变的。原因是只有超过 2160 才能在一个屏幕上 100%
缩放显示视频以及软件的 ui 界面。

以写代码的需求来说，3840->5120 也是有质变的。一般来说，目前的 4k 多数时间要配合缩放使用，所以写代码常见的左右分屏场景，1920 再缩放一下，实际上水平宽度经常不够用。

如果是带鱼替代双屏，体验会很好。物理方面视觉中心是一块屏幕，没有边框分割也没有色差，还更省空间。软件方面不涉及多屏易用性也好很多。如果是三屏的话，带鱼屏的优势反倒不明显了。

楼主的问题可以参考 https://github.com/linux-surface/linux-surface 里面有 surface 各硬件的内核驱动支持，SGO2 算是比较完善的，选一个方便切换内核的发行版就可以了。考虑到硬件平台比较久远了，桌面平台使用 xfce 这种轻量型体验会比较好，硬核一点可以 i3/sway 来自定义。

因为你这个做法很不常见，我猜测可能是 XY 问题导致的偏差，所以特地去看了你的使用场景。

这里我引用一下"为什么要搞 IP 保护"的描述："暴露的端口会被探测"，看到这里我就理解你的需求了。

本质上你是在保护自己的 IP 资产，而不是客户，客户只是租用而已。因为你以虚拟机的形式为客户交付服务，并不能控制客户在虚拟机上的行为，比如客户可以在在这个公网 IP 上开放公开的 http/socks 服务等等。

怎么向客户描述这个问题不重要，但是你的思路被带偏了，甚至说你的整体产品架构思路都被带偏了。当然这只是我个人的想法，可能理解有偏差。

如果我来设计的话，向客户交付的部分其实是 B ，而 A 是由自己完全控制的，A 是 B 的路由器。技术层面，B 本身就是云服务，利用 VPC 保证 B 的所有出站流量都一定由 A 路由就可以了。

这样做的附加好处是，所有 A 节点都可以用低成本标准化的网络设备完成，无需托管真实主机，至于 B 完全可以利用云服务来提供定制。

直接说结论：

如果 A 的防火墙是类似于 `iptables -t nat -A PREROUTING -s 2.2.2.2 -j ACCEPT` 的形式，那就无法通过 NAT 的形式做端口映射。

做全端口映射的原理就是楼上说的 DMZ ，转换成 iptables 规则就是 B 作为 A 的网关，对出流量做 SNAT ，对入流量做 DNAT 。

但是 A 的防火墙规则限制了来源只能是 B ，那 B 要对入流量同时做 SNAT ，修改其来源 IP 为 B 2.2.2.2 ，这就导致 A 认为请求来源都是 B ，回复的 DstIP 都是 B 2.2.2.2 ，因而无法正常返回数据。

解决的办法是：

1. B 以反向代理（ reverse proxy ）的形式工作，这样 A 可以保留防火墙规则。但反向代理对于协议有限制，tcp/http 类可以，udp 很难。

2. A/B 各自增加一个网络接口，两个接口之间建立某种点对点链路，然后走 NAT 映射

直接说结论：如果 A 的防火墙

OP 发了不少帖子了，一直想证明前端利用 wasm 做混淆很难破解。这个结论本身没问题，你要逆向 wasm 的内部逻辑就要走汇编调试那一套。只靠单纯的前端技术应付不了，但是在做逆向的人眼里，没什么区别。

这里大部分回复的都是在说，wasm/js 的交互机制决定了，多数时间把 wasm 当黑盒，用 RPC 方式调用就好了。没有必要去理会内部实现。

这里讨论的隐藏前提是用混淆手段防机器人的，基于加密参数限制非 web 客户端对于后端 api 的调用。

然后 OP 提出，这个加密逻辑全生命流程只能执行一次。说实话我想象不到这样的代码的应用场景，特别是防机器人的方面。（比较接近的是类似微信读书，原始 html 用 canvas 重渲染然后删掉原始数据）

对于 RPC 调用的应对，OP 认为可以在 wasm 内部做针对外部环境的检测。这一点我从根本上就不认同。

因为从根本上，客户端就不是可信的运行环境。别说浏览器了，手机 app 为什么都要做 root 越狱检测，都是一样的道理。这是个技术之外的哲学问题，你能判断自己是不是生活在虚拟世界里吗？

至于实践方面，我是比较赞同 @tool2d 的，基于虚拟机的混淆，模糊掉控制流和调用逻辑，给逆向的人造成的烦躁感远比 wasm 大多了。

而且虚拟机类型的混淆是可以高度自动化的，你可以每天都变换生成参数和算法。然而逆向虚拟机类混淆是没有什么自动化手段的。

做得挺好的啊。

请问 http3/quic 抓包路线图计划吗？这个功能虽然和 http 1/2 列在一起，但完全没法复用已有的功能框架，而且实现这个功能需要程序外做很多工作。

因为我自己前两个月就在写 quic mitm 的 poc ，还是非常麻烦的，而且现在 quic 各个实现之间 interop 还不是很理想。如果 op 这边能做个商业成品就最好了。

@hsuehliuyang 这和有没有自信没关系啊。

前段混淆无非就是防君子、小人和机器人。第一个网站的业务，显然不是防君子防机器人，防小人也用不着，因为没有一点东西是自己的。

但是你看它用伪造的 png 头假装图片跑视频流，然后用某站的缓存漏洞托管自己的播放列表文件，这种手段水平，想加个 js 混淆太容易了。

它真想藏的大概不是 url 而是流量。

@hsuehliuyang 这和有没有自信没关系啊。

前段混淆无非就是防君子、小人和机器人。第一个网站的业务，显然不是防君子防机器人

RPC 对于没有混淆的代码来说很好用。


@hsuehliuyang 过 debugger 方法太多了，浏览器内的话方法重载、条件断点、源文件 overrride 都行。浏览器之外的话，重编译一个修改了 js 引擎 debugger 方法的版本。