稍微跑个题，既然变更历史那么重要，有没有考虑过用 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 机制扇出，分配个多个线程来解析。如果是单线程肯定会非常慢。

腾讯软件的 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 这段。假如你一个周对时一次的话，可能也不是多大个事。

我从来没有见过哪个安卓设备支持你说的功能，原因就是一楼指出的安卓平板不支持 RNDIS 输入。

原理层面就是两个设备之间通过 USB 建立以太网连接，而 USB 又是 Master/Slave 机制的，所以一套协议加上主从两套实现才能运作。

协议层面上，主流的是 Windows 的 RNDIS ，基本上所有操作系统都支持了。USB 自己有一套类似的，但是应用不太多。

RNDIS 的从端实现，几乎所有的安卓设备都支持。主端实现，基本只有桌面系统才支持，比如 Windows/Linux 。

Linux 的支持是通过 usbnet 这个内核模块完成的，理论上可以用于安卓。但是从来没有见过，要么是 Android 的内核砍掉了，要么就是单纯没有人做。

@Kinnikuman

如果是本地文件，缓存进度条可能和内存没有太大关系。

缓存的真实量取决于内核管理的 page cache ，假如剩余空间足够大，这个 page cache 会在第一次访问文件的时候把存储中的内容全部加载，不内存不足的话会加载一部分。在应用程序看来，fd 已经在了，stream 读取也开始了，就看你读多少。

这个 page cache 的容量主要影响拖动进度条，超出去了就会去读存储，没超的话，内核会有自己算法加载新的内容进有限的 page cache 里。

@swordsmile #1

Hyprland 目前还不支持 multi-seat 功能 https://github.com/hyprwm/Hyprland/issues/1731

这也是我一直主用 sway 的原因。其他方面 hyprland 易用性好太多了，不得已我还给 sway 写了个简陋的 master stack 布局管理器……

另外还有些 layer-shell 协议的应用（悬浮显示状态、通知和关机菜单这一类）也是硬编码了 seat0 的，有可能会导致显示位置或者输入焦点异常。对我影响比较大的是 tofi （一个 wofi 的改版）会有输入焦点问题。