[혼공네트] Chapter 05. 응용 계층 (5주차)

05-1. DNS와 자원

도메인 네임과 네임 서버

• 도메인 네임(domain name) - IP 주소와 대응되는 문자열 형태의 호스트 특정 정보
  • 모든 호스트의 IP 주소 기억의 어려움과 언제든지 바뀔 수 있기에, 도메인 네임을 많이 사용함
• 네임 서버(name server, DNS 서버) - 도메인 네임과 IP 주소를 서로 대응하여 관리하는 서버
  • 도메인 네임(혹은 IP 주소)을 네임 서버에 질의하면, IP 주소(혹은 도메인 네임)를 알아낼 수 있음
• hosts 파일 - 도메인 네임과 IP 주소의 대응 관계를 저장한 파일 (≃ 개인적인 네임 서버)

ℹ️ 도메인 네임은 점(dot)을 기준으로 계층적으로 분류됨

1. 루트 도메인 (root domain) - 도메인 네임의 마지막 점 (일반적으로 루트 도메인을 생략해서 표기)
2. 최상위 도메인 (Top-Level Domain, TLD) - 도메인 네임의 마지막 부분 (ex. com, net, org, kr, jp)
3. n단계 도메인(n-level domain) - 최상위 도메인의 하부 도메인 (2단계부터 시작)

• 전체 주소 도메인 네임(FQDN; Fully-Qualified) - 도메인 네임을 모두 포함하는 도메인 네임
  • 호스트 네임(host name) - FQDN의 첫 번째 부분
• DNS(Domain Name System) - 계층적이고 분산된 도메인 네임에 대한 관리 체계
  

계층적 네임 서버

1️⃣ 도메인 네임에 대응되는 IP 주소를 알아내는 과정을 "풀이(resolving)한다"라고 표현함
2️⃣ 풀이하는 과정에서 다양한 네임 서버들을 사용함

1. 로컬 네임 서버(로컬 DNS 서버, 리졸버) - 클라이언트와 맞닿아 있는 네임 서버
   • 즉, 클라이언트가 도메인 네임으로 IP 주소를 알아내고자 할 때, 가장 먼저 찾는 네임 서버
   • 일반적으로 ISP에 의해 DNS 주소가 자동으로 할당되어 있음 (공개 DNS 서버 이용도 가능)
2. 루트 네임 서버 - 루트 도메인을 관리하고, 질의에 대해 TLD 네임 서버의 IP 주소를 반환
3. TLD 네임 서버 - TLD 도메인을 관리하고, 질의에 대해 하위 도메인을 관리하는 네임 서버 주소를 반환
4. 책임 네임 서버 - 특정 도메인 영역(zone)을 관리하는 네임 서버
   • 본인이 관리하고 있는 도메인 영역의 질의는 (로컬 네임 서버에게) 바로 답할 수 있음

3️⃣ 도메인 네임을 풀이하는 과정에는 재귀적 질의와 반복적 질의라는 두 가지 방법이 있음

1. 재귀적 질의(recursive query)
   1. 클라이언트가 로컬 네임 서버에 질의하면, 로컬 네임 서버가 루트 네임 서버에 질의함
   2. 루트 네임 서버는 TLD 네임 서버에 질의함
   3. TLD 네임 서버는 다음 단계의 네임 서버에 질의하는 과정을 반복함
   4. 최종 응답 결과를 얻게 되면 단계의 역순으로 전달 받음
2. 반복적 질의(iterative query)
   1. 클라이언트가 로컬 네임 서버에 질의하면, 로컬 네임 서버가 루트 네임 서버에 질의하여
      다음으로 질의할 네임 서버의 주소를 응답받음
   2. TLD 네임 서버에 질의해서 다음으로 질의할 네임 서버의 주소를 응답받는 과정을 반복함
   3. 최종 응답 결과를 얻게 되면 클라이언트에게 전달함

• DNS 캐시(DNS Cache) - 나중에 같은 질의에 활용하기 위해, 응답받은 결과를 임시로 저장한 것
  • 임시 저장된 값은 TTL(Time To Live)에 의해 캐시 유지 시간이 유한함

자원을 식별하는 URI

1️⃣ 자원(Resource) - 네트워크상의 메세지를 통해 주고받는 대상 (HTML, 텍스트, 이미지 등)
2️⃣ 오늘날에는 HTTP를 기반으로 통신하므로, 자원을 'HTTP 요청 메시지의 대상'이라고도 함

