이 글은 보초님 깃허브 레포를 참고해서 공부한 글입니다
[www.naver.com] 을 브라우저에 입력하고 엔터를 쳤을 때, 네트워크 상 어떤 일이 일어나는지 최대한 자세하게 설명해 주세요.
리다이렉트, 캐싱, DNS, IP 라우팅과 ARP, TCP 연결 구축을 거친 다음 컨텐츠를 다운받게 되고 이 후 브라우저 렌더링 과정을 거쳐 네이버라는 화면이 나타난다. 이 과정을 자세히 알아보자
리다이렉트
사용자가 처음 요청한 URL 이 아닌, 다른 URL 로 보내는 것을 말한다.
리다이렉트가 있다면 리다이렉트를 진행하고 없으면 그대로 해당 요청에 대한 과정이 진행된다.
캐싱
캐싱은 요청된 값의 결과값을 저장하고 그 값을 다시 요청하면 다시 제공하는 기술이다.
- 브라우저 캐시
- 브라우저 캐시는 쿠키, 로컬 스토리지 등을 포함한 캐시이다.
- 사용자가 HTTP 를 통해 다운로드 하는 모든 문서를 보유하는 것을 말한다.
- 공유 캐시
- 클라이언트와 서버 사이에 있고, 사용자간에 공유할 수 있는 응답을 저장한다.
- 대표적인 예시로 요청한 서버 앞단에 프록시 서버가 캐싱을 하는 것을 말한다.
해당 요청이 캐싱이 가능한지 가능하지 않은지를 파악한다. 캐싱이 이미 된 요청이라면 캐싱된 값을 반환하고 캐싱이 되지 않은 새로운 요청이라면 그 다음 단계로 넘어간다.
DNS
DNS(Domain Name System) 은 계층적인 도메인 구조와 분산된 데이터베이스를 이용해서 시스템으로 FQDN(Fully Qualified Domain Name) 을 인터넷 프로토콜인 IP 로 바꿔주는 시스템이다.
참고 : FQDN(Fully Qualified Domain Name) 은 호스트와 도메인이 합쳐진 완전한 도메인 이름을 말한다. www 등은 호스트, naver.com 은 도메인이라고 한다.
www.naver.com 에 DNS 쿼리가 오면 오른쪽부터 역순으로 [Root DNS] -> [.com DNS] -> [.naver DNS] -> [.www DNS] 과정을 거쳐 완벽한 주소를 찾아 IP 주소를 매핑한다.
DNS 캐싱
만약 해당 도메인 이름을 요청했다면 로컬 PC 에 자동적으로 저장된다.
IP 라우팅
해당 IP 를 기반으로 IP 라우팅이 일어나고 ARP 과정을 거쳐 실제 서버를 찾는다
TCP 연결 구축
브라우저가 TCP 3 way handshake, SSL 연결등을 통해 연결을 설정한다. 이후 요청을 보낸 후 해당 요청한 서버로부터 응답을 받는다.(naver 서버)
TCP 연결은 HTTP/2 까지 일어나고 HTTP/3 은 QUIC 을 통해 연결하고 데이터를 주고 받는다.
이러한 과정을 거친 다음 콘텐츠를 다운로드하고 받은 데이터를 바탕으로 브라우저 엔진이 브라우저 렌더링 과정을 거쳐 화면이 나타난다.
DNS 쿼리를 통해 얻어진 IP는 어디를 가리키고 있나요?
도메인 이름에 설정된 웹 서버, 이메일 서버, 또는 그 외의 서비스를 제공하는 서버의 실제 위치를 가리키는 것이다.
Web Server와 Web Application Server의 차이에 대해 설명해 주세요.
Web Server
웹 서버는 주로 정적 컨텐츠를 제공하는 데 사용된다. 정적 컨텐츠란 HTML, CSS, 이미지 파일과 같이 서버에 미리 저장되어 있으며 사용자에 요청에 따라 변경되지 않는 파일들을 의미한다.
웹 서버의 주요 기능은 HTTP 요청을 받아서 요청된 파일을 찾아 사용자에게 돌려주는 것이다.
Web Application Server
웹 애플리케이션 서버는 동적 컨텐츠를 생성하고 제공하는데 중점을 둔다. 동적 컨텐츠란 사용자의 요청에 따라 실시간으로 생성되는 컨텐츠로, 서버 사이드 스크립트나 데이터베이스 조회 결과 등을 포함할 수 있다.
웹 애플리케이션 서버는 복잡한 비즈니스 로직을 처리하고, 데이터베이스 연동, 세션 관리, 보안 기능 등과 같은 서비스를 제공한다.
차이점
- 컨텐츠 유형: 웹 서버는 주로 정적 컨텐츠를, 웹 애플리케이션 서버는 동적 컨텐츠를 처리한다.
- 기능과 복잡성: 웹 서버는 상대적으로 단순한 파일 서비스와 기본 보안, 로드 밸런싱 기능을 제공한다. 반면, 웹 애플리케이션 서버는 비즈니스 로직 처리, 데이터베이스 연동, 트랜잭션 관리 등 복잡한 기능을 제공한다.
- 사용 목적: 웹 서버는 사용자 요청에 따라 파일을 빠르게 전달하는 데 최적화되어 있는 반면, 웹 애플리케이션 서버는 사용자 요청에 따라 서버에서 데이터를 처리하고 결과를 돌려주는 동적인 작업을 수행합니다.
URL, URI, URN은 어떤 차이가 있나요?
URI(Uniform Resource Identifier)
URI는 리소스를 유일하게 식별하는 데 사용되는 표준화된 문자열의 집합이다. URI는 웹 리소스의 위치나 이름을 나타내는 데 사용되며, 가장 넓은 범위의 식별자이다. 이 용어는 URL과 URN을 포함하는 상위 개념으로, 리소스를 식별하기 위한 보편적인 방식을 제공 한다.
URL(Uniform Resource Locator)
URL 은 가장 흔히 사용되는 URI 의 형태로, 리소스가 실제로 존재하는 위치를 나타낸다.
URL 은 리소스의 접근하기 위한 구체적인 정보를 포함한다.
http://www.naver.com/index.html 는 http 프로토콜을 사용해 www.naver.com 도메인에 있는 index.html 파일을 가리킨다.
URN(Uniform Resource Name)
URN은 리소스의 위치에 대한 정보 없이 리소스를 유일하게 이름을 붙여 식별한다. URN은 리소스가 현재 어디에 있는지, 어떻게 접근해야 하는지를 설명하지 않는다. 대신, 리소스의 특정한 이름을 제공하며, 이 이름은 리소스의 위치가 변경되어도 변경되지 않는다.
정리
- URI 는 리소스를 식별하는 가장 광범위한 표현으로, URL, URN 모두를 포함한다.
- URL 은 리소스의 실제 위치를 나타내고, 웹에서 어떻게 해당 리소스에 접근할 수 있는지를 설명한다.
- URN 은 리소스의 위치나 접근 방법을 제공하지 않고, 리소스에 대한 유일한 이름을 제공한다.
