Apakah HTTP / 2 membuat websockets menjadi usang?

268

Saya belajar tentang protokol HTTP / 2. Ini adalah protokol biner dengan bingkai pesan kecil. Ini memungkinkan stream multiplexing melalui koneksi TCP tunggal. Secara konsep sepertinya sangat mirip dengan WebSockets.

Apakah ada rencana untuk menghapus websockets dan menggantinya dengan semacam permintaan HTTP / 2 tanpa header dan pesan push yang diprakarsai oleh server? Atau akankah WebSockets melengkapi HTTP / 2?

websocket http2 vbezhenar
sumber
Saya pikir jawaban yang diterima benar, websockets masih merupakan solusi yang lebih disukai untuk aplikasi web untuk berkomunikasi dengan server dua arah termasuk pesan yang didorong server. HTTP digunakan untuk lebih dari sekadar peramban dan ketika klien dan server dapat menggunakan API tingkat rendah, mereka tidak memerlukan soket web. Masih kebanyakan orang menggunakan HTTP untuk aplikasi web dan sebagian besar khawatir tentang API yang terpapar JavaScript. Jika moderator berpikir bahwa jawaban yang diterima harus berbeda, saya tidak menentangnya karena pertanyaan ini tampaknya menghasilkan banyak pandangan dan pendapat saya mungkin salah.
vbezhenar

Jawaban:

162

Dari apa yang saya mengerti HTTP / 2 bukanlah pengganti untuk websocket tetapi bertujuan untuk membakukan protokol SPDY.

Dalam HTTP / 2, server-push digunakan di belakang layar untuk meningkatkan pemuatan sumber daya oleh klien dari browser. Sebagai pengembang, Anda tidak terlalu peduli tentang itu selama pengembangan Anda. Namun, dengan Websocket, pengembang diizinkan untuk menggunakan API yang dapat mengkonsumsi dan mendorong pesan dengan koneksi dupleks-penuh yang unik.

Ini bukan hal yang sama, dan mereka harus saling melengkapi.

Guillaume D.
sumber
3
Terima kasih Guillaume atas jawaban Anda. Namun saya bertanya-tanya apakah Anda (atau seseorang) dapat menambahkan beberapa referensi dari spesifikasi HTTP / 2. Apa yang saya baca dari blog dan sebagainya - dengan HTTP / 2 ada komunikasi dua arah yang benar?
Martin Meeser
3
Tidak yakin spec HTTP / 2 adalah tempat yang tepat untuk memberikan detail tentang asal-usul HTTP / 2 dan bagaimana perbedaannya dari websocket. Namun, Anda dapat dengan mudah melihat bahwa dengan HTTP / 2 kami menggunakan komunikasi bidirectionnal: goo.gl/IJVxWS (halaman 6 dan 13)
Guillaume D.
27
HTTP / 2 memang bidirectional tetapi tidak simetris, artinya hanya klien yang dapat mengirim permintaan yang tepat dan server dapat mengirim respons dan permintaan janji (push). Ini membuat websockets berbeda dalam arti bahwa kedua belah pihak lebih "sama" dalam hal apa yang mereka boleh kirim / terima.
George Antoniadis
3
Ada podcast yang sangat baik di Radio Rekayasa Perangkat Lunak IEEE tentang asal-usul HTTP2. Saya pikir ini dia: secradio.net/2015/07/episode-232-mark-nottingham-on-http2
Max Murphy
2
jawaban serupa dengan rasional lengkap dapat ditemukan dalam artikel InfoQ ini di sini: infoq.com/articles/websocket-and-http2-coexist
mantrid
151

Setelah baru saja selesai membaca spec HTTP / 2 , saya pikir HTTP / 2 memang tidak cocok untuk kebanyakan kasus penggunaan, tetapi mungkin tidak semua.

PUSH_PROMISE(bahasa sehari-hari dikenal sebagai server push) bukan masalah di sini. Itu hanya optimasi kinerja.

