[펌] TUX 가지고 놀기

Posted on by — No Comments ↓

출처 : http://coffeenix.net/doc/lg/issue85/vinayak.html






LINUX GAZETTE
…리눅스를 좀 더 재미있게!
TUX 시작하기
By Vinayak Hegde

한글번역 전정호

이 글은 한글번역판입니다. 원문은 여기에서 볼 수 있습니다.


TUX – “웹서버” 만나기


리눅스의 행운의 마스코트인 Tux 펭귄에 대한 글을 기대했다면 실망했을 것이다. 그러나 기다려봐라: TUX 웹서버가 성능면에서 무엇을 할 수 있는지 읽어보면 만족할 것이다. 또, 무엇인가 해킹 혹은 가지고 놀 것을 발견하게 될지도 모른다. 이 글은 리눅스 커널에 포함된 웹서버 TUX에 대한 글이다.


TUX이란 이름은 ‘Threaded linUX webserver’에서 나왔다. TUX은 Red Hat에서 만들었고, 커널 2.4에 기반한다. TUX은 커널에 포함된 HTTP 하위시스템이다. 짐작했듯이 TUX은 현재 GNU GPL로 발표되있다. 공개 소프트웨어 전통에 따라 특정 목적에 알맞게 자유로이 수정할 수 있다. TUX을 목적에 부합하게 만드는 방법중 하나는 TUX 모듈을 작성하는 것이다. TUX 모듈은 사용자공간(user-space) 혹은 커널공간(kernel-space) 둘 모두 가능하다. TUX은 리눅스에서 고성능 웹서비스를 위해 만들어졌다. 리눅스가 웹서버 시장에서 매우 유명하기때문에 이는 특히 중요하다.


TUX은 아파치와 같이 기능이 많지 않고, 한계도 많다. 그럼에도 불구하고 TUX은 HTTP/1.1 연결지속 (keep-alive), 파이프라이닝(pipelining), CGI 실행, 로그, 가상호스트, 여러 모듈 등 많은 웹서버 기능을 지원하는 HTTP/1.1에 완벽히 호환되는 웹서버다. 현재 TUX은 공식적으로 Red Hat Content Accelerator (RHCA)라고 알려져있다.


TUX은 무슨 일을 하는가 ?


오늘날 웹에서 제공되는 많은 내용들이 동적으로 생성되지만 정적인 것도 많다. 정적인 웹페이지나 이미지가 그 예이다. 그런데 아파치와 같은 사용자공간 웹서버가 이런 정적인 내용을 서비스하기 위해서는 여러 시스템호출을 사용해야하므로 부담이 된다. 프로그램이 커널공간과 사용자공간 사이에서 자주 문맥변환(context switch)을 하면 성능이 상당히 떨어진다. 이 경우 TUX이 해결책이다. TUX은 커널과 같이 컴파일되거나 모듈로 만들어 동적으로 읽어들일 수 있다. 첫번째 방법은 웹서비스 전용 서버에 적합하다. 모듈로 컴파일하면 동적으로 집어넣고 빼서, 서비스를 시작하고 중단할 수 있다. 이 방법은 여러 상황에서 사용할 수 있다.


TUX은 기본적으로 정적인 내용을 서비스하기위해 사용한다. 동적인 내용을 생성하고 서비스하는 일은 아파치와 같은 뒷단(back-end) 웹서버에게 맏긴다. 현재 새로운 TUX 버전은 동적인 내용을 캐쉬할 수 있다. TUX 모듈을 가지고 페이지 캐쉬를 사용하여 저장되는 “객체”를 만들 수 있다. 동적인 자료에 대한 요청에 응답하기위해 TUX 모듈은 동적으로 생성된 자료와 이미 생성한 캐쉬된 객체를 섞어서 보낼 수 있다. 그래서 요청의 대부분인 단순한 “네트웍-복사” 작업은 TUX가 효율적으로 처리한다. 새로운 TUX 버전은 TUX 1.0의 임시 버퍼대신 복사없는 블록 입출력(zero copy block IO)을 사용한다. 또, TUX의 가상호스트 지원이 확장되어 서비스할 수 있는 가상호스트 개수는 디스크 공간과 RAM때문에만 제한된다.


