브라우저 주소창에 google.com을 입력한다면?

작성 2022년 11월 12일

브라우저 주소창에 google.com을 입력하면 어떤 일이 벌어질까요? DNS, TCP, HTTP를 차례대로 외우면 큰 흐름은 잡히지만, 실제 브라우저에서는 캐시나 연결 재사용 때문에 어떤 단계가 생략되기도 합니다.

여기서는 주소를 입력해 HTTPS 페이지로 이동하고, 필요한 경우 새 연결을 만드는 상황을 기준으로 설명하겠습니다. 실제 Google 서비스의 내부 구현을 재현한 글은 아닙니다.

2022년 글의 기본 흐름을 유지하면서 HTTPS, HTTP/3, 캐시와 DevTools 관찰 방법을 보완했습니다. 화면에 남은 IP 주소와 헤더는 당시 예시입니다.

1. 먼저 주소인지 해석한다

주소창은 입력을 URL이나 검색어로 해석합니다. google.com에는 스킴이 없으므로 브라우저의 정책, 이전 방문 기록, 보안 설정 등에 따라 이동할 주소를 정합니다. 여기서는 https://google.com/으로 이동한다고 가정하겠습니다.

URL에서 호스트는 google.com, 경로는 /입니다. DNS가 받는 대상은 호스트 이름입니다. /search?q=... 같은 경로와 검색 파라미터를 DNS에 보내 주소를 찾는 것은 아닙니다.

이 시점 이후에도 반드시 원격 서버에서 HTML을 새로 받아오는 것은 아닙니다. 유효한 HTTP 캐시나 설치된 서비스 워커가 응답을 제공할 수 있기 때문입니다. 아래는 네트워크 요청이 필요한 경우의 흐름입니다.

2. DNS로 접속할 주소를 찾는다

DNS는 이름을 IP 주소를 비롯한 여러 종류의 레코드에 연결하는 분산 시스템입니다. IPv4 주소는 A, IPv6 주소는 AAAA 레코드로 조회할 수 있고, 하나의 이름에 여러 주소가 연결될 수도 있습니다.

nslookup google.com

nslookup의 결과는 실행 위치와 시점에 따라 달라집니다.

브라우저 자체 캐시, 운영체제의 이름 해석 기능, 공유기의 DNS 프록시, 재귀 리졸버 캐시 등이 활용될 수 있습니다. 다만 반드시 이 순서로 모두 조회하는 것은 아닙니다. 브라우저가 DNS over HTTPS를 쓰는 경우 이름 해석 경로가 운영체제 기본 설정과 다를 수 있어요.

필요한 정보가 재귀 리졸버에도 없다면 다음과 같이 찾아갈 수 있습니다.

루트 서버에서 .com을 담당하는 서버 정보를 얻습니다.
.com 서버에서 google.com의 권한 있는 서버 정보를 얻습니다.
권한 있는 서버에서 필요한 주소 등의 응답을 받습니다.
리졸버가 결과를 클라이언트에 돌려주고 TTL에 따라 캐시합니다.

실제로는 중간 정보가 캐시돼 일부 질의가 생략되거나 별칭을 추가로 따라갈 수 있습니다. 클라이언트가 최종 답을 부탁하는 재귀 질의와, 리졸버가 여러 서버에 차례로 물어보는 반복 질의도 구분해야 합니다. DNS의 기본 구조를 정의한 RFC 1034를 참고할 수 있습니다.

IP 주소를 얻었다고 그 주소를 브라우저에 직접 입력하면 항상 같은 사이트가 나오는 것도 아닙니다. 한 서버가 여러 호스트를 처리할 수 있고, HTTPS 인증서도 접속한 이름과 맞아야 합니다.

3. 연결하고 암호화 통신을 준비한다

사용할 프로토콜	새 연결에서의 기본 흐름
HTTPS의 HTTP/1.1·HTTP/2	TCP 연결 후 TLS 핸드셰이크
HTTP/3	UDP 위의 QUIC에서 보안 연결 수립
기존 연결 재사용	이미 준비된 연결을 사용해 설정 비용 절감

TCP의 새 연결은 SYN, SYN/ACK, ACK라는 세 단계로 연결을 수립합니다. 이것이 three-way handshake입니다. TCP 연결만으로 암호화되는 것은 아니며, HTTPS는 TLS로 서버 인증서와 이름 등을 검증하고 통신을 보호할 키를 합의합니다.

HTTP/3는 TCP가 아니라 QUIC을 사용합니다. QUIC은 TLS를 통합해 보안 연결을 만들므로 “모든 웹 요청은 TCP 3-way handshake부터 한다”는 설명은 맞지 않습니다. 브라우저와 서버의 지원, 네트워크 조건에 따라 선택과 재시도 경로가 달라질 수 있습니다. HTTP/3 명세인 RFC 9114에 전송 계층과 HTTP의 관계가 정리돼 있습니다.

4. HTTP 요청을 보낸다

