小知识记录：第九篇

Posted 2020-12-20 hrers

1.网卡配置bond
#网卡bond模式
---------------------------------------------------------
Linux 多网卡绑定
网卡绑定mode共有七种(0~6) bond0、bond1、bond2、bond3、bond4、bond5、bond6

常用的有三种
mode=0：平衡负载模式，有自动备援，但需要”Switch”支援及设定。
mode=1：自动备援模式，其中一条线若断线，其他线路将会自动备援。
mode=6：平衡负载模式，有自动备援，不必”Switch”支援及设定。

需要说明的是如果想做成mode 0的负载均衡,仅仅设置这里options bond0 miimon=100 mode=0是不够的,与网卡相连的交换机必须做特殊配置（这两个端口应该采取聚合方式），因为做bonding的这两块网卡是使用同一个MAC地址.从原理分析一下（bond运行在mode 0下）：

mode 0下bond所绑定的网卡的IP都被修改成相同的mac地址，如果这些网卡都被接在同一个交换机，那么交换机的arp表里这个mac地址对应的端口就有多 个，那么交换机接受到发往这个mac地址的包应该往哪个端口转发呢？正常情况下mac地址是全球唯一的，一个mac地址对应多个端口肯定使交换机迷惑了。所以 mode0下的bond如果连接到交换机，交换机这几个端口应该采取聚合方式（cisco称为 ethernetchannel，foundry称为portgroup），因为交换机做了聚合后，聚合下的几个端口也被捆绑成一个mac地址.我们的解 决办法是，两个网卡接入不同的交换机即可。
mode6模式下无需配置交换机，因为做bonding的这两块网卡是使用不同的MAC地址。

七种bond模式说明：
第一种模式：mod=0 ，即：(balance-rr) Round-robin policy（平衡抡循环策略）
特点：传输数据包顺序是依次传输（即：第1个包走eth0，下一个包就走eth1….一直循环下去，直到最后一个传输完毕），此模式提供负载平衡和容错能力；但是我们知道如果一个连接或者会话的数据包从不同的接口发出的话，中途再经过不同的链路，在客户端很有可能会出现数据包无序到达的问题，而无序到达的数据包需要重新要求被发送，这样网络的吞吐量就会下降

第二种模式：mod=1，即： (active-backup) Active-backup policy（主-备份策略）
特点：只有一个设备处于活动状态，当一个宕掉另一个马上由备份转换为主设备。mac地址是外部可见得，从外面看来，bond的MAC地址是唯一的，以避免switch(交换机)发生混乱。此模式只提供了容错能力；由此可见此算法的优点是可以提供高网络连接的可用性，但是它的资源利用率较低，只有一个接口处于工作状态，在有 N 个网络接口的情况下，资源利用率为1/N

第三种模式：mod=2，即：(balance-xor) XOR policy（平衡策略）
特点：基于指定的传输HASH策略传输数据包。缺省的策略是：(源MAC地址 XOR 目标MAC地址) % slave数量。其他的传输策略可以通过xmit_hash_policy选项指定，此模式提供负载平衡和容错能力

第四种模式：mod=3，即：broadcast（广播策略）
特点：在每个slave接口上传输每个数据包，此模式提供了容错能力

第五种模式：mod=4，即：(802.3ad) IEEE 802.3ad Dynamic link aggregation（IEEE 802.3ad 动态链接聚合）
特点：创建一个聚合组，它们共享同样的速率和双工设定。根据802.3ad规范将多个slave工作在同一个激活的聚合体下。
外出流量的slave选举是基于传输hash策略，该策略可以通过xmit_hash_policy选项从缺省的XOR策略改变到其他策略。需要注意的 是，并不是所有的传输策略都是802.3ad适应的，尤其考虑到在802.3ad标准43.2.4章节提及的包乱序问题。不同的实现可能会有不同的适应 性。
必要条件：
条件1：ethtool支持获取每个slave的速率和双工设定
条件2：switch(交换机)支持IEEE 802.3ad Dynamic link aggregation
条件3：大多数switch(交换机)需要经过特定配置才能支持802.3ad模式

