分布式框架实现基础之IO技术(4)-网络和负载均衡

本章简单聊下网络和LBS相关的内容，本文中描述的都是基础部分。一般的公司会在基础上封装成需要的基础服务。网络分4层和7层：

4层：网络访问层、网络层、传输层、应用层；

7层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层；

目录

一、网络

1.1、TCP/IP原理

1.2、HTTP原理

1.3、服务CDN原理

二、负载均衡

2.1、概述

2.2、负载均衡的算法和策略

2.3、实现技术

---

一、网络

1.1、TCP/IP原理

TCP/IP 协议不是 TCP 和 IP 这两个协议的合称，而是指因特网整个 TCP/IP 协议族。从协议分层 模型方面来讲，TCP/IP 由四个层次组成:网络接口层、网络层、传输层、应用层。

1.1.1、详细解释

1.1.1.1、网络访问层

网络访问层(Network Access Layer)在 TCP/IP 参考模型中并没有详细描述，只是指出主机必须使用某种协议与网络相连。

1.1.1.2、网络层

网络层(Internet Layer)是整个体系结构的关键部分，其功能是使主机可以把分组发往任何网络，并使分组独立地传向目标。这些分组可能经由不同的网络，到达的顺序和发送的顺序也可能不同。高层如果需要顺序收发，那么就必须自行处理对分组的排序。互联网层使用因特 网协议(IP，Internet Protocol)

1.1.1.3、传输层

传输层(Tramsport Layer)使源端和目的端机器上的对等实体可以进行会话。在这一层定义了 两个端到端的协议:传输控制协议(TCP，Transmission Control Protocol)和用户数据报协 议(UDP，User Datagram Protocol)。TCP 是面向连接的协议，它提供可靠的报文传输和对上层应用的连接服务。为此除了基本的数据传输外，它还有可靠性保证、流量控制、多路 复用、优先权和安全性控制等功能。UDP 是面向无连接的不可靠传输的协议，主要用于不需要 TCP 的排序和流量控制等功能的应用程序。

1.1.1.4、应用层

应用层(Application Layer)包含所有的高层协议，包括:虚拟终端协议(TELNET， TELecommunications NETwork)、文件传输协议(FTP，File Transfer Protocol)、电子邮件传输协议(SMTP，Simple Mail Transfer Protocol)、域名服务(DNS，Domain Name Service)、网上新闻传输协议(NNTP，Net News Transfer Protocol)和超文本传送协议(HTTP，HyperText Transfer Protocol)等。

1.1.2、三次/四次握手

TCP 在传输之前会进行三次沟通，一般称为“三次握手”，传完数据断开的时候要进行四次沟通，一般称为“四次挥手”。

1.1.2.1、数据包结构说明

• 源端口号( 16 位)：它(连同源主机 IP 地址)标识源主机的一个应用进程；
• 目的端口号( 16 位)：它(连同目的主机 IP 地址)标识目的主机的一个应用进程。这两个值加上 IP 报头中的源主机 IP 地址和目的主机 IP 地址唯一确定一个 TCP 连接；
• 顺序号 seq( 32 位)：用来标识从 TCP 源端向 TCP 目的端发送的数据字节流，它表示在这个报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动，则 TCP 用顺序号对每个字节进行计数。序号是 32bit 的无符号数，序号到达 2 的 32 次方 - 1 后 又从 0 开始。当建立一个新的连接时， SYN 标志变 1 ，顺序号字段包含由这个主机选择的该 连接的初始顺序号 ISN ( Initial Sequence Number )；
• 确认号 ack( 32 位)：包含发送确认的一端所期望收到的下一个顺序号。因此，确认序号应当是上次已成功收到数据字节顺序号加 1 。只有 ACK 标志为 1 时确认序号字段才有效。 TCP 为 应用层提供全双工服务，这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据顺序号；
• TCP 报头长度( 4 位)：给出报头中 32bit 字的数目，它实际上指明数据从哪里开始。需要这个值是因为任选字段的长度是可变的。这个字段占 4bit ，因此 TCP 最多有 60 字节的首部。然而，没有任选字段，正常的长度是 20 字节；
• 保留位( 6 位):保留给将来使用，目前必须置为 0 ；
• 控制位( control flags ， 6 位)：在 TCP 报头中有 6 个标志比特，它们中的多个可同时被设置为 1 。依次为:

