前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >深入理解Nginx模块开发与架构解析

深入理解Nginx模块开发与架构解析

作者头像
硬核项目经理
发布2019-08-06 15:25:30
5780
发布2019-08-06 15:25:30
举报

一、研究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 path1[path2]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方式

六、开发一个简单的HTTP过滤模块

七、Nginx提供的高级数据结构

八、Nginx基础架构

九、事件模块

十、HTTP框架的初始化

十一、HTTP框架的执行流程

十二、upstream机制的设计与实现

十三、邮件代理模块

十四、进程间的通信机制

十五、变量

十六、slab共享内存

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-01-06,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 码农老张 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
负载均衡
负载均衡(Cloud Load Balancer,CLB)提供安全快捷的流量分发服务,访问流量经由 CLB 可以自动分配到云中的多台后端服务器上,扩展系统的服务能力并消除单点故障。负载均衡支持亿级连接和千万级并发,可轻松应对大流量访问,满足业务需求。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档