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, embora alguns IDs de região sejam semelhantes aos códigos de país e estado mais usados. A inclusão de REGION_ID.r em URLs do App Engine é opcional para aplicativos que já existem e, em breve, será obrigatória para todos os aplicativos novos.

Para garantir uma transição tranquila, estamos atualizando gradativamente o App Engine para usar IDs de região. Se ainda não tivermos atualizado seu projeto do Google Cloud, você não verá um ID de 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 de região está disponível para os aplicativos atuais.

Saiba mais sobre IDs da região.

Neste documento, descrevemos como um aplicativo do App Engine recebe solicitações e envia respostas. Para mais detalhes, consulte a referência sobre respostas e 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 roteadas.

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. Também é possível alterar o número de solicitações simultâneas que uma instância pode processar. Basta configurar o elemento max_concurrent_requests no arquivo app.yaml.

O servidor determina qual script de gerenciador PHP será executado comparando o URL da solicitação com os padrões de URL no arquivo de configuração app.yaml do aplicativo. Em seguida, o script preenchido com os dados da solicitação é executado. Os dados da solicitação são colocados em variáveis de ambiente e no stream de entrada padrão pelo servidor. As ações apropriadas à solicitação são executadas e uma resposta é preparada e colocada no stream de saída padrão.

O exemplo a seguir é de um script PHP para responder a qualquer solicitação HTTP com a mensagem "Hello World!"

<?php

echo "hello world!";

No exemplo a seguir, o Slim Framework é usado para responder a uma solicitação HTTP.

$app = new Slim\App();
$app->get('/', function ($request, $response) {
    // Use the Null Coalesce Operator in PHP7
    // http://php.net/manual/en/language.operators.comparison.php#language.operators.comparison.coalesce
    $name = $request->getQueryParams()['name'] ?? 'World';
    return $response->getBody()->write("Hello, $name!");
});
$app->run();

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 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) 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 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 gerenciadores de solicitações:

Limite Valor
tamanho da solicitação 32 megabytes
tamanho da resposta 32 megabytes
tempo limite da solicitação depende do tipo de escalonamento usado pelo aplicativo
número máximo total de arquivos (arquivos de aplicativos e arquivos estáticos) 10.000 no total
1.000 por diretório
tamanho máximo de um arquivo de aplicativo 32 megabytes
tamanho máximo de um arquivo estático 32 megabytes
tamanho máximo total de todos os arquivos de aplicativo e arquivos estáticos o primeiro 1 gigabyte é gratuito
US$ 0,026 por gigabyte por mês após o primeiro 1 gigabyte

Limites de respostas

As respostas dinâmicas são limitadas a 32 MB. Se um gerenciador de script gerar uma resposta maior do que esse limite, o servidor devolverá uma resposta vazia com um código de status 500 Erro interno do servidor. Essa limitação não se aplica a respostas que disponibilizam dados do Cloud Storage

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.

Para mais informações, consulte a referência sobre cabeçalhos de solicitação.

Como especificar um prazo para solicitação

O App Engine é otimizado para aplicativos com solicitações de curta duração, normalmente aquelas que levam poucas centenas de milissegundos. Aplicativos eficientes respondem com rapidez à maioria das solicitações. Caso contrário, o aplicativo não escalonará bem com a infraestrutura do App Engine.

Um script PHP tem um período limitado para gerar e retornar uma resposta a uma solicitação. Assim que o prazo é alcançado, o bit TIMEOUT do bitfield status da conexão (em inglês) é definido. O script terá então um segundo prazo curto para limpar qualquer tarefa de execução longa e retornar uma resposta ao usuário.

Se o script não tiver retornado uma resposta no final do segundo prazo, o gerenciador será finalizado e uma resposta de erro padrão será retornada.

Respostas

O App Engine chama o script com a matriz $_REQUEST preenchida, armazena em buffer qualquer saída do script e, quando a execução do script é concluída, envia a saída em buffer para o usuário final.

Existem limites de tamanho que se aplicam à resposta gerada. Além disso, essa resposta pode ser modificada antes de retornar ao cliente.

Para mais informações, consulte a referência sobre respostas a solicitações.

Respostas de streaming

O App Engine não é compatível com respostas de streaming em que os dados são enviados em blocos incrementais para o cliente enquanto uma solicitação está sendo processada. Todos os dados do seu código são coletados conforme descrito acima e enviados como uma única resposta HTTP.

Compactação de resposta

Para respostas retornadas pelo código, o App Engine compacta os dados na resposta se ambas as condições a seguir forem verdadeiras:

  • A solicitação contém o cabeçalho Accept-Encoding que inclui gzip como um valor.
  • A resposta contém dados baseados em texto, como HTML, CSS ou JavaScript.

Para respostas retornadas por um arquivo estático ou gerenciador de diretórios do App Engine, os dados de resposta serão compactados se todas as seguintes condições forem verdadeiras:

  • A solicitação inclui Accept-Encoding com gzip como um dos valores.
  • O cliente é capaz de receber os dados de resposta em um formato compactado. O Google Frontend mantém uma lista de clientes que têm problemas com respostas compactadas. Esses clientes não receberão dados compactados de gerenciadores estáticos no seu aplicativo, mesmo que os cabeçalhos de solicitação contenham Accept-Encoding: gzip.
  • A resposta contém dados baseados em texto, como HTML, CSS ou JavaScript.

