[CS] 응용 계층 - HTTP의 응용

눈치없어·2025년 3월 27일

쿠키, 캐시, 콘텐츠 협상, 인증, 보안으로 대표되는 각종 HTTP 기반의 다양한 기술들

쿠키

HTTP는 상태를 기억하지 않는 스테이트리스 프로토콜이기 때문에
사용자 상태를 유지하려면 추가적인 수단이 필요

쿠키는 서버가 생성하고 클라이언트에 저장하는 <이름, 값> 형태의 데이터

📌 쿠키 특징

이름과 값 이외에도 때로는 쿠키의 만료 기간과 같은 추가적인 속성값도 가질 수 있음
클라이언트는 서버로부터 받은 쿠키를 주로 브라우저에 저장
서버로부터 전달받은 쿠키는 브라우저를 통해 확인할 수 있음
서버는 쿠키를 생성하여 클라이언트에 전송하고, 클라이언트는 쿠키를 저장해 두었다가 추후 같은 서버에 요청을 보낼 때 요청 메시지에 쿠키를 포함하여 전송

쿠키 용도 예시

"3일간 보지 않기"
로그인 유지
사용자 맞춤 설정 기억

📌 쿠키 동작 흐름

서버 → 클라이언트로 쿠키 전송
- 응답 메시지의 Set-Cookie 헤더 사용
클라이언트 → 서버로 쿠키 전송
- 요청 메시지의 Cookie 헤더 사용

📌 쿠키 전달 예시

응답 메시지의 Set-Cookie 헤더 예시

쿠키의 이름과 값, 때로는 세미콜론으로 구분한 쿠키의 속성이 명시될 수 있음
여러 쿠키를 전달할 때는 여러 개의 Set-Cookie 헤더가 사용되기도 함

Set-Cookie: 이름=값
Set-Cookie: 이름=값; 속성1
Set-Cookie: 이름=값; 속성1; 속성2

HTTP/1.1 200 OK  
Content-Type: text/html  
Set-Cookie: name=javaaaa  
Set-Cookie: phone=100-100  
Set-Cookie: message=Hello

Cookie 헤더의 예시

서버에 여러 쿠키를 전달할 때는 세미콜론으로 여러 쿠키의 <이름, 값> 쌍을 구분할 수 있음
특정 서버로부터 쿠키를 전달받았다면 다음부터 해당 서버에 요청을 보낼 때 전달받은 쿠키를 자동으로 전송
즉, 어떤 서버로부터 쿠키를 전달받으면 해당 서버에 보내는 요청 메시지에는 자동으로 전달받은 쿠키가 포함

Cookie: 이름=값; 이름=값;

GET /next_page HTTP/1.1  
Host: example.com  
Cookie: name=javaaaa; phone=100-100; message=Hello

📌 쿠키 속성 종류

대부분의 쿠키 데이터에는 속성값이 포함되어 있음

Domain
쿠키를 전송할 도메인 지정
Set-Cookie: name=javaaaa; Domain=javaaaa.net
Path
쿠키를 전송할 URL 경로 지정
Set-Cookie: name=javaaaa; Path=/lectures
Expires
쿠키 만료 시점 지정 (형식: 요일, 날짜, 시간, GMT)
Set-Cookie: sessionID=abc123; Expires=Fri, 23 Aug 2024 09:00:00 GMT
Max-Age
쿠키 유효기간을 초 단위로 설정
예: Set-Cookie: sessionID=abc123; Max-Age=2592000 (30일)
Secure
HTTPS 통신에서만 쿠키를 주고받을 수 있도록 제한
HttpOnly
자바스크립트에서 쿠키 접근을 제한

📌 웹 스토리지: 로컬 스토리지와 세션 스토리지

웹 브라우저 내의 저장 공간으로, 일반적으로 쿠키보다 더 큰 데이터를 저장할 수 있음
쿠키는 서버로 자동 전송되지만, 웹 스토리지의 정보는 서버로 자동 전송되지 않음

웹 스토리지는 크케 로컬 스토리지와 세션 스토리지가 있음

로컬 스토리지: 별도로 삭제하지 않는 한 영구적으로 저장이 가능한 정보
세션 스토리지: 세션이 유지되는 동안(브라우저가 열려있는 동안) 유지되는 정보

캐시

캐시 메모리는 메모리에 접근하는 시간을 줄이기 위해 자주 참조되는 내용을 저장하는 장치
HTTP에서도 이와 유사한 개념인 HTTP 캐시(혹은 웹 캐시, 이하 캐시)가 있음

캐시: 응답받은 자원의 사본을 임시 저장하여 불필요한 대역폭 낭비와 응답 지연을 방지하는 기술

자원의 사본을 임시 저장하면 추후 동일한 요청 메시지를 보내야 할 때 임시 저장된 사본을 재활용할 수 있고, 결과적으로 더 빠르게 자원에 접근할 수 있음

캐시는 클라이언트(주로 웹 브라우저)에 저장되기도 하고, 클라이언트와 서버 사이에 위치한 중간 서버에 저장되기도 함
전자를 개인 전용 캐시, 후자를 공용 캐시 라고 함

캐시 유효기간

📌 캐시 유효기간 설정 방법

1️⃣ Expires 헤더

자원의 만료 일시를 명시

Expires: Tue, 06 Feb 2024 12:00:00 GMT

2️⃣ Cache-Control 헤더 + max-age 속성
현재 시점부터 몇 초 동안 캐시 유효한지를 지정

Cache-Control: max-age=1200

