Que sont le sondage long, les Websockets, les événements envoyés par le serveur (SSE) et Comet ?

Dans les exemples ci-dessous, le client est le navigateur et le serveur est le serveur web qui héberge le site web.

Avant de pouvoir comprendre ces technologies, vous devez d'abord comprendre le trafic web HTTP classique.

HTTP classique :

1. Un client demande une page web à un serveur.
2. Le serveur calcule la réponse
3. Le serveur envoie la réponse au client.

![HTTP][1]

Interrogation Ajax :

1. Un client demande une page Web à un serveur en utilisant le protocole HTTP normal (voir HTTP ci-dessus).
2. Le client reçoit la page Web demandée et exécute le JavaScript de la page qui demande un fichier au serveur à intervalles réguliers (par exemple 0,5 seconde).
3. Le serveur calcule chaque réponse et la renvoie, comme un trafic HTTP normal.

!Ajax Polling][2]

Ajax Long-Polling :

1. Un client demande une page web à un serveur en utilisant le protocole HTTP normal (voir HTTP ci-dessus).
2. Le client reçoit la page Web demandée et exécute le JavaScript de la page qui demande un fichier au serveur.
3. Le serveur ne répond pas immédiatement avec les informations demandées mais attend jusqu'à ce qu'il y ait de nouvelles informations disponibles.
4. Lorsqu'il y a de nouvelles informations disponibles, le serveur répond avec ces nouvelles informations. 5.
5. Le client reçoit les nouvelles informations et envoie immédiatement une autre demande au serveur, relançant ainsi le processus.

!Ajax Long-Polling][3]

HTML5 Server Sent Events (SSE) / EventSource :

1. Un client demande une page Web à un serveur en utilisant le protocole HTTP normal (voir HTTP ci-dessus).
2. Le client reçoit la page Web demandée et exécute le JavaScript de la page qui ouvre une connexion au serveur.
3. Le serveur envoie un événement au client lorsqu'il y a de nouvelles informations disponibles.

• Le trafic en temps réel du serveur au client, c'est généralement ce dont vous aurez besoin.
• Vous voudrez utiliser un serveur qui possède une boucle d'événements.
• Les connexions avec des serveurs d'autres domaines ne sont possibles qu'avec des paramètres CORS corrects [4].
• Si vous voulez en savoir plus, j'ai trouvé ces informations très utiles : [(article)][5], [(article)][6], [(article)][7], [(tutoriel)][8].

!HTML5 SSE][9]

Websockets HTML5 :

1. Un client demande une page web à un serveur en utilisant le protocole http normal (voir HTTP ci-dessus).
2. Le client reçoit la page web demandée et exécute le JavaScript de la page qui ouvre une connexion avec le serveur.
3. Le serveur et le client peuvent maintenant s'envoyer des messages lorsque de nouvelles données (de part et d'autre) sont disponibles.

• Trafic en temps réel du serveur vers le client et du client vers le serveur
• Vous voudrez utiliser un serveur qui dispose d'une boucle d'événements.
• Avec les WebSockets, il est possible de se connecter à un serveur d'un autre domaine.
• Il est également possible d'utiliser un serveur Websocket hébergé par un tiers, par exemple [Pusher][10] ou [others][11]. De cette façon, vous n'aurez qu'à implémenter le côté client, ce qui est très facile !
• Si vous voulez en savoir plus, j'ai trouvé ces articles très utiles : ([article][12]), [(article)][13] ([tutoriel][14]).

!HTML5 WebSockets][15].

Comète :

Comet est une collection de techniques antérieures à HTML5 qui utilisent le streaming et le long-polling pour réaliser des applications en temps réel. Pour en savoir plus, consultez [wikipedia][16] ou [cet][17] article.

Maintenant, laquelle de ces techniques dois-je utiliser pour une application en temps réel (que je dois > coder) ?

coder). J'ai beaucoup entendu parler des websockets (avec socket.io [une bibliothèque > node.js]) mais pourquoi pas PHP ? bibliothèque node.js]) mais pourquoi pas PHP ?

Vous pouvez utiliser PHP avec les WebSockets, consultez [Ratchet][18].

