WebSockets ve Sunucu tarafından Gönderilen etkinlikler / EventSource

838

Hem WebSockets hem de Sunucu tarafından Gönderilen Etkinlikler , verileri tarayıcılara aktarabilir. Bana göre rakip teknolojiler gibi görünüyorlar. Onların arasındaki fark ne? Birini diğerinden ne zaman seçersiniz?

html  browser  websocket  server-sent-events 
— Mads Mobæk
kaynak
2
Onları nasıl rakip olarak gördüğünüzden emin değilim. Biri eşzamanlıdır ve gerçek zamanlıya yakın veri xfer için kullanılabilir, diğeri eşzamansızdır ve tamamen farklı bir amaca hizmet eder (sunucu tarafı uygulamasından etkili bir şekilde tost benzeri mesajlar göndermek).
— Brian Driscoll
54
WebSockets iki yönlüdür, sunucuya veri gönderebilir.
— Andre Backlund
13
SSE hakkında gerçekten sevdiğim bir şey, sorun gidermenin kolay olmasıdır ... sadece SSE sunucunuza bir istek açın curl. Sadece HTTP üzerinden bir metin biçimi olduğundan, neler olduğunu görmek kolaydır.
— Sam
7
@BrianDriscoll - asenkron / senkron - hangisi? Bildiğim kadarıyla her ikisi de asenkron transferleri etkinleştirmek?
— Dave Everitt
5
SSE IE üzerinde çalışmıyor, websockets çalışıyor
— Tyler Gillies

Yanıtlar:

978

Web soketleri ve SSE (Sunucu Gönderilen Olaylar) tarayıcılara veri gönderebilir, ancak rakip teknolojiler değildir.

Web soketleri bağlantıları hem tarayıcıya veri gönderebilir hem de tarayıcıdan veri alabilir. Websockets kullanabilen bir uygulamaya iyi bir örnek bir sohbet uygulamasıdır.

SSE bağlantıları yalnızca tarayıcıya veri gönderebilir. Çevrimiçi hisse senedi fiyatları veya zaman çizelgesini veya feed'i güncelleyen twitter'lar, SSE'den yararlanabilecek bir uygulama için iyi örneklerdir.

Uygulamada, SSE ile yapılabilecek her şey Websockets ile de yapılabileceğinden, Websockets çok daha fazla ilgi ve sevgi kazanıyor ve daha birçok tarayıcı WebEckets'i SSE'den daha fazla destekliyor.

Ancak, bazı uygulama türleri için aşırıya kaçabilir ve arka ucun SSE gibi bir protokolle uygulanması daha kolay olabilir.

Ayrıca SSE, yalnızca JavaScript kullanarak yerel olarak desteklemeyen eski tarayıcılara çoklu doldurulabilir. SSE çoklu dolgularının bazı uygulamaları Modernizr github sayfasında bulunabilir .

