[CS] 혼공네트 Chapter 5. 응용 계층

05-1 DNS와 자원

도메인 네임과 네임 서버

• 일반적으로 사용자는 상대 호스트를 특정하기 위해 IP 주소보다는 도메인 네임(domain name)을 많이 사용한다.
• 도메인 네임은 호스트의 IP 주소와 대응되는 문자열 형태의 호스트 특정 정보이다.
  • 도메인 네임과 IP 주소는 네임 서버(name server)에서 관리.
  • 도메인 네임을 관리하는 네임 서버는 DNS 서버라고도 부른다.
• 도메인 네임을 네임 서버에 질의하면 해당 도메인 네임에 대한 IP 주소를 알려주는 방식으로 도메인 네임으로 IP 주소를 알아낼 수 있다.
• 도메인 네임은 IP 주소에 비해 기억하기 쉬울뿐더러, IP 주소가 바뀌더라도 바뀐 IP 주소에 도메인 네임을 다시 대응하면 되므로 IP 주소만으로 호스트를 특정하는 것보다 더 간편하다.

도메인 네임 구조

• 도메인 네임은 점(.)을 기준으로 계층적으로 분류된다.
• 최상단에 루트 도메인이 있고, 그 다음 단계인 최상위 도메인(TLD)이 있으며, 계속 그 다음 단계의 도메인이 있는 식이다.
• 일반적으로 3~5단계 정도미여, 도메인 네임을 모두 포함하는 도메인 네임을 전체 주소 도메인 네임(FQDN: Fully-Qualified Domain Name)이라고 한다.

• 계층적인 도메인 네임을 효율적으로 관리하기 위해 네임 서버 또한 계층적인 형태를 이룬다.
• 네임 서버는 여러 개 존재하며 전 세계 여러 군데에 위치해 있다.
• 계층적이고, 분산된 도메인 네임에 대한 관리 체계를 도메인 네임 시스템(DNS)라고 부른다.
• DNS는 호스트가 이러한 도메인 네임 시스템을 이용할 수 있도록 하는 애플리케이션 계층 프로토콜을 의미하기도 한다.

 

계층적 네임 서버

• IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 과정을 '도메인 네임을 풀이(resolve)한다.'라고 표현.
• 중요한 역할을 담당하는 네임 서버의 4 가지 유형
  • 로컬 네임 서버
    • 클라이언트와 맞닿아 있는 네임 서버.
    • 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾게 되는 네임 서버.
    • 로컬 네임 서버의 주소는 일반적으로 ISP에서 할당해 주는 경우가 많다.
    • 공개 DNS 서버를 이용할 수도 있다.
      • 구글의 8.8.8.8, 8.8.4.4와 클라우드플레어의 1.1.1.1이 있다.
  • 루트 네임 서버
    • 로컬 네임 서버가 대응되는 IP 주소를 모를 때 루트 네임 서버에게 해당 도메인 네임을 질의한다.
    • 루트 도메인을 관장하는 네임 서버로, 질의에 대해 TLD 네임 서버의 IP 주소를 반환할 수 있다.
  • TLD(최상위 도메인) 네임 서버
    • TLD의 하위 도메인 네임을 관리하는 네임 서버 주소를 반환.
    • 하위 도메인 네임을 관리하는 네임 서버는 마찬가지로 그보다 하위 도메인 네임을 관리하는 네임 서버 주소를 반환할 수 있다.
  • 책임 네임 서버
    • 특정 도메인 영역을 관리하는 네임 서버.
    • 자신이 관리하는 도메인 영역의 질의에 대해서 다른 네임 서버에게 떠넘기지 않고 곧바로 답할 수 있는 네임 서버.
    • 즉, 로컬 네임 서버가 마지막으로 질의하는 네임 서버.
    • 일반적으로 로컬 네임 서버는 책임 네임 서버로부터 원하는 IP 주소를 얻어낸다.

 

IP 주소를 알아내는 과정

• 로컬 네임 서버가 네임 서버들에게 질의하는 방법에는 재귀적 질의와 반복적 질의가 있다.

재귀적 질의

• 클라이언트가 로컬 네임 서버에게 도메인 네임을 질의하면, 로컬 네임 서버가 루트 네임 서버에게 질의하고, 루트 네임 서버가 TLD 네임 서버에게 질의하고, TLD 네임 서버가 다음 단계(책임 네임 서버)에 질의하는 과정을 반복하며 최종 응답 결과를 역순으로 전달받는 방식.

 

