Nginx拓展

Snake8859 12/17/2022

# keepalived

在nginx可以以反向代理和负载均衡方式提高系统并发，但是nginx本身也是存在一定并发限制。作为系统的入口，若nginx崩溃，则系统也会受到影响，如何配置高可用nginx集群是一个关键。我们常规的设想可能是再添加一台nginx再反向代理更多nginx，但是这只是自欺欺人，因为还是一个单机入口的形式，我们所要做的是让用户访问域名时，能够根据动态分配到不同nginx服务器上，然后再转发到实际业务服务器。因此我们使用keepalived来实现nginx的高可用。

keepalived可以让多台不同IP的主机共享一个虚拟IP，然后指定一个主服务器使用这个虚拟IP。每台机器上的keepalived会相互通讯，根据其他机器上的keepalived进程是否存在，判断服务器状态。如果默认的Master停止了，就会再剩下的Backup机器种，竞选出一台Nginx服务器作为Master。

# 安装keepalived

yum install -y keepalived

# 修改keepalived配置

配置文件在/etc/keepalived/keepalived.conf
vrrp_instance、authentication、virtual_router_id、virtual_ipaddress这几个一样的机器，才算是同一个组里。这个组才会选出一个作为Master机器

这里我们设置两台机器，分别下载好keepalived，然后进行配置

机器一：

! Configuration File for keepalived

global_defs {
   router_id lb1 # 名字与其他配置了keepalive的机器不重复就行
}

vrrp_instance heyingjie {#vrrp实例名可以随意取
    state MASTER #只能有一个默认的Master，其他写BACKUP
    interface ens33 # ip addr查看下网卡名，默认时ens33
    virtual_router_id 51
    priority 100 # 多台安装了keepalived的机器竞争成为Master的优先级
    advert_int 1 #通信时间
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.16 #虚拟IP
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

机器二：

! Configuration File for keepalived

global_defs {
   router_id lb2 
}

vrrp_instance heyingjie {
    state BACKUP #只能有一个默认的Master，其他写BACKUP
    interface ens33 
    virtual_router_id 51
    priority 50
    advert_int 1 
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.16 #虚拟IP
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

通过命令ip addr查看机器一的ip信息，可以看到虚拟IP

# HTTP和HTTPS

HTTP协议是一种不安全网络传输协议，它在传输过程中的各种数据是透明的（明文传输），这样很容易被劫持，然后获取用户的隐私数据。为了能够保证数据安全，我们需要对通信数据进行加密，由此诞生了HTTPS协议。

# 对称加密和非对称加密

对数据进行加密的方式通常有对称加密和非对称加密。

对称加密

对称加密中通信双峰共享唯一的密钥k，加密算法已知，加密方利用密钥k加密，解密方利用密钥k解密。保密性依赖于密钥k的保密性和加密算法。

但是像nginx这样的开源应用服务器，其内置解密算法很容易破解，同时还要保护密钥不在网络通信中被窃听。
非对称加密

非对称加密采用两个密钥（一个公钥和一个私钥）。在通信时，私钥仅由解密方保存，公钥由任何一个想与解密方通信的加密方保存。

可以设想这样一个场景，在某个自助邮局，每个通信信道都是一个邮箱，每个邮箱所有者都在旁边立了一个一个牌子，上面挂着一把钥匙：这是我的公钥，发送者请将信件放入我的邮箱，并用公钥锁好。但是公钥只能加锁，并不能解锁。解锁只能由邮箱的所有者——因为只有他保存着私钥。这样，通信信息就不会被其他人截获了，这依赖于私钥的保密性。

公私钥对的生成算法依赖于单向函数。

上图就是一个单向函数，任何人都可以利用榨汁机将水果变为果汁，但是几乎无法将果汁变为水果。

在这里，函数 f 的计算方法相当于公钥，陷门 h 相当于私钥。公钥 f 是公开的，任何人对已有输入，都可以用 f 加密，而要想根据加密信息还原出原信息，必须要有私钥才行。

# CA证书

非对称加密依然有一个安全隐患，设想这样情况。

客户端 C 和服务器 S 通信，根据非对称加密原理，C 需要先知道 S 的公钥，而 S 公钥的唯一获取途径，就是把 S 公钥在网络信道中传输。

但在网络通信中有几个问题：

任何人都可以捕获通信包
通信包的保密性由发送者设计
保密算法设计方案默认为公开，而（解密）密钥默认是安全的

因此，假设S公钥不做加密，在通信中传输，那么很有可能存在一个攻击者A，发送给C一个诈包，假装是S公钥，其实就是诱饵服务器AS的公钥。当C收到AS的公钥（缺以为是S的公钥），C后续就会使用AS公钥对数据进行加密，并在公开信道传输，那么A将捕获这些加密包，用AS的私钥解密，将截获C本来要发S的内容。

为了公钥传输的信赖性问题，第三方机构应运而生——证书颁发机构（CA，Certificate Authority）。CA 默认是受信任的第三方。CA 会给各个服务器颁发证书，证书存储在服务器上，并附有 CA 的电子签名。

当客户端（浏览器）向服务器发送 HTTPS 请求时，一定要先获取目标服务器的证书，并根据证书上的信息，检验证书的合法性。一旦客户端检测到证书非法，就会发生错误。客户端获取了服务器的证书后，由于证书的信任性是由第三方信赖机构认证的，而证书上又包含着服务器的公钥信息，客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。

总结来说，带有证书的公钥传输机制如下：

设有服务器 S，客户端 C，和第三方信赖机构 CA。
S 信任 CA，CA 是知道 S 公钥的，CA 向 S 颁发证书。并附上 CA 私钥对消息摘要的加密签名。
S 获得 CA 颁发的证书，将该证书传递给 C。
C 获得 S 的证书，信任 CA 并知晓 CA 公钥，使用 CA 公钥对 S 证书上的签名解密，同时对消息进行散列处理，得到摘要。比较摘要，验证 S 证书的真实性。
如果 C 验证 S 证书是真实的，则信任 S 的公钥（在 S 证书中），

# 参考

https://heyingjiee.github.io/otherLanguage/Nginx%E5%AD%A6%E4%B9%A0.html
https://javaguide.cn/cs-basics/network/http&https.html

Nginx应用