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

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

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

Waiting (TTFB):::1.09s Initial connection + SSL handshake370ms DNS Lookup165ms

但是随后通过持久连接出现以下情况:

Waiting (TTFB)187ms Content Download4ms

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

附带问题:为什么仅当有新连接时才进行新的 DNS 查找?

答案1

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

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

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

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

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

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

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

相关内容