Kasus penggunaan utama untuk Websockets di browser adalah untuk mengaktifkan streaming dua arah data. Jadi, saya pikir pertanyaan OP menjadi apakah HTTP / 2 melakukan pekerjaan yang lebih baik untuk mengaktifkan streaming dua arah di browser, dan saya pikir ya, ya.

Pertama-tama, itu adalah bi-di. Cukup baca pengantar untuk bagian stream :

"Stream" adalah urutan frame dua arah yang independen dan dipertukarkan antara klien dan server dalam koneksi HTTP / 2. Streaming memiliki beberapa karakteristik penting:

Koneksi HTTP / 2 tunggal dapat berisi beberapa stream terbuka secara bersamaan, dengan frame interleaving endpoint dari beberapa stream.

Streaming dapat dibuat dan digunakan secara sepihak atau dibagikan oleh klien atau server.

Streaming dapat ditutup dengan titik akhir mana pun.

Artikel seperti ini (ditautkan dengan jawaban lain) salah tentang aspek HTTP / 2 ini. Mereka bilang itu bukan bidi. Lihat, ada satu hal yang tidak dapat terjadi dengan HTTP / 2: Setelah koneksi dibuka, server tidak dapat memulai stream biasa, hanya push stream. Tetapi begitu klien membuka aliran dengan mengirimkan permintaan, kedua belah pihak dapat mengirim frame DATA melalui soket persisten kapan saja - bidi penuh.

Itu tidak jauh berbeda dari soket web: klien harus memulai permintaan upgrade websocket sebelum server dapat mengirim data juga.

Perbedaan terbesar adalah bahwa, tidak seperti soket web, HTTP / 2 mendefinisikan semantik multipleksnya sendiri: bagaimana stream mendapatkan pengidentifikasi dan bagaimana frame membawa id dari stream mereka berada. HTTP / 2 juga mendefinisikan semantik kontrol aliran untuk memprioritaskan aliran. Ini penting dalam sebagian besar aplikasi bidi di dunia nyata.

(Artikel yang salah itu juga mengatakan bahwa standar Websocket memiliki multiplexing. Tidak, tidak. Tidak terlalu sulit untuk menemukan itu, cukup buka Websocket RFC 6455 dan tekan ⌘-F, dan ketik "multiplex". Setelah Anda membaca

Protokol ini dimaksudkan untuk dapat diperluas; versi mendatang kemungkinan akan memperkenalkan konsep tambahan seperti multiplexing.

Anda akan menemukan bahwa ada 2013 draft extension untuk Websocket multiplexing. Tapi saya tidak tahu browser mana, jika ada, yang mendukungnya. Saya tidak akan mencoba untuk membangun webapp SPA saya di belakang ekstensi itu, terutama dengan HTTP / 2 datang, dukungan mungkin tidak pernah tiba).

Multiplexing adalah hal yang biasanya harus Anda lakukan sendiri setiap kali Anda membuka websocket untuk bidi, misalnya, untuk memberi daya pada aplikasi satu halaman yang diperbarui secara reaktif. Saya senang itu ada di spec HTTP / 2, diurus sekali dan untuk semua.

Jika Anda ingin tahu apa yang bisa dilakukan HTTP / 2, lihat saja gRPC. gRPC diimplementasikan di HTTP / 2. Lihat secara khusus pada opsi streaming dupleks setengah dan penuh yang ditawarkan gRPC. (Perhatikan bahwa gRPC saat ini tidak berfungsi di peramban, tetapi itu sebenarnya karena peramban (1) tidak mengekspos bingkai HTTP / 2 ke javascript klien, dan (2) umumnya tidak mendukung Trailers, yang digunakan dalam spesifikasi gRPC.)

Di mana websockets mungkin masih punya tempat? Yang besar adalah server-> browser mendorong data biner. HTTP / 2 memungkinkan server-> browser mendorong data biner, tetapi itu tidak diekspos di browser JS. Untuk aplikasi seperti mendorong bingkai audio dan video, ini adalah alasan untuk menggunakan soket web.

