네트워크

[네트워크] 도메인 입력시 발생하는일에 관하여

취업 드가자잇 2024. 4. 8. 16:37

우선, 도메인(Domain)이란 쉽게 말하자면 우리가 웹사이트에 진입하기 위해 웹 브라우저에 입력하는 www.뭐시기.com과 같은 사이트 주소이다. 이를 URL과 혼동할 수 있는데 (필자는 그랬다...) 결론적으로 URL이라는 큰 개념안에 도메인 주소가 있다고 이해하면 좋다. 

URL은 'https://www.example.com:443/index.html?page=2&lang=en#section1'와 같이 사용되는 프로토콜, 도메인 주소, 포트 등 인터넷 상에 리소스를 찾기위한 모든 전체 주소이다. 그리고, 도메인 주소는 example.com 이 부분을 의미한다.

 

그렇다면 이제 이 도메인 주소를 입력했을때, 어떤 일이 발생하는지, 어떠한 과정을 거친 이후에 우리에게 웹 페이지를 보여주는지에 대해서 알아보자.

 

1. 웹 주소의 IP를 빠르게 찾기 위한 최적화 단계

 

1. 로컬의 Hosts 파일 조회

  • 각 운영 체제에는 hosts라는 파일이 있으며, 이 파일은 특정 도메인 이름을 그에 해당하는 IP 주소로 직접 매핑한다. 이 파일을 통해 시스템은 DNS 조회를 건너뛰고 바로 IP 주소를 확인할 수 있다. 사용자가 이 파일에 직접 도메인과 IP 주소를 추가하면, DNS 서버에 요청을 보내기 전에 먼저 이 파일을 확인하여 해당 IP 주소로 바로 연결한다.

2. 브라우저, OS, Router, ISP 의 캐시 조회

  • 브라우저 캐시: 대부분의 웹 브라우저는 최근에 방문한 웹사이트의 DNS 정보를 로컬 캐시에 저장한다. 여기서 DNS정보란 일반적으로 도메인주소와 관련된 IP주소를 포함한다. 브라우저는 새로운 웹 페이지 요청 시 먼저 이 캐시를 확인하여 도메인 이름의 IP 주소를 찾는다. 이 캐시는 설정에 따라 일정 시간 동안 유효하다.
  • 운영 체제(OS) 캐시: 브라우저 캐시에 해당 정보가 없을 경우, 운영 체제 자체에도 DNS 캐시가 존재한다. 이 캐시는 시스템이 네트워크 요청을 처리하면서 자동으로 생성되며, 여러 애플리케이션에서 공유할 수 있다.
  • 라우터 캐시: 일부 홈 라우터 및 기업 네트워크의 라우터는 통과하는 DNS 조회 정보를 캐싱하여 네트워크 내의 모든 기기에 대한 DNS 조회 속도를 향상시킨다.
  • ISP(Internet Service Provider) 캐시: 마지막으로, 광역 네트워크 수준에서 인터넷 서비스 제공자는 자체 DNS 서버를 통해 대규모 DNS 캐시를 유지 관리한다. 이는 모든 고객 요청에 대해 더 빠른 DNS 응답 시간을 제공하는 데 사용된다.

이러한 캐시 계층을 통해 캐시된 정보가 최신이고 정확하다면, 이를 통해 불필요한 DNS 조회 요청을 줄이고 사용자 경험을 개선할 수 있는 것이다. 

 

2. DNS (Domain Name System Lookup) 조회 단계

 

만약 hosts파일이 없고, 캐시도 없을 경우, DNS 조회 단계로 넘어가게 된다. DNS는 인터넷 상에서 도메인 이름(예: 뭐시기.com)을 해당 도메인의 IP 주소(예: 192.0.0.1)로 변환하는 시스템이다.

좀 더 구체적으로는 도메인 이름과 IP 주소를 매핑하는 key/value lookup을 제공한다. 

이런 과정이 필요한 이유는 인터넷이 IP 주소를 통해 컴퓨터들을 식별하고 통신하기 때문이다.

그렇기에 클라이언트에게 올바른 웹페이지를 전달하기 위해서는 클라이언트가 입력한 도메인 이름을 해당 웹페이지의 소스를 가지고 있는 서버의 IP주소로 전환하는 작업을 진행해야한다.

즉, 이 단계는 클라이언트와 서버간의 통신을 위한 전초단계라고 이해할 수 있다. 

