Como otimizar o tempo de carregamento da fase inicial da conexão e do handshake SSL de uma página da web em uma rede 3G?

11

Meu site www.example.com (SSL ativado) está hospedado na hospedagem compartilhada Amazon EC2. Carrega mais rápido (tempo de carregamento <2 segundos) em uma conexão wifi / banda larga. O problema está na rede 3G no celular ** (modo H e não no modo H +) **. Inicie uma fase de conexão e o processo de handshake SSL leva muito tempo - 12 segundos. Monitorou os parâmetros de tempo na guia Rede do Chrome. Abaixo está o tempo de carregamento medido para a página da web.

Estatísticas de tempo da rede de carregamento da página

Tipo de dados manipulados na página: A página da Web testada recebe 5 dados JSON emparelhados com valor-chave por meio do AJAX e os exibe na página da Web. É uma página muito leve, com apenas 5-6 conteúdo de texto.

Vi muitos sites carregarem mais rapidamente em uma rede móvel 3G (modo H). Meu site está muito lento durante a fase inicial do estabelecimento da conexão em uma rede 3G. Alguém pode me ajudar em como resolver / otimizar o atraso na fase inicial da conexão? A mudança para hospedagem dedicada resolverá o problema atual?

O servidor Web não está ocupado e sempre há muita CPU e memória disponíveis.

Configuração do servidor: Instância Amazon EC2 - Hospedagem compartilhada (32 CPU e 60 GB RAM). Servidor Web - Apache. SSL - Symantec.

Usuário234334
fonte
Você já tentou usar um balanceador de carga elástico e manipular o HTTPS? É isso que uso na Amazon e não vi problemas de desempenho como este. Por outro lado, nunca testei especificamente contra uma conexão 3G.
Stephen Ostermiller
Obrigado. O servidor não possui balanceamento de carga. Testará o servidor em certos parâmetros novamente e testará.
usar o seguinte código

Respostas:

8

Conexão inicial

Você descobrirá que a conexão inicial inclui a negociação do SSL; portanto, como o handshake é alto, é um bom indicador de que algo está seriamente errado com a maneira como você configurou o SSL.

Google Chrome: Entendendo o tempo dos recursos

Tempo necessário para estabelecer uma conexão, incluindo handshakes / novas tentativas de TCP e negociação de um SSL.

Handshake SSL e TTFB

Você tem dois problemas principais: o tempo gasto na conclusão de um handshake SSL e os servidores aguardando TTFB (tempo até o primeiro byte).

  • TTFB: 4079ms (deve ser menor que 1000ms)
  • Handshake SSL 11830ms (deve ser menor que 100ms)

Também deve ser observado que, ao testar com dispositivos 3G / 4G, pode causar primeiros bytes mais longos devido ao fato de os sinais telefônicos variarem de intensidade ... isso pode causar problemas de conexão intermitentes e tempos de latência variáveis.

Etapa 1: investigando o problema do SSL

É bastante óbvio que você tem um problema sério de SSL e provavelmente devido a uma instalação defeituosa do OpenSSL ou similar. Comece testando seu certificado SSL usando o SSL Labs e, em seguida, corrigindo quaisquer problemas ou avisos sugeridos.

Se o SSL ainda estiver operando lentamente, é provável que você tenha um servidor sobrecarregado ou uma falha no servidor. Se for o mais tarde, você precisará tentar diminuir onde está a falha. Use a pilha de falhas do servidor, caso precise de mais assistência sobre esse assunto, um usuário relatou que a criação de novas chaves resolveu um problema lento de SSL que ele estava enfrentando que pode ou não ser relevante.

Os balanceadores de carga podem ajudar se for um problema de recurso do servidor.

Etapa 2: Investigando o TTFB

Depois de investigar, resolver o problema do SSL e você ainda tiver um TTFB aumentado, deverá testar seu servidor, garantindo que ele tenha recursos suficientes.

O tempo do primeiro byte é influenciado, mas não limitado a:

  • A distância do usuário ao datacenter que hospeda o servidor pode aumentar o TTFB
  • O GZIP sem cache pode aumentar o TTFB
  • Redes congestionadas podem aumentar o TTFB
  • Servidores congestionados podem aumentar o TTFB

