第二十二课时预习笔记

.nginx负载均衡

　　网站的访问量越来越大，服务器的服务模式也得进行相应的升级，比如分离出数据库服务器、分离出图片作为单独服务，这些是简单的数据的负载均衡，将压力分散到不同的机器上。有时候来自web前端的压力，也能让人十分头痛。怎样将同一个域名的访问分散到两台或更多的机器上呢？这其实就是另一种负载均衡了，nginx自身就可以做到，只需要做个简单的配置就行。

　　nginx不单可以作为强大的web服务器，也可以作为一个反向代理服务器，而且nginx还可以按照调度规则实现动态、静态页面的分离，可以按照轮询、ip哈希、URL哈希、权重等多种方式对后端服务器做负载均衡，同时还支持后端服务器的健康检查。

Nginx负载均衡一些基础知识：

nginx 的 upstream目前支持 4 种方式的分配 

1)、轮询（默认） 

　　每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。 

2)、weight 

　　指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 

2)、ip_hash 

　　每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。  

3)、fair（第三方） 

　　按后端服务器的响应时间来分配请求，响应时间短的优先分配。  

4)、url_hash（第三方）

 

2.nginx负载均衡配置,主要是proxy_pass,upstream的使用

在http段做如下配置，即可实现两个域名

 

upstream  www.linuxidc.com  

{

    server   10.0.1.50:8080;

    server   10.0.1.51:8080;

}

 

upstream  blog.linuxidc.com   

{

    server   10.0.1.50:8080;

    server   10.0.1.51:8080;

}

 

server

{

    listen  80;

    server_name  www.linuxidc.com;

 

    location / {

        proxy_pass        http://www.linuxidc.com;

        proxy_set_header   Host             $host;

        proxy_set_header   X-Real-IP        $remote_addr;

        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

    }

}

 

server

{

    listen  80;

    server_name  blog.linuxidc.com wode.linuxidc.com;

 

    location / {

        proxy_pass        http://www.linuxidc.com;

        proxy_set_header   Host             $host;

        proxy_set_header   X-Real-IP        $remote_addr;

        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

    }

}

 

3.注意的几个小问题

3.1 多台机器间session的共享问题

配置负载均衡比较简单,但是最关键的一个问题是怎么实现多台服务器之间session的共享

下面有几种方法(以下内容来源于网络,第四种方法没有实践.)

1). 不使用session，换作cookie

　　能把session改成cookie，就能避开session的一些弊端，在从前看的一本J2EE的书上，也指明在集群系统中不能用session，否则惹出祸端来就不好办。如果系统不复杂，就优先考虑能否将session去掉，改动起来非常麻烦的话，再用下面的办法。

2). 应用服务器自行实现共享

　　php可以用数据库或memcached来保存session，从而在php本身建立了一个session集群，用这样的方式可以令 session保证稳定，即使某个节点有故障，session也不会丢失，适用于较为严格但请求量不高的场合。但是它的效率是不会很高的，不适用于对效率要求高的场合。

以上两个办法都跟nginx没什么关系，下面来说说用nginx该如何处理：

3).  ip_hash

　　nginx中的ip_hash技术能够将某个ip的请求定向到同一台后端，这样一来这个ip下的某个客户端和某个后端就能建立起稳固的session，ip_hash是在upstream配置中定义的：

 

upstream backend {

    server 127.0.0.1:8080 ;

    server 127.0.0.1:9090 ;

    ip_hash;

}

　　ip_hash是容易理解的，但是因为仅仅能用ip这个因子来分配后端，因此ip_hash是有缺陷的，不能在一些情况下使用：

　　nginx不是最前端的服务器。ip_hash要求nginx一定是最前端的服务器，否则nginx得不到正确ip，就不能根据ip作hash。譬如使用的是squid为最前端，那么nginx取ip时只能得到squid的服务器ip地址，用这个地址来作分流是肯定错乱的。

　　nginx的后端还有其它方式的负载均衡。假如nginx后端又有其它负载均衡，将请求又通过另外的方式分流了，那么某个客户端的请求肯定不能定位到同一台session应用服务器上。这么算起来，nginx后端只能直接指向应用服务器，或者再搭一个squid，然后指向应用服务器。最好的办法是用location作一次分流，将需要session的部分请求通过ip_hash分流，剩下的走其它后端去。

4). upstream_hash

　　为了解决ip_hash的一些问题，可以使用upstream_hash这个第三方模块，这个模块多数情况下是用作url_hash的，但是并不妨碍将它用来做session共享。假如前端是squid，他会将ip加入x_forwarded_for这个http_header里，用upstream_hash可以用这个头做因子，将请求定向到指定的后端：可见这篇文档：http://www.sudone.com/nginx/nginx_url_hash.html

在文档中是使用$request_uri做因子，稍微改一下：

hash   $http_x_forwarded_for;

这样就改成了利用x_forwarded_for这个头作因子，在nginx新版本中可支持读取cookie值，所以也可以改成：

hash   $cookie_jsessionid;

　　假如在php中配置的session为无cookie方式，配合nginx自己的一个userid_module模块就可以用nginx自发一个cookie，可参见userid模块的英文文档：http://wiki.nginx.org/NginxHttpUserIdModule

　　另可用姚伟斌编写的模块upstream_jvm_route：http://code.google.com/p/nginx-upstream-jvm-route/

3.2 后端服务器自动加上端口的问题

　　一个典型的 Nginx + Apache 应用方案可以是Nginx 占用 80 端口，过滤静态请求，然后动态请求即 Proxy 到 Apache 的 8080 端口。Proxy 反向代理的好处是访问的时候，始终就是 80端口，来访者不会觉察到有任何的区别。但有的应用确非常“聪明”，识别到 Apache 所位于的端口是 8080 ，就会把相关的超链接都一并加上 :8080 的后续。这么就死定了，还能有正常访问麽？！有个方法可以解决这事，就是把 apache 也运行在80端口上。同一台服务器，有Nginx 也有 Apache，2个httpd服务，都是80，不会冲突麽？

