在nginx中配置访问限制，比如限制附件下限速度，限制每个用户的访问速度，限制每个IP的链接速度等需求。
先看我的nginx配置，很简单，只需3行，打开“nginx根目录/conf/nginx.conf”配置文件修改如下：
limit_zone one $binary_remote_addr 10m;
server {
location / {
limit_conn one 2 ;
limit_rate 40k;
}
}
}
解释：limit_zone针对每个IP定义一个存储session状态的容器。
以上定义了一个名叫one的10m大小的容器，这个名字会在后面的limit_conn中使用。
limit_conn指定每个访客只能建立两条链接，limit_rate限制每条链接的速度不超过40K。
所以，以上配置限制用户访问此站点总速度上限为80K。
属性说明
limit_zone
语法：limit_zone zone_name $variable memory_max_size
作用域：http
limit_conn
语法： limit_conn zone_name 允许每个客户端建立的链接数
作用域：http, server, location
limit_rate
语法：limit_rate 每个链接的最大速率
作用域：http, server, location
附nginx限速实例。
例1：下载资源放在http://domain/download/路径下，针对每个访客下载限速为100K，且只能同时链接1个下载链接。
server {
location /download/ {
limit_conn one 1 ;
limit_rate 100k;
}
}
}
例2：每个访客访问站点的速度最大不超过100K，且可建立5条链接。
server {
location /download/ {
limit_conn one 5 ;
limit_rate 20k;
}
}
}
由于linit_rate是对每个链接限速，以上例子有5条链接，保证总速度不超过100K则每条链接不超过20K。
有关limit_zone的文档，请参考：http://wiki.Nginx.org/NginxHttpLimitZoneModule
有关limit_rate和limit_conn的文档，请参考：http://wiki.Nginx.org/NginxHttpCoreModule
介绍下如何通过修改nginx的配置，以实现提高squid命中率的方法。
1、对静态内容加以问号的访问
例如，http://www.?abc，该请求会透过squid缓存，直达后端服务器，并且在squid中保存缓存，从而造成压力和内存浪费。
解决方法：
在nginx的server中加入对html文件和首页等的过滤规则，此规则判断首页和html、jpg、gif结尾的文件，如果结尾有?xxx，则抛出403错误，由error_page接收，并用302跳转到正确的地址。
proxy_pass http://www.;
if ($is_args)
{
return 403;
error_page 403 =200 $scheme://$host$uri;
}
}
在测试中试图使用rewrite来达成目的，但rewrite之后会保留原来的$args即?的内容，所以不能成功。
另外，如果url中有中文，则跳转是会失败，所以要保证url中不含有中文，包括url_encode的结果。
2、对静态内容发送POST请求
这种请求也会透过squid，但不会在squid缓存内容。
配置：
proxy_pass http://www.;
if ($request_method = POST){
return 403;
error_page 403 =200 $scheme://$host$uri;
}
}
如何提高squid的命中率呢，使用nginx中url hash是用于提高squid命中率的一种架构算法，一般现行的架构通常是使用dns轮询或lvs等将访问量负载均衡到数台squid，这样做可以使squid的访问量做到了均衡，但是忽略了一个重要方面--数据量。
这种架构下，每台squid的数据量虽然是一致的，但通常都是满载，并且存在数据重复缓存的情况。
如果后端服务器数据容量或用户的访问热点数远远超过缓存机器的内存容量，甚至配置的disk cache容量，那么squid将会大量使用磁盘或者不停与后端服务器索取内容。
在新的架构下，使用nginx架载于squid之前，如果squid机器有4台，那么在这4台机器上装上nginx，nginx使用80端口，而squid改为3128端口或其他端口。nginx的效率非常高，消耗内存也
非常少，所以并不需考虑加装nginx所带来的性能损耗。
然后，在nginx上配置url hash，使访问量根据url均衡分布到各台squid，根据url分流之后，每一个url就会只存在于一台squid中，每台squid的数据都会完全不同。
我们有4台机器，每台2G内存的话，原先极有可能因为数据大量重复，内存使用率仍然为2G，而现在我们经过数据均衡分布，8G内存可以达到充分利用。
是否会存在访问不均的情况呢？是有可能的，但是根据大数原理，访问量基本可以保持一致，只要不存在单一的特别夸张的热点。
假如squid是利用squidclient来刷新数据的话，新的架构提供了更高效的方法：在后端服务器中模拟url hash的算法来找到内容所在的squid，然后对此服务器刷新内容即可。在旧的架构中
，需要遍历所有的服务器，比较低效。
具体配置如下：
安装第三方模块：ngx_http_upstream_hash_module
cd nginx-0.5.xx
patch -p0 < /path/to/upstream/hash/directory/nginx-0.5.xx.patch
./configure时加上参数
--add-module=path/to/upstream/hash/directory
make; make install
完成安装
配置：
在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法：
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
hash算法可以使用crc32和默认的simple，在java中可利用java.util.zip.CRC32类实现，simple算法的c语言实现：
#define ngx_hash(key, c) ((u_int) key * 31 c)
u_int ngx_hash_key(u_char *data, size_t len)
{
u_int i, key;
key = 0;
for (i = 0; i < len; i ) {
key *= 31;
key = data[i];
}
return key;
}
java代码（随手写未测试）：
{
long key = 0;
char[] chars = data.toCharArray();
for (int i=0; i key *= 31;
key = (int) chars[i];
}
return key;
}
然后对生成的key和upstream里的服务器数量做一次求余计算，得到服务器号。
提供hash算法的目的如前所述，是便于后端服务器迅速找到内容对应的squid服务器。
在ngx_http_upstream_hash_module模块里有一个hash_again的标签，可以解决squid意外死机的问题。
如果使用了该标签，那么后端的计算对应服务器的方法就会出现错误。
解决方法：
提供一台备份的squid服务器，假如有squid死机，那么在nginx里设置error_page 404和502到这台备份服务器，后端刷新缓存时亦要同时刷备份服务器。