
이 글은 What happens when you type a URL in the browser and press enter? 를 번역하여 옮겨 정리한 글입니다. https://medium.com/@maneesa/what-happens-when-you-type-an-url-in-the-browser-and-press-enter-bb0aa2449c1a
"브라우저에 maps.google.com을 입력하면 어떤 일이 벌어질까?"
우리에게 너무나 친숙한 웹 브라우저를 사용하면서 무심코 지나갔지만 한번쯤은 궁금해봤을만한 주제다.
브라우저에 maps.google.com을 입력했을 때 일어나는 일들은 여덟 단계로 정리할 수 있다.
1. 브라우저 주소창에 maps.google.com을 입력한다.
2. 브라우저가 maps.google.com의 IP 주소를 찾기 위해 캐시에서 DNS 기록을 확인한다.
3. 만약 요청한 URL(maps.google.com)이 캐시에 없다면,
ISP의 DNS 서버가 DNS 쿼리로 maps.google.com을 호스팅하는 서버의 IP 주소를 찾는다.
4. 브라우저가 해당 서버와 TCP 연결을 시작한다.
5. 브라우저가 웹서버에 HTTP 요청을 보낸다.
6. 서버가 요청을 처리하고 응답을 보낸다.
7. 서버가 HTTP 응답을 보낸다.
8. 브라우저가 HTML 컨텐츠를 보여준다.
1. 브라우저의 주소 창에 maps.google.com을 입력한다.
2. 브라우저가 maps.google.com의 해당 IP 주소를 찾기 위해 캐시에서 DNS 레코드를 확인한다.
DNS(도메인 이름 시스템)는 웹사이트의 이름(URL)과 그것이 링크된 특정 IP 주소를 유지 관리하는 데이터베이스이다. 인터넷상의 모든 단일 URL은 그것에 할당된 고유한 IP 주소를 가지고 있다. IP 주소는 우리가 접속하려는 웹사이트의 서버를 호스팅하는 컴퓨터에 속한다. 예를 들어, http://www.google.com은 209.85.227.104의 IP 주소를 가지고 있다. 그래서 원한다면 브라우저에서 http://209.85.227.104를 입력하여 http://www.google.com에 접속할 수 있다. DNS는 URL과 그 IP 주소들의 목록인데, 전화번호부가 이름과 해당 전화번호의 목록인 것처럼 말이다.
DNS의 주요 목적은 인간 친화적인 탐색이다. 웹사이트에 접속하기 위해 올바른 IP 주소를 브라우저에 입력하는 것은 쉽지만, 우리가 정기적으로 접속하는 모든 사이트에 대해 다양한 숫자 세트를 기억하는 것은 상상하기 어렵다. 따라서, URL의 웹사이트 이름을 기억하고 DNS에 맞는 IP로 매핑하는 작업을 맡기는 것이 더 쉽다.
DNS 레코드를 찾기 위해 브라우저는 네 가지 캐시를 확인한다.
2-1. 브라우저 캐시를 확인한다.
브라우저는 고정된 기간 동안 이전에 방문한 웹사이트의 DNS 레코드를 저장하는 저장소를 유지 관리하므로, DNS 쿼리를 실행할 첫 번째 장소이다.
2-2. OS 캐시를 확인한다.
브라우저 캐시에 없다면, 브라우저는 컴퓨터 OS에 시스템 호출(예: Windows의 gethostname)을 하여 레코드를 가져오는데, OS도 DNS 레코드의 캐시를 유지한다.
2-3. 라우터 캐시를 확인한다.
컴퓨터에 없다면, 브라우저는 자체 DNS 레코드 캐시를 유지하는 라우터와 통신한다.
2-4. ISP 캐시를 확인한다.
모든 단계가 실패하면, 브라우저는 ISP로 이동한다. ISP는 자체 DNS 서버를 유지하며, 브라우저가 요청한 URL을 찾기 위해 마지막 희망으로 확인할 DNS 레코드 캐시를 포함한다.
왜 이렇게 많은 레벨에 걸쳐 많은 캐시가 유지되는지 궁금할 수 있다. 우리의 정보가 어딘가에 캐시되어 있다는 사실이 프라이버시 측면에서 매우 편안하진 않지만, 캐시는 네트워크 트래픽을 조절하고 데이터 전송 시간을 개선하기 위해 필수적이다.
3. 요청된 URL이 캐시에 없으면, ISP의 DNS 서버가 maps.google.com을 호스팅하는 서버의 IP 주소를 찾기 위해 DNS 쿼리를 시작한다.
앞서 언급했듯이, maps.google.com을 호스팅하는 서버와 내 컴퓨터가 연결되려면 maps.google.com의 IP 주소가 필요하다. DNS 쿼리의 목적은 웹사이트에 대한 올바른 IP 주소를 찾을 때까지 인터넷상의 여러 DNS 서버를 검색하는 것이다. 이러한 검색을 재귀 검색이라고 부른다. 왜냐하면 검색은 DNS 서버에서 DNS 서버로 필요한 IP 주소를 찾거나 찾을 수 없다는 오류 응답을 반환할 때까지 반복적으로 계속되기 때문이다.
이 상황에서, 우리는 ISP의 DNS 서버를 DNS 리커서로 부른다. DNS 리커서의 책임은 인터넷상의 다른 DNS 서버에 문의하여 의도된 도메인 이름의 적절한 IP 주소를 찾는 것이다. 다른 DNS 서버는 도메인 이름의 도메인 아키텍처를 기반으로 DNS 검색을 수행하기 때문에 이름 서버라고 불린다.
더 혼란스럽게 하지 않기 위해, 다음 다이어그램을 사용하여 도메인 아키텍처를 설명하고자 한다.

