혼자 공부하는 네트워크 - 응용 계층 (DNS, HTTP)

개발지식

Aug 11, 2024

혼공학습단

혼공

혼공네트

혼공단 12기 5주차 학습 기록

응용 계층(Application Layer)의 개념과 DNS, HTTP에 대해 알아보자.

도메인과 네임 서버

네트워크상에서 통신할 때는 IP 주소를 이용해 상대 호스트를 특정한다. 그러나 IP 주소는 언제든지 변할 수 있고 모든 호스트의 IP 주소를 외우고 있긴 어렵기 때문에 일반적으로는 도메인 네임(domain name)이라는 정보를 사용한다. 우리가 특정 사이트에 접속하기 위해 사용하는 www.example.com과 같은 문자열 말이다.

도메인 네임과 IP 주소는 서로 대응된 관계로 도메인 네임 서버에서 관리된다.

도메인 네임 구조

도메인 네임은 점을 기준으로 뒤에서부터 계층적으로 구성되어 있다. 점(.)으로 표현되는 최상단에 위치한 루트 도메인(root domain)을 시작으로 최상위 도메인(TLD; Top-Level Domain) -> 2단계 도메인 -> 3단계 도메인 순으로 구성된다.

*일반적으로 루트 도메인은 생략되어 표기하지만, www.example.com.으로도 접속할 수 있다. com, net, org와 같은 도메인은 루트 도메인이 아니라 최상위 도메인이다.

도메인 계층은 보통 3~5단계 정도로 구성되며 도메인 네임을 모두 포함한 것을 전체 주소 도메인 네임(FQDN; Fully-Qualified Domain Name)이라고 한다.

도메인 네임 시스템(DNS)

DNS는 계층적이고 분산된 도메인 네임 서버에 대한 관리 체계이다. 대표적인 네임 서버 유형은 아래와 같다.

로컬 네임 서버(Local Name Server)

로컬 네임 서버는 클라이언트가 도메인 네임으로 IP 주소를 요청할 때 처음으로 응답하는 서버이다. 캐시에 해당 도메인 네임이 존재하는지 여부를 확인한 후, 존재하지 않다면 상위 네임 서버인 루트 네임 서버로 요청을 전달한다.

루트 네임 서버(Root Name Server)

루트 네임 서버는 DNS 계층 구조에서 최상단에 위치하며, 어떤 TLD 네임 서버를 조회해야 하는지 정보를 제공하는 역할을 한다.

e.g. 로컬 네임 서버로부터 www.example.com.에 대한 질의를 받았을 경우, .com TLD 네임 서버의 주소를 반환

TLD 네임 서버(Top-Level Domain Name Server)

TLD 네임 서버는 이름 그대로 TLD에 대한 권한을 가진 서버이다. 요청받은 도메인에 대한 책임 네임 서버의 정보를 제공한다.

e.g. .com TLD 네임 서버는 로컬 네임 서버에게 example.com 도메인에 대한 책임 네임 서버의 주소를 전달

책임 네임 서버(Authoritative Name Server)

책임 네임 서버는 특정 도메인 네임에 대해 최종적인 권한을 가지는 네임 서버로, 해당 도메인 네임에 대한 정확한 IP 주소를 제공한다.

e.g. www.example.com 책임 네임 서버는 93.184.216.34라는 IP 주소를 반환

질의 방법

도메인 네임에 대응하는 IP 주소를 알아내는 리졸빙 과정에 사용되는 질의 방식은 크게 두 가지로 나눌 수 있다.

재귀적 질의(Recursive query)

클라이언트가 로컬 네임 서버에 질의하면 루트 네임 서버 -> TLD 네임 서버 -> 책임 네임 서버 등을 순차적으로 조회하여 IP 주소를 얻는 방법이다. 해당 방법은 클라이언트가 단일 요청으로 필요한 IP 주소를 받게 되므로 중간 과정을 신경 쓸 필요가 없어 사용하기 편리하다는 장점이 있다.

반복적 질의(Iterative query)

클라이언트가 로컬 네임 서버에 질의하면 질의를 받은 서버가 직접적으로 다음 서버에 질의하는 것이 아닌, 다음 네임 서버의 주소를 반환하는 방식이다. 로컬 네임 서버가 질의하고 주소를 응답받는 과정을 반복하며 최종적인 IP 주소를 얻게 된다. 이 방식은 네임 서버들이 각자 역할을 분담하여 처리하므로, 특정 서버에 과부하가 걸리지 않는다는 장점이 있다.

두 방법 모두 각자의 장점이 있지만, 결국 도메인 네임을 리졸빙하기 위해서는 여러 단계를 거쳐야 하기 때문에 루트 네임 서버에 과부하가 생길 가능성이 있다. 그래서 실제로 네임 서버들은 기존에 응답받은 결과를 캐시로 저장하여 다음 질의에 사용하는 DNS 캐시(DNS cache)를 활용한다.

