一.Nginx是什么，常用于哪些场景及其优点是什么？？
高性能web服务器，常用于 静态web服务器（动静分离）、反向代理和负载均衡服务器、OpenAPI网关；优点有5个：高并发和高性能、高稳定性、高可扩展性、热部署和热升级、开源免费。
基于异步非阻塞的事件驱动模型（master-worker模式）
严格的来说，Nginx 应该叫做 HTTP Server； Tomcat 则是一个Application Server。
Nginx 整体采用模块化设计，有丰富的模块库和第三方模块库，配置灵活;Nginx在处理每一个用户请求时，都是按照若干个不同的阶段依次处理的，与配置文件上的顺序没有关系，详细内容可以阅读《深入理解nginx:模块开发与架构解析》这本书。
Nginx把所有功能都统一抽象成模块，即“万物皆模块”。每个模块仅仅完成一个独立、简单的功能（说白点，就是一个功能模块不能占用cpu时间太长）。
对于一个HTTP请求来说，需要我们考虑的内容很多，因此Nginx将HTTP请求划分成以下11个阶段，每个阶段只处理很简单的功能.
NGX_HTTP_POST_READ_PHASE: 接收完请求头之后的第一个阶段，它位于uri重写之前，实际上很少有模块会注册在该阶段，默认的情况下，该阶段被跳过。
NGX_HTTP_SERVER_REWRITE_PHASE: server级别的uri重写阶段，也就是该阶段执行处于server块内，location块外的重写指令，在读取请求头的过程中nginx会根据host及端口找到对应的虚拟主机配置
NGX_HTTP_FIND_CONFIG_PHASE: 寻找location配置阶段，该阶段使用重写之后的uri来查找对应的location，值得注意的是该阶段可能会被执行多次，因为也可能有location级别的重写指令
NGX_HTTP_REWRITE_PHASE: location级别的uri重写阶段，该阶段执行location基本的重写指令，也可能会被执行多次
NGX_HTTP_POST_REWRITE_PHASE: location级别重写的后一阶段，用来检查上阶段是否有uri重写，并根据结果跳转到合适的阶段
NGX_HTTP_PREACCESS_PHASE: 访问权限控制的前一阶段，该阶段在权限控制阶段之前，一般也用于访问控制，比如限制访问频率，链接数等
NGX_HTTP_ACCESS_PHASE: 访问权限控制阶段，比如基于ip黑白名单的权限控制，基于用户名密码的权限控制等
NGX_HTTP_POST_ACCESS_PHASE: 问权限控制的后一阶段，该阶段根据权限控制阶段的执行结果进行相应处理
NGX_HTTP_TRY_FILES_PHASE: try_files指令的处理阶段，如果没有配置try_files指令，则该阶段被跳过 NGX_HTTP_CONTENT_PHASE: 内容生成阶段，该阶段产生响应，并发送到客户端
NGX_HTTP_LOG_PHASE: 日志记录阶段，该阶段记录访问日志
二.反向代理和负载均衡
反向代理：代理上游服务器（正向代理：代理客户端）（proxy_pass）
负载均衡：客户端的请求量即为负载，将负载分配到集群中的服务器即为负载均衡
Nginx支持的负载均衡调度算法方式如下：
weight轮询(默认)：
接收到的请求按照顺序逐一分配到不同的后端服务器，即使在使用过程中，某一台后端服务器宕机，Nginx会自动将该服务器剔除出队列，请求受理情况不会受到任何影响。 这种方式下，可以给不同的后端服务器设置一个权重值(weight)，用于调整不同的服务器上请求的分配率；权重数据越大，被分配到请求的几率越大；该权重值，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
ip_hash：
每个请求按照发起客户端的ip的hash结果进行匹配，这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器，这也在一定程度上解决了集群部署环境下session共享的问题。
fair：智能调整调度算法
动态的根据后端服务器的请求处理到响应的时间进行均衡分配，响应时间短处理效率高的服务器分配到请求的概率高，响应时间长处理效率低的服务器分配到的请求少；结合了前两者的优点的一种调度算法。但是需要注意的是Nginx默认不支持fair算法，如果要使用这种调度算法，请安装upstream_fair模块。
url_hash：
按照访问的url的hash结果分配请求，每个请求的url会指向后端固定的某个服务器，可以在Nginx作为静态服务器的情况下提高缓存效率。同样要注意Nginx默认不支持这种调度算法，要使用的话需要安装Nginx的hash软件包。
配置方式：upstream 配置上游服务器
upstream test{
ip_hash; --ip_hash
或者 --url_hash
hash $request_url;
hash_method crc32
或者 --默认weight轮询
默认
server localhost:8080;
server localhost:8081;
}
三.Nginx(Openresty)安装配置及使用配置
1.下载nginx-upsync到openresty-1.13.6.2 的bundle目录（bundle存放第三方模块）
git clone https://github.com/weibocom/nginx-upsync-module.git # 建议使用git clone代码编译，刚开始我使用release的tar.gz 编译nginx失败了
2.cd openresty-1.13.6.2
./configure --prefix=/home/zhangshilei/openresty_sync
--with-luajit
--with-http_iconv_module
--add-module=./bundle/nginx-upsync-module/
-j2
3.make &&make install
四：目录结构及常用Nginx指令
nginx.conf文件中的相对目录是prefix或者-p指定的目录
Nginx worker进程数一般设置与CPU核心数一致
在执行configure命令是已经将很多模块编译进nginx,但是是否启用这些模块，取决于配置文件nginx.conf中对应的配置项
常用指令：
1.另行指定配置文件的启动方式
./nginx -c tempnginx.conf
- 另行指定安装目录的启动方式
./nginx -p xxx/xx/
3.另行指定全局配置项
./nginx -g "pid xx/xx/test.pid;" eg ./nginx -g "pid xx/xx/test.pid;" -s stop
4.测试配置文件是否有误
./nginx -t -c tempnginx.conf
5.显示Nginx版本信息
./nginx -v
6.显示编译阶段的参数
./nginx -V
7.向master进程发信号
./nginx -s stop ./nginx -s quit ./nginx -s reload ./nginx -s reopen
8.ps命令来查看nginx master的进程ID：
ps -ef| grep nginx
netstat -ntlp sudo netstat -anp | grep nginx 查看虚拟主机端口号
9.根据master进程进程号关闭nginx
kill -s SIGTERM pid
五：nginx.conf配置
虚拟主机：
常用配置分类：
虚拟主机和请求的分发、文件路径的定义、内存及磁盘资源的分配、网络连接的设置、MIME类型的设置、对客户端请求的限制、文件操作的优化、对客户端请求的特殊处理等
nginx.conf:
定义Nginx运行的用户和用户组
user www www;
启动进程,通常设置成和cpu的数量相等
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
为每个进程分配cpu，上例中将8个进程分配到8个cpu，当然可以写多个，或者将一个进程分配到多个cpu。
指定Nginx worker进程可以打开的最大句柄描述符个数
worker_rlimit_nofile 102400;
全局错误日志及PID文件
error_log /usr/local/nginx/logs/error.log;
错误日志定义等级，[ debug | info | notice | warn | error | crit ]
pid /usr/local/nginx/nginx.pid;
工作模式及连接数上限
events {
use epoll; #epoll是多路复用IO(I/O Multiplexing)中的一种方式,但是仅用于linux2.6以上内核,可以大大提高nginx的性能
worker_connections 102400;
单个后台worker process进程的最大并发链接数 （最大连接数=连接数*进程数）
multi_accept on;
尽可能多的接受请求
}
设定http服务器，利用它的反向代理功能提供负载均衡支持
http {
设定mime类型,类型由mime.type文件定义
include mime.types; #相对nginx.conf的相对路径下
default_type application/octet-stream;
设定日志格式
access_log /usr/local/nginx/log/nginx/access.log;
sendfile on;
sendfile 指令指定 nginx 是否调用 sendfile 函数（zero copy 方式）来输出文件，对于普通应用必须设为 on
如果用来进行下载等应用磁盘IO重负载应用，可设置为 off，以平衡磁盘与网络I/O处理速度，降低系统的 uptime.
autoindex on; #开启目录列表访问，合适下载服务器，默认关闭。
tcp_nopush on; #防止网络阻塞
keepalive_timeout 60; #keepalive超时时间，客户端到服务器端的连接持续有效时间,当出现对服务器的后,继请求时,keepalive-timeout功能可避免建立或重新建立连接。
tcp_nodelay on; #提高数据的实时响应性
开启gzip压缩
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.1;
gzip_comp_level 2;
压缩级别大小，最大为9，值越小，压缩后比例越小，CPU处理更快。
值越大，消耗CPU比较高。
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;
client_max_body_size 10m; #允许客户端请求的最大单文件字节数
client_body_buffer_size 128k; #缓冲区代理缓冲用户端请求的最大字节数
proxy_connect_timeout 90; #nginx跟后端服务器连接超时时间(代理连接超时)
proxy_send_timeout 90; #后端服务器数据回传时间(代理发送超时)
proxy_read_timeout 90; #连接成功后，后端服务器响应时间(代理接收超时)
proxy_buffer_size 4k; #设置代理服务器（nginx）保存用户头信息的缓冲区大小
proxy_buffers 4 32k; #proxy_buffers缓冲区，网页平均在32k以下的话，这样设置
proxy_busy_buffers_size 64k; #高负荷下缓冲大小（proxy_buffers*2）
设定请求缓冲
large_client_header_buffers 4 4k;
client_header_buffer_size 4k;
客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求的头部大小不会超过1k #不过由于一般系统分页都要大于1k，所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得。
open_file_cache max=102400 inactive=20s;
这个将为打开文件指定缓存，默认是没有启用的，max指定缓存数量，建议和打开文件数一致，inactive是指经过多长时间文件没被请求后删除缓存。
open_file_cache_valid 30s; #这个是指多长时间检查一次缓存的有效信息。
open_file_cache_min_uses 1; #open_file_cache指令中的inactive参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive
包含其它配置文件，如自定义的虚拟主机
include vhosts.conf;
这里为后端服务器wugk应用集群配置，根据后端实际情况修改即可，tdt_wugk为负载均衡名称，可以任意指定 #但必须跟vhosts.conf虚拟主机的pass段一致，否则不能转发后端的请求。weight配置权重，在fail_timeout 内检查max_fails次数，失败则剔除均衡。
upstream tdt_wugk {
server 127.0.0.1:8080 weight=1 max_fails=2 fail_timeout=30s;
server 127.0.0.1:8081 weight=1 max_fails=2 fail_timeout=30s;
}
虚拟主机配置
server {
侦听80端口
listen 80;
定义使用www.wuguangke.cn访问
server_name www.wuguangke.cn;
设定本虚拟主机的访问日志
access_log logs/access.log main;
root /data/webapps/wugk; #定义服务器的默认网站根目录位置
index index.php index.html index.htm; #定义首页索引文件的名称 #默认请求
location ~ /{
root /data/www/wugk;
定义服务器的默认网站根目录位置
index index.php index.html index.htm;
定义首页索引文件的名称 #以下是一些反向代理的配置.
proxy_next_upstream http_502 http_504 error timeout invalid_header;
如果后端的服务器返回502、504、执行超时等错误，自动将请求转发到upstream负载均衡池中的另一台服务器，实现故障转移。
proxy_redirect off; #后端的Web服务器可以通过X-Forwarded-For获取用户真实IP proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://tdt_wugk; #请求转向后端定义的均衡模块
}
定义错误提示页面
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
配置Nginx动静分离，定义的静态页面直接从Nginx发布目录读取。
location ~ .*.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)$ {
root /data/www/wugk;
expires定义用户浏览器缓存的时间为3天，如果静态页面不常更新，可以设置更长，这样可以节省带宽和缓解服务器的压力。
expires 3d;
}
PHP脚本请求全部转发到 FastCGI处理. 使用FastCGI默认配置.
location ~ .php$ {
root /root;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /data/www/wugk$fastcgi_script_name;
include fastcgi_params;
}
设定查看Nginx状态的地址
location /NginxStatus {
stub_status on;
}
}
}
一些模块处理请求时可以产生丰富的变量，当然，这些变量还可以用于其他Http模块
Nginx会拿到完整的用户请求存到nginx服务器硬盘或内存后，再向上游服务器发起连接，把缓存的客户端其你去转发到上游服务器
缺点:延长一个请求的处理时间，增大磁盘和内存压力
优点：降低上游服务器负载，把压力放在nginx服务器上
Nginx不会将请求和响应的头部发给对方，可配置加入
自定义模块
一个模块是一个或多个.c文件，将这些文件放到一个文件夹，并在该文件夹下建一个conf文件
在该conf文件中加入下面变量
ngx_addon_name=ngx_http_mytest_module ##指定模块名
HTTP_MODULES="$HTTP_MODULES ngx_http_mytest_module" ##在http模块中加入本模块(也可以是其他模块)
NGX_ADDON_SRCS="ngx_addon_dir/ngx_http_mytest_module.c" ##加入本模块源码
$ngx_addon_dir等价于—add-module=path中的path
编写.c文件
内涵：
ngx_command_t/ngx_http_module_t/ngx_module_t/nginx_http_Xxx_handler/ngx_http_xxx(注册handler)
Server匹配规则： 请求找到对应server处理（找到处理请求的组件）
1.Nginx取出请求头中的Host，与server_name进行匹配
规则:完全匹配>匹配通配符在前>匹配通配符在后>正则表达式
另外 server_name 默认为”” 表示匹配没有host的请求
host形式： 域名； 域名：port; ip:port
2.如果上一步没有匹配到则进行端口匹配
规则：端口中配置default|default_server>匹配listen端口的第一个server
端口：listen 8000;表示监听*:80000
listen 127.0.0.1 表示监听 127.0.0.1:80
listen 127.0.0.1:8000 表示监听 127.0.0.1:8000
先server_name匹配，匹配不到看listen有没有配置默认server,最后进行端口匹配**
我的理解：请求首先根据请求端口进入端口，服务器中端口上保存对应的server信息，开始匹配server_name，当host与其中的server_name匹配，对应server处理，如果不匹配找寻该port下是否存在listen配置了default|default_server ,若有则由该server处理，没有则匹配该port下的找到的第一个server处理
Location匹配规则：请求URI匹配location（找到组件中具体处理方法）
location [=||*|^~|@] /uri/ { … }
[] 内为可选项
location匹配分两种：普通匹配、正则匹配
一般以[=,^~。@]或者不加任何前缀表示普通匹配，普通匹配没有书写顺序，匹配规则是”最大前缀“，
以[,*]开头表示正则匹配，正则匹配有书写顺序，一旦匹配就进入到该location块执行
:区分大小写的正则匹配；*：不区分大小写的正则匹配
前缀含义：不加任何前缀：表示普通匹配，后续仍会进行正则匹配，可以被正则匹配覆盖
= 表示严格精准匹配 ^~表示部分匹配最大长度匹配后不需要再进行正则匹配
（如果不加前缀达到完全匹配，则也是不需要正则匹配的）
正则location 匹配让步普通 location 的精确匹配结果；但覆盖普通 location的最大前缀匹配结果
究极总结：location = >location完全匹配>location ^~ >location | >location部分匹配
https://www.cnblogs.com/lidabo/p/4169396.html
请求转发与重定向
在****nginx****的****rewrite****阶段
包含
匹配进入对应location的处理
1.root 和alias规则
2.proxy_pass规则
六：goaccess使用
服务器访问监控的UI:goaccess
安装：
wget https://tar.goaccess.io/goaccess-1.3.tar.gz
tar -xzvf goaccess-1.3.tar.gz
cd goaccess-1.3/
./configure --enable-utf8 --enable-geoip=legacy
make
make install
使用：
1.配置
goaccess-1.3目录下运行：实时的将nginx的access.log 转存为report.html
[root@localhost goaccess-1.3]#./goaccess /home/zhangshilei/openresty_lua/logs/access.log -o /home/zhangshilei/openresty_lua/html/report.html --real-time-html --time-format='%H:%M:%S' --date-format='%d/%b/%Y' --log-format=COMBINED
！！！！需要执行上述命令，才能实时监控
2.修改nginx.conf
location report.html{
alias html/report.html;
}
3.访问
10.10.38.195:8002/report.html 该页面监控对服务器的的访问
七：ngx_lua API （Lua<-->C相互调用API）
（https://github.com/openresty/lua-nginx-module#ngxshareddictcapacity）
nginx lua 的8个阶段
init_by_lua
set_by_lua
rewrite_by_lua
access_by_lua
content_by_lua
header_filter_by_lua
body_filter_by_lua
log_by_lua
上述网址中有相关的nginx_lua的指令和api 在nginx中使用lua 在lua代码中使用nginx的参数
项目结构：
将lua代码写到一个文件中。在nginx.conf 的http模块中加入lua_package_path 指定?.lua的搜索路径，并写一个lua.conf 在nginx.conf中 include lua.conf;在lua.conf中引用对应的lua文件。在lua代码中使用 require("a.b.c")的方式引入对应的lua代码（c为文件名，a/b为包名）
八：nginx 高可用（keepAlive使用）
#九：Lua脚本学习
Nginx 变量的创建和赋值操作发生在全然不同的时间阶段。Nginx 变量的创建只能发生在 Nginx 配置加载的时候，或者说 Nginx 启动的时候（rewrite阶段）；而赋值操作则只会发生在请求实际处理的时候（content阶段）。这意味着不创建而直接使用变量会导致启动失败，同时也意味着我们无法在请求处理时动态地创建新的 Nginx 变量。(变量在一个请求处理过程被赋值，不同请求有不同的值，所以变量作用域是一个请求处理过程)
Nginx 变量一旦创建，其变量名的可见范围就是整个 Nginx 配置，甚至可以跨越不同虚拟主机的server配置块
Nginx 内建变量最常见的用途就是获取关于请求或响应的各种信息
在Nginx 配置中，变量只能存放一种类型的值，因为也只存在一种类型的值，那就是字符串 ,在Nginx中，除非特殊说明，大部分地方字符串的不需要引号括住，字符串和变量的拼接也不需要引号
一个请求处理过程中维护一个变量副本，不同的请求变量副本不同
“主请求”以及各个“子请求”都拥有不同的变量$var的值容器副本
并非所有的内建变量都作用于当前请求。少数内建变量只作用于“主请求”
ngx_lua API： 从nginx中获取到请求通过lua处理后返回给nginx，最终返回给客户的整个过程
ngx.arg是一个表，可以把nginx的变量放到这个表中，供给Lua使用
context:set_by_lua, body_filter_by_lua
set_by_lua a $b;
ngx.var.VARNAME： 相当于直接操作nginx变量
context:set_by_lua, rewrite_by_lua, access_by_lua, content_by_lua, header_filter_by_lua, body_filter_by_lua, log_by_lua
ngx.var :table保存了Nginx中的变量ngx.var[1] ngx.var.varname
Nginx中已经定义的变量可以被直接使用；
在lua中将变量设置为nil，则Nginx中该变量也会消失. 注意：最好在lua中定义一个变量接收该变量，避免修改导致无法使用
ngx.ctx是一个当前请求对应的lua上下文表（一个请求对应的存储域）
context:init_worker_by_lua, set_by_lua, rewrite_by_lua, access_by_lua, content_by_lua, header_filter_by_lua, body_filter_by_lua, log_by_lua, ngx.timer., balancer_by_lua
ngx.shared.DICT共享内存多worker共用
在http模块中定义如下
lua_shared_dict dog 10m;
在其他地方通过ngx.shared.dog：XX()方法使用该内存* ngx_shared_DICT API
print(...)等价于 ngx.log(ngx.NOTICE, …) 向日志文件中写入内容
ngx.log(log_level, ...)
ok, err = ngx.print(...)：向客户端发送内容，需要先发送响应头
ngx.say():跟ngx.print()一样，只是尾随一个换行符
secs = ngx.req.start_time()请求发起时间
num = ngx.req.http_version()num值：.0, 1.0, 1.1, 0.9，nil表示为识别
ngx.status 读写请求的响应状态（发出响应header之前使用，否则也没大影响只会在error.log中记录error message）
ok, err = ngx.send_headers()发出响应头
value = ngx.headers_sent检测是否发出了响应头
ok, err = ngx.flush(wait?)Flushes response output to the client ：发出响应
ngx.exit(status)结束执行并向nginx返回状态吗
ok, err = ngx.eof()显式指定响应输出流的结尾
时间相关
ngx.sleep(seconds)
str = ngx.today()
secs = ngx.time()
secs = ngx.now()
ngx.update_time()
str = ngx.localtime()当前位置时间 time stamp format yyyy-mm-dd hh:mm:ss
str = ngx.utctime()* UTC time time stamp format yyyy-mm-dd hh:mm:ss
正则支持
captures, err =ngx.re.match(subject, regex, options?, ctx?, res_table?)正则 subject是否匹配正则表达式regex
from, to, err = ngx.re.find(subject, regex, options?, ctx?, nth?)返回正则匹配的位置
iterator, err = ngx.re.gmatch(subject, regex, options?)正则匹配后返回一个迭代器
newstr, n, err = ngx.re.sub(subject, regex, replace, options?)正则匹配后返回第一个匹配的字符串
Nginx提供获取请求的uri的变量 所以ngx_lua没有提供对应的方法
ngx.var.request_uri
$uri指的是请求的文件和路径，不包括“?”或者“#”之后的东西，
$request_uri则是请求的整个字符串，包含了后面的query_string的
请求转发与重定向
rewrite regrex replacement option;
请求uri匹配regex表达式后，使用replacement改写uri,
option:
last： 发起一次重新匹配location server块中使用last
break：不发起重新匹配location location块中常用break
redirect:客户端重发请求
（请求包含）ngx.location.capture:发送子请求的方式实现location的重新定位（一般在location中的content_by_lua 重新匹配location 且指定了请求参数）
res = ngx.location.capture(uri, options?)一般在location中发送子请求得到响应res res.status/ res.body/ res.header/ res.truncated 参数是请求uri和请求参数 请求参数类似一个table，内部可配置多参数method body args ctx
inherit all the request headers of the current request by default ：子请求继承本请求的headers
When the body option is not specified and the always_forward_body option is false (the default value), the POST and PUT subrequests will inherit the request bodies of the parent request
ngx.location.capture.mutil发送多个子请求
res1, res2, ... = ngx.location.capture_multi({ {uri, options?}, {uri, options?}, ... })
value = ngx.is_subrequest是否是子请求
（请求转发）
ngx.exec(uri, args?)：内部转发请求到uri 和args（lua string 或乱table）
等价于rewrite regrex replacement last;
请求URI处理
ngx.req.set_uri(uri, jump?)：改写请求uri，并根据jump的boolean值决定是否跳转
jump为true，等价于rewrite...last 改写uri，并重新匹配location
jump为false，等价于rewrite...break
三者的区别：
is_internal =ngx.req.is_internal()判断当前请求是否是内部请求 返回boolean
内部请求定义： 从当前nginx服务器内部发出而不是从客户端启动的请求。（子请求都是内部请求）//并非是请求当前服务器内部
（请求重定向）重定向到uri
ngx.redirect(uri, status?)：客户端以修改的uri重发一起请求
转发与重定向的区别
转发：浏览器URL的地址栏不变。重定向：浏览器URL的地址栏改变
转发是服务器行为，重定向是客户端行为
转发是浏览器只做了一次访问请求。重定向是浏览器做了至少两次的访问请求；
转发2次跳转之间传输的信息不会丢失，重定向2次跳转之间传输的信息会丢失
请求和响应头处理
ngx.header.HEADER = VALUE设置响应头的参数
value = ngx.header.HEADER获得请求头的参数
headers, err =ngx.resp.get_headers(max_headers?, raw?)
返回当前请求的响应头 lua table
headers, err =ngx.req.get_headers(max_headers?, raw?)*
返回当前请求头 lua table
ngx.req.set_header(header_name, header_value)：设置当前请求的请求头
ngx.req.clear_header(header_name)：清理header_name的请求头内容（删除该请求头的信息）
str = ngx.req.raw_header(no_request_line?)string形式服务器接收到的原始请求头 （默认包含请求行）
请求方法处理
method_name = ngx.req.get_method()： 返回请求方法 （请求方法常量）
ngx.req.set_method(method_id)：改写当前请求的请求方法
请求参数处理（或请求体）：有些格式不对，需要读取请求体
ngx.req.set_uri_args(args) :改写请求参数 参数可以使lua string 或者lua table
args, err = ngx.req.get_uri_args(max_args?) :获取请求参数 lua table存
请求体：某种格式的请求数据
nginx核心本身不会主动读取请求体
请求体的读取一般发生在nginx的content handler中
读取body到内存是第一步(对于lua来说两种方式)
1.ngx.req.read_body()：没有返回 只是读取body到内存
2.lua_need_request_body：是一个指令 将请求的body读入$request_body变量中
从Nginx中读到Lua是第二部
需要配合ngx.req.get_post_args使用
data = ngx.req.get_body_data()返回lua string形式的请求体 vs ngx.req.get_post_args（从内存中将body读取到lua中使用时第二步）
args, err = ngx.req.get_post_args(max_args?)***获取post请求的参数table形式存
ngx.req.set_body_data(data) 修改请求体内容
file_name = ngx.req.get_body_file() 读到文件中 利用lua io
ngx.req.set_body_file(file_name, auto_clean?)通过文件形式写入body*
销毁body
ngx.req.discard_body()读取并丢弃请求体 如果请求体已经被读取，则立即返回不做任何处理
新建body(下述3个共同使用)
ngx.req.init_body(buffer_size?)为当前请求新建一个空的body并初始化大小
写入：body
ngx.req.append_body(data_chunk)：Append new data chunk specified by the data_chunk *argument onto the existing request body created by thengx.req.init_bodycall.
完成写入
ngx.req.finish_body()
