إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
تمكن WebSockets، التي تم إنشاؤها في RFC6455، من الاتصال ثنائي الاتجاه بين العميل والخادم. على عكس طلب HTTP أو HTTPS التقليدي، تسمح WebSockets للمستعرض بإنشاء اتصال وتلقي بيانات مستمرة من خادم، دون الحاجة إلى سحب الخادم البعيد باستمرار أو الحاجة إلى إنشاء اتصالات متعددة في كلا الاتجاهين (العميل إلى الخادم والخادم إلى العميل).
مزايا WebSocket
بروتوكول WebSocket له العديد من الفوائد على طلبات HTTP التقليدية، بما في ذلك:
- توافق المستعرض: تدعم جميع مستعرضات الويب الحديثة تقريبا WebSockets.
- بيانات الوقت الحقيقي: تمكن WebSockets نقل البيانات في الوقت الحقيقي بين العميل والخادم.
- الكفاءة: تلغي WebSockets الحاجة إلى استقصاء الخوادم باستمرار للتحقق من وجود تحديثات.
- الأمان: يمكن تشفير WebSockets باستخدام TLS واستخدام منافذ HTTP القياسية، مثل 80 و443.
- المرونة: يمكن استخدام WebSockets لمجموعة متنوعة من التطبيقات، بما في ذلك الدردشة والألعاب ومنصات التداول المالي.
كيفية عمل بروتوكول WebSocket
لإنشاء اتصال WebSocket يتم تبادل تأكيد الاتصال المحدد المستند إلى HTTP بين حاسوب العميل والخادم. وفي حالة النجاح، يتم "ترقية" بروتوكول طبقة التطبيق من HTTP إلى WebSockets باستخدام اتصال TCP المؤسس مسبقًا. بمجرد حدوث ذلك، يتم تغيير البروتوكول إلى WebSockets ولم تعد نسبة استخدام الشبكة تتدفق عبر HTTP. يتم إرسال البيانات أو تلقيها باستخدام بروتوكول WebSocket بواسطة نقطتي النهاية حتى يتم إغلاق اتصال WebSocket.
إشعار
بعد ترقية الاتصال إلى WebSocket، كوكيل وسيط/إنهاء، سترسل بوابة التطبيق للحاويات البيانات المستلمة من الواجهة الأمامية إلى الخلفية والعكس صحيح، دون أي إمكانية فحص أو معالجة. لذلك، لن يتم تطبيق أي معالجات مثل إعادة كتابة العنوان أو إعادة كتابة عنوان URL أو تجاوز اسم المضيف بعد إنشاء اتصال WebSocket.
قد تكون اتصالات WebSocket إما في نص عادي أو مشفرة عبر TLS. عند إنشاء اتصال عبر نص عادي، يتم إنشاء الاتصال بتنسيق ws://< fqdn>/path. عند إنشاء اتصال عبر TLS، يتم تأسيس الاتصال بتنسيق wss://< fqdn>/path.
تحقيقات الصحة
لا يلزم تكوين للاستفادة من طلب WebSocket في بوابة التطبيق للحاويات، ولكن يجب عليك التأكد من تكوين فحوصات السلامة بشكل صحيح لضمان ظهور الخلفية على أنها صحية.
بشكل افتراضي، تحاول بوابة التطبيق للحاويات بدء تأكيد اتصال HTTP إلى منفذ الواجهة الخلفية الذي يقوم بتشغيل خدمة WebSocket. في كثير من الحالات، يقوم هذا بشكل خاطئ بتسمية الواجهة الخلفية على أنها غير سليمة، لذلك يجب تعريف HealthCheckPolicy لضمان مراعاة التحقيق الصحي استخدام مسبار TCP.
فيما يلي مثال على HealthCheckPolicy لواجهة WebSocket الخلفية.
kubectl apply -f - <<EOF
apiVersion: alb.networking.azure.io/v1
kind: HealthCheckPolicy
metadata:
name: websockets-health-check-policy
namespace: test-infra
spec:
targetRef:
group: ""
kind: Service
name: websockets-backend
namespace: test-infra
default:
interval: 5s
timeout: 3s
healthyThreshold: 1
unhealthyThreshold: 1
http:
path: /health
EOF
إشعار
يتم دعم WebSockets فقط عند استخدام واجهة برمجة تطبيقات البوابة لبوابة التطبيق للحاويات.
المقاييس والمراقبة
سجلات التشخيص:
تعمل اتصالات WebSocket باستخدام بروتوكول مميز. عند بدء الاتصال، يتلقى المتصفح رمز حالة HTTP 101، مما يشير إلى التبديل من HTTP إلى WebSocket وسينعكس في سجل الوصول.
يتم تسجيل تفاصيل اتصال WebSocket فقط عند إغلاق الاتصال. يسمح هذا بقياس مدة كل اتصال بدقة.
الخطوات التالية
تعرف على المزيد حول WebSockets وواجهة برمجة تطبيقات البوابة