HTTP反向代理通常在代理连接的客户端启用HTTP Keep-Alive,而不是在服务器端?

HAProxy能够在客户端启用HTTP保持活动(客户端HAProxy),但在服务器端(HAProxy < – >服务器)禁用它。

我们的一些客户通过卫星连接到我们的networking服务,所以延迟时间大约是600毫秒,我认为通过保持活跃状态​​,它会加速一些事情。 我对吗?

这是由Nginx支持吗? 这是其他软件和硬件负载平衡器中广泛实施的function吗? 除了HAProxy,还有什么?

    编辑:我的回答只包括原始的未经编辑的问题,这是否是负载平衡器/反向代理中的典型情况。 我不确定nginx / product X是否支持这一点,99.9%的反向代理经验是使用HAproxy。

    正确。 HTTP Keep-Alive在客户端,但不在服务器端。

    为什么?

    如果你分解一些细节,你可以很快看到为什么这是一个好处。 对于这个例子,假设我们正在加载一个www.example.com页面,该页面包含3个图像,img [1-3] .jpg。

    浏览器加载一个页面,没有保持活着

    1. 客户端在端口80上build立到www.example.com的TCP连接
    2. 客户端执行HTTP GET请求“/”
    3. 服务器发送URI“/”的HTML内容(包括引用3个图像的HTML标签)
    4. 服务器closuresTCP连接
    5. 客户端在端口80上build立到www.example.com的TCP连接
    6. 客户端执行“/img1.jpg”的HTTP GET请求
    7. 服务器发送图像
    8. 服务器closuresTCP连接
    9. 客户端在端口80上build立到www.example.com的TCP连接
    10. 客户端执行“/img2.jpg”的HTTP GET请求
    11. 服务器发送图像
    12. 服务器closuresTCP连接
    13. 客户端在端口80上build立到www.example.com的TCP连接
    14. 客户端执行“/img3.jpg”的HTTP GET请求
    15. 服务器发送图像
    16. 服务器closuresTCP连接

    请注意,有4个独立的TCP会话build立,然后closures。

    浏览器加载一个页面,保持活着

    HTTP Keep-Alive允许单个TCP连接一个接一个地处理多个HTTP请求。

    1. 客户端在端口80上build立到www.example.com的TCP连接
    2. 客户端为“/”执行HTTP GET请求,并要求服务器将其设置为HTTP Keep-Alive会话。
    3. 服务器发送URI“/”的HTML内容(包括引用3个图像的HTML标签)
    4. 服务器不closures TCP连接
    5. 客户端和HTTP GET请求“/img1.jpg”
    6. 服务器发送图像
    7. 客户端和HTTP GET请求“/img2.jpg”
    8. 服务器发送图像
    9. 客户端和HTTP GET请求“/img3.jpg”
    10. 服务器发送图像
    11. 如果在HTTP Keep-Alive超时期限内没有收到更多的HTTP请求,服务器将closuresTCP连接

    请注意,通过Keep-Alive,只有1个TCP连接被build立并最终closures。

    为什么要保持活力?

    要回答这个问题,您必须了解在客户端和服务器之间build立TCP连接需要什么。 这被称为TCP三方握手。

    1. 客户端发送SYN(chronise)数据包
    2. 服务器发回SYN(chronise)ACK(请求),SYN-ACK
    3. 客户端发送一个ACK(nowledgement)包
    4. TCP连接现在被客户端和服务器认为是活动的

    networking有延迟,因此三次握手的每一步都需要一定的时间。 假设客户端和服务器之间有30ms的时间,build立TCP连接所需的IP数据包的来回发送意味着需要3×30ms = 90ms来build立TCP连接。

    这可能听起来不是很多,但是如果我们考虑在我们最初的例子中,我们必须build立4个独立的TCP连接,这将变成360ms。 如果客户端和服务器之间的延迟是100ms而不是30ms? 然后我们的4个连接需要1200msbuild立。

    更糟的是,一个典型的网页可能需要远远超过3张图片才能加载,可能会有多个客户端需要请求的CSS,JavaScript,图片或其他文件。 如果页面加载30个其他文件并且客户端 – 服务器延迟为100ms,那么我们花费多长时间build立TCP连接?

    1. build立1个TCP连接需要3个等待时间,即3×100ms = 300ms。
    2. 我们必须这样做31次,一次为页面,另外30次为页面引用的每个其他文件。 31×300ms = 9.3秒。

    花了9.3秒build立TCP连接加载引用30个其他文件的网页。 这甚至没有计算发送HTTP请求和接收响应的时间。

    使用HTTP Keep-Alive,我们只需要build立一个TCP连接,需要300ms。

    如果HTTP Keep-Alive非常好,那么为什么不在服务器端使用呢?

    HTTP反向代理(如HAproxy)通常部署在非常靠近代理服务器的后端服务器上。 在大多数情况下,反向代理和后端服务器之间的延迟将在1ms以下,所以build立TCP连接比在客户端之间快得多。

    这只是一半的理由。 HTTP服务器为每个客户端连接分配一定数量的内存。 使用Keep-Alive,它将保持连接的活动,并且通过扩展它将保持服务器上使用的一定数量的内存,直到达到保持活动超时,这可能高达15s,这取决于服务器configuration。

    因此,如果我们考虑在HTTP反向代理的服务器端使用Keep-Alive的效果,我们正在增加对内存的需求,但是由于代理和服务器之间的延迟太低,我们没有从减less了TCP三次握手所花费的时间,因此,在这种情况下,通常只需禁用代理和Web服务器之间的Keep-Alive即可。

    免责声明:是的,这个解释并没有考虑到浏览器通常并行地build立到服务器的多个HTTP连接的事实。 但是,浏览器对同一主机有多less个并行连接是有限制的,而且通常这个连接还是足够小,以保持活跃状态​​。

    Nginx支持双方保持连接。

    • 客户端: http : //nginx.org/r/keepalive_timeout
    • 后端: http : //nginx.org/r/keepalive