ارتباط بلادرنگ: وب‌سوکت و جایگزین‌ها
سامانه‌های زیادی به جایی می‌رسند که کاربر باید چیزی را بدون درخواست کردن ببیند: پیام جدید، تغییر وضعیت سفارش، موقعیت پیک روی نقشه، اعلان.
روش‌های رسیدن به این، از ساده تا پیچیده متفاوت‌اند — و انتخاب پیچیده‌ترین گزینه، شایع‌ترین اشتباه این حوزه است.
چهار روش
۱. دریافت دوره‌ای
مرورگر هر چند ثانیه می‌پرسد «چیز جدیدی هست؟»
مزیت: ساده‌ترین. با هر زیرساختی کار می‌کند. پشت هر واسطی رد می‌شود.
عیب: تأخیر به اندازهٔ فاصلهٔ پرسش. و درخواست‌های بی‌فایده — سامانه‌ای با هزار کاربر و پرسش هر پنج ثانیه، دویست درخواست در ثانیه می‌گیرد که اکثرشان خالی برمی‌گردند.
کِی کافی است: وقتی تأخیر چند ثانیه‌ای قابل قبول است. و این بیشتر از آن چیزی است که تیم‌ها فکر می‌کنند.
۲. دریافت دوره‌ای هوشمند
همان، با فاصلهٔ متغیر: وقتی کاربر فعال است سریع، وقتی صفحه در پس‌زمینه است کند یا متوقف.
تقریباً همیشه بهتر از روش اول است و همان‌قدر ساده.
۳. رویدادهای ارسالی از سرور
اتصال یک‌طرفهٔ باز: سرور هر وقت خواست می‌فرستد، کاربر فقط می‌شنود.
مزیت: ساده‌تر از وب‌سوکت، روی HTTP معمولی کار می‌کند، اتصال مجدد خودکار دارد.
عیب: یک‌طرفه است.
کِی مناسب است: اعلان، به‌روزرسانی وضعیت، داشبورد زنده. برای بیشتر کاربردهای «سرور به کاربر»، این گزینهٔ درست است و کمتر از همه استفاده می‌شود.
۴. وب‌سوکت
اتصال دوطرفهٔ دائم.
مزیت: کمترین تأخیر، دوطرفه.
عیب: پیچیده‌تر. باید اتصال مجدد، ضربان و وضعیت را خودتان مدیریت کنید. و پشت بعضی واسط‌ها و شبکه‌های شرکتی مسدود می‌شود.
کِی لازم است: چت، همکاری همزمان، بازی، ردیابی زندهٔ پرتکرار.
قاعدهٔ انتخاب
ساده‌ترین چیزی که کار می‌کند.
- تأخیر چند ثانیه قابل قبول؟ → دریافت دوره‌ای.
- فقط سرور به کاربر می‌فرستد؟ → رویدادهای ارسالی از سرور.
- دوطرفه و پرتکرار؟ → وب‌سوکت.
تیم‌هایی که از وب‌سوکت شروع می‌کنند، معمولاً پیچیدگی‌ای می‌خرند که لازم ندارند — و شش ماه بعد با مسائل مقیاس‌پذیری‌اش درگیرند.
مسائلی که با سرور دوم ظاهر می‌شوند
اینجا جایی است که معماری اتصال دائم واقعاً سخت می‌شود.
با یک سرور، همه‌چیز ساده است: کاربر متصل است، سرور می‌داند، پیام می‌فرستد.
با دو سرور: کاربر الف به سرور ۱ متصل است و کاربر ب به سرور ۲. حالا اگر الف پیامی برای ب بفرستد، سرور ۱ اصلاً نمی‌داند ب کجاست.
راه‌حل: یک لایهٔ پیام‌رسانی بین سرورها. هر سرور پیام را منتشر می‌کند و سرورهایی که کاربر مقصد را دارند، تحویل می‌دهند. الگویش همان صف پیام است.
و بارگذار باید نشست‌چسبان باشد یا معماری طوری باشد که اهمیت ندهد.
این را از ابتدا در نظر بگیرید. افزودنش به سامانه‌ای که با یک سرور نوشته شده، بازنویسی لایهٔ ارتباط است.
مصرف منابع
هر اتصال باز، حافظه و یک توصیف‌گر فایل می‌گیرد. ده هزار کاربر همزمان یعنی ده هزار اتصال.
دو نکته:
تعداد اتصال مجاز سیستم‌عامل را تنظیم کنید. مقدار پیش‌فرض معمولاً بسیار کمتر از نیاز است — و وقتی به سقف بخورید، خطایی می‌گیرید که ربطش به این تنظیم واضح نیست.
زبان و فریمورک اهمیت دارد. بعضی مدل‌های همزمانی هزاران اتصال را ارزان اداره می‌کنند و بعضی نه. این یکی از معدود جاهایی است که انتخاب فناوری واقعاً روی مقیاس اثر می‌گذارد — برخلاف اکثر موارد که در انتخاب فناوری گفتیم اهمیت کمتری دارد.
قطع اتصال، حالت عادی است
در بازار ما این بند حیاتی است: شبکهٔ همراه مدام قطع و وصل می‌شود.
آنچه لازم است:
اتصال مجدد خودکار با فاصلهٔ فزاینده. نه بلافاصله — اگر سرور مشکل داشته باشد، هزار کاربر که همزمان تلاش می‌کنند وضع را بدتر می‌کنند.
ضربان دوره‌ای، چون اتصالی که مرده ممکن است تا مدت‌ها باز به نظر برسد.
بازیابی پیام‌های ازدست‌رفته. کاربری که سی ثانیه قطع بوده، باید بفهمد چه چیزی را از دست داده. راه‌حل: هر پیام شمارهٔ ترتیب داشته باشد و کاربر هنگام اتصال مجدد بگوید آخرین شماره‌ای که دیده چه بوده.
بدون این، سامانهٔ شما در شبکهٔ ناپایدار داده گم می‌کند — و کاربر نمی‌فهمد.
و نمایش وضعیت اتصال به کاربر.
امنیت
احراز هویت هنگام برقراری اتصال، و بررسی مجدد در طول زمان — اتصالی که ساعت‌ها باز می‌ماند، ممکن است توکنش منقضی شده یا دسترسی کاربر لغو شده باشد.
بررسی مجوز برای هر پیام. کاربری که به کانال متصل شده، لزوماً حق دیدن هر پیامی را ندارد. قاعدهٔ همیشگی: بررسی دسترسی در سرور، به‌ازای رکورد — همان چیزی که در سطوح دسترسی گفتیم.
محدودیت نرخ، وگرنه یک کاربر می‌تواند سرور را با پیام پر کند.
و اعتبارسنجی ورودی، مثل هر رابط دیگری.
موبایل، حالت خاص
روی موبایل، اتصال دائم مسائل خودش را دارد:
سیستم‌عامل اتصال پس‌زمینه را می‌بندد. روی iOS عملاً نمی‌توانید اتصال باز را در پس‌زمینه نگه دارید.
مصرف باتری. اتصال دائم، رادیو را بیدار نگه می‌دارد.
الگوی درست: اتصال دائم فقط وقتی اپ در پیش‌زمینه است. برای پس‌زمینه، اعلان — با همهٔ محدودیت‌هایی که در اعلان‌های موبایل گفتیم.
استثنا: اپ‌هایی که کاربر ساعت‌ها بازشان نگه می‌دارد — اپ راننده، اپ پیک. آنجا اتصال دائم معقول است.
و یک توصیهٔ عملی
اگر مطمئن نیستید کدام روش را لازم دارید، با دریافت دورهٔ‌ای هوشمند شروع کنید.
سامانه را بسازید، ببینید تأخیر واقعاً مشکل‌ساز است یا نه، و بار واقعی را اندازه بگیرید. اگر لازم شد، مهاجرت به روش‌های پیشرفته‌تر ممکن است — به شرطی که لایهٔ دریافت داده را از منطق جدا نگه داشته باشید.
بیشتر سامانه‌هایی که «بلادرنگ» می‌خواهند، در واقع «به‌روز» می‌خواهند — و آن دو یکی نیستند.