DNS와 HTTP의 특성

이선우·2024년 8월 25일

DNS

DNS의 개념에 대해서 말씀드리면 주소창에 google.com 같은 주소를 검색할 때에 컴퓨터가 이런 문자로 된 주소를 이해할 수 있도록 google.com이라고 입력하면, IP주소로 바꿔주는 역할을 하는 시스템입니다.

예를 들어, 전화번호부에서 전화를 하고 싶은 이름을 검색하면 전화번호를 알 수 있듯이 DNS도 웹사이트 이름을 입력하면, DNS가 그 이름에 해당하는 IP 주소를 찾아서 알려주는 역할을 합니다.

DNS는 단순히 하나의 서버가 일을 하는 게 아니라, 여러 단계로 나눠져 있습니다. 이런 식으로 여러 단계로 나뉜 이유는 인터넷이 너무 커서 모든 정보를 한 서버에 다 저장할 수 없기 때문에 여러 서버가 나눠서 정보를 관리하고 있어.

루트 네임 서버

인터넷의 최상위 서버로 사용자가 웹사이트에 접속하려고 할 때, 가장 먼저 이 루트 서버에 물어보는 겁니다. 이 서버는 사용자가 찾는 웹사이트가 어디에 있는지 정확히는 모르지만, 다음에 물어볼 서버를 알려줍니다.

TLD 서버

이건 최상위 도메인 서버입니다. 예를 들어, .com, .kr, .edu 같은 도메인을 관리하는 서버입니다. 루트 서버가 "이 웹사이트는 .com에 있어"라고 알려주면, 이 TLD 서버에 가서 "그럼 구체적으로 어디에 있어?"라고 물어보게 됩니다.

Authoritative DNS 서버

마지막으로 이 서버는 우리가 찾는 웹사이트의 실제 IP 주소를 가지고 있습니다. 그러니까 이 서버가 최종적으로 "구글은 여기 있어! 이 IP 주소를 써!"라고 답해주게 됩니다.

DNS 질의 방식

DNS에는 반복적 질의 방식과 재귀적 질의 방식이 있습니다.

반복적 질의: 사용자가 루트 서버한테 물어보고, 루트 서버가 "난 잘 모르겠는데, 이 서버한테 물어봐"라고 하면, 사용자가 직접 그 서버한테 또 물어보는 방식입니다. 계속 사용자가 직접 물어보는 거라서 반복적 질의라고 한다고 합니다.
재귀적 질의: 이건 사용자가 처음 물어본 DNS 서버가 대신 다 알아봐 주는 방식입니다. 사용자가 한 번만 물어보면 되고, 나머지는 서버가 알아서 다 해주게 됩니다. 그래서 이걸 재귀적 질의라고 불러.

DNS 레코드

DNS 서버에는 여러 가지 정보가 저장되어 있는데 이 정보를 DNS 레코드라고 부릅니다.

A 레코드: 도메인 이름에 대한 IPv4 주소를 저장합니다. 이게 우리가 주로 사용하는 IP 주소 형식입니다.
AAAA 레코드: 이건 IPv6 주소를 저장합니다. IPv6는 좀 더 긴 형식의 IP 주소입니다.
CNAME 레코드: 도메인의 별칭을 저장합니다. 예를 들어 www.example.com이 실제로는 example.com의 다른 이름이라면, 이걸 CNAME 레코드가 저장합니다.
NS 레코드: 이건 도메인을 관리하는 네임 서버의 정보를 저장합니다. 예를 들어, google.com을 관리하는 네임 서버가 어디 있는지를 이 레코드가 알려줘.

DNS 캐싱

DNS 캐싱은 우리가 자주 방문하는 웹사이트의 IP 주소를 미리 저장해 두는 겁니다. 이렇게 하면 웹사이트에 접속할 때마다 DNS 서버에 물어볼 필요가 없어서 더 빠르게 접속할 수 있습니다. 이 캐시된 정보는 일정 시간 동안만 유효합니다. 이 시간을 TTL이라고 하는데, 시간이 지나면 캐시가 만료되고 다시 물어봐야합니다.

이런 식으로 DNS는 우리가 매일 인터넷을 편리하게 사용할 수 있게 도와주는 시스템입니다. 평소에는 잘 느끼지 못하지만, DNS로 인해서 우리는 숫자로 된 IP 주소를 외우지 않고도 편하게 웹사이트를 이용할 수 있습니다.

자원과 자원의 식별

네트워크에서 자원이란?

네트워크에서의 자원은 네트워크를 통해 주고받을 수 있는 모든 정보를 말합니다. 예를 들어, 우리가 웹사이트를 방문할 때 보는 HTML 파일, 웹에서 다운로드하는 이미지나 동영상, JSON 파일 같은 것들이 모두 자원에 속합니다. 간단히 말해서, 인터넷에서 우리가 요청하고 받을 수 있는 모든 데이터가 자원입니다.

