आप सादे HTTP के बजाय WebSockets, SSE, या long-polling का उपयोग कब करेंगे?

Question

IT Interview Practice · Accepted Answer

सादा HTTP **request/response** है: client पूछता है, server जवाब देता है, ख़त्म। यह **real-time** सुविधाओं (chat, live dashboards, notifications, collaborative editing) के लिए ख़राब मेल है जहाँ *server* को जब भी कुछ नया हो तब data push करना होता है। ये विकल्प HTTP के client-आरंभित मॉडल से बचने के तरीके हैं, जटिलता के एक स्पेक्ट्रम के साथ:

```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 चक्र बर्बाद करता है और latency जोड़ता है।

**SSE (Server-Sent Events)** एक हल्का, मानकीकृत **एकतरफ़ा** stream (server → client) है जो एक अकेले लंबे-समय जीवित HTTP response पर होता है। यह तब आदर्श है जब केवल server push करता है — live feeds, notifications, progress, streaming LLM tokens। यह सरल है, सामान्य HTTP/2 पर चलता है (कोई विशेष infrastructure नहीं), और auto-reconnect करता है। सीमा: यह एक-दिशात्मक और केवल-text है।

**WebSockets** एक अकेले HTTP connection को एक स्थायी, **full-duplex** TCP channel में upgrade करते हैं जहाँ दोनों पक्ष न्यूनतम प्रति-message overhead के साथ किसी भी समय भेजते हैं। इसे वास्तव में द्विदिशात्मक, कम-latency अंतःक्रिया के लिए उपयोग करें: chat, multiplayer games, collaborative editors, trading। क़ीमत operational है — यह एक stateful connection है जिसके लिए proxies, load balancers, और autoscalers को configure करना होता है, और आपको reconnection, heartbeats, और backpressure ख़ुद बनाने होते हैं।

**अंगूठे का नियम:** सादे HTTP को default रखें; server→client streaming के लिए **SSE** उपयोग करें; **WebSockets** की ओर केवल तब बढ़ें जब आपको वाक़ई द्विदिशात्मक real-time चाहिए; **long-polling** को सार्वभौमिक fallback के रूप में रखें।

## यह क्यों महत्वपूर्ण है

एक real-time transport चुनना एक क्लासिक senior design निर्णय है जहाँ भोला जवाब ("हर चीज़ के लिए बस WebSockets उपयोग करो") आमतौर पर ग़लत होता है। interviewers देखना चाहते हैं कि आप tool को *संचार पैटर्न* से मिलाते हैं — एकतरफ़ा बनाम द्विदिशात्मक, latency ज़रूरतें, message मात्रा — और यह कि आप stateful, लंबे-समय जीवित connections की **operational क़ीमत** को तौलते हैं: sticky sessions, scaling, proxy timeouts, और reconnection logic। यह पहचानना कि SSE अक्सर "server updates push करता है" को WebSockets की तुलना में अधिक सरलता से कवर करता है, और यह कि long-polling एक मज़बूत fallback बना रहता है, सबसे चमकीले विकल्प की ओर बढ़ने के बजाय असली production अनुभव का संकेत देता है।

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न