[1] : http://i.stack.imgur.com/TK1ZG.png [2] : http://i.stack.imgur.com/qlMEU.png [3] : http://i.stack.imgur.com/zLnOU.png [4] : https://developer.mozilla.org/en-US/docs/Web/API/EventSource/EventSource [5] : https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events [6] : http://html5doctor.com/server-sent-events/#api [7] : http://www.html5rocks.com/en/tutorials/eventsource/basics/ [8] : http://jaxenter.com/tutorial-jsf-2-and-html5-server-sent-events-42932.html [9] : http://i.stack.imgur.com/ziR5h.png [10] : http://pusher.com/ [11] : http://www.leggetter.co.uk/real-time-web-technologies-guide [12] : http://www.developerfusion.com/article/143158/an-introduction-to-websockets/ [13] : https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_client_applications [14] : http://net.tutsplus.com/tutorials/javascript-ajax/start-using-html5-websockets-today/ [15] : http://i.stack.imgur.com/CgDlc.png [16] : http://en.wikipedia.org/wiki/Comet_%28programming%29 [17] : http://www.ibm.com/developerworks/web/library/wa-reverseajax1/index.html [18] : http://socketo.me/

Tieme a mis beaucoup d'efforts dans son excellente réponse, mais je pense que le cœur de la question du PO est de savoir comment ces technologies sont liées à PHP plutôt que de savoir comment chaque technologie fonctionne.

PHP est le langage le plus utilisé dans le développement web, en dehors de l'évident html, css, et javascript côté client. Pourtant, PHP a deux problèmes majeurs lorsqu'il s'agit d'applications en temps réel :

1. PHP a commencé comme un CGI très basique. PHP a beaucoup progressé depuis ses débuts, mais à petits pas. PHP avait déjà plusieurs millions d'utilisateurs au moment où il est devenu la bibliothèque C flexible et intégrable qu'il est aujourd'hui, la plupart d'entre eux étaient dépendants de son modèle d'exécution précédent, donc il n'a pas encore fait de tentative solide pour échapper au modèle CGI en interne. Même l'interface en ligne de commande invoque la bibliothèque PHP (libphp5.so sous linux, php5ts.dll sous windows, etc) comme s'il s'agissait d'un CGI traitant une requête GET/POST. ) comme s'il s'agissait toujours d'un cgi traitant une requête GET/POST. Il exécute toujours du code comme s'il n'avait qu'à construire une "page" puis à terminer son cycle de vie. En conséquence, il a très peu de support pour la programmation multi-thread ou événementielle (dans l'espace utilisateur de PHP), ce qui le rend actuellement peu pratique pour les applications multi-utilisateurs en temps réel.

Notez que PHP a des extensions pour fournir des boucles d'événements (comme libevent) et des threads (comme pthreads) dans l'espace utilisateur de PHP, mais très, très, très peu d'applications les utilisent.

2. PHP a toujours des problèmes significatifs avec le garbage collection. Bien que ces problèmes se soient améliorés de façon constante (probablement la plus grande étape pour mettre fin au cycle de vie comme décrit ci-dessus), même les meilleures tentatives pour créer des applications PHP fonctionnant longtemps nécessitent d'être redémarrées régulièrement. Cela le rend peu pratique pour les applications en temps réel.

PHP 7 sera un grand pas en avant pour résoudre ces problèmes, et semble très prometteur comme plateforme pour les applications en temps réel.

J'ai essayé d'en prendre note et j'ai rassemblé et écrit des exemples d'un point de vue java.

[HTTP pour les développeurs Java][1]

[Reverse Ajax - Old style] [2] (en anglais)

[Manipulation asynchrone du côté serveur] [3]

[Ajax inversé - Nouveau style] [4]

[Événements envoyés par le serveur] [5]

Je le mets ici pour tout développeur java qui se penche sur le même sujet. [1] : http://www.developers-notebook.info/2015/09/http-for-java-developer.html [2] : http://www.developers-notebook.info/2015/09/reverse-ajax.html [3] : http://www.developers-notebook.info/2015/08/async-handling-servlet-30.html [4] : http://www.developers-notebook.info/2016/08/reverse-ajax-new-school.html [5] : http://www.developers-notebook.info/2016/08/server-sent-events.html