Anfrageverarbeitung

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.

Hier finden Sie weitere Informationen zu Regions-IDs.

OK

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 und Antworten.

Wenn Ihre Anwendung Dienste verwendet, können Sie Anfragen an einen bestimmten Dienst oder 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 Programmiersprache 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. Sie können auch die Anzahl der gleichzeitigen Anfragen ändern, die eine Instanz verarbeiten kann. Dazu legen Sie in der Datei app.yaml das Element max_concurrent_requests fest.

Die Go-Laufzeit für App Engine verwendet das standardmäßige HTTP-Paket als Schnittstelle zwischen dem Go-Programm und den App Engine-Servern. Wenn App Engine eine Webanfrage für die Anwendung empfängt, wird der http.Handler aufgerufen, der mit der Anfrage-URL verknüpft ist.

Das folgende Beispiel zeigt eine vollständige Go-Anwendung, die einen hartcodierten HTML-String an den Nutzer ausgibt:

// Sample helloworld is an App Engine app.
package main

import (
	"fmt"
	"log"
	"net/http"
	"os"
)


func main() {
	http.HandleFunc("/", indexHandler)

	port := os.Getenv("PORT")
	if port == "" {
		port = "8080"
		log.Printf("Defaulting to port %s", port)
	}

	log.Printf("Listening on port %s", port)
	if err := http.ListenAndServe(":"+port, nil); err != nil {
		log.Fatal(err)
	}
}



// indexHandler responds to requests with our greeting.
func indexHandler(w http.ResponseWriter, r *http.Request) {
	if r.URL.Path != "/" {
		http.NotFound(w, r)
		return
	}
	fmt.Fprint(w, "Hello, World!")
}

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:

Limit	Menge
Größe der Anfrage	32 MB
Größe der Antwort	32 MB
Zeitüberschreitung bei Anfrage	Hängt von der Art der Skalierung ab, die Ihre Anwendung verwendet
Maximale Gesamtzahl von Dateien (Anwendungsdateien und statische Dateien)	10.000 insgesamt 1.000 pro Verzeichnis
Maximale Größe einer Anwendungsdatei	32 MB
Maximale Größe einer statischen Datei	32 MB
Maximale Gesamtgröße aller Anwendungsdateien und statischen Dateien	Das erste 1 GB ist kostenlos 0,026 $ pro GB pro Monat nach dem ersten GB
Zeitüberschreitung bei ausstehender Anfrage	10 Sekunden
Maximale Größe eines einzelnen Anfrageheaderfelds	8 Kilobyte für Laufzeiten der zweiten Generation in der Standardumgebung. Anfragen an diese Laufzeiten mit Header-Feldern, die 8 Kilobyte überschreiten, geben HTTP 400-Fehler zurück.

Anfragelimits

Alle HTTP/2-Anfragen werden bei der Weiterleitung an den Anwendungsserver in HTTP/1.1-Anfragen umgewandelt.

Antwortlimits

• Dynamische Antworten sind auf eine Größe von 32 MB beschränkt. Wenn ein Skript-Handler eine Antwort generiert, die diesen Grenzwert überschreitet, sendet der Server eine leere Antwort mit dem Statuscode 500 („Interner Serverfehler“) zurück. Diese Beschränkung gilt nicht für Antworten, die Daten aus dem Legacy-Blobstore oder aus Cloud Storage bereitstellen.

• Der Antwortheader beträgt bei Laufzeiten der zweiten Generation 8 KB. Antwortheader, die dieses Limit überschreiten, geben HTTP 502-Fehler zurück, wobei Logs upstream sent too big header while reading response header from upstream enthalten.

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.

Umgang mit Zeitlimits für Anfragen

App Engine ist für Anwendungen mit kurzlebigen Anfragen optimiert, die in der Regel wenige Hundert Millisekunden in Anspruch nehmen. Effiziente Anwendungen antworten schnell auf die meisten Anfragen. Bei Anwendungen, die nicht schnell antworten, ist es unwahrscheinlich, dass sie mit der Infrastruktur von App Engine optimal skalieren. Um dieses Leistungsniveau beizubehalten, gibt es ein vom System festgelegtes maximales Zeitlimit für Anfragen, bis zu dem jede Anwendung antworten muss.

Wenn Ihre Anwendung diese Frist überschreitet, unterbricht App Engine den Anfrage-Handler. Bei Go-Anfrage-Handlern wird der Prozess beendet und die Laufzeitumgebung gibt den HTTP-Fehler 500 (Interner Serverfehler) an den Client zurück.

Antworten

App Engine ruft den Handler mit Request und ResponseWriter auf und wartet dann, bis der Handler in den ResponseWriter geschrieben hat und Daten zurückgibt. Wenn der Handler Daten zurückgibt, werden sie im internen Puffer des ResponseWriter an den Nutzer gesendet.