nginx.conf 的配置中

 

server {

    listen 80;

    server_name www.linuxidc.com;

    ....

}

修改为：

 

server {

    listen 123.123.123.123:80; #指定Nginx只占用某个公网IP的80端口。

    #listen 123.123.123.124:80; #如果你服务器中有多个IP，还可以指定多个。

    server_name www.linuxidc.com;

....

}

把 apache 的配置文件 httpd.conf 中的

Listen 80

改为

Listen 127.0.0.1:80

跟Nginx一样，指定apache所占用的IP及端口。

保存退出，重启apache即可生效。

公钥和私钥  

一直以来对公钥和私钥都理解得不是很透彻，感觉到模棱两可。今天在网上找了半天，通过查看对这个密钥对的理解，总算弄清楚了。       公钥和私钥就是俗称的不对称加密方式，是从以前的对称加密（使用用户名与密码）方式的提高。用电子邮件的方式说明一下原理。       使用公钥与私钥的目的就是实现安全的电子邮件，必须实现如下目的：       1. 我发送给你的内容必须加密，在邮件的传输过程中不能被别人看到。       2. 必须保证是我发送的邮件，不是别人冒充我的。       要达到这样的目标必须发送邮件的两人都有公钥和私钥。       公钥，就是给大家用的，你可以通过电子邮件发布，可以通过网站让别人下载，公钥其实是用来加密/验章用的。私钥，就是自己的，必须非常小心保存，最好加上 密码，私钥是用来解密/签章，首先就Key的所有权来说，私钥只有个人拥有。公钥与私钥的作用是：用公钥加密的内容只能用私钥解密，用私钥加密的内容只能 用公钥解密。       比如说，我要给你发送一个加密的邮件。首先，我必须拥有你的公钥，你也必须拥有我的公钥。       首先，我用你的公钥给这个邮件加密，这样就保证这个邮件不被别人看到，而且保证这个邮件在传送过程中没有被修改。你收到邮件后，用你的私钥就可以解密，就能看到内容。       其次我用我的私钥给这个邮件加密，发送到你手里后，你可以用我的公钥解密。因为私钥只有我手里有，这样就保证了这个邮件是我发送的。       当A->B资料时，A会使用B的公钥加密，这样才能确保只有B能解开，否则普罗大众都能解开加密的讯息，就是去了资料的保密性。验证方面则是使用签 验章的机制，A传资料给大家时，会以自己的私钥做签章，如此所有收到讯息的人都可以用A的公钥进行验章，便可确认讯息是由 A 发出来的了。

   数字证书的原理

   数字证书采用公钥体制，即利用一对互相匹配的密钥进行加密、解密。每个用户自己设定一把特定的仅为本人所知的私有密钥（私钥），用它进行解密和签名；同时 设定一把公共密钥（公钥）并由本人公开，为一组用户所共享，用于加密和验证签名。当发送一份保密文件时，发送方使用接收方的公钥对数据加密，而接收方则使 用自己的私钥解密，这样信息就可以安全无误地到达目的地了。通过数字的手段保证加密过程是一个不可逆过程,即只有用私有密钥才能解密. 在公开密钥密码体制中，常用的一种是RSA体制。 用户也可以采用自己的私钥对信息加以处理，由于密钥仅为本人所有，这样就产生了别人无法生成的文件，也就形成了数字签名。采用数字签名，能够确认以下两点： （1）保证信息是由签名者自己签名发送的，签名者不能否认或难以否认； （2）保证信息自签发后到收到为止未曾作过任何修改，签发的文件是真实文件。

 

 

SSL 是一个安全协议，它提供使用 TCP/IP 的通信应用程序间的隐私与完整性。因特网的 超文本传输协议 （HTTP）使用 SSL 来实现安全的通信。

在客户端与服务器间传输的数据是通过使用对称算法（如 DES 或 RC4）进行加密的。公用密钥算法（通常为 RSA）是用来获得加密密钥交换和数字签名的，此算法使用服务器的SSL数字证书中的公用密钥。有了服务器的SSL数字证书，客户端也可以验证服务器的身 份。SSL 协议的版本 1 和 2 只提供服务器认证。版本 3 添加了客户端认证，此认证同时需要客户端和服务器的数字证书。

SSL 握手/

SSL 连接总是由客户端启动的。在SSL 会话开始时执行 SSL 握手。此握手产生会话的密码参数。关于如何处理 SSL 握手的简单概述，如下图所示。此示例假设已在 Web 浏览器 和 Web 服务器间建立了 SSL 连接。

(1) 客户端发送列出客户端密码能力的客户端“您好”消息（以客户端首选项顺序排序），如 SSL 的版本、客户端支持的密码对和客户端支持的数据压缩方法。消息也包含 28 字节的随机数。

(2) 服务器以服务器“您好”消息响应，此消息包含密码方法（密码对）和由服务器选择的数据压缩方法，以及会话标识和另一个随机数。

注意:客户端和服务器至少必须支持一个公共密码对，否则握手失败。服务器一般选择最大的公共密码对。

(3) 服务器发送其SSL数字证书。（服务器使用带有 SSL 的 X.509 V3 数字证书。）

如果服务器使用 SSL V3，而服务器应用程序（如 Web 服务器）需要数字证书进行客户端认证，则客户端会发出“数字证书请求”消息。在 “数字证书请求”消息中，服务器发出支持的客户端数字证书类型的列表和可接受的CA的名称。

