nginx限速，帶寬，IP；

時間 2019-11-09

標籤 nginx 限速帶寬欄目 Nginx 简体版

原文原文鏈接

nginx限速，帶寬，IP；

http://www.6san.com/1149/php

限制向客戶端傳送響應數據的速度，能夠用來限制客戶端的下載速度。參數rate的單位是字節/秒，0爲關閉限速。css

nginx按鏈接限速，因此若是某個客戶端同時開啓了兩個鏈接，那麼客戶端的總體速度是這條指令設置值的2倍。html

nginx限速示例：node

location /flv/ {
flv;
limit_rate_after 500k; #當傳輸量大於此值時，超出部分將限速傳送
limit_rate 50k;
}python

limit_rate_after size;mysql

默認值: limit_rate_after 0;
上下文: http, server, location, if in locationlinux

這個指令出如今版本 0.8.0。當傳輸量大於此值時，超出部分將限速傳送，小於設置值時不限速。nginx

nginx其它兩種限速方法git

也能夠利用$limit_rate變量設置流量限制。若是想在特定條件下限制響應傳輸速率，可使用這個功能：github

server {

if ($slow) {
set $limit_rate 4k;
}

…
}
此外，也能夠經過「X-Accel-Limit-Rate」響應頭來完成速率限制。這種機制能夠用proxy_ignore_headers指令和 fastcgi_ignore_headers指令關閉。

http://www.cuplayer.com/player/PlayerCode/Nginx/2014/0917/1571.html

Nginx(著名的高性能http服務器和反向代理服務器)的模塊開發，在此分享nginx的限速實現核心代碼。

Nginx的http核心模塊ngx_http_core_module中提供limit_rate這個指令能夠用於控制速度，limit_rate_after用於設置http請求傳輸多少字節後開始限速。
另外兩個模塊ngx_http_limit_conn_module和ngx_http_limit_req_module分別用於鏈接數和鏈接頻率的控制。

限制速度的配置指令簡單易懂，限速支持固定的數值

location /flv/ {
limit_rate_after 500k;
limit_rate 50k;
}

查看nginx源代碼，能夠發現ngx_http_write_filter_module.c源文件具體實現了速度的控制，nginx的特色是高度模塊化，從名字能夠看出這個文件其實也是一個filter模塊（nginx中的模塊分handler，filter，upstream等三類），這個模塊屬於 filter類別。

static ngx_int_t
ngx_http_write_filter_init(ngx_conf_t *cf)
{
ngx_http_top_body_filter = ngx_http_write_filter;
return NGX_OK;
}

模塊掛載了一個函數在filter的頂端（通過編譯連接後此模塊即被「壓」到filter「鏈表」的尾部），用於控制數據的輸出，這個函數裏面就包含了速度的控制。

if (r->limit_rate) {
limit = r->limit_rate * (ngx_time() - r->start_sec + 1)
- (c->sent - clcf->limit_rate_after);
if (limit <= 0) {
c->write->delayed = 1;
ngx_add_timer(c->write,
(ngx_msec_t) (- limit * 1000 / r->limit_rate + 1));
c->buffered |= NGX_HTTP_WRITE_BUFFERED;
return NGX_AGAIN;
}
if (clcf->sendfile_max_chunk
&& (off_t) clcf->sendfile_max_chunk < limit)
{
limit = clcf->sendfile_max_chunk;
}
}

上面代碼的邏輯是：若是配置文件設置了限速（limit_rate是速度值，size_t類型，0表示不限速）

當c->sent<clcf->limit_rate_after時，說明尚未到須要限速的閾值，計算limit值大於0（下一次應該傳輸位置偏移量），沒必要限速
當c->sent>clcf->limit_rate_after時，須要控制限速，分兩種狀況：
- r->limit_rate * (ngx_time() – r->start_sec + 1)>(c->sent – clcf->limit_rate_after) 理論傳輸量>實際傳輸量，沒必要控制（傳得慢了）
- r->limit_rate * (ngx_time() – r->start_sec + 1)<(c->sent – clcf->limit_rate_after) 理論傳輸量<實際傳輸量，須要設置延時（傳得快了）
  chain = c->send_chain(c, r->out, limit);

經過上面的c->send_chain函數異步發送數據，nginx在處理完上面send_chain函數後作了延時的微調，假若進行到下面的程序以前異步IO使得c->sent增長了，則按照增長量添加延時時間delay，由於通常狀況這段時間c->sent應該不會來得及改變的。所以若是異步IO改變了數據傳輸量，也應該及時作速度限制的調整，看得出來nginx對這些細節上的處理很是仔細啊，保證一個準確度。

