الاتصالات المتزامنة

ما الاتصال وكيف يعمل؟

اتصال الشبكة رابط تواصل ينشئه برنامجان لتبادل البيانات. مثلًا، يتصل متصفح بخادم ويب لطلب صفحة وتلقي محتواها. ويوفر الاتصال مسار ذلك التبادل، بينما الطلب والاستجابة رسالتان ترسلان عبره.

لننظر إلى اتصال TCP تقليدي. يتصل التطبيق بعنوان IP للخادم ومنفذ الخدمة المطلوبة. ويتبادل الطرفان رسائل تحكم لإنشاء الاتصال. ثم تنتقل البيانات في وحدات صغيرة تسمى حزمًا. ويتتبع TCP التسليم وينظم إعادة إرسال البيانات المفقودة ويقدمها للمستقبل بالترتيب الصحيح. ويحتفظ الطرفان بمعلومات عن التبادل ما دام الاتصال قائمًا.

مع وكيل TCP تقليدي، يتصل التطبيق أولًا بخادم الوكيل. وينشئ الوكيل اتصالًا منفصلًا بالموقع الوجهة ويمرر البيانات بين الاتصالين في الاتجاهين. لذلك يحافظ على التواصل مع برنامج العميل والوجهة معًا.

يمكن للتطبيق إرسال طلب وتلقي استجابة واستخدام الاتصال المنشأ لتبادل آخر. فتلقي صفحة مثلًا لا يغلق الاتصال بالضرورة؛ قد يحتفظ به المتصفح لطلبات لاحقة إلى الخادم. وعند انتفاء الحاجة، يغلقه أحد الطرفين، وقد ينهيه أيضًا خطأ أو انقضاء مهلة. وحتى إغلاقه، يمكن أن يظل الاتصال قائمًا دون نقل بيانات مستمر.

يمكن لبرنامج الاحتفاظ بعدة اتصالات كهذه في الوقت نفسه: يتلقى بيانات على أحدها وينتظر ردًا على آخر ويبقي ثالثًا جاهزًا لطلب لاحق. وهذه اتصالات متزامنة. ويصف العدد قنوات التواصل المفتوحة في تلك اللحظة، لا إجمالي الطلبات منذ بدء البرنامج.

ما الذي يقيسه الحد؟

يشغل الاتصال المفتوح موضعًا في الحصة المعنية. وبعد إغلاقه وإزالته من عداد الخدمة، يصبح الموضع متاحًا مجددًا. وهذا حد للنشاط الحالي، فلا يستهلك بلوغه رصيد اتصالات شهريًا.

كيفية احتساب الاتصالات ضمن حصة العميل قاعدة مستقلة للخدمة. ووجود جزأين شبكيين عند الوكيل لا يستهلك تلقائيًا وحدتين من الحصة.

يضع المزودون هذه الحدود لأن الاتصالات المفتوحة تستهلك موارد الخادم حتى عند نقل بيانات قليلة. والاتصال الذي ينتظر ردًا يحتاج أيضًا إلى موارد لإبقائه قائمًا. ويساعد ضبط العدد الخدمة على الاحتفاظ بسعة كافية لأعباء العمل التي وافقت على دعمها.

يمكن أن تنطبق عدة حدود مختلفة على الخدمة نفسها:

لذلك لا تبين البيانات غير محدودة الحجم شيئًا عن عدد الاتصالات المتزامنة. وقد يوجد أيضًا حد مستقل لسرعة فتح اتصالات جديدة. وقد يبلغ فتحها وإغلاقها بسرعة ذلك الحد حتى مع بقاء القليل منها مفتوحًا في أي لحظة.

لماذا لا يساوي عدد خيوط التنفيذ عدد الاتصالات؟

يصف عدد خيوط التنفيذ أو عمليات العامل في التطبيق طريقة تنظيمه للمهام، ولا يحدد بموثوقية عدد الاتصالات التي سيحتسبها الوكيل. فقد تتصل مهمة واحدة بعدة خوادم، ويمكن لبرنامج نصي غير متزامن إدارة عمليات شبكية كثيرة دون إنشاء خيط نظام تشغيل مستقل لكل واحدة.

