निवेदन सीमा - रेटलामिटर

यदि आप डरते हैं कि आपकी वेब सेवा को लापरवाह उपयोगकर्ताओं द्वारा रोका जा सकता है, या आपके पास बस एक कमजोर सर्वर है, तो आपने पहले ही प्रत्येक उपयोगकर्ता से अनुरोधों की संख्या को सीमित करने के बारे में सोचा है। एक अच्छे तरीके से - यह केवल एक आवश्यक रक्षा क्षेत्र है। बेशक, इस तरह की सीमा गंभीर हमले से नहीं बचाएगी, लेकिन कीमत / गुणवत्ता के दृष्टिकोण से यह काफी उपयुक्त है

हाल ही में, मैंने एर्लांग में सक्रिय रूप से जुड़ना शुरू किया। खैर, हमेशा की तरह, सामग्री को मजबूत करने के लिए, मैंने मोचीवेब पर एक साधारण वेब सेवा लागू की। मोचीवेब वेब एप्लिकेशन बनाने के लिए एक बहुत ही सभ्य ढांचा है, लेकिन मुझे एक ग्राहक से अनुरोधों की संख्या को सीमित करने की क्षमता नहीं मिली। तो मैंने खुद किया।

क्योंकि कार्यक्षमता को सीमित करने वाली क्वेरी की गति पूरी तरह से अलग है और किसी भी विशिष्ट कार्य से बंधी नहीं है, मैंने एक स्वतंत्र अनुप्रयोग में बनाए गए मॉड्यूल का चयन किया और इसके स्रोत कोड को निर्धारित करने का निर्णय लिया।

कार्य

तो, हमारे पास Erlang / OTP , Mochiweb, rebar है । मैं किसी विशेष उपयोगकर्ता से अनुरोधों की संख्या को पढ़ना चाहता हूं और यदि अनुरोध बहुत बार जाते हैं तो उसे 413 त्रुटि कोड देते हैं। ग्राहक की पहचान उसके आईपी पते से की जाती है। वह जो mochiweb_request:get(peer). देता है mochiweb_request:get(peer).

कार्य इतना मुश्किल नहीं है, लेकिन शायद एक टर्नकी समाधान किसी के समय को बचाएगा।

दृष्टिकोण

मैंने टोकन बाल्टी एल्गोरिथ्म का उपयोग करने का निर्णय लिया।
यदि हम इसका संक्षेप में वर्णन करते हैं, तो हम प्रत्येक ग्राहक के लिए कुछ समय अंतरालों को टोकरियाँ मानते हैं जिसमें हम इस समय अंतराल के लिए उपयोगकर्ता अनुरोध जोड़ेंगे। टोकरी में एक सीमित मात्रा होती है। जैसे ही टोकरी को सीमा तक अनुरोधों के साथ भरा जाता है, हम ग्राहक को सेवा देना बंद कर देते हैं। क्योंकि समय आगे बढ़ता है, क्लाइंट के लिए बास्केट लगातार बदल रहे हैं, और क्लाइंट के पास नए समय अंतराल पर सेवा करने का मौका है।


ऊपर की तस्वीर में, लाल उस समय को इंगित करता है जब प्रत्येक ग्राहक सेवित नहीं था।
जैसा कि आप चित्र से देख सकते हैं, क्लाइंट ए को कुछ समय पहले एक अनुरोध प्रतिबंध प्राप्त हुआ और उन्हें अब और नहीं भेजा गया, क्लाइंट बी चुपचाप काम करता है और सीमा से अधिक नहीं होता है, और क्लाइंट बी ने फिलहाल अनुरोध सीमा का चयन किया है और रिफ्यूज़ल प्राप्त कर रहा है।

हम ग्राहक से अनुरोध के रूप में टोकरियाँ बनाएंगे, और समय को ध्यान में रखेंगे। प्रत्येक ग्राहक का अपना समय पैमाना हो सकता है, टोकरी को जीवन भर पढ़ सकते हैं। टोकरी की मात्रा, अर्थात् अनुरोधों की सीमा, प्रत्येक ग्राहक के लिए अलग से निर्धारित की जा सकती है।

हम डिक्शनरी में ग्राहक बास्केट के बारे में जानकारी स्टोर करेंगे:
कुंजी के रूप में IP + №
counter - वास्तव में, अनुरोध काउंटर

क्लाइंट के लिए API में एक फ़ंक्शन check_rate(IP, TimeScale, Limit) ।
जहाँ
IP ग्राहक का आईपी पता है (हालांकि, यह किसी भी पहचानकर्ता का हो सकता है)
TimeScale - टोकरी जीवनकाल एमएस में।
Limit - टोकरी में अनुरोधों की अधिकतम संख्या

इस फ़ंक्शन को कॉल करने से काउंटर बढ़ जाता है और क्लाइंट को वापस आता है कि क्या अनुरोध सेवित होना चाहिए।

कार्यान्वयन

डेटा स्टोर करने के लिए, मैं ordered_set का ETS टेबल इस्तेमाल करता ordered_set । यह कुंजी द्वारा सॉर्ट किया गया है और डुप्लिकेट कुंजी की अनुमति नहीं देता है। तालिका एक रिकॉर्ड है

 [BucketID, Counter, CreatedAt, ModifiedAt] 

जहाँ
BucketID - {IP, BucketNum}, ऑर्डर_सेट की कुंजी भी है
Counter - ग्राहक से अनुरोधों की संख्या
CreatedAt - टोकरी बनाने का समय (ms में)
ModifiedAt - गाड़ी बदलने का समय (एमएस में)
डिबगिंग के लिए निर्माण का समय अधिक है, आप इसे मना कर सकते हैं

