ID da região
O REGION_ID é um código abreviado que a Google atribui com base na região que seleciona quando cria a sua app. O código não corresponde a um país ou uma província, embora alguns IDs de regiões possam parecer semelhantes aos códigos de países e províncias usados frequentemente. Para apps criadas após
fevereiro de 2020, REGION_ID.r está incluído nos
URLs do App Engine. Para apps existentes criadas antes desta data, o
ID da região é opcional no URL.
Saiba mais acerca dos IDs de regiões.
Este documento descreve como a sua aplicação do App Engine recebe pedidos e envia respostas. Para ver mais detalhes, consulte a referência de cabeçalhos de pedidos.
Se a sua aplicação usar serviços, pode enviar pedidos para um serviço específico ou uma versão específica desse serviço. Para mais informações sobre a capacidade de resposta do serviço, consulte o artigo Como os pedidos são encaminhados.
Processar pedidos
A sua aplicação é responsável por iniciar um servidor Web e processar pedidos. Pode usar qualquer framework Web disponível para a sua linguagem de desenvolvimento.
O App Engine executa várias instâncias da sua aplicação e cada instância tem o seu próprio servidor Web para processar pedidos. Qualquer pedido pode ser encaminhado para qualquer instância, pelo que os pedidos consecutivos do mesmo utilizador não são necessariamente enviados para a mesma instância. Uma instância pode processar vários pedidos em simultâneo. O número de instâncias pode ser ajustado automaticamente à medida que o tráfego muda.
Quotas e limites
O App Engine atribui automaticamente recursos à sua aplicação à medida que o tráfego aumenta. No entanto, isto está sujeito às seguintes restrições:
O App Engine reserva capacidade de escalabilidade automática para aplicações com baixa latência, em que a aplicação responde a pedidos em menos de um segundo.
As aplicações que estão fortemente limitadas pela CPU também podem incorrer em alguma latência adicional para partilhar recursos de forma eficiente com outras aplicações nos mesmos servidores. Os pedidos de ficheiros estáticos estão isentos destes limites de latência.
Cada pedido recebido para a aplicação conta para o limite de pedidos. Os dados enviados em resposta a um pedido contam para o limite de largura de banda de saída (faturável).
Os pedidos HTTP e HTTPS (seguros) são contabilizados para os limites de pedidos, largura de banda de entrada (faturável) e largura de banda de saída (faturável). A Google Cloud página de detalhes da quota da consola também comunica pedidos seguros, largura de banda de entrada segura e largura de banda de saída segura como valores separados para fins informativos. Apenas os pedidos HTTPS contam para estes valores. Para mais informações, consulte a página Quotas.
Os seguintes limites aplicam-se especificamente à utilização de controladores de pedidos:
Limites aos pedidos
- É permitido um máximo de ~15 KB nos cabeçalhos de pedidos.
- O tamanho total do pedido está limitado a ~32 MB.
- Todos os pedidos HTTP/2 são traduzidos em pedidos HTTP/1.1 quando são encaminhados para o servidor de aplicações.
- As ligações SSL terminam no balanceador de carga. O tráfego do equilibrador de carga é enviado para a instância através de um canal encriptado e, em seguida, encaminhado para o servidor de aplicações através de HTTP. O cabeçalho X-Forwarded-Proto permite-lhe compreender se o pedido de origem foi 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 da resposta é de 64 KB. Os cabeçalhos de resposta que excedam este limite devolvem erros HTTP 502, com registos a mostrar
upstream sent too big header while reading response header from upstream.
Pedidos HTTP não suportados
As seguintes funcionalidades não são suportadas pelo ambiente flexível do App Engine:
- Tráfego HTTP/2 para o serviço de back-end.
- Pedidos HTTP que acedem diretamente a instâncias.
Cabeçalhos do pedido
Um pedido HTTP de entrada inclui os cabeçalhos HTTP enviados pelo cliente. Por motivos de segurança, alguns cabeçalhos são limpos ou alterados por proxies intermédios antes de chegarem à aplicação.
Para mais informações, consulte a Referência de cabeçalhos de pedidos.
Desativar colocação no buffer
Por predefinição, todas as respostas do App Engine são armazenadas em buffer em blocos de 64 KB. Em alguns casos, pode ser útil desativar o armazenamento em buffer e transmitir bytes diretamente para o cliente. Geralmente, esta opção é preferível quando usa GETs pendentes ou eventos enviados pelo servidor (SSEs). Para desativar o armazenamento em buffer, pode definir o cabeçalho da resposta X-Accel-Buffering
como no.
Forçar ligações HTTPS
Por motivos de segurança, todas as aplicações devem incentivar os clientes a estabelecer ligação através de
https. Para instruir o navegador a preferir https em vez de http para uma determinada página ou domínio inteiro, defina o cabeçalho Strict-Transport-Security nas suas respostas.
Por exemplo:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Processamento de trabalho assíncrono em segundo plano
O trabalho em segundo plano é qualquer trabalho que a sua app realiza para um pedido depois de ter enviado a resposta HTTP. Evite realizar trabalho em segundo plano na sua app e reveja o código para se certificar de que todas as operações assíncronas terminam antes de enviar a resposta.
Para tarefas de longa duração, recomendamos a utilização do Cloud Tasks. Com o Cloud Tasks, os pedidos HTTP são de longa duração e devolvem uma resposta apenas após a conclusão de qualquer trabalho assíncrono.