ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [와이어샤크 #5] 지연 탐지
    EVI$ION/Wireshark 2019. 6. 24. 11:56

    ※ 실습 파일: http-openoffice101b.pcapng, http-pcaprnet101.pcapng

     

    [Time 열로 지연 문제점 검출하기]

    간혹 패킷 전송이 너무 지연되는 문제가 발생하는 경우가 있다. 이를 검출하기 위해서는 Time 열을 확인해야한다.

    Time 열을 통해서 대기 시간(Latency, 전달 지연)을 알 수 있다. 대기 시간이란, 호스트가 request를 보내고 response를 받을 때까지의 시간 간격을 말한다.

    Time 열과 Info 열을 같이 확인하면 경로, 클라이언트, 서버 입장에서의 대기 시간을 각각 검출할 수 있다.

     

    1) 경로 전달 지연

    : RTT (Round Trip Time, 왕복 시간) 전달 지연

     

    경로 전달 지연이 발생하는 원인은 아래와 같다.

    ▶ 우선 순위에 따라 라우팅하는 대규모 라우터를 사용하는 경우

     대역폭에 병목 현상이 발생하는 경우 (ex. 2개의 Giga 단위 네트워크를 10Mbps 링크에 연결한 경우)

       → 경로 전달 지연뿐만 아니라 패킷 손실도 동시에 발생한다.

     

     

    2) 클라이언트 전달 지연

    3가지 전달 지연(경로, 클라이언트, 서버) 중 가장 발생 확률이 낮다. 

    클라이언트 전달 지연이 발생하는 원인에는 여러 가지가 있다. 이때, 사용자 input이 제때 이루어지지 않는 경우 등 사용자 상호작용에 의한 지연은 고려하지 않는다.

     

    ▶ 자원 부족

    ▶ 애플리케이션 자체의 문제 (ex. 로딩이 느린 경우)

     

     

    3) 서버 전달 지연

    : 서버에 들어오는 요청에 대해, 서버가 느리게 응답할 때 발생한다.

     

    서버 전달 지연 원인은 아래와 같다.

    ▶ 서버의 요청 처리 능력 부족 (ex. 용량이 부족하거나 오래된 경우)

    ▶ 결함이 있는 애플리케이션

    ▶ 다중계층, 미들웨어 구조 사용 시, Response 정보 제공에 관한 타 서버와의 협의 사항

    ▶ 서버 응답을 지연시키는 외부의 간섭

     

    서버 지연을 판단하려면 아래 사항들을 확인해야 한다.

    ▶ 서버로 전송되는 클라이언트 요청 헤더 + 서버의 확인 응답

    ▶ 클라이언트가 요청한 정보가 수신되기 전까지의 대기 시간

        : 일정 수준의 지연은 일반적으로 많이 발생하기 때문에, 대기 시간이 지나치게 긴 경우에만 지연을 의심해봐야 한다.

     

     

    [Time 열 설정]

    와이어샤크에서 Time 열의 디폴트 값은 첫 패킷 시작부터 해당 패킷까지의 누적 시간이다. 만약 누적 시간으로 표시되는 Time 열의 값을 실제 전송에 걸린 시간 값으로 변경하려면 View → Time Display Format → Seconds Since Previous Displayed Packet를 체크해주면 된다. 이렇게 설정하면 전달 지연이 발생한 패킷을 쉽게 찾을 수 있다.

     

    변경 전 (누적 시간)
    View  → Time Display Format  → Seconds Since Previous Displayed Packet
    변경 후 (실제 전송 시간)

     

    위와 같은 Time 열 설정은 TCP Handshake, HTTP, DNS로만 구성된 단순 대화 패킷을 분석하는 경우에는 효율적일 수 있다. 하지만 Time 열에서는 단순히 각 패킷 간의 도착 시간차만을 측정하기 때문에 TCP/UDP 대화가 많은 경우에는 분석이 어렵다. 이러한 경우에는 개별적인 대화의 전달 지연을 알 수 있어야 하는데, 이때 사용되는 설정이 TCP Delta 설정이다.

     

     

    [TCP Delta 열 설정]

    위에서 말한 것처럼 개별적인 대화의 전달 지연을 탐지하기 위해서는 각 TCP 대화마다의 델타 시간(Delta Time)을 알아야 한다. 델타 시간이란, 직전 프레임으로부터의 시간 간격을 말한다. 이는 TCP Delta 열을 새로 생성함으로써 알아낼 수 있다.

     

    TCP 패킷의 패킷 상세 창에서 TCP Timestamps의 "Time since previous frame in this TCP stream" 선택 후 우클릭 → Apply as Column을 하면 새로운 열이 생성된다. 해당 열을 선택하여 우클릭  Edit Column에서 TCP Delta로 열 이름을 변경한다.

     

    TCP Timestamps → Apply as Column

     

    추가된 TCP Delta 열 (열 이름 변경하면 됨)

     

    Time 열과 TCP Delta 열의 차이는 아래와 같다.

    Time 열 = (현재 패킷이 도착한 시간) - (이전 패킷이 도착한 시간)

    TCP Delta 열 = (현재 패킷이 속한 TCP Stream 내에서 현재 패킷이 도착 시간) - (이전 패킷이 도착한 시간)

    (현재 TCP Stream의 첫 패킷은 TCP Delta 값이 무조건 0이다.)

     

     

    [정상적인 지연]

    앞서 잠깐 언급한 것처럼, 일정 수준의 지연은 많이 발생하기 때문에 이러한 지연은 정상적인 지연으로 분류하고 따로 분석하지 않는다. 정상적인 지연에 해당하는 경우는 아래와 같다.

     

    ▶ .ico 파일 요청

    - 브라우저 탭에 있는 아이콘을 눌렀을 때 관련 파일을 받아오기 위해 발생하는 지연이다.

     

    ▶ SYN 패킷 지연

    - 새로운 연결 설정을 위해 첫 SYN 패킷 앞에서 지연이 발생한다.

     

    ▶ FIN/RST 패킷

    - 연결을 종료하기 위해 사용되는 패킷이다.

    - 새로운 탭에서 작업을 수행하거나, 현재 사이트에서 최근 활동이 없을 때, 브라우징 세션이 페이지가 로드된 뒤에 자동으로 닫히도록 구성됐을 때 등의 경우에 지연이 발생한다.

    - 사용자가 알 수 없는 지연이다.

     

    ▶ GET 요청

    - 사용자가 다음 페이지를 요청하거나 백그라운드 프로세스가 페이지 연결을 시도할 경우, 해당 페이지로 연결할 때 지연이 발생한다.

     

    ▶ DNS 쿼리

    - 여러 개의 하이퍼링크를 가진 페이지가 클라이언트 컴퓨터 상에서 로드될 때 지연이 발생한다.

    - 각각의 페이지를 일일이 로드해야 하기 때문에 발생하는 지연이다.

     

    ▶ TLS v1 암호화된 경고

    - TCP 리셋 바로 전에 발생하는 지연이다.

    - 발생 확률은 낮다.

Designed by Tistory.