nginx禁用des加密

1. 只是nginx 开启 ssl 后端的 tomcat 不用 ssl，这样有安全风险吗

如果能确保nginx到Tomcat的网络链路是安全的，不会被监听、篡改，可以不用ssl
如nginx和Tomcat位于安全可信的局域网内，二者通信可以不加密

2. 常见的几种SSL/TLS漏洞及攻击方式

SSL/TLS漏洞目前还是比较普遍的，首先关闭协议：SSL2、SSL3（比较老的SSL协议）配置完成ATS安全标准就可以避免以下的攻击了，最新的服务器环境都不会有一下问题，当然这种漏洞都是自己部署证书没有配置好导致的。

Export 加密算法

Export是一种老旧的弱加密算法，是被美国法律标示为可出口的加密算法，其限制对称加密最大强度位数为40位，限制密钥交换强度为最大512位。这是一个现今被强制丢弃的算法。

Downgrade（降级攻击）

降级攻击是一种对计算机系统或者通信协议的攻击，在降级攻击中，攻击者故意使系统放弃新式、安全性高的工作方式，反而使用为向下兼容而准备的老式、安全性差的工作方式，降级攻击常被用于中间人攻击，讲加密的通信协议安全性大幅削弱，得以进行原本不可能做到的攻击。 在现代的回退防御中，使用单独的信号套件来指示自愿降级行为，需要理解该信号并支持更高协议版本的服务器来终止协商，该套件是TLS_FALLBACK_SCSV(0x5600)

MITM（中间人攻击）

MITM(Man-in-the-MiddleAttack) ，是指攻击者与通讯的两端分别创建独立的联系，并交换其所有收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个对话都被攻击者完全控制，在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。一个中间人攻击能成功的前提条件是攻击者能够将自己伪装成每个参与会话的终端，并且不被其他终端识破。

BEAST（野兽攻击）

BEAST(CVE-2011-3389) BEAST是一种明文攻击，通过从SSL/TLS加密的会话中获取受害者的COOKIE值（通过进行一次会话劫持攻击），进而篡改一个加密算法的 CBC（密码块链）的模式以实现攻击目录，其主要针对TLS1.0和更早版本的协议中的对称加密算法CBC模式。

RC4 加密算法

由于早期的BEAST野兽攻击而采用的加密算法，RC4算法能减轻野兽攻击的危害，后来随着客户端版本升级，有了客户端缓解方案（Chrome 和 Firefox 提供了缓解方案），野兽攻击就不是什么大问题了。同样这是一个现今被强制丢弃的算法。

CRIME（罪恶攻击）

CRIME(CVE-2012-4929)，全称Compression Ratio Info-leak Made Easy，这是一种因SSL压缩造成的安全隐患，通过它可窃取启用数据压缩特性的HTTPS或SPDY协议传输的私密Web Cookie。在成功读取身份验证Cookie后，攻击者可以实行会话劫持和发动进一步攻击。

SSL 压缩在下述版本是默认关闭的： nginx 1.1.6及更高/1.0.9及更高（如果使用了 OpenSSL 1.0.0及更高）， nginx 1.3.2及更高/1.2.2及更高（如果使用较旧版本的 OpenSSL）。

如果你使用一个早期版本的 nginx 或 OpenSSL，而且你的发行版没有向后移植该选项，那么你需要重新编译没有一个 ZLIB 支持的 OpenSSL。这会禁止 OpenSSL 使用 DEFLATE 压缩方式。如果你禁用了这个，你仍然可以使用常规的 HTML DEFLATE 压缩。

Heartbleed（心血漏洞）

Heartbleed(CVE-2014-0160) 是一个于2014年4月公布的 OpenSSL 加密库的漏洞，它是一个被广泛使用的传输层安全（TLS）协议的实现。无论是服务器端还是客户端在 TLS 中使用了有缺陷的 OpenSSL，都可以被利用该缺陷。由于它是因 DTLS 心跳扩展（RFC 6520）中的输入验证不正确（缺少了边界检查）而导致的，所以该漏洞根据“心跳”而命名。这个漏洞是一种缓存区超读漏洞，它可以读取到本不应该读取的数据。如果使用带缺陷的Openssl版本，无论是服务器还是客户端，都可能因此受到攻击。

POODLE漏洞（卷毛狗攻击）

2014年10月14号由Google发现的POODLE漏洞，全称是Padding Oracle On Downloaded Legacy Encryption vulnerability，又被称为“贵宾犬攻击”（CVE-2014-3566），POODLE漏洞只对CBC模式的明文进行了身份验证，但是没有对填充字节进行完整性验证，攻击者窃取采用SSL3.0版加密通信过程中的内容，对填充字节修改并且利用预置填充来恢复加密内容，以达到攻击目的。

