సాదా HTTP బదులుగా మీరు WebSockets, SSE, లేదా long-polling ఎప్పుడు వాడతారు?

Question

IT Interview Practice · Accepted Answer

సాదా HTTP అనేది **request/response**: client అడుగుతుంది, server సమాధానం ఇస్తుంది, అయిపోయింది. అది **real-time** features (chat, live dashboards, notifications, collaborative editing)కు సరిపోదు, ఇక్కడ *server*కు కొత్తది ఉన్నప్పుడల్లా data push చేయాల్సి ఉంటుంది. ఈ ఎంపికలు HTTP client-initiated modelను దాటవేసే మార్గాలు, complexity spectrum వెంట:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

**Long-polling** అనేది అన్నిచోట్లా పనిచేసే fallback: client ఒక సాధారణ request చేస్తుంది, server దాన్ని data వచ్చే వరకు తెరిచి ఉంచుతుంది, తర్వాత client వెంటనే మళ్లీ request చేస్తుంది. ఇది సాదా HTTP మీద pushను ఉజ్జాయింపు చేస్తుంది కానీ messageకి ఒక request cycle వృథా చేసి latency జోడిస్తుంది.

**SSE (Server-Sent Events)** అనేది ఒకే long-lived HTTP response మీద ఒక తేలికైన, ప్రామాణిక **one-way** stream (server → client). server మాత్రమే push చేసినప్పుడు ఇది ఆదర్శం — live feeds, notifications, progress, streaming LLM tokens. ఇది సరళం, సాధారణ HTTP/2 మీద నడుస్తుంది (ప్రత్యేక infrastructure అవసరం లేదు), మరియు auto-reconnect అవుతుంది. పరిమితి: ఇది one-directional మరియు text-only.

**WebSockets** ఒకే HTTP connectionను ఒక persistent, **full-duplex** TCP channelగా upgrade చేస్తాయి, ఇక్కడ రెండు వైపులా కనీస per-message overheadతో ఎప్పుడైనా పంపుతాయి. నిజంగా bidirectional, low-latency interaction కోసం దీన్ని వాడు: chat, multiplayer games, collaborative editors, trading. ఖర్చు operational — ఇది proxies, load balancers, మరియు autoscalers configure చేయాల్సిన ఒక stateful connection, మరియు reconnection, heartbeats, మరియు backpressure మీరే నిర్మించాలి.

**సూత్రప్రాయంగా (rule of thumb):** defaultగా సాదా HTTP; server→client streaming కోసం **SSE** వాడు; నిజంగా bidirectional real-time అవసరమైనప్పుడు మాత్రమే **WebSockets** వైపు వెళ్లు; **long-polling**ను universal fallbackగా ఉంచు.

## ఇది ఎందుకు ముఖ్యం

ఒక real-time transport ఎంచుకోవడం ఒక classic senior design నిర్ణయం, ఇక్కడ naive సమాధానం ("అన్నిటికీ WebSockets వాడు") సాధారణంగా తప్పు. Interviewers మీరు toolను *communication pattern*కు సరిపోల్చారో చూడాలనుకుంటారు — one-way vs bidirectional, latency అవసరాలు, message volume — మరియు stateful, long-lived connections యొక్క **operational cost**ను మీరు తూకం వేస్తారో: sticky sessions, scaling, proxy timeouts, మరియు reconnection logic. SSE తరచుగా "server updates push చేస్తుంది"ను WebSockets కంటే సరళంగా కవర్ చేస్తుందని, మరియు long-polling ఒక బలమైన fallbackగా మిగిలి ఉందని గుర్తించడం అత్యంత మెరుపు option వైపు వెళ్లడం కాకుండా నిజ production అనుభవాన్ని సూచిస్తుంది.

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు