DNS와 URI/URL

도메인 네임과 DNS

• 호스트의 IP 주소는 언제든지 바뀔 수 있음 -> "도메인 네임" 사용의 이유
• 도메인 네임과 그에 대응하는 IP 주소는 "네임 서버"에서 관리
  • 네임서버 == DNS 서버
• 호스트는 네임 서버에 "특정한 도메인 네임을 가진 호스트의 IP 주소"를 질의함으로써 패킷을 주고받고자 하는 호스트의 IP 주소를 얻어낼 수 있음
  • 이러한 과정을 "도메인 네임을 풀이(resolve)한다.", "리졸빙한다"라고 표현

도메인 네임의 계층적 구조

• 점 (.)을 기준으로 계층적으로 분류됨
• 최상단 (제일 오른쪽)에 "루트 도메인"이 있고,
• 그 다음 단계에는 "최상위 도메인(TLD, Top Level Domain)이 있음
  • 최상위 도메인 예시: com, net..
• 최상위 도메인은 이름과 달리 "최상위"가 아님
  • 도메인 네임의 마지막 부분인 "점으로 표현되는 루트 도메인"도 도메인 네임의 일부이기 때문
  • 일반적으로 루트 도메인은 생략하기 때문에 "최상위 도메인"을 도메인 네임의 마지막 부분으로 간주해 "최상위 도메인"이라고 표현한 것
• 최상위 도메인의 하부 도메인 : 2단계 도메인(세컨드 레벨 도메인)
• 2단계 도메인의 하부 도메인 : 3단계 도메인( ex. www)

네임 서버의 계층적 구조

• 네임 서버는 여러 개 존재, 전 세계 여러 곳에 위치. 즉, 네임서버는 분산되어 관리
• 계층적으로 분산되어 있는 도메인 네임에 대한 관리 체계를 "도메인 네임 시스템(DNS)"라고 불름

리졸빙 과정

• 로컬 네임 서버에게 도메인 네임을 질의
  • 로컬 네임 서버 : 클라이언트와 맞닿아 있는 네임 서버, 클라이언트가 리졸빙할 시에 가장 먼저 찾게 되는 네임 서버
• 로컬 네임 서버가 IP 주소를 모른다면, 알아낼 때까지 루트 도메인을 관장하는 서버(루트 네임 서버)에게 질의하고, 최상위 도메인을 관장하는 서버(TLD 네임 서버).. 등에 걸쳐 질의하게 됨
• 즉, 도메인 네임은 계층적 구조이며, 도메인 네임의 각 구조를 관리하는 서버 또한 계층적 구조로 관리되며, 클라이언트와 맞닿아 있는 "로컬 네임 서버"가 도메인 네임과 대응되는 IP 주소를 알아낼 때까지 "계층적인 도메인 네임 서버들"에게 질의를 반복
• DNS 캐시 : 네임 서버들이 기존에 응답받은 결과를 임시로 저장했다가, 추후 같은 질의에 활용

자원과 URI/URL

• 자원을 식별하기 위한 정보 : 자원 식별자 URI
• 위치를 식별하기 위한 정보 : 위치 식별자 URL
• 네트워크에서 자원이란? 네트워크 상의 메시지를 주고받는 대상

URI

• 웹 상에서의 자원을 식별하기 위한 정보를 의미
• "이름"을 기반으로 하기도 하고, "위치"를 기반으로 하기도 함
  • 이름 기반 자원 식별 : URN
  • 위치로 자원을 식별 : URL
• 즉, URI를 위치로 식별하는 것이 URL

URL의 구조

• schme
  • 일반적으로 사용할 프로토콜이 명시
• authority
  • 호스트를 특정할 수 있는 IP 주소나 도메인 네임
  • 포트 번호도 명시 가능
• path
  • 자원이 위치하고 있는 경로가 명시
  • 슬래시(/)를 기준으로 계층적으로 표현
  • 최상위 경로 역시 슬래시로 표현
• query
  • URL에 대한 매개변수 역할
  • 쿼리 문자열 or 쿼리 파라미터 등으로 불림
  • 자원을 식별하기 위한 추가적인 정보
  • 물음표(?)로 시작되는 <키=값> 형태의 데이터
  • 엠퍼샌드(&)를 사용하여 여러 쿼리 연결 가능
• fragment
  • 자원의 일부분, 자원의 한 조각을 가리키기 위한 정보
  • 일반적으로 HTML 파일과 같은 자원에서의 특정 부분을 가리키는 데 사용

HTTP의 특징과 메시지 구조

• HTTP의 목적은 "애플리케이션의 다양한 자원을 네트워크를 통해 송수신하는 것"

HTTP의 특징

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

• HTTP 요청과 HTTP 응답을 주고받는 구조로 작동

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

• HTTP는 주고받을 자원의 특성과 무관하게 자원을 주고받는 수단(인터페이스)의 역할만 수행
• HTTP 메시지로 주고받는 자원의 종류를 "미디어 타입(MIME 타입)"이라고 부름
  • 미디어 타입은 슬래시를 기준으로 하는 "타입/서브타입"의 형식으로 구성

3. stateless 프로토콜

• HTTP는 상태를 유지하지 않는 stateless 프로토콜
• 즉, 서버는 HTTP 요청을 보낸 클라이언트 관련 상태를 기억하지 않음
  • 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주
• 왜 상태를 유지하지 않을까?
  • HTTP 서버는 많은 클라이언트와 상호작용
  • 모든 클라이언트의 상태 정보를 유지하는 것은 큰 부담
  • 또한, 서버는 여러 대로 구성될 수 있는데, 그렇다면 여러 대의 서버가 모두 클라이언트의 상태 정보를 공유해야 함

4. 지속 연결 프로토콜

• 초기 HTTP 버전(HTTP 1.0 이하)에서는 쓰리 웨이 핸드셰이크를 통해 TCP 연결을 수립한 후, 요청에 대한 응답을 받으면 연결을 종료하는 방식으로 동작
  • 추가적인 요청-응답 을 위해선 매번 새롭게 연결을 수립하고 종료했어야 했음
• 하지만, 최근 사용하고 있는(HTTP 1.1 이상)에서는 "지속 연결"이라는 기술을 제공
  • 다른 표현으로는 "킵 얼라이브 keep-alive"라고 부름
  • 이는 하나의 TCP 연결 상에서 여러 개의 요청-응답을 주고받을 수 있는 기술을 의미

HTTP 1.1

• 킵 얼라이브 기능 공식적으로 지원
• 메시지를 평문(Plain text)으로 주고받는다는 특징

HTTP 2.0

• 바이너리 데이터 기반 송수신 : 평문대신 바이너리 데이터를 기반으로 메시지 송수신
• 헤더 압축 : 헤더 압축 가능, 네트워크 이용 효율 향상
• 서버 푸시 : 클라이언트가 요청하지 않았더라도 미래에 필요할 것으로 예상되는 자원을 미리 전송하는 기능
• HTTP 멀티플렉싱 기법
  • 요청-응답 메시지를 병렬적으로 주고받는 기술
  • 요청과 응답을 주고받는 단위는 하나의 스트림에서 이루어지고, 이러한 스트림 여러 개를 독립적으로 활용하는 기술
• HTTP 2.0은 위와 같은 기능(특히 HTTP 멀티 플렉싱 기법)을 통해 HOL 블로킹이라는 HTTP 1.1의 고질적인 문제를 완화한 버전으로도 알려짐
  • HOL 블로킹이란?
    • 같은 큐에 대기하며 순차적으로 처리되는 여러 패킷이 있을 때, 첫 번째 패킷의 처리 지연으로 인해 나머지 패킷들의 처리도 모두 지연되는 상황

HTTP 3.0

• UDP를 기반으로 동작
• 이전까지의 HTTP 버전들은 모두 TCP를 기반으로 동작
• HTTP 3.0부턴 UDP를 기반으로 구현된 QUIC이라는 프로토콜로 동작
• TCP에 비해 송수신 속도가 빠름

HTTP의 메시지 구조

• 시작 라인과 필드 라인, 메시지 본문으로 이루어져 있음
  • 필드 라인 : 0개 이상 가능
  • 메시지 본문 : 생략 가능

시작라인

• "시작 라인"으로 HTTP 메시지가 요청인지 응답인지 구분 가능
  • 요청일 경우, 시작 라인 -> "요청 라인"이 되고
  • 응답일 경우, 시작 라인 -> "상태 라인"이 됨
• 요청 라인
  • 메서드, 요청 대상, HTTP 버전으로 구성
• 상태 라인
  • HTTP 버전, 상태 코드, 이유 구문(생략 가능)으로 구성

필드 라인

• HTTP 헤더가 명시
• HTTP 헤더는 HTTP 메시지 전송과 관련한 부가 정보이자 제어 정보

