WebSocket: ما هو، بروتوكول الاتصال ثنائي الاتجاه وكيف يعمل

ما هو WebSocket؟

WebSocket هو بروتوكول اتصال يعمل عبر TCP ويوفر قناة ثنائية الاتجاه بين العميل والخادم. تم توحيده من قبل IETF كـ RFC 6455 في عام 2011 وهو مدعوم من جميع المتصفحات الحديثة والمنصات المحمولة وأطر عمل الخادم.

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

يستخدم بروتوكول WebSocket منفذ HTTP 80 أو منفذ HTTPS 443 للمصافحة الأولية، وبعد ذلك يتحول إلى بروتوكوله الخاص مع رأس ضئيل — 2 بايت فقط بدلاً من 800+ بايت في HTTP. توفر هذه الميزة ميزة أداء كبيرة مع عدد كبير من الرسائل.

الخصائص الرئيسية للبروتوكول

يبدأ اتصال WebSocket بطلب ترقية HTTP (Upgrade)، وبعد ذلك يتحول البروتوكول إلى تنسيق إطار ثنائي. يتراوح حجم الإطار من 2 بايت إلى 2^63 بايت، مما يسمح بنقل كل من رسائل النص القصيرة والبيانات الثنائية الكبيرة. يدعم البروتوكول تجزئة الرسائل وإخفاء البيانات من العميل إلى الخادم وping/pong للحفاظ على الاتصال نشطاً.

كيف يعمل WebSocket؟

تتكون عملية إنشاء اتصال WebSocket من مرحلتين: المصافحة ونقل البيانات. خلال المصافحة، يرسل العميل طلب HTTP مع رأس Upgrade: websocket، ويؤكد الخادم تبديل البروتوكول بالحالة 101 Switching Protocols. بعد ذلك، يدخل الاتصال في وضع الإرسال ثنائي الاتجاه.

كل رسالة في WebSocket تنقسم إلى إطارات. يحتوي الإطار على opcode (نص، بيانات ثنائية، إغلاق، ping/pong) وطول الحمولة ومفتاح إخفاء للبيانات من العميل. يمكن تجزئة الإطارات — يمكن إرسال إطارات التحكم (ping/pong) بين أجزاء الرسالة، مما يمنع انتهاء مهلة الاتصال أثناء النقل الطويل.

const ws = new WebSocket('wss://example.com/chat')

ws.addEventListener('open', () => {
    console.log('تم إنشاء الاتصال')
    ws.send('مرحباً أيها الخادم!')
})

ws.addEventListener('message', (event) => {
    console.log('تم الاستلام:', event.data)
})

ws.addEventListener('close', () => {
    console.log('تم إغلاق الاتصال')
})

في المثال أعلاه، ينشئ العميل كائن WebSocket مع تحديد URL الآمن wss://. بعد فتح الاتصال، يتم إرسال رسالة ترحيب، ويتلقى معالج الرسالة الردود من الخادم. عند الإغلاق، يتم تفعيل معالج الإغلاق — وهذا مهم لإعادة الاتصال في حالة انقطاع الشبكة.

WebSocket مقابل HTTP: مقارنة

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

للتطبيقات التي تتطلب زمن وصول منخفض وتدفقاً مستمراً للبيانات، يكون WebSocket أكثر كفاءة بشكل ملحوظ. HTTP Long Polling — بديل حيث يحتفظ الخادم بالطلب مفتوحاً حتى تتوفر البيانات — يخلق حملاً زائداً على الخادم ويزيد استهلاك الذاكرة بسبب اتصالات متزامنة متعددة.

