[출처] http://free4u.dnip.net/weblog/9948#1

1. 소개

http에 ssl을 이용한 https가 있듯이 ftp에도 ssl을 이용한 FTPS (FTP over SSL/TLS)가 있습니다.
ftps에 대해 기술되어 있는 rfc4217의 링크입니다.
http://www.faqs.org/rfcs/rfc4217.html

2. 설치

proftpd에서는 ftps를 지원하는 mod_tls가 있습니다. mod_tls는 proftpd 1.2.x이상에서 지원하고 기본으로 포함되지 않습니다.
즉 이미 proftpd가 설치되어 있다면 mod_tls를 다시 집어넣고 proftpd를 다시 컴파일해야 한다는 거죠.
shared 모듈로 설치하고자 한다면 configure시  --with-shared=mod_tls를 추가후 컴파일하면 됩니다.

또는 김정균님이 운영하는 http://oops.org 에서 배포하는 proftpd를 설치했다면 기본으로 설치가 됩니다.
proftpd의 설정파일에 한글설명도 포함되어 있습니다. 편리한쪽으로 사용하시면 되겠습니다. emoticon

proftpd roadmap에 따르면 apache서버의 apxs처럼 원소스가 없어도 특정모듈을 proftpd설치이후 추가로
설치할수 있게 할 예정이라고 합니다. 빨리 안정버전에 포함되었으면 좋겠네요.


% cvs를 확인해보니 며칠전에 추가되었네요!emoticon
파일명이 prxs군요. apache에서 사용하는 apxs와 비슷(proftpd의 모토가 like apache라 역시나)하네요.

mod_tls에서 사용되는 인증서도 웹서버에서 사용되는 인증서와 마찬가지로 자체서명인증으로 테스트 해볼수 있습니다.
http://free4u.dnip.net/weblog/9813

3. 설정

proftpd tls mini howto : http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-TLS.html
proftpd mod_tls : http://www.castaglia.org/proftpd/modules/mod_tls.html

아래설정은 proftpd tls mini howto인데 위링크와 몇가지 다른점이 있으니 참고하시기 바랍니다.

Example mod_tls configuration:

 <IfModule mod_tls.c>
    TLSEngine on
TLSLog /path/to/logfile
# TLSProtocol은 SSLv2를 제외한 SSLv1과 SSLv3를 사용한다.
# SSLv2의 경우 Processing Buffer Overflow로 인해 사용을 권장하지 않는다.
# 참고링크:
http://secunia.com/advisories/24253/
# sslv1과 sslv3를 동시 지원하기 위해 아래처럼 설정한다.
TLSProtocol SSLv23

# Are clients required to use FTP over TLS when talking to this server?
TLSRequired off

# 몇몇 ftp client의 문제로 인해 설정해둠.
TLSOptions NoCertRequest

# Server's certificate
# 아래설정은 웹서버의 ssl인증을 위해 만들어둔 키파일을 가져다 사용할수 있다.
# 자체서명인증도 사용가능
TLSRSACertificateFile /pat/to/server.cert.pem
TLSRSACertificateKeyFile /path/to/server.key.pem

# CA the server trusts
TLSCACertificateFile /path/to/root.cert.pem

# Authenticate clients that want to use FTP over TLS?
TLSVerifyClient off

# Allow SSL/TLS renegotiations when the client requests them, but
# do not force the renegotations. Some clients do not support
# SSL/TLS renegotiations; when mod_tls forces a renegotiation, these
# clients will close the data connection, or there will be a timeout
# on an idle data connection.
TLSRenegotiate required off

</IfModule>

4. 설정확인

아래 그림(?)은 FTPS (FTP over SSL/TLS)를 지원하는 ftp client에서 auth_tls 또는 명시적 FTPS - FTP/SSL (Explicit) 설정후
접속한 화면입니다.

ftp client마다 다른이름으로 설정하게 되어 있으니 확인후 테스트 해보셔야 할것 같습니다.

auth_tls.jpg

