주소창에 URL을 입력하면 무슨 일이 일어날까?

지난 포스팅에서 requestAnimationFrame에 대해 설명하면서 브라우저 렌더링과정에 대해서도 간단하게 알아보았는데, 브라우저의 렌더링 엔진이 파싱하는 html과 css 파일등의 리소스들은 어디서, 어떤 방식으로 어떤 순서로 오게되는 걸까라는 궁금증을 가지고 이번 포스팅을 작성하게 되었다. 네트워크와 관련된 지식과 함께 주소창에 URL을 입력하면 무슨 일이 일어나는지에 대해 알아보도록 하자.

 

1. IP 주소 얻어오기

IP 주소

우리가 살고있는 집에 각각 주소가 있듯이 인터넷 서버도 인터넷 주소가 존재하는데, 인터넷 주소는 IP주소 또는 도메인 이름으로 구분한다. 이 때, IP주소란 네트워크 환경에서 컴퓨터 간의 통신을 위해 각 컴퓨터에 부여되는 네트워크 상 주소를 의미하고 IP주소는 223.130.195.200과 같이 네 개의 10진수로 구성된다. 

 

여기서 각 10진수는 8자리의 2진수로 이루어져있고, 따라서 총 32비트로 구성된다. 위에서 예시로 든 IP주소 223.130.195.200은 다음 그림과 같이 32비트로 표현할 수 있다.

2진수로 변환한 IP주소

또한 IP 주소는 네트워크 주소와 호스트 주소로 나뉘어지는데 네트워크 주소는 라우터를 거치지 않고 내부적으로 통신이 가능한 영역 즉, 쉽게 말해서 각 컴퓨터가 모여있는 하나의 네트워크 집합이라고 할 수 있다. 호스트 주소는 해당 네트워크에 속한 컴퓨터에게 부여하는 고유의 번호다. 따라서 하나의 네트워크에 포함된 컴퓨터는 같은 네트워크 주소를 가지지만 각각 다른 호스트 주소를 갖기 때문에 결과적으로는 고유한 IP주소를 가진다.

클래스

그렇다면 IPv4 기준 32비트 IP주소에서 어디까지가 네트워크 주소이고 어디까지가 호스트 주소인지는 A, B, C, D, E 다섯 가지 클래스로 구분된다. 이 중 A, B, C 클래스가 주로 사용된다.

클래스별 주소 범위

위의 그림에서 정리해놓은 것을 보자.

클래스 A는 처음 8개 비트가 네트워크 주소, 나머지 24개 비트가 호스트 주소이며 첫 번째 비트가 '0'이다.

클래스 B는 처음 16개 비트가 네트워크 주소, 나머지 16개 비트가 호스트 주소이며 첫 번째 비트가 '10'이다.

클래스 C는 처음 24개 비트가 네트워크 주소, 나머지 8개 비트가 호스트 주소이며 첫 번째 비트가 '110'이다.

 

따라서 각 클래스로 나타낼 수 있는 주소의 범위는 위와 같이 나타낼 수 있다.

 

DNS

위에서 IP 주소와 클래스에 따른 IP 주소의 범위에 대해서 알아보았다. 그런데 일반적으로 URL에 주소를 입력할 때 우리는 IP주소 대신 도메인 이름을 입력한다. 예를 들어 네이버 웹사이트를 방문하기 위해서 'www.naver.com' 을 입력하는 것처럼 말이다. 따라서 우리는 기억하기 쉬운 이름으로 특정 서버의 IP 주소를 얻고 있었던 것이고, 도메인 이름을 IP 주소로 변환하거나 IP 주소를 도메인 이름으로 변환하는데 사용되는 시스템인 DNS를 통해 IP 주소를 얻게된다.

 

DNS 과정

가장 먼저 도메인 이름을 입력하는 단계에서 DNS 클라이언트가 시작되고, 웹페이지에 엑세스 하려고 할 때 DNS 클라이언트는 로컬 DNS 캐시를 확인한다. 이전에 방문한 웹사이트의 도메인 이름과 해당 도메인의 IP 주소가 저장되어있는 경우 추가적인 DNS 조회없이 바로 IP 주소를 얻는다. 하지만 로컬 DNS 캐시에 도메인 이름이 없거나 만료된 경우 ISP(인터넷 제공업체 ex. SKT, KT, LG)에서 제공하는 로컬 DNS 서버로 DNS 조회 요청을 보내고 DNS 서버가 재귀적인 질의를 통해 최종적인 IP 주소를 얻는다.

 