TLS POODLE（TLS卷毛狗攻击）

TLS POODLE(CVE-2014-8730) 该漏洞的原理和POODLE漏洞的原理一致，但不是SSL3协议。由于TLS填充是SSLv3的一个子集，因此可以重新使用针对TLS的POODLE攻击。TLS对于它的填充格式是非常严格的，但是一些TLS实现在解密之后不执行填充结构的检查。即使使用TLS也不会容易受到POODLE攻击的影响。

CCS

CCS(CVE-2014-0224) 全称openssl MITM CCS injection attack，Openssl 0.9.8za之前的版本、1.0.0m之前的以及1.0.1h之前的openssl没有适当的限制ChangeCipherSpec信息的处理，这允许中间人攻击者在通信之间使用0长度的主密钥。

FREAK

FREAK(CVE-2015-0204) 客户端会在一个全安全强度的RSA握手过程中接受使用弱安全强度的出口RSA密钥，其中关键在于客户端并没有允许协商任何出口级别的RSA密码套件。

Logjam

Logjam(CVE-2015-4000) 使用 Diffie-Hellman 密钥交换协议的 TLS 连接很容易受到攻击，尤其是DH密钥中的公钥强度小于1024bits。中间人攻击者可将有漏洞的 TLS 连接降级至使用 512 字节导出级加密。这种攻击会影响支持 DHE_EXPORT 密码的所有服务器。这个攻击可通过为两组弱 Diffie-Hellman 参数预先计算 512 字节质数完成，特别是 Apache 的 httpd 版本 2.1.5 到 2.4.7，以及 OpenSSL 的所有版本。

DROWN（溺水攻击/溺亡攻击）

2016年3月发现的针对TLS的新漏洞攻击——DROWN（Decrypting RSA with Obsolete and Weakened eNcryption，CVE-2016-0800），也即利用过时的、弱化的一种RSA加密算法来解密破解TLS协议中被该算法加密的会话密钥。 具体说来，DROWN漏洞可以利用过时的SSLv2协议来解密与之共享相同RSA私钥的TLS协议所保护的流量。 DROWN攻击依赖于SSLv2协议的设计缺陷以及知名的Bleichenbacher攻击。

通常检查以下两点服务器的配置

• 服务器允许SSL2连接，需要将其关闭。

• 私钥同时用于允许SSL2连接的其他服务器。例如，Web服务器和邮件服务器上使用相同的私钥和证书，如果邮件服务器支持SSL2，即使web服务器不支持SSL2，攻击者可以利用邮件服务器来破坏与web服务器的TLS连接。

Openssl Padding Oracle

Openssl Padding Oracle(CVE-2016-2107) openssl 1.0.1t到openssl 1.0.2h之前没有考虑某些填充检查期间的内存分配，这允许远程攻击者通过针对AES CBC会话的padding-oracle攻击来获取敏感的明文信息。

强制丢弃的算法

• aNULL 包含了非验证的 Diffie-Hellman 密钥交换，这会受到中间人（MITM）攻击

• eNULL 包含了无加密的算法（明文）

• EXPORT 是老旧的弱加密算法，是被美国法律标示为可出口的

• RC4 包含的加密算法使用了已弃用的 ARCFOUR 算法

• DES 包含的加密算法使用了弃用的数据加密标准（DES）

• SSLv2 包含了定义在旧版本 SSL 标准中的所有算法，现已弃用

• MD5 包含了使用已弃用的 MD5 作为哈希算法的所有算法

3. SSL/TLS 受诫礼；SSL/TLS RC4 信息泄露的问题

该IP地址启动了SSL证书，目前启动RC4加密属于不安全协议，所以需要禁止！

尝试收到处理漏洞：

1. 禁止apache服务器使用RC4加密算法
   vi /etc/httpd/conf.d/ssl.conf
   修改为如下配置
   SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!RC4
   重启apache服务

2. 关于nginx加密算法

   1.0.5及以后版本，默认SSL密码算法是HIGH:!aNULL:!MD5

   0.7.65、0.8.20及以后版本，默认SSL密码算法是HIGH:!ADH:!MD5

   0.8.19版本，默认SSL密码算法是 ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM

   0.7.64、0.8.18及以前版本，默认SSL密码算法是ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

   低版本的nginx或没注释的可以直接修改域名下ssl相关配置为

   ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES

   256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GC

   M-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

   ssl_prefer_server_ciphers on;

   需要nginx重新加载服务

其它解决办法：升级服务器环境到最新版，重新配置服务器SSL证书就可以直接解决，详情联系服务器环境技术人员处理。

4. 如何在nginx服务器部署ssl证书

1、创建SSL证书