📌 캐시 유효기간 필요 이유

서버의 원본 자원이 변경될 수 있기 때문에 캐시된 데이터와 서버 원본 사이에 불일치가 발생할 수 있음
그래서 일정 시간이 지나면 다시 원본 자원이 바뀌었는지 확인하게 됨
- 이걸 캐시 신선도(freshness)라고 함

📌 캐시 유효기간 만료 후 동작

캐시 유효기간이 끝났다고 무조건 서버에서 자원을 다시 받는 건 아님
대신 원본이 변경됐는지 서버에 물어보고, 변경됐다면 다시 받고 변경 안 됐다면 캐시 재사용하면 됨

캐시 신선도 확인 방법

📌 날짜 기반: If-Modified-Since

: 특정 시점 이후로 원본 자원에 변경이 있었다면 그때만 변경된 자원을 메시지 본문으로 응답하도록 서버에게 요청하는 헤더

If-Modified-Since: Fri, 23 Aug 2024 09:00:00 GMT

If-Modified-Since 헤더를 받은 서버의 자원은 3가지 중 하나의 상황을 따르게 됨

1️⃣ 서버가 요청받은 자원이 변경된 경우
→ 200 OK + 새로운 자원 반환

2️⃣ 서버가 요청받은 자원이 변경되지 않은 경우
→ 304 Not Modified + 본문 없음
→ 캐시 사용

3️⃣ 서버가 요청받은 자원이 삭제된 경우
→ 404 Not Found

📌 버전 기반: If-None-Match

: 요청할 자원에 대한 Etag 값이 명시되며, Etag 값과 일치하는 Etag가 없다면 그때만 변경된 자원으로 응답하도록 서버에게 요청하는 헤더

Etag(엔티티 태그): 자원의 버전을 식별하기 위한 정보
자원이 바뀌면 Etag도 바뀜

서버에 특정 자원의 엔티티 값이 변경되었는지를 물음으로써 자원의 변경 여부도 알 수 있음

If-None-Match: "abc123"

If-None-Match 헤더를 받은 서버의 자원도 3가지 중 하나의 상황을 따르게 됨

1️⃣ 서버가 요청받은 자원이 변경된 경우
→ 200 OK + 새로운 자원 반환

2️⃣ 서버가 요청받은 자원이 변경되지 않은 경우
→ 304 Not Modified + 본문 없음
→ 캐시 사용

3️⃣ 서버가 요청받은 자원이 삭제된 경우
→ 404 Not Found

콘텐츠 협상

HTTP에서 같은 자원에 대해 다양한 표현이 있을 수 있음
→ 예: 한국어, 영어 / HTML, XML 등
클라이언트는 자신이 선호하는 표현 방식을 요청 헤더를 통해 서버에 전달

서버는 그에 따라 가장 적절한 표현으로 응답을 보내주는 과정이 콘텐츠 협상

📌 대표적인 콘텐츠 협상 헤더

Accept: 선호하는 미디어 타입을 나타내는 헤더
Accept-Language: 선호하는 언어를 나타내는 헤더
Accept-Encoding**: 선호하는 인코딩 방식을 나타내는 헤더

GET /index.html HTTP/1.1  
Host: example.com  
Accept-Language: ko  
Accept: text/html

→ 클라이언트는 HTML 형식을 선호하고, 언어는 한국어를 원함

📌 우선순위 지정 방법 (q값)

각 표현에 대해 선호도(우선순위)를 지정할 수 있음

q는 Quality Value의 약자, 범위는 0.0 ~ 1.0
생략 시 기본값은 1.0
값이 클수록 우선순위가 높음

GET /index.html HTTP/1.1  
Host: example.com  
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7  
Accept: text/html,application/xml;q=0.9,text/plain;q=0.6,*/*;q=0.5

→ 클라이언트는 한국어, 영어 순으로 선호하며, HTML과 XML, 일반 텍스트 순으로 선호함

보안: SSL/TLS와 HTTPS

HTTPS = HTTP + SSL/TLS
일반 HTTP에 보안기능(암호화 + 인증)을 추가한 프로토콜
사용자가 접속한 사이트 주소창에 자물쇠 아이콘이 보이면 HTTPS 사용중을 의미

SSL / TLS

SSL: 초기 보안 프로토콜
TLS: SSL의 후속 버전
현재는 TLS 1.2와 TLS 1.3이 주로 사용됨

HTTPS 통신 과정(TLS 1.3 기반)

1️⃣ TCP 쓰리 웨이 핸드셰이크
2️⃣ TLS 핸드셰이크
3️⃣ 메시지 송수신

HTTPS 메시지 송수신은 일반적인 HTTP 메시지 송수신에 2️⃣가 더해진 것에 불과함
2️⃣의 과정을 거쳐 메시지 암호화가 이루어지므로 2️⃣를 거쳐 3️⃣에서 주고받는 메시지는 암호화된 메시지

📌 TLS 핸드셰이크 핵심

1️⃣ 암호화 통신을 위한 키 생성/교환

TLS에서 활용되는 암호화 알고리즘을 통해 평문을 암호화하거나 반대로 암호문을 복호화 하려면 키라는 정보가 필요
서버와 클라이언트는 서로 암호화에 사용할 세션 키를 안전하게 생성
이를 위해 ClientHello ↔ ServerHello 메시지를 주고받음

암호화 알고리즘: 암호화를 수행하는 알고리즘
암호 스위트: TLS 통신에서 사용할 암호화, 인증, 키 교환, 무결성 검증 알고리즘의 조합