查看原文
其他

WEB请求处理(2):Nginx请求反向代理

前端大全 2019-11-13

(点击上方公众号,可快速关注)


作者:伯乐在线 - 陶邦仁

链接:http://blog.jobbole.com/100461/

点击 → 了解如何加入专栏作者


上一篇《WEB请求处理(1):浏览器请求发起处理》,我们讲述了浏览器端请求发起过程,通过DNS域名解析服务器IP,并建立TCP连接,发送HTTP请求。本文讲述请求到达反向代理服务器的一个处理过程,比如:在Nginx中请求的处理流程,请求都是经过了哪些模块,做了哪些处理,又是如何找到应用服务器呢?


为直观明了,先上一张图,红色部分为本章所述模块:



Nginx有五大优点:模块化、事件驱动、异步、非阻塞、多进程单线程。其中,模块化设计类似于面向对象中的接口类,它增强了nginx源码的可读性、可扩充性和可维护性。


Nginx由内核和模块组成的,其中内核完成的工作比较简单,仅仅通过查找配置文件将客户端请求映射到一个location block,然后又将这个location block中所配置的每个指令将会启动不同的模块去完成相应的工作。


所以,在讲述Nginx请求处理过程,首先要了解Nginx模块结构与功能,Nginx中有哪些模块,其功能又是如何。


1 Nginx模块


Nginx总共有5大一类模块:core、conf、event、http、mail,和48个二类模块。每个模块有属于自己的配置项,由commands字段决定;每个模块在初始化和退出销毁时均有回调函数。


多进程模式下的模块初始化主要有四个方面:脚本初始化、静态初始化、动态初始化、进程初始化。


脚本初始化是指在安装nginx时,由configure脚本生成的相关文件,比如ngx_modules.c文件包含了nginx的所有模块;


静态初始化在编译时就完成,主要通过定义全局变量实现;


动态初始化在运行时完成,主要通过master进程main函数,ngx_init_cycle函数,及各模块文件内定义的init函数实现;


进程初始化是指各worker进程执行init_process函数。当nginx退出或重读配置文件或nginx平滑升级时,worker进程会调用各模块的exit_process函数来销毁资源。


开发人员可以根据nginx模块规则注册自己的模块,添加模块后要重新编译源码,并且修改nginx.conf配置文件才能使新模块生效。


1.1 四种角色模块


Nginx模块主要有4种角色:


(1) core(核心模块):构建nginx基础服务、管理其他模块;


(2) handlers(处理模块):用于处理HTTP请求,然后产生输出。


(3) filters(过滤模块):过滤handler产生的输出。


(4) load-balancers(负载均衡模块):当有多于一台的后端备选服务器时,选择一台转发HTTP请求。


Nginx的核心模块主要负责建立nginx服务模型、管理网络层和应用层协议、以及启动针对特定应用的一系列候选模块。其他模块负责分配给web服务器的实际工作:


(1) 当Nginx发送文件或者转发请求到其他服务器,由handlers(处理模块)或load-balancers(负载均衡模块)提供服务;


(2) 当需要Nginx把输出压缩或者在服务端加一些东西,由filters(过滤模块)提供服务。


1.2 模块结构设计




1.3 模块数据结构


1.核心:ngx_module_t(nginx所有模块的数据结构模板)




2.配置文件指令:ngx_command_t(主要负责模块与配置文件nginx.conf的交互)



3.指令配置:ngx_conf_t(解析某个具体的指令)


typedef char *(*ngx_conf_handler_pt)(ngx_conf_t *cf, ngx_command_t *dummy, void *conf);

typedef struct ngx_conf_s        ngx_conf_t;

struct ngx_conf_s {

  char                 *name;         // 指令名

  ngx_array_t          *args;         // 指令后的参数

 

  ngx_cycle_t          *cycle;        // 全局数据结构

  ngx_pool_t           *pool;         // 内存池

  ngx_pool_t           *temp_pool;    // 临时内存池

  ngx_conf_file_t      *conf_file;    // 指令所在配置文件

  ngx_log_t            *log;          // 日志记录

 

  void                 *ctx;          // 模块上下文

  ngx_uint_t            module_type;  // 模块类型

  ngx_uint_t            cmd_type;     // 指令类型

 

  ngx_conf_handler_pt   handler;      // set函数指针

  char                 *handler_conf; // set函数返回值

};


4.全局配置:ngx_cycle_t(nginx绝大部分初始化操作都围绕该结构体)


