DNS와 자원

메시지를 주고받기 위해

메시지를 주고받는 송수신지 파악
IP주소, 도메인 네임
송수신하고자 하는 정보파악

도메인 네임과 네임 서버

IP 주소만으로 송수신지 특정하는 것은 번거로움

통신하고자 하는 모든 호스트의 IP 주소 기억하기 어려움
IP주소는 언제든지 바뀔 수 있음
그래서 상대 호스트 특정을 위해 도메인 네임 사용
도메인 네임 : 호스트의 IP 주소와 대응되는 문자열 형태의 호스트 특정 정보

네임서버(DNS서버)에서 관리
장점 : IP주소 변경되어도 도메인 네임 다시 대응하면 그만

네임서버는 공용 전화번호부

개인 전화번호부와도 같은 hosts 파일

도메인 네임과 IP 주소의 대응관계를 담은 파일

네임서버의 관리

도메인 네임의 구조로 알아보는 네임 서버 관리 방법

점(.)을 기준으로 계층적으로 분류

루트 도메인(.)
최상위 도메인(com,net 등)
2단계 도메인, 3단계 도메인, 4단계 도메인…
보통 3단계 나 4단계 도메인으로 유지하는것이 일반적

전체 주소 도메인 네임

전체 도메인 계층을 모두 포함하는 도메인 네임
FQDN까지 알면 비로소 하나의 호스트를 식별할 수 있게 됨

• Www.example.com.
• Www = 3단계 도메인
  Example = 2단계 도메인

서브 도메인

다른 도메인이 포함된 도메인
Google.com의 서브 도메인

• Mail.google.com

계층적 도메인 네임

이를 관리하기 위한 네임 서버 또한 계층적으로 관리
네임 서버는 전 세계 여러 군데 분산되어 위치

계층적이고 분산된 도메인 네임에 대한 관리를 체계적으로 하기 위한 체계

계층적 네임 서버

도메인 네임에 대응하는 IP 주소를 알아내는 과정

도메인 네임을 풀이한다
계층적이고 분산된 네임 서버들이 사용됨
주요 네임 서버의 유형 : 로컬 네임 서버, 루트 네임 서버, TLD(최상위 도메인) 네임 서버, 책임 네임 서버

로컬 네임 서버

클라이언트와 가장 맞닿아 있는 네임 서버
클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾게 되는 네임 서버
로컬 네임 서버의 주소는 일반적으로 ISP에서 할당
공개 DNS 서버 public DNS Server를 이용할 수도 있음

루트 네임 서버

루트 도메인을 관장하는 네임 서버
로컬 네임 서버가 대응되는 IP 주소를 모를 경우
TLD

TLD 네임 서버

TLD를 관리하는 네임 서버
DNS 질의에 대해 TLD의 하위 도메인 네임을 관리하는 네임 서버 주소 반환

• 하위 도메인 네임을 관리하는 책임 네임서버의 주소를 반환함.

책임 네임 서버

특정 도메인 영역을 관리하는 네임 서버

• 다른 네임 서버에게 떠넘기지 않고 곧바로 답할 수 있는 네임 서버
• 즉, 책임 네임 서버는 로컬 네임 서버가 마지막으로 질의하는 네임 서버

네임서버의 계층적 구조

네임 서버의 계층적 구조를 토대로 IP 주소를 알아내는 과정

재귀적 질의

클라이언트 -> 로컬 네임 서버 -> 루트 네임 서버 -> TLD 네임 서버 -> 책임 네임 서버에게 질의
최종 응답 결과를 역순으로 전달
클라이언트에게 최종적으로 도메인 네임에 대응되는 IP주소는 무엇인지 반환하게됨

반복적 질의

네임 서버에 일일이 질의-응답 반복
최종 응답 결과를 클라이언트에게 전달
응답을 받아낼 때까지 반복적으로 질의하는 것

DNS 캐시

지나치게 많은 질의응답이 이루어진다 (재귀적 질의, 반복적 질의 모두)

그래서 DNS 캐시를 사용한다

네임 서버들이 기존에 응답받은 결과를 임시로 저장햇다가 추후 같은 질의에 이를 활용

Dns 캐시를 저장하는 용도로만 사용되는 서버도 있음

DNS 캐시를 활용하면 더 짧은 시간 안에 원하는 IP 주소를 얻어낼 수 있음

