Bila anda akan menggunakan WebSockets, SSE, atau long-polling dan bukan HTTP biasa?

Question

IT Interview Practice · Accepted Answer

HTTP biasa ialah **request/response**: klien bertanya, server menjawab, selesai. Itu tidak sesuai untuk ciri **real-time** (sembang, papan pemuka langsung, pemberitahuan, penyuntingan kolaboratif) di mana *server* perlu menolak data bila-bila masa ia ada sesuatu yang baharu. Pilihan-pilihan ialah cara untuk mengatasi model dimula-klien HTTP, sepanjang satu spektrum kerumitan:

```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** ialah sandaran yang berfungsi di mana-mana: klien membuat satu permintaan biasa yang server tahan terbuka sehingga ia ada data, kemudian klien serta-merta meminta semula. Ia menghampiri push atas HTTP biasa tetapi membazir satu kitaran permintaan setiap mesej dan menambah latensi.

**SSE (Server-Sent Events)** ialah satu strim **sehala** (server → client) yang ringan dan diseragamkan atas satu respons HTTP yang hidup lama tunggal. Ia ideal apabila hanya server menolak — suapan langsung, pemberitahuan, kemajuan, token LLM yang distrim. Ia mudah, berjalan atas HTTP/2 biasa (tiada infrastruktur khas), dan menyambung semula secara automatik. Hadnya: ia sehala dan teks sahaja.

**WebSockets** menaik taraf satu sambungan HTTP tunggal menjadi satu saluran TCP **full-duplex** yang kekal di mana kedua-dua pihak menghantar bila-bila masa dengan overhead setiap-mesej yang minimum. Guna ia untuk interaksi yang benar-benar dwiarah, latensi-rendah: sembang, permainan berbilang pemain, editor kolaboratif, dagangan. Kosnya ialah operasi — ia satu sambungan berkeadaan yang proxy, load balancer, dan autoscaler mesti dikonfigurasi untuknya, dan anda mesti membina penyambungan semula, heartbeat, dan backpressure sendiri.

**Petua praktikal:** default kepada HTTP biasa; guna **SSE** untuk penstriman server→client; capai **WebSockets** hanya apabila anda benar-benar perlukan real-time dwiarah; kekalkan **long-polling** sebagai sandaran universal.

## Mengapa ia penting

Memilih satu transport real-time ialah keputusan reka bentuk senior klasik di mana jawapan naif ("gunakan sahaja WebSockets untuk segalanya") biasanya salah. Penemu duga mahu melihat bahawa anda memadankan alat dengan *corak komunikasi* — sehala berbanding dwiarah, keperluan latensi, isi padu mesej — dan bahawa anda menimbang **kos operasi** sambungan berkeadaan yang hidup lama: sticky session, penskalaan, timeout proxy, dan logik penyambungan semula. Menyedari bahawa SSE selalu meliputi "server menolak kemas kini" dengan lebih ringkas daripada WebSockets, dan bahawa long-polling kekal sandaran yang kukuh, menandakan pengalaman production sebenar dan bukan mencapai pilihan yang paling menarik.

Mengapa ia penting

Soalan berkaitan