usar - websocket on connection

SPDY como reemplazo de Websockets?

Question

En primer lugar, entiendo que SPDY y Websockets no son lo mismo, y que puede ejecutar Websockets a través de SPDY como lo hace con HTTP, etc.

Sin embargo, me pregunto si SPDY sería un reemplazo viable para websockets si estoy tratando de proporcionar una API REST (similar) que también admita la inserción del servidor (llamadas bidireccionales a través de la misma conexión).

Mi prototipo actual utiliza websockets (node ​​+ socket.io), y funciona bien. Sin embargo, mi problema con websockets es que tengo que idear mi propio protocolo JSON para enrutar solicitudes hacia y desde el servidor. Prefiero usar URI y encabezados de estilo REST en las solicitudes, que se ajustan mejor en una arquitectura basada en REST. Parece que SPDY soportaría esto mejor.

Además, debido a la falta de encabezados, me preocupa que los websockets no encajen bien en nuestra red de implementación, y pensar que SPDY volvería a encajar mejor.

Sin embargo, no he visto muchos ejemplos de solicitudes SPDY bidireccionales, además de enviar archivos al navegador. Me gustaría enviar eventos y datos a los navegadores, como:

Content-Type: application/json
{
   "id": "ca823f3e233233",
   "name": "Greg Brady"
}

pero no me queda claro cómo el navegador / Javascript podría "escuchar" y reaccionar a estos, como lo haría con las API WebSocket y socket.io.

Answer 1

Sin embargo, mi problema con websockets es que tengo que idear mi propio protocolo JSON para enrutar solicitudes hacia y desde el servidor.

Escribí una capa RPC delgada sobre socket.io envolviendo llamadas de red con promesas solo por esa razón. Puedes echarle un vistazo here .

Answer 2

Comencemos por el principio: ¿por qué querría ejecutar WebSockets a través de SPDY, en lugar de hacer una actualización HTTP? Si actualiza una conexión HTTP a WS, entonces nada más puede usar esa secuencia TCP: la conexión WS puede estar inactiva, pero la conexión está bloqueada. Con SPDY, puede mux múltiples solicitudes / respuestas, y una conexión websocket (o incluso múltiples) a través de la misma secuencia TCP subyacente. En una nota práctica, a partir de julio de 2012, WS sobre SPDY sigue siendo un trabajo en progreso, por lo que tendrá que esperar para usar SPDY para WebSockets, aunque espero que no sea demasiado.

Pero supongamos que el soporte está ahí ... La razón por la que no está claro cómo escuchar "SPDY Push" desde JavaScript es porque no hay manera de hacerlo. Un recurso insertado entra en el caché de su navegador: nada más, nada menos. Si necesita transmitir datos a sus devoluciones de llamada de javascript, entonces la respuesta es WebSockets o Server-Sent Events (SSE).

Entonces, juntándolo todo:

• HTTP agrega una gran cantidad de sobrecarga para pequeñas solicitudes individuales (encabezados, etc.)
• WebSockets le ofrece un canal de baja sobrecarga, pero requiere que implemente su propio enrutamiento
• SPDY reducirá significativamente la sobrecarga y el costo de las pequeñas solicitudes HTTP (ganar)
• SSE es una alternativa buena y simple para enviar datos al cliente (que funciona hoy, sobre SPDY)

Podría usar SPDY + SSE para cumplir sus objetivos, y toda esa comunicación puede ejecutarse en el mismo canal TCP. Solicitudes SPDY al servidor, SSE push desde el servidor.

Answer 3

Primero algunas aclaraciones:

• El protocolo base de WebSocket (IETF 6455) no está en capas onto HTTP. El protocolo de enlace inicial para las conexiones de WebSocket es compatible con HTTP, pero una vez que se completa el protocolo de enlace, el protocolo es una conexión bidireccional bidireccional de dúplex completo con sobrecarga muy baja (a menudo solo 2 bytes por fotograma de encabezado).

• La idea de WebSocket over SPDY es una proposal que puede o no ver la luz del día. En este caso, WebSocket de hecho se está colocando en capas en SPDY. La conexión / intercambio inicial puede ocurrir más rápido debido a la naturaleza de SPDY en comparación con HTTP, sin embargo, los marcos de datos tendrán más sobrecarga porque los campos del encabezado WebSocket se asignan a los campos del encabezado SPDY.

SPDY pretende ser un reemplazo más eficiente para HTTP. WebSocket es una bestia completamente diferente que permite la mensajería bidireccional / dúplex de muy baja latencia entre el cliente y el servidor.

Si lo que le interesa es el empuje del servidor con una API simple y no necesita una latencia súper baja, entonces podría considerar los eventos enviados por el servidor que tienen una API que es simple y similar a la API de WebSocket. O puede buscar en una de las muchas bibliotecas Comet buenas que permiten el empuje del servidor pero que soportará mejor los navegadores antiguos a diferencia de cualquiera de las soluciones anteriores.