WebSocket در مقابل Server-Sent Event: تفاوت های کلیدی در سال 2024

WebSockets و Server-Sent Events معمولاً در برنامه‌های real-time استفاده می‌شوند که انتقال سریع و کارآمد داده یک نیاز حیاتی است. انتظارات از تجربیات real-time در برنامه ها تنها با گذشت زمان، با بهبود فناوری و درک آنچه ممکن است، افزایش یافته است.

این مقاله دو پروتکل محبوب real-time یعنی WebSockets و Server-Sent Event APIs را با هم مقایسه می‌کند. در زیر می آموزید که هر کدام چه توانایی هایی دارند، مزایا و معایب آن ها و زمان استفاده از آنها.

WebSockets چیست؟

WebSockets یک لایه انتقال نازک است که در بالای استک TCP/IP دستگاه ساخته شده است که اتصالات دوطرفه، کم تأخیر و رویداد محور را بین سرور و مرورگر فراهم می کند. این برای برنامه‌های real-time ایده‌آل است، زیرا پس از دست دادن اولیه HTTP، یک اتصال WebSocket می‌تواند همه پیام‌ها را برای یک سشن واحد، بدون هیچ گونه دست دادن بیشتر، مدیریت کند. وقتی سشن تمام شد، اتصال باید به عنوان بخشی از پاکسازی بسته شود.

خلاصه ای از ویژگی های کلیدی WebSockets

از پروتکل ws سفارشی برای انتقال پیام ها استفاده می کند که در سطح پایین تری نسبت به HTTP کار می کند.
اتصال دو طرفه است، بنابراین WebSockets برای برنامه‌هایی که نیاز به خواندن و نوشتن داده‌ها از سرور دارند، مانند برنامه‌های چت یا بازی‌های چند نفره، مفید هستند.
پیاده سازی WebSocket از ابتدا می تواند پیچیده باشد، اما طیف گسترده ای از کتابخانه ها برای تسهیل این امر وجود دارد.
مبتنی بر رویداد؛ برای بازیابی پیام ها نیازی به نظرسنجی نیست و به کاهش تأخیر کمک می کند.
RFC 6455 – پروتکل WebSocket در سال 2011 در وب سایت IETF منتشر شد و همه مرورگرهای اصلی اکنون از آن پشتیبانی می کنند.

مزایا و معایب WebSockets
 

مزایای WebSockets:

بازگشت به HTTP: اگر برای غلبه بر کاستی‌های WebSockets ذکر شده در زیر نیاز به بازگشت به HTTP دارید، با استفاده از کتابخانه‌های مبتنی بر WebSockets محبوب مانند Socket.IO که دارای چنین بازگشت‌هایی داخلی هستند، می‌توانید به این هدف برسید.
بهره وری منابع: به دلیل اینکه یک پروتکل سطح پایین است، یک اتصال WebSocket می تواند پهنای باند بالایی را روی یک اتصال واحد مدیریت کند. WebSocket ها از «XMLHttpRequest» استفاده نمی کنند و هر بار که نیاز به دریافت اطلاعات بیشتر از سرور داشته باشیم، سرصفحه ها ارسال نمی شوند. این امر بارهای گران داده ارسال شده به سرور را به حداقل می رساند.
WebSockets ارتباط دوطرفه را در زمان واقعی ارائه می دهد: از آنجایی که WebSocket یک کانال ارتباطی دوطرفه و دوطرفه را فراهم می کند، سرور می تواند پیام هایی را برای کلاینت ارسال کند و هر دو می توانند همزمان پیام ارسال کنند. این باعث می‌شود برنامه‌های real-time دو طرفه و چند کاربره مانند اتاق‌های گفتگو امکان پذیر و کارآمد باشند.
انعطاف پذیری فرمت داده ها: WebSocket ها می توانند داده های باینری و UTF-8 را انتقال دهند به این معنی که برنامه ها می توانند از ارسال متن ساده و فرمت های باینری مانند تصاویر و ویدیو پشتیبانی کنند.

معایب WebSockets:

