WebSockets vs. Server-Sent events / EventSource

839

Baik WebSockets dan Server-Sent Events mampu mendorong data ke browser. Bagi saya mereka tampaknya merupakan teknologi yang bersaing. Apa perbedaan di antara mereka? Kapan Anda memilih satu dari yang lain?

html  browser  websocket  server-sent-events 
— Mads Mobæk
sumber
2
Tidak yakin bagaimana Anda melihat mereka bersaing. Satu sinkron dan bisa / akan digunakan untuk xfer data waktu dekat, sedangkan yang lainnya asinkron dan akan melayani tujuan yang sama sekali berbeda (secara efektif mengirim pesan seperti roti panggang dari aplikasi sisi server).
— Brian Driscoll
54
WebSockets adalah dua arah, dapat mengirim data ke server.
— Andre Backlund
13
Satu hal yang saya sukai tentang SSE adalah mudahnya memecahkan masalah ... buka saja permintaan ke server SSE Anda curl. Karena ini hanya format teks melalui HTTP, mudah untuk melihat apa yang terjadi.
— Sam
7
@BrianDriscoll - asinkron / sinkron - yang mana? Sejauh yang saya mengerti keduanya memungkinkan transfer asinkron?
— Dave Everitt
5
SSE tidak bekerja di IE, websockets tidak
— Tyler Gillies

Jawaban:

979

Websockets dan SSE (Server Sent Events) keduanya mampu mendorong data ke browser, namun mereka bukan teknologi yang bersaing.

Koneksi websockets dapat mengirim data ke browser dan menerima data dari browser. Contoh yang bagus dari aplikasi yang bisa menggunakan soket web adalah aplikasi obrolan.

Koneksi SSE hanya dapat mendorong data ke browser. Kutipan saham online, atau twitter yang memperbarui timeline atau feed adalah contoh yang baik dari aplikasi yang dapat mengambil manfaat dari SSE.

Dalam praktiknya karena semua yang dapat dilakukan dengan SSE juga dapat dilakukan dengan Websockets, Websockets mendapatkan lebih banyak perhatian dan cinta, dan lebih banyak browser mendukung Websockets daripada SSE.

Namun, itu bisa berlebihan untuk beberapa jenis aplikasi, dan backend bisa lebih mudah diimplementasikan dengan protokol seperti SSE.

Selanjutnya SSE dapat di-polyfill ke browser lama yang tidak mendukungnya secara native hanya menggunakan JavaScript. Beberapa implementasi dari polyfills SSE dapat ditemukan di halaman github Modernizr .

Gotchas:

  • SSE menderita pembatasan jumlah maksimum koneksi terbuka, yang bisa sangat menyakitkan ketika membuka berbagai tab karena batasnya adalah per browser dan diatur ke angka yang sangat rendah (6). Masalah telah ditandai sebagai "Tidak akan diperbaiki" di Chrome dan Firefox . Batas ini adalah per browser + domain, sehingga berarti Anda dapat membuka 6 koneksi SSE di semua tab www.example1.comdan 6 koneksi SSE lainnya ke www.example2.com(terima kasih Phate).
  • Hanya WS yang dapat mengirimkan data biner dan UTF-8, SSE terbatas pada UTF-8. (Terima kasih kepada Chado Nihi).
  • Beberapa firewall perusahaan dengan inspeksi paket mengalami kesulitan berurusan dengan WebSockets (Sophos XG Firewall, WatchGuard, McAfee Web Gateway).

HTML5Rocks memiliki beberapa informasi bagus tentang SSE. Dari halaman itu:

Acara yang Dikirim Server vs. WebSockets

Mengapa Anda memilih Server-Sent Events daripada WebSockets? Pertanyaan bagus.

