이 글은 Maneesha Wijesinghe님의 글을 번역한 글 입니다.

maps.google.com을 쳤을때 일어나는 일

만약 당신이 기술 분야에 종사한다면 나는 당신에게 누군가가 한번은 당신에게 이 질문을 했을거라고 확신합니다.

당신이 엔지니어든 개발자든 마케터든 또는 심지어 판매직일지라도, 우리가 사용하는 브라우저 뒤편에 무엇이 일어나고 있는지에 대해서 그리고 어떻게 정보가 인터넷을 통해 우리의 컴퓨터로 옮겨져 오는지에 대해서 기본적으로 이해하고 있는 편이 좋다고 생각합니다.

회사로부터 당신이 예약한 식당까지 가는데 정확히 시간이 얼마나 걸리는지 확인하기 위해 maps.google.com에 접근한다고 가정해보겠습니다.

1. 가장 먼저 당신은 브라우저의 주소창에 maps.google.com을 타이핑 합니다.

2. 브라우저는 캐시에서 DNS 레코드를 확인하여 maps.google.com과 대응되는 IP 주소를 찾습니다.

DNS(Domain Name System)란 website(URL)과 연결된 특정 IP 주소를 유지관리하는 데이터베이스입니다.

모든 인터넷상의 단일 URL들은 고유 IP 주소가 존재합니다.

IP 주소는 우리가 접속하기 위해 요청을 보내는 웹사이트의 서버를 호스팅하는 컴퓨터에 속하게 됩니다.

예를들어 www.google.com은 209.85.227.104라는 IP 주소를 갖고 있습니다.

그래서 만약 당신이 원한다면 당신은 당신의 브라우저의 주소창에 http://209.85.227.104를 타이핑함으로써 www.google.com에 접속할 수 있습니다.

DNS는 마치 전화번호부와 같습니다.

전화번호부는 이름과 이름에 해당하는 전화번호가 쌍을 이루고 있고 쌍들의 목록을 갖고 있습니다.

마찬가지로 DNS는 URL과 IP주소가 쌍으로 이루어진 목록 입니다.

DNS의 주된 목적은 인간 친화적인 탐색입니다.

당신은 당신의 브라우저에서 올바른 IP주소를 타이핑하여 웹사이트에 쉽게 접속할 수 있습니다.

하지만 우리가 주기적으로 접속하는 모든 사이트의 숫자로 이루어진 IP 주소를 기억하는 것이 가능할까요?

그렇기 때문에 URL을 사용해서 웹사이트의 이름을 기억하고 DNS는 올바른 IP 주소를 매핑하기위한 작업을 수행하게 하는 편이 우리가 원하는 웹사이트에 접속하기에 더욱 쉽습니다.

그럼 지금부터 브라우저가 캐시에서 DNS 레코드를 확인하여 maps.google.com과 대응하는 IP를 찾아가는 과정을 알아보도록 하겠습니다.

먼저 DNS 레코드를 찾기 위해 브라우저는 4개의 캐시를 확인합니다.

1. 브라우저 캐시를 체크합니다. 브라우저는 당신이 이전에 이미 방문한 웹사이트에 대해 정해진 기간동안 DNS 레코드의 저장소를 유지관리합니다. 그래서 브라우저 캐시는 DNS 쿼리를 실행하기 위한 첫번째 장소입니다.

2. 브라우저는 OS 캐시를 체크합니다. 만약 브라우저 캐시에 없다면 브라우저는 사용자의 컴퓨터 OS에 대한 시스템 콜을 만들어 레코드를 가져올 것입니다. 왜냐하면 OS 또한 DNS의 캐시를 관리하기 때문이죠.

3. 라우터 캐시를 체크합니다. 만약 당신의 컴퓨터에도 없다면 브라우저는 DNS 레코드의 캐시를 관리하는 라우터와 상호작용할 것입니다.

4. ISP 캐시를 체크합니다. 만약 위에서 언급한 모든 과정이 실패한다면, 브라우저는 ISP로 이동할 것입니다. 당신의 ISP는 DNS 서버를 관리하고 있습니다. DNS 서버는 DNS 레코드의 캐시를 포함하고 있으며 브라우저는 당신의 URL 요청을 찾기 위한 마지막 희망을 품고 확인할 것입니다.