مسدود کردن فایروال: برخی از فایروال‌های سازمانی با بازرسی بسته‌ها در برخورد با WebSockets مشکل دارند (به ویژه فایروال SophosXG، WatchGuard و McAfee Web Gateway).
عدم پشتیبانی داخلی برای اتصال مجدد: هنگامی که یک اتصال WebSocket بسته می شود (مثلاً به دلیل مشکلات شبکه)، کلاینت سعی نمی کند دوباره به سرور متصل شود، به این معنی که برای نظرسنجی از سرور باید کد اضافی بنویسید. برقراری ارتباط زمانی که دوباره در دسترس باشد. از طرف دیگر، می توانید از رویدادهای ارسال شده از سرور یا کتابخانه ای با پشتیبانی از اتصال مجدد مانند Socket.IO استفاده کنید.

شروع کار با WebSockets

برای شروع با WebSockets، معمول است که از یک کتابخانه برای پیاده سازی سرور با استفاده از زبانی مانند Node.js استفاده کنید و سپس از طریق یک کلاینت با استفاده از WebSockets API سمت کلاینت به آن سرور متصل شوید.

دو کلاس اصلی از کتابخانه های WebSocket وجود دارد:

آنهایی که پروتکل را پیاده سازی می کنند و بقیه را به توسعه دهنده می سپارند، مانند ws.
مواردی که در بالای پروتکل با ویژگی‌های اضافی مختلف ساخته می‌شوند که معمولاً توسط برنامه‌های پیام‌رسانی real-time مورد نیاز است، مانند بازیابی اتصالات از دست رفته، pub/sub، کانال‌ها، احراز هویت و مجوز. به عنوان مثال می توان به Socket.IO و SockJS اشاره کرد.

اگرچه کتابخانه های WebSocket که در بالای پروتکل ساخته می شوند، از منظر ویژگی چیزهای زیادی برای ارائه دارند، مهم است که توجه داشته باشیم که آنها اغلب به جای استفاده از WebSocket API خام ارائه شده توسط، نیاز دارند که کتابخانه های خود را در سمت کلاینت استفاده کنند. مرورگر هنگامی که راه حل را ادغام کردید، نسبتاً قفل شده اید. مطمئن شوید که آیا کتابخانه برای برنامه های بلندمدت شما مناسب است یا خیر.

در این بخش، با ایجاد یک سرور WebSocket با استفاده از کتابخانه ای که در دسته اول قرار دارد، با WebSockets شروع می کنید - ws: یک راه حل ساده و قابل اعتماد برای Node.js. سپس به شما نشان خواهیم داد که چگونه با استفاده از WebSocket API اصلی به آن نمونه سرور در مرورگر متصل شوید.

ایجاد سرور WebSocket با ws

قطعه کد زیر یک سرور ساده Node.js WebSocket ایجاد می کند:

const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', function connection(ws) {
  ws.on('message', function incoming(message) {
    console.log('received: %s', message);
  });

  ws.send('something');
});

پس از نیاز به کتابخانه و ایجاد یک سرور WebSocket جدید، یک شنونده رویداد اتصال را به سرور متصل می کنیم تا به اتصالات گوش دهد. هنگامی که یک اتصال رخ می دهد، شنونده رویداد پیام برای گوش دادن به پیام ها و ارسال پیام به کلاینت متصل تنظیم می شود.

استفاده از WebSockets در مرورگر

برای اتصال به سرور WebSocket از یک مرورگر، به چیزی شبیه به این نیاز دارید:

const ws = new WebSocket('ws://example.org');

ws.addEventListener('open', () => {
  // Send a message to the WebSocket server
  ws.send('Hello!');
});
 
ws.addEventListener('message', event => {
  // The `event` object is a typical DOM event object, and the message data sent
  // by the server is stored in the `data` property
  console.log('Received:', event.data);
});

پس از اتصال به سرور از طریق URL آن (به استفاده از پروتکل ws توجه داشته باشید)، شنونده‌های رویداد را تنظیم می‌کنیم تا قبل از ارسال هر پیامی، به تکمیل دست دادن HTTP گوش دهند و به پیام‌های دریافتی از سرور واکنش نشان دهند.

در حالی که کلاس WebSocket ساده و آسان برای استفاده است، فقط یک بلوک ساختمانی اساسی است. ویژگی‌های اضافی مانند کانال‌های پیام‌رسانی مشترک و اتصال مجدد خودکار باید جداگانه اجرا شوند. به همین دلیل است که بسیاری از کتابخانه های سمت سرویس گیرنده وجود دارد.