반복적 질의

• 클라이언트가 로컬 네임 서버에게 IP 주소를 알고 싶은 도메인 네임을 질의하면, 로컬 네임 서버는 루트 도메인 서버에게 질의해서 다음으로 질의할 네임 서버의 주소를 응답받음.
• 다음으로 TLD 네임 서버에게 질의해서 다음으로 질의할 네임 서버의 주소를 응답받는 과정을 반복하다가 최종 응답 결과를 클라이언트에게 알려주는 방식.

• 위의 두 방법은 도메인 네임을 리졸빙 하기 위해 8개의 단계를 거쳐야 하는 것처럼 시간이 오래 걸리고 네트워크상의 메시지 수가 지나치게 늘어날 수 있다는 문제가 있다.
• 그래서 실제로는 네임 서버들이 기존에 응답받은 결과를 임시로 저장했다가 추후 같은 질의에 이를 활용하는 경우가 많다.
• 이를 DNS 캐시라고 하며, 더 짧은 시간 안에 원하는 IP 주소를 얻어낼 수 있다.

 

자원을 식별하는 URI(Uniform Resource Identifier)

• 자원(resource)란 네트워크상의 메시지를 통해 주고받는 대상.
  • 즉, 두 호스트가 네트워크를 통해 서로 정보를 주고받을 때, 송수신하는 대상.
• 네트워크상에서 자원을 주고받으려면 자원을 식별할 수 있어야 하는데 이를 URI라고 한다.
  • 자원을 식별하는 통일된 방식.
• URI를 식별 정보 기준으로 분류한 개념 두 가지
  • URL: 위치를 이용해 자원을 식별
  • URN: 이름을 이용해 자원을 식별

URL(Uniform Resource Locator)

일반적인 URL 형식(RFC 3986)

1. scheme
   • URL의 첫 부분으로 자원에 접근하는 방법을 의미.
   • 일반적으로 사용할 프로토콜이 명시된다.
     • ex) http://   ,   https://
2. authority
   • 호스트를 특정할 수 있는 정보가 명시.
     • IP 주소 혹은 도메인 네임이 명시되며, 콜론(:) 뒤에 포트 번호를 덧붙일 수도 있다.
3. path
   • 자원이 위치한 경로가 명시.
   • 자원의 위치는 슬래시(/)를 기준으로 계층적으로 표현되고, 최상위 경로 또한 슬래시로 표현.
4. query
   • 수많은 정보 중에서 '특정 단어를 검색한 결과'에 해당하는 자원이나 수많은 상품 중에서 '특정 상품을 검색한 뒤 그 결과를 내림차순으로 정렬한 결과'에 해당하는 자원을 scheme, authority, path만으로 모두 표현하기는 어려움.
   • 쿼리 문자열(파라미터)은 물음표(?)로 시작되는 <키=값> 형태의 데이터로, 앰퍼샌드(&)를 사용하여 여러 쿼리 문자열을 연결할 수 있다.
5. fragment
   • 자원의 한 조각을 가리키기 위한 정보.
   • 흔히 HTML 파일과 같은 자원에서 특정 부분을 가리키기 위해 사용.

 

URN(Uniform Resource Name)

• URL은 자원의 위치가 변한다면 더이상 유효해지지 않을 수 있다.
• 자원에 고유한 이름을 붙이는 이름 기반 식별자이기에 자원의 위치와 무관하게 자원을 식별할 수 있다.
• 다만 URN은 아직 URL만큼 널리 채택된 방식은 아니기에 자원을 식별할 URI로는 URN보다는 URL이 더 많이 사용된다.

 

05-2 HTTP (Hypertext Transfer Protocol)

HTTP는 응용 계층에서 정보를 주고받는 데 사용되는 프로토콜이다.

 

HTTP의 특성

요청-응답 기반 프로토콜

• HTTP는 클라이언트-서버 구조 기반의 요청-응답 프로토콜이다.
  • 클라이언트와 서버가 서로 HTTP 요청 메시지와 HTTP 응답 메시지를 주고받는 구조로 동작.
  • 같은 HTTP 메시지일지라도 HTTP 요청 메시지와 HTTP 응답 메시지는 메시지 형태가 다르다.

 

미디어 독립적 프로토콜

