HTTP-Routing
Deploio nimmt eingehende HTTP-Anfragen über einen gemeinsam genutzten Load Balancer entgegen. Der Load Balancer terminiert TLS und leitet jede Anfrage an deine App weiter. Die folgenden Abschnitte beschreiben die Limiten und das Verhalten des Load Balancers.
Die hier beschriebenen Einstellungen gelten für alle Deploio-Apps. Du kannst sie nicht für einzelne Apps ändern.
Timeouts
| Timeout | Wert | Verhalten |
|---|---|---|
| Inaktive Verbindung | 60 Sekunden | Senden weder der Client noch deine App während 60 Sekunden Daten, schliesst der Load Balancer die Verbindung. Hat deine App noch nicht geantwortet, erhält der Client den Fehler 504 Gateway Timeout. |
| Request-Header | 5 Sekunden | Sendet der Client die vollständigen Request-Header nicht innerhalb von 5 Sekunden, schliesst der Load Balancer die Verbindung mit dem Fehler 408 Request Timeout. |
| Inaktiver WebSocket | 1 Stunde | Überträgt eine offene WebSocket-Verbindung während 1 Stunde in keine Richtung Daten, schliesst der Load Balancer die Verbindung. |
Lang laufende Anfragen
Deploio begrenzt die Gesamtdauer einer Anfrage nicht. Das Timeout von 60 Sekunden greift nur, solange keine Daten fliessen. Eine Anfrage kann so lange laufen, wie deine App mindestens einmal alle 60 Sekunden Daten sendet.
Braucht deine App mehr als 60 Sekunden, bevor sie eine Antwort senden kann, verschiebe die Arbeit aus der Anfrage heraus. Verarbeite sie zum Beispiel in einem Worker-Job und lass den Client das Ergebnis abfragen.
Streaming-Antworten und Server-Sent Events
Für Streaming-Antworten und Server-Sent Events (SSE) gilt das Timeout von 60
Sekunden für inaktive Verbindungen. Damit eine solche Verbindung offen bleibt,
sende mindestens einmal alle 60 Sekunden Daten. Bei SSE kannst du zum Beispiel
alle 30 Sekunden eine Kommentarzeile wie : keep-alive senden.
Ein Deployment oder Wartungsarbeiten an der Plattform können die Verbindung
trotzdem schliessen. Browser, welche die EventSource-API verwenden, verbinden
sich automatisch neu. Andere Clients müssen die Wiederverbindung selbst
implementieren.
WebSockets
Deploio unterstützt WebSocket-Verbindungen ohne zusätzliche Konfiguration. Deine App nimmt die Verbindung auf demselben Port entgegen, den sie für HTTP verwendet.
WebSocket-Verbindungen sind nicht dauerhaft. Deploio schliesst sie in folgenden Fällen:
- Du deployst ein neues Release deiner App.
- Nine führt Wartungsarbeiten an der Deploio-Plattform durch. Geplante Wartungsarbeiten finden während des wöchentlichen Wartungsfensters statt.
- Die Verbindung überträgt während 1 Stunde keine Daten.
Stelle sicher, dass deine Clients mit geschlossenen Verbindungen umgehen können:
- Verbinde dich automatisch neu, wenn sich die Verbindung schliesst.
- Verwende für Wiederverbindungen einen exponentiellen Backoff mit Jitter. Viele Verbindungen können sich gleichzeitig schliessen, und gleichzeitige Wiederverbindungen können deine App überlasten.
- Sende etwa alle 30 Sekunden ein Ping-Frame. Netzwerke und Proxys zwischen dem Client und Deploio, zum Beispiel Firmen-Firewalls oder CDNs, schliessen inaktive Verbindungen oft viel früher als Deploio.
HTTP/2 und gRPC
Clients können sich über HTTP/1.1 oder HTTP/2 mit Deploio verbinden. Der Load Balancer leitet Anfragen immer über HTTP/1.1 an deine App weiter. Deine App muss HTTP/2 deshalb nicht unterstützen.
Deploio unterstützt gRPC nicht, da gRPC HTTP/2 zwischen dem Load Balancer und deiner App voraussetzt. Verwende als Alternative ein Protokoll, das über HTTP/1.1 funktioniert, zum Beispiel gRPC-Web oder das Connect-Protokoll.
Grösse des Request-Bodys
Deploio begrenzt die Grösse von Request-Bodys nicht. Für grosse Uploads gilt nur das Timeout für inaktive Verbindungen. Nach Abschluss eines Uploads muss deine App innerhalb von 60 Sekunden mit dem Senden einer Antwort beginnen.
Request-Header
Der Load Balancer setzt bei jeder Anfrage die folgenden HTTP-Header mit
Informationen zur ursprünglichen Anfrage. Die Beispiele zeigen eine Anfrage
eines Clients mit der Adresse 203.0.113.7, die über ein CDN mit der Adresse
198.51.100.2 zu Deploio gelangt.
| Header | Beschreibung | Beispiel |
|---|---|---|
X-Forwarded-Host | Der Hostname, den der Client angefragt hat | http-headers.3a76d95.deploio.app |
X-Forwarded-Proto, X-Forwarded-Scheme | Ob der Client die ursprüngliche Anfrage über HTTPS oder HTTP gestellt hat | https |
X-Forwarded-Port | Die Portnummer der ursprünglichen Anfrage | 443 |
X-Forwarded-For, X-Real-Ip | Die IP-Adresse des Clients oder Proxys, der sich mit Deploio verbunden hat | 198.51.100.2 |
X-Original-Forwarded-For | Die ursprüngliche Kette der IP-Adressen, die ein Proxy vor Deploio in X-Forwarded-For sendet | 203.0.113.7 |
Jeder Client kann den Header X-Original-Forwarded-For auf einen beliebigen
Wert setzen. Vertraue diesem Header nur, wenn alle Anfragen über einen Proxy zu
Deploio gelangen, den du kontrollierst oder dem du vertraust, zum Beispiel ein
CDN.