(4) 服务器发出服务器“您好完成”消息并等待客户端响应。

(5) 一接到服务器“您好完成”消息，客户端（ Web 浏览器）将验证服务器的SSL数字证书的有效性并检查服务器的“你好”消息参数是否可以接受。

如果服务器请求客户端数字证书，客户端将发送其数字证书；或者，如果没有合适的数字证书是可用的，客户端将发送“没有数字证书”警告。此警告仅仅是警告而已，但如果客户端数字证书认证是强制性的话，服务器应用程序将会使会话失败。

(6) 客户端发送“客户端密钥交换”消息。

此消息包含 pre-master secret （一个用在对称加密密钥生成中的 46 字节的随机数字），和 消息认证代码 （ MAC ）密钥（用服务器的公用密钥加密的）。

如果客户端发送客户端数字证书给服务器，客户端将发出签有客户端的专用密钥的“数字证书验证”消息。通过验证此消息的签名，服务器可以显示验证客户端数字证书的所有权。

注意: 如果服务器没有属于数字证书的专用密钥，它将无法解密 pre-master 密码，也无法创建对称加密算法的正确密钥，且握手将失败。

(7) 客户端使用一系列加密运算将 pre-master secret 转化为 master secret ，其中将派生出所有用于加密和消息认证的密钥。然后，客户端发出“更改密码规范” 消息将服务器转换为新协商的密码对。客户端发出的下一个消息（“未完成”的消息）为用此密码方法和密钥加密的第一条消息。

(8) 服务器以自己的“更改密码规范”和“已完成”消息响应。

(9) SSL 握手结束，且可以发送加密的应用程序数据。

 

 

SSL单向双向认证

单向认证：客户端向服务器发送消息，服务器接到消息后，用服务器端的密钥库中的私钥对数据进行加密，然后把加密后的数据和服务器端的公钥一起发送到客户端，客户端用服务器发送来的公钥对数据解密，然后在用传到客户端的服务器公钥对数据加密传给服务器端，服务器用私钥对数据进行解密，这就完成了客户端和服务器之间通信的安全问题，但是单向认证没有验证客户端的合法性。

双向认证：客户端向服务器发送消息，首先把消息用客户端证书加密然后连同时把客户端证书一起发送到服务器端，服务器接到消息后用首先用客户端证书把消息解密，然后用服务器私钥把消息加密，把服务器证书和消息一起发送到客户端，客户端用发来的服务器证书对消息进行解密，然后用服务器的证书对消息加密，然后在用客户端的证书对消息在进行一次加密，连同加密消息和客户端证书一起发送到服务器端，到服务器端首先用客户端传来的证书对消息进行解密，确保消息是这个客户发来的，然后用服务器端的私钥对消息在进行解密这个便得到了明文数据。

 

 

关键词：SSL，PKI，MAC

摘    要：SSL利用数据加密、身份验证和消息完整性验证机制，为基于TCP等可靠连接的应用层协议提供安全性保证。本文介绍了SSL的产生背景、安全机制、工作过程及典型组网应用。

缩略语：

缩略语	英文全名	中文解释
AES	Advanced Encryption Standard	高级加密标准
CA	Certificate Authority	证书机构
DES	Data Encryption Standard	数据加密标准
HTTPS	Hypertext Transfer Protocol Secure	安全超文本传输协议
MAC	Message Authentication Code	消息验证码
MD5	Message Digest 5	消息摘要算法5
PKI	Public Key Infrastructure	公钥基础设施
RSA	Rivest Shamir and Adleman	非对称密钥算法的一种
SHA	Secure Hash Algorithm	安全散列算法
SSL	Secure Sockets Layer	安全套接层
VPN	Virtual Private Network	虚拟专有网络

 

 

1  概述

1.1  产生背景

基于万维网的电子商务和网上银行等新兴应用，极大地方便了人们的日常生活，受到人们的青睐。由于这些应用都需要在网络上进行在线交易，它们对网络通信的安全性提出了更高的要求。传统的万维网协议HTTP不具备安全机制——采用明文的形式传输数据、不能验证通信双方的身份、无法防止传输的数据被篡改等，导致HTTP无法满足电子商务和网上银行等应用的安全性要求。

Netscape公司提出的安全协议SSL，利用数据加密、身份验证和消息完整性验证机制，为网络上数据的传输提供安全性保证。SSL可以为HTTP提供安全连接，从而很大程度上改善了万维网的安全性问题。

1.2  技术优点

SSL具有如下优点：

l              提供较高的安全性保证。SSL利用数据加密、身份验证和消息完整性验证机制，保证网络上数据传输的安全性。

l              支持各种应用层协议。虽然SSL设计的初衷是为了解决万维网安全性问题，但是由于SSL位于应用层和传输层之间，它可以为任何基于TCP等可靠连接的应用层协议提供安全性保证。

l              部署简单。目前SSL已经成为网络中用来鉴别网站和网页浏览者身份，在浏览器使用者及Web服务器之间进行加密通信的全球化标准。SSL协议已被集成到大部分的浏览器中，如IE、Netscape、Firefox等。这就意味着几乎任意一台装有浏览器的计算机都支持SSL连接，不需要安装额外的客户端软件。

2  协议安全机制

SSL协议实现的安全机制包括：

l              数据传输的机密性：利用对称密钥算法对传输的数据进行加密。

l              身份验证机制：基于证书利用数字签名方法对服务器和客户端进行身份验证，其中客户端的身份验证是可选的。

l              消息完整性验证：消息传输过程中使用MAC算法来检验消息的完整性。

2.1  数据传输的机密性

网络上传输的数据很容易被非法用户窃取，SSL采用在通信双方之间建立加密通道的方法保证数据传输的机密性。

