tengine有所谓的备份节点池概念，那么localtion咋配置black up？

请教 tengine有所谓的备份节点池概念或者代码？就是一个虚拟服务在主节点池中rser全部异常时，交由被节点池处理，相当于一个server 使用两个upstream{} 。

文｜杨洋（花名：凯申 )铜锁开源密码库创始人、蚂蚁集团高级技术专家本文 2816 字，阅读 8 分钟再见 BabaSSL ，你好 Tongsuo!BabaSSL 这个名字由于其历史上的若干特殊原因，导致了其看起来是主要 SSL/TLS 协议的密码学产品，这其实并不符合整个产品的功能特性，名字本身也不够中立，这会让用户产生一定程度的误解。目前 BabaSSL 在积极推进向开放原子开源基金会的捐赠行动，并结合社区未来发展的方向，现决定对 BabaSSL 项目进行更名。新名字需要更加中立化，而且需要体现项目的功能特性。基于这些考虑，计划取新名字为：铜锁，对应拉丁字母名称为铜锁的汉语拼音“Tongsuo”。铜锁是在中华文明 5000 年历史的进程中得到了广泛应用的安全设施，且小巧、设计精妙，极具中国传统特色，符合密码库的产品特色和发展目标。一、BabaSSL  从何而来，为何而改？BabaSSL 于 2019 年诞生在蚂蚁和阿里集团内部，是基于 OpenSSL 1.1.1 版本 fork 而来的一个变种版本。创建 BabaSSL 项目的动机是在蚂蚁和阿里内部得到一个统一的 OpenSSL 变种版本，以便使用此统一版本来支撑蚂蚁和阿里内部的各种业务。这样可以减小各个业务方维护 OpenSSL 的成本，实现密码学能力的统一管理和维护，进而降低潜在的安全风险。针对蚂蚁和阿里内部的业务特点，BabaSSL 需要采用和 OpenSSL 完全不同的发展路线。简单来说，BabaSSL 需要覆盖的场景非常的多样化，包括移动端、服务器端、资源受限的嵌入式环境等。而且在算法和密码学特性的支持上，蚂蚁和阿里的业务对前沿的技术存在较大需求，因此要求 BabaSSL 需要采用相对激进的演进策略，但还要确保很高的质量标准以应对蚂蚁和阿里的业务规模。所以我们当年使用 Brisk and Better Assured Cryptography and SSL/TLS toolkit 来命名这个密码学基础库，并缩写为 BabaSSL。随着 BabaSSL 项目的发展，我们发现除了蚂蚁和阿里内部的业务对其有着重大的依赖之外，业界也对国密合规和前沿密码学技术存在较大需求。因此在 2020 年 10 月份，我们将 BabaSSL 进行了开源，并维持 BabaSSL 名称不变。随着 BabaSSL 开源社区的发展、用户数量的增多，我们逐渐发现 BabaSSL 这个名称已经无法继续肩负整个社区更大的目标和使命，因此取一个新名字就十分必要。二、我的新名字——"铜锁/Tongsuo"经过与开源社区小伙伴们共同探讨，并与开放原子开源基金会沟通后，我们最终选定了 “铜锁/Tongsuo” 作为 BabaSSL 开源项目的新名字，其含义如下：1. 铜锁的设计形象和密码学的锁形象异曲同工，都是保障安全的技术2. 铜锁的历史悠久，应用十分广泛3. 铜锁诞生于中国汉代，流行至明清，极具中国特色，代表了中国的传统文化4. 铜锁设计精妙、体积小巧，安全性高铜锁的这些特点，符合 BabaSSL 的项目定位和发展目标：适应场景最广、性能最好、可靠性最高且监管合规的开源密码学基础库。正如铜锁是中国 5000 年历史长河中为人民生命财产提供保证的最基础元素，“铜锁密码库”作为信息安全领域基础组件、中国网络空间安全和数据安全的核心基础元素，也希望能为中国人民的信息和财产安全贡献力量。铜锁的拉丁字母名称则直接采用铜锁的汉语拼音：Tongsuo，除此之外不再赋予其他含义解释，目的是集中体现中国的品牌名称和文化价值。三、更名后的一系列操作我们近期会针对 BabaSSL 开源项目进行如下的更名举措，其中部分举措可能会对用户造成影响，需额外注意：「代码库名称变更」1. 在 Github 上创建新的 Tongsuo 组织，并将 BabaSSL 代码仓库更名为 Tongsuo 后迁移其下；2. BabaSSL 代码仓库的转地址会在 Github 上自动跳转到新的 Tongsuo 仓库地址，方便已有用户访问；3. 新的 Tongsuo 代码仓库的 master 分支变更为基于 OpenSSL 3.0 代码基础，并整体迁移为 Apache License 2.0 开源许可证。由此进行相关分支变更如下：a. 现有的 master 分支更名为 master-babassl，并设置为只读模式，即不再接受新的代码合并，只留做参考用；b. 将 master-tongsuo 分支更名为 master，作为下个大版本 tongsuo-8.4.0 的开发分支。由于新的 master 分支和旧的 master 分支之间没有代码提交的逻辑关系，因此需要用户手动重新检出新的master 分支并覆盖本地的旧 master 分支内容。在此过程中如果你的本地 master 分支存在代码修改，请注意保存以免代码修改丢失。「网站改名」1. 启动 tongsuo.net 网站，并更新网站内容/品牌；2. 将对 babassl.cn 网站的访问重定向到 tongsuo.net；3. 新增 tongsuo.readthedocs.org 网站，作为铜锁项目的文档库。「Release 改名和版本策略」1. 在 8.3.x 版本中将沿用 BabaSSL 名称，即 BabaSSL 8.3.1 等后续版本；2. 从 8.4.0 开始更名为 Tongsuo。Tongsuo 延续 BabaSSL 的版本编号，不再重新定义编号。主要是考虑软件版本的升级和比较的前后兼容性问题。新的 release 包名称为：tongsuo-a.b.c.tar.gz 或 tongsuo-a.b.c.zip。「代码 API 命名修改」需要考虑兼容问题，因此 BABASSL_ 开头的 API 还需持续保留，直到 9.0 大版本发布。四、期待与你共“铜”成长经过这一年的努力，铜锁/Tongsuo 开源密码库项目通过了开放原子开源基金会的 TOC 答辩。接下来我们的重心是继续推进铜锁 8.4.0 版本的研发工作，该版本会在半同态加密算法等前沿密码学领域进行相关特性的大力支持，为铜锁的用户带来隐私计算领域的底层密码学原语能力。希望能有更多朋友参与进来，与我们共同去完善铜锁/Tongsuo，不论你所处哪一个研究领域，我们都非常期待和欢迎你的加入。此外，我们于近期建立了铜锁 （BabaSSL） 的开源项目钉钉群，方便铜锁密码库的用户们进行沟通交流，期待着能有更多的社区朋友在铜锁 （BabaSSL） 共同成长！钉钉用户交流群群号：44810299铜锁（BabaSSL）的更名涉及到较多的现有资产名称变更事宜，例如代码库改名、文档内容名称替换等。具体的相关进展和状态，我们会及时在上述钉钉群中向大家通告。了解更多…铜锁/Tongsuo Star 一下✨：https://github.com/BabaSSL/BabaSSL本周推荐阅读BabaSSL：支持半同态加密算法 EC-ElGamalBabaSSL 发布 8.3.0｜实现相应隐私计算的需求Tengine + BabaSSL ，让国密更易用！TLS 握手带宽直降 80%，BabaSSL 是怎么做到的？

