TCP/IP 4 계층으로 알아보는 네트워크의 동작

우리는 보통 브라우저 주소창에 URL을 입력하고 엔터를 누르는 것으로 네트워크 통신을 시작한다. 하지만 그 짧은 동작 뒤에는 수많은 프로토콜과 계층이 맞물려 동작하는 복잡한 과정이 숨어 있다. 요청 하나가 서버에 도달하고, 다시 응답이 돌아오기까지 컴퓨터는 생각보다 훨씬 많은 일을 처리한다.

네트워크를 처음 배울 때는 OSI 7계층이나 TCP/IP 모델 같은 개념이 다소 추상적으로 느껴질 수 있다. 각 계층이 무엇을 하는지는 외웠지만, 실제 요청 흐름 속에서 어떤 역할을 맡는지는 쉽게 와닿지 않는다. 특히 “그래서 이게 실제 웹 요청이랑 무슨 상관이지?”라는 의문이 남기 마련이다.

이 글에서는 네트워크를 계층별로 나열하는 데서 그치지 않고, 하나의 웹 요청이 발생했을 때 각 계층이 어떤 역할을 수행하는지를 중심으로 정리해보려 한다. google.com을 입력했을 때 벌어지는 과정을 따라가며, 네트워크 인터페이스 계층부터 응용 계층까지가 어떻게 유기적으로 연결되는지를 살펴보자.

네트워크 인터페이스 계층 (Network Interface Layer)

네트워크 인터페이스 계층은 허브나 스위치와 같은 장비를 사용해 동일한 네트워크 내에서 데이터의 전달을 담당하는 계층이다. 이 계층에서는 네트워크에 연결된 각 기기를 식별하기 위해 MAC 주소를 사용한다. 데이터를 전송하려는 대상의 MAC 주소를 알지 못하는 경우, 컴퓨터는 ARP(Address Resolution Protocol)를 통해 IP 주소를 기반으로 MAC 주소를 획득한다.

ARP 프로토콜은 크게 세 단계로 동작한다. 먼저 데이터를 전송하려는 컴퓨터 A는 동일한 허브나 스위치에 연결된 모든 기기에게 특정 IP 주소를 알고 있는지를 묻는 ARP Request를 브로드캐스트 방식으로 전송한다. 이를 수신한 각 기기는 요청된 IP 주소가 자신의 IP와 일치하는지 확인하고, 일치하는 기기 B가 존재할 경우 자신의 MAC 주소를 담은 ARP Response를 유니캐스트로 응답한다. 이후 컴퓨터 A는 B의 IP와 MAC 주소 쌍을 ARP 테이블에 저장하며, 같은 대상과 다시 통신할 경우에는 ARP 요청을 재전송하지 않고 해당 테이블을 참조한다.

허브와 달리 스위치는 MAC 주소 테이블을 사용해 연결된 기기들의 MAC 주소를 관리한다. 이를 통해 특정 목적지 MAC 주소를 가진 기기에게만 프레임을 전달할 수 있으며, 이러한 동작을 MAC 주소 필터링이라고 부른다.

인터넷 계층 (Internet Layer)

인터넷 계층은 라우터를 사용해 서로 다른 네트워크 간의 통신을 가능하게 하는 계층이다. 이 계층부터는 LAN을 넘어 WAN의 영역으로 확장되며, 기기 식별에는 MAC 주소 대신 IP 주소가 사용된다.

IP 주소는 네트워크 ID와 호스트 ID로 구성된다. 과거에는 클래스 A, B, C와 같은 방식으로 네트워크 범위를 구분했지만, 오늘날에는 CIDR(Classless Inter-Domain Routing) 표기법이 주로 사용된다.

AWS VPC를 예로 들면, 10.3.0.0/16이라는 주소에서 /16은 전체 32비트 중 앞의 16비트가 네트워크 ID임을 의미한다. 나머지 16비트는 호스트 ID로 사용된다. 이 VPC 내에서 10.3.1.0/24, 10.3.2.0/24와 같은 서브넷을 구성했다면, 호스트 ID 중 다시 8비트를 서브넷 ID로 분리한 것이다.

/24 서브넷은 이론적으로 256개의 IP를 가질 수 있지만, 실제로는 254개만 사용 가능하다. 가장 첫 번째 주소는 네트워크 주소로, 가장 마지막 주소는 브로드캐스트 주소로 예약되기 때문이다.

