네트워크 스터디 6주차

msgo·2025년 11월 2일
네트워크스터디

DNS와 자원 식별 체계 정리

인터넷 상의 통신은 기본적으로 클라이언트(Client) 와 서버(Server) 간의 요청(Request)과 응답(Response)으로 이루어진다.
이때 메시지를 주고받는 대상을 식별하기 위해 IP 주소뿐 아니라 도메인 네임(Domain Name) 이 사용된다.

도메인 네임 시스템(Domain Name System, DNS)은
사람이 이해하기 쉬운 도메인 네임을 IP 주소로 변환하는 구조다.
네트워크 상에서 자원은 IP 주소로 통신하지만,
이 주소는 기억하기 어렵기 때문에 문자열 형태의 도메인 네임을 사용한다.
이러한 구조는 전 세계적으로 분산 관리되어 있으며,

1. 도메인 네임과 네임 서버

IP 주소는 숫자로 구성되어 사람이 기억하기 어렵다.
이를 사람이 읽기 쉬운 문자열 형태로 표현한 것이 도메인 네임이다.
예를 들어 203.0.113.12 대신 example.com 과 같은 형태를 사용한다.

도메인 네임과 IP 주소의 관계는 네임 서버(Name Server) 가 관리한다.
이 중 도메인 네임을 관리하고 IP 주소로 변환해주는 서버를 DNS 서버(Domain Name System Server) 라고 한다.

도메인 네임은 점(.)을 기준으로 계층적 구조를 가진다.
예를 들어 다음과 같이 구성된다:

www.example.com
└── www: 호스트 네임 (Host Name)
└── example: 2단계 도메인
└── com: 최상위 도메인 (TLD, Top Level Domain)

이처럼 루트 도메인 → 최상위 도메인(TLD) → 2단계 도메인 → 하위 도메인 순으로 이루어진 전체 주소를
FQDN (Fully Qualified Domain Name) 이라고 부른다.

이 계층적 구조를 효율적으로 관리하기 위해 DNS 서버 또한 계층적이고 분산된 형태로 구성된다.

2. DNS 서버의 종류

도메인 네임을 IP로 변환하는 과정(리졸빙, resolving)에는 네 가지 주요 네임 서버가 관여한다.

구분역할
로컬 네임 서버 (Local Name Server)사용자가 가장 먼저 접근하는 서버. 일반적으로 ISP나 조직 내에서 제공됨.
루트 네임 서버 (Root Name Server)도메인 구조의 최상위 서버로, 전 세계에 약 13개가 존재. TLD 서버의 위치 정보를 제공.
TLD 네임 서버 (Top Level Domain).com, .org, .kr 등 최상위 도메인의 정보를 관리.
책임 네임 서버 (Authoritative Name Server)해당 도메인(IP 매핑 정보)의 실제 데이터를 보유한 서버. 최종 응답 제공.

하나의 네임 서버 장애가 전체 인터넷 서비스에 영향을 주지 않도록 설계되어 있다.

3. 리졸빙 과정 (DNS 질의 방식)

도메인 네임을 IP로 변환하는 질의 방식에는 재귀적 질의(Recursive Query) 와 반복적 질의(Iterative Query) 가 있다.

3-1. 재귀적 질의

클라이언트가 로컬 네임 서버에 요청을 보내면,
로컬 서버가 대신 루트 → TLD → 책임 서버까지 직접 질의하고 최종 결과를 클라이언트에게 반환한다.

사용자는 한 번만 요청하면 되므로 편리하지만, 로컬 서버의 부하가 높아진다.

3-2. 반복적 질의

로컬 서버가 루트 서버에 질의하면 루트 서버는 “다음 서버 주소”만 알려준다.
이후 로컬 서버가 TLD 서버 → 책임 서버로 순차적으로 질의한다.

리졸빙 과정은 최대 8단계의 요청·응답을 거칠 수 있다.
이로 인해 응답 시간이 길어질 수 있기 때문에,
DNS 캐시(DNS Cache) 가 도입되었다.