당신은 왜 이렇게 많은 단계에서 이렇게 많은 캐시들이 관리되어지고 있는지에 대해 궁금할지도 모릅니다.

비록 우리의 정보가 어딘가에 캐시되어있는 것은 우리의 개인 정보와 직결되기 때문에 우리의 기분을 썩 좋지 않게 할지도 모르지만 캐시는 네트워크 트래픽을 규제하고 데이터 전송 속도를 증가시키는데 필수적입니다.

3. 만약 요청된 URL이 캐시되어있지 않다면 ISP의 DNS 서버는 maps.google.com을 호스트하는 서버의 IP주소를 찾기 위해 DNS 쿼리를 시작합니다.

앞서 언급했듯이 우리의 컴퓨터는 maps.google.com을 호스트 하는 서버와 연결하기 위해 maps.google.com의 IP 주소를 알아야 합니다.

DNS 쿼리의 목적은 웹사이트(URL)에 해당하는 올바른 IP 주소를 찾을때 까지 인터넷 상의 다수의 DNS 서버를 탐색하는 것입니다.

이러한 탐색은 우리가 필요로 하는 IP 주소를 찾거나 찾을 수 없다는 에러 응답을 반환할때 까지 탐색이 DNS 서버로부터 DNS서버까지 반복해서 계속될 것이기 때문에 재귀 탐색이라고 불려집니다.

이 상황에서 우리는 ISP의 DNS 서버를 DNS recursor라고 부르도록 하겠습니다.

DNS recursor의 책임은 원하는 도메인 이름의 적절한 IP 주소를 인터넷 상에서 다른 DNS 서버에게 물어가며 찾는 것입니다.

다른 DNS 서버는 name server라고 불려지는데 그들이 웹사이트 도메인 이름의 도메인 아키텍쳐를 기반으로 DNS 탐색을 수행하기 때문입니다.

당신을 더욱 더 혼란스럽게 하지 않기 위해 저는 도메인 아키텍처를 설명하기 위한 아래의 다이어그램을 사용하려고 합니다.

오늘날 만나는 대다수 웹사이트 URL은 Third-level domain, second-level domian, top-level domain을 포함하고 있습니다.

이러한 각 레벨에서는 자체 name server를 포함하고 있으며 DNS 조회 프로세스 중 쿼리되어집니다.

maps.google.com을 위해 첫번째로 DNS recursor는 root name server에 접촉합니다.

root name server는 .com 도메인 이름을 redirect 합니다.

깨알 상식 redirect란?

re(다시) + direct(지시하다)라는 의미로 브라우저에게 다른 길로 가라고 알려주는 것을 의미한다.

이게 어디서 쓰이는고 하면 일반적으로 게시판에 있는 글을 읽을 때 로그인이 된 유저만 글을 읽을 수 있는 사이트가 있다고 하자.

만약 로그인이 되지 않은 유저가 해당 게시글을 눌러서 접근하려고 할 때 서버는 클라이언트가 로그인이 되지 않았다면 로그인 페이지로 리다이렉트하게 되는 것이다.

이러한 경우에 주로 리다이렉트가 사용된다.

maps.google.com을 찾기 위해 먼저 DNS recursor는 root name server와 접촉할 것입니다.

root name server는 DNS recursor에게 .com 도메인 name server를 리다이렉트합니다.

.com name server는 google.com name server를 리다이렉트합니다.

google.com name server는 DNS 레코드에서 maps.google.com와 매칭되는 IP 주소를 찾고, 그 IP 주소는 당신의 DNS recursor로 반환될 것입니다.

그리고 마침내 DNS recursor는 당신의 브라우저로 maps.google.com과 매칭되는 IP 주소를 보내게 됩니다.

이러한 요청은 요청의 컨텐츠나 대상 IP주소 정보(DNS recursor의 IP 주소)를 포함한 작은 데이터 패킷을 사용해서 전송됩니다.

