우리가 사용하는 인터넷 프로토콜, 즉 IP 기반의 네트워크는 미 국박성에서 1969년 진행했던 아르파넷(ARPANET) 프로젝트에서 시작되었다. 이 프로젝트는 당시 냉전시대에서 핵저냊ㅇ을 대비하기 위한 통신망 구축을 위해 추진되었다. 이때 기존에 사용되었던 회선교환 방식이 아닌 패킷교환 방식으로 네트ㅡ워크를 구축하게 되는데 이를 토대로 현재의 인터넷 통신 방식의 기반이 세워졌다.

회선 교환 방식

패킷교환 방식은 기존에 전화에서 사용했던 회선교환 방식의 단점을 보완한 방식이다. 그럼 회선교환 방식은 어떻게 연결했을까?

회선교환 방식은 발신자와 수신자 사이에 데이터를 전송할 전용선을 미리 할당하고 둘을 연결한다.(우리가 전화하는 방식) 그래서 내가 연결하고 싶은 상대가 다른 상대와 연결중이라면, 상대방은 이미 다른 상대와의 전용선과 연결되어 있기 때문에 그 연결이 끊어지고 나서야 상대와 연결할 수 있다. 또한 특정 회선이 끊어지는 경우에는 처음부터 다시 연결을 성립해야한다.

패킷교환 방식

아르파넷 프로젝트에서는 이 문제를 해결하기 우하여 패킷교환 방식의 네트워크를 고안했다.

패킷교환 방식은 패킷이라는 단위로 데이터를 잘게 나누어 전송하는 방식이다. 그래서 각 패킷에는 출발지와 목적지 정보가 있고 이에 따라 패킷이 목적지를 향해 가장 효율적인 방식으로 이동할 수 있다. 이를 이용하면 특정 회선이 전용선으로 할당되지 않기 때문에 빠르고 효율적으로 데이터를 전송할 수 있다.

그래서 인터넷 프로토콜, 줄여서 IP는 출발지와 목적지의 정보를IP주소라는 특정한 숫자값으로 표기하고 패킷 단위로 데이터를 전송하게 되었다.

IP와 IP Packet

복잡한 인터넷 망 속 수많은 노드들을 지나 클라이언트와 서버가 통신하게 되는 규칙은 IP(인터넷 프로토콜)주소를 컴퓨터에 부여하여 통신하는 것이다. IP는 지정한 IP주소(IP Address)에 패킷(Packet)이라는 통신 단위로 데이터 전달을 한다.

IP 패킷에서 패킷은 pack과 bucket이 합쳐진 단어로 소포로 비유할 수 있다. IP 패킷은 이를 데이터 통신에 적용한 것이다. IP 패킷은 우체국 송장처럼 전송 데이터를 무사히 전송하기 위해 출발지 IP, 목적지 IP와 같은 정보가 포함되어 있다.

패킷 단위로 전송을 하면 노드들은 목적지 IP에 도달하기 위해 서로 데이터를 전달한다.
이를 통해 복잡한 인터넷 망 사이에서도 정확한 목적지로 패킷을 전송할 수 있다.

서버에서 무사히 데이터를 전송받는다면 서버도 이에 대한 응답을 돌려줘야 한다.
서버 역시 IP 패킷을 이용해 클라이언트에 응답을 전달한다.

IP프로토콜의 한계

• 비연결성 : 만약 패킷을 받을 대상이 없거나 서비스 불능 상태여도 클라이언트는 서버의 상태를 파악할 방법이 없기 때문에 패킷을 그대로 전송하게 된다.

  • 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송

• 비신뢰성 : 중간에 있는 서버가 데이터를 전달하던 중 장애가 생겨 패킷이 중간에 소실되더라도 클라이언트는 이를 파악할 방법이 없다. 또한 전달 데이터의 용량이 클 경우 이를 패킷 단위로 나눠 데이터를 전달하게 되는데, 이때 패킷들은 중간에 서로 다른 노드를 통해 전달될 수 있다. 이렇게 되면 클라이언트가 의도하지 않은 순서로 서버에 패킷이 도착할 수 있다.

  • 중간에 패킷이 사라질 수 있음
  • 패킷의 순서를 보장할 수 없음

TCP vs UDP

아래와 같은 네트워크 계층 구조를 통해 IP 프로토콜의 한계를 보완할 수 있다.

OSI 7 계층과 TCP/IP 4 계층

