Home on virusdefender's blog ʕ•ᴥ•ʔ

ESA 切换到 EdgeOne

Sat, 25 Jul 2026 00:00:01 +0000

本博客是一个纯静态网站，随便找个静态网站托管服务就能跑起来。不过为了自己用着舒心，前几年我一直把静态文件放在阿里云 OSS 上，再通过阿里云 CDN 对外提供访问。这套方案一直很稳定，加上博客平时也没什么访问量，每个月的费用最多也就几块钱。

阿里云 CDN 的计费方案简单来说就是流量费用 + HTTPS 请求数费用，流量费用对于普通用户来说从中国地区的 0.24/GB 到中东非洲区域的 1.31/GB 不等， HTTPS 请求是 0.05/万次，但是每个月有 500 万次免费。

24 年 7 月份，我突然收到了阿里云的欠费提醒，看了一下账单，才发现 CDN 产生了 105 GB 的下行流量，扣了 30 多块钱。这个流量对普通网站也许不算多，但本站的访问量一直没有什么变化，显然不是正常的。通过日志查了一下 IP，才发现是 PCDN 刷量。

PCDN 用户为了平衡上下行流量，防止被运营商发现，进行了大规模的刷量行为，这个事情网上已经有很多讨论了，可以看下 https://github.com/unclemcz/ban-pcdn-ip 和里面的相关链接。PCDN 数量都是请求大文件，所以整体请求数量不是很多，不到 100 万次，所以这次没有产生 HTTPS 请求数费用。

26 年 6 月份，突然发现阿里云又欠费了，接着查日志，发现有一些非洲的 IP 在持续的使用简单的 GET 请求访问不存在的地址，总请求数量 1000 多万，导致 HTTPS 请求数直接超了免费额度 500 多万次，又被扣了 30 多块钱。。。还好 404 页面比较小，流量费用很少，这要是访问大文件再加上非洲地区 1.31/GB 的流量费，估计我就直接注销阿里云账号跑路了。

经历这两次异常账单之后，我觉得继续使用按量付费的 CDN 还是有些不太可控，于是把网站迁到了阿里云的 ESA 网站加速服务。为了省事，这时的源站仍然是 OSS。ESA 免费版目前不收取流量费和 HTTPS 请求数费用，因此日常使用基本只会产生 ESA 回源时的 OSS 出方向流量费用。

POCSAG 协议考古 - SX1276 Packet Mode 实现

Tue, 26 May 2026 00:00:01 +0000

上一篇文章讨论了硬件选型，最终选择了基于 Ebyte E32 开发板（SX1276 + STM32F103C8T6）的方案。这一篇来聊聊软件实现——如何用最简单的方式接收 POCSAG 信号。

现有开源实现：Direct Mode 的"全手动挡"路线

GitHub 上能找到的几个 POCSAG/LBJ 接收项目，不约而同地选择了同一条路：SX1276 的 Direct Mode（直接模式，也叫 Continuous Mode）。要理解 Packet Mode 为什么更好，首先得看清楚 Direct Mode 到底在做什么。

SX1276 的 Continuous Mode 硬件配置

以 SX1276_Receive_LBJ 为例，它的底层是 RadioLib 的 SX127x 驱动。首先看 SX127x::directMode() 如何配置芯片：

 1int16_t SX127x::directMode() {
 2 setMode(RADIOLIB_SX127X_STANDBY);
 3
 4 // DIO1 → DCLK (连续数据时钟输出), DIO2 → DATA (连续解调数据输出)
 5 SPIsetRegValue(REG_DIO_MAPPING_1,
 6 RADIOLIB_SX127X_DIO1_CONT_DCLK | RADIOLIB_SX127X_DIO2_CONT_DATA, 5, 2);
 7
 8 // 不需要等 preamble 或 RSSI 触发，直接开始接收
 9 setAFCAGCTrigger(RADIOLIB_SX127X_RX_TRIGGER_NONE);
10
11 // 切换到 Continuous Mode（PACKET_CONFIG_2 bit 6 = 1）
12 return SPIsetRegValue(REG_PACKET_CONFIG_2,
13 RADIOLIB_SX127X_DATA_MODE_CONTINUOUS, 6, 6);
14}

三个关键操作：

POCSAG 协议考古 - 硬件实现

Sun, 10 May 2026 00:00:01 +0000

上一篇文章梳理了 POCSAG 的协议格式，这一篇来看看硬件的实际选型。POCSAG 是运行在 2-FSK 调制之上的应用层协议，硬件层面只需要两个核心能力：一个支持 FSK 调制解调的射频前端，一个能跑协议解析的 MCU。看上去选择很多，但真要做的时候，射频芯片的寄存器配置、FSK 极性的匹配、频率稳定度、开发门槛都是坑。

好在 GitHub 上有几个开源项目，各走了一条路，拿来当硬件选型的参考很合适。

硬件选型

Warning

无线电设备的研发必须严格遵守相关法律法规：禁止在非民用频段进行信号发射；严禁违规接收非授权频段信号；严禁将非公开的信号与数据上传至互联网。

	MCU	射频前端	板卡方案	简介
GoRail_Pager	STM32F103C8T6	TI CC1101	自己画 PCB	纯 FSK 芯片；外挂 ESP8266 走 MQTT。
SX1276_Receive_LBJ	ESP32	SX1276	现成开发板	TTGO LoRa 32 v1.6.1，约 18 美元到手即用。SX1276 支持 LoRa/FSK 双模。
RP2040-Based	RP2040	SX1276	自己画 PCB	同样基于 SX1276，MCU 换成树莓派 RP2040，有完整的 PCB 和外壳文件。