Salah satu alasan SSE tetap berada dalam bayang-bayang adalah karena API kemudian seperti WebSockets menyediakan protokol yang lebih kaya untuk melakukan komunikasi dua arah, dupleks penuh. Memiliki saluran dua arah lebih menarik untuk hal-hal seperti game, aplikasi pengiriman pesan, dan untuk kasus-kasus di mana Anda memerlukan pembaruan real-time dari kedua arah. Namun, dalam beberapa skenario, data tidak perlu dikirim dari klien. Anda hanya perlu pembaruan dari beberapa tindakan server. Beberapa contoh adalah pembaruan status teman, ticker saham, feed berita, atau mekanisme push data otomatis lainnya (misalnya memperbarui Database SQL Web sisi klien atau penyimpanan objek IndexedDB). Jika Anda perlu mengirim data ke server, XMLHttpRequest selalu menjadi teman.

SSE dikirim melalui HTTP tradisional. Itu berarti mereka tidak memerlukan protokol khusus atau implementasi server untuk dapat bekerja. WebSockets di sisi lain, memerlukan koneksi full-duplex dan server Web Socket baru untuk menangani protokol. Selain itu, Server-Sent Events memiliki beragam fitur yang tidak dimiliki WebSockets oleh desain seperti penyambungan kembali otomatis, ID peristiwa, dan kemampuan untuk mengirim acara yang sewenang-wenang.

Ringkasan TLDR:

Keuntungan SSE dari pada Websockets:

  • Diangkut melalui HTTP sederhana alih-alih protokol khusus
  • Dapat diisi poli dengan javascript untuk "backport" SSE ke browser yang belum mendukungnya.
  • Dukungan bawaan untuk koneksi ulang dan event-id
  • Protokol yang lebih sederhana
  • Tidak ada masalah dengan firewall perusahaan melakukan inspeksi paket

Keuntungan dari Websockets dibandingkan SSE:

  • Real time, komunikasi dua arah.
  • Dukungan asli di lebih banyak browser

Kasus penggunaan SSE yang ideal:

  • Streaming ticker saham
  • pembaruan umpan twitter
  • Pemberitahuan ke browser

Gotchas SSE:

  • Tidak ada dukungan biner
  • Batas koneksi terbuka maksimum
— Alex Recarey
sumber
131
Obrolan dapat dilakukan dengan SSE - Anda dapat menggunakan POST biasa untuk mengirim pesan ke server. WebSockets hanya diperlukan jika Anda menerapkan obrolan a'la Google Wave.
— Kornel
135
Memang benar bahwa obrolan dan aplikasi waktu nyata lainnya dapat dilakukan dengan SSE. Namun, ini membutuhkan balasan POSTing "out of band", yaitu, ini tidak dikontrol oleh protokol SSE, dan sepertinya bukan contoh yang baik untuk penjelasan dasar tentang perbedaan antara SSE dan Websockets. Anda dapat menerapkan obrolan dengan polling HTTP dasar server setiap detik dan POSTing balasan baru. Ini tidak berarti itu cara terbaik / paling elegan untuk melakukannya.
— Alex Recarey
14
Saya pikir solusi pomeL adalah kompromi yang bagus untuk sebagian besar kasus, karena JS selalu dapat "mendorong" berbagai hal ke server dengan POST AJAX. Dari pengalaman saya, masalah utama umumnya adalah perlunya JS untuk polling untuk informasi baru, tetapi SSE yang mengurusnya. : D
— Jacob Pritchett
12
@MattDiPasquale Wave mengirim setiap kunci secara individual saat Anda mengetiknya alih-alih menyelesaikan pesan sekaligus. 200 byte POST overhead untuk 1 keystroke akan sia-sia dibandingkan dengan sekitar 6 untuk WebSocket.
— Kornel
9
Agak aneh mengatakan bahwa mereka bukan teknologi yang bersaing, dan kemudian melanjutkan untuk menggambarkan bahwa keduanya dapat digunakan untuk mencapai solusi yang serupa. Saya akan mengatakan itu membuat mereka bersaing.
— Alex
115

Menurut caniuse.com:

Anda dapat menggunakan polyfill khusus klien untuk memperluas dukungan SSE ke banyak browser lain. Ini lebih kecil kemungkinannya dengan WebSockets. Beberapa polyfills EventSource:

Jika Anda perlu mendukung semua browser, pertimbangkan untuk menggunakan perpustakaan seperti web-socket-js , SignalR atau socket.io yang mendukung banyak transport seperti WebSockets, SSE, Forever Frame dan AJAX polling panjang. Ini sering memerlukan modifikasi ke sisi server juga.

