3일동안 두녀석들과 온종일 시간을 보냈는데.. 육체는 좀 고달팠으나 나름 의미 있는 시간이었다.
휴가가 끝났으니 다시 이어서 HTTP 프로토콜 강좌를 시작한다.
오늘로 HTTP 요청헤더를 마무리 하려 한다.
1. Max-Forwards
OPTIONS나 TRACE 요청방식과 함께 사용되는 헤더이다.
클라이언트는 웹사이트에 접속을 시도했으나, 접속이 되지 않는 경우 여러가지 원인이 있을 수 있다. 그중 네트워크 통신상 오류가 존재하는 경우 Max-Forwards 를 이용하게 되면 어느정도 문제점을 파악할 수 있다.
네트워크 통신상 오류에는 다음 두가지 사례가 있을 수 있다.
첫째로, 루핑(Looping) ..
웹서버로 클라이언트의 요청이 도달하는 과정에 다수의 프록시 서버가 존재하는 경우 아래와 같이 프록시 서버간 요청 Looping이 발생할 수 있다.
두번째, 중간 서버 장애..
웹서버와 클라이언트간에 위치한 중간 프록시 서버가 장애가 나는 경우 클라이언트의 요청이 전달되지 않기 때문에 문제가 될 수 있다.
위 두가지 경우 Max-Forwards 헤더를 TRACE 와 함께 사용하게 되면 어느 지점이 문제의 포인트인지 확인과 진단이 가능하다.
Max-Forwards 는 일종의 네트워크상 문제를 확인하는 Traceroute 와 동작 방식이 비슷하다. 최초 클라이언트는 Max-Forwards 값을 '0'으로 세팅한 후 전달한다. 프록시 A는 최초 이 요청을 받게 되면, 다음 프록시 또는 웹서버에게 전달하지 않고 직접 클라이언트에게 200 OK 메시지와 함께 응답 한다.
클라이언트가 프록시 A로부터 정상 응답을 받게 되면 이 다음 요청에 Max-Forwards 값을 하나 올려서 다시 전달한다.
프록시 A는 Max-Forwards 값을 보고 '0'이 아니면 다음 프록시로 해당 요청을 전달하게 된다. 전달할 때 Max-Forwards의 값을 하나 감소하여 보내는데 이때 프록시 A는 via 헤더에 자신의 정보를 기록한다.
프록시 B는 Max-Forwards의 값이 '0'임을 확인하고 클라이언트에게 직접 응답을 하는데, 응답 메시지의 Via 부분에 요청이 거쳐간 모든 경로를 기록한다.
클라이언트는 이 응답 내용을 가지고 중간 프록시 서버의 Looping 여부를 파악한다.
다음 Looping 의 예를 보자.
위 예에서 1~4 까지는 요청이고, Max-Forwards 의 값이 '0'이 된 4번 요청 이후부터 그러니까 5~8 까지는 응답이다.
예에서 볼수 있듯이 Max-Forwards 를 통해 무한 Looping 을 방지 하고, Max-Forwards 값이 '0'이 된 이후 정상 응답 메시지를 통해 Looping 이 발생되는 지점을 확인 할 수 있다.
클라이언트 A가 받은 메시지의 내용을 보면, proxyA가 최초 그리고 제일 마지막.. 이렇게 2번 기록되어 있기 때문에 A -> B -> C -> A 와 같은 구조라는 것을 우리는 알 수 있다.
Looping 구조 외에 우리는 클라이언트의 TRACE 요청에 아무런 응답이 없는 경우.. 중간 서버 Fault 로 예측해 볼수 있다.
다음 예를 살펴보자.
프록시 C가 장애가 생긴 경우에는 프록시 B로부터 받은 클라이언트의 요청을 다음 단계로 전달하지 못한다. 클라이언트는 Max-Forwards 값을 통해 어느 지점의 프록시 서버 장애인지 확인 가능하다. Max-Forwards 값이 '0'인 경우 정상 응답이 오면 그 지점까지는 문제 발생이 없다고 판단할 수 있기 때문이다.
위 예에서 클라이언트가 Max-Forwards 값을 3이 아닌 1로 설정하여 보냈다면, 프록시 B의 정상 응답을 받을 수 있기 때문에 장애 지점을 프록시 C로 판단할 수 있는 것이다.
2. Proxy-Authorization
프록시 서버는 캐시서버로써 웹서버의 성능 향상을 위해 사용되기도 하지만 사용자들의 인터넷접속 환경에 대한 보안을 위해서도 사용되어진다.
프록시 서버는 사용환경 또는 구축환경에 따라 리버스 프록시 (Reverse Proxy) 혹은 포워드 프록시 (Forward Proxy) 로 구분되어 진다.
리버스 프록시는 오로지 목적이 "웹서버의 성능 향상"이다.
프록시가 웹서버 앞단에 위치하여 다수의 클라이언트들의 요청을 먼저 처리함으로써 웹서버의 성능 향상을 도모한다.
프록시가 클라이언트 앞단에 위치하여 인터넷으로 나가는 관문의 역할을 한다.
Proxy-Authorization 은 포워드 프록시 환경에서 사용될 수 있는 헤더라 하겠다.
어느 회사에 인터넷 관문에 프록시 서버가 있다고 하자. 회사 임직원들은 프록시를 통해서만이 인터넷 접속이 가능하다. 보안 담당자는 직원별로 프록시의 접속을 통제하여 인증받지 못한 직원은 인터넷을 불가하게 하려 한다.
바로 이럴때 프록시에 사용자의 인증이 필요하고, 인증을 수행할 때 Proxy-Authorization 헤더를 이용할 수 있는것이다.
HTTP 보안에 대해서는 헤더 강좌가 끝나면 상세하게 다뤄 보려 한다. 자세한 내용은 우리 그때 다시 이야기 하기로 한다.
3. Referer
우리가 구글, 네이버, 다음 등에서 특정 문자열을 검색하게 되면 잠시 후 검색 결과를 화면에 표시해 준다. 사용자들은 자신이 원하는 내용의 페이지가 있을 경우 그 결과물을 클릭하여 해당 웹사이트로 이동하게 된다.
바로 이때, 사용자가 검색결과를 클릭하여 이동할때 어디로부터 이동되었는지에 대한 정보를 표시해 주는 곳이 있는데 바로 그게 Referer 이다.
우리는 이 정보를 여러 방면에서 활용할 수 있다.
예를 들면.. 특정 웹사이트에서 사용자들의 접속경로를 알아 보고 싶다.
접속 사용자들이 네이버나 다음, 구글에서 검색 해본 후 온것인지? 아니면 직접 입력해서 찾아온것인지? 아니면 다른 사이트에 소개되어 있어서 그걸 클릭하고 온것인지? 등등
전혀 불가능할 것 같지만.. 바로 Referer 헤더가 있어서 .. 이런 통계 데이터를 뽑아 보는게 가능하다.
다음은 실제 Referer 헤더 정보이다.
다음(www.daum.net) 에서 "LG전자" 를 검색한 후 검색된 LG전자 홈페이지를 클릭하였을때 HTTP 요청 헤더 정보이다.
Referer 헤더에 보면 search.daum.net 이 보인다. 바로 Daum을 통해 LG전자 홈페이지(www.lge.co.kr)에 접속했음을 우리가 알수 있다.
내가 접속하는 웹사이트를 어느 곳을 통했는지 확인 할 수 있는 것이 바로 Referer 헤더이다.
4. TE
TE헤더는 클라이언트가 지원하는 전송인코딩(Transfer-encoding) 방식을 웹서버에게 알리기 위해 사용된다. Accept-Encoding 헤더와 매우 비슷하지만, Accept-Encoding은 컨텐츠에 대한 인코딩 방식을 이야기하는 것이고, TE 헤더는 전송인코딩 방식에 대한 것이다.
TE 헤더의 값은 다음과 같다. Accept-Encoding 방식에서 사용되었던것과 아주 유사하다.
TE: gzip, deflate;q=0.8
위 예에서 보면 gzip 이 우선순위가 높기 때문에 deflate 보다 먼저 선택되어진다.
(q 값은 퀄리티를 의미하며, 값이 생략된 경우는 '1' 의 값을 가진것과 같다.)
만약 Chunked 를 지원함을 나타내기 위해서는 다음과 같이 TE 헤더에 Trailers 라는 값만 표시하면 된다.
TE: Trailers
이상 끝!
여기까지 요청헤더에 대한 내용 정리를 마치고 다음에는 응답헤더에 대한 내용을 정리한다.
댓글 없음:
댓글 쓰기