typedef struct ngx_cycle_s       ngx_cycle_t;

struct ngx_cycle_s {

  void                  ****conf_ctx;                       // 配置上下文数组(含所有模块)

  ngx_pool_t               *pool;                           // 内存池

 

  ngx_log_t                *log;                            // 日志

  ngx_log_t                 new_log;

 

  ngx_connection_t        **files;                         // 连接文件

  ngx_connection_t         *free_connections;              // 空闲连接

  ngx_uint_t                free_connection_n;             // 空闲连接个数

 

  ngx_queue_t               reusable_connections_queue;    // 再利用连接队列

 

  ngx_array_t               listening;                     // 监听套接字数组

  ngx_array_t               pathes;                        // 路径数组

  ngx_list_t                open_files;                    // 打开文件链表

  ngx_list_t                shared_memory;                 // 共享内存链表

 

  ngx_uint_t                connection_n;                  // 连接个数

  ngx_uint_t                files_n;                       // 打开文件个数

 

  ngx_connection_t         *connections;                   // 连接

  ngx_event_t              *read_events;                   // 读事件

  ngx_event_t              *write_events;                  // 写事件

 

  ngx_cycle_t              *old_cycle;                     // old cycle指针

 

  ngx_str_t                 conf_file;                     // 配置文件

  ngx_str_t                 conf_param;                    // 配置参数

  ngx_str_t                 conf_prefix;                   // 配置文件目录

  ngx_str_t                 prefix;                        // 程序工作目录

  ngx_str_t                 lock_file;                     // 锁文件,用在不支持accept_mutex的系统中

  ngx_str_t                 hostname;                      // 主机名

};


1.4 模块调用流程


1.当服务器启动,每个handlers(处理模块)都有机会映射到配置文件中定义的特定位置(location);如果有多个handlers(处理模块)映射到特定位置时,只有一个会“赢”(说明配置文件有冲突项,应该避免发生)。处理模块以三种形式返回:


OK


ERROR


或者放弃处理这个请求而让默认处理模块来处理(主要是用来处理一些静态文件,事实上如果是位置正确而真实的静态文件,默认的处理模块会抢先处理)。


2.如果handlers(处理模块)把请求反向代理到后端的服务器,就变成另外一类的模块:load-balancers(负载均衡模块)。负载均衡模块的配置中有一组后端服务器,当一个HTTP请求过来时,它决定哪台服务器应当获得这个请求。Nginx的负载均衡模块采用两种方法:


轮转法,它处理请求就像纸牌游戏一样从头到尾分发;


IP哈希法,在众多请求的情况下,它确保来自同一个IP的请求会分发到相同的后端服务器。


3.如果handlers(处理模块)没有产生错误,filters(过滤模块)将被调用。多个filters(过滤模块)能映射到每个位置,所以(比如)每个请求都可以被压缩成块。它们的执行顺序在编译时决定。filters(过滤模块)是经典的“接力链表(CHAIN OF RESPONSIBILITY)”模型:一个filters(过滤模块)被调用,完成其工作,然后调用下一个filters(过滤模块),直到最后一个filters(过滤模块)。过滤模块链的特别之处在于:


每个filters(过滤模块)不会等上一个filters(过滤模块)全部完成;


它能把前一个过滤模块的输出作为其处理内容;有点像Unix中的流水线。


过滤模块能以buffer(缓冲区)为单位进行操作,这些buffer一般都是一页(4K)大小,当然你也可以在nginx.conf文件中进行配置。这意味着,比如,模块可以压缩来自后端服务器的响应,然后像流一样的到达客户端,直到整个响应发送完成。


总之,过滤模块链以流水线的方式高效率地向客户端发送响应信息。


4.所以总结下上面的内容,一个典型的HTTP处理周期是这样的:


客户端发送HTTP请求 –>


Nginx基于配置文件中的位置选择一个合适的处理模块 ->


(如果有)负载均衡模块选择一台后端服务器 –>


处理模块进行处理并把输出缓冲放到第一个过滤模块上 –>


第一个过滤模块处理后输出给第二个过滤模块 –>


然后第二个过滤模块又到第三个 –>


依此类推 –> 最后把响应发给客户端。


下图展示了nginx模块处理流程:



2 Nginx请求处理


Nginx在启动时会以daemon形式在后台运行,采用多进程+异步非阻塞IO事件模型来处理各种连接请求。多进程模型包括一个master进程,多个worker进程,一般worker进程个数是根据服务器CPU核数来决定的。master进程负责管理Nginx本身和其他worker进程。如下图:



