세미나 2차 - MacOS에서 Wireshark 실습하기 / 네트워크 지연

 

MacOS에서 Wireshark로 패킷 분석 실습을 해보자.

 

먼저 아래 링크에서 WireShark를 다운받는다. 

https://www.wireshark.org/download.html

Wireshark · Download

 

본인은 Intel CPU라서 그에 맞게 다운했다. 

 

Wireshark를 Applications로 드래그 앤 드롭해서 설치해준다. 

설치가 완료되었으면 아래 화면을 볼 수 있다. 

 

 

Wi-Fi:en1을 클릭하니 아래와 같은 에러가 떴다. 

 

You do not have permission to capture on device "en1".
((cannot open BPF device) /dev/bpf0: Permission denied)

Please check to make sure you have sufficient permissions.

If you installed Wireshark using the package from wireshark.org, close this dialog and click on the "installing ChmodBPF" link in "You can fix this by installing ChmodBPF." on the main screen, and then complete the installation procedure.

 

 

터미널에 아래 명령어를 입력해보자. 

sudo chown gildong /dev/bpf*

 

 

정상적으로 실시간 패킷이 잘 확인된다. 

아무튼 이제 다시 돌아오자.

각 패킷이 어디서부터(Source) -> 어디로(Destination) / 어떤 포트를 사용해서 / 패킷을 어느 정도의 길이만큼 주고 받았는지를 확인할 수 있다. 

 

 

 

왼쪽 하단에는 각 패킷의 세부 정보가 나와 있는데 세부 정보에 우클릭을 해서 Apply as Column을 클릭하면

해당 세부 정보를 컬럼으로 추가할 수 있다. 

 

---

패킷 필터링

이 많은 패킷들 중 네트워크 지연 분석을 하려면 어떻게 해야할까?

우선 이 많은 패킷들에 필터를 걸어서 원하는 패킷들만 추출해서 볼 수 있어야 한다. 

 

패킷 필터 방법

패킷 필터 방법은 아래 두 가지가 있다.

1. Capture Filter

• 패킷 수집할 때 부터 필터를 걸어서, 원하는 패킷만 Capture(수집)하는 방법
• 이 방법은 처음 수집할 때부터 조건이 적용되기 때문에 성능에 영향을 줄 수 있다.
• ex. tcp port 443

 

2. Display Filter

• 먼저 전체 패킷을 수집하고 그 이후에 Display 되는 화면에서 필터를 걸어서 보는 방법
• 다양한 필터 조건을 걸 수 있고, 대게 권장되는 방법이다. 
• ex. tcp.port = 443

 

패킷 필터 종류

이제 필터의 종류에 대해 알아보자.

 

우선 필터 예시를 확인해보자.

Analyze > Display Filters 를 클릭하면 

 

아래와 같이 필터 예시가 나온다. +를 눌러서 자주 쓰는 필터를 추가할 수도 있다. 

 

 

 

유용한 필터들을 자세히 좀 정리해보자.

• 프로토콜 필터 : tcp || udp

필터 종류	예시	설명
프로토콜	tcp || udp
MAC 주소	wlan.addr == 00.00.00.000.00.00 wlan.sa == 00.00.00.000.00.00 wlan.da == 00.00.00.000.00.00	무선랜 사용 시 출발지/목적지 MAC 주소로 검색
	eth.addr == 00.00.00.000.00.00 eth.src == 00.00.00.000.00.00 eth.dst == 00.00.00.000.00.00	출발지/목적지 MAC 주소로 검색 출발지 MAC 주소로 검색 목적지 MAC 주소로 검색
포트	tcp.port == 1111 tcp.dstport == 1111 tcp.srcport == 1111	출발지/목적지 모두 목적지만 출발지만
IP 주소	ip.addr == 192.168.0.10 ip.src == 192.168.0.11 ip.dst == 192.168.0.11	출발지/목적지 IP 주소로 검색 출발지 IP 주소로 검색 목적지 IP 주소로 검색
TCP 연결	tcp.flags.syn == 1 tcp.flags.fin == 1 tcp.flags.reset == 1	TCP 연결 O TCP 연결 X TCP 서버 포트 닫혀 있을 때
특정 Byte 포함 여부	data contains 0A:0B:0C:0D	데이터에 16진수 0A0B0C0D 값을 포함하는 패킷 검색
특정 문자열 포함 여부	data contains "\"hello\""	쌍따옴표를 포함하는 문자열을 필터링 할 때는 \" 활용

 

 

 

 

 

