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