HTTP 헤더 및 캐시 설정

HTTP는 Hyper Text Transfer Protocol의 약자로, 하이퍼텍스트를 전송하는 프로토콜이다.

지금은 하이퍼텍스트(html) 뿐만 아니라 모든 형태의 데이터(이미지, 음성, 영상, 파일, 등등)를 다 전송할 수 있다.

 

 

HTTP메시지는 HTTP헤더와 HTTP바디로 이루어진다.

 

헤더는 HTTP 전송에 필요한 모든 부가 정보를 포함하고 있다.

바디는 요청에 대한 응답 데이터이다. (byte로 표현할 수 있는 모든 데이터)

오늘은 그 중 HTTP 헤더에 대해 알아 볼 것이다.

 

헤더에 들어가는 정보로는 메시지 바디의 내용, 크기, 압축, 인증정보, 브라우저 정보, 서버 정보, 캐시 정보 등등이 들어간다.

그 이외에도 필요한 임의의 필드를 추가할 수 있다.

 

헤더 필드는 다음과 같이 지정할 수 있다.

`field-name`: `field-value`

참고로 field-name은 대소문자 구분이 없다.

 

 

 

헤더의 필드 중 표현(Representation) 헤더라고 부르는 부분을 살펴보자.

표현은 리소스를 어떤 형식으로 표현하는지를 나타내는 정보이다. 즉 응답 헤더에서 찾아 볼 수 있다.

예를 들어 회원내역을 조회할 경우, 회원이라는 리소스를 html 혹은 json으로 표현하여 제공할 수 있다.

응답 헤더

- Content-type: 표현 데이터의 형식이다. 미디어타입과 문자 인코딩이 들어간다.

    (ex. Content-type: text/html; charset=utf-8)

- Content-Encoding: 표현 데이터의 압축방식

    (ex. Content-Encoding: gzip, deflate, br)

- Content-Language: 표현 데이터의 자연 언어

- Content-Length: 표현 데이터의 길이(바이트 단위)

    transefer-encoding을 사용하면 한번에 얼마의 데이터를 제공하는지 알지 못하므로 content-length가 없음

    전송방식은 단순전송, 압축전송, 분할 전송(Transfer-Encoding: chuncked), 범위전송이 있음

 

 

헤더의 필드 중 콘텐츠 협상(Negociation) 헤더라고 부르는 필드들이 있다.

클라이언트가 원하는 표현으로 서버에 달라고 요청하는 부분이다.

요청 헤더

- Accept: 클라이언트가 선호하는 미디어 타입

- Accept-Charset: 클라이언트가 선호하는 문자 인코딩

- Accept-Encoding: 클라이언트가 선호하는 압축 인코딩

- Accept-Language: 클라이언트가 선호하는 자연언어 (q를 사용하여 우선순위를 나타냄)

     (ex. Accept-Language: ko-KR; ko;q=0.9, en-US;q=0.8, en;q=0.7)

 

 

일반 정보

요청 헤더

- Referer: 이전 웹페이지 주소

     유입 경로 분석 할 때 사용됨

- User-Agent: 유저의 애플리케이션 정보

     통계정보로 이용가능. 이 헤더를 사용하여 특정 브라우저에서 발생하는 버그 파악 가능

응답 헤더

- Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보

- Date: HTTP 메시지가 발생한 날짜와 시간

 

 

특별한 정보

응답 헤더

- Host : 요청한 호스트정보(도메인). 필수값으로 http 2에서는 authority로 대체됨.

- Location: 페이지 리다이렉션 (3xx 응답에 Location 헤더가 있으면, 이 위치로 이동)

 

 

인증 헤더

요청 헤더

- Authorization: 클라이언트의 인증 정보를 서버에 전달

 

 

쿠키

응답 헤더

- Set-Cookie : 서버에서 클라이언트로 쿠키 전달

요청 헤더

- Cookie: 클라이언트가 HTTP 요청 시 서버에 전달하는 쿠키

 

- 모든 쿠키는 요청시 항상 서버에 전송됨 => 네트워크 트래픽 추가 유발. 최소한의 정보만 쿠키에 담아 사용

 

쿠키 생성시,

- domain: 정보를 넣으면 서브도메인까지 쿠키를 전송함. 도메인을 생략한 경우, 서브도메인은 접근 불가.

ex) domain=example.org => example.org, dev.example.org 도 접근 가능

- path : 경로를 포함한 하위 경로 페이지만 쿠키 접근 (보통 루트 경로로 지정. path=/ )

- secure: https인 경우에만 전송

- HttpOnly: 자바스크립트에서는 접근 불가

- SameSite: 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키 전송 가능 (구 브라우저는 지원x)

 

 

캐시

캐시는 요청헤더와 응답헤더의 조합에 의해 제어된다. 캐시를 제어하기 위해서 세가지 방법을 사용할 수 있다.

 

1. Cache-Control

- Cache-Control: 캐시 응답 방법과 시간 설정

    - max-age=초단위 (캐시 유효시간)

    - no-cache: 데이터는 캐시해도 되지만, 항상 원서버에 검증받아 사용

    - no-store: 저장하지 않음(캐시사용x). 메모리에서만 사용하고 최대한 빨리 삭제.

- Expires: 캐시만료일 지정 (1.1버전에서 사용되었음. cache-control과 함께 있으면 expires는 무시됨)

 

=> 캐시 유효시간이 초과하여 서버에 다시 요청할 때, 서버에서 기존 데이터가 그대로인 경우가 있음

이때 사용하는 것이 검증 헤더

 

검증 헤더

2. Last-Modified

- Last-Modified: 시간 (UTC 표기법)

  응답 결과를 캐시에 저장하면서, 데이터 최종 수정일도 함께 저장

- if-modified-since: last-modified값

  브라우저가 요청헤더에 조건부 요청을 넣어 요청. 서버에서 데이터 최종 수정일을 보고 검증할 수 있음

  수정이 안되었다면, `304 Not Modified` 를 함께 보내어, 캐시에 저장된 데이터 활용(body없음)

 

3. ETag

- ETag: 캐시용 데이터를 위한 해쉬값. 서버에서 부여. 데이터가 변경되면  값이 변경됨.

  캐시 제어 로직을 완전히 서버에서 캐시를 관리하는 방법 (클라이언트에서는 캐시 메커니즘을 알 수 없음)

- if-None-Match: etag 값

   요청헤더에 넣어서 보냄. 서버에서 etag가 똑같으면 304, 아니면 200.

 

 

 

캐시 무효화

돈과 관련된 데이터의 경우, 항상 최신 데이터를 유지할 필요가 있다. 웹브라우저들이 캐시를 설정하지 않아도 임의로 캐시를 적용시키기도 하므로, 최신데이터가 필요한 경우 다음과 같은 설정을 넣어주어야 한다.

- Cache-Control: no-cache, no-store, must-revalidate

    - must-revalidate: 캐시 만료 후 최초 조회 시 원서버에 검증해야함. 원서버 접근 실패시 504 에러 발생

- Pragma: no-cache  (HTTP 1.0 하위 호환)