1. 와이어샤크 설치 및 사용법

앞서 패킷의 개념을 설명했는데, 실제 패킷이 어떻게 생겼는지 궁금할 것이다.

• 패킷의 모습은 패킷 캡처 프로그램을 사용해서 관찰할 수 있다.
• 패킷 캡처 프로그램은 네트워크에서 송수신되는 패킷을 모니터링하고 분석할 수 있는 프로그램이다.
• 대표적인 패킷 캡처 프로그램 중 하나로 와이어샤크(WireShark)라는 프로그램이 있다.

다만, 와이어샤크는 오늘날까지 지속적으로 개발되고 있는 프로그램이라 이 글을 읽는 시점에 따라 설치 방법이나 사용법이 약간 다를 수도 있다. 그러나 와이어샤크 같은 대중적인 프로그램은 기존 사용자들이 사용법을 다시 익혀야 하는 큰 변화가 일어나는 일이 드물다.

1.1 와이어샤크 설치

1.1.1 윈도우

(1) https://www.wireshark.org/download.html에 접속해서, [Downlaod Wireshark]의 [Stable Release]에서 본인의 컴퓨터 환경에 맞는 Windows 설치 파일을 다운로드한다.

(2) 다운로드한 설치 파일(Wireshark-버전명-운영체제명.exe)을 더블 클릭한다. 본격적으로 설치를 시작하기 전에 혹시 와이어샤크가 실행 중인지 확인한다는 내용이다. 계속하려면 [Next] 버튼을 클릭한다.

(3) 라이선스 동의 여부를 묻는 화면이 나타나면, [Noted] 버튼을 클릭하여 라이선스에 동의한다.

(4) 와이어샤크 재단에 대한 기부 안내 화면이 나타나면, 호원 여부와 상관없이 [Next] 버튼을 클릭하여 설치를 진행한다.

(5) 다음으로 와이어샤크 설치 시 구성 요소를 선택하는 화면이 나온다. [TShark], [Tools] 등 구성 요소를 선택할 수 있지만, 기본 설정으로 설치하기 위해 모두 체크된 상태에서 [Next] 버튼을 클릭한다.

(6) 와이어샤크를 시작 메뉴, 데스크톱 아이콘, 빠른 실행 아이콘으로 등록할지, 와이어샤크 관련 파일 확장자도 함께 이용할지 여부를 묻는다. 원하는 항목에 체크한 후 [Next] 버튼을 클릭한다.

(7) 설치 경로를 결정하는 화면이 나타나면, 경로를 확인하고 [Next] 버튼이 클릭한다. 다른 경로에 설치하고 싶다면 [Browse…] 버튼을 클릭해 원하는 경로를 지정할 수도 있다.

(8) 와이어샤크는 윈도우에서 실시간 패킷 캡처를 하기 위해서 내부적으로 Npcap 혹은 WinPcap 이라는 프로그램을 이용한다. WinPcap이 설치되어 있다면, Npcap은 설치할 필요가 없으니 [Next] 버튼을 클릭한다.

💡 WinPcap 미설치 시 진행 과정

만약 WinPcap이 설치되어 있지 않거나 최신 버전의 패킷 캡처 기능을 사용하고 싶다면, [install Npcap] 옵션을 체크하고, [Next] 버튼을 클릭한다.이후 설치 과정에서 Npcap 설치와 함께 진행된다.

(9) 와이어샤크는 USB 트래픽을 캡처하는 기능도 제공한다. 하지만 이 기능은 여기서 다루지 않으므로, [Install USBPcap]은 체크 해제한 후, [Install] 버튼을 클릭한다.

(10) 모든 과정을 마쳤다면, 이제 자동으로 와이어샤크 설치가 진행된다. 만약 앞에서 [Install Npcap]에 체크한 경우, 설치 중에 Npcap 설치를 위한 화면이 나타날 수 있다. 해당 화면에서 Npcap 설치를 완료하면, 와이어샤크 설치가 재개된다.

(11) 와이어샤크의 설치가 완료되면, [Next] 버튼을 클릭한다.

(12) 설치가 완료되었다. [Finish] 버튼을 클릭하면 모든 설치 과정이 끝난다.

(13) 시작 메뉴에서 설치된 와이어샤크를 선택하여 실행해보세요. 창이 나타나면 설치가 제대로 된 것이다.

1.1.2 맥

(1) https://www.wireshark.org/download.html에 접속해서, [Downlaod Wireshark]의 [Stable Release]에서 본인의 컴퓨터 환경에 맞는 Windows 설치 파일을 다운로드한다.

(2) 다운로드한 파일을 실행하면 화면이 나타난다. 와이어샤크를 설치하기 위해 와이어샤크 아이콘을 [Application] 폴더로 드래그한다. 다음으로 패킷 캡처를 위해 같은 화면에서 [Install ChmodBPF.pkg]로 클릭하여 ChmodBPF를 설치한다.

💡 ChmodBPF의 설치 과정은 간단하므로, 따로 첨부하지 않는다.