패킷 세부 정보를 볼 때 해당 패킷 기준으로 필터를 걸고 싶을 때는 해당 정보에 우클릭 후 Apply as Filter 를 사용하면 된다. 

 

 

그럼 위쪽의 필터에 자동으로 ip.src==142.250.256.238 조건이 지정되었고

Source Address가 142.250.256.238 인 패킷들만 display 된 것을 확인할 수 있다. 

 

 

 

---

Packet Delay 여부를 분석하기 위해서는 어떻게 해야 할까?

우선 가장 기본이 되는 시간 컬럼을 잘 분석해야 한다. 

Req ~ Rep 간에 소요되는 시간이 패킷별로 일정한지, 일정하지 않다면 변화가 생기는 지점을 분석해봐야 한다. 

 

 

참고로 시간 포맷은 View > Time Display Format 으로 들어가서 선택할 수 있다. 

 

 

Time Column 종류

• Seconds Since First Captured Packet
  • 첫번째 패킷이 캡쳐된 시간을 0으로 지정하고 그 이후의 패킷들은 첫번째 패킷의 시간을 기준으로 비교해서 측정된다. 

 

 

• Seconds Since Previous Captured Packet
  • 이전 패킷을 기준으로 다음 패킷이 수집되기까지 (받거나 보내거나) 걸리는 시간을 보여준다. 
  • 아래 예시를 보면 2번 패킷은 1번 패킷이 수집되고 0.003859초만에 왔다.
  • 3번 패킷은 2번 패킷이 수집되고 0.000018초만에 왔다. 
  • 4번 패킷은 3번 패킷이 수집되고 0.000001초만에 왔다. 

 

• Seconds Since Previous Displayed Packet
  • 화면에 디스플레이 된 패킷들만 대상으로 두고, 이전 패킷을 기준으로 다음 패킷이 수집되기까지(받거나 보내거나) 걸리는 시간을 보여준다.
  • 이 옵션은 필터가 지정되어 있지 않을 때는 위의 Captured Packet 옵션이랑 동일하다.
  • 그러나 필터가 적용되면 아래와 같이 화면에 보여지는 패킷들(조건 지정된 패킷들) 만 대상으로 패킷간에 전달된 시간을 보여준다. 
  • 7번과 9번 패킷을 보면 7번 패킷 이후에 9번 패킷이 오기까지 0.048793초가 걸렸다. 이는 위 사진을 보면 7번~8번 패킷 간 걸린 시간인 0.001079초와 8번~9번 패킷 간 걸린 시간인 0.047714초를 더한 시간임을 알 수 있다. 

 

 

---

 

네트워크 지연의 원인

 

1. 흐름 제어 (Flow Control)

수신 측 처리 속도보다 송신 측 전송 속도가 빠를 때 발생한다. 

수신 측의 용량보다 더 빠르게 보내서 패킷이 손실되면(OverFlow), 다시 불필요한 전송과 Ack/Nack 응답을 주고 받아 확인해야하므로 이로 인한 딜레이가 발생할 수 있다. 

해결 방법으로는 Stop and Wait와  Sliding Window 가 있다.

1) Stop and Wait

첫번째 Stop and Wait 방식은 매번 잘 받았다고 응답을 보내야 다음 패킷을 보내는 방식이기 때문에 데이터 유실 없이 안정적인 전송이 가능하겠지만 데이터 전송에 시간이 오래 걸릴 수 있다.

 

2) Sliding Window

두번째 Sliding Window 방식은 받는 쪽에서 정한 데이터 크기(Window Size) 에 해당하는 패킷들을 전부 보내서 각 패킷의 응답이 오지 않아도 여러 패킷을 보낼 수 있다. 각 패킷별로 잘 받았다는 응답이 와야 다음 패킷을 보낼 수 있는 Stop and Wait 보다 훨씬 효율적인 방법이다. 통신 과정 중에 네트워크가 혼잡하다면 윈도우 크기는 유동적으로 바뀔 수 있다. 

 

