为什么在 Apache 上创建新的 TCP 会话时，请求的 TTFB 会长 5 倍？

Question

对提供的图像进行测试时 apache，我注意到在创建新会话时：

Waiting (TTFB): 1.09s Initial connection + SSL handshake:370ms DNS Lookup :165ms

但随后使用持久连接如下：

Waiting (TTFB): 187ms Content Download:4ms

因此，我们发现TTFB新连接的非持久性平均要长 5 倍。这是正常的吗？

附带问题：为什么只有在有新连接时才进行新的 DNS 查找？

Answer 1

是的，非持久连接需要更长的时间来发送数据的第一个字节是正常的。

这是因为必须从 DNS 解析 IP 地址，必须建立 TCP 连接，然后必须初始化 SSL/TLS 层，然后才能发送实际数据。

DNS 查找不会在持久连接上执行，因为客户端和服务器 IP 地址之间已经存在活动的 TCP 连接，因此无需将域名解析为 IP 地址。

关于 ApacheKeepAlive和KeepAliveTimeout指令。KeepAlive指定 Apache 是否应为后续对同一站点上的其他资源的请求保持客户端连接打开。这些是持久连接，可以避免前面提到的延迟。

但是，保持连接活动会使用服务器上的资源，因为每个 TCP 连接都会占用内存来维护状态。因此，使用KeepAliveTimeout指令可以指定一个空闲连接在 Web 服务器关闭它之前保持打开的时间。这也使恶意客户端更难通过打开 HTTP 连接并无限期地保持打开来耗尽服务器资源。

MaxKeepaliveRequests表示每个 KeepAlive 连接允许的请求数。我无法想象人们想要限制请求数量的情况。为了获得最佳性能，我会使用0，即无限数量的请求。

这些指令与访问者和 Web 服务器之间的 HTTP(S) 会话相关。PHP-FPM 与此接口无关。但是，对于 FastCGI 接口，nginx 中也有类似的 keepalive 机制。我不知道 Apache 中是否有类似的机制。