详解Nginx中HTTP的keepalive相关配置

http keepalive
在http早期 ,每个http请求都要求打开一个tpc socket连接,并且使用一次之后就断开这个tcp连接。使用keep-alive可以改善这种状态,即在一次TCP连接中可以持续发送多份数据而不会 断开连接。通过使用keep-alive机制,可以减少tcp连接建立次数,也意味着可以减少TIME_WAIT状态连接,以此提高性能和提高httpd 服务器的吞吐率(更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用)。但是,keep-alive并不是 免费的午餐,长时间的tcp连接容易导致系统资源无效占用。配置不当的keep-alive,有时比重复利用连接带来的损失还更大。所以,正确地设置 keep-alive timeout时间非常重要。
keepalvie timeout
Httpd守护进程,一般都提供了keep-alive timeout时间设置参数。比如nginx的keepalive_timeout,和Apache的KeepAliveTimeout。这个 keepalive_timout时间值意味着:一个http产生的tcp连接在传送完最后一个响应后,还需要hold住 keepalive_timeout秒后,才开始关闭这个连接。当httpd守护进程发送完一个响应后,理应马上主动关闭相应的tcp连接,设置 keepalive_timeout后,httpd守护进程会想说:”再等等吧,看看浏览器还有没有请求过来”,这一等,便是 keepalive_timeout时间。如果守护进程在这个等待的时间里,一直没有收到浏览发过来http请求,则关闭这个http连接。
我写了一个脚本,方便测试

<?php
sleep(60); //为了便于分析测试,会根据测试进行调整
echo "www.jb51.net";
?>

1.当keepalive_timeout时间为0时,即不启用Keep-Alive时,一个tcp连接的生命周期

#tcpdump -n host 218.1.57.236 and port 80
20:36:50.792731 IP 218.1.57.236.43052 > 222.73.211.215.http: S 1520902589:1520902589(0) win 65535
20:36:50.792798 IP 222.73.211.215.http > 218.1.57.236.43052: S 290378256:290378256(0) ack 1520902590 win 5840
20:36:50.801629 IP 218.1.57.236.43052 > 222.73.211.215.http: . ack 1 win 3276820:36:50.801838 IP 218.1.57.236.43052 > 222.73.211.215.http: P 1:797(796) ack 1 win 32768
20:36:50.801843 IP 222.73.211.215.http > 218.1.57.236.43052: . ack 797 win 5920:37:50.803230 IP 222.73.211.215.http > 218.1.57.236.43052: P 1:287(286) ack 797 win 59
20:37:50.803289 IP 222.73.211.215.http > 218.1.57.236.43052: F 287:287(0) ack 797 win 59
20:37:50.893396 IP 218.1.57.236.43052 > 222.73.211.215.http: . ack 288 win 32625
20:37:50.894249 IP 218.1.57.236.43052 > 222.73.211.215.http: F 797:797(0) ack 288 win 32625
20:37:50.894252 IP 222.73.211.215.http > 218.1.57.236.43052: . ack 798 win 59

第1~3行建立tcp三次握手,建立连接。用时8898μs
第4~5行通过建立的连接发送第一个http请求,服务端确认收到请求。用时5μs
第5~6行,可以知道脚本执行用时60s1387μs,与php脚本相符。
第6、8行服务端发送http响应。发送响应用时90166μs。
第7行,表明由服务端守护进程主动关闭连接。结合第6、8行,说明http响应一旦发送完毕,服务端马上关闭这个tcp连接
第7、9、10说明tcp连接顺序关闭,用时90963μs。需要注意,这里socket资源并没有立即释放,需要等待2MSL时间(60s)后才被真正释放。
由此可见,在没有设置 keepalive_timeout情况下,一个socket资源从建立到真正释放需要经过的时间是:建立tcp连接 + 传送http请求 + php脚本执行 + 传送http响应 + 关闭tcp连接 + 2MSL 。(注:这里的时间只能做参考,具体的时间主要由网络带宽,和响应大小而定)
2.当keepalive_timeout时间大于0时,即启用Keep-Alive时,一个tcp连接的生命周期。为了便于分析,我们将keepalive_timeout设置为300s