从上图中可以很明显地看到,4个worker进程的父进程都是master进程,表明worker进程都是从父进程fork出来的,并且父进程的ppid为1,表示其为daemon进程。


需要说明的是,在nginx多进程中,每个worker都是平等的,因此每个进程处理外部请求的机会权重都是一致的。


所有实际上的业务处理逻辑都在worker进程。worker进程中有一个ngx_worker_process_cycle()函数,执行无限循环,不断处理收到的来自客户端的请求,并进行处理,直到整个Nginx服务被停止。


worker 进程中,ngx_worker_process_cycle()函数就是这个无限循环的处理函数。在这个函数中,一个请求的简单处理流程如下:


  1. 操作系统提供的机制(例如 epoll, kqueue 等)产生相关的事件。

  2. 接收和处理这些事件,如是接收到数据,则产生更高层的 request 对象。

  3. 处理 request 的 header 和 body。

  4. 产生响应,并发送回客户端。

  5. 完成 request 的处理。

  6. 重新初始化定时器及其他事件。


2.1 多进程处理模型


下面来介绍一个请求进来,多进程模型的处理方式:


首先,master进程一开始就会根据我们的配置,来建立需要listen的网络socket fd,然后fork出多个worker进程。


其次,根据进程的特性,新建立的worker进程,也会和master进程一样,具有相同的设置。因此,其也会去监听相同ip端口的套接字socket fd。


然后,这个时候有多个worker进程都在监听同样设置的socket fd,意味着当有一个请求进来的时候,所有的worker都会感知到。这样就会产生所谓的“惊群现象”。为了保证只会有一个进程成功注册到listenfd的读事件,nginx中实现了一个“accept_mutex”类似互斥锁,只有获取到这个锁的进程,才可以去注册读事件。其他进程全部accept 失败。


最后,监听成功的worker进程,读取请求,解析处理,响应数据返回给客户端,断开连接,结束。因此,一个request请求,只需要worker进程就可以完成。


进程模型的处理方式带来的一些好处就是:进程之间是独立的,也就是一个worker进程出现异常退出,其他worker进程是不会受到影响的;此外,独立进程也会避免一些不需要的锁操作,这样子会提高处理效率,并且开发调试也更容易。


如前文所述,多进程模型+异步非阻塞模型才是胜出的方案。单纯的多进程模型会导致连接并发数量的降低,而采用异步非阻塞IO模型很好的解决了这个问题;并且还因此避免的多线程的上下文切换导致的性能损失。


worker进程会竞争监听客户端的连接请求:这种方式可能会带来一个问题,就是可能所有的请求都被一个worker进程给竞争获取了,导致其他进程都比较空闲,而某一个进程会处于忙碌的状态,这种状态可能还会导致无法及时响应连接而丢弃discard掉本有能力处理的请求。这种不公平的现象,是需要避免的,尤其是在高可靠web服务器环境下。


针对这种现象,Nginx采用了一个是否打开accept_mutex选项的值,ngx_accept_disabled标识控制一个worker进程是否需要去竞争获取accept_mutex选项,进而获取accept事件。


ngx_accept_disabled值,nginx单进程的所有连接总数的八分之一,减去剩下的空闲连接数量,得到的这个ngx_accept_disabled。


当ngx_accept_disabled大于0时,不会去尝试获取accept_mutex锁,并且将ngx_accept_disabled减1,于是,每次执行到此处时,都会去减1,直到小于0。不去获取accept_mutex锁,就是等于让出获取连接的机会,很显然可以看出,当空闲连接越少时,ngx_accept_disable越大,于是让出的机会就越多,这样其它进程获取锁的机会也就越大。不去accept,自己的连接就控制下来了,其它进程的连接池就会得到利用,这样,nginx就控制了多进程间连接的平衡了。


2.2 一个简单的HTTP请求


从 Nginx 的内部来看,一个 HTTP Request 的处理过程涉及到以下几个阶段:


初始化 HTTP Request(读取来自客户端的数据,生成 HTTP Request 对象,该对象含有该请求所有的信息)。


处理请求头。


处理请求体。


如果有的话,调用与此请求(URL 或者 Location)关联的 handler。


依次调用各 phase handler 进行处理。


以上步骤,如下图所示:



在这里,我们需要了解一下 phase handler 这个概念。phase 字面的意思,就是阶段。所以 phase handlers 也就好理解了,就是包含若干个处理阶段的一些 handler。