Sliding Window 방식으로 흐름제어를 하지만 이로 인해 데이터 읽기 속도 저하가 발생할 수 있다. 아래를 보자.

* 흐름제어로 인한 데이터 읽기 속도 저하

TCP header 에는 Window Size가 있다. Window Size값이란 수신자가 받을 수 있는 최대 데이터 크기를 의미한다. 

출처 : https://velog.io/@joosing/2-external-factors-that-can-delay-a-server-response

 

App(수신자)이 네트워크를 통해 전달된 패킷을 받으면 버퍼가 채워지고, App이 데이터를 처리하면(읽으면) 버퍼가 비워진다. 

만약 App의 처리 속도가 1분에 10개의 패킷을 처리한다고 했을 때, Sender 쪽에서 그 보다 더 빠른 속도로 패킷을 전송하면 App의 Window가 점점 차게 된다. 

그럼 Sender 는 데이터의 일부만 보내거나 아예 보낼 수 없는 상황이 발생하고 서버가 전체적으로 지연되는 것이다. 

이런 상황은 어떻게 알 수 있을까?

네트워크에 쓰기 요청을 했는데 그 결과가 0 byte만큼 썼다고 나오면 -> Window Size로 인해 서버 지연이 발생하고 있는 상황을  의심해 볼 수 있다. 

 

 

 

 

2. 혼잡 제어(Congestion Control)

혼잡제어도 흐름제어와 동일하게 받는 쪽에서 처리하는 데이터 속도보다 보내는 쪽의 속도가 더 빠를 때의 문제를 해결하기 위한 기법이다. 다른점은 혼잡제어는 흐름제어와 달리 보다 넓게 호스트 및 라우터를 포함한다. 

 

1) AIMD (Additive Increase Multiplicative Decrease)

정상 시 윈도우 크기를 1씩 증가시키면서 보내다가 패킷 전송 실패 혹은 딜레이 발생 시 패킷 전송 속도를 절반으로 줄이는 방식이다. 

처음에 전송 속도가 느리다는 단점과 문제가 발생하고 나서야 개선을 한다는 단점이 있다.

 

2) Slow Start

AIMD와 비슷하지만 윈도우 크기를 지수적으로 증가시킨다. 즉, 매 RTT마다 2배를 키우다가 (1,2,4,8,16,,) 문제 발생 시 윈도우 크기를 1로 줄인다. 

 

 

 

참고) 

아래 그림은 하드웨어의 네트워크 지연을 나타낸 그림이다.

1. 전송 지연 : 네트워크 장비 자체의 속도로 인함
2. 전파 지연 : 전송 거리로 인함
3. 처리 지연 : 라우터 자체 작업 처리로 인함 (패킷 헤더 처리, 비트 데이터 오류 등)
4. 큐 지연 : 라우터에서 처리하는 중에 추가로 들어오는 데이터들은 큐에 push 후 전송함 

출처 : https://www.baeldung.com/cs/packet-time-latency-bandwidth

 

 

 

 

---

참고) 정상적인 지연 발생 케이스

[와이어샤크 #5] 지연 탐지

[정상적인 지연]

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

 

▶ .ico 파일 요청

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

 

▶ SYN 패킷 지연

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

 

▶ FIN/RST 패킷

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

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

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

 

▶ GET 요청

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

 

▶ DNS 쿼리

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

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

 

▶ TLS v1 암호화된 경고

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

- 발생 확률은 낮다.

 

 

 

 

---

다음 세미나 주제

실제 현장에서 네트워크 딜레이 발생 시 원인 분석을 단계별로 해 나가는 방법 및 실전에서 사용하는 툴

https://blog.ahnlab.com/1288

안철수연구소에서 알려주는 실전 패킷 분석

 

 

 

---

참고

https://velog.io/@joosing/Wireshark-%ED%8C%A8%ED%82%B7-%ED%95%84%ED%84%B0-A-to-Z

https://as-backup.tistory.com/31