• URG：为 1 表示紧急指针有效，为 0 则忽略紧急指针值。
• ACK：为 1 表示确认号有效，为 0 表示报文中不包含确认信息，忽略确认号字段。
• PSH：为 1 表示是带有 PUSH 标志的数据，指示接收方应该尽快将这个报文段交给应用层而不用等待缓冲区装满。
• RST：用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报文段和拒绝连接请求。一般情况下，如果收到一个 RST 为 1 的报文，那么一定发生了某些问题。
• SYN：同步序号，为 1 表示连接请求，用于建立连接和使顺序号同步( synchronize )。
• FIN：用于释放连接，为 1 表示发送方已经没有数据发送了，即关闭本方数据流。

• 窗口大小( 16 位)：数据字节数，表示从确认号开始，本报文的源方可以接收的字节数，即源 方接收窗口大小。窗口大小是一个 16bit 字段，因而窗口大小最大为 65535 字节；
• 校验和( 16 位)：此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16 位字 进行计算所得。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证；
• 紧急指针(16位)：只有当URG标志置1时紧急指针才有效。TCP的紧急方式是发送端向另 一端发送紧急数据的一种方式；
• 选项：最常见的可选字段是最长报文大小，又称为MSS(MaximumSegmentSize)。每个连 接方通常都在通信的第一个报文段(为建立连接而设置 SYN 标志的那个段)中指明这个选项， 它指明本端所能接收的最大长度的报文段。选项长度不一定是 32 位字的整数倍，所以要加填充 位，使得报头长度成为整字数；
• 数据：TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报 文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数 据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

1.1.2.3、三次握手

• 第一次握手：主机 A 发送位码为syn=1（为 1 表示连接请求），随机产生 seq number=1234567 的数据包到服务器，主机 B由 SYN=1 知道，A 要求建立联机;
• 第二次握手：主机 B 收到请求后要确认联机信息，向 A 发送 ack number=(主机 A 的seq+1),syn=1,ack=1,随机产生 seq=7654321 的；
• 第三次握手:主机 A 收到后检查 ack number 是否正确，即第一次发送的 seq number+1,以及位码ack 是否为 1，若正确，主机 A 会再发送 ack number=(主机 B 的 seq+1),ack=1，主机 B 收到后确认seq 值与 ack=1 则连接建立成功。

1.1.2.4、四次挥手

TCP 建立连接要进行三次握手，而断开连接要进行四次。这是由于 TCP 的半关闭造成的。因为 TCP 连接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭。这个单方向的关闭就叫半关闭。当一方完成它的数据发送任务，就发送一个 FIN 来向另一方通告将要终止这个 方向的连接：

• 关闭客户端到服务器的连接:首先客户端 A 发送一个 FIN（为 1 表示发送方已经没有数据发送了，即关闭本方数据流），用来关闭客户到服务器的数据传送，然后等待服务器的确认。其中终止标志位 FIN=1，序列号 seq=u；
• 服务器收到这个 FIN，它发回一个 ACK，确认号 ack 为收到的序号加 1；
• 关闭服务器到客户端的连接：也是发送一个 FIN 给客户端；
• 客户段收到 FIN 后，并发回一个 ACK 报文确认，并将确认序号 seq 设置为收到序号加 1。

最后首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

1.2、HTTP原理

HTTP 是一个无状态的协议。无状态是指客户机(Web 浏览器)和服务器之间不需要建立持久的连接， 这意味着当一个客户端向服务器端发出请求，然后服务器返回响应(response)，连接就被关闭了，在服 务器端不保留连接的有关信息.HTTP 遵循请求(Request)/应答(Response)模型。客户机(浏览器)向 服务器发送请求，服务器处理请求并返回适当的应答。所有 HTTP 连接都被构造成一套请求和应答。

1.2.1、传输流程

这个比较简单就不详细说了，大概流程如下：1、DNS解析--2、封装HTTP请求数据包--3、封装成TCP包并建立连接--4、客户机发送请求（url）--5、服务器响应--6、关闭TCP连接

标注6：如果浏览器或者服务器在其头信息加入了这行代码 Connection:keep-alive，TCP 连接在发送 后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求 建立新连接所需的时间，还节约了网络带宽。

1.2.2、HTTPS

HTTPS(全称:Hypertext Transfer Protocol over Secure Socket Layer)，是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版。即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL。其所用的端口号是 443。 过程大致如下:

• 建立连接获取证书：SSL 客户端通过 TCP 和服务器建立连接之后(443 端口)，并且在一般的 tcp 连接协商(握手)过程中请求证书。即客户端发出一个消息给服务器，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL 的服务器端会回应一个数据包，这里面确定了这次通信所需要的算法，然后服务器向客户端返回证书。(证书里面包含了服务器信息:域名。申请证书的公司，公共秘钥)；
• 证书验证：Client 在收到服务器返回的证书后，判断签发这个证书的公共签发机构，并使用这个机构的公 共秘钥确认签名是否有效，客户端还会确保证书中列出的域名就是它正在连接的域名；
• 数据加密和传输：如果确认证书有效，那么生成对称秘钥并使用服务器的公共秘钥进行加密。然后发送给服务 器，服务器使用它的私钥对它进行解密，这样两台计算机可以开始进行对称加密进行通信。

