[1편] 브라우저는 어떻게 서버를 찾을까? – DNS와 HTTP 메시지 구조까지

flaticon - kerismaker

1. 들어가며

웹 개발을 하다 보면 가장 기초적이면서도 중요한 개념이 바로 HTTP입니다.

하지만 그 시작점인 DNS, 그리고 HTTP 메시지의 구조에 대해 정확히 알고 있어야 합니다.

 

이번 글에서는 다음의 흐름을 따라가며 웹 요청의 여정을 함께 따라가보겠습니다.

• 사용자가 브라우저에 www.example.com을 입력하면,
• 어떻게 서버의 IP를 찾고,
• 어떤 형식의 메시지를 주고받으며,
• 어떻게 웹 페이지가 뜨는지?

---

2. DNS와 URI/URL – 웹 통신의 출발점

2-1. 도메인 네임과 DNS

컴퓨터는 IP 주소(예: 1.2.3.4)로 통신하지만,
우리는 www.example.com 같은 도메인 이름을 사용합니다.

 

이걸 IP로 바꿔주는 시스템이 바로 DNS (Domain Name System) 입니다.

 

즉, DNS는 사람이 읽기 쉬운 도메인 네임을

→ 컴퓨터가 이해할 수 있는 IP 주소로 변환(resolve) 해줍니다.

『이것이 취업을 위한 컴퓨터 과학이다』 p.432

• DNS 서버 역할: 사용자가 입력한 도메인을 해석하여 IP를 반환
• DNS 질의 흐름:
  1. 루트 네임 서버
  2. 최상위 도메인(TLD, .com 등)
  3. 권한 네임 서버(예: example.com을 관리)

📌 예시 흐름: www.example.com → 루트 → TLD → NS → IP 주소 반환

2-2. FQDN과 도메인 구성

• www.example.com은 FQDN (Fully Qualified Domain Name)
  → 정확한 서버를 찾기 위한 전체 경로
• 구성: 호스트 이름(www) + 도메인 이름(example) + 최상위 도메인(com)

🧠 면접 대비 포인트:
FQDN이란 무엇인가요? → "정확히 하나의 호스트를 지칭할 수 있는 전체 도메인 네임입니다."

---

3. Name Server와 DNS 질의 과정

3-1. 네임 서버(Name Server)란?

DNS 질의를 처리하는 서버로, 도메인 이름을 관리하며 계층 구조를 가집니다.

• 루트 네임 서버: 최상위 .com, .org 등으로 연결
• TLD 네임 서버: .com, .net 등 관리
• 권한 네임 서버: 실제 도메인의 IP 정보 보유

3-2. 질의 흐름과 캐싱

『이것이 취업을 위한 컴퓨터 과학이다』 p.434

• 클라이언트 → 로컬 DNS 서버 (ISP 또는 OS 내)
• 로컬 DNS 서버가 없으면 재귀 질의를 통해 루트부터 탐색
• 자주 쓰이는 도메인은 DNS 캐시에 저장되어 응답 속도 개선

💡 캐시의 TTL(Time To Live)은 제한 시간 내 재사용 가능
💡 대표적인 퍼블릭 DNS: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare)

---

4. DNS 레코드 타입 – 도메인과 IP를 연결하는 방식

DNS 서버에는 다양한 형태의 레코드(기록)가 존재합니다. 이를 통해 도메인 이름이 어떤 리소스를 가리키는지 정의할 수 있습니다.

레코드 타입	설명
A	도메인 → IPv4 주소
AAAA	도메인 → IPv6 주소
CNAME	도메인 → 다른 도메인 이름
NS	도메인에 대한 권한 네임 서버 지정
MX	메일 서버 관련 레코드

📌 실무 예시:
example.com → A 레코드 → 1.2.3.4
www.example.com → CNAME → example.com

---

5. URI와 URL – 리소스를 가리키는 방식

5-1. URI, URL, URN의 차이

용어	의미	예시
URI	자원 식별자 전체 개념	urn:isbn:0451450523
URL	자원의 위치 (주소)	https://example.com/index.html
URN	이름 기반 식별	urn:isbn:1234

 

→ URL은 URI의 한 형태이며, 우리가 주로 사용하는 주소는 대부분 URL입니다.

---