ChmodBPF를 삭제하고 싶다면, 해당 화면에서 [Uninstall ChmodBPF.pkg]를 클릭하여 삭제할 수 있다.

(3) 와이어샤크를 사용할 준비가 되었다. 응용 프로그램(Application)에서 와이어샤크를 실행해보세요. 창이 보인다면 설치가 제대로 된 것이다.

1.2 와이어샤크 사용법

1.2.1 패킷 캡처

(1) 와이어샤크를 처음 실행하면 나타나는 화면에서 어떤 네트워크 인터페이스에서 송수신될 패킷을 관찰하고 싶은지 선택한다.

• 필자는 와이파이로 연결된 인터페이스를 선택했다.
• 특정 인터페이스를 통해 패킷이 송수신되고 있다면,
  • 위 화면처럼 해당 인터페이스 이름 오른쪽에 지그재그 모양의 차트가 그려진다.

(2) 선택한 후에는 위와 같은 화면을 확인할 수 있다. 이후 설명하지만, 그림의 좌측 상단에 있는 네모 모양의 캡처 중단 아이콘도 살펴보자.

(3) 송수신되는 패킷을 더욱 명확히 캡처하기 위해 웹 브라우저를 열고, http://example.com에 접속해보자. 해당 URL에 접속하기 위해 http 프로토콜로 주고받을 패킷도 캡처될 것으로 기대할 수 있다.

1.2.2 와이어샤크 화면 구성

다시 와이어샤크로 돌아와서, 앞서 말씀드린 좌측 상단의 캡처 중단 아이콘을 클릭하면, 캡처가 중단된다.

• 캡처를 중단하고, 위쪽 그림의 구성을 관찰해보자.
• cf. 캡처 중단 버튼의 좌측에 위치한 상어 지느러미를 클릭하면, 캡처를 다시 수행할 수 있다.

(1)번 박스 부분부터 살펴보면, 해당 부분에서는 선택한 인터페이스에서 송수신된 패킷들에 대한 정보를 확인할 수 있다.

• 이 정보에는 패킷 번호(No), 시간(Time), 송신지(Source), 수신지(Destination), 프로토콜(Protocol), 패킷의 길이(Length) 그리고 해당 패킷에 대한 간략한 설명(info)이 포함된다.

임의의 패킷 하나를 클릭해서 확인해보세요. 필자는 HTTP 프로토콜 패킷(6389번 패킷)을 클릭했다.

이번에는 우측 하단의 (2)번 박스를 살펴보면, 이 박스에서는 패킷에 해당하는 실제 데이터를 확인할 수 있다.

• 컴퓨터는 기본적으로 0과 1로 표기되는 2진수만 이해할 수 있기에,
• 실제 네트워크에서 송수신되는 데이터 또한 2진수 형태다.
• 그러나 2진수를 그대로 표기하면, 표기가 길어지므로 16진수로 줄여서 쓴 것이다.

다음으로 좌측 하단 (3)번 박스를 확인해보면, 해당 패킷이 어떻게 캡슐화되어 있는지 알 수 있다.

• 아래부터 HTTP, TCP, IPv4, 이더넷 프레임으로 캡슐화된 것을 볼 수 있다.

이번에는 위 그림처럼 [Hypertext Transfer Protocol]을 클릭해보세요.

• 그러면 우측 하단의 데이터 중에서 HTTP 메시지에 대한 내용이 강조된다.
• 즉, 우측 하단의 검은색 배경으로 강조된 47 45 54로 시작하는 부분이 HTTP 메시지다.
• 좌측 하단의 [Hypertext Transfer Protocol]을 펼쳐보면, HTTP 메시지(GET 요청) 내용이 명시된다.
• Host, Connection, Cache-Control 등 5장에서 학습한 HTTP 헤더다.

위 화면처럼 [Transmission Control Protocol]을 클릭하면, 전체 패킷 중에서 TCP 세그먼트에 대한 내용이 강조된다.

• 우측에 강조된 d4 9e 00 ~ 31 00 00이 TCP 세그먼트다.
• [Transmission Control Protocol]을 펼쳐보면,
  • 4장에 본 TCP 세그먼트 필드인 송신지 포트번호(Source Port), 수신지 포트 번호(Destination Port),
  • 순서 번호(Sequence Number), 확인 응답 번호(Acknowledgment Number) 등을 확인할 수 있다.

cf. 위쪽 화면을 보면 [Sequence Number: 1 (relative sequence number)]와 [Sequence Number (raw): 3113215236]이라는 두 개의 순서 번호(Sequence Number)가 있다.

• 전자는 와이어샤크에게 가독성을 높이기 위해 설정한 상대적인 수선 번호이고,
• 후자는 실제 순서 번호다.
• 실제 초기 순서 번호는 임의의 수로 설정된다.
• 다만 임의의 수로 초기화된 실제 순서 번호(raw)로는
  • 해당 세그먼트가 몇 번쨰 순서 번호인지 한눈에 파악하기 어려우므로,
  • 와이어샤크에게 상대적인 순서 번호(relative sequence number)를 부여한 것이다.

