worker_processes 1;
events {
        worker_connections 1024;
}

http {
        include         mime.types;
        default_type    application/octet-stream;
        sendfile        on;
        keepalive_timeout 65;
        geo $cmccip {
                default 1;　　　#　未定义ip的值为1
                include cmcc.conf; 加载geo.conf文件，这个文件定义移动网关ip
        }
        server {
                listen 801;
                server_name XXXXX;
                location / {
                        if ($cmccip) {
                                rewrite ^ http://tx.com.cn;   未定义ip即非移动ip重定向到tx.com.cn;
                        }
                        root /data/www;
                        index index.wml index.html;

                }
        }
}

cmcc.conf文件内容如下：
211.136.222.90/32 0;

CPU：Xeon2.8G X2 
RAM：4G
OS：RedHat As5.3 X64

工具：apache ab
参数：ab -i -c 500 -n 100000

最终服务端：2个squid 需实现均衡负载

成绩如下：

####### Nginx + haproxy :  (由Nginx通过反向代理发送请求至haproxy, 并由其进行均衡负载)

Concurrency Level:      500
Time taken for tests:   53.758 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      38600386 bytes
HTML transferred:       0 bytes
Requests per second:    1860.19 [#/sec] (mean)
Time per request:       268.790 [ms] (mean)
Time per request:       0.538 [ms] (mean, across all concurrent requests)
Transfer rate:          701.21 [Kbytes/sec] received

####### haproxy :  (单独由haproxy进行均衡负载)

Concurrency Level:      500
Time taken for tests:   32.562 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      36606588 bytes
HTML transferred:       0 bytes
Requests per second:    3071.02 [#/sec] (mean)
Time per request:       162.812 [ms] (mean)
Time per request:       0.326 [ms] (mean, across all concurrent requests)
Transfer rate:          1097.85 [Kbytes/sec] received

####### nginx : (单独由nginx进行均衡负载)

Concurrency Level:      500
Time taken for tests:   36.539 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      38600000 bytes
HTML transferred:       0 bytes
Requests per second:    2736.82 [#/sec] (mean)
Time per request:       182.694 [ms] (mean)
Time per request:       0.365 [ms] (mean, across all concurrent requests)
Transfer rate:          1031.65 [Kbytes/sec] received

反复测试，得出其结果：

Haproxy 单独进行均衡负载的性能最强，超过了Nginx。
然而 Nginx + Haproxy 的搭配性能最弱，应该是跟通过了2层反向代理有关。

所以想用 Haproxy 替代 Nginx 所自带的均衡负载功能将会令性能打折。
但 Nginx 的配置法则确远比 Haproxy 灵活。

还是视乎用途而决定吧。

HK 访问起来速度还是不错的，但宽带很少，最大只有2M，超过的话访问会越来越慢。

我在广州设立了squid缓存服务器的架构，分发了所有静态文件。基本上HK 就只有主页的php 传输了。
但这也不小，用 Firebug 查看，首页基本上都有10K 再+上其余的重定向数据。再小20K 左右走不掉。

经过调优，强制启用了Nginx反向代理中也使用 gzip，即 （内陆Nginx） –> gzip –> （香港Nginx） –> gzip –> 用户

流量缩少了10% 但还是处于紧张边缘。
查看 HTTP 访问日志，得出有 google baidu 等蜘蛛抓得也挺狠！于是想到，能不能把搜索引擎的爬虫也从定向到内陆的服务器减少负担？

于是就有了以下这个 Nginx 的配置：

香港配置：

        if ($http_user_agent ~* (baiduspider|googlebot|soso|bing|sogou|yahoo|sohu-search|yodao|YoudaoBot|robozilla|msnbot|MJ12bot|NHN|Twiceler)) {
            rewrite  ^/(.*)$  http://gznow.spider.someqone.com/$1  permanent;
        }
直接+到 server {   里头即可。意思为：
匹配客户端User agent 不分大小写，凡是含有 baidu，google，bing….
之类爬虫。从定向到指定地址，并匹配原有 url 后续 即:

http://www.gznow.org/bbs/index.php
301 从定性为：
http://gznow.spider.someqone.com/bbs/index.php

这样的话既不影响搜索引擎的收录，也可以把流量分配给其他的服务器。
但如果日后搜索引擎收录的访问地址也成了从定向的地址咋办？
所以就要再多一步，把从定向的目的服务器配置一下：

        if ($http_user_agent ~* (Safari|Navigator|Chrome|Opera|Firefox|msie)) {
            rewrite  ^/(.*)$  http://www.gznow.org/$1  permanent;
        }

也是直接加到 server { 即可
原来跟处理爬虫的一样，不分大小写匹配 user agent 中包含的主流浏览器 msie , firefox , chrome….
从定向到指定地址，并匹配原有 url 后续.
这样即使访客由搜索引擎指引到了从定向的服务器，也能从定向回去。

呵，特殊例子，分享一下。
这么一作，我HK 服务器的流量可立马又省下了 30% 。 放心了不少。

squid不支持常见的gzip压缩的原因，有以下两点:

1,   squid只支持gzip的静态压缩，不支持动态压缩。具体一点说，就是response header里必须有content-length, 不可以用chunked方式。

2,   response header中必须有Vary : Accept-Encoding

只要具备以上几点，squid就可以完美的识别压缩和不压缩的内容。

下面说一下nginx针对这个问题的解决方案:

nginx默认的NginxHttpGzipModule, 采用的是chunked方式的动态压缩，而squid是不支持的。需要使用http_gzip_static_module这个模块，进行pre-compress。

具体方法如下:

ngx_http_gzip_static_module was introduced in nginx 0.6.24. You must enable support at compile time:

./configure –with-http_gzip_static_module …

配置文件写法:

gzip          on

gzip_static on;

gzip_http_version 1.0;
gzip_proxied        any;
gzip_disable        “MSIE [1-6]\.”;

gzip_comp_level     9;

注意，这里没有加入gzip_vary on;。这是因为http_gzip_static_module这个模块，只给没压缩的内容加入了vary header，而不是所有内容都加。
所以不能打开这个参数。可以在nginx.conf中手动设置vary header。这样不管压缩与否，返回的文件都会被加上Vary: Accept-Encoding。

至此，nginx的gzip压缩，就能够被squid完美支持了。如果你使用Http1.0，就会返回你没压缩的内容。如果你使用http1.1，并且发送Accept-Encoding:gzip,deflate，就会返回压缩后的内容。

PS: 我又发现了一个问题，就是squid的cache保存问题。按照文档上说，squid是根据url来缓存对象的。
   也就是说，一个url应该只保留一个cache。如果你交替的申请压缩的和不压缩的内容，是会出现反复MISS的情况的。
   但是我实际测试的过程中，发现不是这样的，交替的申请压缩的和不压缩的内容，是会一直HIT的。这说明squid是同时保存两份cache的(压缩的和不压缩的)。

但这里就有个怪点子，能不能让客户端无论有没有发送Accept-Encoding，服务器都会发送压缩内容呢？

这有几个好处：

1、进一步节省带宽。
2、防止水平一般的爬虫抓页面偷数据。

经测试，此种做法并不会影响普通用户，因为他们都是用先进的浏览器上网的；另外，也不会影响主流的搜索引擎，收录仍然会正常。

要做到这点，需要有两个nginx，但也有办法配置两个虚拟主机就可以，不用启动两个nginx主进程。为了方便，我就以前后来区分它们。

前端nginx：

gzip压缩不在前端nginx进行，前端主要是用来强制修改request header，即写上：

这样，后台的nginx无论如何都将接收到Accept-Encoding:gzip，而不管客户端有没有发。

完整的测试样本：

1. server 127.0.0.1:80;
2. }
3. server {
4. server_name www.gznow.org;
5. listen 80;
6. location / {
7.   proxy_pass http://219.x.x.x;
8.   include proxy.conf;
9.   proxy_set_header Accept-Encoding ‘gzip’;
10. }
11. }

要注意proxy.conf里最好没有写过proxy_set_header Accept-Encoding，我的proxy.conf默认有将Accept-Encoding设为空的，这会造成配置重复。但proxy_set_header不会冲突，可以按配置先后顺序生效，我一时忘了是前生效还是后生效，动手测一下便知。

后端nginx：

后端nginx才是负责压缩的，这里要注意gzip的版本，因为nginx是用http1.0方式作代理，因此gzip的版本就不能是默认的1.1版，改成1.0。

1. server {
2. server_name www.gznow.org;
3. listen 80;
4. location / {
5.   root /html/;
6.   gzip on;
7.   gzip_http_version 1.0;
8. }
9. }

这里就简单点了，gzip的其他参数我就不贴上来，想必大家都有现成的配置，留意下version就好。

配好后，测试一下：

1. curl -I http://www.gznow.org/bbs/index.php

发现返回了Content-Encoding:gzip

不加-I参数呢？

1. curl http://www.gznow.org/bbs/index.php

打印出一堆乱码，把SecureCRT的字符都给弄坏了。

也可以通过以下工具来测试压缩成效 http://gzip.zzbaike.com/

例如主站上有动态文件，也有静态文件。
为了让用户有更快速的体验，一般都会把动态文件的请求跟静态文件分开。
把流量分摊给其他外部节点的 squid 服务器等。

这么我就分享一个配置，不用对程序做任何改动，就可实现静态文件重定向。

        location ~* \.(gif|jpg|png|swf|flv|rar|zip|exe|bmp)$ {
            rewrite  ^/(.*)$  http://img.gxxxx.cn:1394/$1  permanent;
        }

修改后的结果是：

当访问： http://www.gxxxx.cn/bbs/photo/logo.gif
即永久从定向至：http://img.gxxxx.cn:1394/bbs/photo/logo.gif

为了安全，可以关闭这些信息。

方法很简单，只需在 nginx.conf 的 http {  里头加入 server_tokens 的参数
例如：

http {
    include       mime.types;
    default_type  application/octet-stream;
    server_tokens off;     #关闭版本显示
    client_header_timeout       3m;
    client_body_timeout         3m;
    send_timeout                3m;

使用 curl 工具测试结果如下：

HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Fri, 11 Dec 2009 01:47:53 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Keep-Alive: timeout=20
Location: http://www.gznow.cn/index

如果想把 Server 所显示的名称也修改，可以参阅：http://www.oschina.net/bbs/thread/1568?lp=1

Nginx 占用 80 端口，过滤静态请求，然后动态请求即 Proxy 到 Apache 的 8080 端口。
Proxy 反向代理的好处是访问的时候，始终就是 80 端口，来访者不会觉察到有任何的区别。

但有的应用确非常“聪明”，识别到 Apache 所位于的端口是 8080 ，就会把相关的超链接都一并加上 :8080 的后续。这么就死定了，还能有正常访问麽？！

有个方法可以解决这事，就是把 apache 也运行在80端口上。
同一台服务器，有Nginx 也有 Apache，2个httpd服务，都是80，不会冲突麽？

下边就是举例方法。

Nginx.conf 的配置中

server {

listen 80;
server_name www.ABC.com;

}

修改一下。

server {

listen 192.168.3.3:80;       #指定Nginx只占用某个IP的80端口。
listen 192.168.10.3:80;           #如果你服务器中有多个IP，还可以指定多个。
server_name www.ABC.com;

}

如果你在Nginx有多个虚拟主机，每一个都需要这么修改。

然后轮到 apache 的 httpd.conf

把原来的

Listen 80

改为

Listen 127.0.0.1:80

跟Nginx一样，指定apache所占用的IP及端口。
保存退出，重启apache即可生效。
如果你 apache 上也有多个虚拟主机。无需好像Nginx那样逐一修改，只要都是 80 端口既可。

如：

NameVirtualHost *:80

<VirtualHost *:80>
    ServerAdmin hello@abc.com
    DocumentRoot /data/web_server/admin
    ServerName www.ABC.com
</VirtualHost>

这样，Nginx 跟 Apache 就仅会占用指定IP的80端口，不会冲突。
只要调整一下 Nginx proxy 的参数。
“聪明”应用问题就能解决了。

所以，我们要在 Nginx 配置中把这一目录的访问都拒绝掉。
由于其 .svn 的目录名较为特殊，需要用到正则表达式，写法如下：

        location ~ ^(.*)\/\.svn\/{
        deny all;
        }

同理，.cvs 也需要这样。

TCP_NODELAY 和 TCP_CORK，
这两个选项都对网络连接的行为具有重要的作用。许多UNIX系统都实现了TCP_NODELAY选项，但是，TCP_CORK则是Linux系统所独有的 而且相对较新；它首先在内核版本2.4上得以实现。此外，其他UNIX系统版本也有功能类似的选项，值得注意的是，在某种由BSD派生的系统上的 TCP_NOPUSH选项其实就是TCP_CORK的一部分具体实现。
TCP_NODELAY和TCP_CORK基本上控制了包的“Nagle化”，Nagle化在这里的含义是采用Nagle算法把较小的包组装为更大的帧。 John Nagle是Nagle算法的发明人，后者就是用他的名字来命名的，他在1984年首次用这种方法来尝试解决福特汽车公司的网络拥塞问题（欲了解详情请参 看IETF RFC 896）。他解决的问题就是所谓的silly window syndrome ，中文称“愚蠢窗口症候群”，具体含义是，因为普遍终端应用程序每产生一次击键操作就会发送一个包，而典型情况下一个包会拥有一个字节的数据载荷以及40 个字节长的包头，于是产生4000%的过载，很轻易地就能令网络发生拥塞,。 Nagle化后来成了一种标准并且立即在因特网上得以实现。它现在已经成为缺省配置了，但在我们看来，有些场合下把这一选项关掉也是合乎需要的。
现在让我们假设某个应用程序发出了一个请求，希望发送小块数据。我们可以选择立即发送数据或者等待产生更多的数据然后再一次发送两种策略。如果我们马上发 送数据，那么交互性的以及客户/服务器型的应用程序将极大地受益。例如，当我们正在发送一个较短的请求并且等候较大的响应时，相关过载与传输的数据总量相 比就会比较低，而且，如果请求立即发出那么响应时间也会快一些。以上操作可以通过设置套接字的TCP_NODELAY选项来完成，这样就禁用了Nagle 算法。
另外一种情况则需要我们等到数据量达到最大时才通过网络一次发送全部数据，这种数据传输方式有益于大量数据的通信性能，典型的应用就是文件服务器。应用 Nagle算法在这种情况下就会产生问题。但是，如果你正在发送大量数据，你可以设置TCP_CORK选项禁用Nagle化，其方式正好同 TCP_NODELAY相反（TCP_CORK 和 TCP_NODELAY 是互相排斥的）。下面就让我们仔细分析下其工作原理。
假设应用程序使用sendfile()函数来转移大量数据。应用协议通常要求发送某些信息来预先解释数据，这些信息其实就是报头内容。典型情况下报头很 小，而且套接字上设置了TCP_NODELAY。有报头的包将被立即传输，在某些情况下（取决于内部的包计数器），因为这个包成功地被对方收到后需要请求 对方确认。这样，大量数据的传输就会被推迟而且产生了不必要的网络流量交换。
但是，如果我们在套接字上设置了TCP_CORK（可以比喻为在管道上插入“塞子”）选项，具有报头的包就会填补大量的数据，所有的数据都根据大小自动地 通过包传输出去。当数据传输完成时，最好取消TCP_CORK 选项设置给连接“拔去塞子”以便任一部分的帧都能发送出去。这同“塞住”网络连接同等重要。
总而言之，如果你肯定能一起发送多个数据集合（例如HTTP响应的头和正文），那么我们建议你设置TCP_CORK选项，这样在这些数据之间不存在延迟。能极大地有益于WWW、FTP以及文件服务器的性能，同时也简化了你的工作。示例代码如下：

intfd, on = 1;
…
/* 此处是创建套接字等操作，出于篇幅的考虑省略*/
…
setsockopt (fd, SOL_TCP, TCP_CORK, &on, sizeof (on)); /* cork */
write (fd, …);
fprintf (fd, …);
sendfile (fd, …);
write (fd, …);
sendfile (fd, …);
…
on = 0;
setsockopt (fd, SOL_TCP, TCP_CORK, &on, sizeof (on)); /* 拔去塞子 */

不幸的是，许多常用的程序并没有考虑到以上问题。例如，Eric Allman编写的sendmail就没有对其套接字设置任何选项。

Apache HTTPD是因特网上最流行的Web服务器，它的所有套接字就都设置了TCP_NODELAY选项，而且其性能也深受大多数用户的满意。这是为什么呢？答 案就在于实现的差别之上。由BSD衍生的TCP/IP协议栈（值得注意的是FreeBSD）在这种状况下的操作就不同。当在TCP_NODELAY 模式下提交大量小数据块传输时，大量信息将按照一次write()函数调用发送一块数据的方式发送出去。然而，因为负责请求交付确认的记数器是面向字节而 非面向包（在Linux上）的，所以引入延迟的概率就降低了很多。结果仅仅和全部数据的大小有关系。而 Linux 在第一包到达之后就要求确认，FreeBSD则在进行如此操作之前会等待好几百个包。

在Linux系统上，TCP_NODELAY的效果同习惯于BSD TCP/IP协议栈的开发者所期望的效果有很大不同，而且在Linux上的Apache性能表现也会更差些。其他在Linux上频繁采用TCP_NODELAY的应用程序也有同样的问题。

< end .entry-content >