Jacin Blog

计算机知识

分类下的全部文章

计算机知识
3 分钟

Github Action 官方托管 与自托管区别

这篇笔记围绕 GitHub Actions 的官方托管 Runner 与 Self-hosted Runner 做取舍说明，重点回答默认机器规格、是否自动扩容、计费方式和运行环境差异。官方 Linux 标准 Runner 通常是 2 vCPU、7GB 内存、14GB SSD，Windows 标准环境也接近 2C7G，macOS 规格相对更高；这些资源不会随构建负载动态增加，任务内存不足时会失败，只有手动选择并付费配置 Larger Runners 才能提升规格。Self-hosted Runner 不消耗 GitHub Actions 每月分钟数，即使长期运行也不会在 GitHub 侧产生分钟账单，但服务器、网络和维护成本需要自行承担。对比部分指出，官方 Runner 每次任务结束后销毁虚拟机，环境纯净、维护成本低，更适合公开仓库；自托管环境持久，能保留 Docker 镜像、node_modules 等本地缓存，构建速度可能明显提升。代价是需要自己安装和维护 Docker、Git、系统环境，并定期清理磁盘，否则容易被缓存和镜像占满。安全边界尤其关键：公开仓库不应随意使用自托管 Runner，因为恶意 PR 可以修改执行脚本并控制服务器；而在内网集成测试、访问私有资源或需要自定义并发能力的场景，自托管才更有优势。

RTMP协议
计算机知识
13 分钟

RTMP协议

这篇内容围绕 RTMP 协议在直播与流媒体链路中的作用展开，先说明它是 Adobe/Macromedia 设计的实时消息传输协议，运行在应用层并通常依赖 TCP 1935 端口提供可靠传输。文章把 RTMP 的使用价值放在直播场景中解释：推流端如 OBS 或推流 SDK 将音视频送入 SRS、Nginx-RTMP、Wowza 等服务器，服务器再面向观众侧转成 HTTP-FLV、HLS 或 WebRTC 等更适合播放和互动的协议。正文重点梳理了完整连接流程，从 TCP 三次握手、C0/C1/C2 与 S0/S1/S2 的 RTMP 握手，到 connect 指定 app、stream key 和认证信息，再到 createStream 获取 stream_id，最后通过 publish 或 play 进入推流、拉流阶段。数据传输部分强调 RTMP 通过 Chunk 分块与消息机制持续传递音频帧、视频帧和 metadata，并借助持久连接实现低延迟、多路复用和音视频同步。文章也补充了 RTMP URL 结构、RTMPT、RTMPS、RTMPE 等变体，以及 macOS 下可用 VLC、Live Stream Player 配合测试流地址进行验证。需要注意的是，浏览器端已不再原生适合播放 RTMP，因为 Flash 已被淘汰；同时 RTMP session 与底层 TCP 连接绑定，正常断开需经历 deleteStream、close 和 TCP 释放，异常断开或服务器踢出则会清理相关 stream。整体适合想理解直播推拉流入口协议、服务器接入流程和连接生命周期的后端、音视频与运维开发者。

计算机知识
6 分钟

什么是Rosetta

这篇笔记围绕 Apple Silicon 上的 Rosetta 2 展开，说明它本质上是 Apple 提供的 Intel x86_64 到 ARM 的动态二进制翻译机制，用来让 M1/M2/M3 设备运行只提供 Intel 架构的应用、解释器或动态库。正文把“Rosetta 终端”和“x86 程序运行”拆开说明：右键 Terminal 或 iTerm 勾选“使用 Rosetta 打开”会让该终端下的进程偏向 x86_64 模式，但启动 x86 可执行程序时 Rosetta 也可以被系统自动触发。文章重点澄清了几个常见误判，uname -m 只能反映当前终端架构，而 platform.machine() 更接近当前 Python 解释器进程的架构；因此 ARM 终端中运行 x86 Conda/Python 并不矛盾。对于 rocketmq-client-cpp、librocketmq.dylib 等依赖 x86 动态库的场景，关键不是终端显示什么架构，而是解释器、动态库和相关依赖是否同为 x86_64，否则就会出现架构不一致问题。笔记还提醒 Homebrew 的安装来源会受运行模式影响，在 Rosetta 终端中执行 brew install 可能安装 x86_64 构建的包，后续与 arm64 环境混用时需要特别留意。整体适合在 Apple Silicon 上维护 Python、Conda、brew 依赖或排查旧版二进制兼容问题的开发者，用来判断什么时候必须开启 Rosetta 终端、什么时候只需保证进程与动态库架构一致。

计算机知识
30 分钟

邮件协议、签名与推送

围绕邮件客户端“整合邮箱”时到底发生了什么，内容先把 SMTP、POP3、IMAP、Webmail、MTA/MDA 的职责拆开：SMTP 负责发信和服务器中继，POP3/IMAP 负责取信与同步，浏览器里的 HTTPS 只是访问 Gmail、Outlook 等 Web UI 的界面层协议。笔记进一步说明 Spark、Apple Mail、Gmail App 等并不是被邮箱服务器直接“推送”邮件，而是依赖定时轮询、IMAP IDLE 长连接，或在移动端通过 APNs、FCM 等通知系统实现近实时提醒。发信可信度部分强调，邮件由谁配置的 SMTP 发出，DKIM、SPF、DMARC 和发信 IP 信誉就主要归谁控制；使用 Gmail SMTP 时，签名和背书来自 Gmail，自建或小服务商 SMTP 则更依赖 SPF、DKIM、PTR、Return-Path 等配置质量。文章还区分了客户端壳子与真正发信服务器的关系，说明 iCloud、Spark、Apple Mail、QQ/网易等整合外部邮箱时，本质都是调用 IMAP/SMTP，只是授权方式、专用密码和风控流程不同。隐私部分重点比较 Apple Mail 本地直连邮箱服务器、只借助 APNs 做状态通知的模式，与 Spark、Edison、Outlook 移动端等可能通过自家云端代收、缓存、分析邮件并转发推送的模式。适合想判断邮件送达率、签名归属、移动端推送延迟以及第三方邮件 App 隐私风险的开发者、运维人员和重度邮箱用户阅读。

计算机知识
1 分钟

关于“计算机知识”类别

“计算机知识”类别适合用于归档具有稳定主题边界的计算机相关内容，重点在于帮助读者按知识领域筛选文章，而不是简单提供一个宽泛标签。该类别的使用需要先说明设立理由：它服务于哪些问题、知识点或学习场景，以及这些内容为什么不宜散落在其他分类中。归类时应明确它与现有类别的差异，例如是否覆盖基础概念、系统原理、网络、硬件、软件使用或通用技术认知等范围，并避免与更具体的开发、运维、工具类栏目重复。类别说明还应给出纳入准则，帮助后续文章判断是否符合共同特征。对于维护者来说，这一类别的价值在于建立可持续的内容组织规则，同时也要定期评估其必要性：若内容过少、边界模糊或与其他分类高度重叠，就应考虑合并为子类别或调整定位。