1. 不清楚你的使用场景，从不信任客户端的角度上说，单独在客户端做限速是可以被轻易绕过的。考虑一下变速齿轮，客户端获取到的系统时间是不可信的。

2. 看你的描述，应该是服务器出口流量分配的策略。比较 naive 的实现有可能在用户不饱和的时候难以有效利用带宽。

3. 限速模块尽量与主逻辑解耦，可以把限速委托给系统或者平台，比如 tc 配合防火墙，或者前置反代等等。主要是界定限速的目标是产品意义上的用户，还是软件意义上的客户端，限制来源可以有包级别，链接级别以及 session 级别等等。

4. 比较简单的限速策略容易在客户端和服务器端之间产生尖峰流量（锯齿状），不适合流媒体等场景。需要平滑速率曲线需要的不是限速（ throttling ）而是流量整形（ traffic shaping ）。

1. Pixel 设备的网络锁（ carrier lock ）的验证是通过 Google 服务器的。

2. 安卓设备本地记录这个状态是通过一个名为 get_unlock_ability 的标志位。这个标志位位于受 TEE 保护的存储区域。

3. 系统设置里的 oem unlocking 选项受前述标志位影响，标志位为 0 的时候 oem unlocking 就是灰色的。

4. 系统设置里的 oem unlocking 选项开启时执行的动作没有二次校验。

5. Pixel 软件里涉及 get_unblock_ability 的代码仅存在于 oobconfig 中（ oob 即 out-of-box ，一个初始化时运行的组件），只会从 0 写为 1 ，已经为 1 就不管了。

综合以上 1234 ，在不真正解锁网络锁的前提下，只需要系统级漏洞就可以解 oem unlocking 灰色锁。只要解锁一次，就再也不会变灰。基本上每个版本都有这么几个漏洞，这些漏洞离 root 差得远，但是把 ui 开关打开是够用了。


PS

咸鱼商家的软件就是 usb 重定向，与实际解锁过程无关。

咸鱼上大部分都是漏洞解，并没有解除网络锁，只是解了这个灰色锁。

特解某型号某运营商的一般是线下和上游走私商家合作，后门解锁，直接把解锁请求发到 Google 那边。这种线上基本见不到。

@ysmood #32

哈哈我一直在用你写的 rod ，非常棒！

@playboy0 #29

流量来源是分光设备，旁路直接进服务器的光口网卡。什么都不用配置，网卡开启 promiscuous 混杂模式抓包就行了。端口镜像应该一样的道理。


这个项目是挺久之前的了，某集团安全审计相关，要做全协议流量分析。内部接入比较复杂，有类似 PPPOE/PPP 之类的认证，VLAN 既有二层也有三层。所以直接从出口分光出来做的。

这个事情本身不是我负责的，我就是去救火的。因为这个事情后来又做了针对某些协议的 DPI ，这玩意后来对外好像卖了接近一千万……

原本有个 DPDK 的方案，是很早之前从别的地方采购的，没人能维护。配套服务器是双路 E5 ，核心倒是多，只是频率很低，系统又是 CentOS 7 。基本上就是抱着死马当活马医的想法，姑且用 Go 一试。

系统太老了不想维护，所以 PF_RING 指望不上，就拿 AF_PACKET 替代了，实际测试下来没啥问题。这个做到后面发现 AF_PACKET/MMAP 其实和 PF_RING 原理几乎一样的。如果现在做的话，可能都是用 AF_XDP 了，性能估计还能翻番。

当时还用的是 google/gopacket 而不是后来有人维护的 gopacket/gopacket 。不过影响不大，整个库的基础功能很完善了，除了当时没有的几个协议做了一下解析实现。


技术上这个只要懂原理的话没什么难度，内核里用 BPF 去抓包，MMAP 内存在内核和应用之间共享，AF_PACKET 设定好扇出，把网卡的数据写入 MMAP 的内存，用户空间的应用通过 ZeroCopy 方式读就可以了。核心部分代码可能没有一百行。

稍微跑个题，既然变更历史那么重要，有没有考虑过用 git 和文本文件做密码管理呢？

使用 git 你可以天然记录变更历史，同时可以任意 self host 或者利用各种公有设施实现分布式备份。

缺点是文本文件要加密。那就再套一层 gpg 加密好了，git 管理 gpg 加密后的文本文件。

剩下的事情就是写个 wrapper 把这个操作简化掉。

如果你认为这个思路合理的话，可以参考 pass - the standard unix password manager

https://www.passwordstore.org/

我已经用了十多年了，在各种平台都有开源可自编译的客户端或命令行工具。

@CC11001100 #2

盲猜一下，估计是那个认证服务器不在内网里，所以要给一段时间让你能够打开那个认证页面，2016 年那些系统还不成熟。

一般这种 captive portal 在出口处的防火墙默认阻止所有 ip 访问（非 mac ），通过认证的就让防火墙放行。然后一般为了减轻防火墙负担，已经建立的连接后续数据包就直接放行了。