확인 응답 번호(Acknowledgment)도 마찬가지다. [Acknowledgment Number: 1 (relative ack number)]와 [Acknowledgment Number (raw): 3472132722]라는 두 개의 확인 응답 번호가 있다.

• 전자는 가독성을 높이고자 임의로 설정한 상대적인 확인 응답 번호이고,
• 후자는 실제 확인 응답 번호다.

그리고 [Stream index], [Conversation completeness], [TCP Segment Len]과 같이 대괄호로 표기된 필드도 확인할 수 있다.

• 이는 실제로 프로토콜에 구현된 필드는 아니지만, 네트워크를 분석하기 쉽도록 와이어샤크가 추가한 일종의 가상필드다.
• 이 필드들은 뒤에 이어지는 패킷 필터링에서 유용하게 사용될 수 있다.

다음으로 [Internet Protocol Version 4]를 클릭해보면, IPv4 패킷에 대한 내용이 강조된다.

• 위 화면에서 우측 하단에 검은색 배경으로 강조된 45 00 02 ~ b8 d8 22가 IP 패킷이다.
• 이 또한 3장에서 배운 IPv4 패킷의 필드를 포함하고 있음을 확인할 수 있다.

마지막으로 [Ethernet 2]를 클릭해보면, 위 화면처럼 이더넷 프레임에 대한 내용이 강조된다.

• 2장에서 학습한 이더넷 프레임의 수신지 MAC 주소(Destination), 송신지 MAC 주소(Source), 타입/길이(Type) 등이 명시되어 있다.

지금까지 와이어샤크를 통해 하나의 패킷이 어떻게 캡슐화되어 있는지, 실제 네트워크에 흐르는 데이터는 어떤 꼴을 이루고 있는지 확인해봤다.

1.2.3 패킷 필터링

와이어샤크가 제공하는 또 하나의 강력한 기능으로 패킷 필터링 기능이 있다.

• 위쪽 화면에서 붉은색 박스로 표시된 입력 창에 와이어샤크 필터를 입력하면,
  • 캡처된 패킷 중에서 필터 조건에 맞는 특정 패킷만 조회할 수 있다.
• e.g. 위와 같이 입력 창에 http를 입력하면, 캡처된 패킷 중에서 HTTP 패킷을 필터링한 경과를 보여준다.

그렇다면 가장 기본적인 필터의 대표적인 예부터 알아보자.

cf. TLS는 뒤에서 학습한다.

기본 필터에 대한 더욱 세부적인 필터링도 가능하다.

• 모든 종류를 나열하기는 어렵지만, 자주 사용되는 대표적인 필터를 다음 표로 정리했다.
• 외우기보다는 기존에 학습한 프로토콜에 포함된 필드(혹은 와이어샤크에서 제공된 가상의 필드)를 기준으로 가볍게 읽어보길 바란다.
• 이전에 학습한 내용들을 상기해보면 아는 내용일 것이다.

eth 관련 필터

ip 관련 필터

udp 관련 필터

tcp 관련 필터

http 관련 필터

이 외에도 와이어샤크에게 제공하는 필터는 여기서 모두 다루기 어려울 만큼 다양하다.

• 더 많은 필터를 학습하려면 다음 URL의 [wireshark-filters] 항목을 참고하세요.
• cf. https://github.com/kangtegong/self-learning-cs2/tree/main/wireshark-filters

이러한 필터들은 일반적으로 연산자와 함께 사용된다.

• 와이어샤크에서 연산자는 여러 필터를 조합하여 사용하거나 특정 조건을 만족하는 필터를 확인하는데 사용된다.
• 자주 사용되는 대표 연산자의 종류는 다음과 같다.

💡 연산자의 우선순위 또한 일반적인 프로그래밍 언어의 연산자와 유사하다.

e.g. ip.src == 192.166.219.100 또는 ip.src eq 192.166.219.100은 송신지 IP 주소(ip.src)가 192.166.219.100과 같은 패킷들만 걸러내는 필터다.

• 이와 유사하게 tcp.port != 80 또는 tcp.port ne 80은 TCP 포트 번호(tcp.port)가 80과 같지 않은 패킷들만 걸러내는 필터다.

e.g. tcp.seq <= 1000 또는 tcp.seq le 1000은 TCP 순서 번호(tcp.seq)가 1000 이하인 패킷들만 걸러내는 필터다.

• 마찬가지로 udp.port > 1023 또는 udp.port gt 1023은 UDP 포트 번호(udp.port)가 1023을 초과하는 패킷들만 걸러내는 필터다.

그렇다면 tcp || udp는 무엇일까?

• 이는 tcp or udp와 같은 필터로, tcp 또는 udp 패킷들만 걸러내는 필터다.
• 마지막으로 ip.src == 192.168.219.102 && tcp.dstport == 80이라는 필터도 확인해보자.
• 이는 ip.src eq 192.168.219.102 and tcp.dstport eq 80과 같은 필터다.

1
ip.src == 192.168.219.102 && tcp.dstport == 80
2

