URL을 통한 브라우저의 서버 접속 과정, TCP/IP 4계층

김민재·2025년 7월 1일

CS

목록 보기

2/12

URL의 구성과 개념에 대해서는 이전 포스팅에서 다룬 바 있다.

이번에는 컴퓨터 네트워크의 핵심인 TCP/IP 4계층과,
브라우저가 URL로 어떤 과정을 통해 서버에 접속하게 되는지 알아보자.

🔎 TCP/IP 4계층

TCP/IP 4계층이란, 네트워크 상에서 데이터를 목적지까지 안정적으로 전달하기 위해 통신 기능을 4단계(애플리케이션, 전송, 인터넷, 네트워크 접근)로 나눈 구조이다.

OSI 7계층이 네트워크 통신의 개념적 표준을 상세히 나누어 7계층으로 구성된 반면,
TCP/IP 모델은 인터넷 프로토콜 스위트의 핵심 프로토콜들을 중심으로 4계층으로 통합하여 설계되었고, 실제 인터넷 환경에서 효율적이고 유연한 통신 구현을 가능하게 한다.

단, 네트워크 통신 과정에서 각 계층이 반드시 순서대로 처리되거나 단계별로 엄격히 분리되어 있지는 않고, 서로 유기적으로 작용한다는 점을 염두에 두어야 한다.

각각의 계층에 대해 알아보자.

1) 응용 계층(Application Layer)

사람이 안부를 묻기 위해 편지를 작성하듯, 브라우저는 화면에서 필요한 데이터를 요청하기 위해 HTTP 데이터(HTTP 요청 메시지)를 생성한다.

또한 편지에 인사말, 본문, 맺음말과 같은 양식이 있는 것처럼,

HTTP도 start-line, headers, body와 같은 양식이 존재한다. 이러한 약속을 '프로토콜'이라고 한다.

같은 응용 계층에 포함된 DNS, FTP, DHCP 등도 마찬가지로 데이터를 생성하고, 특정 양식을 가지고 있다.

✔️ HTTP: 웹페이지를 주고받는 프로토콜
✔️ DNS: 도메인 이름을 IP 주소로 변환하는 서비스
✔️ FTP: 파일을 전송하는 프로토콜
✔️ DHCP: 파일을 전송하는 프로토콜

이렇게 응용 계층에는 사용자와 가장 가까운 위치에서 사용자와 상호작용을 하는 프로토콜들이 포함되어 있고, 형식에 알맞은 데이터를 생성하는 단계가 응용 계층에서 일어난다.

데이터 단위 : 데이터(Data) / 메세지(Message)

예시 : 파일 전송, 이메일, FTP, HTTP , DNS, SMTP 등

2) 전송 계층

전송 계층은 통신 노드 간의 데이터 전송 및 흐름에 있어 신뢰성을 보장한다.

이는 다시 말해 데이터를 적절한 애플리케이션에 정확하게 전달되도록 관리하며, 이를 종단 간(End-to-End) 신뢰성 확보라고 표현할 수 있다.

이 과정에서 전송 계층은 포트(port)를 사용하여 애플리케이션 간 통신을 구분하고 전달한다.

전송 계층의 대표적인 프로토콜인 TCP, UDP에 대해 알아보자.

✔️ TCP

연결 지향형 프로토콜로, 데이터를 보내기 전에 먼저 상대방과 3-way handshake 라는 과정을 거쳐 연결을 설정한다.

그리고 전송 중 데이터가 손실되거나 순서가 뒤바뀌면 이를 자동으로 재전송하거나 재정렬하여, 신뢰성 있는 전송을 보장한다.

수신자의 속도나 네트워크 상태에 따라 데이터 전송 속도를 조절하는 흐름 제어와 혼잡 제어 기능도 갖추고 있다.

안전하지만 속도는 느린 편이다.

HTTP, 이메일, FTP처럼 정확성이 중요한 서비스에 사용된다.

✔️ UDP

비연결형 프로토콜로, 연결 설정 없이 데이터를 바로 전송하며, 데이터의 손실, 중복, 순서 변경이 발생해도 이를 처리하지 않습니다.

신뢰성 대신 속도와 효율을 중시하며, 구조가 단순하고 빠르다.