우리가 오늘날 마주치는 많은 웹사이트 URL에는 세 번째 레벨 도메인, 두 번째 레벨 도메인, 최상위 레벨 도메인이 포함되어 있다. 각각의 레벨에는 DNS 조회 과정 중에 쿼리되는 자체 이름 서버가 포함된다.
maps.google.com의 경우, 먼저 DNS 리커서는 루트 이름 서버에 연락한다. 루트 이름 서버는 그것을 .com 도메인 이름 서버로 리디렉션할 것이다. .com 이름 서버는 그것을 google.com 이름 서버로 리디렉션할 것이다. google.com 이름 서버는 maps.google.com에 대한 일치하는 IP 주소를 자체 DNS 레코드에서 찾아 DNS 리커서에게 반환하고, 이는 브라우저로 다시 전송될 것이다.
이러한 요청은 요청의 내용과 목적지 IP 주소(DNS 리커서의 IP 주소)와 같은 정보를 포함하는 작은 데이터 패킷을 사용하여 전송된다. 이 패킷들은 클라이언트와 서버 사이의 여러 네트워킹 장비를 통해 이동하며, 이 장비들은 라우팅 테이블을 사용하여 패킷이 목적지에 도달하기 위한 가장 빠른 가능한 경로를 파악한다. 이 패킷들이 분실되면, 요청 실패 오류를 받게 된다. 그렇지 않으면, 올바른 DNS 서버에 도달하여 올바른 IP 주소를 가져오고 브라우저로 돌아올 것이다.
4. 브라우저가 서버와 TCP 연결을 시작한다.
브라우저가 올바른 IP 주소를 받으면, 정보를 전송하기 위해 해당 IP 주소와 매치되는 서버와 연결을 구축한다. 브라우저는 이러한 연결을 구축하기 위해 인터넷 프로토콜을 사용한다. 사용될 수 있는 여러 가지 인터넷 프로토콜이 있지만, TCP는 많은 종류의 HTTP 요청에 사용되는 가장 일반적인 프로토콜이다.
당신의 컴퓨터(클라이언트)와 서버 사이에 데이터 패킷을 전송하기 위해서는 TCP 연결이 설정되어 있어야 한다. 이 연결은 SYN(동기화) 및 ACK(승인) 메시지를 교환하여 연결을 설정하는 세 단계 과정인 TCP/IP 세 방향 핸드셰이크를 사용하여 설정된다.
1. 클라이언트 기계는 인터넷을 통해 서버에 SYN 패킷을 보내 새로운 연결을 위해 열려 있는지 묻는다.
2. 서버가 새로운 연결을 수용하고 시작할 수 있는 열린 포트를 가지고 있다면, SYN 패킷에 대한 ACKnowledgment로 SYN/ACK 패킷을 사용하여 응답할 것이다.
3. 클라이언트는 서버로부터 SYN/ACK 패킷을 받고 ACK 패킷을 보내어 이를 승인한다.
그러면 데이터 전송을 위한 TCP 연결 설정이 완료된다!
5. 브라우저가 웹서버에 HTTP 요청을 보낸다.
TCP 연결이 설정되면, 데이터 전송을 시작할 차례다. 브라우저는 maps.google.com 웹 페이지를 요청하는 GET 요청을 보낼 것이다. 자격 증명을 입력하거나 양식을 제출하는 경우, 이것은 POST 요청일 수 있다. 이 요청에는 브라우저 식별(사용자 에이전트 헤더), 수락할 요청 유형(수락 헤더), 추가 요청을 위해 TCP 연결을 유지하도록 요청하는 연결 헤더와 같은 추가 정보도 포함될 것이다. 또한 이 도메인에 대해 브라우저가 저장한 쿠키에서 가져온 정보도 전달될 것이다.
GET 요청 샘플(헤더가 강조 표시됨):