DNS 캐시와 TTL(Time To Live)
DNS 캐시는 한 번 조회된 도메인의 결과(IP 주소)를
일정 시간 동안 임시 저장하는 기능이다.
이 저장 기간을 결정하는 값이 TTL(Time To Live) 이다.

TTL은 해당 도메인 정보를 제공한 책임 네임 서버에서 정의한다.
즉, 도메인 관리자가 DNS 레코드 설정 시 TTL 값을 지정하면,
모든 하위 DNS 서버는 이 TTL을 기준으로 캐시를 유지한다.

짧은 TTL은 빠른 갱신에 유리하지만, 조회 빈도가 높아지면 네트워크 부하가 증가할 수 있다.
긴 TTL은 부하를 줄이지만 IP 변경이 즉시 반영되지 않는다.

4. URI, URL, URN

인터넷 상의 자원(Resource)을 식별하기 위한 통합 개념은 URI(Uniform Resource Identifier) 이다. URI는 다시 URL과 URN으로 구분된다.

구분의미예시
URL자원의 위치(Location) 기반 식별https://www.example.com/images/logo.png
URN자원의 이름(Name) 기반 식별urn:isbn:0451450523

URL은 위치 정보를 기반으로 하며,
스키마(scheme), 권한(authority), 경로(path), 쿼리(query), 프래그먼트(fragment)로 구성된다.

https://example.com:443/path/data.html?user=kim#section2

스키마: 자원에 접근하는 방법 (예: http, https, ftp)

권한(Authority): 자원이 속한 호스트 (도메인 네임 또는 IP 주소)

경로(Path): 자원이 위치한 서버 내 경로

쿼리(Query): ? 이후에 붙는 데이터 전달용 문자열

프래그먼트(Fragment): # 이후의 특정 위치(자원의 조각)

URN은 자원의 위치와 무관하게 고유하게 식별하는 체계로,
위치가 변하더라도 동일 자원을 가리킬 수 있다.
다만 현재는 대부분의 시스템이 URL 기반으로 동작한다.

자원

자원(Resource)은 네트워크를 통해 송수신되는 대상이다.
HTML 문서, 이미지, 영상, JSON 데이터 등 모든 전송 가능한 데이터가 이에 포함된다.

HTTP 프로토콜은 이러한 자원을 요청(request)하고 응답(response)하는 구조를 가진다.
클라이언트는 URL이 포함된 요청 메시지를 전송하며,
서버는 이에 대한 응답 메시지를 반환한다.

프래그먼트(fragment) 는 자원의 일부분을 가리키기 위한 정보이며,
HTML뿐 아니라 비디오 스트리밍에서도 사용될 수 있다.
예를 들어 MPEG-DASH나 HLS와 같은 영상 스트리밍 프로토콜에서는
비디오가 수백 개의 세그먼트(조각)로 나뉘며,
각 조각이 URL의 일부로 접근된다.
이는 대역폭 적응 및 캐싱 효율을 높이기 위한 설계다.

비디오 스트리밍은
“전체 영상을 한 번에 전송”하는 대신
작은 단위(세그먼트, Segment) 로 나누어 전송한다.
이때 각 세그먼트는 몇 초(예: 2~10초) 길이의 영상 조각이다.
이런 세그먼트를 관리하는 방식이 바로 HTTP 기반 스트리밍 프로토콜 이며,
대표적으로 다음 두 가지가 있다.

프로토콜주요 특징표준
HLS (HTTP Live Streaming)애플에서 개발, .m3u8 플레이리스트 사용RFC 8216
MPEG-DASH (Dynamic Adaptive Streaming over HTTP)국제 표준, XML 기반 MPD 파일 사용ISO/IEC 23009-1

HTML에서 #fragment 는 문서의 특정 위치를 가리키기 위해 사용된다
하지만 비디오 스트리밍에서는 “데이터 조각”을 의미하게 된다.

