¿Qué diablos es ReverseHTTP y por qué sería útil?

Question

reversehttp.net ofrece poca información inmediata sobre qué es reversehttp y cómo se puede utilizar mejor, hace que parezca que esta herramienta es demasiado difícil de implementar de manera realista. ¿En qué tipo de entornos podría ser esta la situación ideal de datos en tiempo real y cuándo no funcionaría? ¿Qué navegadores son compatibles con este método? ¿Qué es exactamente?

• ¿Qué hace que reversehttp sea único en otras implementaciones de PUSH?

Gracias a cualquier persona que pueda ayudar y, en primer lugar, ha oído hablar de esto y sabe de qué se trata.

Answer 1

El HTTP inverso es una forma de que el cliente mantenga una conexión abierta a un servidor web para que el servidor web pueda enviar actualizaciones al cliente (en lugar de que el cliente tenga que pedir actualizaciones continuamente).

Tome su clásico cliente de Twitter, por ejemplo.

Actualmente, el cliente le pregunta a Twitter periódicamente si tiene alguna actualización. Si no, es una solicitud desperdiciada.

Con tecnología como Reverse HTTP, una vez que establece la conexión a Twitter ... Twitter podría enviarle las actualizaciones cuando ocurran, ahorrándole a usted y a Twitter algo de ancho de banda, gastos generales y un poco de esfuerzo.

El HTTP inverso funciona ejecutando un servidor web dentro del navegador con el que se comunica el servidor.

Existen tecnologías similares que logran el mismo objetivo de una manera más segura y segura. Microsoft.NET implementa este tipo de servicios como servicios de vinculación dúplex en WCF manteniendo abierta la conexión entre el cliente y el servidor una vez que se ha creado (en lugar de ejecutar un servidor independiente en el cliente). También hay una tecnología llamada Comet que permite lo mismo.

Answer 2

Sólo navegador la página: Mi lectura es que en lugar de, por ejemplo, un sondeo de navegador web para obtener actualizaciones y tirando nuevos datos, el servidor web en lugar empuja nuevos datos en el cliente en cuanto esté disponible.

Para las aplicaciones que requieren una respuesta rápida a cualquier dato nuevo, esto eliminaría gran parte del tráfico causado por el sondeo repetido.

Answer 3

Al mirar algunas de las demostraciones (por ejemplo, this one) parece que está construido encima de una interfaz estándar estilo cometa. La implementación simplemente se presenta como un servidor HTTP completo para el cliente.

Así que en su javascript, "parece que está alojando un servidor web que responde a las solicitudes de" http://reversehttp.net/demo12345/ ", pero en realidad, las solicitudes se canalizan desde el servidor web" real "mediante peticiones de cometas al Javascript cliente corriendo en el navegador y viceversa. Cuando se describe así, parece bastante ineficiente, pero si se tiene en cuenta que en la mayoría de las situaciones, el cliente y el servidor se ejecutan en la misma computadora (entonces solo hay dos computadoras hablando entre sí), entonces la ineficiencia en su mayoría desaparece

Answer 4

He consultado el origen del HTTP inverso al que se ha vinculado.La implementación consta de dos partes:

1. El relé HTTP. Este está alojado en el sitio web reversehttp.net. Simplemente espera solicitudes a una determinada URL (la que se genera) y la reenvía a un canal (ver 2). Luego espera en otro canal (ver 2) y lo envía al solicitante.

2. El servidor HTTP JavaScript. El "servidor de cliente" sondea el "servidor servidor" para cualquier solicitud entrante usando Ajax. Luego, cuando haya solicitado la url en el "servidor servidor", y se reenvíe a un canal, se enviará al "servidor cliente". El servidor del cliente analizará la solicitud HTTP original de la solicitud en el paso 1 y creará una respuesta (la respuesta HTTP). Esta respuesta se enviará de vuelta al "servidor servidor" que termina en el canal que envía la respuesta real al solicitante.

No es en absoluto el alojamiento de un servidor HTTP real en el cliente. Esto requiere un puerto abierto 80, que la mayoría de las personas no tiene. Si está detrás de un NAT o un Firewall, se bloqueará de cualquier forma, si está bien configurado.

Supongo que usar una encuesta larga o Comet es una mejor idea que usar esto. La sobrecarga de analizar encabezados HTTP en el cliente es bastante engorrosa.

La especificación describe una forma de retransmitir solicitudes HTTP. Esto se hará configurando el encabezado Content-Type de cualquier solicitud al "servidor servidor" al message/http. Creo que hay mejores soluciones para proxy o retransmisión de solicitudes HTTP de todos modos, simplemente cambiando el campo Host del destino de retransmisión, agregando un campo especial que contiene alguna referencia al remitente original y la ruta que atravesó, y enviando el solicitud HTTP modificada al siguiente servidor. Entonces el receptor enviará la solicitud simplemente de vuelta, y el receptor busca el campo especial, muestra su origen y pasa la respuesta más adelante en la cadena.