URI

위의 내용은 클라이언트가 메시지를 주고 받을 호스트를 특정하는 과정이라면, 송수신하려는 정보를 특정하기 위한 방식으로는 URI가 있다. URI는 자원을 식별할 수 있는 정보를 의미하며, 위치 기반 식별자인 URL과 이름 기반 식별자인 URN으로 나눌 수 있다.

자세한 내용은 이전에 포스팅한 글을 읽어보면 좋다.

URI와 URL의 차이

URL은 익숙한데, URI는? URL은 일상생활에서도 웹 주소를 가리킬 때 많이 쓰이기 때문에 개발자가 아닌 사람에게도 익숙한 용어이다. 개발 공부를 하다 보면 가끔 URI라는 용어도 혼용해서 사용하는 것 같은데, URL과 이름도 비슷한 URI는 도대체 무엇인가?

https://nxnaxx.github.io/web/uri-vs-url/uri-url-difference/

HTTP(Hypertext Transfer Protocol)

HTTP는 응용 계층에서 정보를 주고받기 위해 사용되는 프로토콜이다.

HTTP 특성

HTTP의 주요 특성은 크게 4가지가 있다.

요청-응답 기반 동작

클라이언트와 서버는 HTTP 요청 메시지와 응답 메시지를 주고받으면서 통신한다.

미디어 독립성

HTTP는 클라이언트와 서버 간 통신에서 주고받을 자원의 종류(media type/MIME type)에 제한을 두지 않고 독립적으로 동작할 수 있다.

MIME type에 관한 자세한 정보는 아래 포스팅에서 확인할 수 있다.

MIME(Multipurpose Internet Mail Extensions) 타입

MIME(Multipurpose Internet Mail Extensions) type MIME type은 인터넷상에서 전송되는 파일의 형식과 내용을 정의하는 표준으로, 이메일, 웹 브라우저, HTTP 및 기타 인터넷 프로토콜에서 파일 형식을 식별하는 데 사용된다.

https://nxnaxx.github.io/web/mime-type/mime-type/

스테이트리스(stateless)

각각의 HTTP 요청과 응답은 독립적으로 처리되므로 서버는 클라이언트의 이전 요청이나 상태를 기억하지 않는다. 그래서 서버의 부담은 줄어들고 네트워크 자원의 효율적 관리가 가능해진다.

요청과 응답을 독립적으로 처리한다는 것은 특정 클라이언트가 특정 서버에 종속되지 않는다는 것을 의미하며, 언제든 쉽게 서버를 추가하거나 다른 서버로 대체할 수 있다는 확장성(scalability)과 견고성(robustness)이 높다는 것을 나타낸다.

지속 연결(persistent connection)

TCP 상에서 동작하는 HTTP는 1.0 이하 버전에서는 매번 HTTP 요청-응답을 진행할 때, TCP 연결을 설정하고 해제하는 과정을 반복해야 했었다. (비지속 연결)

그러나 최근 사용되는 HTTP(1.1 이상)에서는 지속적인 연결로 한 번의 TCP 연결에서도 여러 개의 요청을 전송할 수 있어 네트워크 효율성이 크게 개선되었다.

HTTP 메시지 구조

HTTP 요청 메시지 예시로 메시지 구조를 파악해 보자.

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br

GET /index.html HTTP/1.1

요청 라인(Request Line)

HTTP 요청 메시지의 시작인 요청 라인은 ${메서드} ${요청 리소스 경로} ${사용 중인 HTTP 버전}으로 구성된다. 메서드는 GET, POST, PUT, DELETE 등이 대표적이고 요청 리소스 경로는 보통 URL 경로가 명시된다. 경로는 하위 경로가 없더라도 슬래시(/)로 표기해야 한다.

Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br

헤더(Header)

Host: 요청 대상 서버의 도메인 네임
User-Agent: 요청을 보내는 클라이언트 정보
Accept: 클라이언트가 받을 수 있는 콘텐츠 타입
Accept-Language: 클라이언트 선호 언어
Accept-Encoding: 클라이언트가 지원하는 콘텐츠 인코딩 방식

헤더는 위 내용 말고도 여러 종류가 있으며, HTTP 메시지에는 본문(Body)이 포함될 수도 있다.

HTTP 응답 메시지 구조도 간단하게 살펴보면,

HTTP/1.1 200 OK
Date: Sat, 10 Aug 2024 12:00:00 GMT
Server: Apache/2.4.29 (Ubuntu)
Last-Modified: Mon, 05 Jul 2024 15:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 305

<!DOCTYPE html>
<html>
<head>
    <title>Welcome to Example</title>
</head>
<body>
    <h1>Hello, World!</h1>
    <p>This is a simple HTML page.</p>
</body>
</html>

HTTP/1.1 200 OK

상태 라인(Status Line)

HTTP 응답 메시지의 시작인 상태 라인은 ${사용 중인 HTTP 버전} ${상태 코드} ${상태 메시지}로 구성된다.

