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 il giorno
Febbraio 2020, REGION_ID.r è incluso in
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 il modo in cui l'applicazione App Engine riceve richieste e invia risposte. Per ulteriori dettagli, consulta la sezione Informazioni di riferimento sulle intestazioni delle richieste.
Se la tua applicazione utilizza i 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 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 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, ciò è vincolato dalle seguenti restrizioni:
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 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 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.
- Le dimensioni totali della richiesta sono limitate 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. Traffico proveniente dal carico viene inviato all'istanza tramite un canale criptato, quindi viene 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 memorizzate nel buffer da 64.000 blocchi.
- Le dimensioni della risposta sono illimitate.
- Il limite di tempo di risposta è di un'ora.
- Il limite di intestazione di risposta è 64 KB. Intestazioni della risposta che superano questo limite
restituirà errori HTTP 502 e i log mostrano
upstream sent too big header while reading response header from upstream.
Richieste HTTP non supportate
Le seguenti funzionalità non sono supportate da 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.
Disattivazione del buffering
Per impostazione predefinita, tutte le risposte da App Engine vengono memorizzate nel buffer in 64.000 blocchi. Nella
in alcuni casi potrebbe essere opportuno disattivare il buffering e trasmettere i byte direttamente in streaming
al cliente. Questa opzione è generalmente preferita quando si utilizzano richieste GET o server inutilizzati
Eventi inviati (SSE). Per disattivare il buffering, puoi impostare X-Accel-Buffering
intestazione della risposta a no.
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
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 lavori in background nell'app e rivedi il codice per assicurarti che tutte le operazioni asincrone vengano completate prima di la tua 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.