এনগিনেক্স - অনুরোধ সীমাবদ্ধ করার সময় নোডলে বিকল্পটি কী করে?

Question

Nginx HttpLimitReq মডিউল অনুরোধ আইপি দ্বারা সীমাবদ্ধ করা যেতে পারে। তবে, "নোডলে" বিকল্পটি কী করে তা আমি বুঝতে পারছি না।

সীমা ফেটানোর বিলম্বের মধ্যে অতিরিক্ত অনুরোধগুলি যদি প্রয়োজন হয় না, আপনার নোডলে ব্যবহার করা উচিত

limit_req   zone=one  burst=5  nodelay;

Answer 1

ডকুমেন্টেশন এখানে একটি ব্যাখ্যা যে আপনি যা চান তা মত শোনায় জানেন যে আছে:

দিকনির্দেশনাটি অঞ্চল (অঞ্চল) এবং সর্বাধিক সম্ভাব্য অনুরোধের বিস্ফোরণ (বিস্ফোরণ) নির্দিষ্ট করে। হারটি যদি জোনে বর্ণিত দাবিগুলি ছাড়িয়ে যায় তবে অনুরোধটি বিলম্বিত হয়, যাতে নির্দিষ্ট গতিতে অনুসন্ধানগুলি প্রক্রিয়া করা হয়

আমি যা বুঝি সেগুলি থেকে, বিস্ফোরণের উপর অনুরোধগুলি বিলম্বিত হবে (আরও সময় নিন এবং সেগুলি সরবরাহ করা পর্যন্ত অপেক্ষা করুন), nodelayবিকল্পগুলির সাথে দেরিটি ব্যবহৃত হয় না এবং অতিরিক্ত অনুরোধগুলি 503 ত্রুটির সাথে অস্বীকৃত হয়।

এই ব্লগ পোস্ট ( সংরক্ষণাগার ..org ) কীভাবে রেঞ্জ সীমাবদ্ধতা এনজিএনএক্সে কাজ করে তা ভাল ব্যাখ্যা দেয়:

আপনি যদি আমার মতো হন তবে আপনি সম্ভবত ভাবছেন যে হ্যাক ফেটে আসলে কী বোঝায়। কৌশলটি এখানে: 'বালতি' দিয়ে 'ফেটে' শব্দটি প্রতিস্থাপন করুন এবং ধরে নিন যে প্রতিটি ব্যবহারকারীর জন্য 5 টোকেন দিয়ে একটি বালতি দেওয়া হয়েছে। প্রতিবার যখন তারা প্রতি সেকেন্ডে 1 টি অনুরোধের হার ছাড়িয়েছে, তাদের একটি টোকেন দিতে হবে। একবার তাদের সমস্ত টোকেন ব্যয় করার পরে, তাদের একটি এইচটিটিপি 503 ত্রুটি বার্তা দেওয়া হবে যা মূলত 'ব্যাক অফ ম্যান!' এর মান হয়ে দাঁড়িয়েছে।

Comments

আমি আপনাকে ভুল বলে মনে করি, এনজিএনএক্স ম্যানুয়াল জানিয়েছে: "অতিরিক্ত অনুরোধগুলি যতক্ষণ না তাদের সংখ্যা সর্বাধিক বিস্ফোরণের আকার ছাড়িয়ে যায় ততক্ষণ বিলম্বিত হয়"। নোট করুন যে যতক্ষণ না সর্বাধিক ফেটে যায় ততক্ষণ আপনি যা বলেছিলেন তার চেয়ে আলাদা অর্থ । আপনি অতিরিক্ত অনুরোধের সাথে বিস্ফোরণকেও সঙ্কুচিত করেছেন , আমি বিশ্বাস করি অতিরিক্ত অনুরোধের অর্থ এটি জোনটির উপরে, যদিও এটি এখনও সর্বাধিক বিস্ফোরণের নীচে ।

— হেন্ডি ইরাওয়ান

Answer 2

