როდის გამოიყენებდით WebSockets-ს, SSE-ს ან long-polling-ს ჩვეულებრივი HTTP-ის ნაცვლად?

Question

IT Interview Practice · Accepted Answer

ჩვეულებრივი HTTP არის **request/response**: კლიენტი ითხოვს, სერვერი პასუხობს, დასრულდა. ეს ცუდად ერგება **რეალურ დროში** ფუნქციებს (chat, ცოცხალი dashboard-ები, notification-ები, ერთობლივი რედაქტირება), სადაც *სერვერს* სჭირდება მონაცემის დაპუშვა, როცა კი ახალი რამ აქვს. ვარიანტები არის HTTP-ის კლიენტ-ინიცირებული მოდელის გვერდის ავლის გზები, სირთულის სპექტრზე:

```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, რომელიც ყველგან მუშაობს: კლიენტი აკეთებს ჩვეულებრივ request-ს, რომელსაც სერვერი ღიად ინახავს, სანამ მონაცემი არ ექნება, შემდეგ კლიენტი მაშინვე ხელახლა ითხოვს. ის მიახლოებით ახდენს push-ს ჩვეულებრივ HTTP-ზე, მაგრამ თითო შეტყობინებაზე request-ის ციკლს ხარჯავს და latency-ს ამატებს.

**SSE (Server-Sent Events)** არის მსუბუქი, სტანდარტიზებული **ცალმხრივი** ნაკადი (server → client) ერთ გრძელვადიან HTTP response-ზე. ის იდეალურია, როცა მხოლოდ სერვერი აპუშავებს — ცოცხალი feed-ები, notification-ები, პროგრესი, LLM token-ების streaming. ის მარტივია, ჩვეულებრივ HTTP/2-ზე მუშაობს (სპეციალური ინფრასტრუქტურის გარეშე) და ავტომატურად უერთდება ხელახლა. შეზღუდვა: ის ცალმხრივი და მხოლოდ ტექსტურია.

**WebSockets** ერთ HTTP კავშირს მუდმივ, **full-duplex** TCP არხად აქცევს, სადაც ორივე მხარე ნებისმიერ დროს აგზავნის მინიმალური per-message ზედნადებით. გამოიყენეთ ის ჭეშმარიტად ორმხრივი, დაბალი-latency-ის ინტერაქციისთვის: chat, multiplayer თამაშები, ერთობლივი რედაქტორები, ტრეიდინგი. ღირებულება საოპერაციოა — ეს stateful კავშირია, რომლისთვისაც proxy-ები, load balancer-ები და autoscaler-ები უნდა დაკონფიგურდეს, ხოლო ხელახლა დაკავშირება, heartbeat-ები და backpressure თავად უნდა ააშენოთ.

**საორიენტაციო წესი:** ნაგულისხმევად ჩვეულებრივი HTTP; **SSE** server→client streaming-ისთვის; **WebSockets**-ს მიმართეთ მხოლოდ მაშინ, როცა ნამდვილად გჭირდებათ ორმხრივი რეალურ დროში; **long-polling** უნივერსალურ fallback-ად შეინახეთ.

## რატომ არის ეს მნიშვნელოვანი

რეალურ დროში transport-ის არჩევა კლასიკური senior დიზაინის გადაწყვეტილებაა, სადაც გულუბრყვილო პასუხი ("უბრალოდ ყველაფერზე WebSockets გამოიყენე") ჩვეულებრივ არასწორია. ინტერვიუერებს სურთ დაინახონ, რომ ხელსაწყოს *კომუნიკაციის პატერნს* უსადაგებთ — ცალმხრივი vs ორმხრივი, latency-ის საჭიროებები, შეტყობინებების მოცულობა — და რომ stateful, გრძელვადიანი კავშირების **საოპერაციო ღირებულებას** აწონით: sticky session-ები, მასშტაბირება, proxy-ის timeout-ები და ხელახლა დაკავშირების ლოგიკა. იმის აღიარება, რომ SSE ხშირად "სერვერი განახლებებს აპუშავებს"-ს WebSockets-ზე უფრო მარტივად ფარავს და რომ long-polling მყარ fallback-ად რჩება, მიანიშნებს რეალურ production გამოცდილებას, და არა ყველაზე მოჩვენებით ვარიანტს მიწვდომას.

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები