HTTP 완벽가이드
11장 클라이언트 식별과 쿠키
- 웹 서버는 서로 다른 수천 개의 클라이언트들과 동시에 통신한다. 이 서버들은 익명의 클라이언트들로부터 받는 모든
요청을 처리하는 것 뿐만 아니라 서버와 통신하고 있는 클라이언트를 추적해야 할 수도 있다.
=> 이 장에서는 서버가 통신하는 대상을 식별하는 데 사용하는 기술을 알아본다.
11.1 개별 접촉
- HTTP는 익명으로 사용하여 상태가 없고 요청과 응답으로 통신하는 프로토콜이다.
무상태성
- 연결 자체에 대한 정보를 가지지 않으며 매 요청은 일화성이고 독립적으로 처리된다.
- 이를 가리켜 HTTP는 상태가 없다고 하거나 무상태 ( Stateless )라 부른다.
- 서버는 클라이언트가 보낸 요청을 처리하고 나서 그 응답을 클라이언트로 전송한다.
=> 웹 서버는 요청을 보낸 사용자를 식별하거나 방문자가 보낸 연속적은 요청을 추적하기 위해 약간의 정보를 이용
할 수 있다.
현대의 웹 사이트들은 개인화된 서비스를 제공하고 싶어 한다.
네트워크로 연결 된 사용자들에 대해 더 많은 것을 알고 싶어하며 사용자들이 브라우징하는 것을 기록하고 싶어한다.
예로 Amazon.com같이 유명한 온라인 쇼핑 사이트는 여러가지 방식으로 사이트를 개인화시켜 사용자에게 제공한다.
- 이 장에서는 HTTP가 사용자를 식별하는 데 사용하는 기술들을 정리한다.
- HTTP 자체 식별 관련 기능이 풍부하지 않아 초기 웹 사이트 설계자들은 그들만의 기술을 개발해 활용했다.
11.2 HTTP 헤더
헤더 이름 헤더 타입 설명
From 요청 사용자의 이메일 주소
User-Agent 요청 사용자의 브라우저
Referer 요청 사용자가 현재 링크를 타고 온 근원 페이지
Authorization 요청 사용자 이름과 비밀번호
Client-ip 확장 클라이언트의 IP 주소
X-Forwarded-For 확장 클라이언트의 IP 주소
Cookie 확장 서버가 생성한 ID 라벨
- From 헤더는 사용자의 이메일 주소를 포함한다. 각 사용자가 서로 다른 이메일 주소를 가지므로, From 헤더를 통해
식별이 가능하다. 하지만 악의 적인 서버가 이메일 주소를 모아 스팸 메일을 발송하는 문제가 있어 From 헤더를 보내는
유저는 많지 않다.
- User-Agent 헤더는 사용자가 사용하는 브라우저의 이름과 버전정보를 포항해 서버에게 알려주는데 이는 특정
브라우저에서 제대로 동작하도록 그것들의 속성에 맞추어 콘텐츠를 최적화하는 데 유용할 수 있다.
하지만 특정 사용자를 식별하는 덴 큰 도움이 되지 않는다.
- Referer 헤더는 사용자가 현재 페이지로 유입하게 한 웹페이지의 URL을 가리킨다.
Referer만으로는 사용자를 식별할 수 없지만 사용자가 이전에 어떤 페이지를 방문했는지 알려줘 사용자의 웹 사용
형태나 사용자 취향을 파악가능하다.
※ From, User-Agent, Referer 헤더들은 확실히 식별하기엔 부족하다.
11.3 클라이언트 IP 주소
- 초기 웹 개발자들은 사용자 식별에 클라이언트의 IP 주소를 사용하려 했다.
- IP 주소는 보통 HTTP헤더에 없지만 웹 서버는 HTTP 요청을 보내는 반대쪽 TCP 커넥션의 IP 주소를 확인 가능하다.
※ 약점
1. 클라이언트 IP 주소는 사용자가 아닌 사용하는 컴퓨터를 가리킨다. 여러 사람이 같은 컴퓨터를 사용하면?
2. 많은 인터넷 서비스 제공자 ( ISP )가 사용자가 로그인ㄴ하면 동적으로 IP 주소를 할당한다.
3. 네트워크 주소 변환 방화벽을 통해 인터넷을 사용한다. 실제 IP 주소를 방화벽 뒤에 숨기고 클라이언트의 실제 IP 주소를
내부에서 사용하는 하나의 방화벽 IP 주소로 변환한다.
11.4 사용자 로그인
- IP 주소로 사용자를 식별하려는 수동적인 방식보다, 웹 서버는 사용자 이름과 비밀번호 인증 ( 로그인 ) 할 것을 요구해
사용자에게 명시적으로 식별 요청을 할 수 있다.
- 웹 사이트 로그인이 더 쉽도록 HTTP는 WWW-Authenticate와 Authorization 헤더를 사용해 웹 사이트에 사용자 이름을
전달하는 자체적인 체계가 존재한다.
- 한 번 로그인하면 브라우저는 사이트로 보내는 모든 요청에 이 로그인 정보를 함께 보내므로 웹 서버는 그 로그인 정보를
항상 확인할 수 있다.
클라이언트 ----- 인터넷 ----> 서버
요청 메시지
GET /index.html HTTP/1.0
Host: www.joes-hardware.com
클라이언트 <---- 인터넷 ---- 서버
응답 메시지
HTTP/1.0 401 Login Required
WWW-authenticate: Basic realm="Plumbing And Fixtures"
클라이언트 ----- 인터넷 ----> 서버
요청 메시지
GET /index.html HTTP/1.0
Host: www.joes-hardware.com
Authorization: Basic am910jRmdw4=
클라이언트 <---- 인터넷 ---- 서버
응답 메시지
HTTP/1.0 200 OK
Content-length: 4342
Content-type: text/html
※ 약점
- 웹 사이트 로그인은 귀찮은 일이다. 예를 들면 프레드라는 사용자는 사이트를 옮겨다닐 때마다 각 사이트에 로그인을
해야한다. + 매번 아이디 비밀번호를 기억해야함.. 누가 fred라는 아이디를 선점했다면 어떡할 것인가.
11.5 뚱뚱한 URL
- 어떤 웹 사이트는 사용자의 URL마다 버전을 기술하여 사용자를 식별하고 추적하였다.
- 보통 URL은 URL의 경로의 처음이나 끝에 어떤 상태 정보를 추가하여 확장할 수 있다.
- 사용자가 사이트를 돌아다니면 웹 서저는 URL에 있는 상태 정보를 유지하는 하이퍼링크를 동적으로 생성한다.
- 웹 서버와 통신하는 독립적인 HTTP 트랜잭션을 하나의 ' 세션 ' 혹은 ' 방문 ' 으로 묶는 용도로 뚱뚱한 URL을 사용할
수 있다.
- 사용자가 웹 사이트에 처음 방문하면 유일한 ID가 생성되고, 그 값은 서버가 인식할 수 있는 방식으로 URL에 추가하여
서버는 클라이언트를 이 뚱뚱한 URL로 리다이렉트 시킨다.
- 서버가 뚱뚱한 URL을 포함한 요청을 받으면, 사용자 아이디와 관련된 추가적인 정보 ( 쇼핑 카트, 프로필 등 )를 찾아
밖으로 향하는 모든 하이퍼링크를 뚱뚱한 URL로 바꾼다.
- 이 뚱뚱한 URL을 사용해 사이트를 브라우징하는 사용자를 식별하는 데 사용할 수 있다.
※ 약점
1. 못생긴 URL
- 브라우저에 보이는 뚱뚱한 URL은 새로운 사용자들에게 혼란을 준다.
2.. 공유하지 못하는 URL
- 뚱뚱한 URL은 특정 사용자와 세션에 대한 상태 정보를 포함한다.
- 이 URL을 공유하면 당신의 누적된 개인정보를 본의 아니게 공유하게 되는 것이다.
3. 캐시를 사용할 수 없음.
- URL이 달라 진다는 것은 기존 캐시에 접근할 수 없다는 것을 의미함.
4. 서버 구하 가중
- 서버는 뚱뚱한 URL에 해당하는 HTML 페이지를 다시 그려야 한다.
5. 이탈
- 사용자가 링크를 타고 다른 사이트로 이동하거나 특정 URL을 요청해 의도치 않게 URL 세션에서 '이탈'하기 쉽다.
- 사용자는 서비스를 사용하는 동안, 사전에 세션 정보가 추가된 링크만을 사용해야 뚱뚱한 URL이 문제없이 동작
되기에 사용자가 이탈하게 되면, 지금까지의 진척 상황들이 초기화 될것이다.
11.6 쿠키
- 쿠키는 사용자를 식별하고 세션을 유지하는 방식 중에서 현재까지 가장 널리 사용되는 방식이다.
- 쿠키는 넷스케이프가 최초로 개발했지만, 지금은 모든 브라우저에서 지원한다.
11.6.1 쿠키의 타입
- 쿠키는 크게 세션 쿠키 ( Session Cookie )와 지속 쿠키 ( Persistent Cookie )로 나뉜다.
- 세션 쿠키란 사용자가 사이트를 탐색할 때 관련된 설정과 선호 사항들을 저장하는 임시 쿠키다.
세션 쿠키는 사용자가 브라우저를 닫으면 삭제된다.
- 지속 쿠키는 삭제되지 않고 더 길게 유지될 수 있다. 지속 쿠키는 디스크에 저장되어, 브라우저를 닫거나 컴퓨터를
재시작 하더라도 남아있다. 만료 시간이 지나면 세션은 파기된다.
11.6.2 쿠키는 어떻게 동작하는가
- 처음 사용자가 웹 사이트에 방문하면 웹 서버는 사용자에 대해 아무것도 모른다.
- 웹 서버는 사용자가 다시 돌아 왔을 때, 해당 사용자를 식별하기 위한 유일한 값을 쿠키에 할당한다.
- 쿠키는 임의의 이름=값 형태의 리스트를 가지고 이 리스트는 Set-Cookie 혹은 Set-Cookie2 ( 확장 헤더 ) 같은
HTTP 응답 헤더에 기술되어 사용자에게 전달한다.
클라이언트 ---- 인터넷 ----> 서버
요청 메소드
GET /index.html HTTP/1.0
Host: www.joes-Hardware.com
클라이언트 <---- 인터넷 ---- 서버
응답 메소드
HTTP/1.0 200 OK
Set-Cookie: id="34294"; domain="joes-hardware.com"
클라이언트 ---- 인터넷 ----> 서버
요청 메소드
GET /index.html HTTP/1.0
Host: www.joes-Hardware.com
Cookie: id="34294"
- 서버는 이 쿠키 값으로 사용자의 정보 ( 구매 내용, 주소 정보 등 )를 찾는 데 사용할 수 있다.
- 브라우저는 서버로 온 Set-Cookie 혹은 Set-Cookie2 헤더에 있는 쿠키 콘텐츠를 브라우저 쿠키 베이터베이스에
저장한다. 사용자가 같은 사이트를 방문하면 브라우저는 서버가 이 사용자에게 할당했던 쿠키를 Cookie 요청 헤더에
기술해 전송한다.
11.6.3 쿠키 상자: 클라이언트 측 상태
- 쿠키의 기본적인 발상은 브라우저가 서버 관련 정보를 저장하고, 사용자가 해당 서버에 접근할 때마다 그 정보를 함께
전송하게 하는 것이다.
- 브라우저는 쿠키 정보를 저장할 책임이 있는데 이 시스템을 ' 클라이언트 측 상태 ' 라고 한다. 쿠키 명세에서 이것을
' HTTP 상태 관리 체제 '이다.
11.6.4 사이트마다 각기 다른 쿠키들
- 브라우저는 수백, 수천 개의 쿠키를 가지고 있지만 쿠키 전부를 모든 사이트에 보내지 않는다.
- 보통 브라우저는 쿠키를 생성한 서버에게만 쿠키에 담긴 정보를 전달한다.
※ 쿠키 Domain 속성
- 서버는 쿠키를 생성할 때 Set-Cookie 응답 헤더에 Domian 속성을 기술해서 어떤 사이트가 그 쿠키를 읽을 수 있는지
제어할 수 있다.
Set-Cookie: user="mary17"; domain="airtravelbargains.com"
브라우저가 user="mary17" 이라는 쿠키를 .airtravelbargains.com 도메인을 가지고 있는 모든
사이트에 전달한다는 의미다.
만약 사용자가 www.airtravelbargains.com나 specials.airtravelbargains.com 같이 .airtravelbargains.com로
끝나는 사이트를 방문하면 다음 Cookie 헤더가 항상 적용될 것이다.
Cookie: user="mary17"
※ 쿠키 Path 속성
- 웹 사이트 일부에만 쿠키를 적용할 수 있는데 URL 경로의 앞부분을 가리키는 Path 속성을 기술해 해당 경로에 속하는
페이지에만 쿠키를 전달한다.
Set-cookie: pref=compact; domain="airtravelbargains.com"; path=/autos/
만약 사용자가 http://www.airtravelbargains.com/specials.html에 접근한다면
Cookie: user="mary17" 만 얻게되고
http://www.airtravelbargains.com/autos/cheapo/index.html로 접근하면
Cookie: user="mary17"
Cookie: pref=compact를 얻게된다.
- 위의 예시는 자동차를 대여하는 홈페이지에 자동차 크기를 기록하기 위한 쿠키 활용법이다.
=> 쿠키는 일종의 상태 정보라고 할 수 있으며, 서버가 생성하여 클라이언트에 전달하고, 클라이언트는 그 쿠키를 유효한
사이트에만 다시 전달하고 관리한다.
HTTP 완벽 가이드 : 네이버 도서
네이버 도서 상세정보를 제공합니다.
search.shopping.naver.com