1.3、服务CDN原理

CND 一般包含分发服务系统、负载均衡系统和管理系统

1.3.1、分发服务系统

其基本的工作单元就是各个 Cache 服务器。负责直接响应用户请求，将内容快速分发到用户;同时还 负责内容更新，保证和源站内容的同步。根据内容类型和服务种类的不同，分发服务系统分为多个子服务系统，如:网页加速服务、流媒体加速服务、应用加速服务等。每个子服务系统都是一个分布式的服务集群，由功能类似、地域接近的分布部 署的 Cache 集群组成。

在承担内容同步、更新和响应用户请求之外，分发服务系统还需要向上层的管理调度系统反馈各个 Cache 设备的健康状况、响应情况、内容缓存状况等，以便管理调度系统能够根据设定的策略决定由 哪个 Cache 设备来响应用户的请求。

1.3.2、负载均衡系统

负载均衡系统是整个 CDN 系统的中枢。负责对所有的用户请求进行调度，确定提供给用户的最终访问地址。使用分级实现。最基本的两极调度体系包括全局负载均衡(GSLB)和本地负载均衡(SLB)：

• GSLB 根据用户地址和用户请求的内容，主要根据就近性原则，确定向用户服务的节点。一般通过 DNS 解析或者应用层重定向(Http 3XX 重定向)的方式实现；
• SLB 主要负责节点内部的负载均衡。当用户请求从 GSLB 调度到 SLB 时，SLB 会根据节点内各个 Cache 设备的工作状况和内容分布情况等对用户请求重定向。SLB 的实现有四层调度(LVS)、七层调 度(Nginx)和链路负载调度等；

1.3.3、管理系统

分为运营管理和网络管理子系统。网络管理系统实现对 CDN 系统的设备管理、拓扑管理、链路监控和故障管理，为管理员提供对全网资 源的可视化的集中管理，通常用 web 方式实现。运营管理是对 CDN 系统的业务管理，负责处理业务层面的与外界系统交互所必须的一些收集、整理、 交付工作。包括用户管理、产品管理、计费管理、统计分析等。

二、负载均衡

负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带 宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性，可分为4层和7层（大型的互联网系统都会通过设置两层负载均衡）。

2.1、概述

2.1.1、四层负载均衡(目标地址和端口交换)

比如常用的nginx，主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器（VIP技术）。 以常见的 TCP 为例，负载均衡设备在接收到第一个来自客户端的 SYN 请求时，即通过上述方式选 择一个最佳的服务器，并对报文中目标 IP 地址进行修改(改为后端服务器 IP)，直接转发给该服务 器。TCP 的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类 似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在 转发报文的同时可能还会对报文原来的源地址进行修改。

2.1.2、七层负载均衡(内容交换)

比如haproxy，所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容， 再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。七层应用负载的好处，是使得整个网络更智能化。例如访问一个网站的用户流量，可以通过七层的方式，将对图片类的请求转发到特定的图片服务器并可以使用缓存技术;将对文字类的请求可 以转发到特定的文字服务器并可以使用压缩技术。

2.2、负载均衡的算法和策略

2.2.1、轮循均衡(RoundRobin)

每一次来自网络的请求轮流分配给内部中的服务器，从 1 至 N 然后重新开始。此种均衡算法适合 于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。

2.2.2、权重轮循均衡(WeightedRoundRobin)

根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请 求。例如:服务器 A 的权值被设计成 1，B 的权值是 3，C 的权值是 6，则服务器 A、B、C 将分 别接受到 10%、30%、60%的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用 率，避免低性能的服务器负载过重。

2.2.3、随机均衡(Random)

把来自网络的请求随机分配给内部中的多个服务器。

2.2.4、权重随机均衡(WeightedRandom)

此种均衡算法类似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。

2.2.5、响应速度均衡(ResponseTime探测时间)

负载均衡设备对内部各服务器发出一个探测请求(例如 Ping)，然后根据内部中各服务器对探测 请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好的反映 服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时 间，而不是客户端与服务器间的最快响应时间。

2.2.6、最少连接数均衡(LeastConnection)

最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在 处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡 更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如 FTP。

2.2.7、处理能力均衡(CPU、内存)