#tcpdump -n host 218.1.57.236 and port 80
21:38:05.471129 IP 218.1.57.236.54049 > 222.73.211.215.http: S 1669618600:1669618600(0) win 65535
21:38:05.471140 IP 222.73.211.215.http > 218.1.57.236.54049: S 4166993862:4166993862(0) ack 1669618601 win 5840
21:38:05.481731 IP 218.1.57.236.54049 > 222.73.211.215.http: . ack 1 win 32768
21:38:05.481976 IP 218.1.57.236.54049 > 222.73.211.215.http: P 1:797(796) ack 1 win 32768
21:38:05.481985 IP 222.73.211.215.http > 218.1.57.236.54049: . ack 797 win 59
21:38:07.483626 IP 222.73.211.215.http > 218.1.57.236.54049: P 1:326(325) ack 797 win 59
21:38:07.747614 IP 218.1.57.236.54049 > 222.73.211.215.http: . ack 326 win 32605
21:43:07.448454 IP 222.73.211.215.http > 218.1.57.236.54049: F 326:326(0) ack 797 win 59
21:43:07.560316 IP 218.1.57.236.54049 > 222.73.211.215.http: . ack 327 win 32605
21:43:11.759102 IP 218.1.57.236.54049 > 222.73.211.215.http: F 797:797(0) ack 327 win 32605
21:43:11.759111 IP 222.73.211.215.http > 218.1.57.236.54049: . ack 798 win 59

我们先看一下,第6~8行,跟上次示例不一样的是,服务端httpd守护进程发完响应后,没有立即主动关闭tcp连接。
第8行,结合第6行,我们可以看到,5分钟(300s)后,服务端主动关闭这个tcp连接。这个时间,正是我们设置的keepalive_timeout的时间。
由此可见,设置了keepalive_timout时间情况下,一个socket建立到释放需要的时间是多了keepalive_timeout时间。
3.当keepalive_timeout时间大于0,并且在同一个tcp连接发送多个http响应。这里为了便于分析,我们将keepalive_timeout设置为180s
通过这个测试,我们想弄清楚,keepalive_timeout是从第一个响应结束开启计时,还是最后一个响应结束开启计时。测试结果证实是后者,这里,我们每隔120s发一次请求,通过一个tcp连接发送了3个请求。

# tcpdump -n host 218.1.57.236 and port 80
22:43:57.102448 IP 218.1.57.236.49955 > 222.73.211.215.http: S 4009392741:4009392741(0) win 65535
22:43:57.102527 IP 222.73.211.215.http > 218.1.57.236.49955: S 4036426778:4036426778(0) ack 4009392742 win 5840
22:43:57.111337 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 1 win 3276822:43:57.111522 IP 218.1.57.236.49955 > 222.73.211.215.http: P 1:797(796) ack 1 win 32768
22:43:57.111530 IP 222.73.211.215.http > 218.1.57.236.49955: . ack 797 win 59
22:43:59.114663 IP 222.73.211.215.http > 218.1.57.236.49955: P 1:326(325) ack 797 win 59
22:43:59.350143 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 326 win 3260522:45:59.226102 IP 218.1.57.236.49955 > 222.73.211.215.http: P 1593:2389(796) ack 650 win 32443
22:45:59.226109 IP 222.73.211.215.http > 218.1.57.236.49955: . ack 2389 win 83
22:46:01.227187 IP 222.73.211.215.http > 218.1.57.236.49955: P 650:974(324) ack 2389 win 83
22:46:01.450364 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 974 win 3228122:47:57.377707 IP 218.1.57.236.49955 > 222.73.211.215.http: P 3185:3981(796) ack 1298 win 32119
22:47:57.377714 IP 222.73.211.215.http > 218.1.57.236.49955: . ack 3981 win 108
22:47:59.379496 IP 222.73.211.215.http > 218.1.57.236.49955: P 1298:1622(324) ack 3981 win 108
22:47:59.628964 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 1622 win 3276822:50:59.358537 IP 222.73.211.215.http > 218.1.57.236.49955: F 1622:1622(0) ack 3981 win 108
22:50:59.367911 IP 218.1.57.236.49955 > 222.73.211.215.http: . ack 1623 win 32768
22:50:59.686527 IP 218.1.57.236.49955 > 222.73.211.215.http: F 3981:3981(0) ack 1623 win 32768
22:50:59.686531 IP 222.73.211.215.http > 218.1.57.236.49955: . ack 3982 win 108

