HTTP 완벽가이드 - section 11

Assign: 아벨 코 Status: In Progress

읽기 전에 참고할 만한 영상

쿠키, 세션, 캐시가 뭔가요?

11 클라이언트 식별과 쿠키

11.1 개별 접촉

현대의 웹 사이트들은 여러 가지 방식으로 사이트를 개인화시켜서 유저에게 제공한다.

⇒ 비지니스 요구 사항에 의해서..! 결국 큰 그림의 UX를 위함 아닐까.

개별인사

저장된 사용자 정보

사용자 맞춤 추천

세션 추적

• 각 사용자에게서 오는 HTTP 트랜잭션을 식별할 방법이 필요하다.

---

11.2 HTTP 헤더

7가지 HTTP 요청 헤더: From, User-Agent, Referer, Authorization, Client-ip, X-Forwarded-For, Cookie

From 헤더

• 사용자의 이메일 주소를 포함한다.
• From 헤더를 보내는 브라우저는 많지 않다.
• robot이나 spider는 웹 마스터가 항의 메일을 보낼 수 있도록 From 헤더에 이메일 주소를 기술한다.

User-Agent 헤더

• 유저의 브라우저 이름, 버전 정보, 운영체제에 대한 정보를 서버에게 알려준다.
• 특정 사용자를 식별하는 데는 큰 도움이 되지 않는다.

Referer 헤더

• 현재 페이지로 유입하게 한 웹페이지의 URL을 가리킨다.
• 사용자가 이전에 어떤 페이지를 방문했었는지를 알려준다.
• 유저의 웹 사용 행태나 취향을 더 잘 파악할 수 있게 한다.

⇒ From, User-Agent, Referer 헤더들은 유저를 확실히 식별하기에는 부족한 정보이다.

---

11.3 클라이언트 IP 주소

클라이언트 IP 식별 방식의 약점

• 클라이언트 IP 주소는 사용자가 아닌, 사용하는 컴퓨터를 가리킴
• ISP는 유저가 로그인 하면 동적으로 IP 주소를 할당한다.
• NAT방화벽을 통해 인터넷을 사용하면, 클라이언트의 실제 IP 주소를 방화벽 뒤로 숨기고 내부에서 변환한다.
• 클라이언트의 IP 주소 대신 프락시 서버의 IP 주소를 본다.

---

11.4 사용자 로그인

로그인을 요구해서 사용자에게 명시적으로 식별 요청을 할 수 있다.

HTTP 인증 헤더를 사용하여 사용자 등록하기

1.브라우저가 www.example.com 사이트로 요청

2. 서버는 401 Login Required HTTP 응답 코드와 WWW-Authenticate 헤더를 반환하여 로그인 하라고 요청한다.

3. 유저는 이름과 비밀번호를 입력하고 사용자 식별을 시도한다.

4. 이제 서버는 사용자의 식별 정보를 안다.

⇒ 사이트에 한 번만 로그인하면, 브라우저는 요청마다 해당 사용자의 식별정보 토큰 Authorization 헤더에 담아 서버로 전송한다.

---

11.5 뚱뚱한 URL

URL에 상태 정보를 추가해 확장한다. 웹 서버는 URL에 있는 상태 정보를 유지하는 하이퍼링크를 동적으로 생성한다.

사용자의 상태 정보를 포함하고 있는 URL을 뚱뚱한 URL이라고 한다. 사용자에게 할당된 식별번호를 각 URL 뒤에 붙여서 사용자를 추적한다.

1. 유저가 웹 사이트에 방문하면 고유 ID가 생성된다.
2. 그 값은 서버가 인식할 수 있는 방식으로 URL에 추가된다.
3. 서버는 클라이언트를 이 뚱뚱한URL로 리다이렉트 시킨다.

뚱뚱한 URL은 여러 심각한 문제가 있다.

• 못생긴 URL

  ⇒ 유저에게 혼란을 준다.

• 공유하지 못하는 URL

  ⇒ 특정 유저의 세션에 대한 정보를 포함한다.