nginx 介绍及安装 内容介绍一、I/O 模型二、Nginx 介绍  一、I/O 模型(1)Httpd MPMhttpd MPM :prefork :进程模型,两级结构,一个主进程 master 负责若干个生成子进程,每个子进程负责响应一个请求。 worker :线程模型,三级结构,主进程 master 负责生成子进程,每个子进程负责生成多个线程, 当用户发起请求，由每个线程响应一个请求。 event :线程模型,三级结构，主进程master 负责生成子进程,一个监控线程，回收未被利用的线程，每个子进程响应多个请求。httpd的程序非常稳定，相对来讲在一些传统的公司用web服务的话很多都是httpd，但是对于互联网公司来讲，往往会产生一些不胜任的情况，比方说当并发量达到比较大的时候，连接数过万的时候，其性能就会急剧下降，nginx据说可以应付达到三万以上的并发，主要取决于IO模型 (2)I/O 介绍I/O:网络 IO : 本质是socket 读取。对网络上的数据进行传输的时候，他本质上也算是一种IO，因为在网络编程的时候，实现的socket通讯之间无非也是读和写的机制，在 Linux 之中，一切皆文件，所以你在网络中发送文件的时候是发送到socked 文件中，通过 socked 转发到远程程序，也是用socked 接收。 磁盘 IO :每次IO ,都要经由两个阶段:第一步:将数据从磁盘文件先加载至内核内存空间(缓冲区) ,等待数据准备完成,时间较长第二步:将数据从内核缓冲区复制到用户空间的进程的内存中,时间较短一般情况下的通讯过程：当服务器收到远程通信http的请求，希望得到一个 html 文件，那这个请求会到达网卡，nginx 线程接收收到请求。而 index 文件在物理磁盘上，nginx 是一个进程是工作在用户空间的，用户空间的进程是不能返回硬件的，发请求到kernel，所以需要通过kernel 去访问磁盘，由 kernel 获取到 kernel 缓冲区，再复制到 nginx 缓冲区，来实现数据最终的得到获取，如下图 (3) I/O 模型同步/异步:关注的是消息通信机制同步: synchronous ,调用者等待被调用者返回消息,才能继续执行异步: asynchronous ,被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态 阻塞/非阻塞:关注调用者在等待结果返回之前所处的状态阻塞: blocking ,指IO操作需要彻底完成后才返回到用户空间,调用结果返回之前,调用者被挂起非阻塞: nonblocking ,指IO操作被调用后立即返回给用户一个状态值 , 无需等到IO操作彻底完成,最终的调用结果返回之前,调用者不会被挂起I/O模型:阻塞型、非阻塞型、复用型、信号驱动型、异步  (4) 同步阻塞IO模型同步阻塞IO模型是最简单的IO模型,用户线程在内核进行IO操作时被阻塞用户线程通过系统调用 read 发起 IO 读操作,由用户空间转到内核空间。内核等到数据包到达后,然后将接收的数据拷贝到用户空间,完成 read操作用户需要等待read将数据读取到buffer 后 ,才继续处理接收的数据。整个IO请求的过程中,用户线程是被阻塞的,这导致用户在发起IO请求时,不能做任何事情,对CPU 的资源利用率不够在实际工作中内核和用户进程那个效率高，相对影响用户体验，通常来讲，用户是访问应用程序的，不是访问内核的，内核是为应用程序提供服务的所以希望应用程序访问更快，用户感受更好，话句话说一件事是应用程序做还是内核做，如果应用程序做的事多了，自然对用户响应请求就更慢了，内核多做点减轻了应用程序的事那对用户响应请求就更快，延申出来希望内核做的事多一些，应用程序少做一些，这样应用程序就可以接收更多的用户请求。  (5) 同步非阻塞 IO 模型同步的意思是去访问一个资源，事情做没做完不清楚，只有自己去看。所以当要得到一个资源的时候，发一个请求由内核来完成，内核系统调用recvfrom来完成，但是是否已完成并不知道，所以只能一次次的系统调用去问，非阻塞意味着进程发一个指令给内核，希望他得到一个数据，还可以干点别的事但又由于是同步，不清楚对方做好准备没有，一直问直到数据从磁盘放到内核为止，等一会将数据从内核拷贝到用户空间，才通知整个结束。在磁盘文件复制到内核过程中，用户是并不了解的，他只有不断的轮询。用户线程发起IO请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起IO请求,直到数据到达后,才真正读取到数据,继续执行。即"轮询”机制整个IO请求的过程中，虽然用户线程每次发起IO请求后可以立即返回,但是为了等到数据,仍需要不断地轮询、重复请求,消耗了大量的 CPU 的资源是比较浪费 CPU的方式,一般很少直接使用这种模型,而是在其他IO模型中使用非阻塞IO这一特性 (6) I/O 多路复用模型不用每个进程都要和内核打交道，直接找一个专门的代理select，但进程会受阻与select，发出请求到内核，等待数据从内核复制到用户空间，将数据分成了两部分，第一个阶段是用户进程阻塞在select，第二个阶段是用户进程等待数据从内核空间复制用户空间。实际上也是总阻塞状态。虽然总体性能未提高，但有select可以面对很多用户的请求。多个连接共用一个等待机制,本模型会阻塞进程,但是进程是阻塞在 select或者 poll 这两个系统调用上,而不是阻塞在真正的IO 操作上用户首先将需要进行 IO 操作添加到 select 中,继续执行做其他的工作(异步) , 同时等待 select 系统调用返回。当数据到达时, IO 被激活，select 函数返回。用户线程正式发起 read 请求,读取数据并继续执行。从流程上来看,使用select 函数进行 IO 请求和同步阻塞模型没有太大的区别,甚至还多了添加监视 IO ,以吸调用 select函数的额外操作,效率更差。并且阻塞了两次,但是第一次阻塞在select  上时,  select 可以监控多个IO上是否已有IO操作准备就绪,即可达到在同一个线程内同时处理多个IO请求的目的。而不像阻塞IO那种,一次只能监控一个IO虽然上述方式允许单线程内处理多个IO请求,但是每个IO请求的过程还是阻塞的(在select函数上阻塞) , 平均时间甚至比同步阻塞IO模型还要长。如果用户线程只是注册自己需要的IO请求,然后去做自己的事情,等到数据到来时再进行处理,则可以提高 CPU 的利用率IO多路复用是最常使用的IO模型,但是其异步程度还不够“彻底”, 因它使用了会阻塞线程的select系统调用。因此IO多路复用只能称为异步阻塞IO模型,而非真正的异步IO 多路I/O 复用IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取,就通知该进程IO多路复用适用如下场合 :当客户端处理多个描述符时( -般是交互式输入和网络套接口) , 必须使用I/O复用当一个客户端同时处理多个套接字，多个请求时,此情况可能的但很少出现当一个 TCP 服务器既要处理监听套接字，又要处理已连接套接字，一般也要用到I/O复用当一个服务器即要处理 TCP ,又要处理 UDP，一般要使用I/O复用当一个服务器要处理多个服务或多个协议,一般要使用I/O复用 (7) 信号驱动 IO 模型具有更多的异步特性，就是调用者不需要主动问被调用者，比如当磁盘文件读取到内核当中时，数据还未得到，但进程仍可继续执行，或者响应其他用户的请求，直到磁盘文件读取到内核当中后，将数据从内核拷贝到用户空间中，但这个过程中需要等待，换句话说就是有一部分实现了异步，一部分仍是同步，意味着信号驱动IO模型将数据分成了一半阻塞不阻塞状态，效率提高了不少，因为将磁盘文件拷贝到内核空间上是最费时间的，而信号驱动IO模型可以将这时间自由分配。 信号驱动 IO : signal-driven I/O用户进程可以通过 sigaction系统调用注册一个信号处理程序,然后主程序可以继续向下执行,当有IO操作准备就绪时,由内核通知触发一个 SIGIO信号处理程序执行,然后将用户进程所需要的数据从内核空间拷贝到用户空间此模型的优势在于等待数据报到达期间进程不被阻塞。用户主程序可以继续执行,只要等待来自信号处理函数的通知该模型并不常用 (8)异步 IO 模型当用户发请求，内核得到请求从磁盘复制到内核，从内核复制到用户空间，用户程序一直在执行，没有堵塞，一直由内核复制数据，递交给应用程序。所以对于进程来讲很轻松，内核做的事更多一点，当然进程做的事越少，他的负担越小，就可以同时做更多的事。 (9)五种 I/O 模型同步IO模型一直在阻塞，同步非阻塞模型不是完全非阻塞，只是前面的阶段磁盘拷贝到内核不阻塞，但又因为是同步的还是什么都干不了，因为不清楚做没做完，所以一直消耗资源在轮询。IO复用模型都是阻塞的，只不过在前面阶段阻塞在代理select上面，只是换个地方阻塞。而信号驱动模型，前面阶段不阻塞，可以做一些事情。异步IO模型是最理想的，不阻塞。如图越往左越阻塞，越往右越不阻塞。 (10)I/O 模型的具体实现主要实现方式有以下几种:Select : Linux 实现对应, I/O复用模型, BSD4.2 最早实现Poll : Linux 实现,对应I/O复用模型, System V unix 最早实现Epoll : Linux 实现,对应I/O复用模型,具有信号驱动I/O模型的某些特性Kqueue : FreeBSD 实现,对应I/O复用模型,具有信号驱动I/O模型某些特性/dev/poll : SUN的 Solaris 实现,对应I/O复用模型,具有信号驱动I/O模型的某些特性Iocp Windows 实现 ,对应第5种(异步I/O )模型 (11)select/poll/epoll 区别epoll :在Linux 2.6内核中提出的 select 和 poll 的增强版本支持水平触发 LT和边缘触发 ET ,最大的特点在于边缘触发，它只告诉进程哪些 fd刚刚变为就需态,并且只会通知一次使用"事件”的就绪通知方式,通过 epoll_ ctl 注册 fd ,一旦该 fd 就绪,内核就会采用类似 callback 的回调机制来激活该 fd , epoll_ wait 便可以收到通知  优点:没有最大并发连接的限制:能打开的 FD 的上限远大于1024(1G的内存能监听约10万个端口) 效率提升:非轮询的方式,不会随着 FD 数目的增加而效率下降;只有活跃可用的FD 才会调用callback函数，即 epoll 最大的优点就在于它只管理“活跃"的连接,而跟连接总数无关内存拷贝,利用mmap(Memory Mapping)加速与内核空间的消息传递;即epoll 使用 mmap 减少复制开销 注：mmap 为内存映射内存映射：用 nginx 访问磁盘文件，一般情况要发指令给内核，内核跑到磁盘读取数据，数据在磁盘上存放是文件数组方式组织的，要先从磁盘找节点表inode，通过目录一层层找到文件 data，相对效率不高。 所以可以在磁盘划一块空间就是这个文件，然后把这个文件映射到内存空间，假设磁盘是16M，则内存也是16M，让两块区间一个字节一个字节对应，将来要访问文件时就可以直接访问内存里的这块空间提高了效率，如下图，  二、Nginx 介绍Nginx：engineX,2002年，开源,商业版 NGINX是免费,开源,高性能的 HTTP 和反向代理服务器,邮件代理服务器,通用 TCP/UDP 代理服务器解决 C10K 问题( 10K Connections ) 官网: http://nginx.org二次开发版:Tengine, OpenResty (章亦春)

