1 个三级分类
三级分类
技术体系化整理、工程实践与开发笔记。
专题分组
1 个三级分类
三级分类
2 个三级分类
3 个三级分类
2 个三级分类
2 个三级分类
3 个三级分类
1 个三级分类
三级分类
这篇笔记从 iOS 18.4 中出现的 5G-A 标识出发,解释 5G-Advanced 作为 3GPP Release 18 定义的 5G 演进标准,定位在现有 5G 与未来 6G 之间的过渡阶段。正文把 5G-A 的增强点概括为更高速率、更低时延、更高连接密度,以及引入 AI/ML 进行网络资源管理和优化,并提到 NTN 卫星与地面网络融合、XR、自动驾驶和工业自动化等新场景。文章进一步按应用场景展开,说明 5G-A 在智能制造的精密控制、车联网实时通信、8K VR/AR 和全息体验、智慧城市多设备协同、偏远地区覆盖等方向的潜在价值,同时强调很多应用仍处在试点或早期部署阶段。部署现状部分列举了北京四环内及行政副中心覆盖、杭州商用网络启动,以及上海、深圳、广州等城市的试点或预期推进情况,帮助读者理解手机显示 5G-A 与实际网络建设之间的关系。为便于对比,文章还补充了 5G 的 eMBB、URLLC、mMTC、毫米波、大规模 MIMO、小基站和网络切片等基础概念,并用表格区分 5G 与 5G-A 在速率、时延、能效、连接密度和成熟度上的差异。最后,针对 iPhone 信号满格但网速慢的问题,正文说明信号格主要反映 RSRP、SINR 等接收质量,不等同于网速,实际体验还会受到频段、网络拥堵、基站距离、遮挡和干扰路径影响,适合想快速理解 5G-A 标识、网络能力与现实体验差距的移动网络用户和技术学习者。
这篇笔记围绕个人开发者配置 HTTPS 时最容易混淆的 SSL 服务器证书、CA 根证书和中间证书展开,先从免费证书、低价单域名证书、通配符证书等常见选择切入,说明证书有效期、域名覆盖范围和续期维护成本的差异。正文重点强调申请证书时应在本地生成私钥和 CSR,只向 CA 或证书卖家提交 CSR,避免把私钥交给第三方;CSR 中包含公钥、主题信息和由私钥生成的签名,是 CA 签发最终证书的依据。文章用 HTTPS 握手流程解释浏览器如何接收服务器证书,并根据内置根证书库校验证书链、颁发者、有效期、撤销状态、签名完整性等信息,从而决定是否信任站点。实践部分给出 OpenSSL 生成 RSA 私钥与 CSR、查看 X.509 证书详情的命令,并结合证书输出字段说明 Issuer、Subject、SAN、Key Usage、OCSP、CRL 等信息的含义。Nginx 配置示例展示了服务器证书 crt 与私钥 key 在 443 ssl/http2 站点中的使用方式,帮助读者把证书申请、校验和部署串起来。最后通过表格和类比区分 SSL 证书是网站使用的服务器身份证明,CA 证书是上游权威的公钥凭证,中间证书负责连接服务器证书与浏览器内置根证书,适合正在为自有域名、反向代理或 CDN 服务配置 HTTPS 的开发者参考。
计算机网络这篇笔记围绕 HTTPS 请求的安全链路和连接复用机制展开,适合想把浏览器请求、抓包、TLS 握手和 HTTP 版本差异串起来理解的后端、运维与网络学习者。内容先说明 HTTPS 如何借助 SSL/TLS 完成证书验证、密钥交换和会话密钥生成,并用对称加密保护后续数据;同时区分 Charles、Fiddler 等代理抓包工具通过安装受信任证书进行中间人解密,和 Chrome 开发者工具查看浏览器已解密数据这两种完全不同的场景。随后梳理一次 POST 请求背后的 TCP 三次握手、TLS ClientHello/ServerHello、证书与 Pre-Master Secret 交换、通信结束时四次挥手等过程,指出新建连接会带来额外延迟,而 Session Resumption、TLS 0-RTT 与连接复用可减少重复握手成本。文章还对比 HTTP/1.1 与 HTTP/2:前者依赖 keep-alive、Host 头、分块传输和有限连接并发,仍可能出现应用层队头阻塞;后者通过帧、流、多路复用、HPACK、服务器推送和优先级控制提升传输效率,但仍受 TCP 丢包导致的底层队头阻塞影响。Nginx 配置示例展示了 TLS 版本、加密套件、http2、keepalive_timeout 与 keepalive_requests 的设置方式,并说明在 Nginx 代理 FastAPI/Uvicorn 时,客户端侧可使用 HTTP/2,而后端应用仍可能以 HTTP/1.1 通信。最后,笔记把连接复用放到浏览器、Python requests、Postman、curl、NAT 和 TLS 会话恢复的语境中解释,强调复用只发生在未关闭的连接或可恢复会话中,伪造 IP 与端口无法直接加入既有 TCP/TLS 连接。
计算机网络这篇笔记围绕 DNS 扩展机制 EDNS(0) 与 ECS 展开,先说明传统 DNS 受 UDP 512 字节和缺少扩展字段限制,EDNS 通过 OPT 伪资源记录承载更大的响应、DNSSEC 所需数据以及 Client Subnet 等选项。ECS 的作用是在递归 DNS 向权威 DNS 查询时附带客户端的部分 IP 前缀,使 CDN 不再只依据递归解析器所在地调度,而能按用户大致网段返回更合适的边缘节点。文章用 dig 的 +subnet 参数在阿里公共 DNS 上模拟不同来源网段查询 alibaba.com,对比 203.0.113.0/24 返回 203.119.* 地址、8.8.8.0/24 返回 47.246.* 地址,直观展示同一域名因 ECS 不同而得到完全不同解析结果。随后逐段解释 dig 输出中的 HEADER、OPT PSEUDOSECTION、udp 大小和 CLIENT-SUBNET 的两个前缀长度,帮助读者判断请求是否携带 ECS、服务器是否接受或截断了前缀。文中还整理了国内外公共 DNS 对 ECS 的支持差异,包括阿里、腾讯、百度、Google、Quad9、OpenDNS、Cloudflare、AdGuard、NextDNS 等,并指出 /24、/56 与 /32、/128 在调度精度和隐私暴露之间的取舍。适合需要理解 CDN 解析差异、跨地域访问异常、公共 DNS 行为以及 ECS 隐私影响的网络运维、后端开发和基础网络学习者阅读。
服务器与部署这篇笔记梳理 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 的站点维护者与后端/运维人员,用来建立证书类型、验证主体和部署位置之间的清晰对应关系。
这篇笔记围绕在 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 运维或后端开发者参考。
双 ISP 指同一台服务器、网卡或网络环境同时接入两个不同互联网服务提供商的线路,例如电信 CN2 与移动 CMI,从而获得两个可用的上网出口。文章先解释 ISP 的含义,并用中国电信、中国移动、中国联通、教育网以及 Comcast、NTT、PCCW、Cogent 等例子说明运营商范围,再引出双线接入在家庭、工作环境和服务器场景中的应用。正文重点梳理了双 ISP 的价值:一条线路故障时可由另一条接管,流量可以按延迟、速度、用户运营商或目标地址进行分配,也可在代理、回国加速、流媒体解锁等场景中做分流和路由优化。它还区分了主备模式、双活负载均衡、智能策略分流、基于策略路由的出口选择,以及企业场景下通过 BGP 多线接入实现更优路由的形态。规划这类网络时,需要同时关注家宽与商宽、静态与动态公网 IP、运营商 AS Number 和 IP 信息查询等基础条件,因为这些因素会影响可用性、成本和路由策略设计。整体适合正在理解多线接入、双出口路由、家庭网络升级或服务器网络优化的读者,用来建立双 ISP 的概念框架和常见部署模式认知。
“计算机网络”类别应被理解为站点中用于归档网络相关内容的分类说明页,重点在于界定分类用途,而不是展开某一项具体网络技术。它适合承载围绕网络概念、协议机制、连接与通信问题、网络工具使用、配置实践或排查记录等内容的文章,使读者能够在检索时快速判断这些笔记是否属于网络主题。该类别的边界需要通过与站点中其他既有类别进行区分来维持一致性,尤其是在内容同时涉及操作系统、后端开发、运维部署或安全主题时,应依据文章的核心问题是否落在网络通信层面来判断归属。分类说明还强调需要明确该类别通常包含哪些话题,以减少作者发布时的选择成本,并避免相近类别之间出现重复收纳。对于站点维护者而言,它的价值在于提供一套可执行的归档准则:说明为什么保留这一类别、何时使用它,以及在分类重叠时是否应考虑与其他类别或子类别合并。整体上,这类页面更像是知识库的信息架构规则,适合用于统一内容组织、提升搜索结果一致性,并帮助读者按主题发现计算机网络相关笔记。
常规这是一个用于了解博主技术背景与关注方向的个人介绍页,核心信息围绕其在 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 后端、工程实践和大模型应用落地,并附有邮箱作为直接联系方式。
开发工具这篇记录聚焦 Apple 自定义域名邮箱在第三方邮件客户端中的 SMTP 发信配置,而不是完整讲解 iCloud 邮箱或域名邮箱体系。核心建议是先将域名交由 Cloudflare 管理,因为使用 Cloudflare 的 NS 后,Apple 在配置自定义域名邮箱时可以跳转到 Cloudflare 并自动处理所需的 TXT、Mail 等 DNS 记录,降低手动填写记录带来的错误风险。完成域名侧配置后,用户需要在自己的邮件客户端中填写 Apple 提供的 SMTP 发送信息,用于让自定义域名邮箱能够正常对外发信。认证环节不能直接使用普通 Apple ID 密码,而应按照 Apple 官方说明生成“专用密码”,再把它作为客户端 SMTP 登录凭据。文中给出了 Apple 关于自定义电子邮件域名和专用密码的官方支持页面,方便读者核对配置入口与参数来源。它适合已经拥有域名、使用 Apple 邮箱服务,并且主要卡在客户端发信设置或密码认证方式上的用户参考。