Czy Comet jest już przestarzały z wysyłanymi przez serwer zdarzeniami i WebSocket? [zamknięte]

Podchodzę do tej odpowiedzi zarówno z perspektywy terminologicznej, jak i historycznej.

Jak pisałem w tej innej odpowiedzi , możemy użyć jednego z kilku pojęć parasolowych w odniesieniu do zestawu technologii dostępnych do asynchronicznie wysyłania zdarzeń z serwera www do klienta WWW (i odwrotnie). Termin "technologia Push " jest używany od piętnastu lat (dla krótkiej historii technologii Push możesz zobaczyć ten stary biały papier napisałem wiele lat temu-pełna ujawnienie: jestem twórcą Lightstreamer). Obecnie termin "web Streaming "zyskuje konsensus wśród analityków IT (patrz Gartner, " Cool Vendors in Application and Integration Platforms, 2012", Massimo Pezzini i Jess Thompson, 11 kwietnia 2012).

Ważnym aspektem jest to, że mówimy o komunikacji internetowej, czyli wykorzystywaniu protokołów internetowych. Istnieje mnóstwo protokołów i technologii przesyłania wiadomości, które nie są oparte na sieci (większość MOMs, na przykład) i robimy nie traktuj ich jako część technologii Push (lub streamingu internetowego).

Biorąc to pod uwagę, można wyróżnić dwie podkategorie technologii Push (lub streamingu internetowego):

• HTTP na podstawie
• WebSockets na podstawie

Zarówno HTTP, jak i WebSockets są protokołami sieciowymi.

Jeśli eksplodujesz mechanizmy push oparte na HTTP, możesz zidentyfikować:

• Streaming HTTP
• http Long Ankieta
• ankieta HTTP

Tradycyjnie termin" Kometa " (ukuty w 2006 Alex Russell) odnosi się zarówno do streamingu HTTP, jak i sondowania HTTP. Ale weź pod uwagę, że pierwsze implementacje streamingu HTTP sięgają 2000, na długo przed pojęciem komety (przykładami są Pushlets i Lightstreamer).

Teraz WebSockets ułatwiają implementację streamingu internetowego, szczególnie dla kanału "wstecz" (wiadomości wysyłane z przeglądarki na serwer). Aby uzyskać bardziej szczegółowe wyjaśnienie specyfiki kanału wstecznego przez HTTP, Zobacz ostatnią część tego artykułu, który napisałem dla CometDaily: http://cometdaily.com/2011/07/06/push-technology-comet-and-websockets-10-years-of-history-from-lightstreamers-perspective/

Jak zauważył Phil, Comet jest nadal potrzebny i prawdopodobnie będzie jeszcze przez kilka lat, ponieważ wokół są nie tylko stare przeglądarki (w tym IE9, który nie wsparcie WebSockets...), ale także nieskończone kawałki pośredników sieciowych, które nie mówią WS. Na przykład widzieliśmy, że niektórzy przewoźnicy komórkowi w niektórych krajach (na przykład Vodafone Włochy) wspierają WSS, ale blokują WS. Tak więc świat bez komety "hacki" jest jeszcze daleko... i dodam, na osobistą uwagę, że nigdy nie podobał mi się termin "hack" stosowany do komety (lub, z bardziej poprawnego historycznego punktu widzenia, stosowane do HTTP Streaming i HTTP Long Polling). Pracując nad tymi techniki od 12 lat możemy powiedzieć, że udało nam się je udoskonalić tak bardzo, że same stały się pełnoprawną technologią, całkowicie niezawodną i używaną każdego dnia w wielu krytycznych scenariuszach produkcji (w finansach, lotnictwie i wojsku, by wymienić kilka branż).