所谓加密通道，是指发送方在发送数据前，使用加密算法和加密密钥对数据进行加密，然后将数据发送给对方；接收方接收到数据后，利用解密算法和解密密钥从密文中获取明文。没有解密密钥的第三方，无法将密文恢复为明文，从而保证数据传输的机密性。

加解密算法分为两类：

l              对称密钥算法：数据加密和解密时使用相同的密钥。

l              非对称密钥算法：数据加密和解密时使用不同的密钥，一个是公开的公钥，一个是由用户秘密保存的私钥。利用公钥（或私钥）加密的数据只能用相应的私钥（或公钥）才能解密。

与非对称密钥算法相比，对称密钥算法具有计算速度快的优点，通常用于对大量信息进行加密（如对所有报文加密）；而非对称密钥算法，一般用于数字签名和对较少的信息进行加密。

SSL加密通道上的数据加解密使用对称密钥算法，目前主要支持的算法有DES、3DES、AES等，这些算法都可以有效地防止交互数据被窃听。

对称密钥算法要求解密密钥和加密密钥完全一致。因此，利用对称密钥算法加密传输数据之前，需要在通信两端部署相同的密钥。对称密钥的部署方法请参见“2.4  利用非对称密钥算法保证密钥本身的安全”。

2.2  身份验证机制

电子商务和网上银行等应用中必须保证要登录的Web服务器是真实的，以免重要信息被非法窃取。SSL利用数字签名来验证通信对端的身份。

非对称密钥算法可以用来实现数字签名。由于通过私钥加密后的数据只能利用对应的公钥进行解密，因此根据解密是否成功，就可以判断发送者的身份，如同发送者对数据进行了“签名”。例如，Alice使用自己的私钥对一段固定的信息加密后发给Bob，Bob利用Alice的公钥解密，如果解密结果与固定信息相同，那么就能够确认信息的发送者为Alice，这个过程就称为数字签名。

SSL客户端必须验证SSL服务器的身份，SSL服务器是否验证SSL客户端的身份，则由SSL服务器决定。SSL客户端和SSL服务器的身份验证过程，请参见“3.2  SSL握手过程”。

使用数字签名验证身份时，需要确保被验证者的公钥是真实的，否则，非法用户可能会冒充被验证者与验证者通信。如图1所示，Cindy冒充Bob，将自己的公钥发给Alice，并利用自己的私钥计算出签名发送给Alice，Alice利用“Bob”的公钥（实际上为Cindy的公钥）成功验证该签名，则Alice认为Bob的身份验证成功，而实际上与Alice通信的是冒充Bob的Cindy。SSL利用PKI提供的机制保证公钥的真实性，详细介绍请参见“2.5  利用PKI保证公钥的真实性”。

图1 伪造公钥

2.3  消息完整性验证

为了避免网络中传输的数据被非法篡改，SSL利用基于MD5或SHA的MAC算法来保证消息的完整性。

MAC算法是在密钥参与下的数据摘要算法，能将密钥和任意长度的数据转换为固定长度的数据。利用MAC算法验证消息完整性的过程如图2所示。发送者在密钥的参与下，利用MAC算法计算出消息的MAC值，并将其加在消息之后发送给接收者。接收者利用同样的密钥和MAC算法计算出消息的MAC值，并与接收到的MAC值比较。如果二者相同，则报文没有改变；否则，报文在传输过程中被修改，接收者将丢弃该报文。

图2 MAC算法示意图

MAC算法具有如下特征，使其能够用来验证消息的完整性：

l              消息的任何改变，都会引起输出的固定长度数据产生变化。通过比较MAC值，可以保证接收者能够发现消息的改变。

l              MAC算法需要密钥的参与，因此没有密钥的非法用户在改变消息的内容后，无法添加正确的MAC值，从而保证非法用户无法随意修改消息内容。

MAC算法要求通信双方具有相同的密钥，否则MAC值验证将会失败。因此，利用MAC算法验证消息完整性之前，需要在通信两端部署相同的密钥。MAC密钥的部署方法请参见“2.4  利用非对称密钥算法保证密钥本身的安全”。

2.4  利用非对称密钥算法保证密钥本身的安全

对称密钥算法和MAC算法要求通信双方具有相同的密钥，否则解密或MAC值验证将失败。因此，要建立加密通道或验证消息完整性，必须先在通信双方部署一致的密钥。

SSL利用非对称密钥算法加密密钥的方法实现密钥交换，保证第三方无法获取该密钥。如图3所示，SSL客户端（如Web浏览器）利用SSL服务器（如Web服务器）的公钥加密密钥，将加密后的密钥发送给SSL服务器，只有拥有对应私钥的SSL服务器才能从密文中获取原始的密钥。SSL通常采用RSA算法加密传输密钥。

图3 密钥交换示意图

l      实际上，SSL客户端发送给SSL服务器的密钥不能直接用来加密数据或计算MAC值，该密钥是用来计算对称密钥和MAC密钥的信息，称为premaster secret。SSL客户端和SSL服务器利用premaster secret计算出相同的主密钥（master secret），再利用master secret生成用于对称密钥算法、MAC算法等的密钥。premaster secret是计算对称密钥、MAC算法密钥的关键。

l      用来实现密钥交换的算法称为密钥交换算法。非对称密钥算法RSA用于密钥交换时，也可以称之为密钥交换算法。

 

利用非对称密钥算法加密密钥之前，发送者需要获取接收者的公钥，并保证该公钥确实属于接收者，否则，密钥可能会被非法用户窃取。如图1所示，Cindy冒充Bob，将自己的公钥发给Alice，Alice利用Cindy的公钥加密发送给Bob的数据，Bob由于没有对应的私钥无法解密该数据，而Cindy截取数据后，可以利用自己的私钥解密该数据。SSL利用PKI提供的机制保证公钥的真实性，详细介绍请参见“2.5  利用PKI保证公钥的真实性”。

