Introdução
Dois visitantes de Grove relatam espera ao abrir informações de Lantern Photography. A referência normal e as duas visitas afetadas estão gravadas em uma captura. Você descobrirá se o intervalo longo ocorre depois de enviar uma solicitação ou antes de a próxima aparecer.
Você deve conhecer os filtros HTTP, Follow TCP Stream e os vínculos de solicitação/resposta do laboratório anterior. Este laboratório começa em um ambiente Desktop novo e independente. Você aprenderá referências de tempo e dois intervalos definidos com precisão; não é preciso programar nem reparar servidores. Essas gravações controladas sustentam conclusões sobre tempos de pacotes, não sobre renderização do navegador ou CPU do servidor.
Meça uma solicitação e sua resposta
Nesta etapa, você medirá a primeira transação de detalhes de Aspen. Comece em Desktop, abra Applications → Terminal Emulator pelo menu inferior esquerdo e inicie o Wireshark com a nova entrada.
wireshark /home/labex/project/event-page/input/casebook.pcapng
Maximize o Wireshark. O serviço é 127.0.0.1:18182. Maple (127.0.0.5) é a referência normal; Aspen (127.0.0.6) e Elm (127.0.0.7) são as visitas relatadas; Pine (127.0.0.8) não está relacionado. Cada visita solicita lista, detalhes, programa e detalhes novamente em uma conexão persistente. Persistente significa que permanece aberta durante vários intercâmbios de solicitações e respostas.
Filtre as mensagens HTTP de Aspen:
ip.addr == 127.0.0.6 && http
Selecione o primeiro GET de detalhes. Expanda HTTP e leia X-Request: aspen-02. Use Response in frame → right-click → Go to Linked Packet para localizar a resposta real e confira o vínculo inverso Request in frame. Os quadros de entrada são solicitação 42 e resposta 46.
Na resposta, localize Time since request. Clique com o botão direito e escolha Apply as Column. O valor é aproximadamente 1.6017 segundos. Um segundo equivale a 1.000 milissegundos, portanto são cerca de 1601.7 ms.
Esse é o intervalo entre o quadro de análise HTTP da solicitação e o da resposta correspondente nesta gravação. O Wireshark pode decodificar a mensagem completa no último segmento de remontagem. Não chame isso de tempo de CPU do servidor, carregamento da página no navegador ou tempo até o primeiro byte de resposta.
Confira visualmente o intervalo com uma referência de tempo. Selecione o quadro de solicitação 42 e escolha Edit → Set/Unset Time Reference; nesta versão, o atalho é Ctrl+T. Em View → Time Display Format, selecione Seconds Since Beginning of Capture. Esse formato usa a referência quando definida. A solicitação fica marcada como *REF* e funciona como zero; a resposta aparece cerca de 1,6017 segundos depois. Após comparar, clique com o botão direito no pacote de referência e use o mesmo comando para removê-la.
Não use Seconds Since Previous Captured Packet nem Previous Displayed Packet para essa associação. Um vizinho na lista atual não precisa ser a solicitação correspondente. Alterar o filtro também muda o pacote exibido anterior. Referências de tempo não ficam salvas permanentemente na captura: registre números explícitos de quadro e o intervalo medido para que outro analista possa reproduzir.
Encontre a solicitação seguinte de programa, aspen-03, no quadro 48. A pausa entre a resposta de detalhes 46 e a solicitação 48 é de aproximadamente 0.3 ms. Defina a resposta como referência, leia o tempo relativo da solicitação de programa e remova a referência. Essa pausa é a segunda métrica: o intervalo entre esses dois quadros de análise nomeados, não uma medida geral do tempo de reflexão do usuário.
Aqui, o quadro 46 está marcado como *REF*. Leia a coluna Time do quadro 48: 0.000312566 segundos são aproximadamente 0.3 ms. A coluna separada Time since request no quadro 46 continua descrevendo seu próprio par de solicitação/resposta; são intervalos diferentes.
Crie /home/labex/project/event-page/output/timing.csv com um segundo terminal Desktop e Mousepad. Abra Applications → Terminal Emulator novamente e execute:
mousepad /home/labex/project/event-page/output/timing.csv
As colunas identificam visita, primeira solicitação de detalhes, resposta, próxima solicitação de programa, os dois intervalos em milissegundos e o estágio observado. Use after para um intervalo longo de solicitação a resposta, before para uma pausa longa antes da próxima solicitação e normal quando nenhum for longo. Nessas gravações, intervalos longos ultrapassam 800 ms; esse é um limiar didático, não uma meta de produção. São aceitos valores arredondados com erro de até 5 ms.
visit,request_frame,response_frame,next_request_frame,response_ms,gap_ms,stage
aspen,42,46,48,1601.7,0.3,after
Salve com Ctrl+S. A evidência situa a espera longa de Aspen depois da solicitação de detalhes. Não identifica a causa interna do servidor nem prova que todos os componentes de rede estejam saudáveis.
Compare a pausa e preserve a evidência
Nesta etapa, você comparará Elm e a visita normal Maple com Aspen e preservará as conversas completas necessárias. Comece em Desktop, voltando ao Wireshark e à entrada original. Remova todas as referências de tempo antes de iniciar outra medição.
Filtre Elm:
ip.addr == 127.0.0.7 && http
Siga a resposta real da primeira solicitação de detalhes pelos vínculos de quadro HTTP. elm-02 é a solicitação 74 e a resposta 78. O intervalo entre elas é de cerca de 0.3 ms. Encontre a próxima solicitação de programa, elm-03, no quadro 80. Defina o quadro 78 como referência; o quadro 80 aparece cerca de 1.6012 segundos depois. Remova a referência em seguida.
O intervalo longo de Elm ocorre depois da resposta anterior, mas antes da próxima solicitação. O registro de pacotes estabelece essa posição. Não distingue um temporizador do cliente, trabalho da aplicação ou uma pessoa adiando uma ação. Não o classifique como defeito de frontend sem mais evidências.
Repita para Maple com ip.addr == 127.0.0.5 && http. Sua primeira solicitação de detalhes, a resposta e a solicitação de programa são os quadros 12, 16, 17. Ambos os intervalos são inferiores a um milissegundo. A referência normal mostra como a mesma sequência pode ocorrer sem a espera longa.
Volte ao Mousepad e substitua a tabela pelas três visitas, preservando a linha de Aspen. Use os números de quadro da entrada original e milissegundos:
visit,request_frame,response_frame,next_request_frame,response_ms,gap_ms,stage
maple,12,16,17,0.3,0.1,normal
aspen,42,46,48,1601.7,0.3,after
elm,74,78,80,0.3,1601.2,before
Salve o arquivo. As duas visitas afetadas apresentam atrasos igualmente perceptíveis em posições diferentes. A Duration total de uma conexão não as distingue. Manter apenas a última solicitação de cada fluxo também não associaria corretamente as solicitações repetidas de detalhes.
No Wireshark, examine uma resposta de programa. Seu corpo HTTP é maior e está dividido em segmentos TCP. Selecione a resposta e examine Reassembled TCP e o título JSON completo Lantern Photography. O espaço em branco final é preenchimento sintético de treinamento, não objetos JSON extras. O intervalo dos quadros de análise inclui a conclusão da mensagem; isso mostra por que a métrica não equivale automaticamente ao tempo do primeiro byte.
Agora mantenha as conexões completas de Maple, Aspen e Elm. || significa que qualquer uma das condições pode corresponder. Substitua o filtro de exibição por:
ip.addr == 127.0.0.5 || ip.addr == 127.0.0.6 || ip.addr == 127.0.0.7
Não adicione && http: a exportação também precisa dos segmentos TCP anteriores. Escolha File → Export Specified Packets, selecione Displayed → All packets e salve PCAPNG como /home/labex/project/event-page/output/evidence.pcapng. Exclua Pine. Se já houver uma saída, confirme a substituição somente do arquivo de saída deste curso, nunca da entrada original.
Abra a exportação e confira as três visitas e suas respostas completas. Os números de quadro exportados podem diferir; a tabela se refere explicitamente à entrada original. Se estiver incompleta, reabra a entrada e repita a exportação das conexões completas. Se um filtro novo não mostrar linhas, confira o arquivo aberto e o endereço do cliente; limpe o filtro para recuperar a lista.
A conclusão útil é precisa: o intervalo longo de Aspen vem depois de uma solicitação de detalhes, enquanto o de Elm precede a próxima solicitação de programa. A transação normal Maple fica preservada para comparação. Nenhuma configuração do servidor foi alterada e nenhuma afirmação mais forte sobre a causa interna é exigida.
Resumo
Você usou os vínculos de solicitação, Time since request e referências de tempo do Wireshark para comparar duas posições distintas de espera. Preservou uma referência normal e conversas legíveis de forma independente. Sua conclusão localiza a espera observada sem afirmar uma causa interna de aplicação ou rede não observada.
