Nginx详细讲解-对nginx进行讲解.docx

Nginx详细讲解

前言

nginx作为当今火爆的、高性能的http及反向代理服务，不管前端还是后端，都需要全面去了解，学习，实操。一句话：搞懂nginx如何使用以及工作逻辑对于程序员来说是必不可少的！

我们看看本文的大纲先了解一下本文都讲了哪些东西，大纲如下：

nginx介绍

nginx目录一览

nginx.conf文件解读

location路由匹配规则

反向代理

负载均衡

动静分离

跨域

缓存

黑白名单

nginx限流

https配置

压缩

其他一些常用指令与说明

重试策略

nginx介绍

为了有一个全面的认知，接下来我们先来看看nginx的架构以及一些特点。

nginx特点

处理响应请求快（异步非阻塞I/O，零拷贝，mmap，缓存机制）

扩展性好（模块化设计）

内存消耗低（异步非阻塞，多阶段处理）

具有很高的可靠性（无数次的生产验证，很多头部公司都在用）

热部署

高并发连接（事件驱动模型，多进程机制）

自由的BSD许可协议（可以自己修改代码后发布，包容性极强）

nginx架构

从上边这张图，我们可以一览nginx的架构设计，首先我们可以直观得出nginx的几大特点：

事件驱动异步非阻塞：

本质来说，事件驱动是一种思想（事实上它不仅仅局限于编程），事件驱动思想是实现异步非阻塞特性的一个重要手段。对于web服务器来说，造成性能拉胯不支持高并发的常见原因就是由于使用了传统的I/O模型造成在内核没有可读/可写事件（或者说没有数据可供用户进程读写）时，用户线程一直在等待（其他事情啥也干不了就是干等等待内核上的数据可读/可写），这样的话其实是一个线程（ps:线程在Linux系统也是进程）对应一个请求，请求是无限的，而线程是有限的从而也就形成了并发瓶颈。而大佬们为了解决此类问题，运用了事件驱动思想来对传统I/O模型做个改造，即在客户端发起请求后，用户线程不再阻塞等待内核数据就绪，而是立即返回（可以去执行其他业务逻辑或者继续处理其他请求）。

当内核的I/O操作完成后，内核系统会向用户线程发送一个事件通知，用户线程才来处理这个读/写操作，之后拿到数据再做些其他业务后响应给客户端，从而完成一次客户端请求的处理。事件驱动的I/O模型中，程序不必阻塞等待I/O操作的完成，也无需为每个请求创建一个线程，从而提高了系统的并发处理能力和响应速度。

事件驱动型的I/O模型通常也被被称为I/O多路复用，即这种模型可以在一个线程中，处理多个连接（复用就是指多个连接复用一个线程，多路也即所谓的多个连接），通过这种方式避免了线程间切换的开销，同时也使得用户线程不再被阻塞，提高了系统的性能和可靠性。nginx支持事件驱动是因为他利用了操作系统提供的I/O多路复用接口，如Linux系统中，常用的I/O多路复用接口有select/poll，epoll。

这些接口可以监视多个文件描述符的状态变化，当文件描述符可读或可写时，就会向用户线程发送一个事件通知。用户线程通过事件处理机制（读取/写入数据）来处理这个事件，之后进行对应的业务逻辑完了进行响应。简单一句话概括：事件驱动机制就是指当有读/写/连接事件就绪时再去做读/写/接受连接这些事情，而不是一直在那里傻傻的等，也正应了他的名词：【事件驱动！】，基于事件驱动思想设计的多路复用I/O（如select/poll，epoll），相对于传统I/O模型，达到了异步非阻塞的效果！

既然提到了select/poll,epoll那么我们就简单说一下（注意我这里是简单描述，后续有时间会对相关知识点从源码层面做个系统的整理和图解）：

select：将已连接的Socket都放到一个文件描述符集合，然后用户态调用select函数将文件描述符集合拷贝到内核里，让内核来检查是否有网络事件产生，检查的方式很粗暴，就是通过遍历文件描述符集合的方式，当检查到有事件产生后，将此Socket标记为可读或可写，接着再把整个文件描述符集合拷贝回用户态里，然后用户态还需要再通过遍历的方法找到可读或可写的Socket，然后再对其处理。

poll：poll函数的话其实和select大差不差，唯一区别可能就是socket列表的结构有所不同，不再受FD_SETSIZE的限制。这里就不多说了。

epoll：epoll在前边两者的基础上做了很大的优化，select/poll都需要遍历整个socket列表，当检测到传入的socket可读/可写时，则copysocket列表给用户空间，用户态仍然需要遍历（因为内核copy给用户态的是整个socket列表），而epoll则是通过红黑树结构将需要监控的socket插入到进去，然后当有socket可读时会通过回调机制来将其添加到可读列表中，然后内核将可读列表copy给用户态即可(据