6. URL의 구성 요소 상세 분석

https://www.example.com:8042/over/there?name=ferret#nose
└──────┬──────┘ └────┬────┘ └──────┬────┘ └──────┬──────┘ └───┬───┘
 scheme  host(DN/IP)   port      path         query         fragment

주요 구성요소

요소	설명
scheme	프로토콜 명시 (http, https 등)
authority	호스트 주소 (도메인 or IP)
path	리소스의 경로 (/images/logo.png)
query	파라미터 (ex. ?name=value)
fragment	특정 위치(anchor)로 스크롤 이동

 

🧠 실무 예시:
/search?keyword=book → 검색 키워드
#section1 → 페이지 내 특정 위치로 이동

 

---

7. HTTP의 특징 4가지 

각 특징은 HTTP가 웹에서 널리 쓰이는 이유이기도 하며, API 설계나 성능 최적화, 인증 처리 등에서 자주 언급됩니다.

 

① 요청 응답 기반 프로토콜

HTTP는 클라이언트가 요청(Request)을 보내고, 서버가 그에 대한 응답(Response)을 보내는 구조로 동작합니다.

 

- 브라우저, 앱 등이 요청을 보내고, 서버는 그에 맞는 HTML, JSON 등의 데이터를 응답합니다.
- 단방향 통신이기 때문에, 서버는 클라이언트에게 먼저 메시지를 보낼 수 없습니다.

🧠 실전 포인트:  
서버가 먼저 메시지를 보내야 하는 경우는 WebSocket, SSE 같은 별도 기술이 필요합니다.

 

---

② 미디어 독립적 프로토콜

HTTP는 전송하는 데이터의 종류에 제한이 없습니다.

HTML, CSS, JS, 이미지, JSON, PDF 등 모든 콘텐츠 유형을 전송할 수 있으며,  
어떤 콘텐츠가 오가는지는 Content-Type 헤더를 통해 명시합니다.

Content-Type: application/json

 

이로 인해 HTTP는 문서 전송뿐 아니라

REST API, 이미지 전송, 동영상 스트리밍 등 모든 웹 기능에 대응할 수 있습니다.

✅ 이 특성 덕분에 웹이 ‘문서 중심’에서 ‘앱 플랫폼’으로 진화할 수 있었습니다.

---

③ 스테이트리스 프로토콜 (Stateless)

HTTP는 상태를 유지하지 않는(stateless) 프로토콜입니다.

서버는 각 요청이 독립적이라고 가정하고, 이전 요청의 정보를 저장하지 않습니다.

이 덕분에 서버 구조는 단순하고, 확장성(Scalability)이 뛰어나지만,

로그인 상태 유지, 장바구니 유지 등 사용자 상태 저장이 필요한 기능은

별도 기술로 구현해야 합니다. (→ 쿠키, 세션, 토큰 등)

💡 면접 단골 질문:
“Stateless한 HTTP에서 사용자 인증 상태는 어떻게 유지할까요?”

---

④ 지속 연결 프로토콜 (Persistent Connection)

기본적으로 HTTP는 요청-응답 후 연결을 끊었지만,
HTTP/1.1부터는 연결을 유지하여 여러 요청을 한 번에 처리할 수 있는 ‘지속 연결’을 지원합니다.

• 예전 방식: 요청할 때마다 TCP 연결 → 비효율
• 지속 연결: 하나의 TCP 연결로 여러 요청/응답 처리 → 지연(latency) 감소, 속도 개선

Connection: keep-alive

특히 브라우저는 HTML, CSS, JS, 이미지 등 

다수의 리소스를 병렬로 요청해야 하므로 

지속 연결은 필수적입니다.

📌 이후 등장한 HTTP/2, HTTP/3는 이 특성을 더욱 강화합니다. (멀티플렉싱, 스트림 병렬화 등)

이처럼 HTTP의 4가지 특징은 단순한 개념이 아니라,

📦 웹의 작동 원리와 

🛠️ 서비스 설계, 

🔐 보안 및 인증 처리, 

🚀 성능 최적화에까지 

영향을 줍니다.

 

MIME 타입 (Content-Type)

HTTP는 다양한 미디어 타입을 지원합니다.

