[HTTP] 클라이언트 식별과 쿠키

클라이언트 식별과 쿠키

• 서버가 통신하는 대상을 식별하는 데 사용하는 기술

11.1 개별 접촉

• HTTP는 익명으로 사용하며 상태가 없고 요청과 응답으로 통신하는 프로토콜이다.
  • 상태가 없다 = stateless

• 웹 서버는 요청을 보낸 사용자를 식별하거나 방문자가 보낸 연속적인 요청을 추적하기 위해 약간의 정보를 이용할 수 있다.
• 현대의 웹사이트들은 개인화된 서비스를 제공하고 싶어 한다.
  • 여러 사이트들은 본인들의 사이트를 개인화시켜서 사용자에게 제공한다.

개인화 방법

• 개별 인사
  • 사용자에게 특화된 환영 메시지나 페이지 내용을 만듦
• 사용자 맞춤 추천
  • 사용자 개개인별 상품 추천
• 저장된 사용자 정보
  • 온라인 상점에서 한번 식별된 정보를 저장하여 재사용성을 높임
• 세션 추적
  • HTTP 트랜잭션은 stateless기 때문에 요청 과 응답이 독립적으로 이루어짐
  • 많은 웹사이트에서 사용자가 사이트와 상호작용할 수 있게 사용자의 상태를 남김(장바구니)
  • 상태 유지를 위해 HTTP 트랜잭션을 식별하는 방법이 필요

이번 장 포인트

• HTTP가 사용자를 식별하는 데 사용하는 기술들을 정리
• 사용자 식별 관련 정보를 전달하는 HTTP 헤더들
• 클라이언트 IP 주소 추적으로 알아낸 IP 주소로 사용자를 식별
• 사용자 로그인 인증을 통한 사용자 식별
• URL에 식별자를 포함하는 기술인 뚱뚱한(fat) URL
• 식별 정보를 지속해서 유지하는 강력하면서도 효율적인 기술인 쿠키

11.2 HTTP 헤더

• 사용자 정보 전달을 위한 가장 기본적인 일곱 가지 HTTP 요청 헤더

헤더 이름	헤더 타입	설명
From	요청	사용자의 이메일 주소
User-Agent	요청	사용자의 브라우저
Referer	요청	사용자가 현재 링크를 타고 온 근원 페이지
Authorization	요청	사용자 이름과 비밀번호
Client-ip	확장(요청)	클라이언트 IP 주소
X-Forwarded-For	확장(요청)	클라이언트 IP 주소
Cookie	확장(요청)	서버가 생성한 ID 라벨

11.3 클라이언트 IP 주소

• 초기 웹 선구자들은 IP 주소를 사용자 식별에 이용하려고 했음
  • 잘 바뀌지 않으며 사용자마다 확실한 IP주소를 가지고 있었기 때문이다.

• 그러나 다음과 같은 약점을 가지고 있다.
  • 클라이언트 IP 주소는 사용자가 아닌 사용하는 컴퓨터를 가리킴 -> 여러 사람이 하나의 컴퓨터를 사용할 수 있다.
  • ISP가 동적으로 IP 주소를 할당하기 때문에 매번 다른 주소를 받을 수 있음 (변동 가능성)
  • 네트워크 방화벽은 IP주소를 숨김
  • 프락시가 끼는 경우 프락시 IP가 전송되는 경우가 있음

11.4 사용자 로그인

• IP 주소로 사용자를 식별하는 것은 수동적인 방법이다.
• 웹 서버는 사용자 이름과 비밀번호로 인증(로그인)할 것을 요구해서 사용자에게 명시적으로 식별 요청을 할 수 있음
  • WWW-Authenticate, Authorization 헤더 사용
  • 자세한 내용은 12장에서 다룰 예정

• 웹사이트 로그인은 귀찮은 일이다.
  • 사이트를 옮기면 그때그때 로그인을 해줘야하며 심지어 아이디와 비밀번호를 계속 기억해야한다.

11. 5 뚱뚱한URL

• 사용자의 상태 정보를 포함하고 있는 URL을 뚱뚱한(fat) URL 이라고 함
• 웹 서버와 통신하는 독립적인 HTTP 트랜잭션을 하나의 '세션' 혹은 '방문으로' 묶는 용도로 뚱뚱한 URL 사용 가능
• 이것으로 사용자를 식별가능 하다.

• 문제점
  • 못생긴 URL
    • URL 구분이 힘듦
  • 공유하지 못하는 URL
    • 개인정보가 포함되어 있기 때문
  • 캐시를 사용할 수 없음
    • URL이 달라지기 때문에 사용 불가
  • 서버 부하 가중
    • 뚱뚱한 URL에 맞게 HTML 페이지를 다시 그려야함
  • 이탈
    • 다른 페이지로 이동시 초기화 될 수 있음
  • 세션 간 지속성 부재
    • 로그아웃하면 모든 정보를 잃게됨

