웹서버는 통신하고 있는 클라이언트를 추적하고 식별할 수 있어야 한다.

11.1 개별접촉

HTTP는 익명으로 사용하며 stateless(연결 자체에 대한 정보를 가지지 않고, 매 요청이 일회성이며 독립적으로 처리)하고 요청과 응답으로 통신하는 프로토콜이다.
웹서버가 요청을 보낸 사용자를 식별하거나 방문자가 보낸 연속적인 요청을 추적하기 위해 약간의 정보를 이용한다.

• 개별인사
  사용자 맞춤형 환영 메시지나 페이지 내용
• 사용자 맞춤 추천
  고객의 흥미가 무엇인지 학습해서 고객이 좋아할 것이라고 예상되는 제품 추천
• 저장된 사용자 정보
  주소와 신용카드 정보를 저장하기도 한다.
• 세션 추적
  HTTP 트랜잭션은 상태가 없고 각 요청 및 응답이 독립적으로 일어난다. 많은 웹사이트에서 사용자가 사이트와 상호작용할 수 있게 사용자의 상태를 남긴다.(예: 장바구니 기능) 이렇게 상태를 유지하려면 웹사이틑 각 사용자에게서 오는 HTTP 트랜잭션을 식별할 방법이 필요하다.

HTTP 가 사용자를 식별하는 방법들은 다음과 같고 각각 장단점이 있다.

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

11.2 HTTP 헤더

• From, User-Agent, Referer : 이번 절
• Authorization, Client-ip, X-Forwarded-For, Cookie : 다음절

1. From 헤더 :사용자의 이메일 주소

• 장점: 이상적으로 각 사용자가 다른 이메일 주소를 가지므로 사용자를 식별할 수 있다.
• 단점 : 악의적인 서버가 이메일 주소를 모아 스팸메일을 발송하는 문제가 있어 From 헤더를 보내는 브라우저가 많지 않다.

2. User-Agent 헤더 : 사용자가 쓰고 있는 브라우저의 이름과 버전정보(어떤 경우엔 운영체제 정보까지)

• 장점 : 특정 브라우저에서 제대로 동작할 수 있도록 콘텐츠를 최적화하는 데 유용하다.
• 단점 : 특정 사용자를 식별하는 데는 큰 도움이 되지 않는다.

3. Referer 헤더 : 사용자가 현재 페이지로 유입하게 한 웹페이지의 URL

• 장점 : 사용자의 웹 사용 행태나 사용자의 취향을 더 잘 파악할수 있다.
• 단점 : 특정 사용자를 식별하는 데는 큰 도움이 되지 않는다.

11.3 클라이언트 IP 주소

여기서부턴 특정 사용자를 식별하는 더 정확한 방법!
초기에는 사용자 식별에 클라이언트 IP 주소를 사용하려고 했다. 클라이언트의 IP 주소는 보통 HTTP 헤더에 없지만 웹 서버는 HTTP 요청을 보내는 반대쪽 TCP 커넥션의 IP주소를 알아낼 수 있다.
하지만 클라이언트 IP 주소로 사용자를 식별하는 방식은 다음과 같은 약점을 가진다.

• 클라이언트 IP 주소는 사용자가 아닌 사용하는 컴퓨터를 가리킨다. 여러 사용자가 같은 컴퓨터를 사용한다면 사용자를 식별할 수 없다.
• 많은 인터넷 서비스 제공자(ISP)는 사용자가 로그인하면 동적으로 IP주소를 할당한다. 로그인한 시간에 따라 사용자가 매번 다른 주소를 받기 때문에 웹서버가 사용자를 IP주소로 식별할 수 없다.
• 보안을 강화하고 부족한 주소들을 관리하려고 많은 사용자가 NAT 방화벽을 통해 인터넷을 사용한다. 이런 NAT 장비들은 클라이언트의 실제 IP 주소를 방화벽 뒤에 숨기고 클라이언트의 실제 IP 주소를 내부에서 사용하는 하나의 방화벽 IP주소(&포트번호)로 변환한다.
• 보통 HTTP 프락시와 게이트웨이는 원서버에 새로운 TCP 연결을 하기 때문에 웹 서버는 클라이언트의 IP 주소 대신 프락시 서버의 IP 주소를 보게된다. (프락시는 실제 클라이언트의 ip 주소를 전달하는 확장 헤더를 추가할 수 있지만 모든 프락시가 구현하진 않는다.)

11.4 사용자 로그인

웹 서버는 사용자 이름과 비밀번호로 인증(로그인)할 것을 요구해서 사용자에게 명시적으로 식별 요청을 할 수 있다.
사이트가 접속한 사용자의 식별정보를 알지 못하면 401 상태 코드를 보내 로그인을 요청하고 사용자의 식별정보를 입력받게 된다.

하지만 웹 사이트 로그인은 귀찮은 일이다. 다음 절에서는 이를 해결하는 방안을 다룬다.

11.5 뚱뚱한 URL

사용자의 상태 정보를 포함하고 있는 URL을 뚱뚱한 URL이라고 한다.
URL 경로의 처음이나 끝에 상태정보를 추가해 확장시킨다. 예를 들어 사용자에게 할당된 식별번호를 각 URL 뒤에 붙여 사용자를 추적한다.

