محدودسازی نرخ

سقف‌های نرخ API اوربی‌وی‌پی‌ان، رده‌ها، سرآیندهای پاسخ و بهترین شیوه‌های ساخت یکپارچگی‌هایی را بشناسید که مرزهای نرخ را رعایت می‌کنند و با گلوگاه‌سازی به‌درستی کنار می‌آیند.

مرجع API

محدودسازی نرخ

OrbVPN برای تضمین استفادهٔ منصفانه و پایداری سکو سقف نرخ اعمال می‌کند. بیاموزید سقف‌ها چگونه اعمال می‌شوند، چگونه مصرف خود را پایش کنید و چگونه در یکپارچگی‌های خود با گلوگاه‌سازی کنار بیایید.


رده‌های سقف نرخ

سقف‌های نرخ بسته به ردهٔ نقطهٔ پایانی و سطح احراز هویت شما در دامنه‌های گوناگون اعمال می‌شوند. هر رده شمارندهٔ مستقل خود را دارد.

ردهسقفدامنهتوضیح
سراسری۱۰۰ درخواست در دقیقهبرای هر نشانی IPبر همهٔ درخواست‌های بدون احراز هویت و به‌عنوان خط پایهٔ کل ترافیک یک IP اعمال می‌شود.
نقاط پایانی احراز هویت۱۰ درخواست در دقیقهبرای هر نشانی IPورود، ثبت‌نام، بازنشانی گذرواژه و دیگر نقاط پایانی احراز هویت. برای جلوگیری از حملهٔ جست‌وجوی فراگیر سخت‌گیرانه‌تر است.
نقاط پایانی محافظت‌شده۳۰۰ درخواست در دقیقهبرای هر کاربر احراز هویت‌شدهنقاط پایانی استاندارد API که به رمزینهٔ حامل معتبر نیاز دارند. بر پایهٔ شناسهٔ کاربر دنبال می‌شوند، نه IP.
نقاط پایانی مدیریتی۱۰۰۰ درخواست در دقیقهبرای هر کاربر مدیرنقاط پایانی اداری و مدیریتی. سقف بالاتر برای گردانندگان سکو.
OrbGuard Labs۶۰ درخواست در دقیقهبرای هر کلید APIنقاط پایانی هوش تهدید، تشخیص کلاهبرداری و جرم‌شناسی. بر پایهٔ کلید API دنبال می‌شوند.

چند رده می‌توانند هم‌زمان اعمال شوند

یک درخواست ممکن است به حساب چند رده گذاشته شود. مثلاً درخواستی احراز هویت‌شده به نقطهٔ پایانی محافظت‌شده هم به حساب ردهٔ سراسری (برای هر IP) و هم ردهٔ محافظت‌شده (برای هر کاربر) می‌رود. محدودکننده‌ترین سقف نخست اعمال می‌شود.


سرآیندهای سقف نرخ

هر پاسخ API سه سرآیند دارد که دقیقاً می‌گویند در پنجرهٔ کنونی سقف نرخ کجا ایستاده‌اید.

سرآیندنوعتوضیح
X-RateLimit-Limitعدد صحیحبیشینه شمار درخواست‌های مجاز در پنجرهٔ زمانی کنونی.
X-RateLimit-Remainingعدد صحیحشمار درخواست‌هایی که در پنجرهٔ کنونی برایتان مانده است.
X-RateLimit-Resetمُهر زمانی یونیکسزمان مبدأ UTC (برحسب ثانیه) که پنجرهٔ کنونی سقف نرخ در آن بازنشانی می‌شود.

نمونهٔ سرآیندهای پاسخ

HTTP/1.1 200 OK
Content-Type: application/json
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 247
X-RateLimit-Reset: 1707350460

X-RateLimit-Remaining را پایش کنید

مقدار X-RateLimit-Remaining را در برنامهٔ خود دنبال کنید. وقتی زیر ۱۰٪ سقف افتاد، به‌جای انتظار برای گلوگاه خوردن، پیشدستانه کند کردن نرخ درخواست‌های خود را در نظر بگیرید.


۴۲۹ درخواست‌های بیش‌ازحد

وقتی از سقف نرخ بگذرید، API کد وضعیت 429 را همراه با خطای RATE_LIMITED برمی‌گرداند. پاسخ سرآیند Retry-After را دارد که نشان می‌دهد پیش از فرستادن درخواست دیگر چند ثانیه باید صبر کنید.

429گذر از سقف نرخ
{
  "success": false,
  "error": {
    "code": "RATE_LIMITED",
    "message": "Too many requests. Please wait before retrying.",
    "details": {
      "limit": 100,
      "window": "60s",
      "retryAfter": 23,
      "tier": "global"
    }
  }
}

سرآیندهای پاسخ در ۴۲۹

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 23
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1707350483

سرآیند Retry-After را رعایت کنید

همیشه مقدار Retry-After را رعایت کنید. کلاینت‌هایی که پس از دریافت ۴۲۹ به فرستادن درخواست ادامه می‌دهند ممکن است موقتاً در سطح IP مسدود شوند. سوءاستفادهٔ پیوسته می‌تواند به مسدودسازی دائمی بینجامد.


راهبرد تلاش دوباره: عقب‌نشینی نمایی با نوسان تصادفی

وقتی 429 یا خطای گذرای سرور (500، 502، 503) می‌گیرید، برای تلاش دوباره از عقب‌نشینی نمایی با نوسان تصادفی استفاده کنید. این کار جلوی تلاش هم‌زمان همهٔ کلاینت‌ها در یک لحظه را می‌گیرد (مشکل «هجوم گله‌ای»).

1

خطا را دریافت کنید

پاسخ ۴۲۹، ۵۰۰، ۵۰۲ یا ۵۰۳ را تشخیص دهید. اگر سرآیند Retry-After هست آن را بخوانید.

2

تأخیر را محاسبه کنید

از این فرمول استفاده کنید: delay = min(base * 2^attempt, maxDelay) + random_jitter. با پایهٔ ۱ ثانیه شروع کنید.

3

صبر کنید و دوباره تلاش کنید

به اندازهٔ تأخیر محاسبه‌شده صبر کنید، سپس درخواست را با همان پارامترها و سرآیندها دوباره بفرستید.

4

سقف تلاش دوباره را رعایت کنید

بیشینه شمار تلاش دوباره را تعیین کنید (پیشنهادی: ۵). پس از پایان همهٔ تلاش‌ها، خطا را به کاربر نشان دهید یا برای بررسی ثبتش کنید.

زمان‌بندی عقب‌نشینی

Attempt 1:  1s  + jitter(0-500ms)  =  ~1.0s - 1.5s
Attempt 2:  2s  + jitter(0-500ms)  =  ~2.0s - 2.5s
Attempt 3:  4s  + jitter(0-500ms)  =  ~4.0s - 4.5s
Attempt 4:  8s  + jitter(0-500ms)  =  ~8.0s - 8.5s
Attempt 5: 16s  + jitter(0-500ms)  = ~16.0s - 16.5s

هرگاه Retry-After هست از آن استفاده کنید

اگر پاسخ سرآیند Retry-After دارد، به‌جای فرمول نمایی از آن مقدار به‌عنوان تأخیر اولیهٔ خود استفاده کنید. سرور دقیقاً می‌گوید چقدر باید صبر کنید.


نمونه‌های کد رسیدگی به سقف نرخ

نمونه‌های کامل و کارا که نشان می‌دهند چگونه سقف‌های نرخ را در چهار زبان تشخیص دهید و به‌درستی مدیریت کنید.

#!/bin/bash
# Rate-limit-aware API caller with exponential backoff

BASE_URL="https://api.orbai.world"
MAX_RETRIES=5

call_api() {
  local method="$1"
  local path="$2"
  local token="$3"

  for attempt in $(seq 0 $MAX_RETRIES); do
    response=$(curl -s -w "\n%{http_code}" \
      -X "$method" "${BASE_URL}${path}" \
      -H "Authorization: Bearer $token" \
      -H "Content-Type: application/json" \
      -D /tmp/headers.txt)

    http_code=$(echo "$response" | tail -n1)
    body=$(echo "$response" | sed '$d')

    if [ "$http_code" -eq 200 ] || [ "$http_code" -eq 201 ]; then
      echo "$body"
      return 0
    fi

    if [ "$http_code" -eq 429 ]; then
      # Read Retry-After header
      retry_after=$(grep -i "Retry-After" /tmp/headers.txt \
        | tr -d '\r' | awk '{print $2}')
      remaining=$(grep -i "X-RateLimit-Remaining" /tmp/headers.txt \
        | tr -d '\r' | awk '{print $2}')

      echo "Rate limited. Remaining: $remaining. Waiting ${retry_after}s..." >&2
      sleep "$retry_after"
      continue
    fi

    if [ "$http_code" -ge 500 ] && [ "$attempt" -lt "$MAX_RETRIES" ]; then
      delay=$(echo "2^$attempt" | bc)
      jitter=$(echo "scale=2; $RANDOM/32768*0.5" | bc)
      wait_time=$(echo "$delay + $jitter" | bc)
      echo "Server error $http_code. Retrying in ${wait_time}s..." >&2
      sleep "$wait_time"
      continue
    fi

    # Non-retryable error
    echo "$body" >&2
    return 1
  done

  echo "Max retries exceeded" >&2
  return 1
}