• 캐시를 사용할 수 없음

  ⇒ URL이 달라지기 때문에 기존 캐시에 접근할 수 없다.

• 서버 부하 가중

  ⇒ HTML페이지를 다시 그려야 한다.

• 이탈

  ⇒ URL세션에서 이탈하기 쉽다. 이탈하면 다시 처음부터 시작해야 한다.

• 세션 간 지속성의 부재

  ⇒ 로그아웃하면 모든 정보를 잃는다.

---

11.6 쿠키

유저를 식별하고 세션을 유지하는 방식 중에서 가장 널리 사용하는 방식. 매우 중요한 웹 기술일 뿐 아니라 새로운 HTTP 헤더를 정의한다.

쿠키는 캐시와 충돌할 수 있어서, 쿠키에 있는 내용물을 캐싱하지 않는다.

11.6.1 쿠키의 타입

세션 쿠키

• 사이트 탐색시, 관련 설정과 선호 사항들을 저장하는 임시 쿠키
• 사용자가 브라우저를 닫으면 삭제된다.

지속쿠키

• 삭제 되지 않고 더 길게 유지된다.
• 디스크에 저장된다. 브라우저를 닫거나 컴퓨터를 재시작 하더라도 남아있다.
• 주기적으로 방문하는 사이트에 대한 설정 정보나 로그인 이름을 유지하기 위해 사용한다.

⇒ 세션 쿠키와 지속 쿠키의 다른 점은 파기되는 시점 뿐이다.

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

• 쿠키는 서버가 유저에게 "안녕 내 이름은 .."라고 적어서 붙이는 스티커와 같다. 웹 사이트는 서버가 사용자에게 붙인 모든 스티커를 읽을 수 있다.
• 웹 서버는 유저를 식별하기 위한 유일한 값을 쿠키에 할당한다.
• 쿠키는 임의의 이름=값 형태의 리스트를 가지고, Set-Cookie같은 HTTP 응답 헤더에 기술되어 유저에게 전달한다.
• 브라우저는 서버로 온 Set-Cookie 헤더에 있는 쿠키 콘텐츠를 브라우저 쿠키 데이터베이스에 저장한다.

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

브라우저가 서버 관련 정보를 저장하고, 유저가 해당 서버에 접근할 때마다 그 정보를 함께 전송하는 것

클라이언트 측 상태: 브라우저의 쿠키 정보를 저장할 책임 (HTTP 상태 관리 체계)

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

브라우저는 보통 각 사이트에 2~3개의 쿠키를 보낸다.

• 쿠키를 모두 전달하면 성능이 크게 저하된다.
• 쿠키들은 서버에 특화된 이름/값 쌍을 포함하고 있기 때문에, 대부분 사이트에서는 인식하지 않는 무의미한 값이다.
• 개인정보문제

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

쿠키 Domain 속성

• 서버는 Set-Cookie 응답 헤더에 Domain속성을 기술해서 어떤 사이트가 그 쿠키를 읽을 수 있는지 제어할 수 있다.

쿠키 Path 속성

• Path 속성을 기술해서 해당 경로에 속하는 페이지에만 쿠키를 전달한다.

쿠키는 일종의 상태 정보라고 할 수 있다. 서버가 생성해서 클라이언트에 전달하고, 클라이언트는 그 쿠키를 유효한 사이트에서만 다시 전달하고 관리한다.

11.6.6 Version 0(넷스케이프) 쿠키

Version 0 Set-Cookie 헤더

Set-Cookie 헤더는 쿠키의 이름과 값을 가져야 한다. 쿠키 옵션 속성들에 세미콜론으로 이어 기술한다.

ex) Set-Cookie: customer=Mary

Version 0 Cookie 헤더

Domain, Path, Secure 필터들이 현재 요청 하려고 하는 사이트에 들어맞으면서 아직 파기되지 않은 쿠키들을 함께 보낸다.

ex) Cookie: session-id=002-1145264-324243; session-id-time=1007884800

11.6.7 Version 1 (RFC 2965) 쿠키