• URI(Uniform Resource Identifier) - 자원을 식별할 수 있는 정보
  • 위치(Locator)를 이용해서 식별할 수도 있고, 이름(Name)을 이용해서 식별할 수도 있음

URL

• URL(Uniform Resource Locator) - 오늘날 인터넷 환경에서 많이 사용되는 위치 기반의 식별자

  1. scheme - 자원에 접근하는 방법을 의미함 (일반적으로 사용할 프로토콜이 명시됨)
  2. authority - 호스트를 특정할 수 있는 정보를 의미함 (IP 주소 혹은 도메인 네임 + 포트 번호)
  3. path - 자원이 위치한 경로를 의미함 (자원의 위치는 슬래시(/)를 기준으로 계층적으로 표현됨)
  4. query - 자원을 식별하기 위한 더 많은 정보를 의미함
     • 물음표로 시작되는 <키=값> 데이터 형태의 쿼리 문자열(쿼리 파라미터)를 사용함
  5. fragment - 자원의 일부분을 가리키기 위한 정보를 의미함 (ex. HTML의 특정부분을 가리킴)

URN

• URN(Uniform Resource Name) - 자원에 고유한 이름을 붙이는 이름 기반의 식별자
  • 위치나 프로토콜과 무관하게 자원을 식별할 수 있음

---

05.2 - HTTP

HTTP의 특성

1️⃣ HTTP(Hypertext Transfer Protocol) - 오늘날 응용 계층에서 사용하는 주요한 프로토콜

요청-응답 기반 프로토콜

• HTTP는 클라이언트와 서버 사이 HTTP 요청 메시지와 HTTP 응답 메시지를 주고 받으며 동작함
  • 같은 HTTP 메시지일지라도, 이 둘은 서로 메시지 형태가 다름

미디어 독립적 프로토콜

• HTTP는 주고받을 미디어 타입을 제한하지 않고 자원을 주고받을 수단(인터페이스) 역할만 함
  • 미디어 타입(MIME 타입) - HTTP에서 메시지로 주고받는 자원의 종류 ('타입/서브타입'으로 표기)
    • 타입 - 데이터의 유형 / 서브 타입 - 주어진 타입에 대한 세부 유형
    • 부가적인 설명을 위해 매개변수가 포함될 수도 있음

스테이트리스 프로토콜

• HTTP는 상태를 유지하지 않음 (서버는 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않음)
  • 즉, 클라이언트의 HTTP 요청은 독립적인 요청으로 간주됨

지속 연결 프로토콜

• HTTP는 지속 연결(킵 얼라이브) 기술을 제공함 (하나의 TCP 연결에서 여러 요청-응답을 주고 받음)
  • 다만, 이전의 HTTP 버전(HTTP 1.1 미만)에서는 지속 연결을 지원하지 않음

HTTP 메시지 구조

1️⃣ HTTP 메시지는 시작 라인, 필드 라인, 메시지 본문으로 이루어져 있음
2️⃣ 필드 라인은 없거나 여러 개 있을 수 있고, 메시지 본문은 없을 수도 있음

1. 시작 라인(start-line)

   1️⃣ 요청 라인(request-line) - HTTP 메시지가 요청 메시지일 경우의 시작 라인

   1. 메서드(method) - 클라이언트가 서버의 자원에 대해 수행할 작업의 종류를 의미함
      • 자원이 같더라도 메서드(GET, POST, PUT, DELETE 등)가 다르면 다른 요청으로 처리됨
   2. 요청 대상(request-target) - HTTP 요청을 보낼 서버의 자원을 의미함
      • (쿼리가 포함된) URI의 경로가 명시됨
   3. HTTP 버전(HTTP-version) - 사용된 HTTP 버전을 의미함

   2️⃣ 상태 라인(status-line) - HTTP 메시지가 응답 메시지일 경우의 시작 라인

   1. HTTP 버전 - 사용된 HTTP 버전을 의미함
   2. 상태 코드(status code) - 요청에 대한 결과를 나타내는 세 자리 정수를 의미함
   3. 이유 구문(reason phrase) - 상태 코드에 대한 문자열 형태의 설명을 의미함

2. 필드 라인(field-line; 헤더 라인)

   • 필드 라인에는 0개 이상의 HTTP 헤더(HTTP 통신에 필요한 부가 정보)가 명시됨
   • HTTP 헤더는 콜론을 기준으로 헤더 이름과 헤더 값으로 구성됨