Pelajari lebih lanjut tentang SSE dari:

Pelajari lebih lanjut tentang WebSockets dari:

Perbedaan lainnya:

  • WebSockets mendukung data biner acak, SSE hanya menggunakan UTF-8
— Drew Noakes
sumber
3
Saya ingin menunjukkan pada 2016> 95% pengguna global mendukung WebSockets. Semua browser dan perangkat telah mendukung WebSockets selama lebih dari 4 tahun. Socket.IO akan mundur ke pemungutan suara AJAX panjang dan menangani kompleksitas meniru WebSockets untuk Anda jika itu tidak didukung, yang membuat dukungan 100%. Jika Anda menggunakan apa pun selain WebSockets pada tahun 2016, Anda menggunakan teknologi yang sudah usang.
— Nick Steele
3
@NickSteele Itu pernyataan hype omong kosong. Bergantung pada standar yang lebih tua baik-baik saja jika memenuhi kasus penggunaan Anda dan tidak berarti apa pun sudah usang. Itu hanya standar yang berbeda. Contoh: XHR masih dapat melakukan banyak hal yang tidak dapat dilakukan API Ambil, sehingga tidak ketinggalan zaman. Ini berbeda. Saya telah menggunakan WS di masa lalu, tetapi tahu dari pengalaman bahwa seseorang dapat mencapai hambatan dalam bentuk firewall perusahaan kebisingan yang memblokir permintaan ketika tidak memahami WS. SSE sangat efisien untuk apa yang dilakukannya, mudah dimengerti dan diimplementasikan dengan mudah dan mudah di-debug. Untuk aliran data satu arah kami, itu sempurna.
— oligofren
@oligofren Tidak perlu bersumpah. Jika sesuatu dirancang untuk menggantikan versi sebelumnya, dan industrinya diterima dan lebih baik dalam segala hal, menurut definisi, metode lama sudah usang. Sama seperti iPhone asli sudah usang, begitu pula XHR. XHR keluar sebelum Firefox, Chrome, iPhone pertama, sebelum YouTube, Netflix, Facebook dan bahkan MySpace. Ketika XHR keluar, Windows 98 adalah OS terbaik, AOL adalah penyedia terbaik, dan JSON bahkan tidak ada. WebSockets menggantikan XHR hampir satu dekade lalu. Jika Anda menekan halangan menggunakan WS hal yang menyebabkan halangan itu juga sudah ketinggalan zaman. Tidak ada alasan untuk ketinggalan sejauh itu.
— Nick Steele
4
Ganti BS dengan hiperbola maka :-) WS bukan pengganti untuk XHR / HTTP seperti drone untuk mobil pengiriman. Ini kasus penggunaan yang berbeda. WS bukan HTTP dan memiliki sweet spot yang berbeda. Anda akhirnya menerapkan ulang HTTP (buruk) di ruang pengguna jika Anda mau. Juga, Anda menyiratkan hal-hal yang tidak diberikan fakta: WS hanyalah protokol dua arah yang mendukung server push. Saya belum pernah melihat dokumen desain yang menyebutkan sedang dikembangkan sebagai pengganti apa pun. Sumber? Usia itu sendiri bukanlah faktor. Ketika diberi pilihan, pilih implementasi paling sederhana memeriksa semua persyaratan Anda.
— oligofren
1
Itu hanya dua tahun yang lalu (2017) Saya sedang men-debug tumpukan tumpukan proses Node JS di mana kode Socket.io menyebabkan fragmentasi memori besar-besaran dalam proses IIS, akhirnya berbicara langsung dengan tim Nure Azure. Kompleksitas total tidak gratis. Jika Anda dapat pergi dengan skrip 20 baris sederhana sebagai ketergantungan Anda pada server, sementara masih dapat melayani 100 ribu klien, saya akan melakukannya. Saya suka WS untuk apa yang dilakukannya, tetapi lihat apa yang Anda butuhkan sebelum memilih solusi.
— oligofren
16

