HTTP 프로토콜을 정리하려고 마음 먹을때만 해도, 금방 끝날거라 생각했었는데, 내가 알고 있는 지식을 다시금 확인하는 과정을 거치고, 이를 글로 잘 표현한다는 것이 대단히 어려운 일인 듯 싶다.
어렵고 조심스러운 가장 큰 이유는.. 전문적인 내용을 주제로 다른 사람과 내용을 공유하려다 보니, 일단, 설명을 잘 해야된다는 그런 부담감이 항상 있기 때문이다.
설명이 부족하거나 틀린 내용이 있다면, 댓글로 의견을 주시길 바란다.
일단, 시작을 했고.. 중간부분까지 왔으니.. 마무리를 멋지게 하고픈 욕심이 생긴다. ㅎㅎ
자.. 내용 각설하고... 오늘은 아래 5가지 헤더에 대한 이야기를 해 보려한다.
- Set-Cookie
- Age
- WWW-Authenticate
- Proxy-Authenticate
- Authentication-Info
1. Set-Cookie
쿠키(Cookie)는 서버에서 클라이언트에게 제공하는 작은 정보로써, 상태연결 유지 프로토콜이 아닌 HTTP 의 한계(Stateless Protocol)를 극복하게 해 주는 고마운 녀석이다.
웹서버가 제공하는 쿠키 정보를 클라이언트(웹브라우져)는 자체적으로 저장하고 있다가 같은 웹사이트에 다른 요청을 하는 경우 이 쿠키 정보를 같이 제공하여 웹서버로 하여금 같은 클라이언트임을 확인할 수 있게 해준다.
앞서 강좌에서도 말했지만, 쿠키가 있기 때문에 우리는 다음(www.daum.net)이나 구글, 네이버등 웹사이트에 로그인 하게 되면 이후 요청에 대해서 추가적인 로그인 절차 없이 로그인 정보를 유지할 수 있는 것이다.
웹서버가 클라이언트에게 고유한 정보등을 쿠키 정보로 전달하는데 바로 이때 사용되는 응답헤더가 "Set-Cookie" 인 것이다.
다음 캡쳐 이미지를 살펴보자. 실제 사용되는 Set-Cookie 헤더 정보이다.
최초 요청에서 보면..
클라이언트의 처음 요청에 웹서버가 Set-cookie 를 이용해서 쿠키를 발행함을 확인 할 수 있다.
이후 요청에서 보면..
클라이언트는 서버가 발행한 쿠키를 자신의 디스크에 저장해 놓고, 다음 요청부터 같은 웹서버에 접속하려 하는 경우 이를 사용한다.
상태유지 기능이 없는 프로토콜인 HTTP 에서 이를 보완하여 활용할 수 있도록 한 것이 바로 쿠키이고, 웹서버와 클라이언트가 쿠키를 어떤 형태로 주고 받는지 확인 하였다.
다음은 동작 흐름으로 간단히 정리한 것이니 참고하자.
참고: Set-Cookie2 라는 응답헤더도 있다. Set-Cookie 와 마찬가지로 웹서버가 클라이언트에게 제공하는 쿠키 정보를 전달할때 사용하는 헤더이지만 Set-Cookie 로 부족함이 없어서 현재는 거의 사용되지 않는다.
2. Age
Age 헤더는 응답헤더이며, 캐시서버가 자신이 캐싱하고 있는 컨텐츠가 서비스할 수 있는 상태인지 아닌지를 판단하는데 사용하는 정보이다.
Age 헤더는 값으로 숫자를 사용하며, 숫자의 단위는 초(Second) 이다.
캐시서버가 컨텐츠를 저장(캐싱)한 이후 해당 컨텐츠가 캐시서버내에서 머무른 시간이라고 이해하는게 좋겠다.
Age 헤더의 값이 작다는 것은 캐싱된 컨텐츠가 캐시서버에 저장된 후 오래되지 않았다는 것이고 크다는 것은 오래되었다는 것을 의미한다. 때문에 Age 값이 작은 컨텐츠는 실제 서버에서 여전히 사용하고 있을 확률이 높다는 것이고, 값이 큰 컨텐츠는 실제 사용되는 컨텐츠인지 확인이 필요한 것을 의미한다고 볼 수 있다.
뭐.. 그렇다고 Age 값이 크다고 부정적으로만 생각할 필요는 없다.
캐시서버내에 오래 머물렀다고 해서 서비스 하기에 부적절한 컨텐츠라는 의미가 되는것은 아니기 때문이다.
어플리케이션 관리자나 웹서버 관리자들은 이런것들을 고려하여 Age 헤더의 최대값을 설정하게 된다. 즉, Age 값의 최대값이 갖는 의미는 최대값 동안 만큼은 캐시서버가 직접 클라이언트에게 서비스해도 좋다 라는 것을 허락한다는 뜻 인 것이다.
그렇기 때문에 빈번히 변경되는 이미지와 같은 컨텐츠들은 Age 값을 당연히 짧게 가져가야 할 것이고, 변경이 많지 않는 성격의 컨텐츠들은 Age 값을 길게 두어 캐시서버가 직접 응답할 수 있게 하는것이 서버 성능 효율면에서는 무조건 좋기 때문이다.
그렇다면 Age 헤더의 최대값은 어떻게 정해질까? 당연히 캐시서버가 독단적으로 정하진 않는다. 웹서버가 Age 헤더의 최대값을 정해서 캐시서버에게 알려준다.
바로 이때 사용되는 것이 Cache-Control 헤더이다. 응답헤더 정리가 끝나면 일반(General) 헤더를 정리할텐데.. Cache-Control 헤더는 그때 자세히 이야기 한다. 여기서는 Cache-Control 헤더를 이용해서 최대 Age 값을 알려주는구나 라고만 이해를 하자.
다음 동작 그림을 참고해 보면.. 최초 요청과 실제 웹서버가 Cache-Control 헤더를 이용해서 최대 Age 값을 알려주는 것을 나타내고 있다.
위 그림에서와 같이 실제 웹서버가 Cache-Control 헤더에 명시한 max-age 정보가 바로 Age 의 최대값이 된다.
여기서 다시 정리하면 응답과 함께 제공된 컨텐츠는 최대 600초(10분) 동안은 캐시서버가 클라이언트에게 바로 직접 제공해도 되는 것을 보장한다 라는 의미가 된다.
최초 요청 이후 동일한 컨텐츠를 다시 요청하면 이때 응답헤더에 Age 값이 붙어서 전달된다.
다음 동작 그림과 실제 패킷 데이터를 통해 확인해 볼 수 있다.
동작 그림을 간단히 설명하면.. 위 최초 요청에서 응답데이터를 보자(Step 3)
서버가 응답을 준 시간을 Date 헤더에 포함하여 주는게 그때 시간이 06:00 분이다.
클라이언트는 그로부터 1분 이후 동일 요청을 다시 한다.
캐시서버는 캐싱된 컨텐츠가 max-age 범위인 600 초 이내에 있기 때문에 직접 클라이언트에게 제공한다.
이때, 캐시서버는 Age 헤더의 값으로 60초를 기재하여 보내게 된다.
Age 의 값을 계산하는 공식이 따로 RFC 7234 문서에 기재되어 있다. 하지만, 그걸 보는 순간 머리속이 복잡해진다. 그냥 단순히 Age 헤더의 값은 컨텐츠가 캐시서버에서 저장된 후 머문 시간이라고 이해하는게 아주 쉽다.
다음 실제 패킷데이터를 보자.
패킷 데이터가 두개이다.
모두 웹서버가 클라이언트에게 전달하는 응답에 관련된 내용들이다.
최초 요청에 대한 응답에서 보면 cache-control 헤더에 max-age 값으로 600초를 알리고 있다. 다시 말하면.. 600초(10분)동안 이 컨텐츠는 신선한 것이니 직접 응답을 주도록 하라는 의미이다.
이후 29초 이후에 동일한 요청이 이루어 졌다. (14:20::50 -> 14:21:19)
응답헤더를 보면 Age 헤더가 추가되었고, 그 값으로 29가 설정되어 있다.
29초동안 캐시서버에 있었으니 매우 신선한 이미지이고, 따라서 캐시 서버에서 직접 서비스된다.
Age 헤더의 값인 600을 넘어가게 되면 어떻게 될까?
클라이언트가 최초 요청이후 610초 이후에 동일한 컨텐츠를 요청하였다면, 웹서버는 600초를 넘겼기 때문에 캐시서버는 웹서버에게 해당 컨텐츠를 다시 받아야 하는지 여부를 물어본다. 즉, 캐시서버와 웹서버간의 데이터 교환이 이루어지게 된다.
실제 웹서버에서 변경되지 않았더라도 최대값을 초과하게 되면 캐시서버는 웹서버에 클라이언트의 요청을 전달한다. 응답을 받게 되면 캐시 서버는 Age 값의 카운팅을 다시 시작한다.
3. WWW-Authenticate
웹서버의 서비스 목적에 따라 허가된 클라이언트에게만 서비스를 제공해야 하는 경우가 있다. 예컨데, 특정 부서를 위한 홈페이지등이 그럴 수 있다. 접속은 가능하지만 로그인 과정을 통해 허가된 사용자에게만 컨텐츠를 제공해야 하는 경우...
바로 이럴때 WWW-Authenticate 헤더가 사용 된다.
로그인을 통해 사용자를 구분하는 로직은 웹어플리케이션 개발자가 ASP, PHP, JSP 등의 소스 코드로 직접 구현할 수도 있지만, HTTP 프로토콜에서 제공하는 보안기능을 이용할 수도 있다.
HTTP 프로토콜을 이용하는 경우에 WWW-Authenticate 헤더가 사용된다.
이 HTTP 강좌를 처음부터 보았다면, 아마도 들어본 기억이 있을 것이다.
앞서 요청헤더 중 Authorization 헤더를 다룰 때 응답헤더로 WWW-Authenticate 를 같이 설명하였기 때문이다.
내용이 중복되기 때문에 이에 대한 내용은 다음과 같이 대신하려 한다.
Authorization 과 WWW-Authenticate 헤더의 내용을 보기 위해서는 HTTP 프로토콜 강좌 #12 를 클릭하여 확인해 보도록 하자.
참고로, HTTP 헤더에 대한 정리가 끝나면 HTTP 프로토콜에서 제공하는 보안에 대한 내용을 다루려 한다. 인증 관련된 내용은 그때 상세히 정리할 계획이니 기대 부탁드린다.
4. Proxy-Authenticate
Proxy-Authenticate 헤더는 WWW-Authenticate 헤더와 비슷하지만, 다른 점은 사용자를 인증하는 주체의 차이가 있다.
WWW-Authenticate 헤더를 이용하는 쪽은 웹서버가 클라이언트를 인증하려 할때이고,
Proxy-Authenticate 헤더는 프록시가 클라이언트를 인증할 필요가 있을때 사용된다.
클라이언트의 요청에 Proxy-Authenticate 헤더를 응답헤더에 추가하여 보내면 클라이언트는 사용자 인증을 해야 한다.
응답메시지 측면에서도 차이가 있는데..
WWW-Authenticate 헤더를 이용할 경우 "401 Unauthorized" 라는 응답메시지를 보내서 인증을 유도하는 반면,
Proxy-Authenticate 헤더를 이용할 경우에는 "407 Proxy Authentication Required" 의 상태코드를 사용한다.
다음 그림으로 간단히 둘간의 차이를 표현해 봤다.
앞서 WWW-Authenticate 헤더 설명 말미에 언급했듯이 HTTP 보안 관련 내용이기 때문에 HTTP 보안을 다룰때 다시 정리할 계획이다.
여기서는 이정도만 알고 넘어가자.. Proxy-Authenticate 헤더는 사실 이정도만 알아도 충분하긴 하다. ^^
5. Authentication-Info
사용자 인증에 대한 메시지를 교환하는 마지막 단계에.. 인증이 완료되면, Authentication-Info 헤더에 내용을 담아 웹서버는 클라이언트에게 전달한다.
성공적인 응답을 클라이언트에게 전달할 때 사용되며, 내용에는 인증 교환에 관련된 추가적인 정보를 담는다.
WWW-Authenticate.. 그리고 Proxy-Authenticate 와 마찬가지로 HTTP 보안에 관련되어 사용되는 헤더이므로, 이후 HTTP 보안에서 자세히 다루도록 하겠다.
오늘은 여기서 마무리 하려 한다.
끝!~
댓글 없음:
댓글 쓰기