存档

‘应用服务器’ 分类的存档

linux(centos)下安装php gd库

2017年2月13日 评论已被关闭

linux(centos)下安装php gd库

http://www.phpddt.com/server/984.html

最近帮人搭建了一个b2b网站,(Lamp安装教程),网站测试图片不能上传,经检查图片其实已经上传成功,只是因为php没有开启php gd库(上传图片后php对图片进行处理,加logo等),好吧,我就来搭建gd库了:

运行:  yum -y install php-gd

失败,显示如下:

yum.jpg这是因为没有第三方yum源支持的原因,于是我安装了:

wget http://www.atomicorp.com/installers/atomic

再次运行了命令,安装成功,测试 phpinfo();  还是没有成功,半天也没找到gd库!

我找到gd库的安装路径:/etc/php.d/gd.ini  发现内容为空,难怪,打开文件,加上这句:

extension=gd.so

重启服务器  service  httpd restart  终于看到亲爱的gd库了。

题外话:不用把全部东西都写在php.ini这个文件里,只是需要把*.ini文件写在/etc/php.d/文件夹就可以了,系统会自动把这个目录下的*.ini读入php.ini ; gd库的文件存放在:/usr/lib/php/modules/gd.so

分类: LAMP应用服务器 标签:

在nginx中禁止直接用ip访问及server_name特性

2017年2月6日 评论已被关闭

在nginx中禁止直接用ip访问及server_name特性

https://javawind.net/p121
看了很多nginx的配置,好像都忽略了ip直接访问web的问题,不利于SEO优化,所以我们希望可以避免直接用IP访问网站,而是域名访问,具体怎么做呢,看下面。
官方文档中提供的方法:
If you do not want to process requests with undefined “Host” header lines, you may define a default server that just drops the requests:
server {
listen 80 default_server;
server_name _;
return 444;
}
说白了就是只要是ip访问的直接重置444错误。但是这样好像又不太友好,如果能直接给跳转到该web server的网址就好了。
配置如下:
server {
listen 80 default_server;
server_name _;
rewrite ^ http://www.domain.com$request_uri?;
}
这样还是有一点问题,某些特别的地址,我需要用ip访问,其他的都禁止,如何配置呢?
比如说我想让监控宝直接用ip访问我的机器的nginx状态信息,其他的用ip访问的所有请求都跳转到域名上。
server {
listen 80 default_server;
server_name _;
location /xxxxx{
stub_status on;
access_log off;
}
location /{
rewrite ^ http://www.nginxs.com$request_uri?;
}
}
这样就实现了我们想要的功能了。
另外,在这里说一下server_name。server_name 是可以使用正则表达式的,这个功能因该说相当实用。
Nginx中的server_name指令主要用于配置基于名称的虚拟主机,server_name指令在接到请求后的匹配顺序分别为:
1、准确的server_name匹配,例如:
server {
listen 80;
server_name domain.com www.domain.com;

}
2、以*通配符开始的字符串:
server {
listen 80;
server_name *.domain.com; …
}
3、以*通配符结束的字符串:
server {
listen 80;
server_name www.*;

}
4、匹配正则表达式:
server {
listen 80;
server_name ~^(?.+)\.domain\.com$; …
}
nginx将按照1,2,3,4的顺序对server name进行匹配,只有有一项匹配以后就会停止搜索,所以我们在使用这个指令的时候一定要分清楚它的匹配顺序(类似于location指令)。
server_name指令一项很实用的功能便是可以在使用正则表达式的捕获功能,这样可以尽量精简配置文件,毕竟太长的配置文件日常维护也很不方便。下面是2个具体的应用:
1、在一个server块中配置多个站点:
server
{
listen 80;
server_name ~^(www\.)?(.+)$;
index index.php index.html;
root /data/wwwsite/$2;
}
站点的主目录应该类似于这样的结构:
/data/wwwsite/domain.com
/data/wwwsite/nginx.org
/data/wwwsite/baidu.com
/data/wwwsite/google.com
这样就可以只使用一个server块来完成多个站点的配置。
2、在一个server块中为一个站点配置多个二级域名。
实际网站目录结构中我们通常会为站点的二级域名独立创建一个目录,同样我们可以使用正则的捕获来实现在一个server块中配置多个二级域名:
server
{
listen 80;
server_name ~^(.+)?\.domain\.com$; index index.html;
if ($host = domain.com){ rewrite ^ http://www.domain.com permanent; }
root /data/wwwsite/domain.com/$1/; }
站点的目录结构应该如下:
/data/wwwsite/domain.com/www//data/wwwsite/domain.com/nginx/
这样访问www.domain.com时root目录为/data/wwwsite/domain.com/www/,nginx.domain.com时为/data/wwwsite/domain.com/nginx/,以此类推。
后面if语句的作用是将domain.com的方位重定向到www.domain.com,这样既解决了网站的主目录访问,又可以增加seo中对www.domain.com的域名权重。

三大WEB服务器对比分析(apache ,lighttpd,nginx)

2017年1月23日 评论已被关闭

三大WEB服务器对比分析(apache ,lighttpd,nginx)

http://www.blogjava.net/daniel-tu/archive/2008/12/29/248883.html

一.软件介绍(apache  lighttpd  nginx)

1. lighttpd

Lighttpd是一个具有非常低的内存开销,cpu占用率低,效能好,以及丰富的模块等特点。lighttpd是众多OpenSource轻量级的web server中较为优秀的一个。支持FastCGI, CGI, Auth, 输出压缩(output compress), URL重写, Alias等重要功能。

Lighttpd使用fastcgi方式运行php,它会使用很少的PHP进程响应很大的并发量。

Fastcgi的优点在于:

·         从稳定性上看, fastcgi是以独立的进程池运行来cgi,单独一个进程死掉,系统可以很轻易的丢弃,然后重新分配新的进程来运行逻辑.

·         从安全性上看, fastcgi和宿主的server完全独立, fastcgi怎么down也不会把server搞垮,

·         从性能上看, fastcgi把动态逻辑的处理从server中分离出来, 大负荷的IO处理还是留给宿主server, 这样宿主server可以一心一意作IO,对于一个普通的动态网页来说, 逻辑处理可能只有一小部分, 大量的图片等静态IO处理完全不需要逻辑程序的参与(注1)

·         从扩展性上讲, fastcgi是一个中立的技术标准, 完全可以支持任何语言写的处理程序(php,java,python…)

2.apache

apache是世界排名第一的web服务器, 根据netcraft(www.netsraft.co.uk)所作的调查,世界上百分之五十以上的web服务器在使用apache.

1995年4月, 最早的apache(0.6.2版)由apache group公布发行. apache group 是一个完全通过internet进行运作的非盈利机构, 由它来决定apache web服务器的标准发行版中应该包含哪些内容. 准许任何人修改隐错, 提供新的特征和将它移植到新的平台上, 以及其它的工作. 当新的代码被提交给apache group时, 该团体审核它的具体内容, 进行测试, 如果认为满意, 该代码就会被集成到apache的主要发行版中.

apache 的特性:

1) 几乎可以运行在所有的计算机平台上.

2) 支持最新的http/1.1协议

3) 简单而且强有力的基于文件的配置(httpd.conf).

4) 支持通用网关接口(cgi)

5) 支持虚拟主机.

6) 支持http认证.

7) 集成perl.

8) 集成的代理服务器

9) 可以通过web浏览器监视服务器的状态, 可以自定义日志.

10) 支持服务器端包含命令(ssi).

11) 支持安全socket层(ssl).

12) 具有用户会话过程的跟踪能力.

13) 支持fastcgi

14) 支持java servlets

3.nginx

Nginx是俄罗斯人编写的十分轻量级的HTTP服务器,Nginx,它的发音为“engine X”, 是一个高性能的HTTP和反向代理服务器,同时也是一个IMAP/POP3/SMTP 代理服务器.Nginx是由俄罗斯人 Igor Sysoev为俄罗斯访问量第二的 Rambler.ru站点开发.

Nginx以事件驱动的方式编写,所以有非常好的性能,同时也是一个非常高效的反向代理、负载平衡。其拥有匹配 Lighttpd的性能,同时还没有Lighttpd的内存泄漏问题,而且Lighttpd的mod_proxy也有一些问题并且很久没有更新。但是Nginx并不支持cgi方式运行,原因是可以减少因此带来的一些程序上的漏洞。所以必须使用FastCGI方式来执行PHP程序。

nginx做为HTTP服务器,有以下几项基本特性:

处理静态文件,索引文件以及自动索引;打开文件描述符缓冲.

无缓存的反向代理加速,简单的负载均衡和容错.

FastCGI,简单的负载均衡和容错.

模块化的结构。包括gzipping, byte ranges, chunked responses,以及 SSI-filter等filter。如果由FastCGI或其它代理服务器处理单页中存在的多个SSI,则这项处理可以并行运行,而不需要相互等待。

Nginx专为性能优化而开发,性能是其最重要的考量,实现上非常注重效率。它支持内核Poll模型,能经受高负载的考验,有报告表明能支持高达 50,000个并发连接数。

Nginx具有很高的稳定性。其它HTTP服务器,当遇到访问的峰值,或者有人恶意发起慢速连接时,也很可能会导致服务器物理内存耗尽频繁交换,失去响应,只能重启服务器。例如当前apache一旦上到200个以上进程,web响应速度就明显非常缓慢了。而Nginx采取了分阶段资源分配技术,使得它的CPU与内存占用率非常低。nginx官方表示保持10,000个没有活动的连接,它只占2.5M内存,所以类似DOS这样的攻击对nginx来说基本上是毫无用处的。就稳定性而言,nginx比lighthttpd更胜一筹。