• HTTP는 자원(HTTP가 요청하는 대상)의 특성을 제한하지 않으며, 단지 자원과 상호 작용하는 데 사용할 수 있는 인터페이스를 정의할 뿐이다. 대부분의 자원은 URI로 식별.(RFC 9110)
• 미디어 타입(MIME 타입: Multipurpose Internet Mail Extensions)
  • HTTP에서 메시지로 주고받는 자원의 종류
  • HTTP를 통해 송수신하는 정보의 종류는 미디어 타입으로 나타낼 수 있다.
  • '타입/서브타입' 형식으로 구성된다.(타입: 데이터의 유형, 서브타입: 주어진 타입에 대한 세부 유형)
  • 미디어 타입의 종류는 매우 다양하며, 필요에 따라 새로운 미디어 타입을 등록할 수도 있다.

 

스테이트리스 프로토콜

• 상태를 유지하지 않는다.
  • 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다는 의미.
  • 클라이언트의 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주.
• 상태를 유지하지 않는 특성은 효율적이지 않아 보일 수도 있지만, 실제로는 장점이 더 명확하다.
  • HTTP 서버는 일반적으로 많은 클라이언트와 동시에 상호 작용하기 때문에 클라이언트의 상태 정보를 유지하는 것은 서버에 큰 부담이 된다.
  • 서버가 여러 대로 구성될 경우, 모든 서버가 모든 클라이언트의 상태 정보를 공유하는 작업은 매우 번거롭고 복잡해진다.
  • HTTP가 상태를 유지하는 프로토콜이었다면 클라이언트는 자신의 상태를 기억하는 특정 서버하고만 상호 작용할 수 있게 되어, 특정 클라이언트가 특정 서버에 종속될 수 있다.
• 확장성(scalability)과 견고성(robustness): HTTP의 설계 목표
  • 상태를 유지하지 않는 스테이트리스한 특성은 언제든 쉽게 서버를 추가할 수 있기 때문에 확장성이 높고, 서버 중 하나에 문제가 생겨도 쉽게 다른 서버로 대체가 가능하기 때문에 견고성이 높다.

 

지속 연결 프로토콜

• 기본적으로 HTTP는 TCP 상에서 동작하는데, HTTP는 비연결형 프로토콜이지만, TCP는 연결형 프로토콜이다.
• 초기의 HTTP 버전(HTTP 1.0 이하)은 쓰리 웨이 핸드셰이크를 통해 TCP 연결을 수립한 후, 요청에 대한 응답을 받으면 연결을 종료하는 방식으로 동작.
  • 비지속 연결: 추가적인 요청-응답을 하기 위해서는 다시 TCP 연결을 수립해야 했다.
• 최근 사용되는 HTTP 버전(HTTP 1.1 이상)은 지속 연결(persistent connection, keep-alive)이라는 기술을 제공.
  • 하나의 TCP 연결상에서 여러 개의 요청-응답을 주고받을 수 있는 기술.
  • 지속 연결 기능을 지원하는 HTTP는 매번 새롭게 연결을 수립하고 종료해야 하는 비지속 연결에 비해 더 빠르게 여러 HTTP 요청과 응답을 처리할 수 있다.

 

HTTP 메시지 구조 (HTTP 1.1 버전)

• HTTP 메시지는 시작 라인, 필드 라인, 메시지 본문으로 이루어져 있다.
• 필드 라인은 없거나 여러 개 있을 수 있고, 메시지 본문은 없을 수 있다.
• 필드 라인과 메시지 본문 사이에는 빈 줄바꿈이 있다.

시작라인

• HTTP 요청 메시지일 경우 시작 라인: 요청 라인 = 메서드 (공백) 요청 대상 (공백) HTTP 버전 (줄바꿈)
  • 메서드
    • 클라이언트가 서버의 자원에 대해 수행할 작업의 종류를 나타냄.
    • 대표적으로 Get, Post, Put, Delete
    • 요청 대상이 같아도 메서드가 다르면 각기 다른 요청으로 처리된다.
  • 요청 대상
    • HTTP 요청을 보낼 서버의 자원을 의미.
    • 쿼리가 포함된 URI의 경로가 명시된다.
  • HTTP 버전
    • 사용된 HTTP 버전
    • HTTP/<버전> 이라는 표기 방식을 따른다.

 