연결이 준비되면 브라우저가 문서 요청을 보냅니다. 다음은 이해를 위해 HTTP/1.1의 텍스트 형식으로 쓴 예시입니다. HTTP/2·HTTP/3의 실제 전송 형식과는 다릅니다.

        
      
GET / HTTP/1.1
Host: google.com
Accept: text/html

쿠키가 있더라도 항상 전부 보내지는 않습니다. 도메인·경로, Secure, SameSite 등의 조건에 맞는 쿠키가 대상입니다. 또한 GET은 공개, POST는 암호화라는 구분은 없습니다. 전송 보호는 HTTPS가 맡습니다.

요청은 CDN, 프록시, 로드밸런서를 거쳐 처리될 수 있습니다. 캐시된 정적 HTML을 바로 돌려줄 수도 있고, 서버 애플리케이션이 DB나 다른 API를 호출한 뒤 응답을 만들 수도 있습니다. 모든 요청이 반드시 애플리케이션과 DB까지 가는 것은 아닙니다.

5. 상태 코드와 헤더에 따라 다음 행동을 정한다

응답에는 상태 코드, 헤더, 필요한 경우 본문이 있습니다. 문서의 Content-Type은 해석 방법에, Content-Encoding은 압축 해제에, Cache-Control은 저장·재사용 정책에 영향을 줍니다.

200 응답의 HTML을 받아 렌더링할 수도 있지만 리디렉션이라면 새 URL로 이동합니다. 조건부 요청에 304 Not Modified가 오면 서버가 문서 본문을 다시 보내는 대신 저장된 본문을 재사용합니다.

DNS 캐시와 HTTP 캐시는 저장 대상이 다릅니다. DNS 캐시는 이름 해석 결과를, HTTP 캐시는 요청에 대응하는 응답을 재사용합니다. Cache-Control: no-cache는 재사용 전에 재검증하라는 뜻이고, no-store는 저장하지 말라는 뜻입니다. 이름만 보고 같은 정책으로 처리하면 안 됩니다. MDN의 HTTP 캐시 설명에서 차이를 확인할 수 있습니다.

6. HTML을 화면으로 바꾼다

브라우저는 HTML을 파싱해 DOM을 만들면서 필요한 CSS, JavaScript, 이미지 등의 요청을 발견합니다. CSS로 계산한 스타일과 DOM을 바탕으로 배치를 계산하고, 페인트와 합성을 거쳐 화면에 표시합니다.

한 단계가 완전히 끝나야 다음 단계가 시작되는 직렬 공정은 아닙니다. HTML을 받는 동안 파싱하고 추가 리소스를 요청할 수 있습니다. 스크립트 종류와 위치에 따라 HTML 파싱을 멈추거나 나중에 실행하기도 하고, 스타일 계산이나 JavaScript의 DOM 변경으로 레이아웃을 다시 계산할 수도 있어요. MDN의 브라우저 렌더링 과정은 이 연결을 설명합니다.

SPA라면 HTML을 받은 뒤 JavaScript가 API를 요청하고 화면을 구성하는 작업이 더해질 수 있습니다. 그래서 HTML 응답 완료, 첫 화면 표시, 실제 상호작용 가능 시점은 같지 않습니다.

DevTools에서 직접 확인해보자

Chrome DevTools의 Network를 열고 페이지를 방문해 첫 번째 문서 요청을 선택합니다. 다음은 원인을 바로 단정하기 위한 표가 아니라 추가로 확인할 위치입니다.

관찰	먼저 볼 항목	단정하면 안 되는 것
DNS 구간이 길다	이름 해석 경로, 네트워크 조건	애플리케이션 코드가 느리다
연결·SSL 구간이 길다	새 연결 여부, RTT, 인증서·네트워크 문제	응답 본문이 크다
Waiting/TTFB가 길다	서버 처리, 프록시 대기, 네트워크 왕복	DB 쿼리 하나가 원인이다
Content Download가 길다	전송 크기, 처리량, 스트리밍 여부	서버 CPU만 증설하면 된다
다운로드 후 화면이 늦다	Performance의 스크립트·렌더링 작업	다운로드 시간만 줄이면 된다

Protocol 열에서 h2·h3 등을 확인하고, Timing에서 소요 시간을 비교할 수 있습니다. 캐시나 연결 재사용 시 일부 구간이 없을 수 있습니다. Network의 Disable cache는 개발자 도구가 열린 동안 HTTP 캐시 영향을 줄이는 기능이며, DNS 캐시와 기존 연결까지 모두 초기화하는 스위치는 아닙니다. Chrome Network 패널 공식 설명을 기준으로 해석해야 합니다.

주소창의 한 번의 입력에는 이름 해석, 연결, 요청·응답, 렌더링이 연결돼 있습니다. 이 순서를 이해하는 목적은 면접 답변을 길게 만드는 것보다, 느리거나 실패한 구간을 관찰해서 다음 확인 대상을 좁히는 것에 있겠습니다.