커피닉스, 시스템 엔지니어의 쉼터 - 커피향이 나는 LINUX/UNIX 세계

글쓴이 : 좋은진호 (


	[ 이전화면 / 수정 ] 비밀번호 :
	----------------------------------------------------------------------- 출처 : http://hlug.hanyang.ac.kr/ 제목 : 아파치를 최대 성능으로 끌어 올리기 위한 가이드 글쓴이 : 김진덕 날짜 : 2003/10/27 ----------------------------------------------------------------------- 1. httpd.conf A. config 에서 성능에 대한 요소들 i. KeepAlive Off 한번 connection 하면 바로 connection을 끊지 않고 유지를 하는 기능인데 Off를 해야 더 많은 client 들의 request 처리를 할 수 있다. KeepAlive On 상태이면 MaxKeepAliveRequests, KeepAliveTimeOut 값을 적절히 조절해야 된다. ii. Timeout 30 connection 시점부터 완료 될때까지의 최대 시간값 이다. network 이상이상 등으로 connection 환경이 비정적인 client connection 들이 많아지면 apache child process 새 connetcion 처리를 위해 계속 fork하게 될것이고 server의 과부하가 생긴다. iii. HostnameLookups Off apache 기본값은 Off 이며 On 으로 되어 있으면 connection하고 있는 cilent IP 주소가 역 추적되고 그 정보가 log file등에 쓰인다. 그렇기 때문에 성능에 좋지 않다. iv. FollowSymLinks Options FollowSymLinks 가 설정되어 있다면 symlinks에 대한 보안검사를 수행한다. symlinks에 대한 보안검사에 따라서 성능이 좋지 않게되며 불필요한 경우라면 설정하지 않는게 좋다. v. Options SymLinksIfOwnerMatch 설정되어 있다면 각 directory를 모두 점검해서 각각의 lstat system call을 하게 되므로 성능이 저하된다. vi. AllowOverride None AllowOverride all 로 설정된경우 모든 filename component에 대해서 .htaccess file을 열게된다. 이 file을 한번더 열게 됨으로서 성능이 좋지 않게 되며 이것이 필요없는 경우라면 AllowOverride None 을 사용해야 된다. vii. Negotiation DirectoryIndex index 처럼 wildcard를 사용 하는 것 보다 DirectoryIndex index.cgi index.pl index.shtml index.html 와 같이 complete list로 사용하는 것이 좋다. complete list 에서는 가장 먼저 선택되는 순으로 나열하는 것이 좋다. viii. MaxRequestsPerChild 0 apache child process가 memory leak 이 없고 사용자 module 로 작성한 부분이 견고하다고 판단되면 0 (unlimited)로 설정하는 것이 좋다. ix. Apache 2.0 Multi-Processing Modules 에 따른 Process Creation 1. prefork A. apache 1.3 의 계승(default) 된것이며 thread 를 지원하지 않는 Unix 계열을 위해 남겨둔 것이다. B. MinSpareServers, MaxSpareServers, StartServers 지시자를 적절히 조절해야 된다. C. MaxClients 수는 Client connection 이 너무 많다면 server의 spec에 따라 적절하게 제한 해야 한다. 2. worker A. parent 로 부터 fork 된 child process는 고정된 숫자의 thread 를 가지고 있으며 StartServer에 지정된 숫자 만큼 child process 생성한다. B. ThreadPerChild 에 고정된 숫자 만큼 child process 내 Thread 개수 생성 C. StartServer × ThreadPerChild 숫자만큼의 Thread가 Server Start시에 생성되고 request에 따라 MaxClient 값까지 증가 한다. D. 각각의 thread 들은 connection들의 listen 과 serve 를 한다. E. request 가 늘어나면 parent 는 child process 를 fork 하여 ThreadPerChild에 지정된 숫자 만큼의 thread 를 생성한다. request 가 늘어나면 parent 는 child process 를 kill 하여 child process 내에 있던 thread를 한꺼번에 kill 한다. MaxSpareThreads, MinSpareThreads 지시자 사용하여 적절히 조절해야 한다 F. apache 2.0.35 test 결과로는 child process 를 늘이고 child process 내에 thread 숫자를 줄이는 것이 더 성능이 좋았는데 이유는 thread 간의 경합문제가 생기는 것으로 판단된다. 2. modules compile 시 포함되는 불 필요한 module을 없애서 fork 및 불필요한 system call 의 부하를 줄인다. A. Core Features and Multi-Processing Modules i. core basic server operation을 위해서 꼭 필요하다. ii. mpm_common multi-processing module (MPM) 을 위한 common module iii. MPM module 로서 각 OS에 따라서 1개만 포함 되게 된다. 1. mpm_netware Novell NetWare 를 위한 multi-processing module 2. mpm_winnt Windows NT 를 위한 multi-processing module 3. perchild 각각의 process 들이 다양한 다른 userid 를 가지고 serving 을 할 수 있는 multi-processing module 이며 실험 단계 이다. 4. prefork apache 1.3 의 pre-forking web server 의 계승된 multi-processing module 5. worker hybrid multi-threaded multi-process web server 를 구현한 multi-processing module B. Other Modules i. mod_access , , sections 및 .htaccess files 에 clinet 의 hostname, ip 들을 가지고 access control을 위해서 필요하다. ii. mod_actions CGI scripts 실행이 필요하다면 필요하다. iii. mod_alias URL redirection 이나 Alias ScriptAlias 을 위해 필요하다. iv. mod_asis HTTP header 와 함께 file 내용을 그대로 보낼 때 쓰인다. 불 필요 하다. v. Authentication 에 대한 modules Authentication 에 대한 기능이 필요 없으면 모두 불 필요하다. 1. mod_auth, mod_auth_dbm HTTP basic authentication 으로서 인증에 관한 정보를 text file 등에 저장 할수 있고 mod_auth_dbm 을 통해서 DBM 등에 저장될수도 있다. 인증에 관련 없으면 불 필요. 2. mod_auth_anon FTP 스타일 처럼 "anonymous" user access 를 authenticated areas 에 접근하게 할수 있다. 3. mod_auth_digest MD5 Digest Authentication 지원. 인증에 관련 없으면 불필요 하다. vi. mod_autoindex ls및 dir 명령처럼 directory내의 file들을 정렬해서 나오게 해줄 때 쓰인다. 불필요하다. vii. mod_cgi CGI scripts 실행을 위해서 필요하다. viii. mod_deflate content 압축 지원 (정책상 content 압축을 하기 때문에 필요 할 수 있다.) ix. mod_dir directory index files 을 지원 불필요. x. mod_env CGI scripts 와 SSI pages 에 system 환경 변수 제공 불 필요. xi. mod_imap server 처리 image map으로 처리하기 위해 쓰이며 불 필요. xii. mod_include Server Side Includes (SSI) 처리를 위해서 쓰이며 불 필요. xiii. mod_log_config Logging 위해서 필요하다. xiv. mod_mime content (mime-type, language, character set, encoding) 및 file의 특성에 따라 특정 type 으로 처리하기 위해서 꼭 필요하다. xv. mod_negotiation content negotiation 에 필요하다. xvi. mod_proxy HTTP/1.1 proxy 기능에 필요. xvii. mod_setenvif request의 browser 특성에 따른 서로 다른 script 를 접근하게 하거나 환경 변수를 지정하게 할수있다. BrowserMatch 등의 지지사를 사용하기 위해서 필요하다. xviii. mod_so shared object 형태의 동적인 apache modules 이 있다면 필요하다. xix. mod_ssl Secure Sockets Layer (SSL) 와 Transport Layer Security (TLS) protocols 을 사용한다면 필요하다. xx. mod_status server activity 및 performance 정보들을 moniter 하기 위해서 필요. xxi. mod_userdir 사용자 계정을 이용하여 home page 를 제공 한다. 불 필요 하다. 3. MaxClient 수를 위한 source 수정 A. apahce 1.3 apache_1.3.x/src/include/httpd.h 의 에서 HARD_SERVER_LIMIT 256 B. apache 2.0 i. prefork httpd-2.0.36/server/mpm/prefork/prefork.c DEFAULT_SERVER_LIMIT 256 ii. worker httpd-2.0.36/server/mpm/worker/worker.c DEFAULT_SERVER_LIMIT 16 DEFAULT_THREAD_LIMIT 64 ----------------------------------------------------------------------- 제목 : [re] 아파치를 최대 성능으로 끌어 올리기 위한 가이드 글쓴이 : 김진덕 날짜 : 2003/10/28 ----------------------------------------------------------------------- KeepAlive 에 대해서 On 을 해야 성능이 더 좋은지 Off 를 해야 성능이 더 좋은지 논란이 많습니다. 그러나 환경에 따라서 많이 틀립니다. 한정된 사람이 주기적으로 계속 접속할때... 예를 들어 그룹웨어같이 한정된 IP 에서 접속할땐 KeepAlive 를 On 을 해야 성능이 좋습니다. 왜냐면 TCP/IP 의 3 웨이 핸드 세이킹 부하를 KeepAlive 시간 동안 조금 줄여줍니다. 그러나 매번 접속할때마다 랜덤하게 어떠한 IP에서 접속할지 모르고 또한 접속후에 하나의 리퀘스트만 처리하고 또 올 필요가 없는 서버에선 KeepAlive Off 가 성능이 더 좋습니다. 초당 컨넥션이 많지 않다면 거의 차이 없습니다. 아파치의 가장 취약점 공격은 Slow Get 공격입니다. 분산 DOS 공격보다 더욱더 강력한 이 공격을 피하실려면 Timeout 값을 매우 많이 줄여야 합니다. Slow GET 공격의 원리는 아파치에 요청을 걸고 Timeout 동안 아무일 하지 않고 있다가 Timeout에 의해 컨넥션이 끊어질려고 할때 조금씩 요청을 보냅니다. 이렇게 되면 하나의 요청을 처리하느냐 아파치 프로세스는 이 요청을 잡고 있는 시간이 늘어나고 계속 이런식의 요청을 보내면 아파치의 모든 프로세스는 계속 포킹하여 MaxClient 까지 차게 됩니다. 정상적인 접속이 들어오면 MaxClient 값이 넘어가서 처리를 못하게 됩니다... 즉 아파치 프로세스 회전율을 떨어뜨리게 하는 공격이죠... 클라이언트 네트웍 환경이 불안정한 TCP 접속이 많을 경우엔 Slow Get 공격처럼 보일수도 있습니다. Slow Get 공격 소스는 원하시는 분은 제가 오픈해드릴께요... 아파치를 쓰고 마음에 안드는 사이트는 이 툴로 공격하면 서비스를 전혀 하지 못합니다. 그러나 공격지의 IP 가 남기 때문에 완벽한 트릭은 할수가 없네요... 요즘 네트웍 장비들이 좋아서 공격지의 IP 가 불분명하면 패킷을 버리기 때문에... IP 스푸핑 기법을 이용하여 소스 IP 를 속이는 기법도 있지만... 이런 기법들은 요즘 의미 없는 기법들입니다. Slow Get 공격을 피하고자 아파치 라이브러리 소스를 약간 수정하는일을 한적 기억이 나네요. 한때 이 공격으로 서비스를 전혀 못하던 악몽이...