在对使用 提供的图像进行测试时apache
,我注意到创建新会话时:
Waiting (TTFB)
: 1.09s
Initial connection + SSL handshake
: 370ms
DNS Lookup
:165ms
但随后使用持久连接:
Waiting (TTFB)
: 187ms
Content Download
:4ms
因此,我们发现TTFB
新连接的平均时间是非持久连接的 5 倍。这是正常的吗?
附带问题:为什么只有在有新连接时才进行新的 DNS 查找?
是的,非持久连接需要更长的时间来发送数据的第一个字节是正常的。
这是因为必须从 DNS 解析 IP 地址,必须建立 TCP 连接,然后必须初始化 SSL/TLS 层,然后才能发送实际数据。
DNS 查找不会在持久连接上执行,因为客户端和服务器 IP 地址之间已经存在活动的 TCP 连接,因此无需将域名解析为 IP 地址。
关于 Apache
KeepAlive
和KeepAliveTimeout
指令。KeepAlive
指定 Apache 是否应为后续对同一站点上其他资源的请求保持客户端连接打开。这些是持久连接,可以避免前面提到的延迟。但是,保持连接活动使用服务器上的资源,因为每个 TCP 连接都需要内存来维持状态。因此,使用
KeepAliveTimeout
指令可以指定空闲连接在 Web 服务器关闭之前保持打开多长时间。这也使得恶意客户端更难通过打开 HTTP 连接并无限期地保持它们打开来耗尽服务器资源。MaxKeepaliveRequests
表示每个 KeepAlive 连接允许多少个请求。我无法想象人们想要限制请求数量的情况。为了获得最佳性能,我会使用0
,即无限数量的请求。这些指令与访问者和 Web 服务器之间的 HTTP(S) 会话有关。PHP-FPM 与此接口无关。然而,在 FastCGI 接口的 nginx 中也有类似的 keepalive 机制。我不知道 Apache 中是否有类似的机制。