Sunting: 17 Januari 2020

Seiring waktu, jawaban ini secara bertahap naik ke atas (yang bagus, karena jawaban ini kurang lebih benar). Namun masih ada komentar sesekali yang mengatakan bahwa itu tidak benar karena berbagai alasan, biasanya terkait dengan beberapa kebingungan tentang PUSH_PROMISEatau bagaimana sebenarnya mengkonsumsi server berorientasi pesan -> dorongan klien dalam satu aplikasi halaman. Dan, ada kasus penggunaan untuk soket web di browser, yang merupakan data biner yang didorong server. Untuk data tekstual termasuk JSON, jangan gunakan soket web, gunakan SSE.

Untuk rekap: Protokol HTTP / 2 penuh bi-di. Namun, browser web modern tidak mengekspos protokol HTTP / 2 berorientasi bingkai ke JavaScript . Namun demikian, jika Anda membuat beberapa permintaan ke asal yang sama melalui koneksi HTTP / 2, di bawah tenda semua lalu lintas menjadi multiplexing pada satu koneksi (dan itulah yang kami pedulikan!).

Jadi, jika Anda perlu membangun aplikasi obrolan real-time, katakanlah, di mana Anda perlu menyiarkan pesan obrolan baru ke semua klien di ruang obrolan yang memiliki koneksi terbuka, Anda dapat (dan mungkin harus) melakukan ini tanpa soket web.

Anda akan menggunakan Server-Sent Events untuk mendorong pesan ke bawah dan Ambil api untuk mengirim permintaan ke atas. Server-Sent Events (SSE) adalah API yang sedikit dikenal tetapi didukung dengan baik yang memperlihatkan aliran server-ke-klien yang berorientasi pesan. Meskipun tidak terlihat seperti itu untuk JavaScript klien, di bawah kap browser Anda (jika mendukung HTTP / 2) akan menggunakan kembali koneksi TCP tunggal untuk mengalikan semua pesan tersebut. Tidak ada kerugian efisiensi dan sebenarnya ini merupakan keuntungan dari soket web. Perlu beberapa aliran? Buka beberapa Sumber Event! Mereka akan secara otomatis multiplexing untuk Anda.

Selain lebih hemat sumber daya dan memiliki latensi awal lebih sedikit daripada jabat tangan websocket, Server-Sent Events memiliki properti bagus yang secara otomatis akan mundur dan bekerja melalui HTTP / 1.1. Tetapi ketika Anda memiliki koneksi HTTP / 2 mereka bekerja dengan sangat baik.

Berikut ini adalah artikel yang bagus dengan contoh dunia nyata untuk mencapai pembaruan SPA yang reaktif.

tukang batu
sumber
21
Jawaban ini sebagian tidak setuju dengan yang lain, termasuk yang diterima, dan itu juga jawaban terbaik karena didasarkan pada sumber-sumber langsung.
sudo
7
Saya setuju sepenuhnya dengan jawaban dan komentar ini. HTTP / 2 adalah bidirectional yang terstruktur.
Martin Meeser
3
Sebenarnya jawaban yang benar, pria itu repot-repot memeriksa sumber dan aplikasi dunia nyata (grpc)
Vladimir Akopyan
1
Di websockets, server tidak dapat mulai mendorong byte sewenang-wenang hingga klien memulai permintaan upgrade websocket, tetapi kemudian dapat mendorong kapan saja. Dalam HTTP / 2, server tidak dapat mulai mendorong byte hingga klien memulai koneksi data, tetapi kemudian dapat mendorong byte kapan saja. Apa perbedaan fungsionalnya? Seperti yang telah saya tunjukkan, kemampuan PUSH_PROMISE adalah herring merah. Bukan alasan mengapa HTTP / 2 adalah pengganti soket web. Ini hanya optimasi kinerja kecil ke samping. Ini tidak ada hubungannya dengan jantung HTTP / 2, yang merupakan streaming bidi.
masonk
1
Jawaban ini benar-benar salah. Ini membingungkan banyak aspek sehingga mudah membingungkan. Namun, inti masalahnya adalah bahwa aliran HTTP / 2 "bidi" didorong oleh respons-respons (dan jumlahnya terbatas), sedangkan protokol WebSockets adalah protokol bidi berdasarkan pesan yang benar (bukan berbasis respons-permintaan, kecuali untuk fase jabat tangan). Ini adalah perbedaan besar yang tidak dapat dijembatani hanya dengan salah membaca spesifikasi (karena @masonk tampaknya tidak sengaja telah melakukannya).
Myst
65

