عبارات مثل "50K اتصال" و"100 thread متزامن" التي تراها كثيرًا في باقات البروكسي تعني شيئًا واحدًا: عدد اتصالات TCP التي يمكنك إبقاؤها مفتوحة في الوقت نفسه. هذا الحد يحدد مباشرةً مدى السرعة التي يمكنك العمل بها، ورسائل الخطأ عند تجاوزه تكون مضللة في أغلب الأحيان.
في هذا المقال نتناول ما هو التزامن، وكيف يُحسب الرقم الصحيح، وكيف يُشخَّص تجاوز الحد.
التزامن ومعدل الطلبات ليسا الشيء نفسه
يُخلط باستمرار بين مفهومين:
الصيغة البسيطة لقانون Little: معدل الطلبات = التزامن ÷ متوسط مدة الطلب. إذا كان لديك 20 اتصالًا متزامنًا وكان كل طلب يستغرق 500 ms في المتوسط، فيمكنك إرسال 40 طلبًا في الثانية. وإذا ارتفعت مدة الطلب إلى ثانيتين فلن ترسل بالتزامن نفسه سوى 10 طلبات في الثانية.
البروكسي البطيء يُبطئ عملك دون زيادة التزامن. لهذا السبب يكون التأخير في أغلب الأحيان أكثر حسمًا من حد التزامن.
أين يُطبَّق الحد؟
حد التزامن ليس في مكان واحد، بل في عدة نقاط من السلسلة في آن واحد:
فتحك 200 thread على جانبك لا ينفع بشيء إذا كان المزوّد يحدّك بـ 50؛ فالزائد ينتظر في الطابور أو يتلقى خطأ.
علامات تجاوز الحد
عند تجاوز حد التزامن لن تتلقى رسالة صريحة تقول "تم تجاوز الحد". والعلامات النموذجية هي:
تمييز حاسم: الخطأ 429 يأتي من الهدف، وإعادة ضبط الاتصال من البروكسي، أما EMFILE فمن جهازك أنت. وكل منها يتطلب حلًا مختلفًا.
طريقة إيجاد التزامن الصحيح
النهج التجريبي أكثر موثوقية من الحساب النظري. طبّق اختبار تحميل تدريجيًا:
ابدأ من قيمة منخفضة
أرسل 200 طلب بـ 5 اتصالات متزامنة. سجّل متوسط المدة ومعدل النجاح.
ضاعِف القيمة
تقدّم على النحو 10، 20، 40، 80… وكرّر القياس نفسه في كل خطوة.
اعثر على نقطة الانكسار
اللحظة التي يتوقف فيها الإنتاجية الإجمالية (طلب/ثانية) عن الزيادة ويبدأ متوسط المدة في الارتفاع تعني أنك قريب من الحد الحقيقي.
اعمل عند 70% منها
استخدم نحو 70% من نقطة الانكسار كقيمة إنتاج. هذا الهامش يوفر حماية ضد التقلبات خلال اليوم.
منحنى الإنتاجية يستوي بين 40 و80 بينما يقفز التأخير. وبعد هذه النقطة لا تضيف زيادة التزامن سوى زمن انتظار.
لماذا يُعد تجمّع الاتصالات (Keep-Alive) مهمًا؟
إجراء مصافحة TCP وTLS جديدة لكل طلب مكلف من حيث التأخير والتزامن معًا. وإعادة استخدام الاتصال (keep-alive) تعطي إنتاجية أعلى بكثير بالتزامن نفسه:
يجب ألا يتجاوز حجم تجمّع العميل التزامن الذي يسمح به المزوّد. فإن تجاوزه، تُنشأ اتصالات زائدة وتُغلق فورًا وتضيع تكلفة المصافحة هباءً.
العلاقة بين التزامن وعدد عناوين IP
زيادة التزامن تزيد أيضًا كثافة الطلبات الخارجة من عنوان IP نفسه. وإذا كان الموقع الهدف يطبّق حد سرعة لكل عنوان IP، فإن زيادة التزامن عبر عنوان IP واحد تؤدي مباشرةً إلى الحظر. والنهج الصحيح هو توسيع التزامن مع عدد عناوين IP جنبًا إلى جنب.
لا تتجاوز 1–2 اتصال متزامن لكل عنوان IP لكل هدف. فإذا أردت إرسال 60 طلبًا متزامنًا فأنت بحاجة إلى 30–60 عنوان IP خارجًا مختلفًا على الأقل. ولتحديد حجم التجمّع راجع مقالنا عن مجمع البروكسي راجع.
إدارة سرعة صديقة للهدف
موضوع لا يقل أهمية عن التزامن هو توزيع الطلبات على الزمن. فبدلًا من إرسال 40 طلبًا في الوقت نفسه، توزيعها بتأخيرات صغيرة يبدو أكثر طبيعية لدى الهدف ويمنع تراكم الطابور أيضًا.
- أضف jitter: الانتظار العشوائي بين 150 و350 ms بدلًا من 200 ms ثابتة يقلل الأثر الآلي.
- استخدم token bucket: سلة رموز تنتج N طلبًا في الثانية تمنع الاندفاعات المفاجئة.
- طبّق التراجع: عند تلقي 429 اخفض التزامن تدريجيًا، وارفعه ببطء عند عودة النجاح.
- احتفظ بطابور منفصل لكل هدف: حتى لا يؤثر تباطؤ موقع واحد في البقية.
الحدود النموذجية في أنواع البروكسي المختلفة
| النوع | التزامن المعتاد | العامل المُقيِّد |
|---|---|---|
| Datacenter | عالٍ — بالمئات | النطاق الترددي وحد سرعة الهدف |
| ISP | متوسط إلى عالٍ | تسامح الهدف لكل عنوان IP |
| Residential | متوسط — حسب الخطة | حصة حساب المزوّد |
| Mobile | منخفض | جهاز واحد واتصال المشغّل |
بما أن بروكسيات الهاتف المحمول تخرج عبر مودم فيزيائي واحد، فهي بطبيعتها توفر تزامنًا منخفضًا؛ وفي المقابل تتمتع بأعلى درجة ثقة. وللتفاصيل مقالنا عن البروكسي المحمول يمكنك الاطّلاع.
الخلاصة
التزامن ليس محددًا للسرعة وحده؛ بل هو محدد لها بالاشتراك مع التأخير. وطريق إيجاد القيمة الصحيحة يمر عبر اختبار تحميل تجريبي: اعثر على النقطة التي تستوي عندها الإنتاجية ويقفز فيها التأخير، واعمل عند 70% منها. ثبّت تجمّع الاتصالات عند هذه القيمة، ووسّع التزامن جنبًا إلى جنب مع عدد عناوين IP، وتراجع عند ورود 429. ولقياس تأخير بروكسياتك الحالية اختبار ping و فحص البروكسي يمكنك استخدام أدواتنا.