타입	서브타입	설명
text	plain, html, css	텍스트 문서, HTML, 스타일
image	jpeg, png, gif	이미지 리소스
video	mp4, webm	영상
application	json, pdf	데이터 포맷

8. HTTP 메시지 구조

HTTP 메시지는 요청과 응답 두 종류로 나뉘며, 다음과 같은 구조를 가집니다.

✅ 요청 메시지 구조

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

• 시작 라인: 요청 방식(GET), 경로, HTTP 버전
• 헤더 필드: 요청 정보들 (브라우저 종류, 허용 포맷 등)
• 본문: (POST일 경우) 추가 데이터

✅ 응답 메시지 구조

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 648

<html>...</html>

• 상태 라인: HTTP 버전 + 상태 코드 + 상태 메시지
• 헤더 필드: 응답 정보
• 본문: 실제 콘텐츠

---

면접 질문

Q. HTTP가 스테이트풀한지, 스테이트리스한지에 대해 그 이유와 함께 설명하세요.

• HTTP는 스테이트리스(Stateless) 프로토콜입니다.
• 특징:
  • 각 요청은 독립적으로 처리
  • 이전 요청의 정보를 저장하지 않음
  • 쿠키, 세션으로 상태 관리 보완
• 장점: 서버 확장성 향상, 효율적인 자원 관리
• 단점: 클라이언트의 추가 정보 전송 필요

예: HTTP는 각각의 요청이 독립적으로 처리되는 스테이트리스 프로토콜로, 서버가 클라이언트의 이전 요청 정보를 저장하지 않아 확장성과 자원 관리 측면에서 효율적이지만, 상태 유지가 필요한 경우 쿠키나 세션과 같은 추가적인 방법을 사용해야 합니다.

Q. 웹 브라우저에서 'https://www.google.com' 접속 과정

1. DNS 조회: 도메인 이름 → IP 주소 변환
2. TCP 연결 수립 (3-way handshake)
3. SSL/TLS 핸드셰이크
4. HTTP 요청 전송
5. 서버 응답 처리
6. 웹 브라우저 렌더링

예: 웹 브라우저에서 구글 접속 시, DNS를 통해 도메인 이름을 IP 주소로 변환하고, TCP 3-way handshake로 연결을 수립한 후, SSL/TLS 핸드셰이크로 보안 연결을 설정합니다. 이후 HTTP 요청을 전송하고 서버로부터 응답을 받아 웹 브라우저가 이를 렌더링하여 사용자에게 보여줍니다.

Q. 도메인 네임 웹사이트 연동 과정

1. 도메인 등록 업체에서 도메인 구매
2. 네임서버 설정
3. DNS 레코드 설정 (A 레코드, CNAME 등)
4. 전파 시간 대기 (24-48시간)
5. DNS 설정 확인 및 연결 테스트

예: 도메인 네임을 웹사이트에 연동하기 위해서는 먼저 도메인 등록 업체에서 도메인을 구매하고, 호스팅 서버의 네임서버를 설정한 후, A 레코드나 CNAME 등의 DNS 레코드를 설정합니다. 이후 DNS 설정이 전파되는 시간(보통 24-48시간)을 기다린 후, 연결이 제대로 되었는지 확인하고 테스트합니다.

마무리: HTTP 요청의 출발점 정리

이번 글에서는 다음을 중심으로 정리했습니다.

• 브라우저가 도메인을 입력하면, DNS를 통해 IP를 조회
• 조회된 IP로 TCP 연결 후, HTTP 요청 메시지 전송
• HTTP 4가지 특징
• 요청 메시지에는 메서드, 경로, 헤더, 본문이 포함
• 응답 메시지로는 상태 코드 + 콘텐츠가 돌아옴

📌 이 구조는 API 설계, 네트워크 디버깅, 면접 질문 어디서든 기반이 됩니다.

다음 편 예고

✅ [2편]에서는 상태 코드, 쿠키/세션, HTTPS, 그리고 HTTP의 진화(1.1/2.0/3.0)를 살펴봅니다.

• 서버는 어떻게 로그인 상태를 기억할까요? HTTPS는 왜 필요한 걸까요?

참고 자료

• 『이것이 취업을 위한 컴퓨터 과학이다』 p.431~447
• MDN - HTTP 메시지
• Cloudflare - What is DNS?