Às vezes, aumentar a CPU e a RAM nem sempre é a melhor opção. Às vezes, é melhor introduzir um balanceador de carga, porque não apenas significa que você pode executar vários servidores facilmente lado a lado, mas na verdade descarrega solicitações de cache e SSL. Alguns outros benefícios incluem:

FONTE

  • Armazenamento em cache: o dispositivo pode armazenar conteúdo que não muda (como imagens) e servi-lo diretamente ao cliente sem enviar tráfego para o servidor da web.
  • Compactação: reduz a quantidade de tráfego para objetos HTTP compactando arquivos antes de serem enviados.
  • Descarregamento de SSL: o processamento do tráfego SSL é exigente na CPU de um servidor da Web, portanto, um balanceador de carga pode executar esse processamento.
  • Alta disponibilidade: Dois dispositivos de balanceamento de carga podem ser usados ​​no caso de um falhar.

Dicas para diminuir o seu TTFB:

  • Verifique se o banco de dados está na mesma rede ou em uma nuvem SQL de qualidade .
  • Garanta que seu banco de dados seja lido da memória e NUNCA NUNCA o arquivo SWAP !
  • Faça uso de uma rede de entrega de conteúdo , descarrega solicitações de servidor e tarefas de compactação.
  • Faça uso do Varnish Cache para reduzir a carga no banco de dados, armazenando em cache as páginas
  • Compare seus arquivos estáticos no disco rígido usando o HDParm
  • Avalie seu servidor usando a ferramenta de benchmarking do servidor HTTP Apache
  • Compare o site com 10 passes em vários locais remotos usando o WebPageTest
Simon Hayter
fonte
Obrigado pela sua explicação detalhada. Testará o servidor novamente nos parâmetros sugeridos e implementará o melhor!
usar o seguinte código
O gráfico da pergunta separa o handshake SSL da solicitação inicial e TTFB. De acordo com esse gráfico, o problema está realmente com o SSL antes que a solicitação seja feita.
Stephen Ostermiller
@StephenOstermiller bem visto. O TTFB em espera é de 4000ms, enquanto o SSL está acima de 11000ms. É provável que o SSL esteja afetando o TTFB. Atualizei a pergunta para refletir isso.
Simon Hayter
Obrigado! Testei meu SSL em www.ssllabs.com e a classificação foi "A". Não foram relatados avisos / problemas. Eu descobri que a versão do Apache é 2.2.15, que está desatualizada. Precisa atualizá-lo agora. O conteúdo do meu site (tamanho em TB) está em / var / www / html /. Atualizar / reinstalar o Apache removerá o conteúdo do meu site? Algum método mais seguro de atualizar sem perder dados?
precisa saber é o seguinte
Mais um ponto - o OpenSSL também é da versão mais recente.
usar o seguinte código
6

Lendo o título da sua pergunta , há duas coisas que você pode fazer para acelerar a conexão inicial e o handshake SSL / TLS. Como funcionam para qualquer conexão, não apenas para 3G, você deve usá-las como prática recomendada de qualquer maneira.

Primeiro, use HTTP / 2 para servir o site. Isso requer o Apache 2.4.17 ou posterior .

Segundo, configure o Apache para usar o grampeamento OCSP. Isso requer o Apache 2.3.3 ou posterior, mais o OpenSSL 0.9.8h ou posterior, com um bom guia para configurá-lo aqui . O grampeamento OCSP não acelera as coisas, mas faz parte do trabalho do cliente e poupa o trabalho de tentar uma pesquisa OCSP.

Lendo o texto do corpo da sua pergunta , acho que você tem um problema muito maior com o seu ambiente de hospedagem. Esses tempos de carregamento são inaceitáveis. Você menciona que é 'hospedagem compartilhada', deve entrar em contato com quem estiver gerenciando essa hospedagem compartilhada e perguntar por que o servidor é tão incomumente lento. Provavelmente, é melhor tentar um host compartilhado diferente ou executar um VPS por conta própria (isso é mais trabalhoso, mas oferece melhor velocidade e flexibilidade).

Como você já está na AWS, por que não tentar o nível gratuito para testar as coisas e fazer com que seu próprio servidor funcione e seja otimizado? Use-o com um subdomínio e algumas páginas HTML estáticas para teste e, em seguida, mova o site principal (aumentando os limites da camada gratuita, se necessário).

Tom Brossman
fonte