第六种模式：mod=5，即：(balance-tlb) Adaptive transmit load balancing（适配器传输负载均衡）
特点：不需要任何特别的switch(交换机)支持的通道bonding。在每个slave上根据当前的负载（根据速度计算）分配外出流量。如果正在接受数据的slave出故障了，另一个slave接管失败的slave的MAC地址。
该模式的必要条件：ethtool支持获取每个slave的速率

第七种模式：mod=6，即：(balance-alb) Adaptive load balancing（适配器适应性负载均衡）
特点：该模式包含了balance-tlb模式，同时加上针对IPV4流量的接收负载均衡(receive load balance, rlb)，而且不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的。bonding驱动截获本机发送的ARP应答，并把源硬件地址改写为bond中某个slave的唯一硬件地址，从而使得不同的对端使用不同的硬件地址进行通信。

来自服务器端的接收流量也会被均衡。当本机发送ARP请求时，bonding驱动把对端的IP信息从ARP包中复制并保存下来。当ARP应答从对端到达 时，bonding驱动把它的硬件地址提取出来，并发起一个ARP应答给bond中的某个slave。使用ARP协商进行负载均衡的一个问题是：每次广播 ARP请求时都会使用bond的硬件地址，因此对端学习到这个硬件地址后，接收流量将会全部流向当前的slave。这个问题可以通过给所有的对端发送更新 （ARP应答）来解决，应答中包含他们独一无二的硬件地址，从而导致流量重新分布。当新的slave加入到bond中时，或者某个未激活的slave重新 激活时，接收流量也要重新分布。接收的负载被顺序地分布（round robin）在bond中最高速的slave上

当某个链路被重新接上，或者一个新的slave加入到bond中，接收流量在所有当前激活的slave中全部重新分配，通过使用指定的MAC地址给每个 client发起ARP应答。下面介绍的updelay参数必须被设置为某个大于等于switch(交换机)转发延时的值，从而保证发往对端的ARP应答 不会被switch(交换机)阻截。

必要条件：
条件1：ethtool支持获取每个slave的速率；
条件2：底层驱动支持设置某个设备的硬件地址，从而使得总是有个slave(curr_active_slave)使用bond的硬件地址，同时保证每个bond 中的slave都有一个唯一的硬件地址。如果curr_active_slave出故障，它的硬件地址将会被新选出来的 curr_active_slave接管

其实mod=6与mod=0的区别：mod=6，先把eth0流量占满，再占eth1，….ethX；而mod=0的话，会发现2个口的流量都很稳定，基本一样的带宽。而mod=6，会发现第一个口流量很高，第2个口只占了小部分流量
---------------------------------------------------------
#操作方法
---------------------------------------------------------
Linux网口绑定
通过网口绑定(bond)技术,可以很容易实现网口冗余，负载均衡，从而达到高可用高可靠的目的。前提约定：
2个物理网口分别是：eth0,eth1
绑定后的虚拟口是：bond0
服务器IP是：192.168.0.100

第一步，配置设定文件：
/etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.0.100
NETMASK=255.255.255.0
NETWORK=192.168.0.0
BROADCAST=192.168.0.255
#BROADCAST广播地址
/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
MASTER=bond0
SLAVE=yes

第二步，修改modprobe相关设定文件，并加载bonding模块：
1.在这里，我们直接创建一个加载bonding的专属设定文件/etc/modprobe.d/bonding.conf
[root@test ~]# vi /etc/modprobe.d/bonding.conf
#追加
alias bond0 bonding
options bonding mode=0 miimon=200
2.加载模块(重启系统后就不用手动再加载了)
[root@test ~]# modprobe bonding
3.确认模块是否加载成功：
[root@test ~]# lsmod | grep bonding
bonding 100065 0

