Solicitação lenta de HTTP e TTFB em PCAP: provando se o atraso é DNS, TCP, TLS ou horário do servidor

“O site está lento” e “A solicitação da API leva 10 segundos” não são diagnósticos. Uma captura de pacote pode dividir o atraso em fases: "pesquisa de DNS, handshake TCP, handshake TLS, upload de solicitação, processamento do servidor, download de resposta, retransmissões e comportamento do cliente." O tempo até o primeiro byte costuma ser a frase pesquisada pelos usuários. Na evidência de pacotes, o TTFB não é um campo mágico único. É uma linha do tempo.

Crie o cronograma de solicitação

Para uma solicitação HTTP ou HTTPS, inspecione:

• Início da consulta DNS
• Tempo de resposta DNS
• TCPSYN
• Conclusão do handshake TCP
• Cliente TLSOlá
• Servidor TLS Olá e certificado
• Bytes de solicitação HTTP enviados
• primeiro byte de resposta
• conclusão completa da resposta
• retransmissões ou redefinições

Se o DNS demorar cinco segundos, o servidor ainda não está lento. Se o handshake TCP for rápido, mas o primeiro byte de resposta estiver atrasado, o processamento do servidor ou a dependência upstream podem ser o problema. Se o TLS parar antes do HTTP, concentre-se no comportamento do certificado, da cifra, do SNI ou do middlebox.

HTTP sobre TLS precisa de limites cuidadosos

Nas capturas HTTPS, a carga útil pode ser criptografada, mas o tempo ainda é importante. Muitas vezes você pode identificar:

• início da conexão
• duração do aperto de mão
• dados criptografados do aplicativo do cliente
• primeiros dados de aplicativos criptografados do servidor
• perda ou retransmissão de pacotes
• conexão fechar ou redefinir

Mesmo sem descriptografar o conteúdo, a captura pode mostrar se o atraso aconteceu antes ou depois do envio da solicitação.

Fique atento às retransmissões

HTTP lento pode ser resultado de perda de pacotes. Se retransmissões TCP ou ACKs duplicados aparecerem durante o upload da solicitação ou entrega da resposta, o servidor pode não ser o proprietário principal. Uma grande resposta com perda no caminho do servidor para o cliente pode parecer latência de back-end para os usuários.

O relatório deve separar:

• tempo antes da solicitação deixar o cliente
• servidor de horário parece processar
• tempo gasto na retransmissão da resposta
• comportamento da janela de recebimento do lado do cliente

Essa distinção evita que as equipes de back-end procurem problemas de rede.

Onde a cirurgia PCAP se encaixa

A cirurgia PCAP é útil quando a captura original é muito grande ou muito sensível. Uma transferência de latência HTTP focada deve preservar:

• Janela DNS
• Aperto de mão TCP
• Aperto de mão TLS, se presente
• tempo de solicitação/resposta
• evidência de retransmissão
• redefinições ou alertas
• carimbos de data/hora originais

Se o anonimato for necessário, preserve o tempo e os tamanhos dos pacotes quando forem importantes. Remover muito contexto pode impossibilitar a análise do TTFB.

Para pesquisas como “HTTP slow request pcap”, “time to first byte packet capture” ou “API latency Wireshark”, a resposta é uma linha do tempo fase por fase, não um único rótulo de culpa.