HTTP 웹 기본 지식

HTTP 프로토콜 등장 이전 IP 프로토콜

• 지정한 IP 주소에 데이터 전달
  • IP 주소가 담겨있는 IP 패킷에는 출발지 IP, 목적지 IP 등의 정보가 담겨있다
• 패킷을 통해 데이터 전달

한계

• 비연결성 : 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
• 비신뢰성 : 중간에 패킷이 사라지거나 패킷이 순서대로 안 와도 알 수 없음
• 프로그램 구분 : 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면 구분 불가

이런 문제를 해결하기 위한 새로운 프로토콜 등장

TCP/UDP

우선 인터넷 프로토콜 스택은 4계층으로 이루어짐

​

TCP(Transmission Control Protocol)

• TCP에 관한 데이터가 담겨있는 TCP 패킷에는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등의 데이터가 담겨있다.
• 특징
  • 연결 지향 - 3 way handshake
  • 데이터 전달 보증
  • 순서 보장
  • 신뢰할 수 있는 프로토콜

3 way handshake

• 데이터를 전송하기 전 connect, 연결 과정을 통해 클라이언트와 서버가 통신할 수 있는 상태인지 확인하는 것

  

순서 보장

UDP (User Datagram Protocol)

• 기능이 거의 없음
• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
• IP와 거의 같음 (PORT + 체크섬 정도만 추가)
• 애플리케이션에서 추가 작업 필요

DNS (Domain Name System)

• 데이터 전송 시 IP가 변경되거나 기억하기 어려움 등의 문제를 해결하기 위함

• 도메인 명을 IP 주소로 변환해주는 역할

  

URI (Uniform Resource Identifier)

• “URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다.”

• 즉, URI는 URL과 URN을 둘 다 포함하는 개념

Uniform Resource Identifier의 뜻

• Uniform : 리소스 식별하는 통일된 방식
• Resource : 자원, URI로 식별할 수 있는 모든 것
• Identifier : 다른 항목과 구분하는데 필요한 정보

URL (Uniform Resource Locator), URN (Uniform Resource Name)

• URL : Locator - 리소스가 있는 위치를 지정
• URN : Name - 리소스에 이름을 부여
• 위치는 변할 수 있지만, 이름은 변하지 않음
• URN으로 실제 리소스를 찾을 수 있는 방법이 보편화 X
• 보통 URI와 URL을 같은 의미로 이야기함

URL 문법

• ex) https://www.google.com/search?q=hello&hl=ko

• 프로토코 : https
• 호스트명 : www.google.com
• 포트 번호 : 443 (https port번호, 생략)
• 패스 : /search
• 쿼리 파라미터 : q=hello&hl=ko
  • key=value 형태
  • query parameter, query string 등으로 불림, 웹서버에 제공하는 파라미터

이런 URL을 통해 해당 도메인에 HTTP 요청 메시지를 보낸다.

요청 흐름

• HTTP 메시지는 TCP 패킷에 포함되어 전송된다.
• 해당 메시지를 서버에 보낸 후 서버는 그 메시지에 대한 결과를 HTTP 응답 메시지로 보낸다.
• 이런 과정을 통해 우리가 보는 웹 사이트 결과 화면이 나오는 것이다.

HTTP

• 모든 것은 HTTP

  • 거의 모든 형태의 데이터 전송 가능
  • 서버 간에 데이터를 주고 받을 때도 대부분 HTTP 사용
  • 웹은 모두 HTTP 프로토콜 위에서 만들어진다

• 클라이언트 - 서버 구조

• Stateful, Stateless

  • 거의 모든 것을 Stateless로 설계
  • 하지만 그럴 수 없는 경우 있음 ex) 로그인
  • 일반적으로 브라우즈 쿠키와 서버 세션 등을 사용해 Stateful 설계
  • Stateful은 최소한만 사용

• 비 연결성

  • HTTP는 기본이 연결을 유지하지 않음

  • 그 이유는 일반적으로 응답은 초 단위 이하의 빠른 속도로 처리 됨

  • 또한 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음

  • 서버 자원을 매우 효율적으로 사용 가능

  • 한계

    • 매번 요청마다 TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가

    • 요청 시 수 많은 자원이 함께 다운로드

    • 지금은 HTTP 지속 연결 (Persistent Connections)로 문제 해결

      

HTTP 메시지

HTTP 요청 메시지

• HTTP 메서드
• 요청 대상
• HTTP Version

HTTP 응답 메시지

• HTTP Version
• HTTP 상태코드
• 이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명 글

HTTP 헤더

