Como as solicitações são tratadas

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. É possível usar qualquer framework da Web disponível na linguagem de programação adotada.

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. Este é um aplicativo Flask com um arquivo e muito básico que responde a todas as solicitações de clientes da Web para o caminho raiz ('/') por meio da exibição da mensagem "Hello, world!".

from flask import Flask

app = Flask(__name__)

@app.route('/')
def hello():
    """Return a friendly HTTP greeting."""
    return 'Hello World!'

if __name__ == '__main__':
    # This is used when running locally only. When deploying to Google App
    # Engine, a webserver process such as Gunicorn will serve the app.
    app.run(host='127.0.0.1', port=8080, debug=True)

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.

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 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. Exemplo:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Se quiser definir esse cabeçalho para respostas geradas a partir do seu código, use a biblioteca flask-talisman.

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.