لماذا تسبب الاتصالات القصيرة تحميلًا زائدًا على خادم ذاتي الاستضافة مشغول؟

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

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

السبب الأساسي: كل اتصال جديد يكرر العمل الثابت

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

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

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

ميزة Keep-Alive تقلل المصافحات لكنها تحتاج إلى حدود معقولة

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

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

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

يمكن للاتصالات المغلقة أن تترك حالة في النواة

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

لذلك، تشير عدد كبير من إدخالات TIME_WAIT إلى دوران اتصال متكرر بدلاً من خادم مكسور تلقائيًا. عند معدلات عالية، يمكن أن يستهلك الذاكرة، يعقد الرصد، أو يستنفد منافذ العميل المؤقتة قبل انتهاء صلاحية الإدخالات القديمة.

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

يمكن للأتمتة أن تخلق تذبذبًا في الاتصالات على خادم يبدو خاملاً

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

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

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

الأسئلة المتكررة

هل تعد العديد من الاتصالات القصيرة دائمًا مشكلة؟

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

هل يقضي HTTP/2 على التحميل الزائد للاتصالات؟

يمكن لـ HTTP/2 تعدد طلبات كثيرة عبر اتصالات أقل، مما يقلل التذبذب. يجب على العملاء والوكالات والخدمات العليا التفاوض فعليًا وإعادة استخدامه؛ قد تستخدم القفزات الداخلية اتصالات HTTP/1.1 منفصلة.

هل يجب أن أخفض مهلة TIME_WAIT؟

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