كما لا يحتاج كل طلب HTTP إلى اتصال جديد. يمكن لبرنامج العميل إعادة استخدام اتصال موجود، ويمكن لبروتوكول HTTP/2 حمل عدة طلبات في الوقت نفسه عبر اتصال واحد. لذلك يختلف عدد الطلبات عن عدد الاتصالات.

تهم مصطلحات المزود أيضًا. فقد يعني حد موصوف بأنه «خيوط» أو «جلسات» اتصالات مفتوحة أو طلبات قيد المعالجة. ولا تمثل الجلسة الثابتة التي تبقي IP الوكيل نفسه لطلبات مترابطة اتصال شبكة واحدًا بالضرورة. والتعريف المفيد هو ما تحتسبه الخدمة فعلًا.

أي البرامج تتشارك الحصة؟

قد يخص الحد حسابًا أو باقة مشتراة أو IP وكيل منفردًا أو بوابة معينة. ولحد الحساب أو الباقة، اجمع اتصالات كل البرامج والأجهزة التي تستخدم تلك الحصة. فتقسيم قائمة IP بين عدة حواسيب لا ينشئ حصة مستقلة لكل حاسوب.

في الحد لكل IP، يختلف التوزيع: فقد يبلغ عنوان مشغول سقفه بينما تبقى مساحة لآخر. وقد يفيد نقل بعض العمل إلى العنوان الثاني، بشرط ألا تفرض الخدمة أيضًا حدًا مشتركًا أدنى. وقد تتضمن الباقة حصة إجمالية وتخصيصات أصغر لمستخدمين أو عناوين IP للعميل منفردة.

عدد عناوين IP للعميل المسموح لها بالمصادقة إعداد آخر. فهو يتحكم في الشبكات التي تستطيع الوصول إلى الوكلاء، لا عدد الاتصالات التي يمكنها فتحها. وقد تتشارك عدة أجهزة خلف IP عام واحد قاعدة الوصول وتخصيص الاتصالات المرتبط به معًا.

تغيير IP الوكيل الذي يراه موقع لا يعيد ضبط حصة اتصالات الحساب بأكمله. وبالمثل، لا يوفر تغيير اسم الجلسة الثابتة أو البروتوكول سعة إضافية تلقائيًا. ويظل الحد مرتبطًا بالحساب أو الباقة أو نقطة الاتصال التي يستخدمها المزود للعد.

لماذا تتراكم الاتصالات؟

تتراكم الاتصالات عندما تُفتح الجديدة أسرع من إغلاق القائمة. وقد يحدث ذلك عند تحميل صفحات أو تنزيل ملفات أو تشغيل مهام شبكة أخرى بالتوازي: تظل بعض الاتصالات تنقل بيانات أو تنتظر ردًا بينما يفتح التطبيق أخرى. وتُحتسب هذه الاتصالات في الحصة معًا، وقد تستنفد حد اتصالات الوكيل.

تبقي الاستجابات البطيئة الاتصالات مشغولة مدة أطول. فإذا واصل برنامج بدء عمل جديد بالوتيرة نفسها، تراكم العمل غير المكتمل. وإذا أبقى النشاط المتوازي عند مستوى ثابت بدلًا من ذلك، فإن الموقع الأبطأ يعني عمومًا إنجاز مهام أقل في الدقيقة. ويمكن حدوث الحالتين دون تغيير باقة الوكيل.

قد تؤدي التنزيلات الطويلة والاتصالات المنتظرة لانقضاء المهلة إلى الأثر نفسه. لذلك قد يتزامن عدد كبير من الاتصالات المفتوحة مع سرعة نقل منخفضة، لأن معظم الوقت يُصرف في الانتظار بدل نقل البيانات.