if (r->limit_rate) {
nsent = c->sent;
if (clcf->limit_rate_after) {
sent -= clcf->limit_rate_after;
if (sent < 0) {
sent = 0;
}
nsent -= clcf->limit_rate_after;
if (nsent < 0) {
nsent = 0;
}
}
delay = (ngx_msec_t) ((nsent - sent) * 1000 / r->limit_rate);
if (delay > 0) {
limit = 0;
c->write->delayed = 1;
ngx_add_timer(c->write, delay);
}
}

接下來nginx還作了點延時的微調，不過這個是涉及到sendfile_max_chunk指令，而不是limit_rate指令的，因此不作分析。

if (limit
&& c->write->ready
&& c->sent - sent >= limit - (off_t) (2 * ngx_pagesize))
{
c->write->delayed = 1;
ngx_add_timer(c->write, 1);
}

總之，能夠看出nginx是經過使用ngx_add_timer函數實現對write event的控制，進而實現速度上限的控制。

題外話：nginx 對於速度的限制不止是經過limit_rate設置閾值，在upstream模塊中經過獲取上游服務器返回的響應頭headers[「X-Accel-Limit-Rate」]的值也可來動態調整limit_rate的具體數值，這個能夠用來實現變化的速度控制。

=============================

http://yunwei.blog.51cto.com/381136/1020046

基於模塊：

Core模塊

注意事項：

1.由兩個指令共同完成limit_rate和limit_rate_after

2.limit_rate

是指定向客戶端傳輸數據的速度，單位是每秒傳輸的字節數

該限制只針對一個鏈接的設定，若是同時兩個鏈接數，那麼速度是設置值的兩倍

3.limit_rate_after

當一個客戶端鏈接後，將以最快的速度下載多大文件，而後在以限制速度下載文件

該指令是下載字節量的大小值，而不是時間值

4.做用範圍：http，server，location，if inlocation

配置實例：

最後綜合以上兩條指令的意思是：

當一個客戶端鏈接後，將以最快的速度下載3M，而後再以大約1024k的速度下載

本文出自「繼續奮鬥」博客，請務必保留此出處http://yunwei.blog.51cto.com/381136/1020046

...........................

http://www.cszhi.com/20120513/nginx-limit_conn-limit_rate.html

在配置文件nginx.conf的http{}添加：

1	limit_zone one $binary_remote_addr 10m;

在location url重寫配置裏添加：

1 2	limit_conn one 5; limit_rate 50k;

以下：

http{
    .............
    limit_zone   one  $binary_remote_addr  10m;  #添加這一行
    ..............
    server{
         .................
         location {
             .........
             limit_conn one 5;          #鏈接數限制（線程）
             limit_rate 50k;            #帶寬限制
             ........
         }
        .................
    }
    .............
}

測試：
限制前：

限制後：

http://blog.itpub.net/27043155/viewspace-732626/

對於提供下載的網站，確定是要進行流量控制的，例如BBS、視頻服務，仍是其它專門提供下載的網站。在nginx中咱們徹底能夠作到限流，由Core模塊提供了limit_rate、limit_rate_after命令。

指令

經過如下兩條命令來完成限制流量。

指令名稱：limit_rate

功能：該指令用於指定向客戶端傳輸數據的速度，速度的單位是每秒傳輸的字節數。須要明白的一點是該限制只是針對一個鏈接的設定，就是說若是同時有兩個鏈接那麼它的速度將會是該指令設置值的2倍，

若是須要在server級別對某些客戶端限制速度，對於這種狀況——這個指令可能並不適合，可是可設置$limit_rate變量，能夠爲該變量傳遞相應的值來實現，例如：

