Was sind Long Polling, Websockets, Server-Sent Events (SSE) und Comet?

1047

Ich habe versucht, einige Artikel zu lesen, bin mir aber der Konzepte noch nicht ganz sicher.

Möchte jemand versuchen, mir zu erklären, was diese Technologien sind:

  1. Lange Umfrage
  2. Vom Server gesendete Ereignisse
  3. Websockets
  4. Komet

Eine Sache, auf die ich jedes Mal stieß, war, dass der Server eine Verbindung offen hält und Daten an den Client weiterleitet. Wie wird die Verbindung offen gehalten und wie erhält der Client die Push-Daten? (Wie verwendet der Client die Daten, möglicherweise hilft Code?)

Welchen von ihnen soll ich nun für eine Echtzeit-App verwenden? Ich habe viel über Websockets gehört (mit socket.io [einer node.js-Bibliothek]), aber warum nicht PHP?

php  websocket  comet  long-polling  server-sent-events 
— user1437328
quelle
1
Echtzeit-Websocket oder Webrtc? Es gibt eine Bibliothek für Websocket in PHP. Sie müssen zusätzlichen Code schreiben, damit es mit ZMQ oder nur Socket-Programmierung funktioniert. NodeJs wurde dafür entwickelt, damit es leicht verfügbar ist. Der Grund, warum Websocket in PHP nicht ohne weiteres verfügbar ist, ist, dass Sie ein zusätzliches Terminal ausführen und es laufen lassen müssen, damit der Websocket-Server sofort verfügbar ist. Unter dem Strich haben Sie zwei Server. und die Struktur, PHP ist keine Ereignisstruktur wie Javascript, daher verwendet Websocket eine Ereignisstruktur, um Nachrichten abzufangen und zu senden.
— PauAI
Zusätzlich: Comet- und ServerSent-Ereignisse sind die Problemumgehung von PHP, um fast Echtzeit (nicht wirklich) zu erreichen, ohne zwei Server zu erstellen.
— PauAI

Antworten:

2076

In den folgenden Beispielen ist der Client der Browser und der Server der Webserver, auf dem die Website gehostet wird.

Bevor Sie diese Technologien verstehen können, müssen Sie zuerst den klassischen HTTP-Webverkehr verstehen .

Normales HTTP:

  1. Ein Client fordert eine Webseite von einem Server an.
  2. Der Server berechnet die Antwort
  3. Der Server sendet die Antwort an den Client.

HTTP

Ajax Polling:

  1. Ein Client fordert eine Webseite von einem Server über normales HTTP an (siehe HTTP oben).
  2. Der Client empfängt die angeforderte Webseite und führt das JavaScript auf der Seite aus, die in regelmäßigen Abständen (z. B. 0,5 Sekunden) eine Datei vom Server anfordert.
  3. Der Server berechnet jede Antwort und sendet sie zurück, genau wie normaler HTTP-Verkehr.

Ajax Polling

Ajax Long-Polling:

  1. Ein Client fordert eine Webseite von einem Server über normales HTTP an (siehe HTTP oben).
  2. Der Client empfängt die angeforderte Webseite und führt das JavaScript auf der Seite aus, die eine Datei vom Server anfordert.
  3. Der Server antwortet nicht sofort mit den angeforderten Informationen, sondern wartet, bis neue Informationen verfügbar sind.
  4. Wenn neue Informationen verfügbar sind, antwortet der Server mit den neuen Informationen.
  5. Der Client empfängt die neuen Informationen und sendet sofort eine weitere Anforderung an den Server, wodurch der Prozess neu gestartet wird.

Ajax Long-Polling

HTML5 Server Sent Events (SSE) / EventSource:

  1. Ein Client fordert eine Webseite von einem Server über normales HTTP an (siehe HTTP oben).
  2. Der Client empfängt die angeforderte Webseite und führt das JavaScript auf der Seite aus, die eine Verbindung zum Server herstellt.

  3. Der Server sendet ein Ereignis an den Client, wenn neue Informationen verfügbar sind.

HTML5 SSE

HTML5-Websockets:

  1. Ein Client fordert eine Webseite von einem Server über reguläres http an (siehe HTTP oben).
  2. Der Client empfängt die angeforderte Webseite und führt das JavaScript auf der Seite aus, die eine Verbindung zum Server herstellt.

  3. Der Server und der Client können sich jetzt gegenseitig Nachrichten senden, wenn neue Daten (auf beiden Seiten) verfügbar sind.

    • Echtzeitverkehr vom Server zum Client und vom Client zum Server
    • Sie möchten einen Server mit einer Ereignisschleife verwenden
    • Mit WebSockets ist es möglich, eine Verbindung mit einem Server einer anderen Domäne herzustellen.
    • Es ist auch möglich, einen von Drittanbietern gehosteten Websocket-Server zu verwenden, z. B. Pusher oder andere . Auf diese Weise müssen Sie nur die Client-Seite implementieren, was sehr einfach ist!
    • Wenn Sie mehr lesen möchten, fand ich diese sehr nützlich: ( Artikel ), (Artikel) ( Tutorial ).

HTML5 WebSockets

Komet:

Comet ist eine Sammlung von Techniken vor HTML5, die Streaming und Long-Polling verwenden, um Echtzeitanwendungen zu erzielen. Lesen Sie mehr auf Wikipedia oder diesem Artikel.

Nun, welche davon soll ich für eine Echtzeit-App verwenden (die ich codieren muss). Ich habe viel über Websockets gehört (mit socket.io [einer node.js-Bibliothek]), aber warum nicht PHP?

Sie können PHP mit WebSockets verwenden. Schauen Sie sich Ratchet an .