TUX 시작하기


이제 TUX이 무엇을 할 수 있는지 알았다. 이제 TUX을 설치하고 설정해보자. 다음에 나오는 모든 내용은 Red Hat 7.2의 TUX-2.1.0-2에서 테스트되었다. 쉽게 사용할 수 있고 익숙하기때문에 사용자공간 웹데몬으로 아파치를 사용했다.


1단계. TUX 설치하기


다음 명령어로 tux이 설치되있는지 알아봐라 :- 

# rpm -q tux

아래와 비슷한 문구중 하나가 출력될 것이다 :


  1. tux-2.1.0-2 (TUX이 설치되있고, 버전 번호가 출력된다)
  2. package tux is not installed (명확하다!!)
TUX 설치가 안되있다면 rpm을 (혹은 소스 패키지) 다운받아서 다음과 같이 설치한다:

  1. RPM 패키지의 경우 
    # rpm -ivh tux-2.1.0-2.i386.rpm


  2. 소스 패키지의 경우
    커널을 패치한다 
    # patch -p0 < tux2-full-2.4.10
    
# make oldconfig (여기서 tux을 활성화하고, 커널을 재컴파일하여 설치한다)
    사용자공간 도구를 설치한다 
    # tar xzvf tux-2.1.0.tar.gz
    
# cd tux-2.0.25
    
# make
    
# make install

2단계. 기본 설정하기


디렉토리 /var/www/html을 (원한다면 다른 디렉토리를) 만들고, /etc/sysconfig/tux에서 DOCROOT 값을 수정하여 이 디렉토리를 TUX의 root 디렉토리로 만든다. 또 CGI 스크립트가 저장될 경로를 CGIROOT로 설정한다. TUXTHREADS 변수도 적절한 수로 설정한다. root 디렉토리에 index.html을 만든다. 이 파일은 나중에 테스트용으로 사용한다.


3단계. TUX 시작하기


(관리자 권한으로) 다음 명령어는 TUX을 시작한다. 

# service tux start (Red Hat 시스템의 경우)

# ./tux.init start (Red Hat 시스템이 아닌 경우)

# lsmod

Module	size 	Used by

tux 	75568	0

….

….
이제 브라우저로 localhost에 접속하면 앞에서 만든 index.html 페이지가 보일 것이다. 아니라면 무엇인가 잘못되었거나 설정이 올바르지 않은 경우다. 자세한 내용은 8단계를 참고하라. 
# lynx localhost

4단계. 로그 남기기


TUX은 기본적으로 로그를 남기지않는다. 로그와 referrer 로그를 남기려면 아래 명령어를 실행한다. 

# echo 1 > /proc/sys/net/tux/logging

# echo 1 > /proc/sys/net/tux/referer_logging

# cat /proc/sys/net/tux/logfile

/var/log/tux (이것이 기본 로그파일)

매요청마다 TUX은 요청자의 주소, 최소한 초단위까지 정확한 날짜와 시간, 요청한 내용, 전송한 파일 크기, 마지막으로 요청의 상태를 로그에 남긴다. TUX의 로그파일은 (위에서 본) /var/log/tux에 이진형식으로 저장된다. 이진형식의 로그파일은 표준 ASCII 로그파일보다 약 50% 정도 작다. 로그파일을 보려면 다음 명령어를 사용한다 

# tux2w3c /var/log/tux

127.0.0.1 – – Wed Nov 20 00:22:24 2002 “GET /manual/sections.html HTTP/1.1” – 5523 200

127.0.0.1 – – Thu Nov 21 01:36:55 2002 “GET / HTTP/1.0” – 2890 200

127.0.0.1 – – Thu Nov 21 01:37:20 2002 “GET /manual/index.html HTTP/1.0” – 5557 200

127.0.0.1 – – Thu Nov 21 01:37:24 2002 “GET /manual/mod/index-bytype.html HTTP/1.0” – 6186 200
tux2w3c 프로그램은 이진로그파일을 W3C 표준 웹서버 로그파일로 변환한다.