为了节约成本，定期进行数据备份，并通过delete删除表记录。明明已经执行了delete，可表文件的大小却没减小，令人费解项目中使用Mysql作为数据库，对于表来说，一般为表结构和表数据。表结构占用空间都是比较小的，一般都是表数据占用的空间。当我们使用 delete删除数据时，确实删除了表中的数据记录，但查看表文件大小却没什么变化。Mysql数据结构凡是使用过mysql，对B+树肯定是有所耳闻的，MySQL InnoDB 中采用了 B+ 树作为存储数据的结构，也就是常说的索引组织表，并且数据时按照页来存储的。因此在删除数据时，会有两种情况：删除数据页中的某些记录删除整个数据页的内容表文件大小未更改和mysql设计有关比如想要删除 R4 这条记录：InnoDB 直接将 R4 这条记录标记为删除，称为可复用的位置。如果之后要插入 ID 在 300 到 700 间的记录时，就会复用该位置。由此可见，磁盘文件的大小并不会减少。通用删除整页数据也将记录标记删除，数据就复用用该位置，与删除默写记录不同的是，删除整页记录，当后来插入的数据不在原来的范围时，都可以复用位置，而如果只是删除默写记录，是需要插入数据符合删除记录位置的时候才能复用。因此，无论是数据行的删除还是数据页的删除，都是将其标记为删除的状态，用于复用，所以文件并不会减小。那怎么才能让表大小变小DELETE只是将数据标识位删除，并没有整理数据文件，当插入新数据后，会再次使用这些被置为删除标识的记录空间，可以使用OPTIMIZE TABLE来回收未使用的空间，并整理数据文件的碎片。OPTIMIZE TABLE 表名;注意：OPTIMIZE TABLE只对MyISAM, BDB和InnoDB表起作用。另外，也可以执行通过ALTER TABLE重建表ALTER TABLE 表名 ENGINE=INNODB有人会问OPTIMIZE TABLE和ALTER TABLE有什么区别？alter table t engine = InnoDB（也就是recreate），而optimize table t 等于recreate+analyzeOnline DDL最后，再说一下Online DDL，dba的日常工作肯定有一项是ddl变更，ddl变更会锁表，这个可以说是dba心中永远的痛，特别是执行ddl变更，导致库上大量线程处于“Waiting for meta data lock”状态的时候。因此在 5.6 版本后引入了 Online DDL。Online DDL推出以前，执行ddl主要有两种方式copy方式和inplace方式，inplace方式又称为(fast index creation)。相对于copy方式，inplace方式不拷贝数据，因此较快。但是这种方式仅支持添加、删除索引两种方式，而且与copy方式一样需要全程锁表，实用性不是很强。Online方式与前两种方式相比，不仅可以读，还可以支持写操作。执行online DDL语句的时候，使用ALGORITHM和LOCK关键字，这两个关键字在我们的DDL语句的最后面，用逗号隔开即可。示例如下：ALTER TABLE tbl_name ADD COLUMN col_name col_type, ALGORITHM=INPLACE, LOCK=NONE;ALGORITHM选项INPLACE：替换：直接在原表上面执行DDL的操作。COPY：复制：使用一种临时表的方式，克隆出一个临时表，在临时表上执行DDL，然后再把数据导入到临时表中，在重命名等。这期间需要多出一倍的磁盘空间来支撑这样的 操作。执行期间，表不允许DML的操作。DEFAULT：默认方式，有MySQL自己选择，优先使用INPLACE的方式。LOCK选项SHARE：共享锁，执行DDL的表可以读，但是不可以写。NONE：没有任何限制，执行DDL的表可读可写。EXCLUSIVE：排它锁，执行DDL的表不可以读，也不可以写。DEFAULT：默认值，也就是在DDL语句中不指定LOCK子句的时候使用的默认值。如果指定LOCK的值为DEFAULT，那就是交给MySQL子句去觉得锁还是不锁表。不建议使用，如果你确定你的DDL语句不会锁表，你可以不指定lock或者指定它的值为default，否则建议指定它的锁类型。执行DDL操作时，ALGORITHM选项可以不指定，这时候MySQL按照INSTANT、INPLACE、COPY的顺序自动选择合适的模式。也可以指定ALGORITHM=DEFAULT，也是同样的效果。如果指定了ALGORITHM选项，但不支持的话，会直接报错。OPTIMIZE TABLE 和 ALTER TABLE 表名 ENGINE=INNODB都支持Oline DDL，但依旧建议在业务访问量低的时候使用总结delete 删除数据时，其实对应的数据行并不是真正的删除，仅仅是将其标记成可复用的状态，所以表空间不会变小。可以重建表的方式，快速将delete数据后的表变小（OPTIMIZE TABLE 或ALTER TABLE），在 5.6 版本后，创建表已经支持 Online 的操作，但最好是在业务低峰时使用。如果这篇文章对您有所帮助，或者有所启发的话，求一键三连：点赞、转发、收藏，您的支持是我坚持写作最大的动力。