وفقاً لـ High Performance Browser Networking (Grigorik, O'Reilly)، يقلل WebSocket زمن وصول الشبكة في السيناريوهات في الوقت الفعلي بنسبة 40-60% مقارنة بـ HTTP Long Polling، بينما ينخفض حمل الخادم بمقدار 3-5 مرات بسبب التخلص من المصافحات المتكررة.

أين يُستخدم WebSocket؟

بفضل زمن الوصول المنخفض والاتصال ثنائي الاتجاه، يُستخدم WebSocket في مجموعة واسعة من التطبيقات. تشمل السيناريوهات الرئيسية المراسلة الفورية ومزامنة الحالة في الألعاب ونقل بيانات السوق في الأنظمة المالية.

الدردشات والمراسلة

أصبح WebSocket المعيار الفعلي لتطبيقات الدردشة. منصات مثل Slack وTelegram Web وWhatsApp Web تستخدم WebSocket لتسليم الرسائل الفوري. يسمح البروتوكول بإرسال كل من الرسائل النصية والملفات عبر قناة واحدة، بينما تحافظ آلية ping/pong على الاتصال نشطاً حتى خلال فترات الخمول.

الألعاب عبر الإنترنت

تتطلب ألعاب المتصفح والجوال متعددة اللاعبين زمن وصول ضئيل لمزامنة حالات اللاعبين. WebSocket ينقل الإحداثيات والإجراءات والأحداث في الوقت الفعلي دون تأخير طلبات HTTP. أطر العمل مثل Socket.IO وColyseus تجرد العمليات منخفضة المستوى للبروتوكول، مضيفة إعادة الاتصال التلقائي والغرف.

التطبيقات المالية

تستخدم منصات التداول وبرامج التداول WebSocket لتلقي الأسعار في الوقت الفعلي. تأخير بضع ميلي ثانية يمكن أن يكلف ملايين الدولارات، لذلك توفر API المالية — مثل Binance WebSocket Streams وCoinbase Pro — واجهات WebSocket لبيانات السوق.

التطبيقات المحمولة و IoT

في تطوير الأجهزة المحمولة، يُستخدم WebSocket عبر API أصلية: URLSessionWebSocketTask على iOS وOkHttp WebSocket على Android. لـ Flutter، توجد مكتبة web_socket_channel، ولـ React Native — react-native-websocket. أجهزة IoT تستخدم WebSocket لنقل القياسات عن بعد وتلقي أوامر التحكم، حيث يستهلك البروتوكول طاقة أقل من HTTP polling المستمر.

أمثلة كود WebSocket

لننظر إلى مثال من جانب الخادم باستخدام Node.js مع مكتبة ws — أكثر تطبيقات WebSocket شيوعاً لجافا سكريبت. يقبل الخادم الاتصالات ويعالج الرسائل ويبثها لجميع العملاء المتصلين.

const WebSocket = require('ws')
const wss = new WebSocket.Server({ port: 8080 })

wss.on('connection', (ws) => {
    console.log('عميل جديد متصل')

    ws.on('message', (data) => {
        console.log('تم الاستلام:', data.toString())
        ws.send('الخادم استلم رسالتك')
    })

    ws.on('close', () => {
        console.log('العميل غير متصل')
    })
})

console.log('خادم WebSocket بدأ على المنفذ 8080')

ينشئ الخادم مثيل WebSocket.Server على المنفذ 8080 وينتظر الاتصالات. يتم تعيين كائن ws منفصل لكل عميل جديد يمكن للخادم من خلاله إرسال رسائل فردية. يتم تنفيذ بث الرسائل لجميع العملاء عن طريق التكرار عبر مصفوفة الاتصالات. مع عدد كبير من العملاء (أكثر من 1000)، يُنصح باستخدام مكتبات تدعم العنقودية، مثل Socket.IO، التي تضيف توسعاً عبر Redis وإعادة اتصال تلقائي.

إرسال الرسائل لجميع العملاء

wss.clients.forEach((client) => {
    if (client.readyState === WebSocket.OPEN) {
        client.send('رسالة لجميع المشاركين')
    }
})

التحقق من readyState قبل الإرسال إلزامي: إذا كان العميل قد انقطع بالفعل، فإن استدعاء send سيؤدي إلى خطأ. يضمن علم WebSocket.OPEN أن الاتصال نشط وأن الرسالة سيتم تسليمها.

لتطبيقات iOS المحمولة، يتم تنفيذ WebSocket عبر URLSessionWebSocketTask، المتاح منذ iOS 13. تنشئ الجلسة مهمة بعنوان URL ببروتوكول wss://، وبعد ذلك يتم استدعاء طرق send وreceive. يمكن تنظيم استقبال الرسائل من خلال التكرار المستمر لـ receive، الذي ينتظر الرسالة التالية بعد معالجة السابقة، مما يضمن استقبالاً ثابتاً للبيانات دون إعادة اتصال. لـ Android، يُستخدم OkHttp WebSocket، الذي يوفر واجهة مماثلة مع استدعاءات onOpen وonMessage وonClosing وonClosed، بالإضافة إلى إعادة الاتصال التلقائي عند فقدان الاتصال.

عند العمل مع WebSocket في التطبيقات المحمولة، من المهم مراعاة إدارة دورة الحياة: عندما يدخل التطبيق إلى الخلفية، قد يقوم النظام بإنهاء الاتصال. على iOS، يجب إعادة إنشاء الاتصال عند العودة إلى المقدمة عبر مفوض sceneDidBecomeActive. على Android، يجب استخدام مكونات Lifecycle-aware أو Service للحفاظ على الاتصال. بالإضافة إلى ذلك، يُنصح بتطبيق التراجع الأسي لإعادة الاتصال — زيادة الفاصل الزمني بين المحاولات من 1 إلى 30 ثانية — لتجنب إنشاء حمل زائد على الخادم أثناء مشاكل الشبكة المؤقتة.