这篇笔记梳理 Cloudflare 场景下几类容易混淆的 TLS 证书及其通信方向：边缘证书部署在 Cloudflare CDN 边缘节点，负责浏览器到 Cloudflare 的 HTTPS 入口；源站证书安装在自有服务器上，负责 Cloudflare 回源到 Origin Server 时的加密与校验。文章用“用户→边缘→源站”的链路解释了边缘层的含义，并指出边缘证书带来的低延迟握手、缓存可用性、HTTPS 强制、HSTS、WAF 与规则处理等收益。配置部分区分了 Flexible、Full 和 Full strict：Flexible 只保证用户到 Cloudflare 加密，Full 回源使用 HTTPS 但不验证证书，Full strict 则会验证源站证书，通常适合配合 Cloudflare Origin Certificate 使用。需要注意的是，Origin Certificate 不是公共 CA 签发，只被 Cloudflare 信任，适合回源链路，不适合让浏览器或公网客户端直接访问。文章还拆分了两类“客户端证书”场景：Authenticated Origin Pulls 是 Cloudflare 向源站出示证书，由源站验证请求确实来自 Cloudflare，以降低绕过 CDN 直打源站的风险；访问者侧 mTLS 则要求 API 客户端或受限用户向 Cloudflare 提供客户端证书，用于管理后台、内部 API 等访问控制。整体适合正在配置 Cloudflare SSL/TLS、回源 HTTPS、源站防护或 mTLS 的站点维护者与后端/运维人员，用来建立证书类型、验证主体和部署位置之间的清晰对应关系。

计算机网络

2025年12月6日5 分钟

BBR 算法介绍与开启

这篇笔记围绕在 Ubuntu 22/Linux 上启用 BBR 拥塞控制展开，先交代默认网络栈通常使用 CUBIC 作为 TCP 拥塞控制算法、pfifo_fast 作为队列调度器，再说明 BBR 是 Google 提出的基于瓶颈带宽和最小 RTT 建模的算法。它的核心差异在于不等到丢包或队列明显膨胀后才降速，而是通过 Startup、Drain、ProbeBW、ProbeRTT 四个阶段持续探测可用带宽、排空队列并重测最低时延。文章对比了 BBR 与 CUBIC/Reno 在拥塞判断、Bufferbloat、吞吐收敛、高负载时延抖动和多流共存上的表现，强调优势主要出现在长 RTT、高带宽或链路满载场景。它也提醒单独用空闲 ping 测 RTT 往往看不出差别，因为此时队列未被填满，真正的对比应结合 iperf3 大流量或 ping 搭配满载传输观察吞吐和延迟峰值。操作部分给出启用前提是 Linux 内核不低于 4.9，并通过写入 /etc/sysctl.d/99-bbr.conf 将 default_qdisc 改为 fq、tcp_congestion_control 改为 bbr。最后使用 sysctl、sysctl --system 和 lsmod 验证配置与模块状态，适合希望改善服务器跨地域传输、长距离链路吞吐和满载延迟表现的 Linux 运维或后端开发者参考。

计算机网络

2025年12月6日5 分钟

双ISP-介绍

双 ISP 指同一台服务器、网卡或网络环境同时接入两个不同互联网服务提供商的线路，例如电信 CN2 与移动 CMI，从而获得两个可用的上网出口。文章先解释 ISP 的含义，并用中国电信、中国移动、中国联通、教育网以及 Comcast、NTT、PCCW、Cogent 等例子说明运营商范围，再引出双线接入在家庭、工作环境和服务器场景中的应用。正文重点梳理了双 ISP 的价值：一条线路故障时可由另一条接管，流量可以按延迟、速度、用户运营商或目标地址进行分配，也可在代理、回国加速、流媒体解锁等场景中做分流和路由优化。它还区分了主备模式、双活负载均衡、智能策略分流、基于策略路由的出口选择，以及企业场景下通过 BGP 多线接入实现更优路由的形态。规划这类网络时，需要同时关注家宽与商宽、静态与动态公网 IP、运营商 AS Number 和 IP 信息查询等基础条件，因为这些因素会影响可用性、成本和路由策略设计。整体适合正在理解多线接入、双出口路由、家庭网络升级或服务器网络优化的读者，用来建立双 ISP 的概念框架和常见部署模式认知。