Dabei handelt es sich im Grunde um denselben Vorgang wie beim Schreiben normaler Go-Programme, die das Paket http verwenden.

Für die von Ihnen generierte Antwort gelten Größenbeschränkungen und die Antwort kann geändert werden, bevor sie an den Client zurückgegeben wird.

Weitere Informationen finden Sie in der Referenz zu Antworten auf Anfragen.

Streamingantworten

App Engine unterstützt keine Streamingantworten, bei denen Daten in inkrementellen Blöcken an den Client gesendet werden, während eine Anfrage verarbeitet wird. Alle Daten aus Ihrem Code werden wie oben beschrieben erfasst und in einer einzigen HTTP-Antwort gesendet.

Antwortkomprimierung

Bei Antworten, die von Ihrem Code zurückgegeben werden, komprimiert App Engine die Daten in der Antwort, wenn die beiden folgenden Bedingungen erfüllt sind:

• Die Anfrage enthält den Header Accept-Encoding mit gzip als einem Wert.
• Die Antwort enthält textbasierte Daten wie HTML, CSS oder JavaScript.

Bei Antworten, die von einem statischen Datei- oder Verzeichnis-Handler von App Engine zurückgegeben werden, werden die Antwortdaten komprimiert, wenn alle folgenden Bedingungen erfüllt sind:

• Die Anfrage enthält Accept-Encoding mit gzip als einem der Werte.
• Der Client kann die Antwortdaten in einem komprimierten Format empfangen. Das Google Front-End verwaltet eine Liste von Clients, die bekanntermaßen Probleme mit komprimierten Antworten haben. Diese Clients empfangen keine komprimierten Daten von statischen Handlern in Ihrer Anwendung, auch dann nicht, wenn die Anfrageheader Accept-Encoding: gzip enthalten.
• Die Antwort enthält textbasierte Daten wie HTML, CSS oder JavaScript.

Wichtige Hinweise:

• Ein Client kann erzwingen, dass textbasierte Inhaltstypen komprimiert werden. Dazu muss für die Anfrageheader Accept-Encoding und User-Agent der Wert gzip festgelegt werden.

• Wenn gzip nicht im Header der Anfrage Accept-Encoding enthalten ist, komprimiert App Engine die Antwortdaten nicht.

• Das Google Front-End speichert Antworten von statischen App Engine-Datei- und Verzeichnis-Handlern im Cache. Abhängig von verschiedenen Faktoren, z. B. welche Art von Antwortdaten zuerst im Cache gespeichert wird, welche Vary-Header Sie in der Antwort angegeben haben und welche Header in der Anfrage enthalten sind, kann ein Client möglicherweise eine Anfrage für komprimierte Daten stellen, aber unkomprimierte Daten empfangen und umgekehrt. Weitere Informationen finden Sie unter Antwort-Caching.

Antwort-Caching

Das Google Front-End und möglicherweise der Browser des Nutzers sowie andere zwischengeschaltete Proxyserver für das Caching speichern die Antworten Ihrer Anwendung gemäß den Standard-Caching-Headern, die Sie in der Antwort angeben. Sie können diese Antwortheader entweder über Ihr Framework, direkt in Ihrem Code oder über statische Datei- und Verzeichnis-Handler von App Engine festlegen.

Im Google Front-End ist der Cache-Schlüssel die vollständige URL der Anfrage.

Statische Inhalte im Cache speichern

Damit Clients immer aktualisierte statische Inhalte empfangen, sobald sie veröffentlicht werden, empfehlen wir, statische Inhalte aus versionierten Verzeichnissen wie css/v1/styles.css bereitzustellen. Das Google Front-End führt die Validierung des Caches (seine Prüfung auf aktualisierte Inhalte) erst aus, wenn der Cache abläuft. Auch nach Ablauf des Cache wird der Cache erst aktualisiert, wenn sich der Inhalt der Anfrage-URL ändert.

Die folgenden Antwortheader, die Sie in app.yaml festlegen können, haben Einfluss darauf, wie und wann das Front-End von Google Inhalte im Cache speichert:

• Cache-Control sollte auf public gesetzt sein, damit das Google Front-End Inhalte im Cache speichern kann. Sie können auch vom Google Front-End im Cache gespeichert werden, sofern Sie nicht die Anweisung Cache-Control private oder no-store angeben. Wenn Sie diesen Header nicht in app.yaml festlegen, fügt App Engine ihn automatisch allen Antworten hinzu, die von einem statischen Datei- oder Verzeichnis-Handler verarbeitet werden. Weitere Informationen finden Sie unter Hinzugefügte oder ersetzte Header.