টিএল; ডিআর: নোডলে বিকল্পটি কার্যকর যদি আপনি অনুরোধের মধ্যে অনুমোদিত ব্যবধানকে সীমাবদ্ধ না করে কোনও হার সীমা চাপিয়ে দিতে চান।

অন্যান্য উত্তরগুলি হজম করতে আমার খুব কষ্ট হয়েছিল এবং তারপরে আমি এনগিনেক্সের কাছ থেকে নতুন ডকুমেন্টেশনগুলি আবিষ্কার করেছি যার উদাহরণগুলির উত্তর: https://www.nginx.com/blog/rate-limiting-nginx/

এখানে প্রাসঙ্গিক অংশ। প্রদত্ত:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

location /login/ {
  limit_req zone=mylimit burst=20;
  ...
}

বিস্ফোরণ প্যারামিটারটি নির্ধারণ করে যে কোনও ক্লায়েন্ট জোন দ্বারা নির্ধারিত হারের চেয়ে কত বেশি অনুরোধ করতে পারে (আমাদের নমুনা মাইলিমিট অঞ্চল সহ, হারের সীমা প্রতি সেকেন্ডে 10 টি অনুরোধ, বা প্রতি 100 মিলিসেকেন্ডে 1)। একটি অনুরোধ যা পূর্ববর্তীটি একটি কাতারে রাখার পরে 100 মিলিসেকেন্ডের চেয়ে শীঘ্রই উপস্থিত হয় এবং আমরা এখানে সারিটির আকার 20 এ সেট করছি।

এর অর্থ যদি কোনও প্রদত্ত আইপি ঠিকানা থেকে একসাথে 21 টি অনুরোধ আসে, এনজিআইএনএক্স প্রথমটিকে অবিলম্বে আপস্ট্রিম সার্ভার গ্রুপে ফরোয়ার্ড করে এবং বাকী 20 টি সারিতে ফেলে দেয়। এরপরে এটি প্রতি 100 মিলিসেকেন্ডে সারিযুক্ত অনুরোধটি ফরওয়ার্ড করে এবং কেবলমাত্র যদি আগত অনুরোধটি সারিবদ্ধ অনুরোধের সংখ্যা 20 এর বেশি হয়ে যায় তখন ক্লায়েন্টকে 503 ফেরত দেয়।

আপনি যদি নোডলে যোগ করেন:

location /login/ {
  limit_req zone=mylimit burst=20 nodelay;
  ...
}

নোডলে প্যারামিটারের সাহায্যে এনজিআইএনএক্স এখনও বিস্ফোরণ প্যারামিটার অনুযায়ী কাতারে স্লট বরাদ্দ করে এবং কনফিগার করা হারের সীমা চাপিয়ে দেয়, তবে সারিযুক্ত অনুরোধগুলির ফরওয়ার্ডিংয়ের ফাঁক করে নয়। পরিবর্তে, যখন কোনও অনুরোধটি "খুব শীঘ্রই" উপস্থিত হয়, এনজিআইএনএক্স ততক্ষণ তা ফরওয়ার্ড করে দেয় যতক্ষণ না তার জন্য সারিটিতে স্লট উপলব্ধ থাকে। এটি সেই স্লটটিকে "নেওয়া" হিসাবে চিহ্নিত করেছে এবং উপযুক্ত সময় না পার হওয়া পর্যন্ত এটি অন্য অনুরোধের দ্বারা ব্যবহারের জন্য মুক্ত করে না (আমাদের উদাহরণস্বরূপ, 100 মিলি সেকেন্ডের পরে)।

Answer 3

আমি যেভাবে দেখছি তা নিম্নরূপ:

1. জোনের হার অতিক্রম না করা পর্যন্ত অনুরোধগুলি যথাসম্ভব দ্রুত পরিবেশন করা হবে। জোনের হারটি "গড়", তাই আপনার হারটি যদি হয় 1r/sএবং ফেটে 10যায় তবে 10 সেকেন্ডের উইন্ডোতে আপনার 10 টি অনুরোধ থাকতে পারে।