네트워크에서 자원을 사용하려면, 이 자원을 식별할 수 있어야 합니다. 자원이 어디에 있는지, 그리고 그 자원이 무엇인지를 정확하게 지정해줘야 하기 때문에 등장한 개념이 URI입니다.

URI(Uniform Resource Identifier)

자원을 식별할 수 있는 문자열로 쉽게 말해, 인터넷 상의 자원을 가리킬 수 있는 주소 같은 역할을 하고 이 URI는 크게 두 가지로 나뉩니다.

URL(Uniform Resource Locator)
자원의 위치를 기반으로 식별하며 흔히 보는 웹 주소가 바로 URL이야. 예를 들어, https://www.example.com 같은 게 URL이며 이 주소는 자원이 어디에 있는지를 알려줍니다.
URN(Uniform Resource Name)
자원의 이름을 기반으로 식별합니다. 위치는 상관없이, 그 자원의 고유한 이름을 사용하는 방식입니다. 하지만 일상적으로는 URL이 더 많이 사용돼서 URN은 상대적으로 덜 알려져 있어.

URL의 구성 요소

URL을 보면, 그냥 긴 문자열처럼 보일 수 있는데, 사실은 여러 구성 요소가 있습니다.

Scheme: 주로 프로토콜 이름이 들어가는 부분으로 예를 들어, http://, https://, ftp:// 같은 게 여기에 들어갑니다. 이 부분은 브라우저에게 어떤 방식으로 자원에 접근해야 하는지를 알려줍니다.
Authority: 이 부분은 주로 도메인 이름과 포트 번호로 구성됩니다. 예를 들어 www.example.com:80에서 www.example.com은 호스트 이름(도메인 이름), :80은 포트 번호입니다. 여기서는 Authority가 자원이 어디에 있는지를 더 구체적으로 지정해줍니다.
Path: 이건 자원이 서버 내에서 어디에 있는지를 나타내는 경로입니다. 예를 들어 https://www.example.com/images/logo.png에서 /images/logo.png가 경로입니다. 서버 안에서 그 자원이 저장된 위치를 알려줍니다.
Query: 이건 주로 서버에 전달하는 추가적인 정보로 예를 들어, 검색할 때 https://www.google.com/search?q=example처럼 URL 뒤에 ?q=example 같은 형식이 Query로 서버에 전달될 정보입니다.
Fragment: 이건 자원의 특정 부분을 가리킬 때 사용되며 예를 들어 긴 문서의 특정 섹션으로 바로 이동하고 싶을 때 사용합니다. URL 끝에 #section1 같은 형식으로 붙어. 예를 들어 https://www.example.com/page#section1 에서 #section1입니다.

URL 해석

URL은 처음엔 복잡해 보일 수 있지만, 위의 구성 요소들을 알고 나면 해석하기가 쉬워진다고 합니다.
https://john.doe@www.example.com:123/forum/questions/?tag=networking&order=newest#top이라는 URL을 보면, 이 안에는 다양한 정보가 들어있어:

Scheme: https
Authority: john.doe@www.example.com:123 (여기서 john.doe는 사용자 정보, www.example.com은 호스트, 123은 포트 번호야)
Path: /forum/questions/
Query: ?tag=networking&order=newest (여기서 tag=networking과 order=newest가 서버에 전달될 정보야)
Fragment: #top (이건 자원의 특정 부분, 즉 페이지의 맨 위를 가리키는 거지)

웹 서버와 웹 어플리케이션 서버

서버와 클라이언트의 기본 개념

서버와 클라이언트의 관계에 대해서 간단하게 말해보자면 클라이언트는 요청을 보내는 쪽이고, 서버는 그 요청에 대해 응답을 보내는 쪽입니다. 예를 들어, 우리가 웹 브라우저에서 google.com을 입력하면, 브라우저는 클라이언트가 되고, 구글의 서버는 우리에게 페이지를 보여주기 위해 응답을 보내는 서버가 되는 겁니다.

웹 서버와 웹 애플리케이션 서버의 차이

웹 서버(Web Server): 주로 정적인 자원을 제공합니다. 여기서 정적인 자원이라는 건, 예를 들어 HTML 파일, 이미지, 동영상처럼 언제, 어디서, 누가 보든지 내용이 변하지 않는 파일들을 말합니다. 이런 파일들은 이미 서버에 저장돼 있고, 요청이 오면 그대로 제공되기만 하면 됩니다. 그래서 웹 서버는 단순히 클라이언트의 요청에 따라 이런 정적인 파일들을 제공하는 역할을 합니다.

