HTTP는 기본적으로 Stateless 상태
서버는 클라이언트가 누구인지 기억하지 않음
(각각의 요청은 독립적, 개별적)
Stateless의 결과
- 웹 트랜잭션(web transaction)이라는 개념 X
(요청 순서 기억 X) - 클라이언트/서버의 상호작용 상태를 추적할 필요 없음
- 부분적으로 처리된 요청에 대해 복구할 필요 없음
만약 네트워크나 클라이언트에 문제 생기면,
불완전한 처리 발생할 가능성 높음
1. 쿠키(cookies)
HTTP가 원래 stateless인데도 사용자/서버 간 상태를 유지하기 위한 정보 조각
쿠키 작동을 위한 요소
- Set-Cookie 헤더
(서버 → 클라이언트로 쿠키 전달) - 쿠키 헤더 (요청 시)
(클라이언트 → 서버로 쿠키 포함 요청) - 쿠키 파일
(사용자 로컬에서 쿠키 저장) - 서버 데이터베이스
(쿠키 ID에 해당하는 사용자 상태 정보 저장)
Example 1. Susan의 쇼핑몰 접속
- 사용자가 처음 웹사이트 접속 (Susan이 쇼핑몰 처음 방문)
- 서버는 Susan에게 고유 ID (unique ID)를 생성
→ 이를 쿠키 값으로 응답 메시지에 포함 - 이후 Susan이 다시 같은 사이트에 요청할 경우
→ 브라우저는 해당 쿠키를 자동으로 포함시켜 보냄
→ 서버는 쿠키에 있는 ID를 기반으로 Susan을 인식
Example 2. 아마존 웹사이트 접속
1. 최초 접속
→ 클라이언트가 아마존 서버에 HTTP 요청 전송
→ 서버가 클라이언트를 처음 봤기 때문에 고유 ID: 1678 생성
→ Set-Cookie: 1678 응답에 포함
2. 쿠키 저장
→브라우저가 받은 쿠키(1678)를 로컬 쿠키 파일에 저장
3. 다음 접속 (일주일 후)
→ 브라우저가 다시 아마존에 접속할 때,
저장해둔 cookie: 1678을 요청 메시지에 자동 포함
4. 서버는 쿠키를 확인하고 사용자 식별
→ 데이터베이스에서 1678에 해당하는 사용자 정보 조회
5. 클라이언트에 맞춘 행동 수행
→ 서버는 해당 사용자에 맞는 cookie-specific action 수행
(ex. 로그인 유지)
쿠키의 사용 용도
- Authorization (인증) : 로그인 상태 유지
- Shopping carts (장바구니) : 상품을 담아두고 유지
- Recommendations (추천) : 사용자 이전 행동 기반 추천
- User session state (세션 상태) : 웹 메일 로그인 유지
Cookies와 Privacy
어떤 페이지를 봤는지, 얼마 머물렀는지 등 추적 가능
- 광고 맞춤화, 관심사 분석 등에 활용됨
2. Web caches (proxy servers)
클라이언트의 요청을 원래 서버에 전달하지 않고도 처리할 수 있도록 하는 방법
Web caches 동작 과정
1) 사용자가 브라우저를 웹 캐시(Web cache)로 설정함
(웹 캐시는 프록시 서버(proxy server)로 동작함)
2) 브라우저는 모든 HTTP 요청을 캐시로 보냄
(클라이언트 → 캐시(프록시 서버)로 요청 전송)
- 요청한 객체가 캐시에 있을 경우
: 클라이언트에 즉시 응답 반환 (빠름, 효율적) - 요청한 객체가 캐시에 없을 경우
: 캐시는 원래 서버에 HTTP 요청을 전송
→ 객체를 받아오고, 그것을 자신의 캐시에 저장한 뒤
→ 클라이언트에게 응답을 반환함
Web caches의 역할
Web cache는 클라이언트이자 서버 역할을 함
- 클라이언트에게는 '서버처럼' 동작
- 서버에게는 '클라이언트처럼' 동작
일반적으로 ISP(인터넷 서비스 제공자)가 Web cache설치
(ex. 학교, 회사, 가정용 인터넷 사업자)
Web caches 이점
- 클라이언트의 응답 시간 단축
캐시가 클라이언트와 물리적으로 가까운 곳에 위치
(원래 서버보다 더 빠르게 응답 가능) - 네트워크 트래픽 감소
캐시가 자주 요청되는 콘텐츠를 저장하고 제공
(같은 데이터를 반복적으로 요청할 필요X) - 콘텐츠 제공자에게도 유리
(소규모 제공자도 더 많은 사용자에게 효율적으로 콘텐츠 제공 가능)
3. Caching example
Scenario
Access link utilization
access link rate: 1.54 Mbps
1.54 Mbps로 사용 중이라 이용률이 매우 높음 (~97%)
- 접속 링크에 비해 요청량이 과도
→ 큐 대기 지연 발생
Problem
High utilization → large queuing delay
대역폭 거의 꽉 차면 대기 시간이 급격히 증가함
(acess link에 비해 요청되는게 많음)
Solution
- access link rate 높이기
(너무 비쌈) - web cache 사용
Web Cache 사용
가정
Cache hit rate = 0.4
- 요청의 40%는 캐시에서 처리, 60%는 여전히 원 서버(origin server)에서 처리
1) Access Link 사용 비율
요청 중 60%가 여전히 외부 인터넷과 연결된 접속 링크를 사용함
2) Access Link를 통한 데이터 속도 계산
3) Access Link Utilization (이용률)
(이전 상황의 혼잡도 0.97보다 낮음 -> 혼잡 감소)
4) End-to-End Delay 계산
결과
- 캐시 덕분에 평균 응답 시간이 크게 줄어듦
- 비용 절감 + 성능 향상
4. Conditional GET
캐시된 데이터를 효율적으로 사용할 수 있도록
서버와 클라이언트가 조건부로 통신하는 방식
(데이터가 최신이면, 서버가 굳이 객체를 다시 보내지 않도록)
- 전송 지연 X
- 링크 자원 절약
Conditional GET 동작 원리
Cache의 역할
내가 가진 객체가 언제 저장된 것인지 HTTP 요청 헤더에 포함시켜 전송함
If-Modified-Since: <날짜>
server의 역할
헤더를 보고 객체가 수정되지 않았다면, 객제 전송 생략
(클라이언트는 기존 버전으로 사용)
HTTP/1.0 304 Not Modified
하지만 객체가 수정되었다면, 서버는 새로운 데이터 전송
HTTP/1.0 200 OK
<data>