Wyobraźmy sobie teraz świat, w którym WebSockets są powszechnie wspierane i Kometa nie jest już potrzebna. Co dokładnie dostajesz? Cóż, tylko dwukierunkowy transport, nic więcej... Na wierzchu potrzebujesz aby zbudować wszystko: protokół komunikacyjny (być może oparty na pub/sub), interfejs po stronie serwera do rozmowy z kodem serwera oraz dobry zestaw technik optymalizacji i algorytmów do zarządzania przepływem danych, w tym zarządzanie przepustowością, konflacja danych, automatyczne Dławienie, delta delivery itp. Dobrą rzeczą jest to, że zarówno protokoły przesyłania wiadomości, jak i mechanizmy optymalizacji zostały już wdrożone przez dobre rozwiązania Comet. Tak więc rozszerzenie dotychczasowych serwerów Comet o obsługę WebSocket jest naturalna ewolucja, którą wszyscy dostawcy wdrożyli.

W skrócie, w niedalekiej przyszłości WebSockets może sprawić, że transporty Comet staną się przestarzałe, ale będą musiały wciągać wszystkie wyższe warstwy już zaimplementowane i dobrze przetestowane na tradycyjnych serwerach Comet.

Początkowo myślałem, że WebSockets uświadamiają sobie kometę. Nie są alternatywą . Jednak po pewnej dyskusji zostałem później poprawiony i przekonany przez Alexa Russella, twórcę "komety", że tak nie było.

Comet, jak mówi @kanaka, jest zbiorem zasad symulowania dwukierunkowej komunikacji między Klientem a serwerem (server push to połowa rozwiązania i jest teraz dostarczany przez zdarzenia wysłane przez serwer i źródło zdarzeń API).

Jednak, Rozwiązania Comet są hackami, ponieważ działają niekonsekwentnie w przeglądarkach internetowych. Z tego powodu Alex Russell mówi:

Dalej, Czy Gniazda Sieciowe to forma komety? A może Kometa to tylko hacki HTTP? Pójdę za tą drugą definicją. Fraza i hacki powinny jechać razem w stronę zachodu Słońca. Ja, na przykład, Witam naszych Nie-HTTP realtime overlords. Do tego stopnia, że możemy zapomnieć o starych przeglądarkach (i Bóg wie, że robię swoje: http://google.com/chromeframe ), wszyscy możemy wejść na pokład z "gniazdkami sieciowymi" i potrzeba konkretnego parasola znika.

Więc skupmy się na tym: jak wprowadzić użytkowników do lśniącego nowego samochodu przeglądarki? Jaką ofertę możemy im zaoferować o bogactwie i doświadczeniach w czasie rzeczywistym, jakie może dostarczyć aplikacja oparta na WebSockets? Kometa jest o przeszłości. Uczyńmy przyszłość realną.

Jestem teraz z Alexem w tej sprawie. Jednak rozwiązania Comet-HTTP-nie są stanie się przestarzały do:

1. Obsługa przeglądarki jest 100% i nie potrzebujemy zastępczych dla
2. producenci antywirusów (np. Avast!) rozpocząć obsługę technologii internetowych HTML5 i zatrzymać ich oprogramowanie zakłócające łączność.
[[21]} Trochę Internetu Infrastruktura jest aktualizowana w celu zapewnienia obsługi WebSockets. W moich doświadczeniach podłączony przez WSS przez port 443 (bezpieczne połączenie WebSocket) zwykle oznacza połączenia przejść przez firewalle i proxy, ale chcemy WS przez port 80 zawsze być obsługiwane zbyt.

Podczas gdy WebSocket zapewnia na najbardziej podstawowym poziomie sposób komunikacji dwukierunkowej między Klientem a serwerem w kontekście sieci i HTTP, jest to prosta forma komunikacji.

Comet zapewnia większą funkcjonalność na szczycie WebSocket( w rzeczywistości cometd obsługuje nawet websocket), dla funkcji:

• jak publikować / subskrybować i kanały komunikacji
• Powrót do starszych technik komunikacji klienta serwera, gdy websocket jest unvailable