Opera, Chrome, Safari mendukung SSE, Chrome, Safari mendukung SSE di dalam SharedWorker Firefox mendukung XMLHttpRequest readyState interaktif, sehingga kami dapat membuat EventSource polyfil untuk Firefox

— Yaffle
sumber
8

Websocket VS SSE

Soket Web - Ini adalah protokol yang menyediakan saluran komunikasi dupleks penuh melalui koneksi TCP tunggal. Misalnya komunikasi dua arah antara Server dan Browser Karena protokol lebih rumit, server dan browser harus bergantung pada perpustakaan websocket yangsocket.io

Example - Online chat application.

SSE (Server-Sent Event) - Dalam hal server mengirim acara, komunikasi dilakukan dari server ke browser saja dan browser tidak dapat mengirim data apa pun ke server. Jenis komunikasi ini terutama digunakan ketika kebutuhan hanya untuk menampilkan data yang diperbarui, kemudian server mengirim pesan setiap kali data diperbarui. Misalnya komunikasi satu arah antara Server ke Browser. Protokol ini tidak terlalu rumit, jadi tidak perlu mengandalkan perpustakaan eksternal JAVASCRIPT sendiri menyediakan EventSourceantarmuka untuk menerima pesan yang dikirim server.

Example - Online stock quotes or cricket score website.
— Gaurav Tiwari
sumber
4

Satu hal yang perlu diperhatikan:
Saya memiliki masalah dengan soket web dan firewall perusahaan. (Menggunakan HTTPS membantu tetapi tidak selalu.)

Lihat https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software https://github.com/sockjs/sockjs-client/issues/94

Saya berasumsi tidak ada banyak masalah dengan Server-Sent Events. Tapi saya tidak tahu.

Yang mengatakan, WebSockets sangat menyenangkan. Saya memiliki permainan web kecil yang menggunakan soket web (melalui Socket.IO) ( http://minibman.com )

— Drew LeSueur
sumber
1
Saya juga punya masalah dengan firewall perusahaan.
— oligofren
1
Satu masalah yang saya lihat dengan Server-Sent Events adalah bahwa beberapa proxy / firewall mungkin memblokirnya karena tidak memiliki header Panjang Konten
— Drew LeSueur
2

Berikut ini adalah pembicaraan tentang perbedaan antara soket web dan acara yang dikirim server. Sejak Java EE 7 WebSocket API sudah menjadi bagian dari spesifikasi dan tampaknya server yang mengirim acara akan dirilis dalam versi berikutnya dari edisi perusahaan.

— Patrick Leitermann
sumber
-3

Batas koneksi maks tidak menjadi masalah dengan http2 + sse.

Itu masalah di http 1

— pengguna1948585
sumber
Http2 memungkinkan beberapa permintaan pada domain yang sama diperlakukan sebagai stream. Teknik ini disebut multiplexing. Ini menghemat batas koneksi browser per domain, yang merupakan alasan mengapa orang melakukan sharding domain dengan Http1.
— user1948585
1
HTTP / 2 stream juga terbatas jumlahnya, ini melindungi server agar tidak dibombardir oleh satu browser dan memaksa browser untuk membatasi multiplexing mereka ke sejumlah stream - yang, dalam kasus kami, sama dengan koneksi HTTP / 1.1. yang membawa Anda kembali ke batas koneksi SSE.
— Myst
Saya menganggap koneksi websocket juga mengkonsumsi sumber daya server. samsaffron.com/archive/2015/12/29/websockets-caution-required . Itu selalu baik untuk memiliki kemampuan untuk mengkonfigurasi sebanyak saku Anda memungkinkan.
— user1948585
kemungkinan SSE akan menggunakan sumber daya serupa di sebagian besar server (jika tidak lebih banyak sumber daya karena tumpukan HTTP yang masih ada dan keterbatasannya).
— Myst
1
Jawaban ini benar. Batas 6 koneksi HTTP tidak ada lagi ketika menggunakan HTTP / 2. Bukti: codepen.io/dunglas/pen/yLYxdxK?editors=1010 Dengan HTTP / 2, terserah server dan klien dapat menegosiasikan jumlah maksimum aliran simultan (100 secara default).
— Kévin Dunglas
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.