Nginx支持热部署。它的启动特别容易, 并且几乎可以做到7*24不间断运行,即使运行数个月也不需要重新启动。你还能够在不间断服务的情况下,对软件版本进行进行升级。

.3WEB服务器的比较:

server Apache Nginx      Lighttpd
Proxy代理 非常好 非常好 一般
Rewriter 非常好 一般
Fcgi 不好 非常好
热部署 不支持 支持 不支持
系统压力比较 很大 很小 比较小
稳定性 非常好 不好
安全性 一般 一般
技术支持 非常好 很少 一般
静态文件处理 一般 非常好
Vhosts虚拟主机 支持 不支持 支持
反向代理 一般 非常好 一般
Session sticky 支持 不支持 不支持

注:在相对比较大的网站,节约下来的服务器成本无疑是客观的。而有些小型网站往往服务器不多,如果采用 Apache 这类传统 Web 服务器,似乎也还能撑过去。但有其很明显的弊端: Apache 在处理流量爆发的时候(比如爬虫或者是 Digg 效应) 很容易过载,这样的情况下采用 Nginx 最为合适。

建议方案:

Apache 后台服务器(主要处理php及一些功能请求 如:中文url)

Nginx  前端服务器(利用它占用系统资源少得优势来处理静态页面大量请求)

Lighttpd 图片服务器

总体来说,随着nginx功能得完善将使他成为今后web server得主流。

.性能测试

将分别测试3种软件在对动态页面和静态页面请求及并发时的响应时间

l        静态页面 搜狐首页

LIGHTTPD

n/-c(ab参数) cpu% Mem RequestsperSecond Time taken for tests
100000/100 64 60 462.75 21.6
100000/200 67 60 312.07 32.4
100000/500 83 60 137.24 72.8
100000/1000

出现错误丢包

94 60 126.6 78.9

NGINX

n/-c(ab参数) cpu% Mem RequestsperSecond Time taken for tests
100000/100 34.6 140 943.66 10.597
100000/200 35.6 110 924.32 10.818
100000/500 34.3 110 912.68 10.956
100000/1000 37 160 832.59 12.106

APACHE

n/-c(ab参数) cpu% Mem RequestsperSecond Time taken for tests
100000/100 40.6 170 690.72 14.47
100000/200 41.1 180 685.39 14.59
100000/500 42.3 190 633.64 15.78
100000/1000 43.1 200 547.53 18.26

l        动态页面 内部社区首页

LIGHTTPD

n/-c(ab参数) cpu% Mem RequestsperSecond Time taken for tests
1000/100 50 200 33.54 29.816
1000/200 52 210 30.43 32.858
1000/500 54 230 25.79 38.76
1000/1000 62 250 24.83 40.28

NGINX

n/-c(ab参数) cpu% Mem RequestsperSecond Time taken for tests
1000/100 53.8 250 83.12 12.305
1000/200 55.8 250 74.05 13.504
1000/500 56 260 58.99 16.951
1000/1000 58 260 43.41 23.347

APACHE

n/-c(ab参数) cpu% Mem RequestsperSecond Time taken for tests
100000/100 60 200 27.37 36.541
100000/200 61 220 23.82 41.981
100000/500 73 150 20.59 48.562
100000/1000 53 200 27.18 36.796

l        PHPINFO函数页

LIGHTTPD

n/-c(ab参数) cpu% Mem RequestsperSecond Time taken for tests
100000/100 45 20 168.06 59.504
100000/200 47 22 140.64 71.103
100000/500 49 24 52.80 189.386
100000/1000 在请求到4840时测试测试程序死掉

NGINX

n/-c(ab参数) cpu% Mem RequestsperSecond Time taken for tests
100000/100 70 120 143.46 69.706
100000/200 72 130 140.57 71.140
100000/500 73 150 135.87 73.601
100000/1000 77 160 132.18 75.657

APACHE 出现丢包

n/-c(ab参数) cpu% Mem RequestsperSecond Time taken for tests
100000/100 70 180 245.73 40.694
100000/200 72 190 245.79 40.684
100000/500 75 200 241.29 41.443
100000/1000 77 220 236.74 42.239

四.各大网站WEB服务器资源列表

网站名   操作系统   web服务器

1.门户网站类:

搜狐     LINUX           apache 1.3.37

新浪     LINUX           apache 2.0.54

迅雷     LINUX           nginx 0.6.31

163      LINUX           apache 2.2.6

2.搜索类

百度      unknown        BWS 1.0

Google   linux           gws

Sougou   FreeBSD         apache 2.2.4

Hao123   linux          apache 2.2.4

4. 电子邮箱类

126        linux         apache

Hotmail    win2003      microsoft-IIS 6.0

新浪邮箱    F5 Big-IP    apache 2.2.8

263        linux         apache 2.2.6

5. 博客类

新浪博客    linux          nginx 0.5.35

搜狐博客    linux          nginx

迅雷博客    linux          nginx 0.6.32

天涯博客    F5 Big-IP      Microsoft-IIS/5.0

6.视频类

优酷         linux          apache

土豆         linux          apache

Ku6         linux           apache

六间房       linux          nginx 0.6.14

nginx采用epoll的事件模型,为何效率高

2017年1月19日 评论已被关闭

nginx采用epoll的事件模型,为何效率高
http://zhan.renren.com/louxiaochang?gid=3602888498034749910&checked=true
以前就知道在linux下nginx采用epoll事件模型,处理效率高。但是一直不知道具体为什么,今天查看了下文档,了解了原因。
首先nginx支持一下这些事件模型(才考nginx的wiki)
Nginx支持如下处理连接的方法(I/O复用方法),这些方法可以通过use指令指定。
select – 标准方法。 如果当前平台没有更有效的方法,它是编译时默认的方法。你可以使用配置参数 –with-select_module 和 –without-select_module 来启用或禁用这个模块。
poll – 标准方法。 如果当前平台没有更有效的方法,它是编译时默认的方法。你可以使用配置参数 –with-poll_module 和 –without-poll_module 来启用或禁用这个模块。
kqueue – 高效的方法,使用于 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用双处理器的MacOS X系统使用kqueue可能会造成内核崩溃。
epoll – 高效的方法,使用于Linux内核2.6版本及以后的系统。在某些发行版本中,如SuSE 8.2, 有让2.4版本的内核支持epoll的补丁。
rtsig – 可执行的实时信号,使用于Linux内核版本2.2.19以后的系统。默认情况下整个系统中不能出现大于1024个POSIX实时(排队)信号。这种情况 对于高负载的服务器来说是低效的;所以有必要通过调节内核参数 /proc/sys/kernel/rtsig-max 来增加队列的大小。可是从Linux内核版本2.6.6-mm2开始, 这个参数就不再使用了,并且对于每个进程有一个独立的信号队列,这个队列的大小可以用 RLIMIT_SIGPENDING 参数调节。当这个队列过于拥塞,nginx就放弃它并且开始使用 poll 方法来处理连接直到恢复正常。
/dev/poll – 高效的方法,使用于 Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+.
eventport – 高效的方法,使用于 Solaris 10. 为了防止出现内核崩溃的问题, 有必要安装 这个 安全补丁。
在linux下面,只有epoll是高效的方法。
下面再来看看epoll到底是如何高效的
Epoll是Linux内核为处理大批量句柄而作了改进的poll。 要使用epoll只需要这三个系统调用:epoll_create(2), epoll_ctl(2), epoll_wait(2)。它是在2.5.44内核中被引进的(epoll(4) is a new API introduced in Linux kernel 2.5.44),在2.6内核中得到广泛应用。
epoll的优点
支持一个进程打开大数目的socket描述符(FD)
select 最不能忍受的是一个进程所打开的FD是有一定限制的,由FD_SETSIZE设置,默认值是2048。对于那些需要支持的上万连接数目的IM服务器来说显 然太少了。这时候你一是可以选择修改这个宏然后重新编译内核,不过资料也同时指出这样会带来网络效率的下降,二是可以选择多进程的解决方案(传统的 Apache方案),不过虽然linux上面创建进程的代价比较小,但仍旧是不可忽视的,加上进程间数据同步远比不上线程间同步的高效,所以也不是一种完 美的方案。不过 epoll则没有这个限制,它所支持的FD上限是最大可以打开文件的数目,这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左 右,具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。
IO效率不随FD数目增加而线性下降
传 统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合,不过由于网络延时,任一时间只有部分的socket是”活跃”的,但 是select/poll每次调用都会线性扫描全部的集合,导致效率呈现线性下降。但是epoll不存在这个问题,它只会对”活跃”的socket进行操 作—这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么,只有”活跃”的socket才会主动的去调用 callback函数,其他idle状态socket则不会,在这点上,epoll实现了一个”伪”AIO,因为这时候推动力在os内核。在一些 benchmark中,如果所有的socket基本上都是活跃的—比如一个高速LAN环境,epoll并不比select/poll有什么效率,相 反,如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。
使用mmap加速内核与用户空间的消息传递。
这 点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间,如何避免不必要的内存拷贝就很 重要,在这点上,epoll是通过内核于用户空间mmap同一块内存实现的。而如果你想我一样从2.5内核就关注epoll的话,一定不会忘记手工 mmap这一步的。
内核微调
这一点其实不算epoll的优点了,而是整个linux平台的优点。也许你可以怀疑linux平台,但是你无法回避linux平台赋予你微调内核的能力。比如,内核TCP/IP协 议栈使用内存池管理sk_buff结构,那么可以在运行时期动态调整这个内存pool(skb_head_pool)的大小— 通过echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函数的第2个参数(TCP完成3次握手 的数据包队列长度),也可以根据你平台内存大小动态调整。更甚至在一个数据包面数目巨大但同时每个数据包本身大小却很小的特殊系统上尝试最新的NAPI网卡驱动架构。
以上这些epoll内容,参考epoll_互动百科
在我128M的vps上,我查看了一下,file-max的数量已经达到11945
应该说确实比apache的方式要好,而且资源占用也少。

转自:http://xinlogs.com/nginx-epool-events

分类: LNMP应用服务器 标签:

425 Can’t open data connection

2017年1月3日 评论已被关闭

425 Can’t open data connection
http://blog.sina.com.cn/s/blog_59b30fd40100gcgu.html
425 Can’t open data connection 列表错误 解决方法

尝试方法一:

这个问题主要是由于使用Passive Mode模式造成的,解决这个问题很简单:
1、在ftp服务软件中设置指定端口地址范围,允许Passive Mode使用,比如60000-60020
2、然后在ftp服务器的系统防火墙上打开这些tcp端口,比如是60000-60020,如果使用windows自带的防火墙,就一条一条的增加,20行有点麻烦,但是可以解决。

如果ftp用户较多,可以扩大端口范围。
尝试方法二:

考虑以下原因:
1、防火墙挡住了
2、没有查看内容的权限
3、网管屏蔽了FTP端口 (检查20端口是否开放,如FTP改过端口了1234,刚检查1233端口是否开放)

尝试方法三:

425 Can’t open data connection 和 读取目录列表失败 问题解决

这个问题主要是由于使用Passive Mode模式造成的,解决这个问题很简单:

1、在ftp服务软件中设置指定端口地址范围,允许Passive Mode使用,比如60000-60020

2、然后在ftp服务器的系统防火墙上打开这些tcp端口

尝试方法四:

是由于服务端防火墙的设置,客户端不能用pasv模式,用户在使用FTP上传文件时出现无法列表的情况,是由于选择在PASV方式下进行上传而导致的。因此,请用户将上传方式改为PORT。相同的软件,版本不同,设置方法也略有不同,因此需要根据实际情况进行设置(连接之前请确保已经关闭防火墙,例如卡巴斯基、瑞星、天网、windowsxp系统自带的防火墙等)。

分类: FTP应用服务器 标签:

FTP连接时出现“227 Entering Passive Mode” 的解决方法

2017年1月3日 评论已被关闭

FTP连接时出现“227 Entering Passive Mode” 的解决方法
http://wrj1982.blog.51cto.com/1131419/420537
今天从公网的服务器连接本地内网的FTP server copy文件时,系统老是提示227 Entering Passive Mode (xxx,xxx,,xxx,xxx,x),很是奇怪,于是上网找资料仔细研究了一下,原来FTP有两种工作模式,PORT方式和PASV方式,中文意思为主动式和被动式 ,详细介绍如下:
主动 FTP :
命令连接:客户端 >1024 端口 → 服务器 21 端口
数据连接:客户端 >1024 端口 ← 服务器 20 端口
被动 FTP :
命令连接:客户端 >1024 端口 → 服务器 21 端口
数据连接:客户端 >1024 端口 ← 服务器 >1024 端口
PORT(主动)方式的连接过程是:客户端向服务器的FTP端口(默认是21)发送连接请求,服务器接受连接,建立一条命令链路。当需要传送数据时, 客户端在命令链路上用PORT命令告诉服务器:“我打开了***X端口,你过来连接我”。于是服务器从20端口向客户端的***X端口发送连接请求,建立 一条数据链路来传送数据。

PASV(被动)方式的连接过程是:客户端向服务器的FTP端口(默认是21)发送连接请求,服务器接受连接,建立一条命令链路。当需要传送数据时, 服务器在命令链路上用PASV命令告诉客户端:“我打开了***X端口,你过来连接我”。于是客户端向服务器的***X端口发送连接请求,建立一条数据链 路来传送数据。
由于我的本地FTP服务器在内网,只是从外网映射了两个端口(20,21),所以无法使用PASV方式,解决此问题的办法也很简单,关闭客户端的PASV方式,强制其用PORT方式访问服务器,登录FTP服务器后用passive命令关闭客户端的PASV方式,如下:

ftp> passive
Passive mode off.
ftp> passive (再次运行命令可打开)
Passive mode on.

分类: FTP应用服务器 标签:

425 Can’t open data connection 问题解决

2017年1月3日 评论已被关闭

425 Can’t open data connection 问题解决
http://blog.sina.com.cn/s/blog_5938487901000av3.html
425 Can’t open data connection 和 读取目录列表失败 问题解决

这个问题主要是由于使用Passive Mode模式造成的,解决这个问题很简单:
1、在ftp服务软件中设置指定端口地址范围,允许Passive Mode使用,比如60000-60020
2、然后在ftp服务器的系统防火墙上打开这些tcp端口,比如是60000-60020,如果使用windows自带的防火墙,就一条一条的增加,20行有点麻烦,但是可以解决。

如果ftp用户较多,可以扩大端口范围。

如果问题解决了,回复一下;如果没有解决,请留言,我会继续关注此问题。

分类: FTP应用服务器 标签:

正确设置php-fpm子进程用户,提高网站安全性防挂马

2016年12月11日 评论已被关闭

正确设置php-fpm子进程用户,提高网站安全性防挂马

http://www.lowxp.com/g/article/detail/281

根据生产环境不断反馈,发现不断有 PHP网站被挂木马,绝大部分原因是因为权限设置不合理造成。因为服务器软件,或是 php 程序中存在漏洞都是难免的,在这种情况下,如果能正确设置 Linux 网站目录权限, php 进程权限,那么网站的安全性实际上是可以得到保障的。

那么,造成网站被挂木马的原因是什么?

ftp 连接信息被破解,对这个原因,可行的办法就是使用非常复杂的FTP 用户名(不要使用常用的用户名),如果是固定作业,可考虑使用 iptables 防火墙限制来源 IP 。但是一些情景下,可能需要使用 VPN 以便远程维护。 即网站维护者需要使用 FTP 修改网站文件时,必须先登录到 IDC 机房的 VPN 服务器上,再进行后续的操作。

网站服务器软件/ 配置 /php 程序存在漏洞,被利用,在讨论这个问题前,先说明文件及进程权限的几个概念:

FTP用户对网站目录具有最大修改权限,那么网站的文件所有者一定属于 FTP,  这是毋庸置疑的 , 否则如何修改文件呢?

php-fpm进程, Nginx 进程对网站文件至少需要有读取权限,例如,以下命令即可查看这两个进程所使用的账号:

php-fpm-security1

php-fpm-security2

通过上图,我们可以发现,nginx 和 php-fpm 子进程账号是 nobody 。

我们再查看网站文件目录的权限:

php-fpm-security3

发现网站文件所有者是www 账号,那说明:

  • nginx和 php 对网站只有读取权限,无写入权限
  • 如果php 程序需要对网站某些文件有写入权限,需要手工将文件或目录权限修改为 777
  • 因为php-fpm 子进程是以 nobody 运行,那么 php-fpm 生成的新文件所有者也是 nobody, 这时 ftp 用户将无法修改这些文件,解铃还需系铃人,当 php 生成文件后,需要调用 chmod(“/somedir/somefile”, 0777) 将文件权限修改为 777 ,以便 FTP 用户也可以修改这个文件。
  • 经常有开发人员找我请求重设php 生成的文件的权限。
  • 如果php-fpm 子进程以网站文件所有者用户运行,那意味着 php-fpm 进程对整个网站目录具有可写权限,噩梦也就由此开始。

但是我们发现,有不少系统管理员为了省事,违背了Linux 最小化权限的原则,设置 php-fpm 进程以网站文件所有者账号运行,当然这样可能会方便 php 开发人员( php-fpm 进程对整个网站目录具有可写权限),但是这样一来, Linux 体系的文件系统权限原则将被打破,所有的安全措施将形同虚设。可以想象的是,万一 php 程序中有漏洞,攻击者上传木马,便可以修改网站的所有文件,网站首页被黑,也就不足为怪了。

退一步,如果我们设置了较严格的权限,就算php 程序中存在漏洞,那么攻击者也只能篡改权限为 777 的目录,其它的文件是无法被改写的,网站不就就得更安全了吗?

核心总结:php-fpm 子进程所使用的用户,不能是网站文件所有者。 凡是违背这个原则,则不符合最小权限原则。

经过我参阅网上关于nginx, php-fpm 配置的文章教程和市面上的一些书籍,发现有不少人受这些文章的误导,直接让 php-fpm 子进程以网站所有者账号运行,例如张宴的《实战 nginx 取代 apache 的高性能 Web 服务器》一书的 52 页中,存在以下设置:

www
www

官方提供的配置文件中,php-fpm 子进程使用 nobody 用户,这完全是合理的,无须修改。

那么nginx 的子进程用户,如何设置合理?我的建议是也使用 nobody (对错误日志写入等无影响),设置方法如下:

nginx.conf文件第一行设置为 user nobody; , 再执行 nginx -s reload 即可。

