HTTP / 2 spesifikasyonunu okumayı bitirdikten sonra, HTTP / 2'nin çoğu kullanım durumu için eski websockets yaptığını düşünüyorum, ancak belki de hepsi değil.
PUSH_PROMISE(sözlü olarak sunucu push olarak bilinir) burada sorun değildir. Bu sadece bir performans optimizasyonu.
Bir tarayıcıdaki Websockets için ana kullanım durumu, verilerin çift yönlü akışını sağlamaktır. Bu yüzden, OP'nin sorusunun HTTP / 2'nin tarayıcıda çift yönlü akışı etkinleştirmek için daha iyi bir iş yapıp yapmadığını düşünüyorum ve evet, öyle olduğunu düşünüyorum.
Her şeyden önce, bu ise iki di. Yalnızca akışlar bölümüne giriş bölümünü okuyun :
"Akış", bir HTTP / 2 bağlantısı içinde istemci ve sunucu arasında değiş tokuş edilen bağımsız, çift yönlü bir kare dizisidir. Akışların birkaç önemli özelliği vardır:
Tek bir HTTP / 2 bağlantısı, aynı anda birden çok akıştan uç nokta serpiştirme çerçeveleri içeren, aynı anda birden çok akış içerebilir.
Akışlar tek taraflı olarak oluşturulabilir ve kullanılabilir veya istemci veya sunucu tarafından paylaşılabilir.
Akışlar her iki uç noktadan da kapatılabilir.
Gibi Makaleler bu (başka yanıtında bağlantılı) HTTP / 2 bu yönü hakkında yanlış. Onlar bidi değil derler. Bakın, HTTP / 2 ile gerçekleşemeyen bir şey var: Bağlantı açıldıktan sonra, sunucu normal bir akış başlatamaz, sadece bir push akışı başlatamaz. Ancak istemci bir istek göndererek bir akışı açtığında, her iki taraf da DATA çerçevelerini her zaman kalıcı bir sokete gönderebilir - tam bidi.
Bu, websockets'ten çok farklı değildir: istemcinin, sunucudan da veri gönderebilmesi için bir websocket yükseltme isteği başlatması gerekir.
En büyük fark, websockets'ten farklı olarak, HTTP / 2'nin kendi çoğullama semantiğini tanımlamasıdır: akışların tanımlayıcıları nasıl elde ettiği ve çerçevelerin üzerinde bulundukları akışın kimliğini nasıl taşıdığı. HTTP / 2 ayrıca akışlara öncelik vermek için akış kontrolü semantiğini de tanımlar. Bu, bidi'nin gerçek dünyadaki uygulamalarının çoğunda önemlidir.
(Bu yanlış makale aynı zamanda Websocket standardının çoğullama olduğunu söylüyor. Hayır, yok. Bunu bulmak gerçekten zor değil, sadece Websocket RFC 6455'i açın ve ⌘-F tuşlarına basın ve "multiplex" yazın.
Protokolün genişletilebilir olması amaçlanmıştır; gelecekteki sürümlerde muhtemelen çoğullama gibi ek kavramlar sunulacaktır.
Websocket multiplexing için 2013 taslak uzantısı olduğunu göreceksiniz. Ancak hangi tarayıcıların (varsa) bunu desteklediğini bilmiyorum. SPA web uygulamamı bu uzantının arkasına oluşturmaya çalışmam, özellikle HTTP / 2 ile destek asla gelmeyebilir).
Çoğullama, bidi için bir web soketini her açtığınızda normal olarak kendiniz yapmanız gereken bir şeydir, örneğin, reaktif olarak güncellenen tek bir sayfa uygulamasına güç vermek için. Bir kez ve herkes için özen HTTP / 2 spec, sevindim.
HTTP / 2'nin neler yapabileceğini bilmek istiyorsanız, gRPC'ye bakın. gRPC, HTTP / 2 genelinde uygulanır. Özellikle gRPC'nin sunduğu yarı ve tam çift yönlü akış seçeneklerine bakın. (GRPC'nin şu anda tarayıcılarda çalışmadığını, ancak bunun nedeni aslında tarayıcıların (1) HTTP / 2 çerçevesini istemci javascriptine göstermediği ve (2) genellikle gRPC spesifikasyonu.)
Web soketlerinin hala nerede bir yeri olabilir? Büyük olan sunucu-> tarayıcı ikili verileri itti. HTTP / 2, sunucu-> tarayıcı tarafından itilen ikili verilere izin verir, ancak tarayıcı JS'de gösterilmez. Ses ve video karelerini itmek gibi uygulamalar için bu, web soketlerini kullanmak için bir nedendir.
Düzenleme: 17 Ocak 2020
Zamanla bu cevap yavaş yavaş zirveye yükseldi (bu iyidir, çünkü bu cevap aşağı yukarı doğrudur). Bununla birlikte, çeşitli nedenlerle doğru olmadığını söyleyen ara sıra yorumlar vardır, genellikle PUSH_PROMISEtek bir sayfa uygulamasında mesaj odaklı sunucu -> istemci pushu hakkında bazı karışıklıklar veya gerçekte nasıl tüketileceği ile ilgili . Ve bir tarayıcıda sunucu tarafından itilen ikili veri olan web soketleri için bir kullanım durumu vardır. JSON dahil olmak üzere metin verileri için web soketleri kullanmayın, SSE kullanın.
Özetlemek gerekirse: HTTP / 2 Protokolü tam çift yönlüdür. Ancak, modern web tarayıcıları çerçeve yönelimli HTTP / 2 protokolünü JavaScript'e maruz bırakmaz . Bununla birlikte, bir HTTP / 2 bağlantısı üzerinden aynı kaynaktan birden fazla istekte bulunursanız, kaputun altında tüm bu trafik bir bağlantıda çoğullıyor (ve bu bizim umurumuz!).
Dolayısıyla, gerçek zamanlı bir sohbet uygulaması oluşturmanız gerekiyorsa, diyelim ki, sohbet odasındaki açık bağlantıları olan tüm istemcilere yeni sohbet mesajları yayınlamanız gerekiyorsa, bunu web soketleri olmadan yapabilirsiniz (ve muhtemelen yapmalısınız).
İletileri aşağı itmek için Sunucu Gönderilmiş Etkinlikler'i ve istekleri göndermek için Getir api'sini kullanırsınız. Sunucudan Gönderilen Olaylar (SSE), iletiye yönelik bir sunucudan istemciye akış sunan az bilinen ancak iyi desteklenen bir API'dir. İstemci JavaScript'e benzemese de, tarayıcınızın altında (HTTP / 2'yi destekliyorsa) tüm bu mesajları çoğaltmak için tek bir TCP bağlantısını yeniden kullanır. Hiçbir verimlilik kaybı yoktur ve aslında websockets üzerinden bir kazançtır. Birden fazla akışa mı ihtiyacınız var? Birden fazla EventSources açın! Sizin için otomatik olarak çoklanırlar.
Daha fazla kaynak verimli olmanın ve websocket el sıkışmasından daha az başlangıç gecikmesine sahip olmanın yanı sıra, Sunucu Gönderilen Olaylar otomatik olarak geri düşüp HTTP / 1.1 üzerinde çalıştıkları güzel bir özelliğe sahiptir. Ancak bir HTTP / 2 bağlantınız olduğunda inanılmaz derecede iyi çalışırlar.
İşte reaktif olarak güncellenen SPA'yı gerçekleştirmenin gerçek dünya örneği ile iyi bir makale .