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

1048

J'ai essayé de lire quelques articles, mais je ne suis pas encore très clair sur les concepts.

Quelqu'un voudrait-il tenter de m'expliquer en quoi consistent ces technologies:

  1. Interrogation longue
  2. Événements envoyés par le serveur
  3. Websockets
  4. Comète

Une chose que j'ai rencontrée à chaque fois est que le serveur maintient une connexion ouverte et envoie les données au client. Comment la connexion est-elle maintenue ouverte et comment le client obtient-il les données transmises? (Comment le client utilise-t-il les données, peut-être qu'un code pourrait aider?)

Maintenant, lequel d'entre eux dois-je utiliser pour une application en temps réel. J'ai beaucoup entendu parler des websockets (avec socket.io [une bibliothèque node.js]) mais pourquoi pas PHP?

php  websocket  comet  long-polling  server-sent-events 
— user1437328
source
1
Websocket en temps réel ou webrtc? Il existe une bibliothèque pour websocket en php, vous avez besoin d'écrire du code supplémentaire pour qu'il fonctionne en utilisant ZMQ ou simplement une programmation par socket, nodeJs est construit pour cela, donc il est facilement disponible. La raison pour laquelle websocket n'est pas facilement disponible en php est que vous devez exécuter un terminal supplémentaire et le faire fonctionner pour que le serveur websocket soit facilement disponible, vous aurez deux serveurs en bout de ligne. et la structure, php n'est pas une structure d'événement comme javascript, donc il y a cela, websocket utilise une structure d'événement pour intercepter et envoyer des messages.
— PauAI
De plus: Comet et ServerSent Events sont une solution de contournement de PHP pour réaliser presque en temps réel (pas vraiment) sans créer 2 serveurs.
— PauAI

Réponses:

2077

Dans les exemples ci-dessous, le client est le navigateur et le serveur est le serveur Web hébergeant le site Web.

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

HTTP standard:

  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

Interrogation Ajax:

  1. Un client demande une page Web à un serveur en utilisant HTTP standard (voir HTTP ci-dessus).
  2. Le client reçoit la page Web demandée et exécute le JavaScript sur 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, tout comme le trafic HTTP normal.

Ajax Polling

Ajax Long-Polling:

  1. Un client demande une page Web à un serveur en utilisant HTTP standard (voir HTTP ci-dessus).
  2. Le client reçoit la page Web demandée et exécute le JavaScript sur 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 que de nouvelles informations soient disponibles.
  4. Quand de nouvelles informations sont disponibles, le serveur répond avec les nouvelles informations.
  5. Le client reçoit les nouvelles informations et envoie immédiatement une autre demande au serveur, relançant le processus.

Ajax Long-Polling

Événements envoyés par le serveur HTML5 (SSE) / EventSource:

  1. Un client demande une page Web à un serveur en utilisant HTTP standard (voir HTTP ci-dessus).
  2. Le client reçoit la page Web demandée et exécute le JavaScript sur la page qui ouvre une connexion au serveur.

  3. Le serveur envoie un événement au client lorsque de nouvelles informations sont disponibles.

    • Trafic en temps réel du serveur vers le client, c'est principalement ce dont vous aurez besoin
    • Vous voudrez utiliser un serveur qui a une boucle d'événements
    • Les connexions avec des serveurs d'autres domaines ne sont possibles qu'avec des paramètres CORS corrects
    • Si vous voulez en savoir plus, je les ai trouvés très utiles: (article) , (article) , (article) , (tutoriel) .

HTML5 SSE

Websockets HTML5:

  1. Un client demande une page Web à partir d'un serveur en utilisant http standard (voir HTTP ci-dessus).
  2. Le client reçoit la page Web demandée et exécute le JavaScript sur la page qui ouvre une connexion avec le serveur.

  3. Le serveur et le client peuvent désormais s’envoyer des messages lorsque de nouvelles données (de chaque côté) sont disponibles.

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

WebSockets HTML5

Comète:

Comet est un ensemble de techniques antérieures à HTML5 qui utilisent la diffusion en continu et l'interrogation longue pour réaliser des applications en temps réel. En savoir plus sur wikipedia ou cet article.

Maintenant, lequel d'entre eux dois-je utiliser pour une application en temps réel (que je dois coder). J'ai beaucoup entendu parler des websockets (avec socket.io [une bibliothèque node.js]) mais pourquoi pas PHP?

Vous pouvez utiliser PHP avec WebSockets, consultez Ratchet .