php-fpm子进程用户设置方法:

编辑文件php-fpm.conf (一般位于 /usr/local/php/etc/php-fpm.conf 视安装参数为准),找到 user 、group 两个参数的定义,将其设置为nobody( 默认已经是 nobody) ,再重启 php-fpm 进程即可。

网站可写目录的特殊注意

这里的可写,是相对php-fpm 子进程而言。一个网站最容易出安全问题的即是可写目录,如果可写目录权限能控制严格,安全系数也将大大提高。
我们认为,一个网站可写目录主要分为以下几种:

  1. php 数据缓存目录,如 discuz 的 forumdata 目录,就存放了大量数据缓存文件。此类目录一般会禁止用户直接访问,但是 discuz 在这个目录下又存放了不少 js, css 文件,我们并不能简单地拒绝用户访问这个目录。显然,这个目录下的所有文件,不能直接交给 php 解析,我们后面会给出解决方案。
  2. 附件上传目录。显然此类目录需要开启访问,但不能交由php 引擎解析(即这个目录下的所有文件均视为普通静态文件)。
  3. 静态文件生成目录,这类目录下的文件全部应视为静态文件。
  4. 日志目录, 一般都会拒绝用户直接访问之。

也就是说对网站开发人员而言,需要对可写目录实现动静分离,不同性能的文件,应该区别对待之,这样也就方便系统管理员,设置合理的nginx 规则,以提高安全性。

简单地去掉php 文件的执行权限,并不能阻止 php-fpm 进程解析之。

接下来,根据以上总结,系统管理员如何配置nginx 的目录规则,才更安全呢?

数据缓存目录 /cache/,这个目录的特点是需要777 权限,无须提供给用户访问,那么可以按以下参考配置 nginx

location ~ “^/cache” {
return 403;
}

location ~ “.php$” {
fastcgi_pass 127.0.0.0:9000;
………………..
}

这时,任何用户将无法访问/cache/ 目录内容。

附件上传目录 attachments

此目录的特点是需要开放访问权限,但所有文件不能由php 引擎解析(包括后缀名改为 gif 的木马文件)

location ~ “^/attachments” {
}

location ~ “.php$” {
fastcgi_pass 127.0.0.0:9000;
………………..
}

注意,上面对attachments 目录的 location 定义中是没有任何语句的。 nginx 对正则表达式的 location 匹配优先级最高,任何一个用正则表达式定义的 location, 只要匹配一次,将不会再匹配其它正则表达式定义的 location 。

现在,请在attachments 目录下建立一个 php 脚本文件,再通过浏览器访问安,我们发现浏览器提示下载,这说明 nginx 把 attachments 目录下的文件当成静态文件处理,并没有交给 php fastcgi 处理。这样即使可写目录被植入木马,但因为其无法被执行,网站也就更安全了。

显然,重要的php 配置文件,请勿放在此类目录下。

静态文件生成目录 public

这些目录一般都是php 生成的静态页的保存目录,显然与附件目录有类似之处,按附件目录的权限设置即可。可以预见的是,如果我们设置了较严格的权限,即使网站php 程序存在漏洞,木马脚本也只能被写入到权限为 777 的目录中去,如果配合上述严格的目录权限控制,木马也无法被触发运行,整个系统的安全性显然会有显著的提高。

但是网站可写目录的作用及权限,只有开发人员最为清楚。这方面需要php 开发人员和系统管理员积极沟通。我们使用的方式是:项目上线前,开发人员根据以文档形式提供网站可写目录的作用及权限,由系统管理员针对不同目录进行权限设置。任何一方修改了网站目录权限,但未体现到文档中,我们认为是违反工作流程的

Apache 2.4 编码GB2312中文乱码的问题

2016年12月10日 评论已被关闭

Apache 2.4 编码GB2312中文乱码的问题
http://www.cnblogs.com/wayne173/p/6017697.html
今天部署了一个项目,代码和数据库都是gb2312的,本地和服务器都是apache2.4的版本,本地编码没问题,response的content-type是空的。按html的mete解析的,查看源码也是正常的。可是部署到服务器上就出现乱码,虽然手动设置编码后页面显示正常,可是查看源码还是乱码的,查看了google浏览器的网络插件,发现 response的content-type 里charset给设置成utf-8了,结果一开始是修改的 apache的配置文件, AddDefaultCharset 为 Off 或者 GB2312 都不解决问题。百度了好多内容还是不行。多数是修改AddDefaultCharset。

最后还是FQ去google ,发现有个国外的哥们儿 采用了 headers_module 的扩展,设置 header 然后在 .htaccess 里面试了下,解决问题了。真高兴啊,搞了好久了。现在记录下来。

<Files ~ “\.html?$”>
Header set Content-Type “text/html; charset=utf-8”
</Files>
特别注意的是 这个需要打开 mod_headers.so 模块扩展,具体搜下 http.conf 里的 mod_headers.so ,打开前门的#就可以了。然后重启apache。

Apache 中文乱码解决方案

2016年12月10日 评论已被关闭

Apache 中文乱码解决方案
http://www.cnblogs.com/RChen/archive/2007/08/27/871427.html
原文:http://douzi.org/wp/archives/161
=============================================================

Apache 中文乱码解决方案

服务器端:
======
修改httpd.conf (在Redhat中放置的位置为/etc/httpd/conf/)
查找:
AddDefaultCharset ISO-8859-1
改成:
#AddDefaultCharset ISO-8859-1
AddDefaultCharset off

这种方式关掉了服务器的默认语言的发送,这样仅凭html文件头中设置的语言来决定网页语言。

很多文章都说通过修改为 AddDefaultCharset GB2312 把缺省语言改成GB2312来解决中文乱码,确实GB2312内码的网页可以正常显示了,但这并非万全之策。因为当你的网页内码不是GB2312,就算你在网页用下面的meta指定了正确的语言,如ISO8859-1,也不会解码为ISO8859-1,因为Apache已经先你一步将GB2312指定为网页的语言了,如下图:

而这个是加了 AddDefaultCharset off 后的:

修改后请重新启动Apache,在Redhat中命令为
/etc/init.d/httpd restart

当使用一些网页脚本引擎,如PHP,还可能需要修改相应的配置文件。
以PHP为例,需要修改php.ini (Red Hat中位置在/etc/)

找到:
default_charset = “iso-8859-1″ 或者类似的,如 default_charset = “gb2312″,将其注释掉:
;default_charset=”iso-8859-1″

客户端:
=====
在中文网页请中依情况在标签中添加:
GB2312:
<META http-equiv=”Content-Type” content=”text/html; charset=gb2312″ />
BIG5:
<META http-equiv=”Content-Type” content=”text/html; charset=big5″ />
UTF-8: (注意是UTF-8,而不是UTF8,我已经上过当了)
<META http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />

如果还是不正常,请清空浏览器的Cache试试。

另外附上goghs的”blog工具中中文的问题“一文的修正版,这篇文章很好的阐述了Charset和Encoding之间的关系。

blog工具中中文的问题 [Blog] – goghs @ 23:26:56

现在的blog工具完全中文的并没有,而一般程序的默认,都是使用iso8859-1字符集,或者说en语言编码。字符集(Charset)和编码(Encoding)是两个不同的概念。

如果你使用MT的默认安装,或者使用B2的默认安装,你会发现你所发布的中文文章根本无法正常显示。(此处的MT的默认安装,以使用MySQL为基准,使用文件的我没有测试,不便评述。)

原因很简单,所有页面的默认都是iso8859-1字符集,所以在数据插入数据库的时候,都会被编码(成为html实体,如xxx;类型,xxxx此处都是数字)。

处理的方式并不复杂,对MT而言,你需要将mt.cfg中的NoHTMLEntities以行前面的注释符号去掉,变成
NoHTMLEntities 1
一次来禁止使用HTML::Entities进行实体编码。
然后修改CGI.pm中的一处,设置为正确的gb2312字符集,我在前面的一篇文章中已经谈到。

并且需要修改所有的模板,将其中的charset从iso8859-1修改为gb2312。

而对B2,B2config.php里, 第91行有
# IMPORTANT! set this to 0 if you are using Chinese, Japanese, Korean,
#or other double-bytes languages
$use_htmltrans = 0;

把$use_htmltrans 设定成0就行了。

编码问题还牵涉到生成的RSS文件。作为XML的一个词汇集(此处翻译成中文似乎很让人搞不清楚,也许直接用Vocabulary更好一点),RSS完全需要遵循XML规范。
所有的数据中,有5个字符必须进行特殊处理。它们是单引号(’), 双引号(”), 小于号(< ),大于号(>),以及&,因为他们具有特殊的用处和意义。MT中Util模块(Util.pm)中的encode_html函数负责处理,而在PHP中使用htmlspecialchars()函数做的就是同样的工作(注意默认情况下单引号是不被处理的,你需要使用ENT_QUOTES作为第二个参数)。
对RSS的生成,你只需要使用上述的方法进行处理,就是处理掉5各特殊字符,而千万不要使用MT中的HTMLEntities和PHP中的 htmlentities()函数,因为这样它会将非iso8859-1的字符全部转换成实体,就是xxx;格式。对PHP,虽然4.1版本开始,虽然htmlspecialchars()函数可以通过第三个参数传递一个charset来进行处理,但是以我的简单测试,似乎不行。
另外需要对RSS指定一个正确的encoding, 就是将默认的
<?xml version=”1.0″ encoding=”UTF-8″?>
修改为
<?xml version=”1.0″ encoding=”GB2312″?>
(XML这里确实比较糊涂,encoding使用charset)