HTTP 메서드와 상태 코드

• 요청 라인에서는 메서드, 상태 라인에서는 상태 코드가 핵심

HTTP 메서드

• HEAD
  • 응답 메시지에 메시지 본문이 포함되지 않는다는 점을 제외하면 GET 메서드와 동일
• POST
  • 서버로 하여금 특정 작업을 처리하도록 요청하는 메서드
  • 많은 경우에 "클라이언트가 서버에 새로운 자원을 생성하고자 할 때" 사용됨
  • POST 요청의 응답 메시지에선 "Location 헤더"를 통해 생성된 자원의 위치를 응답하고, 메시지 본문으로 생성된 자원을 응답
• PUT, PATCH
  • PUT : 덮어쓰기, 요청 메시지 본문으로 완전히 대체
  • PATCH : 부분적 수정, 요청 메시지 본문에 해당하는 부분만 수정

HTTP 상태 코드

• 요청의 결과를 나타내는 3자리 정수
• 200번대
  • 200 : 요청 성공
  • 201 : 요청 성공, 새로운 자원 생성
  • 202 : 요청을 잘 받았으나, 아직 요청한 작업을 끝내지 않았음
• 300번대
  • 리다이렉션 관련 코드
  • 리다이렉션이란? 클라이언트가 요청한 자원이 다른 곳에 있을 때 다른 곳으로 요청을 이동시키는 것을 의미
  • 클라이언트가 요청한 자원이 다른 URL에 있을 경우, 서버는 리다이렉션 관련 상태 코드와 함께 응답 메시지의 Location 헤더를 통해 요청한 자원이 위치한 URL을 안내해줌
  • 이를 수신한 클라이언트는 Location 헤더에 명시된 URL로 재요청을 보내 새로운 URL에 대한 응답을 받게 됨
  • 영구적 리다이렉션? 자원이 완전히 새로운 곳으로 이동하여 경로가 영구적으로 재지정되는 것을 의미
  • 일시적 리다이렉션? 자원의 위치가 임의로 변경되었거나 임시로 사용할 URL이 필요한 경우에 주로 사용
  • 308은 301을 보완하기 위한 상태 코드
    • 301의 경우 클라이언트가 Location 헤더로 재요청을 보낼 때, 처음 요청과 다른 메서드로 요청할 수 가능성이 있지만,
    • 308의 경우 Location 헤더에 담긴 URL로 요청을 보낼 때, 처음 요청과 같은 메서드로 요청
• 400번대
  • 401 : 인증을 요구하는 상태 코드
  • 403 : 권한(인가)를 요구하는 상태 코드
  • 인증이란 "자신이 누구인지를 증명하는 작업"
  • 권한이란 "인증된 주체에게 허용된 작업"을 의미
• 500번대
  • 서버에게 잘못이 있음을 나타내는 코드 상태
  • 502 : 중간 서버의 통신 오류

HTTP 주요 헤더

요청 메시지에서 주로 활용되는 HTTP 헤더

• HOST
  • 요청을 보낼 호스트가 명시되는 헤더, 도메인 네임이나 IP 주소로 표현
• User-Agent
  • HTTP 요청을 시작하는 클라이언트 측의 프로그램을 의미
  • 해당 헤더를 통해 HTTP 요청 메시지를 보낸 클라이언트의 접속 수단(웹 인지 모바일인지..)을 유추할 수 있다는 사실을 기억하자
• Referer
  • 클라이언트가 요청을 보낼 때 머무르던 URL이 명시, 이를 통해 클라이언트의 유입 경로를 알 수 있음

응답 메시지에서 주로 활용되는 HTTP 헤더

• Server
  • 응답을 보내는 서버 호스트와 관련된 정보가 명시
• Allow
  • 처리 가능한 HTTP 메서드의 목록을 알리기 위해 사용
  • 405번 상태 코드와 짝궁 (수신한 요청 메시지의 메서드를 지원하지 않는다는 의미의 코드)
• Location
  • 클라이언트에게 자원의 위치를 알려주기 위해 사용

요청과 응답 메시지 모두에서 활용되는 HTTP 헤더

• Content-type, Content-Language, Content-Encoding
  • 메시지 본문이 어떻게 "표현"되었는지와 관련된 헤더라서 "표현 헤더"라고도 불림
• Connection
  • HTTP 메시지를 송신하는 호스트가 어떠한 방식의 연결을 원하는지 명시하는 헤더