تحليل رؤوس حد الطلبات وحساب وقت إعادة الضبط
حد قدره 100 مع 42 طلبًا متبقيًا وقيمة إعادة ضبط 60 عند 12:00 UTC يعني أن الطلبات تعود عند 12:01، أي بعد 60 ثانية. الصقوا القيم الثلاث ووقت استلامها لتخططوا لإعادة محاولة آمنة. مجانًا في متصفحكم.
- مجاني
- يعمل في متصفحك
- دون تسجيل
- بياناتك لا تغادر جهازك
شغّل الأداة مجانًا
مثال محلول
- الحد
- 100
- المتبقي
- 42
- إعادة التعيين
- 60
- الوقت الحالي
- 2026-07-25T12:00:00Z
- النهاية
- 100
- المتبقي
- 42
- نوع إعادة التعيين
- seconds_offset
- إعادة التعيين بتوقيت يونكس
- 1,784,980,860
تبدو رؤوس تحديد المعدّل بسيطة إلى أن تعبّر الخدمات المختلفة عن وقت إعادة الضبط بطرق متباينة. يستقبل هذا المحلّل الحد الأقصى والعدد المتبقي وقيمة إعادة الضبط والوقت الحالي الصريح، ثم يعيد قيما رقمية موحّدة وعدد الثواني الكاملة حتى تتاح الطلبات مجددا. وهو يدعم توقيت Unix بالثواني أو المللي ثانية، وتوقيت UTC الصارم وفق ISO 8601، والإزاحات الرقمية القصيرة.
كيف تُقرأ قيمة إعادة الضبط
تحمل رؤوس حد الطلبات عادة ثلاثة أرقام: الحد الأقصى المسموح، وعدد الطلبات المتبقية، وموعد عودة الحصة. لكن كل خدمة تكتب الرقم الأخير بطريقتها. تُعامل الأرقام الصغيرة مثل 30 أو 900 على أنها ثوانٍ تُضاف إلى الوقت الذي تحددونه. ومن مليار فما فوق تُقرأ القيمة ثواني Unix، ومن مئة مليار فما فوق تُقرأ ميلي ثانية Unix وتُحوَّل إلى ثوانٍ. ويُقبل أيضًا تاريخ ووقت بتوقيت UTC ينتهي بحرف Z. مع حد 100 و42 طلبًا متبقيًا وقيمة إعادة ضبط 60 عند الساعة 12:00 UTC، تعود الحصة عند 12:01، أي بعد 60 ثانية.
أخطاء شائعة وكيف تستخدمون النتيجة
أكثر الأخطاء كلفة هو معاملة القيمة غير المقروءة على أنها صفر، فيعيد البرنامج المحاولة فورًا ويزيد التقييد ويطيل الانقطاع. أما هنا فتنتج القيمة غير المقروءة خطأً واضحًا. وتُرفض أيضًا الأرقام السالبة والتواريخ المستحيلة وعدد متبقٍّ أكبر من الحد. ويُقرَّب وقت الانتظار إلى أعلى ثانية كاملة كي لا تُعاد المحاولة في آخر جزء من الثانية، وإذا كان موعد إعادة الضبط قد مضى فالانتظار صفر. بعد ذلك يقرر برنامجكم هل ينتظر أو يضع العمل في طابور أو يقلل التوازي أو يعرض رسالة.
افهموا كيفية التمييز بين التوقيت والإزاحة
تتبع قيم reset الرقمية أعرافا شائعة. فالقيمة التي تبلغ مليارًا فأكثر تعد ثواني Unix، والتي تبلغ مئة مليار فأكثر تعد مللي ثواني Unix وتحوّل إلى ثوان. يقبل reset أيضا وقت UTC صارما مثل 2026-07-25T12:01:00Z وفق ISO 8601، مع مللي ثوان اختيارية.
تمنع لاحقة UTC افتراض منطقة زمنية. يكشف التحقق التواريخ المستحيلة والوقت غير الصحيح والقيم المفقودة والأعداد السالبة والنصوص الدخيلة. وتنتج قيمة reset غير القابلة للتحليل خطأ إدخال بدلا من تحويلها خفية إلى صفر، لأن إعادة المحاولة الفورية قد تزيد التقييد وتطيل الانقطاع.
استخدموا نتائج حتمية في العملاء والاختبارات
ينبغي فصل تحليل القيم عن قرارات سياسة إعادة المحاولة. استخدموا هذه الإمكانية لتثبيت معلومات الحصة، ثم دعوا تطبيقكم يقرر الانتظار أو إدراج العمل في قائمة أو خفض التزامن أو عرض رسالة. فإزاحة 60 عند الظهر تماما تعطي دائما توقيتا بعد دقيقة وستين ثانية متبقية.
لا تستنتج الأداة رؤوسا خاصة بمزوّد ولا تختار التراجع الأسي، بل تعالج القيم القياسية المستخرجة.
حالات الاستخدام
جدولة إعادة محاولة آمنة
حوّلوا نصوص الرؤوس إلى مهلة بالثواني الكاملة قبل إعادة العمل الفاشل إلى قائمة الانتظار.
تشخيص تقييد المزوّد
وحّدوا الرؤوس الملتقطة وقارنوا وقت إعادة الضبط بلحظة استلام الاستجابة الدقيقة.
إنشاء اختبارات إعادة محاولة حتمية
قدّموا وقتا ثابتا وتحققوا من حسابات مستقرة من دون محاكاة ساعة النظام.
الأسئلة الشائعة
ما صيغ إعادة الضبط المقبولة؟
استخدموا إزاحة غير سالبة بالثواني، أو توقيت Unix بالثواني أو المللي ثانية، أو توقيت UTC صارما وفق ISO 8601 ينتهي بحرف Z.
هل ترسل الأداة طلبا أو تنتظر؟
لا. فهي تتحقق من قيمكم وتوحّدها فقط، ويبقى تطبيقكم مسؤولا عن سياسة إعادة المحاولة والتراجع.
ماذا يحدث إذا كان موعد إعادة الضبط قد مضى؟
يكون الانتظار صفرًا ولا يكون سالبًا أبدًا. ويفيد ذلك عند مراجعة سجلات مؤرشفة أو إشعارات وصلت متأخرة، إذ تبيّن النتيجة أن إعادة المحاولة ممكنة الآن دون اختلاق مدة انتظار.
لماذا يجب إدخال الوقت الحالي؟
كي لا تغيّر ساعة النظام الإجابة، فالمدخلات نفسها تعطي دائمًا النتيجة نفسها. أدخلوا لحظة استلام الاستجابة بثواني Unix أو بالميلي ثانية أو بتاريخ UTC، ولا تُعامل هذه القيمة أبدًا على أنها إزاحة.
ماذا لو كان عدد الطلبات المتبقية أكبر من الحد؟
يُرفض الإدخال. يجب أن يكون الحد والمتبقي عددين صحيحين غير سالبين، وألا يتجاوز المتبقي الحد. كما تعطي قيمة إعادة الضبط غير المقروءة خطأً بدل الصفر، تجنبًا لإعادة محاولة فورية.
أدوات ذات صلة
للمطوّرين — الوصول عبر API
كل ما في هذه الصفحة متاح برمجيًا. هذا القسم موجّه للفرق التقنية التي تريد ربط الأداة بأنظمتها الخاصة؛ بقية المستخدمين يمكنهم استخدام الأداة أعلاه مباشرة دون الحاجة لقراءة ما يلي.
الـEndpoint
صادِق على طلبك بترويسة Bearer، وأرسل طلب POST واحدًا لتدخل مهمتك قائمة التنفيذ فورًا؛ ثم تستلم النتيجة عبر webhook أو رابط موقّع.
استدعِ الخدمة من بيئتك
curl -X POST https://api.kit.forhosting.com/security/rate-limit-header-parse \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}'const res = await fetch("https://api.kit.forhosting.com/security/rate-limit-header-parse", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/security/rate-limit-header-parse",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/security/rate-limit-header-parse", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/security/rate-limit-header-parse", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)مثال على الطلب
{
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
}مثال على الاستجابة
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "security.rate_limit_header_parse",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}الواجهة غير متزامنة: تستلم task_id فور الإرسال، ويمكنك الاستعلام عن الحالة بمعدل طلب واحد في الثانية.
الأسعار
السعر معلن كما تراه: لا tokens ولا نظام نقاط؛ وإن فشلت المهمة فلن تُحاسَب عليها.
الأخطاء
| HTTP | الرمز | المعنى |
|---|---|---|
401 | unauthorized | مفتاح الوصول مفقود أو غير صالح؛ تحقق من ترويسة Bearer في طلبك. |
402 | insufficient_balance | رصيدك لا يكفي لتنفيذ هذه المهمة؛ أعد شحن الرصيد ثم أعد المحاولة. |
404 | unknown_type | نوع المهمة المطلوب غير موجود في الكتالوج — راجع الاسم المرسل في الطلب. |
429 | rate_limited | تجاوزت الحد المسموح من الطلبات؛ انتظر قليلًا ثم أعد المحاولة. |
ملاحظات تقنية
ولأنكم تقدّمون الوقت الحالي، تعطي المدخلات نفسها النتيجة ذاتها في الاختبارات والمتصفح وتكاملات API.
وحّدوا الرؤوس قبل جدولة إعادة المحاولة
ويحتفظ بنص reset الأصلي، ويوضح هل فسره كتوقيت مطلق أم إزاحة بالثواني، ويعيد وقت Unix موحّدا. وإذا مضى وقت إعادة الضبط تكون المهلة صفرا لا قيمة سالبة. تصلح النتيجة للسجلات وبرمجيات إعادة المحاولة وتأخير قوائم الانتظار وبيانات الاختبار، من دون تكرار القواعد نفسها في كل تكامل. تعرض واجهات API عادة الحد الأقصى للطلبات والعدد المتبقي وقيمة إعادة الضبط، لكن على العميل تحويل هذه النصوص إلى قرار آمن. أرسلوا القيم في limit وremaining وreset، وحددوا في current_time لحظة استلام الاستجابة. يتحقق المحلّل من أن limit وremaining عددان صحيحان غير سالبين، ويرفض عددا متبقيا يتجاوز الحد. يقرّب الحقل seconds_until_reset إلى الثانية الأعلى كي لا تعيدوا المحاولة خلال الجزء الأخير من فترة الانتظار.
افهموا كيفية التمييز بين التوقيت والإزاحة
أما الأعداد الأصغر غير السالبة فتضاف إلى current_time كإزاحة. لذلك تعمل 30 أو 900 كمهلة، بينما تبقى قيم العصر الحديثة أوقاتا مطلقة. ويقبل current_time الصيغ المطلقة نفسها، لكنه لا يعامل كإزاحة.
استخدموا نتائج حتمية في العملاء والاختبارات
يُقدَّم current_time صراحة، لذلك لا تغيّر ساعة النظام أو الشبكة أو الإعدادات المحلية أو العشوائية الإجابة. وهكذا تتطابق نتيجة المتصفح مع API وتظل اختبارات الانحدار ثابتة. وتعطي أوقات إعادة الضبط السابقة صفرا، وهو مفيد مع Webhook المتأخر أو السجلات المؤرشفة. نسخة المتصفح مجانية، وتستخدم استدعاءات API الآلية السعر الأساسي المعروض $0.002 لكل عنصر.
أسئلة تقنية
ما تكلفة استدعاء API؟
يستخدم كل عنصر السعر الأساسي المبين وهو $0.002؛ وتنفذ أداة المتصفح الحساب نفسه محليا.
لماذا يجب تقديم current_time؟
يجعل الوقت الصريح الحساب حتميا والنتائج قابلة للتكرار في العملاء والاختبارات.
ماذا يحدث إذا مضى وقت إعادة الضبط؟
يُقيد seconds_until_reset عند صفر، بينما يحتفظ reset_at_unix بالوقت المطلق الذي جرى تحليله.