我目前正在尝试为一堆下载镜像设置一个负载平衡器。 在阅读这个主题的时候，我看到Nginx非常适合作为负载平衡器，太棒了！ 但是当看到不同的configuration时，我有点困惑。
人们可以决定redirect或代理到后端服务器。 redirect非常明确，您告诉客户端去其他地方，请求传递和处理，负载平衡器是不在图片。
但是，如果您select使用代理，是不是基本上削弱了运行多个下载镜像的整个想法？ 鉴于nginx会将请求转发到后端服务器，下载文件并传递给客户端？
所以想象一下我认为它是如何工作的（数据包stream）：
redirect ：客户端=>负载平衡器=>后端=>客户端
代理 ：客户端=>负载平衡器=>后端=>负载平衡器=>客户端
或者，代理会做一些魔术，并告诉客户端实际连接到后端下载他的文件？
如果代理确实有点失败的目的，有多个下载镜像，以获得更多的吞吐量，redirect唯一的select？
编辑：或者我混淆了与重写代理的运作？ 代理实际上是否像使用redirect一样传递请求，而仍然使用相同的URL？
如果您使用nginx作为负载平衡器，则该stream将是：
redirect：
Step 1 : Client => LB (HTTP request) Step 2 : LB => Client (HTTP reply) Step 3 : Client => Backend (HTTP request) Step 4 : Backend => Client (HTTP reply) 代理 ：
Step 1 : Client => LB (HTTP request) Step 2 : LB => Backend (HTTP request) Step 3 : Backend => LB (HTTP reply) Step 4 : LB => Client (HTTP reply)
所以在第一种情况下，负载平衡器就是您认为它是一个简单的HTTP服务器，并直接回复到客户端的方式。 在第二种情况下，它通过nginx一路回到客户端。 由于nginx不一定等待完整的回复主体可用于开始将数据传输到客户端，它将使用缓冲区或临时文件根据configuration将其回传。 但是，由于在实际数据传输过程中再多跳一次，您将遇到更高的数据包往返时间。
所以这就是在使用HTTP的情况下OSI第7层负载平衡的大图。 现在，networking负载平衡并不局限于第7层和HTTP。 还有其他的方法。
特别是，如果您正在寻求一种方法将stream量传播到基本上静态内容的后端服务器，则可以使用keepalived作为直接路由模式下的负载平衡解决scheme，这将使后端服务器直接向客户端回复，同时请求通过负载平衡器（它是OSI第4层，所以它不知道你在做什么，它只是简单地安装一个虚拟IP，并把TCPstream推送到实际的服务器上，在虚拟IP被安装在环回接口上）。 Keepalived还通过使用VRRP（主/备份模式）来处理HA。
如果你绝对要坚持nginx的话，有一些类似的东西叫做stream模块（出现在nginx 1.9.0中，不是“稳定的”版本），但是你需要自己重新编译它，这不会阻止跳转即使在OSI第四层工作也是如此。