N35-第十七周作业

1、简述LVS的几种模式及特点

有四种模式：
NAT:地址转换 这个是通过网络地址转换的方法来实现调度的。首先调度器(LB)接收到客户的请求数据包时（请求的目的IP为VIP），根据调度算法决定将请求发送给哪个后端的真实服务器（RS）。然后调度就把客户端发送的请求数据包的目标IP地址及端口改成后端真实服务器的IP地址（RIP）,这样真实服务器（RS）就能够接收到客户的请求数据包了。真实服务器响应完请求后，查看默认路由（NAT模式下我们需要把RS的默认路由设置为LB服务器。）把响应后的数据包发送给LB,LB再接收到响应包后，把包的源地址改成虚拟地址（VIP）然后发送回给客户端。
NAT模式优缺点：

1、NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写，因此网站访问量比较大的时候LB负载均衡调度器有比较大的瓶颈，一般要求最多之能10-20台节点

2、只需要在LB上配置一个公网IP地址就可以了。

3、每台内部的节点服务器的网关地址必须是调度器LB的内网地址。

4、NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。

TUN模式： 隧道模式 采用NAT模式时，由于请求和响应的报文必须通过调度器地址重写，当客户请求越来越多时，调度器处理能力将成为瓶颈。为了解决这个问题，调度器把请求的报文通过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。这样调度器就只处理请求入站报文，由于一般网络服务应答数据比请求报文大很多，采用VS/TUN模式后，集群系统的最大吞吐量可以提高10倍。

 优点：负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。

缺点：隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分Linux系统上。

DR模式：直接路由模式
DR模式是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器响应后的处理结果直接返回给客户端用户。同TUN模式一样，DR模式可以极大的提高集群系统的伸缩性。而且DR模式没有IP隧道的开销，对集群中的真实服务器也没有必要必须支持IP隧道协议的要求。但是要求调度器LB与真实服务器RS都有一块网卡连接到同一物理网段上，必须在同一个局域网环境。
1、通过在调度器LB上修改数据包的目的MAC地址实现转发。注意源地址仍然是CIP，目的地址仍然是VIP地址。

2、请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此并发访问量大时使用效率很高（和NAT模式比）

3、因为DR模式是通过MAC地址改写机制实现转发，因此所有RS节点和调度器LB只能在一个局域网里面

4、RS主机需要绑定VIP地址在LO接口上，并且需要配置ARP抑制。

5、RS节点的默认网关不需要配置成LB，而是直接配置为上级路由的网关，能让RS直接出网就可以。

6、由于DR模式的调度器仅做MAC地址的改写，所以调度器LB就不能改写目标端口，那么RS服务器就得使用和VIP相同的端口提供服务。

LVS-FULLNAT转发模式

在大规模的网络下，在淘宝的业务中，官方LVS满足不了需求；原因有3点，
1) 刚才讲三种转发模式，部署成本比较高；
2) 和商用的负载均衡比，LVS没有DDOS防御***功能；
3) 主备部署模式，性能无法扩展；一个VIP下的流量特别大怎么办？

FULLNAT原理：
FULLNAT转发数据包是类似NAT模式，IN和OUT数据包都是经过LVS；唯一的区别：后端RealServer 或者交换机不需要做任何配置。
FULLNAT的主要原理是引入local address（内网ip地址），cip-vip转换为lip->rip，而 lip和rip均为IDC内网ip，可以跨vlan通讯

2、用图例和文字说明正向代理和反向代理的区别
正向代理，意思是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理。
和反向代理不同之处在于，典型的正向代理是一种最终用户知道并主动使用的代理方式。例如Chrome浏览器中安装了switchysharp以后，通过switchysharp方便地进行代理转发服务。而为此用户必须要提前在switchysharp中做好设置才能达到相应的效果。
反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

3、用DR模型实现http负载均衡集群

