TIL | 브라우저에 url 입력 후 콘텐츠 렌더링까지의 프로세스

브라우저에 url을 입력시, 다음과 같은 과정을 거쳐 원하는 페이지에 접근할 수 있다.

1. 브라우저에 url 입력
2. 웹사이트를 호스팅하는 웹 서버의 위치 조회
3. 웹 서버에 연결
4. 호스팅 페이지를 가져오기 위한 요청 전송
5. 서버의 응답
6. 페이지의 렌더링(HTML, CSS, Javascript)

---

브라우저에 url 입력

---

웹사이트를 호스팅하는 웹 서버의 위치 조회

• 브라우저에 원하는 도메인을 입력하고 사이트로 접속을 하게 되면, DNS(Domain Name System)에 의해 해당 웹사이트를 호스팅하고 있는 웹서버의 IP 주소를 조회할 수 있다.
• DNS는 복잡하고 매우 빨라야 하기 때문에, 웹 브라우저 사이의 서로 다른 계층과 다양한 위치에 임시로 저장된다. 이를 캐시라 부르며, 웹 브라우저는 DNS 기록을 찾기 위해 우선적으로 브라우저 내 캐시, 운영 체제 캐시, 라우터의 로컬 네트워크 캐시, 회사 네트워크 또는 인터넷 서비스 제공업체(ISP)의 DNS 서버 캐시를 확인한다.
• 만일 웹 브라우저가 캐시 계층에서 해당하는 IP 주소를 몾찾을 경우, 해당하는 IP를 찾지 못하여 오류 응답을 반환할 때까지 회사 네트워크 또는 ISP의 DNS 서버가 재귀적 DNS 조회를 수행한다. 이러한 유형의 검색 방법을 재귀적 질의(Recursive Query)라고 하며 이러한 기능을 담당하는 ISP의 DNS 서버를 DNS 리커서(DNS Recursor)라고 한다.
  (DNS 서버는 할당된 도메인 영역에 대한 정보를 가지고 있는 서버로, 주로 도메인을 IP주소로 변환하는 역할을 한다.)

• 도메인의 아키텍쳐는 위와 같이 구성되어 있다.

• DNS 리커서에 의해 local DNS에서 원하는 도메인 및 IP를 찾아가는 과정(DNS Lookup)은 다음과 같다.
  1. 클라이언트에서 Local DNS로 url(예시: www.naver.com) 입력 및 요청
  2. Local DNS에서 Root DNS 서버로 해당 도메인의 유무 확인
  3. Root DNS에서 해당 도메인이 확인되지 않을 경우, 최상위 도메인인 .com을 확인 후 .com을 관리하는 DNS 서버의 IP 주소를 Local DNS에 전달
  4. Local DNS에서 .com DNS 서버로 해당 도메인 유무 확인
  5. .com DNS 서버에서 해당 도메인이 확인되지 않을 경우, naver.com을 관리하는 DNS 서버의 IP 주소를 Local DNS에 전달
  6. Local DNS에서 naver.com을 관리하는 DNS 서버로 해당 도메인의 유무 확인
  7. 해당 도메인 확인시, IP 주소는 Local DNS에 전달함과 동시에 캐싱이 이루어진다.

---

웹 서버에 연결

• 웹 브라우저가 인터넷에서 서버를 찾으면 데이터 통신을 하기 위한 웹 서버와 TCP 연결이 이루어진다. 이때 연결 과정을 3-way handshake라고 하며, 클라이언트와 서버가 SYN(synchronize: 연결 요청) 및 ACK(acknowledgement: 승인) 메시지를 교환하여 연결을 설정하는 3단계에 걸쳐 연결이 이루어진다.

1. 클라이언트는 SYN 패킷을 서버로 보내 연결 가능 여부 확인
2. 서버는 SYN 패킷에 대한 응답으로 SYN/ACK 패킷을 사용하여 승인 응답
3. 서버로부터 SYN/ACK 패킷을 수산하고 SYNC ACK 패킷 전송하여 승인

---

호스팅 페이지를 가져오기 위한 요청 전송

• TCP 연결이 설정되면 브라우저가 필요한 페이지의 소스들을 가져오기 위해 HTTP 규격에 맞춘 요청을 전송한다. HTTP 요청에는 요청 라인, 헤더(또는 요청에 대한 메타데이터) 및 본문이 포함된다.
  1. 요청 라인
  • GET /blog/1620 HTTP/1.1
    • GET: 요청 메서드
    • /blog/1620: 요청한 리소스가 위한 경로
    • HTTP/1.1: 통신할 HTTP 버전
  1. 헤더
  • 헤더는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송하기 위해 사용된다.
  • 키-값의 페어 형태로 이루어져 있다.
  2. 본문
  • 해당 요청의 실제 메세지/내용이다.
  • 일반적으로 GET을 통한 요청은 없는 경우가 많으며, POST, PUT 또는 PATCH와 같은 리소스를 조작하는 요청의 경우 본문에는 생성하거나 업데이트할 클라이언트의 데이터(payload)가 포함된다.

---

서버의 응답

• 웹 서버는 요청을 받고 요청 라인, 헤더, 본문을 기반으로 요청 처리 방법을 결정한다. 그리고 요청에 대해 서버는 해당 요청에 맞는 콘텐츠를 가져오고 응답을 생성하여 클라이언트로 다시 전송한다. 응답에는 다음과 같은 내용들이 포함된다.
  1. 클라이언트에게 요청 상태를 알려주는 상태 라인
  2. 브라우저에 응답 처리 방법을 알려주는 응답 헤더
  3. 해당 경로에서 요청된 리소스 (HTML, CSS, Javascript, 이미지 파일과 같은 콘텐츠 또는 데이터)

---

페이지의 렌더링

• 웹 브라우저가 서버로부터 응답을 받으면 응답 헤더를 검사하여 리소스를 렌더링하는 방법에 대한 정보를 확인한다. Content-Type 헤더는 브라우저에 응답 본문에서 HTML 리소스를 수신했음을 알리며 브라우저는 HTML을 파싱하게 된다.
• 추가로 HTML 파싱 과정에서 Javascript, CSS, 이미지 리소스를 삽입하는 구문을 만나게 되면 해당하는 파일을 fetch 후 파싱이 되며 브라우저 렌더링 과정에 의해 원하는 콘텐츠의 렌더링이 이루어진다.

---

Reference

• 웹 브라우저에 URL을 입력하면 어떤 일이 생기나요?
• Three-Way Handshake
• 브라우저에 url을 입력하면 어떤일이 벌어질까?
• DNS 기본 동작 설명
• HTTP 구조 - 헤더와 본문