目录

1.Nginx介绍

   1.1 什么是Nginx

   1.2 Nginx能做什么

   1.3 为什么要选择用Nginx

2.Nginx的安装与配置

   2.1 Nginx 安装

   2.2 Nginx配置

   2.3 Nginx常用操作

3.Nginx工作原理

   3.1 工作原理：

      3.1.1 Nginx处理Request请求过程解析

      3.1.2 一个完整的Request请求流程

   3.2 keepalive 长连接

1.Nginx介绍

1.1 什么是Nginx

Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务。

那么何为正向代理与反向代理呢？说白了，正向代理就是客户端的代理，反向代理就是服务器端的代理。

1.2 Nginx能做什么

• 作为 Web 服务器：相比 Apache，Nginx 使用更少的资源，支持更多的并发连接，体现更高的效率，这点使 Nginx 尤其受到虚拟主机提供商的欢迎。能够支持高达 50,000 个并发连接数的响应，感谢 Nginx 为我们选择了 epoll and kqueue 作为开发模型
• 作为负载均衡服务器：Nginx 既可以在内部直接支持 Rails 和 PHP，也可以支持作为 HTTP代理服务器 对外进行服务。Nginx 用 C 编写, 不论是系统资源开销还是 CPU 使用效率都比 Perlbal 要好的多。
• 作为邮件代理服务器：Nginx 同时也是一个非常优秀的邮件代理服务器（最早开发这个产品的目的之一也是作为邮件代理服务器），Last.fm 描述了成功并且美妙的使用经验。

1.3 为什么要选择用Nginx

• 作为Web服务器，Nginx处理静态文件、索引文件，自动索引的效率非常高
• 作为代理服务器，Nginx可以实现无缓存的反向代理加速，提高网站运行速度
• 作为负载均衡服务器，Nginx既可以在内部直接支持Rails和PHP，也可以支持HTTP代理服务器对外进行服务，同时还支持简单的容错和利用算法进行负载均衡
• 在性能方面，Nginx是专门为性能优化而开发的，实现上非常注重效率。它采用内核Poll模型，可以支持更多的并发连接，最大可以支持对5万个并发连接数的响应，而且只占用很低的内存资源
• 在稳定性方面，Nginx采取了分阶段资源分配技术，使得CPU与内存的占用率非常低。Nginx官方表示，Nginx保持1万个没有活动的连接，而这些连接只占用2.5MB内存，因此，类似DOS这样的攻击对Nginx来说基本上是没有任何作用的
• 在高可用性方面，Nginx支持热部署，启动速度特别迅速，因此可以在不间断服务的情况下，对软件版本或者配置进行升级，即使运行数月也无需重新启动，几乎可以做到7x24小时不间断地运行
• Nginx 安装非常的简单，配置文件 非常简洁（还能够支持perl语法），Bugs非常少的服务器: Nginx 启动特别容易，并且几乎可以做到7*24不间断运行，即使运行数个月也不需要重新启动

2.Nginx的安装与配置

2.1 Nginx 安装

系统平台：CentOS release 6.6 (Final) 64位。

一、安装编译工具及库文件

yum -y install make zlib zlib-devel gcc-c++ libtool  openssl openssl-devel

二、首先要安装 PCRE

PCRE 作用是让 Nginx 支持 Rewrite 功能。

1、下载 PCRE 安装包，下载地址： http://downloads.sourceforge.net/project/pcre/pcre/8.35/pcre-8.35.tar.gz

[root@bogon src]# wget http://downloads.sourceforge.net/project/pcre/pcre/8.35/pcre-8.35.tar.gz

2、解压安装包:

[root@bogon src]# tar zxvf pcre-8.35.tar.gz

3、进入安装包目录

[root@bogon src]# cd pcre-8.35

4、编译安装 

[root@bogon pcre-8.35]# ./configure [root@bogon pcre-8.35]# make && make install

5、查看pcre版本

[root@bogon pcre-8.35]# pcre-config --version

三、安装 Nginx

