Kann ich eine Antwort über http2 an den Browser senden?

Question

Ist es möglich, eine Antwort zurück zum Browser zu streamen, von Knoten, vielleicht mit http2?

In meiner Web-App drückt ein Benutzer eine Schaltfläche, die einen Serverprozess startet. Dieser Vorgang dauert möglicherweise 10 Minuten oder länger. Ich möchte Statusaktualisierungen zurück an den Client/Browser senden.

Ich glaube, ich kann dies mit WebSockets tun, aber ich hatte gehofft http2 hatte etwas, um dies zu erleichtern. Ich weiß, dass es "Push" unterstützt, aber soweit ich weiß, dient das nur dazu, Dateien zu drängen, die der Benutzer in Zukunft brauchen könnte.

Oder vielleicht brauche ich nicht einmal http2? Wie lange hält der Browser eine Verbindung offen? Kann ich res.write() auf unbestimmte Zeit halten?

Answer 1

Prinzipiell können Sie Daten von einem Server zum Client mit jeder HTTP-Version streamen, indem Sie nur Fragmente der Daten innerhalb des Antworttextkörpers senden. Die aktuellen Browser-APIs (XHR und Fetch) erlauben jedoch noch nicht, den Antworttext stream zu lesen, stattdessen puffern sie die gesamte Antwort (was für einen unendlichen Stream keinen Sinn ergibt). Die Arbeit mit einem gestreamten Antworttext ist in Zukunft möglich, wenn die Streaming-Funktion der Abruf-API vollständig verfügbar ist, siehe: https://www.chromestatus.com/feature/5804334163951616 Sie können es bereits in Chrome verwenden, aber soweit ich weiß, ist es noch nicht vollständig standardisiert und allgemein verfügbar.

Eine Ausnahme von dieser allgemeinen Regel sind Server Sent Events (SSE), bei denen es sich um HTTP-Antworten des Browsers handelt, die einer definierten Transformationscodierung (text/event-stream) folgen. Browser unterstützen die SSE-APIs, um mit SSE-Antworten zu arbeiten, und die SSE-APIs ermöglichen Ihnen, für jeden empfangenen Datenblock ein Ereignis abzurufen. Die API ist ziemlich einfach und Sie müssen keinen eigenen Chunking-Mechanismus erfinden, daher könnte es eine gute Option für Ihre Anwendung sein.

In Bezug auf HTTP/1.1 und HTTP/2: Der Hauptunterschied, den Sie beobachten würden, ist die Anzahl der gleichzeitigen Streams, die Sie mit ihnen erstellen können. Für HTTP/1.1 benötigt jeder Stream eine vollständige TCP-Verbindung, und Browser begrenzen Verbindungen zu einem Remote-Host (ich denke an weniger als 10). Es ist also nicht möglich, 50 SSE-Streams zu erstellen - und ich würde sogar noch weiter gehen und würde sagen, dass Sie wahrscheinlich nur einen einzigen SSE-Stream verwenden sollten und alle Event-Daten darin einfügen sollten. HTTP/2 erlaubt andererseits, viele HTTP-Anfragen (und damit auch gestreamte Body-Antworten) auf einer einzigen TCP-Verbindung zu multiplexen, was bedeutet, dass dort eine größere Anzahl von gleichzeitigen SSE-Streams weniger ein Problem ist.