简介

静态Web服务器的主要功能由ngx_http_core_module。

所有Http配置项都必须直属http块、server块、location块、upstream块等,所以HTTP配置项都必须包含与http块内。

虚拟机的请求分发

由于IP地址数量有限,因此经常存在多个主机域名对应同一IP地址的情况,这时在nginx.conf中可以按照server_name并通过server块来定义虚拟主机,每个server块就是一个虚拟主机,它只处理与之相对应的主机域名请求,这样一台服务器上的Nginx就能以不同的方式处理访问不同主机域名的http请求了。

配置项
listen

语法:isten address:port[default_server][backlog=num][ssl]
默认:listen 80;
上下文:server

listen参数决定Nginx服务如何监听端口。 在listen后可以只加IP地址、 端口或主机名, 非常灵活。

listen 127.0.0.1:8000;
listen 127.0.0.1; #注意: 不加端口时, 默认监听80端口
listen 8000;
listen *:8000;
listen localhost:8000;

listen 443 default_server ssl backlog=1024;

一些参数:

  • default_server :标志当前server作为整个Web服务的默认server,当一个请求无法匹配到配置文件中给的所有主机域名时,就会使用默认的虚拟主机。当不设置时,使用配置文件配置的第一个server块作为默认主机。

  • backlog:表示设置TCP backlog队列的大小,默认-1,表示不设置,用于存放没来得及处理的TCP连接,如果队列满了,新TCP连接直接返回连接失败。

  • ssl:在当前监听的端口上建立连接必须基于SSL协议。

server_name

语法:server_name name1[name2…]
默认:""
上下文:server

server_name后可以跟多个主机名称, 如server_name www.testweb.com 、download.testweb.com;。

在开始处理一个HTTP请求时, Nginx会取出header头中的Host, 与每个server中的
server_name进行匹配, 以此决定到底由哪一个server块来处理这个请求。 有可能一个Host与
多个server块中的server_name都匹配, 这时就会根据匹配优先级来选择实际处理的server块。

优先级:

  1. 首先选择所以字符串完全匹配的server_name,如www.testweb.com
  2. 其次选择通配符在前面的server_name,如*.testweb.com
  3. 再次匹配通配符在后面的server_name,如www.testweb.*
  4. 最后使用正则表达式匹配,如~^.testweb.com$。
  5. 如果请求没有Host请求头,则匹配 server_name ""的server。

如果匹配不上,就使用默认的server。

server_names_hash_bucket_size

语法:server_names_hash_bucket_size size;
默认:server_names_hash_bucket_size 32|64|128;
上下文: http、server、location

为了提高快速寻找到相应server name的能力, Nginx使用散列表来存储server name。
server_names_hash_bucket_size设置了每个散列桶占用的内存大小。

server_names_hash_max_size

语法:server_names_hash_max_size size;
默认:server_names_hash_max_size 512;
上下文: http、server、location

server_names_hash_max_size会影响散列表的冲突率。 server_names_hash_max_size越大,
消耗的内存就越多, 但散列key的冲突率则会降低, 检索速度也更快,server_names_hash_max_size越小, 消耗的内存就越小, 但散列key的冲突率可能增高。

location

语法:location[=||*|^~|@]/uri/{…}
默认:-----
上下文:server

location会尝试根据用户请求中的URI来匹配上面的/uri表达式, 如果可以匹配, 就选择
location{}块中的配置来处理用户请求。 当然, 匹配方式是多样的, 下面介绍location的匹配
规则。

root

语法:root path;
默认:root html;
上下文:http、server、location

作用:定义资源的根目录。

比如:
location /download/{
root webhtml;
}

如果一个请求的uri是 /download/index/test.html的话,那么nginx服务器会返回webhtml/download/index/test.html文件给客户端。

index

语法:index file1[file2…]
默认:index index.html
上下文:http、server、location

有时, 访问站点时的URI是/, 这时一般是返回网站的首页, 而这与root不同。这里用ngx_http_index_module模块提供的index配置实现。 index后可以跟多个文件参数, Nginx
将会按照顺序来访问这些文件, 例如:

location /{
	root path;
	index index.html index.htm;

}

