minguri brain is busy

브라우저에 URL을 입력하면 어떤 일이 일어날까요? 본문

Others/Web, CS

브라우저에 URL을 입력하면 어떤 일이 일어날까요?

minguri.k 2023. 4. 11. 19:07
반응형
해당 포스트는 What happens when you type a URL in the browser and press enter? 글을 참고하여 번역, 정리한 글입니다.

 
maps.google.com에 액세스 한다고 가정하고 그 과정을 살펴봅시다.
 

1. 브라우저 주소 표시줄에 maps.google.com을 입력합니다.

 

2. 브라우저는 DNS 레코드의 캐시를 확인하여 maps.google.com의 해당 IP 주소를 찾습니다.

DNS(Domain Name System)는 웹 사이트의 이름(URL)과 연결된 특정 IP 주소를 유지 관리하는 데이터베이스입니다. 인터넷의 모든 URL은 고유한 IP 주소가 할당되어있습니다.
IP 주소는 우리가 액세스를 요청하는 웹사이트의 서버를 호스팅 하는 컴퓨터에 속합니다. 예를 들어 www.google.com의 IP 주소는 209.85.227.104입니다. 따라서 원하는 경우 브라우저에 http://209.85.227.104를 입력하여 www.google.com에 접속할 수 있습니다. DNS는 전호번호부에서 이름과 전화번호 목록인 것과 같이 URL과 IP 주소 목록입니다.
 
DNS의 주요 목적은 인간 친화적인 탐색입니다. 숫자의 집합으로 이루어진 IP주소를 기억하는 것보다 URL을 이용하여 웹사이트 이름을 기억하는 것이 더 쉽습니다.
 
DNS 레코드를 찾기 위해 브라우저는 4개의 캐시를 확인합니다.
1. 브라우저 캐시: 브라우저는 이전에 방문한 웹 사이트에 대해 일정 기간 동안 DNS 레코드 저장소를 유지합니다. 따라서 DNS 쿼리를 실행하는 첫 번째 위치입니다.
2. OS 캐시: 브라우저 캐시에 없으면 OS가 DNS 레코드의 캐시도 유지 관리하므로 브라우저는 레코드를 가져오기 위해 기본 컴퓨터 OS에 시스템 호출(예: Windows의 gethostname)을 수행합니다.
3. 라우터 캐시: 컴퓨터에 없으면 브라우저는 자체 DNS 레코드 캐시를 유지 관리하는 라우터와 통신합니다.
4. ISP(회사 네트워크 또는 인터넷 서비스 제공업체, Internet Service Provider) 캐시: 모든 단계가 실패하면 브라우저는 ISP로 이동합니다. 나의 ISP는 DNS 레코드 캐시를 포함하는 자체 DNS 서버를 유지하며, 브라우저는 내가 요청한 URL을 찾을 수 있는 마지막 희망으로 이를 확인합니다.
 
많은 수준에서 유지 관리되는 캐시가 왜 그렇게 많을까요? 우리의 정보가 어딘가에 캐싱되는 것은 개인정보와 관련하여 불편할 수는 있으나 캐시는 네트워크 트래픽을 규제하고 데이터 전송 시간을 개선하는데 필수적입니다.

 

3. 요청한 URL이 캐시에 없으면 ISP의 DNS 서버가 DNS 쿼리를 시작하여 maps.google.com을 호스팅 하는 서버의 IP 주소를 찾습니다.

앞서 언급했듯이 내 컴퓨터가 maps.google.com을 호스팅 하는 서버에 연결하려면 maps.google.com의 IP 주소가 필요합니다. DNS 쿼리의 목적은 웹사이트의 올바른 IP 주소를 찾을 때까지 인터넷에서 여러 DNS 서버를 검색하는 것입니다. 이러한 유형의 검색을 재귀 검색이라고 합니다. 필요한 IP 주소를 찾거나 찾을 수 없다는 오류 응답을 반환할 때까지 여러 DNS 서버에 반복하여 계속 검색하기 때문입니다.
 
이 상황에서 우리는 ISP의 DNS 서버를 인터넷의 다른 DNS 서버에 응답을 요청하여 의도한 도메인 이름의 적절한 IP 주소를 찾는 책임이 있는 DNS 재귀자라고 합니다. 다른 DNS 서버는 웹 사이트 도메인 이름의 도메인 아키텍처를 기반으로 DNS 검색을 수행하므로 네임서버라고 합니다.

https://webhostinggeeks.com/guides/dns/

오늘날 접하는 많은 웹사이트 URL에는 3단계 도메인, 2단계 도메인 및 최상위 도메인이 포함되어 있습니다. 이러한 각 수준에는 DNS 조회 프로세스 중에 쿼리 되는 자체 네임 서버가 포함되어 있습니다.
 
maps.google.com의 경우 먼저 DNS 리커서가 루트 네임 서버에 연결합니다. 루트 이름 서버는 이를 .com 도메인 네임 서버로 리디렉션합니다. .com 네임 서버는 google.com 네임 서버로 리디렉션 합니다. .google.com 네임 서버는 DNS 레코드에서 maps.google.com과 일치하는 IP 주소를 찾아 DNS 리커서로 반환하고 다시 브라우저로 보냅니다.
 
이러한 요청은 요청 내용 및 요청 대상 IP 주소(DNS 리커서의 IP 주소)와 같은 정보가 포함된 작은 데이터 패킷을 사용하여 전송됩니다. 이러한 패킷은 올바를 DNS 서버에 도달하기 전에 클라이언트와 서버 간에 여러 네트워킹 장비를 통해 이동합니다. 이 장비는 라우팅 테이블을 사용하여 패킷이 목적지에 도달하는 가장 빠른 방법을 파악합니다. 이러한 패킷이 손실되면 요청 실패 오류가 발생합니다. 그렇지 않으면 올바른 DNS 서버에 도달하고 올바른 IP 주소를 얻은 다음 브라우저로 돌아올 것입니다.

 

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