此种均衡算法将把服务请求分配给内部中处理负荷(根据服务器 CPU 型号、CPU 数量、内存大小 及当前连接数等换算而成)最轻的服务器，由于考虑到了内部服务器的处理能力及当前网络运行 状况，所以此种均衡算法相对来说更加精确，尤其适合运用到第七层(应用层)负载均衡的情况下。

2.2.8、DNS响应均衡(FlashDNS)

在此均衡算法下，分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求，并在 同一时间内把此域名解析成各自相对应服务器的 IP 地址并返回给客户端，则客户端将以最先收到 的域名解析 IP 地址来继续请求服务，而忽略其它的 IP 地址响应。在种均衡策略适合应用在全局负 载均衡的情况下，对本地负载均衡是没有意义的。

2.2.9、一致性哈希算法

一致性哈希一致性 Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往 该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

2.2.10、IP 哈希（散列）算法

通过管理发送方 IP 和目的地 IP 地址的散列，将来自同一发送方的分组(或发送至同一目的地的分 组)统一转发到相同服务器的算法。当客户端有一系列业务需要处理而必须和一个服务器反复通信 时，该算法能够以流(会话)为单位，保证来自相同客户端的通信能够一直在同一服务器中进行处理。

2.2.11、URL 哈希（散列）算法

通过管理客户端请求 URL 信息的散列，将发送至相同 URL 的请求转发至同一服务器的算法。

2.3、实现技术

2.3.1、LVS

LVS 的 IP 负载均衡技术是通过 IPVS 模块来实现的，IPVS 是 LVS 集群系统的核心软件，它的主要作用是:安装在 Director Server 上，同时在 Director Server 上虚拟出一个 IP 地址，用户必须通 过这个虚拟的 IP 地址访问服务器。这个虚拟 IP 一般称为 LVS 的 VIP，即 Virtual IP。访问的请求 首先经过 VIP 到达负载调度器，然后由负载调度器从 Real Server 列表中选取一个服务节点响应用 户的请求。 在用户的请求到达负载调度器后，调度器如何将请求发送到提供服务的 Real Server 节 点，而 Real Server 节点如何返回数据给用户，是 IPVS 实现的重点技术。

• ipvs : 工作于内核空间，主要用于使用户定义的策略生效ipvsadm；
• 工作于用户空间，主要用于用户定义和管理集群服务的工具；

ipvs 工作于内核空间的 INPUT 链上，当收到用户请求某集群服务时，经过 PREROUTING 链，经检查本机路由表，送往 INPUT 链;在进入 netfilter 的 INPUT 链时，ipvs 强行将请求报文通过 ipvsadm 定义的集群服务策略的路径改为 FORWORD 链，将报文转发至后端真实提供服务的主机。它有几下几种模式：

2.3.1.1、NAT 模式（改写IP地址）

1.客户端将请求发往前端的负载均衡器，请求报文源地址是 CIP(客户端 IP),后面统称为 CIP)，目 标地址为 VIP(负载均衡器前端地址，后面统称为 VIP)；2.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的目 标地址改为了后端服务器的 RIP 地址并将报文根据算法发送出去。；3.报文送到 Real Server 后，由于报文的目标地址是自己，所以会响应该请求，并将响应报文返还 给 LVS。；4.然后 lvs 将此报文的源地址修改为本机并发送给客户端。

注意：在 NAT 模式中，Real Server 的网关必须指向 LVS，否则报文无法送达客户端。

NAT 技术将请求的报文和响应的报文都需要通过 LB 进行地址改写，因此网站访问量比较大的 时候 LB 负载均衡调度器有比较大的瓶颈，一般要求最多只能 10-20 台节点。只需要在 LB 上配置一个公网 IP 地址就可以了。每台内部的 realserver 服务器的网关地址必须是调度器 LB 的内网地址。NAT 模式支持对 IP 地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。

优点: 集群中的物理服务器可以使用任何支持 TCP/IP 操作系统，只有负载均衡器需要一个合法的 IP 地址。缺点：扩展性有限。当服务器节点(普通 PC 服务器)增长过多时,负载均衡器将成为整个系统的瓶颈，因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇在负载均衡器那，速度就会变慢!

2.3.1.2、DR 模式(改写 mac 地址)

1、客户端将请求发往前端的负载均衡器，请求报文源地址是 CIP，目标地址为 VIP。 2.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的源 MAC 地址改为自己 DIP 的 MAC 地址，目标 MAC 改为了 RIP 的 MAC 地址，并将此包发送给 RS。 3.RS 发现请求报文中的目的 MAC 是自己，就会将次报文接收下来，处理完请求报文后，将响应 报文通过 lo 接口送给 eth0 网卡直接发送给客户端。

