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

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

도메인과 네임 서버

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

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

도메인 네임 구조

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

도메인 계층은 보통 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으로 나눌 수 있습니다.

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

---

HTTP(Hypertext Transfer Protocol)

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

HTTP 특성

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

1. 요청-응답 기반 동작
   클라이언트와 서버는 HTTP 요청 메시지와 응답 메시지를 주고받으면서 통신합니다.

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

   
   

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

   

   MIME(Multipurpose Internet Mail Extensions) 타입

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

   https://www.raey-dev.com/post/mime-type

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

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

4. 지속 연결(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

요청 라인(Request Line)

HTTP 요청 메시지의 시작인 요청 라인은 메서드+요청 리소스 경로+사용 중인 HTTP 버전으로 구성됩니다.

// {메서드} {요청 리소스 경로} {사용 중인 HTTP 버전}  
GET /index.html HTTP/1.1

메서드는 GET, POST, PUT, DELETE 등이 대표적이고 요청 리소스 경로는 보통 URL 경로가 명시됩니다. 경로는 하위 경로가 없더라도 /(슬래시)로 표기해야 합니다.

헤더(Header)

• Host: 요청 대상 서버의 도메인 네임

• User-Agent: 요청을 보내는 클라이언트 정보

• Accept: 클라이언트가 받을 수 있는 콘텐츠 타입

• Accept-Language: 클라이언트 선호 언어

• Accept-Encoding: 클라이언트가 지원하는 콘텐츠 인코딩 방식

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

헤더는 위 내용 말고도 여러 종류가 있으며, 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>

상태 라인(Status Line)

HTTP 응답 메시지의 시작인 상태 라인은 사용 중인 HTTP 버전+상태 코드+상태 메시지로 구성됩니다.

// {사용 중인 HTTP 버전} {상태 코드} {상태 메시지}  
HTTP/1.1 200 OK

헤더(Header)

• Date: 응답이 생성된 날짜와 시간

• Server: 응답을 처리한 서버 소프트웨어 정보

• Last-Modified: 리소스가 마지막으로 수정된 날짜 및 시간

• Content-Type: 응답 콘텐츠의 MIME 타입과 문자 인코딩 방식

• Content-Length: 응답 본문의 바이트 길이

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

본문(Body)

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

<!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 메서드/상태 코드

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

---

기본 미션

MISSION 1

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

정답: (4)

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

MISSION 2

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

정답: (1)

300번대 상태 코드는 리다이렉션 관련 상태 코드입니다.

---

추가 미션

MISSION 1

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

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

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

---

References

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