[혼자 공부하는 네트워크] Chapter 5 - 3 HTTP 헤더와 HTTP 기반 기술

HTTP 헤더

HTTP 헤더는 아주 다양하기 때문에 자주 활용되는 중요한 HTTP 헤더들을 위주로 알아보자.

요청 시 활용되는 HTTP 헤더

HTTP 요청 메시지에 활용되는 대표적인 헤더를 알아보자.

• Host
  • 요청을 보낼 호스트를 나타내는 헤더. 주로 도메인 네임으로 명시되며, 포트 번호가 포함될 수 있다.
• User-Agent
  • 웹 브라우저와 같이 HTTP 요청을 시작하는 클라이언트 측의 프로그램을 의미한다.
  • 서버 입장에서는 이 정보를 통해 클라이언트의 접속 환경을 유추할 수 있다.
• Referer
  • 클라이언트가 요청을 보낼 때 머무르고 있던 URL을 명시하는 정보이다.
  • 이 정보로 클라이언트의 유입 경로를 알 수 있다.
• Authorization
  • 클라이언트의 인증 정보가 담겨있다. 인증 타입과 인증을 위한 정보가 차례로 명시된다.
  • 가장 기본적인 인증 타입은 Basic으로, 사용자 아이디와 비밀번호를 콜론을 이용해 합친 뒤, Base64 인코딩한 값을 인증 번호로 삼는 방식이다.

응답 시 활용되는 HTTP 헤더

• Server
  • 요청을 처리하는 서버 측의 소프트웨어와 관련된 정보
• Allow
  • 클라이언트에게 허용된 HTTP 메서드 목록을 알려주기 위해 사용. 상태 코드 405 ‘요청한 메서드를 지원하지 않음’에서 사용된다.
• Retry-After
  • 상태 코드 503 ‘현재는 요청을 처리할 수 없으나 추후 가능할 수도 있음’에서 사용된다. 자원을 사용할 수 있는 날짜 혹은 시각을 나타낸다.
• Location
  • 클라이언트에게 자원의 위치를 알려주기 위해 사용되는 헤더. 리다이렉션이 발생하거나, 새로운 자원이 생성되었을 때 사용된다.
• WWW-Authenticate
  • 자원에 접근하기 위한 인증 방식을 설명하는 헤더. 상태 코드 401 ‘유효한 인증이 없음’에서 사용된다.

클라이언트의 Authorization 헤더와 서버의 WWW-Authenticate 헤더를 통해 클라이언트가 HTTP 인증을 수행하는 과정은 다음과 같다.

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

• Date
  • 메시지가 생성된 날짜와 시각에 관련된 정보
• Connection
  • 클라이언트의 요청과 응답 간의 연결 방식을 설정하는 헤더. 지속 연결을 희망할 땐 keep-alive 값을, 연결을 종료하고 싶다면 close 값을 첨부해서 보낼 수 있다.
• Content-Length
  • 본문의 바이트 단위 크기
• Content-Type, Content-Language, Content-Encoding
  • 메시지 본문의 표현 방식을 설명한다.
  • Content-Type엔 본문에서 사용된 미디어 타입을 다룬다.
  • Content-Language에선 메시지 본문이 어떤 언어로 작성되어 있는지를 다룬다.
  • Content-Encoding에선 메시지 본문을 압축하거나, 변환한 방식이 명시되어 있다.

캐시

클라이언트가 서버에게 크기가 큰 자원을 자주 요청한다면 서버는 과부하가 걸릴 수 있다. 이를 방지하고자 오늘날의 인터넷 환경에서는 HTTP 캐시(혹은 웹 캐시)를 활용한다.

캐시는 불필요한 대역폭 낭비와 응답 지연을 방지하기 위해 정보의 사본을 임시로 저장하는 기술이다. 캐시는 웹 브라우저에 저장되어 있기도 하고, 클라이언트와 서버 사이에 위치한 중간 서버에 저장되기도 한다. 각각 개인 전용 캐시, 공용 캐시라고 불린다. 개인 전용 캐시에 초점을 맞춰 알아보자.

캐시는 원본이 아닌 사본을 저장한다. 따라서 캐시 이후 원본 데이터가 변경되는 상황에 대비해야 한다. 이런 대비를 위해 캐시에 만료 기간이 함께 부여된다. 만료 기간은 응답 메시지의 헤더에 함께 첨부된다.

만약 시간이 흘러 캐시의 만료기간이 도래했어도 자원이 변경되지 않았다면, 여전히 아직 사용해도 되는 자원이다. 반면에 만료 기간 이후에 자원이 변경되었다면 최신 자원을 서버에게 요청해야 한다. 이렇게 현재 캐시가 변경되었는지 아닌지를 체크하는 방법은 크게 두 가지가 있다.

• 날짜를 기반으로 서버에게 질의
  • 클라이언트가 If-Modified-Since 헤더를 통해 서버에게 특정 시점 이후로 원본 데이터가 변경되었는지 질의한다.
  • 자원이 변경되었다면 상태 코드 200과 함께 새로운 자원을 반환한다.
  • 자원이 변경되지 않았다면, 본문 없는 상태 코드 304를 보내 변경되지 않았음을 알린다.
  • 자원이 삭제되었다면, 상태 코드 404를 통해 자원이 존재하지 않음을 알린다.
