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. Das Einbinden von REGION_ID.r in App Engine-URLs ist für vorhandene Anwendungen optional und wird bald für alle neuen Anwendungen erforderlich sein.

Für einen reibungslosen Übergang wird App Engine nach und nach für die Verwendung von Regions-IDs aktualisiert. Wenn Ihr Google Cloud-Projekt noch nicht aktualisiert wurde, wird für Ihre Anwendung keine Regions-ID angezeigt. Da die ID für vorhandene Anwendungen optional ist, müssen Sie keine URLs aktualisieren oder andere Änderungen vornehmen, wenn die Regions-ID für Ihre vorhandenen Anwendungen verfügbar wird.

Hier finden Sie weitere Informationen zu Regions-IDs.

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


package hello

import (
	"fmt"
	"net/http"
)

func init() {
	http.HandleFunc("/", hello)
}

func hello(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintf(w, "<h1>Hello, world</h1>")
}

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 Anwendungen, die bei einem hohen Anfrageaufkommen eine sehr hohe Latenz von beispielsweise über einer Sekunde pro Anfrage haben, ist Silber-, Gold- oder Platin-Support erforderlich. Kunden mit einer dieser Supportstufen können bei ihrem zuständigen Supportmitarbeiter höhere Durchsatzlimits anfordern.

  • 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-Anfragen werden auf die Limits für Anfragen, Eingehende Bandbreite (kostenpflichtig) und Ausgehende Bandbreite (kostenpflichtig) angerechnet. In der Cloud Console werden auf der Seite „Kontingentdetails“ zu Informationszwecken außerdem die Werte für Sichere Anfragen, Sichere eingehende Bandbreite und Sichere ausgehende Bandbreite als separate Werte 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.

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.

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

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