🛡️ 用 UFW + CrowdSec，彻底阻止恶意端口扫描 副标题 / 摘要： 如何安全防护你的服务器暴露端口？本文带你从 Fail2ban 的正则地狱走出，构建一个稳定、自动化、智能化的端口扫描防御系统。 🎯 目标读者 使用 FRP / 内网穿透的开发者 管理云服务器（腾讯云、阿里云、AWS 等）的运维人员 想防御端口扫描、SSH 暴力破解的新手或中级 Linux 用户 对 Fail2ban 感兴趣、想升级到更现代安全体系的人 想完善服务器安全方案的个人开发者 💢 背景 / 动机：为什么需要端口扫描防护？ 在运行 FRP（frps + frpc）或开放多个端口时，你的服务器通常会遭遇： 海量扫描：每秒多次 SYN 探测 恶意连接尝试：get a user connection […] SSH 密码爆破 自动化脚本扫描 6001–6010、7000、22、8080 等常见端口 传统做法存在痛点： 防火墙（UFW）只能被动拒绝 Fail2ban 配置复杂、依赖正则、容易误判、不支持高级行为分析 FRPS 日志格式特殊，Fail2ban 很难匹配 攻击会占用 frps/sshd 资源，最终导致卡顿、断流 因此，我们需要一个无需写正则、能自动检测扫描、智能封禁恶意 IP 的现代防御体系。 📘 核心概念 FRP（frps / frpc）：用于内网穿透，常暴露大量 TCP 端口（如 6001–6010），容易被扫描。 UFW（Uncomplicated Firewall）：Ubuntu 默认防火墙，但缺乏智能检测功能。 Fail2ban：传统日志匹配型封禁工具，需要手写正则，踩坑概率高。 CrowdSec（推荐）：新一代开放式入侵防御系统 (IPS)，自动检测端口扫描和暴力破解，事件驱动 + 行为分析，资源消耗极低，是 Fail2ban 的现代替代。 🛠 实践指南：使用 CrowdSec 自动阻止端口扫描（Ubuntu/Debian） 1) 安装 CrowdSec curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash sudo apt install crowdsec -y 2) 安装防火墙封禁组件（iptables / ufw 自动配合） sudo apt install crowdsec-firewall-bouncer-iptables CrowdSec 会自动接管封禁动作。 ...

🛡️ WireGuard 全面指南：构建安全高速的私人内网（VPN 实战教程） 副标题 / 摘要： 本文是一篇适合初学者与中级用户的 WireGuard VPN 入门与实战指南。你将学会如何搭建高速、安全、现代化的内网，并实现“服务不暴露公网，只能通过 VPN 访问”的零信任式安全架构。 👤 目标读者 想用 VPN 隐藏自己服务器/电脑端口的人 想提高服务器安全性、避免被扫描的人 希望构建私人内网 / 远程访问家庭电脑的人 Linux / Windows / 开发者 / 运维初学者 🎯 背景与动机：为什么你需要 WireGuard？ 现代互联网环境下，一旦你的服务器开放端口到公网（SSH、数据库、后台服务），就会： 持续被扫描 遭遇密码爆破 被爬虫探测漏洞 面临潜在入侵风险 传统解决方案如 OpenVPN 虽然成熟，但复杂、速度慢、配置烦琐。 WireGuard 是为现代安全而生的 VPN： 小巧、安全、快，如同“下一代 VPN 协议” 代码量 < 4000 行（OpenVPN 是 40 万+） 极易配置 延迟低、带宽高 适合自建内网、服务器保护、远程办公 本文将教你如何用 WireGuard 构建一个完全隐藏在互联网上的私人内网。 🔑 核心概念 WireGuard 是什么？ WireGuard 是一种现代化、极简、安全的 VPN 协议，运行在 Linux 内核中，使用最先进的加密算法（ChaCha20、Curve25519 等）。 ...

