電流制限に(下)戦闘

制限手段を一般的なアプリケーション

制限アプリケーション開発の一般的な電流がどのようなことですか。実際には、一般的な制限手段はキーが高い同時サービスを制限され、比較的簡単です。制限LB上で効率的かつ効果的に達成するために、一般的な方法は、nginxの+のLUAまたはnginxの+ Redisのサービスを実装するためにサービスを制限するので、市場は一般OpenrestyベースフレームWAFを達成するために使用されています。私たちは、より一般的な電流制限モードのいくつかを見てください。

Openresty +流量制限を達成するために、共有メモリを数えます

コードを制限するコードを見てください

lua_shared_dict limit_counter 10m;
server {
listen 80;
server_name www.test.com;
location / {
root html;
index index.html index.htm;
}

location /test {
access_by_lua_block {
local function countLimit()
local limit_counter =ngx.shared.limit_counter
local key = ngx.var.remote_addr .. ngx.var.http_user_agent .. ngx.var.uri .. ngx.var.host
local md5Key = ngx.md5(key)
local limit = 10
local exp = 300
local current =limit_counter:get(key)
if current ~= nil and current + 1> limit then
return 1
end
if current == nil then
limit_counter:add(key, 1, exp)
else
limit_counter:incr(key, 1)
end
return 0
end

local ret = countLimit()
if ret > 0 then
ngx.exit(405)
end
}
content_by_lua 'ngx.say(111)';
}
}

URIは、5分以内に各ユーザとのURIは、要求が10倍以上であれば、わずか10の要求を許可するようにされたキーと同じ組み合わせIP UAホストに固有のこの単純なコードは、説明上は、状態405に戻りますコードは、10未満の場合、処理は、後の段階に進みます。
結果は、アクセスを見て

curlhttp://www.test.com/test
111
curl http://www.test.com/test
111
curl http://www.test.com/test
111
curl http://www.test.com/test
111
curl http://www.test.com/test
111
curl http://www.test.com/test
111
curl http://www.test.com/test
111
curl http://www.test.com/test
111
curl http://www.test.com/test
111
curl http://www.test.com/test
<html>
<head><title>405 Not Allowed</title></head>
<body bgcolor="white">
<center><h1>405 Not Allowed</h1></center>
<hr><center>openresty/1.13.6.2</center>
</body>
</html>

これは、単純なカウンタ流量制限の一例です

Openrestyリミットモジュールの接続と要求の数

接続要求の数を制限し、モジュールの数は、LUA-resty制限-トラフィックです。そのスピードリーキーバケット原理に基づいて、我々は前に言いました。
水問題がある一方で貯水池の水側をオンにします。射出速度は、本明細書に新たな速度要求/接続され、排水速度制限速度が配置されています。水より速いスピード(プールの水のパフォーマンスが表示されます)より、遅延値が返されたときに水をオンにします。ngx.sleep(遅延)を通る水の速度が遅くする発信者。リザーバは(接続の現在のリクエスト/バースト数が設定値を超えたとして表される)一杯になると、エラーメッセージが拒否戻されます。呼び出し側は、オーバーフローのこの部分を失うする必要があります。
構成コードを見てください

http {
lua_shared_dict my_req_store 100m;
lua_shared_dict my_conn_store 100m;

server {
location / {
access_by_lua_block {
local limit_conn = require "resty.limit.conn"
local limit_req = require "resty.limit.req"
local limit_traffic = require "resty.limit.traffic"

local lim1, err = limit_req.new("my_req_store", 300, 150)
--300r/s的频率,大于300小于450就延迟大概0.5秒,超过450的请求就返回503错误码
local lim2, err = limit_req.new("my_req_store", 200, 100)
local lim3, err = limit_conn.new("my_conn_store", 1000, 1000, 0.5)
--1000c/s的频率,大于1000小于2000就延迟大概1s,超过2000的连接就返回503的错误码,估算每个连接的时间大概是0.5秒,
local limiters = {lim1, lim2, lim3}

local host = ngx.var.host
local client = ngx.var.binary_remote_addr
local keys = {host, client, client}

local states = {}
local delay, err = limit_traffic.combine(limiters, keys, states)
if not delay then
if err == "rejected" then
return ngx.exit(503)
end
ngx.log(ngx.ERR, "failed to limit traffic: ", err)
return ngx.exit(500)
end

if lim3:is_committed() then
local ctx = ngx.ctx
ctx.limit_conn = lim3
ctx.limit_conn_key = keys[3]
end

print("sleeping ", delay, " sec, states: ",
table.concat(states, ", "))

if delay >= 0.001 then
ngx.sleep(delay)
end
}
log_by_lua_block {
local ctx = ngx.ctx
local lim = ctx.limit_conn
if lim then
local latency = tonumber(ngx.var.request_time)
local key = ctx.limit_conn_key
local conn, err = lim:leaving(key, latency)
if not conn then
ngx.log(ngx.ERR,
"failed to record the connection leaving ",
"request: ", err)
return
end
end
}
}
}
}