1.1生产私钥，openssl genrsa -des3 -out xn2.lqb.com.key 2048。此命令将生成2048位的RSA私钥，使用DES3算法，私钥文件名可任意命名，在Nginx配置中指定文件路径即可，会提示设定私钥密码，请设置密码，并牢记。

[root@Monitorssl]#opensslgenrsa-des3-outxn2.lqb.com2048 GeneratingRSAprivatekey,2048bitlongmolus …………………………….+++ ……………………………………………….+++ eis65537(0x010001) Enterpassphraseforxn2.lqb.com: Verifying-Enterpassphraseforxn2.lqb.com:

1.2以上生产的key是有密码的，如果把密码去除，执行如下命令openssl rsa -in xn2.lqb.com -out xn2.lqb.com_nopwd.key

[root@Monitorssl]#ls xn2.lqb.com [root@Monitorssl]#opensslrsa-inxn2.lqb.com-outxn2.lqb.com_nopwd.key Enterpassphraseforxn2.lqb.com: writingRSAkey

1.3由已生产的私钥生成证书请求文件CSR。openssl rsa -in xn2.lqb.com -out xn2.lqb.com_nopwd.key

[root@Monitorssl]#opensslrsa-inxn2.lqb.com-outxn2.lqb.com_nopwd.key Enterpassphraseforxn2.lqb.com: writingRSAkey [root@Monitorssl]#opensslreq-new-keyxn2.lqb.com-outxn2.lqb.com.csr Enterpassphraseforxn2.lqb.com: intoyourcertificaterequest. . , Ifyouenter’.’,thefieldwillbeleftblank. —– CountryName(2lettercode)[AU]:CN StateorProvinceName(fullname)[Some-State]:shanghai LocalityName(eg,city)[]:shanghai OrganizationName(eg,company)[InternetWidgitsPtyLtd]:xn2.lqb.com OrganizationalUnitName(eg,section)[]:IT CommonName(e.g.serverFQDNorYOURname)[]:xn2.lqb.com EmailAddress[]:[email protected] Pleaseenterthefollowing’extra’attributes Achallengepassword[]: Anoptionalcompanyname[]: [root@Monitorssl]#ls xn2.lqb.comxn2.lqb.com.csrxn2.lqb.com_nopwd.key

1.4.证书请求文件CSR文件必须有CA的签名才能形成证书，可以将此CSR发给StartSSL(可免费)、verisign(一大笔钱)等地方由他来验证。也可以自己做CA，自己给自己颁发证书。创建一个自己签署的CA证书。openssl req -new -x509 -days 3650 -key xn2.lqb.com -out xn2.lqb.com.crt

[root@Monitorssl]#opensslreq-new-x509-days3650-keyxn2.lqb.com-outxn2.lqb.com.crt xn2.lqb.comxn2.lqb.com.csrxn2.lqb.com_nopwd.key [root@Monitorssl]#opensslreq-new-x509-days3650-keyxn2.lqb.com_nopwd.key-outxn2.lqb.com.crt intoyourcertificaterequest. . , Ifyouenter’.’,thefieldwillbeleftblank. —– CountryName(2lettercode)[AU]:CN StateorProvinceName(fullname)[Some-State]:Shanghai LocalityName(eg,city)[]:shanghai OrganizationName(eg,company)[InternetWidgitsPtyLtd]:lqb.com OrganizationalUnitName(eg,section)[]:IT CommonName(e.g.serverFQDNorYOURname)[]:xn2.lqb.com EmailAddress[]: [root@Monitorssl]#ls xn2.lqb.comxn2.lqb.com.crtxn2.lqb.com.csrxn2.lqb.com_nopwd.key

2、配置nginx虚拟主机文件

[root@Monitorssl]#vim../server.conf server{ listen80; server_namexn2.lqb.com; root/html/xn2; #rewrite^/(.*)$https:xn3.lqb.com/$1permanent; location/{ indexindex.html; #proxy_cachemycache; #proxy_cache_valid2003h; #proxy_cache_valid30130210m; #proxy_cache_validall1m; #proxy_cache_use_staleerrortimeouthttp_500http_502http_503; # #proxy_passhttp://192.168.180.9; #proxy_set_headerHost$host; #proxy_set_headerX-Real-IP$remote_addr; } location/images/ { indexindex.html; } } server{ listen*:443; server_namexn2.lqb.com; sslon;###位虚拟主机开启ssl支持 ssl_certificate/usr/local/nginx/conf/server/ssl/xn2.lqb.com.crt;###为虚拟主机指定签名证书文件 ssl_certificate_key/usr/local/nginx/conf/server/ssl/xn2.lqb.com_nopwd.key;###为虚拟主机指定私钥文件 ##ssl_session_timeout5m;####客户端能够重复使用存储在缓存中的会话参数时间 root/html/xn3; location/images/{ indexindex.html; } location/{ proxy_passhttp://192.168.180.23; proxy_set_headerHost$host; proxy_set_headerX-Real-IP$remote_addr; } }

