هل واجهت من قبل أن اتصال الـ WebSocket أو الـ Server-Sent Events (SSE) الخاص بك ينقطع فجأة كل دقيقة، ويظهر لك في المتصفح رمز الخطأ 1006؟ لا تقلق، لست وحدك، وهذا يعني غالبًا أن هناك «مراقب صامت» في شبكتك. بالنسبة للمطورين، هذا الانقطاع المتكرر مزعج ويسبب تجربة سيئة للمستخدم، لكن الأهم هو معرفة السبب الحقيقي والحل. هذه المشكلة ليست عيبًا في كودك الخاص بالرسائل، بل هي مشكلة في إعدادات الشبكة.

عندما يفصل اتصالك كل 60 ثانية (أو 55، أو 30 ثانية)، وبدون سبب واضح من السيرفر أو المتصفح، فهذا غالبًا بسبب ما يُسمى «مهلة الخمول» (idle timeout) في جهاز وسيط بين العميل والسيرفر. هذا الجهاز، والذي قد يكون بروكسي أو موازن حمل (load balancer)، يقطع اتصال TCP عندما لا تتدفق بيانات تطبيقية لفترة معينة. رمز 1006 يشير إلى إغلاق غير طبيعي للاتصال، وهذا بالضبط ما يفعله هذا الجهاز الوسيط: ينهي الاتصال من الطرفين دون إخبار السيرفر أو المتصفح. الأمر المحير هو أن هذا قد يعمل بشكل مثالي في بيئة التطوير المحلية، لأنك لا تملك هذه الأجهزة الوسيطة.

قد تتساءل عن «نبضات TCP» (TCP keepalives)، وللأسف، هذه لا تساعد هنا لأن البروكسي أو الموازن ينهي اتصال TCP من كلا الجانبين. هو لا يرى نبضات TCP، بل يهتم فقط ببيانات التطبيق. الحل ليس بزيادة مهلة الانقطاع، بل بإرسال ما نسميه «نبضات قلب» (heartbeats) من السيرفر. هذه النبضات هي عبارة عن بيانات صغيرة تُرسل بانتظام وبفترة أقصر من مهلة الخمول لدى أضيق جهاز وسيط في مسار الشبكة. هذا يضمن أن هناك دائمًا بيانات تتدفق، ويمنع أي بروكسي من قطع الاتصال بحجة الخمول. يجب أن يكون العميل أيضًا جاهزًا لإعادة الاتصال بهدوء إذا حدث أي انقطاع. لذا، في المرة القادمة التي ترى فيها رمز 1006 بانتظام، تذكر أنه ليس خطأ في تطبيقك، بل هو مؤقت في مسار الشبكة يحتاج إلى «نبضة قلب» ليبتسم لك مرة أخرى!