[네트워크] 도메인 입력 시 발생하는 일에 관하여 (1편-최적화)

 

이전에 도메인 주소를 입력했을때, 어떤 일이 발생하는지, 어떠한 과정을 거친 이후에 우리에게 웹 페이지를 보여주는지에 대해 설명한 적이 있다. 그러다가 최근 이전에 정리한 내용을 복습할겸, 새로 추가하고 싶은 내용들이 생겨서 각 단계 별로 이전 내용과 종합한(+ 개인적으로 흥미로웠던 사실들을 함께) 글을 새롭게 작성해보고자 한다. 

 

 

일단, 개발자들은 효율에 미친 사람들이기 때문에 반복되는 작업을 극혐한다.

그렇기 때문에 시스템상에 웹 주소의 IP를 빠르게 찾기 위한 여러 최적화 시스템을 심어놓았는데 그중에 하나가 Hosts파일이다.

 

1. 로컬의 Hosts 파일 조회

우리가 사용하는 운영 체제에는 hosts라는 파일이 있다.

이 hosts라는 파일은 운영 체제마다 존재하며 특정 도메인 이름을 IP 주소로 직접 매핑하는 파일이다.

우리가 알아할 것은 '이 파일을 통해 DNS 조회를 건너뛰고 바로 IP 주소를 확인할 수 있다' 라는 사실이다.

// hosts 파일 조회 명령어
cat /etc/hosts

 

 

hosts 파일을 직접 조회하기 위해서는 터미널을 통해 해당하는 명령어를 입력하면 된다. 그러면 다음과 같은 화면을 볼 수 있다.

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost

# Custom entries
192.168.1.200   myapp.local

 

기본적으로 hosts 파일은 운영 체제에서 제공하는 기본 설정만 포함하고 있으며, 여기서 기본 설정이란 로컬 호스트와 브로드캐스트 도메인만 정의되어 있는 것을 말한다. 혹시 브로드캐스트 도메인에 대해 잘 모른다면 필자가 작성한 글중 IP란? 게시물을 참고하길 바란다.

그렇기에 사용자가 직접 수정하지 않는 한 대부분의 DNS 조회는 hosts 파일을 거치지 않고 진행됩니다.

하지만 만약 우리가 밥먹듯이 네이버를 방문하는 사람이라 티끌만큼이라도 로딩속도를 개선하고 싶다면 naver.com의 실제 IP 주소(예: 125.209.222.141)를 위 예시처럼 매핑해놓으면 아마 좀 더 빠르게 로딩이 될 것이다... (해보진 않았다 + 굳이...) 

 

 

Hosts 파일의 용도 

여기까지만 보면 hosts 파일 그거 뭐 쓸데없는거 아닌가 싶지만, 결국 시스템 속에 존재하는 것은 다 저마다 목적이 있기 때문에 존재하는 것이다. 그래서 이놈은 대체 뭘하는걸까 GPT성님에게 여쭈어보았고, 프론트엔드 개발자로서 납득할만한 사용 목적을 일부 알 수 있었는데 이는 다음과 같다. 

 

1. 도메인 기반 쿠키 테스트

쿠키는 특정 도메인에 종속이 된다는 특징이 있다. 그런데 우리가 보통 처음 개발을 진행하는 localhost는 실제 도메인과 다르게 취급되기 때문에 쿠키가 다른 도메인에서도 동일하게 작동하는지 테스트하기 어려울 수 있다. 이럴때 로컬 네트워크 환경 내에서만 유효한 가상 IP 주소를 만들어내서 우리가 개발중인 작업물 사이트와 연동시켜놓으면 마치 실제로 배포된 이후의 환경처럼 쿠키 테스트를 진행할 수 있다는 것이다. 

 

2. CORS (Cross-Origin Resource Sharing) 테스트

두번째로 CORS 테스트인데 마찬가지로 localhost는 다른 도메인에서 오는 요청을 허용하는 정책을 설정할 때 특별한 예외가 적용될 수 있다. 그렇기에 다른 가상 IP주소와 우리가 개발할 서비스의 가상 도메인을 매핑해놓고, 실제 운영 환경과 유사한 환경에서 API 호출을 테스트해볼 수 있다는 것이다. 

 

3. SSL/TLS 설정 테스트

배포 환경에서는 HTTPS가 요구되지만, 로컬 환경에서는 HTTP를 사용하는 경우가 꽤 많은 것 같다. 예전에도 백엔드 개발자분과 미니 프로젝트를 진행할때 로컬에서는 문제가 없었지만 Netlify를 통해 배포한 이후의 환경에서는 API 호출이 제대로 되지 않았던 적이 있다.

만약 이때 로컬 환경에서 가상 도메인과 HTTPS를 설정하여 테스트했다면 배포하기전에 해당 문제를 미리 인지할 수 있었을 것 같다는 생각이 들었다. 

 

