[HTTP 완벽 가이드] 클라이언트 식별

HTTP 통신은 익명이며 상태가 없다. 연결 자체에 대한 정보가 없으며 매 요청은 독립적이다.

그러나 웹사이트에서는 개인화된 서비스를 제공하고자 하는 니즈가 있다.

* 쇼핑 사이트 등에서 개인화된 정보 제공- 맞춤 추천
* 사용자 정보 저장 (신용카드, 주소 등)
* 세션추적 (장바구니)

다음에서 HTTP에서 사용자를 식별하는 데 사용하는 기술을 정리한다.

HTTP 헤더

사용자에 대한 정보를 헤더에 담아서 보낸다.
사용자에 대한 정보를 전달하는 헤더에는 다음과 같은 것들이 있다.

• From: 사용자 이메일
  이상적으로는 사용자의 이메일 정보는 각각 다르므로 개인을 식별가능하다. 다만 악의적인 서버가 남의 이메일 주소를 모두 습득하여 스팸을 발송하는 케이스가 많아서 실제 brower에서 from 헤더를 보내는 경우는 별로 없음
• User-Agent: 사용자의 브라우저 정보
  브라우저 이름(Safari, Chrome, Explorer등), 버전정보, 운영체제 정보 (MacOS, Android 등)을 포함. 컨텐츠를 브라우저에 맞게 분기하는데 도움이 됨. 특정 사용자 식별에는 사용이 어려움
• Referer: 사용자가 현재 링크를 타고 온 근원
  현재 페이지로 유입된 웹페이지의 URL. 특정 사용자 식별에 사용되긴 어렵지만, 사용자의 웹 사용 형태나 취향에 대해 알 수 있다. (구글에서 검색을 잘하나? 네이버 검색파냐? 야구 홈페이지에 뜬 광고를 보고 왔나?)

하지만 위의 세가지 정보는 특정 사용자 식별에 사용할수는 없음

IP 주소

• 클라이언트의 IP는 보통 HTTP 헤더에는 없으나, 웹서버는 HTTP 요청을 보내는 반대쪽 TCP 커넥션의 IP 주소를 알 수 있다. (getpeername() 함수 등)
• 다만, 다음과 같은 한계가 있음 
  • 클라이언트 IP는 사용자가 아닌. 컴퓨터를 가르킴. 공용 컴퓨터라면 서로를 식별 불가
  • 대부분의 ISP는 IP를 동적 할장함. 로그인한 시간에 따라 사용자의 IP 주소가 달라짐
  • 보안을 위해 NAT(network address translation) 방화벽을 사용하여 실제 IP주소를 방화벽 뒤로 숩기고, 클라이언트의 IP 주소들을 방화벽 IP 주소로 변환
  • 프록시와 게이트웨이를 사용하면, 원서버에 새로운 TCP 연결을 하므로 웹서버는 클라이언트 IP 주소 대신 프록시의 IP주소를 보게됨 (일부 프록시는 원본 IP를 보존하여 확장헤더에 데이터를 저장하나, 모든 프록시가 이러한 방식을 사용하지는 않음)

위와 같은 이유로 현재는 대다수 웹사이트에서 사용자 식별에 IP주소를 사용하지 않는다.

로그인

웹서버가 사용자 이름/비번으로 로그인을 요구하여 명시적인 사용자 식별을 함.

1. 웹서버에서 401 응답코드와 WWW-Authenticate 헤더를 반환하여 사용자의 로그인을 요청
2. 사용자가 ID, PWD를 입력 후 해당 정보를 Authorization 헤더에 보냄 (암호화, 보안 등은 별도의 글에 내용 추가)
3. 이제 웹서버는 사용자를 식별가능.
   이 시점 이후의 요청에 대해서는 브라우저가 식별정보 토큰을 Authrization 헤더에 담아서 서버로 전송하여 한 세션 (브라우저가 닫힐 때까지) 이 진행되는 내내 식별을 유지한다.

하지만 단점은 매번 사이트 접속시마다 로그인이 귀찮다. 귀찮음 때문에 다른 사이트로 이탈이 가능하다.

FAT URL

어떠한 웹사이트는 사용자 URL 경로에 상태 정보를 추가한다. 이렇게 사용자의 상태 정보를 포함한 URL을 fat url 이라고 한다.
예를 들어, 각 URL 에 상점을 돌아다니는 사용자 식별번호 (대충 123-1234-5345346과 같은) 을 URL에 붙여 추적한다.
예) www.amazon.com/exec/varzea/tg/armed-forces/-// ref=gr_af_/123-1234-5345346

이렇게 하면 웹 서버와 통신하는 독립적 HTTP 트랜잭션을 하나의 세션으로 묶는 용도로 사용이 가능하다.
웹사이트 방문 시 하나의 고유 ID 를 생성하고 이 값을 서버가 인식가능하도록 URL에 추가하여, 서버는 클라로 이 fat url로 리다이렉션한다.
서버가 이 식별 가능한 URL을 받으면, 사용자와 관련된 추가정보(쇼핑카트, 프로필)을 찾아서 밖으로 향하는 모든 하이퍼링크를 fat url 로 대체한다.
다만 아래와 같은 단점이 있음

• 못생김: 사용자가 주소창 보고 혼란
• 개인정보 유출: 친구에게 와 이거 예쁘지 않냐 라고 URL 공유시 당신의 개인정보도 공유
• 캐시X: url이 다르다는건 캐시를 사용할수 없다는 것
• 서버 부하: 매번 url 리다이렉션
• 이탈: 다른 사이트 갔다오면 장바구니 사라짐
• 세션간 지속성 부재: 로그아웃 시 모든 정보잃음

따라서 위와 같은 방식 각각 단독으로는 사용자 식별에 한계점이 있다.

실제로는 로그인과 쿠키, 세션, FAT URL 등 여러가지 방식을 함께 사용해서 사용자를 식별하게 된다.

2023.02.26 - [Computer/Network] - [HTTP 완벽 가이드] 쿠키