ID da região
O REGION_ID é um código abreviado que o Google atribui
com base na região que você selecionou ao criar o aplicativo. O código não
corresponde a um país ou estado, ainda que alguns IDs de região sejam semelhantes
aos códigos de país e estado geralmente usados. Para apps criados após
fevereiro de 2020, o REGION_ID.r está incluído nos
URLs do App Engine. Para apps existentes criados antes dessa data, o
ID da região é opcional no URL.
Saiba mais sobre IDs de região.
Este documento descreve como um aplicativo do App Engine recebe solicitações e envia respostas. Para mais detalhes, consulte a referência Cabeçalhos de solicitação.
Se o aplicativo usa serviços, é possível endereçar solicitações para um serviço específico ou uma versão determinada desse serviço. Para mais informações sobre a capacidade de endereçamento do serviço, consulte Como as solicitações são encaminhadas.
Como processar solicitações
O aplicativo é responsável por iniciar um servidor da Web e processar as solicitações. Você pode usar qualquer biblioteca da Web disponível na linguagem de programação que adotou.
Várias instâncias do aplicativo são executadas no App Engine, e cada uma tem um servidor da Web próprio para processar as solicitações. Como cada solicitação pode ser encaminhada para qualquer instância, solicitações consecutivas do mesmo usuário não são necessariamente enviadas para a mesma instância. Uma instância pode processar várias solicitações simultaneamente. O número de instâncias pode ser ajustado automaticamente, à medida que o tráfego muda.
Cotas e limites
No App Engine, os recursos são alocados automaticamente para o aplicativo à medida que o tráfego aumenta. No entanto, isso é limitado pelas seguintes restrições:
O App Engine reserva a capacidade de escalonamento automático para aplicativos com baixa latência, em que a resposta a uma solicitação ocorre em menos de um segundo.
Aplicativos que fazem muito uso da CPU podem gerar mais latência, a fim de compartilhar recursos de maneira eficiente com outros aplicativos nos mesmos servidores. Solicitações de arquivos estáticos estão isentas dos limites de latência.
Cada solicitação recebida para o aplicativo é contabilizada no limite de Solicitações. Os dados enviados em resposta a uma solicitação são contabilizados no limite de Largura de banda de saída (faturável).
Tanto as solicitações HTTP quanto as HTTPS (seguras) são contabilizadas nos limites de Solicitações, Largura de banda de entrada (faturável) e Largura de banda de saída (faturável). A página "Detalhes da cota" do console do Google Cloud também exibe Solicitações seguras, largura de banda de entrada segura e largura de banda de saída segura como valores separados para fins informativos. Apenas solicitações HTTPS são contabilizadas nesses valores. Para mais informações, consulte a página Cotas.
Os limites a seguir se aplicam especificamente ao uso de manipuladores de solicitações:
Limites de solicitações
- É permitido usar no máximo aproximadamente 15 KB nos cabeçalhos das solicitações.
- O tamanho total da solicitação está limitado a aproximadamente 32 MB.
- Todas as solicitações em HTTP/2 são traduzidas para HTTP/1.1 quando encaminhadas para o servidor do aplicativo.
- As conexões SSL terminam no balanceador de carga. O tráfego do balanceador de carga é enviado para a instância por meio de um canal criptografado e, em seguida, encaminhado para o servidor do aplicativo por HTTP. Com o cabeçalho X-Forwarded-Proto, é possível saber se a solicitação de origem era HTTP ou HTTPS.
Limites de respostas
- As respostas são armazenadas em buffer por blocos de 64 KB.
- O tamanho da resposta é ilimitado.
- O limite de tempo de resposta é de uma hora.
- O limite do cabeçalho de resposta é de 64 KB. Os cabeçalhos de resposta que excederem esse limite retornarão erros HTTP 502, com
registros que mostram
upstream sent too big header while reading response header from upstream.
Solicitações HTTP não compatíveis
Os recursos a seguir não são compatíveis com o ambiente flexível do App Engine:
- Tráfego HTTP/2 para o serviço de back-end
- Solicitações HTTP com acesso direto às instâncias
Cabeçalhos de solicitação
Uma solicitação HTTP recebida inclui os cabeçalhos HTTP enviados pelo cliente. Para fins de segurança, alguns cabeçalhos são limpos ou retificados por proxies intermediários antes de chegarem ao aplicativo.
Para mais informações, consulte a referência sobre cabeçalhos de solicitação.
Como desativar o armazenamento em buffer
Por padrão, todas as respostas do App Engine são armazenadas em buffer por blocos de 64 KB. Em alguns casos, será útil desativar o armazenamento em buffer e fazer streaming dos bytes diretamente para o cliente. Geralmente, é preferível fazer isso ao usar GETs pendentes ou eventos enviados pelo servidor (SSEs, na sigla em inglês). Para desativar o armazenamento em buffer, defina o cabeçalho da resposta X-Accel-Buffering como no.
Como forçar conexões HTTPS
Por motivos de segurança, todos os aplicativos precisam incentivar os clientes a
se conectar por https. Para instruir o navegador a preferir https a http em uma determinada página
ou em todo o domínio, defina o cabeçalho Strict-Transport-Security nas respostas.
Por exemplo:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Como gerenciar o trabalho em segundo plano assíncrono
O trabalho em segundo plano é qualquer trabalho que seu aplicativo execute para uma solicitação depois de ter entregado a resposta HTTP. Evite executar trabalhos em segundo plano no aplicativo e revise seu código para verificar se todas as operações assíncronas foram concluídas antes de enviar a resposta.
Para jobs de longa duração, recomendamos o uso do Cloud Tasks. Com o Cloud Tasks, as solicitações HTTP têm longa duração e retornam uma resposta somente após o término de qualquer trabalho assíncrono.