3
ip.src == 192.168.219.102 ------- (1)
4
&& ------- (3)
5
tcp.dstport == 80 ------- (2)

이 필터는 다음 조건을 만족하는 패킷들만 걸러낸다.

• (1) IP의 송신지 주소(ip.src)가 192.168.219.102와 같고,
• (2) TCP의 수신지 포트 번호(tcp.dstport)가 80과 같으며,
• (3) 이 둘을 동시에 만족하는 패킷들만 걸러낸다.
• 이 필터를 사용하면, 192.168.219.102가 80번 포트 번호를 향해 전송한 패킷만 조회할 수 있다.

1
(ip.src == 192.168.219.100) && (tcp.dstport == 80)
2

3
(ip.src == 192.168.219.100) ------- (1)
4
&& ------- (3)
5
(tcp.dstport == 80) ------- (2)

e.g. 위 그림에서 나오는 필터는 괄호로 묶어서 표기할 수 있다.

• cf. 여러 연산을 괄호로 묶어서 표기할 수도 있다.
• 괄호는 연산자처럼 우선순위가 높으므로, 먼저 연산되기를 원하는 연산자는 괄호로 묶어서 표현하면 된다.

와이어샤크의 필터 종류는 매우 다양하므로, 처음부터 모든 필터를 암기할 필요는 없다.

• 대부분의 와이어샤크 필터는 프로토콜의 역할과 필드만 잘 기억해두면 언제든지 빠르게 익힐 수 있으니,
• 지금으로서는 위에서 설명한 대표적인 필터들 정도만 알고 있어도 무방하다.

1.2.4 캡처 파일 저장과 열기

이제 캡처한 파일을 패킷 캡처 파일로 저장해둔다.

(1) 패킷 캡처 파일은 일반적으로 pcap 확장자 또는 pcapng 확장자로 저장된다.

• 이런 파일로 캡처 파일을 저장하면, 언제든지 캡처된 패킷들을 다시 열어서 조회할 수 있다.
• 위 화면처럼 [File] - [Save] 메뉴를 클릭해보세요.

(2) [Save Capture File As] 창이 나타나면, [저장 위치], [파일 이름]을 설정한 뒤 [저장] 버튼을 클릭한다.

• 이렇게 저장된 패킷 캡처 파일은 와이어샤크로 다시 열어볼 수 있다.

여기서 배운 내용을 와이어샤크로 복습할 수 있도록 몇 개의 패킷 캡처파일이 있다.

• 와이어샤크, 강의 자료 등에서 자유롭게 사용하도록 배포된 패킷 캡처 파일들을 변형한 파일이다.
• cf. https://github.com/kangtegong/self-learning-cs2/tree/main/packets

(3) 패킷 캡처 파일을 다운로드한 뒤, 와이어샤크로 돌아와보자.

• [File] - [Open] 메뉴를 클릭하고, 다운로드한 패킷 캡처 파일을 선택한 뒤, [열기] 버튼을 클릭해보세요.

(4) 파일을 열면, 위 화면처럼 패킷의 내용을 확인할 수 있다.

다음 절에서는 사전에 준비된 이 패킷 캡처 파일들의 일부를 활용해 프로토콜의 실제 모습과 동작을 관찰해본다.

2. 와이어샤크를 통한 프로토콜 분석

1
ipv4-fragmentation.pcapng
2
ipv6-fragmentation.pcapng
3
3-way-handshake.pcapng
4
connection-close.pcapng
5
tcp-retransmission.pcapng
6
http-request-response.pcapng

앞서 와이어샤크 설치 및 사용법을 배웠다.

• 이제 패킷 캡처 파일을 분석해볼 것이다.
• 분석할 파일은 총 6가지로, 위에서 명시된 파일들이다.
• cf. 준비한 패킷 속 IP 주소, MAC 주소 등은 임의로 생성한 것으로, 패킷 캡처 파일 내 정보는 학습자료로만 참고.
• cf. https://github.com/kangtegong/self-learning-cs2/tree/main/packets

2.1 IP 분석

와이어샤크를 사용해 IP 분석을 수행해보자. 총 6개의 파일 중 IPv4 단편화와 ICMP에 대해 학습한다.

2.1.1 IPv4 단편화 + ICMP

가장 먼저 ipv4-fragmentation 파일을 열어보면, IPv4의 단편화 과정과 ICMP 패킷을 보여주는 패킷 캡처 파일이다.

• 1번부터 7번까지는 호스트 10.0.0.1이 10.0.0.2에게 패킷을 전송하는 과정이고,
• 8번부터 14번까지는 10.0.0.2가 10.0.0.1에게 패킷을 전송하는 과정이다.

각 패킷의 [Internet Protocol Version 4] 항목을 확인해보면, (e.g. 1번 패킷을 보면),

• 3장에서 IP의 주된 2가지 역할은 IP 단편화와 IP 주소 지정이라고 했다.
• 이 패킷을 보면 송신지 IP 주소(Source Address), 수신지 IP 주소(Destination Address) 필드를 통해 주소 지정이 이루어지고 있음을 확인할 수 있다.

