负载均衡模型

一、问题引入

​ 如果有多个用户来访问服务器,要想要减轻服务器的压力,应该怎么办呢?

1. 首先想到的方法就是用多个服务器来分担

   问题:两台计算机通信最终是通过ip,如果客户端连接多台服务器,服务器这里是不能够都配相同的ip地址了(IP冲突),因为这里如果进行三次握手的话也乱了

2. 使用一台服务器,客户端请求它,该服务器再将请求转给另外的几台服务器,只要该服务器足够快就能够解决高并发的问题

   问题:转发给的几台服务器解决慢

   为什么tomcat慢,并发数少呢?

   • 网络层上:

     因为它是7层中的一层,自身就是应用层的,也是最末端的层次,所以通信上面不算最快的,而且想到应用的话传输控制层还要进行3次握手,然后才开辟应用层,CPU开辟资源等操作

   • 开发语言,基于Java开发的,需要JVM

3. 知道为什么服务器会慢,所以负载均衡的服务器就应该快速的发给服务端,就避免握手,就跟网线一样

结论

​ 要想解决高并发,从通信层次我们要避免握手连接,客户端是直接与服务端进行握手的,并且传输控制层只是窥探了端口号,通过端口号来判定是否要将数据包转发给其他的服务器.

基于上述理论,所以我们应该得出这样的服务器,如下图所示.这里服务器是镜像的,对于客户端是不可见的,所以服务器所得到的效果应该是一样

二、基本负载均衡模型

• 语义

  1. CIP-客户端IP
  2. VIP-虚拟IP
  3. DIP-分发IP
  4. RIP-真实IP

• 特点

  1. 四层负载
  2. 数据包转发级别(特别快)
  3. 不会和client握手
  4. 后端服务器是镜像的(相同)

注意: 这里客户端会CIP->VIP,但是server1不会响应,因为它会检查目标地址是否是RIP,如果不是会丢包

三、NAT模型

模拟在家上网的网络模型(Network Address Translation，网络地址转换)-NAT模型,一般是在路由器,左边为内网地址,右边是公网地址

• 场景:
  在家两个人同时访问百度,也就是1.8和1.6同时访问8.8.8.8,

• 过程

  访问过程路由器会随机申请一个端口号并记录内网的ip和端口号然后发给百度,这两个信息的唯一区分就是在端口号上,当请求之后的数据回来的时候在路由器上的表查询,替换对应的信息在返回,从而达到独立通信的目的(如果是替换的原地址,那么就是S-NAT,其中S是source源地址的意思)

四、D-NAT模型

D-NAT(Destination Network Address Translation):目的地址转换

• 特点

  1. 非对称

     客户端发来的请求一般是很小的,但是服务端返回的数据很大,所以是非对称的

  2. 带宽

     来回都经过负载均衡服务器,带宽成为瓶颈

  3. 消耗算力

     请求出去和回来都有地址的转换,所以消耗算力

  4. 要求RS的GW指向负载均衡服务器

• 过程

  CIP->VIP->负载均衡服务器->RIP->地址转换(RIP-CIP)->负载均衡服务器->CIP

• 场景

  常用于防火墙中

五、DR模型

DR模式（直接路由模式:Virtual Server via Direct Routing）

• 特点

  1. 负载均衡服务器暴露VIP,服务器隐藏VIP
  2. 基于2层(链路,物理)
  3. mac地址欺骗
  4. 负载服务器和RS在一跳的距离(负载服务器要和RS在同一局域网)
  5. 直接返回给客户端,没走负载均衡服务器

• 过程

  CIP->VIP->负载均衡服务器(发送的时候拼接RIP的mac地址)->RIP->地址反转(通过隐藏VIP)->CIP

六、TUN模式

TUN 是IP Tunneling ，IP隧道的简称，它将调度器收到的IP数据包封装在一个新的IP数据包中，转交给应用服务器，然后实际服务器的返回数据会直接返回给用户

• 特点

  1. 解决了DR(负载服务器要和RS在同一局域网)和D-NAT模式(网关指向均衡负载服务器)的缺点
  2. 拼接IP数据包,速度极快

• 过程

  CIP->VIP->负载均衡服务器(拼接DIP->RIP数据包)->RIP->解开数据包然后进行地址转换(CIP->VIP通过隐藏VIP)->VIP

• VPN&翻墙