이번 포스팅에서는 사용자가 www.google.com 로 접속했을 때 일어나는 일에 정리했다.
너무 깊은 지식은 다루지 않았고, 무엇보다 내 지식을 복기하고 싶었어서 아무런 자료도 찾아보지 않고 작성했다.
이후 다이어그램만 자료를 찾아서 첨부했다.
1. 사용자 브라우저 주소 입력
사용자가 크롬, 엣지, 사파리 같은 웹 브라우저의 주소창에 www.google.com 를 입력한다.
2. 로컬 DNS 캐시 확인 (Local DNS Cache)
1) 브라우저 내부 캐시 확인
브라우저는 이전 접속에서 기억하고 있는 DNS 캐시를 가장 먼저 확인한다. (예: 크롬 DNS 캐시)
2) OS DNS 캐시 확인
브라우저에 없으면 메모리에 저장되어 있는 운영체제 DNS 캐시를 확인한다.
(예: Windows ipconfig /displaydns, Linux systemd-resolve --statistics).
3) Hosts 파일 확인
OS가 유지하는 hosts 파일을 확인한다.
- Windows: C:\Windows\System32\drivers\etc\hosts
- Linux/Mac: /etc/hosts
결과:
캐시에 있으면 IP 주소 반환 후 DNS 과정 종료.
없으면 DNS 서버 쿼리 단계로 이동.
3. DNS 서버 쿼리 (Domain Name Resolution)
1) 로컬 DNS 서버 (ISP DNS 서버)로 질의
로컬 DNS 서버로 도메인 네임을 질의한다.
사용자의 네트워크 설정에 따라 상이할 수 있지만, 일반적으로 ISP에서 제공하는 DNS 서버를 로컬 DNS 서버로 사용한다.
2) 로컬 DNS 서버 캐시 확인
로컬 DNS 서버 캐시의 해당 도메인에 대한 레코드 내용이 있으면 캐시된 IP 주소를 반환한다.
- ISP 네트워크 내 같은 로컬 DNS 서버를 사용하는 사용자 A가 www.google.com 를 이미 접속한 경우 DNS 반환 값이 캐싱돼 사용자 B가 이를 재활용할 수 있다.
3) 없을 경우 DNS 재귀 질의 (Recursive Query)
캐싱된 데이터가 없으면 로컬 DNS 서버는 root hints 파일에 내장된 루트 네임 서버를 시작으로 DNS 재귀 질의를 수행한다.
Root DNS 서버는 TLD(Top-Level Domain) 서버 NS 레코드를 반환한다.
TLD 서버는 Sub Domain 서버 NS 레코드를 반환한다.
Sub Domain 서버는 접근하고자 하는 호스트의 A, CNAME 레코드 등을 반환해 최종적으로 IP 주소를 얻게된다.
결과:
IP 주소를 사용자 브라우저에 제공.
4. 라우팅 테이블 조회 (경로 결정) 및 NAT 변환
사용자의 PC는 반환된 목적지 IP에 접근하기 위해 Default Gateway로 요청 패킷을 전달한다.
라우터는 NAT를 통해 요청 패킷을 공인 IP로 변환한다.
결과:
사용자의 요청 패킷이 공인 IP로 변환되어 인터넷 전송 준비.
5. TCP 3-Way Handshake (연결 설정)
변환된 공인 IP와 구글의 웹 서버 IP가 정상적으로 패킷을 송수신했다면 TCP 기반의 웹 프로토콜 사용을 위해 세션을 수립한다.
1) 클라이언트가 서버로 SYN 플래그 세그먼트를 전송한다.
2) 서버는 SYN 플래그 세그먼트의 응답에 대한 ACK 플래그 세그먼트와 양방향 연결 수립을 위한 SYN 플래그 세그먼트를 반환한다.
3) 클라이언트는 SYN 플래그 세그먼트의 응답에 대한 ACK 플래그 세그먼트를 반환한다.
위 과정을 통해 안정적인 통신을 위한 TCP 세션이 수립됐다.
결과:
TCP 레벨에서 안정적 통신을 위한 세션 수립.
6. TLS 1.3 핸드셰이크 (HTTPS 암호화 설정)
수립된 TCP 세션 위에 HTTPS 암호화와 인증을 위한 TLS 핸드셰이크를 수행한다.
1) 클라이언트가 서버에게 ClientHello 메시지를 보낸다.
이 ClientHello 메시지에는 지원 가능한 암호화 방식, 대칭(세션) 키를 위한 랜덤 데이터, SNI 값을 담는다.
2) 서버가 클라이언트에게 ServerHello 메시지를 보낸다.
이 ServerHello 메시지에는 서버가 결정한 암호화 방식 통보, 서버 인증서(공개 키 포함), 대칭(세션) 키를 위한 랜덤 데이터, 키 교환 방식에 대한 값을 담는다.
3) 키 교환 및 대칭키 생성
클라이언트와 서버가 서로 공개키 기반으로 키를 교환한다.
또, 클라이언트와 서버가 교환한 랜덤 값을 이용해 동일한 키를 독립적으로 각각 생성한다.
4) 양방향으로 Finished 메시지를 보낸다.
세션 무결성 확인을 위해 최종 Finished 메시지를 보낸다.
위 과정을 통해 모든 데이터는 TLS로 암호화된 상태로 전송된다.
결과:
암호화 채널(Secure Channel) 형성 및 이를 활용한 암호화 통신 수행
7. HTTP 요청 (Request) 및 응답
사용자의 브라우저에 출력할 웹 페이지를 웹 서버로부터 받아오기 위해 HTTP GET 메서드를 사용한 메시지를 생성해 서버에 전달한다.
이 과정에서 생성해 놓은 암호화 채널, TCP 세션 등을 활용해 암호화된 메시지가 안정적으로 전달된다.
서버는 클라이언트로부터 전달받은 응답에 대해 값을 반환한다.
결과:
서버에 HTTP GET 메시지를 요청해 응답받아 브라우저가 해석할 웹 페이지를 수신받는다.
8. 데이터 렌더링 (브라우저 파싱 및 렌더링)
사용자는 최종적으로 HTML, CSS 파일을 얻게 됐다.
1) 브라우저는 전달받은 파일들을 각각 파싱해 DOM 트리와 CSSOM 트리를 생성한다.
2) 이후 생성된 DOM, CSSOM 트리를 통합해 실제 렌더링 대상 요소만 포함하는 Render 트리를 생성한다.
3) 브라우저의 렌더링 엔진은 Render 트리를 기반으로 레이아웃, 페인팅이라는 시각적 처리를 수행한다.
이때 완벽한 페이지가 아니더라도 사용자 경험을 고려해 초기 페이지를 보여주고, 필요에 따라 리소스(CSS, JS, 이미지 등)을 별도로 요청한 후 위 과정을 반복해 최종 웹 페이지를 완성한다.
결과:
사용자가 웹 페이지를 볼 수 있다.
요약
[사용자 브라우저 주소 입력]
│
▼
[로컬 DNS 캐시 확인] ─────────────────────────────┐
│ (브라우저 캐시, OS 캐시, hosts 파일) │
│ │
│ (IP 주소 발견 시) │
└──> [IP 주소 반환] <──────────────────────────┘
│ (IP 주소 없을 시)
│
▼
[DNS 서버 쿼리 (ISP DNS)] ── 캐시 확인 ──┐
│ │
(캐시 없음) ▼ │
[재귀적 DNS 질의] │
(Root DNS → TLD DNS → 권한 DNS) │
│ │
▼ │
[IP 주소 획득] <─────────────────┘
│
▼
[라우팅 테이블 조회 및 NAT 변환]
│
▼
[TCP 3-Way Handshake (연결 수립)]
(SYN → SYN-ACK → ACK)
│
▼
[TLS 1.3 핸드셰이크 (암호화 채널 설정)]
(ClientHello ↔ ServerHello ↔ 키 교환 ↔ Finished)
│
▼
[HTTP GET 요청 및 서버 응답]
(암호화된 HTTP 요청/응답)
│
▼
[HTML, CSS, JS, 이미지 데이터 수신]
│
▼
[브라우저 파싱 및 렌더링]
(HTML 파싱 → DOM 생성 → CSSOM 생성)
│
▼
[렌더 트리 생성 → 레이아웃 → 페인팅]
│
▼
[웹 페이지 최종 화면 표시]
'Theory > Infrastructure & Network' 카테고리의 다른 글
네트워크 이론 (4) (0) | 2025.03.13 |
---|---|
네트워크 이론 (2) ~ (3) (0) | 2025.03.12 |
네트워크 이론 (1) (0) | 2025.03.10 |
클라우드 컴퓨팅 이론 (3) (0) | 2025.03.10 |
클라우드 컴퓨팅 이론 (2) (0) | 2025.03.08 |