2.5  利用PKI保证公钥的真实性

PKI通过数字证书来发布用户的公钥，并提供了验证公钥真实性的机制。数字证书（简称证书）是一个包含用户的公钥及其身份信息的文件，证明了用户与公钥的关联。数字证书由权威机构——CA签发，并由CA保证数字证书的真实性。

SSL客户端把密钥加密传递给SSL服务器之前，SSL服务器需要将从CA获取的证书发送给SSL客户端，SSL客户端通过PKI判断该证书的真实性。如果该证书确实属于SSL服务器，则利用该证书中的公钥加密密钥，发送给SSL服务器。

验证SSL服务器/SSL客户端的身份之前，SSL服务器/SSL客户端需要将从CA获取的证书发送给对端，对端通过PKI判断该证书的真实性。如果该证书确实属于SSL服务器/SSL客户端，则对端利用该证书中的公钥验证SSL服务器/SSL客户端的身份。

3  协议工作过程

3.1  SSL的分层结构

图4 SSL协议分层

如图4所示，SSL位于应用层和传输层之间，它可以为任何基于TCP等可靠连接的应用层协议提供安全性保证。SSL协议本身分为两层：

l              上层为SSL握手协议（SSL handshake protocol）、SSL密码变化协议（SSL change cipher spec protocol）和SSL警告协议（SSL alert protocol）；

l              底层为SSL记录协议（SSL record protocol）。

其中：

l              SSL握手协议：是SSL协议非常重要的组成部分，用来协商通信过程中使用的加密套件（加密算法、密钥交换算法和MAC算法等）、在服务器和客户端之间安全地交换密钥、实现服务器和客户端的身份验证。

l              SSL密码变化协议：客户端和服务器端通过密码变化协议通知对端，随后的报文都将使用新协商的加密套件和密钥进行保护和传输。

l              SSL警告协议：用来向通信对端报告告警信息，消息中包含告警的严重级别和描述。

l              SSL记录协议：主要负责对上层的数据（SSL握手协议、SSL密码变化协议、SSL警告协议和应用层协议报文）进行分块、计算并添加MAC值、加密，并把处理后的记录块传输给对端。

3.2  SSL握手过程

SSL通过握手过程在客户端和服务器之间协商会话参数，并建立会话。会话包含的主要参数有会话ID、对方的证书、加密套件（密钥交换算法、数据加密算法和MAC算法等）以及主密钥（master secret）。通过SSL会话传输的数据，都将采用该会话的主密钥和加密套件进行加密、计算MAC等处理。

不同情况下，SSL握手过程存在差异。下面将分别描述以下三种情况下的握手过程：

l              只验证服务器的SSL握手过程

l              验证服务器和客户端的SSL握手过程

l              恢复原有会话的SSL握手过程

3.2.1  只验证服务器的SSL握手过程

图5 只验证服务器的SSL握手过程

如图5所示，只需要验证SSL服务器身份，不需要验证SSL客户端身份时，SSL的握手过程为：

(1)        SSL客户端通过Client Hello消息将它支持的SSL版本、加密算法、密钥交换算法、MAC算法等信息发送给SSL服务器。

(2)        SSL服务器确定本次通信采用的SSL版本和加密套件，并通过Server Hello消息通知给SSL客户端。如果SSL服务器允许SSL客户端在以后的通信中重用本次会话，则SSL服务器会为本次会话分配会话ID，并通过Server Hello消息发送给SSL客户端。

(3)        SSL服务器将携带自己公钥信息的数字证书通过Certificate消息发送给SSL客户端。

(4)        SSL服务器发送Server Hello Done消息，通知SSL客户端版本和加密套件协商结束，开始进行密钥交换。

(5)        SSL客户端验证SSL服务器的证书合法后，利用证书中的公钥加密SSL客户端随机生成的premaster secret，并通过Client Key Exchange消息发送给SSL服务器。

(6)        SSL客户端发送Change Cipher Spec消息，通知SSL服务器后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。

(7)        SSL客户端计算已交互的握手消息（除Change Cipher Spec消息外所有已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。

(8)        同样地，SSL服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。

(9)        SSL服务器计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。

SSL客户端接收到SSL服务器发送的Finished消息后，如果解密成功，则可以判断SSL服务器是数字证书的拥有者，即SSL服务器身份验证成功，因为只有拥有私钥的SSL服务器才能从Client Key Exchange消息中解密得到premaster secret，从而间接地实现了SSL客户端对SSL服务器的身份验证。

&  说明：

l      Change Cipher Spec消息属于SSL密码变化协议，其他握手过程交互的消息均属于SSL握手协议，统称为SSL握手消息。

l      计算Hash值，指的是利用Hash算法（MD5或SHA）将任意长度的数据转换为固定长度的数据。

 

3.2.2  验证服务器和客户端的SSL握手过程

图6 验证服务器和客户端的SSL握手过程

SSL客户端的身份验证是可选的，由SSL服务器决定是否验证SSL客户端的身份。如图6中蓝色部分标识的内容所示，如果SSL服务器验证SSL客户端身份，则SSL服务器和SSL客户端除了交互“3.2.1  只验证服务器的SSL握手过程”中的消息协商密钥和加密套件外，还需要进行以下操作：

(1)        SSL服务器发送Certificate Request消息，请求SSL客户端将其证书发送给SSL服务器。

(2)        SSL客户端通过Certificate消息将携带自己公钥的证书发送给SSL服务器。SSL服务器验证该证书的合法性。

(3)        SSL客户端计算已交互的握手消息、主密钥的Hash值，利用自己的私钥对其进行加密，并通过Certificate Verify消息发送给SSL服务器。

