Como as solicitações são tratadas

ID da região

O REGION_ID é um código que o Google atribui com base na região selecionada ao criar o aplicativo. A inclusão de REGION_ID.r nos URLs do App Engine é opcional para aplicativos atuais e em breve será obrigatória para todos os aplicativos novos.

Para garantir uma transição tranquila, estamos atualizando lentamente o App Engine para usar códigos da região. Se ainda não tivermos atualizado seu projeto do Google Cloud, você não verá um ID da região para o aplicativo. Como o ID é opcional para os aplicativos atuais, não é necessário atualizar os URLs ou fazer outras alterações quando o ID da região está disponível para os aplicativos já existentes.

Saiba mais sobre IDs da região.

Este documento descreve como um aplicativo do App Engine recebe solicitações e envia respostas. Para saber mais, 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!".

import logging

from flask import Flask

app = Flask(__name__)

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

@app.errorhandler(500)
def server_error(e):
    logging.exception('An error occurred during a request.')
    return """
    An internal error occurred: <pre>{}</pre>
    See logs for full stacktrace.
    """.format(e), 500

if __name__ == '__main__':
    # This is used when running locally. Gunicorn is used to run the
    # application on Google App Engine. See entrypoint in app.yaml.
    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, há as 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 com latência muito alta exigem suporte Silver, Gold ou Platinum. Por exemplo, latência de mais de um segundo por solicitação no caso de muitas solicitações. Os clientes com esses níveis de suporte podem entrar em contato com nossos representantes para solicitar limites de capacidade mais altos.

  • 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 em HTTP quanto em HTTPS (seguro) contabilizam 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 Cloud também informa 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 são encerradas 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 alterados por proxies intermediários antes de chegar ao aplicativo.

For saber more, consulte a referência sobre Cabeçalhos de solicitação.

Respostas a solicitações

O App Engine chama o script do gerenciador com um Request e espera o retorno do script. Todos os dados gravados no fluxo de saída padrão são enviados como a resposta HTTP.

Existem limites que se aplicam à resposta gerada e a resposta pode ser modificada antes de ser retornada ao cliente.

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.

X-Accel-Buffering: no

Como forçar conexões HTTPS

Por motivos de segurança, todos os aplicativos precisam incentivar os clientes a se conectar por https. É possível usar o cabeçalho Strict-Transport-Security para instruir o navegador a preferir https a http em uma determinada página ou em um domínio inteiro. Por exemplo:

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

É possível usar a biblioteca flask-talisman (em inglês) que processa a configuração de cabeçalhos de segurança HTTP.