فهم SSE (أحداث مرسلة من الخادم) وفوائدها

مقدمة

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

في جوهرها، يتم تنفيذها باستخدام نهج التدفق، حيث يبدأ العميل طلب اتصال بالخادم ويبقي الاتصال مفتوحًا. ثم يقوم الخادم بدفع الرسائل إلى العميل بشكل نشط. يجب أن تكون البيانات المرسلة من الخادم إلى العميل باستخدام أحداث مرسلة من الخادم (SSE) مشفرة بتنسيق UTF-8، ويكون نوع المحتوى المعاد هو text/event-stream. على سبيل المثال، عند استخدام ChatGPT، عندما تسأله سؤالًا، ستلاحظ أنه يعرض الإجابة كلمة بكلمة. في الواقع، يقوم ChatGPT بدفع البيانات المحسوبة مسبقًا إليك بشكل نشط، باستخدام تقنية SSE لإرجاع البيانات أثناء الحساب، مما يتجنب أوقات الانتظار الطويلة للواجهة التي قد تؤدي إلى إغلاق الصفحة مباشرة.

فوائد SSE

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

2. تقليل الحمل على الشبكة: مقارنة بطرق الاستطلاع التقليدية، يستخدم SSE اتصالات طويلة الأمد. من خلال اتصال HTTP واحد، يمكن للخوادم دفع أحداث متعددة إلى العملاء، مما يتجنب طلبات HTTP المتكررة ويقلل من الحمل على الشبكة.

3. خفيف الوزن: يعتمد SSE على بروتوكول HTTP، مدعومًا من قبل برامج الخادم الحالية، وأسهل في الاستخدام مقارنة بـ WebSocket.

4. إعادة الاتصال التلقائي: يمكن لـ SSE محاولة إعادة الاتصال تلقائيًا بعد انقطاع الاتصال دون الحاجة إلى كود إضافي. تعزز هذه الآلية التلقائية لإعادة الاتصال استقرار النظام، مما يضمن استمرارية الاتصال حتى في ظروف الشبكة غير المستقرة.

وكالة خدمات SSE باستخدام API7 Enterprise

في التطبيقات العملية، يمكن الاستفادة من بوابة API لوكالة خدمات SSE للمساهمة في تعزيز استقرار الخدمة، وحل مشكلات الأمان والعبر-أصلية، وهو مناسب للتعامل مع سيناريوهات التطبيقات المعقدة. يعتبر NGINX واحدًا من أكثر خوادم الوكالة العكسية شعبية، ويحتل حصة سوقية كبيرة.

عند وكالة خدمات SSE على NGINX، من الضروري تعطيل proxy_buffering. ومع ذلك، يجب إغلاق هذا التكوين على الأقل على مستوى الموقع، مما يعني أنه إذا كان هناك مواقع متعددة في النظام وبعضها فقط يحتاج إلى تعطيل التخزين المؤقت لدعم خدمات SSE، فقد يؤثر ذلك على أداء واجهات برمجة التطبيقات الأخرى غير SSE. بالإضافة إلى ذلك، يفتقر تكوين proxy_buffering في NGINX إلى المرونة حيث لا يمكن تمكينه أو تعطيله ديناميكيًا أثناء التشغيل، مما يتطلب إعادة تحميل التكوين لتصبح فعالة، مما قد يؤدي إلى انقطاع الخدمة.

يوفر API7 Enterprise المكون الإضافي proxy-buffering، مما يسمح لك بوكالة خدمات SSE بشكل أكثر مرونة. من خلال تمكين هذا المكون الإضافي في المسارات المقابلة، يمكنك التحكم بسهولة في التخزين المؤقت دون الحاجة إلى إعادة تحميل التكوين بالكامل. تلبي هذه المرونة متطلبات وكالة خدمات SSE مع تلبية احتياجات الأداء والتكوين الديناميكي.

يؤكد الاختبار أدناه على نجاح وكالة خدمات SSE.

curl "http://127.0.0.1:9080/.sse" -H "Accept: text/event-stream"

event: server
data: 27d365b177ae
id: 1

event: request
data: GET /.sse HTTP/1.1
data:
data: Host: 127.0.0.1:9080
data: Accept: text/event-stream
data: User-Agent: curl/8.1.2
data: X-Forwarded-For: 192.168.65.1
data: X-Forwarded-Host: 127.0.0.1
data: X-Forwarded-Port: 9080
data: X-Forwarded-Proto: http
data: X-Real-Ip: 192.168.65.1
data:
id: 2

event: time
data: 2024-01-29T04:04:20Z
id: 3

event: time
data: 2024-01-29T04:04:21Z
id: 4
...

الخلاصة

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