기술 면접을 준비하면서 브라우저에 www.naver.com을 입력하면 어떤일이 발생할까요? 에 대한 질문을 받았는데 어렴풋이 어떤 동작이 일어나는 지는 알았지만 이를 자세하게 답을 할 수는 없었습니다. 그래서 이에 대해 자세하게 정리해보려고 합니다.
간단하게 살펴보면 다음과 같습니다.
- 웹 브라우저에 URL을 입력하고 Enter 키를 누릅니다.
- 웹 브라우저가 도메인의 IP 주소를 조회합니다. (먼저 캐시를 찾고, 그다음 DNS를 검색합니다.)
- 웹 브라우저가 찾은 IP 주소를 기반으로 서버와의 TCP 연결을 시작합니다.
- 웹 브라우저가 HTTP 요청을 서버로 전송합니다. (필요한 경우, HTTPS 보안 통신이 진행됩니다.)
- 웹 서버가 요청을 처리하고 응답을 다시 웹 브라우저로 전송합니다.
- 웹 브라우저가 전송 받은 콘텐츠를 렌더링합니다.
웹 브라우저에 URL을 입력하고 Enter를 누릅니다.
웹 브라우저가 도메인의 IP 주소를 조회합니다.
웹 브라우저에서 www.naver.com와 같은 url을 입력하면 브라우저는 인터넷에서 사이트를 호스팅하는 서버를 파악해야합니다. 이는 www.naver.com 도메인을 검색하여 주소를 찾는 과정입니다.
서버, 휴대폰, 태블릿 등 인터넷의 각 디바이스에는 모두 IP 주소라는 고유한 주소가 있습니다. IP 주소에는 223.130.195.95 와 같은 4개의 번호가 매겨진 부분이 있습니다. 이러한 IP 주소는 www.naver.com보다 기억하기가 매우 어렵습니다. 휴대폰에 연락처 앱이 있어 이름만으로 우리가 전화번화를 찾을 수 있듯이 인터넷에서도 마찬가지입니다. DNS(도메인 네임 시스템)은 휴대폰의 연락처 앱과 같습니다. DNS는 브라우저가 인터넷에서 서버를 찾는 데 도움이 됩니다. 도메인 이름을 기반으로(www.naver.com) 서버의 IP 주소를 찾을 수 있습니다.
터미널에서 nslookup URL 을 통해 IP 주소를 확인할 수 있다.
캐시에서 DNS 기록을 확인합니다.
DNS 기록을 확인하는 과정은 다음과 같습니다.
-
웹 브라우저 캐시 검색
브라우저는 이전에 방문한 웹 사이트의 DNS 정보를 일정 기간 동안 저장하는 캐시를 가지고 있습니다. 브라우저는 먼저 자체 캐시를 검색하여 해당 도메인의 IP 주소를 확인합니다. 캐시에 DNS 기록이 있는 경우 추가 DNS 조회 없이 해당 IP 주소로 직접 연결을 시도할 수 있습니다.
브라우저에서 캐시된 파일을 직접 보기 위해선 구글 크롬 같은 경우 별도의 크롬 캐시 뷰어를 통해 확인 가능합니다.
-
운영체제 캐시 검색: 브라우저의 캐시에 해당 DNS 기록이 없거나 만료된 경우, 운영체제(OS)는 자체적으로 DNS 기록을 캐시로 관리합니다. 브라우저는 운영체제 캐시에서 DNS 기록을 검색하여 IP 주소를 확인하려고 시도합니다.
윈도우 터미널에서 ipconfig /displaydns를 통해 확인 가능합니다.
-
라우터 캐시 검색: 운영체제의 DNS 캐시에도 해당 DNS 기록이 없는 경우, 브라우저는 로컬 네트워크에 연결된 라우터의 DNS 캐시를 검색합니다. 일부 라우터는 자체 DNS 캐시를 유지하며, 이를 통해 이전에 방문한 도메인의 IP 주소를 찾을 수 있습니다.
라우터 제조사마다 라우터 캐시를 확인하는 방법은 다르지만 보통 라우터의 IP주소를 브라우저에 입력하면 라우터 관리자 인터페이스를 통해 캐시를 확인하거나 삭제할 수 있습니다.
-
ISP 캐시 검색: 만약 위 모든 단계에서 DNS 기록을 찾지 못한다면, 브라우저는 ISP에서 DNS 기록을 찾는다. ISP(Internet Service Provider)는 DNS 서버를 가지고 있는데, 해당 서버에서 DNS 기록 캐시를 검색할 수 있다.
ISP : 인터넷 서비스 제공자 EX) SKT ,KT, LG Etc.
ISP 는 3계층으로 나눌 수 있다. 자세한 것은 검색
이렇게 캐시를 통해 네트워크 트랙픽 조절과 데이터 전송 시간을 줄여준다.
요청한 URL이 캐시에 없으면, ISP의 DNS 서버에서 다른 DNS 서버를 DNS Query를 통해 검색하여 IP 주소를 찾는다.
-
DNS 리커서(재귀 확인자)
재귀 확인자는 클라이언트와 DNS 네임 서버 사이의 중개자 역할을 합니다. 재귀 확인자는 웹 클라이언트로부터 DNS 쿼리를 받아 캐시된 데이터로 응답하거나 요청을 루트 네임서버로 보내고 또 다른 요청을 TLD 네임서버로 보낸 후 마지막 요청을 권한 있는 네임서버로 보냅니다. 재귀 확인자는 요청된 IP 주소가 있는 권한 있는 네임서버로부터 응답을 받은 후 응답을 클라이언트에 보냅니다. -
DNS의 가장 상위 계층에 위치한 서버입니다.
역할과 위치
DNS 루트 네임 서버는 전 세계적으로 분산되어 있으며, 13개의 논리적인 서버로 구성됩니다.
이러한 서버는 각기 다른 지리적 위치와 IP 주소를 가지고 있습니다.
루트 네임 서버는 최상위 도메인 레벨(예: .com, .org, .net)에 대한 권한을 가지고 있지 않습니다. 그 대신, 상위 레벨 도메인 서버에 대한 참조 정보를 제공합니다.확인자는 DNS 루트 서버를 어떻게 찾을까요?
DNS 루트 영역은 DNS 계층 구조의 맨 위에 있으므로 DNS 조회에서 재귀 확인자를 DNS 루트 영역으로 리디렉션할 수 없습니다. 이 때문에 모든 DNS 확인자에는 소프트웨어에 내장된 13개의 IP 루트 서버 주소 목록이 있습니다. DNS 조회가 시작될 때마다 리커서의 첫 번째 통신은 13개의 IP 주소 중 하나와 이루어집니다.
- TLD(Top-Level Domain) 네임서버
상위 레벨 도메인(Top-Level Domain)에 대한 정보를 관리하는 서버입니다. TLD는 도메인 이름의 최상위 계층을 나타내며, 예를 들어 ".com", ".org", ".net"과 같은 TLD가 있습니다.TLD 네임서버는 .com, .net 또는 URL의 마지막 점 뒤에 오는 것 같은 일반적인 도메인 확장자를 공유하는 모든 도메인 이름의 정보를 유지합니다. 예를 들어 TLD 네임서버는 ‘.com’으로 끝나는 모든 웹사이트의 정보를 갖고 있습니다. 사용자가 google.com을 검색하는 경우 재귀 확인자는 루트 네임서버로부터 응답을 받은 후 쿼리를 .com TLD 네임서버에 보내고, 해당 네임서버는 해당 도메인의 권한 있는 네임서버(아래 참조)를 가리켜 응답합니다.
-
권한 있는 네임서버
특정 도메인에 대한 IP 주소 정보를 직접 관리하는 서버입니다.
도메인 소유자 또는 관리자가 해당 도메인에 대한 DNS 레코드를 생성하고 유지합니다.
클라이언트가 도메인 이름에 대한 IP 주소를 요청하면, 권한 DNS 서버가 해당 도메인에 대한 IP 주소 정보를 반환합니다.웹 브라우저가 찾은 IP 주소를 기반으로 서버와의 TCP 연결을 시작합니다
브라우저가 IP 주소를 찾으면 해당 IP 주소에 있는 서버와 연결해 정보를 전달한다.
인터넷 프로토콜(IP)은 인터넷의 주소 체계로, 소스 장치에서 대상 장치로 정보 패킷을 전달하는 것이 핵심 기능입니다. IP는 네트워크 연결이 이루어지는 기본적인 방법으로, 인터넷의 기반을 확립합니다. IP는 패킷 순서 지정 또는 오류 검사를 처리하지 않습니다. 이러한 기능은 다른 또 하나의 프로토콜을 필요로 하며 대개의 경우 전송 제어 프로토콜(TCP)이 그 역할을 합니다.
TCP/IP 관계는 퍼즐에 메시지를 작성하여 우편으로 보내는 것과 비슷합니다. 퍼즐에 메시지를 작성하면 퍼즐은 여러 조각으로 나뉘어집니다. 퍼즐의 조각들은 각각 다른 우편 경로를 통해 전달되는데, 조각마다 여기 걸리는 시간이 다릅니다. 다른 경로를 통해 전달된 퍼즐의 조각들은 순서가 뒤죽박죽되어 있을 수 있습니다. IP는 각 조각이 목적지 주소에 도착하도록 합니다. TCP 프로토콜은 반대쪽에서 조각들을 올바른 순서로 맞추고, 누락된 조각을 다시 보내달라고 요청하고, 발신자에게 조각을 받았음을 알려주는 사람으로 생각하면 됩니다. TCP는 첫 번째 조각을 보내기 전부터 마지막 조각을 보낸 후까지 발신자와의 접속을 유지합니다.
IP는 연결이 없는 프로토콜입니다. 즉, 데이터의 각 단위는 개별적으로 주소가 지정되고 소스 장치로부터 대상 장치로 라우팅되며, 대상 장치는 이를 수신했다는 확인을 소스에 보내지 않습니다. 여기에 TCP와 같은 프로토콜이 필요해집니다. TCP는 IP와 함께 사용하여 발신자와 대상 사이의 연결을 유지하며 패킷 순서를 보장합니다.이러한 TCP 연결은 3-WAY Handshake라는 연결과정을 통해 이루어집니다.
첫째, 대화를 시작할 수 있도록 소스가 SYN "최초 요청" 패킷을 대상 서버로 보냅니다.
다음으로, 대상 서버가 SYN-ACK 패킷을 보내 이 과정에 동의합니다.
마지막으로, 소스가 대상에 ACK 패킷을 보내 이 과정을 확인하며,
이후 메시지 콘텐츠를 전송합니다.이메일 메시지는 궁극적으로 패킷으로 분할된 후 인터넷으로 보내지며, 인터넷에서는 일련의 게이트웨이를 거쳐 대상 장치에 도착하는데, 여기에서 이 패킷들이 다시 TCP에 의해 조립되어 이메일의 원래 메시지로 구성됩니다.
IP와 TCP웹 브라우저가 HTTP 요청을 서버로 전송합니다. (필요한 경우, HTTPS 보안 통신이 진행됩니다.)
TCP 연결이 완료 되면 브라우저는 HTTP 요청을 합니다. 즉 나 이 데이터 필요하니까 서버에서 보내달라는 요청을 의미합니다.
브라우저는 HTTP 요청 메시지를 생성하여 웹 서버로 전송합니다. 요청 메시지에는 요청 방식(GET, POST 등), 헤더, 쿠키, 요청 바디 등의 정보가 포함됩니다.
예를 들어 www.naver.com 네이버 웹 페이지를 요청하는 GET 요청을 보내면
요청 정보는 다음과 같습니다.
웹 서버가 요청을 처리하고 응답을 다시 웹 브라우저로 전송합니다.
웹 서버는 브라우저로부터 받은 요청에 대한 응답을 생성하여 전송합니다. 응답은 HTTP 상태 코드, 헤더, 쿠키, 응답 본문 등의 정보로 구성됩니다.
웹 브라우저가 전송 받은 콘텐츠를 렌더링합니다.
브라우저는 서버로부터 받은 응답을 처리합니다. 이 과정에는 HTML, CSS, JavaScript 등의 리소스를 해석하고, 화면에 표시하기 위한 렌더링 작업이 포함됩니다. 응답에 포함된 리소스(이미지, 스타일시트, 스크립트 등)들은 필요에 따라 추가적인 네트워크 요청을 통해 다운로드됩니다. 이후 브라우저는 해당 리소스를 화면에 표시합니다.
