2. 클라이언트 식별
http는 익명으로 사용하며 상태가 없고 요청과 응답으로 통신하는 포로토콜이다.
서버에서 클라이언트를 식별하는 방법이 필요하다.
• 사용자 식별 관련 정보를 전달하는 HTTP 헤더들
• 클라이언트 IP 주소 추적으로 알아낸 IP 주소로 사용자를 식별
• 사용자 로그인 인증을 통한 사용자 식별
• URL에 식별자를 포함하는 기술인 뚱뚱한 URL
• 식별 정보를 지속해서 유지하는 강력하면서도 효율적인 기술인 쿠키
3. HTTP 헤더
User-Agent 요청 사용자의 브라우저
Referer 요청 사용자가 현재 링크를 타고 온 근원 페이지
Authorization 요청 사용자 이름과 비밀번호
Client-IP 확장(요청) 클라이언트의 IP 주소
X-Forwarded-For 확장(요청) 클라이언트의 IP 주소
Cookie 확장(요청) 서버가 생성한 ID 라벨
From 요청 사용자의 이메일 주소
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/
537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36"
4. 클라이언트 IP 주소
• IP 주소는 사용자보다는 컴퓨터를 가리킨다.
• ISP가 사용자의 IP를 동적으로 변경할 수 있다.
• NAT(Network Address Translation) 방화벽을 통해 사용하면 실제 IP주소를 알 수 없다.
• HTTP 프락시와 게이트웨이가 껴있을 경우 서버는 클라이언트의 IP 대신 프락시의 IP를 본다. (확
장 헤더를 통해 해결은 가능하다)
초기에는 IP를 개인 식별에 사용하려고 했지만, IP 고갈 문제에 맞물려 하나의 IP를 여러 사용자가
사용할 수 있어서 식별하기에는 맞지 않다.
6. 뚱뚱한 URL
URL에 사용자 정보를 포함하는 방식.
어떤 웹사이트는 URL에 개인 식별 값을 포함하는 경우가 있었는데, 더이상 이런 방법을 고려하지 않는다.
단점으로는 너무 긴 URL, 공유하지 못하는 URL, 캐시 사용 불가, 서버 부하 가중
7. 쿠키
쿠키는 사용자를 식별하고 세션을 유지하는 방식 중 가장 널리 사용하는 방식이다.
세션 쿠키: 브라우저 창이 닫히면 사라짐
지속 쿠키: 컴퓨터가 재시작 하더라도 남아 있다.
Set-Cookie: name=value [; expires=date] [; path=path] [; domain=domain] [;
secure] Cookie: name1=value1 [; name2=value2] ...
8. 쿠키
TMI
크롬의 경우 SQLite로 쿠키를 관리하고, IE의 경우는 디렉토리에서 파일로 관리한다.
지금 사용하고 있는 쿠키는 넷스케이프가 개발하였고, Version 0을 사용하고 있다.
Version 1 쿠키도 있었지만 지금은 폐기 됐다.
