ssl_buffer_size 不影响 TLS 握手耗时，仅优化握手后首响应的发送时机与分片；应设为1400（公网）或1460（内网），并强制开启tcp_nodelay，按路径分级配置，抓包验证生效。
ssl_buffer_size 本身不减少 TLS 握手耗时，它只影响握手完成后的首个或前几个 HTTP 响应数据如何封装进 TLS record。所谓“大包传输时的协议碎片延迟”，实际是误解——真正需要优化的不是大包，而是首响应体小、但被大 buffer 拖慢发出时机所引发的延迟确认（Delayed ACK）和 TCP 分片问题。
明确目标：不是为大包调小，而是让首包“刚好一发即走”
默认 ssl_buffer_size=4096 字节，在传输一个仅 1.2KB 的 HTML 首响应时，Nginx 可能等待填满缓冲区或触发 write 调用时机，导致首 record 延迟发出；若该 record 加密后超过路径 MSS（如 1460），内核会分片，客户端需等待第二个分片到达才能解密，形成“协议碎片延迟”。这不是 TLS 握手变慢，而是应用数据发出太晚、或被拆得太碎。
- 设为 1400 字节：适配公网常见缩减 MTU（含隧道封装），确保加密后 record 长度稳定落在单个 TCP 段内，避免分片
- 设为 1460 字节：仅适用于直连内网等路径 MTU 稳定为 1500 的环境，稍有封装开销就易越界
- 避免 <1024：record 数量翻倍，TLS 头占比升高（固定 5 字节），CPU 加密开销上升，得不偿失
必须同步关闭 Nagle 算法，否则小 buffer 形同虚设
即使设了 ssl_buffer_size 1400，若 tcp_nodelay 未开启，Linux TCP 栈仍可能把多个小 record 合并成一个 TCP 段发送，或等待 200ms 再发，彻底抵消 buffer 缩小的效果。
- 配置中必须包含：tcp_nodelay on;
- 该指令需放在 server 或 http 块顶层，作用于所有 SSL 连接
- 不可与 tcp_nopush 同时启用——后者会尝试攒够 MSS 再发包，与精细控制首包冲突
按响应特征分级设置，而非全局一刀切
大文件下载（如 /download/、/video/）根本不受 ssl_buffer_size 影响，首包延迟可忽略，此时大 buffer（4KB 或 16KB）反而降低 TLS 加密调用频次、提升吞吐。真正要调小的是 API 和 HTML 首响应路径：
- /api/、/health、/status：首响应常 ≤800 字节 → 推荐 ssl_buffer_size 1024;
- /、/home、/product（含内联 CSS/JS 的首 HTML）：体积多在 1.5–2.5KB → 推荐 ssl_buffer_size 2048;
- /static/、/cdn/、/download/：资源体大、首包不敏感 → 保持默认 4096 或显式设为 16384
验证是否真生效：不能只看 curl 时间，要看包
改完配置后，必须抓包确认行为改变，而非依赖端到端指标：
- 用 Wireshark 过滤 tls.record.content_type == 23 && frame.number < 50，找到 TLS 握手完成后的首个 Application Data 包
- 检查其 Length 字段是否稳定落在你设定值 ±100 字节范围内（如设 1400，则应为 1350–1450）
- 观察该 record 是否出现在 TCP 握手 FIN/ACK 后的第 1 或第 2 个 TCP 段中；若拖到第 4、5 个段，说明仍有延迟确认或 write 时机问题