TTGO LoRa 32 价格不算低，但完全不用 DIY——一块板子到手即用，代码现成，不需要画 PCB。缺点是板子形态固定，体积、功耗、接口都没法自己调整。

自己画板的灵活度最高：通过嘉立创免费打板和淘宝采购芯片，成本应该会低于现成开发板，而且可以根据需求自由调整 PCB 尺寸、外设取舍等。代价是需要一定的 PCB 设计知识，尤其是射频走线部分——阻抗匹配、接地设计这些还是有一定的难度。如果要提高灵敏度再加入温度补偿晶振或者放大器等，就会更加复杂。对于我这种小白不太友好。

POCSAG 协议考古 - 协议基本格式

Fri, 01 May 2026 00:00:01 +0000

在智能手机普及之前，有一个时代的移动通信是靠 BP 机（Pager/寻呼机）撑起来的。POCSAG 就是那个时代最成功的寻呼协议之一。虽然 BP 机早已淡出大众视野，但 POCSAG 在今天并没有完全消失——一些医院的老式内部呼叫系统、工厂的报警通知、铁路列车接近预警（800MHz 机车电台 LBJ）等场景中，仍然能看到它的身影。

今天让我们翻开这份来自上世纪的技术文档，看看它是如何在极其有限的带宽和功耗约束下，设计出一套完整的一对多消息广播系统的。

什么是 POCSAG

POCSAG 全称是 Post Office Code Standardization Advisory Group（邮政总局编码标准化咨询组），由当时掌管全英电信的英国邮政总局制定。它是一种无线数据传输的协议，用于向"寻呼机"（Pager）单向发送消息。

POCSAG 定义了三种标准数据速率：512 bps、1200 bps、2400 bps。512 bps 的通信距离最远，而 1200 和 2400 bps 允许每秒传的寻呼消息数量更多。

物理层：调制方式

POCSAG 采用 Frequency Shift Keying（FSK，频移键控）调制。FSK 是一种数字调制技术，用载波频率的变化来表示数字信号——不同的频率对应不同的 bit 值，接收端通过检测频率来判断发过来的是 0 还是 1。

具体到 POCSAG：在射频载波上使用 ±4500Hz 的频偏，高频代表数字 0，低频代表数字 1。同一个传输频道上可以混合不同速率的数据块。

CAP Code：寻呼机的"身份证"

CAP Code（Channel Access Protocol code，频道接入协议码）是每台寻呼机独一无二的地址标识，总共 21 位，这意味着一个频道理论上可以分配 2097152 个不同的地址。

这 21 位实际上被拆成了两部分：

字段	位数	位置
地址位（Address bits）	18 bit	高位（MSB）
帧位置位（Frame location bits）	3 bit	低位（LSB）

拆出 3 个帧位置位的设计非常精巧——它允许寻呼机只在"属于自己"的那几帧时间里打开接收器，其他帧时间直接断电休眠，显著延长电池寿命。后文会详细展开。

体验 LetsEncrypt 的短期证书

Thu, 27 Nov 2025 00:00:01 +0000

在今年 2 月份的时候，LetsEncrypt 就发布了一篇文章称要推出六天的短期证书，而目前 LetsEncrypt 的默认证书还是 90 天的。

为何要使用有效期更短的证书呢，这个主要有两个重要的原因：

证书吊销机制不可靠

证书吊销一直是依赖 OCSP 或 CRL 机制，但是都需要是客户端主动的去检查，否则对证书有效性没有任何的影响。

CRL（证书吊销列表）

CA 定期生成一个签名的列表，其中包含所有已被吊销但尚未过期的证书序列号。客户端在验证证书时，会下载这个列表，并检查目标证书的序列号是否在其中。如果在，则说明该证书已被吊销，不应信任。

缺点包括

体积大：随着吊销证书增多，CRL 文件会变得很大，影响性能。
存在时效性问题：两次更新之间的窗口期内吊销的证书无法被及时发现。

OCSP（在线证书状态协议）

客户端向 CA 指定的 OCSP 响应服务器发送一个查询请求，包含目标证书的序列号等信息，OCSP 服务器实时返回该证书的状态。

缺点包括

每次查询都会暴露用户正在访问哪个网站
依赖网络和服务器可用性：如果 OCSP 服务器宕机或响应慢，可能导致连接延迟甚至失败。某些客户端可能会忽略 OCSP 错误继续连接。

其改进版为 OCSP Stapling，即服务器主动从 CA 获取 OCSP 响应，并在 TLS 握手时一并发送给客户端。避免了客户端直接连接 OCSP 服务器，提升性能和隐私。

短期证书的主要优势在于，它们能显著缩短潜在的风险暴露时间，因为这类证书会相对较快地过期。这降低了对证书吊销机制的依赖。因为上述吊销机制一直不够可靠，所以短期证书将不包含 CRL 或者 OCSP 的配置信息。

此外，短期证书实际上要求必须实现自动化管理，实现证书签发的自动化也对于安全性至关重要。

支持 IP 证书

虽然说 IP 和域名的 SSL 的验证和签发本质都是一样的，但是过去只有少数几家 CA 小规模提供此类服务。

IP 证书很少见最重要的原因是 IP 地址的所有权的变动比域名频繁多了，比如你在某个云厂商创建了一个新的虚拟机，分配了一个 IP 地址，在释放虚拟机的时候，如果你同时选择了释放 IP 的话，这个 IP 可能随时就被其他人所占用。这时候已经签发的长期有效的 IP 地址的证书可能就存在安全隐患了，而使用短期证书即可以匹配 IP 生命周期也可能比较短的场景。