मुख्य समारोह:

 -spec count_hit(Id::binary(), Scale::integer(), Limit::integer()) -> {ok, continue} | {fail, Count::integer()}. %% Counts request by ID and blocks it if rate limiter fires %% ID of the client %% Scale of time (1000 = new bucket every second, 60000 = bucket every minute) %% Limit - max size of bucket count_hit(Id, Scale, Limit) -> Stamp = timestamp(), %% milliseconds since 00:00 GMT, January 1, 1970 BucketNumber = trunc(Stamp / Scale), %% with scale=1 bucket changes every millisecond Key = {BucketNumber, Id}, case ets:member(?RATERLIMITER_TABLE, Key) of false -> ets:insert(?RATERLIMITER_TABLE, {Key, 1, Stamp, Stamp }), {ok, continue}; true -> % increment counter by 1, created_time by 0, and changed_time by current one Counters = ets:update_counter(?RATERLIMITER_TABLE, Key, [{2,1},{3,0},{4,1,0, Stamp}]), % Counter, created at, changed at [BucketSize, _, _] = Counters, if (BucketSize > Limit) -> {fail, Limit}; true -> {ok, continue} end end. 

पहले, जांचें कि क्या हमारे पास टोकरी {आईपी, बकेटनंबर} है।
एक नई टोकरी के मामले में, सब कुछ बहुत सुंदर है - प्रारंभिक मानों के साथ एक नई टोकरी बनाएं और ठीक कहें।

मौजूदा टोकरी में एक काउंटर जोड़ना थोड़ा अधिक दिलचस्प है। ईटीएस मॉड्यूल आपको निर्दिष्ट नियमों के अनुसार काउंटरों को संशोधित करने की अनुमति देता है। मुझे यह पसंद आया कि अंतिम कॉल की तारीख में बदलाव के साथ आप काउंटर के वेतन वृद्धि को कैसे जोड़ सकते हैं।

तो कोड:

  Counters = ets:update_counter(?RATERLIMITER_TABLE, Key, [{2,1},{3,0},{4,1,0, Stamp}]) 

इंक्रीमेंट काउंटर नंबर 2 बाय 1 (यह सिर्फ हिट काउंटर है), सृजन के समय में 0 जोड़ें, अधिकतम मूल्य की जांच के साथ 1 से काउंटर नंबर 4 में जोड़ें। क्योंकि अधिकतम मान 0 है, चौथा काउंटर हमेशा स्टैम्प (वर्तमान समय) पर सेट है। आउटपुट पर, हमें क्रम में सभी परिवर्तनीय काउंटरों की एक सूची मिलती है, अर्थात।

[Counter, CreatedTime, ChangedTime]

नतीजतन, टेबल पर दो कॉल के लिए, हमने अपडेट किया या एक टोकरी बनाई और आउटपुट पर कॉल की संख्या प्राप्त की। वर्तमान raterlimiter कार्यान्वयन में , बदलते तालिकाओं की परमाणुता महत्वपूर्ण नहीं है, यह केवल सिंक्रोनस (कॉलिंग gen_server: call / 2 सिंक्रोनस है)।

पुराने कूड़ेदान को हटाना

समय के साथ, ग्राहक सभी ढेर को ढेर कर देते हैं और ढेर कर देते हैं। इन्हें हटाना जरूरी है।

निकालना समय-समय पर होता है। बस, निर्दिष्ट सीमा से अधिक पुराने सभी बास्केट हटा दिए जाते हैं।

मुझे कहना होगा कि एर्लैंग पर सब कुछ सुंदर और संक्षिप्त लगता है -

 remove_old_limiters(Timeout) -> NowStamp = timestamp(), Matcher = ets:fun2ms(fun ({_,_,_,Accessed}) when Accessed < (NowStamp - Timeout) -> true end), ets:select_delete(?RATERLIMITER_TABLE, Matcher). 

ets: select_delete मैच फ़ंक्शन ( MatchSpec ) से मेल खाते सभी रिकॉर्ड मिटा देता है। मैन्युअल रूप से इन match_spec को लिखना नरक है। ईट्स का उपयोग करना बहुत आसान है : fun2ms फ़ंक्शन , जो नियमित एर्लैंग फ़ंक्शन को पत्राचार फ़ंक्शन में परिवर्तित करता है। उदाहरण के लिए, उपरोक्त फ़ंक्शन

 fun ({_,_,_,Accessed}) when Accessed < (NowStamp - Timeout) -> true end 

मैचस्टेक प्रारूप में अंतिम रूप में, NowStamp = 1000 के लिए, टाइमआउट = 0 दिखता है

 [{{'_','_','_','$1'},[{'<','$1',{'-',1000,0}}],[true]}] 

ईट का उपयोग करते समय मुख्य बात: fun2ms स्रोत में एक अतिरिक्त फ़ाइल को शामिल करना नहीं भूलना है -

 -include_lib("stdlib/include/ms_transform.hrl"). 

के उपयोग

चेक_ट्रेड पर एक कॉल में उपयोग कम हो जाता है, गिनती नहीं, ज़ाहिर है, कोड और सेटिंग्स को रैट्लिमिटर एप्लिकेशन को लॉन्च करने के लिए। यहाँ मेरे Mochiweb आधारित अनुप्रयोग से एक उदाहरण है:

  {Status, _Reason} = raterlimiter:check_rate(Req:get(peer), 30000, 500), % 500 requests per 30 seconds allowed case Status of ok -> serve_request(Req, DocRoot, Path); _ -> % client wants too much information Req:respond({413,[{"Content-Type", "text/html"}, {"Retry-After", "900 (Too many requests)"}], "  IP   ,  15 ."}) end 

पूरा कोड जीथब पर उपलब्ध है। वहां आप त्रुटियां रिपोर्ट कर सकते हैं, या पुल अनुरोध कर सकते हैं।