웹서버와 통신하는 독립적인 HTTP 트랜잭션을 하나의 세션 혹은 방문으로 묶는 용도로 사용된다.
사용자가 접속하면 뚱뚱한 URL을 만들고 뚱뚱한 URL로 클라이언트를 리다이렉트 시킨다. 서버가 뚱뚱한 URL을 포함한 요청을 받으면 사용자의 밖으로 향하는 모든 하이퍼링크를 뚱뚱한 URL로 바꾼다.
뚱뚱한 URL은 사이트를 브라우징하는 사용자를 식별하는 데 사용할 수 있지만 문제가 있다.

• 못생긴 URL
  사용자에게 혼란을 준다.
• 공유하지 못하는 URL
  특정 사용자와 세션에 대한 상태 정보가 URL에 담기게 되기 때문에 공유되면 개인정보가 유출된다.
• 캐시를 사용할 수 없음
  URL로 만드는 것은 URL이 달라지기 떄문에 기존 캐시에 접근할 수 없음을 의미한다.
• 서버 부하 가중
  서버는 뚱뚱한 URL에 해당하는 HTML을 다시 그려야 한다.
• 이탈
  사용자가 뚱뚱한 URL 세션에서 이탈하기 쉽다.
• 세션 간 지속성의 부재
  사용자가 로그아웃하면 모든 정보를 잃는다.

11.6 쿠키

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

11.6.1 쿠키의 타입

세션 쿠키

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

지속 쿠키

• 사용자가 주기적으로 방문하는 사이트에 대한 설정 정보나 로그인 이름을 유지하려고 사용한다.

=> 둘의 차이는 파기되는 시점!
(Discard 파라미터 유 / Expires or Max-Age 파라미터 유 -> 세션 쿠키)

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

1. 처음에 사용자가 웹 사이트에 방문하면 웹 서버는 사용자에 대해서 아무것도 모른다.
2. 웹 서버는 사용자가 다시 돌아왔을 때 해당 사용자를 식별하기 위한 유일한 값을 쿠키에 할당한다. (쿠키는 임의의 이름=값 형태의 리스트를 가짐)
3. 쿠키의 리스트는 Set-Cookie 혹은 Set-Cookie2 같은 HTTP 응답 헤더에 기술되어 사용자에게 전달한다.
4. 사용자가 미래에 같은 사이트를 방문하면 브라우저는 서버가 이 사용자에게 할당헀던 쿠키를 Cookie 요청 헤더에 기술해서 전송한다.

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

브라우저는 쿠키 정보를 저장할 책임이 있다. 이런 시스템을 클라이언트 측 상태라고 한다. (공식 명칭은 HTTP 상태 관리 체계)
각 브라우저는 각기 다른 방식으로 쿠키를 저장한다.

구글 크롬 쿠키

Cookies라는 SQLite 파일에 쿠키를 저장

• creation_utc : 쿠키가 새성된 시점
• host_key : 쿠키의 도메인
• name : 쿠키의 이름
• value : 쿠키의 갓
• path : 쿠키와 관련된 도메인에 있는 경로
• expire_utc : 쿠키의 파기 시점
• secure : 쿠키를 SSL 커넥션일 경우에만 보낼지를 가리킴

마이크로소프트 인터넷 익스플로러 쿠키

캐시 디렉터리에 각각의 개별 파일로 쿠키를 저장한다.

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

브라우저가 쿠키 전부를 모든 사이트에 보내지는 않는다. 브라우저는 보통 각 사이트에 두세개만의 쿠키를 보낸다.
왜???

• 쿠키를 모두 전달하면 성능이 크게 저하된다.(실제 콘텐츠보다 쿠키가 바이트가 커지는...)
• 이 쿠키들 대부분이 서버에 특화된 이름/값 쌍을 포함하고 있기 때문에 대부분의 사이트에서는 인식하지 않는 무의미한 값이다.
• 모든 사이트에 쿠키 전체를 전달하는 것은 잠재적인 개인정보 문제를 일으킬 수 있다.(특정사이트에서 제공한 정보를 신뢰하지 않는 사이트에서 가져갈 수 있다.)

웹사이트 자체의 일부인 것처럼 제작된 광고드은 지속 쿠키를 만들어낸다. 같은 광고사에서 제공하는 서로 다른 웹 사이트에 사용자가 방문하면 브라우저는 앞서 만든 지속 쿠키를 다시 광고사 서버로 전송한다. 이는 지속 쿠키의 도메인이 같기 때문이다. 광고사는 이 기술에 Referer 헤더를 접목해서 사용자의 프로필과 웹사이트를 사용하는 습관에 대한 방대한 데이터를 구축할 수 있다. (오용될수도 있다)

쿠키 Path 속성

웹 사이트 일부에만 쿠키를 적용할 수 있다.
URL 경로의 앞부분을 가리키는 Path 속성을 기술해서 해당 경로에 속하는 페이지에만 쿠키를 전달한다.

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

11.6.8 쿠키와 세션 추적

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

예 : Amazon.com에서 세션쿠키를 사용하여 쇼핑카트 유지

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

11.6.9 쿠키와 캐싱

다른 사용자 쿠키가 할당되거나 개인정보가 다른 사람에게 노출되는 일이 벌어질 수 있기 때문에 쿠킨 트랜잭션과 관련된 문서를 캐싱하는 것은 주의해야한다.