2. জোনের হার অতিক্রম করার পরে:

   ক। ছাড়া nodelay, আরও অনুরোধগুলি burstবিলম্বিত হবে।

   খ। সাথে nodelay, আরও অনুরোধগুলি burstযত দ্রুত সম্ভব পরিবেশন করা হবে।

3. burstঅতিক্রম করার পরে , ফাটানো উইন্ডোটির মেয়াদ শেষ না হওয়া অবধি সার্ভার ত্রুটির প্রতিক্রিয়া ফিরিয়ে দেবে। যেমন হার 1r/sএবং বিস্ফোরণের জন্য 10, ক্লায়েন্টকে পরবর্তী স্বীকৃত অনুরোধের জন্য 10 সেকেন্ড পর্যন্ত অপেক্ষা করতে হবে।

Answer 4

সেটিংসটি সংজ্ঞায়িত করে যে অনুরোধগুলি বিলম্বিত হবে কিনা যাতে তারা পছন্দসই হারের সাথে সামঞ্জস্য হয় বা তারা কেবল প্রত্যাখ্যানযোগ্য হবে ... কিছুটা হার সীমাবদ্ধতা সার্ভার দ্বারা পরিচালিত হয় বা ক্লায়েন্টের কাছে দায়বদ্ধ হয়ে যায় কিনা।

nodelay বর্তমান

অনুরোধগুলি যত তাড়াতাড়ি সম্ভব পরিচালনা করা হবে; নির্দিষ্ট সীমাতে পাঠানো কোনও অনুরোধ হিসাবে কোড সেট সহ প্রত্যাখ্যান করা হবেlimit_req_status

nodelay অনুপস্থিত (ওরফে বিলম্ব)

অনুরোধগুলি এমন হারে পরিচালিত হবে যা নির্দিষ্ট সীমাতে মেনে চলে। সুতরাং উদাহরণস্বরূপ যদি কোনও হার 10 রেকর্ড / সেটের সেট করা থাকে তবে প্রতিটি অনুরোধ> = .1 (1 / হার) সেকেন্ডে পরিচালনা করা হবে, যার ফলে হারকে ছাড়িয়ে যাওয়ার অনুমতি দেওয়া হবে না, তবে অনুরোধগুলি ব্যাক আপ করার অনুমতি দেয়। যদি বালতিটি উপচে পড়ার জন্য পর্যাপ্ত অনুরোধগুলি ব্যাক আপ হয় (যা একই সাথে সংযোগ সীমাতেও প্রতিরোধ করা হত), তবে সেগুলি কোড সেট হিসাবে প্রত্যাখ্যান করা হবে limit_req_status।

বেহাল বিবরণগুলি এখানে: https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_limit_req_module.c#L263 যেখানে সীমাটি এখনও পাস না হয়ে গেলে সেই যুক্তিটি লাথি দেয় এবং এখন বিলম্ব optionচ্ছিকভাবে অনুরোধে প্রয়োগ করা হবে। nodelayনির্দেশিকা থেকে বিশেষত প্রয়োগটি এখানে কার্যকর হয়: https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_limit_req_module.c#L495 যার ফলে delayউপরের মান 0 টি ট্রিগার হয় অবিলম্বে ফেরত হ্যান্ডলার NGX_DECLINEDযা পরবর্তী হ্যান্ডলারের কাছে অনুরোধটি পাস করে (পরিবর্তে NGX_AGAINকার্যকরভাবে এটি পুনরায় প্রক্রিয়াজাতকরণের জন্য অনুরোধ করবে)।

Answer 5

Https://www.nginx.com/blog/rate-limiting-nginx/ থেকে পরিচয় পড়ার সময় আমি প্রথম বুঝতে পারি নি ।

এখন আমি নিশ্চিত যে আমি বুঝতে পেরেছি এবং আমার উত্তর এ পর্যন্ত সেরা। :)

ধরুন: 10r/sসেট করা আছে, সার্ভারের সর্বাধিক সক্ষমতা হ'ল উদাহরণস্বরূপ 10000r/sযা রয়েছে 10r/msএবং এই মুহূর্তে কেবলমাত্র 1 জন ক্লায়েন্ট রয়েছে।

