nginx源码分析

Ⅰ nginx host$1指的是什么

是这样衫茄子或没察的，nginx的ngx_http_variables.c文件中对于nginx内置的http变量进行了定义。
从nginx的源码来分析，修改headers_in中的host成员是不察含会修改$host变量的值的。
如下是nginx的代码：
{
ngx_string("http_host"),
NULL,
ngx_http_variable_...

Ⅱ 从刚刚“简书”平台的短暂异常，谈Nginx An error occurred报错～

An error occurred.

Sorry, the page you are looking for is currently unavailable.

Please try again later.

If you are the system administrator of this resource then you should check theerror log for details.

Faithfully yours, nginx.

如上，刚老徐正打算上平台，写文章，出现如上错误，应该持续了几分钟～不知道有多少用户有感知，平台响应还不错，几分钟后已恢复正常～

一般nginx的此类报错，原因如下（当然，老徐对nginx了解不深，如下都是一些可能原因）

出现问题，首先是去分析nginx的日志，得到一些线索～

可能的常见原因：

／ 1 ／

很明显这是一个nginx的错误，查看nginx.conf的文件过程中分析可能是以下行族的问题，在nginx.xml中胡带闷有如下配置：

标红的部分是很大的嫌疑，恰好应用中在提交数据的一瞬间和服务器有多次交互，这些交互都要过nginx。再加上用户IP来做key，假如多个用户访问在网上的最后一跳是同一个路由器，很显然会被服务器当成是一台电脑，从而出现判断错误。那么又一个新问题来了，出现503错误后为啥返回的是那个错误页面呢？

带着这个问题在nginx.conf中又发现了一段配置，如下图：

这个配置的意思是当出现500、502、503、504的错误时返回50x.html页面，这个页面在nginx安装目录的html文件夹下，内容如下：

这个页面经过浏览器解析就是开头第一幅图的样子。

分析到这裤弯里，就大概估计出原因了，把之前的rate值该大一点即可。那么到底改多大？这个要根据不同的业务而定，甚至去掉这个配置，所以这个是个经验值，通过多次试验可以得到一个相对于应用合理的值，这里就不说了。

实际nginx出现这个错误原因应该有很多，这里提供一种可能原因，以供网友参考。

／ 2 ／

日志记录中HTTP状态码出现499错误有多种情况，我遇到的一种情况是nginx反代到一个永远打不开的后端，就这样了，日志状态记录是499、发送字节数是0。

老是有用户反映网站系统时好时坏，因为线上的产品很长时间没有修改，所以前端程序的问题基本上可以排除，于是就想着是Get方式调用的接口不稳定，问了相关人员，说没有问题，为了拿到确切证据，于是我问相关人员要了nginx服务器的日志文件（awstats日志），分析后发现日志中很多错误码为499的错误，约占整个日志文件的1%，而它只占全部报错的70%左右（全部报错见下图），那么所有报错加起来就要超过1%了，这个量还是特别大的。

499错误是什么？让我们看看NGINX的源码中的定义：

ngx_string(ngx_http_error_495_page), /* 495, https certificate error */

ngx_string(ngx_http_error_496_page), /* 496, https no certificate */

ngx_string(ngx_http_error_497_page), /* 497, http to https */

ngx_string(ngx_http_error_404_page), /* 498, canceled */

ngx_null_string,                    /* 499, client has closed connection */

可以看到，499对应的是 “client has closed connection”。这很有可能是因为服务器端处理的时间过长，客户端“不耐烦”了。

Nginx 499错误的原因及解决方法

打开Nginx的access.log发现在最后一次的提交是出现了HTTP1.1 499 0 -这样的错误，在网络搜索nginx 499错误，结果都是说客户端主动断开了连接。

但经过我的测试这显然不是客户端的问题，因为使用端口+IP直接访问后端服务器不存在此问题，后来测试nginx发现如果两次提交post过快就会出现499的情况，看来是nginx认为是不安全的连接，主动拒绝了客户端的连接.

但搜索相关问题一直找不到解决方法，最后终于在google上搜索到一英文论坛上有关于此错误的解决方法：

proxy_ignore_client_abort on;

Don’t know if this is safe.

就是说要配置参数 proxy_ignore_client_abort on;

表示代理服务端不要主要主动关闭客户端连接。

以此配置重启nginx,问题果然得到解决。只是安全方面稍有欠缺，但比总是出现找不到服务器好多了。

还有一种原因是 我后来测试发现 确实是客户端关闭了连接,或者说连接超时 ,无论你设置多少超时时间多没用 原来是php进程不够用了 改善一下php进程数 问题解决

／ 3 ／

今天网站突然出现如下错误：

The page you are looking for is temporarily unavailable.Please try again later.

很奇怪，我对服务器端的技术不是很熟悉，于是查询了下google，在https://wiki.archlinux.org/index.php/Nginx

上面的解决方法：

Error: The page you are looking for is temporarily unavailable. Please try again later.

This is because the FastCGI server has not been started.

如何解决呢？

刚开始我怀疑是不是nginx挂了，我首先通过 ps aux | grep nginx ，结果出现：

root      3769  0.0  0.0   5760   692 ?        Ss   Apr21   0:00 nginx: master process /usr/local/nginx/sbin/nginx

www       3770  0.0  0.1  18680 14252 ?        S    Apr21   0:03 nginx: worker process

www       3771  0.0  0.1  18680 14252 ?        S    Apr21   0:03 nginx: worker process

www       3772  0.0  0.1  18712 14276 ?        S    Apr21   0:03 nginx: worker process

www       3774  0.0  0.1  18680 14248 ?        S    Apr21   0:03 nginx: worker process

www       3776  0.0  0.1  18712 14240 ?        S    Apr21   0:03 nginx: worker process

www       3777  0.0  0.1  18680 14252 ?        S    Apr21   0:03 nginx: worker process

www       3778  0.0  0.1  18680 14232 ?        S    Apr21   0:02 nginx: worker process

root     24068  0.0  0.0   5196   756 pts/1    S+   14:33   0:00 grep nginx

可见nginx是正常的，本来打算重启nginx的：

/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf的，

突然觉得有没有其他方法，有同事提示先在一个目录下运行下test.html和test.php，结果html可以运行，php无法运行。

证实是php没有启动，我刚才也检测过php的进程，的确是没有php进程，这台服务器我不熟悉，同事帮忙查看了下

cd /etc/init.d，就是web管理员经常看的地方，是随着系统自动启动的服务，程序等。可以看看：

http://blog.wgzhao.com/2008/12/27/talk-about-rc-local.html的《 说说？ /etc/rc.d/rc.local 》

找到：

/usr/local/php/sbin/php-fpm start，首先什么是php-fpm呢？

就是FastCGI Process Manager，是一种可选的PHP FastGCI执行模式，有一点很有特点的应用，尤其是一个繁忙的网站中：

(1)可适应的进行再生(NEW!)

(2)基本的统计功能（Apache's mod_status)

(3)高级进程管理功能，能够优雅的停止/开始

(4)能够使用不同的工作用户和不同的php.ini

(5)输入，输出日志记录...

开启后，一切恢复正常！自己的服务器端技术还是有很多地方使用的不够。需要多学习使用！

总结：

1、试检查一下nginx.conf的设置，是不是有limit的设置，比如limit_zone、limit_conn，这些参数也是有影响的。

2、检查一下防火墙，是不是有相关的设置限制。

3、检查一下nginx.conf的设置，看看有没有valid_referers none blocked的防链设置。

4、看下访问静态文件是否正常，错误排除～

OK，如上只是一些猜测～

具体原因，具体分析～

越来越多的系统，采用nginx，大家有必要了解些nginx的知识～

Ⅲ 服务器程序源代码分析之二：php-fpm

php作为排名top2 互联网开发工具，非常流行，可以参考：中国最大的25个网站采用技术选型方案

php这个名称实际上有两层含义

直接定义：

php-fpm从php5.3.3开始已经进入到php源代码包，之前是作为patch存在的

很少人会去读php本身源代码，我6年前解决php内存泄露问题的时候做了些研究,最近再查看了一番，发现php的开发者很有诚意，这是一款非常出色的服务器软件，支持如下

在linux服务器上，如果不设置 events.mechanism ,那么默认就是采用epoll，所以

php-fpm的IO模型&并发处理能力和nginx是完全一致

nginx以性能卓越闻名，大部分程序员都认为php效率低下，看了源代码，才知道这是传奇啊

在高性能部署的时候，大家往往会针对性的优化nginx 。我自己之前部署php程序也犯了错误，8G内存的server，php-fpm的max children都会设置128+，现在看来太多了，参考nginx的部署:

php-fpm配置为 3倍 cpu core number就可以了

php-fpm稳定性比nginx稍差 这是因为php-fpm内置了一个php解析器,php-fpm进程就和php程序捆绑了，如果php脚本写得不好，有死循环或者阻塞在某个远端资源上，会拖累加载它的php-fpm进程

而nginx和后端应用服务器之间通过网络连接，可以设置timeout，不容易堵死的

php-fpm的fastcgi是短连接 我原以为是长连接的，看了代码才知道也是短连接，处理一个request就关闭掉

php-fpm接口采用fastcgi 非常遗憾，php-fpm和fastcgi完全绑定了，无法独立使用 。只能部署在支持http-fcgi协议转换程序背后(nginx）。其实可以考虑在php-fpm代码包里面引入http协议支持，这样php-fpm可以独立运行，让nodejs无话可说

php-fpm等同于OpenResty OpenResty是一个国人开发的nginx模块，就是在nginx引入lua解释器. 实际上，它和php-fpm的唯一差别就是一个采用php语法，一个用lua，所以OpenResty要作为nginx增强包使用还可以，要选择它作为一个主要编程工具，没有任何必要

从架构上来说，php-fpm已经做到最好，超过大多数 python部署工具，我再也不黑它了

Ⅳ nginx 源代码分析 （一）

ngx_pool_t提供内存分配接口。

ngx_pool_t对大块内存和小块内存的分配使用不同的策略。

对于大块内存（超过指定阈值，一般是内存的页大小4096），调用malloc()动态分配。

对于小块内存，则是先预分配大的内存块，然后根据需要从中动态分配小块的。

ngx_create_pool()创建这个单向链表的第一个元素。

ngx_palloc()从指定的ngx_pool_t实例中分配内存。如果要求大块内存，则调用ngx_palloc_large()，否则调用ngx_palloc_small()。

对于ngx_palloc_small()，

对于ngx_palloc_large()，

ngx_free()负责释放内存。它只是调用free()释放大块嫌肆丛内存。实际上小块内存是不能一个一个释放的，nginx的策略是释放就释放全部。

ngx_reset_pool()释放所有大块内存，将ngx_pool_t链表置于未使用状态。

ngx_destroy_pool()释放所有大块内存，雹信也释芹樱放ngx_pool_t链表自身占用的内存。

nginx_pool_t还用于保存“待清理的任务”，这个任务保存在ngx_pool_cleanup_t结构中，从预分配内存中分配。这也是一个单向链表，保存在ngx_pool_t的成员cleanup中。

ngx_pool_cleanup_t的成员handler是任务的处理函数，成员data是处理函数的参数。

ngx_array_t实现了数组。

ngx_array_create()创建数组。

ngx_array_push()从数组中得到一个可用的元素。

ngx_list_create()实现单向链表。与一般链表不同的是，它的链表中每一个元素中保存的是一个数组。下图是包含两个ngx_list_part_t元素的链表。

ngx_list_create()创建一个链表。

ngx_list_push()从链表中得到一个可用的位置。

ngx_queue_t是一个双向链表。

使用ngx_queue_t的方式是，在结构中包含ngx_queue_t，就可以把结构串联起来。如下面的示意图。

ngx_queue_data()可以根据ngx_queue_t成员在结构中的位置偏移，从成员地址计算结构地址。

ngx_rbtree_t实现红黑树，ngx_rbtree_node_t是树上的节点。

对于ngx_rbtree_node_t，

对于ngx_rbtree_t，

Ⅳ nginx-rtmp模块简介

1:  Mole Configuration Struct(s)模块配置结构

这个结构的命名规则为ngx_http_[mole-name]_[main|srv|loc]_conf_t。

main,srv,loc表示这个模块的作用范围是配置文件中的main/server/location三种范围（这个需要记住，后面会经常用到）

2: Mole Directives模块命令结构

static ngx_command_t ngx_http_echo_commands[] = {

{

ngx_string("echo"), //命令名字

NGX_HTTP_LOC_CONF|NGX_CONF_TAKE1, //代表是local配置，带一个参数

ngx_http_echo, //组装模块配置结构

NGX_HTTP_LOC_CONF_OFFSET, //上面的组装模块配置获取完参数后存放到 哪里？使用这个和下面的offset参数来进行定位

offsetof(ngx_http_echo_loc_conf_t, ed), //同上 

},

ngx_null_command //必须使用ngx_null_command作为commands的结束标记

};

3: The Mole Context模块内容

static ngx_http_mole_t   ngx_http_circle_gif_mod ule_ctx

主要是定义了一些钩子函数, nginx会在不同时期会调用

4: The Mole Definition模块整合

ngx_mole_t ngx_http_<mole name>_mole = {

NGX_MODULE_V1,

&ngx_http__mole_ctx, /* mole context模块内容 */

ngx_http__commands, /* mole directives模块命令*/

NGX_HTTP_MODULE, /* mole type模块类型，HTTP模块，或者HTTPS*/

5: Mole Installation模块安装

1: ngx_rtmp_live_mole

直播模块:推拉流同点, 不涉及回源

2: ngx_rtmp_relay_mole

中继模块:  1:回源pull  2: 转推: push

一:  建立rtmp连接, 需要握手

      1: ngx_rtmp_handshake_recv()开始握手

      2: NGX_RTMP_HANDSHAKE_DONE()握手完成

      3: ngx_rtmp_cycle()重新设置读写handler

二:  建立网络连接

    建立rtmp连接之后, ngx_rtmp_recv函数会利用ngx_event_t结构会获取推送过来的原始数据, 接受到的数据会存放到ngx_rtmp_stream_t的in链表结构中.

1:接受chunk数据

2:分析处理chunk数据, 如果message还没接受完, 继续接受数据

3:将chunk组成一个rtmp message, 然后交给ngx_rtmp_receive_message处理, 这个函数根据消息的类型找对应的handle

三:  建立网络流

        在建立网络连接后,就需要建立网络流了, 网络流代表了发送多媒体数据的通道. 服务器和客户端只能建立一个网络连接, 且多个网络流可以复用这一个网络连接

1: ngx_rtmp_recv接受数据后交给ngx_rtmp_receive_handler, 它会根据类型区别处理, 此时客户端发送ngx_rtmp_msg_chunk_size类型的消息

2:接受message后跳转到处理函数ngx_rtmp_amf_message_handler. 处理客户端发送的amf控制消息. 此时连续接受3个amf数据.

3:调用ngx_rtmp_cmd_create_stream_init初始化网络流. 利用ngx_rtmp_receive_amf获取接受的amf数据.

4:调用ngx_rtmp_cmd_create_stream创建网络流, 利用ngx_rtmp_send_amf向客户端发送amf控制消息

四:  传输媒体数据

在客户端和服务端建立网络流之后,接下来就可以传输媒体数据了, 一般来讲, 媒体数据分为两部分, 一部分为meta元信息, 另一部分是音视频数据, 首先传送的是meta元信息. 然后推送媒体. 服务器处理如下:

1:从客户端接受amf命令信息, 然后服务端会利用ngx_rtmp_cmd_publish_init来初始化发布环境.  函数功能: 会读取刚接受端amf信息

2:利用ngx_rtmp_auto_push_publish, ngx_rtmp_notify_publish, ngx_rtmp_exec_publish建立发布环境,

3:如果conf配置了record命令记录媒体文件, 此时会调用ngx_rtmp_record_publish来初始化记录环境;

4:执行ngx_rtmp_access_publish;

[if !supportLists]l [endif]meta信息:

5:接受客户端amf, 并调用ngx_rtmp_codec_meta_data获取meta元信息;

6:结合服务器的参数, 利用ngx_rtmp_codec_reconstruct_meta接口重构meta元信息, 并调用ngx_rtmp_prepare_message组成消息保存

[if !supportLists]l [endif]媒体数据:

7:接受客户端推送, 根据类型转到ngx_rtmp_codec_av来处理音视频数据; 其中利用函数ngx_rtmp_codec_parse_avc_header来处理头部信息

8:调用record模块记录数据, 接口为ngx_rtmp_codec_av;

9:调用live模块来广播发布数据, 接口为ngx_rtmp_live_av, 广播到所有观察者, 第一次调用接口ngx_rtmp_live_start创建广播, 之后直接调用ngx_rtmp_append_shared-bufs

 

rtmp 的 信令交互图:

1: 播放器端发起play

2: ngx_rtmp_relay_play()

3: ngx_rtmp_relay_pull() --主要建立pull请求, 将远程拉流的上下文和本地上下文放到链表中

    ngx_rtmp_relay_create_local_ctx()创建本地上下文

    ngx_rtmp_relay_create_remote_ctx()创建远端上下文

4: ngx_rtmp_relay_create_remote_ctx详解:  创建远端session, 开始rtmp信令交互

       1: ngx_rtmp_relay_create_connection  

        2: ngx_rtmp_init_session

注意:此时session中的flashver为“ngx-local-relay“

5: rtmp信令交互流程

核心函数: ngx_rtmp_relay_on_result主要用来接收对端服务端发送的amf消息包，而后按正常rtmp协议请求进行下一步交互，这个主要是当前服务端做为客户端发起远程rtmp请求流程

例如:   ngx_rtmp_client_handshake(发起握手)

         握手完成后调用回调函数: ngx_rtmp_relay_handshake_done

       ngx_rtmp_relay_send_connect:发起连接请求, 接着参考rtmp信令交互图

        核心功能:向nginx推送一个直播流，该直播流经 nginx-rtmp 的 ngx_rtmp_live_mole 模块转发给 application live 应用，然后使用vlc连接 live，播放该直播流。本质上就是1对多的广播

参考: http://nginx.org/en/docs/debugging_log.html

1: Nginx-rtmp-mole模块源码学习

https://blog.evanxia.com/2017/02/1264

2: nginx_rtmp_relay_mole模块解读

https://www.shangmayuan.com/a/d74b78669f804fb5b12cae5a.html

3:开发手册中文版:包含指令介绍

https://blog.csdn.net/ai2000ai/article/details/55517992

Ⅵ Nginx rtmp 推流(publish) 解析

系列文章：
Nginx rtmp 拉流播放(play)_fdsafwagdagadg6576的专栏-CSDN博客
Nginx rtmp 拉流(转发pull)_fdsafwagdagadg6576的专栏-CSDN博客
Nginx rtmp 转推_fdsafwagdagadg6576的专栏-CSDN博客
Nginx rtmp 点播流模携简隐渣程_fdsafwagdagadg6576的专栏-CSDN博客

1 整体结构图:

先建立信令，然后接收媒体

2 流程图旦裤

4 源码分析:

**ngx_rtmp_relay_publish(ngx_rtmp_session_t s, ngx_rtmp_publish_t v)

**s->relay **

**接收流媒体 **

Ⅶ 07《Nginx 入门教程》Nginx 的 Http 模块介绍（上）

本部分内容将详细介绍 Nginx 中对 Http请求的 11 个处理阶段，分成 3 个小节讲解并进行相关实验操作。

Nginx 将一个 Http 请求分成多个阶段，以模块为单位进行处理。其将 Http请求的处理过程分成了 11 个阶段，各个阶段可以包含任意多个 Http 的模块并以流水线的方式处理请求。这 11 个 Http 阶段如下所示：

网上有人做了一个非常形象的图片，如下图所示。我们可以看到 11 个阶段的处理顺序，以及每个阶段中涉及到的相关模块以及模块之间的顺序。

POST_READ 阶段是 Nginx 接收到 Http 请求完整头部后的处理阶段，这里主要使用的是 realip 模块获取用户的真实地址，方便后续对该 IP 进行限速或者过滤其请求等。

SERVER_REWRITE 和后面的 REWRITE 阶段一般是使用 rewrite 模块修改 Http请求的 uri，实现请求的控制。

FIND_CONFIG 阶段只是做 location 的匹配项。

PREACCESS、ACCESS 和 POST_ACCESS 是和 Http 请求访问权限相关的阶段。PREACCESS 阶段是在连接之前要做的访问控制, 这个阶段有 limit_conn 和 limit_req 等模块工作。ACCESS 阶段是解决用户能不能访问，比如根据用户名、密码限制用户访问(auth_basic 模块)、根据 ip 限制用户访问(access 模块)以及第三方模块认证限制用户的访问(auth_request模块)。POST_ACCESS 是在 ACCESS 之后要做的一些工作。

TRY_FILES 阶段为访问静态文件资源而设置的。有时候又称之为 PRECONTENT 阶段，即在 CONTENT 阶段之前做的事情。主要是 try_files 模块在此阶段工作。

最重要的 CONTENT 是处理 Http 请求内容的阶段，大部分 HTTP 模块介入这个阶段，比如 index、autoindex、concat 以及反向代理的模块都是在这里生效的。

LOG 是处理完请求后的日志记录阶段，如 access_log 模块。

realip 模块是在 postread 阶段生效的，它的作用是: 当本机的 nginx 处于一个反向代理的后端时获取到真实的用户 ip。 如果没有 realip 模块，Nginx 中的 $remote_addr 可能就不是客户端的真实 ip 了，而是代理主机的 ip。
realip模块的配置实例如下:

set_real_ip_from 是指定我们信任的后端代理服务器，real_ip_header 是告诉 nginx 真正的用户 ip 是存在 X-Forwarded-For 请求头中的。

当 real_ip_recursive 设置为 off 时，nginx 会把 real_ip_header 指定的 Http头中的最后一个 ip 当成真实 ip;

而当 real_ip_recursive 为 on 时，nginx 会把 real_ip_header 指定的 Http头中的最后一个不是信任服务器的 ip (前面设置的set_real_ip_from)当成真实 ip。通过这样的手段，最后拿到用户的真实 ip。

rewrite 模块可以看到它在 SERVER_REWRITE 和 REWRITE 阶段都有介入。rewrite 模块的主要功能是改写请求的 uri。它是 Nginx 默认安装的模块。rewrite 模块会根据正则匹配重写 uri，然后发起内部跳转再匹配 location, 或者直接做30x重定向返回客户端。rewrite 模块的指令有 break, if, return, rewrite, set 等，这些都是我们常用到的。

return 指令返回后，Http 请求将在 return 的阶段终止，后续阶段将无法进行，所以许多模块得不到执行。

1、将 regex 指定的 url 替换成 replacement 这个新的 url,可以使用正则表达式及变量提取。

2、当 replacement 以 http:// 或者 https:// 或者 $schema 开头，则直接返回 302 重定向

3、替换后的 url 根据 flag 指定的方式进行处理

if 指令的条件表达式:

location 匹配是在 FIND_CONFIG 阶段进行的，我们需要掌握 location 的匹配规则和匹配顺序。

有一个简单总结如下：

即：

realip 模块默认没有被编译进 Nginx 的，我们需要在源码编译阶段使用–with-http_realip_mole，将 realip 模块编译进来后方可使用。接下来，我们做个简单测试，首先准备一个 server 块如下：

首先，我们将 real_ip_recursive 设置为 off，然后做一次请求:

这里返回的是头部参数 X-Forwarded-For 中最后一个 ip，如果将 real_ip_recursive 设置为 on，此时，由于 set_real_ip_from 中设置218.19.206.164为信任的方向代理 ip，那么 Nginx 会往前找一位，认为 1.1.1.1 是用户的真实ip。

我们写一个简单配置如下：

先测试if指令，当请求方法为 POST 时，我们能得到 ‘post request!’ 这样的字符串输出。GET 请求时候，针对 404 情况，会跳转到/403.html，我们准备一个 403.html 页面，里面写上’403, forbidden!’ 这一行内容，开始下面的 Http 请求:

如果我们打开 return 405 这行指令，则 error_page 将不会生效，连同后面的 location 匹配也不会生效。无论我们发送如何请求，都会返回405的错误信息。这是因为 server 中的 return 指令是在 SERVER_REWRITE中执行的，而 location 匹配则是在下一个阶段 FIND_CONFIG 中执行的，所以上一个阶段在 return 后，根本不会进入后面的阶段执行。

首先，我们准备环境，首先是新建一个目录 third（全路径为/root/test/third），再该目录下新建一个文件 3.txt, 里面只有一行内容 ‘hello, world’。接下来，我们准备一个 server 块，加到 Http 指令块中:

上述配置中，要打开 rewrite_log指令，这样我们可以看到 rewrite 指令的相应日志，方便查看结果。

当我们在 /second 配置中，使用 break 时，请求命令:

如果是不使用 break 标识，则请求结果如下:

首先是 /first/3.txt 请求在 /first 中匹配，并被替换为 /second/3.txt， last 标识表示将继续进行匹配，在 /second 中，uri 又被 rewrite 成 /third/3.txt, 如果后面跟了 break 标识，表示 rewrite 到此结束，不会执行后面的 return 指令，直接请求静态资源 /third/3.txt,得到其内容’hello, world’;如果是没有 break 标识，则会在执行 return 指令后直接返回，并不会继续执行下去，最后返回’second!'字符串。

我们按照这样的 location 规则，进行匹配实验，结果如下：

这里介绍了 Nginx 处理 Http 请求的 11 个阶段，并重点介绍了 前三个阶段POST_READ、REWRITE以及FIND_CONFIG以及这些阶段中涉及到的模块和指令。前面讲到的指令都是 Nginx 中的高频指令，必须要熟练掌握。

Ⅷ nginx动态域名解析

原文链接：
https://priesttomb.github.io/%E6%8A%80%E6%9C%AF/2020/05/17/nginx-cached-dns-server-resolvered-answer/

接 上篇文章 中提到的 Nginx 解析域名地址的问题，用一句话描述就是“proxy_pass 中如果配置的是域名地址，Nginx 只有在 start / restart / reload 时，才会连接一次域名服务器解析域名，缓存解析的结果，后续则 不会根据解析结果的 TTL 进行自动更新 ”，如果遇到了域名地址配置有多个 IP ，且还在动态变化，那就会出现 Nginx 把请求转发到一个过期的 IP 地址的情况，连接超时的报错日志类似这样：

这个说法在 官方的一篇 2016 年的博客 中有提到：

除此之外，除了一些分析源码的网络文章，暂时还没有找到其他的官方文档中说到这个细节

在 upstream 中可以对上游的服务器进行更详细的设置，解决 DNS 缓存的问题可以在 upstream 中指定需要的负载均衡算法，比如 least_conn ，并指定 max_fails ，以实现调用失败 N 次之后判定该服务异常，暂停转发该服务

注：

这个配置的示例是官方博客中的，看到这个配置时觉得有点闹明奇怪，自己进行了模拟测试，测试的方案是在 hosts 文件中配置一个模拟的域名与三个 IP 地址，其中两个 IP 是正确的，另一个是内网不存在的 IP，测试的结果就是 Nginx 始终会将请求转发到那个错误的 IP 去，日志中一直能看到超时的报错，配置的 max_fails 仿佛没有任何作用（有补充配置了 fail_timeout ，也尝试配置了 proxy_next_upstream 、 proxy_next_upstream_timeout 和 proxy_next_upstream_tries ）

不清液者告楚用 hosts 配置的方式是不是必然会出现这样的情况，因为目前没条件测试真正想要的场景，所以不敢说博客中的这种配置是错的【如果以后碰巧有条件能测试验证，再回头来更新

最初学习 Nginx 的时候测试过 max_fails 这个配置，当时在 upstream 里配置的都是一些 IP 地址的上游服务。再次按 IP 地址进行测试，在 upstream 中配置两个正确的 IP 地址 和一个错误的 IP 地址，发现这样的配置就是能生效的，失败一定次数之后（实际失败的次数比设置的 max_fails 多，不清楚什么原因），Nginx 在 fail_timeout 时间内就不再转发请求到那个错误的 IP

resolver 的配置详情可看 官方文档 ，示例的配置是指定 DNS 服务器 10.0.0.2，指定 DNS 解析的有效时间为 10 秒，按博客 《Nginx动态解析upstream域名》 中博主的测试，不是说 Nginx 每过 10 秒会自己重新调一次 DNS 解析，而是嫌埋有请求转发时才检验一次有效期是否过期

不配置 valid 选项时，V1.1.9 之后的 Nginx 默认会使用 DNS 解析结果中的 TTL

在 proxy_pass 中使用变量，带来的作用就是在 TTL 过期时能再次调用 DNS 解析，从而解决一直使用缓存结果的问题

这大概是目前官方原版唯一解决 DNS 缓存的解决方案了，带来的弊端也如 《Nginx动态解析upstream域名》 的博主所说，不能使用 upstream 模块特有的相关配置

Nginx Plus 版有更好的配置解决这些问题，另外使用 Lua 插件或许也能更完美的解决这个问题，暂时就没什么研究了

Ⅸ [code.nginx] Nginx的时间管理

在Linux平台上获取系统时间的方法有很多，比如使用time()函数、gettimeofday()函数和localtime()函数等，大部分函数本质上都是通过系统调用来获取时间的。但是使用系统调用时，有一个问题需要特别关注，就是系统调用开销的问题。

Nginx服务器程序在获取系统时间时，本质上使用的是gettimeofday函数，该函数是C语言库提供的函数，从严格意义上来讲，该函数不也是系统调用，但它是对系统调用sys_gettimeofday()的封装，因此一般也就认为它是一个系统调用了。
大家都知道，Linux平台上程序函数调用可以分为库调用和系统调用两大类，这里不过多的解释这两种机制的不同，主要是明确系统调用与库调用相比，时间成本是相当巨大的。程序执行一次系统调用将至少经过一下步骤：

在Linux平台上使用C语言进行程序设计时，为了精确获取系统时间，我们经常会使用gettimeofday()这个函数。该函数的原型为：

调用该函数后，当前的时间将用timeval结构体返回，时间可以精确到微秒。当地时区的信息则放在timezone结构体中。timeval结构体的定义为：

gettimeofday()函数在执行过程中，一般情况下实际上是调用了另一个函数sys_gettimeofday()，该函数才是名副其实的系统调用，通过该调用就可以获取保存在系统内核中的时间信息。在实际程序设计中是不提倡频繁使用gettimeofday()函数的。
vsyscall方式在内存中创建了一个内核态的共享页面，它的数据由内核来维护，但这块区域用户态也有权限访问，通过这样的机制，不经过系统中断和陷入内核也能获取一些内核信息。x86_64体系上使用vsyscall方式实现了gettimeofday()的功能，这样系统开销比普通的系统调用要小的多。

Nginx服务器重视程序的高效运行，Nginx程序采取缓存时间的方法来减少对gettimeofday()的调用，并且每个工作进程会自行维护时间缓存。Nginx的时间缓存一般会赋值给一下四种变量，更新缓存时是同步更新的。

Nginx服务器更新时间缓存的两个函数是ngx_time_update()和ngx_time_sigsafe_update()，具体的实现的源码都在/nginx/src/core/ngx_time.c中可以找到。我们分别来分析一下它们的源码。
1.ngx_time_update()
该函数是Nginx服务器时间管理的核心函数。更新时间缓存的过程实际上是一个写缓存的过程，Nginx服务器为了解决信号处理过程中更新时间缓存产生的数据一致性的问题，需要使用原子变量ngx_time_lock进行写加锁。

2.ngx_time_update()的调用
该函数的调用时机主要有三个：一是在Nginx服务器主进程捕捉、处理完一个信号返回的时候。二是在缓存索引管理进程中调用该函数，用于标记缓存数据的时间属性。三是在Nginx服务器工作进程中在进行事件处理时调用了该函数。主要是第三种情况对该函数的调用频率较高。
epoll_wait()函数用于等待事件的产生，执行epoll_wait()函数返回后会调用ngx_time_update()函数更新时间缓存。当epoll机制通知有事件到达或者epoll机制超时退出时，Nginx服务器程序就会更新一次缓存时间。然后调用各个事件对应的处理函数处理事件。

指令timer_resolution用于设置执行两次缓存时间更新工作之间的间隔时间。该参数设置的越大，则对系统调用gettimeofday()的使用频率就越低，但缓存时间的精度也就越低。该指令的语法结构为：

其中的Interval参数就是更新时间间隔，默认值为100ms。该指令只能在Nginx配置文件的全局块中进行设置。