ID regione
REGION_ID è un codice abbreviato assegnato da Google in base alla regione selezionata al momento della creazione dell'app. Non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono apparire 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 regione è facoltativo nell'URL.
Scopri di più sugli ID regione.
Questo documento descrive come l'applicazione App Engine riceve richieste e invia risposte. Per maggiori dettagli, consulta la sezione Riferimento alle 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 maggiori informazioni sull'indirizzabilità dei servizi, consulta Modalità di routing delle richieste.
Gestione delle richieste
La tua 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, ognuna con 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 inviate necessariamente 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 limitazioni:
App Engine riserva una capacità di scalabilità automatica per le applicazioni a bassa latenza, in cui l'applicazione risponde alle richieste in meno di un secondo.
Le applicazioni molto legate alla CPU possono 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 nell'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).
Entrambe le richieste HTTP e 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 della console Google Cloud segnala anche le Richieste sicure, la 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'uso 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 saranno tradotte in richieste HTTP/1.1 quando inoltrate al server delle applicazioni.
- Le connessioni SSL terminano al bilanciatore del carico. Il traffico proveniente dal bilanciatore del carico viene inviato all'istanza tramite un canale criptato, quindi 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 da 64.000 blocchi.
- Le dimensioni della risposta sono illimitate.
- Il tempo di risposta è di un'ora.
- Il limite per le intestazioni delle risposte è di 64 kB. Le intestazioni di risposta che superano questo limite restituiranno 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 dall'ambiente flessibile di App Engine:
- il 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 controllate o modificate da proxy intermedi prima che raggiungano l'applicazione.
Per ulteriori informazioni, consulta la sezione Riferimento alle intestazioni delle richieste.
Disattivazione del buffering in corso...
Per impostazione predefinita, il buffer di tutte le risposte di App Engine viene eseguito in blocchi da 64.000. In
alcuni casi, potrebbe essere opportuno disabilitare il buffering e trasmettere direttamente i byte
al client. Questa è in genere l'opzione preferita per l'utilizzo di GET inutilizzati o di eventi inviati dal server (SSE). Per disabilitare 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 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 in background asincrono
Per lavoro in background si intende qualsiasi operazione eseguita dalla tua app per una richiesta dopo l'invio della risposta HTTP. Evita di eseguire operazioni in background nell'app ed esamina il codice per assicurarti che tutte le operazioni asincrone vengano completate prima di consegnare la risposta.
Per i job a lunga esecuzione, consigliamo di utilizzare Cloud Tasks. Con Cloud Tasks, le richieste HTTP durano a lungo e restituiscono una risposta solo al termine di qualsiasi lavoro asincrono.