단편화에 관여하는 필드는 식별자(Identification), 플래그(Flags), 단편화 오프셋(Offset)이라고 설명했다.

• 식별자에 해당하는 Identification 값을 살펴보자.
• 식별자는 같은 패킷에서부터 단편화되었음을 나타내기 위해 IPv4 패킷에 부여되는 고유한 값이다.

1번부터 7번 패킷까지의 식별자 값은 0x2c2e(11310)로 동일하며,

• 8번부터 14번 패킷의 식별자 값도 직접 확인해보면, 0x2aad(10925)로 동일하다는 것을 알 수 있다.
• 이는 1번부터 7번 패킷까지의 패킷들과 8번부터 14번까지의 패킷들이 본래 하나의 데이터 덩어리가 단편회된 것임을 나타낸다.

이번에는 플래그(Flags)를 살펴보면,

• 1번 패킷부터 6번 패킷까지, 8번 패킷부터 13번 패킷까지의 플래그를 보면,
  • more fragment(MF) 플래그사 설정되어 있는 것을 확인할 수 있다.
• 이는 다음에 더 단편화된 패킷이 있음을 나타낸다.

반면, 7번 패킷과 14번 패킷은 MF 플래그가 활성화되어 있지 않다. 이는 더 이상의 단편화된 패킷이 없음을 의미한다.

마지막으로 각 패킷의 단편화 오프셋(Offset)도 살펴보면,

• 단편화 오프셋은 단편화된 패킷이 초기 데이터로부터 얼마나 떨어져 있는지를 나타낸다고 했다.
• e.g. 1번부터 6번까지의 패킷의 [offset] 항목은 각각 0, 1480, 4440, 5920, 7400 으로,
  • 이를 통해 각 패킷의 데이터는 1480 바이트씩 떨어져 있음을 알 수 있다.

cf. 단편화 오프셋 값과 하단의 [Length] 열의 의미를 혼돈할 수도 있다.

• [Length] 열은 이더넷 프레임 헤더 14바이트와 IP 헤더 20바이트를 포함한 패킷의 전체 크기를 바이트 단위를 표현한 것이다.
• 반면 단편화 오프셋인 1480은 단편화된 데이터만 고려한 크기를 나타낸다는 점에서 다르다.

ICMP 패킷이 포함된 7번 패킷과 14번 패킷도 간략히 살펴보면,

• 7번 패킷과 14번 패킷의 [Internet Control Protocol] 항목을 확인해보세요.
• 앞서 4장에서 ICMP를 학습했다.
• ICMP는 패킷의 전송 과정에 대한 피드백 메시지를 얻고자 사용하는 프로토콜이고,
  • 피드백 메시지의 종류는 ICMP 패킷의 타입 필드와 코드 필드의 조합으로 정의된다고 했다.
• 그럼 7번 패킷과 14번 패킷의 타입과 코드를 확인해보자.

7번 패킷의 타입(Type)은 8이고, 코드(Code)는 0이다.

• 타입 8, 코드 0에 해당하는 ICMP 메시지는 에코 요청 메시지라는 점을 알 수 있다.

14번 패킷의 타입은 0이고, 코드는 0이다.

• 이에 부합하는 ICMP 메시지는 에코 응답 메시지다.
• 다시 말해, 14번 패킷은 7반 패킷의 에코 요청에 대한 에코 응답이다.

2.1.2 IPv6 단편화 + UDP

이번에는 ipv6-fragmentation 파일을 열어보면, 아 파일은 ipv6의 단편화와 UDP 데이터그램을 보여주는 파일이다.

• 1번과 2번패킷은 20f4:c750:2f42:53df::11:0이 26f7:f750:2ffb:53df::1001에게 보내는 과정을 나타내며,
• 3번부터 6번 패킷까지는 26f7:f750:2ffb:53df::1001이 20f4:c750:2f42:53df::11:0에게 패킷을 전송하는 과정을 나타낸다.

💡 IPv6 주소 줄여쓰기

1
20f4:c750:2f42:53df:0000:0000:0011:0000
2
26f7:f750:2ffb:53df:0000:0000:0000:1001

IPv6 주소는 128 비트 크기의 주소 체계로,

• 하나의 IPv6 주소를 표현하기 위해서는 원칙적으로 32개의 16진수가 필요하다.
• 위 표시와 같이 4개의 16진수가 콜론(:)으로 구분되어 8개의 그룹으로 나뉘게 된다.

하지만 와이어샤크 속 IPv6 주소를 보면, 32개의 16진수가 사용되지 않는다.

• 이는 IPv6 주소의 16진수 일부가 생략된 것이다.
• (1) 콜론으로 구분된 그룹 앞부분에 0이 연속해서 등장할 경우, 연속된 0은 하나의 0으로 단축할 수 있고(),
• (2) 여러 필드에 걸쳐 0이 연속해서 등장할 경우, ::과 같이 필드에 명시되는 0을 생략할 수 있다.