이러한 패킷 레벨은 그것이 적절한 DNS 서버에 닫기 전까지 클라이언트와 서버 사이에 있는 다수의 네트워크 장비를 통과합니다.

이 장비는 패킷이 목적지까지 도달하는데 가능한 가장 빠른 길이 어디인지를 알아내기 위해 라우팅 테이블을 사용합니다.

만약 이러한 패킷이 유실되면 당신은 요청 실패 에러를 받게 될 것입니다.

실패 요청을 받지 않는다면 올바른 DNS 서버에 연결하여 IP 주소를 얻어온 다음 당신의 브라우저로 돌아오게 됩니다.

4. 브라우저는 서버와 TCP 연결을 시작합니다.

한번 브라우저가 올바른 IP 주소를 받고 나서 정보를 전송하기 위해 IP 주소와 매칭 되는 서버와 커넥션을 만들 것입니다.

브라우저는 이같은 커넥션을 만들기 위한 인터넷 프로토콜을 사용합니다.

사용되어질 수 있는 몇가지 다른 인터넷 프로토콜이 있지만 TCP는 많은 유형의 HTTP 요청에 사용되어지는 가장 일반적인 프로토콜입니다.

당신의 컴퓨터(클라이언트)와 서버 사이에 데이터 패킷을 옮기기 위해 TCP 연결을 설정하는 것은 대단히 중요합니다.

이 연결은 TCP/IP three-way handshake라고 불려지는 과정을 사용해서 수립되어집니다.

이것은 클라이언트와 서버가 연결을 수립하기 위해 SYN(synchronize)와 ACK(acknowledge) 메세지를 교환하며 세 단계 과정을 거칩니다.

1. 클라이언트는 인터넷상에서 SYN 패킷을 서버에게 보내서 새로운 연결이 열려있는지 물어봅니다.

2. 서버가 수용할 수 있는 새로운 포트가 열려 있고 새로운 연결을 시작할 수 있다면 SYN/ACK 패킷을 사용해서 SYN 패킷의 ACKnowledgement를 응답합니다.

3. 클라이언트는 서버로부터 SYN/ACK 패킷을 받을 것이고 ACK 패킷을 보냄으로써 응답합니다.

그리고 나서 TCP 연결은 데이터 전송을 위해 수립되어 집니다.

5. 브라우저는 웹서버에 HTTP 요청을 보냅니다.

일단 TCP 연결이 수립되어지면, 데이터 전송을 시작할 시간입니다! (야호)

브라우저는 maps.google.com 웹 페이지를 요청하는 GET 요청을 보낼 것입니다.

만약 당신이 로그인 또는 게시글 작성 페이지에 들어간 경우라면 이것은 POST 요청이 될 것입니다.

이 요청은 또한 브라우저 identification, 수락할 요청 유형 및 추가적인 요청에 대해 TCP 연결을 유지하도록 요청하는 connection header와 같은 추가적인 정보를 포함하게 됩니다.

또한 브라우저가 이 도메인에 대한 저장소에서 갖고 있는 쿠키로 부터 얻은 정보를 전달할 것입니다. ( 이 부분은 해석이 깔끔하게 안되서 아래에 원글을 첨부했습니다. )

It will also pass information taken from cookies the browser has in store for this domain.

간단한 GET request (Header를 강조해놓았음) :

(당신이 이 뒤편에 무엇이 일어나는지 궁금하다면, 당신은 HTTP Request를 보기 위해(take a look at) Firebug같은 툴을 사용할 수 있습니다. 우리가 알지 못한채 클라이언트와 서버 사이에 지나가는 정보들을 보는 것은 꽤나 재밌을 거에요.)

지나가던 길고양이의 조언 - Firebug란? -

역자 말 : take a look을 보자 떠오른 그 고양이

지나가던 고양이 : 저는 Firebug를 처음봐서 어떤 툴인지 공부하고자 이 내용을 넣었습니다.

제가 아는 패킷 분석용 도구는 Wireshark인데 여기서는 Firebug라는 것을 사용했더라구요.

