调优ssl_buffer_size可显著降低弱网下TLS首包延迟，核心是让首个TLS record尽快发出以避开TCP延迟确认与Nagle算法；推荐设为1400字节匹配MSS，并须同步开启tcp_nodelay、TLSv1.3及OCSP Stapling。
调优 ssl_buffer_size 能显著降低弱网下 TLS 首包延迟，核心思路是让首个加密数据块（TLS record）尽快发出，避免被 TCP 层卡住或触发延迟确认。它不改变握手流程，但直接影响“握手完成→首字节发出”这一关键窗口。
为什么弱网下这个参数特别关键
弱网环境（高延迟、丢包、低带宽）会放大 TCP 层的固有行为：
- 延迟确认（Delayed ACK）：接收端默认等待 200ms 或等第二个包才回 ACK；若 Nginx 发出的第一个 TLS record 太大（如默认 4KB），可能因未填满缓冲区而迟迟不发，白白多等一个 ACK 周期
- Nagle 算法干扰：若未禁用，小数据会合并等待；而过大的 ssl_buffer_size 让首 record 变成“半包”，更容易被 Nagle 拦截
- 重传敏感性：首包若因分片失败或被中间设备丢弃，大 record 分片越多，重传成本越高；单段承载更可靠
推荐配置值与依据
目标不是最小化，而是匹配路径 MSS（通常 1400–1460 字节），确保加密后 record 能完整塞进一个 TCP 段：
- 1400 字节：最通用选择，适配标准以太网（MTU=1500 → IP+TCP头=40 → MSS=1460），留出 TLS 头和填充余量
- 1300 字节：适合经公网 LB 或 IPv6/隧道场景，规避部分云厂商压低的 MSS（如 1360 或更低）
- 避免设为 512 或 1024：虽能更快发包，但 record 过多导致 TLS 头开销上升、CPU 加密调用频繁，在弱网下反而增加处理负担
必须同步做的三件事
单独改 ssl_buffer_size 效果有限，需组合生效：
- 开启 tcp_nodelay on;：彻底关闭 Nagle，让每个 TLS record 到达 TCP 层后立即发送
- 强制启用 TLSv1.3：使用 ssl_protocols TLSv1.3;，1-RTT 握手本身已压缩前置耗时，让 buffer 策略收益更可测
- 启用 OCSP Stapling：加 ssl_stapling on; 和 ssl_stapling_verify on;，防止客户端因查证书状态而阻塞首包
验证是否真正起效
不能只看配置是否加载，要抓包确认行为变化：
- 用 Wireshark 抓 Nginx 出口流量，过滤 tls && tcp.len > 0，观察 TLS Application Data record 的 Length 字段是否稳定在设定值附近（如 1400±50）
- 重点检查 TLS 握手完成（Finished）后的第一个 TCP 包是否就携带了 HTTP 响应首行（如 HTTP/1.1 200 OK）
- 对比测试：curl -w "TTFB: %{time_starttransfer}\n" -k https://yoursite/，在模拟弱网（如 tc qdisc add dev eth0 root netem delay 100ms loss 2%）下多轮采样
