nginx - 学习脑图

高性能的静态web服务器
反向代理（负载均衡）

nginx 为什么适应高并发：
一个进程处理多个请求
非阻塞式的

OpenResty是一个通过Lua扩展Nginx实现的可伸缩的Web平台，内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项。
用于方便地搭建能够处理超高并发、扩展性极高的动态Web应用、Web服务和动态网关。
功能和nginx类似，就是由于支持lua动态脚本，所以更加灵活，可以实现鉴权、限流、分流、日志记录、灰度发布等功能。
OpenResty通过Lua脚本扩展nginx功能，可提供负载均衡、请求路由、安全认证、服务鉴权、流量控制与日志监控等服

对请求结果缓存

优势特点：
高并发，高性能
扩展性好
异步非租塞的事件驱动模型
高可靠性
热部署，平滑升级

进行nginx 二次开发，尽可能减少修改 masterprocess，而是修改第三方模块，行业规定也是不开发masterProcess

materProcess 不真正处理用户请求，而是进行管理 和监控，如下第三方模块
子模块down掉了，masterprocess，会重启一个子模块， linux 里面子进程会发送信号
配置文件修改，加了路由，热重启后，materProcess 检测到修改后，会自动通知work Process，靠这种结构，才可以进行平滑升级

真正缓存哪些内容，由workProcess进行处理，cacahLoader 负责加载缓存，cacah Manager 负责管理缓存
所有子进程 通信，使用共享内存。

linux 信号量管理机制：
对于进程管理是使用信号量管理的


父子进程信号量， 子进程down ，迫使向 父进程发送信号量
了解不深
进程优雅退出
进程直接退出
关机的时候，向应用程序，先发15 ，到等待时间不完成，发送9
signup 迫使进程重新读取配置文件
用户自定义信号量

使用信号量管理master 和worker

不推荐 直接向worker进程 发送信号量， 而是有mater进程发送信号量，对worker进程进行管理

term int 直接关闭
quit 平滑关闭
hup 接受hup信号，重读配置文件，之后可能改变nginx某些行为，重新kill调worker进程，打开新的worker进程
usr1
usr2
winch

为什么要切割日志？一般Nginx安装好后有些人会打开日志记录，有些人会关闭日志记录，打开日志记录的人一般都会把架设在Nginx上的所有网站日志都存在同一个文件里（比如我存在access.log日志文件里），这样日积月累所有网站的访问记录就会把日志文件越积越大，当需要查看日志文件的时候一看就是一大串，不方便查找。现在，如果我把每天的日志文件分割开来用相应的日期标识出来这样就大大方便查找了。

我是建议打开日志记录，日志记录里面存放着很多有用的东西。比如：浏览器名称，可以方便你对网站的排版做出调整；IP地址，如果网站收到攻击，你就可以查到那个IP地址。

Linux下我们可以简单的把日志文件mv走，但是你会发现mv走后新的日志文件没有重新生成，一般linux下用的文件句柄，文件被打开情况下你mv走文件，但是原来操作这个文件的进程还是有这个文件的inode等信息，原进程还是读写原来的文件，因此简单的mv是无法生效的。

因此建议过程如下

1. mv原文件到新文件目录中，这个时候 nginx还写这个文件（写入新位置文件中了）

2. 调用nginx -s reopen用来打开日志文件，这样nginx会把新日志信息写入这个新的文件中

这样完成了日志的切割工作， 同时切割过程中没有日志的丢失。

相当于给 mater进程发送 命令，

nginx 采用事件驱动模型，事件处理机制，对于这个模型，会要求，worker进程尽量和CPU的个数绑定在一块，从而尽可能减少CPU的切换，提高CPU 缓存切换 命中效率，这个是nginx的初衷，所以，cpu有多少课，就启动多少worker进程。

这个是nginx 主二进制配置文件

master 进程接受信号量

对worker进程进行演示

二进制文件 操作nginx 其实也是对信号量进行操作

配置文件重载的原理真相

nginx 的热升级（nginx 升级新版本）


winch信号 导致 旧的worker 子进程退出，master 不退出

热升级，首先要保证目录结构一致，
还可以使用命令行，查看参数和 版本

