Nginx模块开发与架构解析

本篇内容主要讲解“Nginx模块开发与架构解析”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Nginx模块开发与架构解析”吧!

一、研究Nginx前的准备工作

1.Nginx特点：更快、高扩展性、高可靠性、低内存消耗、单机支持10万以上的并发连接、热部署、最自由的BSD许可协议

2.退出nginx

• nginx -s stop

• nginx -s quit

3.日志回滚：nginx -s reopen

二、Nginx的配置

A.运行中的Nginx进程间的关系

1. 一般情况下，worker进程的数量与服务器上的CPU数量相等

B.Nginx服务的基本配置

1.用于调试进程和定位问题的配置项

• daemon on | off;：是否以守护进程方式运行Nginx，默认on

• master_process on | off;：是否以master/worker方式工作，默认on

• error_log pathfile level;：error日志的设置

• debug_points [stop|abort]：帮助用户跟踪调试nginx，一般不用

• debug_connection [IP | CIDR]：仅对指定的客户端输出debug级别的日志，对定位高并发请求下发生的问题有用，需要configure时加入参数--with-debug

• worker_rlimit_core size;：限制coredump核心转储文件的大小

• working_directory path;：指定coredump文件生成的目录

2.正常运行的配置项

• evn VAR|VAR=VALUE：让用户直接设置操作系统上的环境变量

• include pathfile;：嵌入其他配置文件

• pid path/file;pid文件的路径

• user username [groupname];：Nginx worker进程运行的用户及用户组

• worker_rlimit_nofile limit;：指定Nginx worker进程可以打开的最大句柄描述符个数

• worker_rlimit_sigpending limit;：限制信号队列

3.优化性能的配置

• worker_processes number;：定义worker进程的个数

• worder_cpu_affinity cpumask [cpumask...];：绑定worker进程到指定的CPU内核

• ssl_engine device;：SSL硬件加速

• timer_resolution t;：系统调用gettimeofday的执行频率

• worker_priority nice;：worker进程优先级设置

4.事件类配置项

• accept_mutex [on | off];：是否打开accept锁，可以让多个worker进程轮流地、序列化地与新的客户端建立TCP连接

• lock_file path/file;：lock文件的路径

• accept_mutex_delay ms;：使用accept锁后到真正建立连接之间的延迟时间

• multi_accept on | off;：批量建立新连接

• use [kqueue|rtsig|epoll|/dev/poll|select|poll|eventport];：选择事件模型

• worker_connections number;：每个worker的最大连接数

C.用HTTP核心模块配置一个静态Web服务器

1.虚拟主机与请求的分发

• listen address:port[default|default_server|[backlog=num|rcvbuf=size|sndbuf=size|accept_filter=filter|deferred|bind|ipv6only=[on|off]|ssl]];：监听端口，配置在server块

• server_name name[...];：主机名称，配置在server块

• server_names_hash_bucket_size size;：设置每个散列表占用的内存大小，nginx使用散列表来存储server_name

• server_names_hash_max_size size;：影响散列表的冲突率，越大消耗的内存越多，但散列key的冲突则会降低，检索速度也快

• server_name_in_redirect on|off;：重定向主机名称的处理

• location [=|~|~*|^~|@]/uri/{...}：根据请求的URI来匹配进入location{}块中的配置来处理用户请求，配置在server块

2.文件路径的定义

• root path;：以root方式设置资源路径

• alias path;：别名，将uri映射到真实的磁盘文件上，只能在location块中

• index file ...;：访问首页

• error_page code[code...][=|=answer-code]uri|@named_location：根据HTTP返回码重定向页面

• recursive_error_pages [on|off];：是否允许递归使用error_page

• try_files path2[path3]uri;：尝试按照顺序访问每一个path

3.内存及磁盘资源的分配

• client_body_in_file_only on|clean|off;：HTTP包体只存储到磁盘文件中

• client_body_in_single_buffer on|off;：HTTP包体尽量写入到一个内存buffer中

• client_header_buffer_size size;：存储HTTP头部的内存buffer大小

• large_client_header_buffers number size;：定义了Nginx接收一个超大HTTP头部请求的buffer个数和每个buffer的大小

• client_body_buffer_size size;：存储HTTP包体的内存buffer大小

• client_body_temp_path dir-path[level1[level2[level3]]];：HTTP包体的临时存放目录

• connection_pool_size size;：Nginx对于每个建立成功的TCP连接会预先分配一个内存池，这个配置将指定个内存池的初始大小，用于减少内核对于小块内存的分配次数

• request_pool_size size;：Nginx会为每个请求分配一个内存池，配置将指定这个内存池的初始大小

4.网络连接的设置

• client_header_timeout time：读取HTTP头部的超时时间

• client_body_timeout time：读取HTTP包体的超时时间

• send_timeout time;：发送响应的超时时间

• reset_timeout_connection on|off;：连接超时后将通过向客户端发送RST包来直接重置连接，这个选项打开后，Nginx将直接向用户发送RST重置包，不再等待用户应答，直接释放缓存

• lingering_close off|on|always;：控制Nginx关闭用户连接的方式

• lingering_time time;：对上传大文件很有用，当超过时间后，不管是否仍在上传，都会关闭连接