1、下载 Nginx，下载地址：http://nginx.org/download/nginx-1.6.2.tar.gz

[root@bogon src]# wget http://nginx.org/download/nginx-1.6.2.tar.gz

2、解压安装包

[root@bogon src]# tar zxvf nginx-1.6.2.tar.gz

3、进入安装包目录

[root@bogon src]# cd nginx-1.6.2

4、编译安装

[root@bogon nginx-1.6.2]# ./configure --prefix=/usr/local/webserver/nginx --with-http_stub_status_module --with-http_ssl_module --with-pcre=/usr/local/src/pcre-8.35 [root@bogon nginx-1.6.2]# make [root@bogon nginx-1.6.2]# make install

5、查看nginx版本

[root@bogon nginx-1.6.2]# /usr/local/webserver/nginx/sbin/nginx -v

到此，nginx安装完成。

2.2 Nginx配置

注：红色字体内容为配置说明

Nginx的配置文件nginx.conf配置详解如下：

 

user nginx nginx ;

#Nginx用户及组：用户 组。window下不指定

 

worker_processes 8;

#工作进程：数目。根据硬件调整，通常等于CPU数量或者2倍于CPU。

 

error_log  logs/error.log;  

error_log  logs/error.log  notice;  

error_log  logs/error.log  info;  

#错误日志：存放路径。

 

pid logs/nginx.pid;

#pid（进程标识符）：存放路径。

 

worker_rlimit_nofile 204800;

指定进程可以打开的最大描述符：数目。

这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文件数（ulimit -n）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimit -n 的值保持一致。

现在在Linux 2.6内核下开启文件打开数为65535，worker_rlimit_nofile就相应应该填写65535。

这是因为nginx调度时分配请求到进程并不是那么的均衡，所以假如填写10240，总并发量达到3-4万时就有进程可能超过10240了，这时会返回502错误。

 

events

{

use epoll;

#使用epoll的I/O 模型。linux建议epoll，FreeBSD建议采用kqueue，window下不指定。

补充说明:

与apache相类，nginx针对不同的操作系统，有不同的事件模型

A）标准事件模型

Select、poll属于标准事件模型，如果当前系统不存在更有效的方法，nginx会选择select或poll

B）高效事件模型

Kqueue：使用于FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X.使用双处理器的MacOS X系统使用kqueue可能会造成内核崩溃。

Epoll：使用于Linux内核2.6版本及以后的系统。

/dev/poll：使用于Solaris 7 11/99+，HP/UX 11.22+ (eventport)，IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。

Eventport：使用于Solaris 10。 为了防止出现内核崩溃的问题， 有必要安装安全补丁。

 

worker_connections 204800;

#每个工作进程的最大连接数量。根据硬件调整，和前面工作进程配合起来用，尽量大，但是别把cpu跑到100%就行。每个进程允许的最多连接数，理论上每台nginx服务器的最大连接数为。worker_processes*worker_connections

keepalive_timeout 60;

#keepalive超时时间。

 

client_header_buffer_size 4k;

#客户端请求头部的缓冲区大小。这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。

分页大小可以用命令getconf PAGESIZE 取得。

[root@web001 ~]# getconf PAGESIZE

4096

但也有client_header_buffer_size超过4k的情况，但是client_header_buffer_size该值必须设置为“系统分页大小”的整倍数。

 

open_file_cache max=65535 inactive=60s;

#这个将为打开文件指定缓存，默认是没有启用的，max指定缓存数量，建议和打开文件数一致，inactive是指经过多长时间文件没被请求后删除缓存。

 

open_file_cache_valid 80s;

#这个是指多长时间检查一次缓存的有效信息。

 

open_file_cache_min_uses 1;

#open_file_cache指令中的inactive参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive时间内一次没被使用，它将被移除。

}

 

 

##设定http服务器，利用它的反向代理功能提供负载均衡支持

http