让 FastAPI 异步真正“不卡”：asyncio.create_task + to_thread 并发实践（含 MySQL 写入） 副标题 / 摘要 把同步重活丢给线程、把可并行的子流程拆出来并发执行，让你的 FastAPI WebSocket/HTTP 服务在高并发文件处理场景下保持流畅与可靠。适合需要在事件循环中混合 CPU 计算与阻塞 I/O 的工程团队。 目标读者 中级后端工程师、服务端架构师 正在用 FastAPI/asyncio 落地异步工作流、混合 I/O/CPU 任务的开发者 背景 / 动机 常见痛点： 在异步服务里不小心执行了同步 CPU/数据库操作，单个请求“卡住”事件循环，导致同一 worker 上的其它请求/WebSocket 心跳/进度推送都被拖慢。 CPU/数据库步骤彼此本无强依赖，却被串行放到一条链上，整体时延被“关键路径”拖长。 目标： 不改变外部行为的前提下，消除事件循环阻塞。 让独立步骤并发执行，缩短关键路径。 核心概念 线程（Thread）：同一进程内共享内存，切换开销低；CPython 受 GIL 限制，纯 Python CPU 计算难并行，但适合并发等待阻塞 I/O。 进程（Process）：独立内存、无 GIL 约束，CPU 计算可多核并行；切换/通信成本更高，参数/结果需可序列化。 异步（async/await）：单线程事件循环的协作式调度；只有在 await 时让出控制权，同步阻塞会“卡死”循环。 asyncio.to_thread：把同步函数放到后台线程，释放事件循环；不等于多核加速，但对阻塞 I/O 有实效。 asyncio.create_task：并发启动一个协程，让它和当前协程重叠运行；用于编排并发，而非解除阻塞。 实践指南 / 步骤 识别阻塞点（示例项目） CPU 构树/展平/序列化：HeaderTree.from_documents、flatten_dfs、FlatHeaderTree.to_dict 同步 MySQL 写入：file_tree_table.upsert_tree 用 to_thread 包裹同步重活（释放事件循环） 在 build_file_tree 中，将 CPU/DB 步骤放入 await asyncio.to_thread(...)。 并发编排，缩短关键路径 在 full_pipeline_async：在 split 后立即 create_task(build_file_tree(...))，并发执行图片/表格处理、重组、存储；返回前再 await 构树结果。 可选：事件屏障与互斥 如需“保证某步骤不早于构树完成”，用 asyncio.Event。 多协程修改共享状态，用 asyncio.Lock 保护原子更新。 观测与参数 MySQL 连接池每进程默认较小（示例为 2），必要时调大。 Uvicorn workers 控制进程数，提升隔离与吞吐。 可运行示例 非阻塞构树与持久化（替换 build_file_tree 内部）： ...