计算机网络

2025年12月6日1 分钟

关于“计算机网络”类别

“计算机网络”类别应被理解为站点中用于归档网络相关内容的分类说明页，重点在于界定分类用途，而不是展开某一项具体网络技术。它适合承载围绕网络概念、协议机制、连接与通信问题、网络工具使用、配置实践或排查记录等内容的文章，使读者能够在检索时快速判断这些笔记是否属于网络主题。该类别的边界需要通过与站点中其他既有类别进行区分来维持一致性，尤其是在内容同时涉及操作系统、后端开发、运维部署或安全主题时，应依据文章的核心问题是否落在网络通信层面来判断归属。分类说明还强调需要明确该类别通常包含哪些话题，以减少作者发布时的选择成本，并避免相近类别之间出现重复收纳。对于站点维护者而言，它的价值在于提供一套可执行的归档准则：说明为什么保留这一类别、何时使用它，以及在分类重叠时是否应考虑与其他类别或子类别合并。整体上，这类页面更像是知识库的信息架构规则，适合用于统一内容组织、提升搜索结果一致性，并帮助读者按主题发现计算机网络相关笔记。

常规

2025年12月6日1 分钟

关于-博主ME

这是一个用于了解博主技术背景与关注方向的个人介绍页，核心信息围绕其在 AI 科技公司担任 Python 后端开发工程师的工作经历展开。页面说明作者主要参与后端核心业务与 AI 业务模块的设计开发，技术栈覆盖 Python 异步编程、FastAPI、Django、Django Ninja 等 Web 框架，以及 PostgreSQL、Redis、消息队列、接口设计和数据库建模等后端工程能力。基础设施与交付侧则包括 Docker、CI/CD、Nginx 和 Linux 运维，反映出作者不仅关注业务代码实现，也具备一定的部署、运维和系统架构意识。在 AI 应用方向，作者提到会使用 Copilot、ChatGPT、Cursor 提升开发效率，并持续关注 OpenAI API、Prompt 工程、RAG 架构、工具调用、向量搜索、pgvector 与 GPT embedding 等实践主题。页面还补充了作者对 AIGC、系统设计、云原生和新框架的兴趣，以及通过博客记录和分享技术经验的个人倾向。对于希望判断博客内容取向的读者来说，这一页提供了清晰的作者画像：偏 Python 后端、工程实践和大模型应用落地，并附有邮箱作为直接联系方式。

开发工具

2025年12月6日1 分钟

apple自定义域名邮箱发送SMTP

这篇记录聚焦 Apple 自定义域名邮箱在第三方邮件客户端中的 SMTP 发信配置，而不是完整讲解 iCloud 邮箱或域名邮箱体系。核心建议是先将域名交由 Cloudflare 管理，因为使用 Cloudflare 的 NS 后，Apple 在配置自定义域名邮箱时可以跳转到 Cloudflare 并自动处理所需的 TXT、Mail 等 DNS 记录，降低手动填写记录带来的错误风险。完成域名侧配置后，用户需要在自己的邮件客户端中填写 Apple 提供的 SMTP 发送信息，用于让自定义域名邮箱能够正常对外发信。认证环节不能直接使用普通 Apple ID 密码，而应按照 Apple 官方说明生成“专用密码”，再把它作为客户端 SMTP 登录凭据。文中给出了 Apple 关于自定义电子邮件域名和专用密码的官方支持页面，方便读者核对配置入口与参数来源。它适合已经拥有域名、使用 Apple 邮箱服务，并且主要卡在客户端发信设置或密码认证方式上的用户参考。

开发工具

2025年12月6日2 分钟

cursor-vscode配置cpp环境