(인터넷이 어떻게 작동되는지 궁금하다면, 개발자 도구(F12)를 켜서 HTTP 요청 헤더를 확인해볼 수 있다.)
6. 서버가 요청을 처리하고 응답을 돌려보낸다.
서버에는 요청을 받고 요청 핸들러에게 전달하여 응답을 읽고 생성하는 웹서버(Apache, IIS 등)가 포함되어 있다. 요청 핸들러는 프로그램(ASP.NET, PHP, Ruby 등으로 작성됨)으로서 요청, 헤더 및 쿠키를 읽어 요청된 것이 무엇인지 확인하고 필요한 경우 서버의 정보를 업데이트한다. 그런 다음 특정 형식(JSON, XML, HTML)으로 응답을 조립한다.
7. 서버가 HTTP 응답을 보낸다.
서버 응답에는 요청한 웹 페이지뿐만 아니라 상태 코드, 압축 유형(Content-Encoding), 페이지 캐싱 방법(Cache-Control), 설정할 쿠키, 개인 정보 보호 정보 등이 포함된다.
HTTP 서버 응답 예제:

위의 응답을 보면, 첫 번째 줄에 상태 코드가 표시된다. 이것은 응답의 상태를 알려주는 매우 중요한 부분이다. 상태 코드를 사용하여 다섯 가지 유형의 상태를 자세히 설명한다.
- 1xx (Information Response): 정보 메시지만을 나타낸다.
- 2xx (Successful Response): 서버와의 요청이 성공함을 나타냄
- 3xx (Redirection Message) : 요청 완료를 위해 추가 작업 조치가 필요함을 의미함.
- 4xx (Client Error Response) : 클라이언트의 Request에 에러가 있음을 의미함.
- 5xx (Server Error) : 서버 측의 오류로 request를 수행할 수 없음.
따라서 오류를 겪었다면, 받은 HTTP 응답의 상태 코드를 확인하여 수신한 상태 코드의 유형을 확인할 수 있다.
8. 브라우저는 HTML 내용을 표시한다 (HTML 응답이 가장 흔하기 때문에).
브라우저는 HTML 내용을 단계별로 표시한다. 먼저, HTML의 기본 골격을 렌더링한다. 그런 다음 HTML 태그를 확인하고 웹 페이지의 추가 요소(예: 이미지, CSS 스타일시트, 자바스크립트 파일 등)에 대한 GET 요청을 보낸다. 이러한 정적 파일은 브라우저에 의해 캐시되므로 다음에 페이지를 방문할 때 다시 가져올 필요가 없다. 최종적으로, maps.google.com이 브라우저에 표시된다.

"브라우저에 maps.google.com을 입력하면 어떤 일이 벌어질까?"
단순해 보이지만, 인터넷 작동 원리에 대한 기본적인 이해를 할 수 있어야 답할 수 있는 질문이다. 몇초도 안되는 시간 동안 여러 동작들을 거친다는 사실을 글을 정리하며 알게되어 매우 흥미로웠다.
정말 컴퓨터의 세계는 방대하고 배울게 정말 많구나라고 다시 한번 느끼게 되었다.
'CS' 카테고리의 다른 글
| 3. HTTP 기본 (1) | 2024.04.05 |
|---|---|
| URI와 웹 브라우저 요청 흐름 (4) | 2024.04.04 |
| 인터넷 네트워크 (0) | 2024.04.04 |
| Call by reference란 무엇이고 보통 어떻게 쓰이나요? (0) | 2024.02.01 |
| [CS] 트랜잭션과 무결성에 대하여 (2) | 2024.01.09 |