11.6 쿠키

• 쿠키는 사용자를 식별하고 세션을 유지하는 방식 중에서 현재까지 가장 널리 사용하는 방식
• 쿠키는 캐시와 충돌할 수 있어서, 대부분의 캐시나 브라우저는 쿠키에 있는 내용물을 캐싱하지 않음

11.6.1 쿠키의 타입

• 세션 쿠키
  • 사용자가 사이트를 탐색할 때 관련한 설정과 선호 사항들을 저장하는 임시 쿠키
  • 브라우저 닫으면 사라짐

• 지속 쿠키
  • 디스크에 저장되어 브라우저 닫아도 남아있음
  • 사용자가 주기적으로 방문하는 사이트에 대한 설정 정보나 로그인이름을 유지하기위해 사용

• 쿠키는 Discard 파라미터가 설정되어 있거나, 파기되기까지 남은 시간을 가리키는 Expires, Max-age가 없음녀 세션 쿠키가됨

11.6.2 쿠키는 어떻게 동작하는가

• 처음 웹 사이트 방문시에는 쿠키가 없다.
• 웹 서버는 Set-Cookie, Set-Cookie2(확장 헤더) 같은 HTTP 응답 헤더에 쿠키 정보를 담아 사용자에게 전달함
• 브라우저는 서버로 온 Set-Cookie, Set-Cookie2 헤더에 있는 쿠키 컨텐츠를 브라우저 쿠키 데이터베이스에 저장함
• 사용자가 미래에 같은 사이트를 방문하면 그 쿠키를 통해 확인함

11.6.3 쿠키 상자 : 클라이언트 측 상태

• 쿠키의 기본적인 발상은 브라우저가 서버 관련 정보를 저장하고, 사용자가 해당 서버에 접근할 때마다 그 정보를 함께 전송하는 것
• 브라우저는 쿠키 정보를 저장할 책임이 있는데 이 시스템은 클라이언트 측 상태 라고 함
• 공식적 이름은 HTTP 상태 관리 체계
  • HTTP State Management Mechanism

11.6.4 사이트마다 각기 다른 쿠키들

• 브라우저는 보통 각 사이트에 두 개 혹은 세 개의 쿠키만을 보냄
  • 쿠키를 모두 전달하면 성능 저하됨
  • 이름/값 쌍 형태인데 대부분 사이트에서는 인지못함
  • 쿠키를 준다는 것은 개인정보를 준다는 것이기 때문에 문제를 일으킬 수 있음

• 보통 브라우저는 쿠키를 생성한 서버에게만 쿠키를 담긴 정보를 전달함

• 쿠키 Domain
  • 쿠키에 domain 속성을 기술해 어떤 사이트에서 쿠키를 읽을 수 있는지 기술함
  • ex) Set-cookie: user="mary17"; domain="airtravelbargains.com"

• 쿠키 Path
  • 웹사이트 일부에만 적용 가능
  • ex) Set-cookie: user="mary17"; domain="airtravelbargains.com"; path=/autos/

11.6.5 ~ 11.6.7 까지는 쿠키 헤더에 대한 정보

11.6.8 쿠키와 세션 추적

• 쿠키는 웹 사이트에 수차례 트랜잭션을 만들어내는 사용자를 추적하는 데 사용함

• 이 요청과정에서 서버는 계속해서 세션 쿠키를 첨부한다.

11.6.9 쿠키와 캐싱

• 쿠키 트랜잭션과 관련된 문서를 캐싱하는 것은 주의해야함
  • 개인정보가 유출될 수 있기 때문
• 캐시를 다루는 기본 원칙
  • 캐시되지 말아야할 문서가 있다면 표시하라
    • 명시적으로 Cache-Control: no-cache = "Set-cookie"를 기술할수 있음
    • 캐시를 해도 되는 문서에 Cache-Control:public을 사용하면 웹의 대역폭을 절약시켜줌

• Set-Cookie 헤더를 캐시 하는것에 유의하라
  • 같은 Set-Cookie를 헤더를 여러 사용자에게 보내면 사용자 추적에 실패할 것이다.
  • 어떤 캐시는 응답 저장 전 Set-Cookie 헤더를 제거한다.
  • Cache-Control: must-revalidate, max-age = 0 속성을 통해 문서 재검사 가능

• Cookie 헤더를 가지고 있는 요청을 주의하라
  • 결과 콘텐츠가 개인 정보를 담고있을수 있음