تمنحك WebSocket قناة ثابتة وذات اتجاهين بين العميل والخادم عبر اتصال TCP واحد. بمجرد فتح الاتصال، يمكن لأي من الطرفين إرسال رسالة في أي وقت، وهذا ما يجعلها العمود الفقري للمحادثات المباشرة، وتغذيات التداول، والألعاب متعددة اللاعبين، ولوحات المعلومات. يعد اختبارها تمرينًا مختلفًا عن اختبار واجهة برمجة تطبيقات (API) التي تعتمد على الطلب والاستجابة، لأنه لا توجد استجابة واحدة يمكن فحصها. هناك دفق.
هذا الدليل عملي. يغطي ما يمكن وما لا يمكن لـ curl فعله مع WebSocket، وكيفية استخدام الأداة المخصصة websocat، ومتى يكون عميل واجهة المستخدم الرسومية (GUI) هو الخيار الأفضل. كل أمر هنا حقيقي وجاهز للنسخ.
لماذا يختلف اختبار WebSocket عن اختبار REST
اختبار REST هو معاملة. ترسل طلبًا واحدًا، تحصل على استجابة واحدة، تتحقق منها، وتكون قد انتهيت. اختبار WebSocket هو محادثة. تفتح اتصالًا مرة واحدة، ثم تتبادل العديد من الرسائل على مدار عمره، ويمكن أن تصل الرسائل دون طلب منك.
هذا يغير ما تتحقق منه. أنت تؤكد أن الاتصال يتم ترقيته بشكل صحيح من HTTP. وتؤكد أن الخادم يقبل رسالتك الأولى ويرد كما هو متوقع. وتؤكد أن الرسائل التي يدفعها الخادم تصل دون أن تطلبها. وتراقب كيف يغلق الاتصال، ومع أي رمز إغلاق. الأداة المصممة للطلبات الفردية تواجه صعوبة في كل هذا، ولهذا السبب فإن curl، أداة HTTP الشاملة، مناسبة جزئيًا فقط. للحصول على صورة اختبار أوسع، يربط الاختلاف بين سيناريو الاختبار وحالة الاختبار بدقة بمحادثة WebSocket مقابل فحص رسالة واحدة.
مصافحة WebSocket
يبدأ كل اتصال WebSocket كطلب HTTP يطلب الترقية. يرسل العميل رؤوس Upgrade: websocket و Connection: Upgrade بالإضافة إلى Sec-WebSocket-Key، ويرد الخادم بـ HTTP 101 Switching Protocols. بعد ذلك، لم يعد الاتصال HTTP. بل يتحدث بروتوكول إطارات WebSocket المحدد في RFC 6455.
هذا هو أساس قيود curl. يتحدث curl الكلاسيكي بروتوكول HTTP. يمكنه إرسال رؤوس الترقية، لكنه لا يستطيع تأطير وإلغاء تأطير رسائل WebSocket بعد المصافحة. محاولة تزييف جلسة WebSocket كاملة باستخدام علامات الرأس الخام لا تعمل بعد المصافحة نفسها. أنت بحاجة إلى أداة تفهم الإطارات.
اختبار WebSocket باستخدام curl
أضاف curl الحديث، الإصدار 7.86 وما بعده، دعمًا تجريبيًا أصليًا لـ WebSocket. إنه قابل للاستخدام بشكل حقيقي للفحوصات البسيطة، مع التحفظ على أنه لا يزال مصنفًا كتجريبي.
أولاً تأكد من إصدارك:
curl --version
إذا كنت تستخدم الإصدار 7.86 أو أحدث، يمكنك الاتصال بنقطة نهاية WebSocket مباشرة. إليك اتصال بخادم صدى عام، والذي يرد بما ترسله:
curl --include --no-buffer \
--header "Connection: Upgrade" \
--header "Upgrade: websocket" \
--header "Sec-WebSocket-Version: 13" \
--header "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
https://echo.websocket.org
تُظهر العلامة --include رؤوس الاستجابة حتى تتمكن من تأكيد الحالة 101، وتمنع --no-buffer curl من حجب الإخراج، وهو أمر مهم للتدفق. للاتصالات الآمنة، استخدم عنوان URL wss:// تمامًا كما تفعل مع https://.
يتألق دعم curl لـ WebSocket لشيء واحد: تأكيد أن نقطة النهاية يمكن الوصول إليها وتكمل الترقية. إنه غير مناسب لجلسة تفاعلية ترسل فيها عدة رسائل وتقرأ الردود، لأن curl ليس مبنيًا حول حلقة رسائل. لإجراء فحص سريع "هل نقطة النهاية هذه نشطة" في برنامج نصي، لا بأس به. للاختبار التفاعلي الحقيقي، ابحث عن أداة مخصصة. إذا كنت تقوم ببرمجة هذه الفحوصات في مسار عمل، فإن دليلنا حول أتمتة اختبارات API في CI/CD يغطي توصيل فحوصات سطر الأوامر في عملية بناء.
اختبار WebSocket باستخدام websocat
websocat هي أداة سطر الأوامر التي يرغب فيها معظم الناس بالفعل لأعمال WebSocket. إنها مصممة خصيصًا، وتفهم الإطارات بشكل صحيح، وتتصرف مثل netcat لـ WebSocket.
قم بتثبيتها باستخدام مدير الحزم الخاص بك، على سبيل المثال brew install websocat على macOS أو عبر cargo install websocat. ثم الاتصال والدردشة يتمان بأمر واحد:
websocat wss://echo.websocket.org
هذا يفتح جلسة تفاعلية. اكتب سطرًا، اضغط Enter، ويتم إرساله كرسالة. تطبع ردود الخادم فور وصولها. لإرسال رسالة واحدة والخروج، قم بتمريرها عبر الأنابيب (pipe):
echo '{"action":"subscribe","channel":"prices"}' | websocat wss://stream.example.com/feed
يتعامل websocat أيضًا مع إضافات مفيدة. يمكنك تمرير رؤوس لنقاط النهاية التي تتطلب المصادقة:
websocat --header "Authorization: Bearer your-token-here" wss://api.example.com/socket
ويمكنك تشغيله كخادم محلي لاختبار عميل، أو ربط WebSocket بمنفذ TCP عادي. لاختبار WebSocket عبر سطر الأوامر، يغطي websocat تقريبًا كل ما لا يستطيع curl فعله. تعامل مع التأكيدات بنفس الطريقة التي تتعامل بها في أي مكان آخر؛ تنطبق ملاحظاتنا حول كتابة تأكيدات API مفيدة على فحص حمولات الرسائل أيضًا.
اختبار WebSocket باستخدام أداة واجهة المستخدم الرسومية (GUI)
تُعد أدوات سطر الأوامر رائعة للبرامج النصية والفحوصات السريعة. لكنها مرهقة للاختبار الاستكشافي، حيث ترغب في رؤية المخطط الزمني للرسائل، وإرسال JSON منظم بسهولة، والحفاظ على الاتصال مفتوحًا أثناء التعامل معه.
يحتوي Apidog على عميل WebSocket مخصص مصمم لهذا الغرض. تقوم بإدخال عنوان URL ws:// أو wss://، ثم تتصل، وترى كل رسالة مرسلة ومستلمة في عرض زمني مع تمييز بناء جملة JSON. يمكنك حفظ الاتصالات، وتعيين الرؤوس ومعلمات الاستعلام للمصادقة، والحفاظ على الاتصال نشطًا أثناء التجريب. يتعامل مع REST و GraphQL و SOAP في نفس التطبيق، لذا يجلس اختبار WebSocket جنبًا إلى جنب مع بقية عملك على API بدلاً من استخدام أداة منفصلة. قم بتنزيل Apidog لاختبار نقاط نهاية WebSocket بمخطط زمني مرئي.
تعتبر واجهة المستخدم الرسومية (GUI) هي الخيار الصحيح عندما تستكشف واجهة برمجة تطبيقات WebSocket غير مألوفة، أو تصحح أخطاء عدم وصول الرسائل، أو تشارك اختبارًا قابلًا للتكرار مع زميل. سطر الأوامر هو الخيار الصحيح عندما تريد تشغيل الفحص دون مراقبة. يستخدم معظم المهندسين كلا الأسلوبين، ويختارون بناءً على المهمة. إذا كنت ترغب في رؤية أوسع لخيارات واجهة المستخدم الرسومية، فإن قائمتنا التي تجمع أدوات اختبار API المجانية عبر الإنترنت تتضمن عدة أدوات تتعامل مع WebSocket.
قائمة فحص بسيطة لاختبار WebSocket
- تأكيد الترقية. يجب أن يعيد الاتصال HTTP 101. إذا لم يحدث ذلك، فإن نقطة النهاية، المسار، أو رؤوسك خاطئة.
- التحقق من المصادقة. تتوقع العديد من خوادم WebSocket وجود رمز مميز (token) في رأس أو معلمة استعلام. الاتصال الذي يفتح ثم يغلق فورًا غالبًا ما يعني رفض الرمز المميز.
- إرسال رسالة معروفة والتحقق من الرد. استخدم حمولة حقيقية تفهمها واجهة برمجة التطبيقات الخاصة بك وتأكد من شكل الاستجابة.
- التحقق من الرسائل المدفوعة من الخادم. اشترك في قناة وتأكد من وصول التحديثات دون طلبات أخرى منك.
- اختبار الإغلاق. أغلق الاتصال وتحقق من رمز الإغلاق. الإغلاق النظيف هو 1000؛ وتشير الرموز الأخرى إلى مشاكل محددة.
- اختبار مسارات الفشل. أرسل رسالة سيئة التكوين وتأكد من أن الخادم يستجيب بشكل معقول بدلاً من الإسقاط بصمت.
لتنظيم هذه في مجموعة قابلة للتكرار، ينطبق دليلنا حول بناء مجموعات اختبار API على تدفقات WebSocket بنفس القدر الذي ينطبق به على REST.
تصحيح أخطاء اتصال WebSocket الذي لا يعمل
عندما يفشل اتصال WebSocket، يكون السبب دائمًا تقريبًا واحدًا من مجموعة صغيرة من المشاكل. تعامل معها بالترتيب.
ابدأ بمخطط عنوان URL. يفشل الاتصال بـ wss:// من صفحة أو سياق يتوقع ws://، أو العكس، فورًا. تحظر المتصفحات أيضًا اتصال ws:// من صفحة مقدمة عبر HTTPS، لأن ذلك يخلط بين المحتوى الآمن وغير الآمن. تأكد من أن المخطط يطابق البيئة.
بعد ذلك، تحقق من استجابة المصافحة. إذا لم ترَ HTTP 101، فإن الخادم لم يوافق أبدًا على الترقية. يشير 404 إلى أن المسار خاطئ. يشير 401 أو 403 إلى فشل المصادقة قبل الترقية. غالبًا ما يشير 400 إلى رأس ترقية مفقود أو سيئ التكوين. تُظهر لك علامة --include في curl والوضع المطول في websocat هذه الاستجابة، حتى تتمكن من تمييز فشل المصافحة عن مشكلة لاحقة.
إذا نجحت المصافحة ولكن الاتصال انقطع بعد ثوانٍ، فابحث في مهلات الخمول وإطارات ping أو pong. تتوقع العديد من الخوادم أن يجيب العميل على إطارات ping لإثبات أنه لا يزال نشطًا، وتغلق الاتصالات التي تصبح صامتة. يمكن لوكيل (proxy) أو موازن تحميل (load balancer) أمام الخادم أن ينهي الاتصالات الخاملة وفقًا لجدوله الخاص. أخيرًا، اقرأ رمز الإغلاق. تم تعريف الرموز في RFC 6455، ويشير رمز مثل 1006 إلى إغلاق غير طبيعي بدون مصافحة نظيفة، بينما يشير 1011 إلى خطأ في الخادم. يخبرك رمز الإغلاق عادةً أي جانب استسلم ولماذا.
أتمتة فحوصات WebSocket
يؤكد الاختبار اليدوي لمرة واحدة أن نقطة النهاية تعمل اليوم. لكنه لا يحميك من تراجع في الأسبوع المقبل. لذلك، يجب أن يتم تشغيل فحص WebSocket تلقائيًا.
تُسهّل أدوات سطر الأوامر هذا الأمر. يمكن لبرنامج نصي صغير أن يفتح اتصالاً باستخدام websocat، يرسل رسالة معروفة، يلتقط الرد، ويقارنه بقيمة متوقعة، ثم يخرج بقيمة غير صفرية إذا لم تتطابق. يدخل هذا البرنامج النصي إلى مسار عمل التكامل المستمر (CI pipeline) كأي خطوة اختبار أخرى. يمكن لأداة واجهة المستخدم الرسومية (GUI) المزودة بمشغل سيناريو، مثل Apidog، حفظ تدفق WebSocket، بما في ذلك الرسائل المرسلة والتأكيدات على الردود، وإعادة تشغيلها في جدول زمني أو من خلال مشغل مسار عمل.
حافظ على تركيز اختبارات WebSocket المؤتمتة. تأكد من ترقية الاتصال، وتأكد من زوج واحد معروف من الطلب والاستجابة، وتأكد من أن القناة المشترك بها تسلم رسالة واحدة على الأقل في غضون مهلة زمنية. محاولة التأكد من كل رسالة ممكنة في اتصال طويل الأمد يجعل الاختبار بطيئًا وغير مستقر. نفس ضبط النفس الذي يحافظ على حالة الاختبار دقيقة يحافظ على موثوقية فحص WebSocket: اختبر شيئًا واحدًا واضحًا، واختبره جيدًا.
الأسئلة الشائعة
هل يمكن لـ curl اختبار اتصالات WebSocket؟
جزئيًا. يدعم curl الإصدار 7.86 وما بعده دعمًا أصليًا تجريبيًا لـ WebSocket يمكنه إكمال المصافحة وتبادل الرسائل الأساسية، وهو ما يكفي لتأكيد إمكانية الوصول إلى نقطة النهاية. إنه غير مناسب للجلسات التفاعلية التي تحتوي على العديد من الرسائل. لاختبار WebSocket الحقيقي، يُعد websocat أو عميل واجهة المستخدم الرسومية مثل Apidog خيارًا أفضل.
ما الفرق بين ws و wss؟
ws:// هو اتصال WebSocket غير مشفر، و wss:// مشفر باستخدام TLS، وهو ما يعادل WebSocket لـ HTTP مقابل HTTPS. استخدم دائمًا wss:// لأي شيء يتجاوز التطوير المحلي، نظرًا لأن ws:// يرسل الرسائل بنص عادي. تتعامل الأدوات مع عنواني URL بشكل متطابق بغض النظر عن التشفير.
لماذا يفتح اتصال WebSocket الخاص بي ثم يغلق فورًا؟
السبب الأكثر شيوعًا هو المصادقة. إذا كان الخادم يتوقع رمزًا مميزًا (token) في رأس أو معلمة استعلام ولم يحصل على رمز صالح، فإنه يقبل اتصال TCP ثم يغلقه. تحقق من رمز الإغلاق، وتحقق من الرمز المميز الخاص بك، وتأكد من أنك ترسله بالطريقة التي يتوقعها الخادم.
هل websocat أفضل من curl لاختبار WebSocket؟
بالنسبة لـ WebSocket على وجه التحديد، نعم. websocat مصمم خصيصًا، ويفهم بروتوكول الإطارات بالكامل، ويدعم الجلسات التفاعلية، والرؤوس المخصصة، وتمرير الرسائل إلى الداخل والخارج. curl هي أداة HTTP عامة لا يزال دعمها لـ WebSocket تجريبيًا. استخدم curl لفحص سريع لإمكانية الوصول و websocat للاختبار الفعلي.
كيف أختبر أن الخادم يدفع الرسائل دون طلب؟
افتح الاتصال، اشترك في القناة أو الحدث ذي الصلة إذا كانت واجهة برمجة التطبيقات تتطلب ذلك، ثم انتظر وراقب. باستخدام websocat، تُطبع الرسائل المدفوعة فور وصولها. باستخدام عميل واجهة المستخدم الرسومية مثل Apidog، تظهر في المخطط الزمني للرسائل. تأكد من وصول الرسائل دون أي إدخال إضافي منك، لأن التسليم غير المطلوب هو جوهر WebSocket.