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.
Questo documento descrive come l'applicazione App Engine riceve le richieste e invia le risposte. Per ulteriori dettagli, consulta la sezione Informazioni di riferimento sulle intestazioni 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 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.
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:
Limiti per le richieste
- È consentito un massimo di circa 15 KB nelle intestazioni della richiesta.
- La dimensione totale della richiesta è limitata a circa 32 MB.
- Tutte le richieste HTTP/2 verranno tradotte in richieste HTTP/1.1 quando vengono inoltrate al server dell'applicazione.
- Le connessioni SSL terminano al bilanciatore del carico. Il traffico dal bilanciatore del carico viene inviato all'istanza tramite un canale criptato e poi inoltrato al server delle applicazioni tramite HTTP. L'intestazione X-Forwarded-Proto consente di capire se la richiesta di origine era HTTP o HTTPS.
Limiti di risposta
- Le risposte vengono messe in buffer per blocchi di 64 KB.
- Le dimensioni della risposta sono illimitate.
- Il limite di tempo di risposta è di un'ora.
- Il limite di intestazione di risposta è 64 KB. Le intestazioni di risposta che superano questo limite
restituiranno errori HTTP 502, con i log che mostrano
upstream sent too big header while reading response header from upstream.
Richieste HTTP non supportate
Le seguenti funzionalità non sono supportate dall'ambiente flessibile di App Engine:
- Traffico HTTP/2 verso il servizio di backend.
- Richieste HTTP che accedono direttamente alle istanze.
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.
Disattivare il buffering
Per impostazione predefinita, tutte le risposte di App Engine vengono messe in buffer in blocchi di 64 KB. In alcuni casi, potrebbe essere opportuno disattivare il buffering e trasmettere direttamente i byte al client. In genere, questa opzione è preferita quando si utilizzano richieste GET inutilizzate o eventi inviati dal server (SSE). Per disattivare il buffering, puoi impostare l'intestazione della risposta X-Accel-Buffering su no.
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
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.