websocket http2

¿HTTP/2 hace obsoletos los websockets?



http2 (7)

Bueno, para citar infoq.com/articles/websocket-and-http2-coexist artículo de infoq.com/articles/websocket-and-http2-coexist :

Bueno, la respuesta es claramente no, por una simple razón: como hemos visto anteriormente, HTTP / 2 introduce Server Push, que permite al servidor enviar recursos de forma proactiva a la memoria caché del cliente. Sin embargo, no permite enviar datos a la aplicación cliente. Los empujes del servidor solo son procesados ​​por el navegador y no aparecen en el código de la aplicación, lo que significa que no hay API para que la aplicación reciba notificaciones de esos eventos.

Y, por lo tanto, HTTP2 push es realmente algo entre su navegador y servidor, mientras que Websockets realmente expone las API que pueden ser utilizadas tanto por el cliente (javascript, si se ejecuta en el navegador) como por el código de la aplicación (que se ejecuta en el servidor) para transferir datos en tiempo real.

Estoy aprendiendo sobre el protocolo HTTP / 2. Es un protocolo binario con pequeños marcos de mensajes. Permite la multiplexación de secuencias a través de una única conexión TCP Conceptualmente parece muy similar a WebSockets.

¿Hay planes para obsoletos websockets y reemplazarlos con algún tipo de solicitudes HTTP / 2 sin encabezado y mensajes push iniciados por el servidor? ¿O WebSockets complementará HTTP / 2?

Después de terminar de leer la especificación HTTP / 2 , creo que HTTP / 2 hace obsoletos websockets para la mayoría de los casos de uso, pero tal vez no todos.

PUSH_PROMISE (conocido coloquialmente como inserción del servidor) no es el problema aquí. Eso es solo una optimización del rendimiento.

El principal caso de uso de Websockets en un navegador es permitir la transmisión bidireccional de datos. Entonces, creo que la pregunta del OP se convierte en si HTTP / 2 hace un mejor trabajo al habilitar la transmisión bidireccional en el navegador, y creo que sí, lo hace.

En primer lugar, es bi-di. Solo lea la introducción a la sección de transmisiones :

Un "flujo" es una secuencia independiente y bidireccional de tramas intercambiadas entre el cliente y el servidor dentro de una conexión HTTP / 2. Las corrientes tienen varias características importantes:

Una única conexión HTTP / 2 puede contener múltiples flujos abiertos simultáneamente, con marcos de intercalación de punto final de múltiples flujos.

Los flujos pueden ser establecidos y utilizados unilateralmente o compartidos por el cliente o el servidor.

Las secuencias se pueden cerrar por cualquier punto final.

Artículos como infoq.com/articles/websocket-and-http2-coexist (vinculados en otra respuesta) están equivocados sobre este aspecto de HTTP / 2. Dicen que no es bidi. Mire, hay una cosa que no puede suceder con HTTP / 2: después de abrir la conexión, el servidor no puede iniciar una transmisión normal, solo una transmisión automática. Pero una vez que el cliente abre una transmisión enviando una solicitud, ambas partes pueden enviar tramas DATA a través de un socket persistente en cualquier momento, bidi completo.

Eso no es muy diferente de websockets: el cliente debe iniciar una solicitud de actualización de websocket antes de que el servidor también pueda enviar datos.

La mayor diferencia es que, a diferencia de los websockets, HTTP / 2 define su propia semántica de multiplexación: cómo las transmisiones obtienen identificadores y cómo los marcos transportan la identificación de la transmisión en la que están. HTTP / 2 también define la semántica de control de flujo para priorizar flujos. Esto es importante en la mayoría de las aplicaciones del mundo real de bidi.

(Ese artículo equivocado también dice que el estándar Websocket tiene multiplexación. No, no lo tiene. No es realmente difícil de averiguarlo, simplemente abra el Websocket RFC 6455 y presione ⌘-F, y escriba "multiplex". Después de leer

El protocolo está destinado a ser extensible; Las versiones futuras probablemente introducirán conceptos adicionales como la multiplexación.

Encontrará que hay una extensión de borrador de 2013 para la multiplexación de Websocket. Pero no sé qué navegadores, si los hay, son compatibles con eso. No trataría de construir mi aplicación web SPA en la parte posterior de esa extensión, especialmente con HTTP / 2, el soporte nunca llegará).

La multiplexación es exactamente el tipo de cosas que normalmente debe hacer usted mismo cada vez que abre un websocket para bidi, por ejemplo, para alimentar una aplicación de una sola página que se actualiza de forma reactiva. Me alegro de que esté en la especificación HTTP / 2, cuidada de una vez por todas.

Si desea saber qué puede hacer HTTP / 2, solo mire gRPC. gRPC se implementa a través de HTTP / 2. Mire específicamente las opciones de transmisión de dúplex medio y completo que ofrece gRPC. (Tenga en cuenta que gRPC no funciona actualmente en los navegadores, pero eso es realmente porque los navegadores (1) no exponen el marco HTTP / 2 al javascript del cliente, y (2) generalmente no admiten Trailers, que se usan en la especificación de gRPC)

