YARP Proxying WebSockets und SPDY

Einleitung

YARP aktiviert standardmäßig Proxy-WebSocket- und SPDY-Verbindungen. Diese Unterstützung funktioniert sowohl mit dem Ansatz der direkten Weiterleitung als auch mit dem Ansatz der vollständigen Pipeline.

WebSockets ist ein bidirektionales Streamingprotokoll, das auf HTTP/1.1 oder höher basiert, das an HTTP/2 angepasst wurde.

SPDY- ist der Vorläufer von HTTP/2 und wird häufig in Kubernetes-Umgebungen verwendet.

Upgrades in HTTP/1.1

WebSockets und SPDY bauen auf HTTP/1.1 auf, das die Funktion Verbindungsupgrades verwendet. YARP leitet die ursprüngliche Anforderung per Proxy weiter, und wenn der Zielserver mit 101 Switching Protocols antwortet, aktualisiert es mithilfe des neuen Protokolls die Verbindung zu einem undurchsichtigen, bidirektionalen Stream. YaRP unterstützt das Upgrade auf andere Protokolle wie HTTP/2 auf diese Weise nicht.

HTTP/2

YARP unterstützt WebSockets über HTTP/2 ab .NET 7 und YARP 2.0. Kestrel ist der einzige verfügbare AspNetCore-Server, der eingehende HTTP/2-WebSocket-Anforderungen akzeptiert und diese Unterstützung automatisch aktiviert wird. Browser können diese vom Server angekündigte Unterstützung erkennen und automatisch zu HTTP/2 wechseln.

Die Versionen für eingehende und ausgehende Protokolle müssen nicht übereinstimmen. Die eingehende WebSocket-Anforderung kann HTTP/1.1 oder 2 sein. Für ausgehende Anforderungen gibt es keine spezifische Konfiguration für WebSockets. YARP verwendet die ForwarderRequestConfigVersion und VersionPolicy, um die zu verwendende ausgehende Version zu ermitteln. Diese Standardeinstellungen sind HTTP/2 und RequestVersionOrLower.

WebSockets erfordern unterschiedliche HTTP-Header für HTTP/2, sodass YARP diese Header bei Bedarf bei der Anpassung zwischen den verschiedenen Versionen hinzufügt und entfernt.

Nach der ersten Handshake-Funktion funktionieren WebSockets auf die gleiche Weise über beide HTTP-Versionen.

Auszeit

HTTP-Anfrage-Timeouts (.NET 8+) können standardmäßig oder nach Richtlinien auf alle Anfragen angewendet werden. Diese Timeouts werden nach einem WebSocket-Handshake deaktiviert. Sie bleiben weiterhin gültig für gRPC-Anforderungen. Weitere Konfigurationsoptionen finden Sie unter Timeouts.