본문으로 건너뛰기

주소창에 google.com을 치면 일어나는 일

이 질문은 컴퓨터 네트워크에서 데이터가 어떻게 전달되는지와 브라우저에서 웹 페이지를 어떻게 렌더링하는지에 대한 모든 것을 포함한다.

브라우저에서 google.com을 검색하면 구글 웹 서버의 80번 포트로 HTTP Request를 보내는 것이다. 요청을 웹 서버로 전달하기 위해서는 패킷을 만들어야한다. 패킷에는 TCP/IP 4계층에서 각 계층에 필요한 정보들이 담겨야 한다.

Application Layer에서는 HTTP 프로토콜, Transport Layer에서는 TCP, Internet Layer에서는 IP, Network Access Layer에서는 Ethernet 프로토콜을 사용한다.

웹 서버로부터 HTML, CSS, JavaScript를 받아오면 이후엔 브라우저의 Critical Rendering Path를 따른다.

Handling Inputs


사용자가 주소창에 텍스트를 입력하면 브라우저 프로세스 안에 UI 스레드가 텍스트가 search query인지 URL인지를 판단한다.

  • search query: 검색 엔진에게 전달
  • URL: network thread로 URL 값 전달 준비

만약 검색어를 입력했다면 사용자가 선택한 검색 엔진의 URL과 조합하여 새로운 URL 형태로 변환하게 된다.

Start Navigation

유저가 엔터를 입력하면 UI 스레드가 컨텐츠를 가져오기 위한 네트워크 요청을 시작한다.(Network thread 에게 URL 전달)


위 그림과 같이 로딩 스피너가 나타나고, 네트워크 스레드가 DNS lookup과 같은 적절한 프로토콜을 사용하여 요청에 대하여 TLS(Transfort Layer Security) connection을 만든다. 만약 네트워크 스레드로 HTTP 301 response가 오면 UI 스레드와 상호작용하여 새로운 URL로 redirect한다.

DNS 서버 주소는 컴퓨터에 저장되어 있다. DNS도 Application Layer의 프로토콜이다. (53번 포트를 사용) Domain이 담긴 Query를 DNS 서버에 보내면 DNS 서버는 해당 Domain의 IP 주소를 반환한다.

nslookup google.com을 입력하면 구글의 IP 주소를 얻어올 수 있고 이 주소를 입력해도 똑같은 구글 창이 뜬다.

Read response


응답 body가 들어오면 필요할 경우에 네트워크 스레드는 몇몇 바이트를 읽는다. 응답의 Content-Type 헤더는 데이터 유형을 알려줘야하지만 누락되거나 잘못되었을 수 있으므로 MIME Type 확인이 여기서 이루어진다.

  • header의 Content-Type과 실제 응답받은 데이터 형식이 다를 수 있기에 MIME 스니핑을 실행하여 데이터의 실제 형식을 알아낸다.
  • 응답이 HTML 파일이라면, 렌더러 프로세스에게 전달하고, 렌더러 프로세스가 다룰 수 없는 데이터 형식(zip파일 또는 다른 타입의 파일) 이라면 다운로드 매니저에게 데이터를 전달한다.

이 과정에서 SafeBrowsing이 일어난다. 만약 도메인과 응답 데이터가 악의적인 사이트라고 의심되는 경우에는 네트워크 스레드는 경고창을 띄운다. 추가적으로 민감한 cross-site 데이터를 차단하기위한 Cross Origin Read Blocking(CORB) 체크도 이루어진다.

Find a renderer processor


체크가 모두 끝나면 네트워크 스레드는 UI 스레드에게 데이터가 준비되었다고 알린다. UI 스레드는 렌더링을 수행할 렌더러 프로세스를 찾는다. 네트워크 요청이 응답을 받는데 수백 밀리초가 걸릴 수 있으므로 이 프로세스 속도를 높이기 위한 최적화가 적용된다. 2단계에서 UI 스레드가 네트워크 스레드에 URL 요청을 보낼 때 탐색할 사이트를 이미 알고 있다. UI 스레드는 네트워크 요청과 병렬로 렌더러 프로세스를 사전에 찾거나 시작하려고 시도한다. 이렇게 하면 모든 것이 예상대로 진행되고 렌더러 프로세스는 네트워크 스레드가 데이터를 수신했을 때 이미 대기 위치에 있다. 탐색이 cross-site로 리다이렉션되는 경우 이 대기 프로세스가 사용되지 않을 수 있으며, 이 경우 다른 프로세스가 필요할 수 있다.

Commit Navigation

데이터와 렌더러 프로세스가 준비되면 IPC를 통해 브라우저 프로세스에서 렌더러 프로세스로 데이터를 전달한다. 렌더러 프로세스는 HTML 데이터를 받게되고 네비게이션은 끝나고 문서의 로딩이 이루어진다.


렌더러 프로세스가 HTML 데이터를 계속 수신할 수 있도록 브라우저 프로세스는 데이터 스트림을 전달합니다. 렌더러 프로세스에서 내비게이션이 실행되었다는 것을 브라우저 프로세스가 확인하고 나면 내비게이션이 완료되고 문서 로딩 단계가 시작됩니다.


브라우저가 URL에 적힌 값을 파싱해서 HTTP Request Message를 만들고, OS에 전송을 요청한다. 이 때, Domain으로 요청을 보낼 수 없기 때문에 DNS Lookup을 수행한다.

DNS Lookup 과정은 크롬의 경우 브라우저 -> hosts 파일 -> DNS cache의 순서로 도메인에 매칭되는 ip를 찾는다. 일반적으로 설명하는 DNS Lookup은 루트 도메인 서버에서부터 서브 도메인 서버순으로 찾게된다.

HTTP 요청 메시지는 TCP/IP 프로토콜을 사용하여 서버로 전송된다.

이 요청은 프로토콜 스택이라는 OS에 내장된 네트워크 제어용 소프트웨어에 의해 패킷에 담기고 패킷에 제어정보를 덧붙여 LAN 어댑터에 전송하고, LAN 어댑터는 이를 전기신호로 변환시켜 송출한다.

패킷은 스위칭 허브 등을 경유하여 인터넷 접속용 라우터에서 ISP로 전달되고 인터넷으로 이동한다. 액세스 회선에 의해 통신사용 라우터로 운반되고 인터넷의 핵심부로 전달된다. 고속 라우터들 사이로 목적지까지 패킷이 흘러들어가게 된다. 핵심부를 통과한 패킷은 목적지의 LAN에 도착하고, 방화벽이 패킷을 검사한 후 캐시 서버로 보내어 웹 서버에 갈 필요가 있는지 검사한다.

웹 서버에 도착한 패킷은 프로토콜 스택이 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘긴다. 애플리케이션은 요청에 대한 응답 데이터를 작성하여 클라이언트로 회송하고, 이는 전달된 방식 그대로 전송된다.

요약

브라우저는 HTTP 프로토콜을 사용하여 요청 메시지를 생성하고 HTTP 요청 메시지는 TCP/IP 프로토콜을 사용하여 서버로 전송된다. 서버는 response 메시지를 생성하여 다시 브라우저에게 데이터를 전송한다. 브라우저는 response를 받아 파싱하여 화면에 렌더링한다.

Reference