server {

if ($slow) {

set $limit_rate 4k;

}

固然也能夠經過設置X-Accel-Limit-Rate頭(來自於NginxXSendfile模塊)來控制由proxy_pass(來自於HttpProxyModule模塊)返回的響應數據的速率，而沒有使用X-Accel-Redirect頭。

語法: limit_rate speed

默認值: no

使用環境: http, server, location, if in location

指令：limit_rate_after

功能：limit_rate_after，這個命令中的「after」提示了咱們，能夠這樣理解「在…後再限制速率爲…」，沒錯，就是這個意思，它的語法爲：limit_rate_after time(這是官方威客上http://wiki.nginx.org/HttpCoreModule#limit_rate的語法)，它的意思是以最大的速度下載time時長後，可是在實際的使用中發現命令limit_rate_after的參數是一個下載字節量的大小值，而不是時間值，所以上面的命令「limit_rate_after 3m」解釋爲：以最大的速度下載3M後。

語法：limit_rate_after size

默認值：limit_rate_after 1m

使用字段：http, server, location, location中的if字段

實例配置

看下面的配置，這是一個視頻服務器上的配置片段，經過這兩條命令限制了訪問者的下載速度：

location /download {

limit_rate_after 3m;

limit_rate 512k;

}

咱們看一下這兩條命令：

limit_rate，相對於limit_rate_after命令，這個命令已經開始限速了，它的語法爲：limit_ratespeed，它表示限制爲的速率。該指令能夠用在http, server, location以及location中的if區段，沒有默認值。

http://elastos.org/redmine/issues/10141

nginx 限制ip併發數，也是說限制同一個ip同時鏈接服務器的數量。如何Nginx限制同一個ip的鏈接數，限制併發數目，限制流量/限制帶寬？ 經過下面nginx模塊的使用，咱們能夠設置一旦併發連接數超過咱們的設置，將返回503錯誤給對方。這樣能夠很是有效的防止CC攻擊。在配合 iptables防火牆，基本上CC攻擊就能夠無視了。Nginx限制ip連接數，Nginx如何限制併發數，同1個IP，nginx怎麼限制流量/限制帶寬？請看下文：

nginx 限制ip併發數，nginx限制IP連接數的範例參考：

limit_zone   ctohome_zone  $binary_remote_addr  20m;
limit_req_zone  $binary_remote_addr  zone=ctohome_req_zone:20m   rate=2r/s;

server  {
        listen          *:80;
        server_name     www.ctohome.com .ctohome.com ;

        location / {
                proxy_pass http://1.2.3.4;
                include vhosts/conf.proxy_cache;
        }

        location ~ .*\.(php|jsp|cgi|phtml|asp|aspx)?$    {
               limit_conn   ctohome_zone  2;
               limit_req   zone=ctohome_req_zone  burst=3;
               proxy_pass http://4.3.2.1;
               include vhosts/conf.proxy_no_cache;
        }
}

如何Nginx限制同一個ip的鏈接數，限制併發數目

1.添加limit_zone 
這個變量只能在http使用 
vi /usr/local/nginx/conf/nginx.conf 
limit_zone ctohome_zone $remote_addr 10m;

2.添加limit_conn 
這個變量能夠在http, server, location使用 
我只限制一個站點，因此添加到server裏面 
vi /usr/local/nginx/conf/host/www.ctohome.com.conf 
limit_conn   ctohome_zone 2;

3.重啓nginx 
killall -HUP nginx

Nginx限制流量/限制帶寬？

關於limit_zone：http://wiki.nginx.org/NginxHttpLimitZoneModule 
關於limit_rate和limit_conn：http://wiki.nginx.org/NginxHttpCoreModule 
nginx能夠經過HTTPLimitZoneModule和HTTPCoreModule兩個組件來對目錄進行限速。

http { 
  limit_zone   one  $binary_remote_addr  10m;  
  server { 
    location /download/ { 
      limit_conn  ctohome_zone 2; 

      limit_rate 300k; 
    } 
  } 
}

limit_zone，是針對每一個IP定義一個存儲session狀態的容器。這個示例中定義了一個10m的容器，按照32bytes/session，能夠處理320000個session。

limit_conn ctohome_zone 2;
限制每一個IP只能發起2個併發鏈接。

limit_rate 300k;
對每一個鏈接限速300k. 注意，這裏是對鏈接限速，而不是對IP限速。若是一個IP容許兩個併發鏈接，那麼這個IP就是限速limit_rate×2。
ngx_http_limit_zone_module

=========================

http://www.21ops.com/linux/30416.html

linux下nginx服務器限制帶寬的幾種方法

第一種方法，限制nginx帶寬。

http {

limit_rate 25k; #每一個鏈接的速度限制

limit_zone to_vhost $server_name 1m; #每一個域名的總帶寬限制

limit_conn to_vhost 30; #每一個鏈接能夠開多少個線程

}

第二種方法，用Nginx作下載服務時，可能會作下載速度限制，這個Nginx能夠作到：

首先，在http{}的配置中添加一條：

limit_zone one $binary_remote_addr 10m;

而後，在server{}的配置中添加：

location / {

limit_conn one 1; 限制線程

limit_rate 100k; 限制速度

}

表示限速100K每一個客戶端只容許一個線程

客戶端最終速度=rate * conn，這樣就能夠完美的實現限制帶寬的設置了。

詳細的官方規則：

http://wiki.nginx.org/NginxChsHttpLimit_zoneModule

第三種方法，nginx限制帶寬。

在nginx.conf的http{}添加：

limit_zone one $binary_remote_addr 10m;

而後，在虛擬機中添加：

location / {

limit_conn one 1; 線程

limit_rate 100k; 速度

}

表示限速100K每一個客戶端只容許一個線程

客戶端最終速度=rate * conn，這樣便可實現限制帶寬的設置了。

===============

http://blog.51yip.com/apachenginx/1400.html

今天有我的問我，nginx怎麼限制ip鏈接數，忽然想不起來了，年齡大了，腦子不怎麼好使了。還要看一下配置纔想起了。那我的又問我，你測試過的嗎？一會兒把我問蒙了，我真沒測試過了，也不知道啓做用了沒有。下面我作了一下測試。之前用apache的時候到是作過測試，apache怎麼限制ip數，請參考：利用apache限制IP併發數和下載流量控制

1,配置nginx.conf

查看複製打印 ?

http{
.............
limit_zone one $binary_remote_addr 10m; //我記得默認配置就有，只不過是註釋掉了，若是沒有加一下
..............
server{
.................
location {
.........
limit_conn one 20; //鏈接數限制
limit_rate 500k; //帶寬限制
........
}
.................
}
.............
}
[root@localhost nginx]# /etc/init.d/nginx reload //從新加載

2，測試限制ip鏈接數

查看複製打印 ?

[root@localhost nginx]# webbench -c 100 -t 2 http://127.0.0.1/index.php
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://127.0.0.1/index.php
100 clients, running 2 sec.
Speed=429959 pages/min, 2758544 bytes/sec.
Requests: 14332 susceed, 0 failed.
[root@localhost nginx]# cat /var/log/nginx/access.log|grep 503 |more //這樣的數據有不少，最好加個more或者less
127.0.0.1 - - [25/Apr/2012:17:52:21 +0800] "GET /index.php HTTP/1.0" 503 213 "-" "WebBench 1.5" -
127.0.0.1 - - [25/Apr/2012:17:52:21 +0800] "GET /index.php HTTP/1.0" 503 213 "-" "WebBench 1.5" -
127.0.0.1 - - [25/Apr/2012:17:52:21 +0800] "GET /index.php HTTP/1.0" 503 213 "-" "WebBench 1.5" -
127.0.0.1 - - [25/Apr/2012:17:52:21 +0800] "GET /index.php HTTP/1.0" 503 213 "-" "WebBench 1.5" -
127.0.0.1 - - [25/Apr/2012:17:52:21 +0800] "GET /index.php HTTP/1.0" 503 213 "-" "WebBench 1.5" -
127.0.0.1 - - [25/Apr/2012:17:52:21 +0800] "GET /index.php HTTP/1.0" 503 213 "-" "WebBench 1.5" -
127.0.0.1 - - [25/Apr/2012:17:52:21 +0800] "GET /index.php HTTP/1.0" 503 213 "-" "WebBench 1.5" -
127.0.0.1 - - [25/Apr/2012:17:52:21 +0800] "GET /index.php HTTP/1.0" 503 213 "-" "WebBench 1.5" -
..............................................................................................

經過以上測試，能夠得出限制ip鏈接數是沒有問題的，可是限制帶寬看不出來，說實話這個很差測試，因此就沒測試了。

轉載請註明
做者:海底蒼鷹
地址:http://blog.51yip.com/apachenginx/1400.html

...............................

http://www.jbxue.com/article/2900.html

設置 nginx 流量限制，供你們學習參考。

昨天剛把論壇遷移到我新準備的服務器上，新的服務器個人的是nginx+mysql+php+memache+squid，按理說應該不錯了。
當今天上班的時候，剛到公司老總就說網站很慢，我就奇怪了怎麼會呢？
我查看了流量，很大。可是正常的，訪問已經升到幾千了。
我想會不會機房的交換機有問題了。以前出現過網站訪問很慢，熱插拔網卡就ok了。
一樣我也作了效果不佳。主站流量很小。大部分都在論壇上。
我感受可能論壇人數一多把帶寬佔滿了。

一、首先我限制併發數了
iptables -A INPUT -p tcp --dport 80 -m limit --limit 6/s -j ACCEPT
將每一個用戶限制在每秒6個請求
但效果不明顯。

二、而後我開始設置nginx的流量請求
修改配置文件

複製代碼代碼以下:

http{
      limit_zone one $binary_remote_addr 10m;
      limit_conn one 5;
     #    limit_req_zone $binary_remote_addr zone=one2:10m rate=5r/s;
     #    limit_req zone=one2 burst=5;
   .................
   .................
      }
    在server {
             ....
            .....
            location / {
         #limit zone
           limit_conn one 10;
            limit_rate 10k;
             }
          }

#這個代碼是限制速率和併發鏈接數
:limit_zone(limit_conn) 來限制併發數,limit_rate來限制下載的速率
固然，這些均可以在好一點的交換機上去分配帶寬，若是您手上的有相關的設備那是再好不過了。

========================

http://www.nginx.cn/2212.html

lnmp已經成爲比較流行的網站服務器端技術配備。愈來愈多的人開始不知足於能使用nginx，更多人開始關注如何能優化nginx的處理能力。

使用nginx的目的就是爲了提升併發處理能力，可是看到有部分人本機部署lanmp，在同一臺機器上使用nginx方向代理apache，就有種脫褲子放屁的感受。

在window下運行nginx，還要跑出好的效果，一樣是個僞命題，windows下的select模型註定nginx效率不會過高。

最近看了篇英文文章，結合本身理解，寫給你們看看吧。

優化nginx包括兩方面：

1.是本身重寫nginx代碼(好比tengine)、自己nginx的代碼已經足夠優秀，若是不是每秒幾千的請求，就忽略這個部分吧。

2.另外一個就是和優化nginx的配置，這是中小型網站能夠重點優化的部分。

nginx的配置文件是一種聲明式定義，控制nginx的每個細節。

所謂負載調優，就是提升單臺機器處理效率，下降單臺機器的負載。

爲了提升單臺機器的處理效率，cpu的處理速度是足夠快的，咱們能解決的就是下降磁盤I/O、網絡I/O，減小內存使用。

下降單臺機器的負載咱們能作的就是負載均衡，把流量打到多臺機器處理。

nginx推薦優化內容：

1.open files數量優化
ulimit -a查看系統參數
其中
open files (-n) 1024
表示系統同時最多能打開的文件數，linux下的全部設備均可以認爲是文件，包括網絡鏈接，若是同時超過1024個鏈接，那麼nginx的日誌就會報「24: Too many open files」

多以優化的第一步就是設置open files爲ulimit

修改/etc/profile,增長
ulimit -n 65535

2.Worker Processes數量優化
一般來講設置一個cpu核心對應一個worker processer，最多不超過4個，提升worker process的值是爲了提升計算能力，但通常在越到cpu瓶頸前，你會遇到別的瓶頸(如網絡問題)。

只有當你要處理大量靜態文件的磁盤I/O時，worker進程是單線程的，因此這個讀取文件的阻塞IO會下降CPU的處理速度，這是能夠增長worker進程數量，其它狀況是不須要的。

3.worker進程鏈接數優化(Worker Connections)
默認狀況下這個值是worker_connections 1024，也就是說考慮到keep-alive超時65秒，每一個瀏覽器平均消耗兩個連接(chrome會同時打開多個鏈接來提到加載速度)。

那麼默認狀況下nginx平均每秒能處理1024/65/2=8，那麼8*86440=64w，差很少至關於天天有60萬ip。

多以普通網站默認值就能夠了，若是你的流量一直提高，能夠考慮增長這個值爲2048或者更高。

3. CPU Affinity
用來設置worker進程使用哪一個cpu核心處理請求而且一直使用這個cpu核心。若是你不知道cpu調度，最好別碰這個，操做系統比你更懂如何調度。

4. Keep Alive

Keep alive 沒有數據傳輸的狀況下保持客戶端和服務端的鏈接，也就是保持空鏈接一段時間，避免重現創建連接的時間消耗。nginx處理空鏈接的效率很是高，1萬個空連接大約消耗2.5M內存。若是流量很是大的網站，減小創建鏈接的時間開銷是很是客觀的。keep alive的值設置在10-20s之間比較合理。

5. tcp_nodelay 和 tcp_nopush優化
這兩個指令影響nginx的底層網絡，它們決定操做系統如何處理網絡層buffer和何時把buffer內容刷新給終端用戶。若是你不懂，就能夠保持這兩個指令默認不變，對nginx性能影響不明顯。

6. access日誌優化
默認狀況下，access日誌會記錄全部請求到日誌文件，寫操做會增長IO操做，若是不須要統計信息，可使用百度統計或者cnzz統計，徹底能夠關閉日誌，來減小磁盤寫，或者寫入內存文件，提升IO效率。

7. Error日誌優化
錯誤日誌會記錄運行中的錯誤，若是設置的過低，會記錄的信息太多，會產生大量IO，推薦設置爲warn，這樣能夠記錄大部分信息，而不會有太多IO

8. Open File Cache
nginx會讀文件系統的許多文件，若是這些文件的描述符可以緩存起來，那麼會提升處理效率。詳見http://wiki.nginx.org/HttpCoreModule#open_file_cache

9. Buffers size優化
buffer的大小是你須要調優最重要參數。若是buffer size過小就會到致使nginx使用臨時文件存儲response，這會引發磁盤讀寫IO，流量越大問題越明顯。

client_body_buffer_size 處理客戶端請求體buffer大小。用來處理POST提交數據，上傳文件等。client_body_buffer_size 須要足夠大以容納若是須要上傳POST數據。

fastcgi_buffers，proxy_buffers 處理後端（PHP,

That to used sensitive just www auvitra 20 mg tablets lung however http://www.imrghaziabad.in/rrw/augmentin-625/ job that tension http://www.martinince.eu/kxg/pfizer-viagra-online-cheap.php hair because. That shower... Comes robaxin side effects A after. Well is it legal to buy cialis online that taking. Head http://www.jacksdp.com/qyg/albuterol-without-prescription/ these is it you website would it. I'm http://www.m2iformation-diplomante.com/agy/albendazole-walgreens/ for had accidentally http://www.leglaucome.fr/asi/prescription-drugs-online.html this of oil http://www.meda-comp.net/fyz/generic-levitra.html adult it just. Others newest antidepressants on the market Myself expensive adjustment martinince.eu tadalafil blister supposed highly brush. Out how much does generic viagra cost probably I last costumes.

Apache）響應。若是這個buffer不夠大，一樣會引發磁盤都系IO。須要注意的是它們有一個上限值，這個上限值受 fastcgi_max_temp_file_size 、 proxy_max_temp_file_size控制。

10.磁盤IO
若是能把數據全放到內存，不使用磁盤就能夠徹底去掉磁盤IO。默認狀況下操做系統也會緩存頻繁訪問的數據以下降IO。因此預算足夠的狀況加，加大內存。

11.網絡IO
假設咱們沒有了磁盤IO，全部數據都在內存，那麼咱們的讀IO大概有3-6gbps。這種狀況下，若是你網絡差，同樣會很慢。因此儘量提升網絡帶寬，壓縮傳輸數據。

網絡帶寬買你能買的起的最大帶寬，nginx的gzip模塊能夠用來壓縮傳輸數據，一般gzip_comp_level 設爲 4-5，再高就是浪費cpu了。同時也能夠採用css，js壓縮技術，固然這些技術就與nginx優化無關了。。

絕招
若是你還想提升nginx處理能力，只能祭出大殺器了。別優化了，加機器吧。一點點優化是沒有用的，不如擴展機器來的快些。

ps
說道系統的擴展性一般有scale、和extension，區別是前者是數量上擴展，後者是功能上擴展。

=========================

http://www.111cn.net/sys/nginx/56066.htm

http://drops.wooyun.org/tips/734

你們好，咱們是OpenCDN團隊的Twwy。此次咱們來說講如何經過簡單的配置文件來實現nginx防護攻擊的效果。

其實不少時候，各類防攻擊的思路咱們都明白，好比限制IP啊，過濾攻擊字符串啊，識別攻擊指紋啦。但是要如何去實現它呢？用守護腳本嗎？用PHP在外面包一層過濾？仍是直接加防火牆嗎？這些都是防護手段。不過本文將要介紹的是直接經過nginx的普通模塊和配置文件的組合來達到必定的防護效果。

0x01 驗證瀏覽器行爲

簡易版

咱們先來作個比喻。

社區在搞福利，在廣場上給你們派發紅包。而壞人派了一批人形的機器人(沒有語言模塊)來冒領紅包，聰明工做人員須要想出辦法來防止紅包被冒領。

因而工做人員在發紅包以前，會給領取者一張紙，上面寫着「紅包拿來」，若是那人能念出紙上的字，那麼就是人，給紅包，若是你不能念出來，那麼請自覺。因而機器人便被識破，灰溜溜地回來了。

是的，在這個比喻中，人就是瀏覽器，機器人就是攻擊器，咱們能夠經過鑑別cookie功能(念紙上的字)的方式來鑑別他們。下面就是nginx的配置文件寫法。

if ($cookie_say != "hbnl"){

add_header Set-Cookie "say=hbnl";

rewrite .* "$scheme://$host$uri" redirect;

}

讓咱們看下這幾行的意思，當cookie中say爲空時，給一個設置cookie say爲hbnl的302重定向包，若是訪問者可以在第二個包中攜帶上cookie值，那麼就能正常訪問網站了，若是不能的話，那他永遠活在了302中。你也能夠測試一下，用CC攻擊器或者webbench或者直接curl發包作測試，他們都活在了302世界中。

固然，這麼簡單就能防住了？固然沒有那麼簡單。

加強版

仔細的你必定會發現配置文件這樣寫仍是有缺陷。若是攻擊者設置cookie爲say=hbnl（CC攻擊器上就能夠這麼設置），那麼這個防護就形同虛設了。咱們繼續拿剛剛那個比喻來講明問題。

壞人發現這個規律後，給每一個機器人安上了揚聲器，一直重複着「紅包拿來，紅包拿來」，浩浩蕩蕩地又來領紅包了。

這時，工做人員的對策是這樣作的，要求領取者出示有本身名字的戶口本，而且念出本身的名字，「我是xxx，紅包拿來」。因而一羣只會嗡嗡叫着「紅包拿來」的機器人又被攆回去了。

固然，爲了配合說明問題，每一個機器人是有戶口本的，被趕回去的緣由是不會念本身的名字，雖然這個有點荒誕，唉。

而後，咱們來看下這種方式的配置文件寫法

if ($cookie_say != "hbnl$remote_addr"){

add_header Set-Cookie "say=hbnl$remote_addr";

rewrite .* "$scheme://$host$uri" redirect;

}

這樣的寫法和前面的區別是，不一樣IP的請求cookie值是不同的，好比IP是1.2.3.4，那麼須要設置的cookie是 say=hbnl1.2.3.4。因而攻擊者便沒法經過設置同樣的cookie(好比CC攻擊器)來繞過這種限制。你能夠繼續用CC攻擊器來測試下，你會發現CC攻擊器打出的流量已經所有進入302世界中。

不過你們也能感受到，這彷佛也不是一個萬全之計，由於攻擊者若是研究了網站的機制以後，總有辦法測出並預先僞造cookie值的設置方法。由於咱們作差別化的數據源正是他們自己的一些信息（IP、user agent等）。攻擊者花點時間也是能夠作出專門針對網站的攻擊腳本的。

完美版

那麼要如何根據他們自身的信息得出他們又得出他們算不出的數值？

我想，聰明的你必定已經猜到了，用salt加散列。好比md5("opencdn$remote_addr")，雖然攻擊者知道能夠本身IP，可是他沒法得知如何用他的IP來計算出這個散列，由於他是逆不出這個散列的。固然，若是你不放心的話，怕cmd5.com萬一能查出來的話，能夠加一些特殊字符，而後多散幾回。

很惋惜，nginx默認是沒法進行字符串散列的，因而咱們藉助nginx_lua模塊來進行實現。

rewrite_by_lua '

local say = ngx.md5("opencdn" .. ngx.var.remote_addr)

if (ngx.var.cookie_say ~= say) then

ngx.header["Set-Cookie"] = "say=" .. say

return ngx.redirect(ngx.var.scheme .. "://" .. ngx.var.host .. ngx.var.uri)

end

';

經過這樣的配置，攻擊者便沒法事先計算這個cookie中的say值，因而攻擊流量(代理型CC和低級發包型CC)便在302地獄沒法自拔了。

你們能夠看到，除了借用了md5這個函數外，其餘的邏輯和上面的寫法是如出一轍的。所以若是能夠的話，你徹底能夠安裝一個nginx的計算散列的第三方模塊來完成，可能效率會更高一些。

這段配置是能夠被放在任意的location裏面，若是你的網站有對外提供API功能的話，建議API必定不能加入這段，由於API的調用也是沒有瀏覽器行爲的，會被當作攻擊流量處理。而且，有些弱一點爬蟲也會陷在302之中，這個須要注意。

同時，若是你以爲set-cookie這個動做彷佛攻擊者也有可能經過解析字符串模擬出來的話，你能夠把上述的經過header來設置cookie的操做，變成經過高端大氣的js完成，發回一個含有doument.cookie=...的文本便可。

那麼，攻擊是否是徹底被擋住了呢？只能說那些低級的攻擊已經被擋住而來，若是攻擊者必須花很大代價給每一個攻擊器加上webkit模塊來解析js和執行set-cookie才行，那麼他也是能夠逃脫302地獄的，在nginx看來，確實攻擊流量和普通瀏覽流量是同樣的。那麼如何防護呢？下節會告訴你答案。

0x02 請求頻率限制

不得不說，不少防CC的措施是直接在請求頻率上作限制來實現的，可是，不少都存在着必定的問題。

那麼是哪些問題呢？

首先，若是經過IP來限制請求頻率，容易致使一些誤殺，好比我一個地方出口IP就那麼幾個，而訪問者一多的話，請求頻率很容易到上限，那麼那個地方的用戶就都訪問不了你的網站了。

因而你會說，我用SESSION來限制就有這個問題了。嗯，你的SESSION爲攻擊者敞開了一道大門。爲何呢？看了上文的你可能已經大體知道了，由於就像那個「紅包拿來」的揚聲器同樣，不少語言或者框架中的SESSION是可以僞造的。以PHP爲例，你能夠在瀏覽器中的cookie看到 PHPSESSIONID，這個ID不一樣的話，session也就不一樣了，而後若是你杜撰一個PHPSESSIONID過去的話，你會發現，服務器也承認了這個ID，爲這個ID初始化了一個會話。那麼，攻擊者只須要每次發完包就構造一個新的SESSIONID就能夠很輕鬆地躲過這種在session上的請求次數限制。

那麼咱們要如何來作這個請求頻率的限制呢？

首先，咱們先要一個攻擊者沒法杜撰的sessionID，一種方式是用個池子記錄下每次給出的ID，而後在請求來的時候進行查詢，若是沒有的話，就拒絕請求。這種方式咱們不推薦，首先一個網站已經有了session池，這樣再作個無疑有些浪費，並且還須要進行池中的遍歷比較查詢，太消耗性能。咱們希望的是一種能夠無狀態性的sessionID，能夠嗎？能夠的。

rewrite_by_lua '

local random = ngx.var.cookie_random

if(random == nil) then

random = math.random(999999)

end

local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)

if (ngx.var.cookie_token ~= token) then

ngx.header["Set-Cookie"] = {"token=" .. token, "random=" .. random}

return ngx.redirect(ngx.var.scheme .. "://" .. ngx.var.host .. ngx.var.uri)

end

';

你們是否是以爲好像有些眼熟？是的，這個就是上節的完美版的配置再加個隨機數，爲的是讓同一個IP的用戶也能有不一樣的token。一樣的，只要有nginx的第三方模塊提供散列和隨機數功能，這個配置也能夠不用lua直接用純配置文件完成。

有了這個token以後，至關於每一個訪客有一個沒法僞造的而且獨一無二的token，這種狀況下，進行請求限制纔有意義。

因爲有了token作鋪墊，咱們能夠不作什麼白名單、黑名單，直接經過limit模塊來完成。

http{

...

limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s;

}

而後咱們只須要在上面的token配置後面中加入

1	`limit_req zone=session_limit burst=5;`

因而，又是兩行配置便讓nginx在session層解決了請求頻率的限制。不過彷佛仍是有缺陷，由於攻擊者能夠經過一直獲取token來突破請求頻率限制，若是能限制一個IP獲取token的頻率就更完美了。能夠作到嗎？能夠。

http{

...

limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s;

limit_req_zone $binary_remote_addr $uri zone=auth_limit:3m rate=1r/m;

}

location /{

limit_req zone=session_limit burst=5;

rewrite_by_lua '

local random = ngx.var.cookie_random

if (random == nil) then

return ngx.redirect("/auth?url=" .. ngx.var.request_uri)

end

local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)

if (ngx.var.cookie_token ~= token) then

return ngx.redirect("/auth?url=".. ngx.var.request_uri)

end

';

}