第一组,三个ip包表示tcp三次握手建立连接,由浏览器建立。
第二组,发送第一次http请求并且得到响应,服务端守护进程输出响应之后,并没马上主动关闭tcp连接。而是启动keepalive_timout计时。
第三组,2分钟后,发送第二次http请求并且得到响应,同样服务端守护进程也没有马上主动关闭tcp连接,重新启动keepalive_timout计时。
第四组,又2分钟后,发送了第三次http请求并且得到响应。服务器守护进程依然没有主动关地闭tcp连接(距第一次http响应有4分钟了,大于keepalive_timeout值),而是重新启动了keepalive_timout计时。
第五组,跟最后一个响应keepalive_timeout(180s)内,守护进程再没有收到请求。计时结束,服务端守护进程主动关闭连接。4次挥手后,服务端进入TIME_WAIT状态。
这说明,当设定了keepalive_timeout,一个socket由建立到释放,需要时间是:tcp建立 + (最后一个响应时间 – 第一个请求时间) + tcp关闭 + 2MSL。红色加粗表示每一次请求发送时间、每一次请求脚本执行时间、每一次响应发送时间,还有两两请求相隔时间。进一步测试,正在关闭或者 TIME_WAIT状态的tcp连接,不能传输http请求和响应。即,当一个连接结束keepalive_timeout计时,服务端守护进程发送第一 个FIN标志ip包后,该连接不能再使用了。
http keep-alive与tcp keep-alive
http keep-alive与tcp keep-alive,不是同一回事,意图不一样。http keep-alive是为了让tcp活得更久一点,以便在同一个连接上传送多个http,提高socket的效率。而tcp keep-alive是TCP的一种检测TCP连接状况的保鲜机制。tcp keep-alive保鲜定时器,支持三个系统内核配置参数:

echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 15 > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes

keepalive是TCP保鲜定时器,当网络两端建立了TCP连接之后,闲置idle(双方没有任何数据流发送往来)了 tcp_keepalive_time后,服务器内核就会尝试向客户端发 送侦测包,来判断TCP连接状况(有可能客户端崩溃、强制关闭了应用、主机不可达等等)。如果没有收到对方的回答(ack包),则会在 tcp_keepalive_intvl后再次尝试发送侦测包,直到收到对对方的ack,如果一直没有收到对方的ack,一共会尝试 tcp_keepalive_probes次,每次的间隔时间在这里分别是15s, 30s, 45s, 60s, 75s。如果尝试tcp_keepalive_probes,依然没有收到对方的ack包,则会丢弃该TCP连接。TCP连接默认闲置时间是2小时,一般 设置为30分钟足够了。也就是说,仅当nginx的keepalive_timeout值设置高于tcp_keepalive_time,并且距此tcp连接传输的最后一 个http响应,经过了tcp_keepalive_time时间之后,操作系统才会发送侦测包来决定是否要丢弃这个TCP连接。一般不会出现这种情况, 除非你需要这样做。
keep-alive与TIME_WAIT
使用http keep-alvie,可以减少服务端TIME_WAIT数量(因为由服务端httpd守护进程主动关闭连接)。道理很简单,相较而言,启用keep-alive,建立的tcp连接更少了,自然要被关闭的tcp连接也相应更少了。
最后
我想用一张示意图片来说明使用启用keepalive的不同。另外,http keepalive是客户端浏览器与服务端httpd守护进程协作的结果,所以,我们另外安排篇幅介绍不同浏览器的各种情况对keepalive的利用。

时间: 2016-01-04

nginx/apache/php隐藏http头部版本信息的实现方法

1.nginx隐藏头部版本信息方法 编辑nginx.conf配置文件,在http{}内增加如下一行 复制代码 代码如下: http {      --      server_tokens off;      --     } 编辑php-fpm配置文件,fastcgi.conf或fcgi.conf 找到: 复制代码 代码如下: fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; 改为: 复制代码 代码如下: fastcgi_param SER

在网关中使用Nginx配置HTTP透明代理案例

出于某些需求在网关级架设 HTTP 透明代理,劫持用户 HTTP 请求,转发或直接进行响应. iptables配置 iptables 用于将经过网关的 TCP 80 端口的上行流量转发至网关上的 Nginx 服务. 复制代码 代码如下: sudo iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j DNAT \--to-destination 网关IP:端口 Nginx 演示配置 复制代码 代码如下: worker_processe

高性能WEB开发 nginx HTTP服务器篇

第一篇:HTTP服务器 因tomcat处理静态资源的速度比较慢,所以首先想到的就是把所有静态资源(JS,CSS,image,swf) 提到单独的服务器,用更加快速的HTTP服务器,这里选择了nginx了,nginx相比apache,更加轻量级, 配置更加简单,而且nginx不仅仅是高性能的HTTP服务器,还是高性能的反向代理服务器. 目前很多大型网站都使用了nginx,新浪.网易.QQ等都使用了nginx,说明nginx的稳定性和性能还是非常不错的. 1. nginx 安装(linux) htt

Nginx中使用gzip_http_version解决CDN只支持http 1.0问题

