• 해당 게시물은 인프런 - "모든 개발자를 위한 HTTP 웹 기본 지식" 강의를 참고하여 작성한 글 입니다.
• 유료강의이므로 자세한 내용은 없고, 간단한 설명 위주로 정리했습니다.
  강의 링크 -> 김영한 - 모든 개발자를 위한 HTTP 웹 기본 지식 (유료강의)
  

---

📖 HTTP 헤더 1 - 일반 헤더

📒 HTTP 헤더 개요

HTTP 헤더

header-field =field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)

HTTP 전송에 필요한 모든 부가정보(메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등)

HTTP 바디

메시지 본문(페이로드)로 데이터 전달
표현은 전달할 실제 데이터이며, 표현 헤더(데이터 유형, 길이, 압축 정보 등)는 표현 데이터를 해석할 수 있는 정보 제공

📒 표현

• Content-Type: 표현 데이터의 형식
  ex) text/html; charset=utf-8, application/json, image/png

• Content-Encoding: 표현 데이터의 압축 방식
  ex) gzip, deflate, identity

• Content-Language: 표현 데이터의 자연 언어
  ex) ko, en, en-US

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

📒 콘텐츠 협상

• Accept
  클라이언트가 선호하는 미디어 타입 전달

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

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

• Accept-Language
  클라이언트가 선호하는 자연 언어

🖋️ 협상과 우선순위

Quality Values(q)

0~1 사이, 클수록 높은 우선순위, 생략 = 1
ex) Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

구체적인 것이 우선
ex) Accept: text/*, text/plain, text/plain;format=flowed, */*

📒 전송 방식

• 단순 전송
  ex) Content-Length: 3423

• 압축 전송
  ex) Content-Encoding: gzip

• 분할 전송
  ex) Transfer-Encoding: chunked

• 범위 전송
  ex) Content-Range: bytes 1001-2000 / 2000

📒 일반 정보

• From: 유저 에이전트의 이메일 정보

• Referer: 이전 웹 페이지 주소
  A -> B로 이동하는 경우 B를 요청할 때 -> ex) Referer: A
  유입 경로 분석 가능

• User-Agent: 유저 에이전트 애플리케이션 정보
  ex) user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/ 537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36

• Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
  ex) Server: Apache/2.2.22 (Debian)
  ex) server: nginx

• Date: 메시지가 생성된 날짜
  ex) Date: Tue, 15 Nov 1994 08:12:31 GMT

📒 특별한 정보

• Host: 요청한 호스트 정보(도메인)
  필수 값
  하나의 서버가 여러 도메인을 처리해야 할 때
  하나의 IP 주소에 여러 도메인이 적용되어 있을 때
  ex) Host: www.google.com

• Location: 페이지 리다이렉션
  201 (Created): Location 값은 요청에 의해 생성된 리소스 URI
  3xx (Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를
  가리킴

• Allow: 허용 가능한 HTTP 메서드
  405 (Method Not Allowed) 에서 응답에 포함해야함
  ex) Allow: GET, HEAD, PUT

• Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
  503 (Service Unavailable): 서비스가 언제까지 불능인지 알려줌
  ex) Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜 표기)
  ex) Retry-After: 120 (초단위 표기)

📒 인증

• Authorization: 클라이언트 인증 정보를 서버에 전달
  ex) Authorization: Basic xxxxxxxxxxxxxxxx

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

📒 쿠키

Stateless
HTTP는 무상태(Stateless) 프로토콜
클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어짐
클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못함
클라이언트와 서버는 서로 상태를 유지하지 않음

이러한 문제점을 해결하기 위해 쿠키(Cookie) 를 사용한다.

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

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

모든 요청에 쿠키 정보 자동 포함

쿠키는 주로 사용자 로그인 세션 관리에 사용되고, 쿠키 정보는 항상 서버에 전송되며, 최소한의 정보만 사용해야 한다.

set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secure

• 생명주기: expires, max-age
  만료일이 되면 쿠키 삭제
  ex) expires=Sat, 26-Dec-2020 04:39:21 GMT
  ex) max-age=3600 (3600초)

• 도메인: domain
  명시한 문서 기준 도메인 + 서브 도메인 포함
  ex) domain=example.org
  생략하면 현재 문서 기준 도메인만 적용

• 경로: path
  경로를 포함한 하위 경로 페이지만 쿠키 접근
  ex) path=/home

• 보안: Secure, HttpOnly
  Secure - HTTPS인 경우에만 전송
  HttpOnly - 자바스크립스에서 접근 불가하고, HTTP 전송에만 사용