네트워크 프로토콜 계층은 다음과 같이 OSI 7계층과 TCP/IP 4 계층으로 나눌 수 있다.
IP 프로토콜보다 더 높은 계층에 TCP 프로토콜이 존재하기 때문에 앞서 다룬 IP 프로토콜의 한계를 보완할 수 있다. * TCP/IP 4 계층은 OSI 7 계층보다 먼저 개발되었으며 TCP/IP 프로토콜의 계층은 OSI 모델의 계층과 정확하게 일치하지는 않는다. 실제 네트워크 표준은 업계표준을 따르는 TCP/IP 4 계층에 가깝다.

위 이미지는 채팅 프로그램에서 메시지를 보낼 때 발생하는 일이다.

먼저 HTTP 메시지가 생성되념 Socket을 통해 전달된다. 프로그램이 네트워크에서 데이터를 송수신할 수 있도록, "네트워크 환경에 연결할 수 있게 만들어진 연결부"가 바로 네트워크 소켓(Socket)이다. 그리고 IP패킷을 생성하기 전 TCP 세그먼트를 생성한다.

TCP/IP 패킷 : TCP 세그먼트에는 IP 패킷의 출발지 IP와 목적지 IP 정보를 보완할 수 있는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등을 포함한다.

TCP(Transmission Control Protocol) 특징

• 연결 지향 : TCP 3 way handshake(가상 연결)
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 프로토콜

TCP 3 way handshake

TCP는 장치들 사이에 논리적인 접속을 성립하기 위하여 3 way handshake를 사용하는 연결지향형 프로토콜이다.

연결 방식은 다음과 같다.

• 먼저 클라이언트는 서버에 접속을 요청하는 SYN 패킷을 보낸다.
• 서버는 SYN요청을 받고 클라이언트에게 요청을 수락한다는 ACK 와 SYN이 설정된 패킷을 발송하고 클라이언트가 다시 ACK으로 응답하기를 기다린다.
• 클라이언트가 서버에게 ACK을 보내면 이 이후로는 연결이 성립되며 데이터를 전송할 수 있다.

만약 서버가 꺼져있다면 클라이언트가 SYN을 보내고 서버에서 응답이 없기 때문에 데이터를 보내지 않는다.
현재에는 최적화가 이루어져 3번 ACK를 보낼 때 데이터를 함께 보내기도 한다.

• SYN은 Synchronize, ACK는 Acknowledgment의 약자

OSI 7 계층 모델

해당 계층 모델은 ISO(International Organization for Standardization)라고 하는 국제표준화기구에서 1984년에 제정한 표준 규격이다. 왜 네트워크에 대한 표준 규격을 정해야만 했을까?

지금은 상상하기 어렵지만 같은 회사에서 만든 컴퓨터끼리만 통신이 가능했던 시절이 있었다. 따라서 다른 회사의 시스템이라도 네트워크 유형에 관계없이 상호 통신이 가능한 규약, 즉 프로토콜(Protocol)이 필요했다. 그래서 ISO에서는 제조사에 상관없이 공통으로 사용할 수 있는 네트워크 표준 규격을 정의했다.

OSI 7계층 모델은 네트워크를 이루고 있는 구성요소들을 7단계로 나누고, 각 계층의 표준을 정하였다. OSI 7계층 모델의 목적은 표준화를 통하여 포트, 프로토콜의 호환 문제를 해결하고, 네트워크 시스템에서 일어나는 일을 해당 계층 모델을 이용해 쉽게 설명할 수 있다. 또한 네트워크 관리자가 문제가 발생 했을 때 이것이 물리적인 문제인지, 응용 프로그램과 관련이 있는지 등 원인이 어디에 있는지 범위를 좁혀 문제를 쉽게 파악할 수 있다. 즉 사이트에 접속되지 않는다고 해서 무작정 컴퓨터를 껐다 키는 일을 피할 수 있다.

각 계층은 다음과 같이 구분된다..

• 1계층 - 물리 계층: OSI 모델의 맨 밑에 있는 계층으로서, 시스템 간의 물리적인 연결과 전기 신호를 변환 및 제어하는 계층이다. 주로 물리적 연결과 관련된 정보를 정의한다. 주로 전기 신호를 전달하는데 초점을 두고, 들어온 전기 신호를 그대로 잘 전달하는 것이 목적이다.

  • e.g. 디지털 또는 아날로그로 신호 변경

