¿Puedo transmitir una respuesta al navegador usando http2?

¿Es posible transmitir una respuesta de vuelta al navegador, desde el nodo, tal vez usando http2?

En mi aplicación web, un usuario presiona un botón que inicia un proceso de servidor. Este proceso puede tardar 10 minutos o más en completarse. Quiero transmitir actualizaciones de estado al cliente / navegador.

Creo que puedo hacer esto con websockets, pero esperaba que http2 tuviera algo que facilitarlo. Sé que admite “push”, pero que yo sepa, eso es solo para enviar archivos que el usuario pueda necesitar en el futuro.

O tal vez ni siquiera necesito http2? ¿Por cuánto tiempo mantendrá abierta la conexión el navegador? ¿Puedo simplemente seguir res.write() ing de forma indefinida?

En principio, puede transmitir datos de un servidor a cliente con cualquier versión de HTTP, simplemente enviando solo fragmentos de los datos dentro del cuerpo de la respuesta. Sin embargo, las actuales API HTTP de Brower (XHR y fetch) aún no permiten leer el cuerpo de la respuesta de forma continua, en su lugar almacenarán la respuesta completa (lo que no tiene sentido para una transmisión infinita). Trabajar con un cuerpo de respuesta transmitido será posible en el futuro cuando la función de transmisión de la API de recuperación esté completamente disponible, consulte: https://www.chromestatus.com/feature/5804334163951616 Ya puede usarlo en Chrome, pero hasta ahora Según tengo entendido, todavía no está completamente estandarizado y está disponible de manera general.

Una excepción a esta regla general son los eventos enviados por el servidor (SSE), que son respuestas HTTP desde el navegador que siguen una encoding de transformación bien definida ( text/event-stream ). Los navegadores son compatibles con las API de SSE para trabajar con las respuestas de SSE, y las API de SSE le permiten obtener un evento por cada fragmento de datos recibidos. La API es bastante sencilla y no necesita inventar un mecanismo de fragmentación propio, por lo que podría ser una buena opción para su aplicación.

Con respecto a HTTP / 1.1 y HTTP / 2: la principal diferencia es que usted observará la cantidad de flujos simultáneos que puede crear con ellos. Para HTTP / 1.1, cada transmisión requiere una conexión TCP completa, y los navegadores limitan las conexiones a un host remoto (creo que a menos de 10). Por lo tanto, crear 50 flujos de SSE no es posible, y yo iría aún más lejos y diría que probablemente solo debería usar un solo flujo de SSE y poner todos los datos de eventos en eso. HTTP / 2, por otro lado, permite multiplexar lotes de solicitudes HTTP (y, por lo tanto, también respuestas de cuerpo transmitidas) en una sola conexión TCP, lo que significa que tener un mayor número de flujos SSE concurrentes es un problema menor allí.