Sorunlar:

  • SSE, maksimum sekme açık bağlantı sayısında bir sınırlama yaşar; bu, sınır tarayıcı başına ve çok düşük bir sayıya ayarlandığından çeşitli sekmeleri açarken özellikle acı verici olabilir (6). Sorun, Chrome ve Firefox'ta "Düzeltilmeyecek" olarak işaretlendi . Bu sınır tarayıcı + etki alanı başınadır, yani tüm sekmelerde www.example1.com6 SSE bağlantısı ve başka bir 6 SSE bağlantısı açabilirsiniz www.example2.com(teşekkürler Phate).
  • Sadece WS hem ikili verileri hem de UTF-8 iletebilir, SSE UTF-8 ile sınırlıdır. (Chado Nihi'ye teşekkürler).
  • Paket denetimine sahip bazı kurumsal güvenlik duvarları WebSockets (Sophos XG Firewall, WatchGuard, McAfee Web Gateway) ile ilgili sorun yaşıyor.

HTML5Rocks , SSE hakkında bazı iyi bilgilere sahiptir. Bu sayfadan:

Sunucu Tarafından Gönderilen Etkinlikler ve WebSockets

Neden WebSockets üzerinden Sunucudan Gönderilen Olaylar'ı seçtiniz? İyi soru.

SSE'lerin gölgede kalmasının bir nedeni, WebSockets gibi daha sonraki API'lerin çift yönlü, tam çift yönlü iletişim gerçekleştirmek için daha zengin bir protokol sağlamasıdır. İki yönlü bir kanala sahip olmak oyunlar, mesajlaşma uygulamaları ve her iki yönde gerçek zamanlıya yakın güncellemelere ihtiyaç duyduğunuz durumlar için daha caziptir. Ancak, bazı senaryolarda verilerin istemciden gönderilmesine gerek yoktur. Bazı sunucu işlemlerinden güncellemelere ihtiyacınız vardır. Birkaç örnek, arkadaşlarınızın durum güncellemeleri, hisse senedi işaretçileri, haber beslemeleri veya diğer otomatik veri gönderme mekanizmalarıdır (örneğin, istemci tarafı Web SQL Veritabanını veya IndexedDB nesne deposunu güncelleme). Bir sunucuya veri göndermeniz gerekirse, XMLHttpRequest her zaman bir dosttur.

SSE'ler geleneksel HTTP üzerinden gönderilir. Bu, çalışmak için özel bir protokol veya sunucu uygulaması gerektirmedikleri anlamına gelir. Diğer yandan WebSockets, protokolü işlemek için tam çift yönlü bağlantılar ve yeni Web Socket sunucuları gerektirir. Buna ek olarak, Sunucudan Gönderilen Olaylar, WebSockets'in otomatik yeniden bağlanma, olay kimlikleri ve rasgele olaylar gönderme yeteneği gibi tasarım gereği eksik olduğu çeşitli özelliklere sahiptir.

TLDR özeti:

SSE'nin Web Soketlerine Göre Avantajları:

  • Özel bir protokol yerine basit HTTP üzerinden aktarılır
  • Henüz desteklemeyen tarayıcılara SSE'yi "backport" yapmak için javascript ile poli doldurulabilir.
  • Yeniden bağlantı ve olay kimliği için yerleşik destek
  • Daha basit protokol
  • Paket denetimi yapan şirket güvenlik duvarlarında sorun yok

Web Soketlerinin SSE'ye Göre Avantajları:

  • Gerçek zamanlı, iki yönlü iletişim.
  • Daha fazla tarayıcıda yerel destek

SSE'nin ideal kullanım durumları:

  • Stok senedi akışı
  • twitter feed güncelleme
  • Tarayıcıya bildirimler

SSE gotchas:

  • İkili destek yok
  • Maksimum açık bağlantı limiti
— Alex Recarey
kaynak
131
Sohbet SSE ile mükemmel bir şekilde yapılabilir - sunucuya mesaj göndermek için normal POST kullanabilirsiniz. WebSockets, yalnızca bir Google Wave'de sohbet uyguluyorsanız gerekir.
— Kornel
135
Sohbet ve diğer gerçek zamanlı uygulamaların SSE ile yapılabileceği doğrudur. Ancak bu, "bant dışı" olarak POST yanıtları gerektirir, yani bu SSE protokolü tarafından kontrol edilmez ve SSE ve Web Soketleri arasındaki farklar hakkında temel bir açıklama için iyi bir örnek gibi görünmemektedir. Sunucuyu her saniye yoklayarak temel HTTP ile sohbet ve yeni yanıtlar POSTing yapabilirsiniz. Bu, bunu yapmanın en iyi / en zarif yolu olduğu anlamına gelmez.
— Alex Recarey
14
JS her zaman bir AJAX POST ile bir şeyler sunucuya "itebilirsiniz" çünkü, pomeL çözüm çoğu durumda büyük bir uzlaşma olduğunu düşünüyorum. Deneyimlerime göre, asıl mesele JS'nin yeni bilgiler için anket yapması gerektiğiydi, ancak SSE bununla ilgileniyor. : D
— Jacob Pritchett
12
@MattDiPasquale Wave, bir kerede tam mesaj yerine her anahtarı yazarken tek tek gönderdi. 1 tuş vuruşu için 200 bayt POST yükü, WebSocket için yaklaşık 6'ya kıyasla israf olacaktır.
— Kornel
9
Rakip teknolojiler olmadıklarını söylemek biraz garip görünüyor ve sonra her ikisinin de benzer çözümler elde etmek için kullanılabileceğini açıklamaya devam ediyor. Onları rekabet ettiriyor diyebilirim.
— Alex
115

Caniuse.com'a göre:

SSE desteğini diğer birçok tarayıcıya genişletmek için yalnızca istemci çoklu dolgusu kullanabilirsiniz. Bu WebSockets ile daha az olasıdır. Bazı EventSource çoklu dolguları:

  • Başka kütüphane bağımlılığı olmayan Remy Sharp tarafından EventSource (IE7 +)
  • Rick Waldron tarafından jQuery.EventSource
  • EventSource tarafından Yaffle (tarayıcılar arasında yerli uygulanmasını yerini normale davranış)

Tüm tarayıcıları desteklemeniz gerekiyorsa , WebSockets, SSE, Forever Frame ve AJAX uzun yoklama gibi birden çok aktarımı destekleyen web-socket-js , SignalR veya socket.io gibi bir kitaplık kullanmayı düşünün . Bunlar genellikle sunucu tarafında da değişiklik yapılmasını gerektirir.

SSE hakkında daha fazla bilgi için:

WebSockets hakkında daha fazla bilgi için:

Diğer farklılıklar:

  • WebSockets keyfi ikili verileri destekler, SSE yalnızca UTF-8 kullanır
— Drew Noakes
kaynak
3
Küresel kullanıcıların% 95'inin yerel olarak WebSockets'i desteklediğini belirtmek isterim. Tüm tarayıcılar ve cihazlar 4 yıldan uzun süredir WebSockets'i desteklemektedir. Socket.IO, AJAX uzun oylamaya geri dönecek ve desteklenmiyorsa WebSockets taklit etme karmaşıklıklarını işleyecektir, bu da% 100 destek sağlar. 2016'da WebSockets dışında bir şey kullanıyorsanız, eski teknolojiyi kullanıyorsunuz.
— Nick Steele
3
@NickSteele Bu bir saçmalık hype ifadesi. Eski standartlara güvenmek, kullanım durumunuzu karşılarsa ve hiçbir şeyin modası geçmiş olduğu anlamına gelmezse gayet iyi. Bu sadece farklı bir standart. Örn: XHR, Fetch API'sının yapamayacağı birçok şey yapabilir, bu nedenle modası geçmiş değildir. Bu farklı. Geçmişte WS'yi kullandım, ancak deneyimlerden birinin, WS'yi anlamadığında istekleri engelleyen gürültü kurumsal güvenlik duvarları şeklinde engellere vurabileceğini biliyorum. SSE yaptığı için süper verimlidir, önemsiz derecede anlaşılabilir ve uygulanabilir ve hata ayıklaması kolaydır. Tek yönlü veri akışımız için mükemmel.
— oligofren
@oligofren Yemin etmeye gerek yok. Önceki sürümün yerini alacak bir şey tasarlanmışsa ve endüstri tarafından kabul edilmiş ve her açıdan daha iyi ise, tanımı gereği eski yöntem eskidir. Orijinal iPhone'un modası geçmiş gibi, XHR de öyle. XHR ilk iPhone, Firefox, Chrome, YouTube, Netflix, Facebook ve hatta MySpace'den önce çıktı. XHR çıktığında Windows 98 en iyi işletim sistemiydi, AOL en iyi sağlayıcıydı ve JSON bile yoktu. WebSockets, yaklaşık on yıl önce XHR'nin yerini aldı. WS kullanarak budaklara vurursanız, bulantıya neden olan şey de güncel değildir. Bu kadar gecikmek için bir bahane yok.
— Nick Steele
4
BS'yi abartma ile değiştirin ve :-) WS, XHR / HTTP'nin yerine dronların teslimat arabaları için olduğundan daha fazla değildir. Farklı kullanım durumları. WS HTTP değildir ve farklı tatlı noktaları vardır. Denerseniz, kullanıcı alanında HTTP'yi (zayıf) yeniden uygularsınız. Ayrıca, gerçekler verilmeyen şeyleri ima ediyorsunuz: WS, sadece sunucu push'unu destekleyen çift yönlü bir protokoldür. Herhangi bir tasarım belgesinin, herhangi bir şeyin yerini aldığını belirttiğini görmedim. Kaynak? Kendi başına yaş bir faktör değildir. Bir seçenek verildiğinde, tüm gereksinimlerinizi kontrol eden en basit uygulamayı seçin.
— oligofren
1
Sadece iki yıl önce (2017) Socket.io kodunun IIS işleminde büyük bellek parçalanmasına neden olduğu ve doğrudan Azure Düğüm ekibiyle konuştuğu Nod JS işlemlerinin yığın dökümlerinde hata ayıklama yapıyordum. Toplam karmaşıklık ücretsiz değildir. 100K istemcilere hizmet sunarken, sunucuya bağımlılığınız olarak basit bir 20 satır komut dosyasıyla kurtulabiliyorsanız, bunun için giderdim. Yine de WS'yi yaptığı şey için seviyorum, ancak bir çözüm seçmeden önce neye ihtiyacınız olduğuna bakın.
— oligofren
16

Opera, Chrome, Safari, SSE'yi destekler, Chrome, Safari, SharedWorker içindeki SSE'yi destekler Firefox XMLHttpRequest readyState etkileşimini destekler, böylece Firefox için EventSource polyfil yapabiliriz

— yeşil ağaçkakan
kaynak
8

Web soketi VS SSE

Web Soketleri - Tek bir TCP bağlantısı üzerinden tam çift yönlü iletişim kanalı sağlayan bir protokoldür. Örneğin, Sunucu ve Tarayıcı arasında iki yönlü iletişim Protokol daha karmaşık olduğundan, sunucu ve tarayıcı, websocket kütüphanesine güvenmek zorundadır.socket.io

Example - Online chat application.

SSE (Sunucudan Gönderilen Olay) - Sunucu tarafından gönderilen olay durumunda iletişim sunucudan yalnızca tarayıcıya gerçekleştirilir ve tarayıcı sunucuya herhangi bir veri gönderemez. Bu tür bir iletişim esas olarak sadece güncellenmiş verileri göstermek gerektiğinde kullanılır, daha sonra veri her güncellendiğinde sunucu mesajı gönderir. Örneğin, Sunucu ile Tarayıcı arasında tek yönlü iletişim. Bu protokol daha az karmaşık, bu yüzden harici kütüphaneye güvenmeye gerek yok JAVASCRIPT kendisi EventSourcesunucu gönderilen mesajları almak için arayüz sağlar .

Example - Online stock quotes or cricket score website.
— Gaurav Tiwari
kaynak
4

Dikkat edilmesi gereken bir nokta:
Web soketleri ve kurumsal güvenlik duvarları ile ilgili sorunlar yaşadım. (HTTPS kullanmak her zaman değil ama yardımcı olur.)

Bkz. Https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software https://github.com/sockjs/sockjs-client/issues/94

Ben varsayalım Sunucu Gönderilen Etkinlikler ile birçok sorunlar yok. Ama bilmiyorum.

Bununla birlikte, WebSockets çok eğlenceli. Websockets (Socket.IO aracılığıyla) kullanan küçük bir web oyunum var ( http://minibman.com )

— Drew LeSueur
kaynak
1
Ayrıca kurumsal güvenlik duvarlarıyla ilgili sorunlar yaşadım.
— oligofren
1
Sunucu tarafından gönderilen
— olaylarda gördüğüm
2

İşte web soketleri ve sunucu tarafından gönderilen olaylar arasındaki farklar hakkında bir konuşma. Java EE 7 olduğundan bir WebSocket API özelliği belirtimin bir parçasıdır ve sunucu tarafından gönderilen olayların kurumsal sürümün bir sonraki sürümünde yayınlanacağı anlaşılmaktadır .

— Patrick Leitermann
kaynak
-3

Maksimum bağlantı sınırı http2 + sse ile ilgili bir sorun değildir.

Http bir sorun oldu 1

— user1948585
kaynak
Http2, aynı etki alanındaki birden çok isteğin akış olarak kabul edilmesini sağlar. Bu tekniğe çoklama denir. Bu, etki alanı başına tarayıcı bağlantı sınırlarını kaydeder, bu da insanların Http1 ile etki alanı parçalaması yapmasının bir nedenidir.
— user1948585
1
HTTP / 2 akışlarının sayısı da sınırlıdır; bu, sunucuların tek bir tarayıcı tarafından bombardımana uğramasını önler ve tarayıcıları çoğullamalarını sınırlı sayıda akışla sınırlamaya zorlar - bu da bizim durumumuzda HTTP / 1.1 bağlantıları ile aynıdır. Bu da sizi SSE bağlantı sınırına geri götürür.
— Myst
Websocket bağlantısının sunucu kaynaklarını da tükettiğini varsayıyorum. samsaffron.com/archive/2015/12/29/websockets-caution-required . Cebinizin izin verdiği ölçüde yapılandırma yeteneğine sahip olmak her zaman iyidir.
— user1948585
SSE'nin çoğu sunucuda benzer kaynakları kullanması muhtemeldir (hala mevcut HTTP yığını ve kısıtlamaları nedeniyle daha fazla kaynak değilse).
— Myst
1
Bu cevap doğrudur. HTTP / 2 kullanılırken 6 HTTP bağlantısı sınırı artık mevcut değil. İspat: codepen.io/dunglas/pen/yLYxdxK?editors=1010 HTTP / 2 ile sunucu çalışır ve istemci maksimum sayıda eşzamanlı akış üzerinde anlaşabilir (varsayılan olarak 100).
— Kévin Dunglas
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.