DNS 캐시는 영원히 남아있는 것은 아님

그래서 대부분 로컬네임서버에서 응답을 받게됨

자원을 식별하는 URI

자원 - 네트워크 상의 메시지를 통해 주고받는 대상

두 호스트가 네트워크를 통해 서로 정보를 주고받을 때, 송수신하는 대상

• HTML 파일
• 이미지나 동영상 파일
• 텍스트파일 등

자원은 HTTP 요청 메시지의 대상이라 보기도

Http가 요청하는 대상을 ‘자원’이라고 합니다

자원을 식별할 수 있는 정보, URI

URL

위치를 이용해 자원을 식별

URN

이름을 기반으로 자원을 식별

• URL의 단점
  자원의 위치는 언제든 변할 수 있음
  즉 자원의 위치가 변경되면 기존 URL로는 자원을 식별할 수 없음
• URN의 장점
  자원에 고유한 이름을 붙이는 이름 기반 식별자이기에 자원의 위치와 무관하게 자원을 식별
• URN은 아직 URL만큼 널리 채택된 방식은 아님
  Urn:isbn:045140523

URL

오늘날 인터넷의 환경에서 자원 식별에 더 많이 사용되는 식별자

1. Scheme

URL의 첫 부분은 scheme은 ‘자원에 접근하는 방법’을 의미
일반적으로 사용할 프로토콜이 명시

• HTTP를 사용하여 자원에 접근할 때에는 "http://" 또는 "https://"를 사용

2. Authority

3. Path

Path에는 ‘자원이 위치한 경로’가 명시
자원의 위치는 경로 변수를 사용해 지정할 수 있습니다

4. Query

HTTP는 요청-응답 기반의 프로토콜

클라이언트는 서버에게 URI가 포함된 HTTP 요청 메시지를 보내고, HTTP 서버는 이에 대해 HTTP 응답 메시지를 보냄
이런 요청은 scheme, authority, path만으로 어떻게 표현할 수 있을까?
이럴때 사용가능한 쿼리 문자열 ,쿼리 파라미터 라고도 부름
물음표로 시작되는 <키,값> 혀앹의 데이터
앰퍼센트(&)로 여러 쿼리 문자열을 덧붙일 수 있음

5. Fragment

Fragment는 ‘자원의 한 조각을 가리키기 위한 정보’

HTML파일과 같은 자원에서 특정 부분을 가리키기 위해 사용

• Https://datatracker.ietf.org/doc/html/rfc3986
• Https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.2

DNS 레코드 타입

네임서버는 무엇을 저장할까

DNS 자원 레코드

• 이름
• 값
• TTL
• 레코드 유형 등

1.2.3.4로 접속가능한 웹서비스 배포, example.com 도메인 네임 구입

이를 1.2.3.4에 대응하고자 한다면?

-> example.com이 1.2.3.4에 대응됨을 네임 서버에 알려야함

가비아나 aws가서 등록하면 됨 => 프로젝트 aws 배포시알게되는 내용임

Dns 레코드 예제

레코드 유형

레코드 유형이 달라지면 레코드 이름과 값의 의미가 달라짐

Example.com에 대한 별칭으로 www.example.com. 사용

네임 서버에 example.com을 질의하면 1.2.3.4 응답

HTTP

HTTP의 4가지 핵심 특성

1. 요청-응답 기반 프로토콜

• 클라이언트-서버 구조 기반의 요청-응답 프로토콜
• HTTP 요청 메시지와 응답 메시지는 서로 다른 형태를 가짐

2. 미디어 독립적 프로토콜

• 자원의 특성을 제한하지 않고 주고받는 수단 역할만 수행
• MIME 타입으로 다양한 미디어 타입 지원 (타입/서브타입 형식)

3. 스테이트리스 프로토콜

• 서버가 클라이언트의 상태를 유지하지 않음
• 모든 요청은 독립적으로 처리
• 서버 부하 감소와 확장성 확보를 위한 설계

4. 지속 연결 프로토콜

• 초기: 비지속 연결 (요청마다 TCP 연결 수립/종료)
• 현재: 지속 연결(Keep-Alive) 방식 사용

HTTP 메시지 구조

기본 구성

1. 시작 라인
2. 필드 라인 (헤더)
3. 메시지 본문

주요 메서드