브라우저가 올바른 IP 주소를 수신하면 정보를 전송하기 위해 IP 주소와 일치하는 서버와 연결을 구축합니다. 브라우저는 인터넷 프로토콜을 사용하여 이러한 연결을 구축합니다. 사용할 수 있는 여러 인터넷 프로토콜이 있지만 TCP는 많은 유형의 HTTP 요청에 사용되는 가장 일반적인 프로토콜입니다.
 
컴퓨터(클라이언트)와 서버 간에 데이터 패킷을 전송하려면 TCP 연결을 설정하는 것이 중요합니다. 이 연결은 TCP/IP 3방향 handshake  프로세스를 사용하여 설정됩니다. 이것은 클라이언트와 서버가 SYN(동기화) 및 ACK(확인) 메시지를 교환하여 연결을 설정하는 3단계 프로세스입니다.
 
1. 클라이언트 시스템은 인터넷을 통해 서버에 SYN 패킷을 보내 새 연결을 위해 열려있는지 묻습니다.
2. 서버에 새 연결을 수락하고 시작할 수 있는 열린 포트가 있는 경우 SYN/ACK 패킷을 사용하여 SYN 패킷의 ACK 인식으로 응답합니다.
3. 클라이언트는 서버로부터 SYN/ACK 패킷을 수신하고 ACK 패킷을 전송하여 이를 확인합니다.
 
그런 다음 데이터 전송을 위해 TCP 연결이 설정됩니다.

 

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

TCP 연결이 설정되면 데이터 전송을 시작할 때입니다! 브라우저는 maps.google.com 웹 페이지를 요청하는 GET 요청을 보냅니다. credential을 입력하거나 form을 submit 하는 경우 이는 POST 요청일 수 있습니다. 이 요청에는 브라우저 식별(User-Agent header), 수락할 요청 유형(Accept header), 추가 요청을 위해 TCP 연결을 유지하도록 요청하는 연결 헤더와 같은 추가 정보도 포함됩니다. 또한 브라우저가 이 도메인에 저장한 쿠키에서 가져온 정보를 전달합니다.
 
샘플 GET 요청(header에 노란색 표시):

(뒤에서 무슨 일이 벌어지고 있는지 궁금하다면 firebug와 같은 도구를 사용하여 HTTP 요청을 살펴볼 수 있습니다.)

 

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

서버에는 브라우저에서 요청을 수신하고 요청 핸들러로 전달하여 응답을 읽고 생성하는 웹 서버(예: Apache, IIS)가 포함되어 있습니다. 요청 핸들러는 요청, 요청 헤더 및 쿠키를 읽어 요청 내용을 확인하고 필요한 경우 서버의 정보를 업데이트하는 프로그램(ASP.NET, PHP Ruby 등으로 작성)입니다. 그런 다음 특정 형식(JSON, XML, HTML)으로 응답을 조합합니다.

 

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

서버 응답에는 상태 코드, 압축 유형(Content-Encoding), 페이지를 캐시 하는 방법(Cache-Control), 설정할 쿠키, 개인 정보 등을 비롯하여 요청한 웹 페이지가 포함됩니다.
HTTP 서버 응답 예:

위의 응답을 보면 첫 줄에 상태 코드가 표시됩니다. 이는 응답 상태를 알려주므로 매우 중요합니다. 숫자 코드를 사용하여 설명하는 5가지 상태유형이 있습니다.
- 1xx: 정보 메시지만을 나타냅니다.
- 2xx: 일종의 성공을 나타냅니다.
- 3xx: 클라이언트를 다른 URL로 리디렉션 합니다.
- 4xx: 클라이언트 측 오류를 나타냅니다.
- 5xx: 서버 부분의 오류를 나타냅니다.
따라서 오류가 발생하면 HTTP 응답을 보고 어떤 유형의 상태 코드를 받았는지 확인할 수 있습니다.

 

8. 브라우저에 HTML 콘텐츠가 표시됩니다.(가장 일반적인 HTML 응답인 경우)

브라우저는 단계적으로 HTML 콘텐츠를 표시합니다. 먼저 HTML 뼈대를 렌더 합니다. 그런 다음 HTML 태그를 확인하고 이미지, CSS 스타일 시트, JavaScript 파일 등과 같은 웹 페이지의 추가 요소에 대한 GET 요청을 보냅니다. 이러한 정적 파일은 브라우저에 의해 캐시 되므로  다음에 이 페이지를 다시 방문할 때 다시 가져올 필요가 없습니다. 결국 브라우저에 maps.google.com 이 표시됩니다.

끝입니다.
 
매우 지루하고 긴 프로세스처럼 보이지만 키보드에서 Enter 키를 누른 후 웹 페이지가 렌더링 되는 데 몇 초도 걸리지 않는다는 것을 알고 있습니다. 이 모든 단계는 우리가 눈치채기도 전에 밀리초 내에 발생합니다. 


정리

1. 웹 브라우저에 URL을 입력합니다.
2. 웹 브라우저가 도메인의 IP주소를 조회합니다.(먼저 캐시를 찾고 없으면 DNS서버가 DNS 쿼리)
3. 웹 브라우가 찾은 IP 주소를 기반으로 서버와의 TCP 연결을 시작합니다.
4. 웹 브라우저가 HTTP(S) 요청을 서버로 전송합니다.
5. 웹 서버가 요청을 처리하고 응답을 다시 웹 브라우저로 전송합니다.
6. 웹 브라우저가 전송 받은 컨텐츠를 렌더링합니다.

반응형
Comments