Modalità di gestione delle richieste

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base alla regione selezionata quando crei l'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare simili ai codici di paesi e province di uso comune. Per le app create dopo febbraio 2020, REGION_ID.r è incluso negli URL di App Engine. Per le app esistenti create prima di questa data, l'ID regione è facoltativo nell'URL.

Scopri di più sugli ID regione.

Ok

Questo documento descrive come l'applicazione App Engine riceve le richieste e invia le risposte.

Per maggiori dettagli, consulta la documentazione di riferimento su intestazioni di richiesta e risposte.

Se la tua applicazione utilizza servizi, puoi indirizzare le richieste a un servizio specifico o a una versione specifica di quel servizio. Per ulteriori informazioni sull'addressability dei servizi, consulta Come vengono instradate le richieste.

Gestione delle richieste

L'applicazione è responsabile dell'avvio di un server web e della gestione delle richieste. Puoi utilizzare qualsiasi framework web disponibile per il tuo linguaggio di sviluppo.

App Engine esegue più istanze della tua applicazione e ogni istanza ha il proprio server web per gestire le richieste. Qualsiasi richiesta può essere indirizzata a qualsiasi istanza, pertanto le richieste consecutive dello stesso utente non vengono necessariamente inviate alla stessa istanza. Un'istanza può gestire più richieste contemporaneamente. Il numero di istanze può essere regolato automaticamente in base alle variazioni del traffico. Puoi anche modificare il numero di richieste simultanee che un'istanza può gestire impostando l'elemento max_concurrent_requests nel file app.yaml.

Il runtime Go per App Engine utilizza il pacchetto http standard come interfaccia tra il programma Go e i server App Engine. Quando App Engine riceve una richiesta web per la tua applicazione, invoca il http.Handler associato all'URL della richiesta.

L'esempio seguente è un'app Go completa che restituisce all'utente una stringa HTML hardcoded:

// 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!")
}

Quote e limiti

App Engine alloca automaticamente le risorse alla tua applicazione man mano che il traffico aumenta. Tuttavia, sono previste le seguenti limitazioni:

• App Engine riserva la capacità di scalabilità automatica per le applicazioni con una bassa latenza, in cui l'applicazione risponde alle richieste in meno di un secondo.

• Le applicazioni che richiedono un'elevata elaborazione della CPU possono anche presentare una latenza aggiuntiva per condividere in modo efficiente le risorse con altre applicazioni sugli stessi server. Le richieste di file statici sono esenti da questi limiti di latenza.

Ogni richiesta in arrivo all'applicazione viene conteggiata ai fini del limite di Richieste. I dati inviati in risposta a una richiesta vengono conteggiati ai fini del limite di larghezza di banda in uscita (fatturabile).

Sia le richieste HTTP che quelle HTTPS (sicure) vengono conteggiate ai fini dei limiti di Richieste, Larghezza di banda in entrata (fatturabile) e Larghezza di banda in uscita (fatturabile). La pagina dei dettagli delle quote della console Google Cloud riporta anche Richieste sicure, Larghezza di banda in entrata sicura e Larghezza di banda in uscita sicura come valori separati a scopo informativo. Solo le richieste HTTPS vengono conteggiate per questi valori. Per ulteriori informazioni, consulta la pagina Quote.

I seguenti limiti si applicano specificamente all'utilizzo dei gestori delle richieste:

Limite	Quantità
Dimensioni richiesta	32 megabyte
Dimensione della risposta	32 megabyte
Timeout richiesta	Dipende dal tipo di scalabilità utilizzato dalla tua app
Numero totale massimo di file (file dell'app e file statici)	10.000 in totale 1000 per directory
Dimensione massima di un file dell'applicazione	32 megabyte
Dimensione massima di un file statico	32 megabyte
Dimensioni totali massime di tutti i file di applicazioni e statici	I primi 1 GB sono gratuiti 0,026$ per GB al mese dopo i primi 1 GB
Timeout della richiesta in attesa	10 secondi
Dimensione massima di un singolo campo dell'intestazione della richiesta	8 kilobyte per i runtime di seconda generazione nell'ambiente standard. Le richieste a questi runtime con campi di intestazione superiori a 8 kilobyte restituiranno errori HTTP 400.

Limiti per le richieste

Tutte le richieste HTTP/2 verranno tradotte in richieste HTTP/1.1 quando vengono inoltrate al server dell'applicazione.

Limiti di risposta

• Le risposte dinamiche sono limitate a 32 MB. Se un gestore di script genera una risposta superiore a questo limite, il server restituisce una risposta vuota con un codice di stato 500 (Errore interno del server). Questa limitazione non si applica alle risposte che forniscono dati provenienti dall'archivio BLOB precedente o da Cloud Storage.

• Il limite di intestazione di risposta è 8 KB per i runtime di seconda generazione. Le intestazioni di risposta che superano questo limite restituiranno errori HTTP 502, con log che mostrano upstream sent too big header while reading response header from upstream.

Intestazioni delle richieste

Una richiesta HTTP in arrivo include le intestazioni HTTP inviate dal client. Per motivi di sicurezza, alcune intestazioni vengono sottoposte a sanificazione o modificate da proxy intermedi prima di raggiungere l'applicazione.

Per ulteriori informazioni, consulta la sezione Informazioni di riferimento sulle intestazioni delle richieste.

Gestione dei timeout delle richieste

App Engine è ottimizzato per le applicazioni con richieste di breve durata, tipicamente quelle che richiedono alcune centinaia di millisecondi. Un'app efficiente risponde rapidamente alla maggior parte delle richieste. Un'app che non lo fa non avrà una buona scalabilità con l'infrastruttura di App Engine. Per garantire questo livello di prestazioni, esiste un timeout della richiesta massimo imposto dal sistema entro il quale ogni app deve rispondere.

Se la tua app supera questa scadenza, App Engine interrompe il gestore delle richieste. Per i gestori delle richieste Go, il processo viene interrotto e l'ambiente di runtime restituisce al client un errore interno del server HTTP 500.

Risposte

App Engine chiama il gestore con un Request e un ResponseWriter, poi attende che il gestore scriva nel ResponseWriter e ritorni. Quando il gestore ritorna, i dati nel buffer interno di ResponseWriter vengono inviati all'utente.

È praticamente lo stesso che accade quando scrivi normali programmi Go che utilizzano il pacchettohttp.

Esistono limiti di dimensione che si applicano alla risposta generata e la risposta può essere modificata prima di essere restituita al client.

Per ulteriori informazioni, consulta la sezione Documentazione di riferimento per le risposte alle richieste.

Risposte dinamiche

App Engine non supporta le risposte in streaming in cui i dati vengono inviati al client in blocchi incrementali durante l'elaborazione di una richiesta. Tutti i dati del codice vengono raccolti come descritto sopra e inviati come singola risposta HTTP.

Compressione delle risposte

Per le risposte restituite dal codice, App Engine comprime i dati nella risposta se entrambe le seguenti condizioni sono vere:

• La richiesta contiene l'intestazione Accept-Encoding che include gzip come valore.
• La risposta contiene dati basati su testo, come HTML, CSS o JavaScript.

Per le risposte restituite da un gestori di directory o file statici di App Engine, i dati della risposta vengono compressi se tutte le seguenti condizioni sono vere:

• La richiesta include Accept-Encoding con gzip come uno dei suoi valori.
• Il client è in grado di ricevere i dati di risposta in un formato compresso. Il Frontend di Google gestisce un elenco di client noti per avere problemi con le risposte compresse. Questi client non riceveranno dati compressi dagli handler statici nella tua app, anche se le intestazioni di richiesta contengono Accept-Encoding: gzip.
• La risposta contiene dati basati su testo, come HTML, CSS o JavaScript.

Tieni presente quanto segue:

• Un client può forzare la compressione dei tipi di contenuti basati su testo impostando entrambe le intestazioni di richiesta Accept-Encoding e User-Agent su gzip.

• Se una richiesta non specifica gzip nell'intestazione Accept-Encoding, App Engine non comprimerà i dati di risposta.

• Il Frontend di Google memorizza nella cache le risposte dei gestori di directory e file statici di App Engine. A seconda di una serie di fattori, ad esempio il tipo di dati della risposta memorizzati nella cache per primo, le intestazioni Vary che hai specificato nella risposta e le intestazioni incluse nella richiesta, un client potrebbe richiedere dati compressi, ma ricevere dati non compressi e viceversa. Per maggiori informazioni, consulta Memorizzazione nella cache delle risposte.

Memorizzazione nella cache delle risposte

Il frontend di Google e potenzialmente il browser dell'utente e altri server proxy intermediari per la memorizzazione nella cache memorizzeranno nella cache le risposte della tua app come indicato dalle intestazioni di memorizzazione nella cache standard specificate nella risposta. Puoi specificare queste intestazioni di risposta tramite il tuo framework, direttamente nel codice o tramite gli handler di directory e file statici di App Engine.

In Google Frontend, la chiave della cache è l'URL completo della richiesta.

Memorizzazione nella cache dei contenuti statici

Per assicurarti che i clienti ricevano sempre contenuti statici aggiornati non appena vengono pubblicati, ti consigliamo di pubblicarli da directory con versioni, ad esempio css/v1/styles.css. Il Frontend di Google non convalida la cache (controlla la presenza di contenuti aggiornati) fino alla scadenza della cache. Anche dopo la scadenza della cache, questa non verrà aggiornata finché i contenuti dell'URL della richiesta non cambieranno.

Le seguenti intestazioni di risposta che puoi impostare in app.yaml influiscono su come e quando il Frontend di Google memorizza nella cache i contenuti:

• Cache-Control deve essere impostato su public affinché il frontend di Google memorizzi nella cache i contenuti. Potrebbe anche essere memorizzato nella cache dal frontend di Google, a meno che non specifichi un'istruzione Cache-Control private o no-store. Se non imposti questo header in app.yaml , App Engine lo aggiunge automaticamente per tutte le risposte gestite da un gestore di directory o file statico. Per ulteriori informazioni, consulta la sezione Intestazioni aggiunte o sostituite.

• Vary: per consentire alla cache di restituire risposte diverse per un URL in base agli intestazioni inviati nella richiesta, imposta uno o più dei seguenti valori nell'intestazione di risposta Vary:Accept, Accept-Encoding, Origin o X-Origin

  A causa della potenziale alta cardinalità, i dati non verranno memorizzati nella cache per altri valoriVary.

  Ad esempio:

  1. Specifica la seguente intestazione di risposta:

     Vary: Accept-Encoding

  2. La tua app riceve una richiesta che contiene l'intestazione Accept-Encoding: gzip. App Engine restituisce una risposta compressa e il frontend di Google memorizza nella cache la versione compressa con gzip dei dati della risposta. Tutte le richieste successive per questo URL che contengono l'intestazione Accept-Encoding: gzip riceveranno i dati compressi con gzip dalla cache fino a quando la cache non viene invalidata (a causa della modifica dei contenuti dopo la scadenza della cache).

  3. La tua app riceve una richiesta che non contiene l'intestazione Accept-Encoding. App Engine restituisce una risposta non compressa e Google Frontend memorizza nella cache la versione non compressa dei dati della risposta. Tutte le richieste successive per questo URL che non contengono l'intestazione Accept-Encoding riceveranno i dati compressi dalla cache finché la cache non diventa non valida.

  Se non specifichi un'intestazione di risposta Vary, il frontend di Google crea una singola voce della cache per l'URL e la utilizza per tutte le richieste, indipendentemente dalle intestazioni presenti nella richiesta. Ad esempio:

  1. Non specifichi l'intestazione della risposta Vary: Accept-Encoding.
  2. Una richiesta contiene l'intestazione Accept-Encoding: gzip e la versione compressa con gzip dei dati di risposta verrà memorizzata nella cache.
  3. Una seconda richiesta non contiene l'intestazione Accept-Encoding: gzip. Tuttavia, poiché la cache contiene una versione compressa con gzip dei dati di risposta, la risposta verrà compressa con gzip anche se il client ha richiesto dati non compressi.

Le intestazioni nella richiesta influiscono anche sulla memorizzazione nella cache:

• Se la richiesta contiene un'intestazione Authorization, i contenuti non verranno memorizzati nella cache dal frontend di Google.

Scadenza della cache

Per impostazione predefinita, le intestazioni di memorizzazione nella cache aggiunte ai gestori di directory e file statici di App Engine alle risposte ordinano ai client e ai proxy web, come il frontend di Google, di far scadere la cache dopo 10 minuti.

Dopo che un file è stato trasmesso con una determinata data e ora di scadenza, in genere non è possibile rimuoverlo dalle cache del proxy web, anche se l'utente svuota la cache del proprio browser. Il nuovo deployment di una nuova versione dell'app non reimposta le cache. Pertanto, se prevedi di modificare un file statico, deve avere un breve periodo di scadenza (meno di un'ora). Nella maggior parte dei casi, il valore predefinito di 10 minuti per la data e l'ora di scadenza è appropriato.

Puoi modificare la scadenza predefinita per tutti i gestori di file e directory statici specificando l'elemento default_expiration nel file app.yaml. Per impostare date di scadenza specifiche per i singoli gestori, specifica l'elemento expiration all'interno dell'elemento gestore nel file app.yaml.

Il valore specificato nell'elemento di scadenza verrà utilizzato per impostare le intestazioni di risposta HTTP Cache-Control e Expires.

Forzare le connessioni HTTPS

Per motivi di sicurezza, tutte le applicazioni devono incoraggiare i client a connettersi tramite https. Per indicare al browser di preferire https a http per una determinata pagina o per l'intero dominio, imposta l'intestazione Strict-Transport-Security nelle risposte. Ad esempio:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Per impostare questo intestazione per tutti i contenuti statici pubblicati dalla tua app, aggiungilo agli handler di file e directory statici della tua app.

Per impostare questa intestazione per le risposte generate dal tuo codice, utilizza il pacchetto secureheader.

Attenzione: i client che hanno ricevuto l'intestazione in passato rifiuteranno di connettersi se https non è funzionale o viene disattivato per qualsiasi motivo. Per saperne di più, consulta questo cheat sheet su HTTP Strict Transport Security.

Gestione del lavoro in background asincrono

Il lavoro in background è qualsiasi lavoro eseguito dalla tua app per una richiesta dopo che hai fornito la risposta HTTP. Evita di eseguire operazioni in background nella tua app e controlla il codice per assicurarti che tutte le operazioni asincrone vengano completate prima di inviare la risposta.

Per i job di lunga durata, consigliamo di utilizzare Cloud Tasks. Con Cloud Tasks, le richieste HTTP sono di lunga durata e restituiscono una risposta solo al termine di qualsiasi lavoro asincrono.

Avviso: l'esecuzione di attività in background asincrone può comportare una fatturazione più elevata. App Engine potrebbe eseguire lo scale up di istanze aggiuntive a causa di un carico elevato della CPU, anche se non ci sono richieste attive. Gli utenti potrebbero anche riscontrare un aumento della latenza a causa delle richieste in attesa nella coda in attesa di istanze disponibili.