nginx 的模块化管理机制

核心模块 ，是运行必备模块
ssl 对https
gzip 对相应报文时候，进行压缩

nginx 配置安装的配置参数

–prefix 配置主目录

在安装过程中，由于新增 模块，缺少什么依赖包，使用相应的依赖包

nginx 配置文件使用



代表一个work 子进程 里面可以最多可以处理并发请求数量，需要根据测试环境后，调整

虚拟主机的分类： 其实就是利用单台主机，构建多个不同类型的网站

在单台服务器上，安装多块网卡，每块网卡上配置公网IP地址

网卡只有一块， 但是不同端口提供不同服务

监听各个网卡上IP的8080端口，（该机器上有三块网卡）

一台物理主机上，使用不同域名，区别不同服务，两个域名绑定一个公网IP

配置文件main断核心参数用法



存放master 主进程的存放文件

rlimit 命令，可以看当前用户 可以打开的文件句柄数，linux的哲学就是一切是文件，对于每一个进程，能打开的文件个数也是有限制的，这是linux的一个特性，如果前面user 指定的为nginx ，就默认使用nginx 的默认打开进程数
每一个连接，都发送一个TCP 连接，发送数据报文，每个连接，至少有一个套接字，一个套接字可以理解为一个文件句柄，要承载更大的并发量，就要将这个调高。
20480* 4 但是 linux 最大能打开的句柄数是65535 ，

这个目录，对于nginx用户，必须要有写权限啊，没有写权限，依然是写不了

不管什么进程， 都不会再CPU上永远运行，每个进程根据自己的优先级，向CPU申请时间片，CPU说可以运行了
work被调度，使用CPU资源，到时间片完了，必须下来or睡眠。

进程切换or上下文切换，降低切换，充分利用CPU的缓存，

绑定是不能够永远使用，时间片到了，依旧要撤下来，好处在于，充分利用CPU缓存，永远只能向CPU1 申请时间片
不用CPU之间的缓存是失效的，绑定是为了什么，减少CPU缓存失效。



指定worker子进程的nice 值， 用来调整nginx的优先级，默认linux默认进程优先级为120，值越小越优先。

优雅退出超时时间， work不会主动关闭，而是处理完，等待客户端关闭连接，但是客户端异常了，或者就是不返回确认，故意发送数据报文，但就是不确认，不让你关闭，如果永远不关闭，就不释放，严重影响nginx性能。

work子进程 自身运行在用户态，在运行过程中，会向内核态发送多次调用，就比如计时器，要获得内核态的时间，发起内核调用，向内核态切换，都会降低性能。

开发打开调试模式的时候，使用off ，nginx 使用在前台。

event 端核心参数用法

use 和Linux 底层 使用 的 事件驱动模型有关

不推荐对这个参数 进行指定， 让linux 自行选择

linux 有一个最大的能打开套接字的个数 65535 ，这个是操作系统本身决定的，10万，20万，没有实际意义。

是吧每个请求都发送给work子进程呢，还是 只发送给一个呢，默认是off ，当请求来的时候，会发送一个事件，唤醒所有的work子进程，假如每个 work 子进程，都有很多请求正在处理，master 发给一个事件请求，work子进程进行处理，就会耗费性能。打开on，只会找其中一个会询问你们那个能处理新的用户连接，不用每一个去相应，其他的该休眠休眠，谁争抢到，谁来处理。

必须设置成 on 这个参数才有用， 只找一个询问，当这个work子进程 处理不过来后，这个超时时间就有意义，没有给我回应，就会给其他分发，不会导致，一个work特别繁忙，新请求得不到处理

负载均衡锁，把相关信息写到这个锁文件中

默认每个work子进程 只会处理一个链接， 打开后，认为 可以一次性处理多个http请求，这个对性能影响很小，因为epoll 事件驱动模型 已经非常先进了，在同一时间进行一个请求处理，已经非常高效了。

server name 结构用法


需要有优先级

location 用法：



深入理解location中URL结尾的反斜线：

不带 先当目录，在当文件，如果任何一个能找到就返回
带， 只会当做目录处理

stub_status 模块的用法：


uri 要比较私密 ，