요컨대 위 예시 속 20f4:c750:2f42:53df::11:0과 26f7:f750:2ffb:53df::1001은

• 사실 20f4:c750:2f42:53df:0000:0000:0011:0000과
• 26f7:f750:2ffb:53df:0000:0000:0000:1001의 축약된 표현이다.

각 패킷의 [Internet Protocol Version 6] 항목을 보면,

• 128비트 크기의 송신지 IPv6 주소(Source Address), 수신지 IPv6 주소(Destination Address)를 확인할 수 있다.

단편화가 이루어지는 부분은 3번 패킷부터 5번 패킷이다.

• 우선 1번과 2번 패킷을 보면, 이 패킷들은 단편화되지 않았으므로 단편화 확장 헤더가 없다.
• 이 경우 Next Header 필드는 캡슐화한 프로토콜인 UDP를 가리키고 있다.

이번에는 3번 패킷부터 6번 패킷까지 살펴보면, 이들은 단편화되어 전송된 패킷이므로 단편화 확장 헤더가 포함되어 있다.

• 이를 나타내는 것이 [Fragment Header for IPv6]이다.
• 단편화되지 않은 1번과 2번 패킷은 이 확장 헤더가 없다.

단편화 확장 헤더를 살펴보면,

• 캡슐화된 UDP를 가리키는 다음 헤더(Next header),
• 같은 값을 공유하는 식별자(Identification),
• 얼마나 떨어진 데이터를 담고 있는지를 나타내는 오프셋(Offset) 값이 명시되어 있는 것을 볼 수 있다.

이어서 UDP 데이터그램의 내용을 살펴보면, 1번과 2번 패킷의 [User Datagram Protocol] 항목을 확인해보세요.

• 4장에서 배운 송신지 포트(Source Port)와 수신지 포트(Destination Port),
• 그리고 UDP 데이터그램의 바이트 단위 길이(Length) 등이 명시되어 있음을 알 수 있다.

2.2 TCP 분석

다음으로 와이어샤크를 사용해 TCP 분석을 수행해보면, TCP 연결 수립부터 연결 종료, 재전송 과정까지 분석해보자.

2.2.1 TCP 연결 수립

이번에는 3-way-handshake파일을 열어보면, TCP의 연결 수립 과정을 살펴보자.

• TCP는 연결형 통신을 수행하는 프로토콜이고, 연결 수립 과정은 3-way-handshake를 통해 이루어진다.
• 파일의 내용은 그 과정을 나타낸다.

첫 번쨰 패킷은 192.168.0.1이 10.10.10.1에게 연결 요청을 보내는 패킷이다.

• 두 번쨰 패킷은 10.10.10.1이 192.168.0.1에게 확인 응답을 보내는 패킷이며,
• 마지막으로 세 번쨰 패킷은 다시 192.168.0.1이 10.10.10.1에게 확인 응답을 보내는 패킷이다.

이 상황을 그림으로 표현하면 위 그림과 같다.

첫 번쨰 패킷의 [Transmission Control Protocol] 항목을 열어보자.

• 가장 먼저 보이는 것은 송신지 포트 번호(Source Port)와 수신지 포트 번호(Destination Port)이다.
• 첫 번쨰 패킷의 송신지 포트 번호는 49859이고, 수신지 포트 번호는 80이다.

송신지 포트 번호 49859는 동적 포트 번호 범위에 속한다.

• 4장에서 언급했듯, 웹 브라우저처럼 클라이언트로 동작하는 프로그램은 동적 포트 번호 중에서 임의의 포트 번호가 할당되는 경우가 많다.
• 반면, 포트 번호 80은 잘 알려진 포트 번호 범위인 웰 노운 포트에 속한다.
• 이 포트 번호는 주로 HTTP에 사용된다고 설명했다.
• 따라서 첫 번쨰 패킷은 송신 호스트인 192.168.0.1의 클라이언트 프로세스가 임의의 동적 포트 번호 49859를 할당받아 HTTP 서버로 동작하는 10.10.10.1에게 연결 요청을 보낸 것으로 추정할 수 ㅣㅇㅆ다.

또한 순서 번호(Sequence Number)도 볼 수 있다.

• 와이어샤크에게 보기 편하도록 상대적인 순서 번호(relative sequence number)를 매기긴 했지만,
  • 실제 순서 번호(raw)는 3588415412이다.
• 플래그(Flags) 값도 보면, 3-way-handshake를 시작하는 세그머트의 SYN 비트는 1로 설정되어 있어야 한다.
• 실제로 SYN 플래그를 보면, 1로 설정된 것을 확인할 수 있다.

💡 cf. 화면 하단의 옵션 부분을 보면, 4장에서 학습한 MSS 크기와 SACK(Selective ACK) 허용 어부도 확인할 수 있다.

이번에는 두 번쨰 패킷의 [Transmission Control Protocol] 항목을 보자.