Saya katakan Nay ( Websockets tidak usang ).

Masalah pertama dan yang paling sering diabaikan adalah bahwa push HTTP / 2 tidak dapat ditegakkan dan mungkin diabaikan oleh proxy, router, perantara lain atau bahkan browser.

yaitu (dari konsep HTTP2):

Seorang perantara dapat menerima dorongan dari server dan memilih untuk tidak meneruskannya ke klien . Dengan kata lain, bagaimana memanfaatkan informasi yang didorong hingga perantara itu. Sama halnya, perantara mungkin memilih untuk melakukan dorongan tambahan kepada klien, tanpa tindakan apa pun yang dilakukan oleh server.

Karenanya, HTTP / 2 Push tidak dapat menggantikan WebSockets.

Juga, koneksi HTTP / 2 tutup setelah beberapa saat.

Memang benar bahwa standar menyatakan bahwa:

Koneksi HTTP / 2 bersifat persisten. Untuk kinerja terbaik, diharapkan bahwa klien tidak akan menutup koneksi sampai ditentukan bahwa tidak ada komunikasi lebih lanjut dengan server diperlukan (misalnya, ketika pengguna menavigasi jauh dari halaman web tertentu) atau sampai server menutup koneksi.

Tapi...

Server didorong untuk mempertahankan koneksi terbuka selama mungkin tetapi diizinkan untuk mengakhiri koneksi idle jika perlu. Ketika salah satu titik akhir memilih untuk menutup koneksi TCP layer transport, titik akhir yang mengakhiri HARUS mengirimkan frame GOAWAY (Bagian 6.8) sehingga kedua titik akhir dapat dengan andal menentukan apakah frame yang dikirim sebelumnya telah diproses dan dengan anggun menyelesaikan atau menghentikan tugas-tugas tersisa yang diperlukan.

Bahkan jika koneksi yang sama memungkinkan untuk mendorong konten ketika sedang terbuka dan bahkan jika HTTP / 2 menyelesaikan beberapa masalah kinerja yang diperkenalkan oleh HTTP / 1.1 'keep-live' ... Koneksi HTTP / 2 tidak tetap terbuka tanpa batas waktu. .

Halaman web juga tidak dapat memulai kembali koneksi HTTP / 2 setelah ditutup (kecuali kita kembali ke long-pulling, yaitu).

EDIT (2017, dua tahun kemudian)

Implementasi HTTP / 2 menunjukkan bahwa banyak tab / jendela browser membagikan satu koneksi HTTP / 2, artinya pushtidak akan pernah tahu tab / jendela mana yang dimiliki, sehingga tidak dapat digunakan pushsebagai pengganti Websockets.

EDIT (2020)

Saya tidak yakin mengapa orang-orang mulai memilih jawabannya. Jika ada, tahun-tahun sejak jawaban awalnya diposting membuktikan bahwa HTTP / 2 tidak dapat menggantikan WebSockets dan tidak dirancang untuk melakukannya.

Memang, HTTP / 2 dapat digunakan untuk tunnel koneksi WebSocket, tetapi koneksi tunneled ini masih akan memerlukan protokol WebSocket dan mereka akan mempengaruhi cara perilaku wadah HTTP / 2.

