Modalità di gestione delle richieste

Go Java Node.js PHP Python Ruby

ID regione

Il REGION_ID è un codice abbreviato che Google assegna 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 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 Intestazioni e risposte delle richieste.

Se la tua applicazione utilizza servizi, puoi indirizzare le richieste a un servizio specifico o a una versione specifica di quel servizio. Per saperne di più sull'indirizzabilità del servizio, consulta Come vengono instradate le richieste.

Gestione delle richieste

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

App Engine esegue più istanze dell'applicazione e ogni istanza ha il proprio server web per la gestione delle richieste. Qualsiasi richiesta può essere indirizzata a qualsiasi istanza, quindi 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 tuo file app.yaml, o nel file appengine-web.xml se utilizzi i servizi in bundle legacy di App Engine.

L'esempio seguente è uno script Python che risponde a qualsiasi richiesta HTTP con il messaggio "Hello World!".

# Copyright 2018 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

from flask import Flask


# If `entrypoint` is not defined in app.yaml, App Engine will look for an app
# called `app` in `main.py`.
app = Flask(__name__)


@app.route("/")
def hello():
    """Return a friendly HTTP greeting.

    Returns:
        A string with the words 'Hello World!'.
    """
    return "Hello World!"


if __name__ == "__main__":
    # This is used when running locally only. When deploying to Google App
    # Engine, a webserver process such as Gunicorn will serve the app. You
    # can configure startup instructions by adding `entrypoint` to app.yaml.
    app.run(host="127.0.0.1", port=8080, debug=True)

Quote e limiti

App Engine alloca automaticamente le risorse alla tua applicazione man mano che il traffico aumenta. Tuttavia, questa operazione è vincolata alle seguenti limitazioni:

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

• Le applicazioni che utilizzano molto la CPU potrebbero anche comportare 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 entrata 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).

Le richieste HTTP e HTTPS (sicure) vengono conteggiate ai fini dei limiti di Richieste, Larghezza di banda in entrata (fatturabile) e Larghezza di banda in uscita (fatturabile). La Google Cloud console Pagina Dettagli quota 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 sono applicabili 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 totali 1000 per directory
Dimensione massima di un file dell'applicazione	32 megabyte
Dimensione massima di un file statico	32 megabyte
Dimensione totale massima di tutti i file statici e dell'applicazione	Il primo gigabyte è gratuito $ 0,026 per gigabyte al mese dopo il primo gigabyte
Timeout della richiesta in attesa	10 secondi
Dimensione massima di un singolo campo di 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 convertite in richieste HTTP/1.1 quando vengono inoltrate al server delle applicazioni.

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 invia una risposta vuota con un codice di stato 500 Errore interno del server. Questa limitazione non si applica alle risposte che forniscono dati da Cloud Storage o dall'API Blobstore precedente, se disponibile nel runtime.

• Il limite dell'intestazione della risposta è di 8 KB per gli 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 entrata include le intestazioni HTTP inviate dal client. Per motivi di sicurezza, alcune intestazioni vengono sanificate o modificate da proxy intermedi prima di raggiungere l'applicazione.

Per saperne di più, consulta la documentazione di riferimento delle intestazioni delle richieste.

Gestione dei timeout delle richieste

App Engine è ottimizzato per le applicazioni con richieste di breve durata, in genere quelle che richiedono poche centinaia di millisecondi. Un'app efficiente risponde rapidamente alla maggior parte delle richieste. Un'app che non risponde rapidamente non verrà scalata correttamente con l'infrastruttura di App Engine. Per garantire questo livello di prestazioni, esiste un timeout della richiesta massimo imposto dal sistema a cui ogni app deve rispondere.

Se la tua app supera questa scadenza, App Engine interrompe il gestore di richieste.

Risposte

App Engine chiama lo script del gestore con un Request e attende che lo script restituisca un valore. Tutti i dati scritti nel flusso di output standard vengono inviati come risposta HTTP.

Esistono limiti di dimensioni che si applicano alla risposta che generi e la risposta potrebbe essere modificata prima di essere restituita al client.

Per maggiori informazioni, consulta il riferimento Risposte alle richieste.

Risposte dinamiche

App Engine non supporta le risposte in streaming in cui i dati vengono inviati in blocchi 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 tuo codice, App Engine comprime i dati nella risposta se sono vere entrambe le seguenti condizioni:

• 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 gestore di file o directory statici di App Engine, i dati di risposta vengono compressi se sono vere tutte le seguenti condizioni:

• 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. Google Front End (GFE) gestisce un elenco di client noti per avere problemi con le risposte compresse. Questi client non riceveranno dati compressi dai gestori statici nella tua app, anche se le intestazioni delle richieste 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 della richiesta Accept-Encoding e User-Agent su gzip.

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

• Il Google Front End memorizza nella cache le risposte dei gestori di file statici e delle directory di App Engine. A seconda di una serie di fattori, ad esempio il tipo di dati di risposta memorizzati nella cache per primi, le intestazioni Vary specificate 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 front-end di Google e potenzialmente il browser dell'utente e altri server proxy di memorizzazione nella cache intermedi memorizzeranno nella cache le risposte della tua app come indicato dalle intestazioni di memorizzazione nella cache standard che specifichi nella risposta. Puoi specificare queste intestazioni di risposta tramite il framework, direttamente nel codice o tramite i gestori di file e directory statici di App Engine.

