- 0
- 286 words
웹 브라우저 주소창에 웹사이트 주소를 입력하고 엔터를 누르면 바로 화면이 나타나는 것처럼 보인다.
하지만 실제로는 그 짧은 순간에 꽤 많은 일이 일어난다.
예를 들어 브라우저에
https://www.example.com을 입력했다고 해보자.
브라우저가 이 주소를 보고 바로 서버에 HTTP 요청을 보내는 것은 아니다.
먼저 도메인 이름을 IP 주소로 바꾸고, 서버와 연결을 만들고, HTTPS라면 TLS 보안 연결까지 설정한 다음 HTTP 요청을 보낸다.
그 이후 서버에서 응답을 받아 브라우저가 HTML, CSS, JavaScript 등을 처리하고 화면을 그린다.
전체 흐름을 아주 간단하게 표현하면 다음과 같다.
URL 입력
↓
URL 분석
↓
DNS 조회
↓
IP 주소 확인
↓
TCP 연결
↓
TLS 연결
↓
HTTP 요청
↓
서버 처리
↓
HTTP 응답
↓
HTML/CSS/JavaScript 처리
↓
웹 페이지 표시이번 글에서는 이 과정을 처음부터 끝까지 하나씩 살펴보려고 한다.
1. 주소창에 URL을 입력한다
먼저 브라우저 주소창에 웹사이트 주소를 입력한다.
https://www.example.com/products여기에는 여러 정보가 들어 있다.
https://
↓
프로토콜
www.example.com
↓
호스트 이름
/products
↓
경로(Path)필요하다면 포트 번호가 포함될 수도 있다.
https://www.example.com:443/products여기서 https는 HTTPS를 사용한다는 의미이고, www.example.com은 접속할 서버를 나타내는 도메인 이름이다.
브라우저는 먼저 이 URL을 분석해서 어떤 프로토콜을 사용하고 어떤 서버에 연결해야 하는지 판단한다.
2. 브라우저는 서버의 IP 주소를 알아낸다
컴퓨터가 실제 네트워크 통신을 하려면 서버의 IP 주소가 필요하다.
그런데 사람이
www.example.com같은 도메인을 사용하는 것은 IP 주소를 직접 입력하는 것보다 편하다.
그래서 브라우저는 DNS를 이용해 도메인 이름에 대응하는 IP 주소를 알아낸다.
브라우저
│
│ www.example.com
▼
DNS 서버
│
│ IP 주소
▼
브라우저DNS 조회 결과 예를 들어 다음과 같은 IP 주소를 얻었다고 생각해보자.
203.0.113.10이제 브라우저는 어느 서버와 통신해야 하는지 알게 된다.
다만 실제로는 브라우저와 운영체제의 DNS 캐시 등을 먼저 확인할 수 있기 때문에 항상 외부 DNS 서버까지 질의하는 것은 아니다.
3. 서버와 연결을 만든다
DNS를 통해 IP 주소를 알아냈다고 해서 바로 HTTP 데이터를 보내는 것은 아니다.
TCP 기반 HTTPS라면 먼저 서버와 TCP 연결을 설정한다.
앞에서 공부했던 3-Way Handshake가 여기서 등장한다.
클라이언트 서버
SYN ─────────────────────────→
←──────────────── SYN-ACK
ACK ─────────────────────────→이 과정을 통해 클라이언트와 서버 사이에 TCP 연결이 만들어진다.
TCP는 데이터를 순서대로 전달하고, 손실이 발생하면 재전송하는 등의 기능을 제공한다.
즉, 지금까지 공부했던 TCP의 개념이 실제 웹 브라우저 접속 과정에서 사용되는 것이다.
다만 한 가지 예외가 있다.
HTTP/3는 TCP가 아니라 QUIC을 기반으로 동작하며 UDP를 사용한다.
따라서 HTTP/3에서는 전통적인 TCP 3-Way Handshake 과정이 그대로 사용되지 않는다.
처음에는 웹 접속이라고 하면 무조건
DNS → TCP → HTTP라고 생각하기 쉽지만, 사용하는 HTTP 버전에 따라 실제 연결 방식이 달라질 수 있다.
4. HTTPS라면 TLS 연결을 설정한다
이번에는 주소가
https://로 시작했기 때문에 TLS 연결을 설정해야 한다.
TLS는 브라우저와 서버 사이의 통신을 보호하기 위한 보안 프로토콜이다.
TLS Handshake 과정에서는 서버 인증서를 확인하고, 사용할 암호화 방식과 키를 협상해 안전한 통신을 준비한다.
개념적으로 보면 다음과 같다.
브라우저 서버
│
│ ── TLS 연결 시작 ────────→
│
│ ←─ 인증서 및 설정 정보 ───
│
│ ── 키 교환 관련 정보 ────→
│
│ ←─ 보안 연결 설정 완료 ───
│서버 인증서가 정상적으로 검증되고 필요한 설정이 끝나면 이제 브라우저와 서버는 암호화된 통신을 할 준비가 된다.
여기서 앞에서 공부했던 SSL과 TLS가 연결된다.
현재 웹에서 사용하는 것은 TLS이며, SSL은 과거의 프로토콜이다.
5. 이제 HTTP 요청을 보낸다
DNS 조회도 끝났고 연결도 만들어졌으며 HTTPS 보안 설정까지 끝났다.
이제 드디어 HTTP 요청을 보낸다.
예를 들어 사용자가 다음 주소에 접속했다면
https://www.example.com/products브라우저는 서버에 비슷한 형태의 요청을 보낼 수 있다.
GET /products HTTP/1.1
Host: www.example.com실제 요청에는 이것보다 훨씬 많은 헤더가 포함될 수 있다.
예를 들어 쿠키가 있다면
Cookie: SESSIONID=abc123같은 정보가 포함될 수도 있다.
그런데 HTTPS에서는 이 HTTP 요청 내용이 TLS에 의해 보호된다.
따라서 네트워크에서 패킷을 관찰하더라도 HTTP 요청 내용을 그대로 보는 것은 어렵다.
6. 서버가 요청을 처리한다
HTTP 요청을 받은 서버는 요청 내용을 확인한다.
예를 들어
GET /products라는 요청이 들어왔다면 서버는 /products에 해당하는 작업을 처리한다.
단순한 정적 웹페이지라면 HTML 파일을 바로 반환할 수도 있다.
반면 쇼핑몰이나 게시판 같은 동적인 서비스라면 서버에서 여러 작업이 이루어질 수 있다.
HTTP 요청
↓
웹 서버
↓
애플리케이션 서버
↓
데이터베이스 조회
↓
결과 생성
↓
HTTP 응답예를 들어 상품 목록을 요청했다면 서버가 데이터베이스에서 상품 정보를 조회한 뒤 HTML이나 JSON 형태의 데이터를 만들어 응답할 수 있다.
7. 서버가 HTTP 응답을 보낸다
서버의 처리가 끝나면 브라우저로 HTTP 응답을 보낸다.
예를 들어 다음과 같은 형태다.
HTTP/1.1 200 OK
Content-Type: text/html그리고 실제 HTML 데이터가 뒤에 따라온다.
<html>
<body>
<h1>상품 목록</h1>
</body>
</html>앞에서 공부했던 HTTP 상태 코드도 여기서 등장한다.
200 → 정상 처리
301/302 → 다른 주소로 이동
404 → 요청한 리소스를 찾지 못함
500 → 서버 내부 오류따라서 브라우저가 화면을 표시하기 전에 서버에서 어떤 HTTP 응답을 받았는지가 중요하다.
8. 브라우저가 HTML을 분석한다
여기까지 왔다고 해서 화면이 완성된 것은 아니다.
브라우저가 서버에서 받은 HTML을 분석해야 한다.
예를 들어 HTML에
<h1>Hello</h1>
<p>Welcome</p>가 있다면 브라우저는 HTML 구조를 분석해서 문서 구조를 만든다.
이 과정에서 DOM(Document Object Model)이 만들어진다.
HTML
↓
HTML 파싱
↓
DOM 생성그리고 HTML 안에 CSS 파일이나 JavaScript 파일이 포함되어 있다면 브라우저는 해당 파일도 추가로 요청한다.
9. CSS와 JavaScript 파일도 요청한다
웹페이지 하나를 표시하는 데 HTML 하나만 필요한 경우는 많지 않다.
예를 들어 HTML에 다음과 같은 코드가 있다고 해보자.
<link rel="stylesheet" href="/style.css">
<script src="/app.js"></script>브라우저는 필요한 리소스를 추가로 요청한다.
HTML
│
├── style.css 요청
│
└── app.js 요청이미 브라우저 캐시에 파일이 있다면 서버에 다시 요청하지 않을 수도 있다.
이미지를 사용하는 페이지라면 이미지 파일도 추가로 요청할 수 있다.
HTML
├── CSS
├── JavaScript
├── 이미지
├── 폰트
└── 기타 리소스그래서 실제 웹페이지를 열면 처음 접속한 주소 하나에 대해서만 통신이 발생하는 것이 아니라 여러 개의 네트워크 요청이 연속적으로 발생할 수 있다.
10. 브라우저가 CSS를 적용한다
HTML 구조가 만들어졌다면 브라우저는 CSS를 적용한다.
예를 들어
h1 {
font-size: 30px;
}같은 CSS가 있다면 브라우저는 어떤 요소에 어떤 스타일을 적용할지 계산한다.
이 과정을 통해 웹페이지의 크기, 위치, 색상, 글꼴 등의 정보가 결정된다.
개념적으로 보면
HTML
↓
DOM
CSS
↓
스타일 정보
DOM + CSS
↓
화면에 배치할 구조 계산이후 브라우저가 실제 화면에 표시할 위치와 크기 등을 계산한다.
11. JavaScript가 실행된다
JavaScript가 포함되어 있다면 브라우저는 JavaScript 코드도 실행한다.
예를 들어 버튼을 클릭했을 때 메뉴가 열리거나 서버에서 새로운 데이터를 가져오는 기능 등이 JavaScript로 구현될 수 있다.
페이지 로딩
↓
JavaScript 실행
↓
이벤트 처리
↓
추가 HTTP 요청
↓
화면 업데이트요즘 웹사이트는 페이지를 처음 불러온 이후에도 JavaScript를 이용해서 서버와 계속 통신하는 경우가 많다.
그래서 화면이 표시된 이후에도 네트워크 요청이 계속 발생할 수 있다.
12. 브라우저가 최종적으로 화면을 그린다
HTML, CSS, JavaScript 등을 처리하고 나면 브라우저는 실제 화면에 웹페이지를 표시한다.
간단하게 보면
HTML
↓
DOM 생성
CSS
↓
스타일 계산
DOM + CSS
↓
배치(Layout)
↓
그리기(Paint)
↓
화면 표시이 과정을 브라우저의 렌더링 과정이라고 생각하면 된다.
사용자가 보는 것은 결국 이 과정을 거쳐 만들어진 결과다.
전체 과정을 한 번에 연결해보자
지금까지 배운 내용을 모두 연결하면 다음과 같은 흐름이 된다.
사용자가 URL 입력
↓
URL 분석
↓
DNS 조회
↓
IP 주소 확인
↓
┌─────────────────┐
│ TCP 연결 설정 │
└─────────────────┘
↓
┌─────────────────┐
│ TLS Handshake │
│ HTTPS인 경우 │
└─────────────────┘
↓
HTTP Request
↓
서버 처리
↓
HTTP Response
↓
HTML 파싱
↓
CSS / JS / 이미지
↓
추가 요청 발생
↓
렌더링
↓
화면 표시HTTP/3를 사용하는 경우에는 TCP 부분이 QUIC 기반 연결로 달라진다는 점만 기억해두면 된다.
쿠키와 세션은 어디에 들어갈까?
앞에서 공부했던 쿠키와 세션도 이 과정에서 등장한다.
사용자가 로그인한 상태라면 브라우저에는 로그인과 관련된 쿠키가 저장되어 있을 수 있다.
서버에 요청을 보낼 때 브라우저가 해당 쿠키를 함께 전송한다.
GET /mypage
Cookie: SESSIONID=abc123서버는 이 세션 ID를 이용해 사용자를 확인할 수 있다.
브라우저
│
│ Cookie: SESSIONID=abc123
▼
서버
│
│ 세션 조회
▼
사용자 확인그리고 HTTPS를 사용한다면 이 쿠키를 포함한 HTTP 통신이 TLS로 보호된다.
이렇게 보면 앞에서 각각 따로 공부했던 기술들이 하나의 흐름으로 연결된다.
DNS
↓
TCP
↓
TLS
↓
HTTP
↓
Cookie / Session
↓
HTML / CSS / JavaScript
↓
브라우저 렌더링개발자 도구를 사용하면 실제로 볼 수 있다
이 과정은 단순한 이론이 아니다.
크롬이나 엣지 같은 브라우저에서 개발자 도구를 열고 Network 탭을 보면 실제 요청과 응답을 확인할 수 있다.
웹페이지를 새로고침하면 여러 요청이 나타난다.
Document
CSS
JS
Img
Font
Fetch/XHR각 요청을 클릭하면 요청 URL, HTTP 메서드, 상태 코드, 응답 헤더, 쿠키 등의 정보를 확인할 수 있다.
특히 Network 탭은 웹 개발이나 네트워크 공부를 할 때 상당히 유용하다.
예를 들어 페이지가 느리다면 어떤 요청이 오래 걸리는지 확인할 수 있고, 특정 API가 404나 500을 반환하는지도 확인할 수 있다.
주소 하나 입력했을 뿐인데 왜 이렇게 복잡할까?
사용자 입장에서는 단순하다.
주소 입력
↓
엔터
↓
웹페이지 표시하지만 실제 컴퓨터 내부에서는 여러 단계가 순서대로 진행된다.
도메인 이름을 IP로 변환
↓
서버와 네트워크 연결
↓
TLS로 보안 연결
↓
HTTP 요청
↓
서버 처리
↓
HTTP 응답
↓
HTML 분석
↓
CSS 적용
↓
JavaScript 실행
↓
추가 리소스 요청
↓
화면 렌더링우리가 지금까지 공부했던 네트워크 개념이 실제 웹페이지 하나를 열 때 모두 연결되어 사용되는 것이다.
마무리
웹 브라우저에 주소를 입력하는 것은 단순히 서버에 파일 하나를 요청하는 과정이 아니다.
브라우저는 먼저 URL을 분석하고 필요한 경우 DNS를 통해 서버의 IP 주소를 확인한다.
그다음 TCP 기반 연결이라면 TCP 연결을 설정하고, HTTPS라면 TLS Handshake를 통해 보안 연결을 만든다.
그 이후 HTTP 요청을 서버로 보내고 서버는 요청을 처리한 뒤 HTTP 응답을 반환한다.
브라우저는 응답으로 받은 HTML을 분석하고 CSS와 JavaScript, 이미지 같은 추가 리소스를 가져온 다음 최종적으로 화면을 렌더링한다.
전체 흐름을 가장 간단하게 정리하면 다음과 같다.
URL
↓
DNS
↓
TCP / QUIC
↓
TLS
↓
HTTP
↓
서버
↓
HTTP Response
↓
HTML / CSS / JavaScript
↓
렌더링
↓
웹페이지이 흐름을 이해하면 지금까지 공부했던 DNS, TCP, TLS, HTTP, 쿠키와 세션 같은 개념이 서로 따로 떨어진 기술이 아니라는 것을 알 수 있다.
결국 사용자가 브라우저에서 웹사이트 하나를 여는 순간에도 여러 네트워크 프로토콜과 웹 기술이 순서대로 연결되어 동작하고 있는 것이다.
이 정도까지 이해했다면 이제 네트워크의 기초적인 흐름을 공부할 때 각각의 기술을 따로 외우기보다, 실제 요청이 어떻게 이동하는지를 기준으로 바라볼 수 있게 된다.
글쓴이
rjsan46@koreabites.com