5단계. Gzip 압축하기


이미 TUX이 응답시간을 줄인다는 것을 안다. Gzip 압축을 사용하여 다운로드 시간을 줄이고 네트웍 전용량을 줄일 수도 있다. 그러나 이 기능을 사용하려면 클라이언트가 Gzip 압축을 지원해야 한다. TUX은 기본적으로 자료 압축을 하지않는다. 자료를 압축하려면 다음과 같다: 

# echo 1 > /proc/sys/net/tux/compression
시작할 때마다 적용하려면 다음 줄을 /etc/sysctl.conf에 추가한다 
net.tux.compression=1
또, 서비스하려는 페이지와 같은 디렉토리에 확장자가 .gz인 Gzip 파일이 있어야 한다.

6단계. TUX 가지고 놀기


아직 설정이 안끝났다. 몇몇 흥미로운 기능들이 남아있다. (일부는 RHCA v2.2에서만 가능하다.)


  • application_protocol
    1로 설정하면 RHCA FTP 서버를 돌린다. 기본값은 1이다.
  • virtual_server
    1이면 대량의 가상호스트를 가능하게 한다. 브라우저가 Hosts 헤더를 보내면 $DOCROOT/<Host>에 (가상 docroot) 직접 대응한다. 이렇게 성능을 떨어트리지않고도 TUX에서 여러 호스트를 서비스할 수 있다.
  • max_backlog
    TUX가 기다리는(listening) 소켓의 SYN backlog 최대값. SYN 공격을 피하기위해 적절히 설정해야 한다. 기본값은 2048이다.
  • http_dir_indexing
    1이면 index 파일이 없는 디렉토리의 경우 파일들을 보여준다. (index.html 자동생성)
TUX 웹서버 성능을 최대화하기위해 설정할 수 있는 항목들이 더많이 있다. 알아보고 용도에 맞게 수정하라.

7단계. TUX와 같이 사용할 아파치 설정하기


이미 말했듯이 TUX을 포트 80을 (기본 http 포트) 사용하는 앞단(front-end) 웹서버로 사용하고, 포트 8080에 TUX이 이해하지 못하는 요청을 (보통 PHP 페이지와 같이 동적으로 생성하는 내용) 처리할 뒷단 웹서버를 (여기서는 아파치를 예로 든다) 사용하길 추천한다. 이 경우 아파치 웹서버의 httpd.conf 파일을 수정해야 한다. 

다음 줄을

Port 80 


다음과 같이 수정한다

Port 8080 (아파치가 기다릴 포트)
또, 사용자가 TUX을 피해 직접 아파치에 접근하는 것을 막으려면 다음과 같이 수정한다. 보안상 이유로 필요할 수 있다. 
다음 줄을

BindAddress *


다음과 같이 수정한다

BindAddress 127.0.0.1 (loopback 주소)
마지막으로 httpd를 재시작한다 
# service httpd restart

8단계. TUX 디버깅과 재시작


다음 명령어로 TUX을 중단하고 재시작할 수 있다: 

# service tux stop (Red Hat 시스템의 경우)

혹은

# ./tux-init stop (Red Hat 시스템이 아닌 경우)


# service tux restart

혹은

# ./tux-init restart
디버깅을 위해 /usr/share/doc/tux-version/ 디렉토리에 있는 gettuxconfig 스크립트를 사용할 수 있다. SMP 시스템을 사용한다면 모든 네트웍 인터페이스가 checkbindings 스크립트를 사용하도록 설정되있는지 확인하라. 이 파일도 같은 디렉토리에 있다.

결론


이미 말했듯이 TUX은 동작의 일부를 사용자공간 대신 커널공간에 두어서 웹서버의 효율성을 높인다. 그래서 더 나은 성능을 얻고, 서버 자원을 더 잘 활용하게 된다. TUX은 많은 부분을 설정할 수 있고, 흥미로운 기능이 많다. 이 글이 재미있었길 바란다. 즐거운 해킹!!


참고자료


댓글 남기기