• HTTP 전송에 필요한 모든 부가정보 ex) 메시지 바디의 내용, 크기, 압축 등등
• 표준 헤더가 굉장히 많다, 또 필요시 임의의 헤더 추가 가능

HTTP 바디

• 실제 전송할 데이터
• HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능

HTTP API

• 제일 중요한 것은 리소스 식별

  • 회원에 관한 URL을 설계할 때 회원이라는 개념 자체가 바로 리소스다.

  • 회원을 등록하고 수정하고 조회, 삭제하는 것은 모두 배제하고 설계해야한다.

  • 회원이라는 리소스만 식별해 -> 회원 리소스를 URL에 매핑

    

• 그 다음 필요한 것이 조회, 등록, 수정, 삭제를 구분하는 것
• URI는 리소스만 식별, 리소스와 해당 리소스를 대상으로 하는 행위를 분리
  • 리소스 : 회원
  • 행위 : 조회, 등록, 삭제, 변경
• 그렇기 위해 필요한 것이 HTTP 메서드

HTTP 메서드

• 메서드 종류
  • GET : 리소스 조회
  • POST : 요청 데이터 처리, 주로 등록에 사용
  • PUT : 리소스를 대체, 해당 리소스가 없으면 생성
  • PATCH : 리소스 부분 변경
  • DELETE : 리소스 삭제

GET

• 리로스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아 권장 X

POST

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
  • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
• 주요 사용처
  • 새 리소스 생성(등록) : 서버가 아직 식별하지 않은 새 리소스 생성
  • 요청 데이터 처리 : 프로세스를 처리해야 하는 경우, POST의 결과로 새로운 리소스가 생성되 지 않을 수도 있음
  • 다른 메서드로 처리하기 애매한 경우

PUT

• 리소스가 있으면 대체, 없으면 생성 (덮어쓰기)
• 클라이언트가 리소스를 식별 : 클라이언트가 리소스 위치를 알고 URI 지정
• 주의 : 리소르를 완전히 대체함. 부분 변경 X

PATCH

• 리소스 부분 변경

DELETE

• 리소스 제거

HTTP 메서드의 속성

• 안전 (Safe) : 호출해도 리소스를 변경 X
• 멱등 (Idempotent) : 한 번 호출하든 100번 호출하든 결과가 같음
  • POST : 두 번 호출하면 같은 결제가 중복해서 발생할 수 있어 멱등이 아님
  • 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려 X
• 캐시가능 (Cacheable) : 응답 결과 리소스를 캐시해서 사용해도 되는지
  • GET, HEAD 정도만 캐시로 사용
  • POST, PATCH는 분문 내용까지 캐시 키로 고려해야 하는데, 쉽지 않다

클라이언트에서 서버로 데이터 전송

• 정적 데이터 (이미지, 정적 텍스트 문서)

  • 조회는 GET 사용, 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능

• 동적 데이터 조회

  • 주로 검색, 게시판 목록에서 정렬 필터(검색어)
  • 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
  • 조회는 GET 사용, 쿼리 파라미터 사용해서 데이터를 전달

• HTML Form 데이터 전송

  • HTML Form submit시 POST 전송

  • Content-Type : application/x-www-form-urlencoded 사용

    • POST의 경우 form의 내용을 메시지 바디를 통해서 전송 (key=value, 쿼리 파라미터 형식)
    • 전송 데이터를 url encoding 처리 ex) abc김 -> abc%EA%B9%80
  • HTML Form은 GET 전송도 가능
  • Content-Type : multipart/form-data
    • 파일 업로드 같은 바이너리 데이터 전송시 사용
    • 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능

• HTTP API 데이터 전송

  • 서버 to 서버 : 백엔드 시스템 통신
  • 앱 클라이언트 : 아이폰, 안드로이드
  • 웹 클라이언트 : HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용(AJAX)
  • POST, PUT, PATCH : 메시지 바디를 통해 데이터 전송
  • GET : 조회, 쿼리 파라미터로 데이터 전달
  • Content-Type : application/json을 주로 사용 (사실상 표준)

API 설계 예시

• POST 기반 등록

  

  • 클라이언트는 등록될 리소스의 URI를 모른다

  • 서버가 새로 등록된 리소스 URL를 생성해준다.

    • HTTP/1.1 201 Created

      Location: /members/100

  • 컬렉션(Collection)

    • 서버가 관리하는 리소스 디렉토리
    • 서버가 리소스의 URI를 생성하고 관리
    • 여기서 컬렉션은 /members