• 첫 번쨰 패킷과 비교했을 떄, 첫 번쨰 포트의 송신지 포트 번호와 수신지 포트 번호가 두 번쨰 패킷에서는 바뀌어 있다.
• 두 번쨰 패킷은 호스트 10.10.10.1의 80번 포트에서 동작하는 프로세스가
  • 호스트 192.168.0.1의 49859번 포트에서 동작하는 프로세스에게 응답하기 위한 세그먼트이기 떄문이다.
• 패킷의 순서 번호를 살펴보면,
  • 연결 요청을 받은 호스트 10.10.10.1도 자신의 순서 번호인 697411256을 알리는 것을 볼 수 있다.

이어서 하단을 보면, 첫 번쨰 패킷에 대한 확인 응답 번호(Acknowledgment Number)가 있다.

• 첫 번쨰 패킷이 자신의 순서 번호를 3588415412로 알렸으니,
  • 다음으로 받기를 기대하는 순서 번호를 확인 응답 번호로 삼아 3588415413을 전송하는 것을 볼 수 있다.
• 3-way-handshake 과정의 2번쨰 세그먼트는 SYN 비트와 ACK 비트가 1로 설정된 세그먼트라 했죠?
• 하단 플래그(Flags)를 보면, 실제로도 그렇다는 것을 확인할 수 있다.

3-way-handshake의 마지막 단계는 두 번쨰 패킷에 대한 ACK 세그먼트를 전송한다.

• 두 번쨰 패킷의 순서 번호는 697411256이다.
• 따라서 확인 응답 번호로 697411257을 전송하고,
  • 두 번쨰 패킷의 확인 응답 번호에 해당하는 순서 번호인 3588415413을 전송하는 것을 확인할 수 있다.
• 이런 과정을 통해 연결이 수립된다.

2.2.2 TCP 연결 종료

그렇다면 이번에는 연결 종료 과정도 살펴보면, connection-close 파일을 열어보세요.

TCP의 연결 수립 과정을 이해했다면, 연결 종료 과정도 어렵지 않게 이해할 수 있다.

• TCP의 연결 종료 과정은 통신을 주고받는 호스트가 서로 FIN과 ACK를 주고받으며 이루어진다.
• 패킷 속 상황을 그림으로 표현하면 위 그림과 같다.

첫 번쨰 패킷에서는 10.10.10.1이 192.168.0.1로 FIN 비트가 설정된 세그먼트를 전송한다.

• 이는 연결 종료 요청과 같다.
• 액티브 클로즈의 과정이다.

두 번쨰 패킷에서는 192.168.0.1이 첫 번쨰 패킷에 대한 응답으로 ACK 비트가 설정된 세그먼트를 전송한다.

어느 정도의 시간이 흐른 뒤, 192.168.0.1은 FIN 비트가 설정된 세 번쨰 세그먼트를 보낸다.

마지막으로 10.10.10.1이 192.168.0.1에게 ACK 비트가 설정된 세그먼트를 보내면, 연결 종료 과정이 완료된다.

• 192.168.0.1의 경우, 네 번쨰 패킷을 받으면 즉시 연결이 종료되고,
• 10.10.10.1의 경우, 네 번쨰 패킷을 전송한 후에 일정 시간을 대기한 뒤 연결이 종료될 것이다.

2.2.3 TCP 재전송

TCP는 신뢰성을 제공하고자 재전송 기반의 오류 제어를 수행한다고 했다.

• 이번에 살펴볼 파일은 이러한 재전송 기반의 오류 제어를 보여주는 파일이다.
• tcp-retransmission 파일을 열어보면 위 그림과 같다.

위 화면은 TCP의 연결 수립 이후 TCP의 송수신 과정 중 일부 보여준다. 이 과정은 다소 복잡할 수 있으므로, 그림과 함께 이해해보세요.

• 먼저 1번 패킷을 보면, 순서 번호는 2530489553이고, 확인 응답 번호는 3714426508이다.
• 이어서 2번 패킷을 보면, 1번 패킷에 대한 응답으로 순서 번호가 3714426508인 패킷을 보내고,
  • 확인 응답 번호는 2530491013을 보낸다.
• 여기서, ‘2번 패킷이 유실되어 정상적으로 송신되지 않았다’라고 가정해보자.

다음으로 3번 패킷을 살펴보면, 순서 번호는 2530504153이고, 확인 응답 번호는 3714426508이다.

• 앞의 가정에 따라 2번이 유실되었으므로, 10.10.10.1은 2번 패킷의 순서 번호(3714426508)를 받지 못했다.
• 따라서 3번 패킷의 확인 응답 번호는 1번과 동일하다.

2번 패킷의 확인 응답 번호는 2530491013(위 그림 속 붉은색 표기)이었다.

• 이는 순서 번호가 2530491013인 패킷을 보내달라는 의미다.
• 하지만 2번 패킷이 유실되었기 때문에 192.168.0.1입장에서는 아직 순서 번호 2530491013을 받지 못했다.
  • 그렇다면 10.10.10.1에게 확인 응답 번호가 2530491013인 ACK 세그먼트를 다시 보내야겠죠.
  • 즉, 중복된 ACK 세그먼트를 보내야 하는 상황이다.