3. 메시지 본문(message-body)

   • HTTP 요청/응답 메시지에서 본문이 필요할 경우에 명시됨

HTTP 메서드

1. GET - 특정 자원을 조회할 때 사용되는 메서드
2. HEAD - GET 메서드와 동일한 역할을 하되, 응답 메시지의 헤더만 반환하는 메서드
3. POST - 서버에게 특정 작업을 처리하도록 요청하는 메서드
4. PUT - 메시지 본문으로 자원을 새로 생성하거나, 메시지 본문으로 자원을 대체하는 메서드
5. PATCH - 메시지 본문에 맞게 자원의 일부만 수정하는 메서드
6. DELETE - 특정 자원을 삭제할 때 사용하는 메소드

HTTP 상태 코드

ℹ️ 상태 코드의 종류는 백의 자리 수를 기준으로 유형을 구분할 수 있음

200번대 : 성공 상태 코드

1. 200 (OK) - 요청이 성공했음
2. 201 (Created) - 요청이 성공했으며, 새로운 자원이 생성되었음
3. 202 (Accepted) - 요청이 성공했지만, 아직 요청한 작업을 끝내지 않았음
4. 203 (No Content) - 요청이 성공했지만, 메시지 본문으로 표시할 데이터가 없음

300번대 : 리다이렉션(redirection) 상태 코드

ℹ️ 리다이렉션 - 요청한 자원이 다른 곳에 있을 때, 클라이언트의 요청을 다른 곳으로 이동시키는 것

1. 영구적인 리다이렉션(permanent redirection) - 자원의 경로가 영구적으로 재지정된 것
   • 301 (Moved Permanetly) - 영구적 리다이렉션 (재요청 메서드가 변경될 수 있음)
   • 308 (Permanent Redirect) - 영구적 리다이렉션 (재요청 메서드가 변경되지 않음)
2. 일시적인 리다이렉션(temporary redirection) - 자원의 경로가 일시적으로 변경되었거나,
   임시로 사용할 URL이 필요한 경우
   • 302 (Found) - 일시적 리다이렉션 (재요청 메서드가 변경될 수 있음)
   • 303 (See Other) - 일시적 리다이렉션 (재요청 메서드가 GET으로 변경됨)
   • 307 (Temporary Redirect) - 일시적 리다이렉션 (재요청 메서드가 변경되지 않음)

400번대 : 클라이언트 에러 상태 코드

• 400 (Bad Request) - 클라이언트 요청이 잘못되었음
• 401 (Unauthorized) - 요청한 자원에 대한 유효한 인증이 없음
  • 이 상태 코드로 응답할 때, 반드시 WWW-Authenticate 헤더를 통해 인증 방법을 알려주어야 함
• 403 (Forbidden) - (접근 권한이 없는 등의 이유로) 요청이 서버에 의해 거부됨
• 404 (Not Found) - 요청받은 자원을 찾을 수 없음
• 405 (Method Not Allowed) - 요청한 메서드를 지원하지 않음

500번대 : 서버 에러 상태 코드

• 500 (Internal Server Error) - 요청을 처리할 수 없음
• 502 (Bad Gateway) - 중간 서버의 통신 오류
• 503 (Service Unavailable) - 일시적인 서버 오류

---

05.3 - HTTP 헤더와 HTTP 기반 기술

HTTP 헤더

요청 시 활용되는 HTTP 헤더

1. Host - 요청을 보낼 호스트를 나타내는 헤더 (주로 도메인 네임이 명시되며, 포트번호가 있을 수 있음)
2. User-Agent - (HTTP 요청 메시지를 보내는) 클라이언트 측의 프로그램을 나타냄
3. Referer - 클라이언트가 요청을 보낼 때, 머무르고 있던 URL을 나타냄 (유입경로 파악)
4. Authorization - 클라이언트의 인증 정보를 담는 헤더

응답 시 활용되는 HTTP 헤더

1. Server - 서버 측의 소프트웨어와 관련된 정보를 나타냄
2. Allow - 클라이언트에게 허용된 HTTP 메서드 목록을 나타냄
3. Retry-After - 자원을 사용할 수 있는 날짜/시각을 나타냄
4. Location - 자원의 위치를 나타냄 (주로 리다이렉션/새로운 자원이 생성되었을 때 사용됨)
5. WWW-Authenticate - 자원에 접근하기 위한 인증 방식을 나타냄

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