Wireshark는 Firebug보다 네트워크 상의 패킷의 내용을 확인하는 것에 있어 전문적인 툴입니다.

그에 비해 Firebug는 HTML,CSS,DOM,자바스크립트의 실시간 디버깅, 편집, 모니터링을 간편하게 해주는 도구죠. 즉, 전문 패킷 분석용 도구는 아니라는 뜻입니다.

원래 Firebug는 웹 개발 시 디버깅이나 모니터링 용도로 사용되는 툴인데, HTTP 네트워크 상태 모니터링과 HTTP 헤더를 볼 수 있는 기능 또한 제공하고 있습니다.

예제가 단순히 HTTP Request,Response에 대한 내용을 보는 정도였기 때문에 Wireshark 보다는 Firebug를 사용하지 않았나 싶습니다.

6. 서버는 요청을 처리하고 응답을 다시 보냅니다.

서버는 브라우저로 부터 요청을 받는 요청을 수신하여 요청 처리기로 전달하여 응답을 읽고 생성하는 웹서버(아파치 같은)를 포함합니다.

요청 처리기는 프로그램(ASP.NET,PHP,Ruby 등)입니다.

요청,헤더 및 쿠키를 읽어 요청되는 내용을 확인하고 필요한 경우 서버의 정보를 업데이트 합니다.

그리고 나서 특정한 포맷(JSON,XML,HTML)으로 응답을 조합합니다.

7. 서버는 HTTP 응답을 보냅니다.

서버 응답은 당신이 요청한 웹페이지 뿐만 아니라status code와 compression type(Content-Encoding)과 페이지 캐시 방법(Cache-Control) 그밖에 설정된 쿠키나 개인적인 정보 등을 포함합니다.

예시 HTTP 서버 응답:

당신이 위의 응답을 본다면 첫째 줄 상태코드를 보도록 합시다.

이것은 우리에게 응답의 상태를 말하는 것으로 꽤나 중요합니다.

숫자 코드를 사용한 자세한 응답에는 5가지 유형이 있습니다.

• 1xx는 정보 메세지를 나타낸다.

• 2xx는 성공을 나타낸다.

• 3xx는 다른 URL로 클라이언트를 리다이렉션한다.

• 4xx는 클라이언트 측에서 에러가 났음을 나타낸다.

• 5xx는 서버측에서 에러가 났음을 나타낸다.

그래서 만약 당신이 에러가 발생한다면 당신은 받은 상태 코드의 유형이 무엇인지 확인하기 위해 HTTP 응답을 볼 수 있습니다.

8. 브라우저는 HTML 컨텐츠를 보여줍니다 (HTML 응답은 가장 일반적인 경우)

브라우저는 HTML 컨텐츠를 단계적으로 보여줍니다.

첫째, 브라우저는 HTML 골격을 그릴 것입니다.

그리고 나서 HTML 태그를 확인하고 이미지,CSS,stylesheets,JavaScript Files 등 웹페이지에 추가 요소에 대한 GET 요청을 보냅니다.

이러한 정적 파일은 브라우저에 의해 캐시되어지고 그래서 당신이 다음번에 페이지를 방문하더라도 다시 그것들을 가져올 필요가 없습니다.

끝으로 당신은 당신의 브라우저에 나타나는 maps.google.com를 보게 될 것입니다.

That’s It!

비록 이것은 매우 지루한 장기간의 과정 처럼 보이지만 우리는 우리가 키보드에 엔터를 치고 나서 웹페이지를 그려내는데 1초도 안걸린다는 사실을 알고 있습니다.

이 모든 과정은 우리가 미처 알아채기도 전에 milliseconds만에 일어나게 됩니다.

저는 제 글이 누군가가 당신에게 다음과 같은 질문에 대답하는데 도움이 되는 글이기를 진심으로 희망합니다.

“야야 내가 브라우저 주소창에 google.com을 타이핑 하고 엔터를 뙇 치면 무슨일이 일어나는지 설명해줄래?”

Reference

https://medium.com/@maneesha.wijesinghe1/what-happens-when-you-type-an-url-in-the-browser-and-press-enter-bb0aa2449c1a