手动 tcp 发包的方法也太扯淡了……没实践过就别瞎说。

这种行为本质上和 Slowloris 攻击没区别，当服务器都是傻子呢。

既然是 Lua 可以嵌入到 C 里面？

对于你的这个目标，没有什么风控措施的，最理想的方案就是用上你最大的资源，短间隔高并发请求。

对于有风控和频率控制的目标，那就是个技术活了。

python 版本管理：asdf
https://asdf-vm.com/

虚拟环境：python venv

包管理：pdm
https://pdm-project.org/

纯靠猜的话，我感觉外层是去掉 +/ 的 base62 ，内层是 aes cbc 128bit 块。

userid 和 did 应该是两个等长字符串的拼接。即 userid/did 都是两段明文，分别 aes 加密然后 base62 编码，然后连接了两段编码后的字符串。

你要是能逆向的话可以试试看我猜得对不对。

@yang2yang #33

我不是专门做外包的，但是在疫情封城的时候高强度做过一段时间。那段时间是单人在做，后来回头客多了就根据兴趣和精力选择性做一些，其他的介绍给朋友做。

我在正文暗示过了，这个事情不能卷……外包需求最多的都是做网站做小程序这种，耗时耗力均价也不高，最大的问题是要花大量时间去争抢订单。但是你看我列举的例子，都是比较偏门或者专业的需求，这些订单多数都是各种原因转到我手上的。

另一方面就是这个帖子的由来，交付快自然就能做得多了。

@m1dsummer #30

我只了解非常有限的 .NET 的技术，跨平台 Mono 就在项目里尝试过一次，印象还不错。

以我个人的感受来说，微软家的技术路线切换太过于商业驱动了，虽然跨平台方面这两年进步很大，但市场和开发者的信心依旧不够。所以学习相关的技术属于投资有风险那一类。

@seers #28

在 Go 的生态里 Cgo 的意义非常重要。做个不那么恰当的类比，游戏行业 Unity/C#/Lua 生态很大程度上就是因为 Lua 和 C 互通能力。

还是回到我正文里提到的 OpenCV 的例子，在 CV 领域几乎没有完全的替代。不得不用的情况下，除非用 C++ 开发，其他语言想要使用 OpenCV 都要有相应的 bindings 。

开发这种 bindings 本身就是很复杂的事情，这里 Cgo 的优势就显现出来了。简单的项目不用写 bindings 就可以直接用，复杂的项目通过 Cgo 可以高度自动化 bindings 的生成过程。

某种程度上可以认为，C 生态完全可以为 Go 所用。正文里提到过，Go 欠缺的恰恰就是这一类的轮子。

@jackmod #25

实时性要求高的场景，无 GC 永远都比有 GC 优秀。对于 GC 来说，最难处理的情形要么是碎片化分配，要么是海量引用。我的贴子里提到的技巧主要是解决前者，后者是很难在代码层面上有所改善的，也是 Go 原理上做不到的。

还是那句话，技术栈该换就换。

~~虽然 discord 技术博客写得很好，但是软件体验仍旧是一坨……~~

@GeekGao #19

确实是这个意思，Go 的性价比很高。另外 cNk 这个说法我感觉好多年没见过了，N=1 的时候算是个硬件问题，N=10 的时候算是技术问题，N=100 大概更接近于工程问题了。

我在正文没有提到 Go 带来的另一个好处，主要原因是这个体验比较主观。我确实认为 Go 的项目很有利于长期维护。

最明显的一点是，即使我现在回看两年前的项目，不管文档、注释写得如何，几乎很快都能回顾起来。看 GitHub 的开源项目也有同感，几乎都能非常快地定位到关键代码。

核心原因应该是得益于 Go 的两个优秀设计，一个是 `share by communicating` 的 concurrency 模型，另一个是 `accepting interfaces, return structs` 的解耦机制。

在 Go 之前，想要轻松写出正确的多线程代码是非常困难的事情，想轻松写出扩展性强的代码也需要有深厚的功底。

@mainjzb #16

Windows API 难用某种程度上说是微软故意的。我没做过特别专业的 Windows 开发，这是我个人的推测。