DNS 계층구조

재귀적인 DNS 조회는 다음 DNS 계층구조를 따른다. 따라서 예시로 'www.amazon.com'의 IP를 찾아가는 과정을 설명하자면 다음과 같다.

 

1. 로컬 DNS 서버가 루트 DNS 서버로 질의하여 TLD DNS 서버의 주소를 찾는다.

2. 로컬 DNS 서버가 TLD DNS 서버로 질의하여 도메인 이름에 해당하는 DNS 서버 주소를 찾는다.

3. 로컬 DNS 서버가 도메인 이름에 해당하는 DNS 서버로 질의하여 최종적으로 'www.amazon.com'의 IP 주소를 얻는다.

 

2. 브라우저와 IP 주소에 해당하는 서버 간의 TCP 연결

IP 주소를 정상적으로 받아왔기 때문에 IP 주소에 해당하는 서버와 http 통신을 하기위해서는 데이터를 전송하기 전에 정확한 전송 보장을 위해 사전에 연결을 수립하는 과정인 TCP 연결이 필요하다. 일반적으로 인터넷에 연결된 웹 브라우저 요청 패킷은 TCP/IP 프로토콜을 사용하기 때문에 TCP 연결 설정을 위해 클라이언트와 해당 서버 간에 3-way-handshake 과정이 이루어진다. HTTPS를 사용하는 경우 TLS handshake 과정이 추가로 수행된다.

3-way-handshake 과정

클라이언트는 서버에 접속을 요청하는 SYN 패킷을 보내고, SYN/ACK 응답을 기다리는 SYN_SENT 상태가 된다. 이후 서버는 SYN 요청을 받고 클라이언트에게 요청을 수락한다는 의미로 ACK와 함께 SYN 플래그가 설정된 패킷을 전송하고 클라이언트가 다시 ACK로 응답하기를 기다리며 SYN_RECIEVED 상태가 된다. 클라이언트는 서버에게 ACK를 보내고 서버의 상태는 ESTABLISHED 상태가 되어 연결이 성립된다.

 

위의 과정을 쉽게 풀어서 설명하면

 

Client: 서버야 내 말 잘 들리니?

Server: 응. 잘 들려, 너는 내 말 잘 들리니?

Client: 응. 나도 잘 들려, 이제 연결됐다.

 

위와 같이 표현할 수 있다.

 

3. 브라우저가 서버에 HTTP 요청(Request) 전송

TCP 연결이 설정되면 데이터 전송이 시작되고, 브라우저는 가장 먼저 페이지의 콘텐츠를 요청하기 위해 서버에 HTTP 요청을 전송한다. 아래 그림은 주소창에 'www.naver.com'을 입력한 후 네트워크 탭에서 Request Header을 확인한 그림이다.

Request Header

4. 서버가 요청을 처리하고 응답(Response) 반환

서버에는 웹 서버가 포함되어 있고 이 웹 서버는 브라우저로 부터 받은 요청을 request handler에 전달하여 특정한 포맷으로 작성된 response를 생성하여 반환한다. 서버의 response에는 요청 웹 페이지, 상태 코드, content-type, cache-control 등이 포함된다. 아래 그림은 위에서 살펴본 Request에 대한 Response이다.

Response Header

 

5. 브라우저가 콘텐츠 렌더링

위의 Response Header에서 Content-Type에서 알 수 있듯이 브라우저는 서버로 부터 HTML 리소스를 수신했음을 보여준다. 따라서 HTML을 받은 브라우저의 렌더링 엔진은 파싱을 진행하며 다른 CSS, Javascript, 이미지 리소스를 참조하고 콘텐츠를 설계된대로 렌더링 하기위해 추가적인 리소스를 서버로 부터 받아온다. 결과적으로 URL에 입력한 주소의 페이지가 브라우저에 나타나게 된다.

 

 

참고

https://aws.amazon.com/ko/blogs/korea/what-happens-when-you-type-a-url-into-your-browser/

웹 브라우저에 URL을 입력하면 어떤 일이 생기나요? | Amazon Web Services

https://j-ho.dev/cs-4/

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