HTTP کلاسیک تکطرفه است: کلاینت میپرسد، سرور جواب میدهد. برای «سرور خودش خبر دهد» چهار الگو داریم — و انتخاب بینشان سؤال ثابت مصاحبههای بلادرنگ است.
| الگو | جهت | بستر | بهترین جا |
|---|---|---|---|
| Short Polling | کلاینت → سرور، دورهای | HTTP معمولی | بهروزرسانی غیرحساس به تأخیر (هر ۳۰ ثانیه) |
| Long Polling | کلاینت میپرسد، سرور نگه میدارد تا داده بیاید | HTTP معمولی | سازگار با همهجا؛ ولی اتصالهای معلق منابع میخورند |
| SSE — Server-Sent Events | فقط سرور → کلاینت | HTTP معمولی، یک اتصال باز | نوتیفیکیشن، فید زنده، استریم توکن LLM؛ auto-reconnect رایگان |
| WebSocket | دوطرفه کامل | Upgrade از HTTP به پروتکل فریمبندی | چت، بازی، همکاری زنده — جایی که کلاینت هم زیاد حرف میزند |
قانون تصمیم: اگر فقط سرور حرف میزند (قیمت لحظهای، استریم جواب هوش مصنوعی، نوتیف) SSE سادهتر، سبکتر و خودکار reconnect دارد؛ اگر دوطرفه و پرتراکنش است (چت، بازی) WebSocket. Long Polling فقط برای سازگاری با شبکههای قدیمی/سختگیر. Webhook برای سرور-به-سرور است، نه مرورگر.
مقیاسدادن اتصالهای ماندگار
DIAGRAMمیلیونها اتصال WebSocket
Clients
→
LB — L4
→
Gateway 1..N — اتصالهای ماندگار
→
Pub/Sub لایه fanout
→
سرویسهای منطق
- هر node مدرن میتواند صدها هزار اتصال TCP نگه دارد (با تیونینگ file descriptor و حافظه) — ولی اتصال state است: node باید بداند هر کاربر به کدام socket وصل است.
- پیام به کاربرِ روی node دیگر: رجیستری (Redis: user→node) یا لایه Pub/Sub که همه Gateway ها عضوشاند و هرکدام به اتصالهای محلیاش fanout میکند.
- Heartbeat اجباری: هر ~۳۰ ثانیه ping/pong تا NAT و پروکسی اتصال را نکشند؛ قطعبیخداحافظی را با TTL بفهم.
- Reconnection با backoff + جمعکردن عقبماندگی: کلاینت با «آخرین event_id دیدهشده» برمیگردد و سرور از همان نقطه ادامه میدهد (resume).
- Load balancing اتصال ماندگار با L4 و consistent hashing؛ ولی یادت باشد reconnect ها به گرهای متفاوت میتوانند برسند — resume state باید قابل حمل باشد.
به زبان ساده
سه راه برای «زنده» بودن صفحه: هر چند ثانیه سؤالکردن (long-polling)، کانال یکطرفه سروربهکلاینت (SSE) و خط دوطرفه دائمی (WebSocket) — هر کدام قیمت خودش را دارد.
مثال واقعی
قیمت لحظهای بورس با SSE کافی است چون فقط سرور حرف میزند؛ اما چت دوطرفه به WebSocket نیاز دارد چون هر دو طرف پی در پی حرف میزنند.