Advanced WWW Server AdministrationAdvanced WWW Server AdministrationWWW 서비스가 1992년에 첫선을 보인 이래 1993년에 모자익이 등장하고 1994년에 넷스케이프가 (개발사 측에서는 '모질라'라고 발음해주길 원하지만 국내에서는 통상 '넷스케이프'라고 불리운다) 등장하면서 WWW 서비스는 인터넷을 휘어잡을 것처럼 사용자들 사이에 돌풍을 일으키기 시작하였다. WWW는 인터넷에 존재하는 많은 응용 소프트웨어 가운데 하나이고 여기서 사용하는 HTTP 프로토콜도 TCP/IP 프로토콜 스택에서 응용계층에 해당하는 프로토콜에 지나지 않을 뿐인데, 이제는 WWWW가 곧바로 인터넷을 말하는 것으로 오인되기도 하고 인터넷의 대명사로 지칭될 정도에까지 이르르게 되었다.
이것이 가능하게 된 이유에는 여러가지 꼽을 수가 있으나, 크게 살펴 보면, 손쉽게 웹브라우저를 사용할 수 있다는 것과 웹서버의 설치가 아주 수월했다는 것 두 가지로 볼 수가 있다. 초보자라 할지라도 웹브라우저의 사용법은 너무나 수월하여 마우스만 있으면 사용이 가능하였고 (처음 나온 92년에 웹은 별 인기를 끌지 못하였으나 93년에 모자익이 나오면서 사용자들의 폭발적 반응이 나타나기 시작하였다) 관심을 가지게 된 초보자도 손쉽게 자신의 서버를 만들어서 인터넷에 서비스를 개시할 수 있게 되자, 서로 상승 작용을 일으켜 오늘의 인터넷 대명사가 된 것이다.
이렇게 하여 지금 전세계 인터넷에 존재하는 웹 서버의 갯수는 얼마나 될까? 수만개? 수십만개? 직접 헤아려 보시라! :) 지난 1월에 Yahoo에서 조사한 자료로는 약 45,000개 정도이다.
그러면 여러가지 서버 소프트웨어들 가운데 어떤 것이 가장 많이 쓰이고 있을까 하는 질문도 가져볼 수 있다. 이에 대해 조사한 자료가 있다. 이 결과에 따르면, 가장 많이 쓰이고 있는 서버 소프트웨어는 NCSA, Apache, Netscape, CERN 등의 순서이며, 조사를 수행한 Paul은 지난 해 9월에 같은 조사를 벌여 금년 1월에 실시한 조사와 비교해볼 때, Netscape의 점유율이 불과 4개월 사이에 8%에서 13%로 증가하였고 많은 사람들이 NCSA와 CERN에서 Apache로 옮겨가는 추세에 있으며 NCSA 서버와 형제간이라 할 수 있는 Apache와 NCSA 서버를 합치면 점유율 60%로서 비슷한 수준을 유지하고 있다고 하였다. 1792개의 조사 결과에 대한 주요 결과가 다음에 보이고 있다. [Hoffman 96]
Server Count Pct NCSA 732 41% Apache 305 17% CERN 198 11% Netscape-Commerce 111 7% Netscape-Communications 101 6% WebSTAR/MacHTTP 101 6% WebSite 73 4%
국내의 경우에 대해서는 충남대 이강찬씨가 조사한 자료가 있다. 352개의 서버에 대한 조사 자료에 따르면 아래와 같다. [KangChan 96]
Server Count Pct NCSA 219 62.2% CERN 62 17.6% Netscape 40 11.4% Apache 14 4.0% WebSite 6 1.7%
여기서는 국내에서 가장 많이 쓰이고 있는 두 가지 서버 소프트웨어에 대해 활용 가치가 있으나 잘 쓰이지 않고 묻혀져 있는 주요 기능들을 살펴보고, 편리하고 효율적인 서버 관리의 방안을 찾아보기로 한다.
2장에서 설명하는 특징들은 겉으로 드러나는 몇 가지를 나열했을 뿐이며, HTTP/1.0 프로토콜에 따라 지원해야 할 기본적인 기능들은 유사하며, 다만 서버 관리에 있어서의 편리성 측면에서 상이한 차이점들이 있다. 이 문서의 목표는 서버 관리에 있어서의 효율성과 편리성 측면에서 각각의 서버 소프트웨어가 제공하는 기능들을 살펴보고자 하는 것이다.
NCSA(National Center for Supercomputing Applications)는 미국 Urbana Champaign 소재 일리노이 대학교에 자리잡은 슈퍼컴퓨팅 관련 응용을 연구하는 국립연구기관이다. 모자익을 제작, 배포한 것으로 유명한 이 기관에서 만든 웹 서버 소프트웨어의 특징은 다음과 같다.
CERN은 스위스에 있는 유럽 핵물리 연구기관으로서 World Wide Web 프로젝트가 시작된 곳이다. 여기서 만들어진 웹 서버의 특징은 다음과 같다.
이것은 NCSA HTTPd 1.4 버전부터 지원되는 기능이다.
이전의 프로그램에서는 HTTPd 데몬을 Standalone과 Inetd 형식의 두 가지로 동작하게끔 하였는데, Standalone 방식에서는 하나의 프로세스가 (HTTPd 데몬) 존재하고 있다가 사용자의 요구가 들어오면 fork를 통해 child process를 만들어서 이것이 사용자 요구를 처리하게 한 것이고, Inetd 방식에서는 inetd라고 하는 프로세스가 있다가 사용자의 요구가 들어면 fork가 아니라 완전히 새로운 HTTPd 프로세스를 생성시켜서 처리하도록 한 것이다. 따라서 fork를 통해 만들어진 프로세스는 parent process가 최초에 생성될 때 화일 시스템으로부터 이미 읽혀져 있는 정보를 전달받게 되고, inetd를 통해 생성된 프로세스는 화일 시스템으로부터 새로 필요한 정보를 읽어야 하므로, inetd 방식으로 동작할 때 성능상의 저하를 만나게 된다. 그래서 standalone 방식으로 동작시킬 것을 권고하고 있다.
이렇게 standalone 방식으로 동작한다 할지라도 서비스 요구가 많은 서버를 관리할 때는 fork를 통해 child process를 여러 번 만든다는 것은 상당한 부담이 된다. 이를 개선하기 위해 1.4 버전부터는 pre-forking model을 도입하여 일정 갯수의 HTTPd 서버 프로세스를 미리 생성시켜 놓은 것이다. 이 상태에서 사용자 요구가 들어오면 미리 생성시켜 놓은 child process 하나에게 요구에 대한 처리를 맡기도록 한다. 동시에 수행하는 사용자의 요구가 많아서 미리 생성시킨 프로세스 갯수를 초과할 때는 새로이 fork를 통해 child process를 생성시키면 된다.
많은 사용자가 방문하여 정보 서비스 요구가 빈번하게 일어나는 서버는 NCSA HTTPd가 제공하는 Pre-Forking Model을 이용함이 성능 개선에 도움이 된다. 이의 사용법은 httpd.conf 화일 속에 있는 StartServers와 MaxServers 변수에 프로세스 갯수를 지정하면 된다. 즉, 다음과 같다.
StartServers 5 MaxServers 20
서버에 축적되는 logging 화일에서 1분 정도의 시간 동안에 동시에 서비스를 제공하는 빈도를 살펴보고 이 횟수만큼 StartServers 갯수를 지정해 놓는다면 서버가 동작하는 동안에 fork를 통한 시스템 부하를 줄이고 또한 성능의 개선을 도모할 수가 있는 것이다. StartServers는 최초에 몇 개의 HTTPd 프로세스를 생성시켜 놓을 것인가 지정하는 것이고 MaxServer는 서비스를 제공하는 동안 최대 몇 개의 프로세스를 생성 가능하게 할 것인가 지정하는 것이다. 최대 갯수 제한은 HTTPd 프로세스에 의해 시스템에 지나친 부하를 주지 않기 위한 배려이다. 이 갯수를 넘어서는 사용자 요구가 동시에 들어와서 생성된 최대 갯수 프로세스가 모두 소진된 경우라면 최개 갯수를 넘어서 요구하는 사용자 요구는 처리되지 않고 서비스 거부로 돌아오게 된다.
만약 이것을 사용하지 않고 기존의 경우처럼 사용하겠다면 두 가지 변수 모두 0으로 지정하면 되겠다.
이 말은 서버에 저장되어 있는 HTML 화일 속에 어떤 실행 프로그램의 결과나 특정의 화일을 포함할 수 있다는 말이다. 예를 들어, 자신이 작성한 문서가 10개 있다고 할 때 각 문서의 끝부분에 문서 작성자에 대한 설명이 들어가 있다고 하자. 만약 전화번호가 바뀌어서 고치고자 한다면 10개 문서 전부를 고쳐야 할 상황이 될 것이다. 그러므로 자신에 대한 정보를 담은 조그만 화일 하나를 만들어 두고, 10개의 문서에서 마지막 부분에 이 화일을 Server Side Include를 이용하여 include를 하면 작성자 정보를 담은 화일 하나만 고치면 손쉽게 해결될 것이다. 마찬가지로 어떤 실행 프로그램의 결과도 추가해서 넣을 수 있다.
그런데 이것은 그만큼의 위험성과 성능의 저하를 유도하고 있으므로 유의해야 한다. 이 기능을 이용한다는 것은 서버가 단순히 HTML 화일을 전송하는 정도에서 끝나는 것이 아니라, HTML 화일을 parsing 해서 SSI에서 지정하는 것을 처리해야 하므로 성능상의 부담을 유발하고 있고, 서비스를 요구하는 사용자에게 서버 사용자로서 프로그램 실행을 가능케 하는 역할을 하고 있으므로 시스템 보안상의 위험을 유발케 하고 있다. 따라서 SSI 기능을 사용하고자 할 때는 이 점을 심각히 고려하여야 한다.
3.2.1 SSI 환경 설정
이렇게 parsing의 대상이 되는 화일의 명시는 MIME 형식으로 지정하여 서버에게 알려줄 수 있다. 다음과 같으며, srm.conf 속에서 정의한다.
AddType text/x-server-parsed-html .shtml
만약에 서버의 성능에는 상관없이 모든 html 화일을 parsing의 대상으로 삼고자 한다면 다음과 같이 하면 된다.
AddType text/x-server-parsed-html .html
SSI 형식을 이용하여 Includes 기능을 이용하거나 프로그램 실행을 통하여 결과를 문서 속에서 활용하고자 할 때, 다음과 같은 방식으로 활용한다.
command 부분에 올 수 있는 것들과 각 attribute로 올 수 있는 것들은 다음과 같다.
하나의 서버 컴퓨터에 두 개 이상의 IP 주소를 부여하여 서비스를 제공할 수 있다면 서버 관리자의 처지에서 아주 편리할 수 있다. 예를 들어 세 개 회사의 웹 서버를 구축할 때 각 회사의 이름주소 또는 IP 주소는 서로 다를 것이므로 각기 다른 컴퓨터 시스템에 서버를 설치해야 할 것이다. 그런데 이 서버를 한 대의 컴퓨터에 구축하여 한 사람이 관리하게 할려고 한다면, 한 대의 컴퓨터에 세 개의 IP를 부여할 수 있어야 한다는 말이 된다. NCSA HTTPd에서는 이것을 가능하게 하고 있다. 3.3.1 BindAddress 변수
하나의 인터페이스 카드에 대해 할당되어 있는 IP 주소는 통상 하나이지만 (솔라리스와 같은 OS에서는 여러 개의 IP 주소가 할당 가능하다) 127.0.0.1이라고 하는 localhost 주소가 기본적으로 할당되어 있다. 이에 따라 하나의 호스트는 두 개의 IP 주소를 가진 셈이 되며, 아래의 예와 같이 지정해 놓으면 두 개 호스트에 대해서만 접속이 허용된다.
BindAddress 127.0.0.1 pec.etri.re.kr
호스트에 대해 지정되어 있는 여러 개의 IP 주소들을 위와 같이 나열해 놓으면 서버가 최초에 실행될 때 각 IP 주소에 대해 바인드 작업을 수행하고, 나열해 놓은 IP 주소에 대해서만 접근을 허용한다. 이것을 이용하여 일종의 서버 보안 기능으로도 활용할 수 있다.
3.3.2 VirtualHost 변수
하나의 서버 호스트에 여러 개의 IP 주소를 할당하여, 어느 IP 주소로부터 들어온 서비스 요구인지 알아내어 해당하는 별도의 서버 홈페이지로 연결해주는 역할을 말한다. 이것을 이용하여 한 대의 컴퓨터 호스트에서 각각의 IP 주소를 가지는 여러 곳의 서버 홈페이지를 구성할 수가 있다. 이것을 지정하는 방법은 아래와 같다.
앞서 설명처럼 하나의 호스트는 127.0.0.1이란 localhost 주소와 또 하나의 IP 주소로 지정되어 있는데, 호스트 내 사용자와 외부에서 접속하는 사용자에 대해 다른 서비스를 제공해주자 할 때 위와 같은 방식을 사용할 수 있다. 또한 마찬가지로 같은 호스트에 대해 추가로 할당되어 있는 IP 주소가 있을 때 위와 같은 방법으로 새로운 서버 구성을 할 수가 있다. 만약 같은 호스트에 대해 we.world.org란 이름주소와 함께 특정 IP 주소가 할당되어 있다면,
이와 같이 하여 /home/www/we.world.org란 디렉토리 속에 we.world.org_srm.conf 화일에 따라서 서버를 구성할 수가 있는 것이다.
서버 구성을 위한 환경 변수 지정을 위에서는 ResourceConfig에 화일 이름으로 정해 놓았는데, 이를 다른 방식으로도 지정할 수 있다. 즉,
이와 같이 VirtualHost 변수 속에 SRMOptions를 포함하여 srm.conf 화일 속에 들어있는 주요 지정 사항들을 내부에 포함시켜도 된다. 위에서 Required라고 정의되어 있는 것은 환경 변수 지정에 문제가 있을 때 서버의 실행을 중단시키는 것이고, 이것 대신에 OPtional로 대치시킬 수가 있는데 이 경우는 서버를 실행시킬 때 환경 변수 지정에 문제가 있더라도 동작을 해라는 표시이다. 기본적으로 Required로 지정되어 있다.
따라서 이상과 같은 기능을 사용하기 위해서는 하나의 호스트에 여러 개의 IP 주소를 할당할 수 있는 시스템이라야만 가능한 것이며, Solaris를 사용하는 호스트에서는 이것이 가능하다.
3.3.3 Solaris에서의 IP 할당 방법
Solaris 2.x에서는 아주 손쉽게 하나의 인터페이스 카드에 대해 여러 개의 IP 주소를 할당할 수 있다. 예를 들어 아래와 같이 honey란 이름을 가진 호스트에서 ifconfig -a 라는 명령을 실행시키면 다음과 같은 결과를 볼 수 있다.
이것은 하나의 호스트에 lo0과 le0라고 하는 두 개의 IP 주소가 기본적으로 할당되어 있는 것을 보여주고 있다. le0라고 하는 인터페이스 카드에 새로운 IP 주소를 할당하는 예는 아래와 같다.
하나 더 할당하고자 한다면,
이와 같이 1, 2, 3, ..., 255의 순서로 번호를 붙여가며 각기 다른 IP 주소를 할당할 수 있다. 이 가운데 2번에 대해 할당한 IP 주소를 해제하고자 한다면,
이상과 같이 하면 된다. 이에 따라 각각의 IP 주소로 접속하는 서비스 요구는 VirtualHost에서 확인되어 해당 서버 홈페이지를 제공해줄 수 있게 된다.
브라우저가 서버로부터 데이타를 갖고 올 때는 대상이 되는 화일마다 별도의 TCP 연결을 만들어서 갖고 오게 된다. 예를 들어, 하나의 HTML 문서 속에 그림 화일이 두 개가 들어 있다면 문서를 갖고 오기 위한 TCP 연결이 하나 생기고 이어서 그림 화일 두 개를 갖고 오기 위한 TCP 연결이 두 개 새롭게 생긴다. 이렇게 여러 개의 연결이 만들어져서 데이타를 갖고 오는데, 성능의 관점에서 본다면 TCP 연결을 매번 만들 때마다 연결을 설립할 때의 시간 부담을 일으키게 된다.
그런데 사용자의 관점에서 본다면, 특정 서버에 한 번 접속하면 단지 하나의 문서만 갖고 온다고 하기보다는 그곳에서 몇 가지 문서를 더 갖고 올 것이며, 빈번하게 접속해서 문서를 갖고 온다고 할 때 그때마다 매번 TCP 연결을 맺어서 문서를 갖고 온다는 것은 사실 짜증나는 일이다.
이러한 것을 제일 쉽게 찾아볼 수 있는 게 브라우저에서 ftp 프로토콜을 사용할 때이다. ftp 서버에 접속하여 문서를 몇 개 갖고 오고자 할 때, 그때마다 새로운 연결을 만들어서 서버에 접속하고 anonymous 사용자 확인을 하고 그 속에서 데이타를 갖고 오는 과정을 거친다. 이것이 몇 번 반복되면 여간 짜증나는 일이 아니다. 브라우저를 사용하지 않고 직접 ftp 프로그램을 이용하여 연결을 하면 이런 일이 발생하지 않는다. 즉, ftp 프로그램에서는 처음에 한 번 연결을 맺어 놓으면 일정 시간 동안은 연결이 끊어지지 않고 대기하고 있으므로 새로이 연결을 맺는 시간 부담이 줄어드는 것이다.
그래서 NCSA 서버에서는 KeepAlive라는 기능을 도입하여 일정 시간 동안 연결을 끊지 않고 그냥 두게 한다. 아무런 추가 요구가 없고 지정한 시간이 지나면 서버에서는 연결을 끊어버린다. 이것을 이용하면 빈번하게 문서를 찾아보고 활용하는 경우에 훨씬 좋아진 서비스 느낌을 가질 것이다. PC 윈도용 Mosaic에서 구현하여 실험해본 결과 약 30%의 성능 향상을 볼 수 있었다 한다. 이처럼 이러한 기능을 활용하기 위해서는 KeepAlive를 지원하게끔 브라우저가 구현되어 있어야 한다. NCSA에서 제공하는 모자익 브라우저는 이 기능을 지원한다. 사용법은 아래와 같다.
KeepAlive on | off KeepAliveTimeout N MaxKeepAliveRequests N
KeepAlive 기능을 사용할 것인가 하지 않을 것인가에 따라서 On과 Off 둘 중 하나를 선택한다. 브라우저와 연결되었을 때 몇 초 동안 연결을 끊지 않고 그대로 둘 것인가를 KeepAliveTimeout에서 지정한다. 60으로 지정한다면 60초 동안 대기하겠다는 것이다. 그런데 이러한 KeepAlive 기능은 서버로 볼 때는 시스템 부하가 된다. TCP 연결을 끊지 않고 일정 시간 동안 두고, 이런 연결이 많은 갯수로 있다면 서버에게 상당한 부담의 요소로서 작용하므로, 최대 몇 개의 TCP 연결까지 이 기능을 허용하겠다 지정할 수가 있다. 이것은 MaxKeepAliveRequests에서 설정한다. 이 변수들은 httpd.conf 화일 속에 있다.
3.5.1 Redirect
특정의 이름으로 들어오는 서비스 요구를 직접 처리하지 않고 다른 서버에게 넘겨주고자 할 때 사용할 수 있다.
Redirect /HTTPd/ http://hoohoo.ncsa.uiuc.edu/이렇게 해놓으면, 서버 본래 URL이 http://www.server.org라고 했을 때, http://www.server.org/HTTPd/ 이렇게 접속하는 요구를 www.server.org라고 하는 서버에서 처리하는 것이 아니라, hoohoo.ncsa.uiuc.edu라고 하는 서버로 넘겨주는 것이다.
이 기능을 이용하면 여러 곳에 분산되어 있는 서버 데이타라고 할지라도 하나의 호스트에서 한 가지 호스트 주소를 사용하는 URL을 통해 서비스를 제공할 수 있는 것이다.
CERN 서버에도 Redirect 기능이 쓰이고 있으며 똑같은 역할을 한다.
3.5.2 Alias
어느 디렉토리 속에 문서를 저장해 두었다가 또는 특정의 화일 이름으로 서비스를 제공하고 있다가, 서버 관리자가 디렉토리 이름을 바꾸거나 경로를 바꾸었을 때 또는 화일의 이름을 바꾸었을 때, 서버 관리자는 이것을 잘 알고서 활용할 수 있을 것이지만 외부에 있는 사용자들은 이것을 모를 것이고, 만약 외부 사용자 자신의 브라우저에 등록해 두고서 이용하고 있다면 다시 접속하고자 할 때 그런 디렉토리가 없다거나 그런 화일이 없다고 응답이 돌아올 것이다.
이때 서버 관리자는 Alias란 기능을 이용하여 바뀐 디렉토리나 이름에 대해 정의를 하여 계속 서비스 받을 수 있게 할 수 있다. 이것은 Unix 명령어 상에서 사용하는 엘리어스 기능과 같다. 따라서 실제로 존재하는 화일 이름이나 디렉토리 경로에 대해 하나의 이름으로 대치시킬 수가 있게 된다. 즉,
Alias /images /www/www_home/images
이렇게 해놓으면 http://www.server.address/images/figure.gif 라는 URL에 대해 /www/www_home/images란 디렉토리 밑에서 figure.gif란 화일을 찾게 된다. 따라서 이러한 엘리어스 기능을 이용하여, 복잡한 디렉토리 구소 속에서 어느 화일이나 디렉토리를 참조하고자 할 때 Alias 기능을 이용하여 간편하게 정의하여 사용할 수 있다.
CERN 서버에서는 Pass란 변수를 이용하여 이 기능을 실현시킬 수 있다.
3.5.3 Script Alias
사용자로부터 들어온 서비스 요구에 대해 서버가 문서를 보낼 때는 기본적으로 전송할 데이타의 하나로서 취급한다. 그런데, CGI 프로그램의 경우는 전송할 데이타가 아니라 서버가 실행시켜야 할 대상이며, 이의 결과를 전송하든지 서버에서 결과를 처리하여 또 다른 일을 하게끔 해야 한다.
서버는 어떤 화일이 실행시켜야 할 대상인지 인식을 해야 하는데, 이것을 지정하는 것이 ScriptAlias이다. 이 변수에 의해 지정되어 있는 디렉토리 속의 모든 데이타는 전송할 대상이 아니라 실행시킬 대상으로서 인식하게 된다. 그러므로 서버 관리자는 서버에서 서비스를 제공하는 각 사용자들이 자신의 CGI 프로그램을 작성하고 서비스 하고자 한다면, 서버 관리자가 이들을 모아서 총괄 관리할 것이 아니라 사용자 디렉토리의 특정 부분에 대해 ScriptAlias를 지정해주면 되는 것이다. 각 사용자의 CGI 프로그램 관리는 그 사람의 재량에 맡기면 끝난다. 다음은 이것의 예이다.
ScriptAlias /cgi-bin/ cgi-bin/
이 경우는 http://pec.etri.re.kr/cgi-bin/ 과 같이 cgi-bin이란 URL 요소가 있을 때 서버가 실제로 찾아야 할 디렉토리의 이름을 지정하는 것이며, cgi-bin/ 이렇게 되어 있으므로 ServerRoot 변수에서 지정한 디렉토리 이름 밑에서 cgi-bin 디렉토리를 찾는다. 만약 다음과 같이 되어 있다면,
ScriptAlias /cgi-bin/ /home/www/all-cgi-bin/
ServerRoot 변수에서 지정한 디렉토리 밑이 아니라 화일 시스템의 /home/www란 실제 디렉토리 밑에서 all-cgi-bin이란 디렉토리를 찾게 된다.
이와 같은 방법으로 여러 명의 사용자들이 갖고 있는 각자의 CGI 프로그램에 대해 ScriptAlias를 지정할 수 있다. 예를 들어,
ScriptAlias /~mjlim/cgi-bin/ /home/users/mjlim/cgi-bin/ ScriptAlias /bkmoon/cgi-bin/ /home/managers/bkmoon/cgi-bin/
이와 같이 하였을 때, 만약 서버의 주소가 honey.etri.re.kr이라고 한다면, http://honey.etri.re.kr/~mjlim/cgi-bin/hello 라는 URL에 대해 서버는 /home/users/mjlim/cgi-bin 디렉토리 밑에서 hello라는 화일을 실행시킨다. 또한, http://honey.etri.re.kr/bkmoon/cgi-bin/dear 라는 URL에 대해서 서버는 /home/managers/bkmoon/cgi-bin 디렉토리 밑에서 dear라는 화일을 실행시킨다.
3.5.4 Script 기능에서의 유의 사항
위와 같은 예에서, 다음과 같이 구성되어 있다면 어떤 결과가 발생할 것인가?
Script /~mjlim/ /home/users/mjlim/www_home/ ScriptAlias /~mjlim/cgi-bin/ /home/users/mjlim/cgi-bin/ ScriptAlias /bkmoon/cgi-bin/ /home/managers/bkmoon/cgi-bin/
mjlim이란 사용자는 http://honey.etri.re.kr/~mjlim 이란 URL로 들어오는 자신의 홈페이지를 /home/users/mjlim/www_home에서 서비스하고 싶다는 지정 사항이 첫 줄에 있는 Script이다. 이 사용자가 만든 CGI 프로그램은 /home/users/mjlim/cgi-bin 디렉토리 밑에 있다는 것이 두 번째 줄에 나오는 ScriptAlias 변수이다.
이 상황에서 mjlim이란 사용자가 만들어둔 hello란 CGI 프로그램이 cgi-bin이란 디렉토리 밑에 있으며, http://honey.etri.re.kr/~mjlim/cgi-bin/hello 란 URL에 의해 hello 프로그램이 제대로 실행될 것인가?
그런 것 없다는 오류만 받게 될 것이다. 그렇다면 순서를 바꾸어,
ScriptAlias /~mjlim/cgi-bin/ /home/users/mjlim/cgi-bin/ Script /~mjlim/ /home/users/mjlim/www_home/ ScriptAlias /bkmoon/cgi-bin/ /home/managers/bkmoon/cgi-bin/
이렇게 둔다면 어떻게 될 것인가? 성공적으로 동작한다. 그러면 단지 순서만 뒤바뀐 것에서 어떻게 다른 결과가 나올 수 있을 것인가 생각해보자.
앞서 예제에서 Script 지정이 먼저 나와 있으므로 서버는 /~mjlim/cgi-bin/ 이란 디렉토리를 Script 변수에서 지정한 장소에서 항상 찾는다. 따라서 www_home 디렉토리 밑에서 cgi-bin 디렉토리를 찾는다는 것이며, 실제로는 여기에 있는 것이 아니라 mjlim 사용자 디렉토리 밑에 있으므로 찾지 못한다는 오류가 발생한다.
이러한 문제는 CERN 서버에서도 발생하는 것이니 사용상 유의해야 하는 사항이다.
3.5.5 CGI anywhere
위에서와 같이 CGI 프로그램만 두는 디렉토리를 따로 만들고 설정할 수도 있으나 아예 화일 확장자 이름을 보고서 어느 디렉토리에 있든지 CGI 프로그램으로 인식하도록 할 수도 있다.
이것은 srm.conf 화일 속에 다음과 같이 지정하면 된다.
AddType application/x-httpd-cgi .cgi .pl .sh
이와 같이 지정해 놓으면 화일 이름이 .cgi, .pl, .sh로 끝날 때 CGI 프로그램으로 인식하고서 실행되게 된다. 이렇게 해서 사용할려면, access.conf 화일 속에 반드시 지정해야 하는 것이 있다. 이것은 access.conf의 첫 부분에 나오는 Options 부분에 ExecCGI 항목이 추가되어야 한다는 것이다.
서버에 만들어둔 디렉토리나 화일들 가운데 사용자에 대해 접근을 제한할 필요가 있는 것들이 있다. 이때 사용자 식별 아이디를 사용하여 사용자 확인을 할 수도 있고, 서비스 요구를 하는 브라우저의 IP 주소에 대해 접근을 제한할 수도 있다. 이것을 통해 특정 문서나 특정 디렉토리에 대해 사용자 접근을 제한하고자 할 때 사용자 접근 제어를 하여야 한다.
이러한 접근 제어를 정의할 때 서버에 있는 전체 디렉토리에 대해 접근 제어를 시행하는 방법이 있고, 각 디렉토리마다 접근 제어를 위한 정의 화일을 두어서 시행하는 방법이 있다.
서버 전체 디렉토리에 대한 접근 제어를 시행하기 위해서는 srm.conf 화일 속에 다음과 같은 변수에 대해 어떤 화일이 전체 접근 제어에 사용될 것인지 지정해 놓아야 한다.
AccessConfig conf/access.conf
만약 정해져 있지 않으면, 기본적으로 conf 디렉토리 밑의 access.conf 화일을 이것으로 인정한다. 이 화일은 디렉토리 속에 있으모로 서버 관리자는 이 변수 지정을 하지 않아도 된다. 다만 다른 화일을 이용하여 지정하고자 할 때는 있어야 한다. 즉,
AccessConfig conf/global-access
이러한 지정 사항은 srm.conf 화일 속에 두며, 각 디렉토리에서 사용자 접근 제어를 위해 사용하는 화일의 이름은 AccessFileName이란 변수에서 지정하고 마찬가지로 srm.conf 화일 속에 둔다. 이 화일 속에 아래와 같이 지정되어 있다.
AccessFileName .htaccess
3.6.1 접근 제어의 적용 범위 설정
사용자 접근 제어 기능을 이용할 때, 특정 디렉토리에 대해서만 별도의 제어 기능을 활용하고자 할 때가 있다. 이때 사용할 수 있는 것이 다음과 같은 것이다.
이러간 범위 지정은
3.6.2 접근 제어 화일에 적용할 수 있는 환경 변수
접근 제어 화일이란 앞서 AccessConfig와 AccessFileName에 의해 지정되는 화일을 말하는 것이다. 이 화일 속에 지정할 수 있는 변수들은 여러가지가 있는데 몇 가지는 간단하게 설명하도록 한다. 아래 설명은 위에 지정한 두 가지 화일 이름, access.conf와 .htaccess에 대해 어느 쪽에서 사용할 수 있는지 함께 나타내도록 한다. 괄호 속의 화일 이름은 그 화일에서만 사용할 수 있는 뜻이다.
AddDescription "I LOVE YOU!" To_you.html이와 같은 지정에 대해, http://pec.etri.re.kr/test/ 이란 URL로 화일 이름 없이 디렉토리로 지정할 때 기본 서비스 문서가 만들어져 있지 않다면, 디렉토리의 화일 목록이 대신 서비스 될 때 이 설명문이 보이게 된다. 즉, 다음과 같다.
AddEncoding x-gzip gz
AddIcon /icons/image.xbm .gif .jpg .xbm AddIcon /icons/text.xbm .txt .ks .html .htm AddIcon /icons/doc.xbm .doc AddIcon /icons/bin.xbm .exe .com .tar .gz .Z .z AddIcon /icons/dir.xbm ^^DIRECTORY^^ AddIcon /icons/blank.xbm ^^BLANKICON^^ AddIcon (SND,/icons/sound.xbm) *.au
위에서 SND는 그래픽 브라우저가 아닌 텍스트 브라우저로 접속할 때 아이콘 그림 대신에 그 자리에 보여줄 표시이다.
AddType text/plain txt AddType text/html To_you.html
앞에서 화일 접근 제어는 두 가지 방식으로 이루어진다고 하였다. 그러므로 전체 대상 접근 제어와 각 디렉토리별 접근 제어는 서로 배치될 가능성도 있다. 이때, 각 디렉토리별 접근 제어 화일이 영향을 미칠 수 있는 범위를 설정할 수가 있다. 이것은 access.conf와 같이 서버 전체 접근 제어 화일에만 쓰일 수 있으며, 다음과 같다.
AllowOverride or1 or2 or3 ... orn
여기서 각 or은 다음의 것들 가운데 한 가지가 될 수 있다.
AuthName AuthType AuthUserFile AuthGroupFile
AddDescription "I LOVE YOU!" To_you.html
어느 디렉토리의 .htaccess 화일에 다음과 같은 사항이 정의되어 있을 때,
AddDescription "I LIKE YOU!" To_you.html
그 디렉토리 속에 있는 To_you.html 화일의 설명에 I LOVE YOU!란 말 대신에 I LIKE YOU!가 나타난다. 결국 각 디렉토리에 있는 .htaccess 화일의 내용이 우선권을 가지게 되는 것이다.
3.6.4 접근 제어의 규칙
특정 디렉토리에 접근하고자 하는 사용자에 대해 제어를 하고자 할 때 구체적인 지정 사항들이 있어야 한다. 예를 들어, 어떤 서비스를 허용하고, 어느 호스트 주소에 대해 어느 그룹 어느 사용자에게 허용할 것인지 정의를 해야 하는 것이다.
이것은 access.conf와 .htaccess 두 곳 모두에 적용할 수 있다. 이러한 제어 규칙을 적용할 때 Directory 변수를 이용하여 적용 범위를 지정할 수 있으며, .htaccess의 경우는 해당 디렉토리에 대한 적용 범위이므로 Directory 변수를 이용할 수 없다. 앞서 설명처럼 Directory 변수는 access.conf에만 사용할 수 있다.
다음과 같이 사용한다.
위와 같은 예에서, GET 부분은 GET, PUT, POST 세 가지 가운데 하나가 쓰일 수 있는데, PUT은 아직 구현되어 있지 않고 POST는 완전히 구현되어 있지 않고 POST라고 하는 스크립트에 대해서만 구현되어 있다. 따라서 완전히 쓸 수 있는 것은 GET 하나 뿐이라고 해야 하겠다.
여기에 지정할 수 있는 것은 모두 세 가지이며, 이 가운데 하나만 선택할 수 있다.
deny, allow allow, deny mutual-failureallow, deny의 순서는 allow 기능을 먼저 처리하고 그 다음에 deny 기능을 처리하겠다는 것이다.
mutual-failure의 경우에는 허용하고 거부할 호스트 주소를 allow와 deny에 반드시 명시하여야 한다. 이 경우에 allow에 나타나는 주소는 어떤 것이든지 접근 허용이 되고, deny에 나타나는 것은 어떤 것이든지 거부되며, 어느 쪽에든 명시 되지 않은 것들은 (neither) 접근 거부된다.
.etri.re.kr deny.etri.re.kr 129.254.201.255 129.254.200. all
require entity en1 en2 en3 ... enn
en 자리에는 해당 요소들의 이름이 들어간다. 각각의 구분은 빈 공백으로 표현한다. 예를 들어 사용자 아이디나 그룹 이름들이 주루룩 나열될 수 있다. 두 가지 가운데 어느 것인지는 entity 사항에서 지정한다.
entity 자리에 들어갈 수 있는 요소는 세 가지이다. 하나는 user로서 나열하는 사용자에게만 접근이 허용되는 것이고 사용자 등록에 대한 정보는 AuthUserFile 변수에 지정되어 있는 화일에 기록되어 있다. 다음은 한 가지 예이다.
require user qkim love honey sun moon
entity 자리에 group으로 지정할 수도 있다. 나열하는 사용자 그룹에 대해서만 접근이 허용된다는 것이고 사용자 등록에 대한 정보는 AuthGroupFile 변수에 지정되어 있는 화일에 기록되어 있다. 다음은 한 가지 예이다.
require group pec etri multimedia
entity 자리에 valid-user를 지정할 수 있으며, AuthUserFile에 등록되어 있는 모두에게 접근을 허용한다는 뜻이다. 그리고 모든 경우에 있어 비밀번호 확인 작업을 거쳐야 한다.
문서에 대한 접근 제어를 할려면 문서 서비스를 요청하는 상대에 대한 확인 작업을 거쳐야 한다. 이것은 사용자의 아이디와 비밀번호를 확인함으로써 가능한 것인데, 사용자 인증을 위한 환경을 설정할 때 환경 변수 지정에 있어 반드시 지켜야 할 것이 있다. 네 가지 환경 변수가 쓰이고 있으며 이의 나열 순서가 다음과 같은 순서로 반드시 지켜져야 한다는 것이다.
AuthName AuthType AuthUserFile AuthGroupFile
각각에 대해 살펴보도록 한다.
3.7.1 사용자 인증 확인처
이러한 사용자 인증을 어느 곳에서 확인하고 있는지 확인처 이름을 밝힌다. 결국 해당 사용자 인증에 대한 주인을 명시하는 것이다. access.conf와 .htaccess 두 가지 모두에 사용할 수 있고, 단어 사이에 공백이 있어도 가능하다.
AuthName ETRI Multimedia Standardization Section
3.7.2 사용자 인증 방식
사용하고 있는 인증 방식을 정의하는 것이며, 현재 Basic 방식만 구현되어 있으므로 Basic이라 지정하면 된다. access.conf와 .htaccess 두 가지 모두에 사용할 수 있다.
AuthType Basic
3.7.3 접근허용 사용자 관리
접근을 허용할 사용자와 이의 비밀번호를 관리하는 화일의 이름과 장소를 지정한다. access.conf와 .htaccess 두 가지 모두에 사용할 수 있다.
AuthUserFile /www/conf/.htpasswd
.htpasswd라고 하는 사용자 등록 화일이 /www/conf 디렉토리 속에 있다는 뜻이다.
3.7.4 사용자 그룹 관리
사용자 인증을 위한 그룹 관리를 할 수 있는데, 그룹의 목록을 관리하는 화일의 이름을 지정하도록 한다. 이것은 access.conf와 .htaccess 두 가지 모두에 사용할 수 있다.
AuthGroupFile /www/conf/.htgroup
.htgroup이라고 하는 그룹 목록이 /www/conf 디렉토리 속에 있다는 뜻이다.
3.7.5 사용자 관리
사용자 인증을 위한 등록자 관리가 이루어져야 하는데, 이를 위한 실행 프로그램이 있다. htpasswd 라는 것으로서 support 디렉토리 속에 있다. 이의 사용법은 다음과 같다.
htpasswd -c .htpasswd qkim Adding password for qkim. New password: Re-type new password:
htpasswd .htpasswd love Adding user love New password: Re-type new password:
htpasswd tmp qkim Changing password for user qkim New password: Re-type new password:
이상과 같은 사용자 등록 관리를 할 수 있으며, 등록된 각 사용자들에 대한 그룹 관리를 할 수 있는데 이것은 아래와 같다.
groupname: member1 member2 member3 your_team: member1 member 10 member11 my_team: member2 member3 member20
CERN 서버는 3.0 버전에서 상위 버전이 아직 발표되지 않은 상태이다. 상세한 설치 과정은 다음의 문서를 참조하면 된다.
ftp://most.etri.re.kr/pub/guide/Sun_CERN_httpd.ks ftp://most.etri.re.kr/pub/guide/cern_server_install.ps.Z두 가지 문서는 서로 같은 것이나 Sun_CERN_httpd.ks는 한글 LsTeX을 이용한 문서이며, 따라서 LaTeX을 모르는 사람에겐 이해할 수 없는 기호들이 나올 것이다. 그러나 한글 설명의 부분은 그대로 볼 수 있다. PostScript 화일을 인쇄할 수 있는 사람은 cern_server_install.ps.Z를 갖고 가서 프린트하면 된다.
CERN에서는 NCSA보다 다양한 융통성을 제공하는 매핑 기능이 있다. NCSA 서버에서는 Alias와 Redirect 두 가지 요소로서 관련 기능을 제공하고 있지만, CERN 서버는 Map, Redirect 및 Pass 세 가지 요소로 활용하고 있다. 그런 만큼 NCSA 서버보다는 매핑 기능에 있어 보다 강력하게 이용할 수 있다.
4.1.1 Redirect
Redirect 라고 하는 것은 서버가 수신하는 서비스 요청을 지정해 놓은 다른 곳으로 그대로 넘겨주는 역할을 한다. 즉, 이 서버가 설치되어 있는 호스트의 URL이 http://nirong.etri.re.kr/이라고 했을 때, 다음과 같은 예를 볼 수 있다.
Redirect /www/* http://irong.etri.re.kr/~irong/*
위와 같은 경우는 http://nirong.etri.re.kr/www/ 이란 URL로 들어오는 서비스 요청을 nirong 의 서버에서는 http://irong.etri.re.kr/~irong/ 이란 URL로 irong 의 서버에게 그대로 넘겨주는 역할을 하는 것이다.
이에 따른 결과는, 브라우저에서 http://nirong.etri.re.kr/www/ 이란 URL로 서비스를 요청했다고 해도 나중에 돌아온 결과와 함께 보이는 브라우저에는 http://irong.etri.re.kr/~irong/이란 URL로 보인다는 것이다. 이것과 비교하여 설명할 수 있는 것이 Pass 란 것이다. 이에 대해서는 아래에서 설명하도록 한다.
이러한 Redirect 의 기능을 가장 잘 활용할 수 있는 경우는, 지금까지 서비스해 오던 URL에서 디렉토리 변경이나 화일 이름 변경이 생겼을 때 외부에서는 모르고 있을 것이므로 기존의 이름에다 Redirect 를 만들어서 새로운 이름으로 지정해 놓으면 외부의 사용자는 과거에 쓰이던 URL을 갖고서도 서비스를 받을 수 있으며, 또한 사용자의 브라우저에는 바뀐 URL의 이름이 그대로 나타나서 바뀐 사실을 알 수 있는 것이다.
이것은 NCSA 서버에서도 그대로 동작한다.
4.1.2 Map
Map 의 기능은 앞에 있는 URL을 뒤에 있는 것으로 대치한다는 의미를 갖고 있다. 예를 들어, 이 서버가 http://nirong.etri.re.kr/ 라는 URL로 설치되어 아래와 같이 명시되어 있다면,
Map /~qkim/ /home/mm/qkim/www_home/who.am.i.html Pass /home/mm/qkim/www_home/who.am.i.html
http://nirong.etri.re.kr/~qkim/ 으로 들어오는 모든 서비스 요구는 곧바로 /home/mm/qkim/www_home/who.am.i.html 로 대치된다. 따라서 URL을 실제의 화일로 곧바로 지정할 때 사용할 수 있다.
그러나 이것은 하나의 스트링으로 처리되기 때문에 단지 이렇게만 하면 서버에서는 /home/mm/qkim/www_home/who.am.i.html 을 인식하질 못한다. 그래서 Pass를 이용하여 인식할 수 있게 한다. 여기서 Pass 는 도착하는 서비스 요구를 받아들이겠다는 의미를 갖고 있다. 따라서 /home/mm/qkim/www_home/who.am.i.html 이란 것으로 mapping되어 있는 것이라도 서비스 요구로 인정하여 받아 주겠다는 것이다.
아래의 것은 또 다른 예이다.
Map /bbs http://irong.etri.re.kr/love/bbs/* Map /bbs/* http://irong.etri.re.kr/love/bbs/* Map /love/bbs http://irong.etri.re.kr/love/bbs/* Map /love/bbs/* http://irong.etri.re.kr/love/bbs/* Pass http://irong.etri.re.kr/love/bbs/*
4.1.3 Pass
앞서의 설명처럼 Pass 는 서비스 허용의 의미를 갖고 있다. 예를 들어 다음과 같은 경우가 가능하다.
Pass /dream/* /home/mm/dream/*위의 경우로 설명해 보면 http://irong.etri.re.kr/dream/* 로 들어오는 모든 서비스 요청은 /home/mm/dream/* 로 간주하여 처리하겠다는 것이다. 이것은 NCSA 서버에서의 Alias 기능과 같다. 그러나 이와 함께 다른 측면의 Redirect 기능도 제공한다.
앞서의 Redirect 변수에서는 들어오는 서비스 요구를 그대로 넘겨주는 역할을 했지만, Pass 변수에서는 들어오는 서비스 요구를 넘겨주지 않고 중간에서 대신 처리해준다. 그래서 밖에서는 실제로 서비스해 주는 곳은 보이지 않고 중간에서 처리해 주는 곳만 보이는 것이다.
이러한 기능을 활용하면 다수의 서버가 있을 때 보안상의 문제로 하나의 서버만 외부에서 인식할 수 있게 하면서 제공하는 서비스는 다수 서버의 것을 활용하고자 할 때 유용하게 쓰일 수 있는 것이다. 따라서 다수의 서버는 외부에서 한 대만 있는 것으로 인식될 수 있다.
예를 들어, Redirect 에서와 같은 URL에 대해 아래와 같은 Pass 를 사용했다면
Pass /www/* http://irong.etri.re.kr/~irong/*
이의 동작은, 서버가 설치되어 있는 nirong 호스트에 대해 http://nirong.etri.re.kr/www/* 으로 들어오는 서비스 요청을 nirong 의 서버가 irong 의 서버에게 요청하여 서비스 받은 후에 다시 원래 요청했던 브라우저에게 넘겨주는 것이다. 그래서 서비스를 요청한 브라우저에는 실제로 서비스를 제공한 irong 의 호스트 이름이 보이지 않고 nirong 이란 호스트 이름이 보이게 된다.
먼저 Proxy 서버의 개념부터 이해할 필요가 있다. Proxy 서버란 방화벽 (firewall) 시스템이 설치되어 있는 호스트에서 동작하는 서버이며, 방화벽 내에 있는 사용자들에게 방화벽 밖에 있는 서버로의 자유로운 서비스 요구와 응답을 받기 위한 수단으로 만들어진 것이다.
해킹과 같이 외부로부터의 불법적인 접속을 방어하기 위해 설치하는 시스템이 방화벽인데, 외부인의 접속이 어려운 만큼 내부인의 외부 접속도 제한될 수 밖에 없다. 이러한 때 방화벽이 설치되어 있는 시스템에다 Proxy 서버를 설치해 두면, 방화벽에서는 이 서버에 대한 동작을 허용하고 내부의 모든 사용자는 이 서버에게만 서비스 요구를 하도록 한다. 그러면 이 서버는 외부의 서버들에게 서비스 요청을 하고 응답을 받으면 원래 요청했던 방화벽 내부의 사용자에게 전달해 준다. 즉, Proxy 서버는 사용자 브라우저와 방화벽 외부의 서버들 사이에서 방화벽을 통과하는 중계 게이트웨이 역할을 해주는 것이다.
이러한 장점을 살리면 다른 용도로서 활용할 수도 있다. 예를 들어, DNS서비스가 제공되지 않는 시스템에서 브라우저를 이용해서 서비스를 받는다는 것은 사실상 불가능하다.
이처럼 DNS 서비스를 제대로 받지 못 하는 것은 시스템의 환경 구성을 잘못해서 그럴 수도 있지만 외부에 드러나지 않기 위해 의도적으로 자신을 숨기는 경우도 있다. 어떤 경우이든지 적절히 Web 브라우저를 이용하기 위해서는 DNS 서비스를 받아야만 한다. 이러한 때 DNS 서비스가 제공되는 호스트에는 Proxy 서버를 설치하고, DNS 서비스가 제공되지 않는 호스트의 브라우저에서는 Proxy 서버에게 서비스 요구를 하고 이에 대한 응답을 받으면 해결될 수 있는 것이다. 그러므로 Proxy 서버를 이용하고자 하는 브라우저에서는 자신이 사용할 Proxy 서버의 주소를 브라우저 환경 설정에서 지정해 주어야 한다.
이러한 Proxy 서버의 능력을 활용하면 속도의 향상 효과도 얻을 수 있다. 속도가 빠른 곳에 서버를 설치해두고 비교적 느린 곳에 있는 많은 사용자들은 외부로 직접 서비스 요구를 할 필요없이 설치해둔 Proxy 서버에게 요구를 하면 속도의 향상 효과도 얻을 수 있다.
4.2.1 Proxy 서버의 설치
Proxy 서버의 설치는 간단하다. 이것을 일반 서버의 동작과 동시에 Proxy 서버로 동작하게 할 수도 있으면, 다른 포트 번호를 활용하여 Proxy 서버 전용으로 동작하게 할 수도 있다. 여기서는 Proxy 서버 전용으로 설치하는 예를 보이고자 한다.
CERN httpd 서버 프로그램 속에 들어있는 proxy.conf를 기준으로 설명한다.
ServerRoot /home/www/httpd Port 8080 UserId nobody GroupId nogroup AccessLog logs/proxy-log ErrorLog logs/proxy-errors LogFormat Common LogTime LocalTime
기존의 일반 서버 설치할 때와 똑같은 방식으로 지정하면 된다. Proxy 서버로 동작하게 하는 결정적인 사항이 아래에 있는 것이다.
# # Pass the URLs that this proxy is willing to forward. # Pass http:* Pass ftp:* Pass gopher:* Pass wais:*
이렇게 지정하기만 하면 된다. 위에 있는 다섯 가지 지정 사항이 갖고 있는 뜻을 설명하고자 하므로 상상의 나래를 펴면서 잘 생각해 보기 바란다.
지금 현재의 상황은 http://nirong.etri.re.kr/ 서버가 위와 같이 지정되어 Proxy 서버로서 동작하고 있다고 하자. Proxy 서버를 활용하기 위해서는 Proxy 서버를 만들어야 할 뿐만이 아니라 사용자 브라우저에서도 이 서버를 지정하여 서비스 요구를 해야 한다. 브라우저에는 이것을 지정할 수 있는 메뉴가 있으므로 사용하고자 하는 Proxy 서버를 지정할 수 있다.
사용자가 브라우저에서 Proxy 서버를 지정하지 않고 마우스 선택에 의한 서비스를 요구하면(1) URL에 지정되어 있는 서버에게 직접 서비스 요구를 하고 해당 서비스를 받게 된다.
그런데 브라우저에서 Proxy 서버를 지정하고 마우스 선택이나 URL 입력에 의해 서비스 요구를 하면 해당 URL에 있는 서버에게 직접 서비스 요구를 하는 것이 아니라 브라우저에 지정되어 있는 Proxy 서버에게 서비스 요구를 한다. 서비스 요청을 받은 Proxy 서버는 URL에 지정되어 있는 서버에게 다시 서비스 요구를 하고 이에 대한 수신 데이타를 브라우저에게 넘겨준다. 이에 따라 Proxy 서버는 중계 역할을 수행하는 것이다. 위에 보이는 다섯 가지 지정 사항이 갖는 뜻는 이러한 다섯 가지에 대해 Proxy 서버로서 중간에서 중계 역할을 하겠다는 것이다.
4.2.2 Proxy 서버의 접근 제어
#
# Proxy protections; if you want only certain domains to use
# your proxy, uncomment these lines and specify the Mask
# with hostname templates or IP number templates:
#
Protection PROXY-PROT {
ServerId pec.etri.re.kr
Mask @*.etri.re.kr
# Mask @(*.etri.re.kr, *.postech.ac.kr)
# GetMask @*.cern.ch
# PostMask @*.cern.ch
# PutMask @*.cern.ch
}
Protect * PROXY-PROT
Protect http:* PROXY-PROT
Protect ftp:* PROXY-PROT
일반적 서버로 동작을 하든 Proxy 서버로 동작을 하든 문서 서비스 내용에
대해 접근 제한을 할 수 있다. 이때 위와 같은 방법을 활용하면 Proxy 서버에
대한 접근 제한을 할 수 있다. Proxy 서버에서는 자신의 서버 자체에서 각종
문서 서비스를 제공하는 것이 아니라 가운데 위치에서 중계 역할만 하고
있으므로 문서 서비스에 대한 접근 제한이 아니라 Proxy 서버 이용권에 대한
제한을 하는 것이다. 위 예에서 보이는 것 가운데 각각에 대한 것을 살펴보면,
Protect * PROXY-PROT
이것은 모든 Proxy 서비스 요구에 대한 거부를 나타내고 있다.
Protect http:* PROXY-PROT
이것은 http://nirong.etri.re.kr/ 처럼 http 로서 들어오는 모든 서비스 요구들에 대해 PROXY-PROT 란 접근 제한 형식을 지정한다는 뜻이다. 이러한 접근 제한 형식은 Protection PROXY-PROT 라는 변수 지정에 의해 이루어지며 PROXY-PROT 는 정해져 있는 것이 아니므로 사용자의 의도에 맞춰 이름을 바꾸어도 된다.
이러한 주소 지정을 숫자로서도 나타낼 수 있는데,
Mask @(129.254.*.*, 141.223.*.*)}
이렇게 표현할 수 있다. 각 숫자 주소는 *.etri.re.kr, *.postech.ac.kr에 각각 대응한다.
4.2.3 Proxy 서버의 Caching
Proxy 서버로 동작을 하면 브라우저와 다른 서버 사이의 중간에서 서비스 요청 및 응답을 중계해주는 게이트웨이 역할을 한다고 했는데, 이때 중간에서 여러 브라우저가 원하던 문서들을 중계해 주는 동시에 특정 디렉토리에 저장해 두면, 다른 브라우저가 똑같은 문서를 요구할 때 멀리에 있는 원래 서버에까지 가서 문서를 가져 오지 않아도 미리 저장되어 있는 문서들을 제공해줄 수 있다. 이에 따라 서비스 요구에 대해 훨씬 빨리 응답을 받을 수 있다. 이러한 캐시 기능에 대한 사항들을 지정하고 있다.
# # *** PROXY CACHING *** # Caching On CacheRoot /usr1/www/www_proxy CacheSize 30 M NoCaching http://nirong.etri.re.kr/* NoCaching http://irong.etri.re.kr/* #CacheOnly http://really_important_site/* CacheClean http:* 1 month CacheClean ftp:* 15 days CacheClean gopher:* 15 days 2 hours CacheUnused http://info.cern.ch/* 7 days CacheUnused * 10 days CacheDefaultExpiry ftp:* 5 days CacheDefaultExpiry gopher:* 5 days CacheTimeMargin 5 mins CacheNoConnect Off CacheExpiryCheck On Gc On ### activated on caching enabled GcDailyGc 3:00 GcMemUsage 500 CacheLimit_1 200 K CacheLimit_2 4000 K CacheLockTimeOut 20 mins ### should be > OutputTimeOut각각의 환경 변수들에 대한 설명을 아래에 한다.
CacheClean http:* 1 month이와 같은 경우, http: 서비스 요구에 의해 저장되어 있는 데이타는 한 달이 지난 후에 모두 지워진다. 다른 경우도 마찬가지다.
국내에서 가장 대중적으로 쓰이는 NCSA 서버와 CERN 서버 두 가지에 대한 주요 기능들을 살펴 보았다. 각각이 가진 특징들이 있으므로 그 특징을 이용할려면 해당 서버 프로그램을 이용하면 될 것이다. 예를 들어 CERN 서버의 경우는 성능상 NCSA에 비해 떨어지지만 Proxy 서버로서 동작시킬 수 있는 장점이 있으며 매핑 기능이 뛰어나 보다 나은 융통성을 발휘시킬 수 있다. 이에 비해 NCSA는 CERN 서버에 비해 보다 특질적인 기능들이 제공되고 있으며 성능상의 효율성도 이루어지고 있다. 현재는 NCSA 서버 프로그램을 개량하여 만든 Apache 서버가 있으며, 개량형이니 만큼 성능과 기능상의 향상을 도모 하였고 이에 따라 점차 사용 빈도가 높아지는 추세에 있다. 주요한 설명은 NCSA 서버에 준하여 생각하면 되므로, 큰 어려움 없이 Apache 서버로의 변경이 가능하므로 향후의 서버 프로그램으로 고려해볼 필요가 있겠다.