HTTP 헤더

HTTP 헤더 : HTTP 전송에 필요한 모든 부가정보를 포함. 표준 헤더 너무 많음. 필요시 임의의 헤더 추가 가능하다.

2014년 RFC7230~7235 등장. 엔티티에서 표현으로 바뀜. 표현 = 표현 메타데이터+표현 데이터

• 메세지 본문을 통해 표현 데이터를 전달한다. 메세지 본문은 페이로드

• 표현은 요청이나 응답에서 전달할 실제 데이터. 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공(데이터 유형, 데이터 길이, 압축 정보)

• 표현 : Content-Type : 표현 데이터의 형식, Content-Encoding : 표현 데이터의 압축 방식, Content-Language : 표현 데이터의 자연 언어, Content-Length : 표현 데이터의 길이. 표현 헤더는 전송, 응답 둘다 사용한다.

• Content-Type : 미디어 타입, 문자 인코딩(text/html, application/json, image/png)

• Content-Encoding : 표현 데이터를 압축하기 위해 사용한다. 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가한다. 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제한다.(예)gzip, deflate, identity)

• Content-Language : 표현 데이터의 자연 언어를 표현한다.(예 : ko,en,en-US)

• Content-Length : 표현 데이터의 길이. 바이트 단위이다. Transfer-encoding을 사용하면 Content-Length를 사용하면 안된다.

• 협상 : 컨텐츠 네고시에이션. 클라이언트가 선호하는 표현을 요청하는 것이다. Accept: 클라이언트가 선호하는 미디어 타입을 전달한다, Accept-Charset : 클라이언트가 선호하는 문자 인코딩, Accept-Encoding : 클라이언트가 선호하는 압축 인코딩, Accept-Language : 클라이언트가 선호하는 자연 언어. 협상 헤더는 요청시에만 사용한다.

• 협상과 우선순위에서 Quality Values(q)값 사용한다. 0~1 사이이고 클수록 높은 우선순위를 가진다. 생략하면 1이다. 그리고 구체적인 것이 우선한다. 구체적인 것을 기준으로 미디어 타입을 맞춘다.
  

• 전송방식 : 단순 전송, 압축 전송, 분할 전송, 범위 전송이 있다.

• 일반 전송 : From : 유저 에이전트의 이메일 정보. 일반적으로 사용되지 않는다. 검색 엔진 같은 곳에서 사용하고 요청에서 사용한다., Referer: 이전 웹 페이지 주소. 이걸 활용해서 유입 경로 분석 가능하다., User-Agent: 유저 에이전트 어플 정보. 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능하다., Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보. apache,nginx가 있다., Date: 메세지가 생성된 날짜

• 특별한 정보 : Host : 요청한 호스트의 정보. 요청에서 사용한다. 하나의 IP 주소에 여러 도메인이 적용되어 있을때 사용한다., Location : 페이지 리다이렉션. 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면 Location 위치로 자동 이동한다., Allow : 허용 가능한 HTTP 메서드. 405에서 응답에 포함해야 한다., Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간.

• 인증 : Authorization : 클라이언트 인증 정보를 서버에 전달한다. WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의. 401 Unauthorized 응답과 함께 사용한다.

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

  2. Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고 HTTP 요청시 서버로 전달
  • HTTP는 무상태 이므로 모든 요청에 정보를 넘겨야 한다. 리소스 문제가 발생할 수 있다. 따라서 쿠키를 활용한다. 쿠키 저장소에 있는 데이터를 사용해서 서버에 요청한다.
    
  • 사용자 로그인 세션 관리, 광고 정보 트래킹등에 사용된다. 쿠키 정보는 항상 서버에 전송되므로 최소한의 정보만 사용한다. 서버에 전송하고 싶지 않으면 웹 스토리지 사용한다. 참고로 보안에 민감한 데이터는 저장하면 안된다.
  • 쿠키의 생명주기 : Expires : 만료일이 되면 쿠키 삭제, max-age : 0이나 음수를 지정하면 쿠키 삭제. 세션 쿠키는 만료 날짜를 생략하면 브라우저 종료시 까지만 유지한다. 영속 쿠키는 만료 날짜를 입력하면 해당 날짜까지 유지한다.
  • 쿠키에 도메인 지정할때는 명시했을 경우 명시 문서 기준 도메인 + 서브 도메인을 포함한다. 생략한 경우 문서 기준 도메인만 적용한다.
  • 쿠키에 경로를 넣은 경우 이 경로를 포함한 하위 경로 페이지만 쿠키에 접근한다.
  • 쿠키의 보안 : Secure를 적용하면 https인 경우에만 전송한다. HttpOnly를 쓰면 XSS 공격 방지. 자바스크립트에서 접근 불가. HTTP 전송에만 사용한다. SameSite를 적용하면 XSRF 공격을 방지한다. 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키를 전송한다.