예를 들어 HLS에서는 다음과 같이 구성된다.

playlist.m3u8
├─ segment1.ts
├─ segment2.ts
├─ segment3.ts

프래그먼트의 역할

역할설명
지연 최소화전체 영상을 다운로드하지 않고 일부 조각만 받아 즉시 재생할 수 있다.
품질 적응네트워크 속도에 따라 낮은 비트레이트 조각 또는 높은 비트레이트 조각을 선택한다.
캐싱 효율 향상조각 단위로 CDN에서 캐시되므로, 인기 있는 구간만 효율적으로 재사용할 수 있다.
오류 복구 용이특정 세그먼트가 손상돼도 나머지 구간에 영향을 주지 않는다.

HTTP의 핵심 구조와 동작 원리

HTTP(HyperText Transfer Protocol)는 응용 계층에서 동작하는 통신 프로토콜로, 웹에서 정보를 주고받기 위한 기반이 되는 구조다. 클라이언트와 서버 간의 상호작용은 요청(request)과 응답(response)으로 이루어지며, 이 단순한 구조는 웹의 확장성과 유연성을 가능하게 하는 핵심 요소다.

5. HTTP의 네 가지 주요 특성

  1. 요청과 응답 기반
    HTTP는 요청과 응답 메시지를 주고받는 구조로 동작한다. 클라이언트가 서버에 요청 메시지를 전송하면, 서버는 이에 대한 응답 메시지를 반환한다. 이로써 클라이언트는 서버의 자원을 요청하고, 서버는 해당 자원을 전송하거나 상태를 전달한다.

  2. 미디어 독립성
    HTTP는 전송되는 자원의 종류와 특성에 제약이 없다. HTML, JSON, 이미지, 동영상 등 어떤 형태의 데이터든 전송할 수 있으며, 이러한 자원의 형태를 미디어 타입(Media Type) 으로 정의한다.
    미디어 타입은 일반적으로 타입/서브타입 형태로 표현된다. 예를 들어 text/html, application/json, image/png 등이 있다. 이로써 HTTP는 자원의 내용과 무관하게 데이터를 전달하는 범용 인터페이스 역할을 수행한다.

  3. 상태 비유지(Stateless)
    HTTP는 상태를 유지하지 않는 프로토콜이다. 서버는 이전 요청에 대한 정보를 저장하지 않으며, 모든 요청은 독립적으로 처리된다.
    이는 대규모 트래픽 환경에서 서버의 부담을 줄이고, 장애 복구나 확장 시 유연성을 확보하는 설계적 이점이 있다. 만약 상태를 유지해야 했다면, 클라이언트는 특정 서버에 종속되어 서버 장애 시 세션 정보를 잃게 되었을 것이다. 이러한 제약을 없애기 위해 HTTP는 클라이언트 상태를 서버 외부에서 관리하도록 설계되었다.

  4. 지속 연결(Persistent Connection)
    초창기 HTTP(0.9~1.0)는 요청과 응답이 완료되면 TCP 연결을 종료하는 비지속(non-persistent) 구조였다. 이 방식은 요청마다 새로운 TCP 연결을 수립해야 하므로 비효율적이었다.
    HTTP/1.1부터는 Connection: keep-alive를 통해 지속 연결(persistent connection) 을 지원한다. 하나의 TCP 연결에서 여러 요청과 응답을 연속적으로 처리할 수 있으며, 이는 지연(latency)을 줄이고 성능을 향상시킨다.

6. HTTP 메시지 구조

HTTP 메시지는 크게 세 부분으로 구성된다.
시작 라인(Start Line), 필드 라인(Header Line), 메시지 본문(Message Body) 이다.
필드 라인은 0개 이상 존재할 수 있으며, 본문은 상황에 따라 생략될 수도 있다. 필드 라인과 본문 사이에는 반드시 빈 줄(Empty Line) 이 존재한다.

(1) 시작 라인

