HTTP on Tony老师的博客

将 Next.js 照片博客从 Vercel 迁移到腾讯云 Lighthouse 并持续优化

Sun, 22 Mar 2026 08:00:00 +0800

本文记录将基于 exif-photo-blog 的照片站点从 Vercel 全家桶迁移到腾讯云 Lighthouse 自托管的过程，以及迁移后围绕图片处理和回源协议做的两轮关键优化。整个过程借助 WorkBuddy（Claude Opus 4.6）和 OpenClaw（MiniMax-2.5）完成代码改造、脚本编写和问题排查。

HTTP/2 多路复用、帧结构与 HoL 阻塞

Wed, 15 Aug 2018 10:00:00 +0800

HTTP/2（RFC 7540，2015 年发布）解决了 HTTP/1.1 时代前端工程师无数痛点：多路复用替代串行请求、头部压缩、服务器推送。本文从二进制帧入手，逐步拆解 HTTP/2 的核心机制，并分析它的局限——TCP 层的 Head-of-Line 阻塞问题。

HTTP/1.1 的痛点

HTTP/1.1 默认每个连接只能处理一个请求-响应。这种串行模型导致：

浏览器只能并发开 6 个 TCP 连接（Chrome 默认），每个连接还得排队
想绕开必须用域名分片、雪碧图、CSS 合并、JS 合并
头部每次都重复传输（特别是 cookie），浪费带宽
没法主动推送资源，得等客户端解析 HTML 后再请求

HTTP/2 的设计目标正是消除这些工程上的丑陋 hack。

二进制分帧层

HTTP/2 最大的变化是引入了二进制分帧层（Binary Framing Layer），所有信息都用 Frame 传输：

graph LR
 subgraph Frame
 L[Length: 24 bits]
 T[Type: 8 bits]
 F[Flags: 8 bits]
 S[Stream ID: 31 bits]
 P[Payload: 可变长]
 end

 L --> T --> F --> S --> P

字段	大小	含义
Length	24 bits	Payload 长度
Type	8 bits	帧类型（DATA、HEADERS、PRIORITY 等）
Flags	8 bits	类型相关标志位
Stream Identifier	31 bits	流 ID（1 为奇数表示客户端发起的流）
Payload	可变	帧内容

关键的 10 种帧：

HTTPS TLS 1.2 握手过程与加密原理全解析

Thu, 10 May 2018 10:00:00 +0800

HTTPS = HTTP + TLS（早期叫 SSL）。TLS 在传输层之上、应用层之下，提供加密、完整性校验和身份认证三大能力。本文聚焦 TLS 1.2（当前仍为主流的版本），从密码学原语到完整握手逐步剖析。

三大密码学原语

TLS 用到三类基本工具：

对称加密（如 AES、ChaCha20）：加密实际传输的数据，速度快
非对称加密（如 RSA、ECDSA）：用于密钥交换和身份认证，效率低
哈希 + MAC（如 SHA-256、HMAC）：保证数据完整性，防止篡改

TLS 的精妙之处在于用非对称加密安全地协商出一个对称密钥，之后的通信都用对称加密完成——兼顾安全和性能。

TLS 1.2 完整握手流程

一个完整的 TLS 1.2 RSA 密钥交换握手需要 2-RTT（两次往返）：

sequenceDiagram
 participant C as Client
 participant S as Server

 C->>S: 1. ClientHello<br/>TLS 版本、随机数、加密套件列表
 S->>C: 2. ServerHello<br/>选定加密套件、随机数<br/>Certificate (服务器证书链)<br/>ServerHelloDone
 C->>S: 3. ClientKeyExchange<br/>用服务器公钥加密 Pre-Master Secret<br/>ChangeCipherSpec<br/>Finished (MAC 校验)
 S->>C: 4. ChangeCipherSpec<br/>Finished (MAC 校验)

 Note over C,S: 握手完成，后续用对称密钥加密通信

第一步：ClientHello

客户端发送：

登录安全：重放攻击与防御策略

Wed, 01 Feb 2017 04:59:01 +0800

现在的应用系统中，大部分密码存储都是采用 md5 加密后存储，常用的登录基本流程如下：

前端 web 页面用户输入账号、密码，点击登录
请求提交之前，web 端首先通过客户端脚本对密码原文进行 md5 加密
提交账号、md5 之后的密码
后端验证账号与密码是否与数据库中的一致

这种流程看似安全，但实际上存在重放攻击风险！

Nginx SSI 使用指南

Fri, 08 Apr 2016 12:47:34 +0800

这是最早期的 SSR 方式之一——服务端在返回 HTML 前完成页面组装，客户端直接拿到完整页面，而非空壳再客户端渲染。

相信很多人在浏览网页时都遇到过这样的情况：本地在开发环境运行正常的页面，部署到测试环境后却发现部分内容缺失。比如导航栏、页脚、公用组件等内容本地看不到。

如果你遇到这样的情况，先检查一下页面源码中是否有类似这样的代码：

<!--#include virtual="/new/ssi/script.html"-->

这就对了——这就是 SSI（Server Side Include）在起作用。本地没有配置 SSI，所以包含的内容没有渲染出来。

HTTP 协议演进：从 1.0 到 2.0 的工程意义

Sun, 20 Sep 2015 14:00:00 +0800

2015 年初，一个普通的网页大约包含 100+ 个 HTTP 请求（HTML、CSS、JS、图片、字体、统计、追踪）。用 HTTP/1.0 的浏览器加载完一个页面要等几十秒——不是带宽不够，是 TCP 连接来回握手、响应必须串行排队这两个看似无关的设计叠加起来，把延迟推到了用户能感知的阈值。

从 HTTP/1.0（RFC 1945，1996）到 HTTP/2（RFC 7540，2015），整个 20 年的演进史可以浓缩成三个工程问题：怎么减少 TCP 握手？怎么并行？怎么压缩重复的头？