SSE dan WebSocket

Dalam artikel ini, kami akan membandingkan Peristiwa Dihantar Pelayan (SSE) dan WebSocket, yang kedua-duanya merupakan kaedah yang boleh dipercayai untuk menghantar data. Kami akan menganalisisnya dalam lapan aspek, termasuk arah komunikasi, protokol asas, keselamatan, kemudahan penggunaan, prestasi, struktur mesej, kemudahan penggunaan dan alat ujian. Perbandingan aspek-aspek ini diringkaskan seperti berikut: Kategori Peristiwa Dihantar Pelayan (SSE) WebSocket Arah Komunikasi Sehala Dwi-arah Protokol Pendasar HTTP WebSocket Protocol Keselamatan Sama seperti HTTP Kerentanan keselamatan sedia ada Kemudahan penggunaan Tetapan Tetapan mudah Prestasi kompleks Kelajuan penghantaran mesej pantas Dijejaskan oleh pemprosesan mesej dan pengurusan sambungan Struktur mesej Teks biasa Teks atau binari Kemudahan penggunaan Tersedia secara meluas Keperluan untuk penyepaduan WebSocket Alat ujian menggunakan Posmen dan koleksi Menggunakan JMeter, Gadling, sse-perf, Testable atau k6

Dalam artikel hari ini , saya ingin melihat dengan lebih dekat Lihat Peristiwa Dihantar Pelayan (pendek kata SSE) dan WebSockets. Kedua-duanya adalah kaedah pertukaran data yang terbukti dan baik.

SSE lwn. WebSockets Image

Saya akan mulakan dengan pencirian ringkas kedua-dua alatan ini - apakah ciri-cirinya dan apa yang mereka tawarkan. Saya kemudian akan membandingkannya berdasarkan lapan kategori, yang pada pendapat saya adalah yang paling penting untuk sistem moden.

Kategori adalah seperti berikut:

• Arah Komunikasi

• Protokol Dasar

• Keselamatan

• Kesempurnaan

• Struktur Mesej

• Mudah diterima pakai

Pakaian Kerja

Bertentangan dengan perbandingan saya sebelum ini yang membandingkan REST dan gRPC, saya tidak akan mengisytiharkan sebarang pemenang atau pemberian mata untuk setiap kategori. Sebaliknya, dalam perenggan ringkasan, anda akan menemui sejenis jadual TL;DR. Jadual ini mengandungi perbezaan utama antara kedua-dua teknologi dalam bidang yang dinyatakan di atas.

Mengapa

Tidak seperti REST, kedua-dua SSE dan WebSocket lebih tertumpu kepada kes penggunaan. Dalam kes tertentu (atau kes), fokus utama kedua-dua konsep adalah untuk menyediakan medium komunikasi "masa nyata". Disebabkan tumpuan khusus mereka, mereka kurang popular daripada REST, yang merupakan alat yang lebih umum dan satu saiz untuk semua.

Namun begitu, kedua-dua SSE dan WebSocket menawarkan pelbagai kemungkinan menarik dan lebih baharu sedikit daripada pendekatan REST klasik untuk menyelesaikan masalah.

Pada pendapat saya, adalah baik untuk mengetahui tentang mereka dan mencari sedikit ruang untuk mereka dalam kotak peralatan kami, kerana suatu hari nanti mereka mungkin berguna untuk memberikan anda penyelesaian yang lebih mudah kepada masalah yang agak rumit - Terutama apabila anda memerlukan "sebenar- masa" kemas kini atau apabila aplikasi anda memerlukan pendekatan yang lebih berorientasikan tolak.

Selain membandingkan dan menerangkannya di sini, saya juga ingin menjadikannya lebih popular.

Apakah itu WebSocket?

Ringkasnya, WebSockets ialah protokol komunikasi yang menyediakan komunikasi dua hala antara pelayan dan klien menggunakan satu sambungan TCP berterusan Disebabkan ciri ini, kami tidak perlu sentiasa berkomunikasi dengan pelayan Sebaliknya, data ditukar "secara nyata masa" antara pihak yang berminat. Setiap mesej ialah data binari atau teks Unicode.

Protokol ini telah diseragamkan oleh IETF pada tahun 2011 sebagai RFC 6455. .Protokol WebSocket berbeza daripada HTTP, tetapi kedua-duanya terletak di lapisan 7 model OSI dan bergantung pada TCP pada lapisan 4.

• Protokol ini mempunyai set awalan uniknya sendiri dan berfungsi dengan cara yang sama seperti awalan HTTP "http" dan " https" serupa dengan:

• ws - Menunjukkan bahawa sambungan adalah tidak terjamin menggunakan TLS

wss - Menunjukkan bahawa sambungan dijamin oleh TLS