• ligering_timeout time;：在lingering_close生效后，在关闭连接前，会检测是否有用户发送的数据到达服务器，如果超过时间后还没有数据可读，就直接关闭连接

• keepalive_disable [msie6|safari|none]...：对某些浏览器禁用keepalive功能

• keepalive_timeout time time：keepalive超时时间

• keepalive_requests n;：一个keepalive长连接上允许承载的请求最大数

• tcp_nodelay on|off;：确定对keepalive连接是否使用TCP_NODELAY选项

• tcp_nopush on|off;：在打开sendfile选项时，确定是否开启FreeBSD系统上的TCP_NOPUSH或Linux系统上的TCP_CORK功能

5.MIME类型的设置

• type{...};：MIME type与文件扩展的映射

• default_type MIME-type;：默认MIME type

• types_hash_bucket_size size;：设置散列表占用的内存大小

• types_hash_max_size size;：影响散列表的冲突率

6.对客户端请求的限制

• limit_except method...{...}：按HTTP方法名限制用户请求

• client_max_body_size size;：HTTP请求包体的最大值

• limit_rate speed;：对客户端请求限制每秒传输的字节数

• limit_rate_after time;：表示nginx向客户端发磅的响应长度超过limit_rate_after后才开始限速

7.文件操作的优化

• sendfile on|off;：启用sendfile系统调用来发送文件

• aio on|off;：表示是否在FreeBSD或Linux系统上启用内核级别的异步I/O功能，与sendfile是互斥的

• directio size|off;：在FreeBSD和Linux系统上使用O_DIRECT选项去读取文件，与sendfile互斥

• directio_alignment size;：与directio配合，指定directio方式读取文件时的对齐方式

• open_file_cache max=N[inactive=time]|off;：打开文件缓存

• open_file_cache_errors on|off;：是否缓存打开文件错误的信息

• open_file_cache_min_uses number;：不被淘汰的最小访问次数，与open_file_cache的inactive配合使用，如果超过了，则不会被淘汰出缓存

• open_file_cache_valid time;：检验缓存中元素有效性的频率

8.对客户端请求的特殊处理

• ignore_invalid_headers on|off;：忽略不合法的HTTP头部

• underscores_in_headers on|off;：HTTP头部是否允许下划线

• if_modified_since [off|exact|before];：对If-Modified-Since头部的处理策略

• log_not_found on|off;：文件未找到时是否记录到error日志

• merge_slashes on|off;：是否合并相邻的/

• resolver address...;：废黜DNS名字解析服务器的地址

• resolver_timeout time;：DNS解析超时时间

• server_tokens on|off;：返回错误页面时是否在Server中注明Nginx版本

D.用HTTP proxy module配置一个反向代理服务器

1.负载均衡的基本配置

• upstream name {...}：定义了一个上游服务器的集群，便于反向代理中的proxy_pass使用，配置在http块

• server name [weight=number,max_fails=number,fail_timeout=time,down,backup]：指定一台上游服务器的名字，可以是域名、ip地址端口、UNIX句柄等，配置在upstream块中

• ip_hash;：根据客户IP地址将请求始终落在固定的一台上游服务器中，与weight配置不可同时使用

2.反向代理的基本配置

• proxy_pass URL;：将当前请求反向代理到URL参数指定的服务器上，URL可使用是域名、ip地址端口、UNIX句柄或upstream块，配置在location、if块中

• proxy_set_header Host $host;：转发请求中的Host头，默认proxy_pass不转发

• proxy_method method;：转发时的协议方法名

• proxy_hide_header the_header;：可以指定哪些HTTP头部字段不能被转发

• proxy_pass_header the_header;：与proxy_hide_header相反

• proxy_pass_request_body on|off;：确定是否向上游服务器发送HTTP包体部分

• proxy_pass_request_headers on|off;：确定是否转发HTTP头部

• proxy_redirect [default|off|redirect replacement];：当上游服务器返回重定向或刷新请求时，可以重设HTTP头部的location或refresh字段

• proxy_next_upstream [ errpo,timeout,invalid_header,http500,http_502,http503,http_504,http_404,off]：当一台上游服务器转发请求出现错误时，继续换一台处理这个请求

三、开发一个简单的HTTP模块

1.整型的封装：ngx_int_t、ngx_uint_t

2.字符串：ngx_str_t

3.链表容器：ngx_list_t

4.key/value对：ngx_table_elt_t

5.缓冲区：ngx_buf_t

6.与ngx_buf_t配合使用的链接结构：ngx_chain_t

四、配置、error日志和请求上下文

五、访问第三方服务

1.upstream可以保证在与第三方服务器交互时（包括三次握手建立TCP连接、发送请求、接收响应、四次握手关闭TCP连接等）不会阻塞Nginx进程处理其他请求

2.subrequest是分解复杂请求的一种设计模式，最终也是基于upstream实现的

3.当我们希望把第三方服务的内容几乎原封不动地返回给用户时，一般使用upstream方式，可以非常高效地透传HTTP；如果访问第三方服务只是为了获取某些信息，再依据这些信息来构造 响应并传送给客户，应该使用subrequest方式

到此，相信大家对“Nginx模块开发与架构解析”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！