5. 请教个nginx 配置SSL的问题

生成证书
可以通过以下步骤生成一个简单的证书：
首先，进入你想创建证书和私钥的目录，例如：
$ cd /usr/local/nginx/conf
创建服务器私钥，命令会让你输入一个口令：
$ openssl genrsa -des3 -out server.key 1024
创建签名请求的证书（CSR）：
$ openssl req -new -key server.key -out server.csr
在加载SSL支持的Nginx并使用上述私钥时除去必须的口令：
$ cp server.key server.key.org
$ openssl rsa -in server.key.org -out server.key
配置nginx
最后标记证书使用上述私钥和CSR：
$ openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
修改Nginx配置文件，让其包含新标记的证书和私钥：
server {
server_name YOUR_DOMAINNAME_HERE;
listen 443;
ssl on;
ssl_certificate /usr/local/nginx/conf/server.crt;
ssl_certificate_key /usr/local/nginx/conf/server.key;
}
重启nginx。
这样就可以通过以下方式访问：
https://YOUR_DOMAINNAME_HERE
另外还可以加入如下代码实现80端口重定向到443IT人乐园
server {
listen 80;
server_name ww.centos.bz;
rewrite ^(.*) https://$server_name$1 permanent;
}

6. 如何用Nginx快速搭建一个安全的微服务架构

教你如何用Nginx搭建一个安全的、快速的微服务架构
今天我们要谈论微服务以及如何使用Nginx构建一个快速的、安全的网络系统。最后，我们将向您展示一个使用Fabric模式如何非常快速和轻松地构建一个微服务的demo。
在我们探讨Fabric模式之前，我想谈一谈微服务并且从Nginx的角度来看这意味着什么。
0：56 - 大转变

微服务已经引起了应用程序架构的重大转变。

当我第一次开始构建应用程序时，他们都是差不多的。幻灯片中所展示的单体架构也象征了应用程序的构造方式。
目前存在着某种类型的虚拟机（VM），对我来说，就是通常的Java。在虚拟机中应用的功能组件以对象的形式存在，这些对象是在内存中相互通讯的，它们将来来回回处理并进行方法调用。偶尔，你会采用诸如通知等机制来接触到其他系统以便获取数据或传递信息。

有了微服务之后，应用程序如何构建的范式是完全不同的了。你的功能组件会从在同一个主机的内存中通过虚拟机相互通讯转变到部署在容器中，并且使用Restful API调用通过HTTP来相互连接。
这是非常强大的，因为它赋予了你功能隔离。它为您提供了更细粒度的可伸缩性，并且你可以获得更好地处理故障的弹性。很多情况下这是简单的事实，你只需要使用HTTP进行跨网络调用。
现在，这种方法也有一些缺点。
一件轶事


我有一个暗黑的秘密，我是一个微软的员工并且从事.Net开发已经很多年了。当我在那儿的时候，我搭建了一个他们的名为Showcase的视频发布平台。
Showcase是一个用来将微软内部发布的所有视频发布到网上的工具。人们可以观看这些视频并进行学习，比如Microsoft Word的使用提示和技巧。这是一个非常受欢迎的平台，我们有很多人使用它，并且其中很多人都会在我们发布的视频上发表评论。
Showcase从一开始就是一个.Net单体应用，随着它日益受欢迎，我们决定应该将它更换为SOA架构。转换是相对容易的。Visual Studio提供了本质上的翻转开关的能力，也就是将你的DLL调用转变为Restful API调用。随着一些小的重构，我们能够让我们的代码运行得相当好。我们也为这些评论和应用内的社区功能使用智能社区服务。
紧密的回路问题


看起来我们是SOA可行的，在我们的首次测试中，一切都工作正常，直到我们将系统切换到我们的Staging环境并开始使用生产环境数据时，我们就会看到一些严重的问题。这些问题在在页面上有很多评论。
这是一个非常受欢迎的平台，其中的一些页面已经有多达2000条评论了。当我们深入这些问题时，我们意识到这些页面需要花费一分钟进行渲染的原因是因为智能社区服务首先需要填充用户名，然后对每一个用户名都需要发起一个对于用户数据库的网络调用来获得用户详细信息并且填充在渲染页面上。这是非常低效的，需要一到两分钟来渲染页面，而在内存中进行通常只需要5到6秒钟。
缓解