(4)        SSL服务器计算已交互的握手消息、主密钥的Hash值，利用SSL客户端证书中的公钥解密Certificate Verify消息，并将解密结果与计算出的Hash值比较。如果二者相同，则SSL客户端身份验证成功。

3.2.3  恢复原有会话的SSL握手过程

图7 恢复原有会话的SSL握手过程

协商会话参数、建立会话的过程中，需要使用非对称密钥算法来加密密钥、验证通信对端的身份，计算量较大，占用了大量的系统资源。为了简化SSL握手过程，SSL允许重用已经协商过的会话，具体过程为：

(1)        SSL客户端发送Client Hello消息，消息中的会话ID设置为计划重用的会话的ID。

(2)        SSL服务器如果允许重用该会话，则通过在Server Hello消息中设置相同的会话ID来应答。这样，SSL客户端和SSL服务器就可以利用原有会话的密钥和加密套件，不必重新协商。

(3)        SSL客户端发送Change Cipher Spec消息，通知SSL服务器后续报文将采用原有会话的密钥和加密套件进行加密和MAC计算。

(4)        SSL客户端计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSL服务器，以便SSL服务器判断密钥和加密套件是否正确。

(5)        同样地，SSL服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用原有会话的密钥和加密套件进行加密和MAC计算。

(6)        SSL服务器计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSL客户端，以便SSL客户端判断密钥和加密套件是否正确。

4  典型组网应用

4.1  HTTPS

HTTPS是基于SSL安全连接的HTTP协议。HTTPS通过SSL提供的数据加密、身份验证和消息完整性验证等安全机制，为Web访问提供了安全性保证，广泛应用于网上银行、电子商务等领域。

图8为HTTPS在网上银行中的应用。某银行为了方便客户，提供了网上银行业务，客户可以通过访问银行的Web服务器进行帐户查询、转帐等。通过在客户和银行的Web服务器之间建立SSL连接，可以保证客户的信息不被非法窃取。

图8 HTTPS在网上银行中的应用

4.2  SSL VPN

SSL VPN是以SSL为基础的VPN技术，利用SSL提供的安全机制，为用户远程访问公司内部网络提供了安全保证。如图9所示，SSL VPN通过在远程接入用户和SSL VPN网关之间建立SSL安全连接，允许用户通过各种Web浏览器，各种网络接入方式，在任何地方远程访问企业网络资源，并能够保证企业网络的安全，保护企业内部信息不被窃取。

图9 SSL VPN的典型组网环境

生成ssl密钥对

cd /usr/local/nginx/conf
首先要有openssl,没有需要安装
rpm -qf which openssl
openssl-1.0.2k-8.el7.x86_64

openssl genrsa -des3 -out tmp.key 2048 //rsa形式的key文件为私钥
openssl rsa -in tmp.key -out aminglinux.key //-in转换key，取消密码 -out输出的 
rm -f tmp.key
openssl req -new -key aminglinux.key -out aminglinux.csr //生成证书请求文件，需要拿这个文件和私钥一起生产公钥文件
openssl x509 -req -days 365 -in aminglinux.csr -signkey aminglinux.key -out aminglinux.crt
这里的aminglinux.crt为公钥

nginx配置SSL证书