Mister
sumber
4
Soket WS juga tidak akan terbuka selamanya. Perbedaannya adalah aliran; HTTP / 2 memberi Anda beberapa aliran aliran yang berarti kontrol aliran pada server sangat berbeda dan seringkali tanpa kunci. WS (sebagai protokol) harus memiliki pemrosesan masuk yang tidak diatur. Kontrol aliran diterapkan lebih tinggi ke tumpukan. Untuk keamanan dan integritas server, HTTP / 2 jauh lebih baik daripada WS.
obligasi
4
@bond, saya setuju bahwa HTTP / 2 memiliki banyak keuntungan sebagai lapisan transport (berbagi satu koneksi di banyak tab browser hanyalah satu contoh). Namun, itu tidak dirancang sebagai lapisan komunikasi . Ini adalah pertanyaan fungsional. Kedua protokol menjawab kebutuhan yang berbeda. yaitu mengimplementasikan sshterminal pada browser sangat mudah saat menggunakan Websockets. Ini akan menjadi sakit kepala total pada HTTP / 2, terutama jika lebih dari satu tab terbuka. Juga, bagaimana jika browser (atau salah satu proxy HTTP / 2) menutup koneksi? Bisakah klien menganggap tidak ada data baru yang tersedia? kita kembali ke tempat pemungutan suara.
Myst
1
Browser dapat dengan mudah menutup koneksi WS Anda. Itulah hidup dengan segala jenis jaringan. Sejujurnya, multiplexing dalam HTTP / 2 adalah berlebihan. Protokolnya benar-benar tidak membutuhkannya. Dengan membuka beberapa aliran, Anda mulai mengalami masalah dengan buffer TCP yang membatasi throughput. Saya setuju dengan Anda bahwa WS lebih baik dalam hal daripada HTTP / 2. Pada dasarnya, WS adalah sesuatu yang membutuhkan banyak kontrol tingkat yang lebih tinggi untuk mencegah pengguna melakukan hal-hal buruk.
obligasi
2
Mengutip Paman Ben (Spider-Man): "Ingat, dengan kekuatan besar datang tanggung jawab besar". Ya, @bond, Anda benar sekali. Soket web, sebagai protokol yang sangat "mentah", memerlukan desain server yang lebih bertanggung jawab. Dan ya, WS dapat ditutup semudah HTTP / 2, tetapi WS mendukung onclosecallback, jadi tidak perlu polling. Adapun multiplexing, saya pikir itu suatu keharusan daripada pilihan. keep-alivegagal dan satu-satunya cara untuk menghindari hit kinerja "first-in-line" adalah dengan mengambil risiko multiplexing. Waktu akan menunjukkan :)
Myst
1
Dari sudut pandang desain server outbound multiplexing adalah masalah yang rumit dan mahal. Ini membutuhkan mekanik IO untuk melakukan jajak pendapat internal yang mahal sekali. Kecuali jika Anda streaming dokumen besar, multiplexing tidak akan berfungsi karena permintaan mungkin akan merespons dan buffering sepenuhnya secara internal sebelum yang kedua bahkan tersedia dan multiplexing gagal dijalankan. RTMP memiliki multiplexing keluar tetapi hanya server Adobe yang melakukannya. Sungguh menakjubkan seberapa dekat HTTP / 2 dengan RTMP.
obligasi
40

Jawabannya adalah tidak. Tujuan antara keduanya sangat berbeda. Bahkan ada RFC untuk WebSocket melalui HTTP / 2 yang memungkinkan Anda untuk membuat beberapa koneksi WebSocket melalui satu pipa HTTP / 2 TCP.

WS over HTTP / 2 akan menjadi permainan konservasi sumber daya dengan mengurangi waktu untuk membuka koneksi baru dan memungkinkan lebih banyak saluran komunikasi tanpa tambahan biaya soket, IRQ lunak, dan buffer.

https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01

