ID regione
REGION_ID
è un codice abbreviato assegnato da Google
in base alla regione selezionata al momento della creazione dell'app. Il codice non
corrispondono a un paese o a una provincia, anche se potrebbero essere visualizzati alcuni ID regione
in modo simile ai codici paese e provincia 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.
Questo documento descrive come l'applicazione App Engine riceve le richieste e invia le risposte.
Per ulteriori dettagli, consulta l'articolo Riferimento a intestazioni e risposte delle richieste.
Se la tua applicazione utilizza servizi, puoi indirizzare le richieste a un servizio specifico o a una versione specifica completamente gestito di Google Cloud. Per ulteriori informazioni sull'addressability dei servizi, consulta In che modo 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 instradata
a qualsiasi istanza, quindi le richieste consecutive dello stesso utente non sono necessariamente
inviati 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 in parallelo che un'istanza può gestire
impostando la classe max_concurrent_requests
nel file app.yaml.
http.Handler
associato all'URL della richiesta.
L'esempio seguente è un'app Go completa che genera una stringa HTML hardcoded all'utente:
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 bassa latenza, dove l'applicazione risponde alle richieste in meno di un secondo.
Le applicazioni che sono fortemente legate alla CPU possono inoltre subire una latenza aggiuntiva al fine di condividere in modo efficiente le risorse con altre applicazioni sulla stessa server web. 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 Larghezza di banda in uscita (fatturabile).
Sia le richieste HTTP che quelle HTTPS (protette) vengono conteggiate ai fini delle Richieste, delle Richieste in entrata. Limiti di larghezza di banda (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à usata dall'app |
Numero totale massimo di file (file dell'app e file statici) | 10.000 in totale 1.000 per directory |
Dimensione massima del file di un'applicazione | 32 megabyte |
Dimensione massima di un file statico | 32 megabyte |
Dimensione totale massima di tutti i file statici e dell'applicazione | 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 oltre questo limite, il server restituisce una risposta vuota con un valore Codice di stato di errore interno del server. Questo limite non si applica alle risposte che forniscono dati nell'archivio BLOB legacy 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 per motivi di sicurezza, alcune intestazioni vengono convalidate o modificate da proxy intermedi prima di raggiungere l'applicazione.
Per ulteriori informazioni, consulta Riferimento alle intestazioni delle richieste.
Gestione dei timeout delle richieste
App Engine è ottimizzato per applicazioni con richieste di breve durata, di solito quelle che impiegano qualche centinaio 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 una richiesta massima impostata dal sistema timeout a cui 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 conRequest
e ResponseWriter
,
quindi attende che il gestore scriva sul ResponseWriter
e riaggancia. Quando il gestore ritorna, i dati nel buffer interno di ResponseWriter
vengono inviati all'utente.
È praticamente la stessa cosa che scrivi quando scrivi normali programmi Go che usano
http
pacco.
Esistono limiti di dimensioni che si applicano alle risposte genera 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 modalità flusso quando i dati vengono inviati di chunk incrementali al client 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 includegzip
come un valore. - La risposta contiene dati basati su testo, come HTML, CSS o JavaScript.
Per le risposte restituite da un App Engine file statico o directory di rete, i dati di risposta vengono compressi se tutte le seguenti condizioni sono vere:
- La richiesta include
Accept-Encoding
congzip
come uno dei valori. - Il client è in grado di ricevere i dati della 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 sia delle intestazioni della richiesta
Accept-Encoding
eUser-Agent
agzip
.Se per una richiesta non è specificato
gzip
nell'intestazioneAccept-Encoding
, App Engine non comprime i dati di risposta.Il Frontend di Google memorizza nella cache le risposte dei gestori di directory e file statici di App Engine. In base a una serie di fattori, come il tipo di i dati delle risposte vengono prima memorizzati nella cache; le intestazioni
Vary
che hai specificato e quali intestazioni sono incluse nella richiesta, un client potrebbe richiedere che però ricevono 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 attraverso il tuo framework, direttamente o mediante il file statico e la directory di App Engine e i gestori di rete.
In Google Frontend, la chiave cache è l'URL completo della richiesta.
Memorizzazione nella cache dei contenuti statici
Per garantire che i clienti ricevano sempre i contenuti statici aggiornati non appena possibile.
pubblicata, ti consigliamo di pubblicare contenuti statici
come css/v1/styles.css
. Google Frontend non eseguirà la convalida
nella cache (verifica la presenza di contenuti aggiornati) fino alla scadenza. 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
impostato in
app.yaml
influenzano come e quando Google Frontend memorizza i contenuti nella cache:
Cache-Control
deve essere impostato supublic
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'istruzioneCache-Control
private
ono-store
. Se non imposti questo header inapp.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 a inviate nella richiesta, impostare uno o più dei seguenti valori nell'intestazione della rispostaVary
:Accept
,Accept-Encoding
,Origin
oX-Origin
A causa della potenziale alta cardinalità, i dati non verranno memorizzati nella cache per altri valori
Vary
.Ad esempio:
Specifica la seguente intestazione della risposta:
Vary: Accept-Encoding
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'intestazioneAccept-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).La tua app riceve una richiesta che non contiene
Accept-Encoding
intestazione. 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'intestazioneAccept-Encoding
riceveranno i dati compressi dalla cache finché la cache non diventa non valida.
Se non specifichi un'intestazione della risposta
Vary
, Google Frontend crea singola voce della cache per l'URL e la utilizzerà per tutte le richieste delle intestazioni nella richiesta. Ad esempio:- Non specifichi l'intestazione della risposta
Vary: Accept-Encoding
. - Una richiesta contiene l'intestazione
Accept-Encoding: gzip
e il file dei dati della risposta verrà memorizzata nella cache. - 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.
Anche le intestazioni della richiesta influiscono 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 viene trasmesso con una data di scadenza, in genere c'è non c'è modo di svuotarle dalle cache dei proxy web, anche se l'utente cancella i propri della propria cache del 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
default_expiration
in
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
https
. Per indicare al browser di preferire https
rispetto a http
per una determinata pagina
o un intero dominio, imposta l'intestazione Strict-Transport-Security
nelle risposte.
Ad esempio:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Per impostare questa intestazione per le risposte generate dal codice, utilizza il metodo
Pacchetto secureheader
.
Gestione asincroni in background
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 hanno una lunga durata e restituiscono solo una risposta al termine del lavoro asincrono.