1.新建证书存放路径(/usr/local/nginx目录下) mkdir ssl 2.生成一个RSA私钥(/usr/local/nginx/ssl目录下) openssl genrsa -des3 -out yangwanli.key 1024               --其中 yangwanli可以自定义 输入密码后，再次重复输入确认密码。记住此密码，后面会用到 3.创建csr证书 openssl req -new -key yangwanli.key -out yangwanli.csr     --其中 yangwanli.csr可以自定义命名 按照命令依次输入内容 输入私钥密码------->国家(zh)------>省份(浙江)----->城市(杭州)------>公司名称------->组织-------->公司域名-------->邮箱-------->私钥密码 执行完后会在ssl目录下会有两个文件，一个是私钥(key)，一个是证书 yangwanli.csr  yangwanli.key 4.生成crt证书 openssl x509 -req -days 365 -in yangwanli.csr -signkey yangwanli.key -out yangwanli.crt 已生成成功 5.配置证书 修改nginx.conf文件  server {         listen       443 ssl;         server_name    www.lee.com;              ssl_certificate      /usr/local/nginx/ssl/yangwanli.crt;         ssl_certificate_key  /usr/local/nginx/ssl/lee.key;              ssl_session_cache    shared:SSL:1m;         ssl_session_timeout  5m;              ssl_ciphers  HIGH:!aNULL:!MD5;         ssl_prefer_server_ciphers  on; 6.设置重定向 rewrite ^(.*) https://www.yangwanli.com$1 permanent; #可以把http协议重定向到https上面 7. 重启nginx    service nginx restart  重启 --------------------- 本文来自 工作QQ感冒的石头 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/qq_39291929/article/details/79113717?utm_source=copy

php-fpm的pool

第一部分：FPM 配置

参数　　　　　　　　　　| 说明

---

 -p　　　　　　　　　　　　| 命令行中动态修改--prefix 　

;include=etc/fpm.d/*.conf　　| 用于包含一个或多个文件，如果glob(3)存在(glob()函数返回匹配指定模式的文件名或目录)

第二部分：全局配置

由标志[global]开始：

;pid = run/php-fpm.pid　　　　　 设置pid文件的位置，默认目录路径 /usr/local/php/var
;error_log = log/php-fpm.log　　记录错误日志的文件，默认目录路径 /usr/local/php/var
;syslog.facility = daemon　　　　用于指定什么类型的程序日志消息。
;syslog.ident = php-fpm　　　　  用于FPM多实例甄别
;log_level = notice　　　　　　　 记录日志的等级，默认notice，可取值alert, error, warning, notice, debug
;emergency_restart_threshold = 0 如果子进程在这个时间段内带有IGSEGV或SIGBUS退出，则重启fpm，默认0表示关闭这个功能
;emergency_restart_interval = 0　设置时间间隔来决定服务的初始化时间（默认单位：s秒），可选s秒，m分，h时，d天
;process_control_timeout = 0　　  子进程等待master进程对信号的回应（默认单位：s秒），可选s秒，m分，h时，d天
; process.max = 128　　　　　　　　 控制最大进程数，使用时需谨慎
; process.priority = -19　　　　　 处理nice(2)的进程优先级别-19(最高)到20(最低)
;rlimit_files = 1024　　　　　　　　设置主进程文件描述符rlimit的数量
;rlimit_core = 0　　　　　　　　　　 设置主进程rlimit最大核数
;events.mechanism = epoll　　　　　使用处理event事件的机制
　　; - select     (any POSIX os)
　　; - poll       (any POSIX os)
　　; - epoll      (linux >= 2.5.44)
　　; - kqueue     (FreeBSD >= 4.1, OpenBSD >= 2.9, NetBSD >= 2.0)
　　; - /dev/poll  (Solaris >= 7)
　　; - port       (Solaris >= 10)
;daemonize = yes　　　　　　　　　　 将fpm转至后台运行，如果设置为“no”，那么fpm会运行在前台
;systemd_interval = 10

第三部分：进程池的定义

通过监听不同的端口和不用管理选择可以定义多个不同的子进程池，进程池被用与记录和统计，对于fpm能够处理进程池数目的多少并没有限制

其中$pool变量可以在任何指令中使用，他将会替代相应的进程池名字。例如：这里的[www]

[root@test ～]# ps -ef | grep php-fpm
root      3028     1  0 20:33 ?        00:00:00 php-fpm: master process (/usr/local/php/etc/php-fpm.conf)
nobody    3029  3028  0 20:33 ?        00:00:00 php-fpm: pool www          
nobody    3030  3028  0 20:33 ?        00:00:00 php-fpm: pool www

[www]
; It only applies on the following directives:
; - 'access.log'
; - 'slowlog'
; - 'listen' (unixsocket)
; - 'chroot'
; - 'chdir'
; - 'php_values'
; - 'php_admin_values'

;prefix = /path/to/pools/$pool   如果没有制定，将使用全局prefix替代
user = nobody　　　　　　　　　　　　 进程的发起用户和用户组，用户user是必须设置，group不是
group = nobody
listen = 127.0.0.1:9000　　　　　　 监听ip和端口
;listen.backlog = 65535　　　　　　 设置listen(2)函数backlog
;listen.owner = nobody
;listen.group = nobody
;listen.mode = 0660
;listen.acl_users =
;listen.acl_groups =
;listen.allowed_clients = 127.0.0.1 允许FastCGI客户端连接的IPv4地址，多个地址用','分隔，为空则允许任何地址发来链接请求
; process.priority = -19
pm = dynamic　　　　　　　　　　　　　 选择进程池管理器如何控制子进程的数量
　　static：　　对于子进程的开启数路给定一个锁定的值(pm.max_children)
　　dynamic:　 子进程的数目为动态的，它的数目基于下面的指令的值(以下为dynamic适用参数)
　　　　pm.max_children：  同一时刻能够存货的最大子进程的数量
　　　　pm.start_servers： 在启动时启动的子进程数量
　　　　pm.min_spare_servers： 处于空闲"idle"状态的最小子进程，如果空闲进程数量小于这个值，那么相应的子进程会被创建
　　　　pm.max_spare_servers： 最大空闲子进程数量，空闲子进程数量超过这个值，那么相应的子进程会被杀掉。
　　ondemand： 在启动时不会创建，只有当发起请求链接时才会创建(pm.max_children, pm.process_idle_timeout)

pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
;pm.process_idle_timeout = 10s;　　空闲进程超时时间
;pm.max_requests = 500　　　　　　　 在派生新的子进程前，每一个子进程应该处理的请求数目，在第三方库中解决内存溢出很有用，设置为0则不会限制
;pm.status_path = /status　　　     配置一个URI，以便查看fpm状态页
状态页描述：
　　accepted conn: 该进程池接受的请求数量
　　pool: 进程池的名字
　　process manager: 进程管理，就是配置中pm指令，可以选择值static，dynamic，ondemand
　　idle processes: 空闲进程数量
　　active processes: 当前活跃的进程数量
　　total processes: 总的进程数量=idle+active
　　max children reached: 达到最大子进程的次数，达到进程的限制，当pm试图开启更多的子进程的时候(仅当pm工作在dynamic时)
;ping.path = /ping　　　　该ping URI将会去调用fpm监控页面，如果这个没有设置，那么不会有URI被做为ping页
;ping.response = pong　　用于定制平请求的响应，响应的格式text/plain(对200响应代码)
;access.log = log/$pool.access.log
;access.format = "%R - %u %t \"%m %r%Q%q\" %s %f %{mili}d %{kilo}M %C%%"
　　; The following syntax is allowed
　　;  %%: the '%' character
　　;  %C: %CPU used by the request
　　;      it can accept the following format:
　　;      - %{user}C for user CPU only
　　;      - %{system}C for system CPU only
　　;      - %{total}C  for user + system CPU (default)
　　;  %d: time taken to serve the request
　　;      it can accept the following format:
　　;      - %{seconds}d (default)
　　;      - %{miliseconds}d
　　;      - %{mili}d
　　;      - %{microseconds}d
　　;      - %{micro}d
　　;  %e: an environment variable (same as $_ENV or $_SERVER)
　　;      it must be associated with embraces to specify the name of the env
　　;      variable. Some exemples:
　　;      - server specifics like: %{REQUEST_METHOD}e or %{SERVER_PROTOCOL}e
　　;      - HTTP headers like: %{HTTP_HOST}e or %{HTTP_USER_AGENT}e
　　;  %f: script filename
　　;  %l: content-length of the request (for POST request only)
　　;  %m: request method
　　;  %M: peak of memory allocated by PHP
　　;      it can accept the following format:
　　;      - %{bytes}M (default)
　　;      - %{kilobytes}M
　　;      - %{kilo}M
　　;      - %{megabytes}M
　　;      - %{mega}M
　　;  %n: pool name
　　;  %o: output header
　　;      it must be associated with embraces to specify the name of the header:
　　;      - %{Content-Type}o
　　;      - %{X-Powered-By}o
　　;      - %{Transfert-Encoding}o
　　;      - ....
　　;  %p: PID of the child that serviced the request
　　;  %P: PID of the parent of the child that serviced the request
　　;  %q: the query string
　　;  %Q: the '?' character if query string exists
　　;  %r: the request URI (without the query string, see %q and %Q)
　　;  %R: remote IP address
　　;  %s: status (response code)
　　;  %t: server time the request was received
　　;      it can accept a strftime(3) format:
　　;      %d/%b/%Y:%H:%M:%S %z (default)
　　;  %T: time the log has been written (the request has finished)
　　;      it can accept a strftime(3) format:
　　;      %d/%b/%Y:%H:%M:%S %z (default)
　　;  %u: remote user
;slowlog = log/$pool.log.slow　　 用于记录慢请求
;request_slowlog_timeout = 0　　  慢日志请求超时时间，对一个php程序进行跟踪。
;request_terminate_timeout = 0　　终止请求超时时间，在worker进程被杀掉之后，提供单个请求的超时间隔。由于某种原因不停止脚本执行时，应该使用该选项，0表示关闭不启用
　　(在php.ini中，max_execution_time 一般设置为30，表示每一个脚本的最大执行时间)
;rlimit_files = 1024　　　　　　　　设置打开文件描述符的限制
;rlimit_core = 0　　　　　　　　　　 设置内核对资源的使用限制，用于内核转储
;chroot =　　　　　　　　　　　　　　　设置chroot路径，程序一启动就将其chroot放置到指定的目录下，该指令值必须是一个绝对路径
;chdir = /var/www　　　　　　　　　　在程序启动时将会改变到指定的位置(这个是相对路径，相对当前路径或chroot后的“/”目录)　　　　
;catch_workers_output = yes　　　　将worker的标准输出和错误输出重定向到主要的错误日志记录中，如果没有设置，根据FastCGI的指定，将会被重定向到/dev/null上
;clear_env = no　　　　　　　　　　  清理环境
;security.limit_extensions = .php .php3 .php4 .php5　　限制FPM执行解析的扩展名
;env[HOSTNAME] = $HOSTNAME
;env[PATH] = /usr/local/bin:/usr/bin:/bin
;env[TMP] = /tmp
;env[TMPDIR] = /tmp
;env[TEMP] = /tmp

; Additional php.ini defines, specific to this pool of workers. These settings
; overwrite the values previously defined in the php.ini. The directives are the
; same as the PHP SAPI:
;   php_value/php_flag             - you can set classic ini defines which can
;                                    be overwritten from PHP call 'ini_set'.
;   php_admin_value/php_admin_flag - these directives won't be overwritten by
;                                     PHP call 'ini_set'
; For php_*flag, valid values are on, off, 1, 0, true, false, yes or no.

; Defining 'extension' will load the corresponding shared extension from
; extension_dir. Defining 'disable_functions' or 'disable_classes' will not
; overwrite previously defined php.ini values, but will append the new value
; instead.

;php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -i -f www@my.domain.com
;php_flag[display_errors] = off
;php_admin_value[error_log] = /var/log/fpm-php.www.log
;php_admin_flag[log_errors] = on
;php_admin_value[memory_limit] = 32M
　　

总结

1) 在php-fpm的配置文件中，有两个指令非常重要，就是"pm.max_children" 和 "request_terminate_timeout"

　第一个指令"pm.max_children" 确定了php-fpm的处理能力，原则上时越多越好，但这个是在内存足够打的前提下，每开启一个php-fpm进程要占用近30M左右的内存

　如果请求访问较多，那么可能会出现502，504错误。对于502错误来说，属于繁忙进程而造成的，对于504来说，就是客户发送的请求在限定的时间内没有得到相应，过多的请求导致“504  Gateway  Time-out”。这里也有可能是服务器带宽问题。

    另外一个需要注意的指令"request_terminate_timeout"，它决定php-fpm进程的连接/发送和读取的时间，如果设置过小很容易出现"502 Bad Gateway" 和 “504  Gateway  Time-out”，默认为0，就是说没有启用，不加限制，但是这种设置前提是你的php-fpm足够健康，这个需要根据实际情况加以限定。

 php-fpm进程管理

pm = dynamic //动态进程管理，也可以是static(只有pm.max_children生效)
pm.max_children = 50 //最大子进程数，ps aux可以查看
pm.start_servers = 20 //启动服务时会启动的进程数
pm.min_spare_servers = 5 //定义在空闲时段，子进程数的最少数量，如果达到这个数值时，php-fpm服务会自动派生新的子进程。
pm.max_spare_servers = 35 //定义在空闲时段，子进程数的最大值，如果高于这个数值就开始清理空闲的子进程。
pm.max_requests = 500 //定义一个子进程最多处理的请求数，也就是说在一个php-fpm的子进程最多可以处理这么多请求，当达到这个数值时，它会自动退出。