시작 라인은 요청과 응답 메시지에서 각각 다르게 구성된다.

  • 요청 메시지(Request Message)

    메서드(Method) 요청대상(Request Target) HTTP버전

    예시:

    GET /index.html HTTP/1.1

    • 메서드(Method): 서버가 수행할 동작을 지정한다.

      메서드설명
      GET자원을 요청
      POST데이터를 전송
      PUT자원을 생성 또는 대체
      DELETE자원을 삭제
      PATCH자원의 일부 수정

    • 요청 대상(Request Target): 요청할 자원의 경로(URL)를 의미한다. 예를 들어 /api/user?id=1 형태로 지정할 수 있다.

    • HTTP 버전: 사용 중인 HTTP의 버전을 나타낸다. (예: HTTP/1.1)

  • 응답 메시지(Response Message)

    HTTP버전 상태코드(Status Code) 이유구문(Reason Phrase)

    예시:

    HTTP/1.1 200 OK

    • 상태 코드(Status Code): 요청 처리 결과를 나타내는 세 자리 정수 값.

      코드의미설명
      200OK요청 성공
      201Created자원 생성 성공
      400Bad Request잘못된 요청
      404Not Found요청 자원 없음
      500Internal Server Error서버 내부 오류

    • 이유 구문(Reason Phrase): 상태 코드에 대한 짧은 설명.

(2) 필드 라인(Header Line)

필드 라인은 요청과 응답 모두에 존재하며, 통신에 필요한 부가 정보를 제공한다.
각 헤더는 이름: 값 형태로 구성된다.
예시:

Content-Type: application/json
User-Agent: Mozilla/5.0

헤더는 크게 다음과 같이 구분된다.

  • 요청 헤더(Request Header): 클라이언트 관련 정보 (예: User-Agent, Accept)
  • 응답 헤더(Response Header): 서버 관련 정보 (예: Server, Set-Cookie)
  • 엔티티 헤더(Entity Header): 본문 데이터에 관한 정보 (예: Content-Length, Content-Type)

(3) 메시지 본문(Message Body)

메시지 본문은 요청 또는 응답에 포함될 실제 데이터가 담기는 부분이다.
본문은 필수적이지 않으며, 주로 POST, PUT, PATCH 요청이나 JSON, HTML 문서, 파일 전송 등에 사용된다.
본문의 데이터 유형은 Content-Type 헤더로 명시된다.

7. HTTP의 버전별 발전

버전주요 특징
HTTP/0.9단일 라인 요청, HTML만 전송 가능
HTTP/1.0헤더 도입, MIME 타입 지원
HTTP/1.1지속 연결, 파이프라이닝 지원
HTTP/2멀티플렉싱, 헤더 압축
HTTP/3UDP 기반 QUIC 프로토콜 사용, 지연 감소

HTTP의 진화는 단순한 요청-응답 모델의 확장 과정으로 볼 수 있다. 각 버전은 네트워크 병목, 지연 시간, 효율성 문제를 해결하기 위해 발전해왔다.

HTTP/3에서 사용되는 QUIC(Quick UDP Internet Connections) 은 TCP를 대체하는 전송 계층 프로토콜로, UDP 위에서 동작하면서 TCP의 흐름 제어와 신뢰성 보장 기능을 자체적으로 구현한다.
흐름제어의 핵심은 스트림 단위 제어다.
기존 HTTP/2는 TCP 위에서 멀티플렉싱을 수행했지만, 하나의 패킷 손실이 전체 연결의 지연을 초래했다(Head-of-Line Blocking).
반면 QUIC은 연결 내 여러 스트림(stream) 을 독립적으로 관리한다. 각 스트림은 별도의 시퀀스 번호와 흐름제어 윈도우를 가지며, 하나의 스트림에서 손실이 발생하더라도 다른 스트림의 전송에는 영향을 주지 않는다.

profile
msgo
이전 포스트

Agent

다음 포스트

네트워크 스터디 7주차-1

0개의 댓글