Nel Google Front End (GFE), la chiave della cache è l'URL completo della richiesta.

Memorizzazione nella cache dei contenuti statici

Per garantire che i client ricevano sempre contenuti statici aggiornati non appena vengono pubblicati, ti consigliamo di pubblicare contenuti statici da directory con controllo delle versioni, ad esempio css/v1/styles.css. Il front-end di Google non convaliderà la cache (non controllerà la presenza di contenuti aggiornati) finché non scade. Anche dopo la scadenza della cache, questa non verrà aggiornata finché i contenuti dell'URL della richiesta non cambiano.

Le seguenti intestazioni di risposta che puoi impostare in app.yaml influenzano il modo e il momento in cui il Google Front End (GFE) memorizza nella cache i contenuti:

• Cache-Control deve essere impostato su public affinché il Google Front End (GFE) memorizzi nella cache i contenuti; questi ultimi potrebbero anche essere memorizzati nella cache dal Google Front End (GFE), a meno che tu non specifichi un'istruzione Cache-Control private o no-store. Se non imposti questa intestazione in app.yaml, App Engine la aggiunge automaticamente a tutte le risposte gestite da un gestore di file o directory statici. Per ulteriori informazioni, consulta la sezione Intestazioni aggiunte o sostituite.

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

  A causa della potenziale cardinalità elevata, i dati non verranno memorizzati nella cache per altri valori di Vary.

  Ad esempio:

  1. Specifica la seguente intestazione della 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 Google Front End (GFE) memorizza nella cache la versione gzipped dei dati di risposta. Tutte le richieste successive per questo URL che contengono l'intestazione Accept-Encoding: gzip riceveranno i dati compressi con gzip dalla cache finché 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 di risposta. Tutte le richieste successive per questo URL che non contengono l'intestazione Accept-Encoding ricevono dati non compressi dalla cache finché la cache non viene invalidata.

  Se non specifichi un'intestazione di risposta Vary, il Google Front End (GFE) crea una singola voce della cache per l'URL e la utilizza per tutte le richieste, indipendentemente dalle intestazioni della 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.

Anche le intestazioni della richiesta influiscono sulla memorizzazione nella cache:

• Se la richiesta contiene un'intestazione Authorization, i contenuti non verranno memorizzati nella cache daGoogle Front End (GFE)d.

Scadenza della cache

Per impostazione predefinita, le intestazioni di memorizzazione nella cache che i gestori di file statici e directory di App Engine aggiungono alle risposte indicano ai client e ai proxy web, come Google Front End (GFE), di scadere la cache dopo 10 minuti.

Una volta trasmesso un file con un determinato tempo di scadenza, in genere non è possibile cancellarlo dalle cache dei proxy web, anche se l'utente svuota la cache del browser. Il redeployment di una nuova versione dell'app non reimposta le cache. Pertanto, se prevedi di modificare un file statico, questo deve avere un tempo di scadenza breve (inferiore a un'ora). Nella maggior parte dei casi, il tempo di scadenza predefinito di 10 minuti è appropriato.

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

Il valore specificato nell'ora degli elementi di scadenza verrà utilizzato per impostare le intestazioni della 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 questa intestazione per qualsiasi contenuto statico pubblicato dalla tua app, aggiungi l'intestazione ai gestori di file e directory statici dell'app.

Per impostare questa intestazione per le risposte generate dal tuo codice, utilizza la libreria flask-talisman.

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

Gestione del lavoro asincrono in background

Il lavoro in background è qualsiasi lavoro che la tua app esegue per una richiesta dopo aver fornito la risposta HTTP. Evita di eseguire operazioni in background nell'app e controlla il codice per assicurarti che tutte le operazioni asincrone terminino prima di inviare la risposta.

Per i job a esecuzione prolungata, 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 operazioni asincrone in background può comportare una fatturazione più elevata. App Engine potrebbe scalare istanze aggiuntive a causa del carico elevato della CPU, anche se non ci sono richieste attive. Gli utenti potrebbero anche riscontrare una maggiore latenza a causa delle richieste in attesa nella coda in sospeso per le istanze disponibili.

Priorità della coda in attesa di App Engine

Durante i periodi di traffico intenso, App Engine potrebbe inserire le richieste in una coda in attesa di un'istanza disponibile con la seguente priorità:

• App Engine dà la priorità alle altre richieste in coda rispetto a quelle in attesa in coda dalla coda delle attività. Anche le richieste da App Engine Cloud Tasks condividono questo comportamento di priorità della coda in attesa per motivi di compatibilità.

• All'interno della coda in attesa, App Engine tratta le richieste provenienti da Cloud Tasks con target HTTP come traffico HTTP normale. Le richieste di destinazione HTTP non hanno una priorità inferiore.

• Quando un servizio riceve traffico HTTP standard a volume elevato e serve anche traffico di Task Queue o Cloud Tasks a volume molto inferiore, l'impatto sulla latenza del traffico di Task Queue o Cloud Tasks è sproporzionato. Ti consigliamo di dividere i tipi di traffico in versioni separate o di utilizzare attività di destinazione HTTP per evitare la messa in coda prioritaria. Devi anche prendere in considerazione la possibilità di gestire le richieste sensibili alla latenza da Cloud Tasks con una versione principale o un servizio dedicati.