如果要是用这个模块，要在编译的时候，使用这个命令，加入这个模块



再谈 connection 和request


开启长连接，一个connection 可以发送request

liming_conn 模块：

具体指令：

在http 上文中定义，在server，location 里面引用就可以

必须定义在Http段中

limit_rate: 给客户端传输速率 150 字节每秒。

limit_req 模块：

算法思路：

只有桶的容量超了，才会拒绝

zone=zone：设置使用哪个配置名来做限制，与上面 limit_req_zone 里的 name 对应

burst=5 ：这个配置的意思是设置一个大小为5的缓冲区，当有大量请求过来时，超过访问频次限制 rate=1r/s 的请求可以先放到这个缓冲区内等待，但是这个缓冲区只有5个位置，超过这个缓冲区的请求直接报503并返回。

nodelay：如果设置，会在瞬间提供处理（rate+burst）个请求的能力，请求超时（rat+burst）的时候直接返回503，永远不存在请求需要等待的情况。如果没有设置，则所有请求会依次等待排队；

限制特定IPor网段访问access模块：
执行集合： allow deny

限制特定用户访问的auth_basic 模块



先要在linux 上安装 httpd-tools 包 ，使用命令行，生成文件，在使用nginx命令引入文件

auth_request模块

上图中的server 应该是listen

rewrite 模块中的return 指令

rewrite 指令

return 和rewrite 指令 执行顺序

是顺序执行， 但是 注意 last 和break 对整个流程的影响

rewrite模块中的if 用法

&http_user-agent 是一个变量，在浏览器发送请求的时候，会自动带上


每个浏览器内核不同，处理方式不同，比如如上的写法，有的浏览器下载，有的浏览器展示

autoindex用法：

就比如 下载时候，列出列表


是否需要打开这个功能，如果磁盘上有目录结构就会展示
当我们在浏览器浏览文件时，是否显示文件大小。以字节问单位

找路径download 下 opt/source下的a.html文件，所以功能没有打开

b.html不存在，再回继续执行下面的代码

nginx变量分类：
有助于 定制 log 文件







如上变量， nginx 会自己处理，变为另一个值

场景应用：


真实服务器，叫做动态资源服务器

静态资源相应能力很强

反向代理支持的协议：

用于定义上游服务的upstream模块：

upstream 模块：




从第一次不可达开始计时，10s后，尝试三次，如果都不行的话，会把服务器标记为不可用，如果有一次行了，就计数器重新记录， 过了10s后，还会再去调度


注意是空闲长连接

一个长连接处理到最大http个数后就关闭了，在发起一个新的连接进行处理请求

这个模块在F5商用服务器才会使用

proxy_pass 用法常见误区

代理场景下nginx 接受用户请求包体的处理方式




先发一半，全收完了，再发

对应缓冲区的大小

single_buffer设定内存连续存储
temp_path 设定存储目录

file_only 打开，不管大于缓冲区大小，还是小于缓冲区大小，都会写到磁盘上，选择clean，在请求返回的时候，会删除掉文件，on处理完成也不会删除

timeout 参数 建立连接后，上时间不发送请求，会自动断开连接

代理从场景下nginx 如何更改发往上游的用户请求：

要想nginx 和上游应用服务器 开启长连接 ，proxy_http_version 设置为1.1 之外 ，还要proxy_set_header Connection 改为keepAlive

代理场景下nginx 与上游服务建立连接细节：（这块理解不够深刻）

建立长连接有两个阶段

代表 nginx 连接上游服务器 连接 超时时间

直接复用TCP 的长连接， 复用操作系统的长连接

nginx 向上游服务器，没有发送内容的时候 ，超时时间，60s内没有发送内容，连接会断开

用户放弃请求后，nginx 是否放弃 发送给上游应用服务器request

负载均衡：
加权轮询：
哈希算法：

让URI 为Hash ，会路由到指定的服务器

ip_hash算法：

最少连接数算法
之前的算法，都没有考虑到后端服务器的转态

让后端应用服务器都是50请求，就退化为rr算法


使用共享内存，在worker子进程，同步后端服务器状态

负载均衡场景下，nginx针对上游服务器返回异常时候的容错机制