4、简述下述规则的意义
iptables-N clean_in
新建一条名为clean_in的自定义链
iptables-A clean_in-d 255.255.255.255 -p icmp-j DROP
在名为clean_in的自定义链上丢弃目标IP为 255.255.255.255 且 协议为icmp的报文
iptables-A clean_in-d 172.16.255.255 -p icmp-j DROP
在名为clean_in的自定义链上丢弃目标IP为 172.16.255.255 且 协议为icmp的报文
iptables-A clean_in-p tcp! --syn-m state --state NEW -j DROP
在名为clean_in的自定义链上丢弃tcp报文首部的标志位syn不是1，且 请求连接追踪状态为NEW的报文
iptables-A clean_in-p tcp--tcp-flags ALL ALL-j DROP
在名为clean_in的自定义链上丢弃TCP报文首部的标志位都是1的报文
iptables-A clean_in-p tcp--tcp-flags ALL NONE -j DROP
在名为clean_in的自定义链上丢弃TCP报文首部的标志位都是0的报文
iptables-A clean_in-d 172.16.100.7 -j RETURN
在名为clean_in的自定义链上如果有报文的目标IP为172.16.100.7，则直接返回到调用此自定义链的内置链上
iptables-A INPUT -d 172.16.100.7 -j clean_in
如果INPUT链上匹配到了目标地址为172.16.100.7的报文就直接调用自定义链clean_in
iptables-A INPUT -ilo -j ACCEPT
在INPUT链上指定入栈报文经由名为lo的接口设备上流入的放行
iptables-A OUTPUT -o lo -j ACCEPT
在OUTPUT链上指定出栈报文经由名为lo的接口设备上流出的放行
iptables-A INPUT -ieth0 -m multiport -p tcp--dports53,113,135,137,139,445 -j DROP
在INPUT链上指定入栈报文为tcp协议的，且目标端口为53,113,135,137,139,445的经由接口设备名为eth0的丢弃
iptables-A INPUT -ieth0 -m multiport -p udp--dports53,113,135,137,139,445 -j DROP
在INPUT链上指定入栈报文为udp协议的，且目标端口为53,113,135,137,139,445的经由接口设备名为eth0的丢弃
iptables-A INPUT -ieth0 -m multiport -p tcp--dports1433,4899 -j DROP
在INPUT链上将协议为tcp且目标端口为1433,4899的经由接口设备名为eth0流入的入栈报文丢弃
iptables-A INPUT -p icmp-m limit --limit 10/second -j ACCEPT
在INPUT链上放行协议为icmp且最大新建连接为10个每秒

5、简述几种io模型原理与优缺点(至少3种)

1.阻塞IO模型

　　最传统的一种IO模型，即在读写数据过程中会发生阻塞现象。

　　当用户线程发出IO请求之后，内核会去查看数据是否就绪，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，用户线程交出CPU。当数据就绪之后，内核会将数据拷贝到用户线程，并返回结果给用户线程，用户线程才解除block状态。

典型的阻塞IO模型的例子为：

data = socket.read();

如果数据没有就绪，就会一直阻塞在read方法。

2.非阻塞IO模型

　　当用户线程发起一个read操作后，并不需要等待，而是马上就得到了一个结果。如果结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦内核中的数据准备好了，并且又再次收到了用户线程的请求，那么它马上就将数据拷贝到了用户线程，然后返回。

　　所以事实上，在非阻塞IO模型中，用户线程需要不断地询问内核数据是否就绪，也就说非阻塞IO不会交出CPU，而会一直占用CPU。

3.多路复用IO模型

　　多路复用IO模型是目前使用得比较多的模型。Java NIO实际上就是多路复用IO。

　　在多路复用IO模型中，会有一个线程不断去轮询多个socket的状态，只有当socket真正有读写事件时，才真正调用实际的IO读写操作。因为在多路复用IO模型中，只需要使用一个线程就可以管理多个socket，系统不需要建立新的进程或者线程，也不必维护这些线程和进程，并且只有在真正有socket读写事件进行时，才会使用IO资源，所以它大大减少了资源占用。

　　在Java NIO中，是通过selector.select()去查询每个通道是否有到达事件，如果没有事件，则一直阻塞在那里，因此这种方式会导致用户线程的阻塞。

4.信号驱动IO模型

　　在信号驱动IO模型中，当用户线程发起一个IO请求操作，会给对应的socket注册一个信号函数，然后用户线程会继续执行，当内核数据就绪时会发送一个信号给用户线程，用户线程接收到信号之后，便在信号函数中调用IO读写操作来进行实际的IO请求操作。这个一般用于UDP中，对TCP套接口几乎是没用的，原因是该信号产生得过于频繁，并且该信号的出现并没有告诉我们发生了什么事情

5.异步IO模型

　　异步IO模型才是最理想的IO模型，在异步IO模型中，当用户线程发起read操作之后，立刻就可以开始去做其它的事。而另一方面，从内核的角度，当它受到一个asynchronous read之后，它会立刻返回，说明read请求已经成功发起了，因此不会对用户线程产生任何block。然后，内核会等待数据准备完成，然后将数据拷贝到用户线程，当这一切都完成之后，内核会给用户线程发送一个信号，告诉它read操作完成了。也就说用户线程完全不需要关心实际的整个IO操作是如何进行的，只需要先发起一个请求，当接收内核返回的成功信号时表示IO操作已经完成，可以直接去使用数据了。

　　也就说在异步IO模型中，IO操作的两个阶段都不会阻塞用户线程，这两个阶段都是由内核自动完成，然后发送一个信号告知用户线程操作已完成。用户线程中不需要再次调用IO函数进行具体的读写。这点是和信号驱动模型有所不同的，在信号驱动模型中，当用户线程接收到信号表示数据已经就绪，然后需要用户线程调用IO函数进行实际的读写操作；而在异步IO模型中，收到信号表示IO操作已经完成，不需要再在用户线程中调用iO函数进行实际的读写操作。

转载于:https://blog.51cto.com/14086421/2377053