obligasi
sumber
Itu luar biasa! Apakah ada contoh publik dari klien Javascript yang telah menerapkan ini? Saya tidak dapat menemukan contoh. Apa yang harus saya lakukan? Apakah ini sumber yang bagus? undertow.io/blog/2015/04/27/An-in-depth-overview-of-HTTP2.html
RaisinBranCrunch
Adakah yang tahu sumber klaim di atas tentang 1) menemukan panjang header, 2) lebih rendah casing nama field?
Pim Heijden
@PimHeijden mendeteksi panjang header di HTTP / 1.x membutuhkan perulangan melalui semua byte mencari penanda akhir 4 byte. Itu sangat mahal. Insensivitas kasus dari nama bidang juga berarti bahwa setiap pencocokan bidang harus dilakukan untuk versi huruf besar dan kecil dari karakter. Ini membutuhkan pengetahuan seluruh rangkaian karakter ke huruf besar dan kecil untuk pemeriksaan. Dalam 2.x Anda dapat menganggap mereka huruf kecil.
obligasi
@RaisinBranCrunch Anda tidak dapat mengontrol semua ini dari Javascript. Peramban melakukan segalanya untuk Anda.
obligasi
@bond Saya saat ini menggunakan HTTP / 2 dengan Nginx, dan proxy_pass untuk mengirim koneksi websocket ke server socket, tetapi ketika saya memiliki satu pengguna membuka banyak tab di situs web, server socket memperlakukannya sebagai beberapa koneksi. Saya akan berasumsi bahwa jika HTTP / 2 adalah koneksi multiplexing melalui satu pipa TCP, server akan memperlakukannya sebagai satu koneksi. Apakah ini salah? Apakah ada cara untuk memverifikasi bahwa server tidak membuat koneksi tambahan yang tidak perlu?
RaisinBranCrunch
23

Nah, mengutip dari artikel InfoQ ini:

Jawabannya jelas tidak, karena alasan sederhana: Seperti yang telah kita lihat di atas, HTTP / 2 memperkenalkan Server Push yang memungkinkan server mengirim sumber daya secara proaktif ke cache klien. Namun, itu tidak memungkinkan untuk mendorong data ke aplikasi klien itu sendiri. Dorongan server hanya diproses oleh browser dan tidak muncul ke kode aplikasi, artinya tidak ada API untuk aplikasi untuk mendapatkan pemberitahuan untuk peristiwa tersebut.

Maka push HTTP2 benar-benar sesuatu antara browser dan server Anda, sementara Websockets benar-benar mengekspos API yang dapat digunakan oleh kedua klien (javascript, jika dijalankan di browser) dan kode aplikasi (berjalan di server) untuk mentransfer data waktu nyata.

Jeet Prakash
sumber
5

Pertukaran pesan dan streaming sederhana (bukan audio, streaming video) dapat dilakukan melalui Http / 2 multiplexing dan WebSockets. Jadi ada beberapa tumpang tindih, tetapi WebSockets memiliki protokol yang mapan, banyak kerangka / API dan overhead header yang lebih sedikit. Inilah artikel yang bagus tentang topik ini .

Dennis R
sumber
2

Akan ada implementasi WebSocket di HTTP / 2. https://tools.ietf.org/html/rfc8441

Dzintars
sumber
Tidak ada tidak akan ... koneksi WebSocket akan terowongan melalui HTTP / 2, tetapi HTTP / 2 tidak akan menggantikan protokol, juga tidak akan menjadi usang.
Myst
@ Tuan Apakah saya mengatakan itu?
Dzintars
2
Tidak, kamu tidak mengatakan itu, benar. Anda menulis bahwa akan ada implementasi WebSocket di HTTP / 2, yang IMHO tampak terlalu pendek dan agak menyesatkan karena perincian penting dihilangkan.
Myst
2

Untuk saat ini April 2020, HTTP / 2 tidak membuat WebSockets usang. Keuntungan terbesar WebSockets dibanding HTTP2 adalah itu

HTTP/2 works only on Browser Level not Application Level

Berarti HTTP / 2 tidak menawarkan JS API seperti WebSockets untuk memungkinkan komunikasi dan mentransfer beberapa jenis JSON atau data lain ke server langsung dari Aplikasi (misalnya Situs Web). Jadi, sejauh yang saya percaya, HTTP / 2 hanya akan membuat WebSockets usang jika mulai menawarkan API seperti WebSockets untuk berbicara dengan server. Hingga versi HTTP 1.1 yang baru saja diperbarui dan lebih cepat.

Airy
sumber
2

Mulai hari ini, tidak.

HTTP / 2, dibandingkan dengan HTTP, memungkinkan Anda mempertahankan koneksi dengan server. Dari sana, Anda dapat memiliki beberapa aliran data sekaligus. Maksudnya adalah Anda dapat mendorong banyak hal pada saat yang bersamaan bahkan tanpa klien memintanya. Misalnya, ketika browser meminta index.html, server mungkin ingin juga mendorong index.cssdan index.js. Peramban tidak memintanya, tetapi server mungkin menyediakannya tanpa diminta karena dapat mengasumsikan Anda akan menginginkannya dalam beberapa detik.

Ini adalah lebih cepat dari HTTP / 1 alternatif mendapatkan index.html, parsing itu, menemukan perlu index.jsdan index.cssdan kemudian membangun 2 permintaan lain untuk file-file. HTTP / 2 memungkinkan server mendorong data yang bahkan belum pernah diminta oleh klien.

Dalam konteks itu, ini mirip dengan WebSocket, tetapi tidak benar-benar secara desain. WebSocket seharusnya memungkinkan komunikasi dua arah yang mirip dengan koneksi TCP, atau koneksi serial. Ini adalah soket di mana keduanya saling berkomunikasi. Juga, perbedaan utama adalah bahwa Anda dapat mengirim paket data sembarang dalam byte mentah, tidak dienkapsulasi dalam protokol HTTP. Konsep header, jalur, string kueri hanya terjadi selama jabat tangan, tetapi WebSocket membuka aliran data.

Perbedaan lainnya adalah Anda mendapatkan lebih banyak akses yang disesuaikan ke WebSocket dalam Javascript, sedangkan dengan HTTP, itu ditangani oleh browser. Yang Anda dapatkan dengan HTTP adalah apa pun yang dapat Anda masukkan XHR/ fetch(). Itu juga berarti browser akan mendapatkan mencegat dan memodifikasi HTTP header tanpa Anda bisa mengendalikannya (misalnya: Origin, Cookies, dll). Juga, apa yang dapat didorong oleh HTTP / 2 dikirim ke browser. Itu berarti JS tidak selalu (jika pernah) mengetahui hal-hal yang didorong. Sekali lagi, masuk akal untuk index.cssdan index.jskarena browser akan menyimpannya, tetapi tidak terlalu banyak untuk paket data.

Itu benar-benar semua dalam nama. HTTP adalah singkatan dari HyperText Transfer Protocol. Kami diarahkan pada konsep mentransfer aset. WebSocket adalah tentang membangun koneksi soket di mana data biner dilewatkan secara dua arah.

Yang tidak kita bahas adalah SSE (Server-Sent Events). Mendorong data ke aplikasi (JS) bukan maksud HTTP / 2, tetapi untuk SSE. SSE semakin diperkuat dengan HTTP / 2. Tapi itu bukan pengganti nyata untuk WebSockets ketika yang penting adalah data itu sendiri, bukan titik akhir variabel yang tercapai. Untuk setiap titik akhir dengan WebSocket aliran data baru dibuat, tetapi dengan SSE itu dibagi antara sesi HTTP / 2 yang sudah ada.

Ringkasan di sini adalah tujuan untuk masing-masing:

  • HTTP - Menanggapi permintaan dengan satu aset
  • HTTP / 2 - Menanggapi permintaan dengan banyak aset
  • SSE - Menanggapi dengan aliran acara teks searah (UTF-8)
  • WebSocket - Membuat aliran data biner dua arah
ShortFuse
sumber