当一台应用程序服务器 失败的时候，nginx转发到另一条上游服务器

nginx 转发上游服务器，没有得到相应，该等待多久呢，0代表无限等待

失败几次呢 ，0 代表无限次重试

proxy_read_timeout 如果不能再5s内 把response去读回来，就返回timeout，error 是上游服务器异常，产生问题

缓存基础：

缓存相关执行用法：

引用在proxt_cache_path 里面定义的共享内存，代表开启上游应用开启的共享内存

至少缓存8000个key

以上两个 命令结合使用·，共享内存多定义到http段内

CM的 消耗越大 nginx的性能越低，占用worker进程 资源。
CL 是指nginx 重启的时候， 将共享内存载入。

上游服务器，缓存状态。
使用 缓存状态 ，来代表缓存是否命中

nginx 如何不是用缓存

不会缓存，会获取新的内容

缓存失效降低上游压力机制–合并源请求

三个相同请求到nginx，只有一个请求到应用服务器，只有该请求返回到nginx后，其他两个请求，直接从本地区去资源

第一个请求分发，但是超时没返回，这时过5秒 后再发一个

缓存失效降低上游压力机制 -启用陈旧缓存

当第一个请求发送给应用服务器，但还没有回来呢，其他相同请求发现nginx 本地有陈旧缓存，则直接使用本地陈旧缓存，等第一个请求返回回来了，就更新陈旧缓存

打开的化，第一个都不会去应用服务器，而是直接返回，nginx自身会发送一个http请求，给我们应用服务器，更新资源的缓存

清楚缓存模块：


发送特定请求，指定清除的缓存 key

https介绍：

多少客户端，服务器需要维持多少秘钥
报文可以被切割后，在传输。

黑客也有公钥，服务器私钥加密的东西，黑客也可以解密

nginx 高可用基础：

IP 地址，程序，数据文件 ，三要素在另外一台服务器上，可以启动

VRRP 原理

gatway 有两个IP，内网和公网


地址解析协议，即ARP（Address Resolution Protocol），是根据IP地址获取物理地址的一个TCP/IP协议。主机发送信息时将包含目标IP地址的ARP请求广播到局域网络上的所有主机，并接收返回消息，以此确定目标的物理地址

KeepAlived 架构图：

优化专题：

提高CPU的利用率，让CPU尽可能在用户空间，处理逻辑，而不是在处理TCP/IP这方面

根据不同用户，进行DNS

LINUX CPU 调度机制：
每个程序的申请的时间片 不一定，有CPU调度算法决定，大体原则，进程优先级越高，获得时间片越高，运行时间片所赋予的时间，前提进程不会陷入阻塞状态

当我们TCP/IP 连接建立之后，如果用户没有发送HTTP请求，nginx 自身是不会被激活的。没有这个参数，建立完TCP/IP连接之后，会激活nginx worker进程一次，这个是没有意义的。

TCP三次握手和四次挥手

在网卡追层拆包
网络层和链路层，优化非常少，因为和硬件相关

TCP 对每个包都需要确认的

客户端过了两个MSL 时间，才会才送ack =y+2 ，两边都会认为数据报文无效

这个数字5 代表180s， 第一个是nginx 作为客户端， 第二个是nginx作为服务器

当三次握手已经完成后，连接会从sync队列，到accept队列，后续由应用进程来处理
ngiinx 程序是通过 backlog 参数决定nginx accept队列长度，操作系统还有一个参数决定所有进程的accept队列长度。

sync攻击

不立即分配内存空间，避免了服务器立刻被打死
tcp_syncookies 参数 为1 ，避免了sync攻击

core.somaxconn 对应系统级别的 accept队列长度
netdev_max_backlog 代表，连接肯定到达网卡，但是部分连接已经到达到syn队列，有些还没有到达，没有到达的话，会存储到网卡，未处理的backlog队列长度。



proc文件夹里面都是临时文件，是立即生效，

TCP的FastOpen功能

客户端和服务器端都要支持FastOpen功能

1代表 nginx 作为客户端有这个功能，2 作为服务端都有这个功能， 3 不管作为客户端还是服务端都有这个功能。