1.四层负载均衡工作在OSI模型中的四层，即传输层。四层负载均衡只能根据报文中目标地址和源地址对请求进行转发，而无法修改或判断所请求资源的具体类型，然后经过负载均衡内部的调度算法转发至要处理请求的服务器。四层负载均衡单纯的提供了终端到终端的可靠连接，并将请求转发至后端，连接至始至终都是同一个。LVS就是很典型的四层负载均衡。
2.七层负载均衡工作在OSI模型的第七层应用层，所以七层负载均衡可以基于请求的应用层信息进行负载均衡，例如根据请求的资源类型分配到后端服务器，而不再是根据IP和端口选择。七层负载均衡的功能更丰富更灵活，也能使整个网络更智能。如上图所示，在七层负载均衡两端(面向用户端和服务器端)的连接都是独立的。
3.简言之，四层负载均衡就是基于IP+端口实现的。七层负载均衡就是通过应用层资源实现的。
什么是并发、并行、阻塞、异步、同步 并发/并行: CPU在执行多个任务时的方式，并发表示同一段时间里面有多个进程在同一CPU执行，在极短的时间互相切换使人不会发觉。并行只会出现在多个CPU的情况下，表示同一时刻之内有多个进程在执行
例子： 在开车的时候有个电话，必须停下车才可以接电话，接完电话继续开车，这就是并发。 如果一边开车一遍接电话，这就是并行
同步/异步: 关注的是请求和响应的通讯机制，描述的是被调用方。当发出请求后，该请求是否等待结果后再返回，同步就是没有得到结果前不会返回，返回即得到请求结果。异步就是得到发出请求后就直接返回，也可能不会立即得到结果，服务得到结果后再通过通知或者回调函数等方法通知调用者
例子: 去买咖啡，付了钱在前台等待咖啡制作完毕，就是同步，付了钱不在前台等待，找位置坐下，服务员送过来就是异步
阻塞/非阻塞: 关注的是请求在等待结果时的状态，描述的是调用方。 阻塞就是在等待结果的时候，当前线程会被挂起，在得到结果之后返回；非阻塞则是没有得到结果之前也不会阻塞当前线程
例子: 阻塞的情况就是卖咖啡的时候什么都不能做，只能挂起；非阻塞的时候就是在等咖啡的时候可以玩着手机，过一会检查咖啡是否好了
OSI七层
【1】物理层：主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流（就是由1、0转化为电流强弱来进行传输,到达目的地后在转化为1、0，也就是我们常说的数模转换与模数转换），这一层的数据叫做比特。
【2】数据链路层：定义了如何让格式化数据以进行传输，以及如何让控制对物理介质的访问，这一层通常还提供错误检测和纠正，以确保数据的可靠传输。
【3】网络层：在位于不同地理位置的网络中的两个主机系统之间提供连接和路径选择，Internet的发展使得从世界各站点访问信息的用户数大大增加，而网络层正是管理这种连接的层。
【4】传输层：定义了一些传输数据的协议和端口号（WWW端口80等），如：TCP（传输控制协议，传输效率低，可靠性强，用于传输可靠性要求高，数据量大的数据），UDP（用户数据报协议，与TCP特性恰恰相反，用于传输可靠性要求不高，数据量小的数据，如QQ聊天数据就是通过这种方式传输的）， 主要是将从下层接收的数据进行分段和传输，到达目的地址后再进行重组，常常把这一层数据叫做段。
【5】会话层：通过传输层（端口号：传输端口与接收端口）建立数据传输的通路，主要在你的系统之间发起会话或者接受会话请求（设备之间需要互相认识可以是IP也可以是MAC或者是主机名）。
【6】表示层：可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。例如，PC程序与另一台计算机进行通信，其中一台计算机使用扩展二一十进制交换码（EBCDIC），而另一台则使用美国信息交换标准码（ASCII）来表示相同的字符。如有必要，表示层会通过使用一种通格式来实现多种数据格式之间的转换。
【7】应用层： 是最靠近用户的OSI层，这一层为用户的应用程序（例如电子邮件、文件传输和终端仿真）提供网络服务。
TCP/IP 四层
应用层：负责向用户提供应用程序，比如HTTP、FTP、Telnet、DNS、SMTP等。 传输层：负责对报文进行分组和重组，并以TCP或UDP协议格式封装报文。 网络层：负责路由以及把分组报文发送给目标网络或主机。 链路层：负责封装和解封装IP报文，发送和接受ARP/RARP报文等 下面的是两者之间的对比:
两者比较图
TOP参数解释
第一行 分别显示：系统当前时间 系统运行时间 当前用户登陆数 系统负载。
系统负载（load average），这里有三个数值，分别是系统最近1分钟，5分钟，15分钟的平均负载。一般对于单个处理器来说，负载在0 — 1.00 之间是正常的，超过1.00就要引起注意了。在多核处理器中，你的系统均值不应该高于处理器核心的总数。
第二行 分别显示：total进程总数、 running正在运行的进程数、 sleeping睡眠的进程数、stopped停止的进程数、 zombie僵尸进程数。
第三行
分别显示：
%us用户空间占用CPU百分比、
%sy内核空间占用CPU百分比、
%ni用户进程空间内改变过优先级的进程占用CPU百分比、
%id空闲CPU百分比、
%wa等待输入输出（I/O）的CPU时间百分比 、
%hi指的是cpu处理硬件中断的时间、%si指的是cpu处理软中断的时间 、
%st用于有虚拟cpu的情况，用来指示被虚拟机偷掉的cpu时间。
通常id%值可以反映一个系统cpu的闲忙程度。
第四行 MEM ：total 物理内存总量、 used 使用的物理内存总量、free 空闲内存总量、 buffers 用作内核缓存的内存量。
第五行 SWAP：total 交换区总量、 used使用的交换区总量、free 空闲交换区总量、 cached缓冲的交换区总量。
buffers和cached的区别需要说明一下，buffers指的是块设备的读写缓冲区，cached指的是文件系统本身的页面缓存。它们都是linux操作系统底层的机制，目的就是为了加速对磁盘的访问。
第六行 PID(进程号)、 USER（运行用户）、PR（优先级）、NI（任务nice值）、VIRT（虚拟内存用量）VIRT=SWAP+RES 、RES（物理内存用量）、SHR（共享内存用量）、S（进程状态）、%CPU（CPU占用比）、%MEM（物理内存占用比）、TIME+（累计CPU占 用时间)、 COMMAND 命令名/命令行。
下面简单介绍top命令的使用方法：
top [-] [d] [p] [q] [c] [C] [S] [s] [n]
运维必会！
参数说明
d指定每两次屏幕信息刷新之间的时间间隔。当然用户可以使用s交互命令来改变之。
p通过指定监控进程ID来仅仅监控某个进程的状态。
q该选项将使top没有任何延迟的进行刷新。如果调用程序有超级用户权限，那么top将以尽可能高的优先级运行。
S指定累计模式。
s使top命令在安全模式中运行。这将去除交互命令所带来的潜在危险。
i使top不显示任何闲置或者僵死进程。
c显示整个命令行而不只是显示命令名。
下面介绍在top命令执行过程中可以使用的一些交互命令
从使用角度来看，熟练的掌握这些命令比掌握选项还重要一些。
这些命令都是单字母的，如果在命令行选项中使用了s选项，则可能其中一些命令会被屏蔽掉。
Ctrl+L 擦除并且重写屏幕。
h或者? 显示帮助画面，给出一些简短的命令总结说明。
k 终止一个进程。系统将提示用户输入需要终止的进程PID，以及需要发送给该进程什么样的信号。一般的终止进程可以使用15信号；如果不能正常结束那就使用信号9强制结束该进程。默认值是信号15。在安全模式中此命令被屏蔽。
i 忽略闲置和僵死进程。这是一个开关式命令。
q 退出程序。
r 重新安排一个进程的优先级别。系统提示用户输入需要改变的进程PID以及需要设置的进程优先级值。输入一个正值将使优先级降低，反之则可以使该进程拥有更高的优先权。默认值是10。
s 改变两次刷新之间的延迟时间。系统将提示用户输入新的时间，单位为s。如果有小数，就换算成m s。输入0值则系统将不断刷新，默认值是5 s。需要注意的是如果设置太小的时间，很可能会引起不断刷新，从而根本来不及看清显示的情况，而且系统负载也会大大增加。
f或者F 从当前显示中添加或者删除项目。
o或者O 改变显示项目的顺序。
l 切换显示平均负载和启动时间信息。
m 切换显示内存信息。
t 切换显示进程和CPU状态信息。
c 切换显示命令名称和完整命令行。
M 根据驻留内存大小进行排序。
P 根据CPU使用百分比大小进行排序。
T 根据时间/累计时间进行排序。
W 将当前设置写入~/.toprc文件中。这是写top配置文件的推荐方法。
Shift+M 可按内存占用情况进行排序。
503 服务不可用
404 未找到
499 客户端主动断开了连接
500 服务器内部错误
504 网关超时
301 永久转移
302 临时转移
load average的含义
系统负载是系统CPU繁忙程度的度量，即有多少进程在等待被CPU调用(进程等待队列的长度)
Linux系统中的Load对当前CPU工作量的度量，简单的来说是进程队列的长度。
Load Average就是一段时间(1分钟、5分钟、15分钟)内系统的平均Load
如何查看Load Average
top、w、uptime
这些工具的平均负载是从/proc/loadvg文件读取的，也可以直接使用cat命令查看
[root@abcdocker ~]# cat /proc/loadavg 0.02 0.12 0.16 1/214 12861
ssl握手过程 基于RSA握手和密钥交换的客户端验证服务器为实例详解TLS/SSL握手过程
1.client_hello
客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息
2.server_hello+server_certificate+server_hello_done
server_hello 服务器返回协商的信息结果，包括使用的协议版本version,选择的加密套件ciphersuite，选择的压缩算法compression method、随机数random_S等，其中随机数用于后续的密钥协商；server_certificates 服务端配置对应的证书链，用于身份验证与密钥交换；server_hello_done 通知客户端server_hello信息发送结束；
3.证书效验
客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错情情况下不同做出提示和操作
4.client_key_exchange+change_cipher_spec+encrypted_handshake_message
(a) client_key_exchange，合法性验证通过之后，客户端计算产生随机数字 Pre-master，并用证书公钥加密，发送给服务器;
(b) 此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，计算得到协商密钥;
enc_key=Fuc(random_C, random_S, Pre-Master)
© change_cipher_spec，客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;
(d) encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证;
5.change_cipher_spec+encrypted_handshake_message
(a) 服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);
(b) 计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;
© change_cipher_spec, 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;
(d) encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端;
6.握手结束
客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成;
7.加密通信
开始使用协商密钥与算法进行加密通信。
关于SSL加密协议可以参考https://www.cnblogs.com/barrywxx/p/8570715.html
tcp和udp的区别 相同点
UDP协议和TCP协议都是传输层协议
TCP (Transmission Control Protocol，传输控制协议)提供的是面向连接，可靠的字节流服务。即客户端和服务器交换数据前，必须先在双方之间建立一个TCP连接，之后才能传输数据。并且提供超时重发，丢弃重复数据，校验数据，流量控制等功能，保证数据能从一端传到另外一端
UDP (User Data Protocol,用户数据报协议)是一个简单的面向数据报的传输层协议。它不提供可靠性，只是把应用程序传给IP层的数据报发送出去，但是不能保证它们能到达目的地。由于UDP在传输数据报前不用再客户端和服务器之间建立一个连接，且没有超时重发等机制，所以传输速度很快。
不同点
报头不同特点不同协议不同
UDP数据报最大长度64K(包含UDP头部)，如果数据长度超过64K就需要在应用层手动分包，UDP无法保证包序，需要在应用层进行编号
特点
1.无连接: 知道对端的IP和端口号就可以进行传输，不需要建立连接
2.不可靠：没有确认机制，没有重传机制；如果因为网络故障该段无法发到对方，UDP协议层也不会给应用层返回任何错误信息
3.面向数据报：不能够灵活的控制读写数据的次数和数量，应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并
4.数据不够灵活，但是能够明确区分两个数据报，避免粘包问题
UDP相关协议
NFS
TFTP
DHCP
BOOTP
DNS
TCP则需要建立TCP三次握手，在断开请求时需要TCP四次断开
特点
1.可靠性传输
2.面向字节流
TCP相关协议
HTTP
HTTPS
SSH
Telnet
FTP
SMTP
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接
握手之前主动打开连接的客户端结束CLOSED阶段，被动打开的服务器端也结束CLOSED阶段，并进入LISTEN阶段。随后开始“三次握手”：
(1) 首先客户端向服务器端发送一段TCP报文，其中：
标记位为SYN，表示“请求建立新连接”;序号为Seq=X（X一般为1）；随后客户端进入SYN-SENT阶段。
(2) 服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段。并返回一段TCP报文，其中：
标志位为SYN和ACK，表示“确认客户端的报文Seq序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接”（即告诉客户端，服务器收到了你的数据）；
序号为Seq=y；确认号为Ack=x+1，表示收到客户端的序号Seq并将其值加1作为自己确认号Ack的值；随后服务器端进入SYN-RCVD阶段。
(3) 客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文。其中：
标志位为ACK，表示“确认收到服务器端同意连接的信号”（即告诉服务器，我知道你收到我发的数据了）；序号为Seq=x+1，表示收到服务器端的确认号Ack，并将其值作为自己的序号值；确认号为Ack=y+1，表示收到服务器端序号Seq，并将其值加1作为自己的确认号Ack的值；
随后客户端进入ESTABLISHED阶段。服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段。
在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性。一旦出现某一方发出的TCP报文丢失，便无法继续”握手”，以此确保了”三次握手”的顺利完成。
为什么要进行第三次握手为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
由于网络传输是有延时的(要通过网络光纤和各种中间代理服务器)，在传输的过程中，比如客户端发起了SYN=1创建连接的请求(第一次握手)。
如果服务器端就直接创建了这个连接并返回包含SYN、ACK和Seq等内容的数据包给客户端，这个数据包因为网络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包。
客户端可能设置了一个超时时间，时间到了就关闭了连接创建的请求。再重新发出创建连接的请求，而服务器端是不知道的，如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话，
服务器端是不知道客户端有没有接收到服务器端返回的信息的。
TCP 四次挥手 所谓的四次挥手即TCP连接的释放(解除)。连接的释放必须是一方主动释放，另一方被动释放。以下为客户端主动发起释放连接的图解
挥手之前主动释放连接的客户端结束ESTABLISHED阶段。随后开始“四次挥手”：
(1) 首先客户端想要释放连接，向服务器端发送一段TCP报文，其中：
标记位为FIN，表示“请求释放连接“；序号为Seq=U；随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。
(2) 服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中：
标记位为ACK，表示“接收到客户端发送的释放连接的请求”；序号为Seq=V；确认号为Ack=U+1，表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值；随后服务器端开始准备释放服务器端到客户端方向上的连接。客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段
前”两次挥手”既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了
(3) 服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文，其中：
标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。序号为Seq=W；确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值。随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。
(4) 客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：
标记位为ACK，表示“接收到服务器准备好释放连接的信号”。序号为Seq=U+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值。确认号为Ack=W+1；表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值。随后客户端开始在TIME-WAIT阶段等待2MSL
**为什么要客户端要等待2MSL呢 **
服务器端收到从客户端发出的TCP报文之后结束LAST-ACK阶段，进入CLOSED阶段。由此正式确认关闭服务器端到客户端方向上的连接。
客户端等待完2MSL之后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。
后“两次挥手”既让客户端知道了服务器端准备好释放连接了，也让服务器端知道了客户端了解了自己准备好释放连接了。于是，可以确认关闭服务器端到客户端方向上的连接了，由此完成“四次挥手”。
与“三次挥手”一样，在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便无法继续”挥手”，以此确保了”四次挥手”的顺利完成。
TCP连接状态LISTEN 监听来自远方的TCP端口的连接请求SYN-SENT 再发送连接请求后等等匹配的连接请求(客户端)SYN-RECEIVED 再收到和发送一个连接请求后等等对方连接请求的确认 (服务器)ESTABLISHED 代表一个打开的连接FIN-WAIT-1 等待远程TCP连接中端请求，或先前的连接中断请求的确认FIN-WAIT-2 从远程TCP等待连接中断请求CLOSING 等待远程TCP对连接中断的确认LAST-ACK 等待原来的发向远程TCP的连接中断请求的确认TIME-WAIT 等待足够的实际以确保远程TCP连接收到中断请求的确认CLOSED 没有任何连接状态#查看服务器连接ss -ant | awk 'NR>1 {++s[$1]} END {for(k in s) print k,s[k]}'
主动端可能出现的状态: FIN_WAIT1、FIN_WAIT2、CLOSING、TIME_WAIT
被动端可能出现的状态: CLOSE_WAIT LAST_ACK
以下Shell 参数含义
$$ Shell本身的PID（ProcessID） $! Shell最后运行的后台Process的PID $? 最后运行的命令的结束代码（返回值） $- 使用Set命令设定的Flag一览 $* 所有参数列表。如"$*"用「"」括起来的情况、以"$1 $2 … $n"的形式输出所有参数。 $@ 所有参数列表。如"$@"用「"」括起来的情况、以"$1" "$2" … "$n" 的形式输出所有参数。 $# 添加到Shell的参数个数 $0 Shell本身的文件名 $1～$n 添加到Shell的各参数值。$1是第1参数、$2是第2参数…。#在脚本中添加set -x可以进行每一行的调试