¿Dónde podrían tener un sitio websockets? Si no necesita ninguno de los bits adicionales que especifica HTTP / 2 (es una especificación enorme y complicada), entonces tal vez los websockets sean mejores. Agitando nuestras manos sobre la dificultad de implementación, estoy seguro de que cumplir con el protocolo websocket siempre será menos costoso desde el punto de vista informático que HTTP / 2: HTTP / 2 solo requiere que haga más cosas.

El tamaño de los marcos es muy comparable. Los marcos de Websocket son un poco más pequeños, 2-14 bytes de sobrecarga por marco, en comparación con HTTP / 2 fijo 9. Debido a que Websocket optó por un encabezado de longitud variable, puede codificar marcos más grandes (hasta 2 ^ 64-1 bits por marco vs HTTP / 2 2 ^ 24-1 bits por trama). Entonces, si necesita un enchufe para chupar algo gordo sin mucha ceremonia, como, no sé, tal vez marcos de video, entonces los websockets aún podrían tener sentido. Para la mayoría de los casos de uso, en particular los relacionados con páginas web, creo que HTTP / 2 parece ser el camino a seguir.

Digo no (los Websockets no son obsoletos).

El primer problema que se ignora con mayor frecuencia es que el empuje HTTP / 2 no es exigible y puede ser ignorado por servidores proxy, enrutadores, otros intermediarios o incluso el navegador.

es decir (del borrador HTTP2):

Un intermediario puede recibir impulsos del servidor y elegir no reenviarlos al cliente. En otras palabras, cómo hacer uso de la información enviada depende de ese intermediario. Del mismo modo, el intermediario podría optar por realizar impulsos adicionales al cliente, sin ninguna acción tomada por el servidor.

Además, las conexiones HTTP / 2 se cierran después de un tiempo.

Es cierto que el estándar establece que:

Las conexiones HTTP / 2 son persistentes. Para obtener el mejor rendimiento, se espera que los clientes no cierren las conexiones hasta que se determine que no es necesaria una comunicación adicional con un servidor (por ejemplo, cuando un usuario navega fuera de una página web en particular) o hasta que el servidor cierre la conexión.

Pero...

Se alienta a los servidores a mantener las conexiones abiertas el mayor tiempo posible, pero se les permite terminar las conexiones inactivas si es necesario. Cuando cualquiera de los puntos finales elige cerrar la conexión TCP de la capa de transporte, el punto final de terminación DEBE enviar primero una trama GOAWAY (Sección 6.8) para que ambos puntos finales puedan determinar de manera confiable si las tramas enviadas previamente se han procesado y completar o terminar con gracia cualquier tarea restante necesaria.

Incluso si la misma conexión permite empujar contenido mientras está abierto e incluso si HTTP / 2 resuelve algunos de los problemas de rendimiento introducidos por ''keep-alive'' de HTTP / 1.1 ... Las conexiones HTTP / 2 no se mantienen abiertas indefinidamente .

Tampoco puede una página web reiniciar una conexión HTTP / 2 una vez cerrada (a menos que volvamos a la extracción prolongada, claro).

EDITAR (2017, dos años después)

Las implementaciones de HTTP / 2 muestran que múltiples pestañas / ventanas del navegador comparten una única conexión HTTP / 2, lo que significa que push nunca sabrá a qué pestaña / ventana pertenece, eliminando el uso de push como reemplazo de Websockets.

El intercambio de mensajes y la transmisión simple (no audio, transmisión de video) se pueden realizar a través de multiplexación Http / 2 y WebSockets. Por lo tanto, existe cierta superposición, pero WebSockets tiene un protocolo bien establecido, muchos marcos / API y menos encabezados. infoq.com/articles/websocket-and-http2-coexist .

La respuesta es no. El objetivo entre los dos es muy diferente. Incluso hay un RFC para WebSocket sobre HTTP / 2 que le permite hacer múltiples conexiones WebSocket sobre una sola tubería TCP HTTP / 2.

WS sobre HTTP / 2 será un juego de conservación de recursos al disminuir el tiempo para abrir nuevas conexiones y permitir más canales de comunicación sin el gasto adicional de más sockets, IRQs suaves y buffers.

https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01

Por lo que entendí, HTTP / 2 no es un reemplazo para websocket, sino que apunta a estandarizar el protocolo SPDY.

En HTTP / 2, server-push se utiliza detrás de escena para mejorar la carga de recursos por parte del cliente desde el navegador. Como desarrollador, realmente no te importa durante tu desarrollo. Sin embargo, con Websocket, el desarrollador puede usar una API que puede consumir y enviar mensajes con una conexión dúplex completa única.

Estas no son las mismas cosas, y deberían complementarse entre sí.