تُبقى بعض الاتصالات مفتوحة عمدًا بين الطلبات، ويسمى ذلك عادة keep-alive. وهو يجنب إعداد اتصال جديد كل مرة، لكن الاتصال الخامل قد يظل يشغل موضعًا إذا كانت الخدمة تعد الاتصالات المفتوحة. والاتصال المعاد إلى مجموعة اتصالات التطبيق متاح لإعادة الاستخدام، ولم يُغلق بالضرورة عند الوكيل.

مشكلة أخرى مستقلة هي الخلل في تحرير الاتصالات. وقد يحدث في البرامج الجاهزة كما في البرامج النصية الخاصة. فمثلًا، قد تبدأ الشيفرة قراءة استجابة ثم تواجه خطأ وتبدأ طلبًا آخر دون إكمال الاستجابة السابقة أو إغلاقها. وإذا استمر فتح اتصالات جديدة مع بقاء القديمة مشغولة، فقد يستنفد التطبيق حصته دون إنجاز عمل مفيد أكثر. وهذا سبب لفحص التحرير بعد الأخطاء والإلغاءات، لا بعد الطلبات الناجحة فقط.

يتيح التحرير الصحيح لبرنامج العميل إعادة استخدام اتصال مناسب أو إغلاق ما لم يعد يحتاج إليه. وتمنع المهل العمليات المتروكة من الانتظار بلا نهاية. وتعطيل إعادة الاستخدام في كل مكان ليس حلًا عامًا، فهو يزيد عمل إعداد الاتصالات وقد يرفع معدل فتح الجديدة. والهدف عدد مضبوط من الاتصالات القابلة لإعادة الاستخدام، مع تحرير غير الضروري أو إغلاقه بصورة صحيحة.

لماذا يبدو أن الوكلاء يعملون ثم يتوقفون ثم يعملون مجددًا؟

الأعطال المتقطعة تحت الحمل سبب لفحص حد الاتصالات مبكرًا. تبدو بعض عناوين الوكلاء عاملة وأخرى فاشلة، ثم يتغير النمط بعد قليل. ومن منظور التطبيق، قد يبدو أن أجزاء مختلفة من قائمة الوكلاء تخرج من الخدمة باستمرار.

أحد التفسيرات امتلاء الحصة المشتركة. فقد تستمر الاتصالات الموجودة، بينما تُرفض محاولات فتح المزيد أو تُترك منتظرة. ومع إغلاق الاتصالات السابقة، تنجح بعض المحاولات الجديدة. وتفشل أخرى عند امتلاء المواضع المتاحة مجددًا. وينتج تغير النتيجة من التنافس على الحصة نفسها، لا مجموعة ثابتة من IP معطلة.

يوصف هذا السلوك أحيانًا بالتقييد، أو throttling. ويؤثر القيد هنا في قبول الاتصالات الجديدة، ولا يخفض بالضرورة سرعة كل اتصال قائم. وتعتمد الاستجابة الدقيقة على الخدمة، فقد تعيد رسالة حد واضحة أو ترفض الاتصال أو تترك برنامج العميل حتى تنقضي مهلته. ولا يُضمن وجود صف انتظار.

لفحص التفسير، قارن الأعطال بعدد الاتصالات وخفض النشاط المتوازي مؤقتًا عبر البرامج التي تتشارك الحصة. وإذا توقفت الأعطال تحت الحد وعادت عند امتلائه، فحد الاتصالات سبب مرجح. وقد تأتي انقطاعات مماثلة أيضًا من الموقع المستهدف أو الشبكة. ولا يثبت انقضاء مهلة أو استجابة HTTP 429 أو 502 أو 503 وحدها بلوغ حد اتصالات الوكيل؛ فمصدر الخطأ وصياغته مهمان.

كيف تبقي العمل المفيد ضمن الحد؟

