[8주차] wireshark를 통해 패킷 뜯어보기(컴네 시험 공부를 곁들인)

[Wireshark란?]

 

WireShark란

오픈소스로 배포되는 패킷 분석 프로그램으로 실제 통신 중에 주고 받는 패킷을 캡쳐하여 분석가능하게 한다.

 

 

설치는 우분투 소프트웨어 스토어에서 진행했기에 과정은 생략한다.

(이전에는 더 복잡했던 듯)

 

 

말로 하는 설명보다는 직접 보는 것이 빠를 것 같다.

 

 

위와 같이

2계층 MAC주소부터 3계층 ip src+dest주소, checksum, ttl, 4계층 src+dest Port number 등

 

그냥 네트워크 통신을 하기 위해 주고받는 모든 정보를 캡처해서 보여주는 것을 알 수 있다.

 

드래그 해놓은 26번째 바이트에서 29번째 바이트를 보면 

ac 1c e0 01이라고 되어있는데

이는 ipv4기반의 ip src주소를 가리킨다.

 

16진법으로 표현되어있는 것을 풀어서 보면

ac_16 = 10* 16 + 12 * 1 = 172

1c_16 = 1*16 + 12 * 1 = 28

e0_16 = 14 * 16 + 0 * 1 = 224

01_16 = 0 * 16 + 1 * 1 = 1

 

 

따라서 172.28.224.1이 완성된다.

 

 

ipv4는 32bit의 ip address를 가시성 좋게 표현하기 위해

8개의 Byte 단위로 끊어서

0.0.0.0 ~ 255.255.255.255를 표현하는 것은 알았는데,

이를 패킷내에서는 4bit의 16진수 두개씩 끊어서 FF.FF.FF.FF식으로 표현하는 형식은 처음 알게 된 사실이었다.

(수업을 제대로 안 들었나..?)

 

 

 

 

[TCP 관련 간단한 지식]

 

TCP는 연결 생성 및 해제 과정을 포함하는 프로토콜이다.

 

TCP 3 Way Handshake

는 그중에서도 장치들 사이의 논리적인 연결을 생성하는 과정이고

TCP 4 Way Handshake

는 연결을 해제하는 과정이다.

 

이를 이해하기 위해선 TCP flag에 대해 간략히 알면 좋다.

 

TCP 세그먼트 필드 안에 각각 1비트로 아래 순서와 같이 정의되어있다.

URG, ACK, PSH, RST, SYN, FIN

 

각각의 기능은

SYN-연결 요청

ACK-응답

RST-강제 연결 초기화

PSH-버퍼에 들어온 데이터를 즉시 Application 계층으로 전송

URG-긴급 데이터

FIN-연결 종료 요청

 

 

 

 

[3-way-Handshaking]

 

먼저 연결을 생성하는 3-way Handshaking의 경우

 

다음과 같이

Client > Server : SYN

Server > Client : SYN ACK

Client > Server : ACK

로 이뤄진다.

 

다음은 유튜브에 접속하여 연결을 생성하는 부분을 직접 찾아서 캡처한 것이다.

 

위에서 3번째 줄부터 5번째 줄을 보면 위의 패턴을 확인할 수 있다.

클라이언트 56006 포트에서 server 443 포트측으로 연결 생성을 하는 모습이다.

 

처음 보낸 Client에서 보낸 SYN에 대해 잘 받았다는 의미로 보내온 Seq 넘버에 1을 더한 ACK =1과 함께 Server에서도 Client에게 SYN을 보내면서 연결을 생성하는 모습이다. (PiggyBacking이 사용된 모습)

 

여기서 443은 https 프로토콜의 기본 포트 넘버라고 한다.

따라서

https://www.youtube.com 나

https://www.youtube.com:443 나

결국 동일한 의미이고 첫번째 도메인 이름이 주어지면 뒤에 443을 자동적으로 붙여 접속하는 것을 알 수 있다.

 

 

 

 

[4-way-Handshaking]

 

 

연결을 해제하는 4-way-Handshaking의 경우, 위의 그림처럼 동작한다.(중간에 회색을 data가 오가는 부분은 제외하고 볼 것)

 

Client > Server : FIN

Server > Client : ACK

Server > Client : FIN

Client > Server : ACK

의 순서로 이루어지는데

 

진짜 별게 없게 없고 연결 해제를 요청하는 FIN을 각각 보내고 그 상대편이 ACK를 보내주는 방식이다.

 

 

위의 그림에서 35574 -> 443 방향의 FIN

443 -> 35574 방향의 FIN과 각각에 대한 ACK를 모두 확인할 수 있었다.

 

 

 

[QUIC]

 

마지막으로 구글이나 유튜브는 HTTP3를 이미 도입한 것으로 컴퓨터네트워크 시간에 배웠는데,

프로토콜의 이름으로 HTTP3가 아니라 위와 같이 QUIC으로 검색되었다.

 

 

가볍게 시험공부도 할 겸 수업내용을 복습해보면,

 

 

QUIC은

기존 HTTP2에서의 Header Compression, Multiplexing을 잘 살리고, TCP보다 더 효율적인 연결 생성 및 해제, 흐름 제어, 혼잡 제어를 하는 알고리즘에다가 마지막으로 기존 TLS에 해당하는 보안적인 부분까지도 함께 담당하는 구조로

네트워크 지연 시간을 획기적으로 단축 시키는 등 성능 향상을 이뤘다.

 

단지 모든 상황에 대해서 좋은 것이 아니라 적절히 따져보고 상황에 맞게 적용되어야 할 선택적인 툴임은 잊지 말아야겠다.