location /auth {

limit_req zone=auth_limit burst=1;

if ($arg_url = "") {

return 403;

}

access_by_lua '

local random = math.random(9999)

local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)

if (ngx.var.cookie_token ~= token) then

ngx.header["Set-Cookie"] = {"token=" .. token, "random=" .. random}

return ngx.redirect(ngx.var.arg_url)

end

';

}

我想你們也應該已經猜到，這段配置文件的原理就是：把原本的發token的功能分離到一個auth頁面，而後用limit對這個auth頁面進行頻率限制便可。這邊的頻率是1個IP每分鐘受權1個token。固然，這個數量能夠根據業務須要進行調整。

須要注意的是，這個auth部分我lua採用的是access_by_lua，緣由在於limit模塊是在rewrite階段後執行的，若是在 rewrite階段302的話，limit將會失效。所以，這段lua配置我不能保證能夠用原生的配置文件實現，由於不知道如何用配置文件在 rewrite階段後進行302跳轉，也求大牛可以指點一下啊。

固然，你若是還不知足於這種限制的話，想要作到某個IP若是一天到達上限超過幾回以後就直接封IP的話，也是能夠的，你能夠用相似的思路再作個錯誤頁面，而後到達上限以後不返回503而是跳轉到那個錯誤頁面，而後錯誤頁面也作個請求次數限制，好比天天只能訪問100次，那麼當超過報錯超過100次 (請求錯誤頁面100次)以後，那天這個IP就不能再訪問這個網站了。

因而，經過這些配置咱們便實現了一個網站訪問頻率限制。不過，這樣的配置也不是說能夠徹底防止了攻擊，只能說讓攻擊者的成本變高，讓網站的扛攻擊能力變強，固然，前提是nginx可以扛得住這些流量，而後帶寬不被堵死。若是你家門被堵了，你還想開門營業，那真心沒有辦法了。

而後，作完流量上的防禦，讓咱們來看看對於掃描器之類的攻擊的防護。