Otimize a duração da conexão (TCP + TLS), sub-parte do Time to First Byte

Otimize a duração da conexão (TCP + TLS), sub-parte do Time to First Byte

O Time to First Byte (TTFB) pode ser dividido nas seguintes sub-partes:

• Waiting + Redirect (ou duração de espera)
  
• Worker + Cache (ou duração de cache)
• DNS (ou duração de DNS)
• Connection  (ou duração de conexão)
• Request (ou duração de request)

Quer otimizar o Time to First Byte? Este artigo fornece uma análise detalhada da parte de duração de DNS do Time to First Byte. Se você deseja entender ou corrigir o Time to First Byte e não sabe o que significa a duração de espera, consulte o que é o Time to First Byte e identifique e corrija problemas de Time to First Byte antes de começar com este artigo

A parte da duração de conexão do Time to First Byte consiste em algum tempo onde o navegador está se conectando ao servidor web. Após essa conexão, o navegador e o servidor geralmente adicionam uma camada de criptografia (TLS). O processo de negociação dessas 2 conexões leva um pouco de tempo e esse tempo é adicionado ao Time to First Byte.

Processo de conexão em detalhes

O Transmission Control Protocol (TCP) é responsável por estabelecer uma conexão confiável entre o cliente (navegador) e o servidor. Este processo envolve um handshake de três vias:

• SYN (Synchronize) Packet: O cliente envia um pacote SYN ao servidor para iniciar a conexão e solicitar sincronização.
• SYN-ACK (Synchronize-Acknowledge) Packet: O servidor responde com um pacote SYN-ACK, confirmando o recebimento do pacote SYN e concordando em estabelecer uma conexão.
• ACK (Acknowledge) Packet: O cliente envia um pacote ACK de volta ao servidor, confirmando o recebimento do pacote SYN-ACK. Neste ponto, uma conexão TCP é estabelecida, permitindo que os dados sejam transferidos de forma confiável entre o cliente e o servidor.

O TCP garante que os dados sejam enviados e recebidos na ordem correta, reenviando quaisquer pacotes perdidos e gerenciando o controle de fluxo para corresponder à capacidade da rede.

Uma vez que a conexão TCP é estabelecida, o protocolo Transport Layer Security (TLS) é usado para proteger a conexão. O handshake TLS envolve várias etapas para autenticar o servidor e estabelecer um canal de comunicação seguro:

• ClientHello: O cliente envia uma mensagem "ClientHello" ao servidor, indicando as versões de TLS suportadas, conjuntos de cifras e um número aleatório (Client Random).
• ServerHello: O servidor responde com uma mensagem "ServerHello", selecionando a versão de TLS e o conjunto de cifras da lista do cliente, e fornecendo seu certificado digital e um número aleatório (Server Random).
• Certificate and Key Exchange: O servidor envia seu certificado digital ao cliente para autenticação. O cliente verifica o certificado junto às autoridades certificadoras confiáveis.
• Premaster Secret: O cliente gera um premaster secret, criptografa-o com a chave pública do servidor (do certificado) e o envia ao servidor.
• Session Key Generation: Tanto o cliente quanto o servidor usam o premaster secret, juntamente com o Client Random e o Server Random, para gerar uma chave de sessão compartilhada para criptografia simétrica.
• Finished Messages: O cliente e o servidor trocam mensagens criptografadas com a chave de sessão para confirmar que o handshake foi bem-sucedido e que ambas as partes possuem a chave de sessão correta.

Uma vez que o handshake TLS é concluído, o cliente e o servidor estabeleceram uma conexão segura e criptografada. Isso garante que quaisquer dados trocados estejam protegidos contra interceptação e adulteração por terceiros.

HTTP/3 acelera as conexões TLS ao integrar-se com o protocolo QUIC, que reduz o número de round trips necessários para estabelecer uma conexão segura ao combinar os processos de handshake em um só, e suporta a retomada 0-RTT para reconexões mais rápidas. Além disso, o uso de UDP pelo QUIC elimina o bloqueio head-of-line e melhora o controle de congestionamento, resultando em uma transmissão de dados mais eficiente e carregamentos de página mais rápidos.

• HTTP/3 - traz o protocolo QUIC sobre UDP em vez de TCP, permitindo uma transferência de dados mais rápida e eficiente
  
• TLS 1.3 Adiciona mais segurança e reduz os round trips do handshake e é necessário para a retomada de conexão 0-RTT. 
• 0-RTT Connection Resumption - Recurso do TLS 1.3 que permite que clientes que retornam enviem dados criptografados imediatamente ao reconectar, reutilizando informações previamente trocadas.
  
• TCP Fast Open. Permite que dados sejam enviados no pacote SYN inicial, reduzindo o tempo de round-trip para o handshake TCP.
• TLS false start - Permite o envio antecipado de dados antes que o handshake TLS seja concluído.
  
• OCSP Stapling -  Acelera a validação de certificados ao eliminar a necessidade de o cliente contatar a autoridade certificadora diretamente

Time to Fist Byte TIP: um CDN não apenas oferece tempos de round trip mais curtos. Utilizar um CDN frequentemente melhora imediatamente os tempos de conexão TCP e TLS porque provedores de CDN premium terão configurado corretamente essas configurações para você!

Como encontrar problemas de TTFB causados por tempo de conexão lento

Para encontrar o impacto que os usuários reais experimentam causado por redirecionamento, você precisará usar uma ferramenta de RUM como o CoreDash. O monitoramento de usuários reais permitirá que você acompanhe os Core Web Vitals com mais detalhes e sem o atraso de 28 dias do Google.

No CoreDash simplesmente 'clique em Time to Fist Byte breakdown' para visualizar a parte de conexão do Time to First Byte.