DNS 조회 단계는 다음과 같다.

  1. DNS 리졸버 시작: 사용자가 도메인 이름 (예: example.com)을 입력하면, DNS 리졸버가 IP 주소 조회를 시작한다.
  2. 루트 DNS 서버 질의: 리졸버는 먼저 루트 DNS 서버에 접근하여 해당 도메인의 최상위 도메인 (TLD, 예: .com) 서버 정보를 요청한다. (즉, 모든 DNS에는 루트 DNS의 주소를 가지고 있다)
  3. TLD 서버 질의: 루트 서버로부터 받은 정보를 바탕으로 TLD 서버에 접근하여 해당 도메인의 네임 서버(특정 도메인에 대한 DNS 정보를 관리하는 서버)정보를 요청한다.
  4. 도메인 이름 서버 질의: TLD 서버가 제공한 정보를 바탕으로 도메인 이름 서버(도메인 이름을 해당 웹 서버의 IP 주소로 변환하는 역할)에 접속하여 실제 IP 주소를 요청한다.
  5. IP 주소 반환: 도메인 이름 서버는 최종적으로 도메인의 IP 주소(웹 서버의 위치)를 리졸버에게 반환하며, 리졸버는 이를 사용자의 브라우저에 전달한다. 사용자의 브라우저는 이 IP 주소를 사용해 웹 페이지에 접속한다.

 

3. TCP 연결

 

웹에서는 신뢰성있는 데이터의 전송이 매우 중요하기에 TCP연결을 사용한다. (물론 HTTP3라면 QUIC 프로토콜을 사용한다)

TCP연결을 위해서 3-way handshake 과정을 거치고, 이를 통해 브라우저와 서버간의 안정적인 통신 채널을 보장한다. 추가적으로, 이 과정에서는 일반적으로 포트 80(HTTP) 또는 포트 443(HTTPS)이 사용된다.

이제 포트는 또 뭔가싶을 수 있다. 예를 들어, IP주소가 호텔 주소라면, 포트는 방 번호라고 할 수 있다.

이전 단계를 통해 우리가 찾는 서버(집 주소)를 찾았다면, 이제는 어떠한 목적으로 연결을 할건지(투숙 목적이 무엇인지)에 대해 정의해야할것이다 (예시가 적절한지는 모르겠다).

아무튼, 이 과정을 통해 해당 통신이 웹 브라우저와 웹 서버 간의 통신임을 정의하고, HTTP경우 80, HTTPS의 경우 일반적으로 443 포트를 사용하게 된다.

 

4. HTTP / HTTPS 요청 보내기

 

사용자들은 의식하지 못하지만, 인터넷을 사용하며 웹사이트에 진입할때마다 사실은 해당 서버에 GET요청을 지속적으로 해왔다.

이것이 HTTP요청이다.

이전 단계에서 TCP 연결을 통해 신뢰성있는 통신이 보장되었기에, HTTP 프로토콜을 사용한다면 해당 서버에 해당 웹페이지에 대한 정보를 바로 GET요청을 한다.

반면, HTTPS 프로토콜을 사용하는 경우, SSL/TLS 핸드셰이크 (이전 글 참조) 과정을 우선적으로 진행한다음 암호화된 GET 요청을 날린다.

HTTP / HTTPS 요청의 종류

  • GET: 서버로부터 정보를 조회하기 위해 사용된다. 
  • POST: 서버에 데이터를 생성하거나 업데이트하기 위해 데이터를 전송할 때 사용된다. 예) 로그인
  • PUT: 기존의 데이터를 새로운 데이터로 대체하기 위해 사용된다.
  • DELETE: 특정 데이터를 삭제하기 위해 사용된다.
  • PATCH: 데이터의 일부만을 업데이트하기 위해 사용된다.

 

5. 웹 페이지 랜더링

 

서버가 정상적으로 요청을 받았다면, 해당 요청에 해당하는 응답을 우리의 브라우저에게 전송해줄것이다.

이 응답에는 서버측이 가지고 있던 HTML, CSS, Javascript 파일등이 있을 수 있으며, 브라우저는 이 파일을 해석하고, 사용자에게 보여줄 수 있는 형태로 웹페이지를 그려낸다(렌더링한다).

이때, 추가로 이미지나 비디오가 포함되어있다면, 브라우저는 서버에 추가적으로 요청을 보내어 필요한 렌더링 작업을 마저 수행핸다.

이후 랜더링 과정이 성공적으로 완수되었다면 사용자는 비로소 본인이 원하던 웹페이지를 마주할 수 있게 된다. 

 

웹 페이지 랜더링의 경우, 다른 글에서 더 자세하기 다뤄보겠다 (DOM 등).