• HTTP 응답 메시지일 경우 시작 라인: 상태 라인 = HTTP 버전 (공백) 상태 코드 (공백) 이유 구문 (줄바꿈)
  • HTTP 버전 (위와 같음)
  • 상태 코드
    • 요청에 대한 결과를 나타내는 세 자리 정수.
    • 클라이언트는 상태 코드를 통해 요청이 어떻게 처리되었는지 판단.
  • 이유 구문
    • 상태 코드에 대한 문자열 형태의 설명.
    • ex) HTTP/1.1 200 OK -> '요청이 성공적으로 받아들여지고 수행되었음'
    • ex) HTTP/1.1 404 Not Found -> '요청한 자원이 존재하지 않음'

 

필드 라인 (헤더 라인)

• '0개 이상'의 HTTP 헤더(HTTP 통신에 필요한 부가 정보)가 명시된다.
• 실제로는 한 HTTP 메시지에 아주 다양한 HTTP 헤더들이 사용되는 것이 일반적이다.
• 각 HTTP 헤더는 콜론(:)을 기준으로 헤더 이름과 하나 이상의 헤더 값으로 구성된다.(5-3에서 자세히)

헤더이름: 헤더 값 예시

 

메시지 본문

• HTTP 요청 혹은 응답 메시지에서 본문이 필요할 경우 메시지 본문에 명시된다.
• 메시지 본문은 존재하지 않을 수도 있고, 다양한 콘텐츠 타입이 사용될 수도 있다.

 

HTTP 메서드

• GET
  • 특정 자원을 조회할 때 사용되는 메서드.
  • '이것(자원)을 가져다주세요'라고 요청을 보내는 것.
  • 가장 흔히 사용되는 메서드 중 하나이며, 웹 브라우저를 통해조회하는 자원은 대부분 GET 요청 메시지에 대한 응답.
  • Host 헤더에는 요청을 보낼 호스트가 명시된다.
  • GET 요청 메시지가 성공적으로 처리되었다면 이에 대한 응답으로서 요청한 자원을 전달받는다.
  • GET 메서드에 요청 메시지 본문을 포함시키는 것은 바람직하지 않다. GET 요청 메시지에서는 메시지 본문보다 쿼리 문자열이 사용되는 경우가 많다.
• HEAD
  • 사실상 GET 메서드와 동일한 역할.
  • 차이점은 응답 메시지에 메시지 본문이 포함되지 않는다는 것.
  • HEAD 메서드를 사용하면 서버는 요청에 대한 응답으로 응답 메시지의 헤더만 반환.
• POST
  • 서버로 하여금 특정 작업을 처리하도록 처리하도록 요청하는 메서드.
  • '이것을 처리해 주세요'라는 요청.
  • 처리할 대상은 메시지 본문으로 명시.
  • 클라이언트가 서버에 새로운 자원을 생성하고자 할 때 사용된다.
  • 새로운 자원이 생성되면 서버는 응답 메시지의 Location 헤더를 통해 생성된 자원의 위치를 클라이언트에게 알려 줄 수 있다.
• PUT
  • '덮어쓰기'를 요청하는 메서드.
  • 요청 자원이 없다면 메시지 본문으로 자원을 새롭게 생성한다.
  • 이미 자원이 존재한다면 메시지 본문으로 자원을 완전히 대체한다.
• PATCH
  • PUT 메서드가 완전한 대체에 가깝다면 PATCH 메서드는 부분적 수정에 가깝다.
  • 메시지 본문에 맞게 자원이 일부 수정된다.
• DELETE
  • 특정 자원을 삭제하고 싶을 때 사용하는 메서드.

 

HTTP 상태 코드

• 상태 코드의 종류는 백의 자리 수를 기준으로 유형을 구분한다.

 

200번대: 성공 상태 코드

• 요청이 성공했음을 의미.

• 200(OK)
  • 서버가 요청을 성공적으로 받아들이고 처리한 경우, 서버는 요청한 자원과 함께 상태 코드를 포함한 응답을 할 수 있다.
• 201(Created)
  • POST 요청을 통해 서버에 새로운 자원을 생성한 경우, 요청이 성공했으며 새로운 자원이 만들어졌음을 알릴 수 있다.
• 202(Accepted)
  • 요청을 잘 받았으나, 아직 요청한 작업을 끝내지 않았음을 의미.
  • 작업 시간이 긴 대용량 파일 업로드 작업과 같이 요청 결과를 곧바로 응답하기 어려운 상황.
• 204(No Content)
  • 요청 메시지에 대해 성공적으로 작업을 완료했더라도 마땅히 메시지 본문으로 표기할 것이 없을 경우.

 

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

