ssl相关、负载均衡、root和alias扩展

最新推荐文章于 2024-09-29 21:52:47 发布

转载最新推荐文章于 2024-09-29 21:52:47 发布

· 323 阅读

0 ·

版权

原文链接：https://my.oschina.net/u/3992081/blog/2989462

文章标签：

#后端 #运维

ssl原理

要想弄明白SSL认证原理，首先要对CA有有所了解，它在SSL认证过程中有非常重要的作用。
说白了，CA就是一个组织，专门为网络服务器颁发证书的，国际知名的CA机构有VeriSign、Symantec，国内的有GlobalSign。
每一家CA都有自己的根证书，用来对它所签发过的服务器端证书进行验证。

如果服务器提供方想为自己的服务器申请证书，它就需要向CA机构提出申请。
服务器提供方向CA提供自己的身份信息，CA判明申请者的身份后，就为它分配一个公钥，
并且CA将该公钥和服务器身份绑定在一起，并为之签字，这就形成了一个服务器端证书。

如果一个用户想鉴别另一个证书的真伪，他就用CA的公钥对那个证书上的签字进行验证，一旦验证通过，该证书就被认为是有效的。
证书实际是由证书签证机关（CA）签发的对用户的公钥的认证。

证书的内容包括：电子签证机关的信息、公钥用户信息、公钥、权威机构的签字和有效期等等。
目前，证书的格式和验证方法普遍遵循X.509国际标准。

单向

1.客户端say hello 服务端
2.服务端将证书、公钥等发给客户端
3.客户端CA验证证书，成功继续、不成功弹出选择页面
4.客户端告知服务端所支持的加密算法
5.服务端选择最高级别加密算法明文通知客户端
6.客户端生成随机对称密钥key，使用服务端公钥加密发送给服务端
7.服务端使用私钥解密，获取对称密钥key
8.后续客户端与服务端使用该密钥key进行加密通信

双向

1.客户端say hello 服务端
2.服务端将证书、公钥等发给客户端
3.客户端CA验证证书，成功继续、不成功弹出选择页面
4.客户端将自己的证书和公钥发送给服务端
5.服务端验证客户端证书，如不通过直接断开连接
6.客户端告知服务端所支持的加密算法
7.服务端选择最高级别加密算法使用客户端公钥加密后发送给客户端
8.客户端收到后使用私钥解密并生成随机对称密钥key，使用服务端公钥加密发送给服务端
9.服务端使用私钥解密，获取对称密钥key
10.后续客户端与服务端使用该密钥key进行加密通信

Nginx负载均衡（工作在七层“应用层”）功能主要是通过upstream模块实现，Nginx负载均衡默认对后端服务器有健康检测的能力，仅限于端口检测，在后端服务器比较少的情况下负载均衡能力表现突出。

Nginx的几种负载均衡算法：

1、轮询（默认）：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端某台服务器宕机，则自动剔除故障机器，使用户访问不受影响。

2、weight：指定轮询权重，weight值越大，分配到的几率就越高，主要用于后端每台服务器性能不均衡的情况。

3、ip_hash：每个请求按访问IP的哈希结果分配，这样每个访客固定访问一个后端服务器，可以有效的解决动态网页存在的session共享问题。

4、fair（第三方）：更智能的一个负载均衡算法，此算法可以根据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。如果想要使用此调度算法，需要Nginx的upstream_fair模块。

5、url_hash（第三方）：按访问URL的哈希结果来分配请求，使每个URL定向到同一台后端服务器，可以进一步提高后端缓存服务器的效率。如果想要使用此调度算法，需要Nginx的hash软件包。

在upstream模块中，可以通过server命令指定后端服务器的IP地址和端口，同时还可以设置每台后端服务器在负载均衡调度中的状态，常用的状态有以下几种：

1、down：表示当前server暂时不参与负载均衡。

2、backup：预留的备份机，当其他所有非backup机器出现故障或者繁忙的时候，才会请求backup机器，这台机器的访问压力最轻。

3、max_fails：允许请求的失败次数，默认为1，配合fail_timeout一起使用

4、fail_timeout：经历max_fails次失败后，暂停服务的时间，默认为10s（某个server连接失败了max_fails次，则nginx会认为该server不工作了。同时，在接下来的 fail_timeout时间内，nginx不再将请求分发给失效的server。）

下面是一个负载均衡的配置示例，这里只列出http配置段，省略了其他部分配置：

http