Observe o seguinte:

  • Um cliente pode forçar a compactação de tipos de conteúdo baseados em texto, definindo os cabeçalhos de solicitação Accept-Encoding e User-Agent como gzip.

  • Se uma solicitação não especificar gzip no cabeçalho Accept-Encoding, o App Engine não compactará os dados de resposta.

  • O Google Frontend armazena em cache as respostas dos gerenciadores de arquivos e diretórios estáticos do App Engine. Dependendo de diversos fatores, como qual tipo de dados de resposta é armazenado em cache primeiro, quais cabeçalhos Vary são especificados na resposta e quais cabeçalhos estão incluídos na solicitação, o cliente pode solicitar dados compactados e receber dados não compactados e vice-versa. Para mais informações, consulte Cache de resposta.

Armazenamento de respostas em cache

O Google Frontend e, possivelmente, o navegador do usuário e outros servidores proxy de cache intermediários, armazenarão as respostas do seu app em cache, conforme instruído pelos cabeçalhos de armazenamento em cache padrão especificados na resposta. Especifique esses cabeçalhos de resposta por meio do framework, diretamente no seu código ou por meio de gerenciadores de diretórios e arquivos estáticos do App Engine.

No front-end do Google, a chave de cache é o URL completo da solicitação.

Armazenar conteúdo estático em cache

Para garantir que os clientes sempre recebam conteúdo estático atualizado assim que ele for publicado, recomendamos que você exiba conteúdo estático de diretórios com versão, como css/v1/styles.css. O Google Frontend não validará o cache (verifique o conteúdo atualizado) até que o cache expire. Mesmo após a expiração do cache, o cache não será atualizado até que o conteúdo do URL de solicitação seja alterado.

Os seguintes cabeçalhos de resposta que podem ser definidos em app.yaml influenciam como e quando o Google Frontend armazena conteúdo em cache:

  • Cache-Control precisa ser definido como public para que o Google Frontend armazene o conteúdo em cache. Se você não definir esse cabeçalho em app.yaml, o App Engine o adicionará automaticamente a todas as respostas processadas por um arquivo estático ou um gerenciador de diretório. Para mais informações, consulte Cabeçalhos adicionados ou substituídos.

  • Vary: para permitir que o cache retorne respostas diferentes para um URL com base nos cabeçalhos enviados na solicitação, defina um ou mais dos seguintes valores no cabeçalho da resposta Vary: Accept, Accept-Encoding, Origin ou X-Origin

    Devido ao potencial para alta cardinalidade, os dados não serão armazenados em cache para outros valores de Vary.

    Exemplo:

    1. Especifique o seguinte cabeçalho de resposta:

      Vary: Accept-Encoding

    2. Seu app recebe uma solicitação que contém o cabeçalho Accept-Encoding: gzip. O App Engine retorna uma resposta compactada e o Google Frontend armazena em cache a versão em gzip dos dados da resposta. Todas as solicitações subsequentes deste URL que contêm o cabeçalho Accept-Encoding: gzip receberão os dados compactados em gzip do cache até que o cache se torne invalidado (devido à alteração do conteúdo após a expiração do cache).

    3. Seu app recebe uma solicitação que não contém o cabeçalho Accept-Encoding. O App Engine retorna uma resposta descompactada e o Google Frontend armazena em cache a versão descompactada dos dados de resposta. Todas as solicitações subsequentes deste URL que não contenham o cabeçalho Accept-Encoding receberão os dados compactados do cache até que o cache se torne invalidado.

    Se você não especificar um cabeçalho de resposta Vary, o Google Frontend criará uma única entrada de cache para o URL e o usará para todas as solicitações, independentemente dos cabeçalhos na solicitação. Exemplo:

    1. Você não especifica o cabeçalho de resposta Vary: Accept-Encoding.
    2. Uma solicitação contém o cabeçalho Accept-Encoding: gzip, e a versão compactada em gzip dos dados de resposta será armazenada em cache.
    3. Uma segunda solicitação não contém o cabeçalho Accept-Encoding: gzip. No entanto, como o cache contém uma versão compactada em gzip dos dados de resposta, a resposta será compactada, mesmo que o cliente tenha solicitado dados descompactados.

Os cabeçalhos na solicitação também influenciam o armazenamento em cache:

  • Se a solicitação contiver um cabeçalho Authorization, o conteúdo não será armazenado em cache pelo Google Frontend.

Expiração do cache

Por padrão, os cabeçalhos de armazenamento em cache que o arquivo estático e os gerenciadores de diretório do App Engine adicionam às respostas instruem os clientes e os proxies da Web, como o Google Frontend, a expirar o cache após 10 minutos.

Depois que um arquivo é transmitido com um prazo de validade determinado, geralmente não há como removê-lo de caches de proxy da Web, mesmo que o usuário limpe seu próprio cache do navegador. A reimplantação de uma nova versão do aplicativo não redefinirá nenhum cache. Portanto, se você planeja modificar um arquivo estático, ele tem que ter um tempo de expiração curto (menos de uma hora). Na maioria dos casos, o prazo de validade padrão de 10 minutos é suficiente.

É possível alterar a validade padrão de todos os gerenciadores de arquivos estáticos e de diretório especificando que o elemento default_expiration no seu arquivo app.yaml. Para definir prazos de validade específicos para gerenciadores individuais, especifique o elemento expiration dentro do elemento do gerenciador no arquivo app.yaml.

O valor especificado no tempo dos elementos de expiração será usado para definir os cabeçalhos de resposta HTTP Cache-Control e Expires.

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

Strict-Transport-Security: max-age=31536000; includeSubDomains
Para definir esse cabeçalho para qualquer conteúdo estático exibido pelo app, adicione o cabeçalho aos gerenciadores de diretórios e arquivos estáticos do app.

Para informações sobre como configurar cabeçalhos em uma resposta gerada a partir do seu script, consulte as instruções fornecidas pelo framework da Web usado no seu app. Se você não estiver usando um framework da Web, use a função header do PHP.