企业运维训练营之云上网络原理与实践课程第二讲配套实验：访问4层&7层 CLB场景对比 视频地址：https://developer.aliyun.com/learning/course/991/detail/14976 一、实验简介： 在大量真实业务场景（如微服务）中，在CLB后端提供服务的ECS之间存在服务上的依赖关系（ECS既做客户端又做服务端），本实验以CLB后端的一个ECS来访问CLB的4层监听与7层监听的端口，以理解其转发规则的不同。 实验网址：https://developer.aliyun.com/adc/scenario/exp/e39b51556c34432faae378075ac99abb 二、实验步骤： 1. 创建资源。 a.   在体验实验室页面左侧，单击创建资源，创建所需资源。b.   在页面左侧导航栏中，单击云产品资源列表，查看本次实验资源相关信息。 说明：资源创建过程需要1~3分钟。完成实验资源的创建后，您可以在云产品资源列表查看已创建的资源信息，例如：IP地址、用户名和密码等。 2. 了解实验架构。 本实验架构为1台CLB，后端挂载了2台ECS，以CLB后端的一个ECS来访问CLB的4层监听与7层监听的端口。 3. 实验准备。 注：后台已创建好了对应的云产品资源，这里仅了解和核实环境和相关配置。 如下仅供学员了解和参考，不需要去手动创建（如了解，可跳过）： 创建ECS 参考文档：https://help.aliyun.com/document_detail/25422.html私网CLB实例创建 参考文档：https://help.aliyun.com/document_detail/86454.html  4. 手动安装nginx并设置自定义首页。 注：不同学员会有属于自己的ECS实例（后台自动创建），请以实际配置中实例的信息（id、IP等）为准。系统默认资源创建过程需要1~3分钟。完成实验资源的创建后，您可以在“云产品资源”列表查看已创建的资源信息，例如：IP地址、用户名和密码等。 本实验演示的ECS示例为杭州地域下的ECS，以其ECS IP为：192.168.11.180和192.168.11.181做样例演示。 在系统内手动安装nginx（yum install nginx）； yum install nginx 在/usr/share/nginx/html目录下使用本机的hostname替换原有的index.html文件，内容为ECS本机的hostname； cd /usr/share/nginx/html/hostname > index.html 最后启动nginx服务； service nginx start  5. 将ECS1、ECS2加入到CLB的默认服务器组 注：不同学员会有属于自己的CLB实例（后台自动创建），请以实际配置中实例的信息（id、IP等）为准。 本实验演示的杭州地域clb实例ID为lb-bp1srfo9275l6vlxq9mg2，IP地址为192.168.11.175。 将ECS1、ECS2加入到CLB的默认服务器组内。  6. 创建CLB实例的监听，80端口的TCP和8080端口的HTTP，并配置默认服务器组。 7. 在CLB监听的后端服务器ECS1上安装telnet，以便访问4层CLB的80端口，同时在ECS1内部抓包。 抓包时注意需要抓取any网卡：由于回包时目标IP为本机IP，在当前的系统路由表中，本机IP的路由会走loop网卡，如果只抓eth0，会出现回包无法抓到的情况。 访问时为什么会出现时通时不通的现象？  8. 在CLB监听的后端服务器上测试ECS1访问4层CLB的80端口，并在ECS1内部抓包。 抓包时注意需要抓取any网卡。 [root@ECS1 ~]# tcpdump -nni any port 80 and not net 100.64.0.0/1013:45:15.962843 IP 192.168.11.181.48092 > 192.168.11.175.80: Flags [S], seq 3268167503, win 29200, options [mss 1460,sackOK,TS val 818983 ecr 0,nop,wscale 7], length 013:45:15.964410 IP 192.168.11.181.48092 > 192.168.11.181.80: Flags [S], seq 3268167503, win 29200, options [mss 1460,sackOK,TS val 818983 ecr 0,nop,wscale 7], length 013:45:15.964429 IP 192.168.11.181.80 > 192.168.11.181.48092: Flags [S.], seq 1270453242, ack 3268167504, win 43690, options [mss 65495,sackOK,TS val 818984 ecr 818983,nop,wscale 7], length 013:45:15.964439 IP 192.168.11.181.48092 > 192.168.11.181.80: Flags [R], seq 3268167504, win 0, length 0 9. 在CLB监听的后端服务器上测试ECS1访问4层CLB的8080端口，并在ECS内部抓包。 访问时建议需要使用curl，因为：7层监听是http层面的动作，如果只用telnet来测试，三次握手建立好了之后，客户端和proxy集群（tengine集群）进行了连接，没有发起任何数据的时候，在CLB部分集群上不会向后端ECS建立连接发送数据的，所以必须用curl实际的发送一些7层的数据。 抓包时我们关注的信息有哪些？除了192开头的IP，我们还可以看到来自100网段的IP数据包，这些数据包正是7层监听交互的表现。 14:24:03.135859 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [S], seq 1995438430, win 29200, options [mss 1460,sackOK,TS val 3146156 ecr 0,nop,wscale 7], length 014:24:03.137054 IP 192.168.11.175.8080 > 192.168.11.181.34290: Flags [S.], seq 2376897256, ack 1995438431, win 29200, options [mss 1440,nop,nop,sackOK,nop,wscale 9], length 014:24:03.137071 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [.], ack 1, win 229, length 014:24:03.137179 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [P.], seq 1:84, ack 1, win 229, length 83: HTTP: GET / HTTP/1.114:24:03.138336 IP 192.168.11.175.8080 > 192.168.11.181.34290: Flags [.], ack 84, win 58, length 014:24:03.139023 IP 100.122.64.142.2292 > 192.168.11.181.80: Flags [S], seq 1176088477, win 28480, options [mss 1424,sackOK,TS val 4003383056 ecr 0,nop,wscale 9], length 014:24:03.139038 IP 192.168.11.181.80 > 100.122.64.142.2292: Flags [S.], seq 2293269875, ack 1176088478, win 28960, options [mss 1460,sackOK,TS val 3146159 ecr 4003383056,nop,wscale 7], length 014:24:03.140054 IP 100.122.64.142.2292 > 192.168.11.181.80: Flags [.], ack 1, win 56, options [nop,nop,TS val 4003383058 ecr 3146159], length 014:24:03.140073 IP 100.122.64.142.2292 > 192.168.11.181.80: Flags [P.], seq 1:162, ack 1, win 56, options [nop,nop,TS val 4003383058 ecr 3146159], length 161: HTTP: GET / HTTP/1.114:24:03.140078 IP 192.168.11.181.80 > 100.122.64.142.2292: Flags [.], ack 162, win 235, options [nop,nop,TS val 3146160 ecr 4003383058], length 014:24:03.140254 IP 192.168.11.181.80 > 100.122.64.142.2292: Flags [FP.], seq 1:264, ack 162, win 235, options [nop,nop,TS val 3146160 ecr 4003383058], length 263: HTTP: HTTP/1.1 200 OK14:24:03.141713 IP 100.122.64.142.2292 > 192.168.11.181.80: Flags [F.], seq 162, ack 265, win 58, options [nop,nop,TS val 4003383059 ecr 3146160], length 014:24:03.141732 IP 192.168.11.181.80 > 100.122.64.142.2292: Flags [.], ack 163, win 235, options [nop,nop,TS val 3146161 ecr 4003383059], length 014:24:03.141742 IP 192.168.11.175.8080 > 192.168.11.181.34290: Flags [P.], seq 1:247, ack 84, win 58, length 246: HTTP: HTTP/1.1 200 OK14:24:03.141754 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [.], ack 247, win 237, length 014:24:03.141889 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [F.], seq 84, ack 247, win 237, length 014:24:03.143047 IP 192.168.11.175.8080 > 192.168.11.181.34290: Flags [F.], seq 247, ack 85, win 58, length 014:24:03.143056 IP 192.168.11.181.34290 > 192.168.11.175.8080: Flags [.], ack 248, win 237, length 0 三、实验分析 1、实验结果 从以上的实验结果来看，ECS1访问CLB的80端口，会出现时通时不通的表现，而访问CLB的8080端口，则是100%连通。 2、实验分析  a.   由于四层CLB下， CLB会将客户端的原始链接转发到后端服务器上，因此在这种情况下，ECS1访问CLB内网地址的80端口时相当于访问自己的80端口，从抓包可看到源目IP都是自己，在回SYN_ACK时直接由lo网卡转发到本机，内核未看到SYN_ACK包对应五元组的SYN包，导致内核直接发送了RST。 b.   七层CLB下，由于CLB在中间隔离了TCP链接，因此ECS1看到的源IP均为CLB的内网IP，因此地址不会冲突。 

