优化 Time to First Byte 的连接时长(TCP + TLS)子部分

TTFB 的连接时长包括建立 TCP 和 TLS 连接。了解 TTFB 的这一子部分,以缩短总的 Time to First Byte

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-21

优化 Time to First Byte 的连接时长(TCP + TLS)子部分

Time to First Byte (TTFB) 可以分解为以下子部分:

  • Waiting + Redirect(即等待时长)
  • Worker + Cache(即缓存时长)
  • DNS(即 DNS 时长)
  • Connection (即连接时长)
  • Request(即请求时长)

想要优化 Time to First Byte本文对 Time to First Byte 中 DNS 时长部分进行了深入分析。如果您想了解或修复 Time to First Byte 但不清楚等待时长的含义,请先阅读 什么是 Time to First Byte修复和识别 Time to First Byte 问题,然后再开始阅读本文

Time to First Byte 的连接时长部分包括浏览器连接到 Web 服务器所花费的时间。连接建立后,浏览器和服务器通常会添加一个加密层(TLS)。协商这两个连接的过程需要一些时间,而这些时间会被计入 Time to First Byte。


连接过程详解

传输控制协议(TCP)负责在客户端(浏览器)和服务器之间建立可靠的连接。此过程涉及三次握手:

tcp 3 way handshake

  • SYN(同步)数据包:客户端向服务器发送 SYN 数据包以发起连接并请求同步。
  • SYN-ACK(同步-确认)数据包:服务器回复 SYN-ACK 数据包,确认收到 SYN 数据包并同意建立连接。
  • ACK(确认)数据包:客户端向服务器回发 ACK 数据包,确认收到 SYN-ACK 数据包。此时,TCP 连接已建立,可以在客户端和服务器之间可靠地传输数据。

TCP 确保数据按正确顺序发送和接收,重新发送丢失的数据包,并管理流量控制以匹配网络容量。

TCP 连接建立后,传输层安全(TLS)协议用于保护连接安全。TLS 握手涉及多个步骤来验证服务器身份并建立安全的通信通道:

  • ClientHello:客户端向服务器发送“ClientHello”消息,指示支持的 TLS 版本、密码套件和一个随机数(Client Random)。
  • ServerHello:服务器回复“ServerHello”消息,从客户端列表中选择 TLS 版本和密码套件,并提供其数字证书和一个随机数(Server Random)。
  • 证书和密钥交换:服务器将其数字证书发送给客户端进行身份验证。客户端根据受信任的证书颁发机构验证该证书。
  • Premaster Secret:客户端生成预主密钥(premaster secret),使用服务器的公钥(来自证书)加密后发送给服务器。
  • 会话密钥生成:客户端和服务器使用预主密钥以及 Client Random 和 Server Random 生成用于对称加密的共享会话密钥。
  • 完成消息:客户端和服务器交换使用会话密钥加密的消息,以确认握手成功且双方都拥有正确的会话密钥。

TLS 握手完成后,客户端和服务器便建立了安全的加密连接。这确保了交换的任何数据都受到保护,免受第三方的窃听和篡改。

HTTP/3 通过与 QUIC 协议集成来加速 TLS 连接,将握手过程合并为一个从而减少建立安全连接所需的往返次数,并支持 0-RTT 恢复以实现更快的重新连接。此外,QUIC 使用 UDP 消除了队头阻塞问题并改善了拥塞控制,从而实现更高效的数据传输和更快的页面加载。

连接时间如何影响 Time to First Byte?
TCP 和 TLS 协议通过在初始连接建立过程中引入延迟和计算开销来影响 Time to First Byte (TTFB)。TCP 连接需要三次握手来建立可靠连接,这增加了往返时间延迟。TLS 握手是保护连接安全所必需的,它需要额外的往返来协商加密参数和验证证书。 

这一组合过程会给 TTFB 带来实际延迟,尤其是在网络条件不佳或使用较旧版本的 TLS 时(与 TLS 1.3 等较新版本相比,旧版本需要更多的往返)

如何最小化连接时间对 TTFB 的影响

要最小化连接时间对 TTFB 的影响,最可行的做法是配置您的 Web 服务器使用最新技术,如 HTTP/3 和 TLS 1.3。同时确保 Web 服务器在地理位置上靠近您的访客,因为连接时间需要多次往返,服务器的物理距离也会影响连接时间。对于拥有全球受众的网站,CDN 是确保较短连接往返时间的唯一方式。

在优化服务器设置时,以下设置可以启用或配置以加快连接时长:

  • HTTP/3将 QUIC 协议引入 UDP 而非 TCP,实现更快、更高效的数据传输
  • TLS 1.3 增强安全性并减少握手往返次数,是 0-RTT 连接恢复的必要条件。 
  • 0-RTT Connection Resumption - TLS 1.3 功能,允许回访客户端在重新连接时通过重用先前交换的信息立即发送加密数据。
  • TCP Fast Open。允许在初始 SYN 数据包中发送数据,减少 TCP 握手的往返时间。
  • TLS false start - 允许在 TLS 握手完成之前提前发送数据。
  • OCSP Stapling -  加速证书验证,无需客户端直接联系证书颁发机构

Time to First Byte 提示:CDN 不仅能提供更短的往返时间。使用 CDN 通常会立即改善 TCP 和 TLS 连接时间,因为优质的 CDN 提供商已经为您正确配置了这些设置!

如何发现由缓慢的连接时间导致的 TTFB 问题

要发现真实用户因重定向而受到的影响,您需要使用像 CoreDash 这样的 RUM 工具。真实用户监控可以让您更详细地跟踪 Core Web Vitals,而无需等待 Google 28 天的延迟。

在 CoreDash 中,只需"点击 Time to First Byte 分解"即可可视化 Time to First Byte 的连接部分。  

ttfb dns coredash breakdown

Secure your Q3 Metrics.

Do not let technical debt derail your Core Web Vitals. I provide the strategy, the code, and the verification to pass Google's assessment.

Start the Engagement >>

  • Strategic Planning
  • Code Implementation
  • Verification & Testing
优化 Time to First Byte 的连接时长(TCP + TLS)子部分Core Web Vitals 优化 Time to First Byte 的连接时长(TCP + TLS)子部分