Selain itu, sambungan WebSocket (ws) tidak selamat tidak boleh dibuka dari tapak selamat (https) ) tidak boleh dibuka daripada tapak tidak selamat (http

Sebaliknya, WebSocket direka untuk berfungsi pada port HTTP 443 dan 80 dan menyokong konsep HTTP seperti proksi dan pengantaraan tingkatkan protokol daripada HTTP kepada WebSocket

Kelemahan terbesar WebSocket sebagai protokol ialah WebSocket tidak tertakluk kepada dasar asal yang sama, yang mungkin membuat serangan seperti CSRF lebih mudah Apakah itu Acara Dihantar Pelayan? ialah teknologi yang membolehkan pelayan web menghantar kemas kini ke halaman web, serupa dengan WebSocket, menggunakan sambungan HTTP jangka panjang tunggal untuk menghantar data "dalam masa nyata". sejak tahun 2004. Pelaksanaan pertama SSE telah dilaksanakan oleh pasukan Opera pada tahun 2006.

Kebanyakan penyemak imbas moden menyokong SSE - Sokongan Microsoft Edge telah ditambahkan pada Januari 2020. Ia juga boleh memanfaatkan sepenuhnya HTTP/2, yang menghapuskan salah satu masalah terbesar dengan SSE, dihapuskan dengan berkesan oleh HTTP/1.1.

Secara definisi, acara yang dihantar pelayan mempunyai dua blok binaan asas:

EventSource - antara muka berdasarkan spesifikasi WHATWG dan dilaksanakan oleh penyemak imbas, yang membolehkan pelanggan (dalam kes ini, penyemak imbas) melanggan acara.

Penstriman Acara - Protokol yang menerangkan format teks biasa standard untuk acara dihantar pelayan yang mesti diikuti oleh pelanggan EventSource untuk memahami dan menyebarkannya.

Mengikut spesifikasi, acara boleh membawa data teks sewenang-wenangnya, ID pilihan, dipisahkan oleh baris baharu. Mereka juga mempunyai jenis MIME unik mereka sendiri: teks/event-strim

Malangnya, acara yang dihantar pelayan sebagai teknologi direka untuk hanya menyokong mesej berasaskan teks, walaupun kami boleh menghantar acara dengan format tersuai, tetapi akhirnya Mesej itu mesti. menjadi rentetan berkod UTF-8.

Lebih penting lagi, SSE menyediakan dua ciri yang sangat menarik:

• Auto-sambung semula - Jika pelanggan terputus sambungan secara tidak sengaja, EventSource akan cuba menyambung semula secara berkala.

• Sambung Strim Automatik - EventSource secara automatik mengingati ID mesej yang terakhir diterima dan secara automatik menghantar pengepala Last-Event-ID apabila cuba menyambung semula.

Perbandingan

Arah Komunikasi

Mungkin perbezaan terbesar antara keduanya ialah gaya komunikasi mereka.

• SSE hanya menyediakan komunikasi sehala - acara hanya boleh dihantar dari pelayan kepada pelanggan.

• WebSockets menyediakan komunikasi dua hala yang lengkap, membolehkan pihak yang berminat bertukar maklumat dan bertindak balas terhadap sebarang peristiwa di kedua-dua belah pihak.

Saya akan mengatakan bahawa kedua-dua pendekatan mempunyai kebaikan dan keburukan mereka, dan setiap satu mempunyai set kes penggunaan khusus tersendiri.

Di satu pihak, jika anda hanya perlu menolak aliran yang dikemas kini secara berterusan kepada pelanggan, maka SSE akan menjadi pilihan yang lebih sesuai. Sebaliknya, jika anda perlu bertindak balas terhadap salah satu peristiwa ini dalam apa jua cara, maka WebSocket mungkin lebih berfaedah.

Secara teori (dan amalan) semua yang boleh dilakukan dengan SSE juga boleh dilakukan dengan WebSocket, tetapi kami sedang memasuki bidang seperti sokongan, kesederhanaan penyelesaian atau keselamatan.

Saya akan menerangkan semua bidang ini dan banyak lagi dalam perenggan di bawah. Selain itu, menggunakan WebSocket berkemungkinan menjadi keterlaluan yang teruk dalam semua kes, manakala penyelesaian berasaskan SSE mungkin lebih mudah untuk dilaksanakan.

Protokol Dasar

Ini adalah satu lagi perbezaan besar antara kedua-dua teknologi.

• SSE bergantung sepenuhnya pada HTTP dan menyokong HTTP/1.1 dan HTTP/2.

• Sebaliknya, WebSocket menggunakan protokol tersuainya sendiri - secara mengejutkan - protokol WebSocket.

Mengenai SSE, memanfaatkan HTTP/2 menyelesaikan salah satu masalah utama SSE - had sambungan selari maksimum. HTTP/1.1 mengehadkan bilangan sambungan selari mengikut spesifikasinya.

Tingkah laku ini boleh menyebabkan masalah yang dipanggil head-of-line blocking. HTTP/2 menyelesaikan masalah ini dengan memperkenalkan pemultipleksan, sekali gus menyelesaikan sekatan HOL pada lapisan aplikasi. Walau bagaimanapun, penyekatan kepala baris masih boleh berlaku pada peringkat TCP.

Mengenai protokol WebSocket, saya telah menyebutnya secara terperinci dalam baris di atas. Di sini saya hanya mengulangi perkara yang paling penting. Protokol ini berbeza sedikit daripada HTTP klasik, walaupun pengepala Peningkatan HTTP digunakan untuk memulakan sambungan WebSocket dan menukar protokol komunikasi dengan berkesan.

Namun begitu, ia juga menggunakan protokol TCP sebagai asasnya dan serasi sepenuhnya dengan HTTP. Kelemahan terbesar protokol WebSocket ialah keselamatannya.

Mudah

Secara amnya, menyediakan penyepaduan berasaskan SSE adalah lebih mudah daripada penyepaduan WebSocketnya. Sebab paling penting di sebalik ini adalah sifat komunikasi yang digunakan oleh teknologi tertentu.

Pendekatan sehala SSE dan model tolaknya menjadikannya lebih mudah pada tahap konsep. Gabungkan ini dengan penyambungan semula automatik dan strim sokongan kesinambungan di luar kotak, dan kami mempunyai lebih sedikit untuk ditangani.

Dengan semua ciri ini, SSE juga boleh dianggap sebagai satu cara untuk mengurangkan gandingan antara pelanggan dan pelayan. Pelanggan hanya perlu mengetahui titik akhir yang menjana acara.

Walau bagaimanapun, dalam kes ini, pelanggan hanya boleh menerima mesej, jadi jika kita ingin menghantar apa-apa jenis maklumat kembali ke pelayan, kita memerlukan medium komunikasi lain, yang boleh membuat perkara menjadi sangat rumit.

Setakat WebSocket, keadaannya agak rumit. Pertama, kita perlu mengendalikan peningkatan sambungan daripada protokol HTTP kepada protokol WebSockets. Walaupun ini adalah perkara yang paling mudah untuk dilakukan, ia satu lagi perkara yang perlu kita ingat.

Masalah kedua datang dari sifat dua arah WebSocket. Kami perlu mengurus keadaan sambungan tertentu dan mengendalikan semua kemungkinan pengecualian yang mungkin berlaku semasa memproses mesej. Sebagai contoh, bagaimana jika memproses salah satu mesej membuang pengecualian pada bahagian pelayan?

Langkah seterusnya ialah menangani penyambungan semula, untuk WebSockets kita perlu mengendalikannya sendiri.

Terdapat juga isu yang menjejaskan kedua-dua teknologi - sambungan jangka panjang.

Kedua-dua teknologi memerlukan mengekalkan sambungan terbuka jangka panjang untuk menghantar aliran acara yang berterusan.

Menguruskan sambungan sedemikian (terutamanya pada skala) boleh menjadi satu cabaran kerana kita cepat kehabisan sumber. Selain itu, mereka mungkin memerlukan konfigurasi khas, seperti tamat masa lanjutan, dan lebih terdedah kepada sebarang isu sambungan rangkaian.

Keselamatan

Tiada apa-apa yang istimewa tentang keselamatan dari segi SSE, kerana ia menggunakan protokol HTTP lama biasa sebagai medium pengangkutan. Semua kebaikan dan keburukan HTTP standard digunakan untuk SSE, semudah itu.

Sebaliknya, keselamatan adalah salah satu kelemahan terbesar bagi keseluruhan protokol WebSocket. Pertama, tiada perkara seperti "Dasar Asal yang Sama", jadi tiada sekatan di mana kami ingin menyambung melalui WebSocket.

Malah terdapat jenis serangan khusus yang direka untuk mengeksploitasi kelemahan ini, iaitu rampasan WebSocket asal silang. Jika anda ingin mendalami topik Dasar Asal yang Sama dan WebSocket, berikut ialah artikel yang mungkin menarik minat anda. Selain daripada itu, tiada lubang keselamatan khusus protokol dalam WebSocket.

Saya akan mengatakan bahawa dalam kedua-dua kes, semua piawaian dan amalan keselamatan terbaik terpakai, jadi berhati-hati apabila melaksanakan penyelesaian anda.

Prestasi

Saya akan katakan kedua-dua teknologi adalah sama dari segi prestasi. Kedua-dua teknologi sememangnya tidak mempunyai had prestasi teori.

Walau bagaimanapun, saya akan mengatakan bahawa dari segi bilangan mesej yang dihantar sesaat, SSE boleh menjadi lebih pantas kerana ia mengikut prinsip api-dan-lupa. WebSocket juga perlu mengendalikan respons daripada pelanggan.

Satu-satunya perkara yang boleh menjejaskan prestasi kedua-duanya ialah pelanggan asas yang kami gunakan dalam aplikasi kami dan pelaksanaannya. Semaknya, baca dokumentasi, jalankan ujian tekanan tersuai, dan anda mungkin mendapat cerapan yang sangat menarik tentang alat yang anda gunakan atau sistem secara keseluruhan.

Struktur Mesej

Struktur mesej mungkin merupakan salah satu perbezaan terpenting antara protokol.

Seperti yang saya nyatakan di atas, SSE ialah protokol teks biasa. Kami boleh menghantar mesej dengan format dan kandungan yang berbeza, tetapi akhirnya semuanya berakhir dalam teks yang dikodkan UTF-8. Tiada kemungkinan format kompleks atau data binari.

WebSocket, sebaliknya, boleh mengendalikan kedua-dua mesej teks dan binari. Membolehkan kami menghantar imej, audio atau hanya fail biasa. Perlu diingat bahawa pemprosesan fail boleh mempunyai overhed yang besar.

Mudah Digunapakai

Di sini, kedua-dua teknologi berada pada tahap yang hampir sama. Dari perspektif SSE, terdapat banyak alat untuk menambah WebSocket dan sokongan acara yang dihantar oleh pelayan (klien dan pelayan).

Kebanyakan bahasa pengaturcaraan yang mantap mempunyai berbilang perpustakaan sedemikian. Tidak perlu memasukkan terlalu banyak butiran. Saya menyediakan jadual, meringkaskan perpustakaan asas, dan menambah sokongan WebSockets dan SSE.

Java:

Spring SSE/WebSockets

Quarkus SSE/WebSockets

Scala:

Suka SSE/WebSockets

Sumber Main/WebScript

Total.js SSE/WebSocekts

Soket . io

Python

                                                                                                                                                                                              . Sudah tentu, ini hanyalah sampel yang sangat kecil daripada semua perpustakaan; Masalah sebenar mungkin mencari yang paling sesuai untuk kes penggunaan khusus anda.

Alat

Pengujian automatik

Setahu saya, tiada alat ujian automatik untuk SSE atau WebSockets. Walau bagaimanapun, kefungsian yang serupa boleh dicapai dengan agak mudah menggunakan Posmen dan koleksi.

Posmen menyokong acara dan WebSocket yang dihantar pelayan. Dengan menggunakan beberapa sihir yang diperoleh daripada koleksi Posmen, anda boleh menyediakan satu set ujian untuk mengesahkan ketepatan titik akhir anda.

Performance Testing

Untuk ujian prestasi, anda boleh menggunakan JMeter atau Gadling. Setakat yang saya tahu, ini adalah dua alat ujian prestasi keseluruhan yang paling matang. Sudah tentu, mereka semua juga menyokong SSE (JMeter, Gadling) dan WebSockets (JMeter, Gadling).

Terdapat alat lain seperti sse-perf (SSE sahaja), Boleh Diuji atau k6 (WebSockets sahaja).

Di antara semua alat ini, saya secara peribadi mengesyorkan Gattle atau k6. Kedua-duanya nampaknya mempunyai pengalaman pengguna yang terbaik dan paling sesuai untuk pengeluaran.

Dokumentasi

Sehingga tiada alat khusus untuk mendokumentasikan SSE atau WebSocket. Sebaliknya, terdapat alat yang dipanggil AsyncAPI yang boleh digunakan untuk kedua-dua konsep dengan cara ini.

Malangnya, OpenAPI nampaknya tidak menyokong SSE atau WebSockets.

Ringkasan

Seperti yang dijanjikan, ringkasan akan menjadi cepat dan mudah - lihat di bawah.

Jadual perbandingan antara WebSockets dan SSE

Saya rasa jadual di atas ialah ringkasan topik dan keseluruhan artikel yang baik dan padat.

Perbezaan paling penting ialah arah komunikasi, kerana ia menentukan kemungkinan kes penggunaan untuk teknologi tertentu. Ia mungkin akan mempunyai impak terbesar dalam memilih satu daripada yang lain.

Struktur mesej juga boleh menjadi kategori yang sangat penting apabila memilih kaedah komunikasi tertentu. Membenarkan hanya mesej teks biasa adalah kelemahan yang sangat penting dalam acara yang dihantar pelayan.

Atas ialah kandungan terperinci SSE dan WebSocket. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!