关于语言代码和国际代码,有很多复杂的标准,我也没太搞清楚,这里就不说了。总之记住对简体中文,charset = gb2312 或者说更准确的应是 charset = GB2312, encoding = “zh”。其他的不知道也罢。

在rss生成中,只要你在前面制定了正确的charset, 即使你没有正确设置encoding,其源文件是完全可读的,只是如果你使用浏览器进行浏览时,它会以UTF-8编码显示,因此中文是乱码,只有你正确制定了中文编码后,才可以正确显示(你也可以通过切换浏览器的编码来看)。

总之这是一个比较复杂的问题,我的能力有限,也只能解释道这一步了。
仓促中写就,可能有很多错误,请大家指正。

分类: LAMP应用服务器 标签:

Apache2.4.x版wampserver本地php服务器如何让外网访问及启用.htaccess

2016年12月10日 评论已被关闭

Apache2.4.x版wampserver本地php服务器如何让外网访问及启用.htaccess

http://www.jb51.net/article/61193.htm
这篇文章主要介绍了Apache2.4.x版wampserver本地php服务器如何让外网访问及启用.htaccess,需要的朋友可以参考下
Apache 从2.2升级到 Apache2.4.x 后配置文件 httpd.conf 的设置方法有了大变化,以前是将 deny from all 全部改成 Allow from all 实现外网访问,现在是将 Require all denied 以及 Require local 都该为 Require all granted 就可以了。
.htaccess 如果不起作用将 LoadModule rewrite_module modules/mod_rewrite.so 前面的注释(#)去掉就可以了。
下面看一下 Apache2.4 的变化:(官方英文说明)
所有的请求都被拒绝
2.2上的配置
Order deny,allow
Deny from all
2.4上的配置
Require all denied
所有请求都是允许的
2.2上的配置
Order allow,deny
Allow from all
2.4上的配置
Require all granted
在域中的所有主机都可以访问example,所有其他外网主机的访问被拒绝
2.2上的配置
Order Deny,Allow
Deny from all
Allow from example.org
2.4上的配置
Require host example.org
要想外网访问将 Require local 该为 Require all granted 。
经常会用到的:
Require all denied
Require all granted
Require host xxx.com
Require ip 192.168.1 192.168.2
Require local
举例说明
仅允许IP:192.168.0.1 访问
Require all granted
Require ip 192.168.0.1
仅禁止IP:192.168.0.1访问
Require all granted
Require not ip 192.168.0.1
允许所有访问
Require all granted
拒绝所有访问
Require all denied
默认是 Require local 仅允许本地访问。
还有好多变化,可以去官方说明详细看一下,不过只有英文版的。软件变化无常,建议大家升级前详细阅读官方更新文档,以免来个措手不及。

分类: LAMP应用服务器 标签:

Apache2.2 配置 默认编码 解决中文乱码

2016年12月10日 评论已被关闭

Apache2.2 配置 默认编码 解决中文乱码
http://blog.csdn.net/ylqmf/article/details/5306594

在Apache的配置文件httpd.conf中

1)在配置文件中找包含“AddLanguage”或“AddCharset”的行,在这些行最前面增加一行:

AddDefaultCharset GB2312

2)养成良好的习惯,在每个网页的<head></head>里加入这行:

<meta http-equiv=”Content-Type” content=”text/html; charset=gb2312″>

一般的中文版网页编辑工具(例如FrontPage、Dreamweaver等)都会自动加上这行。

PS:刚刚安装好的Apache2.2中是没有“AddLanguage”或“AddCharset”的,直接在httpd.conf文件末尾添加就ok了

Apache alias目录配置

2016年12月10日 评论已被关闭

Apache alias目录配置

http://www.cnblogs.com/bourneli/archive/2012/11/13/2767522.html
一个apache网站,在不同目录下有不同网站,但在同一个域名下,这时可以配置alias,这与多域名不一样。

在http.conf里增加:
<IfModule alias_module>

Alias /your_alias /your/dqm/new/proj/root

# 保留其他配置

</IfModule>

# 设置相关目录属性

<Directory “/your/dqm/new/proj/web/root”>

Options Indexes FollowSymLinks

AllowOverride None

Order allow,deny

Allow from all

</Directory>
访问时的url: http://your_host.com/your_alias/ 这样就可以映射到对应目录了

Alias与virtual host不冲突,可以并存

分类: LAMP应用服务器 标签: ,

Linux/Nginx查看搜索引擎蜘蛛爬虫的行为

2016年12月8日 评论已被关闭

Linux/Nginx查看搜索引擎蜘蛛爬虫的行为
https://blog.hackroad.com/operations-engineer/linux_server/5107.html
Linux/Nginx查看搜索引擎蜘蛛爬虫的行为 Nginx

做好网站SEO优化的第一步就是首先让蜘蛛爬虫经常来你的网站进行光顾,下面的Linux命令可以让你清楚的知道蜘蛛的爬行情况。下面我们针对nginx服务器进行分析,日志文件所在目录:/usr/local/nginx/logs/access.log,access.log这个文件记录的应该是最近一天的日志情况,首先请看看日志大小,如果很大(超过50MB)建议别用这些命令分析,因为这些命令很消耗CPU,或者更新下来放到分析机上执行,以免影响网站的速度。

Linux shell命令

1. 百度蜘蛛爬行的次数

cat access.log | grep Baiduspider | wc
最左面的数值显示的就是爬行次数。

2. 百度蜘蛛的详细记录(Ctrl C可以终止)

cat access.log | grep Baiduspider
也可以用下面的命令:

cat access.log | grep Baiduspider | tail -n 10
cat access.log | grep Baiduspider | head -n 10
只看最后10条或最前10条,这用就能知道这个日志文件的开始记录的时间和日期。

3. 百度蜘蛛抓取首页的详细记录

cat access.log | grep Baiduspider | grep “GET / HTTP”
百度蜘蛛好像对首页非常热爱每个钟头都来光顾,而谷歌和雅虎蜘蛛更喜欢内页。

4. 百度蜘蛛派性记录时间点分布

cat access.log | grep “Baiduspider ” | awk ‘{print $4}’
5. 百度蜘蛛爬行页面按次数降序列表

cat access.log | grep “Baiduspider ” | awk ‘{print $7}’ | sort | uniq -c | sort -r
文中的Baiduspider 改成Googlebot都可以查看谷歌的数据,鉴于大陆的特殊性,大家应该对百度的log更为关注。

附:(Mediapartners-Google)Google adsense蜘蛛的详细爬行记录

cat access.log | grep Mediapartners
Mediapartners-Google是什么呢?Google adsense广告之所以能与内容相关,因为每个包含着adsense的广告被访问后,很快就有个Mediapartners-Google蜘蛛来到这个页面,所以几分钟后再刷新就能显示相关性广告了,真厉害啊!

使用nginx限制百度蜘蛛的频繁抓取

2016年12月8日 评论已被关闭

使用nginx限制百度蜘蛛的频繁抓取
http://www.bo56.com/使用nginx限制百度蜘蛛的频繁抓取/
百度蜘蛛抓取量骤增,导致服务器负载很高。最终用nginx的ngx_http_limit_req_module模块限制了百度蜘蛛的抓取频率。每分钟允许百度蜘蛛抓取200次,多余的抓取请求返回503。
nginx的配置:
#全局配置
limit_req_zone $anti_spider zone=anti_spider:60m rate=200r/m;
#某个server中
limit_req zone=anti_spider burst=5 nodelay;
if ($http_user_agent ~* “baiduspider”) {
set $anti_spider $http_user_agent;
}

参数说明:
指令limit_req_zone 中的rate=200r/m 表示每分钟只能处理200个请求。
指令limit_req 中的burst=5 表示最大并发为5。即同一时间只能同时处理5个请求。
指令limit_req 中的 nodelay 表示当已经达到burst值时,再来新请求时,直接返回503
IF部分用于判断是否是百度蜘蛛的user agent。如果是,就对变量$anti_spider赋值。这样就做到了只对百度蜘蛛进行限制了。
详细的参数说明,可以查看官方文档。
http://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req_zone

这个模块对请求的限制采用了漏桶算法。
漏桶算法详见 http://baike.baidu.com/view/2054741.htm
相关代码请查看nginx源码文件 src/http/modules/ngx_http_limit_req_module.c
代码的核心部分是ngx_http_limit_req_lookup 方法。

Nginx发布1.9.0版本,新增支持TCP代理和负载均衡的stream模块

2016年12月5日 评论已被关闭

Nginx发布1.9.0版本,新增支持TCP代理和负载均衡的stream模块

http://www.lxway.com/918814204.htm

文章来源:http://zhangge.net/5037.html

昨天在公司微信群,CTO分享了这个消息,对运维来说以后基于TCP协议的后端业务的高可用又多了一个新的选择,实在是棒极了!

一直以来,Nginx 并不支持tcp协议,所以后台的一些基于TCP的业务就只能通过其他高可用负载软件来完成了,比如Haproxy。

Nginx发布1.9.0版本,新增支持TCP代理和负载均衡的stream模块

这算是一个nginx比较明显的缺憾。不过,在1.90发布后这个认知将得到改写:

2015-04-28 nginx-1.9.0 mainline version has been released, with the stream module for generic TCP proxying and load balancing.nginx-1.9.0 已发布,该版本增加了 stream 模块用于一般的 TCP 代理和负载均衡。