1. Date - 메시지가 생성된 날자와 시각에 관련된 정보를 나타냄
2. Connection - 클라이언트의 요청과 응답 간의 연결 방식(지속 연결 등)을 나타냄
3. Content-Length - 본문의 바이트 단위 크기(길이)를 나타냄
4. Content-Type/Language/Encoding (표현 헤더) - 메시지 본문의 표현 방식을 나타냄

캐시

• 캐시(cache) - 대역폭 낭비와 응답 지연을 막고자, 정보의 사본을 임시로 저장하는 기술
  • 웹 브라우저에 저장되기도 하고 (개인 전용 캐시) 중간 서버에 저장되기도 함 (공용 캐시)
• 캐시 신선도(cache freshness) - 캐시된 사본 데이터와 최신 원본 데이터와의 유사도
  • 신선도를 유지를 위해, 캐시 데이터에 Expires 및 Cache-Control 헤더로 유효기간을 설정함
    • 유효 기간이 만료되었다면, 원본 데이터를 다시 요청함

쿠키

• 쿠키(cookie) - 상태를 유지하지 않는 HTTP의 특성을 보완하기 위한 수단
  • 서버에서 생성되어 클라이언트의 부라우저에 저장되고 관리됨
• 클라이언트는 요청 메시지에 쿠키를 포함해서 전송하여, 서버는 쿠키 정보(세션 ID 등)를 참고함

콘텐츠 협상과 표현

• 콘텐츠 협상(content negotiation) - 같은 URI에 대해 가장 적합한 자원의 형태를 제공하는 메커니즘
• 표현(representation) - 송수신 가능한 자원의 '형태'
  • 클라이언트가 선호하는 표현을 반영하기 위해, Accept-Language 등의 협상 관련 헤더를 사용함

---

숙제

기본 숙제

1. 도메인 네임과 네임 서버에 대한 설명으로 옳지 않은 것을 골라 보세요.
   1. 8.8.8.8은 대표적인 공개 DNS 서버로, 구글이 관리합니다.
   2. 도메인 네임은 호스트를 특정할 수 있는 문자열 형태의 정보입니다.
   3. DNS는 계층적이고 분산된 도메인 네임에 대한 관리 체계이자 이를 관리하는 프로토콜입니다.
   4. www.example.com에서 루트 도메인은 com에 해당합니다.
      • www.example.com에서 루트 도메인은 .(점)이고, com은 최상위 도메인(TLD)에 해당한다.
2. HTTP 상태 코드에 대한 설명으로 옳지 않은 것을 골라 보세요.
   1. 300번대 상태 코드는 요청한 자원이 존재하지 않음을 의미합니다.
      • 300번대는 리다이렉션에 관한 상태를 설명하기 위한 상태 코드이다.
   2. 400번대 상태 코드는 클라이언트에 의한 에러를 의미합니다.
   3. 500번대 상태 코드는 서버에 의한 에러를 의미합니다.
   4. 200번대 상태 코드는 요청이 성공했음을 의미합니다.

추가 숙제

ℹ️ HTTP 요청 메시지는 키보드의 [F12] 키를 누르고, 상단의 '네트워크' 탭에서 확인할 수 있음

• 주요한 것을 보면 메서드로 GET을 사용하고, 상태코드로 200(OK)을 알 수가 있었음

---

회고

드디어 마지막 계층인 응용 계층에 대해 공부하는 시간을 가지게 되었다. 이번 차시에서는 응용 계층 중에서도 HTTP 프로토콜에 대해서 주로 다루었다. HTTP를 배우기 전에 나는 API를 활용하려 할 때, GET 혹은 HEAD 등의 메서드가 왜 사용되는지도 몰랐었고, 상태 코드는 '404'만 알지 실제로 어떤 것을 의미하는 지 몰랐었다. 그러나, 이번 차시의 공부를 통해 어떤 식으로 API를 사용하여 프로그램 로직을 구성해야할 지 감이 잡히고, 실제로 토이 프로젝트를 만드는 데 큰 도움이 되었다. (사실상 HTTP를 먼저 공부하고 API를 활용하는 것이 일반적이지만...) 어떻게 보면 단순히 웹페이지만 불러올 것 같은 HTTP라는 프로토콜 속에는 사실 엄청 복잡하고 체계적인 헤더 등이 뭉쳐진 프로토콜이었고, 이것이 왜 개발자들이 HTTP가 중요하다고 강조하는 이유에 대해 새삼 깨닫게 되는 계기가 되었다.