Beberapa jawaban bagus dari orang lain yang mencakup banyak hal. Ini sedikit tambahan.
Satu-satunya keuntungan WebSockets dibandingkan plugin seperti Java Applets, Flash atau Silverlight adalah bahwa WebSockets secara native dibangun ke dalam browser dan tidak bergantung pada plugin.
Jika dengan ini Anda bermaksud bahwa Anda dapat menggunakan Java Applet, Flash, atau Silverlight untuk membuat sambungan soket, maka ya, itu mungkin. Namun Anda tidak melihatnya diterapkan di dunia nyata terlalu sering karena batasannya.
Misalnya, perantara dapat dan melakukan penutupan lalu lintas tersebut. Standar WebSocket dirancang agar kompatibel dengan infrastruktur HTTP yang ada dan oleh karena itu jauh lebih kecil kemungkinannya untuk diganggu oleh perantara seperti firewall dan proxy.
Selain itu, WebSocket dapat menggunakan port 80 dan 443 tanpa memerlukan port khusus, sekali lagi berkat desain protokol yang kompatibel dengan infrastruktur HTTP yang ada.
Alternatif soket tersebut (Java, Flash, dan Silverlight) sulit digunakan dengan aman dalam arsitektur lintas sumber. Jadi orang yang sering mencoba menggunakannya lintas sumber akan mentolerir ketidakamanan daripada berusaha melakukannya dengan aman.
Mereka juga dapat meminta port "non-standar" tambahan untuk dibuka (sesuatu yang tidak ingin dilakukan oleh administrator) atau file kebijakan yang perlu dikelola.
Singkatnya, menggunakan Java, Flash, atau Silverlight untuk konektivitas soket cukup bermasalah sehingga Anda tidak terlalu sering melihatnya diterapkan dalam arsitektur yang serius. Flash dan Java telah memiliki kemampuan ini setidaknya selama 10 tahun, namun itu tidak lazim.
Standar WebSocket dapat dimulai dengan pendekatan baru, dengan mempertimbangkan batasan tersebut, dan mudah-mudahan telah belajar beberapa pelajaran darinya.
Beberapa implementasi WebSocket menggunakan Flash (atau mungkin Silverlight dan / atau Java) sebagai fallbacknya saat konektivitas WebSocket tidak dapat dibuat (seperti saat berjalan di browser lama atau saat perantara mengganggu).
Meskipun beberapa jenis strategi fallback untuk situasi tersebut adalah cerdas, bahkan perlu, kebanyakan dari mereka yang menggunakan Flash dkk akan mengalami kekurangan yang dijelaskan di atas. Tidak harus seperti itu - ada beberapa solusi untuk mencapai koneksi berkemampuan lintas sumber yang aman menggunakan Flash, Silverlight, dll - tetapi sebagian besar implementasi tidak akan melakukannya karena itu tidak mudah.
Misalnya, jika Anda mengandalkan WebSocket untuk koneksi lintas sumber, itu akan berfungsi dengan baik. Tetapi jika Anda kemudian menjalankan di browser lama atau firewall / proxy mengganggu dan mengandalkan Flash, katakanlah, sebagai fallback Anda, Anda akan kesulitan melakukan koneksi lintas-sumber yang sama. Kecuali Anda tidak peduli dengan keamanan, tentu saja.
Itu berarti sulit untuk memiliki satu arsitektur terpadu yang berfungsi untuk koneksi native dan non-native, kecuali jika Anda siap untuk melakukan sedikit pekerjaan atau menggunakan kerangka kerja yang telah melakukannya dengan baik. Dalam arsitektur yang ideal, Anda tidak akan memperhatikan apakah koneksi itu asli atau tidak; pengaturan keamanan Anda akan berfungsi dalam kedua kasus; pengaturan pengelompokan Anda akan tetap berfungsi; perencanaan kapasitas Anda akan tetap berlaku; dan seterusnya.
Satu-satunya keuntungan WebSockets dibandingkan streaming http adalah Anda tidak perlu berusaha "memahami" dan mengurai data yang diterima.
Ini tidak sesederhana membuka aliran HTTP dan duduk santai saat data Anda mengalir selama beberapa menit, jam, atau lebih lama. Klien yang berbeda berperilaku berbeda dan Anda harus mengelolanya. Misalnya beberapa klien akan menyangga data dan tidak merilisnya ke aplikasi sampai beberapa ambang batas terpenuhi. Lebih buruk lagi, beberapa tidak akan meneruskan data ke aplikasi sampai koneksi ditutup.
Jadi jika Anda mengirim banyak pesan ke klien, mungkin aplikasi klien tidak akan menerima data sampai 50 data senilai data telah diterima, misalnya. Itu tidak terlalu real-time.
Meskipun streaming HTTP bisa menjadi alternatif yang layak saat WebSocket tidak tersedia, ini bukanlah obat mujarab. Diperlukan pemahaman yang baik untuk bekerja dengan cara yang kuat di tanah tandus Web dalam kondisi dunia nyata.
Apakah ada perbedaan signifikan lainnya yang saya lewatkan?
Ada satu hal lain yang belum disebutkan, jadi saya akan membahasnya.
Protokol WebSocket dirancang untuk menjadi lapisan transport untuk protokol tingkat yang lebih tinggi. Meskipun Anda dapat mengirim pesan JSON atau yang tidak secara langsung melalui koneksi WebSocket, itu juga dapat membawa protokol standar atau kustom.
Misalnya, Anda dapat melakukan AMQP atau XMPP melalui WebSocket, seperti yang telah dilakukan orang. Jadi klien dapat menerima pesan dari broker AMQP seolah-olah terhubung langsung ke broker itu sendiri (dan dalam beberapa kasus memang demikian).
Atau jika Anda memiliki server yang sudah ada dengan beberapa protokol khusus, Anda dapat memindahkannya melalui WebSocket, sehingga memperluas server back-end tersebut ke Web. Seringkali aplikasi yang sudah ada yang telah dikunci di perusahaan dapat memperluas jangkauannya menggunakan WebSocket, tanpa harus mengubah infrastruktur back-end apa pun.
(Secara alami, Anda ingin dapat melakukan semua itu dengan aman, jadi tanyakan kepada vendor atau penyedia WebSocket.)
Beberapa orang menyebut WebSocket sebagai TCP untuk Web. Karena sama seperti TCP mengangkut protokol tingkat yang lebih tinggi, begitu pula WebSocket, tetapi dengan cara yang kompatibel dengan infrastruktur Web.
Jadi, meskipun mengirim pesan JSON (atau apa pun) secara langsung melalui WebSocket selalu memungkinkan, Anda juga harus mempertimbangkan protokol yang ada. Karena untuk banyak hal yang ingin Anda lakukan, mungkin ada protokol yang sudah dipikirkan untuk melakukannya.
Saya minta maaf jika saya menanyakan kembali atau menggabungkan banyak pertanyaan yang sudah ada di SO menjadi satu pertanyaan, tapi saya hanya ingin memahami semua info yang ada di SO dan web mengenai konsep ini.
Ini adalah pertanyaan yang bagus, dan semua jawabannya sangat informatif!