{

upstream whsirserver {

server 192.168.0.120:80 weight=5 max_fails=3 fail_timeout=20s;

server 192.168.0.121:80 weight=1 max_fails=3 fail_timeout=20s;

server 192.168.0.122:80 weight=3 max_fails=3 fail_timeout=20s;

server 192.168.0.123:80 weight=4 max_fails=3 fail_timeout=20s;

}

server

{

listen 80;

server_name blog.whsir.com;

index index.html index.htm;

root /data/www;

location / {

proxy_pass http://whsirserver;

proxy_next_upstream http_500 http_502 error timeout invalid_header;

}

upstream负载均衡开始，通过upstream指定了一个负载均衡器的名称为whsirserver，这个名称可以自己定义，在后面proxy_pass直接调用即可。

proxy_next_upstream参数用来定义故障转移策略，当后端服务器节点返回500、502和执行超时等错误时，自动将请求转发到upstream负载均衡器中的另一台服务器，实现故障转移。

处于最顶上的树根位置的那个证书，就是“根证书”。除了根证书，其它证书都要依靠上一级的证书，来证明自己。
那谁来证明“根证书”可靠呢？
实际上，根证书自己证明自己是可靠滴（或者换句话说，根证书是不需要被证明滴）。
聪明的同学此刻应该意识到了：根证书是整个证书体系安全的根本。
所以，如果某个证书体系中，根证书出了问题（不再可信了），那么所有被根证书所信任的其它证书，也就不再可信了。

通常，我们如果访问某些敏感的网页（比如用户登录的页面），其协议都会使用HTTPS而不是HTTP,因为HTTP协议是明文的，
一旦有坏人在偷窥你的网络通讯，他/她就可以看到网络通讯的内容（比如你的密码、银行帐号、等）。
而 HTTPS 是加密的协议，可以保证你的传输过程中，坏蛋无法偷窥。
但是，千万不要以为，HTTPS协议有了加密，就可高枕无忧了。
假设有一个坏人，搞了一个假的网银的站点，然后诱骗你上这个站点。
假设你又比较单纯，一不留神，就把你的帐号，口令都输入进去了。那这个坏蛋的阴谋就得逞了。
为了防止坏人这么干，HTTPS 协议除了有加密的机制，还有一套证书的机制。通过证书来确保，某个站点确实就是某个站点。
有了证书之后，当你的浏览器在访问某个HTTPS网站时，会验证该站点上的CA证书（类似于验证介绍信的公章）。
如果浏览器发现该证书没有问题（证书被某个根证书信任、证书上绑定的域名和该网站的域名一致、证书没有过期），
那么页面就直接打开，否则的话，浏览器会给出一个警告，告诉你该网站的证书存在某某问题，是否继续访问该站点。

root和alias

nginx指定文件路径有两种方式root和alias，这两者的用法区别，使用方法总结了下，方便大家在应用过程中，快速响应。root与alias主要区别在于nginx如何解释location后面的uri，这会使两者分别以不同的方式将请求映射到服务器文件上。

[root]
语法：root path
默认值：root html
配置段：http、server、location、if

[alias]
语法：alias path
配置段：location

实例：

location ~ ^/weblogs/ {

root /data/weblogs/www.ttlsa.com;

autoindex on;

auth_basic "Restricted";

auth_basic_user_file passwd/weblogs;

}

如果一个请求的URI是/weblogs/httplogs/www.ttlsa.com-access.log时，web服务器将会返回服务器上的/data/weblogs/www.ttlsa.com/weblogs/httplogs/www.ttlsa.com-access.log的文件。
[info]root会根据完整的URI请求来映射，也就是/path/uri。[/info]
因此，前面的请求映射为path/weblogs/httplogs/www.ttlsa.com-access.log。

location ^~ /binapp/ {

limit_conn limit 4;

limit_rate 200k;

internal;

alias /data/statics/bin/apps/;

}

alias会把location后面配置的路径丢弃掉，把当前匹配到的目录指向到指定的目录。如果一个请求的URI是/binapp/a.ttlsa.com/favicon时，web服务器将会返回服务器上的/data/statics/bin/apps/a.ttlsa.com/favicon.jgp的文件。
[warning]1. 使用alias时，目录名后面一定要加"/"。
2. alias可以指定任何名称。
3. alias在使用正则匹配时，必须捕捉要匹配的内容并在指定的内容处使用。
4. alias只能位于location块中。

转载于:https://my.oschina.net/u/3992081/blog/2989462