关于nginx keep-alive 参数的验证和心得

用chrome连接nginx服务器(nginx+spero),发现每次请求结果返回给浏览器后,会过一会才会运行

ngx_http_close_connection函数,可以看到nginx返回给chrome的header和结果是:

HTTP/1.1 200 OK

Server: nginx

Date: Fri, 15 Apr 2016 08:39:50 GMT

Content-Type: text/plain

Content-Length: 28

Connection: keep-alive

Keep-Alive: timeout=5

spero return ads, status 200

而通过curl访问,也是返回同样的结果,但是nginx会立刻调用ngx_http_close_connection函数,看起来keep-alive没有起作用,猜测是curl拿到结果后立马主动关闭连接。

HTTP/1.1 200 OK

Server: nginx

Date: Fri, 15 Apr 2016 08:44:11 GMT

Content-Type: text/plain

Content-Length: 28

Connection: keep-alive

Keep-Alive: timeout=5

spero return ads, status 200

那么做一个实验:设置nginx的配置文件,将keep-alive关掉,看看chrome访问时是否ngx_http_close_connection函数立刻被调用?

首先,用命令:keepalive_timeout 0 禁用长连接,则看到header中的Connection为close

HTTP/1.1 200 OK

Server: nginx

Date: Fri, 15 Apr 2016 08:50:05 GMT

Content-Type: text/plain

Content-Length: 28

Connection: close

spero return ads, status 200

同时,在nginx print的log中也可以看到,ngx_http_finalize_request函数之后,ngx_http_close_connection函数立刻就被调用了。

在spero项目中,长连接必须被关闭以支持大并发请求。

时间: 2024-10-06 02:11:50

关于nginx keep-alive 参数的验证和心得的相关文章

Nginx&Apache&PHP参数汇总

1.Nginx vim /etc/nginx/conf.d/www.cmdschool.org.conf   client_max_body_size 30m; //上传文件大小改30M   upstream www.cmdschool.org {     server 10.168.82.25:87;     ip_hash;   }   server {     listen 80;     server_name www.cmdschool.org;     location / {   

nginx rewrite arg 带问号的地址转发参数处理?Nginx重定向的参数问题

Nginx重定向的参数问题 在给某网站写rewrite重定向规则时,碰到了这个关于重定向的参数处理问题.默认的情况下,Nginx在进行rewrite后都会自动添加上旧地址中的参数部分,而这对于重定向到的新地址来说可能是多余.虽然这也不会对重定向的页面显示结果造成多少影响,但当你注意到新地址中包含有多余的"?xxx=xxx"时,心里总还是会觉得不爽.而且可能影响到网站的搜索优化SEO.那么该如何来处理这部分的内容呢?看了下面两个简单的例子你就会明白了. 例如:把http://exampl

ABP应用层——参数有效性验证

ABP应用层——参数有效性验证 基于DDD的现代ASP.NET开发框架--ABP系列之17.ABP应用层——参数有效性验证 ABP是“ASP.NET Boilerplate Project (ASP.NET样板项目)”的简称. ABP的官方网站:http://www.aspnetboilerplate.com ABP在Github上的开源项目:https://github.com/aspnetboilerplate 应用程序的输入数据首先应该被检验是否有效.输入的数据能被用户或其他应用程序提交.

nginx实现带参数目录域名重定向二级域名方法

本文章介绍了关于nginx实现带参数目录域名重定向二级域名方法,有需要学习的朋友可参考一下. 下面的代码是基于nginx的子目录301到其他域名(URL)的规则.作用是例如访问http://www.php100.com/phper/php.html (有杠和没杠是不同的,下面的代码中可以看出来),自动301到 http://php.php100.com  代码如下 复制代码 location ~* ^/phper/ {rewrite ^/phper/(.*)$ http://php.php100

WebService,ASMX文件使用XML格式数据传递参数、验证与获取XML格式返回值的一种方式

1:首先WebService方法定义,每个方法定义两个参数,一个用于验证权限,string格式的XML文本用于传输数据.最终目的实现,WebService方法,验证权限,获取XML数据,处理之后返回XML数据.一下面一段代码为例进行说明: [WebMethodAttribute(Description = "新增督学计划")] public string InspectorPlan_Add(string Token, string XMLParas) { try { //安全凭证检查

Nginx 主配置文件参数详解

Nginx 主配置文件参数详解 Nginx 安装完毕后,会有响应的安装目录,安装目录里 nginx.conf 为 nginx 的主配置文件, ginx 主配置文件分为 4 部分,main(全局配置).server(主机设置).upstream(负载均衡 服务器设)和 location(URL 匹配特定位置的设置),这四者关系为:server 继承 main, location 继承 server,upstream 既不会继承其他设置也不会被继承. 一.Nginx 的 main(全局配置)文件 [

nginx获取url参数

在文件src\http\ngx_http_core_module.c的函数ngx_http_core_run_phases(ngx_http_request_t *r)里面,添加如下代码: //声明部分 ngx_str_t* name; ngx_http_variable_value_t* val; char temp[15]; //实现部分 name=ngx_pnalloc(r->pool, sizeof(ngx_str_t)); name->data="arg_test"

Nginx中FastCGI参数优化

FastCGI: FastCGI是从CGI发展改进而来的.传统CGI接口方式的主要缺点是性能很差,因为每次HTTP服务器遇到动态程序时都需要重新启动脚本解析器来执行解析,然后结果被返回给HTTP服务器.这在处理高并发访问时,几乎是不可用的.另外传统的CGI接口方式安全性也很差,现在已经很少被使用了. FastCGI接口方式采用C/S结构,可以将HTTP服务器和脚本解析服务器分开,同时在脚本解析服务器上启动一个或者多个脚本解析守护进程.当HTTP服务器每次遇到动态程序时,可以将其直接交付给Fast

nginx安装及参数解读

安装 一.安装nginx时必须先安装相应的编译工具yum -y install gcc gcc-c++ autoconf automakeyum -y install zlib zlib-devel openssl openssl-devel pcre-devel 建立nginx 组groupadd -r nginxuseradd -s /sbin/nologin -g nginx -r nginxid nginx zlib:nginx提供gzip模块,需要zlib库支持openssl:ngin