26 篇
1 个三级分类
三级分类
技术笔记整理
技术体系化整理、工程实践与开发笔记。
专题分组
二级专题与三级分类
39 篇
2 个三级分类
19 篇
3 个三级分类
42 篇
2 个三级分类
12 篇
2 个三级分类
26 篇
3 个三级分类
1 篇
1 个三级分类
三级分类
当前页继续展示这个根分类下的全部文章；上面的二级专题和三级分类用于快速定位更细的主题入口。
Python 开发19 分钟
AES算法与接口解密
这篇笔记围绕 AES 对称加密的基础机制和接口响应解密实践展开，先说明 AES 以 128 位分组处理数据，密钥可为 128、192、256 位，并强调加解密使用同一密钥。内容对 ECB、CBC、CFB、OFB、CTR 等模式做了区分：ECB 不需要 IV 但相同明文块会产生相同密文，CBC 等模式依赖初始化向量来提升随机性，其中 CBC 会让每个块与前一块密文形成链式关系。实践部分先用 Python 和 pycryptodome 演示 ECB 解密流程，包括 Base64 解码、创建 AES.MODE_ECB 解密器、解密字节数据以及按 PKCS7 规则去除填充。随后以接口返回的 data 与 secret 为线索，通过 Chrome 全局搜索前端代码，定位到调用 Ie(e.data, e.secret) 后再 parseJson 的解密逻辑，并继续分析该函数实际使用 CryptoJS 的 AES-CBC、Pkcs7 padding 和 window.TurboApply.data.aesIv 作为 IV。文章还给出 Python 复现 AES-CBC 解密的代码结构，明确需要把 secret 和 iv 转为 UTF-8 字节、对密文做 Base64 解码、再调用 AES.new(key, AES.MODE_CBC, iv) 并 unpad。最后提醒固定 IV 会削弱 CBC 的安全性，容易造成相同明文产生可比较的密文模式；更合理的实现是每次加密生成随机且唯一的 16 字节 IV，并随密文一起传输，适合想理解接口加密分析、AES 模式差异和解密复现流程的开发者阅读。
爬虫
22 分钟
Nginx 配置
这份笔记围绕 Ubuntu 环境下的 Nginx 日常部署与配置展开，先梳理它作为 Web 服务器、反向代理、负载均衡、内容缓存和邮件代理的常见用途，并说明 Nginx 主要工作在应用层，而 NAT 属于网络层的地址映射机制。安装部分记录了 apt 安装、systemctl 查看状态、whereis 定位程序，以及 /etc/nginx、/etc/nginx/sites-available、/var/log/nginx、/var/www/html 等关键目录，适合用于快速确认服务文件和配置入口。配置解释部分重点说明 user、worker_processes、error_log、pid、events、worker_connections、http、MIME 类型和 log_format 等指令的作用，并提醒生产环境中让 worker 进程以 root 运行会带来较高安全风险。样例 nginx.conf 展示了多个 server 块的组合用法，包括 HTTP 到 HTTPS 的 301 跳转、不同域名反向代理到本地端口、静态目录 alias、媒体文件匹配、Gzip 压缩、代理头传递、关闭缓冲、超时设置和 client_max_body_size 限制。证书部分给出从下载证书、合并 crt、重命名私钥、检查并移除 UTF-8 BOM，到放入 /etc/nginx/ssl、调整属主与 chmod 600 权限的操作链路。整体更像一份部署备忘录，适合后端开发或运维在配置 HTTPS 站点、代理本地应用、排查连接数和日志问题时对照使用。
15 分钟
精品网络-介绍
围绕“精品网络”的技术含义，内容先用 BGP 和自治系统解释互联网跨网络互联的基本逻辑：运营商、云厂商和数据中心通过 ASN 宣告 IP 段、选择出口、配置多线接入与 Peering，从而影响用户访问路径。文章以阿里云 AS45102、腾讯云 AS132203 接入三大运营商为例，说明云厂商并不是简单租用带宽，而是作为独立 AS 参与三网互联和智能选路。随后梳理精品网络从企业专线走向 VPS、IDC、游戏加速和节点服务的背景，并归纳其优势，包括绕开拥堵公网、降低延迟和丢包、提供 QoS 保障以及改善国际出口。运营商部分分别说明电信 CN2 GT/GIA、联通 AS9929 与移动 CMI 的定位、常见 ASN、与普通公网在线路优化、稳定性、拥塞风险和价格上的差异。最后给出 mtr 测试命令、目标地址和路径样例，提示可借助 59.43.x.x 等路由特征初步判断 CN2 GIA 类线路质量。适合准备购买 VPS 或 IDC 服务、评估跨境访问体验、排查三网回程路径的网络学习者和运维人员建立基础判断框架。
15 分钟
gRPC 使用
这篇笔记以一个只有 Predict 方法的 MyService 为例，串起 gRPC 与 Protocol Buffers 的基本使用路径：先在 .proto 文件中定义 package、service、rpc 方法以及 PredictRequest、PredictResponse 消息，再通过 protoc 生成 Python 侧的数据模型和 RPC 桩代码。内容区分了 my_service_pb2.py 与 my_service_pb2_grpc.py 的职责，前者承载 message、enum 对应的序列化与反序列化类型，后者提供服务端基类、注册函数和客户端 Stub，用来连接业务实现与远程调用。服务端部分展示了继承 MyServiceServicer、实现 Predict、使用线程池创建 grpc.server、注册服务并监听 50051 端口的完整流程，同时解释了生成文件中 DescriptorPool、AddSerializedFile 和 BuildTopDescriptorsAndMessages 动态注册消息类的现象，说明为什么 IDE 可能找不到定义但运行时可正常使用。客户端部分则说明如何通过 insecure_channel 建立连接、创建 MyServiceStub、构造 PredictRequest 并像调用本地方法一样执行远程 Predict，同时提醒未加密通道更适合本地测试，生产环境应考虑 TLS。文章还补充了 Go 客户端通过 protoc 插件生成代码、Dial 连接、创建客户端并带超时上下文调用服务的写法，用来体现一份 IDL 支撑跨语言调用的价值。最后将 gRPC 与 tRPC、HSF、SOFA RPC 等框架放在同一类实现思路下理解：先定义接口协议，再生成存根，服务端实现接口，客户端调用 Stub，底层负责序列化、网络传输与错误处理，适合刚开始学习 RPC、后端服务通信或跨语言接口开发的读者建立整体框架。
11 分钟
gRPC 相关介绍
这篇笔记围绕 gRPC 的组成和使用方式建立整体认知，核心说明它并不是重新发明底层网络协议，而是在 HTTP/2 之上结合 Protobuf 形成的高性能 RPC 规范。内容先拆解 HTTP/2 相比 HTTP/1.1 的差异，包括二进制帧、多路复用、HPACK 头部压缩、流式传输和更少的连接开销，并补充 Nginx 作为反向代理时可能只在客户端侧提供 HTTP/2、后端仍走 HTTP/1.1 的现实边界，以及 Uvicorn、Hypercorn 对 HTTP/2 支持的区别。随后解释 Protobuf 的定位：通过 .proto 预先定义消息结构和服务接口，将字段名替换为字段编号等紧凑二进制表示，从而在体积和序列化速度上区别于 JSON，同时也说明它与 gzip 这类通用压缩算法不是同一层面的优化。实践部分使用 grpcurl 连接 grpcb.in:9000 公开服务，演示安装工具、以 plaintext 明文方式列出服务、查看 grpcbin.GRPCBin 方法，并调用 Empty、DummyUnary 等接口。最后回到 gRPC 的本质：跨网络、跨语言调用远程服务，让 Go、Python、Java 等通过同一份 .proto 生成各自客户端和服务端代码，像调用本地函数一样传输 Protobuf 消息。适合正在理解微服务通信、RPC 框架、HTTP/2 部署边界或准备上手 gRPC 调试工具的后端开发者阅读。
11 分钟
"阿里云差点被‘劫持’？你必须懂的 DNS 知识
从 aliyuncs.com 注册状态异常导致部分地区解析失败切入，文章把一次看似“阿里云被劫持”的事件还原为域名过期、未及时续费引发的 DNS 异常，并指出其影响可能波及 OSS、CDN、SLB 以及依赖这些资源的第三方网站和 App。正文随后梳理 A、AAAA、NS、CNAME、MX、TXT 等常见 DNS 记录的职责，尤其强调 NS 决定“谁负责解析”，A 记录决定“解析到哪个 IPv4 地址”，CNAME 常用于别名、CDN 和第三方平台接入。通过简化的域名访问链路，读者可以理解浏览器从查询上级 DNS、定位权威 NS，到获得最终 IP 并建立连接的基本过程。后半部分区分 DNS 污染与注册商层面的域名解析劫持：前者是伪造或干扰 DNS 响应，把用户导向错误地址；后者则可能通过篡改 NS 夺走整个域名的解析控制权。文章列出 dig、whois 等基础排查方式，并给出加密 DNS、可信公共 DNS、VPN、Hosts、DNSSEC、域名锁定、MFA、WHOIS 隐私保护和 NS 监控等防护手段。它适合希望补齐 DNS 基础、理解云服务域名风险、排查解析异常的开发者、运维和安全入门读者。
15 分钟
CDN 是什么？
这篇笔记面向刚接触网站加速和对象存储的开发者，解释 CDN 作为内容分发网络如何把 HTML、JS、CSS、图片、视频等静态资源缓存到靠近用户的边缘节点，从而减少跨区域访问延迟、降低源站压力，并在节点故障或大流量场景下提升可用性与抗压能力。正文先用“用户请求资源、节点检查缓存、命中直接返回、未命中回源并缓存”的流程说明 CDN 的基本工作机制，再列出网站加速、App 安装包分发、直播流媒体、电商秒杀和可缓存 GET 接口等典型使用场景。随后通过 jsDelivr、腾讯云 CDN 和 Cloudflare R2 的响应头示例，拆解 cache-control、age、x-cache、x-served-by、x-cache-lookup、cf-cache-status、cf-ray、accept-ranges 等字段，帮助读者判断缓存策略、命中状态、多级节点路径、边缘节点位置以及是否支持断点续传。文章也区分了对象存储与 CDN 的职责：COS、OSS 或 R2 负责保存源数据，CDN 负责分发、缓存和加速，其中 R2 还天然接入 Cloudflare 的全球边缘网络，可通过自定义域名、Worker 或缓存规则进一步优化访问。最后落到业务系统设计，建议数据库保存原始资源路径，由后端接口、序列化器或 DTO 统一拼接 CDN 地址返回给前端，避免把源站链接、展示链接和网关响应改写耦合在一起。
3 分钟
点击劫持-介绍
这篇笔记围绕点击劫持的基本原理和防护响应头展开，适合正在为 Web 应用补齐基础安全配置的后端或全栈开发者阅读。文中用银行转账页面被攻击者通过透明 iframe 嵌入恶意页面的例子，说明用户可能在不知情的情况下点击到真实站点上的操作入口，从而触发非预期行为。防护重点放在两个响应头：X-Frame-Options: DENY 用于直接禁止页面被任何站点以 frame 或 iframe 方式嵌入，SAMEORIGIN 则允许同源嵌入，而 ALLOW-FROM 已不适合依赖现代浏览器支持。另一种方式是使用 CSP 中的 frame-ancestors 'none'，它同样用于限制页面作为祖先框架中的子页面出现，并且比传统 X-Frame-Options 更现代、可扩展。文章最后给出 FastAPI 中间件写法，在每次响应返回前统一添加 X-Frame-Options、Content-Security-Policy、X-Content-Type-Options 和 Referrer-Policy，分别覆盖点击劫持、iframe 限制、MIME 嗅探和 referrer 泄露等基础风险。整体价值在于把点击劫持的攻击场景与可落地的安全头配置连接起来，可作为 FastAPI 项目的最小安全响应头参考。
9 分钟
跨站请求-介绍
跨站请求指浏览器在访问一个站点时向另一个站点发起请求，安全风险集中在浏览器会自动为目标站点携带已有 Cookie，从而让恶意页面可能借隐藏表单、图片或请求触发用户已登录站点的敏感操作。文章用网银转账示例说明 CSRF 的基本链路，同时区分了它与 CORS 的边界：CORS 主要由服务端通过 Access-Control-Allow-Origin 控制跨域资源读取，而同源策略仍会阻止 A 站脚本直接访问 B 站 Cookie。内容进一步解释“允许所有 Cookie”并不等于站点间可以互读 Cookie，它更多涉及第三方 Cookie、iframe、图片或脚本加载时浏览器是否允许目标域存取自己的 Cookie。防护部分围绕 CSRF Token、SameSite、Referer 检查和 POST 身份验证展开，重点说明 SameSite=Strict、Lax、None 对跨站请求携带 Cookie 的不同约束。对于传统 Cookie 登录，Strict 或 Lax 能降低 CSRF 风险；但前后端分离且依赖 Cookie 登录时，可能需要 SameSite=None; Secure，而使用 Authorization Header 或 JWT 的方案则基本不受 SameSite 影响。最后补充 secure=True 或 https_only=True 的含义：浏览器只会在 HTTPS 请求中发送该 Cookie，这能减少中间人窃听风险，但会影响本地 HTTP 测试环境和登录态调试。
10 分钟
CORS与OPTIONS请求
这篇笔记聚焦浏览器跨域访问中的 CORS 判断与 OPTIONS 预检机制，核心澄清“跨域失败”并不是后端主动拦截响应，而是浏览器在安全策略下根据响应头决定是否把结果交给前端 JS。内容从 Access-Control-Allow-Origin 的作用讲起，说明后端必须在响应中明确允许来源，否则即使接口返回 200 或 404，浏览器也会阻止脚本读取内容。对于带 Authorization、自定义 Header、application/json 或 PUT、PATCH、DELETE 等复杂请求，浏览器会先发送 OPTIONS 预检，并通过 Origin、Access-Control-Request-Method、Access-Control-Request-Headers 询问后端是否允许后续真实请求。文章重点记录了 FastAPI CORSMiddleware 的排查细节：只有请求携带 Origin 头时，中间件才会识别并提前处理跨域 OPTIONS；如果 curl、Apifox 等工具模拟预检时漏掉 Origin，请求会落到路由层，未注册 OPTIONS 方法时就可能返回 405。相应的解决路径是用带 Origin 和 Access-Control-Request-Method 的请求复现浏览器行为，并检查 allow_origins、allow_methods、allow_headers 等配置是否能返回 Access-Control-Allow-* 头。它适合后端开发、前端联调人员和接口排查人员，用来区分浏览器 CORS 拦截、后端路由 405、以及测试工具模拟不完整这几类容易混淆的问题。