PCAP의 HTTP 느린 요청 및 TTFB: 지연이 DNS, TCP, TLS 또는 서버 시간인지 증명

"웹사이트 속도가 느립니다.", "API 요청에 10초가 소요됩니다."는 진단이 아닙니다. 패킷 캡처는 지연을 DNS 조회, TCP 핸드셰이크, TLS 핸드셰이크, 요청 업로드, 서버 처리, 응답 다운로드, 재전송 및 클라이언트 동작의 단계로 나눌 수 있습니다.

첫 번째 바이트까지의 시간은 사용자가 검색하는 문구인 경우가 많습니다. 패킷 증거에서 TTFB는 단일 매직 필드가 아닙니다. 타임라인입니다.

요청 타임라인 구축

HTTP 또는 HTTPS 요청의 경우 다음을 검사하세요.

• DNS 쿼리 시작
• DNS 응답 시간
• TCP 동기화
• TCP 핸드셰이크 완료
• TLS 클라이언트안녕하세요
• TLS ServerHello 및 인증서
• 전송된 HTTP 요청 바이트
• 첫 번째 응답 바이트
• 전체 응답 완료
• 재전송 또는 재설정

DNS에 5초가 걸린다면 서버는 아직 느리지 않은 것입니다. TCP 핸드셰이크는 빠르지만 첫 번째 응답 바이트가 늦는 경우 서버 처리 또는 업스트림 종속성이 문제일 수 있습니다. HTTP 전에 TLS가 중단되면 인증서, 암호, SNI 또는 미들박스 동작에 집중하세요.

TLS를 통한 HTTP에는 신중한 경계가 필요합니다

HTTPS 캡처에서는 페이로드가 암호화될 수 있지만 타이밍은 여전히 ​​중요합니다. 다음을 자주 식별할 수 있습니다.

• 연결 시작
• 악수 기간
• 클라이언트의 암호화된 애플리케이션 데이터
• 서버의 첫 번째 암호화된 애플리케이션 데이터
• 패킷 손실 또는 재전송
• 연결 종료 또는 재설정

콘텐츠를 해독하지 않고도 캡처를 통해 요청이 전송되기 전이나 후에 지연이 발생했는지 여부를 확인할 수 있습니다.

재전송 감시

느린 HTTP는 패킷 손실로 인해 발생할 수 있습니다. 요청 업로드 또는 응답 전달 중에 TCP 재전송 또는 중복 ACK가 나타나면 서버가 기본 소유자가 아닐 수 있습니다. 서버-클라이언트 경로에서 손실이 있는 대규모 응답은 사용자에게 백엔드 대기 시간처럼 보일 수 있습니다.

보고서는 다음과 같이 구분되어야 합니다.

• 요청이 클라이언트를 떠나기 전의 시간
• 시간 서버가 처리하는 것으로 나타납니다.
• 응답을 재전송하는 데 소요된 시간
• 클라이언트 측 수신 창 동작

이러한 구별은 백엔드 팀이 네트워크 문제를 추적하는 것을 방지합니다.

PCAP 수술이 적합한 곳

PCAP 수술은 원본 캡처가 너무 크거나 너무 민감한 경우에 유용합니다. 집중된 HTTP 대기 시간 핸드오프는 다음을 유지해야 합니다.

• DNS 창
• TCP 핸드셰이크
• TLS 핸드셰이크(있는 경우)
• 요청/응답 타이밍
• 재전송 증거
• 재설정 또는 경고
• 원래 타임스탬프

익명화가 필요한 경우 중요한 경우 타이밍과 패킷 크기를 보존하십시오. 너무 많은 컨텍스트를 제거하면 TTFB 분석이 불가능해질 수 있습니다.

"HTTP 느린 요청 pcap", "첫 번째 바이트 패킷 캡처까지의 시간" 또는 "API 대기 시간 Wireshark"와 같은 검색의 경우 대답은 단일 비난 레이블이 아닌 단계별 타임라인입니다.