실시간 영상 스트리밍, 온라인 게임, 음성 통화처럼 빠른 전송이 중요한 서비스에 자주 사용된다.

부가적인 정보는 다음과 같다.

데이터 단위 : 세그먼트(Segment)

전송 주소 : Port

예시 : TCP, UDP 등

3) 인터넷 계층

수많은 네트워크가 연결된 인터넷에서 특정 주소를 의미하는 단어를 우리는 IP 주소라고 부른다. IP는 Internet Protocol의 약자로 인터넷에서 주소를 구분하고 찾기 위해 사용하는 약속이다.

이렇게 인터넷에서 편지가 가야 하는 목적지 주소를 찾기 위한 단계가 인터넷 계층에서 일어난다.

데이터 단위 : 패킷(Packet)

전송 주소 : IP

예시 : IP, ARP, ICMP, RARP

4) 네트워크 접근 계층

네트워크 접근 계층은 데이터가 실제 물리적인 장치를 통해 전송되는 방식을 담당하는 계층이다.

보통 같은 네트워크(로컬 네트워크, 예: 같은 Wi-Fi나 LAN) 내에서 동작하며,
장치 간에는 MAC 주소를 통해 데이터를 주고받는다.

사용자가 멀리 떨어진 서버에 접속할 때는 인터넷 계층(IP 계층)이 IP 주소를 참조해 경로를 결정한다. 내 컴퓨터에서 가까운 라우터는 목적지 IP 주소를 보고, 다음 목적지(라우터)를 선택하며, 이렇게 라우터들을 거치면서 각 구간마다 네트워크 접근 계층이 MAC 주소 등을 사용해 실제 데이터 전송을 수행하게 되는 것이다.

즉 서버의 네트워크를 찾기 위해 IP주소를 사용하고, 그 네트워크 내부에 있는 컴퓨터와 통신하기 위해 MAC 주소가 필요한 것이다.

데이터 단위 : 프레임(Frame)

전송 주소 : MAC

예시 : MAC, LAN, 패킷망 등에 사용되는 것(대표적으로 Ethernet)

데이터를 송수신 할 때 각 계층에서 작용하는 일들과 순서는 다음 글을 참고하면 좋을 것 같다.
https://adjh54.tistory.com/515

🔎 URL을 통한 브라우저의 서버 접속 과정

브라우저에 URL을 입력한 후 서버에 접속하기까지의 과정에 대해 파헤쳐보자.

1. DNS 서버 조회

DNS 서버로부터 IP 주소를 받아올 때, 다음 과정을 거친다.

우선 브라우저가 실제 DNS 서버에 요청을 보내기 전에, 불필요한 요청을 줄이기 위해 먼저 로컬 캐시를 확인한다.
만약 없다면, 운영체제(OS)의 DNS 캐시나 호스트 파일 등을 확인해서 이미 알고 있는 정보가 있는지 탐색한다.
여기도 존재하지 않는다면, OS는 resolver를 호출한다. resolver는 보통 각자의 ISP (Internet Service Provider)이다. KT, SK브로드밴드, LG유플러스 등이 대표적인 ISP이다. 이 resolver는 로컬 DNS 서버라고도 한다.
DNS 루트 서버의 IP를 알고 있는 resolver는, 루트 서버에 이 도메인에 해당하는 IP를 찾을 수 있는지 물어보고, 루트 서버는 .com으로 끝나는 도메인들을 담당하는 서버의 IP주소를 알려준다.
이와 같은 방식으로 로컬 DNS 서버는 naver.com에 해당하는 IP주소를 알아내 브라우저에게 알려주고, 이렇게 브라우저는 정확한 위치를 알아내게 된다.

5번 과정까지 마치게 되면 URL 주소를 브라우저/운영체제/Local DNS에 캐싱하게 된다. 따라서 다음 요청부터는 다음 그림처럼 바로 IP주소를 응답받게 된다.

하지만 영구적으로 캐싱되는 것은 아니고, 설정된 TTL(Time To Live)에 의해 일정 시간이 지나면 사라진다.

2. HTTP 요청 메시지 생성

📍 HTTP 요청 메시지의 구성

