فهم اتصال WebSocket للحصول على دقة

المقدمة

يصف هذا المستند اتصال WebSocket بالكامل بحيث يتم فهم العمليات الأساسية بشكل كامل أثناء أستكشاف الأخطاء وإصلاحها.

المتطلبات الأساسية

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

المكونات إستخدمنا

تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:

• Cisco Finesse 
• UCCX 

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

معلومات أساسية

يعد Web Socket بمثابة اتصال دائم بين العميل والخادم.

مقبس ويب

ما المقصود بمصطلح الاتصال الدائم؟

وهذا يعني أنه بمجرد تأسيس الاتصال بين العميل والخادم، يمكن للعميل والخادم إرسال البيانات و/أو استقبالها في أي وقت.

هذا اتصال ثنائي الإتجاه مزدوج كامل.

لا يتعين على الخادم انتظار طلب العميل لإرجاع أية بيانات.

وبالمثل، لا يتعين على العميل أيضا إنشاء اتصال جديد في كل مرة لإرسال أي بيانات جديدة إلى الخادم.

يتم إستخدام اتصال مأخذ التوصيل على الويب بشكل رئيسي في التطبيقات التي تتطلب تحديثات بيانات في الوقت الفعلي.

على سبيل المثال، تطبيقات تداول الأسهم، تطبيقات المراسلات، وفي حالتنا، Cisco Finesse.

كيف تعمل مقابس الويب؟

تأملوا:

HTTP

1. يتم إجراء اتصال TCP (مصافحة ثلاثية الإتجاه).
2. ثم يرسل العميل طلب HTTP.
3. يرسل الخادم إستجابة HTTP.
4. بعد دورة إستجابة طلب واحدة، يتم إغلاق اتصال TCP.
5. لطلب HTTP جديد، مرة أخرى، يتم إنشاء اتصال TCP أولا.

HTTP 1.0 - بعد كل إستجابة طلب، تبدأ مصافحة TCP مرة أخرى لاستجابة طلب HTTP أخرى.

HTTP 1.1 - عمل هذا الاتصال لأنه يمكنك إرسال البيانات واستقبالها ثم إغلاق الاتصال.

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

مشكلة في HTTP

تبدأ المشكلة بالأنظمة الآنية.

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

لحل هذه المشكلة، يتم إستخدام آلية من HTTP تسمى اقتراع.

إستفتاء قصير - يتم تنفيذ العملية عند تعيين مؤقت ثابت قصير للطلبات والاستجابات. على سبيل المثال، 05 ثانية أو ثانية واحدة حسب التطبيق.

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

إستفتاء طويل - يتجاوز التصويت القصير إلى حد ما، ولكن لا يزال لديه وقت ثابت لانتظار الرد.

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

ولذلك، فإن التصويت ليس أفضل طريقة للتغلب على هذه المشكلة.

ولهذا السبب، تسمى الطريقة الأخرى المستخدمة SSE.

SSE

قام الخادم بإرسال الأحداث

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

ما يجب ملاحظته هنا هو أنه اتصال أحادي الإتجاه مما يعني أن الخادم فقط يمكنه إرسال البيانات إلى العميل وليس العكس.

مثال على حالة إستخدام هو: الإعلامات أو التحديثات المجمعة من خادم إلى عميل. على سبيل المثال، News Live Updates و Instagram Live وما إلى ذلك.

وهذا غير فعال للغاية في التطبيقات التي تتضمن تحديثات في الوقت الفعلي والمراسلة.

يعد اتصال مأخذ التوصيل للويب اتصالا ثنائي الإتجاه كاملا وثنائي الإتجاه.

قد تكون هذه مكالمة هاتفية بين خادم وعميل حيث يمكن لأي طرف التحدث مع الطرف الآخر في أي وقت.

إجراءات WebSocket

1. لإنشاء اتصال WebSocket، يرسل العميل طلب مصافحة HTTP برأس تمت ترقيته أو تحديثه.
   1. هذا يعني أن العميل يقول للخادم أن هذا الآن فوق HTTP ولكنه من الآن فصاعدا ينتقل إلى اتصال WebSocket.
2. ومن ثم يستجيب الخادم مع إستجابة HTTP 101، مما يعني أن SIT تقوم بتدقيق إستجابة البروتوكول.
3. بعد ذلك، يتم تأسيس اتصال WebSocket.

والآن يمكن للخادم والعميل إستخدام نفس الاتصال لنقل البيانات إلى بعضهما البعض في أي وقت.

تصحيح أخطاء WebSocket

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

الطريقة - GET
المجال - اسم الخادم

الملف - /ws/

البادئ - OpenFire.js - WebSocket

فحص الطلب والرد:

طلب

إحضار

النظام: WSS

المضيف: uccxpub.prabhat.com:8445

اسم الملف : /ws/

العنوان: IP لخادم UCCX

الحالة: 101

تبديل البروتوكولات

VersionHTTP/1.1

رأس الاستجابة

الاتصال: ترقية

الترقية: WebSocket

          

Request – open Response PLAIN http://jabber.org/protocol/caps" hash="sha-1" node=" https://www.igniterealtime.org/projects/openfire/" ver="k3mOuil8afx3OTZxYy6yxLmFsok="/> Request - auth YWRtaW5pc3RyYXRvckB1Y2N4cHViLnByYWJoYXQuY29tAGFkbWluaXN0cmF0b3IAMTIzNA== Response Request – XMPP Bind Bind request to Bind the resource which in this case is desktop with a jabber id desktop Response – XMPP Bind where User ID is given a jabber id administrator@uccxpub.prabhat.com/desktop administrator@uccxpub.prabhat.com/desktop Presence request Presence response http://jabber.org/protocol/caps" hash="sha-1" node=" http://www.igniterealtime.org/projects/smack" ver="NfJ3flI83zSdUDzCEICtbypursw="> http://jabber.org/protocol/caps" hash="sha-1" node=" http://www.igniterealtime.org/projects/smack" ver="NfJ3flI83zSdUDzCEICtbypursw="> PUBSUB request – Requesting to subscribe the user to the pubsub node so that all the events on the user are monitored. Response – user subscribed. http://jabber.org/protocol/pubsub"> PUBSUB request – Requesting to subscribe the Team to the pubsub node so that all the events on the team are monitored. Response – Team subscribed http://jabber.org/protocol/pubsub">

معلومات ذات صلة

• الدعم الفني والتنزيلات من Cisco