FTPS (FTP over SSL/TLS)를 지원하는 ftp client 목록은 아래링크에서 확인할수 있습니다.
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html#client


FTPS의 경우 서버 설정 혹은 ftp client설정에 따라 control channel또는 data channel로 분리해 ssl연결을 적용하는 방법도
가능한데 그부분은 다음에 작성해 포스팅 해보도록 하겠습니다. emoticon
이올린에 북마크하기(0) 이올린에 추천하기(0)
Posted by 백성용 헬로우보이

[출처] http://free4u.dnip.net/weblog/?mid=blog&category=528&document_srl=10026

apache 2.x대의 mod_deflate 를 사용하고 있었고 다른설정 테스트중 deflate log를 남겨 확인해보니 javascript파일이
압축이 안된채 클라이언트에게 서비스 되는것이 확인되었습니다.

apache의 소스파일에 첨부된 mime.types파일의 내용중 javascript 정의(?)에 관한것이 apache버전별로 약간 차이가
있더군요.  javascript정의 차이점은 아래를 참고하세요.

apache 1.3.x
application/x-javascript    js

apache 2.0.x
application/javascript    js

apache 2.2.x
application/javascript   js

apache 2.2.x와 mod_deflate모듈을 사용하고 AddOutputFilterByType설정으로 특정 파일형식을 압축전송하고자 할때
(아래 예제는 javascript의 예) apache 버전에 맞는 mime type을 적용해야 설정대로 동작하게 됩니다.

AddOutputFilterByType DEFLATE application/javascript

mime.types에 정의된 javascript설정과 httpd.conf의 deflate모듈 설정중 javascript의 정의가 다를경우 압축전송이 되질
않습니다. 로그는 아래를 참고하세요.

123.456.789 GET /gallery/scripts.js HTTP/1.1 [date +0900] -/- (-%)
http://free4u.dnip.net/gallery/ Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;)
압축율 부분이 -% 이렇게 표시되고 압축이 되지 않은 상태로 전송됩니다.


다음로그는 제대로 설정되었을때 남은 로그입니다.
123.456.789 GET /gallery/scripts.js HTTP/1.1 [date +0900] 1383/5209 (26%)
http://free4u.dnip.net/gallery/ Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;) 
파일 사이즈와 1383/5209  압축율(26%)이 정확히 기록이 되는군요.


apache버전에 따른 mime type의 변화로 인해 기존 버전(apache 1.3.x, apache 2.0.x)의 설정을 그대로 유지할경우
문제가 생길수 있으니 mime type을 확인후 설정을 테스트 해보는것이 좋겠습니다.

apache 2.0.x와 apache 2.2.x의 mime.types파일은 정확히 같은 파일이고 차이점은 없습니다.
이올린에 북마크하기(0) 이올린에 추천하기(0)
Posted by 백성용 헬로우보이

아파치 2 최적화

웹 서비스의 성능 최적화는 웹서버에서의 튜닝과 웹 브라우져, 웹 콘텐츠 그리고 다른 시스템과의 관계 등을 동시에 다루어야 하지만 자바스크립트, 웹 그래픽, HTML, CSS 등의 최적화에 대한 것은 이 글에서 취급하지 않는다. 필자는 http://www.websiteoptimization.com/ 에서 그런 정보들을 얻을수 있었다.

이 글은 아파치 웹 서버의 최적화에 대해서만 다루고 있으므로, 그 외의 다른것들과 통합해서 웹 서비스 성능 개선 방안을 마련하는 것은 여러분의 몫이다.


<필자소개>

성명 : 박성수

“리눅스포털” www.superuser.co.kr 대표

중소기업연수원 객원교수

한국정보통신인력개발센터 전문위원

--------------------------------------------------

1회|2005. 7|아파치 2 최적화

--------------------------------------------------

필자소개 