这份记录聚焦在 macOS 环境下为 Cursor 或 VS Code 搭建一个最小可用的 C++ 编写与运行环境，目标不是完整工程化配置，而是先让本地代码能跑起来并具备基础编辑辅助。操作从命令行安装编译器开始，使用 brew install gcc，并通过 gcc --version、which gcc 检查当前 gcc 命令的实际版本与路径；示例输出显示其指向 Apple clang，路径位于 /usr/bin/gcc，这一点有助于理解 macOS 上 gcc 命令可能并非 GNU GCC。编辑器侧安装 Code Runner 插件后，可以直接点击右上角运行按钮，用包含 cin 输入和 cout 输出的 Hello World 程序验证标准输入输出流程是否正常。随后补充安装 ms-vscode.cpptools，用于提供 C++ 代码跳转等语言辅助能力，使编辑体验不只停留在运行单文件代码。整体适合刚开始在 macOS 上使用 Cursor、VS Code 写 C++ 的读者，用来快速确认编译器、运行插件和跳转插件三件事是否到位；需要更复杂的多文件工程、调试配置或 CMake 集成时，还需要在此基础上继续扩展。

计算机知识

2025年12月6日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 终端、什么时候只需保证进程与动态库架构一致。

计算机知识

2025年12月6日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 隐私风险的开发者、运维人员和重度邮箱用户阅读。

计算机知识

2025年12月6日1 分钟

关于“计算机知识”类别

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

开发工具

2025年12月6日14 分钟

cloudfare+gmail 配置 smtp 邮箱

这篇笔记记录了一套个人域名邮箱的轻量方案：把域名 DNS 托管到 Cloudflare，用 Cloudflare Email Routing 负责收信转发，再借助 Gmail 的 SMTP 功能以自定义域名地址发信，从而避免自建邮件服务器。配置前需要先在 Namecheap 等注册商处把 NS 切换为 Cloudflare，因为 Cloudflare 只有接管权威 DNS 后，才能统一管理 MX、TXT、CNAME 等记录，并提供后续的 CDN、防护和证书能力。收信部分的关键是启用 Cloudflare 邮件路由，让系统自动写入 route1/route2/route3.mx.cloudflare.net 等 MX 记录，并在后台把 name@域名转发到 Gmail、QQ 等真实邮箱。文章特别强调邮件 DNS 记录不能混用：iCloud+、Google Workspace 或 Cloudflare 的 MX 入口只能保留一套，SPF、DKIM、DMARC 也不能随意叠加，否则可能导致验证失败、进入垃圾箱或退信。发信部分则在 Google 账户中生成应用专用密码，再到 Gmail 的“账号和导入”里添加其他发件地址，SMTP 服务器填写 smtp.gmail.com、端口 587、用户名为 Gmail 地址，并通过确认邮件完成验证。它还解释了一个容易混淆的点：MX 只决定收信入口，所以 dig MX 仍会看到 Cloudflare；真正发信走的是 Gmail SMTP，Cloudflare 不参与发信链路。适合已有个人域名、希望拥有多个自定义邮箱别名，并希望用免费或低维护方式完成收发配置的用户参考。

服务器与部署

2025年12月6日16 分钟

cloudfare配置内网穿透

这篇记录围绕 Cloudflare Tunnel 搭建内网穿透展开，适用于希望把本地 FastAPI、管理后台或前端开发服务通过自有域名暴露到公网、但没有公网 IP 或不想做路由器端口映射的场景。流程从域名接入 Cloudflare 开始：先在原域名服务商关闭 DNSSEC，再把 NS 修改为 Cloudflare 提供的 Name Servers，并可用 dnschecker 检查 NS 是否已切换成功，因为 Cloudflare 的域名验证主要依赖 NS 接管而不是添加 TXT 记录。正文随后记录 cloudflared 的安装验证、tunnel login 授权、创建 tunnel，以及通过 config.yml 的 ingress 把 api、admin、web 等不同 hostname 映射到 localhost 的不同端口。一个 tunnel 可以承载多个服务，但每个 hostname 仍需分别创建 DNS 路由，既可在控制台添加 CNAME，也可用 cloudflared tunnel route dns 自动生成指向 cfargotunnel.com 的记录。文章还说明接入 Cloudflare 后 Universal SSL 会自动为域名签发并续期 HTTPS 证书，通常无需手动管理证书。排障部分强调 DNS 和隧道生效可能存在延迟，QUIC 连接失败多与 UDP 7844 被阻断有关，可改用 HTTP/2；若访问出现 502，则常见原因是本地目标服务未启动。最后补充了长期运行方式：cloudflared tunnel run 只是前台进程，生产或长期访问应改用系统服务或 nohup，并在修改 config.yml 后重启 cloudflared 才能让新配置生效。

文章归档

183 篇