{

include mime.types;

#设定mime类型,类型由mime.type文件定义

 

default_type application/octet-stream;

 

log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for"';

log_format log404 '$status [$time_local] $remote_addr $host$request_uri $sent_http_location';

#日志格式设置。

$remote_addr与$http_x_forwarded_for用以记录客户端的ip地址；

$remote_user：用来记录客户端用户名称；

$time_local： 用来记录访问时间与时区；

$request： 用来记录请求的url与http协议；

$status： 用来记录请求状态；成功是200，

$body_bytes_sent ：记录发送给客户端文件主体内容大小；

$http_referer：用来记录从那个页面链接访问过来的；

$http_user_agent：记录客户浏览器的相关信息；

通常web服务器放在反向代理的后面，这样就不能获取到客户的IP地址了，通过$remote_add拿到的IP地址是反向代理服务器的iP地址。反向代理服务器在转发请求的http头信息中，可以增加x_forwarded_for信息，用以记录原有客户端的IP地址和原来客户端的请求的服务器地址。

 

access_log  logs/host.access.log  main;

access_log  logs/host.access.404.log  log404;

#用了log_format指令设置了日志格式之后，需要用access_log指令指定日志文件的存放路径；

 

server_names_hash_bucket_size 128;

#保存服务器名字的hash表是由指令server_names_hash_max_size 和server_names_hash_bucket_size所控制的。参数hash bucket size总是等于hash表的大小，并且是一路处理器缓存大小的倍数。在减少了在内存中的存取次数后，使在处理器中加速查找hash表键值成为可能。如果hash bucket size等于一路处理器缓存的大小，那么在查找键的时候，最坏的情况下在内存中查找的次数为2。第一次是确定存储单元的地址，第二次是在存储单元中查找键 值。因此，如果Nginx给出需要增大hash max size 或 hash bucket size的提示，那么首要的是增大前一个参数的大小.

 

client_header_buffer_size 4k;

#客户端请求头部的缓冲区大小。这个可以根据你的系统分页大小来设置，一般一个请求的头部大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得。

 

large_client_header_buffers 8 128k;

#客户请求头缓冲大小。nginx默认会用client_header_buffer_size这个buffer来读取header值，如果

header过大，它会使用large_client_header_buffers来读取。

 

open_file_cache max=102400 inactive=20s;

#这个指令指定缓存是否启用。

例: open_file_cache max=1000 inactive=20s; 

open_file_cache_valid 30s; 

open_file_cache_min_uses 2; 

open_file_cache_errors on;

 

open_file_cache_errors

#语法:open_file_cache_errors on | off 默认值:open_file_cache_errors off 使用字段:http, server, location 这个指令指定是否在搜索一个文件是记录cache错误.

open_file_cache_min_uses

#语法:open_file_cache_min_uses number 默认值:open_file_cache_min_uses 1 使用字段:http, server, location 这个指令指定了在open_file_cache指令无效的参数中一定的时间范围内可以使用的最小文件数,如果使用更大的值,文件描述符在cache中总是打开状态.

open_file_cache_valid

#语法:open_file_cache_valid time 默认值:open_file_cache_valid 60 使用字段:http, server, location 这个指令指定了何时需要检查open_file_cache中缓存项目的有效信息.

 

 

client_max_body_size 300m;

#设定通过nginx上传文件的大小

 

sendfile on;

#sendfile指令指定 nginx 是否调用sendfile 函数（zero copy 方式）来输出文件，对于普通应用，必须设为on。如果用来进行下载等应用磁盘IO重负载应用，可设置为off，以平衡磁盘与网络IO处理速度，降低系统uptime。

 

tcp_nopush on;

#此选项允许或禁止使用socke的TCP_CORK的选项，此选项仅在使用sendfile的时候使用

 

proxy_connect_timeout 90; 

#后端服务器连接的超时时间_发起握手等候响应超时时间

 

proxy_read_timeout 180;

#连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间）

 

proxy_send_timeout 180;

#后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据

 

proxy_buffer_size 256k;

#设置从被代理服务器读取的第一部分应答的缓冲区大小，通常情况下这部分应答中包含一个小的应答头，默认情况下这个值的大小为指令proxy_buffers中指定的一个缓冲区的大小，不过可以将其设置为更小

 

proxy_buffers 4 256k;

#设置用于读取应答（来自被代理服务器）的缓冲区数目和大小，默认情况也为分页大小，根据操作系统的不同可能是4k或者8k

 

proxy_busy_buffers_size 256k;

 

proxy_temp_file_write_size 256k;

#设置在写入proxy_temp_path时数据的大小，预防一个工作进程在传递文件时阻塞太长

 

proxy_temp_path /data0/proxy_temp_dir;

#proxy_temp_path和proxy_cache_path指定的路径必须在同一分区

 

proxy_cache_path /data0/proxy_cache_dir levels=1:2 keys_zone=cache_one:200m inactive=1d max_size=30g;

#设置内存缓存空间大小为200MB，1天没有被访问的内容自动清除，硬盘缓存空间大小为30GB。

 

keepalive_timeout 120;

#keepalive超时时间。

 

tcp_nodelay on;

 

client_body_buffer_size 512k;

#如果把它设置为比较大的数值，例如256k，那么，无论使用firefox还是IE浏览器，来提交任意小于256k的图片，都很正常。如果注释该指令，使用默认的client_body_buffer_size设置，也就是操作系统页面大小的两倍，8k或者16k，问题就出现了。

无论使用firefox4.0还是IE8.0，提交一个比较大，200k左右的图片，都返回500 Internal Server Error错误

 

proxy_intercept_errors on;

#表示使nginx阻止HTTP应答代码为400或者更高的应答。

 

upstream bakend {

server 127.0.0.1:8027;

server 127.0.0.1:8028;

server 127.0.0.1:8029;

hash $request_uri;

}

#nginx的upstream目前支持4种方式的分配

1、轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

2、weight

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

例如：

upstream bakend {

server 192.168.0.14 weight=10;

server 192.168.0.15 weight=10;

}

2、ip_hash

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

例如：

upstream bakend {

ip_hash;

server 192.168.0.14:88;

server 192.168.0.15:80;

}

3、fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstream backend {

server server1;

server server2;

fair;

}

4、url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

例：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法

upstream backend {

server squid1:3128;

server squid2:3128;

hash $request_uri;

hash_method crc32;

}

tips:

upstream bakend{#定义负载均衡设备的Ip及设备状态}{

ip_hash;

server 127.0.0.1:9090 down;

server 127.0.0.1:8080 weight=2;

server 127.0.0.1:6060;

server 127.0.0.1:7070 backup;

}

在需要使用负载均衡的server中增加

proxy_pass http://bakend/;

每个设备的状态设置为:

1.down表示单前的server暂时不参与负载

2.weight为weight越大，负载的权重就越大。

3.max_fails：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream模块定义的错误

4.fail_timeout:max_fails次失败后，暂停的时间。

5.backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

nginx支持同时设置多组的负载均衡，用来给不用的server来使用。

client_body_in_file_only设置为On 可以讲client post过来的数据记录到文件中用来做debug

client_body_temp_path设置记录文件的目录 可以设置最多3层目录

location对URL进行匹配.可以进行重定向或者进行新的代理 负载均衡

 

 

##配置虚拟机

server

{

listen 80;

#配置监听端口

 

server_name image.***.com;

#配置访问域名

 

location ~* \.(mp3|exe)$ {

#对以“mp3或exe”结尾的地址进行负载均衡

 

proxy_pass http://img_relay$request_uri;

#设置被代理服务器的端口或套接字，以及URL

 

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

#以上三行，目的是将代理服务器收到的用户的信息传到真实服务器上

}

 

location /face {

if ($http_user_agent ~* "xnp") {

rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;

}

proxy_pass http://img_relay$request_uri;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

error_page 404 502 = @fetch;

}

location @fetch {

access_log /data/logs/face.log log404;

rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;

}

location /image {

if ($http_user_agent ~* "xnp") {

rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;

}

proxy_pass http://img_relay$request_uri;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

error_page 404 502 = @fetch;

}

location @fetch {

access_log /data/logs/image.log log404;

rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;

}

}

 

注释：变量

Ngx_http_core_module模块支持内置变量，他们的名字和apache的内置变量是一致的。

首先是说明客户请求title中的行，例如$http_user_agent,$http_cookie等等。

此外还有其它的一些变量

$args此变量与请求行中的参数相等

$content_length等于请求行的“Content_Length”的值。

$content_type等同与请求头部的”Content_Type”的值

$document_root等同于当前请求的root指令指定的值

$document_uri与$uri一样

$host与请求头部中“Host”行指定的值或是request到达的server的名字（没有Host行）一样

$limit_rate允许限制的连接速率

$request_method等同于request的method，通常是“GET”或“POST”

$remote_addr客户端ip

$remote_port客户端port

$remote_user等同于用户名，由ngx_http_auth_basic_module认证

$request_filename当前请求的文件的路径名，由root或alias和URI request组合而成

$request_body_file

$request_uri含有参数的完整的初始URI

$query_string与$args一样

$sheeme http模式（http,https）尽在要求是评估例如

Rewrite ^(.+)$ $sheme://example.com$; Redirect;

$server_protocol等同于request的协议，使用“HTTP/或“HTTP/

$server_addr request到达的server的ip，一般获得此变量的值的目的是进行系统调用。为了避免系统调用，有必要在listen指令中指明ip，并使用bind参数。

$server_name请求到达的服务器名

$server_port请求到达的服务器的端口号

$uri等同于当前request中的URI，可不同于初始值，例如内部重定向时或使用index

2.3 Nginx常用操作

常用到的命令如下：

• nginx -s stop ：快速关闭Nginx，可能不保存相关信息，并迅速终止web服务。

• nginx -s quit ：平稳关闭Nginx，保存相关信息，有安排的结束web服务。

• nginx -s reload ：因改变了Nginx相关配置，需要重新加载配置而重载。

• nginx -s reopen ：重新打开日志文件。

• nginx -c filename ：为 Nginx 指定一个配置文件，来代替缺省的。

• nginx -t ：不运行，而仅仅测试配置文件。nginx 将检查配置文件的语法的正确性，并尝试打开配置文件中所引用到的文件。

• nginx -v：显示 nginx 的版本。

• nginx -V：显示 nginx 的版本，编译器版本和配置参数。

• sudo service nginx status ：查看nginx运行状态

• sudo service nginx restart：重启

• pkill -9 nginx：杀掉nginx运行进程

3.Nginx工作原理

首先，我们通过一个内部结构流程图来熟悉一下Nginx的工作流程：

3.1 工作原理：

Nginx真正处理请求业务的是Worker之下的线程。worker 进程中，ngx_worker_process_cycle()函数就是这个无限循环的处理函数。在这个函数中，一个请求的简单处理流程如下：

1. 操作系统提供的机制（例如 epoll, kqueue 等）产生相关的事件。
2. 接收和处理这些事件，如是接收到数据，则产生更高层的 request 对象。
3. 处理 request 的 header 和 body。
4. 产生响应，并发送回客户端。
5. 完成 request 的处理。
6. 重新初始化定时器及其他事件。

3.1.1 Nginx处理Request请求过程解析

下面我们结合一个请求流程来理解一下Nginx整个过程当中做了哪些事。从 Nginx 的内部来看，一个 HTTP Request 的处理过程涉及到以下几个阶段：

1. 初始化 HTTP Request（读取来自客户端的数据，生成 HTTP Request 对象，该对象含有该请求所有的信息）。
2. 处理请求头。
3. 处理请求体。
4. 如果有的话，调用与此请求（URL 或者 Location）关联的 handler。
5. 依次调用各 phase handler 进行处理。

我们再通过一个流程图看看处理过程：

根据注释，我们可以看到：

• Nginx启动后，首先会根据配置与对应的客户端进行初始化连接。
• 而当一个Request进入后，先是对请求头及请求体进行解析和处理。
• 处理过程中，通过请求头找到对应的server config，然后与真实服务器进行连接并进行读写事件处理。
• 最后我们会看到有多个phase handler，就是包含若干个处理阶段的一些 handler。一个 phase handler 对这个 request 进行处理，并产生一些输出。通常 phase handler 是与定义在配置文件中的某个 location 相关联的。
• 一个通常会做一下处理：

1. 获取 location 配置。
2. 产生适当的响应。
3. 发送 response header。
4. 发送 response body。

3.1.2 一个完整的Request请求流程

3.2 keepalive 长连接

在nginx中，对于http1.0与http1.1也是支持长连接的。

什么是长连接呢？我们知道，http请求是基于TCP协议之上的，那么，当客户端在发起请求前，需要先与服务端建立TCP连接，而每一次的TCP连接是需要三次握手来确定的，如果客户端与服务端之间网络差一点，这三次交互消费的时间会比较多，而且三次交互也会带来网络流量。当然，当连接断开后，也会有四次的交互，当然对用户体验来说就不重要了。而http请求是请求应答式的，如果我们能知道每个请求头与响应体的长度，那么我们是可以在一个连接上面执行多个请求的，这就是所谓的长连接，但前提条件是我们先得确定请求头与响应体的长度。

对于请求来说，如果当前请求需要有body，如POST请求，那么nginx就需要客户端在请求头中指定content-length来表明body的大小，否则返回400错误。也就是说，请求体的长度是确定的，那么响应体的长度呢？先来看看http协议中关于响应body长度的确定：

对于http1.0协议来说，如果响应头中有content-length头，则以content-length的长度就可以知道body的长度了，客户端在接收body时，就可以依照这个长度来接收数据，接收完后，就表示这个请求完成了。而如果没有content-length头，则客户端会一直接收数据，直到服务端主动断开连接，才表示body接收完了。

而对于http1.1协议来说，如果响应头中的Transfer-encoding为chunked传输，则表示body是流式输出，body会被分成多个块，每块的开始会标识出当前块的长度，此时，body不需要通过长度来指定。如果是非chunked传输，而且有content-length，则按照content-length来接收数据。否则，如果是非chunked，并且没有content-length，则客户端接收数据，直到服务端主动断开连接。

从上面，我们可以看到，除了http1.0不带content-length以及http1.1非chunked不带content-length外，body的长度是可知的。此时，当服务端在输出完body之后，会可以考虑使用长连接。能否使用长连接，也是有条件限制的。如果客户端的请求头中的connection为close，则表示客户端需要关掉长连接，如果为keep-alive，则客户端需要打开长连接，如果客户端的请求中没有connection这个头，那么根据协议，如果是http1.0，则默认为close，如果是http1.1，则默认为keep-alive。如果结果为keepalive，那么，nginx在输出完响应体后，会设置当前连接的keepalive属性，然后等待客户端下一次请求。

当然，nginx不可能一直等待下去，如果客户端一直不发数据过来，岂不是一直占用这个连接？所以当nginx设置了keepalive等待下一次的请求时，同时也会设置一个最大等待时间，这个时间是通过选项keepalive_timeout来配置的，如果配置为0，则表示关掉keepalive，此时，http版本无论是1.1还是1.0，客户端的connection不管是close还是keepalive，都会强制为close。

如果服务端最后的决定是keepalive打开，那么在响应的http头里面，也会包含有connection头域，其值是”Keep-Alive”，否则就是”Close”。如果connection值为close，那么在nginx响应完数据后，会主动关掉连接。所以，对于请求量比较大的nginx来说，关掉keepalive最后会产生比较多的time-wait状态的socket。一般来说，当客户端的一次访问，需要多次访问同一个server时，打开keepalive的优势非常大，比如图片服务器，通常一个网页会包含很多个图片。打开keepalive也会大量减少time-wait的数量。

参考链接：

https://www.php.cn/nginx/421872.html

https://www.jianshu.com/p/6215e5d24553