— Tieme
quelle
21
Das ist fantastisch! Ich lese gerade über SSE und habe diesen Artikel gefunden. Er ist sehr schön. Wie ich jetzt verglichen habe, können Sie hier auch SSE einfügen, damit wir auch den Unterschied zu Websocket überprüfen können.
— Index
1
@Tieme Oh war das das? Ich dachte, SSE bedeutet vom Server gesendete Ereignisse. Wie auch immer, danke, ich sehe es jetzt.
— Index
1
F: Nehmen wir in PHP an, Sie verwenden Websocket. Würde jeder Client, der über ws mit meinem Server verbunden ist, einen Thread zugewiesen haben und seine Größe ~ 2 MB betragen, wie dies bei normalen Anforderungen der Fall ist? Wie würde sich das in NodeJS unterscheiden? Wie viele gleichzeitige Clients können NodeJS verarbeiten und wenn es kaputt geht, was passiert dann?
— Muhammad Umer
5
Sie können mit beiden Lösungen dasselbe erreichen, aber der Mechanismus ist unterschiedlich. Bei langen Abfragen werden "normale" http-Daten verwendet. SSE verwendet ein anderes zugrunde liegendes Protokoll und benötigt im Vergleich zu langen Abfragen ein anderes Server-Setup.
— Tieme
2
Nun, Sie könnten Apache verwenden, wenn Sie wollen. Aber viele Leute benutzen Node.js, weil es eine Ereignisschleife hat. Aber für Apache, siehe stackoverflow.com/questions/12203443/…
— Tieme
37

Tieme hat viel Mühe in seine exzellente Antwort gesteckt, aber ich denke, der Kern der OP-Frage ist, wie sich diese Technologien auf PHP beziehen und nicht wie jede Technologie funktioniert.

PHP ist neben dem offensichtlichen clientseitigen HTML, CSS und Javascript die am häufigsten verwendete Sprache in der Webentwicklung. PHP hat jedoch zwei Hauptprobleme, wenn es um Echtzeitanwendungen geht:

1) PHP wurde als sehr einfaches CGI gestartet. PHP ist seit seinem frühen Stadium sehr weit fortgeschritten, aber es geschah in kleinen Schritten. PHP hatte bereits viele Millionen Benutzer, als es zur einbettbaren und flexiblen C-Bibliothek wurde, von der die meisten von seinem früheren Ausführungsmodell abhängig waren. Daher hat es noch keinen soliden Versuch unternommen, dem zu entkommen CGI-Modell intern. Sogar die Befehlszeilenschnittstelle ruft die PHP-Bibliothek auf (libphp5.so unter Linux, php5ts.dll unter Windows usw.), als ob es sich immer noch um ein CGI handelt, das eine GET / POST-Anforderung verarbeitet. Es führt weiterhin Code aus, als müsste nur eine "Seite" erstellt und dann der Lebenszyklus beendet werden. Infolgedessen wird die Multithread- oder ereignisgesteuerte Programmierung (innerhalb des PHP-Benutzerbereichs) kaum unterstützt, sodass sie derzeit für Echtzeitanwendungen mit mehreren Benutzern unpraktisch ist.

Beachten Sie, dass PHP über Erweiterungen verfügt, um Ereignisschleifen (wie z. B. libevent) und Threads (wie z. B. pthreads) im PHP-Benutzerbereich bereitzustellen, aber nur sehr wenige Anwendungen verwenden diese.

2) PHP hat immer noch erhebliche Probleme mit der Speicherbereinigung. Obwohl sich diese Probleme ständig verbessert haben (wahrscheinlich der größte Schritt, um den Lebenszyklus wie oben beschrieben zu beenden), müssen selbst die besten Versuche, lang laufende PHP-Anwendungen zu erstellen, regelmäßig neu gestartet werden. Dies macht es auch für Echtzeitanwendungen unpraktisch.

PHP 7 wird auch ein großer Schritt sein, um diese Probleme zu beheben, und scheint als Plattform für Echtzeitanwendungen sehr vielversprechend zu sein.

— JSON
quelle
2
Eine kleine Korrektur: PHP wurde immer in C geschrieben, wie hier zu sehen ist: museum.php.net/php1 Auch "weniger verwendet (aber immens populärer)" ist eher widersprüchlich; Vielleicht ist das, was du meinst, "modischer"?
— IMSoP
@IMSoP - Danke für die Korrektur, ich benutze PHP seit über einem Jahrzehnt und hatte immer den Eindruck, dass seine Wurzeln in Perl liegen. Die PHP- Verlaufsseite unterstützt eindeutig, dass es ursprünglich auch C war. Ich werde meine Antwort bearbeiten, sobald ich einen Moment gefunden habe.
— JSON
Ich werde das bisschen über Perl entfernen, da es sich nicht gut in die offizielle Dokumentation einfügt, aber dies ist immer noch ein verwirrender Bereich in der frühen Entwicklung von PHP.
— JSON
PHP 7 scheint als Plattform für Echtzeitanwendungen sehr vielversprechend? Welche Verbesserung / Änderung in PHP7 für Echtzeitanwendungen?
— Ich werde
1
— eis
9

Ich habe versucht, dies zu notieren und Beispiele aus einer Java-Perspektive gesammelt und geschrieben .

HTTP für Java-Entwickler

Reverse Ajax - Alter Stil

Asynchrone Behandlung auf der Serverseite

Reverse Ajax - Neuer Stil

Vom Server gesendete Ereignisse

Stellen Sie es hier für jeden Java-Entwickler ein, der sich mit dem gleichen Thema befasst.

— John
quelle
Die meisten dieser Websites funktionieren nicht!
— Alexander Dunn
@ AlexanderDunn, danke, dass du es angesprochen hast. Ich werde es mit aktualisierten Links korrigieren
— John
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.