• Vary: Damit der Cache basierend auf Headern, die in der Anfrage gesendet werden, unterschiedliche Antworten für eine URL zurückgeben kann, legen Sie im Vary-Anfrageheader einen oder mehrere der folgenden Werte fest: Accept, Accept-Encoding, Origin oder X-Origin

  Aufgrund einer potenziell hohen Kardinalität werden Daten für andere Vary-Werte nicht im Cache gespeichert.

  Beispiel:

  1. Sie geben den folgenden Antwortheader an:

     Vary: Accept-Encoding

  2. Ihre Anwendung erhält eine Anfrage mit dem Header Accept-Encoding: gzip. App Engine gibt eine komprimierte Antwort zurück und das Google Front-End speichert die mit gzip komprimierte Version der Antwortdaten im Cache. Alle nachfolgenden Anfragen für diese URL, die den Header Accept-Encoding: gzip enthalten, empfangen die mit gzip komprimierten Daten aus dem Cache, bis der Cache ungültig wird (weil sich der Inhalt nach Ablauf des Caches ändert).

  3. Ihre Anwendung erhält eine Anfrage ohne den Header Accept-Encoding. App Engine gibt eine unkomprimierte Antwort zurück und das Google Front-End speichert die unkomprimierte Version der Antwortdaten im Cache. Alle nachfolgenden Anfragen für diese URL, die den Header Accept-Encoding nicht enthalten, empfangen die komprimierten Daten aus dem Cache, bis der Cache ungültig wird.

  Wenn Sie keinen Vary-Antwortheader festlegen, erstellt das Google Front-End einen einzelnen Cache-Eintrag für die URL und verwendet ihn für alle Anfragen, unabhängig von den Headern in der Anfrage. Beispiel:

  1. Sie geben den Antwortheader Vary: Accept-Encoding nicht an.
  2. Eine Anfrage enthält den Header Accept-Encoding: gzip und die mit gzip komprimierte Version der Antwortdaten wird im Cache gespeichert.
  3. Eine zweite Anfrage enthält den Header Accept-Encoding: gzip nicht. Da der Cache jedoch eine mit gzip komprimierte Version der Antwortdaten enthält, wird die Antwort auch dann mit gzip komprimiert, wenn der Client nicht komprimierte Daten angefordert hat.

Die Header in der Anfrage haben auch Auswirkungen auf das Caching:

• Wenn die Anfrage einen Authorization-Header enthält, werden die Inhalte vom Google Front-End nicht im Cache gespeichert.

Cache-Ablauf

Die Caching-Header, die den Antworten durch statische Datei- und Verzeichnis-Handler von App Engine hinzugefügt werden, weisen Clients und Webproxys wie das Google Front-End standardmäßig an, den Cache nach 10 Minuten ablaufen zu lassen.

Nachdem eine Datei mit einer bestimmten Ablaufzeit gesendet wurde, ist es im Allgemeinen nicht möglich, sie aus Webproxy-Caches zu löschen, auch wenn der Nutzer seinen eigenen Browser-Cache löscht. Caches werden nicht zurückgesetzt, wenn Sie eine neue Version der Anwendung bereitstellen. Falls Sie also jemals vorhaben, eine statische Datei zu ändern, sollte diese eine kurze Ablaufzeit von weniger als einer Stunde haben. In der Regel kann die Standardablaufzeit von 10 Minuten übernommen werden.

Sie können die Standardablaufzeit für alle statischen Datei- und Verzeichnis-Handler ändern. Geben Sie dazu in Ihrer Datei app.yaml das Element default_expiration an. Zum Festlegen bestimmter Ablaufzeiten für einzelne Handler legen Sie das Element expiration innerhalb des Handler-Elements in Ihrer Datei app.yaml fest.

Der Wert, den Sie für die Ablaufzeit der Elemente angeben, wird zum Festlegen der HTTP-Antwortheader Cache-Control und Expires verwendet.

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

Zum Festlegen dieses Headers für statische Inhalte, die von Ihrer Anwendung bereitgestellt werden, fügen Sie den Header den statischen Datei- und Verzeichnis-Handlern Ihrer Anwendung hinzu.

Verwenden Sie das Paket secureheader, um diesen Header für Antworten festzulegen, die aus dem Code generiert werden.

Achtung: Clients, die diesen Header in der Vergangenheit empfangen haben, lehnen die Verbindung ab, wenn https nicht funktionsfähig oder aus irgendeinem Grund deaktiviert ist. Weitere Informationen finden Sie unter HTTP Strict Transport Security auf einen Blick.

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 senden.

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.

Warnung: Das Ausführen asynchroner Hintergrundarbeiten kann zu einer höheren Abrechnung führen. App Engine kann aufgrund der hohen CPU-Auslastung zusätzliche Instanzen hochskalieren, auch wenn keine aktiven Anfragen vorhanden sind. Außerdem kann es zu einer erhöhten Latenz kommen, wenn Anfragen in der Warteschlange auf verfügbare Instanzen warten.