---

📖 HTTP 헤더 2 - 캐시와 조건부 요청

📒 캐시 기본 동작

캐시가 있을 때

• 똑같은 요청이 왔을 때, 해당 데이터가 캐시에 있으면 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨
• 비싼 네트워크 사용량을 줄일 수 있음
• 브라우저 로딩 속도가 매우 빠름

캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신하여 네트워크를 통해 데이터를 다운로드 한다.

📒 검증 헤더와 조건부 요청1

캐시 유효 시간이 초과해서 서버에 다시 요청할 경우 2가지 상황

• 서버에서 기존 데이터를 변경함 ex) ❤️->💚
• 서버에서 기존 데이터를 변경하지 않음 ex) ❤️

캐시 만료 후에도 서버에서 데이터를 변경하지 않았을 경우, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요하다.

🖋️ 검증 헤더 추가

Last-Modified

데이터가 마지막에 수정된 시간
ex) Last-Modified: 2020년 11월 10일 10:00:00

서버에 있는 요청 데이터의 최종 수정일을 비교하여 같을 경우, HTTP 상태코드로 304 Not Modified를 보내고 서버에서는 요청 받은 데이터를 전송하지 않는다.(HTTP Body 없음)

검증 헤더와 조건부 요청

• 캐시 유효 시간이 초과, 서버의 데이터 갱신X -> 304 Not Modified + 헤더 메타 정보 응답(바디X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 용량이 적은 헤더 정보만 다운로드하여 실용적

📒 검증 헤더와 조건부 요청2

• 검증헤더
  캐시 데이터와 서버 데이터가 같은지 검증
  ex) Last-Modified , ETag

• 조건부 요청 헤더
  If-Modified-Since: Last-Modified 사용
  If-None-Match: ETag 사용
  조건 만족 -> 200 OK, 조건 불만족 -> 304 Not Modified

Last-Modified, If-Modified-Since 단점

• 1초 미만(0.x초) 단위로 캐시 조정이 불가능
• 데이터를 수정해서 날짜가 다르지만, 데이터 결과가 똑같은 경우
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우

🖋️ ETag, If-None-Match

캐시 제어 로직을 서버에서 완전히 관리

ETag(Entity Tag)

• 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠
  ex) ETag: "v1.0", ETag: "a2jiodwjekjl3"
• 데이터가 변경되면 이 이름을 바꾸어서 변경함(Hash를 다시 생성)
  ex) ETag: "aaaaa" -> ETag: "bbbbb"
• 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 다운로드

📒 캐시와 조건부 요청 헤더

🖋️ 캐시 지시어(directives)

• Cache-Control: max-age
  캐시 유효 시간(초 단위)

🖋️ 검증 헤더와 조건부 요청 헤더

• 검증 헤더 (Validator)
  ex) ETag: "v1.0", ETag: "asid93jkrh2l"
  ex) Last-Modified: Thu, 04 Jun 2020 07:19:24 GMT

• 조건부 요청 헤더
  If-Match, If-None-Match: ETag 값 사용
  If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용

📒 프록시 캐시

🖋️ 캐시 지시어(directives) - 기타

• Cache-Control: public
  응답이 public 캐시에 저장되어도 됨

• Cache-Control: private
  응답이 해당 사용자만을 위한 것, private 캐시에 저장해야 함(기본값)

📒 캐시 무효화

🖋️ 캐시 지시어(directives) - 확실한 캐시 무효화

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

• Cache-Control: no-cache
  데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용

• Cache-Control: no-store
  데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제)

• Cache-Control: must-revalidate
  캐시 만료후 최초 조회시 원서버에 검증
  원서버 접근 실패시, 반드시 오류가 발생 - 504(Gateway Timeout)
  must-revalidate는 캐시 유효 시간이라면 캐시를 사용함

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

🖋️ no-cache vs must-revalidate

no-cache 기본 동작

no-cache일 경우, 만약 프록시 캐시 서버와 원서버 사이에 순간 네트워크가 단절되어 원서버에 접근 불가한 상황이 올 경우, 오류 보다는 오래된 데이터를 보여주게 된다.

반면 must-revalidate 일 경우에 원서버에 접근할 수 없으면 항상 오류를 발생(504 Gateway Timeout)시킨다.

---

지금까지 김영한 - 모든 개발자를 위한 HTTP 웹 기본 지식 (유료강의) 강의를 참고하여 HTTP 헤더 1 - 일반 헤더, HTTP 헤더 2 - 캐시와 조건부 요청 에 대해 공부하였다.