رویدادهای ارسال شده توسط سرور چیست؟

رویدادهای ارسال شده از سرور (SSE) بر اساس رویدادهای DOM ارسال شده از سرور است. مرورگرها می توانند با استفاده از رابط EventSource در جریان رویدادهایی که توسط یک سرور ایجاد می شود مشترک شوند و هر زمان که یک رویداد جدید رخ دهد، به روز رسانی ها را دریافت کنند. EventSource اتصال جریان رویداد HTTP را از یک URL خاص می پذیرد و اتصال را در حین بازیابی داده های موجود باز نگه می دارد. رویدادهای ارسال شده توسط سرور (به جای اینکه کشیده شوند یا درخواست شوند) از یک سرور به یک مرورگر منتقل می شوند.

رویدادهای ارسال شده از سرور استانداردی است که توضیح می‌دهد چگونه سرورها می‌توانند پس از برقراری اتصال اولیه کلاینت، انتقال داده به کلاینتان را حفظ کنند. این یک اجرای حافظه کارآمد از جریان XHR را ارائه می دهد. بر خلاف اتصال XHR خام، که کل پاسخ دریافتی را تا زمانی که اتصال قطع شود، بافر می کند، یک اتصال SSE می تواند پیام های پردازش شده را بدون انباشته شدن همه آنها در حافظه حذف کند.

خلاصه ای از ویژگی های کلیدی رویدادهای ارسال شده توسط سرور

از جریان XHR برای انتقال پیام ها از طریق HTTP استفاده می کند.
اتصال یک طرفه است، بنابراین SSE ها برای برنامه هایی مفید هستند که فقط به خواندن داده ها از سرور نیاز دارند، مانند سهام زنده یا اخبار.
پیچیدگی کمتری برای پیاده سازی اتصالات مبتنی بر SSE، اما کتابخانه های مرتبط زیادی در دسترس نیستند.
مبتنی بر رویداد؛ برای رهگیری پیام ها نیازی به نظرسنجی نیست.
رویدادهای ارسال شده توسط سرور در مشخصات HTML مشخص شده اند و چندین سال است که توسط همه مرورگرهای اصلی پشتیبانی می شوند. برای جزئیات بیشتر به جدول پشتیبانی مرورگر EventSource در MDN مراجعه کنید.

مزایای رویدادهای ارسال شده توسط سرور:

Polyfillable: رویدادهای ارسال شده از سرور را می توان با جاوا اسکریپت در مرورگرهایی که هنوز آن را پشتیبانی نمی کنند، پر کرد. این برای سازگاری به عقب مفید است زیرا شما می توانید به جای نوشتن یک جایگزین، به پیاده سازی موجود اعتماد کنید.
پشتیبانی داخلی برای اتصال مجدد: اتصالات رویداد ارسال شده از سرور، اتصال را پس از از بین رفتن دوباره برقرار می کند، به این معنی که کد کمتری برای نوشتن برای دستیابی به یک رفتار ضروری است.
بدون مسدود کردن فایروال: SSE ها با فایروال های شرکتی که بازرسی بسته را انجام می دهند، مشکلی ندارند، که برای پشتیبانی از برنامه ها در تنظیمات سازمانی مهم است.

معایب رویدادهای ارسال شده توسط سرور:

محدودیت های قالب داده رویدادهای ارسال شده توسط سرور به انتقال پیام های UTF-8 محدود می شود. داده های باینری پشتیبانی نمی شود.
اتصالات همزمان محدود در هر مرورگر فقط می توانید شش اتصال SSE باز همزمان داشته باشید. زمانی که می خواهید چندین تب را با اتصالات SSE باز کنید، این می تواند دردناک باشد. برای اطلاعات بیشتر و پیشنهادات راه‌حل، «رویدادهای ارسال‌شده توسط سرور و محدودیت‌های مرورگر» را ببینید.
SSE یک جهته است. شما فقط می توانید از سرور به کلاینت پیام ارسال کنید. در حالی که این برای ایجاد برنامه‌های بی‌درنگ فقط خواندنی مانند نمادهای سهام مفید است، اما برای بسیاری از انواع دیگر برنامه‌های real-time محدود است.