তাই এখানে মধ্যে মূল পার্থক্য 10r/s per IP burst=40 nodelayএবং 10r/s per IP burst=40।

Https://www.nginx.com/blog/rate-limiting-nginx/ নথিভুক্ত হিসাবে ( আমি প্রথম নিবন্ধটি পড়ার দৃ strongly়ভাবে পরামর্শ দিচ্ছি ( দ্বি-স্তরের হার সীমাবদ্ধকরণ বিভাগটি বাদে )), এই আচরণটি একটি সমস্যা সমাধান করে। কোনটি?:

আমাদের উদাহরণস্বরূপ, কাতারে থাকা 20 তম প্যাকেটটি এগিয়ে যেতে 2 সেকেন্ড অপেক্ষা করে, এমন সময়ে এটির কোনও প্রতিক্রিয়া ক্লায়েন্টের পক্ষে আর কার্যকর নাও হতে পারে।

আমি যে খসড়াটি তৈরি করেছি তা পরীক্ষা করুন, 40thঅনুরোধটি তখনই সাড়া পায় 1sযখন অন্যটি 40thসাড়া দেয় 4s।

এটি সার্ভারের সক্ষমতাটির সর্বোত্তম ব্যবহার করতে পারে: x r/sপ্রদত্ত ক্লায়েন্ট / আইপি সীমাবদ্ধ রেখে এখনও যত তাড়াতাড়ি প্রতিক্রিয়া পাঠায় ।

তবে এখানে খরচও আছে। ব্যয় হবে:

আপনার যদি অনেক ক্লায়েন্ট সার্ভারে কাতারে থাকে তবে আসুন ক্লায়েন্ট A, Bএবং C।

ছাড়া nodelay, অনুরোধগুলি অনুরূপ অর্ডারে সরবরাহ করা হয় ABCABCABC।
সাথে nodelay, ক্রমটি সম্ভবত হওয়ার সম্ভাবনা বেশি AAABBBCCC।

---

আমি এখানে নিবন্ধটি https://www.nginx.com/blog/rate-limiting-nginx/ সংক্ষিপ্ত করতে চাই ।

সর্বোপরি, সবচেয়ে গুরুত্বপূর্ণ কনফিগারেশনটি হ'ল x r/s।

1. x r/s কেবলমাত্র, অতিরিক্ত অনুরোধগুলি তত্ক্ষণাত্ প্রত্যাখাত হয়।

2. x r/s+ burst, অতিরিক্ত অনুরোধগুলি সারিবদ্ধ রয়েছে।

1.বনাম 2., ব্যয়টি হ'ল ক্লায়েন্টের পক্ষে, সারিযুক্ত অনুরোধগুলি পরবর্তী পুনর্বিবেচনার সম্ভাবনা গ্রহণ করে যা পরিবেশন করার সুযোগ পাবে।

উদাহরণস্বরূপ, 10r/s burst=20বনাম 10r/s, 11thঅনুরোধটি পরবর্তী শর্তে অবিলম্বে প্রত্যাখ্যান করার কথা রয়েছে তবে এখন এটি সারিযুক্ত এবং পরিবেশন করা হবে। 11thঅনুরোধ লাগে 21thঅনুরোধ এর সুযোগ।

3. x r/s+ + burst+ + nodelay, ইতিমধ্যে ব্যাখ্যা।

---

পিএস নিবন্ধের দ্বি-স্তরের হার সীমাবদ্ধকরণ বিভাগটি খুব বিভ্রান্তিকর। আমি বুঝতে পারছি না তবে ব্যাপারটি মনে হচ্ছে না।

উদাহরণ স্বরূপ:

এই কনফিগারেশনটি স্থানে রেখে, এমন ক্লায়েন্ট যা 8 টি আর / এস-এ অনুরোধের একটি অবিরাম প্রবাহ তৈরি করে তা নীচের আচরণটি অনুভব করে।

8 আর / এস? গম্ভীরভাবে? ছবিতে প্রদর্শিত 3 সেকেন্ডের মধ্যে 17 টি অনুরোধ রয়েছে, 17/3 = 8?