참고로 IP 주소를 사용해 다른 네트워크와 통신하더라도, 실제 전송 과정에서는 여전히 MAC 주소가 필요하다. 내 컴퓨터는 라우터의 MAC 주소를 알아야 하고, 라우터 역시 다음 홉 라우터의 MAC 주소를 알아야 한다. 이렇게 IP는 유지된 채, MAC 헤더만 교체되며 데이터는 목적지까지 전달된다.

전송 계층 (Transport Layer)

전송 계층은 데이터를 목적지까지 신뢰성 있게 전달하는 것을 목표로 한다. 이 계층에서는 목적에 따라 TCP와 UDP 두 가지 프로토콜이 사용된다.

TCP는 연결형 프로토콜로, 데이터의 손실 없이 정확한 전달을 보장하는 것이 목적이다. 반면 UDP는 비연결형 프로토콜로, 데이터의 일부 손실을 감수하더라도 빠른 전송이 중요한 경우에 사용된다. 실시간 스트리밍이나 방송과 같은 시나리오가 대표적이다.

TCP 통신은 3-way handshake를 통해 시작된다. 이 과정은 두 기기가 실제로 데이터를 주고받을 준비가 되었는지를 확인하는 절차다.

1. 송신자는 수신자에게 SYN과 Window Size를 전송한다. SYN은 연결을 식별하기 위한 초기 시퀀스 번호이며, Window Size는 송신자가 한 번에 보낼 수 있는 데이터 크기를 의미한다.

2. 수신자는 SYN, ACK, 그리고 자신의 Window Size를 함께 전송한다. ACK는 송신자가 보낸 SYN에 1을 더한 값이며, 정상적으로 수신되었음을 알리는 역할을 한다. 이때 수신자의 SYN 값은 새로운 값이다.

3. 송신자는 수신자의 SYN에 1을 더한 ACK를 전송하며, 이로써 연결이 성립된다.

이 과정을 통해 양측은 서로의 수신·송신 가능 데이터 크기를 확인하고, 데이터를 효율적으로 세그먼트 단위로 나누어 전송할 수 있게 된다.

응용 계층 (Application Layer)

응용 계층에서는 클라이언트와 서버가 실제 서비스를 주고받는다. 일반적으로 요청을 보내는 쪽을 클라이언트, 요청을 처리하고 응답을 제공하는 쪽을 서버라고 부른다.

이 계층에서는 각 서비스에 따라 서로 다른 프로토콜과 포트 번호가 사용된다. 대표적으로 HTTP는 80번, HTTPS는 443번, FTP는 20·21번, POP3는 110번 포트를 사용한다.

종합적인 네트워크 요청 흐름

브라우저 주소창에 google.com을 입력하고 엔터를 누르면, 컴퓨터는 먼저 DNS 질의를 시작한다. 이때 로컬 라우터의 MAC 주소와 이미 알고 있는 DNS 서버의 IP 주소를 사용한다. 로컬 라우터가 DNS 서버의 MAC 주소를 모를 경우, 라우팅 테이블을 기반으로 다음 홉 라우터를 찾아가며 이 과정이 반복된다.

DNS 서버 역시 다른 DNS 서버들과 통신하며 google.com의 IP 주소를 알고 있는 서버를 찾아 나선다. 최종적으로 IP 주소를 알아내면, 그 결과가 다시 내 컴퓨터로 전달된다.

이제 내 컴퓨터는 구글 서버의 IP 주소를 대상으로 TCP 연결을 시도한다. SYN과 Window Size가 포함된 요청을 보내고, 구글 서버가 이에 응답하면 3-way handshake가 완료된다.

연결이 성립되면, 브라우저는 google.com/index.html에 대한 HTTPS 요청을 보낸다. 이때 사용하는 포트는 443이다. 구글 서버는 미리 협상된 Window Size를 기준으로 데이터를 여러 세그먼트로 나누어 전송하며, 내 컴퓨터는 각 세그먼트를 수신할 때마다 ACK를 응답한다.

모든 세그먼트가 도착하면, 브라우저는 HTML 문서를 완전히 확보하게 되고, 이후 렌더링 과정이 시작된다.