شروع با رویدادهای ارسال شده توسط سرور

در این بخش به نحوه شروع آزمایش با SSE ها، پیاده سازی یک سرور ساده با express-sse برای تمیز نگه داشتن چیزها و اتصال به آن از مرورگر با استفاده از EventSource نگاه خواهید کرد.

ایجاد سرور SSE با express-sse

قطعه کد زیر یک سرور ساده Node.js SSE ایجاد می کند:

var SSE = require('express-sse');
var sse = new SSE();
app.get('/stream', sse.init);
// we can always call sse.send from anywhere the sse variable is available, and see the result in our stream.

let content = 'Test data at ' + JSON.stringify(Date.now());
sse.send(content);

پس از ایجاد یک جریان با sse.init، یک پیام ساده با استفاده از ()sse.send به پایین استریم ارسال می شود.

استفاده از SSE در مرورگر

برای اتصال به سرور SSE از یک مرورگر، به چیزی شبیه به این نیاز دارید:

const evtSource = new EventSource("/stream");

eventSource.addEventListener('message', event => {
    console.log(event.data);
}

EventSource URL جریان را برای اتصال به آن ارسال می کند. پس از اتصال، شنونده رویداد پیام را در منبع رویداد راه‌اندازی می‌کنیم تا پیام‌های دریافتی را مدیریت کند. برای مثال ساده ما، پیام را به کنسول وارد می کنیم.

آیا باید از WebSockets یا رویدادهای ارسال شده توسط سرور استفاده کنم؟

اینکه از کدام فناوری استفاده کنید بستگی به مورد استفاده شما دارد. در این بخش، موارد استفاده مناسب برای هر دو را بررسی خواهیم کرد.

زمان استفاده از WebSockets

WebSocket ها پیچیده تر و سخت تر از SSE هستند و نیاز به مقداری ورودی از توسعه دهنده دارند. برای این سرمایه گذاری، یک اتصال TCP تمام دوبلکس به دست می آورید که برای طیف وسیعی از سناریوهای کاربردی مفید است. به عنوان مثال، WebSockets برای موارد استفاده مانند همکاری چند نفره و برنامه های چت ترجیح داده می شود. در حالی که از نظر فنی می توان از SSE + AJAX برای دستیابی به این موارد استفاده کرد، این ترکیب می تواند منجر به ارتباط غیرهمگام و کار بیشتر از آنچه ممکن است با WebSocket ها باشد، شود.

چرا از رویدادهای ارسال شده توسط سرور از طریق WebSockets استفاده کنیم؟

رویدادهای ارسال شده از سرور جایگزین خوبی برای WebSockets برای موارد استفاده real-time ساده است که فقط به ارتباط یک طرفه (از سرور به کلاینت) نیاز دارد. به عنوان مثال می‌توان به برنامه‌های بی‌درنگ فقط خواندنی مانند نمادهای سهام یا به‌روزرسانی‌های اخبار اشاره کرد. با این حال، به خاطر داشته باشید که شما فقط می توانید داده های UTF-8 را از طریق SSE ارسال کنید (داده های باینری پشتیبانی نمی شوند).

رویدادهای ارسال شده توسط سرور در مقابل WebSockets کدام بهتر است؟

SSE راه حل ساده تری است، اما قابل توسعه نیست: اگر الزامات برنامه وب شما تغییر کند، این احتمال وجود دارد که در نهایت باید با استفاده از WebSockets اصلاح شود. اگرچه فناوری WebSocket کارهای اولیه بیشتری را ارائه می دهد، اما چارچوبی همه کاره تر و توسعه پذیرتر است، بنابراین گزینه بهتری برای برنامه های پیچیده است که احتمالاً در طول زمان ویژگی های جدیدی را اضافه می کنند.

نتیجه

مهمترین تفاوت در جهت ارتباط است زیرا مورد استفاده احتمالی یک فناوری خاص را تعیین می کند. احتمالاً بیشترین تأثیر را در انتخاب یکی از دیگری خواهد داشت.

ساختار پیام همچنین می تواند مقوله بسیار مهمی در انتخاب یک راه ارتباطی خاص باشد. اجازه دادن فقط پیام‌های متنی ساده یک اشکال بسیار مهم برای رویدادهای ارسال شده توسط سرور است.