现代加密替代方案：AES‑GCM 与 ChaCha20‑Poly1305 实战指南（附 Python 示例） 副标题 / 摘要 这篇延伸读聚焦现代 AEAD 算法，解释为什么 AES‑GCM 与 ChaCha20‑Poly1305 是 RC4 的安全替代，并提供可运行的 Python 示例、常见陷阱与最佳实践。 建议先阅读配套文章《用 Python 还原 RC4 + JWT + 自定义 SSO Token 加解密》，理解遗留方案，再迁移到本篇的现代实践。 目标读者 后端/安全工程师（中级以上） 需要在服务间或 Web 客户端安全传输数据的工程团队 计划从自研/过时算法迁移到现代 AEAD 的项目负责人 背景 / 动机 RC4 等过时算法存在结构性弱点，且难以正确、安全地使用。现代 AEAD（Authenticated Encryption with Associated Data）算法在保证“机密性”的同时还能“认证完整性”，有效防止篡改与重放，API 更易用，错误空间更小——因此成为主流推荐。 核心概念 AEAD：同时提供加密（Confidentiality）与认证（Integrity/Authenticity）的模式。 Nonce/IV（随机数）：每次加密必须唯一（对同一密钥）。常用长度：12 字节。 AAD（Associated Data）：不加密但要认证的额外上下文（例如请求头、资源标识）。 Tag（认证标签）：解密时必须验证；任何修改都会导致校验失败。 Key Derivation（密钥派生）：通过 HKDF/Argon2/Scrypt 将口令或主密钥派生为会话密钥，避免直接使用弱口令。 实践指南 / 步骤 安装依赖 pip install cryptography 生成或派生密钥 服务到服务：使用随机 16/32 字节密钥（AES‑128/256），KMS 管理与轮换。 口令到密钥：使用 HKDF（或 Argon2/Scrypt）派生固定长度密钥，避免直接使用口令。 选择算法 AES‑GCM：硬件加速广泛（x86 AES‑NI），在服务端通用、高性能。 ChaCha20‑Poly1305：对移动/无 AES 加速的设备更友好，性能稳定。 Nonce 策略 每条消息使用唯一 Nonce（12 字节），推荐 os.urandom(12)，将 Nonce 与密文一起存储/传输（前缀写入）。 AAD 的使用 将上下文信息（版本、用户ID、消息类型等）作为 AAD 提供，增强完整性绑定。 密钥轮换 引入 kid（Key ID），支持多活密钥与平滑迁移。 可运行示例 以下示例仅演示用法。请结合 KMS、密钥轮换、权限隔离与 TLS，构建完整的生产级方案。 ...

用 Python 还原 RC4 + JWT + 自定义 SSO Token 加解密（含可运行示例） 副标题 / 摘要 这篇文章带你从 0 拆解 RC4 流加密、Base64/Hex 编码，以及基于 JWT 与自定义 SSO 的鉴权设计，并给出可以复制运行的 Python 示例。示例中的密钥与发行方均为占位值，切勿用于生产。 目标读者 Python 后端/测试工程师（中级） 对鉴权、令牌与基础加密流程感兴趣的开发者 想理解 RC4 工作方式与替代方案的安全入门读者 背景 / 动机 在实际项目中，我们常需要为 HTTP 或 WebSocket 请求附带令牌进行身份校验。常见做法包括使用 JWT（对称/非对称签名）或自定义的 SSO Token（例如对某段明文进行对称加密后再以 Hex/Base64 编码）。本文整理并复现一种组合方案：RC4+Base64/Hex 与 JWT/SSO 的加解密与校验流程，帮助你在测试或 PoC 中快速上手，同时理解其安全取舍。 核心概念 RC4：经典流加密（已不再安全）。通过密钥调度（KSA）与伪随机序列（PRGA）生成密钥流，与明文字节按位异或得到密文。解密过程与加密一致（同一函数）。 Base64 与 Hex：两种将二进制数据编码为可传输文本的方式。Base64 更紧凑；Hex 可读、调试直观。 JWT：JSON Web Token。Header.Payload.Signature。常包含 iss（发行方）、aud（受众/自定义）、iat/exp（签发/过期）。 自定义 SSO Token：一种自定义明文格式（示例采用 issuer_expire_ts_userSeqId_userId），经对称加密后再编码为 Hex，便于在 HTTP 头中传输。 限制与风险：RC4 已过时且不建议用于生产；如需兼容遗留系统，应仅在测试/过渡场景，且搭配 TLS、短周期、签名与回放防护。 实践指南 / 步骤 安装依赖 pip install pyjwt 设定占位常量（不要使用真实密钥/发行方） ISSUER = "demo-issuer" SECRET = "demo-secret-change-me" RC4KEY = "demo-rc4-key-change-me" UTE_ISSUER = "ute-demo" 实现 RC4 与常用编码包装 encrypt_string/decrypt_string：RC4 后 Base64 encrypt_hex_string/decrypt_hex_string：RC4 后 Hex 构造与校验 JWT（x-auth-token） aud = [Base64(RC4(user_id)), Base64(RC4(user_seq_id))] iss/iat/exp 等标准字段 构造与校验 SSO Token（x-sso-token） 明文 UTE_ISSUER_expire_ts_userSeqId_userId → RC4 → Hex 校验发行方与过期时间 运行演示，观察生成与校验结果 可运行示例（完整代码） 仅用于学习与测试，切勿将 RC4 用于生产环境。请优先使用现代 AEAD（AES‑GCM/ChaCha20‑Poly1305）。 ...