第三步，重启一下网络，然后确认一下状况：
[root@test ~]# /etc/init.d/network restart
[root@test ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
……
[root@test ~]# ifconfig | grep HWaddr
bond0 Link encap:Ethernet HWaddr 00:16:36:1B:BB:74
eth0 Link encap:Ethernet HWaddr 00:16:36:1B:BB:74
eth1 Link encap:Ethernet HWaddr 00:16:36:1B:BB:74
从上面的确认信息中，我们可以看到3个重要信息：
1.现在的bonding模式是active-backup
2.现在Active状态的网口是eth0
3.bond0,eth1的物理地址和处于active状态下的eth0的物理地址相同，这样是为了避免上位交换机发生混乱。
任意拔掉一根网线，然后再访问你的服务器，看网络是否还是通的。

第四步，系统启动自动绑定、增加默认网关：
[root@test ~]# vi /etc/rc.d/rc.local
#追加
ifenslave bond0 eth0 eth1
route add default gw 192.168.0.1
#如可上网就不用增加路由，0.1地址按环境修改.

留心：前面只是2个网口绑定成一个bond0的情况，如果我们要设置多个bond口，比如物理网口eth0和eth1组成bond0，eth2和eth3组成bond1，
那么网口设置文件的设置方法和上面第1步讲的方法相同，只是/etc/modprobe.d/bonding.conf的设定就不能像下面这样简单的叠加了：
alias bond0 bonding
options bonding mode=1 miimon=200
alias bond1 bonding
options bonding mode=1 miimon=200

正确的设置方法有2种：
第一种,你可以看到，这种方式的话，多个bond口的模式就只能设成相同的了：
alias bond0 bonding
alias bond1 bonding
options bonding max_bonds=2 miimon=200 mode=1

第二种，这种方式，不同的bond口的mode可以设成不一样：
alias bond0 bonding
options bond0 miimon=100 mode=1
install bond1 /sbin/modprobe bonding -o bond1 miimon=200 mode=0

仔细看看上面这2种设置方法，现在如果是要设置3个，4个，甚至更多的bond口，你应该也会了吧！

后记：简单的介绍一下上面在加载bonding模块的时候，options里的一些参数的含义：
miimon 监视网络链接的频度，单位是毫秒，我们设置的是200毫秒。
max_bonds 配置的bond口个数
mode bond模式，主要有以下几种，在一般的实际应用中，0和1用的比较多，
---------------------------------------------------------

2.分片上传及断点续传原理
#分片上传，就是将所要上传的文件，按照一定的大小，将整个文件分隔成多个数据块（我们称之为Part）来进行分别上传，上传完之后再由服务端对所有上传的文件进行汇总整合成原始的文件。分片上传不仅可以避免因网络环境不好导致的一直需要从文件起始位置还是上传的问题，还能使用多线程对不同分块数据进行并发发送，提高发送效率，降低发送时间。

分片上传主要适用于以下几种场景：
网络环境不好：当出现上传失败的时候，可以对失败的Part进行独立的重试，而不需要重新上传其他的Part。
断点续传：中途暂停之后，可以从上次上传完成的Part的位置继续上传。
加速上传：要上传到OSS的本地文件很大的时候，可以并行上传多个Part以加快上传。
流式上传：可以在需要上传的文件大小还不确定的情况下开始上传。这种场景在视频监控等行业应用中比较常见。
文件较大：一般文件比较大时，默认情况下一般都会采用分片上传。

分片上传的整个流程大致如下：
将需要上传的文件按照一定的分割规则，分割成相同大小的数据块；
初始化一个分片上传任务，返回本次分片上传唯一标识；
按照一定的策略（串行或并行）发送各个分片数据块；
发送完成后，服务端根据判断数据上传是否完整，如果完整，则进行数据块合成得到原始文件。

#断点续传
由于分片上传的数据是永久性的，因此可以很容易的基于分片上传来实现断点续传。
在分片上传的过程中，如果因为系统崩溃或者网络中断等异常因素导致上传中断，这时候客户端需要记录上传的进度。在之后支持再次上传时，可以继续从上次上传中断的地方进行继续上传。
为了避免客户端在上传之后的进度数据被删除而导致重新开始从头上传的问题，服务端也可以提供相应的接口便于客户端对已经上传的分片数据进行查询，从而使客户端知道已经上传的分片数据，从而从下一个分片数据开始继续上传。

3.traceroute命令
traceroute (Windows 系统下是tracert) 命令利用ICMP 协议定位您的计算机和目标计算机之间的所有路由器。TTL 值可以反映数据包经过的路由器或网关的数量，通过操纵独立ICMP 呼叫报文的TTL 值和观察该报文被抛弃的返回信息，traceroute命令能够遍历到数据包传输路径上的所有路由器。
基于icmp协议，所以需要防火墙或者安全组放开icmp协议，同理mtr命令一样。否则再使用这两个命令后无法看到最后一跳信息。
Traceroute程序的设计是利用ICMP及IP header的TTL（Time To Live）栏位（field）。首先，traceroute送出一个TTL是1的IP datagram（其实，每次送出的为3个40字节的包，包括源地址，目的地址和包发出的时间标签）到目的地，当路径上的第一个路由器（router）收到这个datagram时，它将TTL减1。此时，TTL变为0了，所以该路由器会将此datagram丢掉，并送回一个「ICMP time exceeded」消息（包括发IP包的源地址，IP包的所有内容及路由器的IP地址），traceroute 收到这个消息后，便知道这个路由器存在于这个路径上，接着traceroute 再送出另一个TTL是2 的datagram，发现第2 个路由器...... traceroute 每次将送出的datagram的TTL 加1来发现另一个路由器，这个重复的动作一直持续到某个datagram 抵达目的地。当datagram到达目的地后，该主机并不会送回ICMP time exceeded消息，因为它已是目的地了，那么traceroute如何得知目的地到达了呢？
Traceroute在送出UDP datagrams到目的地时，它所选择送达的port number 是一个一般应用程序都不会用的号码（30000 以上），所以当此UDP datagram 到达目的地后该主机会送回一个「ICMP port unreachable」的消息，而当traceroute 收到这个消息时，便知道目的地已经到达了。所以traceroute 在Server端也是没有所谓的Daemon 程式。

4.DNF
DNF 是新一代的rpm软件包管理器。他首先出现在 Fedora 18 这个发行版中。而最近，它取代了yum，正式成为 Fedora 22 的包管理器。
DNF包管理器克服了YUM包管理器的一些瓶颈，提升了包括用户体验，内存占用，依赖分析，运行速度等多方面的内容。DNF使用 RPM, libsolv 和 hawkey 库进行包管理操作。尽管它没有预装在 CentOS 和 RHEL 7 中，但你可以在使用 YUM 的同时使用 DNF 。你可以在这里获得关于 DNF 的更多知识：《 DNF 代替 YUM ，你所不知道的缘由》
DNF 的最新稳定发行版版本号是 1.0，发行日期是2015年5月11日。 这一版本的额 DNF 包管理器（包括在他之前的所有版本） 都大部分采用 Python 编写，发行许可为GPL v2.
https://ipcmen.com/dnf #使用与yum类似，yum -y install dnf直接安装，注意依赖epel源

5.HTTPS之SNI介绍
早期的SSLv2根据经典的公钥基础设施PKI(Public Key Infrastructure)设计，它默认认为：一台服务器（或者说一个IP）只会提供一个服务，所以在SSL握手时，服务器端可以确信客户端申请的是哪张证书。
但是让人万万没有想到的是，虚拟主机大力发展起来了，这就造成了一个IP会对应多个域名的情况。解决办法有一些，例如申请泛域名证书，对所有*.yourdomain.com的域名都可以认证，但如果你还有一个yourdomain.net的域名，那就不行了。
在HTTP协议中，请求的域名作为主机头（Host）放在HTTP Header中，所以服务器端知道应该把请求引向哪个域名，但是早期的SSL做不到这一点，因为在SSL握手的过程中，根本不会有Host的信息，所以服务器端通常返回的是配置中的第一个可用证书。因而一些较老的环境，可能会产生多域名分别配好了证书，但返回的始终是同一个。
既然问题的原因是在SSL握手时缺少主机头信息，那么补上就是了。
SNI（Server Name Indication）定义在RFC 4366，是一项用于改善SSL/TLS的技术，在SSLv3/TLSv1中被启用。它允许客户端在发起SSL握手请求时（具体说来，是客户端发出SSL请求中的ClientHello阶段），就提交请求的Host信息，使得服务器能够切换到正确的域并返回相应的证书。
要使用SNI，需要客户端和服务器端同时满足条件，幸好对于现代浏览器来说，大部分都支持SSLv3/TLSv1，所以都可以享受SNI带来的便利。

总结：如果支持SNI扩展，并且配置了SNI扩展可以支持配置多个server服务，并且可以使用同一个证书，因为使用sni扩展后，它允许客户端在发起SSL握手请求时（具体说来，是客户端发出SSL请求中的ClientHello阶段），就提交请求的Host信息，使得服务器能够切换到正确的域并返回相应的证书。如果没有使用SNI扩展则存在多个server时，且没有使用不同的ip地址区分，默认会访问第一个域名证书。总的来说就是影响证书的识别，没有sni可能导致访问第二个虚拟主机server使用的证书是第一个的，由于ssl握手时间内，没有host主机头信息。后期sni扩展后，在ssl握手前就先发送host主机头信息，所以可以对应找到对应的server。
https://blog.51cto.com/zengestudy/2170245
启用SNI表示一个监听器下可为不同的域名配置不同的证书，不启用SNI表示该监听器下多个域名使用同一个证书

6.MSL 是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，MSL指明TCP报文在Internet上最长生存时间,每个具体的TCP实现都必须选择一个确定的MSL值.RFC 1122建议是2分钟,但BSD传统实现采用了30秒.TIME_WAIT 状态最大保持时间是2 * MSL,也就是1-4分钟.在redhat和centos系统中MSL也是采用的30秒

7.TIME_WAIT过多问题的处理思路，可借鉴
https://www.jianshu.com/p/a2938fc35573
https://www.cnblogs.com/softidea/p/5741192.html #timewait的讲解说明，可参考

8.音视频混流
什么是混流？混流就是把多路音视频流混合成单流。准确地说，混流应该叫作混音(音频流)混画面(视频流)。为了表述简单，我们这里就简称为混流。
混流的过程包括解码，混流，编码，和推流这四个步骤。混流这个环节包括做抖动缓冲，目的是把多路流进行画面对齐和音画同步，同时通过缓冲对抗网络抖动，以便混合成一路流以后能够达到良好的效果。
混流本身是一个相对比较耗费计算资源的运算，也是一个比较耗费时间的环节。说它耗费计算资源是因为这个过程涉及到多路流的实时转码，这是比较耗费CPU的事情。说它耗费时间，是因为这个环节涉及到抖动缓冲，会造成一定的延迟。实时转码本身耗费的时间一般会低于一帧的时间，相对不算显著;但是根据网络情况的不同，抖动缓冲会消耗大概80毫秒到1秒的时间。在连麦互动直播中，抖动缓冲造成的延迟对观众的体验十分关键。
在混流的过程中，难点是如何对抗网络抖动等不确定因素。对于各种不确定因素的处理，是最考验技术能力的。在网络好的时候，要尽量让延迟降低，要尽量快地完成处理。在网络不好的时候，又要避免卡顿和不同步等问题。这里需要有比较好的弹性设计，去满足对抗网络抖动的要求。

9.内存管理机制---重要
https://www.cnblogs.com/zhaoyl/p/3695517.html

10.Linux文件系统
https://www.cnblogs.com/bellkosmos/p/detail_of_linux_file_system.html