Saya telah membaca banyak posting di SO dan web mengenai kata kunci dalam judul pertanyaan saya dan belajar banyak dari mereka. Beberapa pertanyaan yang saya baca terkait dengan tantangan implementasi tertentu sementara yang lain berfokus pada konsep umum. Saya hanya ingin memastikan bahwa saya memahami semua konsep dan alasan mengapa teknologi X ditemukan di atas teknologi Y dan seterusnya. Jadi begini:
Http Polling: Pada dasarnya AJAX, menggunakan XmlHttpRequest.
Http Long Polling: AJAX tetapi server menahan respons kecuali server memiliki pembaruan, segera setelah server memiliki pembaruan, ia mengirimkannya dan kemudian klien dapat mengirim permintaan lain. Kerugiannya adalah data header tambahan yang perlu dikirim bolak-balik menyebabkan overhead tambahan.
Streaming Http: Mirip dengan polling panjang tetapi server merespons dengan header dengan "Transfer Encoding: chunked" dan karenanya kami tidak perlu memulai permintaan baru setiap kali server mengirimkan beberapa data (dan karenanya menghemat overhead header tambahan). Kekurangannya di sini adalah kita harus "memahami" dan mencari tahu struktur data untuk membedakan antara beberapa potongan yang dikirim oleh server.
Java Applet, Flash, Silverlight: Mereka menyediakan kemampuan untuk terhubung ke server soket melalui tcp / ip tetapi karena mereka adalah plugin, pengembang tidak ingin bergantung padanya.
WebSockets: mereka adalah API baru yang mencoba mengatasi kekurangan metode di atas dengan cara berikut:
- 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.
- Satu-satunya keuntungan WebSockets dibandingkan streaming http adalah Anda tidak perlu berusaha "memahami" dan mengurai data yang diterima.
- Satu-satunya keuntungan WebSockets dibandingkan Long Polling adalah penghapusan ukuran header ekstra & pembukaan dan penutupan koneksi soket untuk permintaan.
Apakah ada perbedaan signifikan lainnya yang saya lewatkan? 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.
Terima kasih!
sumber
Jawaban:
Ada lebih banyak perbedaan daripada yang telah Anda identifikasi.
Dupleks / arah:
Untuk meningkatkan latensi (perkiraan):
CORS (dukungan lintas sumber):
Data biner asli (array yang diketik, blob):
Bandwidth dalam mengurangi efisiensi:
Dukungan perangkat seluler:
Kompleksitas penggunaan Javascript (dari yang paling sederhana hingga yang paling rumit). Ukuran kompleksitas memang agak subjektif.
Perhatikan juga bahwa ada proposal W3C untuk standarisasi streaming HTTP yang disebut Server-Sent Events . Saat ini cukup awal dalam evolusinya dan dirancang untuk menyediakan API Javascript standar dengan kesederhanaan yang sebanding dengan WebSockets.
sumber
Beberapa jawaban bagus dari orang lain yang mencakup banyak hal. Ini sedikit tambahan.
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.
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.
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.
Ini adalah pertanyaan yang bagus, dan semua jawabannya sangat informatif!
sumber
(StackOverflow membatasi ukuran tanggapan komentar, jadi saya harus menjawab di sini daripada sebaris.)
Itu poin yang bagus. Untuk memahami ini, pikirkan tentang skenario HTTP tradisional ... Bayangkan sebuah browser membuka halaman web, jadi ia meminta http://example.com , katakanlah. Server merespons dengan HTTP yang berisi HTML untuk halaman tersebut. Kemudian browser melihat bahwa ada sumber daya di halaman tersebut, jadi browser mulai meminta file CSS, file JavaScript, dan gambar tentunya. Mereka semua adalah file statis yang akan sama untuk semua klien yang memintanya.
Beberapa proxy akan menyimpan sumber daya statis sehingga permintaan berikutnya dari klien lain bisa mendapatkan sumber daya statis tersebut dari proxy, daripada harus kembali ke server web pusat untuk mendapatkannya. Ini adalah caching, dan ini merupakan strategi yang bagus untuk memindahkan permintaan dan pemrosesan dari layanan pusat Anda.
Jadi klien # 1 meminta http://example.com/images/logo.gif , misalnya. Permintaan itu melewati proxy sampai ke server web pusat, yang menyajikan logo.gif. Saat logo.gif melewati proxy, proxy akan menyimpan gambar itu dan mengaitkannya dengan alamat http://example.com/images/logo.gif .
Ketika klien # 2 datang dan juga meminta http://example.com/images/logo.gif , proxy dapat mengembalikan gambar dan tidak perlu komunikasi kembali ke server web di tengah. Ini memberikan respons yang lebih cepat kepada pengguna akhir, yang selalu bagus, tetapi juga berarti lebih sedikit beban di tengah. Itu bisa berarti mengurangi biaya perangkat keras, mengurangi biaya jaringan, dll. Jadi itu hal yang baik.
Masalah muncul saat logo.gif diperbarui di server web. Proksi akan terus menampilkan gambar lama tanpa menyadari bahwa ada gambar baru. Hal ini menyebabkan semua hal di sekitar kedaluwarsa sehingga proxy hanya akan menyimpan gambar dalam cache untuk waktu yang singkat sebelum "kedaluwarsa" dan permintaan berikutnya melewati proxy ke server web, yang kemudian menyegarkan cache proxy. Ada juga solusi yang lebih canggih di mana server pusat dapat mendorong ke cache yang diketahui, dan seterusnya, dan semuanya bisa menjadi sangat canggih.
Bagaimana hal ini terkait dengan pertanyaan Anda?
Anda bertanya tentang streaming HTTP di mana server mengalirkan HTTP ke klien. Tetapi streaming HTTP sama seperti HTTP biasa kecuali Anda tidak berhenti mengirim data. Jika server web menyajikan gambar, HTTP dikirim ke klien yang pada akhirnya berakhir: Anda telah mengirim seluruh gambar. Dan jika Anda ingin mengirim data, itu persis sama, tetapi server hanya mengirim untuk waktu yang sangat lama (seperti gambar yang sangat besar, katakanlah) atau bahkan tidak pernah selesai.
Dari sudut pandang proxy, ini tidak dapat membedakan antara HTTP untuk sumber daya statis seperti gambar, atau data dari streaming HTTP. Dalam kedua kasus tersebut, klien membuat permintaan ke server. Proksi mengingat permintaan itu dan juga tanggapannya. Saat permintaan itu masuk lagi, proxy menyajikan respons yang sama.
Jadi, jika klien Anda membuat permintaan untuk harga saham, katakanlah, dan mendapat respons, maka klien berikutnya dapat membuat permintaan yang sama dan mendapatkan data yang disimpan dalam cache. Mungkin bukan yang Anda inginkan! Jika Anda meminta harga saham, Anda menginginkan data terbaru, bukan?
Jadi itu masalah.
Ada trik dan solusi untuk menangani masalah seperti itu, memang benar. Jelas Anda bisa mendapatkan streaming HTTP untuk bekerja karena itu digunakan hari ini. Semuanya transparan bagi pengguna akhir, tetapi orang yang mengembangkan dan memelihara arsitektur tersebut harus melewati rintangan dan membayar harga. Ini menghasilkan arsitektur yang terlalu rumit, yang berarti lebih banyak perawatan, lebih banyak perangkat keras, lebih banyak kompleksitas, lebih banyak biaya. Ini juga berarti pengembang sering kali harus peduli tentang sesuatu yang seharusnya tidak mereka lakukan ketika mereka seharusnya hanya berfokus pada aplikasi, GUI, dan logika bisnis - mereka tidak perlu khawatir tentang komunikasi yang mendasarinya.
sumber
HTTP membatasi jumlah koneksi yang dapat dimiliki klien dengan server menjadi 2 (meskipun hal ini dapat dikurangi dengan menggunakan subdomain) dan IE telah dikenal untuk menegakkannya dengan penuh semangat. Firefox dan Chrome mengizinkan lebih banyak (walaupun saya tidak ingat persis berapa banyak). Ini mungkin tidak tampak seperti masalah besar tetapi jika Anda menggunakan 1 koneksi terus-menerus untuk pembaruan waktu nyata, semua permintaan lainnya harus mengalami hambatan melalui koneksi HTTP lainnya. Dan ada masalah memiliki lebih banyak koneksi terbuka dari klien membuat lebih banyak beban di server.
WebSockets adalah protokol berbasis TCP dan dengan demikian tidak mengalami batas koneksi tingkat HTTP ini (tetapi, tentu saja, dukungan browser tidak seragam).
sumber