一位与两位编码解析的刷题笔记与工程应用全解析（续集，LeetCode 717） 副标题 / 摘要 本文解析 LeetCode《1-bit and 2-bit Characters》题目，讲解如何用简单的指针跳跃算法解析二进制编码序列，并展示该算法在通信协议、数据格式解析、事件流处理等工程场景中的真实应用。适合希望将算法题知识迁移到工程系统的开发者。 目标读者 刷 LeetCode、准备技术面试的开发者 对通信协议、序列解析、数据流处理感兴趣的工程师 想提升“抽象能力与工程迁移能力”的同学 从事监控、序列分析、协议解析等工作的后端开发者 背景 / 动机：为什么这题值得写一篇博客？ 乍一看，这道题好像只是简单判断： 一个由 0/1 组成的编码流，最后一个 0 是否单独构成一个 1 位字符？ 但本质上它对应的是 “变长编码（Variable-Length Coding）解析”，而变长编码在工程中极其常见，比如： UTF-8 字符解析 网络包头编码解析 字节码指令流解析 数据压缩（如 Huffman Coding） 通信协议中的 Frame 解析 行为序列中用跳表式结构编码的事件 因此，这道题不仅是算法题，更是“从左向右解析变长编码的模型题”。 理解这题，就是理解大量系统底层的基础。 核心概念 1. 变长编码（Variable-Length Encoding） 题目中规定了两种编码： 1 位字符：0 2 位字符：10 或 11 这是一种简化的变长编码结构：字符长度取决于首位。 工程中常见： 系统 变长规则 UTF-8 1~4 字节，根据前缀位判断长度 TLV 协议 T + 长度字段决定 Value 长度 字节码流 opcode 决定后续参数个数 硬件指令集 有变长和固定长度两类 题目正是这些系统的「极简模型」。 ...

标题：用 Hugo + GitHub Pages 十分钟上线个人博客（超详细新手指南） 副标题 / 摘要 本教程带你从零开始，将本地 Hugo 博客部署到 GitHub Pages，全程只需 10 分钟，适合想快速上线技术博客、文档站点的开发者。确保你不仅能跑起来，还能理解背后的工作原理。 目标读者 Hugo 初学者 想快速上线个人技术博客的开发者 想了解 GitHub Pages + GitHub Actions 部署的用户 想要零成本托管静态网站的同学 背景 / 动机：为什么要用 Hugo + GitHub Pages？ 许多人写博客时面临这些痛点： 发布文章要手动上传，不自动化 静态站点生成器很多，但部署步骤零散 GitHub Pages 文档不够清晰，新手容易踩坑 主题（如 PaperMod）需要正确处理资源（SCSS）才能编译成功 Hugo + GitHub Pages + GitHub Actions 组合 完美解决了这些问题： Hugo 构建速度极快（上千文章依旧瞬间生成） GitHub Pages 完全免费，不需要服务器 GitHub Actions 自动部署，写完文章 push 即上线 核心概念（必须理解） 1. Hugo 一个超快的静态博客生成器，通过 Markdown 生成 HTML。 2. GitHub Pages GitHub 提供的免费静态网站托管。 ...