• 리다이렉션: 요청을 완수하기 위해 추가적인 조치가 필요한 상태.
  • 클라이언트가 요청한 자원이 '다른 곳'에 있을 때, 클라이언트의 요청을 '다른 곳'으로 이동시키는 것.
    • 다른 곳은 URL이 될 수도 있고, 캐시가 될 수도 있다.
    • 캐시와 관련된 상태 코드 304(Not Modified) - 자원이 변경되지 않았음
  • 클라이언트가 요청한 자원이 다른 URL에 있을 경우, 서버는 응답 메시지의 Location 헤더를 통해 요청한 자원이 위치한 URL 안내.
  • 이를 수신한 클라이언트는 Location 헤더에 명시된 URL로 즉시 재요청을 보내어 새로운 URL에 대한 응답을 받게 된다.

 

• 영구적인 리다이렉션(permanent redirection)
  • 자원이 완전히 새로운 곳으로 이동하여 경로가 영구적으로 재지정되는 것.
  • 기존의 URL에 요청을 메시지를 보내면 항상 새로운 URL로 리다이렉트된다.
  • 서버가 도메인을 이전하는 등 웹 사이트의 큰 개편이 있을 때 접할 수 있다.

• 301(Moved Permanently)
  • 서버에 POST 메서드로 요청 메시지를 보냈을 때 301 응답 메시지를 받는 경우
  • 클라이언트가 보내는 두 번째 요청 메서드는 GET 요청으로 바뀔'수도' 있다.
• 308(Permanent Redirect)
  • 서버에 POST 메서드로 요청 메시지를 보냈을 때 308 응답 메시지를 받는 경우
  • 클라이언트가 보내는 두 번째 요청 메서드는 POST 메서드를 유지한다.
• 301과 308의 차이는 클라이언트의 재요청 메서드 변경 여부이다.

 

• 일시적인 리다이렉션(temporary redirection)
  • 자원의 위치가 임시로 변경되었거나 임시로 사용할 URL이 필요한 경우에 주로 사용한다.
  • 어떤 URL에 대해 일시적인 리다이렉션 관련 상태 코드를 응답 받았다면, 요청을 보낸 URL을 기억해야 한다.

• 302(Found)
  • 301과 유사.
  • 요청한 자원이 '임시로' 다른 곳으로 이동했음.
  • GET이 아닌 요청 메서드를 사용한 클라이언트가 상태 코드 302를 응답받을 경우, 두 번째 요청 메서드는 GET으로 바뀔'수도' 있다.
• 303(See Other)
  • 두 번째 요청 메서드를 GET으로 바꿔 주기 위해 사용된다.
• 307(Temporary Redirect)
  • 308과 유사.
  • 301의 애매모호함을 해결하기 위한 상태 코드가 308인 것처럼 302의 애매모호함을 해결하기 위한 상태 코드는 307.
  • 두 번째 요청 메서드를 변경하지 않는 상태 코드.

 

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

• 클라이언트에 의한 에러가 있음을 알려 주는 상태 코드.
• 서버가 처리할 수 없는 형태로 요청을 보냈거나, 존재하지 않는 자원에 대해 요청을 보내는 경우.

• 400(Bad Request)
  • 클라이언트의 요청이 잘못되었음을 알려 주는 상태 코드
  • 클라이언트 요청 메시지의 내용이나 형식 자체에 문제가 있어 서버가 요청 메시지를 올바르게 처리할 수 없는 경우.
• 401(Unauthorized)
  • 웹 상에서 정보를 검색할 때 모든 자원에 접근이 가능한 것은 아니다. 때로는 특정 자원에 접근하기 위해 인증이 필요할 때가 있다.
  • 401로 응답할 때는 반드시 WWW-Authenticate라는 헤더를 통해 인증 방법을 알려 주어야 한다.
• 403(Forbidden)
  • 클라이언트의 권한이 충분하지 않을 때.
  • '자원에 접근할 권한이 없음'을 의미.
  • 401의 인증이란, '자신이 누구인지 증명하는 것'을 의미하고, 권한 부여는 '인증된 주체에게 작업을 허용하는 것'을 의미.
• 404(Not Found)
  • 접근하고자 하는 자원이 존재하지 않음을 알리는 상태 코드.
  • 존재하더라도 공개하지 않는 자원에 대해 응답하는 경우도 있다.
• 405(Method Not Allowed)
  • 구현되지 않은 메서드로 요청을 보냈을 경우 해당 메서드의 미지원을 알린다.

 

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