网站经过CDN后,看CSS文件的header发现 复制代码 代码如下: Transfer-Encoding: chunked google了许久,发现是CDN的抓取好像只支持http 1.0 而nginx的 gzip_http_version选项默认值为1.1 在nginx的配置文件中增加或修改gzip_http_version参数,为: 复制代码 代码如下: gzip_http_version 1.0 改完重启nginx 再看已经正常. 参考文档:http://wiki.nginx.org/N

Nginx HTTP:413 Request Entity Too Large解决方法

概述 今天遇到一个问题,在PHP程序中上传图片出现了以下错误:HTTP:413 Request Entity Too Large. 开发环境:CentOS + Nginx + PHP + MySql 解决方案 解决此问题,根据上传数据文件的大小,需要调节PHP和Nginx相关的参数配置. 配置PHP PHP默认上传文件大小限制为2M,如果超出2M你需要修改PHP配置文件php.ini里面的参数. 复制代码 代码如下: post_max_size = 8M (表单提交的最大限制,此项不是限制上传单

详解Nginx服务器中HTTP Headers相关的模块配置使用

ngx_http_headers_module模块 一. 前言 ngx_http_headers_module模块提供了两个重要的指令add_header和expires,来添加 "Expires" 和 "Cache-Control" 头字段,对响应头添加任何域字段.add_header可以用来标示请求访问到哪台服务器上,这个也可以通过nginx模块nginx-http-footer-filter研究使用来实现.expires指令用来对浏览器本地缓存的控制. 二.

详解Nginx服务器中配置全站HTTPS安全连接的方法

HTTPS就等于HTTP加上TLS(SSL),HTTPS协议的目标主要有三个: 数据保密性.保证内容在传输过程中不会被第三方查看到.就像快递员传递包裹时都进行了封装,别人无法知道里面装了什么东西.     数据完整性.及时发现被第三方篡改的传输内容.就像快递员虽然不知道包裹里装了什么东西,但他有可能中途掉包,数据完整性就是指如果被掉包,我们能轻松发现并拒收.     身份校验.保证数据到达用户期望的目的地.就像我们邮寄包裹时,虽然是一个封装好的未掉包的包裹,但必须确定这个包裹不会送错地方. 启用

Nginx实现根据域名http、https分发配置示例

tomcat端口:8080 做好虚拟主机 nginx端口:80 根据域名分派 在conf/nginx.conf中的http中增加 复制代码 代码如下: include www.jb51.net.conf 新建conf/www.jb51.net.conf,内容如下: 复制代码 代码如下: server { listen 80; server_name www.jb51.net; location / {     proxy_pass http://127.0.0.1:8080;     proxy

windows下nginxHTTP服务器入门教程初级篇

一.介绍Nginx是俄罗斯人编写的十分轻量级的HTTP服务器,Nginx,它的发音为"engine X", 是一个高性能的HTTP和反向代理服务器,同时也是一个IMAP/POP3/SMTP 代理服务器. 二.Location语法语法:location [=|~|~*|^~] /uri/ { - } 注: 1.~ 为区分大小写匹配 2.~* 为不区分大小写匹配 3.!~和!~*分别为区分大小写不匹配及不区分大小写不匹配 示例一: location / { } 匹配任何查询,因为所有请求都

nginx中使用nginx-http-concat模块合并静态资源文件

首先了解一下 nginx-http-concat,他是一个淘宝的开源Nginx模块,是一个能把多个CSS和JS合并成一个请求的Nginx模块,对于Web性能优化非常有意义. Github地址:https://github.com/alibaba/nginx-http-concat, 先看看淘宝用起来是什么样的,访问淘宝网主页,查看源代码可以看到类似的这样的style/script链接 复制代码 代码如下: <link rel="stylesheet" href="//g

Linux服务器nginx访问日志里出现大量http 400错误的请求分析

服务器中的错误记录类似于这种: 124.65.133.242 – – [27/Oct/2014:14:30:51 +0800] "-" 400 0 "-" "-" 124.65.133.242 – – [27/Oct/2014:14:31:45 +0800] "-" 400 0 "-" "-" 124.65.133.242 – – [27/Oct/2014:14:31:45 +0800]

nginx HTTP模块配置常用指令

一.HTTP模块的作用是什么? Nginx的HTTP模块用于控制Nginx的HTTP进程. 二.配置指令 1. alias含义:指定location使用的路径,与root类似,但不改变文件的跟路径,仅适用文件系统的路径.语法:alias <file-path | directory-path>缺省:N/A作用域:http.server.location示例: 复制代码 代码如下: location /i/ {    alias /home/michael/web/i/;} 如请求 /i/log

Nginx服务器中配置GeoIP模块来拦截指定国家IP

最近有一个网站项目需求:需要屏蔽国内的方问请求.花时间研究了一下这方面的资料.目前找到的最佳方法就是使用 Nginx 的 GeoIP 模块来实现地区的识别.然后配置相关国家的 ISO 名称,禁止访问即可.记录一下相关过程. 编译 GeoIP 组件 maxmind 提供的免费版数据库已经可以满足需求,在使用数据库前,需要先编译 GeoIP 组件: wget http://geolite.maxmind.com/download/geoip/api/c/GeoIP-1.4.8.tar.gz ./co

Nginx服务器基本的模块配置和使用全攻略

1. 安装nginx 1.1 选择稳定版本 我们编译安装nginx来定制自己的模块,机器CentOS 6.2 x86_64.首先安装缺少的依赖包: # yum -y install gcc gcc-c++ make libtool zlib zlib-devel openssl openssl-devel pcre pcre-devel 这些软件包如果yum上没有的话可以下载源码来编译安装,只是要注意编译时默认安装的目录,确保下面在安装nginx时能够找到这些动态库文件(ldconfig). 从

全面了解Nginx中的HTTP协议相关模块配置

要理解 HTTP 模块配置解析的过程,首先需要对 nginx 的配置文件结构做一个了解 nginx 的配置文件是用树状结构组织的,每个 NGX_CORE_MODULE 作为根统领着其下的所有配置项 而如下图所示,HTTP 模块的配置被分成了 main.server.location 三层 整个 nginx 配置解析的过程其实就是这棵树的深度遍历过程 而遍历 HTTP 子树的函数就是下面要介绍的 ngx_http_block 配置文件解析 -- http 配置块 当我们需要使用 http 模块的时

详解Nginx服务器中配置Sysguard模块预防高负载的方案

nginx做为HTTP服务器,有以下几项基本特性: 处理静态文件,索引文件以及自动索引:打开文件描述符缓冲. 无缓存的反向代理加速,简单的负载均衡和容错. FastCGI,简单的负载均衡和容错. 模块化的结构.包括gzipping, byte ranges, chunked responses,以及 SSI-filter等filter.如果由FastCGI或其它代理服务器处理单页中存在的多个SSI,则这项处理可以并行运行,而不需要相互等待. Nginx专为性能优化而开发,性能是其最重要的考量,实

详解Nginx静态服务配置(root和alias指令)

静态文件 Nginx以其高性能著称,常用与做前端反向代理服务器.同时nginx也是一个高性能的静态文件服务器.通常都会把应用的静态文件使用nginx处理. 配置nginx的静态文件有两个指令,一个 root 和一个 alias.对于这两个指令,是否需要在路径的后面加上斜杠,经常容易让人犯晕,本文通过尝试不同的匹配规则,归纳了一个比较通用的配置方式. 基本配置 与Nginx Location Url一文关于location url配置的实验一样,本文也使用vagrant虚拟机里的nginx.其基本

详解Nginx服务器中配置超时时间的方法

一.啥时候用到 用来设置请求资源和服务器返回的时间,保证一个请求占用固定时间,超出后报504超时!这样可以保证一个请求占用过长时间. 二.主要参数 使用nginx服务器如果遇到timeou情况时可以如下设置参数,使用fastcgi: fastcgi_connect_timeout 75;  链接 fastcgi_read_timeout 600;   读取 fastcgi_send_timeout 600;   发请求 这两个选项.          fastcgi_read_timeout是指

nginx环境下配置ssl加密(单双向认证、部分https)

nginx下配置ssl本来是很简单的,无论是去认证中心买SSL安全证书还是自签署证书,但最近公司OA的一个需求,得以有个机会实际折腾一番.一开始采用的是全站加密,所有访问http:80的请求强制转换(rewrite)到https,后来自动化测试结果说响应速度太慢,https比http慢慢30倍,心想怎么可能,鬼知道他们怎么测的.所以就试了一下部分页面https(不能只针对某类动态请求才加密)和双向认证.下面分节介绍. 默认nginx是没有安装ssl模块的,需要编译安装nginx时加入--with

windows下nginx安装、配置与使用

目前国内各大门户网站已经部署了Nginx,如新浪.网易.腾讯等:国内几个重要的视频分享网站也部署了Nginx,如六房间.酷6等.新近发现Nginx 技术在国内日趋火热,越来越多的网站开始部署Nginx. 相比apeach.iis,nginx以轻量级.高性能.稳定.配置简单.资源占用少等优势广受欢迎. 1)下载地址: http://nginx.org 2)启动 解压至c:\nginx,运行nginx.exe(即nginx -c conf\nginx.conf),默认使用80端口,日志见文件夹C:\