标题：如何使用 Hugo 发布文章：从 Markdown 到线上博客的全流程指南 副标题 / 摘要 这篇文章教你如何使用 Hugo 创建、管理与发布文章，包括 front matter 设置、草稿管理、图片处理、目录结构、预览与上线，让你从零掌握完整写作流程。 目标读者 Hugo 初学者 想用 Hugo 搭建技术博客的人 想学习 Markdown + 静态站点写作流程的开发者 使用 PaperMod、DoIt 等主题的用户 背景 / 动机 很多人在成功搭建 Hugo 博客后会遇到新的困惑： 文章应该放在哪个目录？ front matter 要怎么写？ 图片要放哪？ 为什么本地能看到文章但线上看不到？ 草稿 / 发布时间如何控制？ 怎样让文章自动出现在首页？ 这些都是 Hugo 新手非常常见的痛点。 本教程用实战步骤 + 最佳实践帮助你完全掌握“如何发布文章”的整个流程。 核心概念 1. Hugo Content（内容目录） Hugo 的文章都放在 content/ 目录下，比如： content/ posts/ my-first-post.md 2. Front Matter 文章头部的三段 YAML/TOML/JSON，用来控制文章： --- title: "文章标题" date: 2024-08-26 draft: false tags: ["hugo", "blog"] --- 3. Draft（草稿） 草稿不会被构建，只能在本地用 hugo server -D 查看。 ...

标题 用一段优雅的 Python 代码，把 SQLAlchemy 模型安全、高效地序列化成字典 副标题 / 摘要 SQLAlchemy 模型转字典（dict）看似简单，却暗藏字段格式、关系递归、循环引用等坑。本文通过一段实战代码，带你实现一个可复用的 _to_dict 序列化工具，并分析其设计取舍与改进方向，适合正在用 SQLAlchemy 写后端接口的你。 目标读者 这篇文章适合以下读者： 使用 SQLAlchemy 做 ORM 的后端开发者 想把 ORM 模型转换为 JSON/dict 的 Python 工程师 对 模型序列化规范化 有需求的中级开发者 使用 Flask/FastAPI/Django + SQLAlchemy 的同学 一、背景 / 动机：为什么要自己写 _to_dict？ 在 Web 开发中，我们几乎每天都要做一件事： 把数据库里的 ORM 对象，转成可以 JSON 响应给前端的数据结构（通常是 dict / list）。 乍一看好像只是 obj.__dict__ 或用个 asdict 就完事，但现实中的问题包括： 日期时间字段无法直接 JSON 化： datetime / date 对象不能直接 JSON 序列化，必须格式化成字符串。 关系字段怎么处理？ 一对多 / 多对多（uselist=True） 一对一 / 多对一（uselist=False） 避免递归爆炸： 两个模型互相关联，很容易序列化时陷入无限递归。 ...

标题（吸引且准确，包含关键词） 用 Issue 模板把需求写清楚：从 0 配置 GitHub Issue Template 的完整指南 副标题 / 摘要 这篇文章手把手教你在 GitHub 仓库中配置「新需求 / Feature」与「Bug」Issue 模板，包括目录结构、YAML 表单、Markdown 模板以及常见坑。适合想让团队需求沟通更规范、减少反复追问的开发者和团队负责人。 目标读者 这篇文章适合： 经常在 GitHub 仓库里开 Issue、提需求的 后端 / 前端 / 全栈工程师 想把团队需求提交流程「标准化」的 项目负责人 / TL / 架构师 对 GitHub 已经有基本使用经验、但还没用过 Issue 模板的 中级开发者 完全新手也能看懂，但会默认你知道：什么是仓库、什么是 Issue、如何提交代码等。 背景 / 动机：为什么要折腾 Issue 模板？ 没有 Issue 模板时，日常可能是这样的： “这个需求背景是什么？” “影响哪些模块？” “验收标准怎么算通过？” “优先级到底多高？” 一句话 Issue： “做个导出功能” 直接把所有人整破防。 长期下来会有几个痛点： 沟通成本高：每个需求都要反复追问细节； 信息不对称：请求人脑子里很清楚，但写在 Issue 里的只有一句话； 难以排期：没有明确优先级和验收标准，大家都觉得自己的需求是 P0； 历史难追踪：几个月后再看这个 Issue，完全不知道当时怎么想的。 而 GitHub 提供的 Issue Template，其实就是一套「结构化提问」工具： ...