当我们经历了发现和解决问题的过程后，我们最终通过一些措施来调整优化系统，比如对所有的请求进行分组。我们缓存了一些数据，最终我们优化了网络来真正的提高性能。
所以，这与微服务有什么关系呢？对的，借助于微服务，你基本上是采用SOA架构的，并且会将其放入超光速引擎中。在SOA架构中所有的对象都是包含在单个虚拟机中并且在其内部管理，在内存中相互通讯，而现在微服务中是使用HTTP进行数据交换的。
当这样做没有问题时，你会获得很好的性能和线性可伸缩性。
Nginx能够很好地与微服务工作


Nginx是一个你可以用来过渡到微服务的最佳工具之一。
关于Nginx和微服务的一些历史。我们从一开始就参与了微服务运动，还是第一个从Docker Hub下载应用的，我们的客户以及那些拥有一些世界上最大的微服务安装量的最终用户广泛地在他们的基础设施使用Nginx。
原因是Nginx很小、很快并且很可靠。
Nginx微服务参考架构


我们还致力于在Nginx内部使用微服务工作已经有一段时间了。这是一个我们已经搭建的程式化的Nginx微服务参考架构，目前正在AWS上运行。
我们拥有6个核心的微服务，它们都运行在Docker容器里。我们决定建立一个多语种的应用，所以每个容器都可以运行不同的语言，我们目前使用了Ruby、Python、PHP、Java和Node.js。
我们搭建了这个使用十二要素应用的系统，稍加修改，就会使其更好地为微服务工作从而可以替代Roku平台。稍后，我们将向您展示一个实际上运行在demo里的应用。
MRA的价值


为什么我们要建立这样一个参考的微服务架构呢？
我们建立这个参考架构是因为我们需要给我们的客户提供构建微服务的蓝图，我们也想在微服务上下文中测试Nginx和Nginx Plus的功能，弄清楚如何才能更好地利用它的优势。最后，我们要确保我们对于微服务生态系统以及其可以给我们提供什么有一个深入的理解。
网络问题


让我们回到我们讨论的大转变。
从将运行在内存里并且被虚拟机管理的你的应用的所有功能组件迁移到通过网络进行工作并且相互通讯的方式，你会本质上引入一系列为了应用有效工作需要你解决的问题。
第一你需要服务发现，第二，你需要在架构中为所有不同的实例进行负载均衡，然后还有第三个，你需要操心性能和安全。
无论是好是坏，这些问题密不可分，你必须做权衡，有希望的是我们有一个可以解决所有这些问题的解决方案。
让我们更深入地看待每一个问题。
服务发现

让我们来谈谈服务发现。在单体应用中，APP引擎会管理所有的对象关系，你永远不必担心一个对象与另一个对象的相对位置，你只需要简单的调用一个方法，虚拟机会连接到对象实例，然后在调用完毕后销毁。
然后有了微服务，你需要考虑那些服务的位置。不幸的是，这不是一个普遍的标准流程。您正在使用的各种服务注册中心，无论是Zookeeper、Consul、etcd或者其它的，都会以不同的方式进行工作。在这个过程中，你需要注册你的服务，还需要能够读取这些服务在哪里并且可以被连接。
负载均衡


第二个问题是关于负载均衡的。当您拥有多个服务实例时，您希望能够轻松地连接到它们，将您的请求在它们中高效地分发，并以最快的方式执行，所以不同实例之间的负载均衡是非常重要的问题。
不幸的是，最简单形式的负载均衡是非常低效的。当你开始使用不同的更加复杂的方案做负载均衡时，它也变得更加复杂并且不易于管理。理想情况下，您希望您的开发人员能够基于他们的应用程序的需求决定何种负载均衡方案。例如，如果你连接到一个有状态的应用程序，你需要拥有持久化，这样可以确保你的Session信息会被保留。
安全和快速通讯


也许微服务最令人生畏的领域是性能和安全。
当在内存中运行时，一切都很快。现在，运行在网络上就会慢了一个数量级。
被安全地包含在一个系统中的信息，通常是二进制格式的，现在会被用文本格式在网络上传输。现在是比较容易在网络上布置嗅探器并能够监听你的应用正在被移动的所有数据。
如果要在传输层加密数据，那么会在连接速率和CPU使用率方面引入显着的开销。SSL/TLS在其全面实施阶段需要九个步骤来初始化一个请求。当你的系统每天需要处理成千上万、几万、数十万或数百万的请求时，这就成为性能的一个重要障碍了。
一个解决方案


我们已经在Nginx开发的一些解决方案，我们认为，会解决所有的这些问题，它赋予你健壮的服务发现、非常棒的用户可配置负载均衡以及安全和快速加密。
网络架构


