高并发与负载均衡——网络TCP-IP基础知识

一、网络分层

1.七层(接口):解耦,便于开发

应用层:

  • 7.应用层:nginx,软件,浏览器,DNS
  • 6.表示层

传输层:

  • 5.会话层
  • 4.传输层:lvs负载均衡

网络层:

  • 3.网络层

链路层

  • 2.链路层
  • 1.物理层 

2.四层:TCP/IP协议,OSI 7L参考模型对7层的简化分层和实现

举例:GET / www.baidu.com/

1.应用层(应用层+表示层糅合):对数据与字符串的封装

  • http:字符串书写格式与两端方法的交互方式的定义
  • smtp
  • ssh

4.传输层(会话层+传输层糅合)控制):[三次握手>>(传输数据)>>四次挥手]

  • 连接的定义:非物理的连接,是逻辑连接,是一种状态的确认(对TCP来说,就是三次握手的状态确认)
  • tcp:面向连接(状态)的可靠传输协议
    • 过程:客户端和服务端通信,客户端从65535个端口号中申请一个端口号和服务器固定端口进行通信(一般来说是80端口),三次握手成功后,客户端和服务端会各自开辟一个线程来进行通信。所以高并发问题会产生在线程数量和线程池方面。
  • udp:不是面向连接的,不可靠的
  • socket:   IP:PORT-IP:PORT
  •          -netstat  -natp

5.网络层:192.168.9.11

  • ip.icmp
  • ROUTE:下一跳
  •       -route   -n

6.链路层(链路层+物理层糅合):

  • 以太网:Ethernet:MAC
  • ARP:全F,两点通信,交换机学习
    • arp -a

高并发与负载均衡——网络TCP-IP基础知识_第1张图片

高并发与负载均衡——网络TCP-IP基础知识_第2张图片

nginx:负载5w台,处在应用层需要在传输层建立三次握手后才能进行应用层数据解析和负载

lvs负载均衡:负载10w台,工作在传输层在三次握手>>数据传输>>四次挥手的整个过程中都可以监视数据包的状态,来进行快速的负载均衡,但是由于lvs没有权限观看应用层数据,所以属于瞎子负载,不会根据数据包的真实业务需求来进行业务负载可能导致将数据包发送到错误的服务器(不干这个业务的服务器)这时需要nginx和lvs负载搭配使用来可以达到百万级别负载能力。也就是流量先集中在lvs负载均衡服务器,然后这些lvs负载均衡服务器将这些数据发送给它后面的nginx服务器,再由nginx服务器做负载均衡,发送给后台的各种业务功能的tomcat服务器。

 

二、高并发与负载均衡的三种模型推导

1.名词补充

高并发与负载均衡——网络TCP-IP基础知识_第3张图片

2.四层网络对应模型

  • 知识补充:NAT(网络地址/IP转换)

    • S_NAT:数据源地址NAT转换

图1

          高并发与负载均衡——网络TCP-IP基础知识_第4张图片

图2

          高并发与负载均衡——网络TCP-IP基础知识_第5张图片

工作过程

  • 家里上网:假设在192.168.1.1的路由器网关下有192.168.1.88和192.168.1.66两个私有IP地址笔记本,他们要访问百度的公有ip123.123.123.88.他们的数据包会通过四层网络封装发送给广播地址192.168.1.255并由路由器的网关来接收并由路由器通过寻找下一跳的方式最终发送给百度服务器。由于在互联网中,第一点不允许私有ip的存在,一旦发现源数据来自私有IP(192.168.1.88/66就是私有IP),则会丢弃掉该数据包,所以路由器会对私有IP进行转换,将私有IP转换为路由器内部由网络运营商分配给的公网IP也就是18.18.18.8第二点:很有可能两个笔记本在建立连接开始申请的端口号都为21212,那么他们的完整端口号为192.168.1.88:21212和192.168.1.66.21212(图1)。那么在经过路由器的私有到公有IP的转换,两者的转换后的公有IP都为18.18.18.8:21212,那么到时候数据从百度回来后,路由器就不知道应该还给哪个笔记本了,所以路由器会在里面维护一个MAP,来对地址转换做记录(图2),路由器会申请两个不同的端口,例如123与212,分配给两个笔记本(图2).最终两个笔记本的公有IP和端口号为18.18.18.8:123与18.18.18.8:212。这样数据包从百度服务器送回的时候,就可以根据MAP中的数据来区分应该送回给哪个笔记本了。这样的地址转换过程,称之为S_NAT地址转换。
  • 虚拟机上网:虚拟机如果想要访问百度,则虚拟机的宿主机先通过S_NAT将虚拟机的IP地址和端口号转换成宿主机的网卡IP地址,然后通过宿主机网卡再发送给路由器,路由器再经过S_NAT转换发送给百度服务器。
  • 拓扑简略图

高并发与负载均衡——网络TCP-IP基础知识_第6张图片

负载均衡器只做转发,不做三次握手,并保证三次握手>>数据传输>>四次挥手之间整体的过程完整统一,不被切分。

这里的四层负载均衡是一个简单实现,后台的Server是集群式部署而不是分布式部署,所以存储容量并没有提升。

  • 具体实施

    • D_NAT:目标地址转换

图3

高并发与负载均衡——网络TCP-IP基础知识_第7张图片

 

工作原理:客户端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来做,来降低负载均衡服务器的下行压力,于是有了下面的模型。

  • 改善后的具体实施:DR模型——直接路由模型

图4

高并发与负载均衡——网络TCP-IP基础知识_第8张图片

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的下一跳)。

  • DR模型的再改善:TUN隧道模型——突破DR模型物理限制(LVS与RealServer必须在同一局域网下,也就是同一个区域下)

图5

高并发与负载均衡——网络TCP-IP基础知识_第9张图片

工作原理:就是在IP层封装两层,最好理解TUN隧道技术的就是VPN,我们要访问VIP,那么客户端数据包通过路由转发到了负载均衡服务器,负载均衡服务器再在CIP_VIP外层包一层IP层信息DIP_RIP,则DIP与RIP之间通过配置好的隧道技术可以通信了。这就是VPN的原理,我们(CIP)如果要访问美国(RIP),那么我们会先访问香港(VIP),香港再访问美国。

 

你可能感兴趣的:(大数据,负载均衡,计算机网络)