• GET: 자원 조회
• HEAD: 헤더만 조회
• POST: 자원 생성/처리 요청
• PUT: 자원 생성/덮어쓰기
• DELETE: 자원 삭제

상태 코드

• 1xx: 정보성 상태
• 2xx: 성공 (200 OK, 201 Created)
• 3xx: 리다이렉션
• 4xx: 클라이언트 에러 (401 Unauthorized, 404 Not Found)
• 5xx: 서버 에러 (500 Internal Server Error)

리다이렉션의 종류

영구적 리다이렉션

• 301: 메서드 변경 가능
• 308: 메서드 유지

일시적 리다이렉션

• 302: 메서드 변경 가능
• 303: GET으로 변경
• 307: 메서드 유지

HTTP의 발전 과정

HTTP/0.9 (1991)

• 단순한 프로토콜로 시작
• GET 메서드만 지원
• HTML 문서만 전송 가능
• 상태 코드 없음

HTTP/1.0 (1996)

• HEAD, POST 등 새로운 메서드 도입
• 헤더(Header) 개념 도입으로 메타데이터 전송 가능
• 상태 코드 도입으로 요청 결과 확인 가능
• 각 요청마다 새로운 TCP 연결 필요

HTTP/1.1 (1997)

• 현재까지 가장 널리 사용되는 버전
• 영구 연결(Persistent Connection) 도입으로 TCP 연결 재사용
• 파이프라이닝 도입으로 요청 병렬 처리 가능
• HOL(Head of Line) 블로킹 문제
  • 첫 번째 패킷 처리 지연 시 후속 패킷도 모두 지연
  • 성능 저하의 주요 원인

HTTP/2.0 (2015)

• 성능 개선에 초점
• 바이너리 프로토콜로 전환하여 처리 효율성 향상
• 헤더 압축으로 오버헤드 감소
• 서버 푸시 기능 도입
  • 클라이언트 요청 전 필요 리소스 선제적 전송
• 멀티플렉싱으로 HOL 블로킹 개선
  • 독립적인 스트림으로 병렬 통신
  • 각 스트림에서 요청-응답 쌍 처리

HTTP/3.0 (2022)

• TCP 대신 QUIC(UDP 기반) 프로토콜 사용
• 향상된 성능과 보안
  • 연결 설정 시간 단축
  • 네트워크 전환 시 연결 유지
• 비연결형 프로토콜 사용으로 더 빠른 데이터 전송
• 현재 점진적으로 도입 확대 중

HTTP 헤더와 기반 기술의 이해

HTTP 헤더 구조

• 필드이름과 필드값이 콜론(:)으로 구분

주요 요청 헤더

Host

• 요청을 보낼 대상 호스트 지정

User-Agent

• 클라이언트 프로그램 정보 포함
• 브라우저 종류, 버전 등 명시

Referer

• 현재 요청 이전 페이지의 URL
• 사용자 유입 경로 파악에 활용

Authorization

• 클라이언트 인증 정보 포함
• Basic 인증: username:password를 Base64 인코딩

주요 응답 헤더

Server

• 서버 소프트웨어 정보

Allow

• 허용된 HTTP 메서드 목록
• 주로 405 상태코드와 함께 사용

Location

• 리다이렉션 대상 URL
• 새로운 리소스 생성 시 해당 URL

공통 헤더

Content-Type

• 메시지 본문의 미디어 타입 지정
• 문자셋, 인코딩 방식 포함

Content-Length

• 메시지 본문의 크기(바이트)

HTTP 기반 기술

1. 캐시

• 응답 데이터 임시 저장
• 대역폭 절약, 응답 속도 향상
• 유효기간 관리: Expires, Cache-Control
• 신선도 검사: If-Modified-Since, If-None-Match

2. 쿠키

• 클라이언트 상태 정보 저장
• Set-Cookie: 서버가 쿠키 생성
• Cookie: 클라이언트가 쿠키 전송
• 주요 속성:
  • Domain: 쿠키 사용 가능 도메인
  • Secure: HTTPS 전송 제한
  • HttpOnly: JavaScript 접근 제한

3. 콘텐츠 협상

• 최적화된 리소스 표현 제공
• 주요 헤더:
  • Accept: 선호 미디어 타입
  • Accept-Language: 선호 언어
  • Accept-Encoding: 선호 압축 방식
• 우선순위: q값으로 표현 (0~1)