让我们来谈谈你可以安装和配置你的网络架构的各种方法。
我们提出了三种网络模型，它们本身并不相互排斥，但我们认为它们属于多种格式的。这三种模式是Proxy模式、Router Mesh模式和Fabric模式——这是最复杂的，并在许多方面在其头部进行负载均衡。
Proxy模式


Proxy模式完全聚焦于你的微服务应用的入站流量，并且事实上忽略内部通讯。
你会获得Nginx提供的所有的HTTP流量管理方面的福利。你可以有SSL/TLS终止、流量整形和安全，并且借助于最新版本的Nginx Plus和ModSecurity，你可以获得WAF能力。
你也可以缓存，你可以将Nginx提供给你的单体应用的所有东西添加到你的微服务系统里，并且借助于Nginx Plus，你可以实现服务发现。当你的API实例上下浮动时，Nginx Plus可以在负载均衡工具里动态地添加和减去它们。
Router Mesh模式


Router Mesh模式类似于Proxy模式，在其中我们有一个前端代理服务来管理接入流量，但它也在服务之间添加了集中式的负载均衡。
每个服务连接到集中式的Router Mesh，它管理不同服务之间的连接分发。Router Mesh模式还允许你在熔断器模式中搭建，以便可以对你的应用添加弹性并允许你采取措施来监控和拉回你的失效的服务实例。
不幸的是，因为该模式增加了一个额外的环节，如果你不得不进行SSL/TLS加密，它事实上加剧了性能问题。这就是引入Fabric模式的原因。
Fabric模式


Fabric模式是将其头部的所有东西翻转的模式。
就像之前的另外两个模式一样，在前面会有一个代理服务器来管理流入流量，但与Router Mesh模式不同的地方就是你用运行在每个容器里的Nginx Plus来替代了集中式的Router。
这个Nginx Plus实例对于所有的HTTP流量作为反向和正向代理，使用这个系统，你可以获得服务发现、健壮的负载均衡和最重要的高性能加密网络。
我们将探讨这是如何发生的，以及我们如何处理这项工作。让我们先来看看一个服务如何连接和分发他们的请求结构的正常流程。
正常的流程


在这个图中，你可以看到投资管理器需要跟用户管理器通讯来获取信息。投资管理器创建了一个HTTP客户端，该客户端针对服务注册中心发起了一个DNS请求并获得返回的一个IP地址，接着初始化了一个到用户管理器的SSL/TLS连接，该连接需要通过九阶段的协商或者是”握手”过程。一旦数据传输完毕，虚拟机会关闭连接并进行HTTP客户端的垃圾回收。
整个过程就是这样。这是相当简单和易于理解的。当你把它分解成这些步骤时，您可以看到该模式是如何真正完成请求和响应过程的。
在Fabric模式中，我们已经改变了这一点。
Fabric模式的细节


你会注意到的第一件事是Nginx Plus是运行在每一个服务里的，并且应用程序代码是在本地与Nginx Plus通信的。因为这些是本地连接，你不需要担心加密问题。它们可以是从Java或者PHP代码到Nginx Plus实例的HTTP请求，并且都是在容器内的本地HTTP请求。
你也注意到Nginx Plus会管理到服务注册中心的连接，我们有一个解析器，通过异步查询注册中心的DNS实例来获取所有的用户管理器实例，并且预先建立连接，这样当Java服务需要从用户管理器请求一些数据的时候，可以使用预先建立的连接。
持久的SSL/TLS连接


微服务之间的有状态的、持久化的并且可以加密的连接是真正的益处。
记得在第一个图中服务实例是如何通过一些流程的吧，比如创建HTTP客户端、协商SSL/TLS连接、发起请求并关闭的吗？在这里，Nginx预先建立了微服务之间的连接，并使用Keepalive特性，保持调用之间的持续连接，这样你就不必为每一个请求处理SSL/TLS协商了。
本质上，我们创建了一个迷你的从服务到服务的VPN连接。在我们最初的测试中，我们发现连接速度增加了77%。
熔断器Plus


在Fabric模式以及Router Mesh模式中，你也可以从创建和使用熔断器模式中获得好处。
本质上，您定义了一个在服务内部的活跃的健康检查，并设置缓存，以便在服务不可用的情况下保留数据，从而获得完整的熔断器功能。
所以，现在我可以确定你认为Fabirc模式听起来很酷，并且想在实际环境中跃跃欲试。

7. nginx强制使用https是否能保证网站的安全

只能保证客户端和服务器端数据传输的安全。使用Https加密协议访问网站，可激活客户端浏览器到网站服务器之间的"SSL加密通道"（SSL协议），实现高强度双向加密传输，防止传输数据被泄露或篡改。详细介绍：https://www.wosign.com/procts/ssl.htm

8. 如何部署linux下nginx的ssl数字证书

Nginx安装SSL证书：网页链接