企业运维训练营之云上网络原理与实践课程第二讲  负载均衡CLB（上）- 产品和架构 视频地址：https://developer.aliyun.com/learning/course/991/detail/14970课程目标了解负载均衡CLB的产品功能了解负载均衡CLB的底层架构与相关技术掌握负载均衡CLB的最佳实践熟知负载均衡CLB的常见问题与解决思路 课程目录概述相关概念与产品功能产品技术架构最佳实践常见问题与解决思路 正文： 一、概述 CLB（Classic Load Balancer）通过设置虚拟服务地址，将添加的同一地域的多台ECS实例虚拟成一个高性能和高可用的后端服务池，并根据转发规则，将来自客户端的请求分发给后端服务器池中的ECS实例。 CLB默认检查云服务器池中的ECS实例的健康状态，自动隔离异常状态的ECS实例，消除了单台ECS实例的单点故障，提高了应用的整体服务能力。此外，CLB还具备抗DDoS攻击的能力，增强了应用服务的防护能力。 １.  为什么需要负载均衡CLB架构图应对高流量的业务访问大批量用户可以正常同时访问一个接入点,是因为负载均衡器做了一定量的分发； 消除单点故障一台服务器出现故障，其他服务器仍然对外可以提供正常服务，用户使用不受影响； 对外提供统一的入口多个IP地址对外只暴露一个，对外的入口是统一的，运维管理起来比较容易； 开箱即用云产品的特点，即买即用，快速高效； ２.  负载均衡行业趋势与挑战负载均衡云化趋势明显加速负载均衡越来越多以云方式部署，云提供商逐渐成为主要玩家，传统硬件厂家加速向云转型，提供基于云化的解决方案； 5G/IoT等技术带来机遇与挑战5G/IoT将加速催生更大流量洪峰，底层通信协议的升级将网络瓶颈转移至应用层面，万物互联使得IPv4加速退出历史舞台，IPv6时代到来； 网络环境日益复杂安全性需求凸显愈加复杂的网络环境、越来越深入的面向应用系统交付，对安全提出了更高要求； 云原生:从流量入口到面向应用交付面向云原生基于7层高级特性加速企业应用快速交付能力，负载均衡从面向网络层演进到面向应用层；云原生4要素：微服务、容器化、DevOps、持续交付。 二、相关概念与产品功能 １.  负载均衡产品大图 负载均衡产品 a.  实例： 监听：负载均衡以监听为实例提供服务，如TCP监听、UDP监听、http(s)监听等，然后将请求流量分发至后端服务器；服务器组：负载均衡是转发模块，并不承载TCP业务，实际的业务通过服务器组和负载均衡产生关联，将服务器组绑定到监听上，如默认服务器组、虚拟服务器组、主备服务器组等，其中虚拟服务器支持转发策略； b.  访问控制ACL 可以针对不同的监听，设置访问白名单或黑名单，如某些金融客户只允许特定的IP地址访问； c.  证书管理 https证书会对流量进行相应保护，在https监听下，负载均衡会对证书进行托管、加解密转发控制； d.  日志 访问日志：相当于NGINX的access.log，可以通过分析负载均衡的访问日志了解客户端用户行为、客户端用户的地域分布，排查问题等；健康检查日志：后续将有详细介绍。 ２.  负载均衡SLB的核心能力：面向超大规模业务的流量入口 IPv6/IPv4公网入口  IPv6采用6To4方案，前端对外暴露IPv6地址对外提供V6服务，后端采用V4连接到ECS，轻松实现业务向从V4向V6的平滑迁移。 最大500万并发连接，应对大流量、大并发场景 丰富的实例规格，支持各种规模的业务场景,弹性计费,应对业务峰值的同时优化成本。 三、产品技术架构 １.  产品架构 阿里云负载均衡CLB产品总体技术架构如下：  双AZ容灾高可用架构双可用区部署，主备容灾实现高可用，业务Always Online； 海量4层业务处理能力LVS高性能集群处理4层业务流量应对海量业务洪峰； 基于内容的7层业务路由Tengine集群处理7层业务流量，基于内容的业务路由； 高性能HTTPS加解密硬解密卡实现高效HTTPS流量终结,节省后端服务器算力； ２.  全链路流量走向 所有流量都需要经过LVS集群进行转发；LVS集群内的每一台节点服务器均匀地分配海量访问请求；7层监听会额外经过Tengine集群,HTTPS协议首次请求还会经过Key Server集群；CLB与后端ECS、ENI通信走内网； ３.  健康检查  健康检查是对CLB集群对后端进行一个探测，多台ECS同时提供一个服务，通过健康检查可以追踪的故障服务，避免了后端ECS异常对总体服务的影响。 健康检查可以感知到后端ECS的可用性探测源均是承载业务的转发集群探测源IP段为100.64.0.0/10 a.  TCP监听  CLB向后端发起一个TCP三次握手的信报，后端响应完成，以RST方式断开连接。 请求方式：TCP三次握手或HTTP GET；判定成功逻辑：超时时间内收到了SYN_ACK；判定失败逻辑：超时时间内未收到SYN_ACK；关闭连接方式：发送RST数据包； 问题一：为什么选择RST方式而不是传统的四次挥手断开连接？因为健康检查是用CLB额外引入的逻辑，对后端ECS具有一定的负担，为了尽可能地减少健康检查的开销，采用了RST方式，只需要单向的一个包就可以立即断开，两端的内核都不再去维护TCP五元组连接的管理。 问题二：使用RST可能带来哪些问题？RST在TCP/IP定义里属于非正常状态，在某些程序比如java程序会频繁提示“connection reset by peer”，只要确定探测源是100.64.0.0/10，就可以认为这是健康检查探测的逻辑，可以忽略该异常信息。 b.  UDP监听  UDP是面向无连接的协议，一般用于如DNS、syslog协议场景，UDP监听的规则是发出报文，在规定时间内，收到回应表示失败，未收到报文表示成功（也可以设置为返回特定字符串来判定成功）。 请求方式：UDP报文；判定成功逻辑：超时时间内没有收到ICMP端口不可达；判定失败逻辑：超时时间内收到了ICMP端口不可达； c.  HTTP(s)监听  请求方式：HTTP GET方法或HEAD方法，可能包含Host头，默认使用HEAD方法（尽可能地降低健康检查给后端ECS带来的影响，HEAD方式只返回响应头部字节数，开销也比较小）；判定成功逻辑：超时时间内收到了配置的正常状态码（如200）；判定失败逻辑：除上述以外的情况（如收到了502状态码、收到了RST、建连失败等）； d.  滞后性和探测频率  滞后性：如果机器出现故障时，CLB需要一定的时间才能感应到；探测频率：探测频率会由于机器数量而倍增，需要在灵敏性和业务可容忍的范围内，适当设定该频率； ４.  服务器组  a.  默认服务器组（某监听上没有配置任何的转发策略，也没关联任何的虚拟服务器组，流量就会转发到此组，一个CLB实例只有一个默认服务器组）兜底服务器组 b.  虚拟服务器组（最灵活，操作成本最低）转发策略监听维度 c.  主备服务器组（比较灵活，是备用服务机器转发到主服务机器上，不适合常见业务，只适合特定的主备业务）一主一备始终对主进行健康检查 ５.  转发策略 CLB转发策略流程图 提高单个实例的使用率；统一管理入口；灵活调度流量；  

