ID regione
REGION_ID è un codice abbreviato assegnato da Google in base
all'area geografica selezionata al momento della creazione dell'app. Il codice non
corrisponde a un paese o a una provincia, anche se alcuni ID di area geografica potrebbero essere
simili ai codici di 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 area geografica è facoltativo nell'URL.
Scopri di più sugli ID dell'area geografica.
Questo documento descrive il modo in cui l'applicazione App Engine riceve le richieste e invia le risposte. Per maggiori dettagli, consulta il riferimento per le 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 Modalità di routing delle 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 dell'applicazione e ogni istanza dispone di un proprio server web per la gestione delle richieste. Qualsiasi richiesta può essere instradata 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 modificato automaticamente in base alle variazioni del traffico.
Quote e limiti
App Engine alloca automaticamente le risorse all'applicazione in base all'aumento del traffico. Tuttavia, ciò è vincolato dalle seguenti limitazioni:
App Engine prenota 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 fortemente associate alla CPU possono inoltre 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 per l'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 HTTPS (protette) vengono conteggiate ai fini dei limiti Richieste, Larghezza di banda in entrata (fatturabile) e Larghezza di banda in uscita (fatturabile). La pagina dei dettagli delle quote di Cloud Console indica 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 in modo specifico all'utilizzo dei gestori di richieste:
Limiti per le richieste
- Nelle intestazioni delle richieste è consentito un massimo di 15 kB.
- La dimensione totale della richiesta è limitata a 32 MB.
- Tutte le richieste HTTP/2 verranno tradotte in richieste HTTP/1.1 quando inoltrate al server di applicazioni.
- Le connessioni SSL terminano al bilanciatore del carico. Il traffico del bilanciatore del carico viene inviato all'istanza tramite un canale criptato, quindi inoltrato al server delle applicazioni su HTTP. L'intestazione X-Forwarded-Proto ti consente di comprendere se la richiesta di origine era HTTP o HTTPS.
Limiti di risposta
- Le risposte vengono memorizzate nel buffer da 64.000 blocchi.
- La dimensione della risposta è illimitata.
- Il limite di tempo di risposta è di un'ora.
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 entrata include le intestazioni HTTP inviate dal client. Per motivi di sicurezza, alcune intestazioni vengono purificate o modificate da proxy intermedi prima che raggiungano l'applicazione.
Per ulteriori informazioni, consulta il riferimento per le intestazioni delle richieste.
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 rispetto 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
Per lavoro in background si intende qualsiasi lavoro eseguito dalla tua app per una richiesta dopo che hai consegnato la risposta HTTP. Evita di eseguire operazioni in background nell'app ed esamina il codice per assicurarti che tutte le operazioni asincrone siano completate prima di inviare la risposta.
Per i job a lunga esecuzione, consigliamo di utilizzare Cloud Tasks. Con Cloud Tasks, le richieste HTTP sono a lungo termine e restituiscono una risposta solo al termine di un lavoro asincrono.