7. HTTP 헤더 - 2

인증

Authorization: 클라이언트 인증 정보를 서버에 전달
WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의

Authorization

클라이언트 인증 정보를 서버에 전달

Authorization: Basic xxxxxxxxxxxxxxxx

WWW-Authenticate

리소스 접근시 필요한 인증 방법 정의

• 리소스 접근시 필요한 인증 방법 정의 일종의 가이드라인
• 401 Unauthorized 응답과 함께 사용
• WWW-Authenticate: Newauth realm="apps", type=1, title="Login to \"apps\"", Basic realm="simple"

쿠키

• Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)

• Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달

• 주로 사용자 로그인 세션 관리에 사용하고 광고 정보 트래킹 같은 곳에서도 활용됨

• 쿠키 정보는 항상 서버에 전송됨

  • 네트워크 트래픽 추가 유발
  • 최소한의 정보만 사용(세션 id, 인증 토큰)

• 보안에 민감한 데이터는 저장하면 안됨(주민번호, 신용카드 번호 등등)

• ※ 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 (localStorage, sessionStorage) 활용함

쿠키를 쓰는 이유

Stateless

• HTTP는 무상태(Stateless) 프로토콜이다.

• 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어지고 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다 즉 클라이언트와 서버는서로 상태를 유지하지 않는다.

• ※ 예를 들어 로그인을 한 상황을 서버는 알 수 없고 사용자 정보가 필요하다면 요청마다 정보를 넘겨야하는 상황이 발생함

쿠키 적용예

1. 로그인후 쿠키 발급

2. 로그인 이후 요청 과정

쿠키 생명주기

Expires, max-age

• Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
  • 만료일이 되면 쿠키 삭제
• Set-Cookie: max-age=3600 (3600초)
  • 0이나 음수를 지정하면 쿠키 삭제

• 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
• 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

쿠키 도메인

Domain

명시 : 명시한 문서 기준 도메인 + 서브 도메인 포함

• domain=example.org 를 지정해서 쿠키 생성
  • example.org 는 물론이고
  • dev.example.org 도 쿠키 접근

생략: 현재 문서 기준 도메인만 적용

• example.org 에서 쿠키를 생성하고 domain 지정을 생략
  • example.org 에서만 쿠키 접근
  • dev.example.org 는 쿠키 미 접근

쿠키 경로

Path

• 이 경로를 포함한 하위 경로 페이지만 쿠키 접근
• 일반적으로 path=/ 루트로 지정

쿠키 보안

Secure, HttpOnly, SameSite

• Secure
  • 쿠키는 http, https 를 구분하지 않고 전송
  • Secure를 적용하면 https인 경우에만 전송
• HttpOnly
  • XSS 공격 방지
  • 자바스크립트에서 접근 불가(document.cookie)
  • HTTP 전송에만 사용
• SameSite
  • XSRF 공격 방지
  • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

캐시

• 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
• 비싼 네트워크 사용량을 줄일 수 있다
• 브라우저 로딩 속도가 빠르기 대문에 좋은 사용자 경험을 제공함

캐시 제어 헤더

• Cache-Control: 캐시 제어
• Pragma: 캐시 제어(하위 호환)
• Expires: 캐시 유효 기간(하위 호환)

Cache-Control

캐시 지시어(directives)

• Cache-Control: max-age=value
  • 캐시 유효 시간, 초 단위
• Cache-Control: no-cache
  • 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
• Cache-Control: no-store
  • 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)

Pragma

캐시 제어(하위 호환)

• Pragma: no-cache
• HTTP 1.0 하위 호환

Expires

캐시 만료일 지정(하위 호환)

• expires: Mon, 01 Jan 1990 00:00:00 GMT
• 캐시 만료일을 정확한 날짜로 지정
• 지금은 더 유연한 Cache-Control: max-age 권장
• Cache-Control: max-age와 함께 사용하면 Expires는 무시

캐시 사용 예

1. 데이터 요청 후 헤더에 캐시 관련 내용을 포합한 응답을 받음

2. 캐시에 저장

3. 캐시 유효시간내 같은 요청은 캐시에 있는 데이터를 활용

캐시 유효 시간 초과시

• 캐시 유효 시간이 초과하면 위 과정 처럼 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다.
• 이때 다시 네트워크 다운로드가 발생한다.

캐시 유효 시간 초과시에 캐시내용 재사용

캐시 만료후에도 서버에서 데이터를 변경하지 않은 상황에서클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있다면 저장해 두었던 캐시를 재사용 할 수 있다.

검증 헤더와 조건부 요청

• 검증 헤더
  • 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
  • Last-Modified, ETag
• 조건부 요청 헤더
  • 검증 헤더로 조건에 따른 분기
  • If-Modified-Since, If-Unmodified-Since: Last-Modified 사용
  • If-Match, If-None-Match: ETag 사용
  • 조건이 만족하면 200 OK
  • 조건이 만족하지 않으면 304 Not Modified

Last-Modified, If-Modified-Since, If-Unmodified-Since

• 1초 미만(0.x초) 단위로 캐시 조정이 불가능

• Last-Modified
  • 서버에서 클라이언트에 응답 시 최종 수정 날짜를 의미하는 헤더
  • 클라이언트에서 최종 수정 날짜를 저장하기 위함
• If-Modified-Since, If-Unmodified-Since
  • 클라이언트에서 서버에 요청 시 응답하는 최종 수정 날짜를 의미하는 헤더
  • 서버의 최종 수정 날짜가 동일한지 체크하기 위함

ETag, If-Match, If-None-Match

• 단순한 로직
• 캐시 제어 로직을 서버에서 완전히 관리

• ETag
  • 서버에서 클라이언트에 응답 시 고유한 버전 이름을 의미하는 헤더
  • 데이터가 변경되면 이 고유한 버전 이름을 바꾸어서 변경함
  • 클라이언트에서 고유한 버전 이름을 저장하기 위함
• If-Match, If-None-Match
  • 클라이언트에서 서버에 요청 시 응답하는 고유한 버전 이름을 의미하는 헤더
  • 서버의 고유한 버전 이름이 동일한지 체크하기 위함

과정

※ Last-Modified 를 활용한 예

1. 서버에 데이터 요청 후 검증 헤더를 포함한 응답을 받음

2. 캐시에 저장

3. 서버에 조건부 요청 헤더를 포함한 요청을 보내고 조건을 확인함

4. 서버에서 body 데이터 없이 헤더 메타 정보만 응답하고 클라이언트는 캐시에 저장되어 있는 데이터 재활용

프록시 캐시

Cache-Control

캐시 지시어(directives) - 기타

• Cache-Control: **public
  • 응답이 public 캐시에 저장되어도 됨
• Cache-Control: private
  • 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)
• Cache-Control: s-maxage
  • 프록시 캐시에만 적용되는 max-age
• Age: value (HTTP 헤더)
  • 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

원서버 직접 접근

프록시 캐시 도입

캐시 무효화

Cache-Control

확실한 캐시 무효화 응답

• Cache-Control: no-cache
  • 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!)
• Cache-Control: no-store
  • 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제)
• Cache-Control: must-revalidate
  • 캐시 만료후 최초 조회시 원 서버에 검증해야함
  • 원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
  • must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
• Pragma: no-cache
  • HTTP 1.0 하위 호환

no-store 와 must-revalidate비교

참고

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC