¿Qué son Long-Polling, Websockets, Server-Sent Events (SSE) y Comet?

1048

He intentado leer algunos artículos, pero todavía no tengo muy claros los conceptos.

¿A alguien le gustaría intentar explicarme cuáles son estas tecnologías:

  1. Sondeo largo
  2. Eventos enviados por el servidor
  3. Websockets
  4. Cometa

Una de las cosas que encontré cada vez fue que el servidor mantiene una conexión abierta y envía datos al cliente. ¿Cómo se mantiene abierta la conexión y cómo obtiene el cliente los datos enviados? (¿Cómo utiliza el cliente los datos, tal vez algún código podría ayudar?)

Ahora, ¿cuál de ellos debo usar para una aplicación en tiempo real? He estado escuchando mucho sobre websockets (con socket.io [una biblioteca de node.js]) pero ¿por qué no PHP?

php  websocket  comet  long-polling  server-sent-events 
— usuario1437328
fuente
1
Websocket o webrtc en tiempo real? Hay una biblioteca para websocket en php, necesita escribir código adicional para que funcione con ZMQ o simplemente programación de socket, nodeJs está diseñado para esto, por lo que está fácilmente disponible. La razón por la cual websocket no está fácilmente disponible en php es porque tiene que ejecutar un terminal adicional y mantenerlo en funcionamiento para que el servidor websocket esté fácilmente disponible, tendrá dos servidores. y la estructura, php no es una estructura de eventos como javascript, así que hay que, websocket utiliza una estructura de eventos para capturar y enviar mensajes.
— PauAI
Además: Comet y ServerSent Events son la solución alternativa de PHP para lograr casi en tiempo real (no realmente) sin crear 2 servidores.
— PauAI

Respuestas:

2077

En los ejemplos a continuación, el cliente es el navegador y el servidor es el servidor web que aloja el sitio web.

Antes de que pueda comprender estas tecnologías, primero debe comprender el tráfico web HTTP clásico .

HTTP regular:

  1. Un cliente solicita una página web de un servidor.
  2. El servidor calcula la respuesta.
  3. El servidor envía la respuesta al cliente.

HTTP

Encuesta Ajax:

  1. Un cliente solicita una página web de un servidor utilizando HTTP normal (consulte HTTP más arriba).
  2. El cliente recibe la página web solicitada y ejecuta el JavaScript en la página que solicita un archivo del servidor a intervalos regulares (por ejemplo, 0,5 segundos).
  3. El servidor calcula cada respuesta y la envía de vuelta, al igual que el tráfico HTTP normal.

Encuesta Ajax

Ajax Long-Polling:

  1. Un cliente solicita una página web de un servidor utilizando HTTP normal (consulte HTTP más arriba).
  2. El cliente recibe la página web solicitada y ejecuta el JavaScript en la página que solicita un archivo del servidor.
  3. El servidor no responde de inmediato con la información solicitada, pero espera hasta que haya nueva información disponible.
  4. Cuando hay nueva información disponible, el servidor responde con la nueva información.
  5. El cliente recibe la nueva información e inmediatamente envía otra solicitud al servidor, reiniciando el proceso.

Ajax Long-Polling

Eventos enviados por el servidor HTML5 (SSE) / EventSource:

  1. Un cliente solicita una página web de un servidor utilizando HTTP normal (consulte HTTP más arriba).
  2. El cliente recibe la página web solicitada y ejecuta el JavaScript en la página que abre una conexión al servidor.

  3. El servidor envía un evento al cliente cuando hay nueva información disponible.

HTML5 SSE

HTML5 Websockets:

  1. Un cliente solicita una página web de un servidor utilizando http regular (consulte HTTP más arriba).
  2. El cliente recibe la página web solicitada y ejecuta el JavaScript en la página que abre una conexión con el servidor.

  3. El servidor y el cliente ahora pueden enviarse mensajes cuando haya nuevos datos disponibles (en ambos lados).

    • Tráfico en tiempo real del servidor al cliente y del cliente al servidor
    • Querrás usar un servidor que tenga un bucle de eventos
    • Con WebSockets es posible conectarse con un servidor de otro dominio.
    • También es posible utilizar un servidor websocket alojado por un tercero, por ejemplo Pusher u otros . De esta manera, solo tendrá que implementar el lado del cliente, ¡lo cual es muy fácil!
    • Si desea leer más, los encontré muy útiles: ( artículo ), (artículo) ( tutorial ).

HTML5 WebSockets

Cometa:

Comet es una colección de técnicas anteriores a HTML5 que utilizan la transmisión y el sondeo largo para lograr aplicaciones en tiempo real. Lea más en wikipedia o este artículo.

Ahora, ¿cuál de ellos debo usar para una aplicación en tiempo real (que necesito codificar)? He estado escuchando mucho sobre websockets (con socket.io [una biblioteca de node.js]) pero ¿por qué no PHP?

Puede usar PHP con WebSockets, consulte Ratchet .