• 클라이언트가 올바르게 요청을 보냈을지라도 발생할 수 있는 서버 에러에 대한 상태 코드

• 500(Internal Server Error)
  • 500번대에서 가장 자주 사용되는 상태 코드.
  • '서버의 예기치 못한 상황으로 인해 요청을 처리할 수 없음'을 의미.
  • 서버 내 에러를 통칭하기도 한다.
• 502(Bad Gateway)
  • 클라이언트와 서버 사이에 위치한 중간 서버의 통신 오류를 나타내는 상태 코드
  • 게이트웨이를 비롯한 여러 중간 서버가 유효하지 않거나 잘못된 응답을 받을 경우
• 503(Service Unavailable)
  • 현재 서비스를 일시적으로 이용할 수 없음.
  • 서버가 과부하 상태에 있거나 일시적인 점검 상태일 때 볼 수 있는 상태.

 

05-3 HTTP 헤더와 HTTP 기반 기술

HTTP 헤더

요청 시 활용되는 헤더

• Host
  • 요청을 보낼 호스트를 나타내는 헤더.
  • 주로 도메인 네임으로 명시되며, 포트 번호가 포함되어 있을 수 있다.
• User-Agent
  • Host 헤더와 더불어 HTTP 요청 메시지에서 가장 흔히 볼 수 있는 헤더 중 하나.
    • Host: info.cern.ch
  • 웹 브라우저와 같이 HTTP 요청을 시작하는 클라이언트 측의 프로그램을 의미.
  • 운영체제 및 아키텍처 정보, 브라우저 종류 및 버전, 렌더링 엔진과 같은 다양한 정보가 포함.
  • 서버 입장에서는 User-Agent 헤더를 통해 클라이언트의 접속 환경을 유추할 수 있다.
• Referer
  • 클라이언트가 요청을 보낼 때 머무르고 있던 URL이 명시.
    • Referer: https://en.wikipedia.org/
  • 클라이언트의 유입 경로를 파악할 수 있다.
• Authorization
  • 클라이언트의 인증 정보를 담는 헤더.
  • 인증 타입(type)과 인증을 위한 정보(credentials)가 차례로 명시된다.
    • Authorization: <type> <credentials>
  • 가장 기본적인 HTTP 인증 타입은 Basic 타입으로, Base64(문자를 코드로 변환하는 방법) 인코딩한 값을 인증 정보로 삼는다.

 

응답 시 활용되는 헤더

• Server
  • 요청을 처리하는 서버 측의 소프트웨어와 관련된 정보를 명시.
    • Server: Apache/2.4.1 (Unix)
    • 'Unix 운영체제에서 동작하는 아파치 HTTP 서버' 라는 의미
• Allow
  • 클라이언트에게 허용된 HTTP 메서드 목록을 알려 주기 위해 사용된다.
  • 상태 코드 405(Method Not Allowed)를 응답하는 메시지에서 Allow 헤더가 함께 사용된다.
• Retry-After
  • 상태 코드 503(Service Unavailable)와 함께 사용되는 헤더로, 자원을 사용할 수 있는 날짜 혹은 시각을 나타낸다.
    • Retry-After: Fri, 23 Aug 2024 09:00:00 GMT
    • Retry-After: 120
• Location
  • 클라이언트에게 자원의 위치를 알려주기 위해 사용되는 헤더.
  • 주로 리다이렉션이 발생했을 때나 새로운 자원이 생성되었을 때 사용된다.
• WWW-Authenticate
  • 상태 코드 401(Unauthorized)과 함께 사용되는 헤더.
  • 자원에 접근하기 위한 인증 방식을 설명하는 헤더로 다음과 같이 보안 영역(realm)을 함께 알려주거나 인증에 사용될 문자집합(charset)도 알려 줄 수 있다.
    • WWW-Authenticate: Basic realm="Access to engineering site", charset="UTF-8"

 

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

• Date
  • 메시지가 생성된 날짜와 시각에 관련된 정보를 담은 헤더.
    • Date: Tue, 15 Nov 1994 08:12:31 GMT
• Connection
  • 클라이언트의 요청과 응답 간의 연결 방식을 설정하는 헤더.
  • 지속 연결(keep-alive)이 Connection에 명시되는 대표적인 연결 방식.
    • Connection: keep-alive
  • 연결을 종료하고 싶을 때 
    •  Connection: close