• Version 1 표준은 Set-Cookie2와 Cookie2 헤더를 소개하고 있다.
• Version 0 시스템과 호환된다.

RFC 2965에서 추가 된 주요 변경사항:

• 쿠키마다 목적을 설명하는 설명문이 있다.
• 파기 주기에 상관없이 브라우저가 닫히면 쿠키를 강제로 삭제할 수 있다.
• 절대 날짜 값 대신에 초 단위의 상대 값으로 쿠키의 생명주기를 결정할 수 있는 Max-Age
• URL의 포트번호로도 쿠키를 제어할 수 있다.
• 도메인, 포트, 경로 필터가 있으면 Cookie 헤더에 담겨 되돌려 보낸다.
• 사용자 이름과 추가적인 키워드를 구별하기 위해 Cookie 헤더에 $접두어가 있다.

11.6.8 쿠키와 세션 추적

쿠키는 웹 사이트에 수차례 트랜잭션을 만들어내는 유저를 추적하는 데 사용한다.

(전자상거래 웹 사이트는 쇼핑카트를 유지하려 세션 쿠키를 사용한다.)

Amazon.com에 방문하면 일어나는 트랜잭션의 연속:

1. 브라우저가 Amazon.com의 루트 페이지를 요청한다.
2. 서버는 클라이언트를 전자상거래 소프트웨어 URL로 리다이렉트 시킨다.
3. 클라이언트는 리다이렉트 URL로 요청 보낸다.
4. 서버는 응답에 두 개의 세션 쿠키를 기술하고 유저를 다른 URL로 리다이렉트 시키며, 클라이언트는 다시 이 쿠키들을 첨부하여 요청을 보낸다. (새로운 URL은 자체에 어떤 상태정보를 가지고 있으므로 뚱뚱한 URL이라고 할 수 있다.)
5. 클라이언트는 새로운 URL을 요청을 앞서 받은 두 개의 쿠키와 함께 보낸다.
6. 서버는 home.html 페이지로 리다이렉트 시키고 쿠키 두 개를 더 첨부한다.
7. 클라이언트는 home.html 페이지를 가져오고 총 네 개의 쿠키를 전달한다.
8. 서버는 콘텐츠를 보낸다.

11.6.9 쿠키와 캐싱

쿠키 트랜잭션과 관련된 문서를 캐싱하는 것은 주의해야 한다. 개인정보가 다른 이에게 노출되는 최악의 상황이 일어날 수 도 있다.

캐시되지 말아야 할 문서가 있다면 표시하라

• Set-Cookie 헤더를 제외하고 캐시를 해도 될 경우라면 그 문서에 명시적으로 Cache-Control: no-cache=“Set-Cookie”를 기술해서 명확히 표시한다.
• 캐시를 해도 되는 문서에 Cache-Control: public을 사용하면 웹의 대역폭을 더 절약시켜준다.

Set-Cookie 헤더를 캐시 하는 것에 유의하라

• Set-Cookie 헤더를 캐시하는 것은 주의를 기울여야만 한다. 같은 Set-Cookie 헤더를 여러 사용자에게 보내게 되면, 사용자 추적에 실패할 것이다.

Cookie 헤더를 가지고 있는 요청을 주의하라

• 요청이 Cookie 헤더와 함께 오면, 결과 콘텐츠가 개인정보를 담고 있을 수도 있다는 힌트이다.

11.6.10 쿠키, 보안 그리고 개인정보

개인정보를 다루거나 사용자를 추적하는 기술은 잘못된 의도로 사용될 수 있기 때문에 항상 조심하는 것이 좋다.

가장 큰 오용 중 하나는 협력업체 웹 사이트가 사용자를 추적하려고 지속 쿠키를 사용하는 것이다.

쿠키에 대한 부정적이 여론이 많기는 하지만, 제공하는 개인정보를 누가 받는지 명확히 알고 사이트의 개인정보 정책에만 유의한다면, 쿠키에 관련한 위험성보다 세션 조작이나 트랜잭션상의 편리함이 더 크다.