— Tieme
fuente
21
¡Esto es asombroso! Estoy leyendo sobre SSE y encontré este artículo, es muy agradable, como ahora he comparado cosas, ¿también puede incluir SSE aquí para que podamos verificar su diferencia con Websocket?
— índice
1
@Tieme Oh, ¿eso fue todo? Pensé que SSE significaba eventos enviados por el servidor. De todos modos, gracias, lo veo ahora.
— índice
1
P: en php, digamos que estaba usando websocket, ¿todos los clientes conectados a mi servidor usando ws: tendrían un hilo asignado y su tamaño sería de ~ 2mb, como es el caso de las solicitudes normales? ¿Cómo diferiría eso en nodejs? ¿Cuántos clientes concurrentes pueden manejar nodejs y cuando se rompe lo que sucede?
— Muhammad Umer
55
Puede lograr lo mismo con ambas soluciones, pero el mecanismo es diferente. El sondeo largo usa datos http 'regulares', SSE usa un protocolo subyacente diferente y necesita una configuración de servidor diferente en comparación con el sondeo largo.
— Tieme
2
Bueno, podrías usar apache si quieres. Pero mucha gente usa Node.js porque tiene un bucle de eventos. Pero para Apache, consulte stackoverflow.com/questions/12203443/…
— Tieme
37

Tieme puso mucho esfuerzo en su excelente respuesta, pero creo que el núcleo de la pregunta de los OP es cómo se relacionan estas tecnologías con PHP en lugar de cómo funciona cada tecnología.

PHP es el lenguaje más utilizado en el desarrollo web además del obvio cliente html, css y javascript. Sin embargo, PHP tiene 2 problemas principales cuando se trata de aplicaciones en tiempo real:

1) PHP comenzó como un CGI muy básico. PHP ha progresado mucho desde su etapa inicial, pero sucedió en pequeños pasos. PHP ya tenía muchos millones de usuarios cuando se convirtió en la biblioteca C flexible e incrustada que es hoy, la mayoría de los cuales dependían de su modelo de ejecución anterior, por lo que aún no ha hecho un intento sólido de escapar de la modelo cgi internamente. Incluso la interfaz de línea de comandos invoca la biblioteca PHP (libphp5.so en linux, php5ts.dll en windows, etc.) como si todavía fuera un cgi que procesa una solicitud GET / POST. Todavía ejecuta código como si solo tuviera que construir una "página" y luego finalizar su ciclo de vida. Como resultado, tiene muy poco soporte para la programación basada en múltiples hilos o eventos (dentro del espacio de usuario de PHP), por lo que actualmente no es práctico para aplicaciones de múltiples usuarios en tiempo real.

Tenga en cuenta que PHP tiene extensiones para proporcionar bucles de eventos (como libevent) y subprocesos (como pthreads) en el espacio de usuario de PHP, pero muy, muy pocas aplicaciones las usan.

2) PHP todavía tiene problemas importantes con la recolección de basura. Aunque estos problemas han estado mejorando constantemente (probablemente es el mejor paso para finalizar el ciclo de vida como se describe anteriormente), incluso los mejores intentos de crear aplicaciones PHP de larga ejecución requieren reiniciarse de forma regular. Esto también lo hace poco práctico para aplicaciones en tiempo real.

PHP 7 también será un gran paso para solucionar estos problemas, y parece muy prometedor como plataforma para aplicaciones en tiempo real.

— JSON
fuente
2
Una pequeña corrección: PHP siempre se escribió en C, como se puede ver aquí: museum.php.net/php1 Además, "menos utilizado (pero inmensamente más popular)" es bastante contradictorio; ¿Quizás lo que quieres decir es "más de moda"?
— IMSoP
@IMSoP: gracias por la corrección, he estado usando PHP durante más de una década y siempre he tenido la impresión de que sus raíces estaban en Perl. La página del historial de PHP claramente admite que originalmente también era C. Editaré mi respuesta una vez que encuentre un momento.
— JSON
Eliminaré un poco sobre Perl, ya que no se mezcla bien con la documentación oficial, pero esta sigue siendo un área confusa en el desarrollo inicial de PHP.
— JSON
¿PHP 7 parece muy prometedor como plataforma para aplicaciones en tiempo real? ¿Qué mejora / cambio en PHP7 para aplicaciones en tiempo real?
— Volveré el
1
— eis
9

He intentado tomar nota de esto y he recopilado y escrito ejemplos desde una perspectiva de Java .

HTTP para desarrolladores de Java

Ajax inverso: estilo antiguo

Manejo asíncrono en el lado del servidor

Reverse Ajax - Nuevo estilo

Eventos enviados por el servidor

Poniéndolo aquí para cualquier desarrollador de Java que esté investigando el mismo tema.

— Juan
fuente
¡La mayoría de estos sitios no funcionan!
— Alexander Dunn
@AlexanderDunn gracias por mencionarlo. Lo corregiré con enlaces actualizados
— John
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.