• PUT 기반 등록

  

  • 클라이언트가 리소스 URI를 알고 있어야 함
  • 클라이언트가 직접 리소스의 URI를 지정한다
  • 스토어 (Store)
    • 클라이언트가 관리하는 리소스 저장소
    • 클라이언트가 리소스의 URI를 알고 관리
    • 여기서 스토어는 /files

• HTML FORM 사용

  • HTML FORM은 GET, POST만 지원

  • AJAX같은 기술을 사용해서 해결

  • GET, POST만 지원하므로 제약이 있음

    

  • 컨트롤 URL

    • GET, POST만 지원하므로 제약이 있음
    • 이런 제약을 해결하기 위해 동사로 된 리소스 경로 사용
    • POST의 /new, /edit, /delete가 컨트롤 URI
    • HTTP 메서드로 해결하기 애매한 경우 사용

정리

이렇게 리소스에 대한 식별을 URI를 통해서 하는 것이 REST API 설계의 주요 원칙 중 하나이다. 참고링크, REST 참고영상

HTTP 상태코드

• 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
• 1xx (Informational): 요청이 수신되어 처리중
• 2xx (Successful): 요청 정상 처리
• 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
• 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

1xx (Informational)

• 거의 사용 안 함

2xx (Successful)

• 200 OK : 요청 성공
• 201 Created : 요청 성공해서 새로운 리소스가 생성됨, 생성된 리소스는 응답의 Location 헤더 필드로 식별
• 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음
• 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음, 결과 내용이 없어도 204 메시지만으로도 성공을 인식 가능 ex) 웹 문서 편집기에서 save 버튼

3xx (Redirection)

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)

• 종류

  • 영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동, 거의 사용 X ex) /events -> /new-events

    • 원래의 URI를 사용 X, 검색 엔진 등에서도 변경 인지

    • 301 Moved Permanently : 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음 (MAY)

    • 308 Permanent Redirect : 301과 기능은 같음, 리다이렉트시 요청 메서드와 본문 유지

    • ex) 301의 경우 /events에 POST로 요청을 보낼 때 리다이렉션이 일어나면 /new-events에서 다시 데이터를 입력해야함 (본문 제거)

      308은 데이터 다시 입력 X (본문 유지)

  • 일시 리다이렉션 : 일시적인 변경, 주문 완료 후 주문 내역 화면으로 이동, PRG

    • 302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 (MAY)
    • 307 Temporary Redirect : 302와 기능은 같음, 리다이렉트시 요청 메서드와 본문 유지 (요청 메서드를 변경하면 안된다. MUST NOT)
    • 303 See Other : 302와 기능은 같음, 리다이렉트시 요청 메서드가 GET으로 변경
    • 예시) POST로 주문 후에 웹 브라우저를 새로고침하면 다시 요청이 들어가 중복 주문이 될 수 있음 -> PRG 사용
    • PRG (Post/Redirect/Get) : POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트 -> 새로고침으로 인한 중복 주문 방지
    • 거의 대부분 302를 디폴트로 사용

  • 특수 리다이렉션 : 결과 대신 캐시를 사용

    • 304 Not Modified : 캐시를 목적으로 사용. 클라이언트에게 리소스가 수정되지 않았음을 알려줌 따라서 저장된 캐시를 재사용. 응답에 메시지 바디 포함 X. GET, HEAD 요청시 사용할 수 있

4xx (Client Error)

• 클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패
• 400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
• 401 Unauthorized : 인증(Authentication) 되지 않음, 401 오류 발생시 WWW-Authenticate 헤더와 함께 인증 방법을 설명
  • 인증(Authentication) : 본인이 누구인지 확인 (로그인)
  • 인가(Authorization) : 권한부여 (특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음
• 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함
  • 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
• 404 Not Found : 서버가 요청을 이해했지만 승인을 거부함
  • 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경

5xx (Server Error)

• 서버 문제로 오류 발생
• 서버 문제이므로 재시도 하면 성공 가능성 있음
• 500 Internal Server Error : 서버 문제로 오류 발생, 애매하면 500 오류
• 503 Service Unavailable : 서비스 이용 불가, 서버가 일시적인 과부화 또는 예정된 작업으로 잠시 요청을 처리할 수 없음

HTTP 헤더와 바디

• 헤더 분류
  • General 헤더: 메시지 전체에 적용되는 정보, 예) Connection: close
  • Request 헤더: 요청 정보, 예) User-Agent: Mozilla/5.0 (Macintosh; ..)
  • Response 헤더: 응답 정보, 예) Server: Apache
  • Entity 헤더: 엔티티 바디 정보, 예) Content-Type: text/html, Content-Length: 3423
