http - HTTP负载均衡下的TCP连接和流量路由

Question

我试图弄清楚 的类型是什么？加载 (例如，就网络流量而言)HTTP 流量的负载均衡器可以预期接收/转发/重定向。
考虑以下两种不同的 HTTP 流量场景。

单例 HTTP 请求 有效载荷的大小大大超过 的大小单 TCP IP 包(即请求需要很多网络包)

多个 HTTP 请求 超过 single persistent TCP connection

对于他们每个人:

会全部 网络流量(例如 TCP IP 数据包)是否通过负载均衡器本身？ (即负载均衡器“像电缆一样”查看和转发所有流量)

或者负载均衡器是否会让客户端与应用服务器的 IP 地址建立直接 TCP 连接 缓解网络流量的LB？

这取决于协议(protocol)吗？ (例如，说 HTTP 请求与 WebSocket)？或者这些协议(protocol)是否要求 TCP 连接始终可用，负载均衡器在 WebSocket 连接或请求-响应 HTTP 传输的整个持续时间内接收和转发所有 IP 流量？

Answer 1

这取决于。
有像 HAProxy 这样的应用层负载均衡器，其中完整的 HTTP 请求和响应通过代理传递。这里有两个单独的 TCP 连接:一个在客户端和负载均衡器之间，另一个在负载均衡器和上游服务器之间。可以根据 HTTP 请求的内容来选择上游服务器，例如 Host header 和/或路径以及 session cookie - 确保相同的 session 始终由相同的上游服务器处理。如果上游服务器的决定是在 HTTP 请求上完成的，那么到上游服务器的连接只能在读取 HTTP 请求后建立，因为之前不知道。但是请求不需要在单个数据包中。
有网络或传输层负载平衡器根本不作用于数据包有效负载。相反，上游服务器的选择通常是根据客户端 IP 来完成的，因此同一个客户端最终会在同一个上游服务器上。在这种情况下，使用哪个上游的决定已经在第一个数据包(即启动 TCP 握手的 SYN)上完成，客户端基本上直接与​​上游代理建立连接 - 负载平衡器只像路由器一样转发数据包。 HTTP 请求的大小在这里也无关紧要，因为甚至没有检查 TCP 有效负载以做出路由决策。
使用网络或传输层负载均衡器可能会出现非对称路由，即响应可能会采用不同的方式而不通过负载均衡器。使用应用层负载平衡，响应会通过负载平衡器返回。