接收到请求后, Nginx首先会尝试访问path/index.html文件, 如果可以访问, 就直接返回文
件内容结束请求, 否则再试图返回path/index.htm文件的内容, 依此类推。

error_page

语法:error_page code1[code2…] URL/URI
默认:-----
上下文:http、server、location

当对于某个请求返回错误码时, 如果匹配上了error_page中设置的code, 则重定向到新
的URI中。例如:

error_page 500 502 503 50x.html;

当请求返回状态码为500 502 503 时,就重定向到50x.html资源。

内存及磁盘资源的分配

介绍处理请求时内存、 磁盘资源分配的配置项。

配置项
client_body_on_file_only

语法:client_body_on_file_only on|off|clean
默认:client_body_on_file_only off
上下文:http、server、location

设置为on时,用户请求的http body一律保存在磁盘文件中,即使body为0字节。并且请求结束时文件也不会被删除。
当设置为clean时,用户请求的http body一律保存在磁盘文件中,即使body为0字节。并且请求结束时文件会被删除。
当设置为off时,不会报错在磁盘文件中。

client_body_in_single_buffer

语法:client_body_in_single_buffer on|off
默认:client_body_in_single_buffer off
上下文:http、server、location

如果设置为on,用户请求中的HTTP包体一律存储到内存buffer中。 当然, 如果HTTP包体的大小超过了下面client_body_buffer_size设置的值, 包体还是会写入到磁盘文件中。这个配置是请求级别的。

client_body_buffer_size

语法:client_body_buffer_sizesize;
默认:client_body_buffer_size 8k/16k;
上下文:http、server、location

上面配置项定义了Nginx接收HTTP包体的内存缓冲区大小。 也就是说, HTTP包体会先
接收到指定的这块缓存中, 之后才决定是否写入磁盘。

如果用户请求中含有HTTP头部Content-Length, 并且其标识的长度小于定义的buffer大小, 那么Nginx会自动降低本次请求所使用的内存buffer, 以降低内存消耗。这个配置是请求级别的,也就是每个请求一个client_body_buffer_size。

client_body_temp_path

语法 :client_body_temp_path dir-path[level1[level2[level3]]]
默认:client_body_temp_path client_body_temp;
上下文:http、server、location

配置项定义HTTP包体存放的临时目录。 在接收HTTP包体时, 如果包体的大小大于
client_body_buffer_size, 则会以一个递增的整数命名并存放到client_body_temp_path指定的目
录中。

后面跟着的level1、 level2、 level3, 是为了防止一个目录下的文件数量太多, 从而导
致性能下降, 因此使用了level参数, 这样可以按照临时文件名最多再加三层目录。

例如:

client_body_temp_path optnginx/client_temp 1 2;

如果新上传的HTTP包体使用00000123456作为临时文件名, 就会被存放在optnginx/client_temp/6/45/00000123456

client_header_buffer_size

语法:client_header_buffer_size size;
默认:client_header_buffer_size 1k;
上下文:http、server

上面配置项定义了正常情况下Nginx接收用户请求中HTTP header部分(包括HTTP行和
HTTP头部) 时分配的内存buffer大小。 有时, 请求中的HTTP header部分可能会超过这个大
小, 这时large_client_header_buffers定义的buffer将会生效。

large_client_header_buffers

语法:large_client_header_buffers number size;
默认:large_client_header_buffers 1 48k;
上下文:http、server

large_client_header_buffers定义了Nginx接收一个超大HTTP头部请求的buffer个数和每个
buffer的大小。 如果HTTP请求行(如GET/index HTTP/1.1) 的大小超过上面的单个buffer, 则
返回"Request URI too large"(414)。 请求中一般会有许多header, 每一个header的大小也不能超
过单个buffer的大小, 否则会返回"Bad request"(400)。 当然, 请求行和请求头部的总和也不可
以超过buffer个数*buffer大小。

网络连接设置

介绍网络连接的设置配置项。

配置项
client_header_timeout

语法:client_header_timeout time 默认单位秒
默认:client_header_timeout 60
上下文:http、server、location

客户端与服务器建立连接后将开始接收HTTP头部, 在这个过程中, 如果在一个时间间
隔(超时时间) 内没有读取到客户端发来的字节, 则认为超时, 并向客户端返回
408(“Request timed out”)响应。