Date: Sat, 10 Aug 2024 12:00:00 GMT
Server: Apache/2.4.29 (Ubuntu)
Last-Modified: Mon, 05 Jul 2024 15:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 305

헤더(Header)

Date: 응답이 생성된 날짜와 시간
Server: 응답을 처리한 서버 소프트웨어 정보
Last-Modified: 리소스가 마지막으로 수정된 날짜 및 시간
Content-Type: 응답 콘텐츠의 MIME 타입과 문자 인코딩 방식
Content-Length: 응답 본문의 바이트 길이

<!DOCTYPE html>
<html>
<head>
    <title>Welcome to Example</title>
</head>
<body>
    <h1>Hello, World!</h1>
    <p>This is a simple HTML page.</p>
</body>
</html>

본문(Body)

응답 본문에는 요청된 리소스 내용이 포함된다.

HTTP 메서드/상태 코드

HTTP 요청 메시지에서 사용할 수 있는 메서드와 응답 메시지에서의 상태 코드를 간단하게 정리해 보면 아래와 같다.

HTTP 메서드	설명
GET	리소스 조회
HEAD	리소스 헤더 정보 조회
POST	데이터를 서버에 전송, 리소스 생성
PUT	리소스 대체
PATCH	리소스 일부 수정
DELETE	리소스 삭제
CONNECT	리소스 양방향 연결 시작
OPTIONS	지원하는 HTTP 메서드 조회
TRACE	리소스에 대한 루프백 테스트 수행

HTTP 상태 코드	범주	설명
200	OK	요청이 성공함
201	Created	요청이 성공했고 새로운 리소스가 생성됨
202	Accepted	요청이 수락되었지만, 아직 처리되지 않음
204	No Content	요청이 성공했지만, 반환할 콘텐츠가 없음
301	Moved Permanently	요청한 리소스가 영구적으로 이동됨
302	Found	요청한 리소스가 임시적으로 이동됨
304	Not Modified	요청한 리소스가 수정되지 않았음
400	Bad Request	클라이언트 요청이 잘못됨
401	Unauthorized	인증이 필요하지만 제공되지 않음
403	Forbidden	요청한 리소스에 접근 권한이 없음
404	Not Found	요청한 리소스를 찾을 수 없음
405	Method Not Allowed	요청한 메서드를 지원하지 않음

각 메서드 사용 방법은 이전 포스팅에서 확인할 수 있다.

REST API란 무엇인가? 메서드 실습해보기

REST? REST API? REST는 HTTP를 기반으로 웹에서 데이터를 다루는 방식을 규정한 아키텍처이고 이 방식으로 설계된 API를 REST API라고 한다. REST는 데이터를 처리하는 방식을 URL로 정의하기 때문에 직관적으로 이해하기 쉽다는 특징이 있다. REST API 설계 원칙

https://nxnaxx.github.io/web/rest-api/rest-api-%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90/

기본 미션

MISSION 1

1. 도메인 네임과 네임 서버에 대한 설명으로 옳지 않은 것을 골라 보세요. (p.271)

(1) 8.8.8.8은 대표적인 공개 DNS 서버로, 구글이 관리합니다.
(2) 도메인 네임은 호스트를 특정할 수 있는 문자열 형태의 정보입니다.
(3) DNS는 계층적이고 분산된 도메인 네임에 대한 관리 체계이자 이를 관리하는 프로토콜입니다.
(4) www.example.com에서 루트 도메인은 com에 해당합니다.

정답: (4). 루트 도메인은 마지막에 .으로 표기하며 생략될 수 있다. com은 루트 도메인이 아니라 TLD(Top-Level Domain)이다.

MISSION 2

2. HTTP 상태 코드에 대한 설명으로 옳지 않은 것을 골라 보세요. (p.307)

(1) 300번대 상태 코드는 요청한 자원이 존재하지 않음을 의미합니다.
(2) 400번대 상태 코드는 클라이언트에 의한 에러를 의미합니다.
(3) 500번대 상태 코드는 서버에 의한 에러를 의미합니다.
(4) 200번대 상태 코드는 요청이 성공했음을 의미합니다.

정답: (1) 300번대 상태 코드는 리다이렉션 관련 상태 코드이다.

추가 미션

MISSION 1

Q. HTTP 요청 메시지 확인해 보기

Chrome에서 개발자 도구를 사용하면 HTTP 요청을 확인해 볼 수 있다.

macOS 기준, command+option+I 단축키를 눌러 개발자 도구를 열고, Network 탭을 선택한다. Network 탭에서 확인하고 싶은 요청을 클릭하면 오른쪽에 세부 정보가 나타나고, Headers 섹션에서 HTTP 요청 메시지의 메서드, URL, 헤더 등을 확인할 수 있다.

References

[📚book] 혼자 공부하는 네트워크

Table Of Contents