• HTTP BODY (RFC2616 (과거))
  • message body은 entity body을 전달하는데 사용
  • 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터
  • 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보 제공
    • 데이터 유형, 데이터 길이, 압축 정보 등등
• 현재 (RFC7230~7235)
  • 엔티티(Entity) -> 표현(Representation)
  • Representation = representation Metadata + Representation Data
  • 표현 = 표현 메타데이터 + 표현 데이터

  • 메시지 본문(message body)을 통해 표현 데이터 전달

  • 메시지 본문 = 페이로드(payload)

  • 표현은 요청이나 응답에서 전달할 실제 데이터

  • 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공

  • 데이터 유형(html, json), 데이터 길이, 압축 정보 등등

  • 참고: 표현 헤더는 표현 메타데이터와, 페이로드 메시지를 구분해야 하지만, 여기서는 생략

표현 (Representation)

• Content-Type : 표현 데이터의 형식
  • 미디어 타입, 문자 인코딩
  • ex) application/json
• Content-Encoding : 표현 데이터의 압축 방식
  • 표현 데이터를 압축하기 위해 사용
  • 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
  • 읽는 쪽에서는 인코딩 헤더의 정보로 압축 해제
  • ex) gzip
• Content-Language : 표현 데이터의 자연 언어
  • 표현 데이터의 자연 언어를 표현
  • ex) ko, en
• Content-Length : 표현 데이터의 길이
  • 바이트 단위
  • Transfer-Encoding(전송 코딩)을 사용하면 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
  • 구체적인 것이 우선한다

HTTP 전송 방식

• 단순 전송 (Content-Length) : message body 길이
• 압축 전송 (Content-Encoding) : gzip 등 압축 전송
• 분할 전송 (Transfer-Encoding) : chunked, 5 Hello 5 World 0 \r\n 와 같이 길이와 내용을 응답
• 범위 전송 (Range, Content-Range) : 범위를 지정해서 요청 가능

헤더의 일반 정보

• From: 유저 에이전트의 이메일 정보
  • 일반적으로 잘 사용되지 않음
  • 검색 엔진 같은 곳의 요청에서 사용
• Referer: 이전 웹 페이지 주소 (Referrer의 오타)
  • 현재 요청된 페이지의 이전 웹 페이지 주소
  • 유입 경로 분석 가능
  • 요청에서 사용
• User-Agent: 유저 에이전트 애플리케이션 정보
  • 클라이언트의 애플리케이션 정보 (웹 브라우저 정보 등)
  • 통계 정보, 요청에서 사용
• Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
  • Server: Apache/2.2.22 (Debian)
  • 응답에서 사용
• Date: 메시지가 생성된 날짜
  • 응답에서 사용

헤더의 특별한 정보

• Host: 요청한 호스트 정보(도메인)

  • 요청에서 사용

  • 필수

  • 하나의 서버가 여러 도메인을 처리해야 할 때

    

• Location: 페이지 리다이렉션

  • 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)

• Allow: 허용 가능한 HTTP 메서드

  • 405 (Method Not Allowed) 에서 응답에 포함해야함

• Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

인증

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

쿠키

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

HTTP 무상태 프로토콜로 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어짐 -> 연결할 때마다 사용자 정보를 요청 정보에 매번 포함시켜야 함

이런 문제를 쿠키를 통해 해결

쿠키란

• 사용처 : 사용자 로그인 세션 관리 등
• 쿠기 정보는 항상 서버에 전송됨
  • 네트워크 트래픽 추가 유발
  • 최소한의 정보만 사용(세션 id, 인증 토큰)
  • 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지를 사용
  • 보안에 민감한 데이터는 저장하면 안됨

쿠키의 생명주기

• Set-Cookie : expires=Sat, 26-Dec-2020 04:39:21 GMT
  • 만료일이 되면 쿠키 삭제
• Set-Cookie: max-age=3600 (3600초)
  • 0이나 음수를 지정하면 쿠키 삭제
• 세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
• 영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지

쿠키의 도메인

• 명시 : 명시한 문서 기준 도메인 + 서브 도메인 포함
  • domain=example.org를 지정해서 쿠키 생성 시 example.org는 물론이고 dev.example.org도 쿠키 접근
• 생략 : 현재 문서 기준 도메인만 적용
  • domain=example.org를 지정해서 쿠키 생성 시 example.org는 접근 가능이고 dev.example.org은 쿠키 미접근

쿠키의 경로

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

쿠키의 보안

