peticiones - metodos http
¿Hay un verdadero empuje del servidor sobre http? (7)
Sé que hay formas de fingir, sondear (o hacer largas encuestas), pero ¿hay alguna forma de que el servidor se contacte con el navegador para enviar información?
Cualquiera de las opciones de sondeo desperdicia recursos en el servidor y, dependiendo del servidor, puede bloquearlo (apache e iis, por ejemplo).
Parece que muchos sitios están utilizando un sondeo largo para falsificar un mecanismo de inserción del servidor en lugar de http. ¿No sería mejor tener un verdadero protocolo de inserción integrado en un navegador?
¿Qué opciones hay que sean amigables con el servidor para enviar información (falsa o no) a los navegadores web?
Mmm no.
Su navegador no escucha las conexiones entrantes.
Tampoco te gustaría que sea capaz de hacerlo. Tenemos suficientes hazañas como es.
No necesita "falsificar" nada. Flash tiene un objeto Socket muy bonito y bien desarrollado que funciona de manera brillante, y puedes escribir una pequeña aplicación Flash que se comunica con la página web, por lo que no tienes que hacer nada en Flash aparte de la comunicación con el servidor (si prefiere construir la página en HTML). Necesitarás un oyente de socket del lado del servidor, por supuesto, pero también es muy fácil lanzarlo. Gran cantidad de documentación en línea sobre cómo implementar todo ... Aquí está el primer ejemplo que encontré (no lo examiné demasiado de cerca, pero parece que funcionaría muy bien). http://www.giantflyingsaucer.com/blog/?p=205
Si está utilizando la tecnología RIA como Adobe Flex, creo que la versión Flex de un "servidor de inserción" (mensajes AMF) cumpliría con su definición de un servidor de inserción.
Por supuesto, también puedes hacer el método de votación primitivo ajax-y (hacky), pero no hay razón para que no estés obligado a hacerlo.
Creo que WebSockets (ver http://en.m.wikipedia.org/wiki/WebSocket ) es real push, por lo que la respuesta sería: depende del navegador. Si necesita una amplia compatibilidad, lo mejor que puede hacer hoy en día son las bibliotecas de JavaScript que elegirán el mejor protocolo disponible para el navegador en el que se ejecuta (por ejemplo, https://github.com/ffdead/jquery-graceful-websocket ). Pero quería servidores amigables, y admitir múltiples protocolos no es amigable para el servidor. El estado actual de la tecnología es que hacer cosas geniales que funcionen en los navegadores es intensivo en ingeniería.
Como otros dijeron, es imposible para el servidor contactar al cliente sin solicitud del cliente (en HTTP regular).
Pero si busca una solución limpia para las notificaciones push , entonces consulte Eventos enviados por el servidor . Es un HTTP regular y funciona sin problemas con la mayoría de los navegadores compatibles con HTTP 1.1.
SSE solo funciona en una sola dirección (servidor -> cliente), que es la principal mecánica para las notificaciones automáticas . Para la comunicación entre el cliente y el servidor, siempre puede usar Ajax. Hice un resumen de esto en ¿Qué tecnología para la comunicación en tiempo real para una aplicación web?
Sé que hay formas de fingir, sondear (o hacer largas encuestas), pero ¿hay alguna forma de que el servidor se contacte con el navegador para enviar información?
La conexión debe ser establecida primero por el cliente en el servidor. No hay forma de que un servidor se contacte con un cliente web.
Cualquiera de las opciones de sondeo desperdicia recursos en el servidor y, dependiendo del servidor, puede bloquearlo (apache e iis, por ejemplo).
Eso es correcto. El sondeo frecuente es ineficiente, lo cual es una de las razones por las que nos estamos moviendo a un mundo de empuje con conexiones persistentes. WebSockets será la mejor solución para esto. Trabajo para Pusher , una solución hospedada en tiempo real de WebSocket, y hemos visto una aceptación masiva de esta tecnología impulsada por una comunidad que cree que es la mejor solución para el problema de los recursos y la comunicación en tiempo real.
Parece que muchos sitios están utilizando un sondeo largo para falsificar un mecanismo de inserción del servidor en lugar de http. ¿No sería mejor tener un verdadero protocolo de inserción integrado en un navegador?
Sí, es por eso que ahora tenemos WebSockets. Las soluciones HTTP para los navegadores web son, en última instancia, un truco y no funcionan de manera consistente (de la misma manera) entre los navegadores.
¿Qué opciones hay que sean amigables con el servidor para enviar información (falsa o no) a los navegadores web?
- HTTP Long-Polling : la conexión se mantiene abierta hasta que el servidor tenga nueva información. Nota: esto es diferente al sondeo estándar donde las solicitudes de nueva información pueden ser una pérdida de tiempo completa.
- Transmisión HTTP : esta es probablemente la solución que está buscando (respondiendo a la pregunta HTTP). Con esta técnica, la conexión se mantiene abierta y se pueden enviar nuevas piezas de información a través de esa conexión existente, de servidor a cliente, sin que la conexión se cierre y se vuelva a abrir como lo hace con HTTP Long-Polling.
- HTTP / 2 Server Push : otro mecanismo estandarizado para pasar del servidor al cliente. Se conocen como "respuestas impuestas" y el navegador puede almacenarlas en caché.
- WebSockets : comunicación bidireccional y full dúplex completa a través de una única conexión TCP dentro de un navegador web (o cualquier cliente web).
Información y recursos relacionados:
- Puede pensar en los eventos enviados por el servidor (la API de EventSource ) como una estandarización de HTTP Long-Polling y HTTP-Streaming.
- HTTP / 2 Server Push
Puede ser que la tecnología haya avanzado desde el momento en que se hizo la pregunta ... Encontré esta buscando algo más.
WebPush está disponible en la mayoría de los navegadores y hay varios proveedores de notificaciones push que envían información desde el servidor al navegador. Aparte de algunos navegadores como Safari, se pueden desarrollar controladores que se pueden invocar cuando llega la notificación y realizar alguna acción en el navegador del lado del cliente.