암튼 일단은 테스트할때 쓰면 조타~ 이정도로 이해하면 좋을 것 같다.

 

 

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

hosts 파일 조회를 완료했다면 이제 브라우저, OS, Router, ISP의 캐시를 조회할 차례다.

여기서 캐시를 조회한다는것은 우리가 접속하려고 하는 사이트의 DNS 정보(도메인주소와 관련된 IP주소)를 브라우저, OS, Router, ISP에서 한번 확인해본다는 의미이다. 

 

1. 브라우저 캐시

가장 먼저 브라우저 캐시부터 살펴보자면 우리가 사용하는 크롬같은 브라우저는 최근에 방문한 웹사이트에 대한 정보를 로컬 캐시에 저장한다. 개발자 도구를 키면 캐시된 리소소들을 쉽게 확인해볼 수 있다.

 

캐시된 리소스 예시

 

뭐 이런식으로 브라우저는 캐시된 리소스에는 그냥 OK가 아니라 메모리 캐시에서 같은 문장이 따라 붙는데 의미는 다음과 같다.

 

• 200 OK (from memory cache): 리소스가 메모리 캐시에서 제공되었음을 나타낸다.
• 200 OK (from disk cache): 리소스가 디스크 캐시에서 제공되었음을 나타낸다.
• 304 Not Modified: 리소스가 변경되지 않았음을 나타내며, 브라우저가 캐시된 버전을 사용하도록 지시한다

 

정리하자면,

캐시는 브라우저가 웹 페이지의 리소스를 저장해두고, 같은 리소스를 다시 요청할 때 네트워크를 통해 서버에서 다시 다운로드하는 대신 저장된 버전을 사용하는 방식으로 작동한다는 것이다. 

그렇기에 우리가 자주 방문하는 사이트일수록

브라우저 캐시에 해당 사이트의 리소스가 저장되어 있을 가능성이 높다는 것이고, 이로 인해 웹 페이지 로딩 속도가 더 빨라질 수도 있다는 것이다. 

 

2. 운영 체제(OS) 캐시

만약 브라우저 캐시에 접속하려는 사이트의 DNS 정보가 없다면, 운영 체제 캐시로 차례가 넘어간다. hosts 파일이외에 운영 체제 자체에도 DNS 캐시가 존재하며 DNS 캐시는 운영 체제의 메모리에 저장된다. 여기서 운영 체제의 메모리란 통상적으로 RAM을 의미한다. 

운영체제 캐시의 특징으로는 브라우저 캐시와 달리 Cache Storage 같은 항목을 딸깍하면서 직접 접근 및 수정이 불가하는 점이다.

다만, 캐시를 지우는 명령어는 사용할 수 있다고 한다. 

 

3. 라우터 캐시

운영 체제 캐시에도 찾는 정보가 없다면 이제 라우터 캐시로 바통터치가 됬다.

다만 이전에 소개한 캐시와는 다르게 라우터 캐시는 일부 홈 라우터 및 기업 네트워크의 라우터에만 존재한다. 

결국 라우터를 통해 DNS 요청들이 왔다갔다 하는 구조인데 만약 고오급 라우터라면 이런 DNS 요청을 캐시하는 것이다.

그리고 나중에 동일한 도메인 이름에 대한 후속 요청이 발생하면, 고오급 라우터는 캐시된 응답을 사용하여 즉시 IP 주소를 반환하는 식이다.

이로 인해 네트워크 응답 시간을 단축하고, DNS 서버에 대한 불필요한 요청을 줄여 트래픽을 최적화할 수 있는 것이다.

 

4. ISP(Internet Service Provider)캐시

마지막으로(?), 라우터 캐시에도 찾는 정보가 없다면, 이제 ISP 캐시로 바통이 넘어간다.

ISP(인터넷 서비스 제공자)는 광역 네트워크 수준에서 자체 DNS 서버를 통해 대규모 DNS 캐시를 유지 관리한다.

ISP의 DNS 캐시는 운영 체제나 라우터 캐시보다 훨씬 큰 규모로 운영되며, 그만큼 수많은 도메인 이름과 IP 주소 매핑 정보를 저장한다.

우리가 알만한 국내의 주요 ISP 기업은 SK, KT, LG 유플러스 같은 회사들이다.

 

 

 

+) 이런 내용을 공부하다 보면 우리가 일상적으로 사용하는 것들에도 정말 무수한 기술들이 기저에 깔려있다는 생각이 들고, 뭔가 사고가 확장되는 느낌을 받는다.

아무튼 내용이 다소 방대했는데, 결론은 이러한 캐시 계층을 통해 캐시된 DNS 정보가 최신이고 정확하다면, 이를 통해 불필요한 DNS 조회 요청을 줄이고, 더 빠른 DNS 응답 시간을 사용자에게 제공할 수 있게 하는 것이 이 최적화의 목적이라 할 수 있다.