• Secure
  • 쿠키는 http, https를 구분하지 않고 전송
  • Secure를 적용하면 https인 경우에만 전송
• HttpOnly, SameSite 등이 있음

캐시

• 캐시가 없다면 데이터가 변경되지 않은 데이터임에도 계속 다운
• 인터넷 네트워크는 매우 느리고 비싸고 브라우저 로딩 속도가 느려진다.
• 브라우저 캐시를 이용해 처음 다운 받은 데이터를 저장시켜놓고 캐시 유효시간 동안 같은 데이터를 요청하면 브라우저 캐시에서 조회해 사용한다.
• 캐시를 적용하면 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨
• 비싼 네트워크 사용량을 줄이고 로딩 속도가 빨라짐

캐시 시간

• cache-control: max-age=60 와 같이 설정
• 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신
• 이때 다시 네트워크 다운로드 발생

캐시 유효 시간이 초과해서 서버에 다시 요청하면 두 가지 상황이 나타남

1. 서버에서 기존 데이터를 변경함
2. 서버에서 기존 데이터를 변경하지 않음

2번의 경우 데이터를 서버에서 다시 받아오는 대신 캐시에 저장해 두었던 데이털르 재사용 하면 된다.

단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요하다. 그것이 검증 헤더

검증 헤더

• 응답 검증 헤더 : Last-Modified: 2024년 04월 21일 10:00:00
  • 데이터가 마지막에 수정된 시간
• 요청 검증 헤더 : if-modified-since: 2024년 04월 21일 10:00:00
  • 캐시가 가지고 있는 데이터 최종 수정일
• 응답 시 수정 날짜를 포함해 응답 데이터를 보냄 -> 데이터를 캐시에 저장 -> 다시 요청 시 -> 캐시가 가지고 있는 데이터 최종 수정일을 요청의 if-modified-since에 넣어서 보냄 -> 서버의 데이터 최종 수정일과 같다면 304 Not Modified를 응답 (HTTP Body가 없음) -> 응답 결과를 재사용, 헤더 데이터 갱신

정리

검증 헤더와 조건부 요청

• 검증 헤더

  • 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
  • Last-Modified, ETag가 있음

• 조건부 요청 헤더

  • 검증 헤더로 조건에 따른 분기

  • if-Modified-Since : Last-Modified 사용

  • if-None-Match : ETag 사용

  • 조건이 만족하면 200 OK

  • 조건이 만족하지 않으면 304 Not Modified

  • ex) 데이터 미변경 시 : 304 Not Modified, 헤더 데이터만 전송

    ​ 데이터 변경 시 : 200 OK, 모든 데이터 전송

  • Last-Modified, if-Modified-Since 단점

    • 1초 미만 단위로 캐시 조정이 불가능

    • 날씨 기반의 로직 사용

    • 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우

    • 서버에서 별도의 캐시 로직을 관리하고 싶은 경우

      ex) 주석을 변경하는 등 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

  • ETag, if-None-Match

    • ETag(Entity Tag)

    • 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠

      ex) ETag: “v1.0”, ETag: “a2jiodwjekjl3”

    • 데이터가 변경되면 이 이름을 바꾸어서 변경함 (Hash로 생성)

      ex) ETag: “aaaaa” -> ETag: “bbbbb”

  • ETag, If-None-Match 정리

    • ETag만 서버에 보내서 같으면 유지, 다르면 다시 받음

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

    • 클라이언트는 단순히 이 값을 서버에 확인하는데만 씀

    • 캐시 제어 헤더

  • Cache-Control : 캐시 제어

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

  • Pragma : 캐시 제어 (하위 호환)

    • HTTP 1.0 하위 호환

  • Expries : 캐시 유효 기간 (하위 호환)

    • 캐시 만료일을 정확한 날짜로 지정
    • 지금은 더 유연한 Cache-Control: max-age 권장

프록시 캐시

• 원 서버에 직접 접근할 시 만약 미국에 있는 원 서버를 한국에서 접근할 경우 너무 오래걸림 -> 프록시 캐시 도입

• 프록시 캐시 : 한국 어딘가에 프록시 캐시 서버를 만들어둠

  

Cache-Control

• 캐시 지시어 (directives)

• Cache-Control: public

  응답이 public 캐시에 저장되어도 됨

• Cache-Control: private

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

• Cache-Control: s-maxage

  프록시 캐시에만 적용되는 max-age

• Age: 60 (HTTP 헤더)

  오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초

캐시 무효화

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

no-cache VS must-revalidate

• no-cache

  

• must-revalidate