• 2계층 - 데이터링크 계층: 네트워크 기기 간의 데이터 전송 및 물리주소(e.g. MAC 주소)를 결정하는 계층이다. 물리 계층에서 들어온 전기 신호를 모아 알아 볼 수 있는 데이터 형태로 처리한다. 이 계층에서는 주소 정보를 정의하고 출발지와 도착지 주소를 확인한 후, 데이터 처리를 수행한다.

  • e.g. 브리지 및 스위치, MAC 주소

• 3계층 - 네트워크 계층: OSI 7 계층에서 가장 복잡한 계층 중 하나로서 실제 네트워크 간에 데이터 라우팅을 담당한다. 이때 라우팅이란 어떤 네트워크 안에서 통신 데이터를 짜여진 알고리즘에 의해 최대한 빠르게 보낼 최적의 경로를 선택하는 과정을 라우팅이라고 한다.

  • e.g. IP 패킷 전송

• 4계층 - 전송 계층: 컴퓨터간 신뢰성 있는 데이터를 서로 주고받을 수 있도록 하는 서비스를 제공하는 계층이다. 하위 계층에서 신호와 데이터를 올바른 위치로 보내고 신호를 만드는데 집중했다면, 전송 계층에서는 해당 데이터들이 실제로 정상적으로 보내지는지 확인하는 역할을 한다. 네트워크 계층에서 사용되는 패킷은 유실되거나 순서가 바뀌는 경우가 있는 데, 이를 바로 잡아주는 역할도 담당한다.

  • e.g. TCP/UDP 연결

• 5계층 - 세션 계층: 세션 연결의 설정과 해제, 세션 메시지 전송 등의 기능을 수행하는 계층이다. 즉, 컴퓨터간의 통신 방식에 대해 결정하는 계층이라고 할 수 있다. 쉽게 말해, 양 끝 단의 프로세스가 연결을 성립하도록 도와주고, 작업을 마친 후에는 연결을 끊는 역할을 한다.

• 6계층 - 표현 계층: 응용 계층으로 전달하거나 전달받는 데이터를 인코딩 또는 디코딩하는 계층이다. 일종의 번역기 같은 역할을 수행하는 계층이라고 볼 수 있다.

  • e.g. 문자 코드, 압축, 암호화 등의 데이터 변환

• 7계층 - 응용 계층: 최종적으로 사용자와의 인터페이스를 제공하는 계층으로 사용자가 실행하는 응용 프로그램(e.g. Google Chrome)들이 해당 계층에 속한다.

  • e.g. 이메일 및 파일 전송, 웹 사이트 조회

데이터 캡슐화

OSI 7계층 모델은 송신 측의 7계층과 수신 측의 7계층을 통해 데이터를 주고 받는다. 각 계층은 독립적이므로 데이터가 전달되는 동안에 다른 계층의 영향을 받지 않는다.

데이터를 전송하는 쪽은 데이터를 보내기 위해서 상위 계층에서 하위 계층으로 데이터를 전달한다. 이때 데이터를 상대방에게 보낼 때 각 계층에서 필요한 정보를 데이터에 추가하는데 이 정보를 헤더(데이터링크 계층에서는 트레일러)라고 한다. 그리고 이렇게 헤더를 붙여나가는 것을 캡슐화라고 한다.

마지막 물리 계층에 도달하며 송신 측의 데이터링크 계층에서 만들어진 데이터가 전기 신호로 변환되어 수신 측에 전송된다.

데이터를 받는 쪽은 하위 계층에서 상위 계층으로 각 계층을 통해 전달된 데이터를 받게된다. 이때 상위 계층으로 데이터를 전달하며 각 계층에서 헤더(데이터링크 계층에서는 트레일러)를 제거해 나가는 것을 역캡슐화라고 한다. 역캡슐화를 거쳐 마지막 응용 계층에 도달하면 드디어 전달하고자 했던 원본 데이터만 남게 된다.

TCP/IP 4 계층 모델

TCP/IP 4계층 모델은 OSI 모델을 기반으로 실무적으로 이용할 수 있도록 현실에 맞춰 단순화된 모델이다. 쉽게 말해 OSI 7계층 이론을 실제 사용하는, 즉 실용성에 기반을 둔 현대의 인터넷 표준이 TCP/IP 4계층이라고 할 수 있다.

• 4계층: 어플리케이션 계층: OSI 계층의 세션 계층, 표현 계층, 응용 계층에 해당하며 TCP/UDP 기반의 응용 프로그램을 구현할 때 사용한다.

  • e.g. FTP, HTTP, SSH