웹 애플리케이션 서버(WAS: Web Application Server): 반면에, WAS는 동적인 자원을 제공합니다. 동적인 자원이란 사용자가 누구인지, 또는 언제, 어디서 요청을 하느냐에 따라 내용이 달라질 수 있는 데이터를 말합니다. 예를 들어, "오늘의 날씨는 20도입니다"와 같이, 사용자가 있는 위치나 시간에 따라 변할 수 있는 정보를 제공하는 겁니다. WAS는 이런 정보를 생성하기 위해 데이터베이스와 상호작용해서, 사용자 맞춤형 데이터를 만들어 클라이언트에게 제공합니다.

웹 서버와 WAS의 협력
현대적인 웹 서비스는 웹 서버와 WAS가 서로 협력해서 동작합니다. 웹 서버는 빠르게 정적인 자원을 제공하고, WAS는 필요한 경우 데이터베이스와 상호작용해 동적인 정보를 생성합니다. 이렇게 역할을 분담하면, 전체 시스템이 더 효율적으로 작동하고, 과도한 부하도 막을 수 있고 또한, 보안적인 측면에서도 이점이 있습니다. 왜냐하면, 정적인 자원과 동적인 자원이 분리되어 있기 때문에 각각의 보안을 별도로 관리할 수 있기 때문입니다

HTTP의 특성

HTTP의 기본 개념

먼저, HTTP는 HyperText Transfer Protocol의 약자야. 이 프로토콜은 주로 웹 브라우저와 웹 서버 간에 데이터를 주고받을 때 사용됩니다. 예를 들어, 사용자가 웹사이트를 방문할 때, 브라우저는 HTTP를 사용해서 웹 서버에 "이 페이지를 보여줘!"라고 요청을 보내고, 서버는 그 요청에 응답해서 페이지를 보내줍니다. 이 과정은 요청-응답 기반의 클라이언트-서버 구조로 작동합니다. 여기서 클라이언트는 요청을 보내는 쪽(보통 웹 브라우저), 서버는 그 요청에 응답하는 쪽입니다.

HTTP의 주요 특성

미디어-독립적
HTTP는 어떤 형태의 데이터든지 전송할 수 있습니다. 예를 들어, HTML 문서, 이미지, 동영상, JSON 데이터, XML 파일 등 어떤 데이터라도 HTTP를 통해 전송할 수 있습니다. 그래서 HTTP는 매우 유연한 프로토콜로, 다양한 종류의 데이터를 처리할 수 있어.
비연결성
HTTP는 기본적으로 비연결성 프로토콜입니다. 클라이언트가 서버에 요청을 보내고, 서버가 응답을 보내면 그 연결이 바로 끊어집니다. 이렇게 하면 서버의 자원을 효율적으로 사용할 수 있습니다. 그 이유는 연결을 계속 유지하면 서버 자원이 많이 소모되기 때문입니다. 하지만, 최근의 HTTP/1.1부터는 이러한 비연결성을 개선하기 위해 지속 연결(Keep-Alive) 기능이 추가되었습니다. 이 기능 덕분에, 한 번 연결을 맺으면 그 연결을 유지하면서 여러 요청을 보낼 수 있게 되었습니다.
스테이트리스:
HTTP는 스테이트리스 프로토콜입니다. 이는 서버가 클라이언트의 상태를 기억하지 않는다는 뜻입니다. 예를 들어, 사용자가 웹사이트에서 여러 페이지를 방문해도, 서버는 이전 페이지에서 사용자가 뭘 했는지 기억하지 않습니다. 이 덕분에 서버 확장이 용이해지고, 사용자가 여러 서버에 요청을 보내더라도 문제가 없게 됩니다.
지속 연결 (Keep-Alive):
앞서 말한 것처럼, HTTP/1.1부터는 지속 연결 기능이 추가됐습니다. 이 기능은 한 번 연결된 상태에서 여러 개의 요청과 응답을 주고받을 수 있게 해줍니다. 이렇게 하면 매번 새로운 연결을 맺기 위해 시간을 낭비하지 않아도 돼서, 네트워크 혼잡을 줄이고, 페이지 로딩 속도도 빨라지게 됩니다.

HTTP 버전의 진화

HTTP 0.9: 가장 초기 버전으로, GET 메서드만 지원하고 비지속 연결이었으며 기능이 매우 제한적이었습니다.
HTTP 1.0: 다양한 요청 방법과 헤더를 지원하게 되었지만여전히 비연결성 프로토콜이었어습니다.
HTTP 1.1: 지속 연결 기능이 추가되었고 한 번 연결된 상태에서 여러 요청을 보낼 수 있는 기능이 들어갔습니다.
HTTP 2.0: 성능이 크게 개선되었습니다. 예를 들어, 요청이 꼭 순서대로 처리될 필요가 없어졌고, 헤더 데이터를 압축해서 전송할 수 있게 됐습니다.
HTTP 3.0: 최신 버전으로, TCP 대신 UDP 기반 프로토콜인 QUIC을 사용해 더 빠르고 안전한 연결을 제공합니다

이선우

백엔드 개발자 준비생

이전 포스트

스프링+MySQL+RDS+EC2 배포과정

다음 포스트