WebSocket
مراقبة WebSocket
مصافحة الترقية، والمقبس لا يزال مفتوحًا بعد لحظة، والرسالة الأولى.
جربه الآن
فحص واحد، من مكان واحد، الآن، ولا يتم حفظ أي شيء. المراقب يتحقق من كل موقع نعمل فيه ويؤكد الفشل من قارتين أخريين قبل أن يتم إيقاظ أي شخص، وهو ما لا يمكن أن يظهره نظرة واحدة.
ما الغرض منه
دردشتك، لوحة التحكم الحية، تغذية الأسعار، محررك التعاوني، غرفة الألعاب: كل ذلك هو WebSocket، وهو الجزء من المنتج الذي يفشل بينما تبقى كل الطبقات تحته خضراء. الصفحة يتم تحميلها، API يجيب، الشهادة جيدة، المنفذ مفتوح، والمقبس لا يفتح أبدًا.
أو يفتح ويغلق مرة أخرى بعد مئتي ميلي ثانية، وهو من جانب المستخدم شاشة تتوقف عن التحديث بهدوء ولا يبلغ أحد عنها كعطل. يقومون بالتحديث، يعمل لدقيقة، ثم يستسلمون. لذا فإن هذا لا يتوقف عند المصافحة: يراقب المقبس للحظة بعد ذلك، بنفس الطريقة التي يمكن أن يصر بها تحقق TCP على التحية بدلًا من الاكتفاء بمنفذ مفتوح.
والذي يخسر الناس المال بسببه فعليًا: التغذية التي تكون متصلة وتوقفت عن النشر. أعطنا رسالة لإرسالها ونمطًا يجب أن يتطابق الرد معه، أو مجرد نمط، والتغذية الصامتة هي فشل بدلًا من صف أخضر يبدو صحيًا.
مثل كل فحص هنا، يتم تشغيله من Amsterdam, New York, Sydney and Singapore، ويتم تأكيد الفشل من قارتين أخريين قبل أن يتم إيقاظ أي شخص. كيف يعمل ذلك.
ما يمكنك ضبطه
كل ما هو أدناه موجود في النموذج عند إضافة واحد، على كل خطة.
- العنوان
- عنوان ws:// أو wss://، مع المسار. المضيف والمنفذ هما تحقق TCP، وهو سؤال مختلف.
- أرسل هذا أولاً
- إطار نصي واحد، يتم إرساله بمجرد فتح المقبس، لنقطة نهاية تجيب بدلًا من النشر.
- الرسالة المتوقعة
- تعبير عادي يجب أن يتطابق معه الإطار. ملؤه هو ما يجعل الإطار مطلوبًا على الإطلاق.
- كم من الوقت تنتظر
- ثوانٍ. منفصلة عن مهلة الاتصال، لأن التغذية التي تنشر كل ثلاثين ثانية تكون صحية وستفشل في مهلة على شكل مصافحة.
- مهلة
- مدة المصافحة نفسها.
- التأكيدات
- كم عدد القارات الأخرى التي يجب أن توافق قبل أن يتم إيقاظ أي شخص.
الأسئلة
لماذا لا يمكنني فقط توجيه مراقب HTTPS إليه؟
لأن الإجابة السليمة ستُسجل كتعطل. يبدأ WebSocket كطلب HTTP GET يحمل Upgrade: websocket و Sec-WebSocket-Key، والخادم الذي يجيب على GET عادي برمز 400 أو 426 يتصرف كما يجب. مراقب HTTPS يرى رمز الحالة هذا ويبلغ أنك معطل بينما تعمل بشكل مثالي.
ما الذي يفعله التحقق فعليًا؟
يكمل مصافحة الترقية، مما يعني رمز 101 مع Sec-WebSocket-Accept مشتق من المفتاح الذي أرسله، ثم يحتفظ بالسوكيت للحظة ليرى ما إذا كان سيبقى مفتوحًا. ثم يغلق الاتصال. لا يحتفظ باتصال بين الفحوصات، لذا لا يبدو هذا كعميل لخادمك.
تغذيتي هادئة معظم الوقت. هل سيفشل ذلك؟
لا. السوكيت الذي يفتح ولا يقول شيئًا يعتبر سليمًا ما لم تملأ رسالة متوقعة، لأن التغذية التي ليس لديها شيء للنشر ليست تغذية معطلة. املأ ذلك وستتغير القواعد عمدًا: يصبح الإطار مطلوبًا داخل فترة الانتظار التي تحددها، وهو ما يتيح لك اكتشاف التغذية المتصلة والتي توقفت.
ما الفرق بين 1000 و 1011 في الإغلاق؟
1000 هو إغلاق طبيعي و 1011 هو الخادم يقول إنه واجه حالة لا يمكنه التعافي منها، وكلاهما يصل كسوكيت انتهى. رمز الإغلاق والسبب موجودان في الفشل، بدلاً من أن يتم تسطيحهما إلى منفصل، لأنهما يوجهان من يقوم بالإصلاح إلى مكانين مختلفين.
هل تدعم Socket.IO أو SignalR أو STOMP أو MQTT؟
لا، ونقول ذلك بدلاً من الإيحاء بخلاف ذلك. هذه هي طبقات مضافة فوق WebSocket، كل منها بمصافحتها الخاصة وفكرتها الخاصة عن مساحة الأسماء، وفحص يتحدث نصفها سيكون أسوأ من فحص لا يفعل ذلك. الفحص الخام لا يزال يخبرك أن النقل تحتها يعمل.
هل يتحقق من الشهادة على عنوان wss://؟
نعم. يتم التحقق من اتصال wss:// مقابل مخزن الثقة العام مثل أي اتصال آخر، لذا فإن الشهادة المنتهية الصلاحية أو الموقعة ذاتيًا أو عدم تطابق اسم المضيف يفشل الفحص. الأيام المتبقية هي سؤال مراقب الشهادة، وتستحق التشغيل بجانب هذا الفحص.
هل يمكنني التحقق من سوكيت على شبكتي الخاصة؟
لا، وهذا هو الرفض الذي نأسف عليه أقل شيء. WebSocket إلى عنوان داخلي هو نفق ثنائي الاتجاه طويل الأمد يتم فتحه بواسطة بنيتنا التحتية وفق جدول زمني، وهو نسخة أسوأ من تزوير طلب من جانب الخادم مقارنة بجلب لمرة واحدة. يتم حل العنوان مباشرة قبل الاتصال ويتم رفض العنوان الخاص.
عميل التطبيق يعيد الاتصال تلقائيًا. لماذا تراقب السوكيت أيضًا؟
يجب أن يفعل ذلك، والعميل بدون منطق إعادة المحاولة هو المشكلة الأكبر بين الاثنين، لذا فإن هذا العمل ليس مهدورًا. يعني ذلك أن عميلك يخفي الشيء الذي يستحق المعرفة. السوكيت الذي يقبل الاتصال، يحتفظ به لمدة ثلاثين ثانية ثم يسقطه سيجعل العميل الذي يعيد الاتصال يبدو متصلًا تقريبًا لساعات، بينما كل رسالة تُرسل في الفجوات تضيع. هذا يتصل، يكمل المصافحة ويحتفظ بالسوكيت، لذا فإن الخادم الذي يفشل بهذه الطريقة يفشل الفحص بدلاً من أن يتم تغطيته بمنطق إعادة المحاولة على الجانب الآخر.