ابدأ بالمواقع والعمليات الفعلية التي يحتاج برنامجك إلى تنفيذها. زد النشاط المتوازي تدريجيًا وراقب النتائج الناجحة وأزمنة الاستجابة وذروات الاتصالات. فقد لا يمثل اختبار قصير لصفحة سريعة تشغيلًا كاملًا يتضمن تسجيل دخول واستجابات كبيرة ونقاط اتصال أبطأ.

1. امنح كل البرامج ميزانية اتصالات مشتركة. اترك مساحة لنشاط آخر والزيادات القصيرة. وإذا استخدمت عدة عمليات الباقة نفسها، فإن ضبط كل عملية على حصة الباقة الكاملة قد يحمّل الخدمة فوق طاقتها عند تشغيلها معًا.
2. اضبط المهام والاتصالات معًا. تخزن مجموعة الاتصالات اتصالات لإعادة الاستخدام. وافحص هل إعداد حجمها حد صارم أم مجرد عدد يُحتفظ به لاحقًا، إذ تفتح بعض برامج العميل اتصالات إضافية ما لم يُفعّل وضع انتظار. واحرص على استمرار تحرير الاستجابات وتطبيق المهل، بما في ذلك عند فشل مهمة.
3. وزع التشغيل وإعادة المحاولات زمنيًا. بدء كل المتصفحات معًا أو تكرار كل طلب فاشل فورًا يولد ذروة أخرى. استخدم عددًا محدودًا من المحاولات مع فترات انتظار متزايدة، وأبقها ضمن ميزانية عبء العمل نفسها. كما أن انقضاء المهلة لا يثبت فشل إجراء أُرسل، لذلك يحتاج تكرار شراء أو تحديث إلى عناية.
4. قس العمل المكتمل. لا تفيد زيادة عمليات العامل إلا ما دامت تحسن معدل الإنجاز الناجح. وعندما تزيد أساسًا الانتظار والأخطاء، قد ينهي إعداد أقل المهمة نفسها أسرع. وإذا عرضت لوحة التحكم متوسط النشاط عبر الزمن، فقد تكون الذروات القصيرة أقل وضوحًا من طوابع وقت أخطاء التطبيق.

في مهام المتصفح، قد يقلل تجنب التنزيلات غير الضرورية نشاط الشبكة أيضًا. وقد يفيد حظر الصور أو الفيديو عندما لا تحتاجهما المهمة، بينما قد يؤدي حذف البرامج النصية إلى تعطل العملية نفسها. قيّم التغيير وفق استمرار إتمام المهمة المقصودة بصورة صحيحة.

متى يفيد حد أعلى؟

تفيد سعة اتصالات أكبر عندما يدير التطبيق اتصالاته بصورة صحيحة ويبلغ عبء العمل المطلوب سقف المزود باستمرار. وقد تتيح تشغيل مهام أكثر معًا دون التنافس على الحصة الصغيرة نفسها.

يجب أن ترفع عملية الشراء الحد الذي يجري بلوغه فعلًا. وقد تفيد إضافة IP مع قيد لكل IP عندما يتوزع العمل عليها. أما في حد باقة مشترك، فيجب أن ترفع الباقة الجديدة أو الإضافة تلك الحصة المشتركة. وزيادة عدد IP وحدها لا تثبت حدوث ذلك.

توجد سقوف أخرى أيضًا. فقد تكون مجموعة اتصالات برنامج العميل أصغر، أو تنفد موارد الشبكة في الحاسوب، أو تقيد الوجهة الطلبات. وللاتصال المحمول الواحد أيضًا عرض نطاق متاح خاص به، بغض النظر عن عدد اتصالات الوكيل المسموح بها. وشراء تزامن أكبر لا يزيل تلك القيود ولا يصلح برنامجًا نصيًا يواصل تسريب الاتصالات.

الهدف العملي مساحة كافية لذروات عبء العمل المعتادة مع إبقاء الأعطال قليلة. وبعد تحقيق ذلك، تصبح حصة اتصالات إضافية ترقية مفيدة للسعة، بدلًا من وسيلة لتأجيل إصلاح التطبيق.