【Nginx系列】Nginx配置使用与工作原理

热门系列:


目录

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_busy_buffers_size是用来控制同时传输到客户 端的buffer数量的

 

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;

#启动TCP_NODELAY,就意味着禁用了Nagle算法,允许小包的发送。对于延时敏感型,同时数据传输量比较小的应用,开启TCP_NODELAY选项无疑是一个正确的选择。

 

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;

}

3、ip_hash

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

例如:

upstream bakend {

ip_hash;

server 192.168.0.14:88;

server 192.168.0.15:80;

}

4、fair(第三方)

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

upstream backend {

server server1;

server server2;

fair;

}

5、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的数量。

 

本博客皆为学习、分享、探讨为本,欢迎各位朋友评论、点赞、收藏、关注,一起加油!

 

善良勤劳勇敢而又聪明的老杨 CSDN认证博客专家 Java Spring Mysql
一个喜欢学习,热爱分享的Java技术人!年轻人,要坚持学习,耗子尾汁!
微信搜索关注时代名猿,免费领取VIP精品学习视频、BAT大厂面试资料、IT技术电子书籍
已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 博客之星2020 设计师:CY__ 返回首页