우리는 하루에도 수십 번씩 브라우저를 사용한다.
주소창에 https://www.naver.com을 입력하고 엔터를 누르면 잠시 뒤 네이버 홈페이지가 나타난다.
너무나 당연한 일이어서 그 과정에 대해 깊이 생각해 본 적은 많지 않을 것이다.
그런데 컴퓨터의 관점에서는 전혀 단순한 일이 아니다.
도메인 이름을 IP 주소로 변환해야 하고, 서버와 통신할 연결을 만들어야 하며, 암호화된 통신을 설정해야 한다. 서버로부터 받은 데이터를 해석하고 실제 화면에 그리는 과정도 필요하다.
우리가 엔터를 누르는 짧은 순간, 네트워크와 브라우저에서는 어떤 일이 벌어지고 있을까?
이 질문 하나에 DNS, TCP/IP, TLS, HTTP, 그리고 브라우저 렌더링이라는 핵심 CS 개념이 연결되어 있다.
먼저 도메인 이름부터 살펴보자.
우리는 naver.com이라는 주소를 기억하지만, 인터넷에서 서버와 통신하기 위해서는 목적지의 네트워크 주소를 알아야 한다.
여기서 등장하는 것이 DNS(Domain Name System)다.
DNS는 사람이 이해하기 쉬운 도메인 이름을 IP 주소 등의 DNS 레코드로 연결해 주는 시스템이다.
www.naver.com
|
▼
DNS 조회
|
▼
연결 대상 IP 주소브라우저는 먼저 관련 주소 정보가 캐시되어 있는지 확인할 수 있다.
필요한 정보가 없다면 운영체제와 설정된 DNS 리졸버 등을 통해 조회하게 된다.
DNS 조회는 다양한 캐시와 재귀적 조회 과정을 거칠 수 있다. 매번 루트 DNS 서버부터 모든 과정을 직접 수행하는 것은 아니다.
직접 확인해 보자.
nslookup www.naver.com또는 macOS에서 다음 명령을 사용할 수도 있다.
dig www.naver.com조회 시점과 네트워크 환경에 따라 서로 다른 IP 주소가 반환될 수 있다.
대규모 서비스는 CDN이나 로드 밸런싱을 사용하므로 하나의 도메인이 항상 같은 서버를 가리키는 것은 아니다.
그렇다면 IP 주소를 알게 되었으니 바로 HTML을 받아올 수 있을까?
아직 한 단계가 더 남았다.
2. 서버와 연결을 맺어야 한다
전통적인 HTTPS 통신에서 HTTP/1.1이나 HTTP/2를 사용한다면 일반적으로 TCP를 기반으로 연결을 맺는다.
TCP는 신뢰성 있는 바이트 스트림 통신을 제공하기 위한 전송 계층 프로토콜이다.
TCP 연결을 수립하는 과정은 흔히 3-Way Handshake라고 부른다.
Client Server
| |
| -------- SYN -------------> |
| |
| <----- SYN + ACK ---------- |
| |
| -------- ACK -------------> |
| |
TCP 연결 수립각 단계에는 목적이 있다.
- SYN: 연결을 시작하겠다는 요청
- SYN + ACK: 요청을 확인하고 연결 의사를 전달
- ACK: 상대방의 응답을 확인
이 과정을 거치면 TCP 연결이 수립된다.
다만 현대 웹 환경에서는 한 가지 예외를 알아둘 필요가 있다.
HTTP/3는 TCP가 아니라 QUIC을 사용한다.
QUIC은 UDP 위에서 동작하면서 신뢰성 있는 전송과 암호화 등의 기능을 제공한다.
따라서 모든 HTTPS 요청이 반드시 TCP 3-Way Handshake를 거치는 것은 아니다.
우리가 흔히 설명하는 TCP 연결 과정은 HTTP/1.1 또는 HTTP/2 기반의 HTTPS 통신을 가정한 것이다.
3. HTTPS의 자물쇠는 어떻게 만들어질까?
TCP 연결이 수립되었다고 가정하자.
이제 서버와 데이터를 주고받을 수 있는 통신 경로는 준비되었다.
하지만 HTTP 데이터를 그대로 전송한다면 중간에서 통신 내용을 엿보거나 변조할 위험이 있다.
이를 막기 위해 사용하는 것이 TLS(Transport Layer Security)다.
TLS는 통신 내용을 암호화하고 서버의 신원을 검증하는 데 사용된다.
과정을 단순화하면 다음과 같다.
Client Server
| |
| ------- ClientHello ------> |
| |
| <------ ServerHello ------- |
| 인증서 등 |
| |
| 키 교환 및 검증 과정 |
| |
| <=== 암호화된 통신 ===> |클라이언트와 서버는 지원하는 암호화 방식 등을 협상하고, 서버 인증서를 검증하며, 통신에 사용할 키를 설정한다.
현대적인 TLS에서는 보통 키 합의를 통해 세션 키를 도출하고, 그 키를 사용해 실제 애플리케이션 데이터를 암호화한다.
여기서 공개키 암호화와 대칭키 암호화가 함께 등장한다.
공개키 기반 기술은 인증 및 키 합의에 활용되고, 실제 대용량 데이터 전송에는 효율적인 대칭키 암호화가 사용된다.
즉, HTTPS는 단순히 HTTP 뒤에 S 하나를 붙인 프로토콜이 아니다.
서버와 안전하게 통신할 수 있도록 보안 계층을 적용한 HTTP 통신 방식이다.
4. 드디어 HTTP 요청을 보낸다
연결과 보안 설정이 끝났다면 이제 브라우저가 HTTP 요청을 보낸다.
개념적으로는 다음과 같다.
GET / HTTP/1.1
Host: www.naver.com
Accept: text/html서버는 요청을 처리한 뒤 HTTP 응답을 반환한다.
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8응답 본문에는 HTML 등이 포함될 수 있다.
그러나 HTML을 받았다고 해서 사용자가 보는 화면이 완성되는 것은 아니다.
브라우저는 이 데이터를 해석해야 한다.
여기서 브라우저 렌더링 과정이 시작된다.
5. HTML이 어떻게 실제 화면으로 바뀔까?
브라우저는 HTML을 파싱하여 DOM(Document Object Model)을 구성한다.
CSS는 CSSOM(CSS Object Model)으로 처리한다.
이후 화면에 표시할 요소와 스타일을 바탕으로 렌더 트리를 구성하고, 각 요소의 크기와 위치를 계산한다.
HTML ──→ DOM ──────┐
├──→ Render Tree
CSS ──→ CSSOM ────┘ |
▼
Layout
|
▼
Paint
|
▼
Compositing
|
▼
화면 표시각 단계의 의미를 정리하면 다음과 같다.
| 단계 | 역할 |
|---|---|
| DOM | HTML의 구조를 객체 트리로 표현 |
| CSSOM | CSS 규칙을 해석 |
| Render Tree | 화면에 표시할 요소와 스타일 구성 |
| Layout | 요소의 크기와 위치 계산 |
| Paint | 요소를 픽셀로 그리는 작업 |
| Compositing | 여러 레이어를 조합하여 최종 화면 생성 |
물론 실제 브라우저는 모든 리소스를 다운로드한 뒤 이 과정을 순서대로 한 번만 수행하지 않는다.
HTML을 스트리밍으로 받아 파싱할 수 있고, 이미지와 JavaScript 등의 추가 리소스를 요청하며, DOM이나 스타일이 변경되면 일부 렌더링 작업이 다시 수행될 수 있다.
그렇기 때문에 JavaScript가 메인 스레드를 오랫동안 점유하거나, 레이아웃을 자주 변경하면 화면이 버벅거릴 수 있다.
6. 직접 브라우저에서 확인해 보자
Chrome에서 개발자 도구를 열어보자.
F12또는Cmd + Option + I를 누른다.- Network 탭을 연다.
- 페이지를 새로고침한다.
- 문서 요청을 선택하고 Timing 탭을 확인한다.
요청에 따라 다음과 같은 단계의 시간이 표시된다.
- DNS Lookup
- Initial Connection
- SSL/TLS
- Request Sent
- Waiting (TTFB)
- Content Download
다만 기존 연결이 재사용되거나 캐시가 사용되면 일부 단계는 표시되지 않거나 별도 시간이 발생하지 않을 수 있다.
여기서 중요한 사실을 하나 발견할 수 있다.
웹페이지가 느리다는 현상 하나에도 원인은 여러 가지일 수 있다.
DNS 조회가 느린 것일까?
네트워크 지연이 큰 것일까?
서버가 응답을 생성하는 데 오래 걸리는 것일까?
아니면 브라우저가 JavaScript를 실행하고 렌더링하는 데 시간이 걸리는 것일까?
원인에 따라 해결 방법은 완전히 달라진다.
7. 웹 개발자에게 네트워크 CS가 필요한 이유
처음에는 단순히 웹사이트 주소를 입력하는 과정이 궁금했을 뿐이다.
그런데 그 과정을 따라가다 보니 DNS, TCP, TLS, HTTP, DOM, CSSOM, 브라우저 렌더링까지 연결되었다.
프론트엔드 개발자라면 렌더링 최적화에, 백엔드 개발자라면 서버 응답 시간과 연결 관리에 관심을 가지게 될 것이다.
하지만 결국 두 영역은 하나의 사용자 경험으로 연결되어 있다.
사용자 입장에서는 DNS가 느린 것인지, 서버가 느린 것인지, JavaScript가 느린 것인지 중요하지 않다.
그저 웹사이트가 느리다고 느낄 뿐이다.
따라서 개발자는 자신이 작성한 코드뿐 아니라, 그 코드가 네트워크를 통해 전달되고 사용자 화면에 나타나기까지의 전체 흐름을 이해할 필요가 있다.
생각해 볼 문제
Q1. 브라우저에서 새로고침했는데 DNS Lookup 시간이 표시되지 않는 이유는 무엇일까?
Q2. HTTP/2와 HTTP/3는 사용하는 전송 프로토콜 측면에서 어떤 차이가 있을까?
Q3. 서버 응답 시간이 빠른데도 웹페이지가 느리게 표시된다면 어디를 조사해야 할까?
참고 자료
태그: #Network #DNS #TCP #TLS #HTTP #Browser #Rendering #CS