• 3계층: 전송 계층: OSI 계층의 전송 계층에 해당하며 통신 노드간의 연결을 제어하고, 신뢰성 있는 데이터 전송을 담당한다.

  • e.g. TCP/UDP

• 2계층: 인터넷 계층: OSI 계층의 네트워크 계층에 해당하며 통신 노드 간의 IP 패킷을 전송하는 기능 및 라우팅을 담당한다.

  • e.g. IP, ARP, RARP

• 1계층: 네트워크 인터페이스 계층: OSI 계층의 물리 계층과 데이터 링크 계층에 해당하며 물리적인 주소로 MAC을 사용한다.

  • e.g. LAN, 패킷망 등에 사용됨

응용 계층

응용 계층은 네트워크 모델의 최상위 계층으로 최종적으로 사용자와의 인터페이스를 제공하는 계층이다. 쉽게 말해 사용자가 웹 서핑을 할 때에는 웹 브라우저를 사용하고 메일을 주고 받을 때는 Outlook과 같은 메일 프로그램을 사용하는 것을 예시로 들 수 있다. 이렇게 응용 계층은 이메일, 파일 전송, 웹 사이트 조회 등 어플리케이션에 대한 서비스를 사용자에게 제공하는 계층이다.

이때 어플리케이션은 서비스를 요청하는 측(사용자 측)에서 사용하는 어플리케이션과 서비스를 제공하는 측의 어플리케이션으로 분류된다. 일반적으로 서비스를 요청하는 측을 클라이언트, 서비스를 제공하는 측을 서버라고 한다. 웹 브라우저(e.g. Google Chrome)나 메일 프로그램(e.g. Outlook)은 사용자 측에서 사용하는 어플리케이션이니 클라이언트에 속하는 반면, 서비스를 제공하는 측인 서버에는 웹 서버 프로그램과 메일 서버 프로그램 등이 있다. 클라이언트와 서버 모두 응용 계층에서 동작합니다.

HTTP

HTTP 특징

• 클라이언트 서버 구조

• 무상태 프로토콜(Stateless) : 서버가 클라이언트의 상태를 보존하지 않음

  • 장점 : 서버 확장성이 높음(스케일 아웃)
  • 단점 : 클라이언트가 추가 데이터 전송
    • 로그인이 필요 없는 단순한 서비스 소개 화면 같은 경우엔 무상태로 설계할 수 있지만 로그인이 필요한 서비스라면 유저의 상태를 유지해야 되기 때문에 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지한다.

• 비연결성(Connectionless)

  • TCP/IP의 경우 기본적으로 연결을 유지한다.

  • HTTP는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는다.

  • 이를 통해 최소한의 자원으로 서버 유지를 가능하게 한다.

  • 비연결성의 한계

    • TCP/IP 연결을 새로 맺어야 한다. - 3 way handshake 시간 추가
    • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, CSS, 추가 이미지 등 수 많은 자원이 함께 다운로드
    • 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
    • HTTP/2, HTTP/3에서 더 많은 최적화

• HTTP 메세지

• 단순함, 확장 가능

HTTP Headers의 종류와 특징

요청(Request)에서 사용되는 헤더

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

• 일반적으로 잘 사용하지 않음
• 검색 엔진에서 주로 사용
• 요청에서 사용

Referer : 이전 웹 페이지 주소

• 현재 요청된 페이지의 이전 웹 페이지 주소
• A → B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청
• Referer를 사용하면 유입경로 수집 가능
• 요청에서 사용
• referer는 단어 referrer의 오탈자이지만 스펙으로 굳어짐

User-Agent : 유저 에이전트 애플리케이션 정보

• 클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
• 통계 정보
• 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
• 요청에서 사용
• e.g.
  • 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

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

• 요청에서 사용
• 필수 헤더
• 하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용
• 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용

Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄

• 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다.
• 응답 헤더의 Access-Control-Allow-Origin와 관련

Authorization: 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더

• “토큰의 종류(e.g. Basic) + 실제 토큰 문자”를 전송
  • e.g.
    Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

응답(Response)에서 사용되는 헤더

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

• 응답에서 사용
• e.g.
  • Server: Apache/2.2.22 (Debian)
  • Server: nginx

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

• 응답에서 사용
• e.g.
  • Date: Tue, 15 Nov 1994 08:12:31 GMT