필자는 현재까지 “리눅스포털” www.superuser.co.kr의 대표 운영자로서 활동하고 있고 약 10년간 서버관리를 해왔으며, 그리고 리눅스 서버관련 전문서 집필 및 리눅스 강의를 주로 하고있다.  필자의 가장 큰 꿈이자 희망이라고 한다면 대한민국에서 리눅스가 아무런 제약없이 사용되어지는 것이다. 현재는 이런 문제에 관심을 가지고 나름대로 활동하고 있다.


발문

서버관리 업무에서 가장 큰 관심거리 두가지를 들라고 한다면 안전한 시스템구현을 위한 보안문제와 성능 최적화 및 향상을 위한 튜닝문제일 것이다.  이번강좌에서 필자는 현재 웹서버로써 가장 많이 사용되고 있는 아파치의 성능향상을 위한 튜닝방법에 대하여 실무적인 접근을 해보고자 한다.  이번 강좌에서 언급하지 아니한 많은 부분의 튜닝방법(예: H/W튜닝, 운영체제튜닝등)들이 있기는 하지만 이번 강좌는 순수하게 아파치웹서버 자체에 대한 튜닝임을 밝혀둔다.


필자는 리눅스 시스템 관리자이다.

시스템 관리자란 어떤일을 하는가? 서버가 언제 어떻게 될지 모르는 상황에서 자기시간 이라는 개념이 없으며, 끊임없이 발생하는 취약성들에 대한 점검과 패치, 고객의 각종 문제들, 손실된 데이터 복구 문제 등 늘 긴장속에서 살아가야한다.

시스템 관리자라는 직업이 의미하는 바는 여기서 그치지 않는다.

시스템 유지보수, 성능 관리, 가용성 관리, 용량 관리, 장애 복구 등 시스템 관리자라면 대게 이 정도의 항목들을 관리하게 된다. 다른 분야 역시 마찬가지 이겠지만 시스템 관리자라는 업무는 끊임없는 자기 개발과 노력을 요구한다.

이 글에서는 시스템 관리자의 이런 개발과 노력에 도움이 되고자 리눅스로 운영하는 아파치 웹서버의 최적화에 관해서 다루기로 한다.


아파치 성능 테스트 계획


테스트 환경

OS  : Red Hat Enterprise Linux AS release 4 (Nahant)

Kernel Version : 2.6.9-5.ELsmp

CPU & Cache : 2 Xeon(TM) CPU 3.06GHz 3057MHz, 512 KB Cache

Memory :  2G

Swap : 4G

Web server : Apache Http Server 2.0.52

Web test tool : ab, Httperf, flood


테스트 계획

rpm 설치후 기본 상태에서 설치된 웹서버에 동시 접속자 1000 명이 1000 번의 요청을 하는 경우를 테스트하여 웹서버의 성능을 측정한다.

다양한 환경설정을 변경해서 웹서버를 튜닝한 이후 다시 동일한 환경으로 테스트해서 실제적인 성능향상이 있는지를 점검한다.


테스트 케이스

1) ab -n 1000 -c 1000 -t 10 http://210.183.235.95/

2) httperf --server 210.183.235.95 --port 80 --rate 1000 --num-conns 20000 --hog

3) flood floodconf..xml > result.out (floodconf.xml 파일에 환경설정)

기본설치후 아파치 성능 테스트


웹사이트가 느리면 고객은 바로 다른 사이트로 이동하기 마련이다.

따라서 기업은 고객을 확보, 유지하기 위해 웹사이트의 성능을 최상의 상태로 유지해야하며 이로 인해 웹사이트의 성능을 진단하고 분석하는 도구들에 대해서 많은 관심을 가지고 있으며 현재 기업들마다 다양한 방법들로 성능을 관리하고 있다.

상용 SW

공개 SW

WEBest

SiteAngel 

sitemonitor

WatchPro/TestPro 

WEBest

ab

Flood

Httperf

Hammerhead

Web Performance Tool (WPT)

표 1. <웹서버 성능테스트 프로그램 비교>


웹서버의 성능을 측정하기 위해서 먼저 공개SW 벤치마크 프로그램 ab, Flood, Httperf 에 대해서 알아보기로 하자.


