Co to jest Long-Polling, Websockets, Server-Sent Events (SSE) i Comet?

1046

Próbowałem przeczytać kilka artykułów, ale nie mam jeszcze jasności co do koncepcji.

Czy ktoś chciałby mi wyjaśnić, czym są te technologie:

  1. Długie odpytywanie
  2. Zdarzenia wysłane przez serwer
  3. Gniazda sieciowe
  4. Kometa

Jedną rzeczą, na którą natknąłem się za każdym razem, było to, że serwer utrzymuje otwarte połączenie i przekazuje dane do klienta. Jak połączenie jest utrzymywane otwarte i w jaki sposób klient otrzymuje wypychane dane? (Jak klient korzysta z danych, może jakiś kod może pomóc?)

Teraz którego z nich powinienem użyć do aplikacji w czasie rzeczywistym. Dużo słyszałem o websockets (z socket.io [biblioteką node.js]), ale dlaczego nie PHP?

php websocket comet long-polling server-sent-events użytkownik1437328
źródło
1
W czasie rzeczywistym websocket czy webrtc? Istnieje biblioteka dla websocket w php, musisz napisać dodatkowy kod, aby działał przy użyciu ZMQ lub po prostu programowania gniazd, nodeJs jest do tego stworzony, więc jest łatwo dostępny. Powodem, dla którego websocket nie jest łatwo dostępny w php jest to, że musisz uruchomić dodatkowy terminal i utrzymywać go w działaniu, aby serwer Websocket był łatwo dostępny, będziesz miał dwa serwery dolnej linii. a struktura php nie jest strukturą zdarzeń taką jak javascript, dlatego websocket używa struktury zdarzeń do przechwytywania i wysyłania wiadomości.
PauAI
Dodatkowo: Comet i ServerSent Events są obejściem PHP polegającym na osiągnięciu prawie w czasie rzeczywistym (nie bardzo) bez tworzenia 2 serwerów.
PauAI

Odpowiedzi:

2075

W poniższych przykładach klient jest przeglądarką, a serwerem jest serwer WWW obsługujący witrynę.

Zanim zrozumiesz te technologie, musisz najpierw zrozumieć klasyczny ruch internetowy HTTP.

Zwykły HTTP:

  1. Klient żąda strony internetowej z serwera.
  2. Serwer oblicza odpowiedź
  3. Serwer wysyła odpowiedź do klienta.

HTTP

Sondowanie Ajax:

  1. Klient żąda strony internetowej z serwera za pomocą zwykłego protokołu HTTP (patrz HTTP powyżej).
  2. Klient otrzymuje żądaną stronę internetową i wykonuje JavaScript na stronie, która żąda pliku z serwera w regularnych odstępach czasu (np. 0,5 sekundy).
  3. Serwer oblicza każdą odpowiedź i wysyła ją z powrotem, podobnie jak normalny ruch HTTP.

Ajax Polling

Ajax Long-Polling:

  1. Klient żąda strony internetowej z serwera za pomocą zwykłego protokołu HTTP (patrz HTTP powyżej).
  2. Klient otrzymuje żądaną stronę internetową i wykonuje JavaScript na stronie, która żąda pliku z serwera.
  3. Serwer nie odpowiada natychmiast żądanymi informacjami, ale czeka, aż będą dostępne nowe informacje.
  4. Gdy dostępne są nowe informacje, serwer odpowiada nowymi informacjami.
  5. Klient otrzymuje nowe informacje i natychmiast wysyła kolejne żądanie do serwera, ponownie uruchamiając proces.

Ajax Long-Polling

Zdarzenia wysłane przez serwer HTML5 (SSE) / EventSource:

  1. Klient żąda strony internetowej z serwera za pomocą zwykłego protokołu HTTP (patrz HTTP powyżej).
  2. Klient otrzymuje żądaną stronę internetową i wykonuje JavaScript na stronie, która otwiera połączenie z serwerem.

  3. Serwer wysyła zdarzenie do klienta, gdy dostępne są nowe informacje.

HTML5 SSE

HTML5 Websockets:

  1. Klient żąda strony internetowej z serwera za pomocą zwykłego protokołu http (patrz HTTP powyżej).
  2. Klient otrzymuje żądaną stronę internetową i wykonuje JavaScript na stronie, która otwiera połączenie z serwerem.

  3. Serwer i klient mogą teraz wysyłać sobie wiadomości, gdy nowe dane (po obu stronach) są dostępne.

    • Ruch w czasie rzeczywistym z serwera do klienta i od klienta do serwera
    • Będziesz chciał użyć serwera z pętlą zdarzeń
    • Dzięki WebSockets można połączyć się z serwerem z innej domeny.
    • Możliwe jest również do korzystania osobie trzeciej serwer obsługiwany websocket, na przykład Pusher lub innych . W ten sposób będziesz musiał wdrożyć tylko po stronie klienta, co jest bardzo proste!
    • Jeśli chcesz przeczytać więcej, znalazłem te bardzo przydatne: ( artykuł ), (artykuł) ( tutorial ).

HTML5 WebSockets

Kometa:

Comet to zbiór technik sprzed HTML5, które wykorzystują strumieniowanie i długie odpytywanie w celu uzyskania aplikacji w czasie rzeczywistym. Przeczytaj więcej na wikipedii lub w tym artykule.

Teraz którego z nich powinienem użyć do aplikacji w czasie rzeczywistym (którą muszę zakodować). Dużo słyszałem o websockets (z socket.io [biblioteką node.js]), ale dlaczego nie PHP?

Możesz używać PHP z WebSockets, sprawdź Ratchet .