Nginx 自动跳转到HTTPS：网页链接

SSL证书技术支持：网页链接

注意：安装防火墙需要设置允许443端口或关闭防火墙，如果本地服务器安装安全狗的，请允许443端口。

9. Nginx启动期做了哪些事

它有1个master进程，和多个worker进程（最优配置的数量与CPU核数相关）。那么，首先我们要找到main函数，它在src/core/nginx.c文件中。谈到源码了，这时我们先简单看下源码的目录结构吧。
nginx主要有下列目录：
src/core，这个目录存放了基础的数据结构像LIST、红黑树、nginx字符串，贯穿始终的一些逻辑结构如ngx_cycle_s、ngx_connection_s等，还有对一些底层操作的封装如log、文件操作、共享内存、内存池等，最后还有个nginx.c这个main启动函数了。
src/event，这个目录下存放与抽象事件相关的结构和钩子函数。nginx是以事件驱动处理流程的，事件自然是整个体系的核心了，这里定义了最核心的ngx_event_s结构。
src/event/moles目录存放了具体的种种事件驱动方式，例如epoll、kqueue、poll、aio、select等，它们通过ngx_event_actions_t结构体中的钩子挂在nginx中。nginx启动时会根据配置来决定使用哪种实现方式。
src/os/unix中存放了unix系统下许多函数调用的UNIX实现。
src/http目录存放到http mole的相关实现，这个mole负责处理http请求，包括协议的解析以及访问backend server的代码。
src/http/mole目录存放http mole类型的一些特定用途的mole，比如gzip处理加密，图片压缩等。
有个初步了解后，回到main函数中，顺序看看我们感兴趣的事情。它先执行了ngx_time_init，为什么要初始化时间呢？nginx考虑的还是很周到的，取系统时间gettimeofday是系统调用，这意味着，需要发送中断给linux内核，内核需要做进程间切换来处理这个调用。这是一个不能忽视成本的函数。nginx封装了时间函数，这样，每次我们需要处理时间时，并不是调用gettimeofday，而是nginx自己缓存的时间，这样大量减少了系统调用，取当前时间这事可是谁都爱干的。
那么，nginx是怎么维护自己的这个时钟呢？如何保证用户取到的当前时间是有意义的？nginx设计者的出发点是，nginx是事件驱动机制，当一批事件发生时，也就是epoll_wait返回时，会取一次gettimeofday来更新自己的时间，然后调用各个事件对应的处理函数。这些函数都会保证自己是无阻塞的，也就是毫秒级的处理能力，所以，在任何一个事件处理函数中，取到的时间都是之前epoll_wait刚返回时取到的时间，这样，即使拿到的时间慢了几毫秒也无所谓。关键是，每个函数都是无阻塞的，都要迅速的把控制权交还给nginx，这是基本设计原则哈。
main函数初始化时间后，建立了最核心的数据结构ngx_cycle，之后无论是worker进程还是master进程都是围绕着它进行的。下面，我们要超级关注ngx_init_cycle这个函数，启动过程中大量的工作是在这完成的，代码就不列了，这个函数有800行，超大，也可见其之关键。ngx_init_cycle里做的第一件事就是调用所有nginx mole里的create_conf方法。好，现在我们才来详细看下nginx mole是什么。
nginx 抽象出一个ngx_mole_s结构用来描述各个mole，每个mole处理它感兴起的事件。nginx里共有多少个mole既是写死在代码中的，也是可以灵活配置的，呵呵，nginx式的玩法。回想下，下载nginx源码包后，我们也要执行它提供的configure操作，这个命令会生成makefile和ngx_moles文件，makefilel决定编译哪些mole源文件，而生成的ngx_moles.c文件决定编译出的执行文件究竟使用哪些mole。ngx_moles.c里面会生成一个数组ngx_moles，这是整个nginx工程都在使用的全局变量，它的形式如下：[cpp]ngx_mole_t*ngx_moles[]={
&ngx_core_mole,
&ngx_errlog_mole,
&ngx_conf_mole,
接上文，ngx_init_cycle就是通过ngx_moles数组来调用所有mole的create_conf方法的（每个mole有权力决定是否实现这个方法，如果不实现的话，当然不会调用了）。然后，开始处理配置文件，这里我们需要重点关注ngx_conf_parse函数，因为它里面调用了ngx_conf_handler方法，ngx_conf_handler方法会调用每个mole里自己实现的set钩子函数，让每个mole处理自己感兴趣的配置项。所以，如果你在nginx.conf里没有配置某个mole想要的东东，这个mole虽然编译进去了，却会一直不执行的。这里我们要看下mole的结构了，不能总是干说哈。
[cpp]structngx_mole_s{
ngx_uint_tctx_index;
ngx_uint_tindex;
......void*ctx;ngx_command_t*commands;
ngx_uint_ttype;
ngx_int_t(*init_master)(ngx_log_t*log);
ngx_int_t(*init_mole)(ngx_cycle_t*cycle);
ngx_int_t(*init_process)(ngx_cycle_t*cycle);

10. 怎么看自己服务器的SSL服务使用的协议版本和加密算法

SSL协议是一种安全传输协议，SSL是SecureSocketLayer的缩写，即安全套接层协议。该协议最初由Netscape企业发展而来，目前已经成为互联网上用来鉴别网站和网页浏览者的身份，以及在浏览器使用者及网页服务器之间进行加密通讯的全球化标准协议。由于SSL技术已建立到了所有主要的浏览器和WEB服务器程序当中，因此，仅需安装数字证书，或服务器证书就可以激活服务器功能了。 SSL协议能够对信用卡和个人信息提供较安全的保护。SSL是对计算机之间整个会话进行加密的协议。在SSL中，采用了公开密钥和私有密钥两种加密方法。 SSL协议的优势在于它是应用层协议确立无关的。高层的应用协议如HTTP、FTP、Telnet等能透明地建立于SSL协议之上。其在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协议所传送的数据都会被加密，从而保证我们在互联网上通信的安全。 SSL协议提供的安全服务有: 1)认证用户和服务器，确保数据发送到正确的客户机和服务器; 2)加密数据以防止数据中途被窃取; 3)维护数据的完整性，确保数据在传输过程中不被改变。 SSL的主要目的是在两个通信应用程序之间提供私密信和可靠性。这个过程通过3个元素来完成: 1、握手协议。 握手协议负责协商被用于客户机和服务器之间会话的加密参数。当一个SSL客户机和服务器第一次开始通信时，它们在一个协议版本上达成一致，选择加密算法，选择相互认证，并使用公钥技术来生成共享密钥。 2、记录协议。 记录协议用于交换应用层数据。应用程序消息被分割成可管理的数据块，还可以压缩，并应用一个MAC(消息认证代码);然后结果被加密并传输。接受方接受数据并对它解密，校验MAC，解压缩并重新组合它，并把结果提交给应用程序协议。 3、警告协议。这个协议用于指示在什么时候发生了错误或两个主机之间的会话在什么时候终止。 下面我们来看一个使用WEB客户机和服务器的范例。WEB客户机通过连接到一个支持SSL的服务器，启动一次SSL会话。支持SSL的典型WEB服务器在一个与标准HTTP请求(默认为端口80)不同的端口(默认为443)上接受SSL连接请求。当客户机连接到这个端口上时，它将启动一次建立SSL会话的握手。当握手完成之后，通信内容被加密，并且执行消息完整性检查，知道SSL会话过期。SSL创建一个会话，在此期间，握手必须只发生过一次。当SSL会话过程中出现了问题或端口设置出了问题，就会造成无法使用SSL连接现象。 SSL握手过程步骤: 步骤1:SSL客户机连接到SSL服务器，并要求服务器验证它自身的身份。 步骤2:服务器通过发送它的数字证书证明其身份。这个交换还可以包括整个证书链，直到某个根证书权威机构(CA)。通过检查有效日期并确认证书包含有可信任CA的数字签名，来验证证书。 步骤3:服务器发出一个请求，对客户端的证书进行验证。但是，因为缺乏公钥体系结构，当今的大多数服务器不进行客户端认证。 步骤4:协商用于加密的消息加密算法和用于完整性检查的哈希函数。通常由客户机提供它支持的所有算法列表，然后由服务器选择最安全的加密算法。 步骤5:客户机和服务器通过下列步骤生成会话密钥: a. 客户机生成一个随机数，并使用服务器的公钥(从服务器的证书中获得)对它加密，然后发送到服务器上 b. 服务器用更加随机的数据(从客户机的密钥可用时则使用客户机密钥;否则以明文方式发送数据)响应。 c. 使用哈希函数，从随机数据生成安全密钥。 SSL协议的优点是它提供了连接安全，具有3个基本属性: l 连接是私有的。在初始握手定义了一个密钥之后，将使用加密算法。对于数据加密使用了对称加密(例如DES和RC4)。 l 可以使用非对称加密或公钥加密(例如RSA和DSS)来验证对等实体的身份。 l 连接时可靠的。消息传输使用一个密钥的MAC，包括了消息完整性检查。其中使用了安全哈希函数(例如SHA和MD5)来进行MAC计算。 对于SSL的接受程度仅仅限于HTTP内。它在其他协议中曾被表明可以使用，但还没有被广泛应用。收藏本文章下载本文章(DOC格式)下载本文章(TXT格式)