• 엔티티 태그를 기반으로 서버에게 질의
  • 엔티티 태그는 자원의 버전을 식별하기 위한 정보이다. 자원이 변경될 때마다 자원의 버전을 식별하는 Etag라는 값이 변경된다. 클라이언트는 If-None-Match 헤더를 통해 Etag값을 첨부하여 값이 변했는지 서버에 질의한다.
  • 자원이 변경되었다면 상태 코드 200과 함께 변경된 데이터와 Etag값을 보낸다.
  • 자원이 변경되지 않았다면, 본문이 없는 상태 코드 304를 보내 변경되지 않았음을 알린다.
  • 자원이 삭제되었다면, 상태 코드 404를 보낸다.

쿠키

HTTP는 상태를 유지하지 않는 프로토콜이지만, 클라이언트의 상태를 알아야만 하는 순간이 분명 존재한다. 이는 쿠키를 통해 구현할 수 있다.

쿠키는 서버에서 생성되어 클라이언트 측에 저장되는 데이터이다. 쿠키는 ‘이름, 값’의 형태를 띠고 있고, 추가로 적영 범위와 만료 기간 등 다양한 속성을 가질 수 있다. 이 정보를 통해 서버에서 클라이언트의 상태를 알 수 있게 된다.

서버는 쿠키를 생성하여 클라이언트에게 전송하고, 클라이언트는 전달받은 쿠키를 저장해 두었다가 추후 동일한 서버에 보내는 요청 메시지에 쿠키를 포함해서 전송한다.

💡 세션 인증 쿠키로 전달되는 대표적인 정보로 세션 아이디가 있다. 이는 클라이언트가 서버에게 전송한 인증정보로 통해 생성된 아이디이다. 클라이언트는 세션 아이디를 받으면, 매번 요청을 보낼 때마다 세션 아이디를 함께 보내야 한다. HTTP는 스테이트리스 프로토콜이기 때문에 모든 요청을 별개의 요청으로 간주한다. 하지만 서버로부터 받은 세션아이디를 함께 전송하면 어떤 클라이언트가 보냈는지 알 수 있게 되므로, 매번 인증할 필요가 없다.

서버가 클라이언트에게 쿠키를 전달해 주기 위해선 Set-Cookie 헤더에 값을 넣어서 전달해 주고, 요청메시지에선 Cookie 헤더에 포함되어 서버에 전송된다.

하지만 쿠키에도 한계가 존재한다. 바로 보안이 한계인데, 쿠키에 개인 정보를 비롯해 보안에 민감한 정보를 보내는 것은 바람직하지 않다. 쿠키 정보가 쉽게 노출되거나 조작되기 때문이다.

이를 보완하기 위해 속성으로 Secure와 HttpOnly라는 속성이 있다.

• Secure : HTTPS 프로토콜이 사용되는 경우에만 쿠키를 전송하는 속성
• HttpOnly : HTTP 송수신을 통해서만 쿠키를 이용하도록 제한하는 속성. 자바스크립트에서 쿠키에 접근하지 못하게 막는 속성이다.

💡 웹 스토리지 웹 스토리지는 쿠키 이외에 클라이언트가 저장하고 클라이언트의 상태를 추측할 수 있는 키-값 형태의 정보이다. 웹 스토리지는 웹 브라우저 내의 저장 공간으로, 일반적으로 쿠키보다 더 큰 데이터를 저장할 수 있다. 또 쿠키는 서버로 자동 전송되지만, 웹 스토리지의 정보는 자동 전송되지 않는다. 웹 스토리지는 크게 로컬 스토리지와 세션 스토리지로 나눌 수 있다. 세션 스토리지는 세션이 유지되는 동안 유지되는 정보이고, 로컬 스토리지는 별도로 삭제하지 않는 한 저장이 가능한 정보이다.

콘텐츠 협상과 표현

콘텐츠 협상은 같은 URI에 대해 가장 적합한 자원의 형태를 제공하는 메커니즘을 의미한다. 같은 URI로 식별 가능한 HTML 문서라 해도, 영어로 요청하면 영어로 된 형태로 제공하고, 한국어로 요청하면 한국어로 된 형태를 제공하는 것 또한 콘텐츠 협상이 있기 때문이다.

이때 ‘송수신 가능한 자원의 형태’를 자원의 표현이라고 한다. 즉, 콘텐츠 협상은 클라이언트에게 가장 적합한 자원의 표현을 제공하는 메커니즘이다.

콘텐츠 협상을 위해서 다양한 HTTP 헤더가 사용된다.

• Accept : 선호하는 미디어 타입
• Accept-Language : 선호하는 언어
• Accept-Charset : 선호하는 문자 인코딩 방식
• Accept-Encoding : 선호하는 압축 방식

콘텐츠 협상은 선호도에 우선순위를 받을 수 있다. 예를 들어 클라이언트가 ‘한국어를 선호하지만, 영어도 받을 용의가 있다’라는 식으로 선호도를 담아서 보낼 수 있다. 이런 선호도는 헤더의 q값을 첨부하여 보낼 수 있다.