[HTTP 완벽 가이드] HTTP가 사용자를 식별하는 데 사용하는 기술

공부한 내용을 정리한 글입니다 
내용에 오류가 있거나 더 좋은 의견이 있다면 댓글로 남겨주세요.
배움에 큰 도움이 됩니다. 🖋

 

 

HTTP가 사용자를 식별하는 데 사용하는 기술

---

HTTP는 원래 익명의 상태 없는 프로토콜이지만, 서비스를 제공하는 입장에서는 사용자에 대해 더 많은 것을 알고싶어 하고 사용자들이 브라우징하는 것을 기록하고 싶어한다. 서비스 제공자는 이를 위해 사용자 개인화와 활동 추적을 위한 다양한 기술과 방법을 사용하고 있는데, 이 글에서는 서버가 통신 대상을 식별하는데 사용하는 기술을 알아보고자 한다.

 

 

HTTP 헤더

---

 

헤더 이름	헤더 타입	설명
From	요청	사용자의 이메일 주소
User-Agent	요청	사용자의 브라우저
Referer	요청	사용자가 현재 링크를 타고 온 근원 페이지
Authorization	요청	사용자 이름과 비밀번호
Client-ip	확장(요청)	클라이언트의 ip 주소
X-Forwarded-For	확장(요청)	클라이언트의 ip 주소
Cookie	확장(요청)	서버가 생성한 id 라벨

 

 

From 

이상적으로는 사용자가 서로 다른 이메일 주소를 가지므로 From 헤더로 사용자를 식별할 수 있지만, 악의적 서버가 이메일 주소를 모아 스팸 메일을 발송하는 문제가 있어 From 헤더를 보내는 브라우저는 많지 않다. 데이터를 수집하는 로봇이나 스파이더의 경우는 데이터 수집 과정에서 본의 아니게 웹 사이트에 문제를 일으킬 수도 있으므로, 그럴 때 해당 사이트 측에서 항의 메일을 보낼 수 있도록 From 헤더에 이메일 주소를 기술한다.

User-Agent

사용자가 쓰고 있는 브라우저명, 버전 정보를 서버에게 알려준다. 경우에 따라 운영체제 정보를 포함하는 곳도 있다.

특정 브라우저에서 제대로 동작하도록 콘텐츠를 최적화하는 데 유용할 수 있다.

 

Referer

사용자가 현재 페이지로 유입하게 한 웹페이지의 URL. 사용자의 웹 사용 행태나 사용자의 취햐을 더 잘 파악할 수 있다.

 

보다시피 위의 헤더로 사용자를 식별해 내기에는 쉽지 않아보인다. 좀 더 다양한 방법을 알아보자.

 

 

 

클라이언트 IP 주소

---

초기 웹 선구자들은 사용자 식별에 클라이언트 IP 주소를 사용하려 했으나, 다음과 같은 한계점을 만나게 된다.

 

• 여러 사람이 사용하는 공용 컴퓨터일 경우 한 사람으로 특정할 수 없다
• 인터넷 서비스 제공자(ISP)는 사용자가 로그인하면 동적으로 IP주소를 할당하기에 사용자는 매번 다른 주소를 받는다
• 사용자가 네트워크 주소 변환(Network Address Translation, NAT) 방화벽을 통해 인터넷을 사용하면 NAT 장비들이 클라이언트의 실제 IP주소를 방화벽 뒤로 숨기고 내부에서 사용하는 하나의 방화벽 IP주소로 변환한다
• HTTP 프록시와 게이트웨이는 원 서버에 새로운 TCP 연결을 하는데, 이 때 웹 서버는 클라이언트 IP주소 대신 프록시 서버의 IP주소를 보게 된다.

 

 

 

사용자 로그인

---

사용자가 로그인한 후 모든 요청의 Authorization 헤더에 인증 토큰을 포함해 서버로 전송할 수 있다. 서버는 이 인증 토큰을 검증해 사용자 신원을 확인하고 요청을 처리하거나 거부할 수 있다.

 

 

 

뚱뚱한 URL

---

사용자의 상태 정보를 포함하고 있는 URL을 뚱뚱한 URL이라 한다.

아래는 아마존의 뚱뚱한 URL 예시이며, 사용자에게 할당된 식별번호(여기서는 002-1145265-8016838)를 각 URL 뒤에 붙여 사용자를 추적한다.

 

<a href="gttp://amazon.com/exec/varzea/tg/armed-forces/-//ref=gr_af/002-1145265-8016838">Salute Our Trrps</a>

 

 

사용자가 웹 사이트에 처음 방문하면 동일한 ID가 생성되고, 그 값은 서버가 인식가능한 방식으로 URL에 추가 되며, 서버는 클라이언트를 이 뚱뚱한 URL로 리다이렉트 시킨다. 서버가 뚱뚱한 URL을 포함한 요청을 받으면, 사용자는 아이디와 관련된 추가 정보(쇼핑 카트, 프로필 등)를 찾아서 밖으로 향하는 모든 하이퍼링크를 뚱뚱한 URL로 바꾼다. 그러나 이 URL에는 다음 같은 한계점이 있다.

 

• 세션 간 지속성의 부재 : 사용자가 해당 뚱뚱한 URL을 북마크하지 않는 이상, 로그아웃 시 모든 정보를 잃는다
• 이탈 : 사용자가 링크를 타고 다른 사이트로 이동하거나 특정 URL을 요청하면 뚱뚱한 URL 세션에서 이탈되기 쉽다
• 서버 부하 가중 : 서버는 뚱뚱한 URL에 해당하는 HTML 페이지를 다시 그려야 한다
• 캐시 사용 불가 : URL이 달라지기 때문에 기존 캐시에 접근할 수 없다
• 공유할 수 없는 URL : 개인정보가 포함된 URL이기 때문에 다른 사람에게 공유 시, 본의아니게 개인정보를 노출하는 셈이 된다
• 혼란스러운 URL : 브라우저에서 사용자들이 봤을 때 혼란스러울 수 있다

 

 

 

쿠키

---

쿠키는 서버가 사용자에게 "안녕, 내 이름은.."이라 적어 붙이는 라벨 스티커와 같다. 이 스티커는 HTTP 응답 헤더 Set-cookie를 통해 붙혀지고 사용자에게 전달한다.

 

이러한 쿠키는 사용자를 식별하고 세션을 유지하는 방식 중 현재까지 가장 널리 사용되는 방식이다. 쿠키를 사용하면 앞의 기술들이 가진 문제점들을 겪지는 않지만 쿠키만으로 하기 힘든 작업에는 해당 기술들을 함께 사용하기도 한다.

쿠키는 캐시와 충돌할 수 있어 대부분의 캐시나 브라우저는 쿠키에 있는 내용물을 캐싱하지 않는다.

 

 

 

참고

---

https://www.yes24.com/Product/Goods/15381085

HTTP 완벽 가이드 - 예스24