असली सीमा पहचानें
HTTP 429 बहुत अधिक अनुरोध दर्शाता है और उसमें Retry-After हो सकता है। गिनती और दायरा सेवा तय करती है। कम औसत भी छोटी समय-खिड़की की सीमा पार कर सकता है।
| अवधारणा | क्या सीमित है | उपयोगी कदम |
|---|---|---|
| कोटा | एक अवधि में कुल मात्रा | साझा बजट की योजना। |
| दर | छोटी अवधि में आगमन | शुरुआत के समय फैलाएँ। |
| समवर्ती काम | चल रहे ऑपरेशन | एकसाथ काम सीमित करें। |
| Retry-After: 120 | 120 सेकंड प्रतीक्षा | कुल समय और सुरक्षित दोहराव जाँचें। |
अनुमत माँग की योजना
- गिनती की कुंजी जाँचें: खाता, प्रोजेक्ट, उपयोगकर्ता या मार्ग। रीसेट का समय-क्षेत्र, प्रति काम लागत और साझा बजट समझें।
- सीमित कतार से अचानक भार फैलाएँ और जारी काम अलग सीमित करें। रद्द करने का संकेत आगे भेजें और बेकार हो चुके काम हटाएँ।
- Retry-After को HTTP तारीख या सेकंड में प्रतीक्षा मानें। कुल समय-सीमा में उसका पालन करें और अनुपस्थित होने पर भी प्रतीक्षा सीमित रखें।
सुरक्षा को बायपास किए बिना प्रयास
429 सुरक्षित दोहराव का प्रमाण नहीं है। इडेम्पोटेंसी, कुल समय और प्रयासों की सीमा जाँचें। अस्वीकृति और कतार मापें; स्थायी माँग अनुबंध से अधिक हो तो ज़रूरत घटाएँ या क्षमता पर सहमति करें।
प्राथमिक स्रोत
रेट-लिमिट अब्यूज़ को देखने लायक बनाएं
रिक्वेस्ट लिमिट तब बेहतर काम करती हैं जब वे सही इस्तेमाल को असामान्य व्यवहार से अलग करती हैं और एक समझने लायक इवेंट बनाती हैं। सिर्फ़ एरर कोड ही अब्यूज़ पैटर्न की शुरुआत, ड्यूरेशन और पहुँच को छिपा सकते हैं।
- बिना किसी सीक्रेट के थ्रेशहोल्ड, फ़ैसला, रूट और मिनिमम कॉन्टेक्स्ट रिकॉर्ड करें।
- बार-बार मना करने पर सही यूज़र्स पर पड़ने वाले असर को मिलाएं।
- टेस्ट करें कि अलर्ट से इन्वेस्टिगेशन या उसी हिसाब से ट्यूनिंग होती है।
प्राथमिक स्रोत: ACSC and partners — Event logging and threat detection. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.