주소창에 https://naver.com을 입력하면 브라우저는 주소를 해석하고, 서버와 통신하고, 응답을 화면으로 만듭니다. 아래는 새로운 HTTPS 연결을 TCP 위에서 만드는 일반적인 흐름입니다. 네이버의 실제 내부 인프라를 특정하는 설명은 아닙니다.
1. URL 해석과 캐시 확인
브라우저는 스킴 https, 호스트 naver.com, 경로 등을 구분합니다. 사용 가능한 캐시나 기존 연결이 있는지에 따라 네트워크 작업 일부를 생략하거나 재사용할 수 있습니다.
리다이렉트 응답을 받으면 새로운 주소로 추가 요청이 필요할 수도 있습니다.
2. DNS로 서버 주소 확인
브라우저와 운영체제의 DNS 캐시 등에 필요한 정보가 없다면 DNS 해석을 통해 호스트에 대응하는 IP 주소를 구합니다. 한 호스트에 여러 IP가 있을 수 있고, 실제 접속 지점은 CDN이나 로드 밸런서일 수도 있습니다.
캐시와 DNS 구성에 따라 조회 과정은 달라지므로, 모든 요청에서 루트 DNS 서버부터 직접 조회하는 것은 아닙니다.
3. 전송 연결과 TLS 설정
TCP 기반 통신에서는 3-way handshake로 연결을 맺습니다. 이어 TLS 협상과 인증서 검증, 키 교환 등을 통해 HTTP 데이터를 보호할 준비를 합니다.
HTTP/3는 TCP 대신 UDP 기반의 QUIC을 사용하므로 이 단계가 다릅니다. 기존 연결 재사용이나 TLS 세션 재개도 전체 흐름을 바꿀 수 있습니다.
4. HTTP 요청과 응답
브라우저는 해당 자원을 요청하고 서버는 상태 코드, 헤더, 본문으로 응답합니다. 예를 들어 성공한 문서 요청은 HTML 본문을 받을 수 있고, 캐시 검증 결과에 따라 기존 본문을 재사용할 수도 있습니다.
쿠키 역시 주소와 보안 정책에 맞는 경우 요청에 포함됩니다.
5. HTML 해석과 추가 자원 요청
브라우저는 HTML을 파싱해 DOM을 만들고, CSS로 스타일 정보를 구성합니다. HTML에서 발견한 스타일시트, 스크립트, 이미지 등을 추가로 요청합니다.
리소스 로딩과 파싱은 일부 겹쳐 진행됩니다. 스크립트의 defer, async 여부 등도 파싱과 실행 순서에 영향을 줍니다.
6. 화면 렌더링
스타일 계산 후 요소의 위치와 크기를 정하는 레이아웃, 그릴 내용을 처리하는 페인트, 레이어 합성 등을 거쳐 화면을 표시합니다. 이후 JavaScript와 사용자 입력에 따라 일부 단계가 다시 수행됩니다.
더 자세한 화면 구성 단계는 브라우저 렌더링 과정에서 확인할 수 있습니다.
참고