• 캐싱 : 캐시가 없을때는 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. 헤더에 cache-control : max-age=60과 같이 설정한다.
  
  캐시 유효 시간이 초과해서 서버에 다시 요청하면 서버에서 기존 데이터를 변경한 경우 혹은 서버에서 기존 데이터를 변경하지 않은 경우가 있다. 캐시 만료 후에도 서버에서 데이터를 변경하지 않는다면 데이터를 전송하는 대신 저장했던 캐시를 재사용 할 수 있다. 단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다. 검증헤더를 추가하면 된다. 캐시 유효 시간이 초과해도 서버의 데이터가 갱신되지 않으면 304 Not Modified + 헤더 메타 정보만 응답한다. 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신한다. 클라이언트는 캐시에 저장되어 있는 데이터를 재활용한다. 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드한다.
  

• 검증헤더와 조건부 요청 : 검증헤더는 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터이다. Last-Modified, ETag가 있다. 조건부 요청 헤더는 검증헤더로 조건에 따른 분기를 한다. If-Modified-Since는 Last-Modified를 사용하고 If-None-Match는 ETag를 사용하고 조건이 만족하면 200 아니면 304를 반환한다. 단점은 1초 미만으로 캐시 조정이 불가능하고 날짜 기반의 로직을 사용한다는 것이다. 같은 데이터를 수정해서 데이터 결과가 같고 수정을 했기때문에 날짜가 다른 경우에는 캐싱이 안된걸로 인식한다. 그런 경우 ETag를 써서 캐시 데이터에 임의의 고유 버전 이름을 달아둠으로써 고유 이름이 바뀌면 다시 받는 방법을 쓴다. 캐시 제어 로직을 서버에서 완전히 관리할 수 있으며 클라이언트는 단순히 이 값을 서버에 제공하기만 하면 된다.
  

• 캐시 제어 헤더
  1. Cache-Control : 캐시 제어

  • max-age : 캐시 유효 시간, 초 단위, no-cache : 데이터는 캐시해도 되지만 항상 원 서버에 검증하고 사용한다., no-store: 데이터에 민감한 정보가 있으므로 저장하면 안된다.
    2.Pragma : 캐시 제어, HTTP 1.0 하위 호환이다.
  • no-cache.
  3. Expires: 캐시 만료일을 정확한 날짜로 지정한다. 지금은 더 유연한 Cache-Control: max-age를 사용한다. 이걸 사용하면 Expires를 무시한다.

• 검증 헤더와 조건부 요청 헤더
  1. 검증 헤더 : ETag, Last-Modified

  2. 조건부 요청 헤더 : If-Match, If-None-Match는 ETag 값 사용
  3. If-Modified-Since, If-Unmodified-Since : Last-Modified 값 사용한다.

• 프록시 캐시
  

• Cache-Control : public 응답이 public 캐시에 저장되어도 됨, private : 응답이 해당 사용자만을 위한 것임. private 캐시에 저장해야 함, s-maxage : 프록시 캐시에만 적용되는 max-age, age : 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간이다. 캐시 무효화를 하려면 Cache-Control : no-cache, no-store, must-revalidate// Pragma: no-cache 라고 쓰자. no-cache는 데이터는 캐시해도 되지만 항상 원 서버에 검증하고 사용하자는 뜻이고 no-store는 데이터에 민감한 정보가 있으므로 저장하면 안된다는 뜻이다. must-revalidate는 캐시 만료후 최초 조회시 원 서버에 검증해야 한다는 뜻이다. 원 서버 접근 실패시 반드시 오류가 발생해야 한다.

• no-cache vs must-revalidate :
  no-cache : 캐시 서버 요청 > 원서버 접근 > 접근 안됨 > 서버 설정에 따라서 캐시 데이터를 반환할 수 있음.
  must-revalidate : 캐시 서버 요청 > 원 서버에 접근 > 접근 불가능시 항상 오류 발생 504반환
  
  

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