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.