소개
Grove 방문자 두 명이 Lantern Photography 정보를 열 때 기다린다고 보고했습니다. 정상 기준과 영향을 받은 두 방문이 하나의 캡처에 기록되어 있습니다. 긴 구간이 요청 전송 후인지, 다음 요청이 나타나기 전인지 찾습니다.
이전 실습의 HTTP 필터, Follow TCP Stream, 요청 응답 링크를 알아야 합니다. 이 실습은 새로운 독립 Desktop 환경에서 시작합니다. 시간 기준점과 정확히 정의된 두 구간을 배우며 프로그래밍이나 서버 수리는 필요하지 않습니다. 이 통제된 기록은 패킷 시간에 관한 결론을 뒷받침하지만 브라우저 렌더링이나 서버 CPU를 설명하지는 않습니다.
요청과 응답 측정하기
이 단계에서는 Aspen의 첫 상세 트랜잭션을 측정합니다. Desktop에서 시작해 왼쪽 아래의 Applications → Terminal Emulator를 열고 새 입력으로 Wireshark를 실행합니다.
wireshark /home/labex/project/event-page/input/casebook.pcapng
Wireshark를 최대화합니다. 서비스는 127.0.0.1:18182입니다. Maple(127.0.0.5)은 정상 기준, Aspen(127.0.0.6)과 Elm(127.0.0.7)은 보고된 방문, Pine(127.0.0.8)은 관련 없는 방문입니다. 각 방문은 지속 연결에서 목록, 상세, 프로그램, 다시 상세를 요청합니다. 지속 연결은 여러 요청 응답 교환 동안 연결을 열어 둔다는 뜻입니다.
Aspen의 HTTP 메시지를 필터링합니다.
ip.addr == 127.0.0.6 && http
첫 상세 GET을 선택합니다. HTTP를 펼치고 X-Request: aspen-02를 읽습니다. Response in frame → right-click → Go to Linked Packet으로 실제 응답을 찾고 역방향 Request in frame 링크도 확인합니다. 입력의 요청 프레임은 42, 응답은 46입니다.
응답에서 Time since request를 찾아 오른쪽 버튼을 클릭하고 Apply as Column을 선택합니다. 값은 약 1.6017초입니다. 1초는 1,000밀리초이므로 약 1601.7 ms입니다.
이는 이 기록의 요청 HTTP 해석 프레임부터 해당 응답 HTTP 해석 프레임까지의 구간입니다. Wireshark는 재조립의 마지막 세그먼트에서 완전한 메시지를 디코딩할 수 있습니다. 이를 서버 CPU 시간, 브라우저 페이지 로드 시간 또는 응답 첫 바이트까지의 시간이라고 부르지 마세요.
시간 기준점으로 구간을 눈으로 확인합니다. 요청 프레임 42를 선택하고 Edit → Set/Unset Time Reference를 실행합니다. 이 버전의 단축키는 Ctrl+T입니다. View → Time Display Format에서 Seconds Since Beginning of Capture를 선택합니다. 기준점이 설정되면 이 형식은 그 기준을 사용합니다. 요청은 *REF*로 표시되어 0 역할을 하며 해당 응답은 약 1.6017초 뒤에 있습니다. 비교 후 기준 패킷을 오른쪽 버튼으로 클릭하고 같은 명령으로 기준을 해제합니다.
이 대응에는 Seconds Since Previous Captured Packet이나 Previous Displayed Packet을 사용하지 마세요. 현재 목록의 이웃이 일치하는 요청일 필요는 없습니다. 필터를 바꾸면 이전 표시 패킷도 바뀝니다. 시간 기준점은 캡처에 영구 저장되지 않습니다. 다른 분석가가 재현할 수 있도록 명시적인 프레임 번호와 측정 구간을 기록하세요.
다음 프로그램 요청 aspen-03을 프레임 48에서 찾습니다. 상세 응답 46부터 요청 48까지의 간격은 약 0.3 ms입니다. 응답을 기준으로 설정해 프로그램 요청의 상대 시간을 읽고 기준을 해제합니다. 이 간격이 두 번째 지표입니다. 지정한 두 해석 프레임 사이의 구간이지 일반적인 사용자 생각 시간의 측정이 아닙니다.
여기서는 프레임 46에 *REF*가 표시됩니다. 프레임 48의 Time 열을 읽습니다. 0.000312566초는 약 0.3 ms입니다. 프레임 46의 별도 Time since request 열은 여전히 자체 요청 응답 쌍을 설명합니다. 서로 다른 두 구간입니다.
두 번째 Desktop 터미널과 Mousepad로 /home/labex/project/event-page/output/timing.csv를 만듭니다. Applications → Terminal Emulator를 다시 열고 실행합니다.
mousepad /home/labex/project/event-page/output/timing.csv
열은 방문, 첫 상세 요청, 해당 응답, 다음 프로그램 요청, 밀리초 단위의 두 구간, 관찰한 단계를 나타냅니다. 요청부터 응답이 길면 after, 다음 요청 전 간격이 길면 before, 둘 다 길지 않으면 normal을 사용합니다. 이 교육 기록에서는 800 ms를 넘으면 긴 구간입니다. 교육용 기준이며 운영 성능 목표가 아닙니다. 반올림 오차 5 ms 이내의 값을 허용합니다.
visit,request_frame,response_frame,next_request_frame,response_ms,gap_ms,stage
aspen,42,46,48,1601.7,0.3,after
Ctrl+S로 저장합니다. 증거는 Aspen의 긴 대기를 상세 요청 뒤에 위치시킵니다. 서버 내부 원인을 특정하거나 모든 네트워크 구성 요소가 정상이라고 증명하지는 않습니다.
간격 비교와 증거 보존하기
Elm과 정상 Maple 방문을 Aspen과 비교한 뒤 필요한 전체 대화를 보존합니다. Desktop에서 Wireshark와 원본 입력으로 돌아가 시작합니다. 새 측정을 시작하기 전에 모든 시간 기준점을 해제하세요.
Elm을 필터링합니다.
ip.addr == 127.0.0.7 && http
HTTP 프레임 링크로 첫 상세 요청의 실제 응답을 따라갑니다. elm-02는 요청 74, 응답 78입니다. 요청 응답 구간은 약 0.3 ms입니다. 다음 프로그램 요청 elm-03을 프레임 80에서 찾습니다. 프레임 78을 시간 기준으로 설정하면 80은 약 1.6012초 뒤에 나타납니다. 이후 기준을 해제합니다.
Elm의 긴 구간은 이전 응답 뒤이면서 다음 요청 앞입니다. 패킷 기록은 이 위치를 확정합니다. 클라이언트 타이머, 애플리케이션 작업, 사람의 늦은 동작은 구분할 수 없습니다. 추가 증거 없이 프런트엔드 버그라고 하지 마세요.
Maple도 ip.addr == 127.0.0.5 && http로 반복합니다. 첫 상세 요청, 해당 응답, 프로그램 요청은 프레임 12, 16, 17입니다. 두 구간 모두 1밀리초 미만입니다. 정상 기준은 긴 대기가 없는 같은 순서의 모습을 보여 줍니다.
Mousepad로 돌아가 Aspen 행을 보존하며 세 방문 전체로 표를 바꿉니다. 원본 입력의 프레임 번호와 밀리초를 사용합니다.
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
파일을 저장합니다. 영향을 받은 두 방문은 비슷하게 눈에 띄는 지연이 서로 다른 위치에 있습니다. 연결 전체 Duration으로는 구분할 수 없습니다. 각 스트림의 마지막 요청만 유지해도 반복 상세 요청을 올바르게 연결할 수 없습니다.
Wireshark에서 프로그램 응답을 살펴봅니다. HTTP 본문이 크고 TCP 세그먼트로 나뉘어 있습니다. 응답을 선택하고 Reassembled TCP와 완전한 JSON 제목 Lantern Photography를 확인합니다. 뒤의 추가 공백은 합성 교육용 채움이며 추가 JSON 객체가 아닙니다. 해석 프레임 구간에는 메시지 완성이 포함됩니다. 따라서 이 지표가 자동으로 첫 바이트 시간인 것은 아닙니다.
Maple, Aspen, Elm의 전체 연결을 유지합니다. ||는 어느 조건이든 일치하면 된다는 뜻입니다. 디스플레이 필터를 바꿉니다.
ip.addr == 127.0.0.5 || ip.addr == 127.0.0.6 || ip.addr == 127.0.0.7
&& http를 추가하지 마세요. 내보내기에는 앞선 TCP 세그먼트도 필요합니다. File → Export Specified Packets, Displayed → All packets를 선택하고 PCAPNG를 /home/labex/project/event-page/output/evidence.pcapng로 저장합니다. Pine은 제외합니다. 기존 출력이 있다면 이 코스의 출력 파일만 교체하고 원본 입력은 교체하지 마세요.
내보낸 파일을 열어 세 방문과 완전한 응답을 확인합니다. 내보낸 프레임 번호는 달라질 수 있으며 표는 원본 입력을 명시적으로 가리킵니다. 불완전하면 입력을 다시 열고 전체 연결을 다시 내보냅니다. 새 필터에 행이 없다면 예상 파일인지, 클라이언트 주소를 정확히 입력했는지 확인합니다. 필터를 지우면 패킷 목록이 복원됩니다.
유용한 결론은 정확합니다. Aspen의 긴 구간은 상세 요청 뒤이고 Elm의 긴 구간은 다음 프로그램 요청 앞입니다. 비교용 정상 Maple 트랜잭션도 보존됩니다. 서버 설정은 바꾸지 않았으며 더 강한 내부 원인 주장은 필요하지 않습니다.
요약
Wireshark 요청 링크, Time since request, 시간 기준점으로 두 가지 대기 위치를 비교했습니다. 정상 기준과 독립적으로 읽을 수 있는 대화를 보존했습니다. 결론은 관찰된 대기를 찾아내며 관찰하지 않은 애플리케이션 또는 네트워크 내부 원인을 단정하지 않습니다.