Location: 페이지 리디렉션

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 리다이렉트(자동 이동)
• 201(Created): Location 값은 요청에 의해 생성된 리소스 URI
• 3xx(Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴

Allow: 허용 가능한 HTTP 메서드

• 405(Method Not Allowed)에서 응답에 포함
• e.g.
  • Allow: GET, HEAD, PUT

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

• 503(Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
• e.g.
  • Retry-After: Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기)
  • Retry-After: 120(초 단위 표기)

콘텐츠 협상 (Content negotiation) 헤더

• Accept : 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
• Accept-Language : 클라이언트가 선호하는 자연 언어

• 협상 헤더는 요청시에만 사용

만일 클라이언트가 한국어를 선호해서 Accept-Language에 한국어를 요청했지만 서버는 한국어를 지원하지 않으며 기본 언어는 독일어로 설정되어 있을 때, 독일어는 너무 어렵기 때문에 영어로라도 응답받길 원하면 어떻게 하면 될까?

이와 같은 문제를 해결하기 위해 협상 헤더에서는 원하는 콘텐츠에 대한 우선순위를 지정할 수 있다.
1부터 0까지 우선순위를 부여하면 이를 토대로 서버는 응답을 지원한다.

이를 이용해 서버에 우선순위 요청을 하게 되면

1순위인 한국어를 서버에서는 지원하지 않지만 2순위인 영어를 지원하기에 서버에서는 우선순위에 있는 영어를 독일어 보다 클라이언트가 선호하기에 영어로 응답을 주게 된다.

Web Cache

클라이언트가 어떤 이미지 파일인 test.jpg에 대한 요청을 보내고 서버가 해당 이미지에 대한 응답을 줄 때, HTTP 헤더가 0.1M, 바디가 1.0M 총 1.1M로 가정하면 추후에 같은 이미지를 다시 요청하더라도 첫 번째 처럼 똑같이 1.1M의 응답을 보낸다. 이 경우 test.jpg 데이터가 변경되지 않아도 계속 데이터를 새로 다운받아야 한다. 이런 문제를 해결하기 위한 것이 web cache다.

cache가 없을 경우 요청하는 데이터의 용량이 클 수록 비용이 커지고 브라우저의 로딩 속도가 느려진다.

캐시 적용하기

캐시는 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다.

캐시는 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다.

캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있다.

이렇게 되면 응답을 받았을 때 브라우저 캐시에 해당 응답 결과를 저장하며 이는 60초간 유효하다.

캐시가 존재하고, 아직 60초가 지나지 않아 유요한 캐시라면 해당 캐시에서 데이터를 가져온다.

캐시 시간이 초과한 경우 다시 서버에 요청을 하고 60초간 유효한 logo.jpg이미지를 응답받는다. 이 때 다시 네트워크 다운로드가 발생하게 된다.

응답 결과를 브라우저가 렌더링 하면 브라우저 캐시는 기존 캐시를 지우고 새 캐시로 데이터를 업데이트한다.
이 과정에서 캐시 유효 시간이 다시 초기화된다.

캐시 검증 헤더와 조건부 요청

만약 캐시 유효시간이 지났지만 변경이 없기 때문에 해당 데이터를 써도 되는 상황이라면 이를 검증하고 사용하는 방법은 없을까?

Last-Modified와 If-Modified-Since

검증 헤더 Last Modified를 이용해 캐시의 수정 시간을 알 수 있다.
Last Modified는 뎅터가 마지막으로 수정된 시간 정보를 헤더에 포함한다.
이로 인해 응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장된다.

서버의 해당 자료의 최종 수정일과 비교해서 데이터가 수정이 안되었을 경우 응답 메시지에 이를 담아서 알려준다.
이 때, HTTP Body는 응답 데이터에 없으며 상태 코드는 304 Not Modified로 변경된 것이 없다는 뜻이다.
그래서 전송 데이터에 바디가 빠졌기 때문에 헤더만 포함된 0.1M만 전송된다.

Last-Modified와 If-Modified-Since 정리

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면?
  • 304 Not Modified + 헤더 메타데이터만 응답 (바디X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타데이터를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 매우 실용적인 해결책

Last-Modified와 If-Modified-Since 단점

• 1초 미만 단위로 캐시 조정이 불가능
• 날짜 기반의 로직 사용
• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
  • e.g. 스페이스나 주석 처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

ETag와 If-None-Match

서버에서 헤더에 ETag를 작성해 응답한다. 클라이언트의 캐시에서 해당 ETag 값을 저장한다.

만약 캐시 시간이 초과돼서 다시 요청을 해야 하는 경우라면 이 때 ETag 값을 검증하는 If-None-Match를 요청 헤더에 작성하여 보낸다.

서버에서 데이터가 변경되지 않았을 경우 ETag는 동일하기에 그래서 If-None-Match는 거짓이 된다.
이 경우 서버에서는 304 Not Modified를 응답하며 이 때 역시 HTTP Body는 없다.
브라우저 캐시에서는 응답 결과를 재사용하고 헤더 데이터를 갱신한다.

ETag와 If-None-Match 정리

• 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받는 방식
• 캐시 제어 로직을 서버에서 완전히 관리
• 클라이언트는 단순히 이 값을 서버에 제공 (클라이언트는 캐시 메커니즘을 모름)

e.g
1. 서버는 베타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지
2. 애플리케이션 배포 주기에 맞추어 ETag갱신

캐시 지시어(directives)

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

Expires

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

• Expires : Mon, 01 Jan 1990 00:00:00 GMT

• 캐시 만료일을 정확한 날짜로 지정

• HTTP 1.0부터 사용

• 지금은 더 유연한 Cache-Control: max-age권장

• Cache-Control: max-age와 함께 사용하면 Expires는 무시됨

검증 헤더와 조건부 요청 헤더 정리

• 검증 헤더 (Validator)
  • ETag: "v1.0", ETac: "845eed07c5887"
  • Last-Modified: Wed, 26 Dec 2020 12:01:29 GMT
• 조건부 요청 헤더
  • if-Match, if-None-Match: ETag 값 사용
  • if-Modified-Since, If-Unmodified-Since: Last-Modified값 사용

프록시 캐시

한국에 있는 클라이언트에서 특정 데이터가 필요한 상황인데 해당 데이터의 원 서버가 미국에 있다고 가정해 보자.
한국에서 미국까지 직접 접근하여 이미지를 가져오는데 0.5초가량 걸린다고 하면 한국에 있는 클라이언트는 모두 0.5초가량을 기다려야 해당 이미지를 받을 수 있다.
앞서 언급한 예시는 매우 긍정적인 상황이고, 실제로는 더 많은 시간이 걸릴 수 있다.
하지만 우리는 유튜브와 같은 해외 사이트에서 위와 같은 불편한 없이 빠르게 영상을 시청할 수 있다.
어떻게 이와 같은 일이 가능할까?

이는 클라이언트와 원 서버 사이에 위치한 프록시 캐시 서버를 도입했기 때문이다.
한국에 프록시 캐시서버를 두고 한국의 클라이언트는 프록시 캐시서버를 통해 자료를 가져오도록 해보자.
여러 사람이 찾은 자료일수록 이미 캐시에 등록되어 있기에 빠른 속도로 자료를 가져올 수 있다.
이는 같은 국내에 있기에 원서버에 접근하는 것보다 훨씬 빠른 속도에 자료를 가져올 수 있기 때문이다.
이때 클라이언트에서 사용하고 저장하는 캐시를 private 캐시라 하며 프록시 캐시 서버의 캐시를 public 캐시라 한다.

프록시 캐시와 관련된 헤더

캐시 지시어(directives) - 기타

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

캐시 무효화

클라이언트가 캐시를 적용하지 않아도 임의로 브라우저가 캐시를 적용하는 경우, 특정 페이지에서 캐시가 되면 안 되는 정보(e.g. 통장 잔고)가 있다면 어떻게 이를 무효화할 수 있을까?

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

캐시 무효화를 확실하게 해야하는 경우 Pragma와 같은 하위 호환까지 포함하여 아래와 같이 적용해야 한다.

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

no-cache와 must-revalidate 모두 원 서버에 검증해야 하지만 그에 대한 응답에 대해 다른 점이 있다.
캐시 서버 요청을 하면 프록시 캐시 서버에 도착하면 no-cache인 경우 원 서버에 요청을 하게 된다.
그리고 원 서버에서 검증 후 304 응답을 하게 된다.

만약 프록시 캐시 서버와 원 서버 간 네트워크 연결이 단절되어 접근이 불가능하다면, no-cache에서는 응답으로 오류가 아닌 오래된 데이터라도 보여주자라는 개념으로 200OK으로 응답을 한다.

하지만 must-revalidate라면 원 서버에 접근이 불가할 때 504 Gateway Timeout 오류를 보낸다.

통장 잔고 등 중요한 정보가 원 서버를 못 받았다고 해서 예전 데이터로 뜬다면 큰 문제가 생기기 때문에 이런 경우 must-revalidate를 써야 한다.