브라우저에 www.naver.com을 입력하면 먼저 DNS를 통해 도메인에 대응하는 IP 주소를 조회합니다.
이후 해당 IP의 서버와 TCP 3-Way Handshake를 수행하고, HTTPS이기 때문에 TLS Handshake를 통해 서버 인증과 암호화 키 교환을 수행합니다. 연결이 만들어지면 HTTP 요청을 보내고, 요청은 CDN이나 로드 밸런서 등을 거쳐 애플리케이션 서버에 전달될 수 있습니다. 서버는 필요한 경우 캐시나 데이터베이스를 조회해 HTTP 응답을 생성하고, 브라우저는 응답받은 HTML, CSS, JavaScript 등의 리소스를 이용해 화면을 렌더링합니다.
브라우저가 주소를 해석하고, DNS를 통해 도메인에 대응하는 IP 주소를 찾습니다. 이후 서버까지 연결을 수립하고, HTTPS라면 TLS로 서버를 인증하고 암호화 통신을 준비합니다. HTTP 요청을 보내 응답을 받은 뒤에는 HTML을 파싱하고 필요한 CSS·JavaScript·이미지를 요청하면서 화면을 렌더링합니다.
URL 해석 → DNS 조회 → 연결 수립 → TLS → HTTP 요청·응답 → 렌더링 순서로 설명하되, 캐시나 기존 연결이 있으면 일부 과정은 생략할 수 있다고 덧붙이겠습니다.
단계별로 설명하기
https://www.naver.com/에 새로 접속하며, 사용 가능한 캐시·기존 연결이 없고 HTTP/1.1 또는 HTTP/2를 사용하는 경우를 가정합니다. 아래는 일반적인 웹 접속 모델이며 네이버의 실제 내부 서버 구성이나 현재 협상되는 HTTP 버전을 단정하는 설명은 아닙니다.
1. URL 해석과 캐시 확인
브라우저는 scheme(https), host(www.naver.com), port(기본 443), path(/) 등을 구분합니다. 주소에 scheme이 없을 때의 처리나 HTTPS 우선 시도는 브라우저 정책에 따라 달라집니다. HSTS 정책을 알고 있다면 HTTP 요청을 보내기 전에 HTTPS로 전환할 수 있습니다.
HTTP 캐시나 서비스 워커가 응답을 제공할 수 있는지도 확인합니다. HTTP 응답 캐시와 도메인 주소를 저장하는 DNS 캐시는 서로 다릅니다.
2. DNS로 접속할 IP 찾기
브라우저·OS의 이름 해석 경로에서 캐시 등을 활용하고, 필요한 경우 설정된 재귀 리졸버에 질의합니다. 캐시와 hosts 파일의 조회 순서는 브라우저·OS·보안 DNS 설정에 따라 달라지므로 하나의 고정 순서로 암기하지 않습니다.
재귀 리졸버에도 필요한 정보가 없으면 일반적으로 루트 → .com TLD → naver.com의 권한 있는 네임서버 순으로 위임 정보를 따라 질의합니다. A(IPv4)·AAAA(IPv6) 레코드 등을 얻으며, CNAME이 있다면 별칭 대상도 해석합니다. 루트 서버가 곧바로 네이버 웹 서버의 IP를 알려주는 것은 아닙니다. RFC 1034 §4.3·§5.3
3. 패킷 전달과 연결 수립
OS는 라우팅 테이블로 다음 홉을 정합니다. 이더넷 기반 IPv4 환경에서 외부 네트워크로 보낸다면, 필요할 때 ARP로 기본 게이트웨이의 MAC 주소를 알아냅니다. 원격 네이버 서버의 MAC 주소를 직접 알아내는 것이 아닙니다. IPv6에서는 NDP를 사용합니다.
클라이언트의 임시 포트에서 서버의 443 포트로 TCP 3-Way Handshake를 수행합니다. 패킷은 여러 라우터를 거치며, 환경에 따라 공유기의 NAPT 등으로 주소와 포트가 변환될 수 있습니다. 이 전달 과정은 DNS를 비롯한 다른 네트워크 패킷에도 적용되며, DNS 이후에만 한 번 수행하는 별도 단계는 아닙니다.
4. TLS Handshake
서버 인증서를 검증하고 키 합의를 수행한 뒤 대칭키로 HTTP 데이터를 보호합니다. SNI는 접속하려는 서버 이름을 전달하고, ALPN은 HTTP/2 같은 애플리케이션 프로토콜 협상에 사용됩니다. 자세한 과정은 HTTPS란 무엇이며 동작 과정에 대해 설명해주세요를 참고합니다.
5. HTTP 요청과 서버 응답
브라우저는 /에 대한 요청을 보냅니다. HTTP/1.1이라면 Host 헤더, HTTP/2라면 일반적으로 :authority로 대상 호스트를 나타냅니다. CDN·프록시의 캐시가 응답하거나, 애플리케이션 서버가 필요한 작업을 수행해 응답할 수 있습니다. 모든 요청이 반드시 DB까지 도달하는 것은 아닙니다. RFC 9110: HTTP 구조와 메시지
6. 브라우저 렌더링과 연결 재사용
브라우저는 HTML로 DOM, CSS로 CSSOM을 구성하고 렌더 트리·레이아웃·페인트·합성 과정을 거쳐 화면을 표시합니다. HTML을 처리하면서 추가 리소스를 요청하고 JavaScript를 실행하며, 이 작업들은 일부 병렬로 진행되거나 서로를 막을 수 있습니다. 응답 전체를 받은 뒤에야 모든 렌더링을 시작하는 것은 아닙니다. 연결은 후속 요청에서 재사용할 수 있습니다. MDN: 브라우저 동작 과정
주요 꼬리질문
재귀 질의와 반복 질의는 어떻게 다른가요?
재귀 질의는 질의받은 서버에 최종 답을 구해 달라고 요청하는 방식입니다. 반복 질의는 서버가 자신이 아는 답이나 다음에 물어볼 서버의 정보를 반환하는 방식입니다. 일반적으로 클라이언트는 재귀 리졸버에 요청하고, 리졸버는 권한 서버들의 위임을 따라 반복 질의를 수행합니다.
DNS 서버에게 IP 주소를 요청할 때, 왜 UDP를 사용하나요?
DNS는 짧은 질의와 응답이 빠르게 오가야 하므로, 기본적으로 UDP를 사용합니다.
또 DNS 질의는 보통 하나의 요청과 하나의 응답으로 끝나는 무상태 단발 질의입니다. 서버가 클라이언트별 연결 상태를 오래 유지할 필요가 없기 때문에, 같은 자원으로 더 많은 요청을 처리할 수 있습니다.
DNS는 항상 UDP를 사용하나요?
다만 항상 UDP만 쓰는 것은 아닙니다. 응답이 크거나
DNSSEC처럼 더 많은 데이터가 필요한 경우에는 TCP fallback으로 보완합니다.
DNS TTL을 짧게 하면 서버 IP가 바뀌자마자 모두 바뀌나요?
아닙니다. DNS TTL은 레코드의 캐시 수명이며, 이미 캐시된 결과의 남은 수명과 애플리케이션의 별도 캐시 정책을 고려해야 합니다. 이미 연결된 TCP 연결도 DNS 변경만으로 다른 IP로 이동하지 않습니다. Java에서는 JVM DNS 캐시와 연결 풀을 함께 확인해야 합니다.
IP를 찾았는데 HTTP Host나 TLS SNI가 왜 필요한가요?
하나의 IP에서 여러 도메인을 서비스할 수 있기 때문입니다. SNI는 TLS 단계에서 서버 이름을 전달하여 인증서 선택 등에 사용되고, Host 또는 :authority는 HTTP 단계에서 대상 서비스를 구분합니다. 역할과 사용 시점이 다릅니다.
DNS가 알려준 IP는 실제 애플리케이션 서버의 IP인가요?
반드시 그렇지는 않습니다. CDN, 리버스 프록시, 로드 밸런서의 IP일 수 있으며 하나의 도메인이 여러 IP로 해석될 수도 있습니다. DNS가 반환한 IP와 그 뒤에서 비즈니스 로직을 실행하는 서버를 구분해야 합니다.
재접속하면 DNS부터 TLS까지 전부 다시 하나요?
아닙니다. 유효한 캐시를 쓰거나 기존 연결을 재사용하면 일부 단계를 생략합니다. 새 연결이라도 TLS 세션 재개를 사용할 수 있습니다. HTTP/3에서는 TCP 대신 QUIC으로 연결을 수립합니다.
접속이 느리면 어떤 단계부터 확인하나요?
DNS 해석, 연결 수립, TLS, 첫 응답 대기(TTFB), 다운로드, 렌더링 시간을 나눠 봅니다. TTFB가 길다고 곧바로 DB가 느리다고 결론 내릴 수는 없습니다. 서버 큐 대기·애플리케이션 처리·외부 호출·DB 대기 등을 서버 측 지표와 함께 확인합니다.