The ngx_stream_core_module module is available since version 1.9.0. This module is not built by default, it should be enabled with the –with-stream configuration parameter.

ngx_stream_core_module 这个模块在1.90版本后将被启用。但是并不会默认安装,需要在编译时通过指定 –with-stream 参数来激活这个模块。

其他改进包括:

  • Change: 删除过时的 aio 和 rtsig 事件处理方法
  • Feature: 可在 upstream 块中使用 “zone” 指令
  • Feature: 流模块,支持 TCP 代理和负载均衡
  • Feature: ngx_http_memcached_module 支持字节范围
  • Feature: Windows 版本支持使用共享内存,带随机化地址空间布局.
  • Feature: “error_log” 指令可在 mail 和 server 级别
  • Bugfix: the “proxy_protocol” parameter of the “listen” directive did not work if not specified in the first “listen” directive for a listen socket.

所以,我们如果需要用到这个功能,就需要加上 –with-stream 参数重新编译nginx。对于已在线上运行的nginx,你可能要用到平滑升级来避免线上的服务被中断,可以参考张戈以前分享的教程:

《Nginx在线服务状态下平滑升级或新增模块的详细操作记录》

最后贴一下官方分享的stream模块的简单配置demo:

http://nginx.org/en/docs/stream/ngx_stream_core_module.html

worker_processes auto;
error_log /var/log/nginx/error.log info;
events {
worker_connections  1024;
}

stream {
upstream backend {
hash $remote_addr consistent;
server backend1.example.com:12345 weight=5;
server 127.0.0.1:12345            max_fails=3 fail_timeout=30s;
server unix:/tmp/backend3;
}

server {
listen 12345;
proxy_connect_timeout 1s;
proxy_timeout 3s;
proxy_pass backend;
}

server {
listen [::1]:12345;
proxy_pass unix:/tmp/stream.socket;
}
}

和http模块类似,简单明了。相信熟悉 nginx 的朋友很容易的就能完成一个 nginx 下的 TCP 负载均衡集群配置。

由于工作繁忙,实在是心有余而力不足。还好最近公司给我招了个小鲜肉来做运维助理,等空下来了,我再去测一测这个 Nginx 的 TCP 代理和负载均衡功能。到时候再来博客分享一二,敬请期待!

 

下面测试nginx代理TCP协议的配置。

realserver : 10.134.241.68

nginx :10.134.72.166

客户端:10.129.157.168

TCP监听端口:2014

一、配置nginx

看官网上的文档 http://nginx.org/en/docs/stream/ngx_stream_core_module.html

nginx1.90对TCP协议的代理并不是默认开启的,需要在编译的时候配置 –with-stream 参数:

[img]http://images.cnitblog.com/blog2015/450613/201505/071746123452724.png[/img]

nginx.config文件参照官网:

stream {

upstream cloudsocket {

hash $remote_addr consistent;

server 10.134.241.68:2014 weight=5 max_fails=3 fail_timeout=30s;

}

server {

listen 2014;

proxy_connect_timeout 1s;

proxy_timeout 3s;

proxy_pass cloudsocket;

}

}

启动nginx,发现nginx已经开始监听2014端口了

Nginx发布1.9.0版本,新增支持TCP代理和负载均衡的stream模块

二、测试客户端连realserver

在客户端通过telnet连接realserver的2014端口:

Nginx发布1.9.0版本,新增支持TCP代理和负载均衡的stream模块

Nginx发布1.9.0版本,新增支持TCP代理和负载均衡的stream模块

在realserver上查看网络连接:

Nginx发布1.9.0版本,新增支持TCP代理和负载均衡的stream模块

可以正常连接

三、测试客户端连接nginx

在客户端通过telnet连接nginx所在服务器的2014端口

在nginx机器上查看网络连接

在realserver上查看网络连接

可以注意到nginx是给做了一个TCP连接的中转。

Nginx 的 TCP 负载均衡介绍

2016年12月5日 评论已被关闭

Nginx 的 TCP 负载均衡介绍

http://blog.jobbole.com/91757/

Nginx Plus的商业授权版开始具有TCP负载均衡的功能。从Nginx 1.7.7版本开始加入的,现在变成了一个商业收费版本,想要试用,需要在官网申请。也就是说,Nginx除了以前常用的HTTP负载均衡外,Nginx增加基于TCP协议实现的负载均衡方法。

HTTP负载均衡,也就是我们通常所有“七层负载均衡”,工作在第七层“应用层”。而TCP负载均衡,就是我们通常所说的“四层负载均衡”,工作在“网络层”和“传输层”。例如,LVS(Linux Virtual Server,Linux虚拟服务)和F5(一种硬件负载均衡设备),也是属于“四层负载均衡”。

 

TCP负载均衡的配置方式

Nginx使用了一个新的stream模块来实现TCP负载均衡,这个模块,类似于http和mail模块,允许我们配置一组监听TCP连接的服务。允许你配置多个服务的TCP连接,通过在upstream的server组中配置proxy_pass指令。

修改nginx.conf文件,在http模块的统计目录,添加一个stream模块(和http等同级):

 

TCP负载均衡的执行原理

当Nginx从监听端口收到一个新的客户端链接时,立刻执行路由调度算法,获得指定需要连接的服务IP,然后创建一个新的上游连接,连接到指定服务器。

TCP负载均衡支持Nginx原有的调度算法,包括Round Robin(默认,轮询调度),哈希(选择一致)等。同时,调度信息数据也会和健壮性检测模块一起协作,为每个连接选择适当的目标上游服务器。如果使用Hash负载均衡的调度方法,你可以使用$remote_addr(客户端IP)来达成简单持久化会话(同一个客户端IP的连接,总是落到同一个服务server上)。

和其他upstream模块一样,TCP的stream模块也支持自定义负载均和的转发权重(配置“weight=2”),还有backup和down的参数,用于踢掉失效的上游服务器。max_conns参数可以限制一台服务器的TCP连接数量,根据服务器的容量来设置恰当的配置数值,尤其在高并发的场景下,可以达到过载保护的目的。

Nginx监控客户端连接和上游连接,一旦接收到数据,则Nginx会立刻读取并且推送到上游连接,不会做TCP连接内的数据检测。Nginx维护一份内存缓冲区,用于客户端和上游数据的写入。如果客户端或者服务端传输了量很大的数据,缓冲区会适当增加内存的大小。

当Nginx收到任意一方的关闭连接通知,或者TCP连接被闲置超过了proxy_timeout配置的时间,连接将会被关闭。对于TCP长连接,我们更应该选择适当的proxy_timeout的时间,同时,关注监听socke的so_keepalive参数,防止过早地断开连接。

 

服务健壮性监控

TCP负载均衡模块支持内置健壮性检测,一台上游服务器如果拒绝TCP连接超过proxy_connect_timeout配置的时间,将会被认为已经失效。在这种情况下,Nginx立刻尝试连接upstream组内的另一台正常的服务器。连接失败信息将会记录到Nginx的错误日志中。

如果一台服务器,反复失败(超过了max_fails或者fail_timeout配置的参数),Nginx也会踢掉这台服务器。服务器被踢掉60秒后,Nginx会偶尔尝试重连它,检测它是否恢复正常。如果服务器恢复正常,Nginx将它加回到upstream组内,缓慢加大连接请求的比例。

之所“缓慢加大”,因为通常一个服务都有“热点数据”,也就是说,80%以上甚至更多的请求,实际都会被阻挡在“热点数据缓存”中,真正执行处理的请求只有很少的一部分。在机器刚刚启动的时候,“热点数据缓存”实际上还没有建立,这个时候爆发性地转发大量请求过来,很可能导致机器无法“承受”而再次挂掉。以mysql为例子,我们的mysql查询,通常95%以上都是落在了内存cache中,真正执行查询的并不多。

其实,无论是单台机器或者一个集群,在高并发请求场景下,重启或者切换,都存在这个风险,解决的途径主要是两种:

(1)请求逐步增加,从少到多,逐步积累热点数据,最终达到正常服务状态。
(2)提前准备好“常用”的数据,主动对服务做“预热”,预热完成之后,再开放服务器的访问。

TCP负载均衡原理上和LVS等是一致的,工作在更为底层,性能会高于原来HTTP负载均衡不少。但是,不会比LVS更为出色,LVS被置于内核模块,而Nginx工作在用户态,而且,Nginx相对比较重。另外一点,令人感到非常可惜,这个模块竟然是个付费功能。(补注:本文写于 2015 年 1 月,当初这个模块是收费的)

服务器TIME_WAIT和CLOSE_WAIT详解和解决办法

2016年12月4日 评论已被关闭

服务器TIME_WAIT和CLOSE_WAIT详解和解决办法

来自:http://blog.csdn.net/shootyou/article/details/6622226

 

昨天解决了一个HttpClient调用错误导致的服务器异常,具体过程如下:

http://blog.csdn.net/shootyou/article/details/6615051

里头的分析过程有提到,通过查看服务器网络状态检测到服务器有大量的CLOSE_WAIT的状态。

 

在服务器的日常维护过程中,会经常用到下面的命令:

  1. netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

它会显示例如下面的信息:

TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1

常用的三个状态是:ESTABLISHED 表示正在通信,TIME_WAIT 表示主动关闭,CLOSE_WAIT 表示被动关闭。

 

