Regions-ID
REGION_ID ist ein abgekürzter Code, den Google anhand der Region zuweist, die Sie beim Erstellen Ihrer Anwendung ausgewählt haben. Der Code bezieht sich nicht auf ein Land oder eine Provinz, auch wenn einige Regions-IDs häufig verwendeten Länder- und Provinzcodes ähneln können. Bei Anwendungen, die nach Februar 2020 erstellt wurden, ist REGION_ID.r in den App Engine-URLs enthalten. Bei Anwendungen, die vor diesem Datum erstellt wurden, ist die Regions-ID in der URL optional.
In diesem Dokument wird beschrieben, wie Ihre App Engine-Anwendung Anfragen empfängt und Antworten sendet. Weitere Informationen finden Sie in der Referenz zu Anfrageheadern.
Wenn eine Anwendung Dienste nutzt, können Sie Anfragen an einen bestimmten Dienst oder an eine bestimmte Version dieses Dienstes richten. Weitere Informationen zur Adressierbarkeit von Diensten finden Sie unter Anfragenrouting.
Verarbeitung von Anfragen
Ihre Anwendung ist für den Start eines Webservers und die Verarbeitung von Anfragen zuständig. Sie können jedes Web-Framework verwenden, das für Ihre Entwicklungssprache verfügbar ist.
App Engine führt mehrere Instanzen Ihrer Anwendung aus. Jede Instanz hat ihren eigenen Webserver zur Verarbeitung von Anfragen. Jede Anfrage kann an jede Instanz weitergeleitet werden. Daher werden aufeinanderfolgende Anfragen von einem Nutzer nicht zwangsläufig an dieselbe Instanz gesendet. Eine Instanz kann mehrere Anfragen gleichzeitig verarbeiten. Die Anzahl der Instanzen wird automatisch angepasst, wenn sich der Traffic ändert.
Kontingente und Limits
App Engine weist Ihrer Anwendung automatisch Ressourcen zu, wenn der Traffic zunimmt. Dies ist jedoch an folgende Einschränkungen gebunden:
App Engine reserviert Kapazitäten für die automatische Skalierung von Anwendungen mit niedriger Latenz, die Anfragen in weniger als einer Sekunde beantworten.
Bei stark an CPUs gebundenen Anwendungen kann die Latenz auch geringfügig höher sein, um Ressourcen gemeinsam mit anderen Anwendungen effizient auf denselben Servern zu nutzen. Anfragen nach statischen Dateien sind von diesen Latenzbeschränkungen ausgenommen.
Alle eingehenden Anfragen an die Anwendung werden auf das Limit für Anfragen angerechnet. Die als Antwort auf eine Anfrage gesendeten Daten werden auf das Limit Ausgehende Bandbreite (kostenpflichtig) angerechnet.
Sowohl HTTP- als auch (sichere) HTTPS-Requests werden auf die Limits Requests, Eingehende Bandbreite (kostenpflichtig) und Ausgehende Bandbreite (kostenpflichtig) angerechnet. In der Google Cloud Console werden außerdem zu Informationszwecken auf der Seite „Kontingentdetails“ als separate Werte Sichere Requests, Sichere eingehende Bandbreite und Sichere ausgehende Bandbreite angezeigt. In diese Werte fließen nur HTTPS-Anfragen ein. Weitere Informationen finden Sie auf der Seite Kontingente.
Die folgenden Limits gelten speziell für die Verwendung von Anfrage-Handlern:
Anfragelimits
- Es sind maximal ca. 15 KB in Anfrageheadern zulässig.
- Die Gesamtgröße einer Anfrage ist auf ca. 32 MB begrenzt.
- Alle HTTP/2-Anfragen werden bei der Weiterleitung an den Anwendungsserver in HTTP/1.1-Anfragen umgewandelt.
- SSL-Verbindungen enden am Load-Balancer. Der Traffic vom Load-Balancer wird über einen verschlüsselten Kanal an die Instanz gesendet und dann über HTTP an den Anwendungsserver weitergeleitet. Anhand des Headers "X-Forwarded-Proto" können Sie feststellen, ob die ursprüngliche Anfrage über HTTP oder HTTPS erfolgt ist.
Antwortlimits
- Antworten werden in 64-KB-Blöcken zwischengespeichert.
- Die Antwortgröße ist unbegrenzt.
- Das Zeitlimit für die Antwort beträgt eine Stunde.
- Der Antwortheader beträgt max. 64 KB. Antwortheader, die dieses Limit überschreiten, geben HTTP 502-Fehler zurück, wobei Logs
upstream sent too big header while reading response header from upstreamenthalten.
Nicht unterstützte HTTP-Anfragen
Die folgenden Funktionen werden von der flexiblen App Engine-Umgebung nicht unterstützt:
- HTTP/2-Traffic zum Back-End-Dienst
- HTTP-Anfragen, die direkt auf Instanzen zugreifen
Anfrageheader
Eine eingehende HTTP-Anfrage enthält die HTTP-Header, die vom Client gesendet werden. Einige Header werden aus Sicherheitsgründen von zwischengeschalteten Proxys bereinigt oder berichtigt, bevor sie die Anwendung erreichen.
Weitere Informationen finden Sie in der Referenz zu Anfrageheadern.
Zwischenspeichern deaktivieren
Standardmäßig werden alle Antworten von App Engine in 64-KB-Blöcken zwischengespeichert. In einigen Fällen kann es sinnvoll sein, die Zwischenspeicherung zu deaktivieren und Bytes direkt zum Client zu streamen. Dies wird im Allgemeinen bevorzugt, wenn ausstehende GET-Anfragen oder vom Server gesendete Ereignisse (Server Sent Events, SSEs) zulässig sind. Zum Deaktivieren der Zwischenspeicherung setzen Sie den Antwortheader X-Accel-Buffering auf no.
HTTPS-Verbindungen erzwingen
Aus Sicherheitsgründen sollten alle Anwendungen von Clients eine Verbindung über https anfordern. Um den Browser anzuweisen, für eine bestimmte Seite oder für die gesamte Domain https statt http zu verwenden, legen Sie in Ihren Antworten den Header Strict-Transport-Security fest.
Beispiel:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Umgang mit asynchronen Hintergrundarbeiten
Als Hintergrundarbeiten werden alle Arbeiten bezeichnet, die Ihre Anwendung für eine Anfrage ausführt, nachdem Sie Ihre HTTP-Antwort gesendet haben. Führen Sie keine Hintergrundarbeiten in der Anwendung aus und prüfen Sie den Code, um sicherzustellen, dass alle asynchronen Vorgänge abgeschlossen sind, bevor Sie eine Antwort übermitteln.
Für Jobs mit langer Ausführungszeit empfehlen wir die Verwendung von Cloud Tasks. Bei Cloud Tasks sind HTTP-Anfragen langlebig und geben eine Antwort erst zurück, wenn eine asynchrone Arbeit beendet wird.