• 4번 패킷을 살펴보면, 확인 응답 번호는 2530491013이다.
  • 중복된 ACK 세그먼트를 보낸 것이다.

5번 패킷을 살펴보면, 순서 번호는 2530505613이고, 확인 응답 번호는 3714426508이다.

• 이 패킷은 4번 패킷에서 192.168.0.1이 보내달라고 했던 순서 번호 2530491013이 아니죠.
• 따라서 192.168.0.1은 한 번 더 중복된 ACK 세그먼트를 보낸다.
• 이어서 6번 패킷을 살펴보면, 순서 번호는 3714426508이고, 확인 응답 번호는 다시 2530491013이다.

7번 패킷을 살펴보면, 순서 번호는 2530507073이고, 확인 응답 번호는 3714426508이다.

• 여전히 이 순서 번호는 192.168.0.1이 기대한 패킷이 아니다.

8번 패킷을 살펴보면, 순서 번호는 3714426508이고, 확인 응답 번호는 2530491013이다.

• 이는 세 번쨰로 중복된 ACK 세그먼트다.

04-3에서 ‘3번의 중복된 ACK 세그먼트를 수신하면, 빠른 재전송과 더불어 빠른 회복 알고리즘이 수행된다’고 했다.

• 10.10.10.1 입장에서는 3번의 중복 ACK 세그먼트가 발생했으므로, 빠른 재전송을 수행해야겠죠?
• 빠른 재전송을 수행하는 패킷이 9번 패킷이다.
• 순서 번호는 2530491013이다. 드디어 192.168.0.1은 원했던 패킷을 전송받았다.

cf. tcp.analysis.retransmission 필터를 사용하면, 재전송된 패킷을 필터링할 수 있고, tcp.analysis.fast_retransmission 필터를 사용하면, 그림처럼 빠른 재전송에 해당하는 패킷을 필터링할 수 있다.

또한 tcp.analysis.dupliocate_ack 필터를 사용하면, 위 화면처럼 중복된 ACK 세그먼트를 필터링할 수 있다.

2.3 HTTP 분석

마지막으로 HTTP를 분석하기 위해 http-request-response 파일을 열어보세요.

• cf. HTTP 요청과 응답 헤더의 분석은 5장에 언급한 대로 웹 브라우저의 개발자 도구를 이용해도 쉽게 할 수 있다.

1번 패킷 속 HTTP 메시지를 보면, 이는 웹 브라우저를 열고, http://info.cern.ch를 입력했을 떄 캡처된 패킷이다.

• 즉, 요청을 보낸 호스트는 info.cern.ch이며, 요청을 보낸 경로는 /이고,
• 요청에 사용된 HTTP 메서드는 GET이다.

💡 \r과 \n의 의미는 무엇인가

그림을 살펴보면, 한 줄의 끝마다 \r과 \n라는 표기가 있다.

• \r은 캐리지 리턴(Carriage Return)으로, 커서를 현재 행의 앞으로 이동하라는 의미다.
• \n은 라인 피드(Line Feed)으로, 다음으로 커서를 이동하라는 의미다.
• 따라서 \r과 \n를 같이 사용하면,
  • 커서의 위치가 행의 앞으로 이동한 뒤, 다음 행으로 이동하게 되며, 행바꿈(줄바꿈)을 표현한다.

이 요청에 대한 HTTP 응답을 담고 있는 2번 패킷을 확인해보면, 응답 코드(Status Code)가 200이다.

• 요청이 성공적으로 처리되었음을 의미한다.
• 또 Content-Type 헤더를 통해 응답되는 본문이 HTML 문서라는 점을 알 수 있다.

해당 HTML 문서는 위와 같다. 위 HTML 문서는 다음과 같은 웹 페이지를 나타낸다.

• 즉, 클라이언트가 브라우저를 통해 실제로 수신하는 자원은 다음과 같은 HTML 문서다.

3번 패킷도 확인해보면, 위 화면에서 Browse the first website라는 링크를 클릭했을 떄 캡처되는 패킷이다.

• 요청을 보낸 호스트는 info.cern.ch이고, 요청을 보낸 경로는 /hypertext/WWW/TheProject.html이며,
  • 요청에 사용된 HTTP 메서드는 GET이다.
• 또 Referer 헤더를 통해 이전에 요청을 보낸 자원이 http://info.cern.ch임을 확인할 수 있다.

💡 이외에도 캡처된 모든 HTTP 헤더를 5장에서 배웠으니, 하나씩 의미를 파악해보자.

3번 패킷에 대한 HTTP 응답은 5번 패킷이다. 2번 패킷과 마찬가지로 HTML 문서를 응답받았다.

• 응답받은 HTML 문서는 다음과 같은 웹 페이지를 나타낸다.
• cf. 세계 최초의 웹 사이트 모습이다.

지금까지 와이어샤크를 사용해 IPv4, IPv6, ICMP, UDP, TCP, HTTP 프로토콜 패킷을 직접 관찰하여 지금까지 배운 내용을 복습해봤다.