网络及负载均衡

四层和七层区别（不明白就这样去理解，七层最常见就是应用层的http，也就是url，四层是传输层，为tcp/udp端口）

应用层：建立链接 socket ： fd文件描述符

三次握手 确认连接走完之后，开辟线程，开辟资源 四次挥手 处理线程、处理资源

传输控制层：tcp、udp 创建握手包

eth0 ： ip(局域网) net地址：掩码 gateway dns

三层：网络层：下一跳机制：不存储全部的拓扑图，只存部分 这是就用到了路由表 route 按位与运算判定路由，下一跳就是gateway，通过网卡扔出去

二层：链路层协议：到了这个下一跳，拿到对应的mac地址，传到下一个，重新拿mac地址，去访问目标ip

也就是说：

应用层是完成内核的端口映射，准备建立链接

到达内核：传输层拿到了要访问的端口对应的进程，网络层拿到了ip，链路层拿到了mac地址

扩展：

电磁传播会衰减、光传播距离远，带宽频率高

解决高并发：负载均衡

tomcat、nginx都是应用层， nginx在tomcat之上，先访问nginx在访问tomcat

nginx是反向代理，是需要握手的，nginx并发是有上线的

如果我不走7层，只做转发速度就提上来了，lvs应运而生：做数据包转发，不和客户端握手

Lvs：做数据包转发，不和客户端握手

lvs：hold住流量 nginx：hold住握手 收到请求分流到tomcat

nginx是七层的

NAT模式：

cip:client ip

vip：lvsip 虚拟ip

dip： lvs传出去的

Rip ： tomcat ReaIIp

network address：nat路由器

路由器也会维护一个mac表：用来解决同时发送

所以lvs存在瓶颈：NAT 请求和响应对经过LVS

总结：NAT就是做响应的ip转换，达到映射的解决方案，基于四层的

DR模式:不修改ip地址，请求经过lvs，影响不经过lvs

链路层：还有mac地址

Tun隧道模式：NAT不是最快的，DR物理位置被约束着(必须是局域网)，Tun结合两者优点

拨号还是pppoe(pppoe就是包裹)、vpn

负载均衡实践：LVS

Linux Virtual Server 1998年诞生

K8s外部访问流程图

nginx：服务端与nginx三次握手建立链接，nginx解析url，反向代理(nginx与服务器三次握手建立链接)，如果代理多台服务器，做负载均衡

keepalive：为了解决中间的负载均衡挂了 或 有部分server挂了

解决负载均衡单点故障问题

解决部分real server挂了

解决思路：一变多：主备、主主、主主备

扩展：主备、主从

追求自动化：把人解耦出去：用程序替代 keepalived就是一个程序

我理解很像redis 的哨兵模式，哨兵做监听