具体每种状态什么意思,其实无需多说,看看下面这种图就明白了,注意这里提到的服务器应该是业务请求接受处理的一方:

 

这么多状态不用都记住,只要了解到我上面提到的最常见的三种状态的意义就可以了。一般不到万不得已的情况也不会去查看网络状态,如果服务器出了异常,百分之八九十都是下面两种情况:

1.服务器保持了大量TIME_WAIT状态

2.服务器保持了大量CLOSE_WAIT状态

因为linux分配给一个用户的文件句柄是有限的(可以参考:http://blog.csdn.net/shootyou/article/details/6579139),而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持,那么意味着对应数目的通道就一直被占着,而且是“占着茅坑不使劲”,一旦达到句柄数上限,新的请求就无法被处理了,接着就是大量Too Many Open Files异常,tomcat崩溃。。。

下 面来讨论下这两种情况的处理方法,网上有很多资料把这两种情况的处理方法混为一谈,以为优化系统内核参数就可以解决问题,其实是不恰当的,优化系统内核参 数解决TIME_WAIT可能很容易,但是应对CLOSE_WAIT的情况还是需要从程序本身出发。现在来分别说说这两种情况的处理方法:

 

1.服务器保持了大量TIME_WAIT状态

这种情况比较常见,一些爬虫服务器或者WEB服务器(如果网管在安装的时候没有做内核参数优化的话)上经常会遇到这个问题,这个问题是怎么产生的呢?

从 上面的示意图可以看得出来,TIME_WAIT是主动关闭连接的一方保持的状态,对于爬虫服务器来说他本身就是“客户端”,在完成一个爬取任务之后,他就 会发起主动关闭连接,从而进入TIME_WAIT的状态,然后在保持这个状态2MSL(max segment lifetime)时间之后,彻底关闭回收资源。为什么要这么做?明明就已经主动关闭连接了为啥还要保持资源一段时间呢?这个是TCP/IP的设计者规定 的,主要出于以下两个方面的考虑:

1.防止上一次连接中的包,迷路后重新出现,影响新连接(经过2MSL,上一次连接中所有的重复包都会消失)
2. 可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ,就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源,并不会占用很大资源的,除非短时间内接受大量请求或者受到攻击。

关于MSL引用下面一段话:

  1. MSL 為 一個 TCP Segment (某一塊 TCP 網路封包) 從來源送到目的之間可續存的時間 (也就是一個網路封包在網路上傳輸時能存活的時間),由 於 RFC 793 TCP 傳輸協定是在 1981 年定義的,當時的網路速度不像現在的網際網路那樣發達,你可以想像你從瀏覽器輸入網址等到第一 個 byte 出現要等 4 分鐘嗎?在現在的網路環境下幾乎不可能有這種事情發生,因此我們大可將 TIME_WAIT 狀態的續存時間大幅調低,好 讓 連線埠 (Ports) 能更快空出來給其他連線使用。

再引用网络资源的一段话:

  1. 值 得一说的是,对于基于TCP的HTTP协议,关闭TCP连接的是Server端,这样,Server端会进入TIME_WAIT状态,可 想而知,对于访 问量大的Web Server,会存在大量的TIME_WAIT状态,假如server一秒钟接收1000个请求,那么就会积压 240*1000=240,000个 TIME_WAIT的记录,维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些 TIME_WAIT,所以对于新的 TCP连接请求,判断是否hit中一个TIME_WAIT不会太费时间,但是有这么多状态要维护总是不好。
  2. HTTP协议1.1版规定default行为是Keep-Alive,也就是会重用TCP连接传输多个 request/response,一个主要原因就是发现了这个问题。

也就是说HTTP的交互跟上面画的那个图是不一样的,关闭连接的不是客户端,而是服务器,所以web服务器也是会出现大量的TIME_WAIT的情况的。

现在来说如何来解决这个问题。
解决思路很简单,就是让服务器能够快速回收和重用那些TIME_WAIT的资源。
下面来看一下我们网管对/etc/sysctl.conf文件的修改:
  1. #对于一个新建连接,内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255,默认值是5,对应于180秒左右时间
  2. net.ipv4.tcp_syn_retries=2
  3. #net.ipv4.tcp_synack_retries=2
  4. #表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为300秒
  5. net.ipv4.tcp_keepalive_time=1200
  6. net.ipv4.tcp_orphan_retries=3
  7. #表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间
  8. net.ipv4.tcp_fin_timeout=30
  9. #表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。
  10. net.ipv4.tcp_max_syn_backlog = 4096
  11. #表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭
  12. net.ipv4.tcp_syncookies = 1
  13. #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭
  14. net.ipv4.tcp_tw_reuse = 1
  15. #表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭
  16. net.ipv4.tcp_tw_recycle = 1
  17. ##减少超时前的探测次数
  18. net.ipv4.tcp_keepalive_probes=5
  19. ##优化网络设备接收队列
  20. net.core.netdev_max_backlog=3000
修改完之后执行/sbin/sysctl -p让参数生效。
这里头主要注意到的是net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_recycle
net.ipv4.tcp_fin_timeout
net.ipv4.tcp_keepalive_*
这几个参数。
net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的开启都是为了回收处于TIME_WAIT状态的资源。
net.ipv4.tcp_fin_timeout这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间。
net.ipv4.tcp_keepalive_*一系列参数,是用来设置服务器检测连接存活的相关配置。
2.服务器保持了大量CLOSE_WAIT状态
休息一下,喘口气,一开始只是打算说说TIME_WAIT和CLOSE_WAIT的区别,没想到越挖越深,这也是写博客总结的好处,总可以有意外的收获。
TIME_WAIT状态可以通过优化服务器参数得到解决,因为发生TIME_WAIT的情况是服务器自己可控的,要么就是对方连接的异常,要么就是自己没有迅速回收资源,总之不是由于自己程序错误导致的。
但 是CLOSE_WAIT就不一样了,从上面的图可以看出来,如果一直保持在CLOSE_WAIT状态,那么只有一种情况,就是在对方关闭连接之后服务器程 序自己没有进一步发出ack信号。换句话说,就是在对方连接关闭之后,程序里没有检测到,或者程序压根就忘记了这个时候需要关闭连接,于是这个资源就一直 被程序占着。个人觉得这种情况,通过服务器内核参数也没办法解决,服务器对于程序抢占的资源没有主动回收的权利,除非终止程序运行。
如果你使用的是HttpClient并且你遇到了大量CLOSE_WAIT的情况,那么这篇日志也许对你有用:http://blog.csdn.net/shootyou/article/details/6615051
在那边日志里头我举了个场景,来说明CLOSE_WAIT和TIME_WAIT的区别,这里重新描述一下:
服 务器A是一台爬虫服务器,它使用简单的HttpClient去请求资源服务器B上面的apache获取文件资源,正常情况下,如果请求成功,那么在抓取完 资源后,服务器A会主动发出关闭连接的请求,这个时候就是主动关闭连接,服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢?假设 请求的资源服务器B上并不存在,那么这个时候就会由服务器B发出关闭连接的请求,服务器A就是被动的关闭了连接,如果服务器A被动关闭连接之后程序员忘了 让HttpClient释放连接,那就会造成CLOSE_WAIT的状态了。
所以如果将大量CLOSE_WAIT的解决办法总结为一句话那就是:查代码。因为问题出在服务器程序里头啊。
参考资料:
1.windows下的TIME_WAIT的处理可以参加这位大侠的日志:http://blog.miniasp.com/post/2010/11/17/How-to-deal-with-TIME_WAIT-problem-under-Windows.aspx
3.各种内核参数的含义:http://haka.sharera.com/blog/BlogTopic/32309.htm
4.linux服务器历险之sysctl优化linux网络:http://blog.csdn.net/chinalinuxzend/article/details/1792184

nginx大量TIME_WAIT的解决办法

2016年12月4日 评论已被关闭

nginx大量TIME_WAIT的解决办法

http://www.tuicool.com/articles/iiQJbmn

由于网站使用nginx做的反向代理he负载均衡。在没有默认的系统TCP参数情况下回导致大量的TIME_WAIT出现。

终端可以下敲入

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 8535
CLOSE_WAIT 5
FIN_WAIT2 20
ESTABLISHED 248
LAST_ACK 14
CLOSED:无连接是活动的或正在进行
LISTEN:服务器在等待进入呼叫
SYN_RECV:一个连接请求已经到达,等待确认
SYN_SENT:应用已经开始,打开一个连接
ESTABLISHED:正常数据传输状态
FIN_WAIT1:应用说它已经完成
FIN_WAIT2:另一边已同意释放
ITMED_WAIT:等待所有分组死掉
CLOSING:两边同时尝试关闭
TIME_WAIT:另一边已初始化一个释放
LAST_ACK:等待所有分组死掉

解决办法 修改内核参数

vi /etc/sysctl.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse=1 #让TIME_WAIT状态可以重用,这样即使TIME_WAIT占满了所有端口,也不会拒绝新的请求造成障碍 默认是0
net.ipv4.tcp_tw_recycle=1 #让TIME_WAIT尽快回收 默认0
net.ipv4.tcp_fin_timeout=30
/sbin/sysctl -p 让修改生效

在查看,已经恢复正常

TIME_WAIT 69
CLOSE_WAIT 4
FIN_WAIT2 15
ESTABLISHED 236
LAST_ACK 1
分类: LNMP应用服务器 标签:

nginx 优化(突破十万并发)

2016年12月4日 评论已被关闭

nginx 优化(突破十万并发)
http://blog.chinaunix.net/uid-25266990-id-2985541.html
一般来说nginx 配置文件中对优化比较有作用的为以下几项:
worker_processes 8;
nginx 进程数,建议按照cpu 数目来指定,一般为它的倍数。
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
为每个进程分配cpu,上例中将8 个进程分配到8 个cpu,当然可以写多个,或者将一
个进程分配到多个cpu。
worker_rlimit_nofile 102400;
这个指令是指当一个nginx 进程打开的最多文件描述符数目,理论值应该是最多打开文
件数(ulimit -n)与nginx 进程数相除,但是nginx 分配请求并不是那么均匀,所以最好与ulimit -n 的值保持一致。
use epoll;
使用epoll 的I/O 模型
worker_connections 102400;
每个进程允许的最多连接数, 理论上每台nginx 服务器的最大连接数为worker_processes*worker_connections。
keepalive_timeout 60;
keepalive 超时时间。
client_header_buffer_size 4k;
客户端请求头部的缓冲区大小,这个可以根据你的系统分页大小来设置,一般一个请求
头的大小不会超过1k,不过由于一般系统分页都要大于1k,所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE 取得。
open_file_cache max=102400 inactive=20s;
这个将为打开文件指定缓存,默认是没有启用的,max 指定缓存数量,建议和打开文件数一致,inactive 是指经过多长时间文件没被请求后删除缓存。
open_file_cache_valid 30s;
这个是指多长时间检查一次缓存的有效信息。
open_file_cache_min_uses 1;
open_file_cache 指令中的inactive 参数时间内文件的最少使用次数,如果超过这个数字,文件描述符一直是在缓存中打开的,如上例,如果有一个文件在inactive 时间内一次没被使用,它将被移除。
关于内核参数的优化:
net.ipv4.tcp_max_tw_buckets = 6000
timewait 的数量,默认是180000。
net.ipv4.ip_local_port_range = 1024 65000
允许系统打开的端口范围。
net.ipv4.tcp_tw_recycle = 1
启用timewait 快速回收。
net.ipv4.tcp_tw_reuse = 1
开启重用。允许将TIME-WAIT sockets 重新用于新的TCP 连接。
net.ipv4.tcp_syncookies = 1
开启SYN Cookies,当出现SYN 等待队列溢出时,启用cookies 来处理。
net.core.somaxconn = 262144
web 应用中listen 函数的backlog 默认会给我们内核参数的net.core.somaxconn 限制到128,而nginx 定义的NGX_LISTEN_BACKLOG 默认为511,所以有必要调整这个值。
net.core.netdev_max_backlog = 262144
每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许送到队列的数据包的最大数目。
net.ipv4.tcp_max_orphans = 262144
系统中最多有多少个TCP 套接字不被关联到任何一个用户文件句柄上。如果超过这个数字,孤儿连接将即刻被复位并打印出警告信息。这个限制仅仅是为了防止简单的DoS 攻击,不能过分依靠它或者人为地减小这个值,更应该增加这个值(如果增加了内存之后)。
net.ipv4.tcp_max_syn_backlog = 262144
记录的那些尚未收到客户端确认信息的连接请求的最大值。对于有128M 内存的系统而言,缺省值是1024,小内存的系统则是128。
net.ipv4.tcp_timestamps = 0
时间戳可以避免序列号的卷绕。一个1Gbps 的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种“异常”的数据包。这里需要将其关掉。
net.ipv4.tcp_synack_retries = 1
为了打开对端的连接,内核需要发送一个SYN 并附带一个回应前面一个SYN 的ACK。也就是所谓三次握手中的第二次握手。这个设置决定了内核放弃连接之前发送SYN+ACK 包的数量。
net.ipv4.tcp_syn_retries = 1
在内核放弃建立连接之前发送SYN 包的数量。
net.ipv4.tcp_fin_timeout = 1
如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2 状态的时间。对端可以出错并永远不关闭连接,甚至意外当机。缺省值是60 秒。2.2 内核的通常值是180 秒,3你可以按这个设置,但要记住的是,即使你的机器是一个轻载的WEB 服务器,也有因为大量的死套接字而内存溢出的风险,FIN- WAIT-2 的危险性比FIN-WAIT-1 要小,因为它最多只能吃掉1.5K 内存,但是它们的生存期长些。
net.ipv4.tcp_keepalive_time = 30
当keepalive 起用的时候,TCP 发送keepalive 消息的频度。缺省是2 小时。
下面贴一个完整的内核优化设置:
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 16384 4194304
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 262144
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 30
net.ipv4.ip_local_port_range = 1024 65000
下面是一个简单的nginx 配置文件:
user www www;
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000
01000000;
error_log /www/log/nginx_error.log crit;
pid /usr/local/nginx/nginx.pid;
worker_rlimit_nofile 204800;
events
{
use epoll;
worker_connections 204800;
}
http
{
include mime.types;
default_type application/octet-stream;
charset utf-8;
server_names_hash_bucket_size 128;
client_header_buffer_size 2k;
large_client_header_buffers 4 4k;
client_max_body_size 8m;
sendfile on;
tcp_nopush on;
keepalive_timeout 60;
fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2
keys_zone=TEST:10m
inactive=5m;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 4k;
fastcgi_buffers 8 4k;
fastcgi_busy_buffers_size 8k;
fastcgi_temp_file_write_size 8k;
fastcgi_cache TEST;
fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;
fastcgi_cache_min_uses 1;
fastcgi_cache_use_stale error timeout invalid_header http_500;
open_file_cache max=204800 inactive=20s;
open_file_cache_min_uses 1;
open_file_cache_valid 30s;
tcp_nodelay on;
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;
server
{
listen 8080;
server_name backup.aiju.com;
index index.php index.htm;
root /www/html/;
location /status
{
stub_status on;
}
location ~ .*\.(php|php5)?$
{
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fcgi.conf;
}
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|js|css)$
{
expires 30d;
}
log_format access ‘$remote_addr — $remote_user [$time_local] “$request” ‘
‘$status $body_bytes_sent “$http_referer” ‘
‘”$http_user_agent” $http_x_forwarded_for’;
access_log /www/log/access.log access;
}
}
关于FastCGI 的几个指令:
fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10minactive=5m;
这个指令为FastCGI 缓存指定一个路径,目录结构等级,关键字区域存储时间和非活动删除时间。
fastcgi_connect_timeout 300;
指定连接到后端FastCGI 的超时时间。
fastcgi_send_timeout 300;
向FastCGI 传送请求的超时时间,这个值是指已经完成两次握手后向FastCGI 传送请求的超时时间。
fastcgi_read_timeout 300;
接收FastCGI 应答的超时时间,这个值是指已经完成两次握手后接收FastCGI 应答的超时时间。
fastcgi_buffer_size 4k;
指定读取FastCGI 应答第一部分需要用多大的缓冲区,一般第一部分应答不会超过1k,由于页面大小为4k,所以这里设置为4k。
fastcgi_buffers 8 4k;
指定本地需要用多少和多大的缓冲区来缓冲FastCGI 的应答。
fastcgi_busy_buffers_size 8k;
这个指令我也不知道是做什么用,只知道默认值是fastcgi_buffers 的两倍。
fastcgi_temp_file_write_size 8k;
在写入fastcgi_temp_path 时将用多大的数据块,默认值是fastcgi_buffers 的两倍。
fastcgi_cache TEST
开启FastCGI 缓存并且为其制定一个名称。个人感觉开启缓存非常有用,可以有效降低CPU 负载,并且防止502 错误。
fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;
为指定的应答代码指定缓存时间,如上例中将200,302 应答缓存一小时,301 应答缓存1 天,其他为1 分钟。
fastcgi_cache_min_uses 1;
缓存在fastcgi_cache_path 指令inactive 参数值时间内的最少使用次数,如上例,如果在5 分钟内某文件1 次也没有被使用,那么这个文件将被移除。
fastcgi_cache_use_stale error timeout invalid_header http_500;
不知道这个参数的作用,猜想应该是让nginx 知道哪些类型的缓存是没用的。以上为nginx 中FastCGI 相关参数,另外,FastCGI 自身也有一些配置需要进行优化,如果你使用php-fpm 来管理FastCGI,可以修改配置文件中的以下值:
60
同时处理的并发请求数,即它将开启最多60 个子线程来处理并发连接。
102400
最多打开文件数。
204800
每个进程在重置之前能够执行的最多请求数。
下面贴几张测试结果图。
下图为同时在6 台机器运行webbench -c 30000 -t 600 http://backup.aiju.com:8080/index.html 命令后的测试结果:
webbench
使用netstat 过滤后的连接数:
netstat
php 页面在status 中的结果(php 页面为调用phpinfo):

php 页面在netstat 过滤后的连接数:

未使用FastCGI 缓存之前的服务器负载:

此时打开php 页面已经有些困难,需要进行多次刷新才能打开。上图中cpu0 负载偏低
是因为测试时将网卡中断请求全部分配到cpu0 上,并且在nginx 中开启7 个进程分别制定到cpu1-7。
使用FastCGI 缓存之后:

此时可以很轻松的打开php 页面。
这个测试并没有连接到任何数据库,所以并没有什么参考价值,不过不知道上述测试是否已经到达极限,根据内存和cpu 的使用情况来看似乎没有,但是已经没有多余的机子来让我运行webbench 了。囧
转载自 http://bbs.linuxtone.org/thread-4504-1-1.html