크롬 브라우저에 URL을 입력하면?

요약

1. 브라우저 URL 해석
2. URL 파싱 - HSTS, DNS, ARP
3. HTTP 메시지를 통한 TCP socket 통신(Three-Way Handshake), ARP
4. HTTP 프로토콜 요청, HTTP 서버 응답
5. 웹 브라우저가 리소스 그림 - 브라우저 렌더링
6. TCP 연결 종료 (TCP Four-Way Handshake)

출처 : http://tcpschool.com/webbasic/works

 

크롬 브라우저에 url을 입력하면!

크롬에서 일어나는 일

1. Handling inputs : url 입력
   1. Browswer process 안에 UI thread가 text를 search query or URL 판단
      1. search query -> search engine으로 query를 보내 검색 준비
      2. URL -> network thread로 URL 값 전달 준비
2. Start Navigation : enter키 입력
   1. UI thread가 loading spinner를 탭 왼쪽에 그림
   2. Renderer process 찾기 시작
   3. UI thread가 HTTP 요청 메시지 생성
      1. URL 파싱: UI thread는 사용자가 입력한 URL을 파싱 하여 다음과 같은 정보를 추출합니다:
         1. 프로토콜(Protocol): URL에서 사용된 프로토콜을 추출합니다. 예를 들어, "http://" 또는 "https://"
         2. 호스트(Host): 도메인 이름 또는 IP 주소를 추출합니다. 웹 서버의 주소
         3. 포트(Port): URL에 포트 번호가 지정된 경우 해당 포트 번호를 추출합니다. 기본적으로 80(HTTP) 또는 443(HTTPS)을 사용합니다.
         4. 경로(Path): URL에서 리소스(파일 또는 페이지)의 경로를 추출합니다.
         5. 쿼리 문자열(Query String): URL에서 추가 매개변수와 데이터를 나타내는 쿼리 문자열을 추출합니다.
         6. 프래그먼트(Fragment): URL에서 프래그먼트 식별자(웹 페이지 내에서 특정 부분을 가리킬 때 사용)를 추출합니다.
      2. 프로토콜 확인: UI thread는 추출한 프로토콜을 확인하고 URL이 "http://" 또는 "https://"와 같은 웹 프로토콜을 사용하는지 확인합니다.
      3. 호스트 확인: 호스트 정보를 확인하고, DNS(Domain Name System) 조회를 통해 해당 호스트의 IP 주소를 얻습니다. DNS 조회는 네트워크 작업 중의 하나입니다.(network thread 사용)
      4. 포트 확인: URL에 명시된 포트 번호를 확인하고, 지정된 포트 번호가 없는 경우 기본 포트 번호를 사용합니다.
      5. 경로 및 쿼리 문자열 추출: URL에서 경로와 쿼리 문자열 정보를 추출합니다. 이 정보는 HTTP GET 요청 메시지에서 리소스 요청을 명시하는 데 사용됩니다.
      6. HTTP 요청 생성: 이러한 정보를 사용하여 UI 스레드에서 HTTP GET 요청 메시지를 생성합니다. 이 요청은 웹 서버로 해당 URL에서 특정 리소스를 가져오도록 요청하는 메시지입니다.
      7. HTTP 요청 전송: 생성된 HTTP GET 요청 메시지는 네트워크 스레드 또는 백그라운드 스레드로 전달하여 웹 서버로 전송됩니다.
   4. 생성된 HTTP 요청 메시지 network thread에 전달 (network call initiates) (UI thread -> Network thread)
      1. 웹 브라우저가 서버와의 TCP 연결
      2. 서버 응답 대기 - network thread는 서버로부터 응답을 대기
   5. 서버로부터 응답을 받으면
      1. 만약, HTTP 301 response 오면 UI thread로 redirect 전달 -> 다시 Start Navigation부터 시작
      2. 301 response가 아니라면 response body를 network thread로 전달 (Read response)
3. Read response : response body가 network thread로 들어올 때
   1. Network thread가 필요하면 response의 few bytes of stream을 읽음
   2. response header의 content-type으로 type확인
      1. type을 정확하게 확인하려 MIME(Multipurpose Internet Mail extensions) type sniffing
   3. content-type이
      1. HTML 형식 : Renderer process에게 파일 전달 준비후 SafeBrowsing, CORB 체크
      2. HTML 아닌, zip 이나 다른 형식 : Download manager에게 파일 전달 준비
   4. SafeBrowsing : domain & data가 known malicious site -> warning page 보여줌
   5. CORB(Cross Origin Read Blocking) : 민감한 cross-site data는 renderer process에게 전달하지 않음