✔️ Method : HTTP 메서드는 보통 클라이언트가 수행하고자 하는 동작을 정의한 GET, POST, OPTIONS, HEAD를 지칭한다. 클라이언트는 리소스를 가져오거나(GET 사용) HTML 폼의 데이터를 전송(POST 사용)한다.
다른 경우에는 다른 동작이 요구될 수도 있다.

✔️ Path : 가져오려는 리소스의 경로는 전체 주소에서
http://, 도메인명, 포트 번호를 제외한 나머지 부분이다.

✔️ Version of the Protocol : HTTP 프로토콜의 버전.

✔️ Headers : 서버에 대한 추가 정보를 전달하는 선택적 헤더들.

✔️ etc : POST와 같은 몇 가지 메서드를 위한, 전송된 리소스를 포함하는 응답의 본문과 유사한 본문.

3. HTTP 요청 메시지 전송

HTTP 요청 메시지를 전송하기 전, TCP 연결을 먼저 하게 된다.

TCP 연결은 이전 단계에서 얻은 다음 네 가지의 정보를 바탕으로 수행된다.

출발지 IP 주소 (클라이언트의 IP)
목적지 IP 주소 (서버의 IP, DNS를 통해 변환된 정보)
출발지 포트 번호 (클라이언트가 임의로 지정하는 포트)
보통 49152~65535 사이에서 임시 포트가 무작위로 선택된다.
목적지 포트 번호 (서버가 사용하는 서비스 포트)
HTTP는 80, HTTPS는 443

이 정보를 가지고 SYN, SYN+ACK, ACK 과정(3 way handshake)을 통해 서버와 연결을 한다.

SYN 단계(1단계): 클라이언트 측 TCP는 서버 TCP에게 특별한 TCP 세그먼트를 송신한다. 이 특별한 세그먼트는 애플리케이션 계층 데이터를 포함하지 않는다. 세그먼트 헤더에 SYN 비트라고 불리는 하나의 플래그 비트를 가진다. 이러한 특별한 세그먼트를 SYN 세그먼트라 부른다.
추가로 클라이언트는 최초의 순서번호 client_isn을 선택하고, 최초의 TCP SYN 세그먼트의 순서번호 필드 seq에 이 번호를 넣는다. 이 세그먼트는 IP 데이터그램 안에서 캡슐화되고 서버로 송신된다.

SYN-ACK단계(2단계): 1단계에서 보낸 데이터그램이 서버 호스트에 도착했을 때, 서버는 데이터 그램에서 TCP SYN 세그먼트를 뽑아낸다. 그리고 연결에 클라이언트와의 연결을 처리하기 위한 버퍼와 변수들을 할당한다.
또한 클라이언트 TCP로 연결 승인 세그먼트를 송신한다. 세그먼트 헤더 안에는 3개의 중요한 정보를 포함한다.

SYN비트는 1로 설정된다.
TCP 세그먼트 헤더의 확인응답 필드 ack는 client_isn + 1로 설정된다.
자신의 최초의 순서번호 server_isn을 선택하고, TCP 세그먼트 헤더의 순서번호 필드 seq에 이 값을 넣는다.

이 과정은 "나는 당신의 최초 순서번호 client_isn를 가지고 연결을 시작하기 위해서 당신의 SYN 패킷을 수신했다. 이 연결설정에 동의하고, 나의 최초 순서번호는 server_isn이다"라고 말하는 것과 같다.

ACK 단계(3단계): SYN-ACK를 수신한 클라이언트는 연결에 버퍼와 변수들을 할당한다. 그 다음에 클라이언트 호스트는 서버로 또 다른 세그먼트를 송신한다.
이 마지막 세그먼트가 서버의 연결 승인 세그먼트를 확인한다.(클라이언트는 TCP 세그먼트 헤더의 확인응답 필드 ack안에 server_isn + 1 값을 넣는 것으로 그 일을 한다). 연결이 설정되었기 때문에 SYN 비트는 0으로 설정된다. 3 way 핸드셰이크의 세 번째 단계는 클라이언트에서 서버로 세그먼트 페이로드에 '애플리케이션 데이터'를 보낼 수 있다.

HTTPS의 경우에는 이 3-way-handshake에 TLS(Transport Layer security, SSL) handShake가 추가된다.

TCP 연결이 완료되면, 다음과 같이 HTTP 요청 메시지를 TCP/IP 패킷으로 캡슐화하여 서버로 전송하게 된다.