应用层:
传输层:
网络层:
链路层
举例:GET / www.baidu.com/
1.应用层(应用层+表示层糅合):对数据与字符串的封装
4.传输层(会话层+传输层糅合)(控制):[三次握手>>(传输数据)>>四次挥手]
5.网络层:192.168.9.11
6.链路层(链路层+物理层糅合):
nginx:负载5w台,处在应用层,需要在传输层建立三次握手后才能进行应用层数据解析和负载
lvs负载均衡:负载10w台,工作在传输层,在三次握手>>数据传输>>四次挥手的整个过程中都可以监视数据包的状态,来进行快速的负载均衡,但是由于lvs没有权限观看应用层数据,所以属于瞎子负载,不会根据数据包的真实业务需求来进行业务负载,可能导致将数据包发送到错误的服务器(不干这个业务的服务器),这时需要nginx和lvs负载搭配使用来可以达到百万级别负载能力。也就是流量先集中在lvs负载均衡服务器,然后这些lvs负载均衡服务器将这些数据发送给它后面的nginx服务器,再由nginx服务器做负载均衡,发送给后台的各种业务功能的tomcat服务器。
工作过程:
负载均衡器只做转发,不做三次握手,并保证三次握手>>数据传输>>四次挥手之间整体的过程完整统一,不被切分。
这里的四层负载均衡是一个简单实现,后台的Server是集群式部署而不是分布式部署,所以存储容量并没有提升。
工作原理:客户端CIP通过TCP/IP访问负载均衡服务器VIP(也就是负载均衡服务器),然后负载均衡服务器再将客户端的数据包发送给真实服务器Server(RIP),但是由于客户端的目标是VIP,而不是RIP,那么RIP在拿到CIP_VIP的数据包后,由于发现其本身RIP与数据包目标VIP不同,那么服务器会丢弃掉这个数据包。那么握手就不能够建立起来了。所以在这个过程中,负载均衡服务器会将客户端的CIP_VIP数据包监视并修改为CIP_RIP数据包(原理类似S_NAT),并自己内部维护一个MAP来记录修改前的地址与修改后的地址以便数据会回送给客户端(将CIP_RIP的ip对应关系改回CIP_VIP的对应关系,如果不这样做的话,CIP_RIP的数据包直接发送给客户端,那么客户端发现和自己建立的CIP_VIP连接的IP对应关系不对应,则会丢弃改数据包),之后将CIP_RIP数据包发送给RIP,这个修改目标IP的转换,称之为D_NAT。
不足:所有的数据都是通过网线发送的,我们假设客户端有10000个,负载均衡服务器一个,server两个分别负载5000,首先我们要明确一个概念,网络的上行速度和下行速度是不一样的,换句话说,我们访问百度,只需要包装一个几百字节的数据包给服务器(上行),而服务器返回给我们html网页则是很大的,可能几个MB(下行),那么如果我们负载均衡服务器的网线带宽不够,能承受上行而不能承受如此高并发的下行(也就是说能经受访问,但是经受不了数据都从负载均衡服务器回送给客户端)。那么,速度还是很慢的,所以这时候我们想,下行这件事情不由负载均衡来干,由真实服务器RIP来做,来降低负载均衡服务器的下行压力,于是有了下面的模型。
PS:一台机器是可以配置两个IP的,IP对外网和公网是唯一不同的。我们的负载均衡服务器VIP为公网IP,配置在eth0的子接口eth0:2下,私网IP为DIP,确保和RealServer在同一网段下,配置在eth0接口下,我们可以通过ifconfig指令来查看。
关键点:
1.IP冲突问题:为了能够让RIP向客户端发送数据,则Server(RIP)的IP应该为VIP,这样才会匹配客户端的CIP_VIP请求数据包。但是RealServer的IP已经是RIP了并且IP必须是唯一的,而且负载均衡服务器的IP也是VIP,那么就不符合IP唯一的规则。解决办法是在RealServer中配置一个隐含IP为VIP(图4中的*VIP),且该隐含IP只对自己可见,对外网公网不可见,保证了IP地址对外和公网的唯一性,那么就可以实现向客户端回送数据包VIP_CIP。,并且解决了IP冲突的问题。
2.数据包发送问题:在解决了IP冲突问题后,还存在一个问题就是数据包循环问题,当负载均衡服务器收到CIP_VIP的数据包后,它会根据自己的路由表进行负载均衡,但是发现自己本身就是VIP,所以会将这个数据包又直接发给自己,不会做负载均衡。解决这一问题是要干扰负载均衡器,将CIP_VIP数据包进行一个加工,将数据包的目标MAC地址,拼接成RealServer(RIP)的MAC地址:CIP_VIP+RIP_MAC。也就是说与D_NAT不同,D_NAT是更改IP地址将CIP_VIP变成CIP_RIP发送给RealServ-er,是IP层做的工作;而我们现在做的工作是IP层的目标IP不做改动,将链路层的MAC地址由负载均衡的MAC地址修改成RealServer的MAC地址。
3.局域网局限性问题:在解决了1和2之后,还是有问题,就是负载均衡服务器和RealServer必须在同一网段,也就是在同一个局域网下。如果不在同一个局域网下的话,那么负载均衡和RealServer之间相当于是互联网了,那么数据包从负载均衡要走到RealServer的过程是要经过路由判定的,要经过多个跳跃寻找网关了。而路由判定是IP层的工作,那么在IP层,MAC地址是要被替代的,那么根据路由最近判定原则,在第二跳MAC地址又会被刷新覆盖为负载均衡服务器的IP地址,那么数据包又发不出去了,被送回到负载均衡服务器。
4.后端RealServer不能使用NAT模式:在解决了1,2,3后,CIP_VIP+RIP_MAC的数据包终于发送到了RealServer。RealServer在确认后将同样以Tcp/IP的方式发送给客户端,这时候不能使用NAT模式了,因为NAT模式会更改IP地址,将导致客户端因为IP地址不匹配同样不会接受数据包。所以RealServer不能以连接路由或者交换机的方式接入互联网,要直接连网线接入互联网。所以RealServer的默认网关应该直接指向运营商(ISP),并有一个公网IP地址(PIP,也就是RealServer的下一跳)。
工作原理:就是在IP层封装两层,最好理解TUN隧道技术的就是VPN,我们要访问VIP,那么客户端数据包通过路由转发到了负载均衡服务器,负载均衡服务器再在CIP_VIP外层包一层IP层信息DIP_RIP,则DIP与RIP之间通过配置好的隧道技术可以通信了。这就是VPN的原理,我们(CIP)如果要访问美国(RIP),那么我们会先访问香港(VIP),香港再访问美国。