• Content-Length
  • 본문의 바이트 단위 크기(길이)를 나타낸다.
    • Content-Length: 100
• Content-Type, Content-Language, Content-Encoding
  • 이 헤더들은 전송하려는 메시지 본문의 표현 방식을 설명하는 헤더.
  • 표현 헤더(representation header)의 일종이라고도 부른다.
  • Content-Type 헤더는 메시지 본문에서 사용된 미디어 타입을 담고 있다.
    • Content-Type: text/html; charset=UTF-8
    • 메시지 본문이 HTML 문서 형식이며, 문자 인코딩으로 UTF-8을 사용한다는 정보를 알려줌.
  • Content-Language 헤더는 메시지 본문에 사용된 자연어를 언어 태그로 명시.
    • 첫 번째 서브 태그는 언어 코그로, 특정 언어를 의미하는 언어 코드가 명시된다.
      • ex) ko, en, zh, ja, de, fr
    • 두 번째 서브 태그는 국가 코드로, 특정 국가를 의미하는 국가 코드가 명시된다.
      • ex) KR, US, CN, JP, DE, FR, GB, TW
  • Content-Encoding 헤더에는 메시지 본문을 압축하거나 변환할 방식이 명시.
    • 수신 측은 이 헤더를 통해 압축 및 변환 방식을 인식하고, 압축을 해제하거나 원문으로 재변환하여 본문 내용을 확인할 수 있다.

 

캐시(cache)

• 불필요한 대역폭 낭비와 응답 지연을 방지하기 위해 정보의 사본을 임시로 저장하는 기술이다.
• 사본을 임시로 저장해 두면 동일한 요청에 대해 캐시된 데이터를 활용할 수 있기 때문에 불필요한 대역폭 낭비를 줄일 수 있고, 더 빠르게 데이터에 접근할 수 있다.
• 개인 전용 캐시: 캐시가 웹 브라우저에 저장되어 있는 경우.
• 공용 캐시: 클라이언트와 서버 사이에 위치한 중간 서버에 저장되어 있는 경우.
• 캐시 데이터에 유효 기간을 설정하고, 기간이 만료되었다면 원본 데이터를 다시 요청하는 방식으로 캐시 신선도를 유지할 수 있다.
  • Expires 헤더와 Cache-Control 헤더의 Max-Age 값(초)을 사용한다.
• 캐시가 만료되었더라도 캐시된 자원이 여전히 최신 정보라면 클라이언트는 굳이 서버로부터 같은 자원을 응답받지 않고, 캐시된 자원을 유효기간을 연장하여 이용하면 된다.
• 캐시의  신선도를 재검사하는 방법은 크게 두 가지 방법이 있다.
  • 날짜를 기반으로 서버에게 물어보는 방법
    • 클라이언트는 If-Modified-Since 헤더를 통해 서버에게 특정 시점 이후로 원본 데이터에 변경이 있었는지 물어본다.
    • 원본에 변경이 있다면 새 자원으로 응답하도록 서버에 요청.
  • 엔티티 태그(Etag)를 기반으로 서버에게 불어보는 방법
    • Etag는 자원의 버전을 식별하기 위한 정보
    • 자원이 변경될 때마다 자원의 버전을 식별하는 Etag 값이 변경된다.
    • 클라이언트는 If-None-Match 헤더를 통해 서버에게 Etag 값과 일치하는 자원이 있는지 물어본다.
    • Etag 값이 변경되었다면 새 자원으로 응답하도록 서버에 요청. 

 

쿠키

• 서버에서 생성되어 클라이언트 측에 저장되는 데이터로, 상태를 유지하지 않는 HTTP의 특성을 보완하기 위한 수단.
• 쿠키는 기본적으로 <이름, 값> 쌍의 형태를 띠고 있고, 추가로 적용 범위와 만료 기간 등 다양한 속성을 가질 수 있다.
• 서버는 쿠키를 생성하여 클라이언트에게 전송하고, 클라이언트는 전달받은 쿠키를 저장해 두었다가 추후 동일한 서버에 보내는 요청 메시지에 쿠키를 포함하여 전송한다.
• 서버는 쿠키 정보를 참고해 두 개의 요청이 같은 클라이언트에서 왔는지, 로그인 상태를 유지하고 있는지 등을 알 수 있다.
• 응답 메시지의 Set-Cookie 헤더와 요청 메시지의 Cookie 헤더를 통해 전달된다.
  • Set-Cookie: 이름=값; 속성1; 속성2
  • 쿠키를 이루는 정보로는 이름과 그에 대응되는 값뿐 아니라 도메인과 경로, 유효 기간, 보안 관련 속성이 있다.
