ID regione
Il REGION_ID è un codice abbreviato che Google assegna
in base alla regione selezionata durante la creazione dell'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.
Questo documento descrive come l'applicazione App Engine riceve le richieste e invia le risposte. Per maggiori dettagli, consulta la documentazione di riferimento delle 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'indirizzabilità del servizio, vedi 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 modificato 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, 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 con un elevato utilizzo della 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. Ai fini di questi valori, vengono conteggiate solo le richieste HTTPS. 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 delle richieste.
- La dimensione totale della richiesta è limitata a circa 32 MB.
- Tutte le richieste HTTP/2 verranno convertite in richieste HTTP/1.1 quando vengono inoltrate al server delle applicazioni.
- 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 ti consente di capire se la richiesta di origine era HTTP o HTTPS.
Limiti di risposta
- Le risposte vengono memorizzate nel buffer in blocchi da 64 KB.
- Le dimensioni della risposta sono illimitate.
- Il limite di tempo per rispondere è di un'ora.
- Il limite dell'intestazione della risposta è 64 KB. 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.
Richieste HTTP non supportate
Le seguenti funzionalità non sono supportate dall'ambiente flessibile di App Engine:
- Traffico HTTP/2 al servizio di backend.
- Richieste HTTP che accedono direttamente alle istanze.
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 ulteriori informazioni, consulta la Guida di riferimento delle intestazioni delle richieste.
Disattivazione del buffering
Per impostazione predefinita, tutte le risposte di App Engine vengono memorizzate nel buffer in blocchi da 64 kB. In
alcuni casi, potrebbe essere opportuno disattivare il buffering e trasmettere direttamente i byte
al client. Questa opzione è generalmente preferita quando si utilizzano GET sospese o Server
Sent Events (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 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 nella tua app e controlla il codice per assicurarti che tutte le operazioni asincrone terminino prima di fornire 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.