— Attache-moi
source
21
C'est génial! Je lis sur SSE et j'ai trouvé cet article, c'est très bien - comme je l'ai maintenant comparé, pouvez-vous également inclure SSE ici afin que nous puissions également vérifier sa différence avec Websocket?
— index
1
@Tieme Oh c'était ça? Je pensais que SSE signifiait les événements envoyés par le serveur. Quoi qu'il en soit, merci, je le vois maintenant.
— index du
1
Q: en php, disons que vous utilisiez websocket, chaque client connecté à mon serveur via ws aurait-il un thread qui lui serait alloué et sa taille serait de ~ 2 Mo comme c'est le cas avec les requêtes normales? en quoi cela différerait-il dans nodejs? Combien de clients simultanés les nœuds peuvent-ils gérer et quand cela casse ce qui se passe?
— Muhammad Umer
5
Vous pouvez accomplir la même chose avec les deux solutions mais le mécanisme est différent. L'interrogation longue utilise des données http «régulières», SSE utilise un protocole sous-jacent différent et nécessite une configuration de serveur différente de celle de l'interrogation longue.
— Tieme
2
Eh bien, vous pouvez utiliser Apache si vous le souhaitez. Mais beaucoup de gens utilisent Node.js car il a une boucle d'événements. Mais pour Apache, voir stackoverflow.com/questions/12203443/…
— Tieme
37

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

PHP est le langage le plus utilisé dans le développement Web, outre le côté client évident html, css et javascript. Pourtant, PHP a 2 problèmes majeurs en ce qui concerne les applications en temps réel:

1) PHP a commencé comme un CGI très basique. PHP a progressé très loin depuis ses débuts, mais cela s'est produit par petites étapes. PHP comptait déjà plusieurs millions d'utilisateurs au moment où il est devenu la bibliothèque C flexible et intégrable qu'elle est aujourd'hui, dont la plupart dépendaient de son modèle d'exécution antérieur, donc elle n'a pas encore fait une tentative solide pour échapper à la modèle cgi en interne. Même l'interface de ligne de commande appelle la bibliothèque PHP (libphp5.so sur linux, php5ts.dll sur windows, etc.) comme s'il s'agissait toujours d'un cgi traitant une requête GET / POST. Il exécute toujours le code comme s'il ne lui restait qu'à créer une "page" et à mettre fin à son cycle de vie. Par conséquent, il prend très peu en charge la programmation multi-thread ou événementielle (dans l'espace utilisateur PHP), ce qui la 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 (telles que libevent) et des threads (tels que pthreads) dans l'espace utilisateur PHP, mais très, très peu d'applications les utilisent.

2) PHP a toujours des problèmes importants avec la collecte des ordures. Bien que ces problèmes se soient constamment améliorés (il s'agit probablement de la meilleure étape pour mettre fin au cycle de vie comme décrit ci-dessus), même les meilleures tentatives de création d'applications PHP de longue durée nécessitent d'être redémarrées régulièrement. Cela le rend également peu pratique pour les applications en temps réel.

PHP 7 sera également une excellente étape pour résoudre ces problèmes et semble très prometteur en tant que plate-forme pour les applications en temps réel.

— JSON
source
2
Une petite correction: PHP a toujours été écrit en C, comme on peut le voir ici: museum.php.net/php1 De plus, "moins utilisé (mais immensément plus populaire)" est plutôt contradictoire; peut-être que ce que vous voulez dire est "plus à la mode"?
— IMSoP
@IMSoP - Merci pour la correction, j'utilise PHP depuis plus d'une décennie et j'ai toujours eu l'impression que ses racines étaient en Perl. La page d' historique PHP soutient clairement qu'il s'agissait à l'origine de C également. Je modifierai ma réponse une fois que j'aurai trouvé un moment.
— JSON
Je vais supprimer le peu de Perl car il ne se mélange pas bien avec la documentation officielle, mais c'est toujours un domaine déroutant dans les premiers développements de PHP.
— JSON
PHP 7 semble très prometteur comme plate-forme pour des applications en temps réel? Quelle amélioration / changement en PHP7 pour les applications temps réel?
— Je serai de retour
1
— eis
9

J'ai essayé d'en prendre note et j'ai rassemblé et écrit des exemples dans une perspective java .

HTTP pour les développeurs Java

Ajax inversé - Style ancien

Gestion asynchrone côté serveur

Ajax inversé - Nouveau style

Événements envoyés par le serveur

Le mettre ici pour tout développeur java qui se penche sur le même sujet.

— John
source
la plupart de ces sites ne fonctionnent pas!
— Alexander Dunn
@AlexanderDunn merci de l'avoir soulevé. Je vais le corriger avec des liens mis à jour
— John
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.