diff options
| author | Andr챕 Malo <nd@apache.org> | 2004-04-25 22:53:17 +0000 |
|---|---|---|
| committer | Andr챕 Malo <nd@apache.org> | 2004-04-25 22:53:17 +0000 |
| commit | 4bbda0d8a4749de151ac4175c6dce61cc73e8006 (patch) | |
| tree | 0f74dc1d4d1261b2852e95641ea3b1ec67e345c9 /docs/manual/misc | |
| parent | 060deccba8f9847cba4f48ac76f05ac5f7be5c1f (diff) | |
| download | httpd-4bbda0d8a4749de151ac4175c6dce61cc73e8006.tar.gz | |
update transformation
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@103525 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'docs/manual/misc')
20 files changed, 3550 insertions, 12 deletions
diff --git a/docs/manual/misc/perf-tuning.html b/docs/manual/misc/perf-tuning.html index 1078a1bed4..5eaaf7158e 100644 --- a/docs/manual/misc/perf-tuning.html +++ b/docs/manual/misc/perf-tuning.html @@ -1,3 +1,7 @@ URI: perf-tuning.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: perf-tuning.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR diff --git a/docs/manual/misc/perf-tuning.html.en b/docs/manual/misc/perf-tuning.html.en index 8f2d21e5f6..166d43c35f 100644 --- a/docs/manual/misc/perf-tuning.html.en +++ b/docs/manual/misc/perf-tuning.html.en @@ -18,7 +18,8 @@ <div id="path"> <a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.1</a> > <a href="./">Miscellaneous Documentation</a></div><div id="page-content"><div id="preamble"><h1>Apache Performance Tuning</h1> <div class="toplang"> -<p><span>Available Languages: </span><a href="../en/misc/perf-tuning.html" title="English"> en </a></p> +<p><span>Available Languages: </span><a href="../en/misc/perf-tuning.html" title="English"> en </a> | +<a href="../ko/misc/perf-tuning.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p> </div> @@ -1047,7 +1048,8 @@ </div></div> <div class="bottomlang"> -<p><span>Available Languages: </span><a href="../en/misc/perf-tuning.html" title="English"> en </a></p> +<p><span>Available Languages: </span><a href="../en/misc/perf-tuning.html" title="English"> en </a> | +<a href="../ko/misc/perf-tuning.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p> </div><div id="footer"> <p class="apache">Copyright 1999-2004 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p> <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div> diff --git a/docs/manual/misc/perf-tuning.html.ko.euc-kr b/docs/manual/misc/perf-tuning.html.ko.euc-kr new file mode 100644 index 0000000000..617edc5fc6 --- /dev/null +++ b/docs/manual/misc/perf-tuning.html.ko.euc-kr @@ -0,0 +1,974 @@ +<?xml version="1.0" encoding="EUC-KR"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml" lang="ko" xml:lang="ko"><head><!-- + XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX + This file is generated from xml source: DO NOT EDIT + XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX + --> +<title>아파치 성능향상 - Apache HTTP Server</title> +<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" /> +<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" /> +<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /> +<link href="../images/favicon.ico" rel="shortcut icon" /></head> +<body id="manual-page"><div id="page-header"> +<p class="menu"><a href="../mod/">모듈</a> | <a href="../mod/directives.html">지시어들</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">용어</a> | <a href="../sitemap.html">사이트맵</a></p> +<p class="apache">Apache HTTP Server Version 2.1</p> +<img alt="" src="../images/feather.gif" /></div> +<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div> +<div id="path"> +<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.1</a> > <a href="./">Miscellaneous Documentation</a></div><div id="page-content"><div id="preamble"><h1>아파치 성능향상</h1> +<div class="toplang"> +<p><span>가능한 언어: </span><a href="../en/misc/perf-tuning.html" hreflang="en" rel="alternate" title="English"> en </a> | +<a href="../ko/misc/perf-tuning.html" title="Korean"> ko </a></p> +</div> + + + <p>아파치 2.0은 기능과 포팅가능성과 성능의 균형이 맞도록 + 설계한 범용 웹서버이다. 벤치마크 기록을 세우기위해 설계하지 + 않았지만 아파치 2.0은 실제 많은 경우 높은 성능을 낸다.</p> + + <p>아파치 1.3과 비교해서 2.0 버전은 처리량과 확장성(scalability)을 + 높이기위해 많은 최적화를 했다. 기본값으로 대부분 최적화한 + 값을 사용한다. 그러나 컴파일시 혹은 실행시 설정이 성능에 + 큰 영향을 줄 수 있다. 이 문서는 아파치 2.0의 성능을 향상하기위해 + 서버 관리자가 설정할 수 있는 옵션을 설명한다. 어떤 설정 + 옵션은 웹서버가 하드웨어와 운영체제의 기능을 더 잘 활용하도록 + 하는 반면, 어떤 옵션은 속도를 위해 기능을 희생한다.</p> + + </div> +<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#hardware">하드웨어와 운영체제에 대해서</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#runtime">실행시 설정에 대해서</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#compiletime">컴파일시 설정에 대해서</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#trace">부록: 시스템호출 기록을 자세히 분석하기</a></li> +</ul></div> +<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="hardware" id="hardware">하드웨어와 운영체제에 대해서</a></h2> + + + + <p>웹서버 성능에 가장 큰 영향을 주는 것은 메모리다. 스왑은 + 요청당 지연시간을 사용자가 "충분히 빠르다고" 생각하지 못하게 + 늘리기때문에 웹서버는 스왑을 하면 안된다. 느려지면 사용자는 + 정지하고 다시 접속하여 부하가 계속 증가한다. <code class="directive"><a href="../mod/mpm_common.html#maxclients">MaxClients</a></code> 지시어를 조절하여 + 웹서버가 스왑을 할 정도로 많은 자식을 만들지않도록 해야 + 한다. 방법은 간단하다: <code>top</code>과 같은 도구에서 + 프로세스 목록을 보고 아파치 프로세스의 평균 메모리 사용량을 + 알아낸후, 전체 사용가능한 메모리에서 다른 프로세스들이 사용할 + 공간을 뺀 값에서 나눈다.</p> + + <p>나머지는 평범하다: 충분히 빠른 CPU, 충분히 빠른 네트웍카드, + 충분히 빠른 디스크, 여기서 "충분히 빠른"은 실험을 해서 결정해야 + 한다.</p> + + <p>운영체제는 보통 각자 알아서 선택할 일이다. 그러나 일반적으로 + 유용하다고 판명된 몇가지 지침이 있다:</p> + + <ul> + <li> + <p>선택한 운영체제의 최신 안정 버전과 패치를 실행한다. + 많은 운영체제 제작사는 최근 TCP 스택과 쓰레드 라이브러리에 + 많은 속도향상을 했다.</p> + </li> + + <li> + <p>운영체제가 <code>sendfile(2)</code> 시스템호출을 + 지원한다면, 이를 사용하기위한 버전이나 패치를 설치하였는지 + 확인한다. (예를 들어, 리눅스라면 2.4 이상 버전을 뜻한다. + Solaris 8 초기 버전은 패치가 필요하다.) 지원하는 시스템이라면 + 아파치 2는 <code>sendfile</code>을 사용하여 CPU를 덜 + 사용하며 정적 파일을 더 빨리 전송할 수 잇다.</p> + </li> + </ul> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="runtime" id="runtime">실행시 설정에 대해서</a></h2> + + + + <table class="related"><tr><th>관련된 모듈</th><th>관련된 지시어</th></tr><tr><td><ul><li><code class="module"><a href="../mod/mod_dir.html">mod_dir</a></code></li><li><code class="module"><a href="../mod/mpm_common.html">mpm_common</a></code></li><li><code class="module"><a href="../mod/mod_status.html">mod_status</a></code></li></ul></td><td><ul><li><code class="directive"><a href="../mod/core.html#allowoverride">AllowOverride</a></code></li><li><code class="directive"><a href="../mod/mod_dir.html#directoryindex">DirectoryIndex</a></code></li><li><code class="directive"><a href="../mod/core.html#hostnamelookups">HostnameLookups</a></code></li><li><code class="directive"><a href="../mod/core.html#enablemmap">EnableMMAP</a></code></li><li><code class="directive"><a href="../mod/core.html#enablesendfile">EnableSendfile</a></code></li><li><code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code></li><li><code class="directive"><a href="../mod/prefork.html#maxspareservers">MaxSpareServers</a></code></li><li><code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code></li><li><code class="directive"><a href="../mod/core.html#options">Options</a></code></li><li><code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code></li></ul></td></tr></table> + + <h3><a name="dns" id="dns">HostnameLookups와 DNS에 대해 고려할 점들</a></h3> + + + + <p>아파치 1.3 이전에 <code class="directive"><a href="../mod/core.html#hostnamelookups">HostnameLookups</a></code>의 기본값은 + <code>On</code>이였다. 요청을 마치기전에 DNS 검색이 끝나야 + 하므로 요청마다 지연이 생겼다. 아파치 1.3에서 이 설정의 + 기본값이 <code>Off</code>로 변경되었다. 로그파일의 주소를 + 호스트명으로 변환하려면 여러 로그처리 프로그램중 하나인, + 아파치에 포함된 <a href="../programs/logresolve.html"><code>logresolve</code></a> + 프로그램을 사용하라.</p> + + <p>로그처리 작업이 서버 성능에 악영향을 미치므로 실제 + 사용하는 웹서버가 아닌 다른 컴퓨터에서 로그파일을 후처리하길 + 바란다.</p> + + <p><code><code class="directive"><a href="../mod/mod_access.html#allow">Allow</a></code> + from domain</code>이나 <code><code class="directive"><a href="../mod/mod_access.html#deny">Deny</a></code> from domain</code> + 지시어를 사용한다면 (즉, IP 주소가 아닌 호스트명이나 도메인명을 + 사용한다면) 부득이 중복-역 DNS 검색을 (역검색을 한후 악의로 + 변경되었는지 확인하기위해 다시 검색) 해야 한다. 그러므로 + 성능을 높이기위해 이런 지시어에는 가능하면 이름대신 IP + 주소를 사용한다.</p> + + <p><code><Location /server-status></code> 섹션 등으로 + 지시어의 적용범위를 제한할 수 있음을 기억하라. 이 경우 + 조건에 맞는 요청에만 DNS 조회를 한다. 다음은 + <code>.html</code>과 <code>.cgi</code> 파일만 DNS 검색을 + 하는 예제다:</p> + + <div class="example"><p><code> + HostnameLookups off<br /> + <Files ~ "\.(html|cgi)$"><br /> + <span class="indent"> + HostnameLookups on<br /> + </span> + </Files> + </code></p></div> + + <p>그러나 CGI에서 DNS명이 필요할 뿐이라면, 필요한 특정 + CGI에서만 <code>gethostbyname</code> 호출을 하도록 고려해볼 + 수 있다.</p> + + + + <h3><a name="symlinks" id="symlinks">FollowSymLinks와 SymLinksIfOwnerMatch</a></h3> + + + + <p>URL 공간에서 <code>Options FollowSymLinks</code>를 + 사용하지않고 <code>Options SymLinksIfOwnerMatch</code>를 + 사용하면 아파치는 심볼링크를 검사하기위해 시스템호출을 + 한번 더 해야 한다. 파일명의 각 부분마다 한번씩 더 호출을 + 한다. 예를 들어, 설정이 다음과 같고:</p> + + <div class="example"><p><code> + DocumentRoot /www/htdocs<br /> + <Directory /><br /> + <span class="indent"> + Options SymLinksIfOwnerMatch<br /> + </span> + </Directory> + </code></p></div> + + <p><code>/index.html</code> URI에 대한 요청이 있다고 가정하자. + 그러면 아파치는 <code>/www</code>, <code>/www/htdocs</code>, + <code>/www/htdocs/index.html</code> 각각에 대해 + <code>lstat(2)</code>를 호출한다. <code>lstats</code> + 결과를 캐싱하지 않기때문에 요청이 들어올 때마다 매번 같은 + 작업을 한다. 진짜 심볼링크 보안 검사를 원한다면 다음과 + 같이 할 수 있다:</p> + + <div class="example"><p><code> + DocumentRoot /www/htdocs<br /> + <Directory /><br /> + <span class="indent"> + Options FollowSymLinks<br /> + </span> + </Directory><br /> + <br /> + <Directory /www/htdocs><br /> + <span class="indent"> + Options -FollowSymLinks +SymLinksIfOwnerMatch<br /> + </span> + </Directory> + </code></p></div> + + <p>이 경우 최소한 <code class="directive"><a href="../mod/core.html#documentroot">DocumentRoot</a></code> 경로는 검사하지 + 않는다. DocumentRoot 밖에 있는 경로로 <code class="directive"><a href="../mod/mod_alias.html#alias">Alias</a></code>나 <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code>을 사용한 + 경우에도 위와 비슷한 섹션이 필요하다. 심볼링크 보안을 + 고려하지 않고 최고의 성능을 얻으려면, + <code>FollowSymLinks</code>를 설정하고, + <code>SymLinksIfOwnerMatch</code>는 절대로 안된다.</p> + + + + <h3><a name="htacess" id="htacess">AllowOverride</a></h3> + + + + <p>URL 공간에서 overrides를 허용한다면 (보통 + <code>.htaccess</code> 파일) 아파치는 파일명의 각 부분마다 + <code>.htaccess</code>를 열길 시도한다. 예를 들어,</p> + + <div class="example"><p><code> + DocumentRoot /www/htdocs<br /> + <Directory /><br /> + <span class="indent"> + AllowOverride all<br /> + </span> + </Directory> + </code></p></div> + + <p><code>/index.html</code> URI에 대한 요청이 있다고 가정하자. + 아파치는 <code>/.htaccess</code>, <code>/www/.htaccess</code>, + <code>/www/htdocs/.htaccess</code>를 열려고 시도한다. + 해결책은 앞의 <code>Options FollowSymLinks</code> 경우와 + 비슷하다. 최고의 성능을 얻으려면 파일시스템에 대해서 항상 + <code>AllowOverride None</code>을 사용한다.</p> + + + + <h3><a name="negotiation" id="negotiation">내용협상</a></h3> + + + + <p>가능하고 진짜 조금의 성능향상에도 관심이 있다면 내용협상을 + 막는다. 실제로 협상의 이득은 성능저하보다 작다. 서버를 + 빠르게 할 수 있다. 다음과 같이 와일드카드를 사용하는 대신:</p> + + <div class="example"><p><code> + DirectoryIndex index + </code></p></div> + + <p>완전한 목록을 사용한다:</p> + + <div class="example"><p><code> + DirectoryIndex index.cgi index.pl index.shtml index.html + </code></p></div> + + <p>가장 흔한 것을 앞에 둔다.</p> + + <p>또, 디렉토리에서 파일들을 찾는 <code>MultiViews</code> + 보다는, 한 파일만 읽으면 필요한 정보를 얻을 수 있는 + <code>type-map</code> 파일을 직접 만드는 것이 더 빠름을 + 명심하라.</p> + + <p>사이트에 내용협상이 필요하다면 협상을 위해 <code>Options + MultiViews</code> 지시어를 사용하기보다 <code>type-map</code> + 파일을 고려하라. 협상방법에 대한 자세한 설명과 + <code>type-map</code> 파일을 만드는 방법은 <a href="../content-negotiation.html">내용협상</a> 문서를 참고하라.</p> + + + + <h3>메모리대응 (memory-mapping)</h3> + + + + <p>예를 들어, server-side-include를 처리하는 등 아파치 + 2.0이 전송할 파일을 읽을때 운영체제가 <code>mmap(2)</code> + 등을 지원한다면 파일을 메모리대응한다.</p> + + <p>여러 플래폼에서 메모리대응을 성능을 향상한다. 그러나 + 메모리대응이 서버의 성능을 떨어트리고 심지어 안정성을 + 해치는 경우가 있다:</p> + + <ul> + <li> + <p>어떤 운영체제에서 <code>mmap</code>은 CPU 개수가 + 많아질때 <code>read(2)</code> 만큼 확장성이 좋지 않다. + 예를 들어, 다중프로세서 Solaris 서버에서 아파치 2.0은 + 종종 <code>mmap</code>을 사용하지 않을때 서버가 처리한 + 파일을 더 빨리 전송한다.</p> + </li> + + <li> + <p>NFS 마운트한 파일시스템에 있는 파일을 메모리대응하는 + 도중에 다른 NFS 클라이언트에 있는 프로세스가 파일을 + 지우거나 파일크기를 줄이면, 웹서버 프로세스가 다음 + 번에 메모리대응한 파일내용을 읽을때 bus error가 발생할 + 수 있다.</p> + </li> + </ul> + + <p>위의 조건에 해당하면 전송하는 파일을 메모리대응하지 + 않도록 <code>EnableMMAP off</code>를 사용해야 한다. (주의: + 이 지시어는 디렉토리별로 변경할 수 있다.)</p> + + + + <h3>Sendfile</h3> + + + + <p>아파치는 운영체제가 <code>sendfile(2)</code>을 지원하면 + 커널 sendfile을 사용하여 -- 예를 들어, 정적 파일을 서비스할때 + -- 전송할 파일을 직접 읽지않을 수 있다.</p> + + <p>여러 플래폼에서 sendfile을 사용하면 read와 send를 따로 + 할 필요가 없어서 빨라진다. 그러나 sendfile을 사용하면 + 웹서버의 안정성을 해치게되는 경우가 있다:</p> + + <ul> + <li> + <p>sendfile 지원이 잘못되었고 컴파일 시스템이 이점을 + 발견하지 못하는 플래폼이 있다. 특히 다른 컴퓨터에서 + 실행파일을 컴파일하여 sendfile 지원이 잘못된 컴퓨터로 + 가져온 경우에 가능하다.</p> + </li> + <li> + <p>커널은 자신의 캐쉬를 사용하여 NFS로 마운트한 파일을 + 안정적으로 서비스할 수 없는 경우가 있다.</p> + </li> + </ul> + + <p>위의 조건에 해당하면 파일을 sendfile 전송하지 않도록 + <code>EnableSendfile off</code>를 사용해야 한다. (주의: + 이 지시어는 디렉토리별로 변경할 수 있다.)</p> + + + + <h3><a name="process" id="process">프로세스 생성</a></h3> + + + + <p>아파치 1.3 이전에는 <code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code>, <code class="directive"><a href="../mod/prefork.html#maxspareservers">MaxSpareServers</a></code>, <code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code> 설정이 모두 + 벤치마크 결과에 큰 영향을 미쳤다. 특히 아파치는 작업을 + 서비스하기위해 충분한 자식수에 다다를 때까지 "도달" 기간이 + 필요했다. 처음 <code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code>개 자식을 + 만든후, <code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code> + 설정값까지 초당 자식을 하나씩 만들었다. 그래서 <code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code> 기본값이 + <code>5</code>인 서버에 클라이언트 100개가 동시에 접속하면 + 부하를 처리하기에 충분한 자식을 만들기까지 95초가 걸렸다. + 자주 재시작하지 않는 실제 서버에서는 잘 동작하지만, 10분간만 + 실행하는 벤치마크 결과는 매우 나쁘게 나온다.</p> + + <p>초당 한개 규칙은 자식을 새로 시작하면서 서버에 무리를 + 주지 않으려고 정했다. 컴퓨터가 자식을 시작하느라 바쁘면 + 요청을 서비스할 수 없다. 그러나 이 규칙이 아파치의 체감 + 성능에 악영향을 주어 변경하였다. 아파치 1.3에서 초당 한개 + 규칙은 완화되었다. 코드는 자식 한개를 만들고, 1초 쉬고, + 두개를 만들고, 1초 쉬고, 네개를 만들고, 이런 식으로 초당 + 자식을 32개 만들때까지 지수로 증가한다. 자식수가 <code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code> 설정에 다다르면 + 증가를 중단한다.</p> + + <p>이 경우 반응속도가 빨라져서 <code class="directive"><a href="../mod/prefork.html#minspareservers">MinSpareServers</a></code>, <code class="directive"><a href="../mod/prefork.html#maxspareservers">MaxSpareServers</a></code>, <code class="directive"><a href="../mod/mpm_common.html#startservers">StartServers</a></code>를 거의 설정할 필요가 없다. 일초에 + 자식을 4개 이상 생성하면 <code class="directive"><a href="../mod/core.html#errorlog">ErrorLog</a></code>에 기록한다. 이런 오류문이 + 많이 보이면 이 설정들을 조절하길 바란다. + <code class="module"><a href="../mod/mod_status.html">mod_status</a></code> 결과가 도움이 될 것이다.</p> + + <p>프로세스 생성과 관련하여 <code class="directive"><a href="../mod/mpm_common.html#maxrequestsperchild">MaxRequestsPerChild</a></code> 설정은 + 프로세스를 종료한다. 기본값은 자식당 처리할 요청수에 제한이 + 없다는 <code>0</code>이다. 현재 설정이 <code>30</code>과 + 같이 매우 작은 값으로 설정되있다면, 값을 상당히 높힐 필요가 + 있다. SunOS나 오래된 Solaris 버전을 사용한다면, 메모리유출때문에 + 이 값을 <code>10000</code> 정도로 설정하라.</p> + + <p>연결유지(keep-alive)를 사용한다면 자식들은 이미 열린 + 연결에서 추가 요청을 기다리며 아무것도 하지않기때문에 계속 + 바쁘다. <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code>의 + 기본값 <code>15</code> 초는 이런 현상을 최소화한다. 네트웍 + 대역폭과 서버 자원 간의 균형이 맞게 설정한다. <a href="http://www.research.digital.com/wrl/techreports/abstracts/95.4.html"> + 연결유지의 대부분의 이점이 사라지기때문에</a> 어떤 경우에도 + 이 값을 <code>60</code> 초 이상으로 올리지 마라.</p> + + + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="compiletime" id="compiletime">컴파일시 설정에 대해서</a></h2> + + + + <h3>MPM 선택</h3> + + + + <p>아파치 2.x는 <a href="../mpm.html">다중처리모듈</a> + (MPMs)이라는 교체할 수 있는 동기화 모델을 지원한다. 아파치를 + 컴파일할때 MPM을 선택해야 한다. <code class="module"><a href="../mod/beos.html">beos</a></code>, + <code class="module"><a href="../mod/mpm_netware.html">mpm_netware</a></code>, <code class="module"><a href="../mod/mpmt_os2.html">mpmt_os2</a></code>, + <code class="module"><a href="../mod/mpm_winnt.html">mpm_winnt</a></code>와 같이 특정 플래폼에서만 사용할 + 수 있는 MPM도 있다. 일반적인 유닉스류 시스템은 여러 MPM + 중에 하나를 선택할 수 있다. 웹서버의 속도와 + 확장성(scalability)은 어떤 MPM을 선택했냐에 달렸다:</p> + + <ul> + + <li><code class="module"><a href="../mod/worker.html">worker</a></code> MPM은 여러 자식 프로세스가 + 각각 여러 쓰레드를 사용한다. 각 쓰레드는 한번에 한 연결을 + 담당한다. 일반적으로 worker는 prefork MPM 보다 적은 + 메모리를 사용하므로 통신량이 많은 서버에 적절하다.</li> + + <li><code class="module"><a href="../mod/prefork.html">prefork</a></code> MPM은 쓰레드가 한개인 자식 + 프로세스를 여러개 사용한다. 각 프로세스는 한번에 한 + 연결을 담당한다. 여러 시스템에서 prefork의 속도는 worker와 + 비슷하지만, 더 많은 메모리를 사용한다. 다음과 같은 상황에서 + 쓰레드를 사용하지 않는 prefork 방식이 worker에 비해 + 이점을 가진다: 쓰레드에 안전하지 (thread-safe) 않은 + 제삼자가 만든 모듈을 사용할 수 있고, 쓰레드 디버깅 지원이 + 빈약한 플래폼에서 쉽게 디버깅할 수 있다.</li> + + </ul> + + <p>이 MPM들과 다른 MPM에 대해 더 자세한 정보는 MPM <a href="../mpm.html">문서</a>를 참고하길 바란다.</p> + + + + <h3><a name="modules" id="modules">모듈</a></h3> + + + + <p>메모리 사용량이 성능에서 가장 중요한 요인이기때문에 + 실제로 사용하지 않는 모듈을 제거해보자. 모듈을 <a href="../dso.html">DSO</a>로 컴파일했다면 간단히 그 + 모듈에 대한 <code class="directive"><a href="../mod/mod_so.html#loadmodule">LoadModule</a></code> 지시어를 주석처리하면 + 된다. 그래서 모듈을 제거하고 실행하여 사이트가 모듈없이도 + 정상적으로 동작하는지 살펴볼 수 있다.</p> + + <p>반대로 모듈이 아파치 실행파일에 정적으로 링크되있다면 + 원하지 않는 모듈을 제거하기위해 아파치를 재컴파일해야 + 한다.</p> + + <p>여기서 당연히 어떤 모듈을 사용하고 사용하지 말지 + 의문이 생긴다. 정답은 웹사이트마다 다르다. 그러나 아마도 + <em>최소한</em> <code class="module"><a href="../mod/mod_mime.html">mod_mime</a></code>, + <code class="module"><a href="../mod/mod_dir.html">mod_dir</a></code>, <code class="module"><a href="../mod/mod_log_config.html">mod_log_config</a></code> + 모듈은 사용할 것이다. 물론 웹사이트에 로그파일이 필요없다면 + <code>mod_log_config</code>는 없어도 된다. 그러나 추천하지 + 않는다.</p> + + + + <h3>Atomic 명령</h3> + + + + <p><code class="module"><a href="../mod/mod_cache.html">mod_cache</a></code> 같은 모듈과 최근 개발중인 + worker MPM은 APR의 atomic API를 사용한다. 이 API는 경량급 + 쓰레드 동기화를 위할 atomic 명령을 제공한다.</p> + + <p>기본적으로 APR은 각 운영체제/CPU 플래폼에서 가장 효율적인 + 방법을 사용하여 이 명령을 구현한다. 예를 들어, 여러 최신 + CPU에는 하드웨어로 atomic compare-and-swap (CAS) 연산을 + 하는 명령어가 있다. 그러나 어떤 플래폼에서 APR은 이런 + 명령어가 없는 오래된 CPU와 호환성을 위해 더 느린 mutex기반 + 구현을 기본적으로 사용한다. 이런 플래폼에서 아파치를 + 컴파일할때 아파치를 최신 CPU에서만 실행할 계획이라면, + 아파치를 구성할때 <code>--enable-nonportable-atomics</code> + 옵션을 사용하여 더 빠른 atomic 구현을 선택할 수 있다:</p> + + <div class="example"><p><code> + ./buildconf<br /> + ./configure --with-mpm=worker --enable-nonportable-atomics=yes + </code></p></div> + + <p><code>--enable-nonportable-atomics</code> 옵션은 다음과 + 같은 플래폼에 영향이 있다:</p> + + <ul> + + <li>SPARC에서 Solaris<br /> + 기본적으로 APR은 Solaris/SPARC에서 mutex기반 atomic을 + 사용한다. 그러나 구성할때 + <code>--enable-nonportable-atomics</code>를 사용하면 + APR은 빠른 하드웨어 compare-and-swap을 위한 SPARC + v8plus 명령어를 사용한다. 이 옵션을 사용하면 atomic + 명령이 더 효율적이지만 (CPU를 덜 사용하고 더 높은 + 동기화가 가능하다), 컴파일한 실행파일은 UltraSPARC + 칩에서만 실행할 수 있다. + </li> + + <li>Linux on x86<br /> + 기본적으로 APR은 리눅스에서 mutex기반 atomic을 + 사용한다. 그러나 구성할때 + <code>--enable-nonportable-atomics</code>를 사용하면 + APR은 빠른 하드웨어 compare-and-swap을 위한 486 + 명령어를 사용한다. 더 효율적인 atomic 명령이 가능하지만, + 컴파일한 실행파일은 486 이상 칩에서만 (386은 안된다) + 실행할 수 있다. + </li> + + </ul> + + + + <h3>mod_status와 ExtendedStatus On</h3> + + + + <p>아파치를 컴파일할때 <code class="module"><a href="../mod/mod_status.html">mod_status</a></code>를 포함하고 + 실행할때 <code>ExtendedStatus On</code>을 설정하면 아파치는 + 요청을 받을때마다 <code>gettimeofday(2)</code>(혹은 운영체제에 + 따라 <code>times(2)</code>)를 두번 호출하고 (1.3 이전에는) + <code>time(2)</code>도 추가로 여러번 호출한다. 상태 보고서에 + 동작시간이 필요하기 때문이다. 최상의 성능을 얻으려면 + (기본값인) <code>ExtendedStatus off</code>를 설정한다.</p> + + + + <h3>accept 직렬화 - 여러 소켓</h3> + + + + <div class="warning"><h3>주의:</h3> + <p> 아래 문서는 아파치 웹서버 2.0 버전에서 변경된 내용을 + 담고 있지 않다. 아직도 유효한 정보가 있지만, 주의해서 + 사용하길 바란다.</p> + </div> + + <p>유닉스 소켓 API의 단점을 설명한다. 웹서버가 여러 포트 + 혹은 여러 주소를 기다리기위해 여러 <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code>을 사용한다고 가정하자. + 연결이 가능한지 각 소켓을 검사하기위해 아파치는 + <code>select(2)</code>를 사용한다. <code>select(2)</code>는 + 소켓에 기다리고 있는 연결이 <em>없는지</em> 혹은 <em>최소한 + 한개</em> 있는지 알려준다. 아파치에는 여러 자식이 있고, + 쉬고 있는 모든 자식은 동시에 새로운 연결을 검사한다. 원래 + 구현은 다음과 비슷하다 (이 예는 코드에서 가져오지 않았다. + 단지 설명하기위한 용도로 만들었다.):</p> + + <div class="example"><p><code> + for (;;) {<br /> + <span class="indent"> + for (;;) {<br /> + <span class="indent"> + fd_set accept_fds;<br /> + <br /> + FD_ZERO (&accept_fds);<br /> + for (i = first_socket; i <= last_socket; ++i) {<br /> + <span class="indent"> + FD_SET (i, &accept_fds);<br /> + </span> + }<br /> + rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);<br /> + if (rc < 1) continue;<br /> + new_connection = -1;<br /> + for (i = first_socket; i <= last_socket; ++i) {<br /> + <span class="indent"> + if (FD_ISSET (i, &accept_fds)) {<br /> + <span class="indent"> + new_connection = accept (i, NULL, NULL);<br /> + if (new_connection != -1) break;<br /> + </span> + }<br /> + </span> + }<br /> + if (new_connection != -1) break;<br /> + </span> + }<br /> + process the new_connection;<br /> + </span> + } + </code></p></div> + + <p>그러나 위의 단순한 구현에는 심각한 고갈(starvation) + 문제가 있다. 여러 자식이 동시에 이 반복문을 실행하면, + 요청을 기다리며 모두 <code>select</code>에서 멈춘다. 이때 + 어떤 소켓에 요청이 하나라도 들어오면 모든 자식이 깨어난다 + (깨어나는 자식의 개수는 운영체제와 타이밍에 따라 다르다). + 이들은 모두 연결을 <code>accept</code>하길 시도한다. 그러나 + (아직도 한 연결만 대기중이라면) 한 자식만 성공하고, 나머지는 + <code>accept</code>에서 <em>멈춘다.</em> 그러면 이 자식들은 + 한 소켓의 요청만을 서비스하도록 묶여서, 그 소켓으로 새로운 + 요청이 충분히 들어와서 모든 자식을 깨울때까지 정지해있다. + 이런 고갈 문제는 <a href="http://bugs.apache.org/index/full/467">PR#467</a>에 + 처음 보고되었다. 최소한 두가지 해결책이 있다.</p> + + <p>한가지는 소켓을 대기하지 않도록 (non-blocking) 만드는 + 방법이다. 이 경우 자식이 <code>accept</code>를 해도 멈추지 + 않고, 즉시 진행할 수 있다. 그러나 CPU 시간을 낭비한다. + <code>select</code>에서 쉬는 자식이 10개 있고, 새로 연결이 + 한개 들어왔다고 가정하자. 그러면 이 자식중 9개는 깨어나서 + 연결을 <code>accept</code>하길 시도하고 실패하면 아무 + 일도 하지 않고 다시 <code>select</code>를 반복한다. 다시 + <code>select</code>로 돌아올 때까지 어떤 자식도 다른 소켓에 + 들어온 요청을 서비스하지 않는다. (다중프로세서 컴퓨터에서) + 쉬는 자식 개수만큼 CPU 개수가 있는 드문 경우가 아니라면 + 이 해결책은 별로 좋아보이지 않는다.</p> + + <p>다른 방법은 아파치가 사용하는 방법으로 내부 반복문에 + 한 자식만을 들여보낸다. 반복문은 다음과 같다 (차이를 + 강조했음):</p> + + <div class="example"><p><code> + for (;;) {<br /> + <span class="indent"> + <strong>accept_mutex_on ();</strong><br /> + for (;;) {<br /> + <span class="indent"> + fd_set accept_fds;<br /> + <br /> + FD_ZERO (&accept_fds);<br /> + for (i = first_socket; i <= last_socket; ++i) {<br /> + <span class="indent"> + FD_SET (i, &accept_fds);<br /> + </span> + }<br /> + rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);<br /> + if (rc < 1) continue;<br /> + new_connection = -1;<br /> + for (i = first_socket; i <= last_socket; ++i) {<br /> + <span class="indent"> + if (FD_ISSET (i, &accept_fds)) {<br /> + <span class="indent"> + new_connection = accept (i, NULL, NULL);<br /> + if (new_connection != -1) break;<br /> + </span> + }<br /> + </span> + }<br /> + if (new_connection != -1) break;<br /> + </span> + }<br /> + <strong>accept_mutex_off ();</strong><br /> + process the new_connection;<br /> + </span> + } + </code></p></div> + + <p><code>accept_mutex_on</code>과 <code>accept_mutex_off</code> + <a id="serialize" name="serialize">함수</a>는 mutex 세마포어를 + 구현한다. 한번에 오직 한 자식만이 mutex를 가질 수 있다. + mutex를 구현하는 방법은 여러가지이다. 구현 방법은 (1.3 + 이전) <code>src/conf.h</code>나 (1.3과 그 이후) + <code>src/include/ap_config.h</code>에 정의되있다. 어떤 + 아키텍쳐는 잠금(locking) 방법을 선택하지 않기때문에, 이런 + 아키텍쳐에서 여러 <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code> 지시어를 사용하면 + 위험하다.</p> + + <p>실행시 <code class="directive"><a href="../mod/mpm_common.html#acceptmutex">AcceptMutex</a></code> 지시어를 사용하여 + mutex 구현을 변경할 수 있다.</p> + + <dl> + <dt><code>AcceptMutex flock</code></dt> + + <dd> + <p>이 방법은 잠금파일을 잠그기위해 <code>flock(2)</code> + 시스템호출을 사용한다 (잠금파일 위치는 <code class="directive"><a href="../mod/mpm_common.html#lockfile">LockFile</a></code> 지시어로 지정).</p> + </dd> + + <dt><code>AcceptMutex fcntl</code></dt> + + <dd> + <p>이 방법은 잠금파일을 잠그기위해 <code>fcntl(2)</code> + 시스템호출을 사용한다 (잠금파일 위치는 <code class="directive"><a href="../mod/mpm_common.html#lockfile">LockFile</a></code> 지시어로 지정).</p> + </dd> + + <dt><code>AcceptMutex sysvsem</code></dt> + + <dd> + <p>(1.3과 그 이후) 이 방법을 SysV식 세마포어를 사용하여 + mutex를 구현한다. 불행히도 SysV식 세마포어는 나쁜 + 부작용이 있다. 하나는 아파치가 세마포어를 정리하지 + 않고 죽을 수 있는 점이다 (<code>ipcs(8)</code> manpage + 참고). 다른 하나는 웹서버와 동일한 uid로 실행하는 + CGI가 (<em>즉,</em> <code>suexec</code>나 + <code>cgiwrapper</code>를 사용하지않는 한 모든 CGI) + 세마포어 API를 사용하여 서비스거부공격을 할 수 있는 + 점이다. 이런 이유때문에 IRIX를 제외한 아키텍쳐에서 + 이 방법을 사용하지 않는다 (대부분의 IRIX 컴퓨터에서 + 앞의 두 방법은 지나치게 버겁다).</p> + </dd> + + <dt><code>AcceptMutex pthread</code></dt> + + <dd> + <p>(1.3과 그 이후) 이 방법은 POSIX mutex를 사용하기때문에 + POSIX 쓰레드 규약을 완전히 구현한 아키텍쳐라면 모두 + 사용가능하지만, (2.5 이후) Solaris에서만 그것도 특정 + 구성에서만 동작하는 듯하다. 이 방법을 시도해본다면 + 서버가 멈춰서 응답을 안하는지 살펴봐야 한다. 정적 + 내용만 서비스하는 서버는 잘 동작하는 것 같다.</p> + </dd> + + <dt><code>AcceptMutex posixsem</code></dt> + + <dd> + <p>(2.0과 그 이후) 이 방법은 POSIX 세마포어를 사용한다. + mutex를 가진 프로세스의 쓰레드가 죽는다면(segfault) + 세마포어 소유권이 회복되지 않아서 웹서버가 멈춘다.</p> + </dd> + + </dl> + + <p>시스템에 위 목록에 없는 직렬화(serialization) 방법이 + 있다면 그 방법을 사용하는 코드를 APR에 추가할 가치가 있다.</p> + + <p>고려는 해봤지만 구현하지않은 다른 방법은 부분적으로 + 반복문을 직렬화하는 방법이다. 즉, 프로세서를 몇개만 들여보내는 + 것이다. 이 방법은 여러 자식을 동시에 실행할 수 있어서 + 직렬화때문에 전체 대역폭을 활용하지 못하는 다중프로세서 + 컴퓨터에서만 관심을 가져볼 수 있다. 앞으로 살펴볼 부분이지만, + 매우 병렬화된 웹서버가 흔하지 않아서 우선순위가 낮다.</p> + + <p>최상의 성능을 얻기위해서는 여러 <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code> 문을 사용하지 않는 + 것이 이상적이다. 그러나 계속 설명한다.</p> + + + + <h3>accept 직렬화 - 소켓 한개</h3> + + + + <p>앞의 설명은 다중소켓 서버에는 좋지만, 소켓이 한개인 + 서버는 어떤가? 연결이 도착할때까지 모든 자식이 + <code>accept(2)</code>에서 멈춰있기때문에 이론상 같은 + 문제가 발생하지 않고, 고갈 문제도 없다. 그러나 실제로는 + 앞에서 말한 대기하지 않는 (non-blocking) 방법에서 발생하는 + "공회전(spinning)" 현상을 감추고 있다. 대부분의 TCP 스택은 + 연결이 도착하면 커널이 <code>accept</code>에서 멈춰있는 + 모든 자식을 깨우도록 구현되있다. 프로세스중 한개가 연결을 + 얻고 사용자영역으로 돌아가고, 나머지는 커널에서 공회전하여 + 연결이 없음을 발견하면 다시 잠을 잔다. 사용자영역 코드에서는 + 이런 공회전을 알 수 없지만, 분명히 존재한다. 그래서 다중소켓의 + 대기하지 않는 방법과 동일하게 부하를 높이는 불필요한 행동이 + 일어난다.</p> + + <p>그래서 우리는 여러 아키텍쳐에서 소켓이 한개인 경우에도 + 직렬화하면 더 "잘" 동작함을 발견했다. 그래서 거의 대부분의 + 경우 기본적으로 직렬화를 사용한다. 리눅스에서 (커널 2.0.30, + 128Mb 메모리에 듀얼 Pentium pro) 실험한 결과 소켓 한개를 + 직렬화하면 하지 않은 경우에 비해 초당 요청이 3% 미만 + 줄어들었다. 그러나 직렬화를 하지 않은 경우 요청당 100ms + 지연이 발생했다. 이 지연은 아마도 LAN에서 발생하는 긴 + 연결선때문일 것이다. 소켓이 한개인 경우 직렬화를 사용하지 + 않으려면 <code>SINGLE_LISTEN_UNSERIALIZED_ACCEPT</code>를 + 정의한다.</p> + + + + <h3>Close 지연(lingering)</h3> + + + + <p><a href="http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt"> + draft-ietf-http-connection-00.txt</a> 8절에서 설명하듯이 + <strong>안정적인</strong> 웹서버가 되려면, 통신의 양 방향을 + 독립적으로 닫을 수 있어야 한다 (TCP 연결은 쌍방향이고, + 방향은 서로 독립적이다). 이점을 다른 서버에서는 자주 + 간과하지만, 아파치는 1.2부터 정확히 구현해왔다.</p> + + <p>이 기능을 부주의하게 아파치에 추가했을때 여러 유닉스 + 버전에서 많은 문제가 발생했다. TCP 규약은 + <code>FIN_WAIT_2</code>에 타임아웃이 있다고 정하지 않았지만, + 금지하지도 않았다. 타임아웃이 없는 시스템에서 아파치 1.2는 + 많은 소켓을 영원히 <code>FIN_WAIT_2</code> 상태로 만들었다. + 많은 경우 이 문제는 제작사가 제공하는 최신 TCP/IP 패치를 + 적용하여 해결할 수 있다. 그러나 제작사가 패치를 발표하지 + 않는 경우가 (<em>즉,</em> SunOS4 -- 소스 라이선스가 있는 + 사람은 직접 패치할 수 있지만) 있기때문에 이 기능을 사용하지 + 않기로 결정했다.</p> + + <p>방법은 두가지다. 하나는 소켓 옵션 <code>SO_LINGER</code>를 + 사용하는 방법이다. 그러나 불행히도 대부분의 TCP/IP 스택은 + 이 옵션을 올바로 구현하지 않았다. 올바로 구현한 스택에서 + 조차도 (<em>즉,</em> 리눅스 2.0.31) 이 방법은 다음 방법보다 + 더 cpu를 잡아먹는다.</p> + + <p>아파치는 보통 (<code>http_main.c</code>에 있는) + <code>lingering_close</code>라는 함수를 사용한다. 이 함수는 + 대충 다음과 같다:</p> + + <div class="example"><p><code> + void lingering_close (int s)<br /> + {<br /> + <span class="indent"> + char junk_buffer[2048];<br /> + <br /> + /* shutdown the sending side */<br /> + shutdown (s, 1);<br /> + <br /> + signal (SIGALRM, lingering_death);<br /> + alarm (30);<br /> + <br /> + for (;;) {<br /> + <span class="indent"> + select (s for reading, 2 second timeout);<br /> + if (error) break;<br /> + if (s is ready for reading) {<br /> + <span class="indent"> + if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {<br /> + <span class="indent"> + break;<br /> + </span> + }<br /> + /* just toss away whatever is here */<br /> + </span> + }<br /> + </span> + }<br /> + <br /> + close (s);<br /> + </span> + } + </code></p></div> + + <p>이 코드는 연결을 닫을때 더 CPU를 사용하지만, 안정적인 + 구현을 위해 필요하다. HTTP/1.1이 더 널리 퍼지고 모든 연결을 + 유지한다면(persistent), 연결을 받는 비용은 여러 요청을 + 처리하면서 상쇄될 것이다. 위험하게도 + <code>NO_LINGCLOSE</code>를 정의하여 이 기능을 사용하지 + 않을 수 있지만, 절대로 권하지 않는다. 특히 HTTP/1.1 + 파이프라인 <span class="transnote">(<em>역주;</em> 연결유지 상태에서 응답을 기다리지 + 않고 여러 요청을 보내는 기술)</span> 연결유지에는 + <code>lingering_close</code>가 필수적이다 (그리고 <a href="http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html"> + 파이프라인 연결이 더 빠르기때문에</a> 사용하길 바랄 것이다).</p> + + + + <h3>Scoreboard 파일</h3> + + + + <p>아파치의 부모와 자식은 scoreboard라는 것을 통해 서로 + 통신한다. 이상적으로는 scoreboard를 공유메모리로 구현해야 + 한다. 우리 개발자가 해당 운영체제에 접근할 수 있거나 상세한 + 포팅 결과를 받은 경우 보통 공유메모리를 사용하여 구현한다. + 나머지는 디스크에 있는 파일을 사용하여 구현한다. 디스크에 + 있는 파일은 느리고 신뢰도가 떨어진다 (기능도 더 적다). + <code>src/main/conf.h</code> 파일에서 사용하는 아키텍쳐를 + 찾아서 <code>USE_MMAP_SCOREBOARD</code> 혹은 + <code>USE_SHMGET_SCOREBOARD</code>인지 확인한다. 둘중 + 하나를 (각각 함께 사용할 <code>HAVE_MMAP</code>이나 + <code>HAVE_SHMGET</code>도 같이) 정의하면 공유메모리 코드를 + 사용한다. 시스템이 다른 종류의 공유메모리를 사용한다면 + <code>src/main/http_main.c</code> 파일을 수정하여 아파치에서 + 공유메모리를 사용할 수 있도록 훅(hook)을 추가하라. (또한 + 패치를 우리에게 보내주길 바란다.)</p> + + <div class="note">역사적 설명: 아파치의 리눅스 버전은 아파치 1.2 버전부터 + 공유메모리를 사용하기 시작했다. 리눅스에서 초기 아파치 + 버전이 느리고 신뢰도가 떨어졌기 때문이다.</div> + + + + <h3>DYNAMIC_MODULE_LIMIT</h3> + + + + <p>모듈을 동적으로 읽어들이지 않는다면 (가능한 조금이라도 + 성능을 높이기위해 이 글을 읽는다면 아마도 모듈을 동적으로 + 읽어들이지 않을 것이다), 서버를 컴파일할때 + <code>-DDYNAMIC_MODULE_LIMIT=0</code>을 추가한다. 그러면 + 모듈을 동적으로 읽어들이기위해 할당하는 메모리를 절약한다.</p> + + + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="trace" id="trace">부록: 시스템호출 기록을 자세히 분석하기</a></h2> + + + + <p>다음은 Solaris 8에서 worker MPM을 사용한 아파치 2.0.38의 + 시스템호출 기록(trace)이다. 아래 명령어를 사용하여 기록을 + 얻었다:</p> + + <div class="example"><p><code> + truss -l -p <var>httpd_child_pid</var>. + </code></p></div> + + <p><code>-l</code> 옵션을 사용하면 truss는 시스템호출을 + 하는 LWP (lightweight process, 경량급 프로세스--Solaris의 + 커널수준 쓰레드) ID를 같이 기록한다.</p> + + <p>다른 시스템에는 <code>strace</code>, <code>ktrace</code>, + <code>par</code> 같은 시스템호출 추적 도구가 있다. 결과는 + 비슷하다.</p> + + <p>클라이언트는 웹서버에게 크기가 10KB인 정적 파일을 요청한다. + 정적인 파일을 요청하지 않거나 내용협상하는 요청을 한 경우 + 기록이 매우 다르다 (때로는 매우 알아보기 힘들다).</p> + + <div class="example"><pre>/67: accept(3, 0x00200BEC, 0x00200C0C, 1) (sleeping...) +/67: accept(3, 0x00200BEC, 0x00200C0C, 1) = 9</pre></div> + + <p>위에서 연결대기(listener) 쓰레드가 LWP #67에서 실행됨을 + 알 수 있다.</p> + + <div class="note"><code>accept(2)</code> 직렬화를 사용하지 않음을 주목하라. + 여러 포트를 기다리지않는 경우 이 플래폼의 worker MPM은 + 기본적으로 직렬화하지 않은 accept를 사용한다.</div> + + <div class="example"><pre>/65: lwp_park(0x00000000, 0) = 0 +/67: lwp_unpark(65, 1) = 0</pre></div> + + <p>연결은 받아들이고(accept) 연결대기 쓰레드는 + worker 쓰레드를 깨워서 요청을 처리하게 한다. 아래 기록에서 + 요청을 처리하는 worker 쓰레드가 LWP #65임을 알 수 있다.</p> + + <div class="example"><pre>/65: getsockname(9, 0x00200BA4, 0x00200BC4, 1) = 0</pre></div> + + <p>가상호스트를 구현하기위해 아파치는 연결을 받아들인 + 지역(local) 소켓 주소를 알아야 한다. (가상호스트를 사용하지 + 않거나 <code class="directive"><a href="../mod/mpm_common.html#listen">Listen</a></code> + 지시어에 와일드카드 주소를 사용하지 않은 경우 등) 많은 경우 + 이 호출을 없앨 수 있다. 그러나 아직 이런 최적화 작업이 + 안되있다. </p> + + <div class="example"><pre>/65: brk(0x002170E8) = 0 +/65: brk(0x002190E8) = 0</pre></div> + + <p><code>brk(2)</code> 호출은 힙(heap)에서 메모리를 할당한다. + 웹서버는 대부분의 요청 처리시 자체 메모리 + 할당자(<code>apr_pool</code>과 <code>apr_bucket_alloc</code>)를 + 사용하기때문에 시스템호출 기록에서 이 시스템호출을 보기가 + 드물다. 이 기록에서 웹서버는 시작하자마자 자체 메모리 할당자가 + 사용할 메모리블록을 얻기위해 <code>malloc(3)</code>을 호출한다.</p> + + <div class="example"><pre>/65: fcntl(9, F_GETFL, 0x00000000) = 2 +/65: fstat64(9, 0xFAF7B818) = 0 +/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0 +/65: fstat64(9, 0xFAF7B818) = 0 +/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0 +/65: setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0 +/65: fcntl(9, F_SETFL, 0x00000082) = 0</pre></div> + + <p>다음 worker 쓰레드는 클라이언트의 연결(파일기술자 9)을 + 대기안함(non-blocking) 상태로 바꾼다. <code>setsockopt(2)</code>와 + <code>getsockopt(2)</code> 호출은 Solaris의 libc가 소켓에 + 대한 <code>fcntl(2)</code>을 어떻게 처리하는지 보여준다.</p> + + <div class="example"><pre>/65: read(9, " G E T / 1 0 k . h t m".., 8000) = 97</pre></div> + + <p>worker 쓰레드는 클라이언트로 부터 요청을 읽는다.</p> + + <div class="example"><pre>/65: stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0 +/65: open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10</pre></div> + + <p>웹서버 설정은 <code>Options FollowSymLinks</code>와 + <code>AllowOverride None</code>이다. 그래서 요청한 파일경로의 + 각 디렉토리에 대해 <code>lstat(2)</code>하거나 + <code>.htaccess</code> 파일을 검사할 필요가 없다. 파일을 + 검사하기위해, 1) 파일이 있는지, 2) 디렉토리가 아닌 일반파일인지, + <code>stat(2)</code> 호출만 하면 된다.</p> + + <div class="example"><pre>/65: sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C) = 10269</pre></div> + + <p>이 경우 웹서버는 한번의 <code>sendfilev(2)</code> 시스템호출로 + HTTP 응답헤더와 요청한 파일을 전송할 수 있다. Sendfile 지원여부는 + 운영체제마다 다르다. 다른 시스템이라면 <code>sendfile(2)</code>을 + 호출하기 전에 헤더를 보내기위해 <code>write(2)</code>나 + <code>writev(2)</code> 호출을 한다.</p> + + <div class="example"><pre>/65: write(4, " 1 2 7 . 0 . 0 . 1 - ".., 78) = 78</pre></div> + + <p><code>write(2)</code> 호출은 접근로그(access log)에 요청을 + 기록한다. 이 기록에 <code>time(2)</code> 호출이 없음을 주목하라. + 아파치 1.3과 달리 아파치 2.0은 시간을 알기위해 + <code>gettimeofday(3)</code>를 사용한다. + <code>gettimeofday</code>를 최적화한 리눅스와 Solaris 같은 + 몇몇 운영체제에서는 일반적인 시스템호출 부담이 없다.</p> + + <div class="example"><pre>/65: shutdown(9, 1, 1) = 0 +/65: poll(0xFAF7B980, 1, 2000) = 1 +/65: read(9, 0xFAF7BC20, 512) = 0 +/65: close(9) = 0</pre></div> + + <p>worker 쓰레드는 연결을 지연닫기(lingering close)한다.</p> + + <div class="example"><pre>/65: close(10) = 0 +/65: lwp_park(0x00000000, 0) (sleeping...)</pre></div> + + <p>마지막으로 worker 쓰레드는 방금 전송한 파일을 닫고, + 연결대기(listener) 쓰레드가 다른 연결을 할당할 때까지 + 정지한다.</p> + + <div class="example"><pre>/67: accept(3, 0x001FEB74, 0x001FEB94, 1) (sleeping...)</pre></div> + + <p>그동안 연결대기 쓰레드는 연결을 (모든 worker가 작업중이면 + 연결대기 쓰레드를 멈추는 worker MPM의 흐름제어 기능에 따라) + worker 쓰레드에 할당하자마자 다른 연결을 받아들일 수 있다. + 이 기록에는 나오지 않지만, worker 쓰레드가 방금 받은 연결을 + 처리하는 동안 다음 <code>accept(2)</code>가 (요청이 매우 + 많은 경우 항상) 일어날 수 있다.</p> + + </div></div> +<div class="bottomlang"> +<p><span>가능한 언어: </span><a href="../en/misc/perf-tuning.html" hreflang="en" rel="alternate" title="English"> en </a> | +<a href="../ko/misc/perf-tuning.html" title="Korean"> ko </a></p> +</div><div id="footer"> +<p class="apache">Copyright 1999-2004 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p> +<p class="menu"><a href="../mod/">모듈</a> | <a href="../mod/directives.html">지시어들</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">용어</a> | <a href="../sitemap.html">사이트맵</a></p></div> +</body></html>
\ No newline at end of file diff --git a/docs/manual/misc/perf-tuning.xml.ko b/docs/manual/misc/perf-tuning.xml.ko index c550863815..0a05318957 100644 --- a/docs/manual/misc/perf-tuning.xml.ko +++ b/docs/manual/misc/perf-tuning.xml.ko @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="EUC-KR" ?> <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?> -<!-- English Revision: 1.16 --> +<!-- English Revision: 1.17 --> <!-- Copyright 2004 The Apache Software Foundation diff --git a/docs/manual/misc/perf-tuning.xml.meta b/docs/manual/misc/perf-tuning.xml.meta index 3099db5444..190912da28 100644 --- a/docs/manual/misc/perf-tuning.xml.meta +++ b/docs/manual/misc/perf-tuning.xml.meta @@ -7,5 +7,6 @@ <variants> <variant>en</variant> + <variant>ko</variant> </variants> </metafile> diff --git a/docs/manual/misc/relevant_standards.html b/docs/manual/misc/relevant_standards.html index 66aeada7de..ca9e9006c3 100644 --- a/docs/manual/misc/relevant_standards.html +++ b/docs/manual/misc/relevant_standards.html @@ -1,3 +1,7 @@ URI: relevant_standards.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: relevant_standards.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR diff --git a/docs/manual/misc/relevant_standards.html.en b/docs/manual/misc/relevant_standards.html.en index a892688166..a6d63a0acd 100644 --- a/docs/manual/misc/relevant_standards.html.en +++ b/docs/manual/misc/relevant_standards.html.en @@ -18,7 +18,8 @@ <div id="path"> <a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.1</a> > <a href="./">Miscellaneous Documentation</a></div><div id="page-content"><div id="preamble"><h1>Relevant Standards</h1> <div class="toplang"> -<p><span>Available Languages: </span><a href="../en/misc/relevant_standards.html" title="English"> en </a></p> +<p><span>Available Languages: </span><a href="../en/misc/relevant_standards.html" title="English"> en </a> | +<a href="../ko/misc/relevant_standards.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p> </div> <p>This page documents all the relevant standards that the @@ -190,7 +191,8 @@ </div></div> <div class="bottomlang"> -<p><span>Available Languages: </span><a href="../en/misc/relevant_standards.html" title="English"> en </a></p> +<p><span>Available Languages: </span><a href="../en/misc/relevant_standards.html" title="English"> en </a> | +<a href="../ko/misc/relevant_standards.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p> </div><div id="footer"> <p class="apache">Copyright 1999-2004 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p> <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div> diff --git a/docs/manual/misc/relevant_standards.html.ko.euc-kr b/docs/manual/misc/relevant_standards.html.ko.euc-kr new file mode 100644 index 0000000000..20114ef89f --- /dev/null +++ b/docs/manual/misc/relevant_standards.html.ko.euc-kr @@ -0,0 +1,191 @@ +<?xml version="1.0" encoding="EUC-KR"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml" lang="ko" xml:lang="ko"><head><!-- + XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX + This file is generated from xml source: DO NOT EDIT + XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX + --> +<title>관련 표준 - Apache HTTP Server</title> +<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" /> +<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" /> +<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /> +<link href="../images/favicon.ico" rel="shortcut icon" /></head> +<body id="manual-page"><div id="page-header"> +<p class="menu"><a href="../mod/">모듈</a> | <a href="../mod/directives.html">지시어들</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">용어</a> | <a href="../sitemap.html">사이트맵</a></p> +<p class="apache">Apache HTTP Server Version 2.1</p> +<img alt="" src="../images/feather.gif" /></div> +<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div> +<div id="path"> +<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.1</a> > <a href="./">Miscellaneous Documentation</a></div><div id="page-content"><div id="preamble"><h1>관련 표준</h1> +<div class="toplang"> +<p><span>가능한 언어: </span><a href="../en/misc/relevant_standards.html" hreflang="en" rel="alternate" title="English"> en </a> | +<a href="../ko/misc/relevant_standards.html" title="Korean"> ko </a></p> +</div> + + <p>이 문서에는 간단한 설명과 함께 아파치 웹서버가 따르는 + 모든 관련 표준을 열거한다.</p> + + <p>아래 정보에 더하여 다음 자료도 살펴봐야 한다:</p> + + <ul> + <li> + <a href="http://purl.org/NET/http-errata"> + http://purl.org/NET/http-errata</a> - HTTP/1.1 규약 + 정오표 + </li> + <li> + <a href="http://www.rfc-editor.org/errata.html"> + http://www.rfc-editor.org/errata.html</a> - RFC 정오표 + </li> + <li> + <a href="http://ftp.ics.uci.edu/pub/ietf/http/#RFC"> + http://ftp.ics.uci.edu/pub/ietf/http/#RFC</a> - HTTP + 관련 RFC 목록 + </li> + </ul> + + <div class="warning"><h3>주의</h3> + <p>이 문서는 아직 완전하지 않다.</p> + </div> + + </div> +<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#http_recommendations">HTTP 권고</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#html_recommendations">HTML 권고</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#authentication">인증</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#language_country_codes">언어/국가 코드</a></li> +</ul></div> +<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="http_recommendations" id="http_recommendations">HTTP 권고</a></h2> + + <p>어떤 모듈을 컴파일하고 사용하는지와 관계없이 기본적으로 + 웹서버인 아파치는 다음 IETF 권고(recommendation)를 따른다:</p> + + <dl> + <dt><a href="http://www.rfc-editor.org/rfc/rfc1945.txt">RFC 1945</a> + (Informational)</dt> + + <dd>하이퍼텍스트 전송 프로토콜 (Hypertext Transfer Protocol, + HTTP)은 분산, 협동, 하이퍼매체 정보 시스템에 필요한 빠르고 + 가벼운 어플리케이션 수준(application-level) 프로토콜이다. + 이 문서는 HTTP/1.0을 설명한다.</dd> + + <dt><a href="http://www.rfc-editor.org/rfc/rfc2616.txt">RFC 2616</a> + (Standards Track)</dt> + + <dd>하이퍼텍스트 전송 프로토콜 (Hypertext Transfer Protocol, + HTTP)은 분산, 협동, 하이퍼매체 정보 시스템을 위한 어플리케이션 + 수준 프로토콜이다. 이 문서는 HTTP/1.1을 설명한다.</dd> + + <dt><a href="http://www.rfc-editor.org/rfc/rfc2396.txt">RFC 2396</a> + (Standards Track)</dt> + + <dd>표준 자원 식별자 (Uniform Resource Identifier, URI)는 + 추상적 혹은 물리적 자원을 식별하기위한 짧은 문자열이다.</dd> + </dl> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="html_recommendations" id="html_recommendations">HTML 권고</a></h2> + + <p>하이퍼텍스트 마크업 언어 (Hypertext Markup Language, + HTML)와 관련하여 아파치는 다음 IETF 권고와 W3C 권고를 따른다:</p> + + <dl> + <dt><a href="http://www.rfc-editor.org/rfc/rfc2854.txt">RFC 2854</a> + (Informational)</dt> + + <dd>이 문서는 HTML 개발과정을 요약하고, 관련 W3C 권고를 + 기반으로 "text/html" MIME type을 정의한다.</dd> + + <dt><a href="http://www.w3.org/TR/html401">HTML 4.01 규약</a> + (<a href="http://www.w3.org/MarkUp/html4-updates/errata">Errata</a>) + </dt> + + <dd>이 규약은 월드와이드웹의 출판언어인 하이퍼텍스트 마크업 + 언어 (Hypertext Markup Language, HTML)를 정의한다. 이 + 규약은 HTML 4의 하위버전인 HTML 4.01을 정의한다.</dd> + + <dt><a href="http://www.w3.org/TR/REC-html32">HTML 3.2 참고 규약</a></dt> + + <dd>하이퍼텍스트 마크업 언어 (Hypertext Markup Language, + HTML)는 플래폼과 무관한 하이퍼텍스트 문서를 위한 간단한 + 마크업 언어이다. HTML 문서는 SGML 문서이기도 하다.</dd> + + <dt><a href="http://www.w3.org/TR/xhtml11/">XHTML™ 1.1 - + 모듈기반 XHTML</a> + (<a href="http://www.w3.org/2001/04/REC-xhtml-modularization-20010410-errata">정오표</a>) + </dt> + + <dd>이 권고는 Modularization of XHTML에서 정의한 모듈 + 플레임워크와 모듈들을 기반으로 새로운 XHTML document type을 + 정의한다.</dd> + + <dt><a href="http://www.w3.org/TR/xhtml1">XHTML™ 1.0 + 확장 하이퍼텍스트 마크업 언어 (Extensible HyperText Markup + Language) (Second Edition)</a> + (<a href="http://www.w3.org/2002/08/REC-xhtml1-20020801-errata">정오표</a>) + </dt> + + <dd>이 문서는 HTML 4를 XML 1.0으로 재구성한 XHTML 1.0의 + 두번째 버전과 HTML 4에 해당하는 세가지 DTD를 정의한다.</dd> + </dl> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="authentication" id="authentication">인증</a></h2> + + <p>인증방법에 대해 아파치는 다음 IETF 권고를 따른다:</p> + + <dl> + <dt><a href="http://www.rfc-editor.org/rfc/rfc2617.txt">RFC 2617</a> + (Draft standard)</dt> + + <dd>Basic Access Authentication 규약을 포함한 "HTTP/1.0".</dd> + + </dl> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="language_country_codes" id="language_country_codes">언어/국가 코드</a></h2> + + <p>아래 링크에 ISO와 다른 언어/국가 코드 정보가 있다:</p> + + <dl> + <dt><a href="http://www.loc.gov/standards/iso639-2/">ISO 639-2</a></dt> + + <dd>ISO 639는 언어의 이름을 나타내는 두가지 언어 코드를 + 제공한다. 하나는 (639-1) 두 글자 코드이고 다른 하나는 + (이 문서) 세 글자 코드이다.</dd> + + <dt><a href="http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/index.html"> + ISO 3166-1</a></dt> + + <dd>이 문서는 ISO 3166-1과 ISO 3166-1-alpha-2 코드에 따라 + 알파벳 순서로 (영어로 짧은 공식이름) 국가명을 열거한다.</dd> + + <dt><a href="http://www.rfc-editor.org/rfc/bcp/bcp47.txt">BCP 47</a> + (Best Current Practice), + <a href="http://www.rfc-editor.org/rfc/rfc3066.txt">RFC 3066</a></dt> + + <dd>이 문서는 정보 객체에 사용한 언어를 알리기위해 사용할 + 언어 태그와 언어 태그에 사용할 값을 등록하는 방법, 언어 + 태그를 찾는 방식을 설명한다.</dd> + + <dt><a href="http://www.rfc-editor.org/rfc/rfc3282.txt">RFC 3282</a> + (Standards Track)</dt> + + <dd>이 문서는 MIME 내용 부분과 웹 문서와 같은 RFC 822식 + 헤더가 있는 정보의 언어를 알리기위한 "Content-language:" + 헤더와, 선호하는 언어를 나타내는 "Accept-Language:" 헤더를 + 정의한다.</dd> + </dl> + + </div></div> +<div class="bottomlang"> +<p><span>가능한 언어: </span><a href="../en/misc/relevant_standards.html" hreflang="en" rel="alternate" title="English"> en </a> | +<a href="../ko/misc/relevant_standards.html" title="Korean"> ko </a></p> +</div><div id="footer"> +<p class="apache">Copyright 1999-2004 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p> +<p class="menu"><a href="../mod/">모듈</a> | <a href="../mod/directives.html">지시어들</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">용어</a> | <a href="../sitemap.html">사이트맵</a></p></div> +</body></html>
\ No newline at end of file diff --git a/docs/manual/misc/relevant_standards.xml.ko b/docs/manual/misc/relevant_standards.xml.ko index b6ad78f82f..cc31616cf5 100644 --- a/docs/manual/misc/relevant_standards.xml.ko +++ b/docs/manual/misc/relevant_standards.xml.ko @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="EUC-KR" ?> <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?> -<!-- English Revision: 1.7 --> +<!-- English Revision: 1.8 --> <!-- Copyright 2004 The Apache Software Foundation diff --git a/docs/manual/misc/relevant_standards.xml.meta b/docs/manual/misc/relevant_standards.xml.meta index 77d8a06c0d..063e5b05bc 100644 --- a/docs/manual/misc/relevant_standards.xml.meta +++ b/docs/manual/misc/relevant_standards.xml.meta @@ -7,5 +7,6 @@ <variants> <variant>en</variant> + <variant>ko</variant> </variants> </metafile> diff --git a/docs/manual/misc/rewriteguide.html b/docs/manual/misc/rewriteguide.html index 5e9a8c3795..01caef1379 100644 --- a/docs/manual/misc/rewriteguide.html +++ b/docs/manual/misc/rewriteguide.html @@ -1,3 +1,7 @@ URI: rewriteguide.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: rewriteguide.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR diff --git a/docs/manual/misc/rewriteguide.html.en b/docs/manual/misc/rewriteguide.html.en index f9f856c905..118223e9ad 100644 --- a/docs/manual/misc/rewriteguide.html.en +++ b/docs/manual/misc/rewriteguide.html.en @@ -18,7 +18,8 @@ <div id="path"> <a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.1</a> > <a href="./">Miscellaneous Documentation</a></div><div id="page-content"><div id="preamble"><h1>URL Rewriting Guide</h1> <div class="toplang"> -<p><span>Available Languages: </span><a href="../en/misc/rewriteguide.html" title="English"> en </a></p> +<p><span>Available Languages: </span><a href="../en/misc/rewriteguide.html" title="English"> en </a> | +<a href="../ko/misc/rewriteguide.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p> </div> <div class="note"> @@ -2092,7 +2093,8 @@ while (<>) { </div></div> <div class="bottomlang"> -<p><span>Available Languages: </span><a href="../en/misc/rewriteguide.html" title="English"> en </a></p> +<p><span>Available Languages: </span><a href="../en/misc/rewriteguide.html" title="English"> en </a> | +<a href="../ko/misc/rewriteguide.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p> </div><div id="footer"> <p class="apache">Copyright 1999-2004 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p> <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div> diff --git a/docs/manual/misc/rewriteguide.html.ko.euc-kr b/docs/manual/misc/rewriteguide.html.ko.euc-kr new file mode 100644 index 0000000000..8f9c341288 --- /dev/null +++ b/docs/manual/misc/rewriteguide.html.ko.euc-kr @@ -0,0 +1,2004 @@ +<?xml version="1.0" encoding="EUC-KR"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml" lang="ko" xml:lang="ko"><head><!-- + XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX + This file is generated from xml source: DO NOT EDIT + XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX + --> +<title>URL 재작성 지침서 - Apache HTTP Server</title> +<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" /> +<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" /> +<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /> +<link href="../images/favicon.ico" rel="shortcut icon" /></head> +<body id="manual-page"><div id="page-header"> +<p class="menu"><a href="../mod/">모듈</a> | <a href="../mod/directives.html">지시어들</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">용어</a> | <a href="../sitemap.html">사이트맵</a></p> +<p class="apache">Apache HTTP Server Version 2.1</p> +<img alt="" src="../images/feather.gif" /></div> +<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div> +<div id="path"> +<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.1</a> > <a href="./">Miscellaneous Documentation</a></div><div id="page-content"><div id="preamble"><h1>URL 재작성 지침서</h1> +<div class="toplang"> +<p><span>가능한 언어: </span><a href="../en/misc/rewriteguide.html" hreflang="en" rel="alternate" title="English"> en </a> | +<a href="../ko/misc/rewriteguide.html" title="Korean"> ko </a></p> +</div> + + <div class="note"> + <p>원저자<br /> + <cite>Ralf S. Engelschall <rse@apache.org></cite><br /> + 1997년 12월</p> + </div> + + <p>이 문서는 <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> <a href="../mod/mod_rewrite.html">참조 문서</a>를 보충한다. + 이 문서는 웹관리자가 실제 작업에서 부딪치게되는 전형적인 + URL관련 문제를 해결하기위해서 어떻게 아파치 + <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>를 사용하는지 설명한다. URL + 재작성 규칙을 설정하여 문제를 해결하는 방법을 자세히 설명한다.</p> + + </div> +<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#ToC1"><code>mod_rewrite</code> 소개</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#ToC2">실용적인 해결책</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#url">URL 구조</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#content">컨텐츠 다루기</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#access">접근 제한</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#other">기타</a></li> +</ul></div> +<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="ToC1" id="ToC1"><code>mod_rewrite</code> 소개</a></h2> + + + + <p>아파치 <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> 모듈은 굉장하다. + 즉, URL을 조작할 수 있는 강력하고 실로 정교한 모듈이다. + 상상해왔던 거의 모든 종류의 URL 조작이 가능하다. 그러나 + 그 대가로 사용하기 복잡하다. <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>의 + 최대 단점은 초보자가 이해하고 사용하기 쉽지 않다는 점이다. + 심지어 아파치 전문가도 종종 <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>의 + 새로운 용도를 발견한다.</p> + + <p>다른 말로: <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>에 대해 당신은 + 처음에 겁을 먹고 절대로 다시 사용하지 않거나, 강력함에 매료되어 + 앞으로 삶 동안 사랑에 빠질 것이다. 이 글은 첫번째 경우를 + 막기위해 이미 알려진 몇가지 성공사례를 소개하려고 한다.</p> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="ToC2" id="ToC2">실용적인 해결책</a></h2> + + + + <p>이제 내가 직접 만들었거나 다른 사람들이 만든 많은 실용적인 + 해결책이 나온다. 예제에서 URL 재작성의 흑마술을 마음껏 배우길 + 바란다.</p> + + <div class="warning">주의: 서버 설정에 따라 상황에 맞게 + 예제를 조금 수정해야 할 경우가 있다. 예를 들어, 추가로 + <code class="module"><a href="../mod/mod_alias.html">mod_alias</a></code>, <code class="module"><a href="../mod/mod_userdir.html">mod_userdir</a></code> + 등을 사용한다면 <code>[PT]</code> 플래그를 추가한다. 혹은 + 주서버설정/가상호스트 사용장소가 아닌 <code>.htaccess</code> + 사용장소에 알맞게 규칙을 수정할 수도 있다. 사용하기 전에 + 항상 규칙이 어떤 기능을 하는지 이해하도록 해라. 그러면 문제를 + 피할 수 있다.</div> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="url" id="url">URL 구조</a></h2> + + + + <h3>기준이 되는 URL</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>한 리소스에 대해 여러 URL을 가지는 웹서버가 있다. + 보통 (실제 사용하고 알려져야 할) 기준이 되는 URL과, + 단축 혹은 내부 용도의 URL이 있다. 사용자가 요청에 + 어떤 URL을 사용하던지 기준이 되는 URL만을 보여줘야 + 한다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>기준이 되지않는 모든 URL을 브라우저가 알도록 고치기위해 + 외부 HTTP 리다이렉션한다. 예를 들어 아래 규칙은 + <code>/~user</code>를 기준이 되는 <code>/u/user</code>로 + 대체하고, <code>/u/user</code> 마지막에 슬래쉬가 없다면 + 추가한다.</p> + +<div class="example"><pre> +RewriteRule ^/<strong>~</strong>([^/]+)/?(.*) /<strong>u</strong>/$1/$2 [<strong>R</strong>] +RewriteRule ^/([uge])/(<strong>[^/]+</strong>)$ /$1/$2<strong>/</strong> [<strong>R</strong>] +</pre></div> + </dd> + </dl> + + + + <h3>기준이 되는 호스트명</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd>...</dd> + + <dt>해결책:</dt> + + <dd> +<div class="example"><pre> +RewriteCond %{HTTP_HOST} !^fully\.qualified\.domain\.name [NC] +RewriteCond %{HTTP_HOST} !^$ +RewriteCond %{SERVER_PORT} !^80$ +RewriteRule ^/(.*) http://fully.qualified.domain.name:%{SERVER_PORT}/$1 [L,R] +RewriteCond %{HTTP_HOST} !^fully\.qualified\.domain\.name [NC] +RewriteCond %{HTTP_HOST} !^$ +RewriteRule ^/(.*) http://fully.qualified.domain.name/$1 [L,R] +</pre></div> + </dd> + </dl> + + + + <h3><code>DocumentRoot</code>를 옮긴 경우</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>웹서버의 <code class="directive"><a href="../mod/core.html#documentroot">DocumentRoot</a></code>는 보통 URL + "<code>/</code>"과 직접 관련있다. 그러나 이곳에 모든 + 자료가 있지 않고, 자료가 다른 여러 곳에 흩어져있는 + 경우가 있다. 예를 들어 인트라넷 사이트에 (외부를 위한 + 홈페이지) <code>/e/www/</code>와 (인트라넷을 위한 + 홈페이지) <code>/e/sww/</code>가 있다고 하자. 이제 + <code class="directive"><a href="../mod/core.html#documentroot">DocumentRoot</a></code>가 + <code>/e/www/</code>이기때문에, 요청에서 페이지에 + 포함된 그림 등을 이곳에서 가져와야 한다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>우리는 URL <code>/</code>를 <code>/e/www/</code>로 + 리다이렉션만 하면 된다. 사소해 보이지만 실제로 + <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>를 사용해서만 가능하다. + (<code class="module"><a href="../mod/mod_alias.html">mod_alias</a></code> 등이 제공하는) URL + <em>Alias</em> 같은 전형적인 방법은 <em>앞부분</em>만 + 찾는다. <code class="directive"><a href="../mod/core.html#documentroot">DocumentRoot</a></code>가 + 모든 URL의 앞부분이기때문에 이 방법을 사용하여 리다이렉션을 + 할 수 없다. <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>를 사용하면 + 진짜 간단하다:</p> + +<div class="example"><pre> +RewriteEngine on +RewriteRule <strong>^/$</strong> /e/www/ [<strong>R</strong>] +</pre></div> + </dd> + </dl> + + + + <h3>마지막 슬래쉬 문제</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>디렉토리를 지칭하는 URL의 마지막 슬래쉬 문제가 + 없다면 모든 웹관리자는 환호할 것이다. 슬래쉬가 없다면, + 즉 <code>/~quux/foo/</code> 대신 <code>/~quux/foo</code>를 + 사용하면 서버가 <code>foo</code>라는 <em>파일</em>을 + 찾기때문에 오류가 발생한다. 파일이 디렉토리이기때문에 + 받아들이지 않는다. 대부분의 경우 보통 서버가 자동으로 + URL을 고치지만, 가끔 직접 해줘야 할 경우가 있다. 예를 + 들어, CGI 스크립트 등으로 복잡한 URL 재작성을 한 후에 + 그러하다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>이 미묘한 문제의 해결방법은 서버가 자동으로 마지막 + 슬래쉬를 추가하는 것이다. 브라우저가 나머지 그림 등을 + 올바로 요청할 수 있도록, 외부 리다이렉션을 해야 한다. + 내부 리다이렉션을 한다면 디렉토리 페이지에만 동작하여 + 이 페이지가 상대 URL로 포함하는 그림을 브라우저가 + 요청할때 찾을 수 없다. 예를 들어, 외부 리다이렉션을 + 사용하지 않을때 <code>/~quux/foo/index.html</code>에서 + <code>image.gif</code>를 요청하면 + <code>/~quux/image.gif</code>를 요청하게 된다!</p> + + <p>그래서 이를 해결하기위해 다음과 같이 설정한다:</p> + +<div class="example"><pre> +RewriteEngine on +RewriteBase /~quux/ +RewriteRule ^foo<strong>$</strong> foo<strong>/</strong> [<strong>R</strong>] +</pre></div> + + <p>홈디렉토리의 최상위 <code>.htaccess</code> 파일에 + 다음과 같이 설정할 수도 있다. 그러나 처리하는데 부담이 + 된다.</p> + +<div class="example"><pre> +RewriteEngine on +RewriteBase /~quux/ +RewriteCond %{REQUEST_FILENAME} <strong>-d</strong> +RewriteRule ^(.+<strong>[^/]</strong>)$ $1<strong>/</strong> [R] +</pre></div> + </dd> + </dl> + + + + <h3>일관된 URL 구조로 만든 웹클러스터</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>인트라넷 웹서버군의 모든 웹서버에 동일하고 일관된 + URL 구조를 만들고 싶다. 즉, 모든 (정의상 서버에 속하여 + 서버에 의존적인!) URL을 서버 <em>독립적으로</em> 만든다! + 웹 이름공간에 서버독립적인 동일한 구조를 부여해야 한다: + URL은 실제 서버를 지칭하면 안된다. 서버군이 자동으로 + 실제 서버로 유도한다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>먼저 사용자, 그룹, 독립체의 위치 정보를 저장한 + (분산된) 외부맵에 실제 서버 정보를 얻어온다. 외부맵은 + 다음과 같은 형식이다</p> + +<div class="example"><pre> +user1 server_of_user1 +user2 server_of_user2 +: : +</pre></div> + + <p>우리는 이 정보를 각각 <code>map.xxx-to-host</code> + 파일에 저장했다. 다음으로 모든 서버에서 URL이 서버에 + 없다면 다음과 같은 URL을,</p> + +<div class="example"><pre> +/u/user/anypath +/g/group/anypath +/e/entity/anypath +</pre></div> + + <p>다음과 같이 리다이렉션한다</p> + +<div class="example"><pre> +http://physical-host/u/user/anypath +http://physical-host/g/group/anypath +http://physical-host/e/entity/anypath +</pre></div> + + <p>아래 규칙은 맵파일을 사용하여 이 작업을 한다 (server0은 + 맵에 항목이 없는 경우 사용할 기본서버라고 가정한다):</p> + +<div class="example"><pre> +RewriteEngine on + +RewriteMap user-to-host txt:/path/to/map.user-to-host +RewriteMap group-to-host txt:/path/to/map.group-to-host +RewriteMap entity-to-host txt:/path/to/map.entity-to-host + +RewriteRule ^/u/<strong>([^/]+)</strong>/?(.*) http://<strong>${user-to-host:$1|server0}</strong>/u/$1/$2 +RewriteRule ^/g/<strong>([^/]+)</strong>/?(.*) http://<strong>${group-to-host:$1|server0}</strong>/g/$1/$2 +RewriteRule ^/e/<strong>([^/]+)</strong>/?(.*) http://<strong>${entity-to-host:$1|server0}</strong>/e/$1/$2 + +RewriteRule ^/([uge])/([^/]+)/?$ /$1/$2/.www/ +RewriteRule ^/([uge])/([^/]+)/([^.]+.+) /$1/$2/.www/$3\ +</pre></div> + </dd> + </dl> + + + + <h3>홈디렉토리를 다른 웹서버로 이전</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>많은 웹관리자는 웹서버의 모든 홈디렉토리를 다른 + 웹서버로 이전한 경우 해결책을 물어본다. 이 방법은 + 이전 서버를 대체할 새로운 서버를 구성하는데 시간이 + 걸리는 경우에 필요하다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p><code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>를 사용하면 간단하다. + 이전 웹서버는 모든 <code>/~user/anypath</code> URL을 + <code>http://newserver/~user/anypath</code>로 + 리다이렉션하면 된다.</p> + +<div class="example"><pre> +RewriteEngine on +RewriteRule ^/~(.+) http://<strong>newserver</strong>/~$1 [R,L] +</pre></div> + </dd> + </dl> + + + + <h3>홈디렉토리 구조 만들기</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>사용자가 수천명인 사이트는 보통 홈디렉토리 구조를 + 만든다. 즉, 예를 들어 이름이 사용자명의 첫번째 문자인 + 하위디렉토리에 홈디렉토리를 둔다. 그래서, + <code>/~foo/anypath</code>는 + <code>/home/<strong>f</strong>/foo/.www/anypath</code>이고, + <code>/~bar/anypath</code>는 + <code>/home/<strong>b</strong>/bar/.www/anypath</code>이다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>물결표시가 있는 URL을 위와 같은 구조로 변환하기위해 + 다음 규칙을 사용한다.</p> + +<div class="example"><pre> +RewriteEngine on +RewriteRule ^/~(<strong>([a-z])</strong>[a-z0-9]+)(.*) /home/<strong>$2</strong>/$1/.www$3 +</pre></div> + </dd> + </dl> + + + + <h3>파일시스템 재구성</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>이 예는 실로 하드코어적이다: 디렉토리별 + <code>RewriteRules</code>를 매우 많이 사용하여 자료 + 자체는 그대로 둔체로 웹에 자료를 자연스럽게 브라우징하도록 + 한다. 배경: 나는 1992년 부터 자유롭게 사용할 수 있는 + 유닉스 소프트웨어들을 <strong><em>net.sw</em></strong>에 + 모아두고 있었다. 이는 내가 컴퓨터과학을 공부하면서 + 여러해동안 여가시간에 시스템 관리자와 네트웍 관리자를 + 해왔기때문에 내 취미이자 일이다. 매주마다 새로 소프트웨어가 + 추가될 때마다 디렉토리를 깊게 만들어왔다:</p> + +<div class="example"><pre> +drwxrwxr-x 2 netsw users 512 Aug 3 18:39 Audio/ +drwxrwxr-x 2 netsw users 512 Jul 9 14:37 Benchmark/ +drwxrwxr-x 12 netsw users 512 Jul 9 00:34 Crypto/ +drwxrwxr-x 5 netsw users 512 Jul 9 00:41 Database/ +drwxrwxr-x 4 netsw users 512 Jul 30 19:25 Dicts/ +drwxrwxr-x 10 netsw users 512 Jul 9 01:54 Graphic/ +drwxrwxr-x 5 netsw users 512 Jul 9 01:58 Hackers/ +drwxrwxr-x 8 netsw users 512 Jul 9 03:19 InfoSys/ +drwxrwxr-x 3 netsw users 512 Jul 9 03:21 Math/ +drwxrwxr-x 3 netsw users 512 Jul 9 03:24 Misc/ +drwxrwxr-x 9 netsw users 512 Aug 1 16:33 Network/ +drwxrwxr-x 2 netsw users 512 Jul 9 05:53 Office/ +drwxrwxr-x 7 netsw users 512 Jul 9 09:24 SoftEng/ +drwxrwxr-x 7 netsw users 512 Jul 9 12:17 System/ +drwxrwxr-x 12 netsw users 512 Aug 3 20:15 Typesetting/ +drwxrwxr-x 10 netsw users 512 Jul 9 14:08 X11/ +</pre></div> + + <p>1996년 7월 이 저장소를 멋있는 웹 인터페이스를 통해 + 세상에 공개하기로 결정햇다. "멋있다"는 말은, 최상위 + 디렉토리에 CGI 스크립트를 두지 않고도, 저장소 계층구조를 + 직접 브라우질하길 바란다는 뜻이다. 왜? 저장소를 나중에 + FTP로도 접근할 수 있도록 만들 예정이였기때문에 웹이나 + CGI와 관련된 내용을 같이 두기 싫었다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>해결책은 두 부분으로 나뉜다: 먼저 디렉토리 수준에서 + 필요한 모든 페이지를 동적으로 만드는 CGI 스크립트가 + 필요하다. 나는 이 스크립트들을 다음과 같이 + <code>/e/netsw/.www/</code>에 두었다:</p> + +<div class="example"><pre> +-rw-r--r-- 1 netsw users 1318 Aug 1 18:10 .wwwacl +drwxr-xr-x 18 netsw users 512 Aug 5 15:51 DATA/ +-rw-rw-rw- 1 netsw users 372982 Aug 5 16:35 LOGFILE +-rw-r--r-- 1 netsw users 659 Aug 4 09:27 TODO +-rw-r--r-- 1 netsw users 5697 Aug 1 18:01 netsw-about.html +-rwxr-xr-x 1 netsw users 579 Aug 2 10:33 netsw-access.pl +-rwxr-xr-x 1 netsw users 1532 Aug 1 17:35 netsw-changes.cgi +-rwxr-xr-x 1 netsw users 2866 Aug 5 14:49 netsw-home.cgi +drwxr-xr-x 2 netsw users 512 Jul 8 23:47 netsw-img/ +-rwxr-xr-x 1 netsw users 24050 Aug 5 15:49 netsw-lsdir.cgi +-rwxr-xr-x 1 netsw users 1589 Aug 3 18:43 netsw-search.cgi +-rwxr-xr-x 1 netsw users 1885 Aug 1 17:41 netsw-tree.cgi +-rw-r--r-- 1 netsw users 234 Jul 30 16:35 netsw-unlimit.lst +</pre></div> + + <p><code>DATA/</code> 하위디렉토리에 위에서 말한 저장소가 + 있다. 실제 <strong><em>net.sw</em></strong>의 내용은 보통 + <code>rdist</code>를 사용하여 자동으로 가져온다. 두번째 + 부분이 남았다: 어떻게 이 두 구조를 하나의 자연스러운 + URL 구조로 연결하는가? 사용자에게 <code>DATA/</code> + 디렉토리를 감추고, URL마다 적절한 CGI 스크립트를 실행하고 + 싶다. 해결책은 다음과 같다: 먼저 서버의 <code class="directive"><a href="../mod/core.html#documentroot">DocumentRoot</a></code>에서 공개된 + URL <code>/net.sw/</code>를 내부 경로 <code>/e/netsw</code>로 + 재작성하기위해 디렉토리별 설정파일에 다음과 같이 설정한다:</p> + +<div class="example"><pre> +RewriteRule ^net.sw$ net.sw/ [R] +RewriteRule ^net.sw/(.*)$ e/netsw/$1 +</pre></div> + + <p>첫번째 규칙은 마지막에 슬래쉬가 없는 요청을 위해서 + 사용했다! 두번째 규칙이 실제 작업을 한다. 그리고 디렉토리별 + 설정파일 <code>/e/netsw/.www/.wwwacl</code>에 결정적인 + 설정이 나온다:</p> + +<div class="example"><pre> +Options ExecCGI FollowSymLinks Includes MultiViews + +RewriteEngine on + +# 앞 부분이 /net.sw/ 로 접근한다 +RewriteBase /net.sw/ + +# 먼저 최상위 디렉토리를 +# cgi 스크립트로 재작성한다 +RewriteRule ^$ netsw-home.cgi [L] +RewriteRule ^index\.html$ netsw-home.cgi [L] + +# 브라우저가 디렉토리별 페이지를 요청한 경우 +# 하위디렉토리를 추출한다 +RewriteRule ^.+/(netsw-[^/]+/.+)$ $1 [L] + +# 이제 재작성을 마친다 +RewriteRule ^netsw-home\.cgi.* - [L] +RewriteRule ^netsw-changes\.cgi.* - [L] +RewriteRule ^netsw-search\.cgi.* - [L] +RewriteRule ^netsw-tree\.cgi$ - [L] +RewriteRule ^netsw-about\.html$ - [L] +RewriteRule ^netsw-img/.*$ - [L] + +# 다른 cgi 스크립트가 처리할 +# 하위디렉토리가 남았다 +RewriteRule !^netsw-lsdir\.cgi.* - [C] +RewriteRule (.*) netsw-lsdir.cgi/$1 +</pre></div> + + <p>해석을 위한 힌트:</p> + + <ol> + <li>네번째 부분에서 대체 필드('<code>-</code>')가 + 없고 <code>L</code> (last) 플래그가 있음을 주목하라</li> + + <li>마지막 부분에서 첫번째 규칙에 <code>!</code> + (not) 문자와 <code>C</code> (chain) 플래그를 주목하라</li> + + <li>마지막 규칙에서 기타 해당하지 않는 모든 경우를 + 잡아내는 패턴을 주목하라</li> + </ol> + </dd> + </dl> + + + + <h3>NCSA imagemap을 아파치 <code>mod_imap</code>으로</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>사람들은 NCSA 웹서버에서 현대적인 아파치 웹서버로 + 자연스럽게 옮겨가길 바란다. 그래서 오래된 NCSA + <code>imagemap</code> 프로그램을 사용한 페이지를 현대적인 + 아파치 <code class="module"><a href="../mod/mod_imap.html">mod_imap</a></code>로 처리하길 바란다. + 문제는 <code>imagemap</code> 프로그램을 + <code>/cgi-bin/imagemap/path/to/page.map</code>과 + 같이 참조하는 하이퍼링크가 많다는 것이다. 아파치는 + <code>/path/to/page.map</code>과 같은 요청을 받아야 + 한다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>모든 요청에서 앞부분을 동적으로 제거하는 전역 규칙을 + 사용한다:</p> + +<div class="example"><pre> +RewriteEngine on +RewriteRule ^/cgi-bin/imagemap(.*) $1 [PT] +</pre></div> + </dd> + </dl> + + + + <h3>여러 디렉토리에서 페이지 검색</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>가끔 웹서버가 여러 디렉토리에서 파일을 찾아야 할 + 때가 있다. 이 경우 MultiViews나 다른 방법은 도움이 + 안된다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>여러 디렉토리에서 파일을 찾는 규칙을 직접 프로그램한다.</p> + +<div class="example"><pre> +RewriteEngine on + +# 먼저 custom/에서 찾길 시도하고... +# ...찾으면 끝! +RewriteCond /your/docroot/<strong>dir1</strong>/%{REQUEST_FILENAME} -f +RewriteRule ^(.+) /your/docroot/<strong>dir1</strong>/$1 [L] + +# 두번째로 pub/에서 찾길 시도한다... +# ...찾으면 끝! +RewriteCond /your/docroot/<strong>dir2</strong>/%{REQUEST_FILENAME} -f +RewriteRule ^(.+) /your/docroot/<strong>dir2</strong>/$1 [L] + +# 못찾으면 다른 Alias나 ScriptAlias 지시어 등으로 진행한다. +RewriteRule ^(.+) - [PT] +</pre></div> + </dd> + </dl> + + + + <h3>URL에 따라 환경변수를 설정한다</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>요청들간에 상태정보를 유지하기위해 URL에 정보를 + 인코딩하는 방법도 있다. 그러나 단지 이 정보를 제거하기위해 + 모든 페이지에 CGI wrapper를 사용하고 싶지 않다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>재작성 규칙을 사용하여 상태정보를 추출하고, 추출한 + 정보를 나중에 XSSI나 CGI에서 사용하기위해 환경변수에 + 저장한다. 그래서 URL <code>/foo/S=java/bar/</code>는 + <code>/foo/bar/</code>로 변환되고 <code>STATUS</code>라는 + 환경변수 값을 "java"로 설정한다.</p> + +<div class="example"><pre> +RewriteEngine on +RewriteRule ^(.*)/<strong>S=([^/]+)</strong>/(.*) $1/$3 [E=<strong>STATUS:$2</strong>] +</pre></div> + </dd> + </dl> + + + + <h3>가상 사용자 호스트</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>가상호스트를 사용하지 않고 같은 컴퓨터로 DNS A + 레코드를 설정하여 + <code>www.<strong>username</strong>.host.domain.com</code>을 + 사용자의 홈페이지로 제공하고 싶다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>HTTP/1.0 요청의 경우 방법이 없지만, Host: HTTP + 헤더를 포함한 HTTP/1.1 요청은 다음 규칙을 사용하여 + 내부적으로 <code>http://www.username.host.com/anypath</code>를 + <code>/home/username/anypath</code>로 재작성할 수 + 있다:</p> + +<div class="example"><pre> +RewriteEngine on +RewriteCond %{<strong>HTTP_HOST</strong>} ^www\.<strong>[^.]+</strong>\.host\.com$ +RewriteRule ^(.+) %{HTTP_HOST}$1 [C] +RewriteRule ^www\.<strong>([^.]+)</strong>\.host\.com(.*) /home/<strong>$1</strong>$2 +</pre></div> + </dd> + </dl> + + + + <h3>홈디렉토리를 외부 서버로 리다이렉션</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>지역 도메인 <code>ourdomain.com</code> 밖에서 요청이 + 들어오면 홈디렉토리 URL을 다른 웹서버 + <code>www.somewhere.com</code>으로 리다리렉션하길 + 바란다. 종종 가상호스트 사용장소에서 사용한다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>재작성 조건을 사용하면 된다:</p> + +<div class="example"><pre> +RewriteEngine on +RewriteCond %{REMOTE_HOST} <strong>!^.+\.ourdomain\.com$</strong> +RewriteRule ^(/~.+) http://www.somewhere.com/$1 [R,L] +</pre></div> + </dd> + </dl> + + + + <h3>실패한 URL을 다른 웹서버로 리다이렉션</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>URL 재작성에 대해서 웹서버 A에 해당 파일이 없는 + 경우 웹서버 B로 요청을 리다이렉션하는 방법을 자주 + 물어본다. 보통 Perl로 작성한 <code class="directive"><a href="../mod/core.html#errordocument">ErrorDocument</a></code> CGI 스크립트를 + 사용하지만, <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>를 사용하는 + 방법도 있다. 그러나 성능은 <code class="directive"><a href="../mod/core.html#errordocument">ErrorDocument</a></code> CGI 스크립트보다 + 떨어짐을 명심하라!</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>첫번째 방법은 빠르지만 유연성이 떨어지고 완전하지 + 않다:</p> + +<div class="example"><pre> +RewriteEngine on +RewriteCond /your/docroot/%{REQUEST_FILENAME} <strong>!-f</strong> +RewriteRule ^(.+) http://<strong>webserverB</strong>.dom/$1 +</pre></div> + + <p>이 방법의 단점은 <code class="directive"><a href="../mod/core.html#documentroot">DocumentRoot</a></code> 안에 있는 페이지만 + 가능하다는 점이다. (예를 들어 홈디렉토리 등을 위해) + 조건을 추가할 수 있지만, 더 좋은 방법이 있다:</p> + +<div class="example"><pre> +RewriteEngine on +RewriteCond %{REQUEST_URI} <strong>!-U</strong> +RewriteRule ^(.+) http://<strong>webserverB</strong>.dom/$1 +</pre></div> + + <p><code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>의 URL 전방참조(look-ahead)를 + 사용한다. 그래서 모든 URL에 동작하고 안전하다. 그러나 + 모든 요청마다 내부 하위요청을 한번 더 하기때문에 웹서버 + 성능에 악영향을 준다. 그래서 강력한 CPU에서 웹서버를 + 실행한다면 사용하라. 컴퓨터가 느리다면 첫번째 방법이나 + 더 나은 <code class="directive"><a href="../mod/core.html#errordocument">ErrorDocument</a></code> + CGI 스크립트를 사용하라.</p> + </dd> + </dl> + + + + <h3>확장 리다이렉션</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>가끔 리다이렉션하는 URL을 더 조절할 필요가 있다. + 아파치 내부 URL escape 함수는 "<code>url#anchor</code>" + 같은 URL의 anchor도 escape한다. 아파치의 + <code>uri_escape()</code> 함수는 우물정자(#)도 같이 + escape하므로 사용할 수 없다. 그러면 어떻게 이런 URL로 + 리다이렉션할 수 있나?</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>직접 리다이렉션하는 NPH-CGI 스크립트를 사용한 해결책이 + 필요하다. escape를 하지 않기때문이다 (NPH=non-parseable + headers). 먼저 다음 서버설정을 하여 (재작성 규칙의 + 끝부분에 사용해야 한다) 새로운 URL scheme + <code>xredirect:</code>를 도입한다:</p> + +<div class="example"><pre> +RewriteRule ^xredirect:(.+) /path/to/nph-xredirect.cgi/$1 \ + [T=application/x-httpd-cgi,L] +</pre></div> + + <p>그러면 <code>xredirect:</code>로 시작하는 모든 URL은 + <code>nph-xredirect.cgi</code> 프로그램을 통하게 된다. + 프로그램은 다음과 같다:</p> + +<div class="example"><pre> +#!/path/to/perl +## +## nph-xredirect.cgi -- NPH/CGI script for extended redirects +## Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved. +## + +$| = 1; +$url = $ENV{'PATH_INFO'}; + +print "HTTP/1.0 302 Moved Temporarily\n"; +print "Server: $ENV{'SERVER_SOFTWARE'}\n"; +print "Location: $url\n"; +print "Content-type: text/html\n"; +print "\n"; +print "<html>\n"; +print "<head>\n"; +print "<title>302 Moved Temporarily (EXTENDED)</title>\n"; +print "</head>\n"; +print "<body>\n"; +print "<h1>Moved Temporarily (EXTENDED)</h1>\n"; +print "The document has moved <a HREF=\"$url\">here</a>.<p>\n"; +print "</body>\n"; +print "</html>\n"; + +##EOF## +</pre></div> + + <p>그러면 <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>가 직접 받지못하는 + 모든 URL scheme으로 리다이렉션할 수 있다. 예를 들어, + 다음과 같이 <code>news:newsgroup</code>으로 리다이렉션할 + 수 있다</p> + +<div class="example"><pre> +RewriteRule ^anyurl xredirect:news:newsgroup +</pre></div> + + <div class="note">주의: 위의 특별한 "통과" 규칙을 사용하여 + <code>xredirect:</code>를 마지막에 확장해야 하기때문에 + 규칙에 <code>[R]</code>이나 <code>[R,L]</code>을 사용하면 + 안된다.</div> + </dd> + </dl> + + + + <h3>저장소 접근 중계(multiplexer)</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p><a href="http://www.perl.com/CPAN">http://www.perl.com/CPAN</a>에 + 있는 대단한 CPAN (Comprehensive Perl Archive Network)을 + 아는가? 이 주소는 세계에 흩어진 여러 CPAN 미러 FTP + 서버중 클라이언트에 가까이 있는 서버로 리다이렉션한다. + 이를 FTP 접근 중계 서비스라고 한다. CPAN은 CGI 스크립트를 + 사용하지만, <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>를 사용하여 + 비슷하게 만들 수 있을까?</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>먼저 <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> 3.0.0 버전부터 + 리다이렉션에 "<code>ftp:</code>" scheme을 사용할 수 + 있다. 다음으로 클라이언트의 최상위 도메인을 <code class="directive"><a href="../mod/mod_rewrite.html#rewritemap">RewriteMap</a></code>과 같이 + 사용하여 위치를 추정할 수 있다. 복잡히 엮인 규칙에서 + 최상위 도메인을 중계맵의 키로 사용한다.</p> + +<div class="example"><pre> +RewriteEngine on +RewriteMap multiplex txt:/path/to/map.cxan +RewriteRule ^/CxAN/(.*) %{REMOTE_HOST}::$1 [C] +RewriteRule ^.+\.<strong>([a-zA-Z]+)</strong>::(.*)$ ${multiplex:<strong>$1</strong>|ftp.default.dom}$2 [R,L] +</pre></div> + +<div class="example"><pre> +## +## map.cxan -- Multiplexing Map for CxAN +## + +de ftp://ftp.cxan.de/CxAN/ +uk ftp://ftp.cxan.uk/CxAN/ +com ftp://ftp.cxan.com/CxAN/ + : +##EOF## +</pre></div> + </dd> + </dl> + + + + <h3>시간에 따른 재작성</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>시간에 따라 다른 내용을 서비스하는 경우 많은 웹관리자는 + 잠시 특별한 페이지로 리다이렉션하기위해 CGI 스크립트를 + 사용한다. <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>로는 어떻게 + 할 수 있는가?</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>재작성 조건에서 사용할 수 있는 여러 <code>TIME_xxx</code> + 변수가 있다. 변수와 특별한 사전순서 비교 + <code><STRING</code>, <code>>STRING</code>, + <code>=STRING</code>을 사용하여 시간에 따라 리다이렉션할 + 수 있다:</p> + +<div class="example"><pre> +RewriteEngine on +RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700 +RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900 +RewriteRule ^foo\.html$ foo.day.html +RewriteRule ^foo\.html$ foo.night.html +</pre></div> + + <p>URL <code>foo.html</code>을 요청하면 + <code>07:00-19:00</code> 동안 <code>foo.day.html</code> + 내용을 서비스하고, 나머지 시간 동안 + <code>foo.night.html</code> 내용을 서비스한다. 홈페이지에서 + 사용하기 좋은 기능이다...</p> + </dd> + </dl> + + + + <h3>YYYY를 XXXX로 이전한 경우 역호환</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>여러 <code>.html</code> 파일을 <code>.phtml</code>로 + 변환하는 등 <code>document.YYYY</code>를 + <code>document.XXXX</code>로 이전한후 역호환(backward + compatibility) URL을 (가상적으로 존재하게) 만들 수 + 있나?</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>이름을 기본이름으로 재작성한후 새로운 확장자를 + 가진 파일이 있는지 검사한다. 있다면 그 파일명을 사용하고, + 없으면 URL을 원래 상태로 재작성한다.</p> + + +<div class="example"><pre> +# 문서.html 이 없고 +# 문서.phtml 만 있는 경우 +# 문서.html 을 문서.phtml 로 +# 재작성하는 역호환 규칙 +RewriteEngine on +RewriteBase /~quux/ +# 기본이름을 찾고, 찾았다는 사실을 기억한다 +RewriteRule ^(.*)\.html$ $1 [C,E=WasHTML:yes] +# 파일이 있다면 문서.phtml 로 재작성한다 +RewriteCond %{REQUEST_FILENAME}.phtml -f +RewriteRule ^(.*)$ $1.phtml [S=1] +# 아니면 앞에서 찾은 기본이름을 되돌린다 +RewriteCond %{ENV:WasHTML} ^yes$ +RewriteRule ^(.*)$ $1.html +</pre></div> + </dd> + </dl> + + + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="content" id="content">컨텐츠 다루기</a></h2> + + + + <h3>새로 이전 (감추기)</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>최근 <code>foo.html</code>을 <code>bar.html</code>로 + 변경하고 역호환성을 위해 이전 URL을 계속 제공하고 + 싶다고 가정하자. 사용자는 이전 URL이 변경되었다는 + 사실을 눈치채지 못한다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>다음 규칙으로 이전 URL을 내부적으로 새로운 URL로 + 재작성한다:</p> + +<div class="example"><pre> +RewriteEngine on +RewriteBase /~quux/ +RewriteRule ^<strong>foo</strong>\.html$ <strong>bar</strong>.html +</pre></div> + </dd> + </dl> + + + + <h3>새로 이전 (알리기)</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>다시 <code>foo.html</code>을 <code>bar.html</code>로 + 변경하고 역호환성을 위해 이전 URL을 계속 제공하고 + 싶다고 가정하자. 그러나 이제는 이전 URL을 사용하면 + 사용자에게 새로운 URL을 힌트로 알려준다. 즉, 브라우저 + 주소창이 변한다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>새로운 URL로 HTTP 리다이렉션하다. 그러면 브라우저가 + 새로운 URL를 보이고 변경사실을 사용자가 알게된다:</p> + +<div class="example"><pre> +RewriteEngine on +RewriteBase /~quux/ +RewriteRule ^<strong>foo</strong>\.html$ <strong>bar</strong>.html [<strong>R</strong>] +</pre></div> + </dd> + </dl> + + + + <h3>브라우저에 따른 내용</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>최소한 중요한 최상위 페이지는 브라우저에 최적화된 + 내용으로 서비스해야할 경우가 있다. 즉, 최신 Netscape + 브라우저에게는 최상의 버전을, Lynx 브라우저에게는 + 최저 버전을, 나머지 브라우저에는 평균적인 버전을 + 제공한다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>브라우저가 내용협상을 위해 자신의 종류에 대한 정보를 + 제공하지 않기때문에 내용협상을 사용할 수 없다. 대신 + HTTP "User-Agent" 헤더를 사용한다. 다음 규칙은 HTTP + "User-Agent" 헤더가 "Mozilla/3"으로 시작하면 + <code>foo.html</code> 페이지를 <code>foo.NS.html</code>로 + 재작성하고 재작성을 중단한다. 브라우저가 "Lynx"나 + "Mozilla" 버전 1 혹은 2라면 URL은 + <code>foo.20.html</code>이 된다. 나머지 브라우저는 + <code>foo.32.html</code> 페이지를 받는다. 아래 규칙이 + 이 작업을 한다:</p> + +<div class="example"><pre> +RewriteCond %{HTTP_USER_AGENT} ^<strong>Mozilla/3</strong>.* +RewriteRule ^foo\.html$ foo.<strong>NS</strong>.html [<strong>L</strong>] + +RewriteCond %{HTTP_USER_AGENT} ^<strong>Lynx/</strong>.* [OR] +RewriteCond %{HTTP_USER_AGENT} ^<strong>Mozilla/[12]</strong>.* +RewriteRule ^foo\.html$ foo.<strong>20</strong>.html [<strong>L</strong>] + +RewriteRule ^foo\.html$ foo.<strong>32</strong>.html [<strong>L</strong>] +</pre></div> + </dd> + </dl> + + + + <h3>동적 미러</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>외부 호스트에 우리 사이트로 가져오고 싶은 좋은 + 웹페이지가 있다고 가정하자. FTP 서버의 경우 직접 외부 + 자료의 최신복사본을 유지하는 <code>mirror</code> 프로그램을 + 사용할 수 있고, 웹서버라면 HTTP로 비슷한 작업을 하는 + <code>webcopy</code> 프로그램을 사용할 수 있다. 그러나 + 두 방법 모두 단점이 있다: 복사본은 가끔씩 프로그램을 + 실행해줄 때만 최신판으로 유지된다. 직접 구성해야하는 + 정적인 미러가 아니라면 좋겠다. 대신 (외부 호스트에서 + 자료가 갱신되면) 필요할때 자동으로 자료를 갱신하는 + 동적 미러가 필요하다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>이를 위해 <dfn>Proxy Throughput</dfn> 기능을 (플래그 + <code>[P]</code>) 사용하여 외부 웹페이지 혹은 외부 + 웹공간 전체를 우리 이름공간으로 대응한다:</p> + +<div class="example"><pre> +RewriteEngine on +RewriteBase /~quux/ +RewriteRule ^<strong>hotsheet/</strong>(.*)$ <strong>http://www.tstimpreso.com/hotsheet/</strong>$1 [<strong>P</strong>] +</pre></div> + +<div class="example"><pre> +RewriteEngine on +RewriteBase /~quux/ +RewriteRule ^<strong>usa-news\.html</strong>$ <strong>http://www.quux-corp.com/news/index.html</strong> [<strong>P</strong>] +</pre></div> + </dd> + </dl> + + + + <h3>동적 역미러</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd>...</dd> + + <dt>해결책:</dt> + + <dd> +<div class="example"><pre> +RewriteEngine on +RewriteCond /mirror/of/remotesite/$1 -U +RewriteRule ^http://www\.remotesite\.com/(.*)$ /mirror/of/remotesite/$1 +</pre></div> + </dd> + </dl> + + + + <h3>없는 자료를 인트라넷에서 가져오기</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>실제 자료를 방화벽이 보호하는 (내부) 인트라넷 웹서버에 + (<code>www2.quux-corp.dom</code>) 저장하면서, 기업의 + (외부) 인터넷 웹서버를 (<code>www.quux-corp.dom</code>) + 실행하는 것처럼 보이게 한다. 외부 웹서버는 요청한 + 자료를 내부 웹서버에서 가져온다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>먼저 방화벽이 내부 웹서버를 보호하고 외부 웹서버만이 + 내부 웹서버에서 자료를 얻을 수 있게 한다. 다음과 같이 + 패킷필터링 방화벽을 설정한다:</p> + +<div class="example"><pre> +<strong>ALLOW</strong> Host www.quux-corp.dom Port >1024 --> Host www2.quux-corp.dom Port <strong>80</strong> +<strong>DENY</strong> Host * Port * --> Host www2.quux-corp.dom Port <strong>80</strong> +</pre></div> + + <p>실제 설정문법에 알맞게 고쳐라. 없는 자료를 내부적으로 + proxy throughput 기능을 통해 요청하는 + <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> 규칙을 작성한다:</p> + +<div class="example"><pre> +RewriteRule ^/~([^/]+)/?(.*) /home/$1/.www/$2 +RewriteCond %{REQUEST_FILENAME} <strong>!-f</strong> +RewriteCond %{REQUEST_FILENAME} <strong>!-d</strong> +RewriteRule ^/home/([^/]+)/.www/?(.*) http://<strong>www2</strong>.quux-corp.dom/~$1/pub/$2 [<strong>P</strong>] +</pre></div> + </dd> + </dl> + + + + <h3>로드밸런싱 (부하 분산하기)</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p><code>www.foo.com</code>의 통신량을 + <code>www[0-5].foo.com</code> (총 서버 6대)으로 분산하고 + 싶다. 어떻게 하는가?</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>매우 다양한 방법으로 이 문제를 해결할 수 있다. + 먼저 DNS를 사용한 잘 알려진 방법을 설명하고, + <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>를 사용하는 경우를 살펴보자:</p> + + <ol> + <li> + <strong>DNS Round-Robin</strong> + + <p>가장 간단한 로드밸런싱 방법은 <code>BIND</code>의 + DNS round-robin 방식을 사용하는 것이다. 다음과 + 같이 DNS A(address) 레코드에 + <code>www[0-9].foo.com</code>을 설정한다.</p> + +<div class="example"><pre> +www0 IN A 1.2.3.1 +www1 IN A 1.2.3.2 +www2 IN A 1.2.3.3 +www3 IN A 1.2.3.4 +www4 IN A 1.2.3.5 +www5 IN A 1.2.3.6 +</pre></div> + + <p>그리고 다음 항목을 추가한다:</p> + +<div class="example"><pre> +www IN CNAME www0.foo.com. + IN CNAME www1.foo.com. + IN CNAME www2.foo.com. + IN CNAME www3.foo.com. + IN CNAME www4.foo.com. + IN CNAME www5.foo.com. + IN CNAME www6.foo.com. +</pre></div> + + <p>잘못된 것처럼 보이지만, 실제로 <code>BIND</code>의 + 의도된 기능이다. 이제 <code>www.foo.com</code>을 + 찾으면, <code>BIND</code>는 매번 순서를 조금씩 + 바꿔가며 <code>www0-www6</code>을 반환한다. 그래서 + 클라이언트들을 여러 서버로 분산한다. 그러나 DNS + 검색 결과가 네트웍의 다른 네임서버에 캐쉬되여 + <code>www.foo.com</code>을 찾은 결과가 특정 + <code>wwwN.foo.com</code>이면 클라이언트의 다음 + 요청들도 같은 <code>wwwN.foo.com</code>으로 + 보내지기때문에 완벽한 로드밸런싱 기법이 아님을 + 주의하라. 그러나 크게 보면 요청이 여러 웹서버에 + 분산되므로 효과가 좋다.</p> + </li> + + <li> + <strong>DNS 로드밸런싱</strong> + + <p><a href="http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html">http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html</a>에 + 있는 <code>lbnamed</code> 프로그램을 사용하여 + 정교한 DNS기반 로드밸런싱을 할 수 있다. DNS가 + 실제 로드밸런싱을 하도록 만드는 여러 도구와 Perl + 5 프로그램이다.</p> + </li> + + <li> + <strong>Proxy Throughput Round-Robin</strong> + + <p>이 방법은 <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>와 proxy + throughput 기능을 사용한다. 먼저 DNS에 다음 항목을 + 사용하여 <code>www0.foo.com</code>이 실제 + <code>www.foo.com</code>을 전담하게 한다</p> + +<div class="example"><pre> +www IN CNAME www0.foo.com. +</pre></div> + + <p>그리고 <code>www0.foo.com</code>을 프록시전용 + 서버로 변경한다. 즉, URL을 받으면 서버는 내부 + 프록시를 통해 다른 5대 서버중 (<code>www1-www5</code>) + 한대로 보내기만 한다. 이를 위해 먼저 모든 URL을 + 로드밸런싱 스크립트 <code>lb.pl</code>로 보내는 + 규칙을 만든다.</p> + +<div class="example"><pre> +RewriteEngine on +RewriteMap lb prg:/path/to/lb.pl +RewriteRule ^/(.+)$ ${lb:$1} [P,L] +</pre></div> + + <p><code>lb.pl</code>을 작성한다:</p> + +<div class="example"><pre> +#!/path/to/perl +## +## lb.pl -- 로드밸런싱 스크립트 +## + +$| = 1; + +$name = "www"; # 기본 호스트명 +$first = 1; # 첫번째 서버 (자신이 0이기 때문에, 0을 사용하지 않는다) +$last = 5; # round-robin에서 마지막 서버 +$domain = "foo.dom"; # 도메인명 + +$cnt = 0; +while (<STDIN>) { + $cnt = (($cnt+1) % ($last+1-$first)); + $server = sprintf("%s%d.%s", $name, $cnt+$first, $domain); + print "http://$server/$_"; +} + +##EOF## +</pre></div> + + <div class="note">마지막 주의: 왜 이 방법이 유용한가? + <code>www0.foo.com</code>에 부담이 가지않는가? + 물론, 부담이 된다. 그러나 단순한 proxy throughput + 요청만 하기때문에 괜찮다! 모든 SSI, CGI, ePerl + 등은 전적으로 다른 서버가 처리한다. 이것이 핵심이다.</div> + </li> + + <li> + <strong>하드웨어/TCP Round-Robin</strong> + + <p>하드웨어를 사용한 해결책도 있다. Cisco는 TCP/IP + 수준에서 로드밸런싱을 하는 LocalDirector라는 괴물을 + 판다. 실제로는 웹서버군 앞단에 위치하는 일종의 + 회로수준 게이트웨이다. 자금이 충분하고 고성능 + 해결책이 필요하다면 이것을 사용하라.</p> + </li> + </ol> + </dd> + </dl> + + + + <h3>새로운 MIME-type, 새로운 서비스</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>네트웍에는 멋진 CGI 프로그램들이 많다. 그러나 사용하기 + 번거러워서 많은 웹관리자가 사용하지 않는다. 아파치의 + MIME-type에 따른 Action 핸들러 기능도 CGI 프로그램이 + 특별한 URL을 (정확히 <code>PATH_INFO</code>와 + <code>QUERY_STRINGS</code>) 프로그램의 입력으로 사용하지 + 않을 때만 적절하다. 먼저, 확장자가 (secure CGI를 줄여) + <code>.scgi</code>인 파일을 유명한 <code>cgiwrap</code> + 프로그램으로 처리하기위해 새로운 type을 설정한다. + 문제는 (위에서 본) 일관된 URL 구조를 사용하는 경우 + 사용자 홈디렉토리가 <code>/u/user/foo/bar.scgi</code>같은 + URL인 점이다. <code>cgiwrap</code>는 + <code>/~user/foo/bar.scgi/</code> 형식의 URL을 + 원하기때문이다. 다음 규칙이 문제를 해결한다:</p> + +<div class="example"><pre> +RewriteRule ^/[uge]/<strong>([^/]+)</strong>/\.www/(.+)\.scgi(.*) ... +... /internal/cgi/user/cgiwrap/~<strong>$1</strong>/$2.scgi$3 [NS,<strong>T=application/x-http-cgi</strong>] +</pre></div> + + <p>이제 다른 멋진 프로그램, (URL 하위트리에 대한 + <code>access.log</code>를 출력하는) <code>wwwlog</code>와 + (URL 하위트리에 Glimpse를 실행하는) <code>wwwidx</code>가 + 있다고 가정하자. 우리는 프로그램에게 작업할 대상인 + URL 영역을 알려줘야 한다. 그러나 요청할때마다 항상 + 적어줘야 하기때문에 깔끔하지 않다. 즉, 보통 + <code>/u/user/foo/</code>에 대해 <code>swwidx</code> + 프로그램을 실행한다면 다음과 같은 링크를 사용한다</p> + +<div class="example"><pre> +/internal/cgi/user/swwidx?i=/u/user/foo/ +</pre></div> + + <p>깔끔하지 않다. 링크에 영역의 위치<strong>와</strong> + CGI 위치를 <strong>모두</strong> 적어야 하기때문이다. + 영역을 재구성한다면 여러 하이퍼링크를 수정하는데 많은 + 시간이 걸릴 것이다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>해결책은 자동으로 적절한 CGI를 실행하는 새로운 + 특별한 URL 형식을 만드는 것이다. 다음과 같이 설정한다:</p> + +<div class="example"><pre> +RewriteRule ^/([uge])/([^/]+)(/?.*)/\* /internal/cgi/user/wwwidx?i=/$1/$2$3/ +RewriteRule ^/([uge])/([^/]+)(/?.*):log /internal/cgi/user/wwwlog?f=/$1/$2$3 +</pre></div> + + <p>이제 <code>/u/user/foo/</code>을 검색하는 링크는 + 다음과 같다</p> + +<div class="example"><pre> +HREF="*" +/u/user/foo/* (???) +</pre></div> + + <p>내부적으로 다음과 같이 자동변환된다</p> + +<div class="example"><pre> +/internal/cgi/user/wwwidx?i=/u/user/foo/ +</pre></div> + + <p>같은 방법으로 링크 뒤에 <code>:log</code>를 사용하여 + 접근 로그 CGI 프로그램을 실행할 수 있다.</p> + </dd> + </dl> + + + + <h3>정적에서 동적으로</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>어떻게 브라우저와 사용자가 모르게 자연스럽게 정적 + 페이지 <code>foo.html</code>을 동적인 <code>foo.cgi</code>로 + 변경할 수 있나.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>URL을 CGI 스크립트로 재작성하고, MIME-type을 수정하여 + CGI 스크립트로 실행하게 한다. 그래서 + <code>/~quux/foo.html</code>를 요청하면 내부적으로 + <code>/~quux/foo.cgi</code>를 실행하게 된다.</p> + +<div class="example"><pre> +RewriteEngine on +RewriteBase /~quux/ +RewriteRule ^foo\.<strong>html</strong>$ foo.<strong>cgi</strong> [T=<strong>application/x-httpd-cgi</strong>] +</pre></div> + </dd> + </dl> + + + + <h3>즉석 컨텐츠 재생성</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>이 방법은 실로 비기이다: 동적으로 페이지를 생성하지만, + 정적으로 페이지를 서비스한다. 즉, 페이지는 순수하게 + (파일시스템에서 읽은 내용을 그대로) 정적 페이지로 + 전달되지만, 없을 경우 웹서버가 동적으로 생성한다. + 그러면 누가 (혹은 cron 작업이) 정적 컨텐츠를 지우지않는 + 한 CGI가 생성한 페이지를 정적으로 서비스한다. 컨텐츠를 + 지우면 내용을 갱신한다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + 다음 규칙을 사용한다: + +<div class="example"><pre> +RewriteCond %{REQUEST_FILENAME} <strong>!-s</strong> +RewriteRule ^page\.<strong>html</strong>$ page.<strong>cgi</strong> [T=application/x-httpd-cgi,L] +</pre></div> + + <p>여기서 <code>page.html</code>를 요청할때 + <code>page.html</code>이 없거나 파일크기가 0인 경우 + 내부적으로 <code>page.cgi</code>를 실행한다. 여기서 + 비결은 <code>page.cgi</code>가 일반적인 CGI 스크립트와 + 같이 <code>STDOUT</code>에 출력하고, 추가로 출력을 + <code>page.html</code> 파일에 적는다. 한번 실행한후 + 서버는 <code>page.html</code>의 정보를 보낸다. 웹관리자가 + 강재로 내용을 갱신하고 싶다면, (보통 cron 작업이) + <code>page.html</code>을 지우기만 하면 된다.</p> + </dd> + </dl> + + + + <h3>자동으로 새로 고침하는 문서</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>복잡한 웹페이지를 만들때 편집자가 내용을 수정할 + 때마다 자동으로 페이지를 새로 고침하는 웹브라우저가 + 있으면 얼마나 좋을까? 불가능한가?</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>가능하다! MIME multipart 기능과 웹서버 NPH 기능, + <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>의 URL 조작 능력을 결합하면 + 된다. 먼저, 새로운 URL 기능을 만든다: URL에 + <code>:refresh</code>를 추가하기만 하면 파일시스템에서 + 수정될 때마다 새로 고침한다.</p> + +<div class="example"><pre> +RewriteRule ^(/[uge]/[^/]+/?.*):refresh /internal/cgi/apache/nph-refresh?f=$1 +</pre></div> + + <p>이제 다음 URL에 접근하면</p> + +<div class="example"><pre> +/u/foo/bar/page.html:refresh +</pre></div> + + <p>다음 URL을 내부적으로 부른다</p> + +<div class="example"><pre> +/internal/cgi/apache/nph-refresh?f=/u/foo/bar/page.html +</pre></div> + + <p>이제 NPH-CGI 스크립트만 남았다. 보통 "독자에게 + 연습으로 남겨둠"이라고 말하지만 ;-) 나는 이것도 제공한다.</p> + +<div class="example"><pre> +#!/sw/bin/perl +## +## nph-refresh -- NPH/CGI script for auto refreshing pages +## Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved. +## +$| = 1; + +# split the QUERY_STRING variable +@pairs = split(/&/, $ENV{'QUERY_STRING'}); +foreach $pair (@pairs) { + ($name, $value) = split(/=/, $pair); + $name =~ tr/A-Z/a-z/; + $name = 'QS_' . $name; + $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; + eval "\$$name = \"$value\""; +} +$QS_s = 1 if ($QS_s eq ''); +$QS_n = 3600 if ($QS_n eq ''); +if ($QS_f eq '') { + print "HTTP/1.0 200 OK\n"; + print "Content-type: text/html\n\n"; + print "&lt;b&gt;ERROR&lt;/b&gt;: No file given\n"; + exit(0); +} +if (! -f $QS_f) { + print "HTTP/1.0 200 OK\n"; + print "Content-type: text/html\n\n"; + print "&lt;b&gt;ERROR&lt;/b&gt;: File $QS_f not found\n"; + exit(0); +} + +sub print_http_headers_multipart_begin { + print "HTTP/1.0 200 OK\n"; + $bound = "ThisRandomString12345"; + print "Content-type: multipart/x-mixed-replace;boundary=$bound\n"; + &print_http_headers_multipart_next; +} + +sub print_http_headers_multipart_next { + print "\n--$bound\n"; +} + +sub print_http_headers_multipart_end { + print "\n--$bound--\n"; +} + +sub displayhtml { + local($buffer) = @_; + $len = length($buffer); + print "Content-type: text/html\n"; + print "Content-length: $len\n\n"; + print $buffer; +} + +sub readfile { + local($file) = @_; + local(*FP, $size, $buffer, $bytes); + ($x, $x, $x, $x, $x, $x, $x, $size) = stat($file); + $size = sprintf("%d", $size); + open(FP, "&lt;$file"); + $bytes = sysread(FP, $buffer, $size); + close(FP); + return $buffer; +} + +$buffer = &readfile($QS_f); +&print_http_headers_multipart_begin; +&displayhtml($buffer); + +sub mystat { + local($file) = $_[0]; + local($time); + + ($x, $x, $x, $x, $x, $x, $x, $x, $x, $mtime) = stat($file); + return $mtime; +} + +$mtimeL = &mystat($QS_f); +$mtime = $mtime; +for ($n = 0; $n &lt; $QS_n; $n++) { + while (1) { + $mtime = &mystat($QS_f); + if ($mtime ne $mtimeL) { + $mtimeL = $mtime; + sleep(2); + $buffer = &readfile($QS_f); + &print_http_headers_multipart_next; + &displayhtml($buffer); + sleep(5); + $mtimeL = &mystat($QS_f); + last; + } + sleep($QS_s); + } +} + +&print_http_headers_multipart_end; + +exit(0); + +##EOF## +</pre></div> + </dd> + </dl> + + + + <h3>대량의 가상호스트</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>가상호스트가 몇개만 있다면 아파치의 <code class="directive"><a href="../mod/core.html#virtualhost"><VirtualHost></a></code> + 기능이 잘 동작한다. 그러나 가상호스트가 수백개 있는 + ISP라면 이 기능이 최선은 아니다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>이 기능을 제공하려면 <dfn>Proxy Throughput</dfn> + 기능을 (플래그 <code>[P]</code>) 사용하여 외부 웹페이지 + 혹은 전체 외부 웹영역을 우리의 이름공간에 대응한다:</p> + +<div class="example"><pre> +## +## vhost.map +## +www.vhost1.dom:80 /path/to/docroot/vhost1 +www.vhost2.dom:80 /path/to/docroot/vhost2 + : +www.vhostN.dom:80 /path/to/docroot/vhostN +</pre></div> + +<div class="example"><pre> +## +## httpd.conf +## + : +# 리다이렉트할때 정규 호스트명을 사용한다. +UseCanonicalName on + + : +# 가상호스트를 CLF 형식 앞에 추가한다 +CustomLog /path/to/access_log "%{VHOST}e %h %l %u %t \"%r\" %>s %b" + : + +# 주서버에서 재작성 엔진을 사용한다 +RewriteEngine on + +# 두 맵을 정의한다: 하나는 URL을 고치고, +# 다른 하나는 가상호스트별 DocumentRoot를 +# 정의한다. +RewriteMap lowercase int:tolower +RewriteMap vhost txt:/path/to/vhost.map + +# 이제 크고 복잡한 규칙 한개를 사용하여 +# 가상호스트로 대응한다. +# +# 1. 가상호스트들이 같이 사용하는 위치는 대응하지 않는다 +RewriteCond %{REQUEST_URL} !^/commonurl1/.* +RewriteCond %{REQUEST_URL} !^/commonurl2/.* + : +RewriteCond %{REQUEST_URL} !^/commonurlN/.* +# +# 2. 우리가 현재 사용하는 방법이 Host 헤더를 +# 가상호스트를 지원하므로 +# Host 헤더가 있는지 확인한다 +RewriteCond %{HTTP_HOST} !^$ +# +# 3. 호스트명을 소문자로 만든다 +RewriteCond ${lowercase:%{HTTP_HOST}|NONE} ^(.+)$ +# +# 4. vhost.map에서 호스트명을 찾고 +# 경로일때만 기억한다 +# (위에서 "NONE"은 아니다) +RewriteCond ${vhost:%1} ^(/.*)$ +# +# 5. 마지막으로 URL을 문서 위치로 대응하고 +# 로그에 남기기위해 가상호스트를 기억해 둔다 +RewriteRule ^/(.*)$ %1/$1 [E=VHOST:${lowercase:%{HTTP_HOST}}] + : +</pre></div> + </dd> + </dl> + + + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="access" id="access">접근 제한</a></h2> + + + + <h3>로봇 막기</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>어떻게 하면 특정 웹공간의 페이지를 긁어모으는 귀찮은 + 로봇을 막을 수 있나? "Robot Exclusion Protocol" 항목을 + 저장한 <code>/robots.txt</code> 파일은 보통 이런 로봇을 + 막는데 충분하지 않다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>(아마도 디렉토리가 깊어서 로봇이 돌아다니면 서버에 + 부담이 큰 경우) 웹공간 <code>/~quux/foo/arc/</code>에 + 있는 URL들을 거부하는 규칙을 사용한다. 우리는 특정 + 로봇의 접근을 막아야 한다. 즉, 로봇을 실행하는 호스트를 + 막는 것으로는 불충분하며, 그 호스트의 사용자도 막아버리게 + 된다. User-Agent HTTP 헤더 정보도 비교한다.</p> + +<div class="example"><pre> +RewriteCond %{HTTP_USER_AGENT} ^<strong>NameOfBadRobot</strong>.* +RewriteCond %{REMOTE_ADDR} ^<strong>123\.45\.67\.[8-9]</strong>$ +RewriteRule ^<strong>/~quux/foo/arc/</strong>.+ - [<strong>F</strong>] +</pre></div> + </dd> + </dl> + + + + <h3>그림 퍼가기 방지</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p><code>http://www.quux-corp.de/~quux/</code>에 있는 + 페이지들이 GIF 그림을 포함한다고 가정하자. 이 그림이 + 멋있어서, 다른 사람들이 자신의 페이지에 직접 링크를 + 건다. 서버에 불필요한 부담이 되므로 막고 싶다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>그림을 100% 보호할 수는 없지만, 최소한 브라우저가 + HTTP Referer 헤더를 보내는 경우 제한할 수 있다.</p> + +<div class="example"><pre> +RewriteCond %{HTTP_REFERER} <strong>!^$</strong> +RewriteCond %{HTTP_REFERER} !^http://www.quux-corp.de/~quux/.*$ [NC] +RewriteRule <strong>.*\.gif$</strong> - [F] +</pre></div> + +<div class="example"><pre> +RewriteCond %{HTTP_REFERER} !^$ +RewriteCond %{HTTP_REFERER} !.*/foo-with-gif\.html$ +RewriteRule <strong>^inlined-in-foo\.gif$</strong> - [F] +</pre></div> + </dd> + </dl> + + + + <h3>호스트 거부</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>어떻게 외부에서 서버에 접근할 수 없는 호스트 목록을 + 설정할 수 있나?</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>아파치 >= 1.3b6에서:</p> + +<div class="example"><pre> +RewriteEngine on +RewriteMap hosts-deny txt:/path/to/hosts.deny +RewriteCond ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR] +RewriteCond ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND +RewriteRule ^/.* - [F] +</pre></div> + + <p>아파치 <= 1.3b6에서:</p> + +<div class="example"><pre> +RewriteEngine on +RewriteMap hosts-deny txt:/path/to/hosts.deny +RewriteRule ^/(.*)$ ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND}/$1 +RewriteRule !^NOT-FOUND/.* - [F] +RewriteRule ^NOT-FOUND/(.*)$ ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND}/$1 +RewriteRule !^NOT-FOUND/.* - [F] +RewriteRule ^NOT-FOUND/(.*)$ /$1 +</pre></div> + +<div class="example"><pre> +## +## hosts.deny +## +## 주의! 이것은 목록처럼 보이지만 목록이 아니라 맵이다. +## mod_rewrite는 이 정보를 키/값 쌍으로 해석하기때문에, +## 각 항목의 값 자리에 최소한 "-"가 필요하다. +## + +193.102.180.41 - +bsdti1.sdm.de - +192.76.162.40 - +</pre></div> + </dd> + </dl> + + + + <h3>프록시 거부</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>어떻게 특정 호스트 혹은 특정 호스트의 사용자가 + 아파치 프록시를 사용할 수 없도록 하나?</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>먼저 아파치 웹서버를 컴파일할때 구성파일에서 + <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>가 <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code> + 아래에(!) 있어야 한다. 그러면 <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>는 + <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code> <em>이전에</em> 불린다. + 이제 다음과 같이 특정 호스트를 거부하도록 설정한다...</p> + +<div class="example"><pre> +RewriteCond %{REMOTE_HOST} <strong>^badhost\.mydomain\.com$</strong> +RewriteRule !^http://[^/.]\.mydomain.com.* - [F] +</pre></div> + + <p>...그리고 다음은 user@host에 따라 거부한다:</p> + +<div class="example"><pre> +RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>^badguy@badhost\.mydomain\.com$</strong> +RewriteRule !^http://[^/.]\.mydomain.com.* - [F] +</pre></div> + </dd> + </dl> + + + + <h3>특별한 인증 방식</h3> + + + + <dl> + <dt>상활설명:</dt> + + <dd> + <p>가끔 매우 특별한 인증이 필요할 때가 있다. 예를 + 들어, 미리 설정해둔 사용자인지 검사한다. 이들에게만 + (<code class="module"><a href="../mod/mod_auth_basic.html">mod_auth_basic</a></code>의 Basic Auth를 사용한 + 경우와 달리) 별다른 물음없이 접근을 허용한다.</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>친구만 접근이 가능하도록 재작성 규칙들을 사용한다:</p> + +<div class="example"><pre> +RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>!^friend1@client1.quux-corp\.com$</strong> +RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>!^friend2</strong>@client2.quux-corp\.com$ +RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>!^friend3</strong>@client3.quux-corp\.com$ +RewriteRule ^/~quux/only-for-friends/ - [F] +</pre></div> + </dd> + </dl> + + + + <h3>Referer기반 변환기(deflector)</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>"Referer" HTTP 헤더에 따라 원하는대로 참조페이지를 + 설정할 수 있는 유연한 URL 변환기를 만들 수 있는가?</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>다음과 같이 복잡한 규칙을...</p> + +<div class="example"><pre> +RewriteMap deflector txt:/path/to/deflector.map + +RewriteCond %{HTTP_REFERER} !="" +RewriteCond ${deflector:%{HTTP_REFERER}} ^-$ +RewriteRule ^.* %{HTTP_REFERER} [R,L] + +RewriteCond %{HTTP_REFERER} !="" +RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND +RewriteRule ^.* ${deflector:%{HTTP_REFERER}} [R,L] +</pre></div> + + <p>... 재작성 맵과 같이 사용한다:</p> + +<div class="example"><pre> +## +## deflector.map +## + +http://www.badguys.com/bad/index.html - +http://www.badguys.com/bad/index2.html - +http://www.badguys.com/bad/index3.html http://somewhere.com/ +</pre></div> + + <p>그러면 요청을 자동으로 (맵에서 값으로 "<code>-</code>"를 + 사용한 경우) 참조페이지나 (URL이 맵에 있는 경우 두번째 + 아규먼트로) 특정 URL로 리다이렉션한다.</p> + </dd> + </dl> + + + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="other" id="other">기타</a></h2> + + + + <h3>외부 재작성 엔진</h3> + + + + <dl> + <dt>상황설명:</dt> + + <dd> + <p>FAQ: 어떻게 이런저런 잡다한 문제를 풀 수 있는가? + <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>로는 해결책이 안보인다...</p> + </dd> + + <dt>해결책:</dt> + + <dd> + <p>외부 <code class="directive"><a href="../mod/mod_rewrite.html#rewritemap">RewriteMap</a></code>을 사용하라. + 즉, 프로그램이 <code class="directive"><a href="../mod/mod_rewrite.html#rewritemap">RewriteMap</a></code> 역할을 + 한다. 프로그램은 아파치가 시작할때 시작하여 + <code>STDIN</code>에서 요청한 URL을 받고, (같은 순서로!) + 결과 (보통 재작성된) URL을 <code>STDOUT</code>에 출력한다.</p> + +<div class="example"><pre> +RewriteEngine on +RewriteMap quux-map <strong>prg:</strong>/path/to/map.quux.pl +RewriteRule ^/~quux/(.*)$ /~quux/<strong>${quux-map:$1}</strong> +</pre></div> + +<div class="example"><pre> +#!/path/to/perl + +# 아파치 서버가 멈추지 않도록 +# 입출력 버퍼를 사용하지 않는다 +$| = 1; + +# stdin에서 한줄씩 URL을 읽고 +# stdout에 변환한 URL을 출력한다 +while (<>) { + s|^foo/|bar/|; + print $_; +} +</pre></div> + + <p>설명하기위해 모든 <code>/~quux/foo/...</code> URL을 + <code>/~quux/bar/...</code>로 재작성하는 스크립트를 + 예로 들었다. 실제로 마음대로 프로그래밍할 수 있다. + 그러나 일반 사용자가 이런 맵을 <strong>사용할</strong> + 수 있다고 하더라고, 오직 시스템 관리자만이 맵을 + <strong>정의해야</strong> 함을 주의하라.</p> + </dd> + </dl> + + + + </div></div> +<div class="bottomlang"> +<p><span>가능한 언어: </span><a href="../en/misc/rewriteguide.html" hreflang="en" rel="alternate" title="English"> en </a> | +<a href="../ko/misc/rewriteguide.html" title="Korean"> ko </a></p> +</div><div id="footer"> +<p class="apache">Copyright 1999-2004 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p> +<p class="menu"><a href="../mod/">모듈</a> | <a href="../mod/directives.html">지시어들</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">용어</a> | <a href="../sitemap.html">사이트맵</a></p></div> +</body></html>
\ No newline at end of file diff --git a/docs/manual/misc/rewriteguide.xml.ko b/docs/manual/misc/rewriteguide.xml.ko index b2a84babf9..a145f65641 100644 --- a/docs/manual/misc/rewriteguide.xml.ko +++ b/docs/manual/misc/rewriteguide.xml.ko @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="EUC-KR" ?> <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?> -<!-- English Revision: 1.11 --> +<!-- English Revision: 1.12 --> <!-- Copyright 2004 The Apache Software Foundation diff --git a/docs/manual/misc/rewriteguide.xml.meta b/docs/manual/misc/rewriteguide.xml.meta index e9a24ab9c8..fdc8e22705 100644 --- a/docs/manual/misc/rewriteguide.xml.meta +++ b/docs/manual/misc/rewriteguide.xml.meta @@ -7,5 +7,6 @@ <variants> <variant>en</variant> + <variant>ko</variant> </variants> </metafile> diff --git a/docs/manual/misc/security_tips.html b/docs/manual/misc/security_tips.html index 25587f30b8..3746e186a7 100644 --- a/docs/manual/misc/security_tips.html +++ b/docs/manual/misc/security_tips.html @@ -1,3 +1,7 @@ URI: security_tips.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: security_tips.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR diff --git a/docs/manual/misc/security_tips.html.en b/docs/manual/misc/security_tips.html.en index b943bc8afe..909fa511c4 100644 --- a/docs/manual/misc/security_tips.html.en +++ b/docs/manual/misc/security_tips.html.en @@ -18,7 +18,8 @@ <div id="path"> <a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.1</a> > <a href="./">Miscellaneous Documentation</a></div><div id="page-content"><div id="preamble"><h1>Security Tips</h1> <div class="toplang"> -<p><span>Available Languages: </span><a href="../en/misc/security_tips.html" title="English"> en </a></p> +<p><span>Available Languages: </span><a href="../en/misc/security_tips.html" title="English"> en </a> | +<a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p> </div> <p>Some hints and tips on security issues in setting up a web server. @@ -341,7 +342,8 @@ </div></div> <div class="bottomlang"> -<p><span>Available Languages: </span><a href="../en/misc/security_tips.html" title="English"> en </a></p> +<p><span>Available Languages: </span><a href="../en/misc/security_tips.html" title="English"> en </a> | +<a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean"> ko </a></p> </div><div id="footer"> <p class="apache">Copyright 1999-2004 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p> <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div> diff --git a/docs/manual/misc/security_tips.html.ko.euc-kr b/docs/manual/misc/security_tips.html.ko.euc-kr new file mode 100644 index 0000000000..6f894188b1 --- /dev/null +++ b/docs/manual/misc/security_tips.html.ko.euc-kr @@ -0,0 +1,341 @@ +<?xml version="1.0" encoding="EUC-KR"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml" lang="ko" xml:lang="ko"><head><!-- + XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX + This file is generated from xml source: DO NOT EDIT + XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX + --> +<title>보안 팁 - Apache HTTP Server</title> +<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" /> +<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" /> +<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /> +<link href="../images/favicon.ico" rel="shortcut icon" /></head> +<body id="manual-page"><div id="page-header"> +<p class="menu"><a href="../mod/">모듈</a> | <a href="../mod/directives.html">지시어들</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">용어</a> | <a href="../sitemap.html">사이트맵</a></p> +<p class="apache">Apache HTTP Server Version 2.1</p> +<img alt="" src="../images/feather.gif" /></div> +<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div> +<div id="path"> +<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.1</a> > <a href="./">Miscellaneous Documentation</a></div><div id="page-content"><div id="preamble"><h1>보안 팁</h1> +<div class="toplang"> +<p><span>가능한 언어: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English"> en </a> | +<a href="../ko/misc/security_tips.html" title="Korean"> ko </a></p> +</div> + + <p>웹서버를 운영할때 도움이 될 보안 관련 힌트와 팁이다. + 어떤 것은 일반적이고, 어떤 것은 아파치에만 해당하는 것이다.</p> + </div> +<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#uptodate">최신판으로 유지하기</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#serverroot">ServerRoot 디렉토리 권한</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#ssi">Server Side Includes</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#cgi">일반적인 CGI</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#nsaliasedcgi">ScriptAlias하지 않은 CGI</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#saliasedcgi">ScriptAlias한 CGI</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#dynamic">동적 내용을 생성하는 다른 방법</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#systemsettings">시스템 설정 보호하기</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#protectserverfiles">기본적으로 서버에 있는 파일 보호하기</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#watchyourlogs">로그 살펴보기</a></li> +</ul></div> +<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="uptodate" id="uptodate">최신판으로 유지하기</a></h2> + + <p>아파치 웹서버는 안전과 보안 문제에 관심이 많은 개발자 + 공동체로 유명하다. 그러나 크건 작건 발표후 발견되는 문제들을 + 피할 수 없다. 그래서 소프트웨어를 최신버전으로 유지하는 + 것이 중요하다. 아파치에서 직접 웹서버를 다운로드했다면, + 새로운 버전과 보안 업데이트를 알려주는 <a href="http://httpd.apache.org/lists.html#http-announce">아파치 + 웹서버 발표 메일링리스트</a>를 구독하길 강력히 권한다. + 아파치 소프트웨어를 배포하는 많은 제삼자들도 비슷한 서비스를 + 제공한다.</p> + + <p>물론 웹서버 코드때문에 웹서버가 공격을 당하는 경우는 + 많지 않다. 그보다 추가 코드, CGI 스크립트, 하위 운영체제의 + 문제로 공격을 당하는 경우가 많다. 그러므로 항상 주의하며 + 시스템의 모든 소프트웨어를 업데이트해야 한다.</p> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="serverroot" id="serverroot">ServerRoot 디렉토리 권한</a></h2> + + + + <p>보통 root 사용자가 아파치를 시작한 후, 요청을 서비스하기위해 + <code class="directive"><a href="../mod/mpm_common.html#user">User</a></code> 지시어로 + 지정한 사용자로 변환한다. root가 실행하는 명령어가 있다면, + root 이외의 사용자가 수정하지 못하도록 주의해야 한다. 이 + 파일들을 root만 쓸 수 있어야 하고, 디렉토리와 모든 상위디렉토리도 + 마찬가지다. 예를 들어, ServerRoot로 /usr/local/apache를 + 사용한다면 root 사용자가 다음과 같이 디렉토리를 만들길 + 제안한다:</p> + + <div class="example"><p><code> + mkdir /usr/local/apache <br /> + cd /usr/local/apache <br /> + mkdir bin conf logs <br /> + chown 0 . bin conf logs <br /> + chgrp 0 . bin conf logs <br /> + chmod 755 . bin conf logs + </code></p></div> + + <p>그러면 /, /usr, /usr/local 은 root만이 수정할 수 있다. + httpd 실행파일을 설치할때 다음과 같이 보호해야 한다:</p> + + <div class="example"><p><code> + cp httpd /usr/local/apache/bin <br /> + chown 0 /usr/local/apache/bin/httpd <br /> + chgrp 0 /usr/local/apache/bin/httpd <br /> + chmod 511 /usr/local/apache/bin/httpd + </code></p></div> + + <p>htdocs 하위디렉토리는 다른 사용자들이 수정할 수 있도록 + 만들 수 있다 -- root는 그곳에 있는 파일을 실행하지도, 만들지도 + 않아야 한다.</p> + + <p>root가 아닌 사용자가 root가 실행하거나 쓰기가능한 파일을 + 수정할 수 있다면 시스템의 root 권한을 훔칠 수 있다. 예를 + 들어, 누군가 httpd 실행파일을 변경하였다면 다음번 시작할때 + 임의의 코드를 실행하게 된다. logs 디렉토리가 (root가 아닌 + 사용자에게) 쓰기가능하다면 누군가 로그파일을 다른 시스템파일로 + 심볼링크를 걸어서 root가 파일에 임의의 자료를 덮어쓸 수 + 있다. 로그파일이 (root가 아닌 사용자에게) 쓰기가능하다면 + 누군가 로그에 이상한 자료를 기록할 수 있다.</p> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="ssi" id="ssi">Server Side Includes</a></h2> + + + + <p>Server Side Includes (SSI)는 서버 관리자에게 보안상 몇가지 + 잠재적인 위험이다.</p> + + <p>첫번째 위험은 서버의 부하를 늘리는 점이다. 아파치는 파일에 + SSI 지시어가 있는지 여부와 관계없이 모든 SSI 파일을 분석해야 + 한다. 조금 부하가 늘지만, 서버를 여러 사람이 같이 사용하는 + 환경에서는 심각할 수 있다.</p> + + <p>또, SSI 파일은 일반적인 CGI 스크립트와 동일한 위험을 + 가진다. SSI 파일에서 "exec cmd"를 사용하면 httpd.conf에서 + 아파치를 실행하도록 설정한 사용자와 그룹 권한으로 CGI + 스크립트나 프로그램을 실행할 수 있다.</p> + + <p>장점을 활용하면서 SSI 파일의 보안을 향상시키는 방법이 + 있다.</p> + + <p>SSI 파일이 가져올 수 있는 피해를 격리하기위해 서버관리자는 + <a href="#cgi">일반적인 CGI</a> 절에서 설명하는 방법으로 + <a href="../suexec.html">suexec</a>를 사용할 수 있다</p> + + <p>.html이나 .htm 확장자를 SSI 파일로 사용하는 것은 위험하다. + 특히 여러 사람이 공유하거나 통신량이 많은 서버 환경에서 + 위험하다. SSI 파일은 일반적으로 많이 사용하는 .shtml 같은 + 별도의 확장자를 가져야 한다. 그러면 서버 부하를 최소화하고 + 위험요소를 쉽게 관리할 수 있다.</p> + + <p>다른 방법은 SSI 페이지가 스크립트나 프로그램을 실행하지 + 못하도록 만드는 것이다. <code class="directive"><a href="../mod/core.html#options">Options</a></code> 지시어에서 <code>Includes</code> + 대신 <code>IncludesNOEXEC</code>를 사용한다. 그래도 스크립트가 + <code class="directive"><a href="../mod/mod_alias.html#scriptalias">ScriptAlias</a></code> 지시어로 + 지정한 디렉토리에 있다면 <--#include virtual="..." -->를 + 사용하여 CGI 스크립트를 실행할 수 있음을 주의하라.</p> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="cgi" id="cgi">일반적인 CGI</a></h2> + + + + <p>결국 당신은 항상 CGI 스크립트/프로그램의 저자를 신뢰해야 + 하고, 고의건 실수이건 CGI의 잠재적인 보안상 허점을 발견할 + 수 있어야 한다. 기본적으로 CGI 스크립트는 웹서버 사용자 + 권한으로 시스템에서 어떤 명령어라도 실행할 수 있기때문에 + 주의있게 확인하지 않으면 매우 위험하다.</p> + + <p>모든 CGI 스크립트가 같은 사용자로 실행되기때문에 다른 + 스크립트와 (고의건 실수이건) 충돌할 가능성이 있다. 예를 + 들어, 사용자 A는 사용자 B를 매우 싫어하여, 사용자 B의 CGI + 데이터베이스를 지워버리는 스크립트를 작성할 수 있다. 아파치 + 1.2 버전부터 포함되었고 아파치 서버에서 특별한 훅(hook)으로 + 동작하는 <a href="../suexec.html">suEXEC</a>는 스크립트를 + 다른 사용자로 실행하는 방법중 하나다. 다른 대중적인 방법에는 + <a href="http://cgiwrap.unixtools.org/">CGIWrap</a>이 있다.</p> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="nsaliasedcgi" id="nsaliasedcgi">ScriptAlias하지 않은 CGI</a></h2> + + + + <p>다음 조건을 만족할때만 사용자가 어떤 디렉토리에서라도 + CGI 스크립트를 실행하도록 허용할 수 있다:</p> + + <ul> + <li>당신은 고의건 실수이건 사용자가 시스템을 공격에 노출시키는 + 스크립트를 작성하지 않는다고 믿는다.</li> + <li>시스템의 다른 부분의 보안이 약해서, 잠재적인 허점을 + 하나 더 만들어도 나빠질 것이 없다고 생각하는 경우.</li> + <li>사용자가 없고, 아마 아무도 서버를 방문하지않는 경우.</li> + </ul> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="saliasedcgi" id="saliasedcgi">ScriptAlias한 CGI</a></h2> + + + + <p>특정 디렉토리에서만 CGI를 실행할 수 있도록 제한하면 관리자는 + 이들 디렉토리를 통제할 수 있다. 이 경우는 scriptalias하지 + 않은 CGI보다 확실히 안전하다. 단, 신뢰하는 사용자만 디렉토리에 + 접근할 수 있고, 관리자가 새로운 CGI 스크립트/프로그램의 + 잠재적인 보안상 허점을 검사할 용이가 있다면.</p> + + <p>대부분의 사이트는 scriptalias하지 않은 CGI 방식 대신 + 이 방식을 사용한다.</p> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="dynamic" id="dynamic">동적 내용을 생성하는 다른 방법</a></h2> + + + + <p> + mod_php, mod_perl, mod_tcl, mod_python 같이 서버의 일부로 + 동작하는 임베디드 스크립트는 서버와 같은 사용자로 (<code class="directive"><a href="../mod/mpm_common.html#user">User</a></code> 지시어 참고) 실행되기때문에, + 스크립트 엔진이 실행하는 스크립트는 잠재적으로 서버 사용자가 + 접근할 수 있는 모든 것에 접근할 수 있다. 어떤 스크립트 엔진은 + 어느정도 제한을 하지만, 안전하다고 가정하지 않는 것이 좋다.</p> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="systemsettings" id="systemsettings">시스템 설정 보호하기</a></h2> + + + + <p>정말로 안전한 서버를 운영하려면 사용자가 + <code>.htaccess</code> 파일을 사용하여 당신이 설정한 보안기능을 + 변경하길 바라지 않을 것이다. 그러기위해 다음과 같은 방법이 + 있다.</p> + + <p>서버 설정파일에 다음을 추가한다</p> + + <div class="example"><p><code> + <Directory /> <br /> + AllowOverride None <br /> + </Directory> + </code></p></div> + + <p>그러면 사용가능하도록 명시적으로 허용한 디렉토리를 제외하고는 + <code>.htaccess</code> 파일을 사용할 수 없다.</p> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="protectserverfiles" id="protectserverfiles">기본적으로 서버에 있는 파일 보호하기</a></h2> + + + + <p>사람들은 종종 아파치의 기본 접근에 대해 잘못 알고있다. + 즉, 서버가 일반적인 URL 대응 규칙을 사용하여 파일을 찾을 + 수 있다면, 특별히 조치를 하지 않는한 클라이언트에게 파일이 + 서비스될 수 있다.</p> + + <p>예를 들어, 아래와 같은 경우:</p> + + <div class="example"><p><code> + # cd /; ln -s / public_html <br /> + <code>http://localhost/~root/</code> 에 접근한다 + </code></p></div> + + <p>그러면 클라이언트는 전체 파일시스템을 돌아다닐 수 있다. + 이를 막기위해 서버설정에서 다음과 같은 조치를 한다:</p> + + <div class="example"><p><code> + <Directory /> <br /> + Order Deny,Allow <br /> + Deny from all <br /> + </Directory> + </code></p></div> + + <p>그러면 파일시스템 위치에 대해 기본 접근이 거부된다. + 원하는 영역에 접근할 수 있도록 다음과 같은 <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> 블록을 추가한다.</p> + + <div class="example"><p><code> + <Directory /usr/users/*/public_html> <br /> + Order Deny,Allow <br /> + Allow from all <br /> + </Directory> <br /> + <Directory /usr/local/httpd> <br /> + Order Deny,Allow <br /> + Allow from all <br /> + </Directory> + </code></p></div> + + <p><code class="directive"><a href="../mod/core.html#location">Location</a></code>과 <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> 지시어를 같이 사용하는 + 경우 특별히 주의를 기울여라. 예를 들어, <code><Directory + /></code>가 접근을 거부하더라도 <code><Location + /></code> 지시어가 이를 무시할 수 있다</p> + + <p><code class="directive"><a href="../mod/mod_userdir.html#userdir">UserDir</a></code> 지시어를 + 사용하는 경우에도 주의하라. 지시어를 "./" 같이 설정하면 + root 사용자에 대해 바로 위의 경우와 같은 문제가 발생한다. + 아파치 1.3 이상을 사용한다면 서버 설정파일에 아래 줄을 추가하길 + 강력히 권한다:</p> + + <div class="example"><p><code> + UserDir disabled root + </code></p></div> + + </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> +<div class="section"> +<h2><a name="watchyourlogs" id="watchyourlogs">로그 살펴보기</a></h2> + + + + <p>실제로 서버에서 무슨 일이 있어나고 있는지 알려면 <a href="../logs.html">로그파일</a>을 살펴봐야 한다. 로그파일은 + 이미 일어난 일만을 보고하지만, 서버에 어떤 공격이 있었는지 + 알려주고 현재 필요한 만큼 안전한지 확인하게 해준다.</p> + + <p>여러가지 예:</p> + + <div class="example"><p><code> + grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log <br /> + grep "client denied" error_log | tail -n 10 + </code></p></div> + + <p>첫번째 예는 <a href="http://online.securityfocus.com/bid/4876/info/">잘못된 + Source.JSP 요청으로 서버정보를 알아낼 수 있는 Tomcat의 + 취약점</a>를 이용하려는 공격 횟수를 알려주고, 두번째 예는 + 접근이 거부된 최근 클라이언트 10개를 다음과 같이 보여준다:</p> + + <div class="example"><p><code> + [Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied + by server configuration: /usr/local/apache/htdocs/.htpasswd + </code></p></div> + + <p>잘 알 듯이 로그파일은 이미 발생한 사건만을 보고한다. + 그래서 클라이언트가 <code>.htpasswd</code> 파일에 접근할 + 수 있었다면 <a href="../logs.html#accesslog">접근 로그</a>에 + 다음과 같은 기록이 남을 것이다:</p> + + <div class="example"><p><code> + foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1" + </code></p></div> + + <p>즉, 당신은 서버 설정파일에서 다음 부분을 주석처리했을 + 것이다:</p> + + <div class="example"><p><code> + <Files ~ "^\.ht"> <br /> + Order allow,deny <br /> + Deny from all <br /> + <Files> + </code></p></div> + + </div></div> +<div class="bottomlang"> +<p><span>가능한 언어: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English"> en </a> | +<a href="../ko/misc/security_tips.html" title="Korean"> ko </a></p> +</div><div id="footer"> +<p class="apache">Copyright 1999-2004 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p> +<p class="menu"><a href="../mod/">모듈</a> | <a href="../mod/directives.html">지시어들</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">용어</a> | <a href="../sitemap.html">사이트맵</a></p></div> +</body></html>
\ No newline at end of file diff --git a/docs/manual/misc/security_tips.xml.ko b/docs/manual/misc/security_tips.xml.ko index 53c9a3a9cd..9d312b5ec1 100644 --- a/docs/manual/misc/security_tips.xml.ko +++ b/docs/manual/misc/security_tips.xml.ko @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="EUC-KR" ?> <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?> -<!-- English Revision: 1.11 --> +<!-- English Revision: 1.12 --> <!-- Copyright 2003-2004 The Apache Software Foundation diff --git a/docs/manual/misc/security_tips.xml.meta b/docs/manual/misc/security_tips.xml.meta index 8e9ea9600b..e1184d8431 100644 --- a/docs/manual/misc/security_tips.xml.meta +++ b/docs/manual/misc/security_tips.xml.meta @@ -7,5 +7,6 @@ <variants> <variant>en</variant> + <variant>ko</variant> </variants> </metafile> |