簡単なコメントは、それはおそらくパラメータについて説明し導入することができます。特定が下の公式文書に記載されています
https://github.com/openresty/lua-resty-limit-traffic
が対数期に残して接続数を制限し、次のことに注意()動的に要求された時間を調整するために呼び出します。去るに呼び出すことを忘れてはいけない
ので、長いピットを取っ注意が必要なので、何を感じませんでした。試験は、任意の圧力なしで、そうでなければ、簡単な手順をngx.sleep下で必要な効果を測定することである場合、nginxのを実行することができる、全く遅延がないであろう。だから、睡眠の次の段階を行うために、遅延時間のコンテンツをテストする必要があり、あなたは効果を測定することができます。

Openresty制限動的共有メモリ

最初のロギングサービスで見つかったトラフィックが、その後、攻撃IPまたはUIDを照会し、最終的にこれらのIPまたはUIDを禁止:我々は攻撃やトラフィックが、私は通常のプロセスがされたときにオーバー戦うためにことがわかっ使用など。これは、遅れてきました。私たちがやるべきことは、直接トラフィックが入ってくるの動的解析による傍受ではなく、ラグ傍受され、傍受遅れサービスが殺さを流れやすくしています。
動的電流制限は、前述の技術を限定するものに基づいています。

lua_shared_dict limit_counter 10m;
server {
listen 80;
server_name www.test.com;

 

location / {
root html;
index index.html index.htm;
}

location /test {
access_by_lua_block {
local function countLimit()
local limit_counter =ngx.shared.limit_counter
local key = ngx.var.remote_addr .. ngx.var.http_user_agent .. ngx.var.uri .. ngx.var.host
local md5Key = ngx.md5(key)
local limit = 5
local exp = 120
local disable = 7200
local disableKey = md5Key .. ":disable"
local disableRt = limit_counter:get(disableKey)
if disableRt then
return 1
end
local current =limit_counter:get(key)
if current ~= nil and current + 1> limit then
dict:set(disableKey, 1, disable)
return 1
end
if current == nil then
limit_counter:add(key, 1, exp)
else
limit_counter:incr(key, 1)
end
return 0
end

local ret = countLimit()
if ret > 0 then
ngx.exit(405)
end
}
content_by_lua 'ngx.say(111)';
}
}

このラインの結果を見てください

curl http://www.test.com/test
111
curl http://www.test.com/test
111
curl http://www.test.com/test
111
curl http://www.test.com/test
111
curl http://www.test.com/test
111
curl http://www.test.com/test
<html>
<head><title>500 Internal Server Error</title></head>
<body bgcolor="white">
<center><h1>500 Internal Server Error</h1></center>
<hr><center>openresty/1.13.6.2</center>
</body>
</html>

一般的なアイデアは、それがブラックリストに発見された場合、要求は、直接503を返した後、ブラックリスト2時間に、ディスカバリ要求トリガーしきい値(5回2分)後に、一意の値に直接リクエスト比較的簡単です。その後、何のトリガーしきい値、一意の値1を追加する要求が存在しない場合、このカウンタの有効期限は2分、再カウント後2分です。基本的に私たちの現在の動的電流が制限会います。

遂に

私は現在、上記の3つのタイプに制限する、より一般的な方法で働いています、第2のモジュールは、保護サービスの目的を達成するために、電流制限の大半のニーズを満たすことができました、oenresty公式です。実施するのは非常に簡単openresty + shared.DICTの使用を制限するシンプルなコントロールは、Redisのにshared.DICTは、分散制限を実装することができます。もちろん、多くが市場にされている、特に優れたオープンソースのゲートウェイサービスフレームワークは、このような、オレンジ色をよりコングを使用するなど、WAFの機能を備え、大企業の多くを使用して、最近多くの人気apisixなどがされています。需要があれば、我々は次の焦点を合わせることができます。

電流制限オン(ON)

おすすめ

転載: www.cnblogs.com/feixiangmanon/p/11495314.html