브라우저 주소 창에 www.example.com 입력
브라우저에 www.example.com 을 입력하고 엔터를 누르면 웹 요청이 시작된다. 이 요청의 문자열은 서버와 통신하기 위한 핵심 정보들을 담고 있다.
URL 구성
https://www.example.com:443/path/to/resource?key=value#section
많이 복잡해보이지만 하나하나 뜯어보면 요청 흐름의 윤곽을 볼 수 있다.
- https : 스킴 - 사용할 프로토콜 결정 (http / https)
- www.example.com : 호스트 - 요청 대상 서버의 도메인
- 443 : 포트 - 통신에 사용할 포트 번호
- /path : 경로 - 요청할 리소스 위치
- ?key=value : 쿼리 - 요청에 포함할 파라미터
- #section : 프래그먼트 - 문서 내 특정 위치
이렇듯 url을 보면 요청의 내용을 알 수 있지만 사실 컴퓨터는 이런 문자열을 이해하지 못한다. 문자열을 숫자로 바꾸는 IP변환 과정이 필요하다. 우리는 이런 IP변환 작업을 DNS(Domain Name System) 조회 라고 부른다.
DNS 조회
도메인과 IP주소의 관계는 전화번호부의 사람 이름과 전화번호에 비유할 수 있다. 사람 이름을 보고 그에 해당하는 전화번호에 걸듯, 브라우저는 도메인 기반으로 IP주소를 찾아 해당 주소로 통신을 시도한다.
DNS 조회는 어떤 순서로 이루어질까?
DNS 조회는 성능을 고려해 여러 단계를 거치며 이 과정에서 캐시가 적극 활용된다.
- 브라우저 캐시: 브라우저가 이전 요청에서 IP 정보를 저장하고 있다면, 가장 먼저 이를 사용한다.
- 운영체제(OS) 캐시: 브라우저에 정보가 없으면, 운영체제가 가지고 있는 DNS 캐시를 확인한다.
- 호스트 파일: 일부 시스템은 /etc/hosts(Unix) 또는 C:\Windows\System32\drivers\etc\hosts(Windows) 파일에서 도메인-IP 매핑을 직접 설정할 수 있다.
- 로컬 DNS 서버(주로 공유기나 ISP): 캐시에 정보가 없으면, 네트워크에 설정된 DNS 서버로 쿼리를 보낸다.
- 권한 있는 네임서버까지 순차적 조회: 최종적으로, 루트 → TLD → 권한 있는 네임서버로 이어지는 계층적 구조를 따라가며 IP 주소를 찾는다.
참조 : nslookup www.example.com 의 명령어를 통해 사용중인 DNS 서버와 해당 도메인의 IP주소를 확인할 수 있다. 아래 예시는 블로그 웹사이트의 ip주소이다.

TCP 연결
브라우저가 도메인의 IP주소를 알아냈다면 TCP 연결을 맺어야 할 차례이다. 이 과정은 HTTP 요청을 전송하기 전에 반드시 필요한 절차이며, 데이터를 신뢰성 있게 주고받기 위한 준비 단계다.
TCP연결이 필요한 이유
TCP연결은 데이터가 순서대로, 빠짐없이, 손상 없이 전달되도록 보장하며, 이를 위해 3-way Handshake 과정을 거치게 된다.

TCP 연결은 다음 세 단계로 시작된다.
- SYN : 클라이언트가 서버에 연결 요청을 보낸다.
- SYN-ACK : 서버가 요청을 수락하고 응답을 보낸다.
- ACK : 클라이언트가 응답을 확인하고 연결 완료를 알린다.
이 과정을 통해 서로 연결 의사를 확인하고, 이후의 데이터 전송은 이 연결을 기반으로 이루어진다.
HTTP 요청 전송
TCP 연결이 성공적으로 맺어지면, 이제 클라이언트는 서버에게 HTTP 요청 메세지를 전송한다. 단순히 "웹사이트 보여줘!"는 아니고 HTTP 요청 구조에 따라 요청을 하게 된다.
Request Line (요청 시작 줄)
HTTP1GET /posts/1 HTTP/1.1
각 구성은 이렇게 되어있다.
- Method : 요청 방식 (GET, POST 등)
- Path : 요청할 리소스
- HTTP Version : HTTP 버전
Headers (헤더)
헤더에는 요청에 대한 추가 정보를 담고있다. 대표적인 헤더들은 다음과 같다.
- Host : 어떤 서버로 가는 요청인지
- User-Agent : 브라우저 정보
- Authorization : 인증 토큰
- Cookie : 로그인 정보
- Content-Type : body 데이터 타입
- Accept : 원하는 응답 타입
Body (본문)
데이터를 서버로 보낼 때 사용하기 때문에 주로 POST, PUT, PATCH 에서 사용된다.
HTTP 응답 수신
HTTP 응답도 요청과 비슷하게 3부분으로 나뉘어져있다.
Status Line (상태줄)
여기서는 요청이 성공했는지 실패했는지 알려준다.
HTTP1HTTP/1.1 200 OK
응답 상태코드는 다양한 종류가 있으니 몇 가지 유명한 것들만 소개하겠다.
- 200 : 성공
- 301 : 리다이렉션
- 404 : 요청한 리소스를 찾을 수 없음
- 500 : 서버 내부 오류
Response Headers
서버가 보내는 메타 정보이다. 대표적인 것들은
- Content-Type : 응답 데이터 타입
- Content-Length : 데이터 크기
- Set-Cookie : 쿠키 설정
- Cache-Control : 캐싱 정책
- Server : 서버 정보
가 있다. 예를 들어서
HTTP1Content-Type: application/json 2Content-Length: 125 3Set-Cookie: session=abc123 4Cache-Control: no-cache
의 형태를 하고 있다면
body 타입은 JSON 형태이며 125바이트이고 쿠키 저장소에 abc123을 저장해야해. 이 응답은 캐시에 저장하지 말고 매번 서버에서 확인해
라고 말하는 것과 같다.
Body (본문)
이 부분에서는 사용자가 실제로 보거나 사용할 수 있는 데이터가 포함된다.
- HTML : 브라우저에서 렌더링되는 웹 페이지
- JSON : 프론트에서 활용할 API 응답
- 이미지, 영상 등 바이너리 콘텐츠
브라우저 렌더링
이 모든 과정을 거친 뒤 마침내 사용자의 브라우저는 응답받은 HTML을 화면에 시각화한다. 이 과정을 렌더링이라고 부른다.