4. Find Renderer process : Network thread가 확인이 끝난 후, 브라우저가 사이트 이동해야 하면
   1. Network thread가 data is ready라고 UI thread에게 전달
   2. 2-2에서 UI thread가 미리 찾아둔(혹은 시작한) Renderer process에게 data(html file)를 전달
5. Commit Navigation : data, Renderer process가 준비되면
   1. Browser process 안에 UI thread가 Renderer process에 IPC(Inter-process communication)를 보낸다.
   2. Renderer process가 HTML data를 계속 받을 수 있도록 data stream도 보낸다.
   3. Browser process가 Renderer process로부터 commit navigation 되었다는 confirmation을 들으면 Navigation은 끝나고 Document loading phase가 시작된다.
      1. 주소창 업데이트
      2. security indicator & site setting UI reflect newpage information
      3. session history for the tab updated (화면 그리기 전)
         1. forward/back button에 방금 방문한 사이트 추가
         2. 탭/윈도우 닫을 때 복구 기능(session history is sto
6. Initial load complete : navigation is committed
   1. Renderer process는 계속 loading resource, render page -> start rendering process
   2. Renderer process가 rendering 끝나면 browser process에 IPC back
      1. 모든 frame(render process)에서 onload event 발생 후 모든 resource 다 실행된 다음 IPC back
   3. UI thread는 loading spinner를 tab에서 지움
   4. *client side의 JavaScript가 추가적인 resource load 하거나 render new view 할 수 있음

참고 : 브라우저에 URL을 입력하면 어떤 과정이 진행될까?

DNS 조회

DNS(Domain Name Server) 서버는 할당된 도메인 영역에 대한 정보를 가지고 있는 서버로, 주로 도메인을 IP주소로 변환하는 역할을 합니다.

Start Navigation -> HTTP GET 메시지 생성 -> 호스트 확인 과정(2-3-3 )에서 DNS 조회를 통해 IP를 주소를 가져오게 됩니다.

DNS 조회가 시작되면 우선으로 브라우저는 네 개의 캐시를 확인합니다.

1. 브라우저 캐시: 브라우저는 이전에 방문한 웹 사이트의 DNS 레코드를 일정 기간 동안 저장합니다. 따라서 동일한 웹 사이트에 다시 액세스 할 때 해당 DNS 정보를 캐시에서 가져와 사용합니다. 이 정보는 브라우저의 로컬 DNS 캐시에 저장되며 크롬 브라우저의 경우 chrome://net-internals/#dns에서 확인할 수 있습니다.
2. 호스트 파일 (OS 캐싱): 호스트 파일은 운영 체제 수준에서 도메인 이름과 IP 주소 간의 매핑을 포함하며, 브라우저가 이 파일을 참조하여 도메인에 대한 로컬 매핑을 확인합니다.
3. 라우터 캐시: 라우터는 DNS 쿼리를 처리하고 이에 대한 기록을 캐싱할 수 있습니다. 따라서 브라우저는 로컬 라우터의 DNS 캐시를 확인하여 도메인에 대한 정보를 찾을 수 있습니다.
4. ISP 캐시: 브라우저가 이러한 캐시에서 DNS 정보를 찾을 수 없으면, ISP(Internet Service Provider, 인터넷 서비스 제공업체)의 DNS 서버를 참조합니다. ISP의 DNS 서버는 클라이언트의 DNS 쿼리를 처리하고, 원하는 도메인에 대한 IP 주소 정보를 검색하기 위해 다른 DNS 서버로 쿼리를 전달하는 재귀적인 쿼리 프로세스를 수행합니다.

캐시를 통한 이러한 단계적 검색 과정의 목적은 네트워크 트래픽을 줄이고 데이터 전송 시간을 개선하기 위함입니다.

캐시에 없을 경우, DNS 서버에 직접 요청합니다.

1. DNS 서버 위치 확인: 호스트는 DNS 서버의 IP 주소를 알아내어야 합니다. 이때 ARP (Address Resolution Protocol)는 IP 주소를 MAC 주소로 매핑하기 위해 사용됩니다.
2. DNS 서버가 동일 서브넷에 있는 경우: DNS 서버가 호스트와 동일한 서브넷에 있는 경우, 호스트는 해당 서브넷 내에서 ARP를 실행하여 DNS 서버의 MAC 주소를 알아냅니다.
3. DNS 서버가 다른 서브넷에 있는 경우: DNS 서버가 다른 서브넷에 있는 경우, 호스트는 게이트웨이(라우터)의 MAC 주소를 찾기 위해 기본 게이트웨이 IP 주소에 대한 ARP 프로세스를 실행합니다. 그리고 이 게이트웨이를 통해 다른 서브넷으로 데이터를 라우팅 하여 DNS 서버에 도달합니다.

ARP(Address Resolution Protocol) 프로세스

ARP는 IP 주소와 MAC 주소 간의 매핑을 수행하는 프로토콜로, 다음과 같은 순서로 동작합니다:

1. ARP 캐시 확인:
   • ARP 프로세스가 시작되면, 먼저 ARP 캐시를 검사합니다. ARP 캐시는 이전에 통신한 장치의 IP 주소와 해당 장치의 MAC 주소를 저장합니다.
   • 목적지 IP 주소가 ARP 캐시에 있다면, 해당 MAC 주소를 사용하여 통신을 진행합니다.
2. ARP 캐시에 항목이 없는 경우:
   • 목적지 IP 주소가 로컬 라우트 테이블의 서브넷에 속하는지 확인합니다.
   • 목적지 IP 주소가 로컬 서브넷에 속한다면, 해당 서브넷에 속하는 네트워크 인터페이스를 선택합니다.
   • 선택된 네트워크 인터페이스의 MAC 주소를 검색하여 목적지 MAC 주소로 사용합니다.
3. ARP 요청 보내기:
   • ARP 요청은 네트워크 스택 라이브러리에 의해 전송됩니다.
   • ARP 요청 메시지에는 보내는 호스트의 MAC 주소 및 IP 주소, 목적지 IP 주소가 포함됩니다.
   • 이 ARP 요청은 OSI 모델의 2 계층(링크 계층)을 통해 브로드캐스트로 전송됩니다.
4. ARP 응답:
   • ARP 요청을 수신한 호스트 중에서 목적지 IP 주소와 일치하는 호스트가 ARP 응답을 보냅니다.
   • ARP 응답에는 보내는 호스트의 MAC 주소와 IP 주소가 포함됩니다.
   • 이 ARP 응답을 받은 호스트는 목적지 MAC 주소를 알게 됩니다.

DNS 조회 프로세스

DNS 조회 프로세스는 주어진 도메인 이름을 해당 도메인의 IP 주소로 해석하는 과정입니다. 아래는 DNS 조회 프로세스의 단계를 설명합니다:

1. ARP 프로세스를 통해 DNS 서버의 IP 주소를 알아냅니다.
2. DNS 서버와 통신:
   • DNS 서버에게 DNS 조회 요청을 보내기 위해 DNS 서버의 IP 주소를 사용합니다.
   • 클라이언트는 DNS 서버에게 DNS 조회를 요청하고, 해당 도메인의 IP 주소를 얻기 위한 DNS 프로세스를 시작합니다.
3. 로컬/ISP DNS 서버:
   • 로컬 또는 ISP의 DNS 서버가 해당 정보를 가지고 있지 않다면, 재귀적인 DNS 탐색 프로세스가 시작됩니다.
   • DNS 서버는 하위 DNS 서버로 질의를 전달하고, 도메인 이름의 IP 주소를 찾을 때까지 계속해서 상위 DNS 서버로 질의를 전달합니다.
   • DNS 서버 리스트를 타고 올라가서 최종적으로 도메인 이름과 해당 IP 주소를 반환합니다.

이렇게 ARP와 DNS 조회 프로세스는 네트워크 통신과 DNS 조회를 위해 함께 작동하여 IP 주소 및 MAC 주소를 찾고 도메인 이름을 IP 주소로 해석합니다.

ISP의 DNS 서버 예시

ISP의 DNS 서버는 일반적으로 사용자의 인터넷 서비스 제공업체 (ISP)에 의해 운영되며 제공됩니다. 이 서버는 사용자가 도메인 이름을 IP 주소로 해석할 수 있도록 DNS 서비스를 제공합니다. 일반적으로 사용자의 컴퓨터 또는 라우터 설정에서 DNS 서버를 구성하거나 변경할 수 있으며, 이를 통해 사용자는 ISP의 DNS 서버를 사용할 수도 있고, Google Public DNS, OpenDNS, 또는 다른 공용 DNS 서버를 사용할 수도 있습니다. 사용자의 선택에 따라 DNS 서버가 다를 수 있으며, DNS 서버 설정을 통해 변경할 수 있습니다.

도메인 아키텍처는 다음과 같습니다.

출처: Domain Name System

각각 레벨은 DNS 룩업 프로세스를 필요로 하는 고유 서버 이름을 포함합니다. 그림으로 예를 들면, DNS Recursor는 루트 서버 이름과 연결된다. 그다음 .com 도메인 서버로 리다이렉트 시킨다. 또, .com 서버는 microsoft.com 서버로 리다이렉트 시키고, microsoft.com은 download.microsoft.com과 매칭되는 IP를 찾아 DNS Recursor에 반환한다.

로컬 DNS 서버 -> Root DNS 서버 -> TLD DNS 서버 -> SLD DNS 서버 -> TLD DNS 서버 순으로 차례대로 물어보며 답을 찾는 과정을 Recursive Query(재귀적 쿼리)라고 부릅니다.

이러한 요청은 작은 데이터(요청 내용과 목적 IP 주소) 패킷을 사용하도록 합니다. 이 패킷은 올바른 DNS 서버에 도달하기 전에 여러 네트워크를 이동합니다. 패킷은 목적지에 도달하는 가장 빠른 찾는 방법을 알아내기 위해 라우팅 테이블을 사용합니다. 만약 가는 도중 패킷이 손실되었다면, 요청한 URL의 DNS를 찾지 못했다는 것입니다.

TCP 통해 socket 통신

Start Navigation -> 생성된 HTTP 요청 메시지 network thread에 전달 (2-4)에서 HTTP이기 때문에 TCP/IP 통신이 이뤄집니다.

인터넷에 연결된 웹 브라우저 요청 패킷은 일반적으로 TCP/IP(Transmission Control Protocol/Internet Protocol)라고 하는 전송 제어 프로토콜을 사용하여 라우터 장비, 인터넷 서비스 제공회사 교환기를 통해 이동되어, 통신 회사 간 경로인 라우팅 테이블을 따라서 연결할 IP 주소가 있는 웹 서버를 찾습니다.

TCP 연결 설정 (TCP Three-Way Handshake)

1. 클라이언트가 목적지 서버의 IP 주소를 가지고 있으면, TCP 연결을 설정하기 위한 Three-Way Handshake 프로세스를 시작합니다.
2. 클라이언트는 초기 순서 번호(ISN)를 선택하고, SYN(Synchronize) 플래그가 설정된 TCP 패킷을 목적지 서버로 보냅니다.
3. 목적지 서버는 클라이언트의 SYN 패킷을 수신하고, 자체 ISN을 선택하고, SYN 및 ACK(Acknowledgment) 플래그를 설정하여 응답합니다.
4. 클라이언트는 목적지 서버로부터의 응답을 받으면, ACK와 함께 목적지 서버의 ISN + 1 값을 확인 번호로 사용하는 패킷을 보내어 연결을 확립합니다.

만약 통신 프로토콜이 https라면 https(TLS) 핸드쉐이크도 TCP 핸드쉐이크에 이어서 진행합니다.

https://www.cloudflare.com/ko-kr/learning/ssl/transport-layer-security-tls/

HTTP 프로토콜¶

위에서 만든 패킷과 암호화 과정을 토대로 실제로 HTTP 전송을 시작한다.

1. TCP 연결이 설정되면, 클라이언트와 서버는 데이터를 주고받을 수 있습니다. 클라이언트는 HTTP 요청을 생성하여 서버에 보내며, 서버는 HTTP 응답을 생성하여 클라이언트에 반환합니다.
2. 이 데이터는 TCP 세그먼트로 분할되어 전송되고, 각 세그먼트에는 시퀀스 번호가 부여됩니다.

브라우저 렌더링¶

데이터를 받아 브라우저에서 렌더링 하는 과정이 발생합니다. 이 글에서는 브라우저의 렌더링 과정은 생략하도록 하겠습니다.

TCP 연결 종료 (TCP Four-Way Handshake)

1. 데이터 통신 후, 클라이언트 또는 서버가 연결을 종료하려고 할 때 TCP Four-Way Handshake 프로세스를 사용합니다.
2. 클라이언트 또는 서버가 연결을 종료하려고 할 때 FIN(Finish) 패킷을 보내고, 상대방은 ACK로 응답하여 연결을 종료합니다.
3. 이 과정을 통해 TCP 연결은 안전하게 설정되고 통신이 이루어지며, 연결 종료 후에는 리소스가 정리됩니다.

HTTP 1.1부터 도입된 keep-alive 때문에 요청이 끝났더라도 바로 커넥션이 종료되지 않는 게 일반적입니다. keep-alive timeout 설정이 지나고 난 후에 서버-클라이언트 간 접속이 끊어지고 소켓이 만료됩니다.