@root71370 #12

对于去掉符号表、字符串混淆之后的 go 二进制，基本只能硬怼汇编，参考对应版本 runtime 的实现来逆向。不是专门做这个的，可能连 main 入口都找不到。基本上黑产都喜欢拿 go 过免杀。

常规没有防逆向措施的 go 二进制就和 c 逆向差不多。

@sadfQED2 #11

文章里逆向那段主要是想表达一个意思：防破解本质上是个投入产出比的事情。Go 加上十分钟就能学会的小技巧，只需要几行代码和一点点自动化工具，足以为价值几万元的业务提供防御。

我给这个十分钟小技巧，其实包含了动态、静态、控制流和混淆多个层面的防护手段。强度差不多等同于各类动态语言的 vmp 水平。

对于绝大多数开发者来说，如果不是有丰富的对抗经验，是很难写出来真正有效的防破解逻辑的。从专业逆向者的角度上说，过高的门槛本就拦住了绝大部分人，甚至轮不到考虑投入产出比的事情。

如果这个请求不是特定的，指定 upstream 代理。如果是特定的，再写 python 脚本过滤一下。

我觉得这个事情的思路有点跑偏了，Linux 内核网络栈的抽象还是比较难的。

首先“端口”是个协议层面的概念，假如 tcp 只有二元组（源 IP ，目标 IP ）局限就太大了。

所以内核网络栈不会对“端口”做抽象的，因为没有必要。有必要的是对四元组（源 IP ，源端口，目标 IP ，目标端口）做抽象，这个完整的四元组可以唯一确定一个 tcp 连接。这个抽象在 Linux 里就是 socket 。

因此内核里也就不会有端口号的映射关系，如果你去看 netstat/ss 的代码，我猜测都是曲线救国。

由于网络栈是内核实现，为了方便用户态的程序使用，就通过 socketfs 抽象成一般 fd ，这样应用程序只需要确定 socket fd 就能直接在连接层面上完成网络功能了。

前面铺垫这么多，就是为了引出结论，你这个问题的本质是“如何确定 socket fd 和 pid 的映射关系”。

问题在于 fd 这个东西是可以复制或者转移的，于是最终还要回到 /proc/*/fd/* 去遍历才能确认。


PS

“限制进程可绑定端口”的标准操作是 ACL 机制，selinux 比较方便。自己造这个轮子非常不理智。

@nullcache #3

“webview 依赖的问题”说起来比较复杂，我觉得 webview 是个很好的技术，“问题”只是在于合不合适。

笼统地说，浏览器套壳方案的缺点在于性能和打包。性能就是渲染延迟，瓶颈在于 JS 引擎，很难优化到原生水平，所以几乎所有的 webview 应用用户体感迟滞都比较明显。具体到 wails 它在 Windows 上的渲染后端是 WebView2 ，轻微改善了性能和打包问题，但非常有限。

具体到需求，webview 方案会有一些不适合的场景。

一个是它不适合开发 Immediate 模式的 GUI 应用，比如需要实时按帧渲染的游戏。二是它不适合开发重度依赖系统 API 的平台应用（理论上所有的原生 API 都能调用，但是写那个 COM 接口实在是太恶心了）。

反过来，如果这个需求不在乎打包体积，不关注用户体验，也不属于前面说的场景，而你的技术栈恰好又是 Go 和前端，那 wails 其实是非常好的选择。

这种情况我更喜欢的方案其实是用 Svelte 糊一个 SPA 出来，然后用 Go 写服务端和业务逻辑。

@nullcache #1

wails 也是很好的方案。我觉得用不用取决于两点，一看否有意愿去学习，二看能不能接受 webview 作为依赖。

逆向神器，牛逼

Go 几乎是对跨平台协作最友好的了，实际应用里几乎只需要注意 `CRLF` 这一个问题就好了，正常的 git 工作流当中甚至都不会有感知。

说起来大家可能不信，我很早就在 Linux 平台用 Go 开发 Win32/Cocoa GUI 应用，所用到的技术无非就是 CGO 交叉编译。