Zwiąż mnie
źródło
21
To jest niesamowite! Czytam o SSE i znalazłem ten artykuł, jest bardzo fajny - tak jak teraz porównałem różne rzeczy, czy możesz również włączyć SSE, abyśmy mogli sprawdzić, czy to różni się od Websocket?
indeks
1
@Tieme Oh to było to? Myślałem, że SSE oznacza zdarzenia wysyłane przez serwer. W każdym razie dzięki, teraz to widzę.
indeks
1
P: w php powiedzmy, że używasz websocket, czy każdy klient podłączony do mojego serwera za pomocą ws: miałby przydzielony mu jeden wątek, a jego rozmiar wynosiłby ~ 2mb, jak ma to miejsce w przypadku normalnych żądań? czym by to się różniło w przypadku nodejów? Ilu równoczesnych klientów może obsłużyć nodejs i kiedy się zepsuje, co się stanie?
Muhammad Umer
5
Możesz osiągnąć to samo z obydwoma rozwiązaniami, ale mechanizm jest inny. Długie odpytywanie wykorzystuje „zwykłe” dane HTTP, SSE używa innego bazowego protokołu i wymaga innej konfiguracji serwera w porównaniu do długiego odpytywania.
Tieme
2
Możesz użyć apache, jeśli chcesz. Ale wiele osób korzysta z Node.js, ponieważ ma pętlę zdarzeń. Ale Apache, patrz stackoverflow.com/questions/12203443/…
Tieme
37

Tieme włożył wiele wysiłku w swoją doskonałą odpowiedź, ale myślę, że rdzeniem pytania PO jest to, jak te technologie odnoszą się do PHP, a nie jak działa każda z nich.

PHP jest najczęściej używanym językiem w tworzeniu stron internetowych, oprócz oczywistych html, css i javascript po stronie klienta. Jednak PHP ma 2 główne problemy, jeśli chodzi o aplikacje w czasie rzeczywistym:

1) PHP zaczął jako bardzo podstawowy CGI. PHP posunął się bardzo daleko od wczesnego etapu, ale stało się to małymi krokami. PHP miało już wiele milionów użytkowników, zanim stało się wbudowaną i elastyczną biblioteką C, jaką jest dzisiaj, z których większość była zależna od wcześniejszego modelu wykonania, więc nie podjęła jeszcze solidnej próby ucieczki model cgi wewnętrznie. Nawet interfejs wiersza poleceń wywołuje bibliotekę PHP (libphp5.so w systemie Linux, php5ts.dll w systemie Windows itp.), Tak jakby nadal był cgi przetwarzającym żądanie GET / POST. Nadal wykonuje kod tak, jakby po prostu musiał zbudować „stronę”, a następnie zakończyć swój cykl życia. W rezultacie ma bardzo małe wsparcie dla programowania wielowątkowego lub sterowanego zdarzeniami (w przestrzeni użytkownika PHP), co czyni go obecnie niepraktycznym dla aplikacji dla wielu użytkowników w czasie rzeczywistym.

Zauważ, że PHP ma rozszerzenia zapewniające pętle zdarzeń (takie jak libevent) i wątki (takie jak pthreads) w przestrzeni użytkownika PHP, ale bardzo, bardzo niewiele aplikacji z nich korzysta.

2) PHP nadal ma poważne problemy z odśmiecaniem. Chociaż problemy te stale się poprawiają (prawdopodobnie jest to najlepszy krok do zakończenia cyklu życia, jak opisano powyżej), nawet najlepsze próby tworzenia długo działających aplikacji PHP wymagają regularnego restartowania. To sprawia, że ​​jest to niepraktyczne w przypadku aplikacji w czasie rzeczywistym.

PHP 7 będzie świetnym krokiem do rozwiązania tych problemów i wydaje się bardzo obiecujący jako platforma dla aplikacji w czasie rzeczywistym.

JSON
źródło
2
Jedna mała poprawka: PHP zawsze było napisane w C, co można zobaczyć tutaj: museum.php.net/php1 Również „rzadziej używany (ale znacznie bardziej popularny)” jest raczej wewnętrznie sprzeczny; może to, co masz na myśli mówiąc „bardziej modne”?
IMSoP
@IMSoP - Dzięki za poprawkę, korzystam z PHP od ponad dekady i zawsze miałem wrażenie, że jego korzenie były w Perlu. Strona historii PHP wyraźnie potwierdza, że ​​pierwotnie była to również C. Zmienię swoją odpowiedź, gdy tylko znajdę chwilę.
JSON,
Usunę trochę informacji o Perlu, ponieważ nie łączy się on dobrze z oficjalną dokumentacją, ale wciąż jest to mylący obszar we wczesnym rozwoju PHP.
JSON
PHP 7 wydaje się bardzo obiecująca jako platforma dla aplikacji w czasie rzeczywistym? Jakie ulepszenia / zmiany w PHP7 dla aplikacji w czasie rzeczywistym?
Będę z powrotem
1
chociaż także svn.php.net/viewvc/phpdoc/en/trunk/appendices/… && web.archive.org/web/20090426061624/http://us3.php.net/…
eis
1

Możesz łatwo używać Node.JS w swojej aplikacji internetowej tylko do komunikacji w czasie rzeczywistym. Node.JS jest naprawdę potężny, jeśli chodzi o WebSockets. Dlatego „Powiadomienia PHP przez Node.js” byłyby świetną koncepcją.

Zobacz ten przykład: Tworzenie aplikacji czatu w czasie rzeczywistym za pomocą PHP i Node.js

Supun Kavinda
źródło