6月7日早晨(UTC时间Mon, 06 June 2022 20:09)，HTTP/3 标准RFC9114 由IETF标准化工作组正式发布，由此QUIC第一代协议族6大基础标准（不变量/传输框架/拥塞控制和恢复/TLS/HTTP3/QPACK压缩）全部完成RFC化，开启一段新的网络时代。在淘宝，我们从18年开始尝试QUIC，到21~22年实现IETF QUIC及HTTP3标准的规模化应用，针对导购和交易核心链路场景拿到15~20%的网络耗时优化收益，同时沉淀自研的标准协议库实现XQUIC，并于年初开源。笔者想借由本文谈一谈对于网络7层模型中传输层的发展方向看法，以及对于底层技术发展过程中可能碰到的困难及问题提出一点可行的建议。开源仓库：https://github.com/alibaba/xquic什么场景下适合选择QUIC作为TCP的替代品今年我们听到大量的国内外声音，支持QUIC作为TCP的全面替代品，同时也针对QUIC成为网络传输技术新一代的颠覆者，提出支持性的观点。笔者作为XQUIC(一个包含QUIC和HTTP/3标准实现的协议库)项目的发起人和持续建设者，虽然立场相关，但是仍然从客观角度做一下分析。最近一到两年也有很多研发者找到XQUIC项目，希望这个项目能一举解决大家碰到的所有网络问题；笔者的观点是，这个世界上没有银弹，没有任何技术可以解决所有场景的问题，每一项技术都有它适合的场景和它的局限性。那么到底什么场景下适合使用QUIC呢？答案是公网传输链路下，作为TCP的替代品，确实具备理想的优势。我们知道公网的特性是链路长（反应在Round-Trip-Time上）、链路复杂性高（反应在各个节点可能存在的丢包/排队及多流的竞争上）、以及手机端常见的无线信号波动带来的吞吐量抖动（体现在丢包/乱序上），这些问题的解法都是QUIC的强项领域。而在数据中心内部，在链路网络设备可控的情况下，同时追求低性能开销与低成本，TCP/DCTCP仍然表现不错，基于RDMA的一些DC内部解决方案同样也会具备优势。从原理本质上来说，QUIC带来的最大的原理变化是：将传输层从内核态提到用户态，使得传输层可以与应用层进行高度配合，这在过去是无法可想的。这打开了传输层对于应用层传输需求和传输内容理解的天花板，使得传输行为与应用层需求高度匹配具备可行性。有人可能会说这有什么牛逼之处么？我们知道WebRTC在音视频场景下表现出色，其中一部分关键原因就是其RTP的协议传输设计和工程实践，是充分结合音视频内容的传输需求和特性来设计的。因此具备用户态灵活演进的能力，并且能够贴合应用场景进行传输特性的设计，是非常重要的发展和探索方向。此外它基于UDP的多路复用、以及对Steam/Datagram分别支撑 可靠传输 与 非可靠/半可靠场景的传输能力设计，包括0-RTT降低握手延迟这些基础的协议特性带来的优势，就不再多说。谈谈自研、标准与开源对于任何一项好用的技术来说，能够先应用起来并且服务好业务需求，永远是第一步。对于任何具备深度和一定壁垒的技术（碰巧网络也属于），一般我们都会经历4个发展阶段：第一阶段，用好这项技术，首先能用好并切实在业务场景下拿到收益。在当前这个鼓励开源的时代，第一步通过这个领域下已有的开源方案，来验证技术的可行性，并拿到一些初步收益来验证判断和观点，是最快的方式。第二阶段，原理理解透彻，能够充分理解透彻这项技术的底层原理和机制，并针对业务需求做出调整。在这个阶段往往大家会有两条分叉路径：在已有开源项目上继续修改并发展自己的分支；或者 筹备自研。在这个阶段是选择前者还是后者，核心依据有2个：一方面是 是对这项技术长期发展所能带来的红利，是否可以cover前期的投入；另一方面是，是否具备自研能力。第三阶段，具备自研能力，如果从2到3的判断能够满足自研的前提，就会走上自研道路。因此我们可以看到绝大部分一线互联网大厂，都会对战略性的技术投入方向进行自研，同样自研也能够带来技术壁垒的积累。这一步也是第四阶段的前置门槛。第四阶段，引领前沿发展，这个阶段往往又存在两种类型（或两者兼有）：通过开源逐步成为事实标准，或者是参与到行业标准的制定当中。笔者个人的观点是，每个阶段都需要投入不同的精力，对应着领域的持续深挖和人才的长期培养与团队建设。选择走到哪个阶段，没有绝对的好与坏，而是应该根据实际的诉求、可持续投入情况 和 发展的观点来判断。另一方面，作为一个技术人，我们也应当充分尊重技术本身的深度，尊重愿意为了走到第三/四阶段，而投入精力、克服重重困难的技术产品和团队，而非通过一些短期包装和走捷径的方式，避免最终在技术上逐渐空心化，影响技术大环境的发展。如何维护技术环境的一片净土，使得健康的种子能够具备萌芽的条件，这也是技术管理者需要考虑和反思的。如何应用QUIC/HTTP3来提升传输性能表现这次IETF发布的RFC 9114和9204分别描述的是HTTP/3.0和配套的Header压缩算法QPACK的协议机制。HTTP/3.0相对于HTTP/2到底有什么本质提升？这需要从HTTP/3底层的QUIC传输机制讲起。我们都知道，QUIC基于UDP之上的多流（Stream）传输，实现解决原来TCP大管道下的Head-of-Line问题[3]，同时0-RTT等握手机制可以保证连接会话的快速建立和首包的加速。QUIC提供了两种传输模式，基于Steam的可靠传输，和基于Datagram的非可靠传输。基于Stream的模式下，发送方和接收方基于Steam的Offset进行流数据的重排和有序还原，并确保投递给应用层的是有序可靠数据。基于Datagram的模式则适用于实时流媒体类型的场景，针对延迟有强诉求的同时不要求数据完全可靠有序的这类场景，Datagram提供了一种数据封装和ACK通知的方式，帮助半可靠诉求的场景实现数据的快速投递，并向应用层反馈送达情况。[3] TCP Head-of-line头部阻塞问题：原因是TCP是一条大的传输管道，基于TCP传输的数据，由于TCP的传输机制，需要等待前面的数据包完成送达，后续的数据包才能被完成送达和向应用层投递。这在多路复用的场景下，会导致不同的流数据之间互相block，这在HTTP/2是一个没有被完全解决的问题。QUIC在丢包检测和重传机制方面也有较大革新。在丢包检测方面，QUIC提供了两大类丢包检测方式，基于packet number的阈值检测，和基于定时器的超时丢包检测。这两类机制相对于传统的TCP检测方式可以带来更快的丢包感知和恢复。在重传恢复方面，QUIC针对每一个packet分配独立的packet number，避免了过去TCP因重传包和原始包复用相同的sequence，导致的RTT测量不准确的问题。准确测量的RTT，作为拥塞控制算法的一维重要输入，能够使得算法对瓶颈段拥塞状况的检测更加准确。这次发布的HTTP3 RFC，则是在QUIC基础之上，描述了HTTP请求如何通过跟QUIC steam的映射，实现完整的HTTP语义，以及针对基于UDP的多流机制设计的专用头部压缩。因此所有QUIC在UDP之上实现的传输机制革新，HTTP3都可以享受到红利。那么如何把这项革新的技术用起来呢？XQUIC针对QUIC和HTTP/3协议栈提供了完整的能力实现，并且完全符合IETF标准，并通过了IETF工作组的互通性验证[4]。在手机淘宝我们提供了整套的网络解决方案，包含客户端的SDK和服务端网关的能力支持，各类业务场景核心关注开关和放量情况即可。对于外部开发者，可以移步到XQUIC在github的开源仓库[5]，开源仓库有相对完整的文档说明和RFC译文，同时后续开源版本我们也将逐步更新IETF工作组版本的Multipath[8]多路传输能力，以及Tengine相关的适配版本和模块，方便外部开发者能够更方便地使用。如何解决服务端UDP性能问题相信已经在尝试应用QUIC/HTTP3的服务端开发者，或多或少都会经历UDP在内核方面的性能瓶颈问题，考虑到UDP是在近几年才随着QUIC和流媒体传输的场景的逐渐流行，才被逐渐广泛地应用起来，因此内核UDP在性能方面很难与优化了三十年的TCP相抗衡，同时内核的复杂性和通用性要求，也导致一些新的高性能修改难以被迅速接收。因此，在UDP性能优化方面，我们和龙蜥社区的Anolis内核团队联合做了一版bypass内核的用户态高性能udp收发方案。首先我们需要了解到，ebpf[6]有一类专门用于网卡驱动处理的filter叫XDP[7]，可以实现对于网卡接收和发送的packet进行劫持处理；Anolis内核团队基于XDP实现了一套UDP packet卸载和封装逻辑并封装为XUDP[8]库，而我们则基于XUDP进行UDP packet的收取和发送，实现完全bypass内核的高性能UDP收发。这一套方案相较于Linux内核默认的UDP收发 + 四元组hash查找优化的方案，可以在真实场景下，再提升26.3%以上的服务器协议栈处理性能。Tengine + XUDP + XQUIC的打包处理方案，我们后续也会在Tengine社区提供开源版本以供外部开发者参考。写在最后希望大家都能在自己的领域，享受技术前进的快乐。参考文献[1] HTTP3: https://datatracker.ietf.org/doc/rfc9114/[2] QPACK: https://datatracker.ietf.org/doc/rfc9204/[4] 互通性验证：https://interop.seemann.io/[5] XQUIC开源仓库：https://github.com/alibaba/xquic[6] XDP: https://dl.acm.org/doi/pdf/10.1145/3281411.3281443[7] XUDP: https://codeup.openanolis.cn/codeup/hpn/ExpressUDP[8] Multipath Extension for QUIC: https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/团队介绍XQUIC团队隶属于大淘宝平台技术-终端体验平台团队，希望能通过网络技术演进给用户带来更丝滑的体验。如果对XQUIC、网络技术、高性能网络传输等领域比较感兴趣，欢迎点击“阅读原文”关注我们的 GitHub 仓库：https://github.com/alibaba/xquic

