[네트워크 패킷 분석 with 와이어샤크] HTTP 통신

지금까지 네트워크 관련하여 TCP/UDP, SSL/TLS, OSI 7계층 등 학습을 진행해왔는데, 이런 전체적인 흐름이 어떻게 이루어지는지 Wireshark를 통해 확인해 보려고 한다.

 

오늘은 HTTP 통신이 이루어지는 과정을 패킷 캡처를 통해 확인해 볼 것이다.

OSI 7계층을 다시 살펴보자.

HTTP/HTTPS 글 확인하러 가기

HTTP & HTTPS

 

HTTP는 7계층에 해당하고, 아래로 내려가면서 캡슐화가 이루어지며 각 계층별로 전송 계층이 TCP인 경우 3-way handshake, 네트워크 계층에서는 라우팅 과정이 일어나며 데이터가 목적지로 전송될 수 있을 것이다.

 

HTTP 요청 메시지는 시작줄, 헤더, 본문으로 구성이 되는데, 헤더에는 목적지인 Host 정보가 포함된다.

HTTP 요청을 위해 통신을 위한 소켓이 생성될 것이고, 위 호스트 정보에서 IP 값을 얻기 위해서는 DNS 질의가 일어날 것이다.

전체적인 순서를 살펴보면 다음과 같다.

 

1. 통신을 위한 소켓 생성

2. DNS 질의

3. 목적지 IP로 가는 라우팅 과정

4. 3-way handshake 이후 TCP 연결 수립

5. http 메시지 요청/응답

6. 연결 유지 혹은 종료 => 4-way handshake

 

http-google101.pcapng

0.37MB

 

대략 이러한 과정을 확인하기 위해, 위 파일을 통해 패킷 분석을 해 볼 것이다.

 

Wireshark를 통해 위 파일을 열어보면 바로 이런 화면을 살펴볼 수 있다.

 

처음 1~4 과정을 보면 Protocol이 DNS 인 것을 확인할 수 있다.

출발지, 목적지, 프로토콜, 길이, 정보를 확인할 수 있는데 DNS 질의와 응답이 2개씩인 것을 확인할 수 있다.

간단한 Info 정보를 보면 www.google.com에 대한 질의를 하였고,  레코드 A와 AAAA에 대한 요청과 응답이다.

A는 IPv4, AAAA는 IPv6이다.

 

기본적으로 IPv6를 먼저 시도하는게 원칙이지만, 연결이 실패하거나 너무 느리면 IPv4도 요청해서 응답이 먼저 오는쪽을 택한다.

(Happy Eyeballs 알고리즘)

혹은 브라우저 구현에 따라 IPv6를 지원하지 않을 수도, 두 개 동시에 요청해서 더 빠른쪽을 선택할 수도 있다.

A레코드 DNS 질의/응답을 좀 더 자세히 살펴보면 이렇게 주소 리스트를 응답한 것을 볼 수 있다.

로드밸런싱을 위해 한 도메인이 여러 주소를 가지고 있는 경우가 많은데, DNS는 보통 라운드로빈으로 순서를 섞어서 응답하고, 브라우저에서도 보통 첫번째 주소부터 시도하고 안되면 다음 주소를 시도한다.

 

이렇게 IP 주소를 얻어왔으면, 해당 IP로 전송하기 위한 라우팅 과정이 일어난다.

5번부터 7번을 보면 TCP 3-way 핸드셰이크를 확인할 수 있다.

WireShark는 내 NIC를 거치는 패킷들을 캡처하므로 NIC를 나간 이후 노드 간 라우팅 과정을 확인할 수는 없지만,

SYN, SYN-ACK, ACK 과정이 일어난 것을 확인할 수 있다.

TCP는 전송제어를 해주는 프로토콜이기 때문에, Win=8192로 현재 수용가능한 윈도우 사이즈를 알려주기도 한다.

[TCP 글 보러가기]

TCP

 

그리고 다음 8번에서는 TCP 연결 수립 후, HTTP 요청 메시지를 전송한다.

이후 9번부터 34번까지 응답을 받은 것을 확인할 수 있다.

응답이 여러개로 쪼개져서 온 것을 확인할 수 있는데, 네트워크 전송에서는 MTU (Maximum Transmission Unit)라는 제한이 있다.

일반적으로 MTU는 1500 바이트인데, IP 헤더(20B) + TCP 헤더(20B)를 빼면 실제 TCP 데이터(=MSS, Maximum Segment Size)는 약 1460바이트까지 가능하다.

그래서 Info에 Len= 1430으로 된 여러 패킷을 확인할 수 있다.

 

그리고 이렇게 쪼개져서 보낸 패킷들은 받는쪽에서는 Seq를 통해 순서를 재조립할 수 있다.

이것 역시 TCP 프로토콜의 특징이다. (순서 보장)

Info를 자세히 보면 처음 Seq는 1, 다음은 이전 Seq + Len의 값으로 이루어진 것을 알 수 있다.

1번부터 시작해 Len 길이 만큼의 데이터를 전송하였다는 뜻이고, 그래서 이후 Seq 값은 이전 Seq + Len 값이 되는 것이다.

수신측에서는 이러한 Seq를 통해 재조립하여 사용하고, 18번 줄을 확인하면,

수신측이 보내는 패킷의 Ack값이 9500으로, 바로 위에 받은 17번 Seq : 9196, Len : 304 값(9196~ 9499바이트)까지 받아 그 다음에는 9500를 기대한다고 응답하는 것을 확인할 수 있다.

 

이러한 Ack 응답은 각 세그먼트당 보내는게 원칙이지만, 효율 최적화를 위해 누적 확인 방식을 쓴다. (여러 개 받고 한 번 응답 보냄)

그런데 클라이언트에서 새로운 요청을 보낼 경우가 있으면, 이때는 요청과 함께 응답도 전송한다.

 

QUIZ 타임. 그렇다면 http 요청에 대한 서버의 첫 응답에서 Seq는 1, Ack는 289였던 이유는 뭘까?

http 요청 패킷의 Len이 288이었기 때문이다. ~.~

 

마지막 종료 과정을 살펴보자.

FIN 요청을 통해 종료 요청을 보낸다.

그리고 서버에서도 FIN, ACK 응답이 오고, 최종적으로 ACK 응답을 보내 종료된다.

 

원래 4 way는

• FIN, ACK (종료 요청자 → 상대) : 나 이제 보낼 거 다 보냈다.
• ACK (상대 → 종료 요청자) : 알았다, 나도 정리할게.
• FIN, ACK (상대 → 종료 요청자) : 나도 다 보냈다.
• ACK (종료 요청자 → 상대) : 확인했다.

로 4번의 과정이 일어난다.

그런데 지금 종료 과정은 3 way 처럼 보인다. 왜일까?

4way가 표준적인 방법이긴 하지만, 서버에서는 ACK 응답과 동시에 FIN 응답을 함께 보내 최적화하여 응답하기도 한다고 한다.

 

끝.