反复 release/renew 让你的设备在系统看来是新设备加入，清空了之前防火墙记录，你的访问（ dns 请求，发起连接）能在系统预设的时间里发起，流量就能通过。

现在的系统基本上都是绑定到 mac ，比如星巴克用的，你可以跨店免认证接入。再就是认证服务器处于内网，通过旁路连接到中央计费后台。这样就没办法流量偷跑了。

厉害啊哈哈

@playboy0 #26

老 E5 单核 2G ，单个核心处理能力最高 100k pps 左右，包含业务逻辑。单纯解析时间中位数在 20us 左右。

由于整个内核 AF_PACKET 扇出数量和并发线程数是一致的，加上解析过程是 zerocopy ，几乎不会触发 gc ，内存占用没有印象了，应该非常稳定。

https://github.com/google/gopacket

我之前在 go 经验的帖子里写过，这个库配合一些手动内存管理的技巧，在 10Gbps 网络上做实时处理没什么问题。

如果是 pcap 离线文件，直接按照示例写就好了。

这个是不是考虑方向偏了？我觉得有必要明确区分 layout/session ，恢复 layout 是个容易的事情，但恢复 session 不是个很好的方向。

我个人的意见，session 很廉价，完全可以预先开很多 session （习惯通过 systemd service 管理），无论是 ssh 还是本地连接的时候直接 attach 到对应的 session 里面。

对于非重启环境，直接 detach 就可以了。对于重启环境，没想到要恢复 session 的应用场景。

@ChristopherY #18

用什么都可以，取决于你哪种语言比较熟练。C 版本的 libpcap 我没用过，考虑到是 tcpdump 在维护的，肯定是没问题的。Go 版本虽然两年没更新了，但协议这个东西又不会变……

另外我觉得你其实考虑复杂了，gopacket/libpcap 都是强在抓包，至于你是不是用它做解析不关键，用它做解析的原因就是它们把协议相关的数据结构都定义好了。

换个表达方式，你现在以字节形式读取到某个包（忽略到 pcap 文件格式解析），它一定是代表着某个多层嵌套的数据结构：