在每一个阶段,包含有若干个 handler,再处理到某个阶段的时候,依次调用该阶段的 handler 对 HTTP Request 进行处理。


通常情况下,一个 phase handler 对这个 request 进行处理,并产生一些输出。通常 phase handler 是与定义在配置文件中的某个 location 相关联的。


一个 phase handler 通常执行以下几项任务:


获取 location 配置。


产生适当的响应。


发送 response header。


发送 response body。


当 Nginx 读取到一个 HTTP Request 的 header 的时候,Nginx 首先查找与这个请求关联的虚拟主机的配置。如果找到了这个虚拟主机的配置,那么通常情况下,这个 HTTP Request 将会经过以下几个阶段的处理(phase handlers):


NGX_HTTP_POST_READ_PHASE: 读取请求内容阶段


NGX_HTTP_SERVER_REWRITE_PHASE: Server 请求地址重写阶段


NGX_HTTP_FIND_CONFIG_PHASE: 配置查找阶段


NGX_HTTP_REWRITE_PHASE: Location请求地址重写阶段


NGX_HTTP_POST_REWRITE_PHASE: 请求地址重写提交阶段


NGX_HTTP_PREACCESS_PHASE: 访问权限检查准备阶段


NGX_HTTP_ACCESS_PHASE: 访问权限检查阶段


NGX_HTTP_POST_ACCESS_PHASE: 访问权限检查提交阶段


NGX_HTTP_TRY_FILES_PHASE: 配置项 try_files 处理阶段


NGX_HTTP_CONTENT_PHASE: 内容产生阶段


NGX_HTTP_LOG_PHASE: 日志模块处理阶段


在内容产生阶段,为了给一个 request 产生正确的响应,Nginx 必须把这个 request 交给一个合适的 content handler 去处理。如果这个 request 对应的 location 在配置文件中被明确指定了一个 content handler,那么Nginx 就可以通过对 location 的匹配,直接找到这个对应的 handler,并把这个 request 交给这个 content handler 去处理。这样的配置指令包括像,perl,flv,proxy_pass,mp4等。


如果一个 request 对应的 location 并没有直接有配置的 content handler,那么 Nginx 依次尝试:


如果一个 location 里面有配置 random_index on,那么随机选择一个文件,发送给客户端。


如果一个 location 里面有配置 index 指令,那么发送 index 指令指明的文件,给客户端。


如果一个 location 里面有配置 autoindex on,那么就发送请求地址对应的服务端路径下的文件列表给客户端。


如果这个 request 对应的 location 上有设置 gzip_static on,那么就查找是否有对应的.gz文件存在,有的话,就发送这个给客户端(客户端支持 gzip 的情况下)。


请求的 URI 如果对应一个静态文件,static module 就发送静态文件的内容到客户端。


内容产生阶段完成以后,生成的输出会被传递到 filter 模块去进行处理。filter 模块也是与 location 相关的。所有的 fiter 模块都被组织成一条链。输出会依次穿越所有的 filter,直到有一个 filter 模块的返回值表明已经处理完成。


这里列举几个常见的 filter 模块,例如:


server-side includes。


XSLT filtering。


图像缩放之类的。


gzip 压缩。


在所有的 filter 中,有几个 filter 模块需要关注一下。按照调用的顺序依次说明如下:


copy: 将一些需要复制的 buf(文件或者内存)重新复制一份然后交给剩余的 body filter 处理。


postpone: 这个 filter 是负责 subrequest 的,也就是子请求的。


write: 写输出到客户端,实际上是写到连接对应的 socket 上。



专栏作者简介 ( 点击 → 加入专栏作者 


陶邦仁:专注于后端技术研究,前端技术略有涉猎,热衷于构建高性能、高可用网站,擅长于平台服务化、分布式服务、分布式存储等方面的解决方案。目前就职于千丁互联,任技术经理一职,负责社区产品技术研发。曾就职于京东,负责库存组缓存方案技术实现;曾就职于百度糯米,负责PC首页、APP个性化排单服务化解决方案。

打赏支持作者写出更多好文章,谢谢!



【今日微信公号推荐↓】

更多推荐请看值得关注的技术和设计公众号


其中推荐了包括技术设计极客 和 IT相亲相关的热门公众号。技术涵盖:Python、Web前端、Java、安卓、iOS、PHP、C/C++、.NET、Linux、数据库、运维、大数据、算法、IT职场等。点击《值得关注的技术和设计公众号》,发现精彩!



点击阅读原文,了解野狗

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存