• 쿠키의 대표적인 한계는 보안이다. 쿠키 정보가 쉽게 노출되거나 조작될 수 있기 때문이다.
• 이를 보완하기 위한 속성으로 Secure와 HttpOnly라는 속성이 있다.
  • Secure는 HTTPS 프로토콜이 사용되는 경우에만 쿠키를 전송되도록 하는 속성.
  • HttpsOnly는 HTTP 송수신을 통해서만 쿠키를 이용하도록 제한하는 속성.
    • 자바스크립트로 쿠키를 중간에 가로채거나 위변조 할 수 있기 때문에 자바스크립트에서 쿠키에 접근하지 못하도록 함.

 

세션 인증

쿠키를 통해 전달되는 대표적인 정보로 세션 아이디(session id)가 있다.
세션 아이디를 이해하기 위한 세션 인증(session authentication)은 다음과 같은 순서로 이루어지는 인증 방식이다.
1. 클라이언트는 서버에게 (아이디, 비밀번호와 같은) 인증 정보를 전송한다.
2. 인증 정보가 올바르다면, 서버는 세션 아이디를 생성해 클라이언트에게 전송한다.
3. 서버는 생성한 세션 아이디를 데이터베이스 등에 저장한다.
4. 클라이언트는 추후 요청을 보낼 때 쿠키 내에 세션 아이디를 포함하여 전송한다.
5. 서버는 쿠키 속 세션 아이디와 저장된 세션 아이디를 비교하여 클라이언트를 식별한다.
위와 같이 쿠키를 통해서 세션 아이디를 전송하면 요청을 보낼 때마다 번거로운 인증 과정을 거칠 필요가 없어서 효율적이다.

 

웹 스토리지: 로컬 스토리지와 세션 스토리지

쿠키 이외에도 클라이어트가 저장하고 클라이언트의 상태를 추측할 수 있는 웹 스토리지(web storage)가 있다.
웹 스토리지는 웹 브라우저 내의 저장 공간으로, 일반적으로 쿠키보다 더 큰 데이터를 저장할 수 있다.
또 쿠키는 서버로 자동 전송되지만, 웹 스토리지의 정보는 서버로 자동 전송되지 않고 필요할 때 조회할 수 있다.
웹 스토리지에는 로컬 스토리지와 세션 스토리지가 있다. 개발자 도구를 열고 [Application] -> [Storage]에서 확인할 수 있다.
세션 스토리지는 세션이 유지되는 동안(브라우저가 열려 있는 동안) 유지되는 정보이고,
로컬 스토리지는 별도로 삭제하지 않는 한 영구적으로 저장이 가능한 정보이다.

 

콘텐츠 협상과 표현

• 같은 URI에 대해 가장 적합한 '자원의 형태'를 제공하는 메커니즘.
• 같은 URI로 식별 가능한 HTML 문서라 해도, 영어로 요청하면 영어로 된 형태로 제공하고, 한국어로 요청하면 한국어로 된 형태를 제공하는 것.
• 이때, '송수신 가능한 자원의 형태'를 자원의 표현이라고 한다.
• 위에서 GET 메서드를 '자원을 습득하기 위한 메서드'라고 정의했다면 실제 GET 메서드의 정의는 '자원의 특정 표현을 습득하기 위한 메서드'이다.
• 클라이언트가 선호하는 표현을 반영하고자 콘텐츠 협상 관련 HTTP 헤더들이 사용된다.
  • 선호하는 미디어 타입을 나타내기 위한 Accept 헤더
  • 선호하는 언어를 나타내기 위한 Accept-Language 헤더
  • 선호하는 문자 인코딩과 압축 방식을 나타내기 위한 Accept-Charset 및 Accept-Encoding 헤더 등이 있다.
• 콘텐츠 협상은 선호도에 우선순위를 q 값으로 표현할 수 있다.(Quailty Value)
  • 생략되었을 경우에는 1을 의미하고, 범위는 0부터 1까지이며, 값이 클수록 우선순위가 높다.
  • Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
  • Accept: text/html,application/xml;q=0.9,text/plain;q=.06,*/*;q=0.5
  • 한국어, 영어 순으로 선호하고, HTML, XML, 일반 텍스트순으로 선호한다는 의미.