client_body_timeout

语法:client_body_timeout time 默认单位秒
默认:client_body_timeout 60
上下文:http、server、location

客户端与服务器建立连接后将开始接收HTTP包体, 在这个过程中, 如果在一个时间间
隔(超时时间) 内没有读取到客户端发来的字节, 则认为超时, 并向客户端返回
408(“Request timed out”)响应。

send_timeout

语法:send_timeout time 默认单位秒
默认:send_timeout 60
上下文:http、server、location

这个超时时间是发送响应的超时时间, 即Nginx服务器向客户端发送了数据包, 但客户
端一直没有去接收这个数据包。 如果某个连接超过send_timeout定义的超时时间, 那么Nginx
将会关闭这个连接。

keepalive_disable

语法:keepalive_disable [msie6|safari|none]…
默认:keepalive_disable msie6 safari
上下文:http、server、location

HTTP请求中的keepalive功能是为了让多个请求复用一个HTTP长连接, 这个功能对服务
器的性能提高是很有帮助的。 但有些浏览器, 如IE 6和Safari, 它们对于使用keepalive功能的
POST请求处理有功能性问题。 因此, 针对IE 6及其早期版本、 Safari浏览器默认是禁用Keepalive功能。

keepalive_timeout

语法:send_timeout time 默认单位秒
默认:send_timeout 75
上下文:http、server、location

一个keepalive连接在闲置超过一定时间后(默认的是75秒) , 服务器和浏览器都会去关
闭这个连接。 当然, keepalive_timeout配置项是用来约束Nginx服务器的, Nginx也会按照规范
把这个时间传给浏览器, 但每个浏览器对待keepalive的策略有可能是不同的。

keepalive_requests

语法:keepalive_requests n
默认:keepalive_requests 100
上下文:http、server、location

设置一个keepalive长连接上允许同时承载的请求最大数,默认100.

tcp_nodelay

语法:tcp_nodelay on|off
默认:tcp_nodelay on
上下文:http、server、location

确定对keepalive连接是否使用TCP_NODELAY选项。如果开启,这代表数据包不延迟,如果关闭,则代表数据包延时,会把多个数据包合成一个,等待到一个阈值才进行发送,共用传输层的头部信息,节省带宽,但是会延时。

lingering_close

语法: lingering_close off|on|always;
默认: lingering_close on;
上下文: http、 server、 location

该配置控制Nginx关闭用户连接的方式。 always表示关闭用户连接前必须无条件地处理连
接上所有用户发送的数据。 off表示关闭连接时完全不管连接上是否已经有准备就绪的来自用
户的数据,直接关闭。 on是中间值, 一般情况下在关闭连接前都会处理连接上的用户发送的数据, 除了有些情况下在业务上认定这之后的数据是不必要的。

lingering_time

语法: lingering_time time;
默认: lingering_time 30s;
上下文: http、 server、 location

lingering_close启用后, 这个配置项对于上传大文件很有用。 当用户请求的
Content-Length大于max_client_body_size配置时, Nginx服务会立刻向用户发送413(Request
entity too large) 响应。 但是, 很多客户端可能不管413返回值, 仍然持续不断地上传HTTP
body, 这时, 经过了lingering_time设置的时间后, Nginx将不管用户是否仍在上传, 都会把连
接关闭掉。也就是连接发起关闭请求时,经过lingering_time时间后,不管请求是否处理完成都关闭连接。

lingering_timeout

语法: lingering_timeout time;
默认: lingering_timeout 5s;
配置块: http、 server、 location

lingering_close生效后, 在关闭连接前, 会检测是否有用户发送的数据到达服务器, 如果
超过lingering_timeout时间后还没有数据可读, 就直接关闭连接; 否则, 必须在读取完连接缓
冲区上的数据并丢弃掉后才会关闭连接。

MIME类型的配置

MIME type与文件扩展的映射

配置
types

语法:types {…}
默认:无
上下文:http、server、location

作用:定义MIME Type到文件扩展名的映射,多个扩展名可以映射到同一个MIME Type。

例子:

types{
	text/html html;
	text/html conf;
	image/gif gif;
}
default_type

语法:default_type MIME Type
默认:default_type text/plain
上下文:http、server、location