ab

ab는 "Apache HTTP server Benchmarking tool" 의 약어로서 아파치서버의 응답속도를 측정하는 밴치마킹툴이다. 이 툴은 현재 설치된 아파치서버의 실행속도 및 성능테스트를 위해서 제우스테크널리지(Zeus Technology Ltd, http://www.zeustech.net/)의 Adam Twiss가 개발한 툴이며. 아파치를 설치하고 나면 기본적으로 설치되므로 별도의 설치 과정 없이 바로 사용할 수 있다.

명령어위치: /usr/local/apache/bin/ab            

(RPM설치시 : /usr/bin/ab)


아래는 ab를 이용해서 -c(한번에수행할 다중요구수) 값을 1000으로하고, -n(페이지요청수) 값을 1000 으로 하였으며 -t(테스트허용 최대시간)값을 10으로 주는 예이다.


[root@www ~]# ab -c 1000 -n 1000 -t 10 http://210.183.235.95/

This is ApacheBench, Version 2.0.41-dev <$Revision: 1.141 $> apache-2.0

Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/


Server Software:        Apache/2.0.52

Server Hostname:        210.183.235.95

Server Port:            80


Document Path:          /

Document Length:        440 bytes


Concurrency Level:      1000

Time taken for tests:   10.6038 seconds

Complete requests:      13416

Failed requests:        0

Write errors:           0

Total transferred:      8176434 bytes

HTML transferred:       5907440 bytes

Requests per second:    1340.79 [#/sec] (mean)

Time per request:       745.829 [ms] (mean)

Time per request:       0.746 [ms] (mean, across all concurrent requests)

Transfer rate:          797.92 [Kbytes/sec] received


Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        1  286 1301.0      4    9005

Processing:    21  148 467.1     95    6437

Waiting:       17  135 424.3     87    6434

Total:         57  434 1457.6    108    9703


Percentage of the requests served within a certain time (ms)

  50%    108

  66%    120

  75%    127

  80%    135

  90%    179

  95%   3076

  98%   9068

  99%   9076

 100%   9703 (longest request)


ab 의 측정결과에서 다음과 같은 내용을 분석할수 있다.

Server Software

아파치버전을 표시

Server Hostname

특정사이트의 이름(도메인명)

Server Port

웹서비스 사용포트번호

Document Path

초기 문서가 준재하는 웹문서 root위치

Time take for tests

응답시간(매우 중요한 결과 값임)

Document Length

초기문서(대부분 index.html, index.htm)의 용량크기

Complete requests

요구에 응답완료한 세션수

Failed requests

요구에 응답실패한 세션수

Broken pipe errors

실패한 에러수

Total transferred

총 전송바이트수

HTTP transferred

총 전송한 HTML바이트수

Requests per second

초당응답요구수

Time per request

요구에 응답한 시간(단위 micro second, 중요한 결과값)

Time per request

요구에 응답한 시간

Transfer rate

초당전송가능한 용량

표 2. <ab 의 결과분석>



Httperf


Httperf 툴은 요청이 발생하는 비율, 총 연결 수, 타임아웃 한계 등을 제어할 수 있다.

다운로드는 http://www.hpl.hp.com/research/linux/httperf/ 에서 가능하며 설치는 일반적인 소스설치법과 동일하게 ./configure ; make; make install 로 진행할수 있다.

사용할 수 있는 옵션은 아래와 같다

--server 서버주소

여기에 적어 준 서버로 접속을 시도한다

--port 숫자

여기에 적어 준 포트로 접속을 시도한다

--num-conns 숫자

총 몇개의 접속을 만들 것인지를 결정한다.

--rate 숫자

초당 몇개의 접속을 만들 것인지를 결정한다.

--timeout 숫자

숫자만큼의 초 이후 응답이 없는 연결은 timeout 에러로 처리한다.

--think-timeout 숫자

CGI등 서버쪽에서 처리해야 하는 일들이 있는 페이지의 경우 서버측에 이를 처리할 시간을 준다. timeout에서 이곳에 주어진 숫자만큼을 더한 값이 진짜 timeout값이 된다.

--hog

가능한 모든 포트를 사용한다. 이 옵션을 주지 않으면 기본적으로 1024부터 5000까지의 포트만 사용한다.

표 3.<httperf 의 주요옵션>


아래 예제는 210.183.235.95 웹서버의 80번 포트로 1초에 1000개씩 총 20000개의 접속을 만들게 된다.

[root@www ~]# httperf --server 210.183.235.95 --port 80 --rate 1000 --num-conns 20000 --hog

httperf --hog --client=0/1 --server=210.183.235.95 --port=80 --uri=/ --rate=1000 --send-buffer=4096 --recv-buffer=16384 --num-conns=20000 --num-calls=1

Maximum connect burst length: 8


Total: connections 20000 requests 20000 replies 20000 test-duration 20.000 s


Connection rate: 1000.0 conn/s (1.0 ms/conn, <=540 concurrent connections)

Connection time [ms]: min 0.3 avg 70.5 max 3006.4 median 1.5 stddev 422.3

Connection time [ms]: connect 60.8

Connection length [replies/conn]: 1.000


Request rate: 1000.0 req/s (1.0 ms/req)

Request size [B]: 65.0


Reply rate [replies/s]: min 978.7 avg 1000.0 max 1021.5 stddev 17.5 (4 samples)

Reply time [ms]: response 9.6 transfer 0.0

Reply size [B]: header 169.0 content 440.0 footer 0.0 (total 609.0)

Reply status: 1xx=0 2xx=20000 3xx=0 4xx=0 5xx=0


CPU time [s]: user 3.83 system 14.57 (user 19.2% system 72.9% total 92.0%)

Net I/O: 658.2 KB/s (5.4*10^6 bps)


Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0

Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0


Flood - a profile-driven HTTP load tester

Flood 는 아파치 프로젝트 하위의 프로젝트이다

XML 설정파일을 필요로 하며, URL 과 POST data 를 여러 서버들에 테스트할수 있다.


현재 Flood 는 Subversion 으로 관리되고 있으며 설치시에 자동으로 소스 디렉토리 하위에서 apr 과 apr-util 패키지를 찾으므로 아래처럼 체크아웃해서 설치하면 된다.

만일 apr 과 apr-util을 이미 받아온 상태라면  configure 할때 --with-apr and --with-apr-util 옵션을 사용해서 경로를 지정해주면 된다


 % svn co http://svn.apache.org/repos/asf/httpd/test/trunk/flood

 % cd flood

 % svn co http://svn.apache.org/repos/asf/apr/apr/trunk apr

 % svn co http://svn.apache.org/repos/asf/apr/apr-util/trunk apr-util


 % ./buildconf

 % ./configure --disable-shared

 % make all

설치가 정상적으로 진행되었으면 설치한 디렉토리에서 아래처럼 확인할수 있다

 % ./flood examples/round-robin.xml > foo.out


결과 파일을 다른프로그램에서 활용하고 싶은 경우는 

% ./examples/analyze-relative foo.out 를 실행해보면 참고할수 있다.

analyze-relative 파일은 테스트 결과값을 가공하는 간단한 스크립트이다.


Flood 에 대해서 보다 상세한 정보를 원한다면 http://httpd.apache.org/test/flood/faq.html 를 방문하자.

아래는 floodconf.xml 파일을 이용해서 테스트 하는 부분이다. xml형식의 환경설정 파일을 설정하는 방법은 http://httpd.apache.org/test/flood/ 를 방문해서 참고하기 바란다.


[root@www ~]# flood floodconf.xml > result.out

[root@www ~]# ./analyze-relative result.out

Slowest pages on average (worst 5):

   Average times (sec)

connect write   read    close   hits    URL

0.0018  0.0019  0.0081  0.0082  29126   http://210.183.235.95/

Requests: 29127 Time: 0.80 Req/Sec: 41776.74




설정변경을 통한 아파치 성능 최적화