[ L1_Header : L1_Payload [ L2_Header : L2_Payload [ L3_Header : L3_Payload [ ... ] ] ]

然后假设 L1 是来自三层的，然后有 IP/ICMP/IGMP 几种协议，就拿 IP/ICMP/IGMP 的数据结构去套上面的字节流，匹配到就可以拆包了，L1_Payload 就是 [] 里面 L2/L3... 的内容，继续下一层解析就是了。

像 dpkt 这种数据不足，肯定是各种协议 Header 的数据结构定义不完善。scapy 我用过但是印象不深了，我估计慢的主要原因是它没法做到像 C/Go 这样可以手动分配内存，然后 one pass 把多层结构一次解析出来。但是 scapy 大概每次都要遍历匹配所有协议，来判断下一层是什么。

这个解析过程本质上和按照某个特定格式读取二进制文件没什么区别。

提高解析效率除了解析单个包层面的优化，主要是靠多线程。特别是实时抓包实时处理，靠内核 AF_PACKET 机制扇出，分配个多个线程来解析。如果是单线程肯定会非常慢。

AQC113 应该是 14nm 的吧，能效比好了非常多。Marvell 家早些年 28nm 节点的电模块，低负载起步就是 70 度。

这种芯片和模块的散热，正常有点风就不至于热死。但你要纯被动，没有个 1kg 的散热器当热容怕是扛不住。

很多设施水平一般的机房里，环境温度就接近 40 ，用 40 度的空气给 50 度的硬盘，70 度的模块和 90 度的处理器散热也没什么压力，关键就是风量要够。

腾讯软件的 Linux 版本都是应付事的，如果不是要适配国产系统，绝对不会主动开发。

X11 的设计逻辑里，任何应用不管在不在焦点，都可以读取针对其他任何应用的键盘输入。注册快捷键就变成了随便一个应用都去监听键盘输入事件，然后抢过来自己处理。

按照这个逻辑，我估计你用一个没有 input 组访问权限的用户去运行，就能避免它读取并绑定快捷键，但是程序本身可能会选择摆烂。我没有试过，只是提供一个思路。

本来想回复有可能是 headless 导致的，结果看到你已经找到答案了。

虽然 ssh 环境不能访问键盘鼠标显示器这些远程设备，但是 kmsgrab 这种访问 dri 还是可以的，包括很多 headless 环境访问显卡也是一个道理。

如果你需要在无头环境下或者远程主机无输出的环境下录屏，Gnome 新版本身支持创建虚拟显示器（主要是为 gnome 那个 rdp 实现服务的），让远程主机输出到这个虚拟显示器就可以了。

@Kinnikuman #10

这个场景我也没什么经验，结合 #9 #11 楼的引用随便说说。

1. 硬盘、内存速度

目前常见的硬件，即便是机械硬盘，其加载速度也远大于被加载视频的播放速度，更不用说内存了。

2. 硬盘文件的缓存机制

我在前面的回复里解释了一部分。再进一步说，你的应用不会直接读写硬盘，操作系统内核替你“智能”完成硬盘文件在内存中的缓存工作。

当然你也可以手动申请内存，然后读取硬盘文件内容之后保存在申请到的内存中，同时自己编写缓存内容更新的逻辑。这样做只适用于非常有限的场景，比如磁盘 IO 长期被后台应用占用，或者需要反复在多个超大（超过内存容量）文件之间切换。对于一个视频播放器而言，不需要考虑这些事情。

3. 缓存容量设定

我理解你设想中的方案都有一个隐式前提，视频文件非常大，需要尽可能多缓存。但是一般来说，除非你要提供“保存视频文件到本地以备无网络时观看”这个本质上名为“下载”功能，绝大多数时间只缓存一定量的数据即可。换个说法，下载功能可以是按需（ on-demand ）的，填满缓存容量就可以暂停。

也就是说，内存、硬盘的二级缓存机制是没有必要的。用内存缓存的唯一目的就是避免硬盘读写，硬盘缓存是解决内存缓存不够的才用的，一旦使用硬盘作为缓存就没必要再做内存缓存。

4. 缓存的内容取决于来源协议或者格式

根据上面的分析，本地文件技术上说是不需要缓存的，或者说不需要你手动缓存的。

网络视频有可能是以网盘作为后端，本质上还是特定格式视频文件的形式，也有可能是基于某种流媒体协议。对于前者，缓存的就是文件。对于后者，缓存的是视频流意义上的 packet （非网络意义的 packet ）。

5. 播放器本身不关心缓存后端的来源是什么，只关心从特定的来源流式读取。

比如桌面浏览器可以指定缓存后端是内存还是硬盘，但内嵌播放器是无需关心的。播放器这类本地应用，也只需要为数据流的消费者提供一个来源。即播放逻辑永远是固定的，至于来源（缓存）与播放行为是无关的。

6. 下载、解码和播放之间解耦

前面有人引用 mpv 处理缓存的逻辑，它缓存的对象是 packet 经过 demuxer 处理后的数据，即缓存发生于 demuxer 和 decoder 之间。前面 3/4/5 点综合起来说的也是这个意思，下载并不是直接对接播放的，缓存发生于中间解码的部分。不需要对下载和播放逻辑做特殊处理，所有的特殊行为都在中间解码阶段。

7. 缓存的底层数据结构

缓存确实可以用 FIFO 数据结构表达，考虑到播放器的使用场景，固定容量的缓存一定会遇到周期性完整替换的需求。

可以考虑 ring buffer ，这样就需要控制生产者写入速率与消费者播放速率一致。或者考虑 double buffering ，用手动切换缓存后端简化速率匹配。

还有楼上说得不对，网络包是一层一层嵌套的，必须从外向内解析。

当然理论上可以通过某层协议的标志从二进制的某个偏移开始解析，无视下层协议，但是这样做会损失很多信息，也不保证解析结果正确，与最初的目的不符。

gopacket 这个库是可以自己写未知协议扩展的，比如原版里面没有 pppoe/ppp 的支持，我在自己的项目里加上了，可能也就二三十行代码。就是写清楚字节流多少偏移对应该协议的某个字段。如果是那种非定长编码的格式，需要先解析头部的长度信息，再解析对应的字段。

https://github.com/google/gopacket

我之前在 go 经验的帖子里写过，这个库配合一些手动内存管理的技巧，在 10Gbps 网络上做实时处理没什么问题。

如果是 pcap 离线文件，直接按照示例写就好了。

游戏的核心逻辑肯定不会走 http 协议，大多数是在 tcp/udp 基础上自定义协议。最近这些年的游戏多数都会用 protobuf 类似协议来简化开发。

如果是比较小众的游戏私服，大概率是内部泄漏的，可能是服务端程序，也可能是代码文档。如果是比较火的游戏，才比较有可能是人力重建。

如果以逆向工程的方式来重建服务器端，主要是两个工作。一个是逆向客户端，提取客户端发包和收包的数据结构定义，然后实现一个协议兼容的服务器端。另一个就是重建游戏逻辑，这个事情比想象中简单，只是工作量巨大。

要是做过类似的正向开发，这个事情不难理解。具体到你的问题上，能逆向出协议定义的话（无论是静态解密还是动态追踪），抓到 tcp/udp 包就等于 http 抓到请求。

还限制使用区域，是怕卖二手吗哈哈，看来实在是太小众了。

“不需要听用 app 对时虐耳的噪音”，如果目标频率是 40/60 kHz 这个水平的话，估计是用高次谐波实现的吧。一般高频单元也就上到 20kHz 了，基频大概就是 15~20 kHz 这段。假如你一个周对时一次的话，可能也不是多大个事。