作用:设置默认MIME Type,当找不到相应的MINE Type与文件扩展名直接的映射时,使用默认的MIME Type作为HTTP 头的Content-Type。

limit_except

语法:limit_except method{…}
默认:无
上下文:location

作用:Nginx通过limit_except后面指定的方法名来限制用户请求。 方法名可取值包括: GET、
HEAD、 POST、 PUT、 DELETE、 MKCOL、 COPY、 MOVE、 OPTIONS、 PROPFIND、
PROPPATCH、 LOCK、 UNLOCK或者PATCH。

例子:

limit_except GET{
	allow 192.168.1.0/32;
	deny all;
}

配置的是允许192.168.1.0/32段的客户端GET请求,然后拒绝其他所有IP的客户端的GET请求。

注意:允许GET方法就意味着也允许HEAD方法。 因此, 上面这段代码表示的是禁止
GET方法和HEAD方法, 但其他HTTP方法是允许的。

client_max_body_size

语法:client_max_body_size size
默认:client_max_body_size 1m
上下文:http、server、location

浏览器在发送含有较大HTTP包体的请求时, 其头部会有一个Content-Length字段,
client_max_body_size是用来限制Content-Length所示值的大小的。 因此, 这个限制包体的配置
非常有用处, 因为不用等Nginx接收完所有的HTTP包体——这有可能消耗很长时间——就可
以告诉用户请求过大不被接受。例如, 用户试图上传一个10GB的文件, Nginx在收完包头
后, 发现Content-Length超过client_max_body_size定义的值, 就直接发送413(“Request EntityToo Large”)响应给客户端

limit_rate

语法:limit_rate speed
默认:limit_rate 0
上下文:http、server、location、if块

此配置是对客户端请求限制每秒传输的字节数。 可以使用k m 单位。

针对不同的客户端, 可以用$limit_rate参数执行不同的限速策略。 例如:

server{
	if($slow){
		set $limit_rate 4k;
	}
}
limit_rate_after

语法:limit_rate_after time
默认:limit_rate_after 1m 一分钟
上下文:http、server、location、if块

此配置表示nginx向客户端发送响应时间超过limit_rate_after 之后才开始限速。

文件操作优化
配置
sendfile

语法:sendfile on|off
默认:sendfile off
上下文:http、server、location

可以启用Linux上的sendfile系统调用来发送文件, 它减少了内核态与用户态之间的两次
内存复制, 这样就会从磁盘中读取文件后直接在内核态发送到网卡设备, 提高了发送文件的
效率。(零拷贝)。

日志相关

对访问日志的一些配置,这个功能是由ngx_http_log_module模块提供。

配置
access_log

语法:access_log path [format [buffer=size] [gzip[=level]] [flush=time] ];
默认: access_log logs/access.log combined;
上下文:http, server, location, if in location, limit_except

作用:访问日志的配置。

参数讲解:
path:访问日志的文件路径。
format:格式化配置的名称(下面会讲)。
gzip:日志文件压缩的等级。
buffer:日志记录的内存缓冲区大小。
flush=time:把日志重缓冲区刷到磁盘的时间间隔。

log_format

语法: log_format name string …;
默认: log_format combined “…”;
上下文: http

作用:配置访问日志的日志格式。
参数讲解:
name:日志格式配置名称,用于上面的access_log 的format 参数引用。
string: 格式描述。可以使用模块内置变量。

例子:

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                     '$status $body_bytes_sent "$http_referer" '
                     '"$http_user_agent" "$http_x_forwarded_for"';

access_log  logs/access.log  main buffer=10m gzip=5 flush=5m;

表示使用main配置的格式,日志文件记录在access.log文件上,缓冲区大小为10m,每隔5分钟刷盘一次,文件压缩等级为5;

在记录access_log访问日志文件时, 可以使用ngx_http_core_module模块处理请求时所产
生的丰富的变量, 当然, 这些变量还可以用于其他HTTP模块。

变量表:
https://www.cnblogs.com/losbyday/p/5839673.html

Logo

华为开发者空间,是为全球开发者打造的专属开发空间,汇聚了华为优质开发资源及工具,致力于让每一位开发者拥有一台云主机,基于华为根生态开发、创新。

更多推荐