HTTP - (15) 로깅과 사용자 추적

대부분의 서버와 프락시는 HTTP 트랜젝션이 일어났던 히스토리에 대해 로그를 남겨둔다.

사용 추적이나 보안 혹은 통계를 집계하기 위한 용도로 사용된다.

​

일반적으로 로깅하는 정보는 아래와 같다.

- HTTP 메서드

- 요청받은 리소스의 URL

- 응답 HTTP 상태 코드

- 요청과 응답 메시지 크기

- 트랜잭션 발생 시간

- Referer, User-Agent 값

​

로그 포맷에는 여러 표준이 있는데, 대표적인 포맷에 대해서만 살펴보자.

* 일반 로그 포맷 : 가장 많이 사용되는 일반적인 포맷이고, 아래와 같은 구성요소들이 있다.

- remotehost : 요청한 호스트명 혹은 IP주소

- username : 인증된 요청자 이름

- auth-username : 인증을 수행했을 경우 인증된 요청자 이름

- timestamp

- request-line : HTTP 요청 행 그대로를 기록

- response-code : 응답 상태코드

- response-size : 응답 엔터티의 크기

​

* 혼합 로그 포맷

아파치 등이 지원하는 로그 포맷으로 일반 로그 포맷과 매우 유사하다. 몇 가지만 추가되었다.

- Referer : referer http헤더 값

- user-agent : user-agent referer http헤더 값

​

* 넷스케이프 확장 로그 포맷

주로 프락시와 관련된 정보들을 추가로 기록할 수 있도록 하였다.

- proxy-response-code

- proxy-response-size

- client-request-size

- proxy-request-size ...

​

---

서버는 로그를 저장하여 콘텐츠 제공자에게 각 리소스 별 접근량과 광고 노출량 등에 대한 통계를 제공한다.

대부분 클라이언트와 서버 사이에 있는 캐시에서 요청과 응답이 처리되는데, 이 때는 로그 누락이 발생된다.

몇몇 콘텐츠 제공자는 이 때문에 중요 페이지의 경우 캐시되지 않도록 설정해두기도 한다.

이를 해결하기 위해 서버와 캐시 간에 접근 통계를 공유할 수 있도록 새로운 방법이 고안되었다.

​

적중 계량 규악이라는 것인데, 캐시와 서버가 접근 정보를 공유하고 서버가 원하는 통계 정보를 받아볼 수 있도록 해준다.

Meter 헤더가 추가되어 사용량 보고나 재사용 횟수 등에 대한 정보를 제공하도록 되어있다.

하지만 이 방법은 널리 사용되지 않고, 미래에도 그럴 것이다. 완벽한 해결책이 아니기 때문이다.

​

로깅은 여러 유용한 기능을 하기도 하지만, 동시에 사용자의 개인정보 보호에 대해서도 신경써야한다.

사용자는 개인의 행위가 모두 로깅되고 있다는 것을 모르고 있기 때문에 개발자와 관리자가 유념하고 보호에 많은 노력을 기울어야할 것이다.

---

15편의 장편 시리즈로 HTTP에 대한 개괄적인 공부를 해보았다.

HTTP 프로토콜의 메시지가 어떻게 요청/응답되는지, 어떤 방식으로 통신하는지에 대해 알아볼 수 있었고,

서버와 클라이언트, 프락시, 캐시, 게이트웨이 등 메시지의 송신자/수신자 주체에 대해서도 각 역할과 차이를 살펴볼 수 있었다.

요즈음의 인터넷 사용 목적은 대부분 웹 어플리케이션 사용이기 때문에, 이번 글을 통한 학습이 앞으로 많은 도움이 될 것 같다.

---

참고도서

https://book.naver.com/bookdb/book_detail.nhn?bid=8509980