注意：需要设置 lo 接口的 VIP 不能响应本地网络内的 arp 请求。

优点：负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户 端。与 VS-TUN 相比，VS-DR 这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为 物理服务器。 DR 模式的效率很高，但是配置稍微复杂一点，因此对于访问量不是特别大的公司可以用 haproxy/nginx 取代。日 1000-2000W PV 或者并发请求 1 万一下都可以考虑用 haproxy/nginx。缺点:：所有 RS 节点和调度器 LB 只能在一个局域网里面。

2.3.1.3、TUN 模式(IP封装、跨网段)

1、客户端将请求发往前端的负载均衡器，请求报文源地址是 CIP，目标地址为 VIP。 2.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将在客户端请求报文的 首部再封装一层 IP 报文,将源地址改为 DIP，目标地址改为 RIP,并将此包发送给 RS。 3.RS 收到请求报文后，会首先拆开第一层封装,然后发现里面还有一层 IP 首部的目标地址是自己 lo 接口上的 VIP，所以会处理次请求报文，并将响应报文通过 lo 接口送给 eth0 网卡直接发送给客 户端。

注意:需要设置 lo 接口的 VIP 不能在公网上出现。

优点：负载均衡器只负责将请求包分发给后端节点服务器，而 RS 将应答包直接发给用户。所以，减少了 负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方 式，一台负载均衡器能够为很多 RS 进行分发。而且跑在公网上就能进行不同地域的分发。缺点: 隧道模式的 RS 节点需要合法 IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分 Linux 系统上，所以运维起来比较难，所以一般不用。

2.3.1.4、FULLNAT模式（跨网段）

无论是 DR 还是 NAT 模式，不可避免的都有一个问题:LVS 和 RS 必须在同一个 VLAN 下，否则 LVS 无法作为 RS 的网关。这引发的两个问题是: 1、同一个 VLAN 的限制导致运维不方便，跨 VLAN 的 RS 无法接入。 2、LVS 的水平扩展受到制约。当 RS 水平扩容时，总有一天其上的单点 LVS 会成为瓶颈。

Full-NAT 由此而生，解决的是 LVS 和 RS 跨 VLAN 的问题，而跨 VLAN 问题解决后，LVS 和 RS 不再存在 VLAN 上的从属关系，可以做到多个 LVS 对应多个 RS，解决水平扩容的问题。 Full-NAT 相比 NAT 的主要改进是，在 SNAT/DNAT 的基础上，加上另一种转换。

2.3.2、Keepalive

keepalive 起初是为 LVS 设计的，专门用来监控 lvs 各个服务节点的状态，后来加入了 vrrp 的功能，因此除了 lvs，也可以作为其他服务(nginx，haproxy)的高可用软件。VRRP 是 virtual router redundancy protocal(虚拟路由器冗余协议)的缩写。VRRP 的出现就是为了解决静态路由出现的单点故障，它能够保证网络可以不间断的稳定的运行。所以 keepalive一方面具有 LVS cluster node healthcheck 功能，另一方面也具有 LVS director failover。

2.3.3、Nginx 反向代理

普通的负载均衡软件，如 LVS，其实现的功能只是对请求数据包的转发、传递，从负载均衡下的节 点服务器来看，接收到的请求还是来自访问负载均衡器的客户端的真实用户;而反向代理就不一样了，反向代理服务器在接收访问用户请求后，会代理用户 重新发起请求代理下的节点服务器， 最后把数据返回给客户端用户。在节点服务器看来，访问的节点服务器的客户端用户就是反向代 理服务器，而非真实的网站访问用户。

ngx_http_upstream_module 是负载均衡模块，可以实现网站的负载均衡功能即节点的健康检 查，upstream 模块允许 Nginx 定义一组或多组节点服务器组，使用时可通过 proxy_pass 代理方 式把网站的请求发送到事先定义好的对应 Upstream 组 的名字上。

upstream lvsServer{
   server 191.168.1.11 weight=5 ;
   server 191.168.1.22:82;
   server example.com:8080 max_fails=2 fail_timeout=10s backup; #域名的话需要解析的哦，内网记得 hosts
}

proxy_pass 指令属于 ngx_http_proxy_module 模块，此模块可以将请求转发到另一台服务器， 在实际的反向代理工作中，会通过 location 功能匹配指定的 URI，然后把接收到服务匹配 URI 的 请求通过 proyx_pass 抛给定义好的 upstream 节点池。

location /download/ {
   proxy_pass http://download/vedio/;
}