# Usage
call_api "GET" "/api/v1/users/me" "$ACCESS_TOKEN"

بهترین شیوه‌ها

این رهنمودها را دنبال کنید تا با خیال راحت زیر سقف نرخ بمانید و یکپارچگی‌های کارآمد بسازید.

پاسخ‌ها را در حافظهٔ نهان بگذارید

پاسخ‌های GET را به‌صورت محلی نهان کنید. داده‌هایی مانند فهرست سرورها و نمایهٔ کاربران کم تغییر می‌کنند. با سرآیندهای ETag و If-None-Match دادهٔ نهان‌شده را بدون مصرف سهمیهٔ خود اعتبارسنجی کنید.

از نقاط پایانی گروهی استفاده کنید

هر جا موجود است، از نقاط پایانی گروهی استفاده کنید تا به‌جای فراخوان‌های تک‌تک در حلقه، چند منبع را در یک درخواست بگیرید یا تغییر دهید.

به‌جای نظرخواهی مکرر از وب‌هوک استفاده کنید

به‌جای پرسیدن مکرر دربارهٔ تغییرها، در رویدادهای وب‌هوک مشترک شوید. وب‌هوک‌ها داده را بی‌درنگ به سرور شما می‌فرستند و فراخوان‌های تکراری API را به‌کلی حذف می‌کنند.

برای دادهٔ بی‌درنگ از WebSocket استفاده کنید

برای به‌روزرسانی‌های زنده مانند وضعیت اتصال، اعلان‌ها و هشدارهای تهدید از API وب‌سوکت استفاده کنید. یک اتصال پایدار جای صدها درخواست نظرخواهی را می‌گیرد.

صف‌بندی درخواست پیاده کنید

فراخوان‌های خروجی API را در صف بگذارید و با نرخی پایدار زیر سقف خود پردازششان کنید. این کار جلوی جهش‌هایی را می‌گیرد که گلوگاه‌سازی را به راه می‌اندازند و یکپارچگی شما را پیش‌بینی‌پذیرتر می‌کند.

مصرف خود را پایش کنید

سرآیند X-RateLimit-Remaining را از هر پاسخ ثبت کنید. وقتی باقی‌مانده زیر ۱۰٪ افتاد هشدار تنظیم کنید تا پیشدستانه الگوی درخواست‌های خود را تنظیم کنید.


پرسش‌های پرتکرار

اگر پس از ۴۲۹ به فرستادن درخواست ادامه دهم چه می‌شود؟

کلاینت‌هایی که پیوسته پاسخ‌های ۴۲۹ و سرآیند Retry-After را نادیده می‌گیرند ممکن است موقتاً در سطح IP مسدود شوند. سوءاستفادهٔ پیوسته (درخواست‌های مداوم پس از چند هشدار) می‌تواند به مسدودسازی دائمی نشانی IP یا کلید API بینجامد.

آیا سقف‌های نرخ بر اتصال‌های WebSocket اعمال می‌شوند؟

اتصال‌های وب‌سوکت مدل محدودسازی نرخ خود را دارند. گذردهی پیام برای هر اتصال محدود است، اما چون سربار درخواست‌به‌درخواست وجود ندارد، سقف‌ها به‌مراتب بالاتر از نقاط پایانی REST هستند. برای جزئیات راهنمای وب‌سوکت را ببینید.

می‌توانم سقف نرخ بالاتری درخواست کنم؟

مشتریان سازمانی می‌توانند سقف نرخ دلخواه درخواست کنند. برای گفت‌وگو دربارهٔ نیازهای خود با مدیر حساب خود تماس بگیرید یا از راه درگاه پشتیبانی با ما در ارتباط باشید.

آیا سقف‌های نرخ میان کلیدهای API مشترک‌اند؟

خیر. هر کلید API (برای OrbGuard Labs) و هر کاربر احراز هویت‌شده (برای OrbNET) شمارندهٔ مستقل سقف نرخ خود را دارد. ردهٔ سراسری برای هر نشانی IP است و تنها رده‌ای است که میان همهٔ درخواست‌های یک مبدأ مشترک می‌ماند.

سقف نرخ سازمانی

اگر یکپارچگی شما به گذردهی بیشتری از آنچه رده‌های استاندارد اجازه می‌دهند نیاز دارد، برای گفت‌وگو دربارهٔ بسته‌های سازمانی سقف نرخ متناسب با کاربرد خود با تیم OrbVPN تماس بگیرید.


یکپارچگی‌های تاب‌آور بسازید

رسیدگی به سقف نرخ را با مدیریت درست خطا ترکیب کنید تا یکپارچگی‌هایی بسازید که با هر شرایط API به‌درستی کنار می‌آیند. برای کدهای مفصل خطا مرجع کامل خطاها را کاوش کنید.

دیدن مرجع خطاها