文章目录：1.Nginx发展介绍1.1 正向代理和反向代理1.2 正向代理和反向代理举例2.Nginx环境搭建2.1 安装前的准备2.2 上传下载好的压缩包2.3 启动Nginx（三种方式）2.4 关闭与重启Nginx2.5 查看Nginx的版本号1.Nginx发展介绍Nginx （engine x） 是一个高性能的Web服务器和反向代理服务器，也可以作为邮件代理服务器。Nginx 特点是占有内存少，并发处理能力强，以高性能、低系统资源消耗而闻名，Nginx官方测试为5万并发请求。与Nginx同类型的Web服务器还有Apache、Lighttpd（音同lighty）、Tengine（阿里巴巴的）等。Nginx 的并发处理能力在同类型的Web服务器中表现极好（Apache、Lighttpd），在全世界范围内大量的网站使用了Nginx，国内互联网中也大量使用了Nginx，比如：淘宝、新浪、搜狐、网易、美团等。Nginx是免费开源的，同时Nginx也有收费的商业版本，商业版本提供了性能优化、宕机等紧急问题处理等技术支持和服务。1.1 正向代理和反向代理反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器；正向代理类似一个跳板机，代理访问外部资源。比如：我是一个用户，我访问不了某网站，但是我能访问一个代理服务器，这个代理服务器，它能访问那个我不能访问的网站，于是我先连上代理服务器，告诉它我需要那个无法访问网站的内容，代理服务器去取回来,然后返回给我。1.2 正向代理和反向代理举例正向代理：比如你现在缺钱，想找马云爸爸去借钱，可想而知人家可能鸟都不鸟你，到最后碰一鼻子灰借不到钱。不过你认识你家隔壁老王，而老王认识马云同志，而且关系还很好。这时候你托老王去找马云借钱，当然这事最后成了，你从马云那里借到了500万！这时候马云并不知道钱是你借的，只知道这钱是老王借的。最后由老王把钱转交给你。在这里，老王就充当了一个重要的角色：代理。此时的代理，就是我们常说的正向代理。代理客户端去请求服务器，隐藏了真实客户端，服务器并不知道真实的客户端是谁。正向代理应用最广泛的莫过于现在的某些“科学上网工具”，你访问不了谷歌、Facebook的时候，你可以在国外搭建一台代理服务器，代理你访问，代理服务器再把请求到的数据转交给你，你就可以看到内容了。反向代理：比如你现在很无聊，想找人聊天，这时候你拨通了联通客服10010电话，联通的总机可能随机给你分配一个闲置的客服给你接通。这时候你如愿以偿的和客服聊了起来，问了问她目前有没有结婚、有没有对象、家住哪里、她的微信号、她的手机号。。。此时联通总机充当的角色就是反向代理，你只知道和客服接通并聊了起来，具体为什么会接通这个客服MM，怎么接通的，你并不知道。反向代理隐藏了真正的服务端，就像你每天使用百度的时候，只知道敲打www.baidu.com就可以打开百度搜索页面，但背后成千上万台百度服务器具体是哪一台为我们服务的，我们并不知道。我们只知道这个代理服务器，它会把我们的请求转发到真实为我们服务的那台服务器那里去。综上所述：正向代理代理对象是客户端，反向代理代理对象是服务端。在我们正常访问服务器时，我们客户端可以直接访问，如下图但是，当我们有大量的请求访问服务器时，我们的服务器会承受不了，我们可以通过提升服务器的配置，但是不能从根本上解决问题，于是我们就增加服务器的数量，如果请求很多，一台服务器处理不了，我们来可以多来两台，而这三台服务器怎么处理请求大量的请求呢，这就是负载均衡了，通过反向代理实现。（这里的反向代理服务器就是Nginx，它并不处理客户端发来的请求，而只是做一个请求转发）2.Nginx环境搭建免费开源版的官方网站：http://nginx.orgNginx 有 Windows 版本和Linux 版本，但更推荐在 Linux 下使用 Nginx；2.1 安装前的准备Nginx的安装需要确定Linux安装相关的几个库，否则配置和编译会出现错误，具体的检查安装过程为：gcc编译器是否安装         检查是否安装：yum list installed | grep gcc         执行安装：yum install gcc -yopenssl库是否安装         检查是否安装：yum list installed | grep openssl         执行安装：yum install openssl openssl-devel -ypcre库是否安装         检查是否安装：yum list installed | grep pcre         执行安装：yum install pcre pcre-devel -yzlib库是否安装         检查是否安装：yum list installed | grep zlib         执行安装：yum install zlib zlib-devel -y一次性安装，执行如下命令yum install gcc openssl openssl-devel pcre pcre-devel zlib zlib-devel -y（执行此命令即可）2.2 上传下载好的压缩包这里你可以使用 rz -y 命令来上传压缩包。也可以使用Xftp来上传，都可以，我这里就不再演示了。·       上传完成之后，使用 tar -zxvf nginx-1.20.1.tar.gz 命令进行解压即可。·       解压完毕之后，cd nginx-1.20.1 进入nginx的主目录下，执行命令：./configure --prefix=/usr/local/nginx （其中--prefix是指定nginx安装路径） 注意:等号左右不要有空格·       之后，执行命令进行编译：make·       之后，执行命令进行安装：make install·       安装成功后，可以切换到/usr/local/nginx目录下，查看内容2.3 启动Nginx（三种方式）切换到nginx安装目录的sbin目录下，执行：./nginx通过配置文件启动：./nginx -c /usr/local/nginx/conf/nginx.conf/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf其中-c是指定配置文件,而且配置文件路径必须指定绝对路径启动成功之后，可以使用 ps -ef | grep nginx 查看进程。nginx 体系结构由 master 进程和其worker 进程组成         master 进程读取配置文件，并维护 worker 进程，而 worker 进程则对请求进行实际处理         Nginx启动后，安装目录下会出现一些_tmp结尾的文件，这些是临时文件，不用管。在浏览器中输入 http:// + 你自己虚拟机的ip地址 即可访问Nginx服务器，出现以下界面：在访问Nginx服务器的时候，一定要记得关闭虚拟机的防火墙，要不然是访问不到的。关闭防火墙的命令如下：2.4 关闭与重启Nginx重启Nginx的命令：./nginx -s reload。如果是配置文件启动，则应该为：/usr/local/nginx/sbin/nginx -s reload2.5 查看Nginx的版本号Linux上查看nginx版本：/usr/local/nginx/sbin/nginx -V-v （小写的v）显示nginx 的版本-V （大写的V）显示nginx 的版本、编译器版本和配置参数 

请问，Tengine 支持国密证书，需要怎么部署有相关文档吗？