From cc40af334e619bb549038238507407866f774f8f Mon Sep 17 00:00:00 2001 From: hongbotian Date: Mon, 30 Nov 2015 01:35:09 -0500 Subject: upload apache JIRA: BOTTLENECK-10 Change-Id: I67eae31de6dc824097dfa56ab454ba36fdd23a2c Signed-off-by: hongbotian --- .../app/apache2/manual/misc/custom_errordocs.html | 5 + .../apache2/manual/misc/custom_errordocs.html.en | 577 ++++++ rubbos/app/apache2/manual/misc/descriptors.html | 5 + rubbos/app/apache2/manual/misc/descriptors.html.en | 233 +++ rubbos/app/apache2/manual/misc/fin_wait_2.html | 5 + rubbos/app/apache2/manual/misc/fin_wait_2.html.en | 422 ++++ rubbos/app/apache2/manual/misc/index.html | 9 + rubbos/app/apache2/manual/misc/index.html.en | 121 ++ rubbos/app/apache2/manual/misc/index.html.tr.utf8 | 122 ++ .../apache2/manual/misc/known_client_problems.html | 5 + .../manual/misc/known_client_problems.html.en | 408 ++++ rubbos/app/apache2/manual/misc/perf-tuning.html | 13 + rubbos/app/apache2/manual/misc/perf-tuning.html.en | 1058 ++++++++++ .../apache2/manual/misc/perf-tuning.html.ko.euc-kr | 978 +++++++++ .../apache2/manual/misc/perf-tuning.html.tr.utf8 | 1100 ++++++++++ .../apache2/manual/misc/relevant_standards.html | 9 + .../apache2/manual/misc/relevant_standards.html.en | 199 ++ .../manual/misc/relevant_standards.html.ko.euc-kr | 191 ++ rubbos/app/apache2/manual/misc/rewriteguide.html | 9 + .../app/apache2/manual/misc/rewriteguide.html.en | 2110 ++++++++++++++++++++ .../manual/misc/rewriteguide.html.ko.euc-kr | 2013 +++++++++++++++++++ rubbos/app/apache2/manual/misc/security_tips.html | 13 + .../app/apache2/manual/misc/security_tips.html.en | 354 ++++ .../manual/misc/security_tips.html.ko.euc-kr | 345 ++++ .../apache2/manual/misc/security_tips.html.tr.utf8 | 344 ++++ rubbos/app/apache2/manual/misc/tutorials.html | 5 + rubbos/app/apache2/manual/misc/tutorials.html.en | 211 ++ 27 files changed, 10864 insertions(+) create mode 100644 rubbos/app/apache2/manual/misc/custom_errordocs.html create mode 100644 rubbos/app/apache2/manual/misc/custom_errordocs.html.en create mode 100644 rubbos/app/apache2/manual/misc/descriptors.html create mode 100644 rubbos/app/apache2/manual/misc/descriptors.html.en create mode 100644 rubbos/app/apache2/manual/misc/fin_wait_2.html create mode 100644 rubbos/app/apache2/manual/misc/fin_wait_2.html.en create mode 100644 rubbos/app/apache2/manual/misc/index.html create mode 100644 rubbos/app/apache2/manual/misc/index.html.en create mode 100644 rubbos/app/apache2/manual/misc/index.html.tr.utf8 create mode 100644 rubbos/app/apache2/manual/misc/known_client_problems.html create mode 100644 rubbos/app/apache2/manual/misc/known_client_problems.html.en create mode 100644 rubbos/app/apache2/manual/misc/perf-tuning.html create mode 100644 rubbos/app/apache2/manual/misc/perf-tuning.html.en create mode 100644 rubbos/app/apache2/manual/misc/perf-tuning.html.ko.euc-kr create mode 100644 rubbos/app/apache2/manual/misc/perf-tuning.html.tr.utf8 create mode 100644 rubbos/app/apache2/manual/misc/relevant_standards.html create mode 100644 rubbos/app/apache2/manual/misc/relevant_standards.html.en create mode 100644 rubbos/app/apache2/manual/misc/relevant_standards.html.ko.euc-kr create mode 100644 rubbos/app/apache2/manual/misc/rewriteguide.html create mode 100644 rubbos/app/apache2/manual/misc/rewriteguide.html.en create mode 100644 rubbos/app/apache2/manual/misc/rewriteguide.html.ko.euc-kr create mode 100644 rubbos/app/apache2/manual/misc/security_tips.html create mode 100644 rubbos/app/apache2/manual/misc/security_tips.html.en create mode 100644 rubbos/app/apache2/manual/misc/security_tips.html.ko.euc-kr create mode 100644 rubbos/app/apache2/manual/misc/security_tips.html.tr.utf8 create mode 100644 rubbos/app/apache2/manual/misc/tutorials.html create mode 100644 rubbos/app/apache2/manual/misc/tutorials.html.en (limited to 'rubbos/app/apache2/manual/misc') diff --git a/rubbos/app/apache2/manual/misc/custom_errordocs.html b/rubbos/app/apache2/manual/misc/custom_errordocs.html new file mode 100644 index 00000000..23ab34ae --- /dev/null +++ b/rubbos/app/apache2/manual/misc/custom_errordocs.html @@ -0,0 +1,5 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: custom_errordocs.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 diff --git a/rubbos/app/apache2/manual/misc/custom_errordocs.html.en b/rubbos/app/apache2/manual/misc/custom_errordocs.html.en new file mode 100644 index 00000000..fc2ccd8e --- /dev/null +++ b/rubbos/app/apache2/manual/misc/custom_errordocs.html.en @@ -0,0 +1,577 @@ + + + +International Customized Server Error Messages - Apache HTTP Server + + + + + +
<-
+

International Customized Server Error Messages

+
+

Available Languages:  en 

+
+ + +

Warning:

+

This document has not been fully updated + to take into account changes made in the 2.0 version of the + Apache HTTP Server. Some of the information may still be + relevant, but please use it with care.

+
+ +

This document describes an easy way to provide your Apache + HTTP Server with a set of customized error messages which take + advantage of Content + Negotiation and mod_include to return + error messages generated by the server in the client's native + language.

+ +
+ +
top
+
+

Introduction

+ + + +

By using SSI, all ErrorDocument messages + can share a homogenous and consistent style and layout, and + maintenance work (changing images, changing links) is kept to a + minimum because all layout information can be kept in a single + file.

+ +

Error documents can be shared across different servers, or + even hosts, because all varying information is inserted at the + time the error document is returned on behalf of a failed + request.

+ +

Content Negotiation then selects the appropriate language + version of a particular error message text, honoring the + language preferences passed in the client's request. (Users + usually select their favorite languages in the preferences + options menu of today's browsers). When an error document in + the client's primary language version is unavailable, the + secondary languages are tried or a default (fallback) version + is used.

+ +

You have full flexibility in designing your error documents + to your personal taste (or your company's conventions). For + demonstration purposes, we present a simple generic error + document scheme. For this hypothetic server, we assume that all + error messages...

+ +
    +
  • possibly are served by different virtual hosts (different + host name, different IP address, or different port) on the + server machine,
  • + +
  • show a predefined company logo in the right top of the + message (selectable by virtual host),
  • + +
  • print the error title first, followed by an explanatory + text and (depending on the error context) help on how to + resolve the error,
  • + +
  • have some kind of standardized background image,
  • + +
  • display an apache logo and a feedback email address at + the bottom of the error message.
  • +
+ +

An example of a "document not found" message for a german + client might look like this:

+ +

[Needs graphics capability to display]

+ +

All links in the document as well as links to the server's + administrator mail address, and even the name and port of the + serving virtual host are inserted in the error document at + "run-time", i.e., when the error actually occurs.

+
top
+
+

Creating an ErrorDocument directory

+ + + +

For this concept to work as easily as possible, we must take + advantage of as much server support as we can get:

+ +
    +
  1. By defining the MultiViews Options, we + enable the language selection of the most appropriate + language alternative (content negotiation).
  2. + +
  3. By setting the LanguagePriority + directive we define a set of default fallback languages in + the situation where the client's browser did not express any + preference at all.
  4. + +
  5. By enabling mod_include + (and disallowing execution of cgi scripts for + security reasons), we allow the server to include building + blocks of the error message, and to substitute the value of + certain environment variables into the generated document + (dynamic HTML) or even to conditionally include or omit parts + of the text.
  6. + +
  7. The AddHandler and AddType directives + are useful for automatically SSI-expanding all files with a + .shtml suffix to text/html.
  8. + +
  9. By using the Alias directive, we + keep the error document directory outside of the document + tree because it can be regarded more as a server part than + part of the document tree.
  10. + +
  11. The <Directory> block + restricts these "special" settings to the error document + directory and avoids an impact on any of the settings for the + regular document tree.
  12. + +
  13. For each of the error codes to be handled (see RFC2068 + for an exact description of each error code, or look at + src/main/http_protocol.c if you wish to see + apache's standard messages), an ErrorDocument in + the aliased /errordocs directory is defined. + Note that we only define the basename of the document here + because the MultiViews option will select the best candidate + based on the language suffixes and the client's preferences. + Any error situation with an error code not handled + by a custom document will be dealt with by the server in the + standard way (i.e., a plain error message in + english).
  14. + +
  15. Finally, the AllowOverride directive tells + apache that it is not necessary to look for a .htaccess file + in the /errordocs directory: a minor speed optimization.
  16. +
+ +

The resulting httpd.conf configuration would then + look similar to this:

+ +

Note

Note that you can define your own + error messages using this method for only part of the document + tree, e.g., a /~user/ subtree. In this case, the configuration + could as well be put into the .htaccess file at the root of the + subtree, and the <Directory> and </Directory> + directives -but not the contained directives- must be + omitted.
+ +

+ LanguagePriority en fr de
+ Alias /errordocs /usr/local/apache/errordocs
+
+ <Directory /usr/local/apache/errordocs>
+ + AllowOverride none
+ Options MultiViews IncludesNoExec FollowSymLinks
+ AddType text/html .shtml
+ <FilesMatch "\.shtml[.$]">
+ + SetOutputFilter INCLUDES
+
+ </FilesMatch>
+
+ </Directory>
+
+ # "400 Bad Request",
+ ErrorDocument 400 /errordocs/400
+ # "401 Authorization Required",
+ ErrorDocument 401 /errordocs/401
+ # "403 Forbidden",
+ ErrorDocument 403 /errordocs/403
+ # "404 Not Found",
+ ErrorDocument 404 /errordocs/404
+ # "500 Internal Server Error",
+ ErrorDocument 500 /errordocs/500
+

+ +

The directory for the error messages (here: + /usr/local/apache/errordocs/) must then be created + with the appropriate permissions (readable and executable by + the server uid or gid, only writable for the administrator).

+ +

Naming the Individual Error Document files

+ + + +

By defining the MultiViews option, the server was + told to automatically scan the directory for matching variants + (looking at language and content type suffixes) when a + requested document was not found. In the configuration, we + defined the names for the error documents to be just their + error number (without any suffix).

+ +

The names of the individual error documents are now + determined like this (I'm using 403 as an example, think of it + as a placeholder for any of the configured error + documents):

+ +
    +
  • No file errordocs/403 should exist. Otherwise, it would + be found and served (with the DefaultType, usually + text/plain), all negotiation would be bypassed.
  • + +
  • For each language for which we have an internationalized + version (note that this need not be the same set of languages + for each error code - you can get by with a single language + version until you actually have translated + versions), a document + errordocs/403.shtml.lang is created and + filled with the error text in that language (see below).
  • + +
  • One fallback document called + errordocs/403.shtml is created, usually by + creating a symlink to the default language variant (see below).
  • +
+ + +

The Common Header and Footer Files

+ + + +

By putting as much layout information in two special "include + files", the error documents can be reduced to a bare minimum.

+ +

One of these layout files defines the HTML document header + and a configurable list of paths to the icons to be shown in + the resulting error document. These paths are exported as a set + of SSI environment variables and are later evaluated by the + "footer" special file. The title of the current error (which is + put into the TITLE tag and an H1 header) is simply passed in + from the main error document in a variable called + title.

+ +

By changing this file, the layout of all generated + error messages can be changed in a second. (By + exploiting the features of SSI, you can easily define + different layouts based on the current virtual host, or even + based on the client's domain name).

+ +

The second layout file describes the footer to be displayed + at the bottom of every error message. In this example, it shows + an apache logo, the current server time, the server version + string and adds a mail reference to the site's webmaster.

+ +

For simplicity, the header file is simply called + head.shtml because it contains server-parsed + content but no language specific information. The footer file + exists once for each language translation, plus a symlink for + the default language.

+ +

+for English, French and German versions (default english)
+
+foot.shtml.en,
+foot.shtml.fr,
+foot.shtml.de,
+foot.shtml symlink to
+foot.shtml.en +

+ +

Both files are included into the error document by using the + directives <!--#include virtual="head" --> + and <!--#include virtual="foot" --> + respectively: the rest of the magic occurs in mod_negotiation + and in mod_include.

+ +

See the listings below to see an + actual HTML implementation of the discussed example.

+ + +

Creating ErrorDocuments in Different Languages

+ + + +

After all this preparation work, little remains to be said + about the actual documents. They all share a simple common + structure:

+ +

+<!--#set var="title" value="error description title" -->
+<!--#include virtual="head" -->
+ + explanatory error text
+
+<!--#include virtual="foot" --> +

+ +

In the listings section, you can see an + example of a [400 Bad Request] error document. Documents as + simple as that certainly cause no problems to translate or + expand.

+ + +

The Fallback Language

+ + + +

Do we need a special handling for languages other than those we + have translations for? We did set the LanguagePriority, didn't + we?!

+ +

Well, the LanguagePriority directive is for the case where + the client does not express any language priority at all. But + what happens in the situation where the client wants one of the + languages we do not have, and none of those we do have?

+ +

Without doing anything, the Apache server will usually + return a [406 no acceptable variant] error, listing the choices + from which the client may select. But we're in an error message + already, and important error information might get lost when + the client had to choose a language representation first.

+ +

So, in this situation it appears to be easier to define a + fallback language (by copying or linking, e.g., the + english version to a language-less version). Because the + negotiation algorithm prefers "more specialized" variants over + "more generic" variants, these generic alternatives will only + be chosen when the normal negotiation did not succeed.

+ +

A simple shell script to do it (execute within the + errordocs/ dir):

+ +

+ for f in *.shtml.en
+ do
+ + ln -s $f `basename $f .en`
+
+ done +

+ + +
top
+
+

Customizing Proxy Error Messages

+ + + +

As of Apache-1.3, it is possible to use the + ErrorDocument mechanism for proxy error messages + as well (previous versions always returned fixed predefined + error messages).

+ +

Most proxy errors return an error code of [500 Internal + Server Error]. To find out whether a particular error document + was invoked on behalf of a proxy error or because of some other + server error, and what the reason for the failure was, you can + check the contents of the new ERROR_NOTES CGI + environment variable: if invoked for a proxy error, this + variable will contain the actual proxy error message text in + HTML form.

+ +

The following excerpt demonstrates how to exploit the + ERROR_NOTES variable within an error document:

+ +

+ <!--#if expr="$REDIRECT_ERROR_NOTES = ''" -->
+
+ <p>
+ + The server encountered an unexpected condition
+ which prevented it from fulfilling the request.
+
+ </p>
+
+ <p>
+ + <a href="mailto:<!--#echo var="SERVER_ADMIN" -->"
+ SUBJECT="Error message [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" --> for <!--#echo var="REQUEST_URI" -->">
+ Please forward this error screen to <!--#echo var="SERVER_NAME" -->'s
+ WebMaster</a>; it includes useful debugging information about
+ the Request which caused the error.
+
+ <pre><!--#printenv --></pre>
+
+ </p>
+
+ <!--#else -->
+ + <!--#echo var="REDIRECT_ERROR_NOTES" -->
+
+
+ <!--#endif --> +

+ +
top
+
+

HTML Listing of the Discussed Example

+ + + +

So, to summarize our example, here's the complete listing of + the 400.shtml.en document. You will notice that it + contains almost nothing but the error text (with conditional + additions). Starting with this example, you will find it easy + to add more error documents, or to translate the error + documents to different languages.

+ +

+<!--#set var="title" value="Bad Request"-->
+<!--#include virtual="head" -->
+
+ <p>
+ + Your browser sent a request that this server could not understand:
+ <blockquote>
+ + <strong><!--#echo var="REQUEST_URI" --></strong>
+
+ </blockquote>
+
+ The request could not be understood by the server due to malformed
+ syntax. The client should not repeat the request without
+ modifications.
+
+ </p>
+
+ <p>
+ + <!--#if expr="$HTTP_REFERER != ''" -->
+ + Please inform the owner of
+ <a href="<!--#echo var="HTTP_REFERER" -->">the referring page</a> about
+ the malformed link.
+
+
+ <!--#else -->
+ + Please check your request for typing errors and retry.
+
+
+ <!--#endif -->
+
+ </p>
+
+<!--#include virtual="foot" --> +

+ +

Here is the complete head.shtml.en file (the funny + line breaks avoid empty lines in the document after SSI + processing). Note the configuration section at top. That's + where you configure the images and logos as well as the apache + documentation directory. Look how this file displays two + different logos depending on the content of the virtual host + name ($SERVER_NAME), and that an animated apache logo is shown + if the browser appears to support it (the latter requires + server configuration lines of the form

+ +

BrowserMatch "^Mozilla/[2-4]" anigif

+ +

for browser types which support animated GIFs).

+ +

+<!--#if expr="$SERVER_NAME = /.*\.mycompany\.com/" -->
+ +<!--#set var="IMG_CorpLogo" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/CorpLogo.gif" -->
+<!--#set var="ALT_CorpLogo" value="Powered by Linux!" -->
+
+
+<!--#else -->
+ +<!--#set var="IMG_CorpLogo" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/PrivLogo.gif" -->
+<!--#set var="ALT_CorpLogo" value="Powered by Linux!" -->
+
+<!--#endif-->
+
+<!--#set var="IMG_BgImage" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/BgImage.gif" -->
+<!--#set var="DOC_Apache" value="http://$SERVER_NAME:$SERVER_PORT/Apache/" -->
+
+<!--#if expr="$anigif" -->
+ +<!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_anim.gif" -->
+
+<!--#else-->
+ +<!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_pb.gif" -->
+
+<!--#endif-->
+
+ +<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+<head>
+ + <title>
+ [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" -->
+ </title>
+
+</head>
+
+<body bgcolor="white" background="<!--#echo var="IMG_BgImage" -->">
+ + <h1 align="center">
+ [<!--#echo var="REDIRECT_STATUS" -->] + <!--#echo var="title" -->
+ <img src="<!--#echo var="IMG_CorpLogo" -->"
+   alt="<!--#echo var="ALT_CorpLogo" -->" align="right">
+ </h1>
+
+ <hr /> + <!-- ======================================================== -->
+ <div> +
+

+ +

and this is the foot.shtml.en file:

+ +

+ + </div>
+ <hr />
+
+ <div align="right">
+ + <small>Local Server time: + <!--#echo var="DATE_LOCAL" --></small>
+
+ </div>
+
+ <div align="center">
+ + <a href="<!--#echo var="DOC_Apache" -->">
+ <img src="<!--#echo var="IMG_Apache" -->" border="0" align="bottom"
+   alt="Powered by <!--#echo var="SERVER_SOFTWARE" -->"></a>
+ <br />
+ + <small><!--#set var="var" value="Powered by $SERVER_SOFTWARE --
+ File last modified on $LAST_MODIFIED" -->
+ <!--#echo var="var" --></small>
+
+ </div>
+
+ <p>If the indicated error looks like a misconfiguration, please inform
+ <a href="mailto:<!--#echo var="SERVER_ADMIN" -->"
+ subject="Feedback about Error message [<!--#echo var="REDIRECT_STATUS" -->]
+ <!--#echo var="title" -->, req=<!--#echo var="REQUEST_URI" -->">
+ <!--#echo var="SERVER_NAME" -->'s WebMaster</a>.
+ </p>
+
+
+</body>
+</html> +

+ +

If you have tips to contribute, send mail to martin@apache.org

+
+
+

Available Languages:  en 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/descriptors.html b/rubbos/app/apache2/manual/misc/descriptors.html new file mode 100644 index 00000000..e751d582 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/descriptors.html @@ -0,0 +1,5 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: descriptors.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 diff --git a/rubbos/app/apache2/manual/misc/descriptors.html.en b/rubbos/app/apache2/manual/misc/descriptors.html.en new file mode 100644 index 00000000..005356d6 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/descriptors.html.en @@ -0,0 +1,233 @@ + + + +Descriptors and Apache - Apache HTTP Server + + + + + +
<-
+

Descriptors and Apache

+
+

Available Languages:  en 

+
+ + +

Warning:

+

This document has not been fully updated + to take into account changes made in the 2.0 version of the + Apache HTTP Server. Some of the information may still be + relevant, but please use it with care.

+
+ +

A descriptor, also commonly called a file + handle is an object that a program uses to read or write + an open file, or open network socket, or a variety of other + devices. It is represented by an integer, and you may be + familiar with stdin, stdout, and + stderr which are descriptors 0, 1, and 2 + respectively. Apache needs a descriptor for each log file, plus + one for each network socket that it listens on, plus a handful + of others. Libraries that Apache uses may also require + descriptors. Normal programs don't open up many descriptors at + all, and so there are some latent problems that you may + experience should you start running Apache with many + descriptors (i.e., with many virtual hosts).

+ +

The operating system enforces a limit on the number of + descriptors that a program can have open at a time. There are + typically three limits involved here. One is a kernel + limitation, depending on your operating system you will either + be able to tune the number of descriptors available to higher + numbers (this is frequently called FD_SETSIZE). Or you + may be stuck with a (relatively) low amount. The second limit + is called the hard resource limit, and it is sometimes + set by root in an obscure operating system file, but frequently + is the same as the kernel limit. The third limit is called the + soft resource limit. The soft limit is always less + than or equal to the hard limit. For example, the hard limit + may be 1024, but the soft limit only 64. Any user can raise + their soft limit up to the hard limit. Root can raise the hard + limit up to the system maximum limit. The soft limit is the + actual limit that is used when enforcing the maximum number of + files a process can have open.

+ +

To summarize:

+ +

+ #open files <= soft limit <= hard limit <= kernel limit +

+ + +

You control the hard and soft limits using the + limit (csh) or ulimit (sh) + directives. See the respective man pages for more information. + For example you can probably use ulimit -n + unlimited to raise your soft limit up to the hard limit. + You should include this command in a shell script which starts + your webserver.

+ +

Unfortunately, it's not always this simple. As mentioned + above, you will probably run into some system limitations that + will need to be worked around somehow. Work was done in version + 1.2.1 to improve the situation somewhat. Here is a partial list + of systems and workarounds (assuming you are using 1.2.1 or + later).

+ +
+ +
top
+
+

BSDI 2.0

+ +

Under BSDI 2.0 you can build Apache to support more + descriptors by adding -DFD_SETSIZE=nnn to + EXTRA_CFLAGS (where nnn is the number of + descriptors you wish to support, keep it less than the hard + limit). But it will run into trouble if more than + approximately 240 Listen directives are used. This may be + cured by rebuilding your kernel with a higher + FD_SETSIZE.

+ +
top
+
+

FreeBSD 2.2, BSDI 2.1+

+ +

Similar to the BSDI 2.0 case, you should define + FD_SETSIZE and rebuild. But the extra Listen + limitation doesn't exist.

+ +
top
+
+

Linux

+ +

By default Linux has a kernel maximum of 256 open + descriptors per process. There are several patches available + for the 2.0.x series which raise this to 1024 and beyond, and + you can find them in the "unofficial patches" section of the Linux Information HQ. + None of these patches are perfect, and an entirely different + approach is likely to be taken during the 2.1.x development. + Applying these patches will raise the FD_SETSIZE used to + compile all programs, and unless you rebuild all your + libraries you should avoid running any other program with a + soft descriptor limit above 256. As of this writing the + patches available for increasing the number of descriptors do + not take this into account. On a dedicated webserver you + probably won't run into trouble.

+ +
top
+
+

Solaris through 2.5.1

+ +

Solaris has a kernel hard limit of 1024 (may be lower in + earlier versions). But it has a limitation that files using + the stdio library cannot have a descriptor above 255. Apache + uses the stdio library for the ErrorLog directive. When you + have more than approximately 110 virtual hosts (with an error + log and an access log each) you will need to build Apache + with -DHIGH_SLACK_LINE=256 added to + EXTRA_CFLAGS. You will be limited to + approximately 240 error logs if you do this.

+ +
top
+
+

AIX

+ +

AIX version 3.2?? appears to have a hard limit of 128 + descriptors. End of story. Version 4.1.5 has a hard limit of + 2000.

+ +
top
+
+

SCO OpenServer

+ +

Edit the /etc/conf/cf.d/stune file or use + /etc/conf/cf.d/configure choice 7 (User and + Group configuration) and modify the NOFILES + kernel parameter to a suitably higher value. SCO recommends a + number between 60 and 11000, the default is 110. Relink and + reboot, and the new number of descriptors will be + available.

+ +
top
+
+

Compaq Tru64 UNIX/Digital UNIX/OSF

+ +
    +
  1. Raise open_max_soft and + open_max_hard to 4096 in the proc subsystem. + Do a man on sysconfig, sysconfigdb, and + sysconfigtab.
  2. + +
  3. Raise max-vnodes to a large number which + is greater than the number of apache processes * 4096 + (Setting it to 250,000 should be good for most people). + Do a man on sysconfig, sysconfigdb, and + sysconfigtab.
  4. + +
  5. If you are using Tru64 5.0, 5.0A, or 5.1, define + NO_SLACK to work around a bug in the OS. + CFLAGS="-DNO_SLACK" ./configure
  6. +
+ +
top
+
+

Others

+ +

If you have details on another operating system, please + submit it through our Bug Report + Page.

+ +

In addition to the problems described above there are + problems with many libraries that Apache uses. The most common + example is the bind DNS resolver library that is used by pretty + much every unix, which fails if it ends up with a descriptor + above 256. We suspect there are other libraries that similar + limitations. So the code as of 1.2.1 takes a defensive stance + and tries to save descriptors less than 16 for use while + processing each request. This is called the low slack + line.

+ +

Note that this shouldn't waste descriptors. If you really + are pushing the limits and Apache can't get a descriptor above + 16 when it wants it, it will settle for one below 16.

+ +

In extreme situations you may want to lower the low slack + line, but you shouldn't ever need to. For example, lowering it + can increase the limits 240 described above under Solaris and + BSDI 2.0. But you'll play a delicate balancing game with the + descriptors needed to serve a request. Should you want to play + this game, the compile time parameter is + LOW_SLACK_LINE and there's a tiny bit of + documentation in the header file httpd.h.

+ +

Finally, if you suspect that all this slack stuff is causing + you problems, you can disable it. Add -DNO_SLACK + to EXTRA_CFLAGS and rebuild. But please report it + to our Bug + Report Page so that we can investigate.

+ +
+
+

Available Languages:  en 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/fin_wait_2.html b/rubbos/app/apache2/manual/misc/fin_wait_2.html new file mode 100644 index 00000000..64957238 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/fin_wait_2.html @@ -0,0 +1,5 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: fin_wait_2.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 diff --git a/rubbos/app/apache2/manual/misc/fin_wait_2.html.en b/rubbos/app/apache2/manual/misc/fin_wait_2.html.en new file mode 100644 index 00000000..60da4b0d --- /dev/null +++ b/rubbos/app/apache2/manual/misc/fin_wait_2.html.en @@ -0,0 +1,422 @@ + + + +Connections in the FIN_WAIT_2 state and Apache - Apache HTTP Server + + + + + +
<-
+

Connections in the FIN_WAIT_2 state and Apache

+
+

Available Languages:  en 

+
+ + +

Warning:

+

This document has not been fully updated + to take into account changes made in the 2.0 version of the + Apache HTTP Server. Some of the information may still be + relevant, but please use it with care.

+
+ +

Starting with the Apache 1.2 betas, people are reporting + many more connections in the FIN_WAIT_2 state (as reported + by netstat) than they saw using older + versions. When the server closes a TCP connection, it sends + a packet with the FIN bit set to the client, which then + responds with a packet with the ACK bit set. The client + then sends a packet with the FIN bit set to the server, + which responds with an ACK and the connection is closed. + The state that the connection is in during the period + between when the server gets the ACK from the client and + the server gets the FIN from the client is known as + FIN_WAIT_2. See the TCP RFC for + the technical details of the state transitions.

+ +

The FIN_WAIT_2 state is somewhat unusual in that there + is no timeout defined in the standard for it. This means + that on many operating systems, a connection in the + FIN_WAIT_2 state will stay around until the system is + rebooted. If the system does not have a timeout and too + many FIN_WAIT_2 connections build up, it can fill up the + space allocated for storing information about the + connections and crash the kernel. The connections in + FIN_WAIT_2 do not tie up an httpd process.

+ +
+ +
top
+
+

Why Does It Happen?

+ +

There are numerous reasons for it happening, some of them + may not yet be fully clear. What is known follows.

+ +

Buggy Clients and Persistent + Connections

+ +

Several clients have a bug which pops up when dealing with + persistent connections (aka + keepalives). When the connection is idle and the server + closes the connection (based on the KeepAliveTimeout), + the client is programmed so that the client does not send + back a FIN and ACK to the server. This means that the + connection stays in the FIN_WAIT_2 state until one of the + following happens:

+ +
    +
  • The client opens a new connection to the same or a + different site, which causes it to fully close the older + connection on that socket.
  • + +
  • The user exits the client, which on some (most?) + clients causes the OS to fully shutdown the + connection.
  • + +
  • The FIN_WAIT_2 times out, on servers that have a + timeout for this state.
  • +
+ +

If you are lucky, this means that the buggy client will + fully close the connection and release the resources on + your server. However, there are some cases where the socket + is never fully closed, such as a dialup client + disconnecting from their provider before closing the + client. In addition, a client might sit idle for days + without making another connection, and thus may hold its + end of the socket open for days even though it has no + further use for it. This is a bug in the browser or + in its operating system's TCP implementation.

+ +

The clients on which this problem has been verified to + exist:

+ +
    +
  • Mozilla/3.01 (X11; I; FreeBSD 2.1.5-RELEASE + i386)
  • + +
  • Mozilla/2.02 (X11; I; FreeBSD 2.1.5-RELEASE + i386)
  • + +
  • Mozilla/3.01Gold (X11; I; SunOS 5.5 sun4m)
  • + +
  • MSIE 3.01 on the Macintosh
  • + +
  • MSIE 3.01 on Windows 95
  • +
+ +

This does not appear to be a problem on:

+ +
    +
  • Mozilla/3.01 (Win95; I)
  • +
+ +

It is expected that many other clients have the same + problem. What a client should do is + periodically check its open socket(s) to see if they have + been closed by the server, and close their side of the + connection if the server has closed. This check need only + occur once every few seconds, and may even be detected by a + OS signal on some systems (e.g., Win95 and NT + clients have this capability, but they seem to be ignoring + it).

+ +

Apache cannot avoid these FIN_WAIT_2 + states unless it disables persistent connections for the + buggy clients, just like we recommend doing for Navigator + 2.x clients due to other bugs. However, non-persistent + connections increase the total number of connections needed + per client and slow retrieval of an image-laden web page. + Since non-persistent connections have their own resource + consumptions and a short waiting period after each closure, + a busy server may need persistence in order to best serve + its clients.

+ +

As far as we know, the client-caused FIN_WAIT_2 problem + is present for all servers that support persistent + connections, including Apache 1.1.x and 1.2.

+ + + +

A necessary bit of code + introduced in 1.2

+ +

While the above bug is a problem, it is not the whole + problem. Some users have observed no FIN_WAIT_2 problems + with Apache 1.1.x, but with 1.2b enough connections build + up in the FIN_WAIT_2 state to crash their server. The most + likely source for additional FIN_WAIT_2 states is a + function called lingering_close() which was + added between 1.1 and 1.2. This function is necessary for + the proper handling of persistent connections and any + request which includes content in the message body + (e.g., PUTs and POSTs). What it does is read any + data sent by the client for a certain time after the server + closes the connection. The exact reasons for doing this are + somewhat complicated, but involve what happens if the + client is making a request at the same time the server + sends a response and closes the connection. Without + lingering, the client might be forced to reset its TCP + input buffer before it has a chance to read the server's + response, and thus understand why the connection has + closed. See the appendix for more + details.

+ +

The code in lingering_close() appears to + cause problems for a number of factors, including the + change in traffic patterns that it causes. The code has + been thoroughly reviewed and we are not aware of any bugs + in it. It is possible that there is some problem in the BSD + TCP stack, aside from the lack of a timeout for the + FIN_WAIT_2 state, exposed by the + lingering_close code that causes the observed + problems.

+ + +
top
+
+

What Can I Do About it?

+ +

There are several possible workarounds to the problem, some + of which work better than others.

+ +

Add a timeout for FIN_WAIT_2

+ +

The obvious workaround is to simply have a timeout for the + FIN_WAIT_2 state. This is not specified by the RFC, and + could be claimed to be a violation of the RFC, but it is + widely recognized as being necessary. The following systems + are known to have a timeout:

+ +
    +
  • FreeBSD + versions starting at 2.0 or possibly earlier.
  • + +
  • NetBSD version + 1.2(?)
  • + +
  • OpenBSD all + versions(?)
  • + +
  • BSD/OS 2.1, with + the + K210-027 patch installed.
  • + +
  • Solaris as of + around version 2.2. The timeout can be tuned by using + ndd to modify + tcp_fin_wait_2_flush_interval, but the + default should be appropriate for most servers and + improper tuning can have negative impacts.
  • + +
  • Linux 2.0.x and + earlier(?)
  • + +
  • HP-UX 10.x defaults + to terminating connections in the FIN_WAIT_2 state after + the normal keepalive timeouts. This does not refer to the + persistent connection or HTTP keepalive timeouts, but the + SO_LINGER socket option which is enabled by + Apache. This parameter can be adjusted by using + nettune to modify parameters such as + tcp_keepstart and tcp_keepstop. + In later revisions, there is an explicit timer for + connections in FIN_WAIT_2 that can be modified; contact + HP support for details.
  • + +
  • SGI IRIX can be + patched to support a timeout. For IRIX 5.3, 6.2, and 6.3, + use patches 1654, 1703 and 1778 respectively. If you have + trouble locating these patches, please contact your SGI + support channel for help.
  • + +
  • NCR's MP RAS Unix + 2.xx and 3.xx both have FIN_WAIT_2 timeouts. In 2.xx it + is non-tunable at 600 seconds, while in 3.xx it defaults + to 600 seconds and is calculated based on the tunable + "max keep alive probes" (default of 8) multiplied by the + "keep alive interval" (default 75 seconds).
  • + +
  • Sequent's ptx/TCP/IP + for DYNIX/ptx has had a FIN_WAIT_2 timeout since + around release 4.1 in mid-1994.
  • +
+ +

The following systems are known to not have a + timeout:

+ +
    +
  • SunOS 4.x does not + and almost certainly never will have one because it as at + the very end of its development cycle for Sun. If you + have kernel source should be easy to patch.
  • +
+ +

There is a + patch available for adding a timeout to the FIN_WAIT_2 + state; it was originally intended for BSD/OS, but should be + adaptable to most systems using BSD networking code. You + need kernel source code to be able to use it.

+ + + +

Compile without using + lingering_close()

+ +

It is possible to compile Apache 1.2 without using the + lingering_close() function. This will result + in that section of code being similar to that which was in + 1.1. If you do this, be aware that it can cause problems + with PUTs, POSTs and persistent connections, especially if + the client uses pipelining. That said, it is no worse than + on 1.1, and we understand that keeping your server running + is quite important.

+ +

To compile without the lingering_close() + function, add -DNO_LINGCLOSE to the end of the + EXTRA_CFLAGS line in your + Configuration file, rerun + Configure and rebuild the server.

+ + + +

Use SO_LINGER as + an alternative to lingering_close()

+ +

On most systems, there is an option called + SO_LINGER that can be set with + setsockopt(2). It does something very similar + to lingering_close(), except that it is broken + on many systems so that it causes far more problems than + lingering_close. On some systems, it could + possibly work better so it may be worth a try if you have + no other alternatives.

+ +

To try it, add -DUSE_SO_LINGER + -DNO_LINGCLOSE to the end of the + EXTRA_CFLAGS line in your + Configuration file, rerun + Configure and rebuild the server.

+ +

NOTE

Attempting to use + SO_LINGER and lingering_close() + at the same time is very likely to do very bad things, so + don't.
+ + + +

Increase the amount of memory + used for storing connection state

+ +
+
BSD based networking code:
+ +
+ BSD stores network data, such as connection states, in + something called an mbuf. When you get so many + connections that the kernel does not have enough mbufs + to put them all in, your kernel will likely crash. You + can reduce the effects of the problem by increasing the + number of mbufs that are available; this will not + prevent the problem, it will just make the server go + longer before crashing. + +

The exact way to increase them may depend on your + OS; look for some reference to the number of "mbufs" or + "mbuf clusters". On many systems, this can be done by + adding the line NMBCLUSTERS="n", where + n is the number of mbuf clusters you want + to your kernel config file and rebuilding your + kernel.

+
+
+ + + +

Disable KeepAlive

+ +

If you are unable to do any of the above then you + should, as a last resort, disable KeepAlive. Edit your + httpd.conf and change "KeepAlive On" to "KeepAlive + Off".

+ + +
top
+
+

Appendix

+ +

Below is a message from Roy Fielding, one of the authors + of HTTP/1.1.

+ +

Why the lingering close + functionality is necessary with HTTP

+ +

The need for a server to linger on a socket after a close + is noted a couple times in the HTTP specs, but not + explained. This explanation is based on discussions between + myself, Henrik Frystyk, Robert S. Thau, Dave Raggett, and + John C. Mallery in the hallways of MIT while I was at W3C.

+ +

If a server closes the input side of the connection + while the client is sending data (or is planning to send + data), then the server's TCP stack will signal an RST + (reset) back to the client. Upon receipt of the RST, the + client will flush its own incoming TCP buffer back to the + un-ACKed packet indicated by the RST packet argument. If + the server has sent a message, usually an error response, + to the client just before the close, and the client + receives the RST packet before its application code has + read the error message from its incoming TCP buffer and + before the server has received the ACK sent by the client + upon receipt of that buffer, then the RST will flush the + error message before the client application has a chance to + see it. The result is that the client is left thinking that + the connection failed for no apparent reason.

+ +

There are two conditions under which this is likely to + occur:

+ +
    +
  1. sending POST or PUT data without proper + authorization
  2. + +
  3. sending multiple requests before each response + (pipelining) and one of the middle requests resulting in + an error or other break-the-connection result.
  4. +
+ +

The solution in all cases is to send the response, close + only the write half of the connection (what shutdown is + supposed to do), and continue reading on the socket until + it is either closed by the client (signifying it has + finally read the response) or a timeout occurs. That is + what the kernel is supposed to do if SO_LINGER is set. + Unfortunately, SO_LINGER has no effect on some systems; on + some other systems, it does not have its own timeout and + thus the TCP memory segments just pile-up until the next + reboot (planned or not).

+ +

Please note that simply removing the linger code will + not solve the problem -- it only moves it to a different + and much harder one to detect.

+ +
+
+

Available Languages:  en 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/index.html b/rubbos/app/apache2/manual/misc/index.html new file mode 100644 index 00000000..23ec1ec0 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/index.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: index.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 + +URI: index.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 diff --git a/rubbos/app/apache2/manual/misc/index.html.en b/rubbos/app/apache2/manual/misc/index.html.en new file mode 100644 index 00000000..81445841 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/index.html.en @@ -0,0 +1,121 @@ + + + +Apache Miscellaneous Documentation - Apache HTTP Server + + + + + +
<-
+

Apache Miscellaneous Documentation

+
+

Available Languages:  en  | + tr 

+
+ + +

Below is a list of additional documentation pages that apply + to the Apache web server development project.

+ +

Warning

+

Some of the documents below have not been fully updated + to take into account changes made in the 2.0 version of the + Apache HTTP Server. Some of the information may still be + relevant, but please use it with care.

+
+ +
+
How to use XSSI and + Negotiation for custom ErrorDocuments
+ +
+

Describes a solution which uses XSSI and negotiation to + custom-tailor the Apache ErrorDocuments to taste, adding the + advantage of returning internationalized versions of the + error messages depending on the client's language + preferences.

+
+ +
File Descriptor use in + Apache
+ +
+

Describes how Apache uses file descriptors and talks + about various limits imposed on the number of descriptors + available by various operating systems.

+
+ +
FIN_WAIT_2
+ +
+

A description of the causes of Apache processes going + into the FIN_WAIT_2 state, and what you can do + about it.

+
+ +
Known Client + Problems
+ +
+

A list of problems in HTTP clients which can be mitigated + by Apache.

+
+ +
Performance Notes - Apache + Tuning
+ +
+

Notes about how to (run-time and compile-time) configure + Apache for highest performance. Notes explaining why Apache + does some things, and why it doesn't do other things (which + make it slower/faster).

+
+ +
Security Tips
+ +
+

Some "do"s - and "don't"s - for keeping your Apache web + site secure.

+
+ +
URL Rewriting Guide
+
+

This document supplements the mod_rewrite + reference documentation. + It describes how one can use Apache's mod_rewrite + to solve typical URL-based problems webmasters are usually confronted + with in practice.

+
+ +
Apache Tutorials
+ +
+

A list of external resources which help to accomplish common + tasks with the Apache HTTP server.

+
+ +
Relevant Standards
+ +
+

This document acts as a reference page for most of the relevant + standards that Apache follows.

+
+
+
+
+
+

Available Languages:  en  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/index.html.tr.utf8 b/rubbos/app/apache2/manual/misc/index.html.tr.utf8 new file mode 100644 index 00000000..e4cb8a26 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/index.html.tr.utf8 @@ -0,0 +1,122 @@ + + + +Çeşitli Belgeler - Apache HTTP Sunucusu + + + + + +
<-
+

Çeşitli Belgeler

+
+

Mevcut Diller:  en  | + tr 

+
+ + +

Aşağıda listelenen belgeler de Apache HTTP sunucusu geliştirme projesi + kapsamındadır.

+ +

Uyarı

+

Aşağıdaki belgeler, Apache HTTP Sunucusunun 2.0 sürümünde yapılmış + değişikliklere göre tam olarak güncellenmemiştir. Hala güncel kalmış + bazı bilgiler olabilir, fakat siz yine de bu belgeleri kullanırken + dikkatli olun.

+
+ +
+
Hata belgelerinin özelleştirilmesi + için XSSI ve içerik uzlaşımının kullanımı
+ +
+

Belgede, istemcinin dil tercihlerine bağlı olarak hata + iletilerinin yerelleştirilmiş sürümlerini döndürmenin yanında + Apache hata belgelerine bir çeşni katmak için XSSI ve içerik + uzlaşımının kullanımıyla ilgili bir çözüme yer verilmiştir.

+
+ +
Apache’de dosya tanıtıcılarının + kullanımı
+ +
+

Belgede, Apache’nin çeşitli işletim sistemleri tarafından + dayatılan dosya tanıtıcı miktarları için işletim sistemleri ile + nasıl anlaştığı ve bu dosya tanıtıcılarını nasıl kullandığı + açıklanmıştır.

+
+ +
FIN_WAIT_2
+ +
+

Belgede, Apache’nin FIN_WAIT_2 durumuna girme + sebepleri ile bu konuda neler yapılabileceği açıklanmıştır.

+
+ +
Bilinen İstemci Sorunları +
+ +
+

Belgede, HTTP istemcilerinden kaynaklanan bazı sorunların Apache + tarafından hafifletilebilenlerinin bir listesi yer almaktadır.

+
+ +
Başarım Arttırma İpuçları - Apache’ye + İnce Ayar Çekilmesi
+ +
+

Yüksek başarım elde etmek için Apache yapılandırmasında (çalışma + anında ve derleme sırasında) yapılacaklar ile ilgili bazı bilgiler + yanında Apache’de bazı şeylerin (bir şeyleri hızlandıran ve + yavaşlatan şeylerin) yapılma ve yapılmama sebepleri + açıklanmıştır.

+
+ +
Güvenlik İpuçları
+ +
+

Apache HTTP sitenizi güvenli kılmak için yapılacaklar ve + yapılmayacaklar.

+
+ +
URL Yeniden Yazma Rehberi
+ +
+

Bu belge mod_rewrite modülünün başvuru belgesi yerine geçer. + Site yöneticilerinin sıkça karşılaştıkları belli başlı URL temelli + sorunları çözümlemek için Apache’nin mod_rewrite + modülünün nasıl kullanılacağını açıklar.

+
+ +
Apache Öğreticileri
+ +
+

Apache HTTP Sunucusu ile ilgili görevlerinizi yerine getirmenize + yardımcı olacak harici kaynakların bir listesi.

+
+ +
Ä°lgili Standartlar
+ +
+

Bu belge Apache’nin uyacağı standartların bir çoğuna atıfta + bulunmak amacıyla hazırlanmıştır.

+
+
+ +
+
+
+

Mevcut Diller:  en  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/known_client_problems.html b/rubbos/app/apache2/manual/misc/known_client_problems.html new file mode 100644 index 00000000..9f5b039f --- /dev/null +++ b/rubbos/app/apache2/manual/misc/known_client_problems.html @@ -0,0 +1,5 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: known_client_problems.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 diff --git a/rubbos/app/apache2/manual/misc/known_client_problems.html.en b/rubbos/app/apache2/manual/misc/known_client_problems.html.en new file mode 100644 index 00000000..cfc02954 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/known_client_problems.html.en @@ -0,0 +1,408 @@ + + + +Known Problems in Clients - Apache HTTP Server + + + + + +
<-
+

Known Problems in Clients

+
+

Available Languages:  en 

+
+ + +

Warning:

+

This document has not been fully updated + to take into account changes made in the 2.0 version of the + Apache HTTP Server. Some of the information may still be + relevant, but please use it with care.

+
+ +

Over time the Apache Group has discovered or been notified + of problems with various clients which we have had to work + around, or explain. This document describes these problems and + the workarounds available. It's not arranged in any particular + order. Some familiarity with the standards is assumed, but not + necessary.

+ +

For brevity, Navigator will refer to Netscape's + Navigator product (which in later versions was renamed + "Communicator" and various other names), and MSIE will + refer to Microsoft's Internet Explorer product. All trademarks + and copyrights belong to their respective companies. We welcome + input from the various client authors to correct + inconsistencies in this paper, or to provide us with exact + version numbers where things are broken/fixed.

+ +

For reference, RFC1945 + defines HTTP/1.0, and RFC2068 + defines HTTP/1.1. Apache as of version 1.2 is an HTTP/1.1 + server (with an optional HTTP/1.0 proxy).

+ +

Various of these workarounds are triggered by environment + variables. The admin typically controls which are set, and for + which clients, by using mod_browser. Unless + otherwise noted all of these workarounds exist in versions 1.2 + and later.

+ +
+ +
top
+
+

Trailing CRLF on POSTs

+ +

This is a legacy issue. The CERN webserver required + POST data to have an extra CRLF + following it. Thus many clients send an extra CRLF + that is not included in the Content-Length of the + request. Apache works around this problem by eating any empty + lines which appear before a request.

+ +
top
+
+

Broken KeepAlive

+ +

Various clients have had broken implementations of + keepalive (persistent connections). In particular the + Windows versions of Navigator 2.0 get very confused when the + server times out an idle connection. The workaround is present + in the default config files:

+ +

+ BrowserMatch Mozilla/2 nokeepalive +

+ +

Note that this matches some earlier versions of MSIE, which + began the practice of calling themselves Mozilla in + their user-agent strings just like Navigator.

+ +

MSIE 4.0b2, which claims to support HTTP/1.1, does not + properly support keepalive when it is used on 301 or 302 + (redirect) responses. Unfortunately Apache's + nokeepalive code prior to 1.2.2 would not work + with HTTP/1.1 clients. You must apply + this patch to version 1.2.1. Then add this to your + config:

+ +

+ BrowserMatch "MSIE 4\.0b2;" nokeepalive +

+ +
top
+
+

Incorrect interpretation of + HTTP/1.1 in response

+ +

To quote from section 3.1 of RFC1945:

+ +
+ HTTP uses a "<MAJOR>.<MINOR>" numbering scheme to + indicate versions of the protocol. The protocol versioning + policy is intended to allow the sender to indicate the format + of a message and its capacity for understanding further HTTP + communication, rather than the features obtained via that + communication. +
+ +

Since Apache is an HTTP/1.1 server, it indicates so as part of + its response. Many client authors mistakenly treat this part of + the response as an indication of the protocol that the response + is in, and then refuse to accept the response.

+ +

The first major indication of this problem was with AOL's + proxy servers. When Apache 1.2 went into beta it was the first + wide-spread HTTP/1.1 server. After some discussion, AOL fixed + their proxies. In anticipation of similar problems, the + force-response-1.0 environment variable was added + to Apache. When present Apache will indicate "HTTP/1.0" in + response to an HTTP/1.0 client, but will not in any other way + change the response.

+ +

The pre-1.1 Java Development Kit (JDK) that is used in many + clients (including Navigator 3.x and MSIE 3.x) exhibits this + problem. As do some of the early pre-releases of the 1.1 JDK. + We think it is fixed in the 1.1 JDK release. In any event the + workaround:

+ +

+ BrowserMatch Java/1.0 force-response-1.0
+ BrowserMatch JDK/1.0 force-response-1.0 +

+ +

RealPlayer 4.0 from Progressive Networks also exhibits this + problem. However they have fixed it in version 4.01 of the + player, but version 4.01 uses the same User-Agent + as version 4.0. The workaround is still:

+ +

+ BrowserMatch "RealPlayer 4.0" force-response-1.0 +

+ +
top
+
+

Requests use HTTP/1.1 but + responses must be in HTTP/1.0

+ +

MSIE 4.0b2 has this problem. Its Java VM makes requests in + HTTP/1.1 format but the responses must be in HTTP/1.0 format + (in particular, it does not understand chunked + responses). The workaround is to fool Apache into believing the + request came in HTTP/1.0 format.

+ +

+ BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 + force-response-1.0 +

+ +

This workaround is available in 1.2.2, and in a + patch against 1.2.1.

+ +
top
+
+

Boundary problems with + header parsing

+ +

All versions of Navigator from 2.0 through 4.0b2 (and + possibly later) have a problem if the trailing CRLF of the + response header starts at offset 256, 257 or 258 of the + response. A BrowserMatch for this would match on nearly every + hit, so the workaround is enabled automatically on all + responses. The workaround implemented detects when this + condition would occur in a response and adds extra padding to + the header to push the trailing CRLF past offset 258 of the + response.

+ +
top
+
+

Multipart responses and + Quoted Boundary Strings

+ +

On multipart responses some clients will not accept quotes + (") around the boundary string. The MIME standard recommends + that such quotes be used. But the clients were probably written + based on one of the examples in RFC2068, which does not include + quotes. Apache does not include quotes on its boundary strings + to workaround this problem.

+ +
top
+
+

Byterange Requests

+ +

A byterange request is used when the client wishes to + retrieve a portion of an object, not necessarily the entire + object. There was a very old draft which included these + byteranges in the URL. Old clients such as Navigator 2.0b1 and + MSIE 3.0 for the MAC exhibit this behaviour, and it will appear + in the servers' access logs as (failed) attempts to retrieve a + URL with a trailing ";xxx-yyy". Apache does not attempt to + implement this at all.

+ +

A subsequent draft of this standard defines a header + Request-Range, and a response type + multipart/x-byteranges. The HTTP/1.1 standard + includes this draft with a few fixes, and it defines the header + Range and type + multipart/byteranges.

+ +

Navigator (versions 2 and 3) sends both Range + and Request-Range headers (with the same value), + but does not accept a multipart/byteranges + response. The response must be + multipart/x-byteranges. As a workaround, if Apache + receives a Request-Range header it considers it + "higher priority" than a Range header and in + response uses multipart/x-byteranges.

+ +

The Adobe Acrobat Reader plugin makes extensive use of + byteranges and prior to version 3.01 supports only the + multipart/x-byterange response. Unfortunately + there is no clue that it is the plugin making the request. If + the plugin is used with Navigator, the above workaround works + fine. But if the plugin is used with MSIE 3 (on Windows) the + workaround won't work because MSIE 3 doesn't give the + Range-Request clue that Navigator does. To + workaround this, Apache special cases "MSIE 3" in the + User-Agent and serves + multipart/x-byteranges. Note that the necessity + for this with MSIE 3 is actually due to the Acrobat plugin, not + due to the browser.

+ +

Netscape Communicator appears to not issue the non-standard + Request-Range header. When an Acrobat plugin prior + to version 3.01 is used with it, it will not properly + understand byteranges. The user must upgrade their Acrobat + reader to 3.01.

+ +
top
+
+

Set-Cookie header is + unmergeable

+ +

The HTTP specifications say that it is legal to merge + headers with duplicate names into one (separated by commas). + Some browsers that support Cookies don't like merged headers + and prefer that each Set-Cookie header is sent + separately. When parsing the headers returned by a CGI, Apache + will explicitly avoid merging any Set-Cookie + headers.

+ +
top
+
+

Expires headers + and GIF89A animations

+ +

Navigator versions 2 through 4 will erroneously re-request + GIF89A animations on each loop of the animation if the first + response included an Expires header. This happens + regardless of how far in the future the expiry time is set. + There is no workaround supplied with Apache, however there are + hacks for + 1.2 and for + 1.3.

+ +
top
+
+

POST without + Content-Length

+ +

In certain situations Navigator 3.01 through 3.03 appear to + incorrectly issue a POST without the request body. There is no + known workaround. It has been fixed in Navigator 3.04, + Netscapes provides some information. + There's also + some information about the actual problem.

+ +
top
+
+

JDK 1.2 betas lose + parts of responses.

+ +

The http client in the JDK1.2beta2 and beta3 will throw away + the first part of the response body when both the headers and + the first part of the body are sent in the same network packet + AND keep-alive's are being used. If either condition is not met + then it works fine.

+ +

See also Bug-ID's 4124329 and 4125538 at the java developer + connection.

+ +

If you are seeing this bug yourself, you can add the + following BrowserMatch directive to work around it:

+ +

+ BrowserMatch "Java1\.2beta[23]" nokeepalive +

+ +

We don't advocate this though since bending over backwards + for beta software is usually not a good idea; ideally it gets + fixed, new betas or a final release comes out, and no one uses + the broken old software anymore. In theory.

+ +
top
+
+

Content-Type + change is not noticed after reload

+ +

Navigator (all versions?) will cache the + content-type for an object "forever". Using reload + or shift-reload will not cause Navigator to notice a + content-type change. The only work-around is for + the user to flush their caches (memory and disk). By way of an + example, some folks may be using an old mime.types + file which does not map .htm to + text/html, in this case Apache will default to + sending text/plain. If the user requests the page + and it is served as text/plain. After the admin + fixes the server, the user will have to flush their caches + before the object will be shown with the correct + text/html type.

+ +
top
+
+

MSIE Cookie + problem with expiry date in the year 2000

+ +

MSIE versions 3.00 and 3.02 (without the Y2K patch) do not + handle cookie expiry dates in the year 2000 properly. Years + after 2000 and before 2000 work fine. This is fixed in IE4.01 + service pack 1, and in the Y2K patch for IE3.02. Users should + avoid using expiry dates in the year 2000.

+ +
top
+
+

Lynx incorrectly asking for + transparent content negotiation

+ +

The Lynx browser versions 2.7 and 2.8 send a "negotiate: + trans" header in their requests, which is an indication the + browser supports transparent content negotiation (TCN). However + the browser does not support TCN. As of version 1.3.4, Apache + supports TCN, and this causes problems with these versions of + Lynx. As a workaround future versions of Apache will ignore + this header when sent by the Lynx client.

+ +
top
+
+

MSIE 4.0 mishandles Vary + response header

+ +

MSIE 4.0 does not handle a Vary header properly. The Vary + header is generated by mod_rewrite in apache 1.3. The result is + an error from MSIE saying it cannot download the requested + file. There are more details in PR#4118.

+ +

A workaround is to add the following to your server's + configuration files:

+ +

+ BrowserMatch "MSIE 4\.0" force-no-vary +

+ +

(This workaround is only available with releases + after 1.3.6 of the Apache Web server.)

+ +
+
+

Available Languages:  en 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/perf-tuning.html b/rubbos/app/apache2/manual/misc/perf-tuning.html new file mode 100644 index 00000000..84956329 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/perf-tuning.html @@ -0,0 +1,13 @@ +# GENERATED FROM XML -- DO NOT EDIT + +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 + +URI: perf-tuning.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 diff --git a/rubbos/app/apache2/manual/misc/perf-tuning.html.en b/rubbos/app/apache2/manual/misc/perf-tuning.html.en new file mode 100644 index 00000000..2a6bc9d1 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/perf-tuning.html.en @@ -0,0 +1,1058 @@ + + + +Apache Performance Tuning - Apache HTTP Server + + + + + +
<-
+

Apache Performance Tuning

+
+

Available Languages:  en  | + ko  | + tr 

+
+ + +

Apache 2.x is a general-purpose webserver, designed to + provide a balance of flexibility, portability, and performance. + Although it has not been designed specifically to set benchmark + records, Apache 2.x is capable of high performance in many + real-world situations.

+ +

Compared to Apache 1.3, release 2.x contains many additional + optimizations to increase throughput and scalability. Most of + these improvements are enabled by default. However, there are + compile-time and run-time configuration choices that can + significantly affect performance. This document describes the + options that a server administrator can configure to tune the + performance of an Apache 2.x installation. Some of these + configuration options enable the httpd to better take advantage + of the capabilities of the hardware and OS, while others allow + the administrator to trade functionality for speed.

+ +
+ +
top
+
+

Hardware and Operating System Issues

+ + + +

The single biggest hardware issue affecting webserver + performance is RAM. A webserver should never ever have to swap, + as swapping increases the latency of each request beyond a point + that users consider "fast enough". This causes users to hit + stop and reload, further increasing the load. You can, and + should, control the MaxClients setting so that your server + does not spawn so many children it starts swapping. This procedure + for doing this is simple: determine the size of your average Apache + process, by looking at your process list via a tool such as + top, and divide this into your total available memory, + leaving some room for other processes.

+ +

Beyond that the rest is mundane: get a fast enough CPU, a + fast enough network card, and fast enough disks, where "fast + enough" is something that needs to be determined by + experimentation.

+ +

Operating system choice is largely a matter of local + concerns. But some guidelines that have proven generally + useful are:

+ +
    +
  • +

    Run the latest stable release and patchlevel of the + operating system that you choose. Many OS suppliers have + introduced significant performance improvements to their + TCP stacks and thread libraries in recent years.

    +
  • + +
  • +

    If your OS supports a sendfile(2) system + call, make sure you install the release and/or patches + needed to enable it. (With Linux, for example, this means + using Linux 2.4 or later. For early releases of Solaris 8, + you may need to apply a patch.) On systems where it is + available, sendfile enables Apache 2 to deliver + static content faster and with lower CPU utilization.

    +
  • +
+ +
top
+
+

Run-Time Configuration Issues

+ + + + + +

HostnameLookups and other DNS considerations

+ + + +

Prior to Apache 1.3, HostnameLookups defaulted to On. + This adds latency to every request because it requires a + DNS lookup to complete before the request is finished. In + Apache 1.3 this setting defaults to Off. If you need + to have addresses in your log files resolved to hostnames, use the + logresolve + program that comes with Apache, or one of the numerous log + reporting packages which are available.

+ +

It is recommended that you do this sort of postprocessing of + your log files on some machine other than the production web + server machine, in order that this activity not adversely affect + server performance.

+ +

If you use any Allow + from domain or Deny from domain + directives (i.e., using a hostname, or a domain name, rather than + an IP address) then you will pay for + two DNS lookups (a reverse, followed by a forward lookup + to make sure that the reverse is not being spoofed). For best + performance, therefore, use IP addresses, rather than names, when + using these directives, if possible.

+ +

Note that it's possible to scope the directives, such as + within a <Location /server-status> section. + In this case the DNS lookups are only performed on requests + matching the criteria. Here's an example which disables lookups + except for .html and .cgi files:

+ +

+ HostnameLookups off
+ <Files ~ "\.(html|cgi)$">
+ + HostnameLookups on
+
+ </Files> +

+ +

But even still, if you just need DNS names in some CGIs you + could consider doing the gethostbyname call in the + specific CGIs that need it.

+ + + +

FollowSymLinks and SymLinksIfOwnerMatch

+ + + +

Wherever in your URL-space you do not have an Options + FollowSymLinks, or you do have an Options + SymLinksIfOwnerMatch Apache will have to issue extra + system calls to check up on symlinks. One extra call per + filename component. For example, if you had:

+ +

+ DocumentRoot /www/htdocs
+ <Directory />
+ + Options SymLinksIfOwnerMatch
+
+ </Directory> +

+ +

and a request is made for the URI /index.html. + Then Apache will perform lstat(2) on + /www, /www/htdocs, and + /www/htdocs/index.html. The results of these + lstats are never cached, so they will occur on + every single request. If you really desire the symlinks + security checking you can do something like this:

+ +

+ DocumentRoot /www/htdocs
+ <Directory />
+ + Options FollowSymLinks
+
+ </Directory>
+
+ <Directory /www/htdocs>
+ + Options -FollowSymLinks +SymLinksIfOwnerMatch
+
+ </Directory> +

+ +

This at least avoids the extra checks for the + DocumentRoot path. + Note that you'll need to add similar sections if you + have any Alias or + RewriteRule paths + outside of your document root. For highest performance, + and no symlink protection, set FollowSymLinks + everywhere, and never set SymLinksIfOwnerMatch.

+ + + +

AllowOverride

+ + + +

Wherever in your URL-space you allow overrides (typically + .htaccess files) Apache will attempt to open + .htaccess for each filename component. For + example,

+ +

+ DocumentRoot /www/htdocs
+ <Directory />
+ + AllowOverride all
+
+ </Directory> +

+ +

and a request is made for the URI /index.html. + Then Apache will attempt to open /.htaccess, + /www/.htaccess, and + /www/htdocs/.htaccess. The solutions are similar + to the previous case of Options FollowSymLinks. + For highest performance use AllowOverride None + everywhere in your filesystem.

+ + + +

Negotiation

+ + + +

If at all possible, avoid content-negotiation if you're + really interested in every last ounce of performance. In + practice the benefits of negotiation outweigh the performance + penalties. There's one case where you can speed up the server. + Instead of using a wildcard such as:

+ +

+ DirectoryIndex index +

+ +

Use a complete list of options:

+ +

+ DirectoryIndex index.cgi index.pl index.shtml index.html +

+ +

where you list the most common choice first.

+ +

Also note that explicitly creating a type-map + file provides better performance than using + MultiViews, as the necessary information can be + determined by reading this single file, rather than having to + scan the directory for files.

+ +

If your site needs content negotiation consider using + type-map files, rather than the Options + MultiViews directive to accomplish the negotiation. See the + Content Negotiation + documentation for a full discussion of the methods of negotiation, + and instructions for creating type-map files.

+ + + +

Memory-mapping

+ + + +

In situations where Apache 2.x needs to look at the contents + of a file being delivered--for example, when doing server-side-include + processing--it normally memory-maps the file if the OS supports + some form of mmap(2).

+ +

On some platforms, this memory-mapping improves performance. + However, there are cases where memory-mapping can hurt the performance + or even the stability of the httpd:

+ +
    +
  • +

    On some operating systems, mmap does not scale + as well as read(2) when the number of CPUs increases. + On multiprocessor Solaris servers, for example, Apache 2.x sometimes + delivers server-parsed files faster when mmap is disabled.

    +
  • + +
  • +

    If you memory-map a file located on an NFS-mounted filesystem + and a process on another NFS client machine deletes or truncates + the file, your process may get a bus error the next time it tries + to access the mapped file content.

    +
  • +
+ +

For installations where either of these factors applies, you + should use EnableMMAP off to disable the memory-mapping + of delivered files. (Note: This directive can be overridden on + a per-directory basis.)

+ + + +

Sendfile

+ + + +

In situations where Apache 2.x can ignore the contents of the file + to be delivered -- for example, when serving static file content -- + it normally uses the kernel sendfile support the file if the OS + supports the sendfile(2) operation.

+ +

On most platforms, using sendfile improves performance by eliminating + separate read and send mechanics. However, there are cases where using + sendfile can harm the stability of the httpd:

+ +
    +
  • +

    Some platforms may have broken sendfile support that the build + system did not detect, especially if the binaries were built on + another box and moved to such a machine with broken sendfile support.

    +
  • +
  • +

    With an NFS-mounted files, the kernel may be unable + to reliably serve the network file through it's own cache.

    +
  • +
+ +

For installations where either of these factors applies, you + should use EnableSendfile off to disable sendfile + delivery of file contents. (Note: This directive can be overridden + on a per-directory basis.)

+ + + +

Process Creation

+ + + +

Prior to Apache 1.3 the MinSpareServers, MaxSpareServers, and StartServers settings all had drastic effects on + benchmark results. In particular, Apache required a "ramp-up" + period in order to reach a number of children sufficient to serve + the load being applied. After the initial spawning of + StartServers children, + only one child per second would be created to satisfy the + MinSpareServers + setting. So a server being accessed by 100 simultaneous + clients, using the default StartServers of 5 would take on + the order 95 seconds to spawn enough children to handle + the load. This works fine in practice on real-life servers, + because they aren't restarted frequently. But does really + poorly on benchmarks which might only run for ten minutes.

+ +

The one-per-second rule was implemented in an effort to + avoid swamping the machine with the startup of new children. If + the machine is busy spawning children it can't service + requests. But it has such a drastic effect on the perceived + performance of Apache that it had to be replaced. As of Apache + 1.3, the code will relax the one-per-second rule. It will spawn + one, wait a second, then spawn two, wait a second, then spawn + four, and it will continue exponentially until it is spawning + 32 children per second. It will stop whenever it satisfies the + MinSpareServers + setting.

+ +

This appears to be responsive enough that it's almost + unnecessary to twiddle the MinSpareServers, MaxSpareServers and StartServers knobs. When more than 4 children are + spawned per second, a message will be emitted to the + ErrorLog. If you + see a lot of these errors then consider tuning these settings. + Use the mod_status output as a guide.

+ +

Related to process creation is process death induced by the + MaxRequestsPerChild + setting. By default this is 0, + which means that there is no limit to the number of requests + handled per child. If your configuration currently has this set + to some very low number, such as 30, you may want to bump this + up significantly. If you are running SunOS or an old version of + Solaris, limit this to 10000 or so because of memory leaks.

+ +

When keep-alives are in use, children will be kept busy + doing nothing waiting for more requests on the already open + connection. The default KeepAliveTimeout of 15 + seconds attempts to minimize this effect. The tradeoff here is + between network bandwidth and server resources. In no event + should you raise this above about 60 seconds, as + most of the benefits are lost.

+ + + +
top
+
+

Compile-Time Configuration Issues

+ + + +

Choosing an MPM

+ + + +

Apache 2.x supports pluggable concurrency models, called + Multi-Processing Modules (MPMs). + When building Apache, you must choose an MPM to use. There + are platform-specific MPMs for some platforms: + beos, mpm_netware, + mpmt_os2, and mpm_winnt. For + general Unix-type systems, there are several MPMs from which + to choose. The choice of MPM can affect the speed and scalability + of the httpd:

+ +
    + +
  • The worker MPM uses multiple child + processes with many threads each. Each thread handles + one connection at a time. Worker generally is a good + choice for high-traffic servers because it has a smaller + memory footprint than the prefork MPM.
  • + +
  • The prefork MPM uses multiple child + processes with one thread each. Each process handles + one connection at a time. On many systems, prefork is + comparable in speed to worker, but it uses more memory. + Prefork's threadless design has advantages over worker + in some situations: it can be used with non-thread-safe + third-party modules, and it is easier to debug on platforms + with poor thread debugging support.
  • + +
+ +

For more information on these and other MPMs, please + see the MPM documentation.

+ + + +

Modules

+ + + +

Since memory usage is such an important consideration in + performance, you should attempt to eliminate modules that you are + not actually using. If you have built the modules as DSOs, eliminating modules is a simple + matter of commenting out the associated LoadModule directive for that module. + This allows you to experiment with removing modules, and seeing + if your site still functions in their absense.

+ +

If, on the other hand, you have modules statically linked + into your Apache binary, you will need to recompile Apache in + order to remove unwanted modules.

+ +

An associated question that arises here is, of course, what + modules you need, and which ones you don't. The answer here + will, of course, vary from one web site to another. However, the + minimal list of modules which you can get by with tends + to include mod_mime, mod_dir, + and mod_log_config. mod_log_config is, + of course, optional, as you can run a web site without log + files. This is, however, not recommended.

+ + + +

Atomic Operations

+ + + +

Some modules, such as mod_cache and + recent development builds of the worker MPM, use APR's + atomic API. This API provides atomic operations that can + be used for lightweight thread synchronization.

+ +

By default, APR implements these operations using the + most efficient mechanism available on each target + OS/CPU platform. Many modern CPUs, for example, have + an instruction that does an atomic compare-and-swap (CAS) + operation in hardware. On some platforms, however, APR + defaults to a slower, mutex-based implementation of the + atomic API in order to ensure compatibility with older + CPU models that lack such instructions. If you are + building Apache for one of these platforms, and you plan + to run only on newer CPUs, you can select a faster atomic + implementation at build time by configuring Apache with + the --enable-nonportable-atomics option:

+ +

+ ./buildconf
+ ./configure --with-mpm=worker --enable-nonportable-atomics=yes +

+ +

The --enable-nonportable-atomics option is + relevant for the following platforms:

+ +
    + +
  • Solaris on SPARC
    + By default, APR uses mutex-based atomics on Solaris/SPARC. + If you configure with --enable-nonportable-atomics, + however, APR generates code that uses a SPARC v8plus opcode for + fast hardware compare-and-swap. If you configure Apache with + this option, the atomic operations will be more efficient + (allowing for lower CPU utilization and higher concurrency), + but the resulting executable will run only on UltraSPARC + chips. +
  • + +
  • Linux on x86
    + By default, APR uses mutex-based atomics on Linux. If you + configure with --enable-nonportable-atomics, + however, APR generates code that uses a 486 opcode for fast + hardware compare-and-swap. This will result in more efficient + atomic operations, but the resulting executable will run only + on 486 and later chips (and not on 386). +
  • + +
+ + + +

mod_status and ExtendedStatus On

+ + + +

If you include mod_status and you also set + ExtendedStatus On when building and running + Apache, then on every request Apache will perform two calls to + gettimeofday(2) (or times(2) + depending on your operating system), and (pre-1.3) several + extra calls to time(2). This is all done so that + the status report contains timing indications. For highest + performance, set ExtendedStatus off (which is the + default).

+ + + +

accept Serialization - multiple sockets

+ + + +

Warning:

+

This section has not been fully updated + to take into account changes made in the 2.x version of the + Apache HTTP Server. Some of the information may still be + relevant, but please use it with care.

+
+ +

This discusses a shortcoming in the Unix socket API. Suppose + your web server uses multiple Listen statements to listen on either multiple + ports or multiple addresses. In order to test each socket + to see if a connection is ready Apache uses + select(2). select(2) indicates that a + socket has zero or at least one connection + waiting on it. Apache's model includes multiple children, and + all the idle ones test for new connections at the same time. A + naive implementation looks something like this (these examples + do not match the code, they're contrived for pedagogical + purposes):

+ +

+ for (;;) {
+ + for (;;) {
+ + fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+ + FD_SET (i, &accept_fds);
+
+ }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+ + if (FD_ISSET (i, &accept_fds)) {
+ + new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+
+ }
+
+ }
+ if (new_connection != -1) break;
+
+ }
+ process the new_connection;
+
+ } +

+ +

But this naive implementation has a serious starvation problem. + Recall that multiple children execute this loop at the same + time, and so multiple children will block at + select when they are in between requests. All + those blocked children will awaken and return from + select when a single request appears on any socket + (the number of children which awaken varies depending on the + operating system and timing issues). They will all then fall + down into the loop and try to accept the + connection. But only one will succeed (assuming there's still + only one connection ready), the rest will be blocked + in accept. This effectively locks those children + into serving requests from that one socket and no other + sockets, and they'll be stuck there until enough new requests + appear on that socket to wake them all up. This starvation + problem was first documented in PR#467. There + are at least two solutions.

+ +

One solution is to make the sockets non-blocking. In this + case the accept won't block the children, and they + will be allowed to continue immediately. But this wastes CPU + time. Suppose you have ten idle children in + select, and one connection arrives. Then nine of + those children will wake up, try to accept the + connection, fail, and loop back into select, + accomplishing nothing. Meanwhile none of those children are + servicing requests that occurred on other sockets until they + get back up to the select again. Overall this + solution does not seem very fruitful unless you have as many + idle CPUs (in a multiprocessor box) as you have idle children, + not a very likely situation.

+ +

Another solution, the one used by Apache, is to serialize + entry into the inner loop. The loop looks like this + (differences highlighted):

+ +

+ for (;;) {
+ + accept_mutex_on ();
+ for (;;) {
+ + fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+ + FD_SET (i, &accept_fds);
+
+ }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+ + if (FD_ISSET (i, &accept_fds)) {
+ + new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+
+ }
+
+ }
+ if (new_connection != -1) break;
+
+ }
+ accept_mutex_off ();
+ process the new_connection;
+
+ } +

+ +

The functions + accept_mutex_on and accept_mutex_off + implement a mutual exclusion semaphore. Only one child can have + the mutex at any time. There are several choices for + implementing these mutexes. The choice is defined in + src/conf.h (pre-1.3) or + src/include/ap_config.h (1.3 or later). Some + architectures do not have any locking choice made, on these + architectures it is unsafe to use multiple + Listen + directives.

+ +

The directive AcceptMutex can be used to + change the selected mutex implementation at run-time.

+ +
+
AcceptMutex flock
+ +
+

This method uses the flock(2) system call to + lock a lock file (located by the LockFile directive).

+
+ +
AcceptMutex fcntl
+ +
+

This method uses the fcntl(2) system call to + lock a lock file (located by the LockFile directive).

+
+ +
AcceptMutex sysvsem
+ +
+

(1.3 or later) This method uses SysV-style semaphores to + implement the mutex. Unfortunately SysV-style semaphores have + some bad side-effects. One is that it's possible Apache will + die without cleaning up the semaphore (see the + ipcs(8) man page). The other is that the + semaphore API allows for a denial of service attack by any + CGIs running under the same uid as the webserver + (i.e., all CGIs, unless you use something like + suexec or cgiwrapper). For these + reasons this method is not used on any architecture except + IRIX (where the previous two are prohibitively expensive + on most IRIX boxes).

+
+ +
AcceptMutex pthread
+ +
+

(1.3 or later) This method uses POSIX mutexes and should + work on any architecture implementing the full POSIX threads + specification, however appears to only work on Solaris (2.5 + or later), and even then only in certain configurations. If + you experiment with this you should watch out for your server + hanging and not responding. Static content only servers may + work just fine.

+
+ +
AcceptMutex posixsem
+ +
+

(2.0 or later) This method uses POSIX semaphores. The + semaphore ownership is not recovered if a thread in the process + holding the mutex segfaults, resulting in a hang of the web + server.

+
+ +
+ +

If your system has another method of serialization which + isn't in the above list then it may be worthwhile adding code + for it to APR.

+ +

Another solution that has been considered but never + implemented is to partially serialize the loop -- that is, let + in a certain number of processes. This would only be of + interest on multiprocessor boxes where it's possible multiple + children could run simultaneously, and the serialization + actually doesn't take advantage of the full bandwidth. This is + a possible area of future investigation, but priority remains + low because highly parallel web servers are not the norm.

+ +

Ideally you should run servers without multiple + Listen + statements if you want the highest performance. + But read on.

+ + + +

accept Serialization - single socket

+ + + +

The above is fine and dandy for multiple socket servers, but + what about single socket servers? In theory they shouldn't + experience any of these same problems because all children can + just block in accept(2) until a connection + arrives, and no starvation results. In practice this hides + almost the same "spinning" behaviour discussed above in the + non-blocking solution. The way that most TCP stacks are + implemented, the kernel actually wakes up all processes blocked + in accept when a single connection arrives. One of + those processes gets the connection and returns to user-space, + the rest spin in the kernel and go back to sleep when they + discover there's no connection for them. This spinning is + hidden from the user-land code, but it's there nonetheless. + This can result in the same load-spiking wasteful behaviour + that a non-blocking solution to the multiple sockets case + can.

+ +

For this reason we have found that many architectures behave + more "nicely" if we serialize even the single socket case. So + this is actually the default in almost all cases. Crude + experiments under Linux (2.0.30 on a dual Pentium pro 166 + w/128Mb RAM) have shown that the serialization of the single + socket case causes less than a 3% decrease in requests per + second over unserialized single-socket. But unserialized + single-socket showed an extra 100ms latency on each request. + This latency is probably a wash on long haul lines, and only an + issue on LANs. If you want to override the single socket + serialization you can define + SINGLE_LISTEN_UNSERIALIZED_ACCEPT and then + single-socket servers will not serialize at all.

+ + + +

Lingering Close

+ + + +

As discussed in + draft-ietf-http-connection-00.txt section 8, in order for + an HTTP server to reliably implement the + protocol it needs to shutdown each direction of the + communication independently (recall that a TCP connection is + bi-directional, each half is independent of the other). This + fact is often overlooked by other servers, but is correctly + implemented in Apache as of 1.2.

+ +

When this feature was added to Apache it caused a flurry of + problems on various versions of Unix because of a + shortsightedness. The TCP specification does not state that the + FIN_WAIT_2 state has a timeout, but it doesn't prohibit it. + On systems without the timeout, Apache 1.2 induces many sockets + stuck forever in the FIN_WAIT_2 state. In many cases this + can be avoided by simply upgrading to the latest TCP/IP patches + supplied by the vendor. In cases where the vendor has never + released patches (i.e., SunOS4 -- although folks with + a source license can patch it themselves) we have decided to + disable this feature.

+ +

There are two ways of accomplishing this. One is the socket + option SO_LINGER. But as fate would have it, this + has never been implemented properly in most TCP/IP stacks. Even + on those stacks with a proper implementation (i.e., + Linux 2.0.31) this method proves to be more expensive (cputime) + than the next solution.

+ +

For the most part, Apache implements this in a function + called lingering_close (in + http_main.c). The function looks roughly like + this:

+ +

+ void lingering_close (int s)
+ {
+ + char junk_buffer[2048];
+
+ /* shutdown the sending side */
+ shutdown (s, 1);
+
+ signal (SIGALRM, lingering_death);
+ alarm (30);
+
+ for (;;) {
+ + select (s for reading, 2 second timeout);
+ if (error) break;
+ if (s is ready for reading) {
+ + if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
+ + break;
+
+ }
+ /* just toss away whatever is here */
+
+ }
+
+ }
+
+ close (s);
+
+ } +

+ +

This naturally adds some expense at the end of a connection, + but it is required for a reliable implementation. As HTTP/1.1 + becomes more prevalent, and all connections are persistent, + this expense will be amortized over more requests. If you want + to play with fire and disable this feature you can define + NO_LINGCLOSE, but this is not recommended at all. + In particular, as HTTP/1.1 pipelined persistent connections + come into use lingering_close is an absolute + necessity (and + pipelined connections are faster, so you want to support + them).

+ + + +

Scoreboard File

+ + + +

Apache's parent and children communicate with each other + through something called the scoreboard. Ideally this should be + implemented in shared memory. For those operating systems that + we either have access to, or have been given detailed ports + for, it typically is implemented using shared memory. The rest + default to using an on-disk file. The on-disk file is not only + slow, but it is unreliable (and less featured). Peruse the + src/main/conf.h file for your architecture and + look for either USE_MMAP_SCOREBOARD or + USE_SHMGET_SCOREBOARD. Defining one of those two + (as well as their companions HAVE_MMAP and + HAVE_SHMGET respectively) enables the supplied + shared memory code. If your system has another type of shared + memory, edit the file src/main/http_main.c and add + the hooks necessary to use it in Apache. (Send us back a patch + too please.)

+ +
Historical note: The Linux port of Apache didn't start to + use shared memory until version 1.2 of Apache. This oversight + resulted in really poor and unreliable behaviour of earlier + versions of Apache on Linux.
+ + + +

DYNAMIC_MODULE_LIMIT

+ + + +

If you have no intention of using dynamically loaded modules + (you probably don't if you're reading this and tuning your + server for every last ounce of performance) then you should add + -DDYNAMIC_MODULE_LIMIT=0 when building your + server. This will save RAM that's allocated only for supporting + dynamically loaded modules.

+ + + +
top
+
+

Appendix: Detailed Analysis of a Trace

+ + + +

Here is a system call trace of Apache 2.0.38 with the worker MPM + on Solaris 8. This trace was collected using:

+ +

+ truss -l -p httpd_child_pid. +

+ +

The -l option tells truss to log the ID of the + LWP (lightweight process--Solaris's form of kernel-level thread) + that invokes each system call.

+ +

Other systems may have different system call tracing utilities + such as strace, ktrace, or par. + They all produce similar output.

+ +

In this trace, a client has requested a 10KB static file + from the httpd. Traces of non-static requests or requests + with content negotiation look wildly different (and quite ugly + in some cases).

+ +
/67:    accept(3, 0x00200BEC, 0x00200C0C, 1) (sleeping...)
+/67:    accept(3, 0x00200BEC, 0x00200C0C, 1)            = 9
+ +

In this trace, the listener thread is running within LWP #67.

+ +
Note the lack of accept(2) serialization. On this + particular platform, the worker MPM uses an unserialized accept by + default unless it is listening on multiple ports.
+ +
/65:    lwp_park(0x00000000, 0)                         = 0
+/67:    lwp_unpark(65, 1)                               = 0
+ +

Upon accepting the connection, the listener thread wakes up + a worker thread to do the request processing. In this trace, + the worker thread that handles the request is mapped to LWP #65.

+ +
/65:    getsockname(9, 0x00200BA4, 0x00200BC4, 1)       = 0
+ +

In order to implement virtual hosts, Apache needs to know + the local socket address used to accept the connection. It + is possible to eliminate this call in many situations (such + as when there are no virtual hosts, or when + Listen directives + are used which do not have wildcard addresses). But + no effort has yet been made to do these optimizations.

+ +
/65:    brk(0x002170E8)                                 = 0
+/65:    brk(0x002190E8)                                 = 0
+ +

The brk(2) calls allocate memory from the heap. + It is rare to see these in a system call trace, because the httpd + uses custom memory allocators (apr_pool and + apr_bucket_alloc) for most request processing. + In this trace, the httpd has just been started, so it must + call malloc(3) to get the blocks of raw memory + with which to create the custom memory allocators.

+ +
/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
+ +

Next, the worker thread puts the connection to the client (file + descriptor 9) in non-blocking mode. The setsockopt(2) + and getsockopt(2) calls are a side-effect of how + Solaris's libc handles fcntl(2) on sockets.

+ +
/65:    read(9, " G E T   / 1 0 k . h t m".., 8000)     = 97
+ +

The worker thread reads the request from the client.

+ +
/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
+ +

This httpd has been configured with Options FollowSymLinks + and AllowOverride None. Thus it doesn't need to + lstat(2) each directory in the path leading up to the + requested file, nor check for .htaccess files. + It simply calls stat(2) to verify that the file: + 1) exists, and 2) is a regular file, not a directory.

+ +
/65:    sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C)      = 10269
+ +

In this example, the httpd is able to send the HTTP response + header and the requested file with a single sendfilev(2) + system call. Sendfile semantics vary among operating systems. On some other + systems, it is necessary to do a write(2) or + writev(2) call to send the headers before calling + sendfile(2).

+ +
/65:    write(4, " 1 2 7 . 0 . 0 . 1   -  ".., 78)      = 78
+ +

This write(2) call records the request in the + access log. Note that one thing missing from this trace is a + time(2) call. Unlike Apache 1.3, Apache 2.x uses + gettimeofday(3) to look up the time. On some operating + systems, like Linux or Solaris, gettimeofday has an + optimized implementation that doesn't require as much overhead + as a typical system call.

+ +
/65:    shutdown(9, 1, 1)                               = 0
+/65:    poll(0xFAF7B980, 1, 2000)                       = 1
+/65:    read(9, 0xFAF7BC20, 512)                        = 0
+/65:    close(9)                                        = 0
+ +

The worker thread does a lingering close of the connection.

+ +
/65:    close(10)                                       = 0
+/65:    lwp_park(0x00000000, 0)         (sleeping...)
+ +

Finally the worker thread closes the file that it has just delivered + and blocks until the listener assigns it another connection.

+ +
/67:    accept(3, 0x001FEB74, 0x001FEB94, 1) (sleeping...)
+ +

Meanwhile, the listener thread is able to accept another connection + as soon as it has dispatched this connection to a worker thread (subject + to some flow-control logic in the worker MPM that throttles the listener + if all the available workers are busy). Though it isn't apparent from + this trace, the next accept(2) can (and usually does, under + high load conditions) occur in parallel with the worker thread's handling + of the just-accepted connection.

+ +
+
+

Available Languages:  en  | + ko  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/perf-tuning.html.ko.euc-kr b/rubbos/app/apache2/manual/misc/perf-tuning.html.ko.euc-kr new file mode 100644 index 00000000..b5443b1e --- /dev/null +++ b/rubbos/app/apache2/manual/misc/perf-tuning.html.ko.euc-kr @@ -0,0 +1,978 @@ + + + +¾ÆÆÄÄ¡ ¼º´ÉÇâ»ó - Apache HTTP Server + + + + + +
<-
+

¾ÆÆÄÄ¡ ¼º´ÉÇâ»ó

+
+

°¡´ÉÇÑ ¾ð¾î:  en  | + ko  | + tr 

+
+
ÀÌ ¹®¼­´Â ÃÖ½ÅÆÇ ¹ø¿ªÀÌ ¾Æ´Õ´Ï´Ù. + ÃÖ±Ù¿¡ º¯°æµÈ ³»¿ëÀº ¿µ¾î ¹®¼­¸¦ Âü°íÇϼ¼¿ä.
+ + +

¾ÆÆÄÄ¡ 2.0Àº ±â´É°ú Æ÷Æð¡´É¼º°ú ¼º´ÉÀÇ ±ÕÇüÀÌ ¸Âµµ·Ï + ¼³°èÇÑ ¹ü¿ë À¥¼­¹öÀÌ´Ù. º¥Ä¡¸¶Å© ±â·ÏÀ» ¼¼¿ì±âÀ§ÇØ ¼³°èÇÏÁö + ¾Ê¾ÒÁö¸¸ ¾ÆÆÄÄ¡ 2.0Àº ½ÇÁ¦ ¸¹Àº °æ¿ì ³ôÀº ¼º´ÉÀ» ³½´Ù.

+ +

¾ÆÆÄÄ¡ 1.3°ú ºñ±³Çؼ­ 2.0 ¹öÀüÀº 󸮷®°ú È®À强(scalability)À» + ³ôÀ̱âÀ§ÇØ ¸¹Àº ÃÖÀûÈ­¸¦ Çß´Ù. ±âº»°ªÀ¸·Î ´ëºÎºÐ ÃÖÀûÈ­ÇÑ + °ªÀ» »ç¿ëÇÑ´Ù. ±×·¯³ª ÄÄÆÄÀϽà ȤÀº ½ÇÇà½Ã ¼³Á¤ÀÌ ¼º´É¿¡ + Å« ¿µÇâÀ» ÁÙ ¼ö ÀÖ´Ù. ÀÌ ¹®¼­´Â ¾ÆÆÄÄ¡ 2.0ÀÇ ¼º´ÉÀ» Çâ»óÇϱâÀ§ÇØ + ¼­¹ö °ü¸®ÀÚ°¡ ¼³Á¤ÇÒ ¼ö ÀÖ´Â ¿É¼ÇÀ» ¼³¸íÇÑ´Ù. ¾î¶² ¼³Á¤ + ¿É¼ÇÀº À¥¼­¹ö°¡ Çϵå¿þ¾î¿Í ¿î¿µÃ¼Á¦ÀÇ ±â´ÉÀ» ´õ Àß È°¿ëÇϵµ·Ï + ÇÏ´Â ¹Ý¸é, ¾î¶² ¿É¼ÇÀº ¼Óµµ¸¦ À§ÇØ ±â´ÉÀ» Èñ»ýÇÑ´Ù.

+ +
+ +
top
+
+

Çϵå¿þ¾î¿Í ¿î¿µÃ¼Á¦¿¡ ´ëÇؼ­

+ + + +

À¥¼­¹ö ¼º´É¿¡ °¡Àå Å« ¿µÇâÀ» ÁÖ´Â °ÍÀº ¸Þ¸ð¸®´Ù. ½º¿ÒÀº + ¿äû´ç Áö¿¬½Ã°£À» »ç¿ëÀÚ°¡ "ÃæºÐÈ÷ ºü¸£´Ù°í" »ý°¢ÇÏÁö ¸øÇÏ°Ô + ´Ã¸®±â¶§¹®¿¡ À¥¼­¹ö´Â ½º¿ÒÀ» ÇÏ¸é ¾ÈµÈ´Ù. ´À·ÁÁö¸é »ç¿ëÀÚ´Â + Á¤ÁöÇÏ°í ´Ù½Ã Á¢¼ÓÇÏ¿© ºÎÇÏ°¡ °è¼Ó Áõ°¡ÇÑ´Ù. MaxClients Áö½Ã¾î¸¦ Á¶ÀýÇÏ¿© + À¥¼­¹ö°¡ ½º¿ÒÀ» ÇÒ Á¤µµ·Î ¸¹Àº ÀÚ½ÄÀ» ¸¸µéÁö¾Êµµ·Ï ÇØ¾ß + ÇÑ´Ù. ¹æ¹ýÀº °£´ÜÇÏ´Ù: top°ú °°Àº µµ±¸¿¡¼­ + ÇÁ·Î¼¼½º ¸ñ·ÏÀ» º¸°í ¾ÆÆÄÄ¡ ÇÁ·Î¼¼½ºÀÇ Æò±Õ ¸Þ¸ð¸® »ç¿ë·®À» + ¾Ë¾Æ³½ÈÄ, Àüü »ç¿ë°¡´ÉÇÑ ¸Þ¸ð¸®¿¡¼­ ´Ù¸¥ ÇÁ·Î¼¼½ºµéÀÌ »ç¿ëÇÒ + °ø°£À» »« °ª¿¡¼­ ³ª´«´Ù.

+ +

³ª¸ÓÁö´Â Æò¹üÇÏ´Ù: ÃæºÐÈ÷ ºü¸¥ CPU, ÃæºÐÈ÷ ºü¸¥ ³×Æ®¿÷Ä«µå, + ÃæºÐÈ÷ ºü¸¥ µð½ºÅ©, ¿©±â¼­ "ÃæºÐÈ÷ ºü¸¥"Àº ½ÇÇèÀ» Çؼ­ °áÁ¤ÇØ¾ß + ÇÑ´Ù.

+ +

¿î¿µÃ¼Á¦´Â º¸Åë °¢ÀÚ ¾Ë¾Æ¼­ ¼±ÅÃÇÒ ÀÏÀÌ´Ù. ±×·¯³ª ÀϹÝÀûÀ¸·Î + À¯¿ëÇÏ´Ù°í ÆǸíµÈ ¸î°¡Áö ÁöħÀÌ ÀÖ´Ù:

+ +
    +
  • +

    ¼±ÅÃÇÑ ¿î¿µÃ¼Á¦ÀÇ ÃֽŠ¾ÈÁ¤ ¹öÀü°ú ÆÐÄ¡¸¦ ½ÇÇàÇÑ´Ù. + ¸¹Àº ¿î¿µÃ¼Á¦ Á¦ÀÛ»ç´Â ÃÖ±Ù TCP ½ºÅðú ¾²·¹µå ¶óÀ̺귯¸®¿¡ + ¸¹Àº ¼ÓµµÇâ»óÀ» Çß´Ù.

    +
  • + +
  • +

    ¿î¿µÃ¼Á¦°¡ sendfile(2) ½Ã½ºÅÛÈ£ÃâÀ» + Áö¿øÇÑ´Ù¸é, À̸¦ »ç¿ëÇϱâÀ§ÇÑ ¹öÀüÀ̳ª ÆÐÄ¡¸¦ ¼³Ä¡ÇÏ¿´´ÂÁö + È®ÀÎÇÑ´Ù. (¿¹¸¦ µé¾î, ¸®´ª½º¶ó¸é 2.4 ÀÌ»ó ¹öÀüÀ» ¶æÇÑ´Ù. + Solaris 8 Ãʱ⠹öÀüÀº ÆÐÄ¡°¡ ÇÊ¿äÇÏ´Ù.) Áö¿øÇÏ´Â ½Ã½ºÅÛÀ̶ó¸é + ¾ÆÆÄÄ¡ 2´Â sendfileÀ» »ç¿ëÇÏ¿© CPU¸¦ ´ú + »ç¿ëÇϸç Á¤Àû ÆÄÀÏÀ» ´õ »¡¸® Àü¼ÛÇÒ ¼ö ÀÕ´Ù.

    +
  • +
+ +
top
+
+

½ÇÇà½Ã ¼³Á¤¿¡ ´ëÇؼ­

+ + + + + +

HostnameLookups¿Í DNS¿¡ ´ëÇØ °í·ÁÇÒ Á¡µé

+ + + +

¾ÆÆÄÄ¡ 1.3 ÀÌÀü¿¡ HostnameLookupsÀÇ ±âº»°ªÀº + OnÀÌ¿´´Ù. ¿äûÀ» ¸¶Ä¡±âÀü¿¡ DNS °Ë»öÀÌ ³¡³ª¾ß + ÇϹǷΠ¿äû¸¶´Ù Áö¿¬ÀÌ »ý°å´Ù. ¾ÆÆÄÄ¡ 1.3¿¡¼­ ÀÌ ¼³Á¤ÀÇ + ±âº»°ªÀÌ Off·Î º¯°æµÇ¾ú´Ù. ·Î±×ÆÄÀÏÀÇ ÁÖ¼Ò¸¦ + È£½ºÆ®¸íÀ¸·Î º¯È¯ÇÏ·Á¸é ¿©·¯ ·Î±×ó¸® ÇÁ·Î±×·¥Áß ÇϳªÀÎ, + ¾ÆÆÄÄ¡¿¡ Æ÷ÇÔµÈ logresolve + ÇÁ·Î±×·¥À» »ç¿ëÇ϶ó.

+ +

·Î±×ó¸® ÀÛ¾÷ÀÌ ¼­¹ö ¼º´É¿¡ ¾Ç¿µÇâÀ» ¹ÌÄ¡¹Ç·Î ½ÇÁ¦ + »ç¿ëÇÏ´Â À¥¼­¹ö°¡ ¾Æ´Ñ ´Ù¸¥ ÄÄÇ»ÅÍ¿¡¼­ ·Î±×ÆÄÀÏÀ» ÈÄó¸®Çϱæ + ¹Ù¶õ´Ù.

+ +

Allow + from domainÀ̳ª Deny from domain + Áö½Ã¾î¸¦ »ç¿ëÇÑ´Ù¸é (Áï, IP ÁÖ¼Ò°¡ ¾Æ´Ñ È£½ºÆ®¸íÀ̳ª µµ¸ÞÀθíÀ» + »ç¿ëÇÑ´Ù¸é) ºÎµæÀÌ Áߺ¹-¿ª DNS °Ë»öÀ» (¿ª°Ë»öÀ» ÇÑÈÄ ¾ÇÀÇ·Î + º¯°æµÇ¾ú´ÂÁö È®ÀÎÇϱâÀ§ÇØ ´Ù½Ã °Ë»ö) ÇØ¾ß ÇÑ´Ù. ±×·¯¹Ç·Î + ¼º´ÉÀ» ³ôÀ̱âÀ§ÇØ ÀÌ·± Áö½Ã¾î¿¡´Â °¡´ÉÇϸé À̸§´ë½Å IP + ÁÖ¼Ò¸¦ »ç¿ëÇÑ´Ù.

+ +

<Location /server-status> ¼½¼Ç µîÀ¸·Î + Áö½Ã¾îÀÇ Àû¿ë¹üÀ§¸¦ Á¦ÇÑÇÒ ¼ö ÀÖÀ½À» ±â¾ïÇ϶ó. ÀÌ °æ¿ì + Á¶°Ç¿¡ ¸Â´Â ¿äû¿¡¸¸ DNS Á¶È¸¸¦ ÇÑ´Ù. ´ÙÀ½Àº + .html°ú .cgi ÆÄÀϸ¸ DNS °Ë»öÀ» + ÇÏ´Â ¿¹Á¦´Ù:

+ +

+ HostnameLookups off
+ <Files ~ "\.(html|cgi)$">
+ + HostnameLookups on
+
+ </Files> +

+ +

±×·¯³ª CGI¿¡¼­ DNS¸íÀÌ ÇÊ¿äÇÒ »ÓÀ̶ó¸é, ÇÊ¿äÇÑ Æ¯Á¤ + CGI¿¡¼­¸¸ gethostbyname È£ÃâÀ» Çϵµ·Ï °í·ÁÇغ¼ + ¼ö ÀÖ´Ù.

+ + + +

FollowSymLinks¿Í SymLinksIfOwnerMatch

+ + + +

URL °ø°£¿¡¼­ Options FollowSymLinks¸¦ + »ç¿ëÇÏÁö¾Ê°í Options SymLinksIfOwnerMatch¸¦ + »ç¿ëÇÏ¸é ¾ÆÆÄÄ¡´Â ½Éº¼¸µÅ©¸¦ °Ë»çÇϱâÀ§ÇØ ½Ã½ºÅÛÈ£ÃâÀ» + Çѹø ´õ ÇØ¾ß ÇÑ´Ù. ÆÄÀϸíÀÇ °¢ ºÎºÐ¸¶´Ù Çѹø¾¿ ´õ È£ÃâÀ» + ÇÑ´Ù. ¿¹¸¦ µé¾î, ¼³Á¤ÀÌ ´ÙÀ½°ú °°°í:

+ +

+ DocumentRoot /www/htdocs
+ <Directory />
+ + Options SymLinksIfOwnerMatch
+
+ </Directory> +

+ +

/index.html URI¿¡ ´ëÇÑ ¿äûÀÌ ÀÖ´Ù°í °¡Á¤ÇÏÀÚ. + ±×·¯¸é ¾ÆÆÄÄ¡´Â /www, /www/htdocs, + /www/htdocs/index.html °¢°¢¿¡ ´ëÇØ + lstat(2)¸¦ È£ÃâÇÑ´Ù. lstats + °á°ú¸¦ ij½ÌÇÏÁö ¾Ê±â¶§¹®¿¡ ¿äûÀÌ µé¾î¿Ã ¶§¸¶´Ù ¸Å¹ø °°Àº + ÀÛ¾÷À» ÇÑ´Ù. ÁøÂ¥ ½Éº¼¸µÅ© º¸¾È °Ë»ç¸¦ ¿øÇÑ´Ù¸é ´ÙÀ½°ú + °°ÀÌ ÇÒ ¼ö ÀÖ´Ù:

+ +

+ DocumentRoot /www/htdocs
+ <Directory />
+ + Options FollowSymLinks
+
+ </Directory>
+
+ <Directory /www/htdocs>
+ + Options -FollowSymLinks +SymLinksIfOwnerMatch
+
+ </Directory> +

+ +

ÀÌ °æ¿ì ÃÖ¼ÒÇÑ DocumentRoot °æ·Î´Â °Ë»çÇÏÁö + ¾Ê´Â´Ù. DocumentRoot ¹Û¿¡ ÀÖ´Â °æ·Î·Î Alias³ª RewriteRuleÀ» »ç¿ëÇÑ + °æ¿ì¿¡µµ À§¿Í ºñ½ÁÇÑ ¼½¼ÇÀÌ ÇÊ¿äÇÏ´Ù. ½Éº¼¸µÅ© º¸¾ÈÀ» + °í·ÁÇÏÁö ¾Ê°í ÃÖ°íÀÇ ¼º´ÉÀ» ¾òÀ¸·Á¸é, + FollowSymLinks¸¦ ¼³Á¤ÇÏ°í, + SymLinksIfOwnerMatch´Â Àý´ë·Î ¾ÈµÈ´Ù.

+ + + +

AllowOverride

+ + + +

URL °ø°£¿¡¼­ overrides¸¦ Çã¿ëÇÑ´Ù¸é (º¸Åë + .htaccess ÆÄÀÏ) ¾ÆÆÄÄ¡´Â ÆÄÀϸíÀÇ °¢ ºÎºÐ¸¶´Ù + .htaccess¸¦ ¿­±æ ½ÃµµÇÑ´Ù. ¿¹¸¦ µé¾î,

+ +

+ DocumentRoot /www/htdocs
+ <Directory />
+ + AllowOverride all
+
+ </Directory> +

+ +

/index.html URI¿¡ ´ëÇÑ ¿äûÀÌ ÀÖ´Ù°í °¡Á¤ÇÏÀÚ. + ¾ÆÆÄÄ¡´Â /.htaccess, /www/.htaccess, + /www/htdocs/.htaccess¸¦ ¿­·Á°í ½ÃµµÇÑ´Ù. + ÇØ°áÃ¥Àº ¾ÕÀÇ Options FollowSymLinks °æ¿ì¿Í + ºñ½ÁÇÏ´Ù. ÃÖ°íÀÇ ¼º´ÉÀ» ¾òÀ¸·Á¸é ÆÄÀϽýºÅÛ¿¡ ´ëÇؼ­ Ç×»ó + AllowOverride NoneÀ» »ç¿ëÇÑ´Ù.

+ + + +

³»¿ëÇù»ó

+ + + +

°¡´ÉÇÏ°í ÁøÂ¥ Á¶±ÝÀÇ ¼º´ÉÇâ»ó¿¡µµ °ü½ÉÀÌ ÀÖ´Ù¸é ³»¿ëÇù»óÀ» + ¸·´Â´Ù. ½ÇÁ¦·Î Çù»óÀÇ À̵æÀº ¼º´ÉÀúÇϺ¸´Ù ÀÛ´Ù. ¼­¹ö¸¦ + ºü¸£°Ô ÇÒ ¼ö ÀÖ´Ù. ´ÙÀ½°ú °°ÀÌ ¿ÍÀϵåÄ«µå¸¦ »ç¿ëÇÏ´Â ´ë½Å:

+ +

+ DirectoryIndex index +

+ +

¿ÏÀüÇÑ ¸ñ·ÏÀ» »ç¿ëÇÑ´Ù:

+ +

+ DirectoryIndex index.cgi index.pl index.shtml index.html +

+ +

°¡Àå ÈçÇÑ °ÍÀ» ¾Õ¿¡ µÐ´Ù.

+ +

¶Ç, µð·ºÅ丮¿¡¼­ ÆÄÀϵéÀ» ã´Â MultiViews + º¸´Ù´Â, ÇÑ ÆÄÀϸ¸ ÀÐÀ¸¸é ÇÊ¿äÇÑ Á¤º¸¸¦ ¾òÀ» ¼ö ÀÖ´Â + type-map ÆÄÀÏÀ» Á÷Á¢ ¸¸µå´Â °ÍÀÌ ´õ ºü¸§À» + ¸í½ÉÇ϶ó.

+ +

»çÀÌÆ®¿¡ ³»¿ëÇù»óÀÌ ÇÊ¿äÇÏ´Ù¸é Çù»óÀ» À§ÇØ Options + MultiViews Áö½Ã¾î¸¦ »ç¿ëÇϱ⺸´Ù type-map + ÆÄÀÏÀ» °í·ÁÇ϶ó. Çù»ó¹æ¹ý¿¡ ´ëÇÑ ÀÚ¼¼ÇÑ ¼³¸í°ú + type-map ÆÄÀÏÀ» ¸¸µå´Â ¹æ¹ýÀº ³»¿ëÇù»ó ¹®¼­¸¦ Âü°íÇ϶ó.

+ + + +

¸Þ¸ð¸®´ëÀÀ (memory-mapping)

+ + + +

¿¹¸¦ µé¾î, server-side-include¸¦ ó¸®ÇÏ´Â µî ¾ÆÆÄÄ¡ + 2.0ÀÌ Àü¼ÛÇÒ ÆÄÀÏÀ» ÀÐÀ»¶§ ¿î¿µÃ¼Á¦°¡ mmap(2) + µîÀ» Áö¿øÇÑ´Ù¸é ÆÄÀÏÀ» ¸Þ¸ð¸®´ëÀÀÇÑ´Ù.

+ +

¿©·¯ Ç÷¡Æû¿¡¼­ ¸Þ¸ð¸®´ëÀÀÀ» ¼º´ÉÀ» Çâ»óÇÑ´Ù. ±×·¯³ª + ¸Þ¸ð¸®´ëÀÀÀÌ ¼­¹öÀÇ ¼º´ÉÀ» ¶³¾îÆ®¸®°í ½ÉÁö¾î ¾ÈÁ¤¼ºÀ» + ÇØÄ¡´Â °æ¿ì°¡ ÀÖ´Ù:

+ +
    +
  • +

    ¾î¶² ¿î¿µÃ¼Á¦¿¡¼­ mmapÀº CPU °³¼ö°¡ + ¸¹¾ÆÁú¶§ read(2) ¸¸Å­ È®À强ÀÌ ÁÁÁö ¾Ê´Ù. + ¿¹¸¦ µé¾î, ´ÙÁßÇÁ·Î¼¼¼­ Solaris ¼­¹ö¿¡¼­ ¾ÆÆÄÄ¡ 2.0Àº + Á¾Á¾ mmapÀ» »ç¿ëÇÏÁö ¾ÊÀ»¶§ ¼­¹ö°¡ ó¸®ÇÑ + ÆÄÀÏÀ» ´õ »¡¸® Àü¼ÛÇÑ´Ù.

    +
  • + +
  • +

    NFS ¸¶¿îÆ®ÇÑ ÆÄÀϽýºÅÛ¿¡ ÀÖ´Â ÆÄÀÏÀ» ¸Þ¸ð¸®´ëÀÀÇÏ´Â + µµÁß¿¡ ´Ù¸¥ NFS Ŭ¶óÀ̾ðÆ®¿¡ ÀÖ´Â ÇÁ·Î¼¼½º°¡ ÆÄÀÏÀ» + Áö¿ì°Å³ª ÆÄÀÏÅ©±â¸¦ ÁÙÀ̸é, À¥¼­¹ö ÇÁ·Î¼¼½º°¡ ´ÙÀ½ + ¹ø¿¡ ¸Þ¸ð¸®´ëÀÀÇÑ ÆÄÀϳ»¿ëÀ» ÀÐÀ»¶§ bus error°¡ ¹ß»ýÇÒ + ¼ö ÀÖ´Ù.

    +
  • +
+ +

À§ÀÇ Á¶°Ç¿¡ ÇØ´çÇϸé Àü¼ÛÇÏ´Â ÆÄÀÏÀ» ¸Þ¸ð¸®´ëÀÀÇÏÁö + ¾Êµµ·Ï EnableMMAP off¸¦ »ç¿ëÇØ¾ß ÇÑ´Ù. (ÁÖÀÇ: + ÀÌ Áö½Ã¾î´Â µð·ºÅ丮º°·Î º¯°æÇÒ ¼ö ÀÖ´Ù.)

+ + + +

Sendfile

+ + + +

¾ÆÆÄÄ¡´Â ¿î¿µÃ¼Á¦°¡ sendfile(2)À» Áö¿øÇϸé + Ä¿³Î sendfileÀ» »ç¿ëÇÏ¿© -- ¿¹¸¦ µé¾î, Á¤Àû ÆÄÀÏÀ» ¼­ºñ½ºÇÒ¶§ + -- Àü¼ÛÇÒ ÆÄÀÏÀ» Á÷Á¢ ÀÐÁö¾ÊÀ» ¼ö ÀÖ´Ù.

+ +

¿©·¯ Ç÷¡Æû¿¡¼­ sendfileÀ» »ç¿ëÇϸé read¿Í send¸¦ µû·Î + ÇÒ ÇÊ¿ä°¡ ¾ø¾î¼­ »¡¶óÁø´Ù. ±×·¯³ª sendfileÀ» »ç¿ëÇϸé + À¥¼­¹öÀÇ ¾ÈÁ¤¼ºÀ» ÇØÄ¡°ÔµÇ´Â °æ¿ì°¡ ÀÖ´Ù:

+ +
    +
  • +

    sendfile Áö¿øÀÌ À߸øµÇ¾ú°í ÄÄÆÄÀÏ ½Ã½ºÅÛÀÌ ÀÌÁ¡À» + ¹ß°ßÇÏÁö ¸øÇÏ´Â Ç÷¡ÆûÀÌ ÀÖ´Ù. ƯÈ÷ ´Ù¸¥ ÄÄÇ»ÅÍ¿¡¼­ + ½ÇÇàÆÄÀÏÀ» ÄÄÆÄÀÏÇÏ¿© sendfile Áö¿øÀÌ À߸øµÈ ÄÄÇ»ÅÍ·Î + °¡Á®¿Â °æ¿ì¿¡ °¡´ÉÇÏ´Ù.

    +
  • +
  • +

    Ä¿³ÎÀº ÀÚ½ÅÀÇ Ä³½¬¸¦ »ç¿ëÇÏ¿© NFS·Î ¸¶¿îÆ®ÇÑ ÆÄÀÏÀ» + ¾ÈÁ¤ÀûÀ¸·Î ¼­ºñ½ºÇÒ ¼ö ¾ø´Â °æ¿ì°¡ ÀÖ´Ù.

    +
  • +
+ +

À§ÀÇ Á¶°Ç¿¡ ÇØ´çÇϸé ÆÄÀÏÀ» sendfile Àü¼ÛÇÏÁö ¾Êµµ·Ï + EnableSendfile off¸¦ »ç¿ëÇØ¾ß ÇÑ´Ù. (ÁÖÀÇ: + ÀÌ Áö½Ã¾î´Â µð·ºÅ丮º°·Î º¯°æÇÒ ¼ö ÀÖ´Ù.)

+ + + +

ÇÁ·Î¼¼½º »ý¼º

+ + + +

¾ÆÆÄÄ¡ 1.3 ÀÌÀü¿¡´Â MinSpareServers, MaxSpareServers, StartServers ¼³Á¤ÀÌ ¸ðµÎ + º¥Ä¡¸¶Å© °á°ú¿¡ Å« ¿µÇâÀ» ¹ÌÃÆ´Ù. ƯÈ÷ ¾ÆÆÄÄ¡´Â ÀÛ¾÷À» + ¼­ºñ½ºÇϱâÀ§ÇØ ÃæºÐÇÑ Àڽļö¿¡ ´Ù´Ù¸¦ ¶§±îÁö "µµ´Þ" ±â°£ÀÌ + ÇÊ¿äÇß´Ù. óÀ½ StartServers°³ ÀÚ½ÄÀ» + ¸¸µçÈÄ, MinSpareServers + ¼³Á¤°ª±îÁö ÃÊ´ç ÀÚ½ÄÀ» Çϳª¾¿ ¸¸µé¾ú´Ù. ±×·¡¼­ StartServers ±âº»°ªÀÌ + 5ÀÎ ¼­¹ö¿¡ Ŭ¶óÀ̾ðÆ® 100°³°¡ µ¿½Ã¿¡ Á¢¼ÓÇϸé + ºÎÇϸ¦ ó¸®Çϱ⿡ ÃæºÐÇÑ ÀÚ½ÄÀ» ¸¸µé±â±îÁö 95ÃÊ°¡ °É·È´Ù. + ÀÚÁÖ Àç½ÃÀÛÇÏÁö ¾Ê´Â ½ÇÁ¦ ¼­¹ö¿¡¼­´Â Àß µ¿ÀÛÇÏÁö¸¸, 10ºÐ°£¸¸ + ½ÇÇàÇÏ´Â º¥Ä¡¸¶Å© °á°ú´Â ¸Å¿ì ³ª»Ú°Ô ³ª¿Â´Ù.

+ +

ÃÊ´ç ÇÑ°³ ±ÔÄ¢Àº ÀÚ½ÄÀ» »õ·Î ½ÃÀÛÇϸ鼭 ¼­¹ö¿¡ ¹«¸®¸¦ + ÁÖÁö ¾ÊÀ¸·Á°í Á¤Çß´Ù. ÄÄÇ»ÅÍ°¡ ÀÚ½ÄÀ» ½ÃÀÛÇÏ´À¶ó ¹Ù»Ú¸é + ¿äûÀ» ¼­ºñ½ºÇÒ ¼ö ¾ø´Ù. ±×·¯³ª ÀÌ ±ÔÄ¢ÀÌ ¾ÆÆÄÄ¡ÀÇ Ã¼°¨ + ¼º´É¿¡ ¾Ç¿µÇâÀ» ÁÖ¾î º¯°æÇÏ¿´´Ù. ¾ÆÆÄÄ¡ 1.3¿¡¼­ ÃÊ´ç ÇÑ°³ + ±ÔÄ¢Àº ¿ÏÈ­µÇ¾ú´Ù. ÄÚµå´Â ÀÚ½Ä ÇÑ°³¸¦ ¸¸µé°í, 1ÃÊ ½¬°í, + µÎ°³¸¦ ¸¸µé°í, 1ÃÊ ½¬°í, ³×°³¸¦ ¸¸µé°í, ÀÌ·± ½ÄÀ¸·Î ÃÊ´ç + ÀÚ½ÄÀ» 32°³ ¸¸µé¶§±îÁö Áö¼ö·Î Áõ°¡ÇÑ´Ù. Àڽļö°¡ MinSpareServers ¼³Á¤¿¡ ´Ù´Ù¸£¸é + Áõ°¡¸¦ Áß´ÜÇÑ´Ù.

+ +

ÀÌ °æ¿ì ¹ÝÀÀ¼Óµµ°¡ »¡¶óÁ®¼­ MinSpareServers, MaxSpareServers, StartServers¸¦ °ÅÀÇ ¼³Á¤ÇÒ ÇÊ¿ä°¡ ¾ø´Ù. ÀÏÃÊ¿¡ + ÀÚ½ÄÀ» 4°³ ÀÌ»ó »ý¼ºÇϸé ErrorLog¿¡ ±â·ÏÇÑ´Ù. ÀÌ·± ¿À·ù¹®ÀÌ + ¸¹ÀÌ º¸À̸é ÀÌ ¼³Á¤µéÀ» Á¶ÀýÇÏ±æ ¹Ù¶õ´Ù. + mod_status °á°ú°¡ µµ¿òÀÌ µÉ °ÍÀÌ´Ù.

+ +

ÇÁ·Î¼¼½º »ý¼º°ú °ü·ÃÇÏ¿© MaxRequestsPerChild ¼³Á¤Àº + ÇÁ·Î¼¼½º¸¦ Á¾·áÇÑ´Ù. ±âº»°ªÀº ÀڽĴç ó¸®ÇÒ ¿äû¼ö¿¡ Á¦ÇÑÀÌ + ¾ø´Ù´Â 0ÀÌ´Ù. ÇöÀç ¼³Á¤ÀÌ 30°ú + °°ÀÌ ¸Å¿ì ÀÛÀº °ªÀ¸·Î ¼³Á¤µÇÀÖ´Ù¸é, °ªÀ» »ó´çÈ÷ ³ôÈú ÇÊ¿ä°¡ + ÀÖ´Ù. SunOS³ª ¿À·¡µÈ Solaris ¹öÀüÀ» »ç¿ëÇÑ´Ù¸é, ¸Þ¸ð¸®À¯Ã⶧¹®¿¡ + ÀÌ °ªÀ» 10000 Á¤µµ·Î ¼³Á¤Ç϶ó.

+ +

¿¬°áÀ¯Áö(keep-alive)¸¦ »ç¿ëÇÑ´Ù¸é ÀڽĵéÀº ÀÌ¹Ì ¿­¸° + ¿¬°á¿¡¼­ Ãß°¡ ¿äûÀ» ±â´Ù¸®¸ç ¾Æ¹«°Íµµ ÇÏÁö¾Ê±â¶§¹®¿¡ °è¼Ó + ¹Ù»Ú´Ù. KeepAliveTimeoutÀÇ + ±âº»°ª 15 ÃÊ´Â ÀÌ·± Çö»óÀ» ÃÖ¼ÒÈ­ÇÑ´Ù. ³×Æ®¿÷ + ´ë¿ªÆø°ú ¼­¹ö ÀÚ¿ø °£ÀÇ ±ÕÇüÀÌ ¸Â°Ô ¼³Á¤ÇÑ´Ù. + ¿¬°áÀ¯ÁöÀÇ ´ëºÎºÐÀÇ ÀÌÁ¡ÀÌ »ç¶óÁö±â¶§¹®¿¡ ¾î¶² °æ¿ì¿¡µµ + ÀÌ °ªÀ» 60 ÃÊ ÀÌ»óÀ¸·Î ¿Ã¸®Áö ¸¶¶ó.

+ + + +
top
+
+

ÄÄÆÄÀϽà ¼³Á¤¿¡ ´ëÇؼ­

+ + + +

MPM ¼±ÅÃ

+ + + +

¾ÆÆÄÄ¡ 2.x´Â ´ÙÁß󸮸ðµâ + (MPMs)À̶ó´Â ±³Ã¼ÇÒ ¼ö ÀÖ´Â µ¿±âÈ­ ¸ðµ¨À» Áö¿øÇÑ´Ù. ¾ÆÆÄÄ¡¸¦ + ÄÄÆÄÀÏÇÒ¶§ MPMÀ» ¼±ÅÃÇØ¾ß ÇÑ´Ù. beos, + mpm_netware, mpmt_os2, + mpm_winnt¿Í °°ÀÌ Æ¯Á¤ Ç÷¡Æû¿¡¼­¸¸ »ç¿ëÇÒ + ¼ö ÀÖ´Â MPMµµ ÀÖ´Ù. ÀϹÝÀûÀÎ À¯´Ð½º·ù ½Ã½ºÅÛÀº ¿©·¯ MPM + Áß¿¡ Çϳª¸¦ ¼±ÅÃÇÒ ¼ö ÀÖ´Ù. À¥¼­¹öÀÇ ¼Óµµ¿Í + È®À强(scalability)Àº ¾î¶² MPMÀ» ¼±ÅÃÇ߳Ŀ¡ ´Þ·È´Ù:

+ +
    + +
  • worker MPMÀº ¿©·¯ ÀÚ½Ä ÇÁ·Î¼¼½º°¡ + °¢°¢ ¿©·¯ ¾²·¹µå¸¦ »ç¿ëÇÑ´Ù. °¢ ¾²·¹µå´Â Çѹø¿¡ ÇÑ ¿¬°áÀ» + ´ã´çÇÑ´Ù. ÀϹÝÀûÀ¸·Î worker´Â prefork MPM º¸´Ù ÀûÀº + ¸Þ¸ð¸®¸¦ »ç¿ëÇϹǷΠÅë½Å·®ÀÌ ¸¹Àº ¼­¹ö¿¡ ÀûÀýÇÏ´Ù.
  • + +
  • prefork MPMÀº ¾²·¹µå°¡ ÇÑ°³ÀÎ ÀÚ½Ä + ÇÁ·Î¼¼½º¸¦ ¿©·¯°³ »ç¿ëÇÑ´Ù. °¢ ÇÁ·Î¼¼½º´Â Çѹø¿¡ ÇÑ + ¿¬°áÀ» ´ã´çÇÑ´Ù. ¿©·¯ ½Ã½ºÅÛ¿¡¼­ preforkÀÇ ¼Óµµ´Â worker¿Í + ºñ½ÁÇÏÁö¸¸, ´õ ¸¹Àº ¸Þ¸ð¸®¸¦ »ç¿ëÇÑ´Ù. ´ÙÀ½°ú °°Àº »óȲ¿¡¼­ + ¾²·¹µå¸¦ »ç¿ëÇÏÁö ¾Ê´Â prefork ¹æ½ÄÀÌ worker¿¡ ºñÇØ + ÀÌÁ¡À» °¡Áø´Ù: ¾²·¹µå¿¡ ¾ÈÀüÇÏÁö (thread-safe) ¾ÊÀº + Á¦»ïÀÚ°¡ ¸¸µç ¸ðµâÀ» »ç¿ëÇÒ ¼ö ÀÖ°í, ¾²·¹µå µð¹ö±ë Áö¿øÀÌ + ºó¾àÇÑ Ç÷¡Æû¿¡¼­ ½±°Ô µð¹ö±ëÇÒ ¼ö ÀÖ´Ù.
  • + +
+ +

ÀÌ MPMµé°ú ´Ù¸¥ MPM¿¡ ´ëÇØ ´õ ÀÚ¼¼ÇÑ Á¤º¸´Â MPM ¹®¼­¸¦ Âü°íÇÏ±æ ¹Ù¶õ´Ù.

+ + + +

¸ðµâ

+ + + +

¸Þ¸ð¸® »ç¿ë·®ÀÌ ¼º´É¿¡¼­ °¡Àå Áß¿äÇÑ ¿äÀÎÀ̱⶧¹®¿¡ + ½ÇÁ¦·Î »ç¿ëÇÏÁö ¾Ê´Â ¸ðµâÀ» Á¦°ÅÇغ¸ÀÚ. ¸ðµâÀ» DSO·Î ÄÄÆÄÀÏÇß´Ù¸é °£´ÜÈ÷ ±× + ¸ðµâ¿¡ ´ëÇÑ LoadModule Áö½Ã¾î¸¦ ÁÖ¼®Ã³¸®Çϸé + µÈ´Ù. ±×·¡¼­ ¸ðµâÀ» Á¦°ÅÇÏ°í ½ÇÇàÇÏ¿© »çÀÌÆ®°¡ ¸ðµâ¾øÀ̵µ + Á¤»óÀûÀ¸·Î µ¿ÀÛÇÏ´ÂÁö »ìÆ캼 ¼ö ÀÖ´Ù.

+ +

¹Ý´ë·Î ¸ðµâÀÌ ¾ÆÆÄÄ¡ ½ÇÇàÆÄÀÏ¿¡ Á¤ÀûÀ¸·Î ¸µÅ©µÇÀÖ´Ù¸é + ¿øÇÏÁö ¾Ê´Â ¸ðµâÀ» Á¦°ÅÇϱâÀ§ÇØ ¾ÆÆÄÄ¡¸¦ ÀçÄÄÆÄÀÏÇØ¾ß + ÇÑ´Ù.

+ +

¿©±â¼­ ´ç¿¬È÷ ¾î¶² ¸ðµâÀ» »ç¿ëÇÏ°í »ç¿ëÇÏÁö ¸»Áö + Àǹ®ÀÌ »ý±ä´Ù. Á¤´äÀº À¥»çÀÌÆ®¸¶´Ù ´Ù¸£´Ù. ±×·¯³ª ¾Æ¸¶µµ + ÃÖ¼ÒÇÑ mod_mime, + mod_dir, mod_log_config + ¸ðµâÀº »ç¿ëÇÒ °ÍÀÌ´Ù. ¹°·Ð À¥»çÀÌÆ®¿¡ ·Î±×ÆÄÀÏÀÌ ÇÊ¿ä¾ø´Ù¸é + mod_log_config´Â ¾ø¾îµµ µÈ´Ù. ±×·¯³ª ÃßõÇÏÁö + ¾Ê´Â´Ù.

+ + + +

Atomic ¸í·É

+ + + +

mod_cache °°Àº ¸ðµâ°ú ÃÖ±Ù °³¹ßÁßÀÎ + worker MPMÀº APRÀÇ atomic API¸¦ »ç¿ëÇÑ´Ù. ÀÌ API´Â °æ·®±Þ + ¾²·¹µå µ¿±âÈ­¸¦ À§ÇÒ atomic ¸í·ÉÀ» Á¦°øÇÑ´Ù.

+ +

±âº»ÀûÀ¸·Î APRÀº °¢ ¿î¿µÃ¼Á¦/CPU Ç÷¡Æû¿¡¼­ °¡Àå È¿À²ÀûÀÎ + ¹æ¹ýÀ» »ç¿ëÇÏ¿© ÀÌ ¸í·ÉÀ» ±¸ÇöÇÑ´Ù. ¿¹¸¦ µé¾î, ¿©·¯ ÃֽŠ+ CPU¿¡´Â Çϵå¿þ¾î·Î atomic compare-and-swap (CAS) ¿¬»êÀ» + ÇÏ´Â ¸í·É¾î°¡ ÀÖ´Ù. ±×·¯³ª ¾î¶² Ç÷¡Æû¿¡¼­ APRÀº ÀÌ·± + ¸í·É¾î°¡ ¾ø´Â ¿À·¡µÈ CPU¿Í ȣȯ¼ºÀ» À§ÇØ ´õ ´À¸° mutex±â¹Ý + ±¸ÇöÀ» ±âº»ÀûÀ¸·Î »ç¿ëÇÑ´Ù. ÀÌ·± Ç÷¡Æû¿¡¼­ ¾ÆÆÄÄ¡¸¦ + ÄÄÆÄÀÏÇÒ¶§ ¾ÆÆÄÄ¡¸¦ ÃֽŠCPU¿¡¼­¸¸ ½ÇÇàÇÒ °èȹÀ̶ó¸é, + ¾ÆÆÄÄ¡¸¦ ±¸¼ºÇÒ¶§ --enable-nonportable-atomics + ¿É¼ÇÀ» »ç¿ëÇÏ¿© ´õ ºü¸¥ atomic ±¸ÇöÀ» ¼±ÅÃÇÒ ¼ö ÀÖ´Ù:

+ +

+ ./buildconf
+ ./configure --with-mpm=worker --enable-nonportable-atomics=yes +

+ +

--enable-nonportable-atomics ¿É¼ÇÀº ´ÙÀ½°ú + °°Àº Ç÷¡Æû¿¡ ¿µÇâÀÌ ÀÖ´Ù:

+ +
    + +
  • SPARC¿¡¼­ Solaris
    + ±âº»ÀûÀ¸·Î APRÀº Solaris/SPARC¿¡¼­ mutex±â¹Ý atomicÀ» + »ç¿ëÇÑ´Ù. ±×·¯³ª ±¸¼ºÇÒ¶§ + --enable-nonportable-atomics¸¦ »ç¿ëÇϸé + APRÀº ºü¸¥ Çϵå¿þ¾î compare-and-swapÀ» À§ÇÑ SPARC + v8plus ¸í·É¾î¸¦ »ç¿ëÇÑ´Ù. ÀÌ ¿É¼ÇÀ» »ç¿ëÇϸé atomic + ¸í·ÉÀÌ ´õ È¿À²ÀûÀÌÁö¸¸ (CPU¸¦ ´ú »ç¿ëÇÏ°í ´õ ³ôÀº + µ¿±âÈ­°¡ °¡´ÉÇÏ´Ù), ÄÄÆÄÀÏÇÑ ½ÇÇàÆÄÀÏÀº UltraSPARC + Ĩ¿¡¼­¸¸ ½ÇÇàÇÒ ¼ö ÀÖ´Ù. +
  • + +
  • Linux on x86
    + ±âº»ÀûÀ¸·Î APRÀº ¸®´ª½º¿¡¼­ mutex±â¹Ý atomicÀ» + »ç¿ëÇÑ´Ù. ±×·¯³ª ±¸¼ºÇÒ¶§ + --enable-nonportable-atomics¸¦ »ç¿ëÇϸé + APRÀº ºü¸¥ Çϵå¿þ¾î compare-and-swapÀ» À§ÇÑ 486 + ¸í·É¾î¸¦ »ç¿ëÇÑ´Ù. ´õ È¿À²ÀûÀÎ atomic ¸í·ÉÀÌ °¡´ÉÇÏÁö¸¸, + ÄÄÆÄÀÏÇÑ ½ÇÇàÆÄÀÏÀº 486 ÀÌ»ó Ĩ¿¡¼­¸¸ (386Àº ¾ÈµÈ´Ù) + ½ÇÇàÇÒ ¼ö ÀÖ´Ù. +
  • + +
+ + + +

mod_status¿Í ExtendedStatus On

+ + + +

¾ÆÆÄÄ¡¸¦ ÄÄÆÄÀÏÇÒ¶§ mod_status¸¦ Æ÷ÇÔÇÏ°í + ½ÇÇàÇÒ¶§ ExtendedStatus OnÀ» ¼³Á¤ÇÏ¸é ¾ÆÆÄÄ¡´Â + ¿äûÀ» ¹ÞÀ»¶§¸¶´Ù gettimeofday(2)(ȤÀº ¿î¿µÃ¼Á¦¿¡ + µû¶ó times(2))¸¦ µÎ¹ø È£ÃâÇÏ°í (1.3 ÀÌÀü¿¡´Â) + time(2)µµ Ãß°¡·Î ¿©·¯¹ø È£ÃâÇÑ´Ù. »óÅ º¸°í¼­¿¡ + µ¿À۽ð£ÀÌ ÇÊ¿äÇϱ⠶§¹®ÀÌ´Ù. ÃÖ»óÀÇ ¼º´ÉÀ» ¾òÀ¸·Á¸é + (±âº»°ªÀÎ) ExtendedStatus off¸¦ ¼³Á¤ÇÑ´Ù.

+ + + +

accept Á÷·ÄÈ­ - ¿©·¯ ¼ÒÄÏ

+ + + +

ÁÖÀÇ:

+

¾Æ·¡ ¹®¼­´Â ¾ÆÆÄÄ¡ À¥¼­¹ö 2.0 ¹öÀü¿¡¼­ º¯°æµÈ ³»¿ëÀ» + ´ã°í ÀÖÁö ¾Ê´Ù. ¾ÆÁ÷µµ À¯È¿ÇÑ Á¤º¸°¡ ÀÖÁö¸¸, ÁÖÀÇÇؼ­ + »ç¿ëÇÏ±æ ¹Ù¶õ´Ù.

+
+ +

À¯´Ð½º ¼ÒÄÏ APIÀÇ ´ÜÁ¡À» ¼³¸íÇÑ´Ù. À¥¼­¹ö°¡ ¿©·¯ Æ÷Æ® + ȤÀº ¿©·¯ ÁÖ¼Ò¸¦ ±â´Ù¸®±âÀ§ÇØ ¿©·¯ ListenÀ» »ç¿ëÇÑ´Ù°í °¡Á¤ÇÏÀÚ. + ¿¬°áÀÌ °¡´ÉÇÑÁö °¢ ¼ÒÄÏÀ» °Ë»çÇϱâÀ§ÇØ ¾ÆÆÄÄ¡´Â + select(2)¸¦ »ç¿ëÇÑ´Ù. select(2)´Â + ¼ÒÄÏ¿¡ ±â´Ù¸®°í ÀÖ´Â ¿¬°áÀÌ ¾ø´ÂÁö ȤÀº ÃÖ¼ÒÇÑ + ÇÑ°³ ÀÖ´ÂÁö ¾Ë·ÁÁØ´Ù. ¾ÆÆÄÄ¡¿¡´Â ¿©·¯ ÀÚ½ÄÀÌ ÀÖ°í, + ½¬°í ÀÖ´Â ¸ðµç ÀÚ½ÄÀº µ¿½Ã¿¡ »õ·Î¿î ¿¬°áÀ» °Ë»çÇÑ´Ù. ¿ø·¡ + ±¸ÇöÀº ´ÙÀ½°ú ºñ½ÁÇÏ´Ù (ÀÌ ¿¹´Â Äڵ忡¼­ °¡Á®¿ÀÁö ¾Ê¾Ò´Ù. + ´ÜÁö ¼³¸íÇϱâÀ§ÇÑ ¿ëµµ·Î ¸¸µé¾ú´Ù.):

+ +

+ for (;;) {
+ + for (;;) {
+ + fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+ + FD_SET (i, &accept_fds);
+
+ }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+ + if (FD_ISSET (i, &accept_fds)) {
+ + new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+
+ }
+
+ }
+ if (new_connection != -1) break;
+
+ }
+ process the new_connection;
+
+ } +

+ +

±×·¯³ª À§ÀÇ ´Ü¼øÇÑ ±¸Çö¿¡´Â ½É°¢ÇÑ °í°¥(starvation) + ¹®Á¦°¡ ÀÖ´Ù. ¿©·¯ ÀÚ½ÄÀÌ µ¿½Ã¿¡ ÀÌ ¹Ýº¹¹®À» ½ÇÇàÇϸé, + ¿äûÀ» ±â´Ù¸®¸ç ¸ðµÎ select¿¡¼­ ¸ØÃá´Ù. À̶§ + ¾î¶² ¼ÒÄÏ¿¡ ¿äûÀÌ Çϳª¶óµµ µé¾î¿À¸é ¸ðµç ÀÚ½ÄÀÌ ±ú¾î³­´Ù + (±ú¾î³ª´Â ÀÚ½ÄÀÇ °³¼ö´Â ¿î¿µÃ¼Á¦¿Í ŸÀֿ̹¡ µû¶ó ´Ù¸£´Ù). + À̵éÀº ¸ðµÎ ¿¬°áÀ» acceptÇÏ±æ ½ÃµµÇÑ´Ù. ±×·¯³ª + (¾ÆÁ÷µµ ÇÑ ¿¬°á¸¸ ´ë±âÁßÀ̶ó¸é) ÇÑ Àڽĸ¸ ¼º°øÇÏ°í, ³ª¸ÓÁö´Â + accept¿¡¼­ ¸ØÃá´Ù. ±×·¯¸é ÀÌ ÀڽĵéÀº + ÇÑ ¼ÒÄÏÀÇ ¿äû¸¸À» ¼­ºñ½ºÇϵµ·Ï ¹­¿©¼­, ±× ¼ÒÄÏÀ¸·Î »õ·Î¿î + ¿äûÀÌ ÃæºÐÈ÷ µé¾î¿Í¼­ ¸ðµç ÀÚ½ÄÀ» ±ú¿ï¶§±îÁö Á¤ÁöÇØÀÖ´Ù. + ÀÌ·± °í°¥ ¹®Á¦´Â PR#467¿¡ + óÀ½ º¸°íµÇ¾ú´Ù. ÃÖ¼ÒÇÑ µÎ°¡Áö ÇØ°áÃ¥ÀÌ ÀÖ´Ù.

+ +

ÇÑ°¡Áö´Â ¼ÒÄÏÀ» ´ë±âÇÏÁö ¾Êµµ·Ï (non-blocking) ¸¸µå´Â + ¹æ¹ýÀÌ´Ù. ÀÌ °æ¿ì ÀÚ½ÄÀÌ accept¸¦ Çصµ ¸ØÃßÁö + ¾Ê°í, Áï½Ã ÁøÇàÇÒ ¼ö ÀÖ´Ù. ±×·¯³ª CPU ½Ã°£À» ³¶ºñÇÑ´Ù. + select¿¡¼­ ½¬´Â ÀÚ½ÄÀÌ 10°³ ÀÖ°í, »õ·Î ¿¬°áÀÌ + ÇÑ°³ µé¾î¿Ô´Ù°í °¡Á¤ÇÏÀÚ. ±×·¯¸é ÀÌ ÀÚ½ÄÁß 9°³´Â ±ú¾î³ª¼­ + ¿¬°áÀ» acceptÇÏ±æ ½ÃµµÇÏ°í ½ÇÆÐÇÏ¸é ¾Æ¹« + Àϵµ ÇÏÁö ¾Ê°í ´Ù½Ã select¸¦ ¹Ýº¹ÇÑ´Ù. ´Ù½Ã + select·Î µ¹¾Æ¿Ã ¶§±îÁö ¾î¶² Àڽĵµ ´Ù¸¥ ¼ÒÄÏ¿¡ + µé¾î¿Â ¿äûÀ» ¼­ºñ½ºÇÏÁö ¾Ê´Â´Ù. (´ÙÁßÇÁ·Î¼¼¼­ ÄÄÇ»ÅÍ¿¡¼­) + ½¬´Â ÀÚ½Ä °³¼ö¸¸Å­ CPU °³¼ö°¡ ÀÖ´Â µå¹® °æ¿ì°¡ ¾Æ´Ï¶ó¸é + ÀÌ ÇØ°áÃ¥Àº º°·Î ÁÁ¾Æº¸ÀÌÁö ¾Ê´Â´Ù.

+ +

´Ù¸¥ ¹æ¹ýÀº ¾ÆÆÄÄ¡°¡ »ç¿ëÇÏ´Â ¹æ¹ýÀ¸·Î ³»ºÎ ¹Ýº¹¹®¿¡ + ÇÑ Àڽĸ¸À» µé¿©º¸³½´Ù. ¹Ýº¹¹®Àº ´ÙÀ½°ú °°´Ù (Â÷À̸¦ + °­Á¶ÇßÀ½):

+ +

+ for (;;) {
+ + accept_mutex_on ();
+ for (;;) {
+ + fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+ + FD_SET (i, &accept_fds);
+
+ }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+ + if (FD_ISSET (i, &accept_fds)) {
+ + new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+
+ }
+
+ }
+ if (new_connection != -1) break;
+
+ }
+ accept_mutex_off ();
+ process the new_connection;
+
+ } +

+ +

accept_mutex_on°ú accept_mutex_off + ÇÔ¼ö´Â mutex ¼¼¸¶Æ÷¾î¸¦ + ±¸ÇöÇÑ´Ù. Çѹø¿¡ ¿ÀÁ÷ ÇÑ Àڽĸ¸ÀÌ mutex¸¦ °¡Áú ¼ö ÀÖ´Ù. + mutex¸¦ ±¸ÇöÇÏ´Â ¹æ¹ýÀº ¿©·¯°¡ÁöÀÌ´Ù. ±¸Çö ¹æ¹ýÀº (1.3 + ÀÌÀü) src/conf.h³ª (1.3°ú ±× ÀÌÈÄ) + src/include/ap_config.h¿¡ Á¤ÀǵÇÀÖ´Ù. ¾î¶² + ¾ÆÅ°ÅØÃÄ´Â Àá±Ý(locking) ¹æ¹ýÀ» ¼±ÅÃÇÏÁö ¾Ê±â¶§¹®¿¡, ÀÌ·± + ¾ÆÅ°ÅØÃÄ¿¡¼­ ¿©·¯ Listen Áö½Ã¾î¸¦ »ç¿ëÇϸé + À§ÇèÇÏ´Ù.

+ +

½ÇÇà½Ã AcceptMutex Áö½Ã¾î¸¦ »ç¿ëÇÏ¿© + mutex ±¸ÇöÀ» º¯°æÇÒ ¼ö ÀÖ´Ù.

+ +
+
AcceptMutex flock
+ +
+

ÀÌ ¹æ¹ýÀº Àá±ÝÆÄÀÏÀ» Àá±×±âÀ§ÇØ flock(2) + ½Ã½ºÅÛÈ£ÃâÀ» »ç¿ëÇÑ´Ù (Àá±ÝÆÄÀÏ À§Ä¡´Â LockFile Áö½Ã¾î·Î ÁöÁ¤).

+
+ +
AcceptMutex fcntl
+ +
+

ÀÌ ¹æ¹ýÀº Àá±ÝÆÄÀÏÀ» Àá±×±âÀ§ÇØ fcntl(2) + ½Ã½ºÅÛÈ£ÃâÀ» »ç¿ëÇÑ´Ù (Àá±ÝÆÄÀÏ À§Ä¡´Â LockFile Áö½Ã¾î·Î ÁöÁ¤).

+
+ +
AcceptMutex sysvsem
+ +
+

(1.3°ú ±× ÀÌÈÄ) ÀÌ ¹æ¹ýÀ» SysV½Ä ¼¼¸¶Æ÷¾î¸¦ »ç¿ëÇÏ¿© + mutex¸¦ ±¸ÇöÇÑ´Ù. ºÒÇàÈ÷µµ SysV½Ä ¼¼¸¶Æ÷¾î´Â ³ª»Û + ºÎÀÛ¿ëÀÌ ÀÖ´Ù. Çϳª´Â ¾ÆÆÄÄ¡°¡ ¼¼¸¶Æ÷¾î¸¦ Á¤¸®ÇÏÁö + ¾Ê°í Á×À» ¼ö ÀÖ´Â Á¡ÀÌ´Ù (ipcs(8) manpage + Âü°í). ´Ù¸¥ Çϳª´Â À¥¼­¹ö¿Í µ¿ÀÏÇÑ uid·Î ½ÇÇàÇÏ´Â + CGI°¡ (Áï, suexec³ª + cgiwrapper¸¦ »ç¿ëÇÏÁö¾Ê´Â ÇÑ ¸ðµç CGI) + ¼¼¸¶Æ÷¾î API¸¦ »ç¿ëÇÏ¿© ¼­ºñ½º°ÅºÎ°ø°ÝÀ» ÇÒ ¼ö ÀÖ´Â + Á¡ÀÌ´Ù. ÀÌ·± ÀÌÀ¯¶§¹®¿¡ IRIX¸¦ Á¦¿ÜÇÑ ¾ÆÅ°ÅØÃÄ¿¡¼­ + ÀÌ ¹æ¹ýÀ» »ç¿ëÇÏÁö ¾Ê´Â´Ù (´ëºÎºÐÀÇ IRIX ÄÄÇ»ÅÍ¿¡¼­ + ¾ÕÀÇ µÎ ¹æ¹ýÀº Áö³ªÄ¡°Ô ¹ö°Ì´Ù).

+
+ +
AcceptMutex pthread
+ +
+

(1.3°ú ±× ÀÌÈÄ) ÀÌ ¹æ¹ýÀº POSIX mutex¸¦ »ç¿ëÇϱ⶧¹®¿¡ + POSIX ¾²·¹µå ±Ô¾àÀ» ¿ÏÀüÈ÷ ±¸ÇöÇÑ ¾ÆÅ°ÅØÃĶó¸é ¸ðµÎ + »ç¿ë°¡´ÉÇÏÁö¸¸, (2.5 ÀÌÈÄ) Solaris¿¡¼­¸¸ ±×°Íµµ ƯÁ¤ + ±¸¼º¿¡¼­¸¸ µ¿ÀÛÇÏ´Â µíÇÏ´Ù. ÀÌ ¹æ¹ýÀ» ½ÃµµÇغ»´Ù¸é + ¼­¹ö°¡ ¸ØÃç¼­ ÀÀ´äÀ» ¾ÈÇÏ´ÂÁö »ìÆìºÁ¾ß ÇÑ´Ù. Á¤Àû + ³»¿ë¸¸ ¼­ºñ½ºÇÏ´Â ¼­¹ö´Â Àß µ¿ÀÛÇÏ´Â °Í °°´Ù.

+
+ +
AcceptMutex posixsem
+ +
+

(2.0°ú ±× ÀÌÈÄ) ÀÌ ¹æ¹ýÀº POSIX ¼¼¸¶Æ÷¾î¸¦ »ç¿ëÇÑ´Ù. + mutex¸¦ °¡Áø ÇÁ·Î¼¼½ºÀÇ ¾²·¹µå°¡ Á״´ٸé(segfault) + ¼¼¸¶Æ÷¾î ¼ÒÀ¯±ÇÀÌ È¸º¹µÇÁö ¾Ê¾Æ¼­ À¥¼­¹ö°¡ ¸ØÃá´Ù.

+
+ +
+ +

½Ã½ºÅÛ¿¡ À§ ¸ñ·Ï¿¡ ¾ø´Â Á÷·ÄÈ­(serialization) ¹æ¹ýÀÌ + ÀÖ´Ù¸é ±× ¹æ¹ýÀ» »ç¿ëÇÏ´Â Äڵ带 APR¿¡ Ãß°¡ÇÒ °¡Ä¡°¡ ÀÖ´Ù.

+ +

°í·Á´Â ÇغÃÁö¸¸ ±¸ÇöÇÏÁö¾ÊÀº ´Ù¸¥ ¹æ¹ýÀº ºÎºÐÀûÀ¸·Î + ¹Ýº¹¹®À» Á÷·ÄÈ­ÇÏ´Â ¹æ¹ýÀÌ´Ù. Áï, ÇÁ·Î¼¼¼­¸¦ ¸î°³¸¸ µé¿©º¸³»´Â + °ÍÀÌ´Ù. ÀÌ ¹æ¹ýÀº ¿©·¯ ÀÚ½ÄÀ» µ¿½Ã¿¡ ½ÇÇàÇÒ ¼ö À־ + Á÷·ÄÈ­¶§¹®¿¡ Àüü ´ë¿ªÆøÀ» È°¿ëÇÏÁö ¸øÇÏ´Â ´ÙÁßÇÁ·Î¼¼¼­ + ÄÄÇ»ÅÍ¿¡¼­¸¸ °ü½ÉÀ» °¡Á®º¼ ¼ö ÀÖ´Ù. ¾ÕÀ¸·Î »ìÆ캼 ºÎºÐÀÌÁö¸¸, + ¸Å¿ì º´·ÄÈ­µÈ À¥¼­¹ö°¡ ÈçÇÏÁö ¾Ê¾Æ¼­ ¿ì¼±¼øÀ§°¡ ³·´Ù.

+ +

ÃÖ»óÀÇ ¼º´ÉÀ» ¾ò±âÀ§Çؼ­´Â ¿©·¯ Listen ¹®À» »ç¿ëÇÏÁö ¾Ê´Â + °ÍÀÌ ÀÌ»óÀûÀÌ´Ù. ±×·¯³ª °è¼Ó ¼³¸íÇÑ´Ù.

+ + + +

accept Á÷·ÄÈ­ - ¼ÒÄÏ ÇÑ°³

+ + + +

¾ÕÀÇ ¼³¸íÀº ´ÙÁß¼ÒÄÏ ¼­¹ö¿¡´Â ÁÁÁö¸¸, ¼ÒÄÏÀÌ ÇÑ°³ÀÎ + ¼­¹ö´Â ¾î¶²°¡? ¿¬°áÀÌ µµÂøÇÒ¶§±îÁö ¸ðµç ÀÚ½ÄÀÌ + accept(2)¿¡¼­ ¸ØÃçÀֱ⶧¹®¿¡ ÀÌ·Ð»ó °°Àº + ¹®Á¦°¡ ¹ß»ýÇÏÁö ¾Ê°í, °í°¥ ¹®Á¦µµ ¾ø´Ù. ±×·¯³ª ½ÇÁ¦·Î´Â + ¾Õ¿¡¼­ ¸»ÇÑ ´ë±âÇÏÁö ¾Ê´Â (non-blocking) ¹æ¹ý¿¡¼­ ¹ß»ýÇÏ´Â + "°øȸÀü(spinning)" Çö»óÀ» °¨Ãß°í ÀÖ´Ù. ´ëºÎºÐÀÇ TCP ½ºÅÃÀº + ¿¬°áÀÌ µµÂøÇϸé Ä¿³ÎÀÌ accept¿¡¼­ ¸ØÃçÀÖ´Â + ¸ðµç ÀÚ½ÄÀ» ±ú¿ìµµ·Ï ±¸ÇöµÇÀÖ´Ù. ÇÁ·Î¼¼½ºÁß ÇÑ°³°¡ ¿¬°áÀ» + ¾ò°í »ç¿ëÀÚ¿µ¿ªÀ¸·Î µ¹¾Æ°¡°í, ³ª¸ÓÁö´Â Ä¿³Î¿¡¼­ °øȸÀüÇÏ¿© + ¿¬°áÀÌ ¾øÀ½À» ¹ß°ßÇÏ¸é ´Ù½Ã ÀáÀ» ÀÜ´Ù. »ç¿ëÀÚ¿µ¿ª Äڵ忡¼­´Â + ÀÌ·± °øȸÀüÀ» ¾Ë ¼ö ¾øÁö¸¸, ºÐ¸íÈ÷ Á¸ÀçÇÑ´Ù. ±×·¡¼­ ´ÙÁß¼ÒÄÏÀÇ + ´ë±âÇÏÁö ¾Ê´Â ¹æ¹ý°ú µ¿ÀÏÇÏ°Ô ºÎÇϸ¦ ³ôÀÌ´Â ºÒÇÊ¿äÇÑ ÇൿÀÌ + ÀϾ´Ù.

+ +

±×·¡¼­ ¿ì¸®´Â ¿©·¯ ¾ÆÅ°ÅØÃÄ¿¡¼­ ¼ÒÄÏÀÌ ÇÑ°³ÀÎ °æ¿ì¿¡µµ + Á÷·ÄÈ­ÇÏ¸é ´õ "Àß" µ¿ÀÛÇÔÀ» ¹ß°ßÇß´Ù. ±×·¡¼­ °ÅÀÇ ´ëºÎºÐÀÇ + °æ¿ì ±âº»ÀûÀ¸·Î Á÷·ÄÈ­¸¦ »ç¿ëÇÑ´Ù. ¸®´ª½º¿¡¼­ (Ä¿³Î 2.0.30, + 128Mb ¸Þ¸ð¸®¿¡ µà¾ó Pentium pro) ½ÇÇèÇÑ °á°ú ¼ÒÄÏ ÇÑ°³¸¦ + Á÷·ÄÈ­Çϸé ÇÏÁö ¾ÊÀº °æ¿ì¿¡ ºñÇØ ÃÊ´ç ¿äûÀÌ 3% ¹Ì¸¸ + ÁÙ¾îµé¾ú´Ù. ±×·¯³ª Á÷·ÄÈ­¸¦ ÇÏÁö ¾ÊÀº °æ¿ì ¿äû´ç 100ms + Áö¿¬ÀÌ ¹ß»ýÇß´Ù. ÀÌ Áö¿¬Àº ¾Æ¸¶µµ LAN¿¡¼­ ¹ß»ýÇÏ´Â ±ä + ¿¬°á¼±¶§¹®ÀÏ °ÍÀÌ´Ù. ¼ÒÄÏÀÌ ÇÑ°³ÀÎ °æ¿ì Á÷·ÄÈ­¸¦ »ç¿ëÇÏÁö + ¾ÊÀ¸·Á¸é SINGLE_LISTEN_UNSERIALIZED_ACCEPT¸¦ + Á¤ÀÇÇÑ´Ù.

+ + + +

Close Áö¿¬(lingering)

+ + + +

+ draft-ietf-http-connection-00.txt 8Àý¿¡¼­ ¼³¸íÇϵíÀÌ + ¾ÈÁ¤ÀûÀÎ À¥¼­¹ö°¡ µÇ·Á¸é, Åë½ÅÀÇ ¾ç ¹æÇâÀ» + µ¶¸³ÀûÀ¸·Î ´ÝÀ» ¼ö ÀÖ¾î¾ß ÇÑ´Ù (TCP ¿¬°áÀº ½Ö¹æÇâÀÌ°í, + ¹æÇâÀº ¼­·Î µ¶¸³ÀûÀÌ´Ù). ÀÌÁ¡À» ´Ù¸¥ ¼­¹ö¿¡¼­´Â ÀÚÁÖ + °£°úÇÏÁö¸¸, ¾ÆÆÄÄ¡´Â 1.2ºÎÅÍ Á¤È®È÷ ±¸ÇöÇØ¿Ô´Ù.

+ +

ÀÌ ±â´ÉÀ» ºÎÁÖÀÇÇÏ°Ô ¾ÆÆÄÄ¡¿¡ Ãß°¡ÇßÀ»¶§ ¿©·¯ À¯´Ð½º + ¹öÀü¿¡¼­ ¸¹Àº ¹®Á¦°¡ ¹ß»ýÇß´Ù. TCP ±Ô¾àÀº + FIN_WAIT_2¿¡ ŸÀӾƿôÀÌ ÀÖ´Ù°í Á¤ÇÏÁö ¾Ê¾ÒÁö¸¸, + ±ÝÁöÇÏÁöµµ ¾Ê¾Ò´Ù. ŸÀӾƿôÀÌ ¾ø´Â ½Ã½ºÅÛ¿¡¼­ ¾ÆÆÄÄ¡ 1.2´Â + ¸¹Àº ¼ÒÄÏÀ» ¿µ¿øÈ÷ FIN_WAIT_2 »óÅ·Π¸¸µé¾ú´Ù. + ¸¹Àº °æ¿ì ÀÌ ¹®Á¦´Â Á¦Àۻ簡 Á¦°øÇÏ´Â ÃֽŠTCP/IP ÆÐÄ¡¸¦ + Àû¿ëÇÏ¿© ÇØ°áÇÒ ¼ö ÀÖ´Ù. ±×·¯³ª Á¦Àۻ簡 ÆÐÄ¡¸¦ ¹ßÇ¥ÇÏÁö + ¾Ê´Â °æ¿ì°¡ (Áï, SunOS4 -- ¼Ò½º ¶óÀ̼±½º°¡ ÀÖ´Â + »ç¶÷Àº Á÷Á¢ ÆÐÄ¡ÇÒ ¼ö ÀÖÁö¸¸) Àֱ⶧¹®¿¡ ÀÌ ±â´ÉÀ» »ç¿ëÇÏÁö + ¾Ê±â·Î °áÁ¤Çß´Ù.

+ +

¹æ¹ýÀº µÎ°¡Áö´Ù. Çϳª´Â ¼ÒÄÏ ¿É¼Ç SO_LINGER¸¦ + »ç¿ëÇÏ´Â ¹æ¹ýÀÌ´Ù. ±×·¯³ª ºÒÇàÈ÷µµ ´ëºÎºÐÀÇ TCP/IP ½ºÅÃÀº + ÀÌ ¿É¼ÇÀ» ¿Ã¹Ù·Î ±¸ÇöÇÏÁö ¾Ê¾Ò´Ù. ¿Ã¹Ù·Î ±¸ÇöÇÑ ½ºÅÿ¡¼­ + Á¶Â÷µµ (Áï, ¸®´ª½º 2.0.31) ÀÌ ¹æ¹ýÀº ´ÙÀ½ ¹æ¹ýº¸´Ù + ´õ cpu¸¦ Àâ¾Æ¸Ô´Â´Ù.

+ +

¾ÆÆÄÄ¡´Â º¸Åë (http_main.c¿¡ ÀÖ´Â) + lingering_close¶ó´Â ÇÔ¼ö¸¦ »ç¿ëÇÑ´Ù. ÀÌ ÇÔ¼ö´Â + ´ëÃæ ´ÙÀ½°ú °°´Ù:

+ +

+ void lingering_close (int s)
+ {
+ + char junk_buffer[2048];
+
+ /* shutdown the sending side */
+ shutdown (s, 1);
+
+ signal (SIGALRM, lingering_death);
+ alarm (30);
+
+ for (;;) {
+ + select (s for reading, 2 second timeout);
+ if (error) break;
+ if (s is ready for reading) {
+ + if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
+ + break;
+
+ }
+ /* just toss away whatever is here */
+
+ }
+
+ }
+
+ close (s);
+
+ } +

+ +

ÀÌ ÄÚµå´Â ¿¬°áÀ» ´ÝÀ»¶§ ´õ CPU¸¦ »ç¿ëÇÏÁö¸¸, ¾ÈÁ¤ÀûÀÎ + ±¸ÇöÀ» À§ÇØ ÇÊ¿äÇÏ´Ù. HTTP/1.1ÀÌ ´õ ³Î¸® ÆÛÁö°í ¸ðµç ¿¬°áÀ» + À¯ÁöÇÑ´Ù¸é(persistent), ¿¬°áÀ» ¹Þ´Â ºñ¿ëÀº ¿©·¯ ¿äûÀ» + ó¸®Çϸ鼭 »ó¼âµÉ °ÍÀÌ´Ù. À§ÇèÇÏ°Ôµµ + NO_LINGCLOSE¸¦ Á¤ÀÇÇÏ¿© ÀÌ ±â´ÉÀ» »ç¿ëÇÏÁö + ¾ÊÀ» ¼ö ÀÖÁö¸¸, Àý´ë·Î ±ÇÇÏÁö ¾Ê´Â´Ù. ƯÈ÷ HTTP/1.1 + ÆÄÀÌÇÁ¶óÀÎ (¿ªÁÖ; ¿¬°áÀ¯Áö »óÅ¿¡¼­ ÀÀ´äÀ» ±â´Ù¸®Áö + ¾Ê°í ¿©·¯ ¿äûÀ» º¸³»´Â ±â¼ú) ¿¬°áÀ¯Áö¿¡´Â + lingering_close°¡ ÇʼöÀûÀÌ´Ù (±×¸®°í + ÆÄÀÌÇÁ¶óÀÎ ¿¬°áÀÌ ´õ ºü¸£±â¶§¹®¿¡ »ç¿ëÇÏ±æ ¹Ù¶ö °ÍÀÌ´Ù).

+ + + +

Scoreboard ÆÄÀÏ

+ + + +

¾ÆÆÄÄ¡ÀÇ ºÎ¸ð¿Í ÀÚ½ÄÀº scoreboard¶ó´Â °ÍÀ» ÅëÇØ ¼­·Î + Åë½ÅÇÑ´Ù. ÀÌ»óÀûÀ¸·Î´Â scoreboard¸¦ °øÀ¯¸Þ¸ð¸®·Î ±¸ÇöÇØ¾ß + ÇÑ´Ù. ¿ì¸® °³¹ßÀÚ°¡ ÇØ´ç ¿î¿µÃ¼Á¦¿¡ Á¢±ÙÇÒ ¼ö Àְųª »ó¼¼ÇÑ + Æ÷Æà °á°ú¸¦ ¹ÞÀº °æ¿ì º¸Åë °øÀ¯¸Þ¸ð¸®¸¦ »ç¿ëÇÏ¿© ±¸ÇöÇÑ´Ù. + ³ª¸ÓÁö´Â µð½ºÅ©¿¡ ÀÖ´Â ÆÄÀÏÀ» »ç¿ëÇÏ¿© ±¸ÇöÇÑ´Ù. µð½ºÅ©¿¡ + ÀÖ´Â ÆÄÀÏÀº ´À¸®°í ½Å·Úµµ°¡ ¶³¾îÁø´Ù (±â´Éµµ ´õ Àû´Ù). + src/main/conf.h ÆÄÀÏ¿¡¼­ »ç¿ëÇÏ´Â ¾ÆÅ°ÅØÃĸ¦ + ã¾Æ¼­ USE_MMAP_SCOREBOARD ȤÀº + USE_SHMGET_SCOREBOARDÀÎÁö È®ÀÎÇÑ´Ù. µÑÁß + Çϳª¸¦ (°¢°¢ ÇÔ²² »ç¿ëÇÒ HAVE_MMAPÀ̳ª + HAVE_SHMGETµµ °°ÀÌ) Á¤ÀÇÇÏ¸é °øÀ¯¸Þ¸ð¸® Äڵ带 + »ç¿ëÇÑ´Ù. ½Ã½ºÅÛÀÌ ´Ù¸¥ Á¾·ùÀÇ °øÀ¯¸Þ¸ð¸®¸¦ »ç¿ëÇÑ´Ù¸é + src/main/http_main.c ÆÄÀÏÀ» ¼öÁ¤ÇÏ¿© ¾ÆÆÄÄ¡¿¡¼­ + °øÀ¯¸Þ¸ð¸®¸¦ »ç¿ëÇÒ ¼ö ÀÖµµ·Ï ÈÅ(hook)À» Ãß°¡Ç϶ó. (¶ÇÇÑ + ÆÐÄ¡¸¦ ¿ì¸®¿¡°Ô º¸³»ÁÖ±æ ¹Ù¶õ´Ù.)

+ +
¿ª»çÀû ¼³¸í: ¾ÆÆÄÄ¡ÀÇ ¸®´ª½º ¹öÀüÀº ¾ÆÆÄÄ¡ 1.2 ¹öÀüºÎÅÍ + °øÀ¯¸Þ¸ð¸®¸¦ »ç¿ëÇϱ⠽ÃÀÛÇß´Ù. ¸®´ª½º¿¡¼­ Ãʱ⠾ÆÆÄÄ¡ + ¹öÀüÀÌ ´À¸®°í ½Å·Úµµ°¡ ¶³¾îÁ³±â ¶§¹®ÀÌ´Ù.
+ + + +

DYNAMIC_MODULE_LIMIT

+ + + +

¸ðµâÀ» µ¿ÀûÀ¸·Î ÀоîµéÀÌÁö ¾Ê´Â´Ù¸é (°¡´ÉÇÑ Á¶±ÝÀÌ¶óµµ + ¼º´ÉÀ» ³ôÀ̱âÀ§ÇØ ÀÌ ±ÛÀ» ÀÐ´Â´Ù¸é ¾Æ¸¶µµ ¸ðµâÀ» µ¿ÀûÀ¸·Î + ÀоîµéÀÌÁö ¾ÊÀ» °ÍÀÌ´Ù), ¼­¹ö¸¦ ÄÄÆÄÀÏÇÒ¶§ + -DDYNAMIC_MODULE_LIMIT=0À» Ãß°¡ÇÑ´Ù. ±×·¯¸é + ¸ðµâÀ» µ¿ÀûÀ¸·Î ÀоîµéÀ̱âÀ§ÇØ ÇÒ´çÇÏ´Â ¸Þ¸ð¸®¸¦ Àý¾àÇÑ´Ù.

+ + + +
top
+
+

ºÎ·Ï: ½Ã½ºÅÛÈ£Ãâ ±â·ÏÀ» ÀÚ¼¼È÷ ºÐ¼®Çϱâ

+ + + +

´ÙÀ½Àº Solaris 8¿¡¼­ worker MPMÀ» »ç¿ëÇÑ ¾ÆÆÄÄ¡ 2.0.38ÀÇ + ½Ã½ºÅÛÈ£Ãâ ±â·Ï(trace)ÀÌ´Ù. ¾Æ·¡ ¸í·É¾î¸¦ »ç¿ëÇÏ¿© ±â·ÏÀ» + ¾ò¾ú´Ù:

+ +

+ truss -l -p httpd_child_pid. +

+ +

-l ¿É¼ÇÀ» »ç¿ëÇϸé truss´Â ½Ã½ºÅÛÈ£ÃâÀ» + ÇÏ´Â LWP (lightweight process, °æ·®±Þ ÇÁ·Î¼¼½º--SolarisÀÇ + Ä¿³Î¼öÁØ ¾²·¹µå) ID¸¦ °°ÀÌ ±â·ÏÇÑ´Ù.

+ +

´Ù¸¥ ½Ã½ºÅÛ¿¡´Â strace, ktrace, + par °°Àº ½Ã½ºÅÛÈ£Ãâ ÃßÀû µµ±¸°¡ ÀÖ´Ù. °á°ú´Â + ºñ½ÁÇÏ´Ù.

+ +

Ŭ¶óÀ̾ðÆ®´Â À¥¼­¹ö¿¡°Ô Å©±â°¡ 10KBÀÎ Á¤Àû ÆÄÀÏÀ» ¿äûÇÑ´Ù. + Á¤ÀûÀÎ ÆÄÀÏÀ» ¿äûÇÏÁö ¾Ê°Å³ª ³»¿ëÇù»óÇÏ´Â ¿äûÀ» ÇÑ °æ¿ì + ±â·ÏÀÌ ¸Å¿ì ´Ù¸£´Ù (¶§·Î´Â ¸Å¿ì ¾Ë¾Æº¸±â Èûµé´Ù).

+ +
/67:    accept(3, 0x00200BEC, 0x00200C0C, 1) (sleeping...)
+/67:    accept(3, 0x00200BEC, 0x00200C0C, 1)            = 9
+ +

À§¿¡¼­ ¿¬°á´ë±â(listener) ¾²·¹µå°¡ LWP #67¿¡¼­ ½ÇÇàµÊÀ» + ¾Ë ¼ö ÀÖ´Ù.

+ +
accept(2) Á÷·ÄÈ­¸¦ »ç¿ëÇÏÁö ¾ÊÀ½À» ÁÖ¸ñÇ϶ó. + ¿©·¯ Æ÷Æ®¸¦ ±â´Ù¸®Áö¾Ê´Â °æ¿ì ÀÌ Ç÷¡ÆûÀÇ worker MPMÀº + ±âº»ÀûÀ¸·Î Á÷·ÄÈ­ÇÏÁö ¾ÊÀº accept¸¦ »ç¿ëÇÑ´Ù.
+ +
/65:    lwp_park(0x00000000, 0)                         = 0
+/67:    lwp_unpark(65, 1)                               = 0
+ +

¿¬°áÀº ¹Þ¾ÆµéÀÌ°í(accept) ¿¬°á´ë±â ¾²·¹µå´Â + worker ¾²·¹µå¸¦ ±ú¿ö¼­ ¿äûÀ» ó¸®ÇÏ°Ô ÇÑ´Ù. ¾Æ·¡ ±â·Ï¿¡¼­ + ¿äûÀ» ó¸®ÇÏ´Â worker ¾²·¹µå°¡ LWP #65ÀÓÀ» ¾Ë ¼ö ÀÖ´Ù.

+ +
/65:    getsockname(9, 0x00200BA4, 0x00200BC4, 1)       = 0
+ +

°¡»óÈ£½ºÆ®¸¦ ±¸ÇöÇϱâÀ§ÇØ ¾ÆÆÄÄ¡´Â ¿¬°áÀ» ¹Þ¾ÆµéÀÎ + Áö¿ª(local) ¼ÒÄÏ ÁÖ¼Ò¸¦ ¾Ë¾Æ¾ß ÇÑ´Ù. (°¡»óÈ£½ºÆ®¸¦ »ç¿ëÇÏÁö + ¾Ê°Å³ª Listen + Áö½Ã¾î¿¡ ¿ÍÀϵåÄ«µå ÁÖ¼Ò¸¦ »ç¿ëÇÏÁö ¾ÊÀº °æ¿ì µî) ¸¹Àº °æ¿ì + ÀÌ È£ÃâÀ» ¾ø¾Ù ¼ö ÀÖ´Ù. ±×·¯³ª ¾ÆÁ÷ ÀÌ·± ÃÖÀûÈ­ ÀÛ¾÷ÀÌ + ¾ÈµÇÀÖ´Ù.

+ +
/65:    brk(0x002170E8)                                 = 0
+/65:    brk(0x002190E8)                                 = 0
+ +

brk(2) È£ÃâÀº Èü(heap)¿¡¼­ ¸Þ¸ð¸®¸¦ ÇÒ´çÇÑ´Ù. + À¥¼­¹ö´Â ´ëºÎºÐÀÇ ¿äû 󸮽à ÀÚü ¸Þ¸ð¸® + ÇÒ´çÀÚ(apr_pool°ú apr_bucket_alloc)¸¦ + »ç¿ëÇϱ⶧¹®¿¡ ½Ã½ºÅÛÈ£Ãâ ±â·Ï¿¡¼­ ÀÌ ½Ã½ºÅÛÈ£ÃâÀ» º¸±â°¡ + µå¹°´Ù. ÀÌ ±â·Ï¿¡¼­ À¥¼­¹ö´Â ½ÃÀÛÇÏÀÚ¸¶ÀÚ ÀÚü ¸Þ¸ð¸® ÇÒ´çÀÚ°¡ + »ç¿ëÇÒ ¸Þ¸ð¸®ºí·ÏÀ» ¾ò±âÀ§ÇØ malloc(3)À» È£ÃâÇÑ´Ù.

+ +
/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
+ +

´ÙÀ½ worker ¾²·¹µå´Â Ŭ¶óÀ̾ðÆ®ÀÇ ¿¬°á(ÆÄÀϱâ¼úÀÚ 9)À» + ´ë±â¾ÈÇÔ(non-blocking) »óÅ·Π¹Ù²Û´Ù. setsockopt(2)¿Í + getsockopt(2) È£ÃâÀº SolarisÀÇ libc°¡ ¼ÒÄÏ¿¡ + ´ëÇÑ fcntl(2)À» ¾î¶»°Ô ó¸®ÇÏ´ÂÁö º¸¿©ÁØ´Ù.

+ +
/65:    read(9, " G E T   / 1 0 k . h t m".., 8000)     = 97
+ +

worker ¾²·¹µå´Â Ŭ¶óÀ̾ðÆ®·Î ºÎÅÍ ¿äûÀ» Àд´Ù.

+ +
/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
+ +

À¥¼­¹ö ¼³Á¤Àº Options FollowSymLinks¿Í + AllowOverride NoneÀÌ´Ù. ±×·¡¼­ ¿äûÇÑ ÆÄÀÏ°æ·ÎÀÇ + °¢ µð·ºÅ丮¿¡ ´ëÇØ lstat(2)Çϰųª + .htaccess ÆÄÀÏÀ» °Ë»çÇÒ ÇÊ¿ä°¡ ¾ø´Ù. ÆÄÀÏÀ» + °Ë»çÇϱâÀ§ÇØ, 1) ÆÄÀÏÀÌ ÀÖ´ÂÁö, 2) µð·ºÅ丮°¡ ¾Æ´Ñ ÀϹÝÆÄÀÏÀÎÁö, + stat(2) È£Ã⸸ ÇÏ¸é µÈ´Ù.

+ +
/65:    sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C)      = 10269
+ +

ÀÌ °æ¿ì À¥¼­¹ö´Â ÇѹøÀÇ sendfilev(2) ½Ã½ºÅÛÈ£Ãâ·Î + HTTP ÀÀ´äÇì´õ¿Í ¿äûÇÑ ÆÄÀÏÀ» Àü¼ÛÇÒ ¼ö ÀÖ´Ù. Sendfile Áö¿ø¿©ºÎ´Â + ¿î¿µÃ¼Á¦¸¶´Ù ´Ù¸£´Ù. ´Ù¸¥ ½Ã½ºÅÛÀ̶ó¸é sendfile(2)À» + È£ÃâÇϱâ Àü¿¡ Çì´õ¸¦ º¸³»±âÀ§ÇØ write(2)³ª + writev(2) È£ÃâÀ» ÇÑ´Ù.

+ +
/65:    write(4, " 1 2 7 . 0 . 0 . 1   -  ".., 78)      = 78
+ +

write(2) È£ÃâÀº Á¢±Ù·Î±×(access log)¿¡ ¿äûÀ» + ±â·ÏÇÑ´Ù. ÀÌ ±â·Ï¿¡ time(2) È£ÃâÀÌ ¾øÀ½À» ÁÖ¸ñÇ϶ó. + ¾ÆÆÄÄ¡ 1.3°ú ´Þ¸® ¾ÆÆÄÄ¡ 2.0Àº ½Ã°£À» ¾Ë±âÀ§ÇØ + gettimeofday(3)¸¦ »ç¿ëÇÑ´Ù. + gettimeofday¸¦ ÃÖÀûÈ­ÇÑ ¸®´ª½º¿Í Solaris °°Àº + ¸î¸î ¿î¿µÃ¼Á¦¿¡¼­´Â ÀϹÝÀûÀÎ ½Ã½ºÅÛÈ£Ã⠺δãÀÌ ¾ø´Ù.

+ +
/65:    shutdown(9, 1, 1)                               = 0
+/65:    poll(0xFAF7B980, 1, 2000)                       = 1
+/65:    read(9, 0xFAF7BC20, 512)                        = 0
+/65:    close(9)                                        = 0
+ +

worker ¾²·¹µå´Â ¿¬°áÀ» Áö¿¬´Ý±â(lingering close)ÇÑ´Ù.

+ +
/65:    close(10)                                       = 0
+/65:    lwp_park(0x00000000, 0)         (sleeping...)
+ +

¸¶Áö¸·À¸·Î worker ¾²·¹µå´Â ¹æ±Ý Àü¼ÛÇÑ ÆÄÀÏÀ» ´Ý°í, + ¿¬°á´ë±â(listener) ¾²·¹µå°¡ ´Ù¸¥ ¿¬°áÀ» ÇÒ´çÇÒ ¶§±îÁö + Á¤ÁöÇÑ´Ù.

+ +
/67:    accept(3, 0x001FEB74, 0x001FEB94, 1) (sleeping...)
+ +

±×µ¿¾È ¿¬°á´ë±â ¾²·¹µå´Â ¿¬°áÀ» (¸ðµç worker°¡ ÀÛ¾÷ÁßÀ̸é + ¿¬°á´ë±â ¾²·¹µå¸¦ ¸ØÃß´Â worker MPMÀÇ È帧Á¦¾î ±â´É¿¡ µû¶ó) + worker ¾²·¹µå¿¡ ÇÒ´çÇÏÀÚ¸¶ÀÚ ´Ù¸¥ ¿¬°áÀ» ¹Þ¾ÆµéÀÏ ¼ö ÀÖ´Ù. + ÀÌ ±â·Ï¿¡´Â ³ª¿ÀÁö ¾ÊÁö¸¸, worker ¾²·¹µå°¡ ¹æ±Ý ¹ÞÀº ¿¬°áÀ» + ó¸®ÇÏ´Â µ¿¾È ´ÙÀ½ accept(2)°¡ (¿äûÀÌ ¸Å¿ì + ¸¹Àº °æ¿ì Ç×»ó) ÀϾ ¼ö ÀÖ´Ù.

+ +
+
+

°¡´ÉÇÑ ¾ð¾î:  en  | + ko  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/perf-tuning.html.tr.utf8 b/rubbos/app/apache2/manual/misc/perf-tuning.html.tr.utf8 new file mode 100644 index 00000000..44b6dba2 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/perf-tuning.html.tr.utf8 @@ -0,0 +1,1100 @@ + + + +Apache’de Başarımın Arttırılması - Apache HTTP Sunucusu + + + + + +
<-
+

Apache’de Başarımın Arttırılması

+
+

Mevcut Diller:  en  | + ko  | + tr 

+
+ + +

Apache 2.x, esneklik, taşınabilirlik ve başarım arasında bir denge + sağlamak üzere tasarlanmış genel amaçlı bir HTTP sunucusudur. Başka + sunucularla kıyaslama denemelerinde öne geçmek üzere tasarlanmamış + olsa da Apache 2.x gerçek yaşamda karşılaşılan pek çok durumda oldukça + yüksek bir başarıma ulaşacak yetenektedir.

+ +

Apache 1.3 ile karşılaştırıldığında 2.x sürümleri toplam veri hızını + ve ölçeklenebilirliği arttırmak için pek çok en iyileme seçeneği + içerir. Bu iyileştirmelerin pek çoğu zaten öntanımlı olarak etkin + olmakla birlikte derleme ve kullanım sırasında başarımı önemli ölçüde + etkileyebilen yapılandırma seçenekleri de mevcuttur. Bu belgede, bir + Apache 2.x kurulumunda sunucu yöneticisinin sunucunun başarımını + arttırmak amacıyla yapılandırma sırasında neler yapabileceğinden + bahsedilmiştir. Bu yapılandırma seçeneklerinden bazıları, httpd’nin + donanımın ve işletim sisteminin olanaklarından daha iyi + yararlanabilmesini sağlarken bir kısmı da daha hızlı bir sunum için + yöneticinin işlevsellikten ödün verebilmesini olanaklı kılar.

+ +
+ +
top
+
+

Donanım ve İşletim Sistemi ile İlgili Konular

+ + + +

HTTP sunucusunun başarımını etkileyen en önemli donanım bellektir + (RAM). Bir HTTP sunucusu asla takaslama yapmamalıdır. Çünkü takaslama, + kullanıcının "yeterince hız" umduğu noktada sunumun gecikmesine sebep + olur. Böyle bir durumda kullanıcılar yüklemeyi durdurup tekrar + başlatma eğilimindedirler; sonuçta yük daha da artar. MaxClients yönergesinin değerini + değiştirerek takaslamaya sebep olabilecek kadar çok çocuk süreç + oluşturulmasını engelleyebilirsiniz ve böyle bir durumda bunu mutlaka + yapmalısınız. Bunun için yapacağınız işlem basittir: top + benzeri bir araç üzerinden çalışan süreçlerinizin bir listesini alıp + Apache süreçlerinizin ortalama büyüklüğünü saptayıp, mevcut bellekten + bir kısmını diğer süreçler için ayırdıktan sonra kalan miktarı bu + değere bölerseniz yönergeye atayacağınız değeri bulmuş olursunuz.

+ +

Donanımın diğer unsurları için kararı siz verin: Daha hızlı işlemci, + daha hızlı ağ kartı, daha hızlı disk; daha hızlının ne kadar hızlı + olacağını deneyimlerinize bağlı olarak tamamen sizin ihtiyaçlarınız + belirler.

+ +

İşletim sistemi seçimi büyük oranda yerel ilgi konusudur. Fakat yine + de, genelde yararlılığı kanıtlanmış bazı kurallar bu seçimde size + yardımcı olabilir:

+ +
    +
  • +

    Seçtiğiniz işletim sisteminin (çekirdeğin) en son kararlı + sürümünü çalıştırın. Bir çok işletim sistemi, son yıllarda TCP + yığıtları ve evre kütüphaneleri ile ilgili belirgin iyileştirmeler + yapmışlar ve yapmaktadırlar.

    +
  • + +
  • +

    İşletim sisteminiz sendfile(2) sistem çağrısını + destekliyorsa bunun etkinleştirilebildiği sürümün kurulu olması + önemlidir. (Örneğin, Linux için bu, Linux 2.4 ve sonraki sürümler + anlamına gelirken, Solaris için Solaris 8’den önceki sürümlerin + yamanması gerektirdiği anlamına gelmektedir.) + sendfile işlevinin desteklendiği sistemlerde Apache 2 + duruk içeriği daha hızlı teslim etmek ve işlemci kullanımını + düşürmek amacıyla bu işlevselliği kullanacaktır.

    +
  • +
+ +
top
+
+

Çalışma Anı Yapılandırması ile İlgili Konular

+ + + + + +

HostnameLookups ve DNS ile ilgili diÄŸer konular

+ + + +

Apache 1.3 öncesinde, HostnameLookups yönergesinin öntanımlı değeri + On idi. İstek yerine getirilmeden önce bir DNS sorgusu + yapılmasını gerektirmesi sebebiyle bu ayarlama her istekte bir + miktar gecikmeye sebep olurdu. Apache 1.3’ten itibaren yönergenin + öntanımlı değeri Off yapılmıştır. Eğer günlük + dosyalarınızda konak isimlerinin bulunmasını isterseniz, Apache ile + birlikte gelen logresolve programını + kullanabileceğiniz gibi günlük raporlarını çözümleyen Apache ile + gelmeyen programlardan herhangi birini de kullanabilirsiniz.

+ +

Günlük dosyaları üzerindeki bu işlemi sunucu makinesi dışında + günlük dosyasının bir kopyası üzerinde yapmanızı öneririz. Aksi + takdirde sunucunuzun başarımı önemli ölçüde etkilenebilir.

+ +

Allow veya + Deny + yönergelerinde IP adresi yerine bir konak veya alan ismi + belirtirseniz, iki DNS sorguluk bir bedel ödersiniz (biri normal, + diğeri IP taklidine karşı ters DNS sorgusu). Başarımı en iyilemek + için bu yönergelerde mümkün olduğunca isim yerine IP adreslerini + kullanınız.

+ +

HostnameLookups + yönergelerinin <Location /server-status> gibi + bölüm yönergelerinin içinde de yer alabileceğini unutmayın. Bu gibi + durumlarda DNS sorguları sadece istek kuralla eşleştiği takdirde + yapılacaktır. Aşağıdaki örnekte .html ve + .cgi dosyalarına yapılan istekler hariç DNS sorguları + iptal edilmektedir:

+ +

+ HostnameLookups off
+ <Files ~ "\.(html|cgi)$">
+ + HostnameLookups on
+
+ </Files> +

+ +

Yine de bazı CGI’lerin DNS isimlerine ihtiyacı olursa bu CGI’lerin + bu ihtiyaçlarına yönelik olarak gethostbyname çağrıları + yapabileceğini gözardı etmeyiniz.

+ + + +

FollowSymLinks ve + SymLinksIfOwnerMatch

+ + + +

URL uzayınızda geçerli olmak üzere bir Options + FollowSymLinks yoksa veya Options + SymLinksIfOwnerMatch yönergeleri varsa, Apache her sembolik + bağın üzerinde bazı sınamalar yapmak için ek bir sistem çağrısından + başka istenen her dosya için de ayrı bir çağrı yapacaktır.

+ +

Örnek:

+ DocumentRoot /siteler/htdocs
+ <Directory />
+ + Options SymLinksIfOwnerMatch
+
+ </Directory> +

+ +

Bu durumda /index.html için bir istek yapıldığında + Apache, /siteler, /siteler/htdocs ve
+ /siteler/htdocs/index.html üzerinde + lstat(2) çağrıları yapacaktır. lstat + sonuçları önbelleğe kaydedilmediğinden bu işlem her istekte + yinelenecektir. Amacınız gerçekten sembolik bağları güvenlik + açısından sınamaksa bunu şöyle yapabilirsiniz:

+ +

+ DocumentRoot /siteler/htdocs
+ <Directory />
+ + Options FollowSymLinks
+
+ </Directory>
+
+ <Directory /sitem/htdocs>
+ + Options -FollowSymLinks +SymLinksIfOwnerMatch
+
+ </Directory> +

+ +

Böylece DocumentRoot altındaki + dosyalar için fazladan bir çağrı yapılmasını engellemiş olursunuz. + Eğer bazı bölümlerde Alias, RewriteRule gibi yönergeler üzerinden belge kök + dizininizin dışında kalan dosya yollarına sahipseniz benzer + işlemleri onlar için de yapmalısınız. Sembolik bağ koruması yapmamak + suretiyle başarımı arttırmak isterseniz, FollowSymLinks + seçeneğini her yerde etkin kılın ve + SymLinksIfOwnerMatch seçeneğini asla + etkinleştirmeyin.

+ + + +

AllowOverride

+ + + +

Genellikle .htaccess dosyaları üzerinden yapıldığı + gibi URL uzayınızda geçersizleştirmelere izin veriyorsanız, Apache + her dosya bileşeni için bu .htaccess dosyalarını açmaya + çalışacaktır.

+ +

Örnek:

+ DocumentRoot /siteler/htdocs
+ <Directory />
+ + AllowOverride all
+
+ </Directory> +

+ +

Bu durumda /index.html sayfasına yapılan bir istek için + Apache, /.htaccess, /siteler/.htaccess ve + /siteler/htdocs/.htaccess dosyalarını açmaya + çalışacaktır. Çözüm Options FollowSymLinks durumunun + benzeridir; başarımı arttırmak için dosya sisteminizin her yerinde + AllowOverride None olsun.

+ + + +

Dil Uzlaşımı

+ + + +

Başarımı son kırıntısına kadar arttırmak istiyorsanız, mümkünse + içerik dili uzlaşımı da yapmayın. Dil uzlaşımından yararlanmak + isterken büyük başarım kayıplarına uğrayabilirsiniz. Böyle bir + durumda sunucunun başarımını arttırmanın tek bir yolu vardır.

+ +

+ DirectoryIndex index +

+ +

Yukarıdaki gibi bir dosya ismi kalıbı kullanmak yerine, aşağıdaki + gibi seçenekleri tam bir liste halinde belirtin:

+ +

+ DirectoryIndex index.cgi index.pl index.shtml index.html +

+ +

Buradaki sıralama öncelik sırasını belirler; yani, + öncelikli olmasını istediğiniz seçeneği listenin başına + yazmalısınız.

+ +

İstenen dosya için MultiViews kullanarak dizini + taratmak yerine, gerekli bilgiyi tek bir dosyadan okutmak suretiyle + başarımı arttırabilirsiniz. Bu amaçla türeşlem + (type-map) dosyaları kullanmanız yeterli olacaktır.

+ +

Sitenizde içerik dili uzlaşımına gerek varsa, bunu Options + MultiViews yönergesi üzerinden değil, türeşlem dosyaları + kullanarak yapmayı deneyin. İçerik dili uzlaşımı ve türeşlem + dosyalarının oluşturulması hakkında daha ayrıntılı bilgi edinmek + için İçerik Uzlaşımı + belgesine bakınız.

+ + + +

Bellek EÅŸlemleri

+ + + +

Apache’nin SSI sayfalarında olduğu gibi teslim edilecek dosyanın + içeriğine bakma gereği duyduğu durumlarda, eğer işletim sistemi + mmap(2) ve benzerlerini destekliyorsa çekirdek normal + olarak dosyayı belleğe kopyalayacaktır.

+ +

Bazı platformlarda bu belleğe eşleme işlemi başarımı arttırsa da + başarımın veya httpd kararlılığının zora girdiği durumlar + olabilmektedir:

+ +
    +
  • +

    Bazı işletim sistemlerinde işlemci sayısı artışına bağlı + olarak, mmap işlevi read(2) kadar iyi + ölçeklenmemiştir. Örneğin, çok işlemcili Solaris sunucularda + mmap iptal edildiği takdirde içeriği sunucu + tarafından işlenen dosyalar üzerinde bazen daha hızlı işlem + yapılabilmektedir.

    +
  • + +
  • +

    Belleğe kopyalanacak dosya NFS üzerinden bağlanan bir dosya + sistemindeyse ve dosya başka bir NFS istemcisi makine tarafından + silinmiş veya dosyanın boyutu değiştirilmişse sunucunuz dosyaya + tekrar erişmeye çalıştığında bir hata alabilecektir.

    +
  • +
+ +

Böyle durumların olasılık dahilinde olduğu kurulumlarda içeriği + sunucu tarafından işlenecek dosyaların belleğe kopyalanmaması için + yapılandırmanıza EnableMMAP off satırını ekleyiniz. + (Dikkat: Bu yönerge dizin seviyesinde geçersizleştirilebilen + yönergelerdendir.)

+ + + +

sendfile

+ + + +

Apache’nin duruk dosyalarda olduğu gibi teslim edilecek dosyanın + içeriğine bakmadığı durumlarda, eğer işletim sistemi + sendfile(2) desteğine sahipse çekirdek normal olarak bu + desteği kullanacaktır.

+ +

Bazı platformlarda sendfile kullanımı, okuma ve yazma + işlemlerinin ayrı ayrı yapılmamasını sağlasa da + sendfile kullanımının httpd kararlılığını bozduğu bazı + durumlar sözkonusudur:

+ +
    +
  • +

    Bazı platformlar derleme sisteminin saptayamadığı bozuk bir + sendfile desteğine sahip olabilir. Özellikle + derleme işleminin başka bir platformda yapılıp + sendfile desteği bozuk bir makineye kurulum + yapıldığı durumlarda bu desteğin bozuk olduğu + saptanamayacaktır.

    +
  • +
  • +

    Çekirdek, NFS üzerinden erişilen ağ dosyalarını kendi önbelleği + üzerinden gerektiği gibi sunamayabilir.

    +
  • +
+ +

Böyle durumların olasılık dahilinde olduğu kurulumlarda içeriğin + sendfile desteğiyle teslim edilmemesi için + yapılandırmanıza EnableSendfile off satırını ekleyiniz. + (Dikkat: Bu yönerge dizin seviyesinde geçersizleştirilebilen + yönergelerdendir.)

+ + + +

Süreç Oluşturma

+ + + +

Apache 1.3 öncesinde MinSpareServers, MaxSpareServers ve StartServers ayarları, başka sunucularla kıyaslama + denemelerinde olağanüstü kötü sonuçlar alınmasına sebep olmaktaydı. + Özellikle uygulanan yükü karşılamaya yetecek sayıda çocuk süreç + oluşturulması aşamasında Apache’nin elde ettiği ivme bunlardan + biriydi. Başlangıçta StartServers yönergesiyle belli sayıda süreç + oluşturulduktan sonra her saniyede bir tane olmak üzere MinSpareServers sayıda çocuk süreç + oluşturulmaktaydı. Örneğin, aynı anda 100 isteğe yanıt vermek için + StartServers + yönergesinin öntanımlı değeri olarak başta 5 süreç + oluşturulduğundan kalan süreçler için 95 saniye geçmesi gerekirdi. + Sık sık yeniden başlatılmadıklarından dolayı gerçek hayatta + sunucuların başına gelen de buydu. Başka sunucularla kıyaslama + denemelerinde ise işlem sadece on dakika sürmekte ve içler acısı + sonuçlar alınmaktaydı.

+ +

Saniyede bir kuralı, sunucunun yeni çocukları oluşturması sırasında + sistemin aşırı meşgul duruma düşmemesi için alınmış bir önlemdi. + Makine çocuk süreç oluşturmakla meşgul edildiği sürece isteklere + yanıt veremeyecektir. Böylesi bir durum Apache’nin başarımını + kötüleştirmekten başka işe yaramayacaktır. Apache 1.3’te saniyede + bir kuralı biraz esnetildi. Yeni gerçeklenimde artık bir süreç + oluşturduktan bir saniye sonra iki süreç, bir saniye sonra dört + süreç oluşturulmakta ve işlem, saniyede 32 çocuk süreç oluşturulur + duruma gelene kadar böyle ivmelenmektedir. Çocuk süreç oluşturma + işlemi MinSpareServers + değerine ulaşılınca durmaktadır.

+ +

Bu, MinSpareServers, + MaxSpareServers ve + StartServers ayarlarıyla + oynamayı neredeyse gereksiz kılacak kadar iyi sonuçlar verecek gibi + görünmektedir. Saniyede 4 çocuktan fazlası oluşturulmaya + başlandığında hata günlüğüne bazı iletiler düşmeye başlar. Bu + iletilerin sayısı çok artarsa bu ayarlarla oynama vakti gelmiş + demektir. Bunun için mod_status çıktısını bir + kılavuz olarak kullanabilirsiniz.

+ +

Süreç oluşturmayla ilgili olarak süreç ölümü MaxRequestsPerChild değeri ile + sağlanır. Bu değer öntanımlı olarak 0 olup, çocuk süreç + başına istek sayısının sınırsız olduğu anlamına gelir. Eğer + yapılandırmanızda bu değeri 30 gibi çok düşük bir + değere ayarlarsanız bunu hemen kaldırmak zorunda kalabilirsiniz. + Sunucunuzu SunOS veya Solaris’in eski bir sürümü üzerinde + çalıştırıyorsanız bellek kaçaklarına sebep olmamak için bu değeri + 10000 ile sınırlayınız.

+ +

Kalıcı bağlantı özelliğini kullanıyorsanız, çocuk süreçler zaten + açık bağlantılardan istek beklemekte olacaklardır. KeepAliveTimeout yönergesinin öntanımlı + değeri 15 saniye olup bu etkiyi en aza indirmeye yönelik + süredir. Burada ağ band genişliği ile sunucu kaynaklarının kullanımı + arasında bir seçim yapmak söz konusudur. Hiçbir şey umurunuzda + değilse + çoğu ayrıcalığın yitirilmesi pahasına bu değeri rahatça + 60 saniyenin üzerine çıkarabilirsiniz.

+ + +
top
+
+

Derleme Sırasında Yapılandırma ile İlgili Konular

+ + +

MPM Seçimi

+ + +

Apache 2.x, Çok Süreçlilik Modülleri + (MPM) adı verilen eklemlenebilir çok görevlilik modellerini + destekler. Apache’yi derlerken bu MPM’lerden birini seçmeniz + gerekir. MPM’lerden bazıları platformlara özeldir: + beos, mpm_netware, + mpmt_os2 ve mpm_winnt. Unix + benzeri sistemler için ise seçebileceğiniz modül sayısı birden + fazladır. MPM seçiminin httpd’nin hızında ve ölçeklenebilirliğinde + bazı etkileri olabilir:

+ +
    + +
  • worker modülü her biri çok evreli çok sayıda + çocuk süreç kullanımını destekler. Her evre aynı anda tek bir + baÄŸlantıya hizmet sunar. Aynı hizmeti daha az bellek harcayarak + vermesi nedeniyle yüksek trafiÄŸe sahip sunucularda + prefork modülüne göre daha iyi bir seçimdir.
  • + +
  • prefork modülü her biri tek bir evreye sahip + çok sayıda çocuk süreç kullanımını destekler. Her süreç aynı anda + tek bir baÄŸlantıya hizmet sunar. ÇoÄŸu sistemde daha hızlı olması + nedeniyle worker modülüne göre daha iyi bir seçim + olarak görünürse de bunu daha fazla bellek kullanarak saÄŸlar. + prefork modülünün evresiz tasarımının + worker modülüne göre bazı yararlı tarafları + vardır: Çok evreli sistemlerde güvenilir olmayan üçüncü parti + modülleri kullanabilir ve evrelerde hata ayıklamanın yetersiz + kaldığı platformlarda hatalarını ayıklamak daha kolaydır.
  • + +
+ +

Bu modüller ve diğerleri hakkında daha ayrıntılı bilgi edinmek için + Çok Süreçlilik Modülleri belgesine + bakınız.

+ + + +

Modüller

+ + + +

Bellek kullanımı başarım konusunda önemli olduğundan gerçekte + kullanmadığınız modülleri elemeye çalışmalısınız. Modülleri birer DSO olarak derlediyseniz LoadModule yönergesinin bulunduğu satırı + açıklama haline getirmeniz modülden kurtulmanız için yeterli + olacaktır. Modülleri bu şekilde kaldırarak onların yokluğunda + sitenizin hala işlevlerini yerine getirdiğini görme şansına da + kavuşmuş olursunuz.

+ +

Ancak, eğer modülleri Apache çalıştırılabilirinin içine + gömmüşseniz istenmeyen modülleri kaldırmak için Apache'yi yeniden + derlemeniz gerekir.

+ +

Bu noktada bir soru akla gelebilir: Hangi modüller gerekli, + hangileri değil? Bu sorunun yanıtı şüphesiz siteden siteye değişir. + Ancak, olmazsa olmaz moüller olarak mod_mime, + mod_dir ve mod_log_config + modüllerini sayabiliriz. Bunlardan mod_log_config + olmadan da bir sitenin çalışabileceğinden hareketle bu modülün + varlığı isteğe bağlı olsa da bu modülü kaldırmanızı önermiyoruz.

+ + + +

Atomik Ä°ÅŸlemler

+ + + +

Worker MPM'nin en son geliştirme sürümleri ve + mod_cache gibi bazı modüller APR'nin atomik API'sini + kullanırlar. Bu API, düşük ayarlı evre eşzamanlamasında atomik + işlemler yapar.

+ +

Öntanımlı olarak, APR bu işlemleri hedef işletim sistemi/işlemci + platformunda kullanılabilecek en verimli mekanizmayı kullanarak + gerçekleştirir. Günümüz işlemcilerinin çoğu, örneğin, bir atomik + karşılaştırma ve takas (CAS) işlemini donanımda gerçekleştirmektedir. + Bazı platformlarda APR'nin atomik işlemler için öntanımlı olarak daha + yavaş olan mutekslere dayalı gerçeklenimi kullanmasının sebebi eski + işlemcilerde bu tür makine kodlarının yokluğudur. Apache'yi bu tür + platformalarda günümüz işlemcileriyde çalıştırmayı düşünüyorsanız + Apache'yi derlemek için yapılandırırken en hızlı atomik işlemin + seçilebilmesi için --enable-nonportable-atomics + seçeneğini kullanın:

+ +

+ ./buildconf
+ ./configure --with-mpm=worker --enable-nonportable-atomics=yes +

+ +

--enable-nonportable-atomics seçeneği şu platformlar + için uygundur:

+ +
    + +
  • SPARC üzerinde Solaris
    + APR öntanımlı olarak, SPARC/Solaris üzerinde mutekslere dayalı + atomik işlemleri kullanır. Ancak, + --enable-nonportable-atomics yapılandırmasını + kullanırsanız, donanım üzerinde hızlı karşılaştırma ve takas + için uygun SPARC v8plus kodunu kullanacak şekilde kod üretilir. + Apache'yi bu seçenekle yapılandırırsanız atomik işlemler daha + verimli olacak fakat derlenen Apache çalıştırılabiliri sadece + UltraSPARC kırmığı üzerinde çalışacaktır. +
  • + +
  • x86 üzerinde Linux
    + APR öntanımlı olarak, Linux üzerinde mutekslere dayalı atomik + işlemleri kullanır. Ancak, + --enable-nonportable-atomics yapılandırmasını + kullanırsanız, donanım üzerinde hızlı karşılaştırma ve takas + için uygun 486 kodunu kullanacak şekilde kod üretilir. Apache'yi + bu seçenekle yapılandırırsanız atomik işlemler daha verimli + olacak fakat derlenen Apache çalıştırılabiliri (386 üzerinde + değil) sadece 486 ve sonrası kırmıklarda çalışacaktır. +
  • + +
+ + + +

mod_status ve ExtendedStatus On +

+ + + +

mod_status modülünü derlemiş ve Apache'yi + yapılandırır ve çalıştırırken ExtendedStatus On satırını + da kullanmışsanız Apache her istek üzerinde + gettimeofday(2) (veya işletim sistemine bağlı olarak + time(2)) çağrısından başka (1.3 öncesinde) fazladan + defalarca time(2) çağrıları yapacaktır. Bu çağrılarla + durum raporununun zamanlama bilgilerini içermesi sağlanır. Başarımı + arttırmak için ExtendedStatus off yapın (zaten öntanımlı + böyledir).

+ + + +

accept dizgilemesi ve çok soketli işlem

+ + + +

Uyarı:

+

Bu bölüm, Apache HTTP sunucusunun 2.x sürümlerinde yapılan + değişikliklere göre tamamen güncellenmemiştir. Bazı bilgiler hala + geçerliyse de lütfen dikkatli kullanınız.

+
+ +

Burada Unix soket arayüzü gerçeklenirken ihmal edilen bir durumdan + bahsedeceğiz. HTTP sunucunuzun çok sayıda adresten çok sayıda portu + dinlemek için çok sayıda Listen yönergesi kullanmakta olduğunu varsayalım. Her + soketi çalıştığını görmek için denerken Apache bağlantı için + select(2) kullanacaktır. select(2) çağrısı + bu soketin üzerinde sıfır veya en azından bir + bağlantının beklemekte olduğu anlamına gelir. Apache'nin modeli çok + sayıda çocuk süreç içerir ve boşta olanların tümünde aynı anda yeni + bağlantılar denenebilir. Gerçekte çalışan kod bu olmasa da meramımızı + anlatmak için kodun şöyle bir şey olduğunu varsayabiliriz:

+ +

+ for (;;) {
+ + for (;;) {
+ + fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+ + FD_SET (i, &accept_fds);
+
+ }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+ + if (FD_ISSET (i, &accept_fds)) {
+ + new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+
+ }
+
+ }
+ if (new_connection != -1) break;
+
+ }
+ process the new_connection;
+
+ } +

+ +

Bu özet gerçeklenim bir takım açlık sorunlarına sebep olur. Bu + döngünün çalışması sırasında aynı anda çok sayıda çocuk süreç yeniden + çağrılır ve istekler arasında kalan çoğu çocuk da select + ile engellenir. Engellenen tüm bu çocuklar soketlerden herhangi biri + üzerinde tek bir istek göründüğünde select tarafından + uyandırılıp işleme sokulmak üzere döndürülürler (uyandırılan çocuk + sayısı işletim sistemine ve zamanlama ayarlarına göre değişiklik + gösterir). Bunların hepsi döngüye katılıp bağlantı kabul etmeye + (accept) çalışırlar. Fakat içlerinden yalnız biri + (sadece bir bağlantı isteğinin mevcut olduğu varsayımıyla) bunu + başarabilir. Kalanının bağlantı kabul etmesi (accept) + engellenir. Bu durum, bu çocukları istekleri başka başka soketlerden + değil mecburen tek bir soketten kabul etmeye kilitler ve bu soket + üzerinde yeni bir istek belirip uyandırılana kadar bu durumda + kalırlar. Bu açlık sorunu ilk olarak PR#467 sayılı raporla + belgelenmiştir. Bu sorunun en az iki çözümü vardır.

+ +

Çözümün biri engellenmeyen soket kullanımıdır. Bu durumda + accept çocukları engellemeyecek ve yapılan bir + bağlantının ardından diğer çocuklar durumları değişmeksizin bağlantı + beklemeye devam edeceklerdir. Fakat bu durum işlemci zamanının boşa + harcanmasına sebep olur. Seçilmiş (select) boşta on + çocuğun olduğunu ve bir bağlantı geldiğini varsayalım. Kalan dokuz + çocuk işine devam edip bağlantı kabul etmeyi (accept) + deneyecek, başarızsız olacak, dönecek başa, tekrar seçilecek + (select) ve böyle hiçbir iş yapmadan dönüp duracaktır. Bu + arada hizmet sunmakta olanlar da işlerini bitirdikten sonra bu + döngüdeki yerlerini alacaklardır. Aynı kutunun içinde boşta bir sürü + işlemciniz (çok işlemcili sistemler) yoksa bu çözüm pek verimli + olmayacaktır.

+ +

Diğer çözüm ise Apache tarafından kullanılan çözüm olup, girdiyi + bir iç döngüde sıraya sokmaktır. Döngü aşağıda örneklenmiştir (farklar + vurgulanmıştır):

+ +

+ for (;;) {
+ + accept_mutex_on ();
+ for (;;) {
+ + fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+ + FD_SET (i, &accept_fds);
+
+ }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+ + if (FD_ISSET (i, &accept_fds)) {
+ + new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+
+ }
+
+ }
+ if (new_connection != -1) break;
+
+ }
+ accept_mutex_off ();
+ process the new_connection;
+
+ } +

+ +

accept_mutex_on ve accept_mutex_off işlevleri bir karşılıklı red + semoforu oluştururlar. Mutekse aynı anda sadece bir çocuk sahip + olabilir. Bu muteksleri gerçeklemek için çeşitli seçenekler vardır. + Seçim, src/conf.h (1.3 öncesi) veya + src/include/ap_config.h (1.3 ve sonrası) dosyasında + tanımlanmıştır. Bazı mimariler bir kilitleme seçeneğine sahip + değildir. Böyle mimarilerde çok sayıda Listen yönergesi kullanmak güvenilir + olmayacaktır.

+ +

AcceptMutex yönergesi, + seçilen muteks gerçeklenimini çalışma anında değiştirmek için + kullanılabilir.

+ +
+
AcceptMutex flock
+ +
+

Bu yöntem, bir kilit dosyasını kilitlemek için + flock(2) sistem çağrısını kullanır (Kilit dosyasının + yeri LockFile + yönergesiyle belirtilir).

+
+ +
AcceptMutex fcntl
+ +
+

Bu yöntem, bir kilit dosyasını kilitlemek için + fcntl(2) sistem çağrısını kullanır (Kilit dosyasının + yeri LockFile + yönergesiyle belirtilir).

+
+ +
AcceptMutex sysvsem
+ +
+

(1.3 ve sonrası) Bu yöntem muteksi gerçeklemek için SysV tarzı + semaforları kullanır. Maalesef, SysV tarzı semaforların bazı yan + etkileri vardır. Bunlardan biri Apache'nin semaforu temizlemeden + ölme ihtimalidir (ipcs(8) kılavuz sayfasına bakınız). + Diğer biri, CGI'lerin sunucu ile aynı kullanıcı kimliğini + kullanmaları nedeniyle semafor arayüzünün hizmet reddi + saldırılarına açık olmasıdır (suexec veya + cgiwrapper gibi bir şeyler kullanmadıkça bütün + CGI'ler için söz konusudur). Bu sebeple bu yöntem IRIX haricinde + hiçbir mimaride kullanılmaz (önceki ikisi çoğu IRIX makine için + elde edilmesi imkansız derecede pahalı olduğundan).

+
+ +
AcceptMutex pthread
+ +
+

(1.3 ve sonrası) Bu yöntem POSIX mutekslerini kullanır ve POSIX + evreleri belirtiminin tamamen gerçeklendiği mimarilerde çalışması + gerekirse de sadece Solaris (2.5 ve sonrası) üzerinde ve sadece + belli yapılandırmalarla çalışmakta gibi görünmektedir. Bunu + denemişseniz sunucunuzun çöktüğünü ve yanıt vermediğini + görmüşsünüzdür. Sadece duruk içerikli sunucular iyi + çalışmaktadır.

+
+ +
AcceptMutex posixsem
+ +
+

(2.0 ve sonrası) Bu yöntem POSIX semaforlarını kullanır. Eğer + işlem sırasında bir evre muteks kaynaklı parçalama arızalarıyla + karşı karşıya kalırsa HTTP sunucusunun çökmesiyle semaforun sahibi + kurtarılamaz.

+
+ +
+ +

Eğer sisteminiz yukarıda bahsedilenler dışında başka bir dizgileme + yöntemi kullanıyorsa bununla ilgili kodun APR'ye eklenmesi girilen + zahmete değecektir.

+ +

Başka bir çözüm daha vardır ancak döngü kısmen dizgilenmeyeceğinden + (yani belli sayıda sürece izin verilemeyeceğinden) asla + gerçeklenmemiştir. Bu sadece, aynı anda çok sayıda çocuk sürecin + çalışabileceği ve dolayısıyla band genişliğinin tüm yönleriyle + kullanılabileceği çok işlemcili sistemlerde ilginç olabilirdi. Bu + gelecekte incelenmeye değer bir konu olmakla beraber çok sayıda HTTP + sunucusunun aynı anda aynı amaca hizmet edecek şekilde çalışması + standart olarak pek mümkün görülmediğinden bu olasılık çok + düşüktür.

+ +

En yüksek başarımı elde etmek için ideal olanı sunucuları + çalıştırırken çok sayıda Listen yönergesi kullanmamaktır. Fakat siz yine de + okumaya devam edin.

+ + + +

accept dizgilemesi - tek soket

+ + + +

Çok soketli sunucular için yukarıda açıklananlar iyi güzel de tek + soketli sunucularda durum ne? Kuramsal olarak, bunların hiçbiriyle bir + sorunları olmaması gerekir. Çünkü yeni bir bağlantı gelene kadar tüm + çocuklar accept(2) ile engellenirler dolayısıyla hiçbir + açlık sorununun ortaya çıkmaması gerekir. Uygulamada ise son + kullanıcıdan gizli olarak, yukarıda engellenmeyen çocuklar çözümünde + bahsedilenle hemen hemen aynı "boşa dönüp durma" davranışı mevcuttur. + Çoğu TCP yığıtı bu yolu gerçeklemiştir. Çekirdek, yeni bir bağlantı + ortaya çıktığında accept ile engellenen tüm süreçleri + uyandırır. Bu süreçlerden bağlantıyı alan kullanıcı bölgesine geçerken + çekirdek içinde döngüde olan diğerleri de yeni bağlantı keşfedilene + kadar uykularına geri dönerler. Bu çekirdek içi döngü, kullanıcı + bölgesindeki kodlara görünür değildir ama bu olmadıkları anlamına + gelmez. Bu durum, çok soketli engellenmeyen çocuklar çözümündeki boşa + döngünün sebep olduğu gereksiz işlemci yükü sorununu içinde + barındırır.

+ +

Bununla birlikte, tek soketli durumda bile bundan daha verimli bir + davranış sergileyen bir çok mimari bulduk. Bu aslında hemen hemen her + durumda öntanımlı olarak böyledir. Linux altında yapılan üstünkörü + denemelerde (128MB bellekli çift Pentium pro 166 işlemcili makinede + Linux 2.0.30) tek sokette dizgilemenin dizgilenmemiş duruma göre + saniyede %3 daha az istekle sonuçlandığı gösterilmiştir. Fakat + dizgilenmemiş tek soket durumunda her istekte 100ms'lik ek bir gecikme + olduğu görülmüştür. Bu gecikmenin sebebi muhtemelen uzun mesafeli + hatlar olup sadece yerel ağlarda söz konusudur. Tek soketli + dizgilemeyi geçersiz kılmak için + SINGLE_LISTEN_UNSERIALIZED_ACCEPT tanımlarsanız tek + soketli sunucularda artık dizgileme yapılmayacaktır.

+ + + +

Kapatmayı zamana yaymak

+ + + +

draft-ietf-http-connection-00.txt taslağının 8. bölümünde + bahsedildiği gibi, bir HTTP sunucusunun protokolü güvenilir + şekilde gerçeklemesi için her iki yöndeki iletişimi + birbirinden bağımsız olarak (iki yönlü bir TCP bağlantısının her + yarısını diğerinden bağımsız olarak) kapatması gerekir. Bu olgu başka + sunucular tarafından çoğunlukla dikkate alınmaz fakat Apache'nin 1.2 + sürümünden beri gerektiği gibi gerçeklenmektedir.

+ +

Bu özellik Apache'ye eklendiğinde Unix'in çeşitli sürümlerinde + uzgörüsüzlükten dolayı bir takım geçici telaş sorunlarına sebep oldu. + TCP belirtimi FIN_WAIT_2 durumunda bir zaman aşımından + bahsetmez ama yasaklamaz da. Zaman aşımı olmayan sistemlerde, Apache + 1.2 çoğu soketin sonsuza kadar FIN_WAIT_2 durumunda + takılıp kalmasına sebep olur. Çoğu durumda, satıcıdan sağlanan en son + TCP/IP yamalarını uygulanarak bu önlenebilir. Satıcının hiçbir yeni + yama dağıtmadığı durumlarda (örneğin, SunOS4 -- bir kaynak lisansı ile + insanlar bunu kendileri yamayabilirse de) bu özelliği devre dışı + bırakmaya karar verdik.

+ +

Bunun üstesinden gelmenin iki yolu vardır. Bunlardan biri + SO_LINGER soket seçeneğidir. Bu işin kaderi buymuş gibi + görünürse de çoğu TCP/IP yığıtında bu gerektiği gibi + gerçeklenmemiştir. Bu yığıtlar üzerinde, bu yöntemin, doğru bir + gerçeklenimle bile (örneğin, Linux 2.0.31) sonraki çözümden daha + pahalı olduğu ortaya çıkmıştır.

+ +

Çoğunlukla, Apache bunu (http_main.c içindeki) + lingering_close adında bir işlevle gerçekler. Bu işlev + kabaca şöyle görünür:

+ +

+ void lingering_close (int s)
+ {
+ + char junk_buffer[2048];
+
+ /* gönderen tarafı kapat */
+ shutdown (s, 1);
+
+ signal (SIGALRM, lingering_death);
+ alarm (30);
+
+ for (;;) {
+ + /* s'i okumak için, 2 saniyelik zaman aşımı ile seç */
+ select (s for reading, 2 second timeout);
+ /* Hata oluşmuşsa döngüden çık */
+ if (error) break;
+ /* s okumak için hazırsa */
+ if (s is ready for reading) {
+ + if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
+ + break;
+
+ }
+ /* geri kalan herÅŸey burada */
+
+ }
+
+ }
+
+ close (s);
+
+ } +

+ +

Bağlantı sonunda bu doğal olarak biraz daha masrafa yol açar, fakat + güvenilir bir gerçeklenim için bu gereklidir. HTTP/1.1'in daha yaygın + kullanılmaya başlanması ve tüm bağlantıların kalıcı hale gelmesiyle bu + gerçeklenim daha fazla istek üzerinden kendi masrafını + karşılayacaktır. Ateşle oynamak ve bu özelliği devre dışı bırakmak + isterseniz NO_LINGCLOSE'u tanımlayabilirsiniz, fakat bu + asla önerilmez. Özellikle, HTTP/1.1'den itibaren boruhatlı kalıcı + bağlantıların lingering_close kullanmaya başlaması mutlak + bir gerekliliktir (ve + boruhatlı bağlantıların daha hızlı olması nedeniyle bu + bağlantıları desteklemek isteyebilirsiniz).

+ + + +

Çetele Dosyası

+ + + +

Apache'nin ana ve alt süreçleri birbirleriyle çetele denen birşey + üzerinden haberleşirler. Bunun en mükemmel şekilde paylaşımlı bellekte + gerçeklenmesi gerekir. Eriştiğimiz veya portlarını ayrıntılı olarak + belirttiğimiz işletim sistemleri için bu, genellikle paylaşımlı bellek + kullanılarak gerçeklenir. Geri kalanlar, öntanımlı olarak bunu bir + disk dosyası kullanarak gerçekler. Bir disk dosyaı yavaş olmanın yanı + sıra güvenilir de değildir (ve daha az özelliğe sahiptir). Mimarinizin + src/main/conf.h dosyasını inceleyin ve + USE_MMAP_SCOREBOARD veya + USE_SHMGET_SCOREBOARD'a bakın. Bu ikisinden birinin (ve + yanı sıra sırasıyla HAVE_MMAP veya + HAVE_SHMGET'in) tanımlanmış olması, sağlanan paylaşımlı + bellek kodunu etkinleştirir. Eğer sisteminiz diğer türdeki paylaşımlı + belleğe sahipse, src/main/http_main.c dosyasını açıp, + Apache'de bu belleği kullanması gereken kanca işlevleri ekleyin (Bize + de bir yama yollayın, lütfen).

+ +
Tarihsel bilgi: Apache'nin Linux uyarlaması, Apache'nin 1.2 + sürümüne kadar paylaşımlı belleği kullanmaya başlamamıştı. Bu kusur, + Apache'nin Linux üzerindeki erken dönem sürümlerinin davranışlarının + zayıf ve güvenilmez olmasına yol açmıştı.
+ + + +

DYNAMIC_MODULE_LIMIT

+ + + +

Devingen olarak yüklenen modülleri kullanmamak niyetindeyseniz + (burayı okuyan ve sunucunuzun başarımını son kırıntısına kadar + arttırmakla ilgilenen biriyseniz bunu düşünmezsiniz), sunucunuzu + derlerken seçenekler arasına -DDYNAMIC_MODULE_LIMIT=0 + seçeneğini de ekleyin. Bu suretle, sadece, devingen olarak yüklenen + modüller için ayrılacak belleği kazanmış olacaksınız.

+ + + +
top
+
+

Ek: Bir çağrı izlemesinin ayrıntılı çözümlemesi

+ + + +

Burada, Solaris 8 üzerinde worker MPM'li Apache 2.0.38'in bir sistem + çağrısı izlenmektedir. Bu izleme şu komutla elde edilmiştir:

+ +

+ truss -l -p httpd_çocuk_pidi. +

+ +

-l seçeneği, truss'a hafif bir sürecin yaptığı her + sistem çağrısını (hafif süreç -- HS -- Solaris'in bir çekirdek seviyesi + evreleme biçimi) günlüğe yazmasını söyler.

+ +

Diğer sistemlerin sistem çağrılarını izleyen farklı araçları vardır + (strace, ktrace, par gibi). + Bunlar da benzer çıktılar üretirler.

+ +

Bu izleme sırasında, bir istemci httpd'den 10 KB'lık duruk bir dosya + talebinde bulunmuştur. Duruk olmayan veya içerik uzlaşımlı isteklerin + izleme kayıtları vahşice (bazı durumlarda epey çirkince) farklı + görünür.

+ +

+ /67: accept(3, 0x00200BEC, 0x00200C0C, 1) (uykuda...)
+ /67: accept(3, 0x00200BEC, 0x00200C0C, 1) = 9 +

+ +

Bu izlemede, dinleyen evre HS #67 içinde çalışmaktadır.

+ +
accept(2) dizgelemesinin olmayışına dikkat edin. + Özellikle bu platformda worker MPM, çok sayıda portu dinlemedikçe, + öntanımlı olarak dizgeleştirilmemiş bir accept çağrısı kullanır.
+ +

+ /65: lwp_park(0x00000000, 0) = 0
+ /67: lwp_unpark(65, 1) = 0 +

+ +

Bağlantının kabul edilmesiyle, dinleyici evre isteği yerine getirmek + üzere bir worker evresini uyandırır. Bu izlemede, isteği yerine getiren + worker evresi HS #65'e aittir.

+ +

+ /65: getsockname(9, 0x00200BA4, 0x00200BC4, 1) = 0 +

+ +

Sanal konakların gerçeklenimi sırasında, Apache'nin, bağlantıları + kabul etmek için kullanılan yerel soket adreslerini bilmesi gerekir. + Çoğu durumda bu çağrıyı bertaraf etmek mümkündür (hiç sanal konağın + olmadığı veya Listen + yönergelerinin mutlak adreslerle kullanıldığı durumlarda). Fakat bu en + iyilemeleri yapmak için henüz bir çaba harcanmamıştır.

+ +

+ /65: brk(0x002170E8) = 0
+ /65: brk(0x002190E8) = 0 +

+ +

brk(2) çağrıları devingen bellekten bellek ayırır. httpd + çoğu isteği yerine getirirken özel bellek ayırıcılar + (apr_pool ve apr_bucket_alloc) kullandığından + bunlar bir sistem çağrısı izlemesinde nadiren görünür. Bu izlemede, + httpd henüz yeni başlatıldığından, özel bellek ayırıcıları oluşturmak + için ham bellek bloklarını ayırmak amacıyla malloc(3) + çağrıları yapması gerekir.

+ +

+/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 +

+ +

Ardından, worker evresi istemciye (dosya tanıtıcısı 9) engellenmeyen + kipte bir bağlantı açar. setsockopt(2) + ve getsockopt(2) çağrıları, Solaris libc'sinin soketler + üzerindeki fcntl(2) çağrısı yanında birer yan etkiden + ibarettirler.

+ +

+ /65: read(9, " G E T / 1 0 k . h t m".., 8000) = 97 +

+ +

Worker evresi istemciden isteÄŸi okur.

+ +

+/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 +

+ +

Bu httpd Options FollowSymLinks ve AllowOverride + None ile yapılandırılmıştır. Bu bakımdan, ne istenen dosya ile + sonuçlanan yol üzerindeki her dizinde lstat(2) çağrısına ne + de .htaccess dosyalarına bakılmasına gerek vardır. + stat(2) çağrısı basitçe dosya için şunları doğrulamak + amacıyla yapılır: 1) dosya mevcuttur ve 2) bir dizin değil normal bir + dosyadır.

+ +

+ /65: sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C) = 10269 +

+ +

Bu örnekte, httpd, istenen dosyayı ve HTTP yanıt başlığını tek bir + sendfilev(2) sistem çağrısı ile göndermektedir. Dosya + gönderim işleminin anlamı sistemden sisteme değişiklik gösterir. Bazı + sistemlerde, sendfile(2) çağrısından önce başlıkları + göndermek için write(2) veya writev(2) + çağrısı yapmak gerekir.

+ +

+ /65: write(4, " 1 2 7 . 0 . 0 . 1 - ".., 78) = 78 +

+ +

Bu write(2) çağrısı isteği erişim günlüğüne kaydeder. Bu + izlemede eksik olan tek şey, time(2) çağrısıdır. Apache + 1.3'ün aksine, Apache 2.x zamana bakmak için + gettimeofday(3) çağırısını kullanır. Linux ve Solaris gibi + bazı işletim sistemleri, gettimeofday işlevinin, sıradan + bir sistem çağrısından daha fazla götürüsü olmayan en iyilenmiş bir + gerçeklenimine sahiptir.

+ +

+ /65: shutdown(9, 1, 1) = 0
+ /65: poll(0xFAF7B980, 1, 2000) = 1
+ /65: read(9, 0xFAF7BC20, 512) = 0
+ /65: close(9) = 0 +

+ +

Burada worker evresi bağlantıyı zamana yaymaktadır.

+ +

+ /65: close(10) = 0
+ /65: lwp_park(0x00000000, 0) (uykuda...) +

+ +

Son olarak, worker evresi teslim edilen dosyayı kapattıktan sonra + dinleyici evre tarafından başka bir bağlantı atanıncaya kadar beklemeye + alınır.

+ +

+ /67: accept(3, 0x001FEB74, 0x001FEB94, 1) (uykuda...) +

+ +

Bu arada, dinleyici evre bağlantıyı bir worker evresine atar atamaz + başka bir bağlantıyı beklemeye başlar (Mevcut tüm evreler meşgulse + dinleyici evreyi baskılayan worker MPM'nin akış denetim şemasına konu + olur). Bu izlemede görünmüyor olsa da sonraki accept(2) + çağrısı, yeni bağlantı kabul eden worker evresine paralel olarak + yapılabilir (aşırı yük durumlarında normal olarak, bu yapılır).

+ +
+
+

Mevcut Diller:  en  | + ko  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/relevant_standards.html b/rubbos/app/apache2/manual/misc/relevant_standards.html new file mode 100644 index 00000000..0890a9e4 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/relevant_standards.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +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/rubbos/app/apache2/manual/misc/relevant_standards.html.en b/rubbos/app/apache2/manual/misc/relevant_standards.html.en new file mode 100644 index 00000000..2924d461 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/relevant_standards.html.en @@ -0,0 +1,199 @@ + + + +Relevant Standards - Apache HTTP Server + + + + + +
<-
+

Relevant Standards

+
+

Available Languages:  en  | + ko 

+
+ +

This page documents all the relevant standards that the + Apache HTTP Server follows, along with brief descriptions.

+ +

In addition to the information listed below, the following resources + should be consulted:

+ + + +

Notice

+

This document is not yet complete.

+
+ +
+ +
top
+
+

HTTP Recommendations

+ +

Regardless of what modules are compiled and used, Apache as a + basic web server complies with the following IETF recommendations:

+ +
+
RFC 1945 + (Informational)
+ +
The Hypertext Transfer Protocol (HTTP) is an application-level + protocol with the lightness and speed necessary for distributed, + collaborative, hypermedia information systems. This documents + HTTP/1.0.
+ +
RFC 2616 + (Standards Track)
+ +
The Hypertext Transfer Protocol (HTTP) is an + application-level protocol for distributed, collaborative, + hypermedia information systems. This documents HTTP/1.1.
+ +
RFC 2396 + (Standards Track)
+ +
A Uniform Resource Identifier (URI) is a compact string of + characters for identifying an abstract or physical resource.
+
+ +
top
+
+

HTML Recommendations

+ +

Regarding the Hypertext Markup Language, Apache complies with + the following IETF and W3C recommendations:

+ +
+
RFC 2854 + (Informational)
+ +
This document summarizes the history of HTML development, + and defines the "text/html" MIME type by pointing to the relevant + W3C recommendations.
+ +
HTML 4.01 Specification + (Errata) +
+ +
This specification defines the HyperText Markup Language (HTML), + the publishing language of the World Wide Web. This specification + defines HTML 4.01, which is a subversion of HTML 4.
+ +
HTML 3.2 Reference + Specification
+ +
The HyperText Markup Language (HTML) is a simple markup language + used to create hypertext documents that are portable from one + platform to another. HTML documents are SGML documents.
+ +
XHTML 1.1 - + Module-based XHTML + (Errata) +
+ +
This Recommendation defines a new XHTML document type + that is based upon the module framework and modules defined in + Modularization of XHTML.
+ +
XHTML 1.0 The + Extensible HyperText Markup Language (Second Edition) + (Errata) +
+ +
This specification defines the Second Edition of XHTML 1.0, + a reformulation of HTML 4 as an XML 1.0 application, and three + DTDs corresponding to the ones defined by HTML 4.
+
+ +
top
+
+

Authentication

+ +

Concerning the different methods of authentication, Apache + follows the following IETF recommendations:

+ +
+
RFC 2617 + (Draft standard)
+ +
"HTTP/1.0", includes the specification for a Basic + Access Authentication scheme.
+ +
+ +
top
+
+

Language/Country Codes

+ +

The following links document ISO and other language and country + code information:

+ +
+
ISO 639-2
+ +
ISO 639 provides two sets of language codes, one as a two-letter + code set (639-1) and another as a three-letter code set (this part + of ISO 639) for the representation of names of languages.
+ +
+ ISO 3166-1
+ +
These pages document the country names (official short names + in English) in alphabetical order as given in ISO 3166-1 and the + corresponding ISO 3166-1-alpha-2 code elements.
+ +
BCP 47 + (Best Current Practice), + RFC 3066
+ +
This document describes a language tag for use in cases where + it is desired to indicate the language used in an information + object, how to register values for use in this language tag, + and a construct for matching such language tags.
+ +
RFC 3282 + (Standards Track)
+ +
This document defines a "Content-language:" header, for use in + cases where one desires to indicate the language of something that + has RFC 822-like headers, like MIME body parts or Web documents, + and an "Accept-Language:" header for use in cases where one wishes + to indicate one's preferences with regard to language.
+
+ +
+
+

Available Languages:  en  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/relevant_standards.html.ko.euc-kr b/rubbos/app/apache2/manual/misc/relevant_standards.html.ko.euc-kr new file mode 100644 index 00000000..acbccb9d --- /dev/null +++ b/rubbos/app/apache2/manual/misc/relevant_standards.html.ko.euc-kr @@ -0,0 +1,191 @@ + + + +°ü·Ã Ç¥ÁØ - Apache HTTP Server + + + + + +
<-
+

°ü·Ã Ç¥ÁØ

+
+

°¡´ÉÇÑ ¾ð¾î:  en  | + ko 

+
+ +

ÀÌ ¹®¼­¿¡´Â °£´ÜÇÑ ¼³¸í°ú ÇÔ²² ¾ÆÆÄÄ¡ À¥¼­¹ö°¡ µû¸£´Â + ¸ðµç °ü·Ã Ç¥ÁØÀ» ¿­°ÅÇÑ´Ù.

+ +

¾Æ·¡ Á¤º¸¿¡ ´õÇÏ¿© ´ÙÀ½ ÀÚ·áµµ »ìÆìºÁ¾ß ÇÑ´Ù:

+ + + +

ÁÖÀÇ

+

ÀÌ ¹®¼­´Â ¾ÆÁ÷ ¿ÏÀüÇÏÁö ¾Ê´Ù.

+
+ +
+ +
top
+
+

HTTP ±Ç°í

+ +

¾î¶² ¸ðµâÀ» ÄÄÆÄÀÏÇÏ°í »ç¿ëÇÏ´ÂÁö¿Í °ü°è¾øÀÌ ±âº»ÀûÀ¸·Î + À¥¼­¹öÀÎ ¾ÆÆÄÄ¡´Â ´ÙÀ½ IETF ±Ç°í(recommendation)¸¦ µû¸¥´Ù:

+ +
+
RFC 1945 + (Informational)
+ +
ÇÏÀÌÆÛÅؽºÆ® Àü¼Û ÇÁ·ÎÅäÄÝ (Hypertext Transfer Protocol, + HTTP)Àº ºÐ»ê, Çùµ¿, ÇÏÀÌÆÛ¸Åü Á¤º¸ ½Ã½ºÅÛ¿¡ ÇÊ¿äÇÑ ºü¸£°í + °¡º­¿î ¾îÇø®ÄÉÀÌ¼Ç ¼öÁØ(application-level) ÇÁ·ÎÅäÄÝÀÌ´Ù. + ÀÌ ¹®¼­´Â HTTP/1.0À» ¼³¸íÇÑ´Ù.
+ +
RFC 2616 + (Standards Track)
+ +
ÇÏÀÌÆÛÅؽºÆ® Àü¼Û ÇÁ·ÎÅäÄÝ (Hypertext Transfer Protocol, + HTTP)Àº ºÐ»ê, Çùµ¿, ÇÏÀÌÆÛ¸Åü Á¤º¸ ½Ã½ºÅÛÀ» À§ÇÑ ¾îÇø®ÄÉÀÌ¼Ç + ¼öÁØ ÇÁ·ÎÅäÄÝÀÌ´Ù. ÀÌ ¹®¼­´Â HTTP/1.1À» ¼³¸íÇÑ´Ù.
+ +
RFC 2396 + (Standards Track)
+ +
Ç¥ÁØ ÀÚ¿ø ½Äº°ÀÚ (Uniform Resource Identifier, URI)´Â + Ãß»óÀû ȤÀº ¹°¸®Àû ÀÚ¿øÀ» ½Äº°ÇϱâÀ§ÇÑ ÂªÀº ¹®ÀÚ¿­ÀÌ´Ù.
+
+ +
top
+
+

HTML ±Ç°í

+ +

ÇÏÀÌÆÛÅؽºÆ® ¸¶Å©¾÷ ¾ð¾î (Hypertext Markup Language, + HTML)¿Í °ü·ÃÇÏ¿© ¾ÆÆÄÄ¡´Â ´ÙÀ½ IETF ±Ç°í¿Í W3C ±Ç°í¸¦ µû¸¥´Ù:

+ +
+
RFC 2854 + (Informational)
+ +
ÀÌ ¹®¼­´Â HTML °³¹ß°úÁ¤À» ¿ä¾àÇÏ°í, °ü·Ã W3C ±Ç°í¸¦ + ±â¹ÝÀ¸·Î "text/html" MIME typeÀ» Á¤ÀÇÇÑ´Ù.
+ +
HTML 4.01 ±Ô¾à + (Errata) +
+ +
ÀÌ ±Ô¾àÀº ¿ùµå¿ÍÀ̵åÀ¥ÀÇ ÃâÆǾð¾îÀÎ ÇÏÀÌÆÛÅؽºÆ® ¸¶Å©¾÷ + ¾ð¾î (Hypertext Markup Language, HTML)¸¦ Á¤ÀÇÇÑ´Ù. ÀÌ + ±Ô¾àÀº HTML 4ÀÇ ÇÏÀ§¹öÀüÀÎ HTML 4.01À» Á¤ÀÇÇÑ´Ù.
+ +
HTML 3.2 Âü°í ±Ô¾à
+ +
ÇÏÀÌÆÛÅؽºÆ® ¸¶Å©¾÷ ¾ð¾î (Hypertext Markup Language, + HTML)´Â Ç÷¡Æû°ú ¹«°üÇÑ ÇÏÀÌÆÛÅؽºÆ® ¹®¼­¸¦ À§ÇÑ °£´ÜÇÑ + ¸¶Å©¾÷ ¾ð¾îÀÌ´Ù. HTML ¹®¼­´Â SGML ¹®¼­À̱⵵ ÇÏ´Ù.
+ +
XHTML 1.1 - + ¸ðµâ±â¹Ý XHTML + (Á¤¿ÀÇ¥) +
+ +
ÀÌ ±Ç°í´Â Modularization of XHTML¿¡¼­ Á¤ÀÇÇÑ ¸ðµâ + Ç÷¹ÀÓ¿öÅ©¿Í ¸ðµâµéÀ» ±â¹ÝÀ¸·Î »õ·Î¿î XHTML document typeÀ» + Á¤ÀÇÇÑ´Ù.
+ +
XHTML 1.0 + È®Àå ÇÏÀÌÆÛÅؽºÆ® ¸¶Å©¾÷ ¾ð¾î (Extensible HyperText Markup + Language) (Second Edition) + (Á¤¿ÀÇ¥) +
+ +
ÀÌ ¹®¼­´Â HTML 4¸¦ XML 1.0À¸·Î À籸¼ºÇÑ XHTML 1.0ÀÇ + µÎ¹ø° ¹öÀü°ú HTML 4¿¡ ÇØ´çÇÏ´Â ¼¼°¡Áö DTD¸¦ Á¤ÀÇÇÑ´Ù.
+
+ +
top
+
+

ÀÎÁõ

+ +

ÀÎÁõ¹æ¹ý¿¡ ´ëÇØ ¾ÆÆÄÄ¡´Â ´ÙÀ½ IETF ±Ç°í¸¦ µû¸¥´Ù:

+ +
+
RFC 2617 + (Draft standard)
+ +
Basic Access Authentication ±Ô¾àÀ» Æ÷ÇÔÇÑ "HTTP/1.0".
+ +
+ +
top
+
+

¾ð¾î/±¹°¡ ÄÚµå

+ +

¾Æ·¡ ¸µÅ©¿¡ ISO¿Í ´Ù¸¥ ¾ð¾î/±¹°¡ ÄÚµå Á¤º¸°¡ ÀÖ´Ù:

+ +
+
ISO 639-2
+ +
ISO 639´Â ¾ð¾îÀÇ À̸§À» ³ªÅ¸³»´Â µÎ°¡Áö ¾ð¾î Äڵ带 + Á¦°øÇÑ´Ù. Çϳª´Â (639-1) µÎ ±ÛÀÚ ÄÚµåÀÌ°í ´Ù¸¥ Çϳª´Â + (ÀÌ ¹®¼­) ¼¼ ±ÛÀÚ ÄÚµåÀÌ´Ù.
+ +
+ ISO 3166-1
+ +
ÀÌ ¹®¼­´Â ISO 3166-1°ú ISO 3166-1-alpha-2 Äڵ忡 µû¶ó + ¾ËÆĺª ¼ø¼­·Î (¿µ¾î·Î ªÀº °ø½ÄÀ̸§) ±¹°¡¸íÀ» ¿­°ÅÇÑ´Ù.
+ +
BCP 47 + (Best Current Practice), + RFC 3066
+ +
ÀÌ ¹®¼­´Â Á¤º¸ °´Ã¼¿¡ »ç¿ëÇÑ ¾ð¾î¸¦ ¾Ë¸®±âÀ§ÇØ »ç¿ëÇÒ + ¾ð¾î ÅÂ±×¿Í ¾ð¾î ű׿¡ »ç¿ëÇÒ °ªÀ» µî·ÏÇÏ´Â ¹æ¹ý, ¾ð¾î + ű׸¦ ã´Â ¹æ½ÄÀ» ¼³¸íÇÑ´Ù.
+ +
RFC 3282 + (Standards Track)
+ +
ÀÌ ¹®¼­´Â MIME ³»¿ë ºÎºÐ°ú À¥ ¹®¼­¿Í °°Àº RFC 822½Ä + Çì´õ°¡ ÀÖ´Â Á¤º¸ÀÇ ¾ð¾î¸¦ ¾Ë¸®±âÀ§ÇÑ "Content-language:" + Çì´õ¿Í, ¼±È£ÇÏ´Â ¾ð¾î¸¦ ³ªÅ¸³»´Â "Accept-Language:" Çì´õ¸¦ + Á¤ÀÇÇÑ´Ù.
+
+ +
+
+

°¡´ÉÇÑ ¾ð¾î:  en  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/rewriteguide.html b/rubbos/app/apache2/manual/misc/rewriteguide.html new file mode 100644 index 00000000..e58a64eb --- /dev/null +++ b/rubbos/app/apache2/manual/misc/rewriteguide.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +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/rubbos/app/apache2/manual/misc/rewriteguide.html.en b/rubbos/app/apache2/manual/misc/rewriteguide.html.en new file mode 100644 index 00000000..733f48bd --- /dev/null +++ b/rubbos/app/apache2/manual/misc/rewriteguide.html.en @@ -0,0 +1,2110 @@ + + + +URL Rewriting Guide - Apache HTTP Server + + + + + +
<-
+

URL Rewriting Guide

+
+

Available Languages:  en  | + ko 

+
+ +
+

Originally written by
+ Ralf S. Engelschall <rse@apache.org>
+ December 1997

+
+ +

This document supplements the mod_rewrite + reference documentation. + It describes how one can use Apache's mod_rewrite + to solve typical URL-based problems with which webmasters are + commonony confronted. We give detailed descriptions on how to + solve each problem by configuring URL rewriting rulesets.

+ +
+ +
top
+
+

Introduction to mod_rewrite

+ + + +

The Apache module mod_rewrite is a killer + one, i.e. it is a really sophisticated module which provides + a powerful way to do URL manipulations. With it you can do nearly + all types of URL manipulations you ever dreamed about. + The price you have to pay is to accept complexity, because + mod_rewrite's major drawback is that it is + not easy to understand and use for the beginner. And even + Apache experts sometimes discover new aspects where + mod_rewrite can help.

+ +

In other words: With mod_rewrite you either + shoot yourself in the foot the first time and never use it again + or love it for the rest of your life because of its power. + This paper tries to give you a few initial success events to + avoid the first case by presenting already invented solutions + to you.

+ +
top
+
+

Practical Solutions

+ + + +

Here come a lot of practical solutions I've either invented + myself or collected from other people's solutions in the past. + Feel free to learn the black magic of URL rewriting from + these examples.

+ +
ATTENTION: Depending on your server-configuration + it can be necessary to slightly change the examples for your + situation, e.g. adding the [PT] flag when + additionally using mod_alias and + mod_userdir, etc. Or rewriting a ruleset + to fit in .htaccess context instead + of per-server context. Always try to understand what a + particular ruleset really does before you use it. It + avoid problems.
+ +
top
+
+

URL Layout

+ + + +

Canonical URLs

+ + + +
+
Description:
+ +
+

On some webservers there are more than one URL for a + resource. Usually there are canonical URLs (which should be + actually used and distributed) and those which are just + shortcuts, internal ones, etc. Independent of which URL the + user supplied with the request he should finally see the + canonical one only.

+
+ +
Solution:
+ +
+

We do an external HTTP redirect for all non-canonical + URLs to fix them in the location view of the Browser and + for all subsequent requests. In the example ruleset below + we replace /~user by the canonical + /u/user and fix a missing trailing slash for + /u/user.

+ +
+RewriteRule   ^/~([^/]+)/?(.*)    /u/$1/$2  [R]
+RewriteRule   ^/([uge])/([^/]+)$  /$1/$2/   [R]
+
+
+
+ + + +

Canonical Hostnames

+ + + +
+
Description:
+ +
The goal of this rule is to force the use of a particular + hostname, in preference to other hostnames which may be used to + reach the same site. For example, if you wish to force the use + of www.example.com instead of + example.com, you might use a variant of the + following recipe.
+ +
Solution:
+ +
+
+# For sites running on a port other than 80
+RewriteCond %{HTTP_HOST}   !^www\.example\.com [NC]
+RewriteCond %{HTTP_HOST}   !^$
+RewriteCond %{SERVER_PORT} !^80$
+RewriteRule ^/(.*)         http://www.example.com:%{SERVER_PORT}/$1 [L,R]
+
+# And for a site running on port 80
+RewriteCond %{HTTP_HOST}   !^www\.example\.com [NC]
+RewriteCond %{HTTP_HOST}   !^$
+RewriteRule ^/(.*)         http://www.example.com/$1 [L,R]
+
+
+
+ + + +

Moved DocumentRoot

+ + + +
+
Description:
+ +
+

Usually the DocumentRoot + of the webserver directly relates to the URL "/". + But often this data is not really of top-level priority, it is + perhaps just one entity of a lot of data pools. For instance at + our Intranet sites there are /e/www/ + (the homepage for WWW), /e/sww/ (the homepage for + the Intranet) etc. Now because the data of the DocumentRoot stays at /e/www/ we had + to make sure that all inlined images and other stuff inside this + data pool work for subsequent requests.

+
+ +
Solution:
+ +
+

We redirect the URL / to + /e/www/: +

+ +
+RewriteEngine on
+RewriteRule   ^/$  /e/www/  [R]
+
+ +

Note that this can also be handled using the RedirectMatch directive:

+ +

+ RedirectMatch ^/$ http://example.com/e/www/ +

+
+
+ + + +

Trailing Slash Problem

+ + + +
+
Description:
+ +
+

Every webmaster can sing a song about the problem of + the trailing slash on URLs referencing directories. If they + are missing, the server dumps an error, because if you say + /~quux/foo instead of /~quux/foo/ + then the server searches for a file named + foo. And because this file is a directory it + complains. Actually it tries to fix it itself in most of + the cases, but sometimes this mechanism need to be emulated + by you. For instance after you have done a lot of + complicated URL rewritings to CGI scripts etc.

+
+ +
Solution:
+ +
+

The solution to this subtle problem is to let the server + add the trailing slash automatically. To do this + correctly we have to use an external redirect, so the + browser correctly requests subsequent images etc. If we + only did a internal rewrite, this would only work for the + directory page, but would go wrong when any images are + included into this page with relative URLs, because the + browser would request an in-lined object. For instance, a + request for image.gif in + /~quux/foo/index.html would become + /~quux/image.gif without the external + redirect!

+ +

So, to do this trick we write:

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^foo$  foo/  [R]
+
+ +

The crazy and lazy can even do the following in the + top-level .htaccess file of their homedir. + But notice that this creates some processing + overhead.

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteCond    %{REQUEST_FILENAME}  -d
+RewriteRule    ^(.+[^/])$           $1/  [R]
+
+
+
+ + + +

Webcluster through Homogeneous URL Layout

+ + + +
+
Description:
+ +
+

We want to create a homogeneous and consistent URL + layout over all WWW servers on a Intranet webcluster, i.e. + all URLs (per definition server local and thus server + dependent!) become actually server independent! + What we want is to give the WWW namespace a consistent + server-independent layout: no URL should have to include + any physically correct target server. The cluster itself + should drive us automatically to the physical target + host.

+
+ +
Solution:
+ +
+

First, the knowledge of the target servers come from + (distributed) external maps which contain information + where our users, groups and entities stay. The have the + form

+ +
+user1  server_of_user1
+user2  server_of_user2
+:      :
+
+ +

We put them into files map.xxx-to-host. + Second we need to instruct all servers to redirect URLs + of the forms

+ +
+/u/user/anypath
+/g/group/anypath
+/e/entity/anypath
+
+ +

to

+ +
+http://physical-host/u/user/anypath
+http://physical-host/g/group/anypath
+http://physical-host/e/entity/anypath
+
+ +

when the URL is not locally valid to a server. The + following ruleset does this for us by the help of the map + files (assuming that server0 is a default server which + will be used if a user has no entry in the map):

+ +
+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/([^/]+)/?(.*)   http://${user-to-host:$1|server0}/u/$1/$2
+RewriteRule   ^/g/([^/]+)/?(.*)  http://${group-to-host:$1|server0}/g/$1/$2
+RewriteRule   ^/e/([^/]+)/?(.*) http://${entity-to-host:$1|server0}/e/$1/$2
+
+RewriteRule   ^/([uge])/([^/]+)/?$          /$1/$2/.www/
+RewriteRule   ^/([uge])/([^/]+)/([^.]+.+)   /$1/$2/.www/$3\
+
+
+
+ + + +

Move Homedirs to Different Webserver

+ + + +
+
Description:
+ +
+

Many webmasters have asked for a solution to the + following situation: They wanted to redirect just all + homedirs on a webserver to another webserver. They usually + need such things when establishing a newer webserver which + will replace the old one over time.

+
+ +
Solution:
+ +
+

The solution is trivial with mod_rewrite. + On the old webserver we just redirect all + /~user/anypath URLs to + http://newserver/~user/anypath.

+ +
+RewriteEngine on
+RewriteRule   ^/~(.+)  http://newserver/~$1  [R,L]
+
+
+
+ + + +

Structured Homedirs

+ + + +
+
Description:
+ +
+

Some sites with thousands of users usually use a + structured homedir layout, i.e. each homedir is in a + subdirectory which begins for instance with the first + character of the username. So, /~foo/anypath + is /home/f/foo/.www/anypath + while /~bar/anypath is + /home/b/bar/.www/anypath.

+
+ +
Solution:
+ +
+

We use the following ruleset to expand the tilde URLs + into exactly the above layout.

+ +
+RewriteEngine on
+RewriteRule   ^/~(([a-z])[a-z0-9]+)(.*)  /home/$2/$1/.www$3
+
+
+
+ + + +

Filesystem Reorganization

+ + + +
+
Description:
+ +
+

This really is a hardcore example: a killer application + which heavily uses per-directory + RewriteRules to get a smooth look and feel + on the Web while its data structure is never touched or + adjusted. Background: net.sw is + my archive of freely available Unix software packages, + which I started to collect in 1992. It is both my hobby + and job to to this, because while I'm studying computer + science I have also worked for many years as a system and + network administrator in my spare time. Every week I need + some sort of software so I created a deep hierarchy of + directories where I stored the packages:

+ +
+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/
+
+ +

In July 1996 I decided to make this archive public to + the world via a nice Web interface. "Nice" means that I + wanted to offer an interface where you can browse + directly through the archive hierarchy. And "nice" means + that I didn't wanted to change anything inside this + hierarchy - not even by putting some CGI scripts at the + top of it. Why? Because the above structure should be + later accessible via FTP as well, and I didn't want any + Web or CGI stuff to be there.

+
+ +
Solution:
+ +
+

The solution has two parts: The first is a set of CGI + scripts which create all the pages at all directory + levels on-the-fly. I put them under + /e/netsw/.www/ as follows:

+ +
+-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
+
+ +

The DATA/ subdirectory holds the above + directory structure, i.e. the real + net.sw stuff and gets + automatically updated via rdist from time to + time. The second part of the problem remains: how to link + these two structures together into one smooth-looking URL + tree? We want to hide the DATA/ directory + from the user while running the appropriate CGI scripts + for the various URLs. Here is the solution: first I put + the following into the per-directory configuration file + in the DocumentRoot + of the server to rewrite the announced URL + /net.sw/ to the internal path + /e/netsw:

+ +
+RewriteRule  ^net.sw$       net.sw/        [R]
+RewriteRule  ^net.sw/(.*)$  e/netsw/$1
+
+ +

The first rule is for requests which miss the trailing + slash! The second rule does the real thing. And then + comes the killer configuration which stays in the + per-directory config file + /e/netsw/.www/.wwwacl:

+ +
+Options       ExecCGI FollowSymLinks Includes MultiViews
+
+RewriteEngine on
+
+#  we are reached via /net.sw/ prefix
+RewriteBase   /net.sw/
+
+#  first we rewrite the root dir to
+#  the handling cgi script
+RewriteRule   ^$                       netsw-home.cgi     [L]
+RewriteRule   ^index\.html$            netsw-home.cgi     [L]
+
+#  strip out the subdirs when
+#  the browser requests us from perdir pages
+RewriteRule   ^.+/(netsw-[^/]+/.+)$    $1                 [L]
+
+#  and now break the rewriting for local files
+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]
+
+#  anything else is a subdir which gets handled
+#  by another cgi script
+RewriteRule   !^netsw-lsdir\.cgi.*     -                  [C]
+RewriteRule   (.*)                     netsw-lsdir.cgi/$1
+
+ +

Some hints for interpretation:

+ +
    +
  1. Notice the L (last) flag and no + substitution field ('-') in the forth part
  2. + +
  3. Notice the ! (not) character and + the C (chain) flag at the first rule + in the last part
  4. + +
  5. Notice the catch-all pattern in the last rule
  6. +
+
+
+ + + +

NCSA imagemap to Apache mod_imap

+ + + +
+
Description:
+ +
+

When switching from the NCSA webserver to the more + modern Apache webserver a lot of people want a smooth + transition. So they want pages which use their old NCSA + imagemap program to work under Apache with the + modern mod_imap. The problem is that there + are a lot of hyperlinks around which reference the + imagemap program via + /cgi-bin/imagemap/path/to/page.map. Under + Apache this has to read just + /path/to/page.map.

+
+ +
Solution:
+ +
+

We use a global rule to remove the prefix on-the-fly for + all requests:

+ +
+RewriteEngine  on
+RewriteRule    ^/cgi-bin/imagemap(.*)  $1  [PT]
+
+
+
+ + + +

Search pages in more than one directory

+ + + +
+
Description:
+ +
+

Sometimes it is necessary to let the webserver search + for pages in more than one directory. Here MultiViews or + other techniques cannot help.

+
+ +
Solution:
+ +
+

We program a explicit ruleset which searches for the + files in the directories.

+ +
+RewriteEngine on
+
+#   first try to find it in custom/...
+#   ...and if found stop and be happy:
+RewriteCond         /your/docroot/dir1/%{REQUEST_FILENAME}  -f
+RewriteRule  ^(.+)  /your/docroot/dir1/$1  [L]
+
+#   second try to find it in pub/...
+#   ...and if found stop and be happy:
+RewriteCond         /your/docroot/dir2/%{REQUEST_FILENAME}  -f
+RewriteRule  ^(.+)  /your/docroot/dir2/$1  [L]
+
+#   else go on for other Alias or ScriptAlias directives,
+#   etc.
+RewriteRule   ^(.+)  -  [PT]
+
+
+
+ + + +

Set Environment Variables According To URL Parts

+ + + +
+
Description:
+ +
+

Perhaps you want to keep status information between + requests and use the URL to encode it. But you don't want + to use a CGI wrapper for all pages just to strip out this + information.

+
+ +
Solution:
+ +
+

We use a rewrite rule to strip out the status information + and remember it via an environment variable which can be + later dereferenced from within XSSI or CGI. This way a + URL /foo/S=java/bar/ gets translated to + /foo/bar/ and the environment variable named + STATUS is set to the value "java".

+ +
+RewriteEngine on
+RewriteRule   ^(.*)/S=([^/]+)/(.*)    $1/$3 [E=STATUS:$2]
+
+
+
+ + + +

Virtual User Hosts

+ + + +
+
Description:
+ +
+

Assume that you want to provide + www.username.host.domain.com + for the homepage of username via just DNS A records to the + same machine and without any virtualhosts on this + machine.

+
+ +
Solution:
+ +
+

For HTTP/1.0 requests there is no solution, but for + HTTP/1.1 requests which contain a Host: HTTP header we + can use the following ruleset to rewrite + http://www.username.host.com/anypath + internally to /home/username/anypath:

+ +
+RewriteEngine on
+RewriteCond   %{HTTP_HOST}                 ^www\.[^.]+\.host\.com$
+RewriteRule   ^(.+)                        %{HTTP_HOST}$1          [C]
+RewriteRule   ^www\.([^.]+)\.host\.com(.*) /home/$1$2
+
+
+
+ + + +

Redirect Homedirs For Foreigners

+ + + +
+
Description:
+ +
+

We want to redirect homedir URLs to another webserver + www.somewhere.com when the requesting user + does not stay in the local domain + ourdomain.com. This is sometimes used in + virtual host contexts.

+
+ +
Solution:
+ +
+

Just a rewrite condition:

+ +
+RewriteEngine on
+RewriteCond   %{REMOTE_HOST}  !^.+\.ourdomain\.com$
+RewriteRule   ^(/~.+)         http://www.somewhere.com/$1 [R,L]
+
+
+
+ + + +

Redirect Failing URLs To Other Webserver

+ + + +
+
Description:
+ +
+

A typical FAQ about URL rewriting is how to redirect + failing requests on webserver A to webserver B. Usually + this is done via ErrorDocument CGI-scripts in Perl, but + there is also a mod_rewrite solution. + But notice that this performs more poorly than using an + ErrorDocument + CGI-script!

+
+ +
Solution:
+ +
+

The first solution has the best performance but less + flexibility, and is less error safe:

+ +
+RewriteEngine on
+RewriteCond   /your/docroot/%{REQUEST_FILENAME} !-f
+RewriteRule   ^(.+)                             http://webserverB.dom/$1
+
+ +

The problem here is that this will only work for pages + inside the DocumentRoot. While you can add more + Conditions (for instance to also handle homedirs, etc.) + there is better variant:

+ +
+RewriteEngine on
+RewriteCond   %{REQUEST_URI} !-U
+RewriteRule   ^(.+)          http://webserverB.dom/$1
+
+ +

This uses the URL look-ahead feature of mod_rewrite. + The result is that this will work for all types of URLs + and is a safe way. But it does a performance impact on + the webserver, because for every request there is one + more internal subrequest. So, if your webserver runs on a + powerful CPU, use this one. If it is a slow machine, use + the first approach or better a ErrorDocument CGI-script.

+
+
+ + + +

Extended Redirection

+ + + +
+
Description:
+ +
+

Sometimes we need more control (concerning the + character escaping mechanism) of URLs on redirects. + Usually the Apache kernels URL escape function also + escapes anchors, i.e. URLs like "url#anchor". + You cannot use this directly on redirects with + mod_rewrite because the + uri_escape() function of Apache + would also escape the hash character. + How can we redirect to such a URL?

+
+ +
Solution:
+ +
+

We have to use a kludge by the use of a NPH-CGI script + which does the redirect itself. Because here no escaping + is done (NPH=non-parseable headers). First we introduce a + new URL scheme xredirect: by the following + per-server config-line (should be one of the last rewrite + rules):

+ +
+RewriteRule ^xredirect:(.+) /path/to/nph-xredirect.cgi/$1 \
+            [T=application/x-httpd-cgi,L]
+
+ +

This forces all URLs prefixed with + xredirect: to be piped through the + nph-xredirect.cgi program. And this program + just looks like:

+ +
+#!/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##
+
+ +

This provides you with the functionality to do + redirects to all URL schemes, i.e. including the one + which are not directly accepted by mod_rewrite. + For instance you can now also redirect to + news:newsgroup via

+ +
+RewriteRule ^anyurl  xredirect:news:newsgroup
+
+ +
Notice: You have not to put [R] or + [R,L] to the above rule because the + xredirect: need to be expanded later + by our special "pipe through" rule above.
+
+
+ + + +

Archive Access Multiplexer

+ + + +
+
Description:
+ +
+

Do you know the great CPAN (Comprehensive Perl Archive + Network) under http://www.perl.com/CPAN? + This does a redirect to one of several FTP servers around + the world which carry a CPAN mirror and is approximately + near the location of the requesting client. Actually this + can be called an FTP access multiplexing service. While + CPAN runs via CGI scripts, how can a similar approach + implemented via mod_rewrite?

+
+ +
Solution:
+ +
+

First we notice that from version 3.0.0 + mod_rewrite can + also use the "ftp:" scheme on redirects. + And second, the location approximation can be done by a + RewriteMap + over the top-level domain of the client. + With a tricky chained ruleset we can use this top-level + domain as a key to our multiplexing map.

+ +
+RewriteEngine on
+RewriteMap    multiplex                txt:/path/to/map.cxan
+RewriteRule   ^/CxAN/(.*)              %{REMOTE_HOST}::$1                 [C]
+RewriteRule   ^.+\.([a-zA-Z]+)::(.*)$  ${multiplex:$1|ftp.default.dom}$2  [R,L]
+
+ +
+##
+##  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##
+
+
+
+ + + +

Time-Dependent Rewriting

+ + + +
+
Description:
+ +
+

When tricks like time-dependent content should happen a + lot of webmasters still use CGI scripts which do for + instance redirects to specialized pages. How can it be done + via mod_rewrite?

+
+ +
Solution:
+ +
+

There are a lot of variables named TIME_xxx + for rewrite conditions. In conjunction with the special + lexicographic comparison patterns <STRING, + >STRING and =STRING we can + do time-dependent redirects:

+ +
+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
+
+ +

This provides the content of foo.day.html + under the URL foo.html from + 07:00-19:00 and at the remaining time the + contents of foo.night.html. Just a nice + feature for a homepage...

+
+
+ + + +

Backward Compatibility for YYYY to XXXX migration

+ + + +
+
Description:
+ +
+

How can we make URLs backward compatible (still + existing virtually) after migrating document.YYYY + to document.XXXX, e.g. after translating a + bunch of .html files to .phtml?

+
+ +
Solution:
+ +
+

We just rewrite the name to its basename and test for + existence of the new extension. If it exists, we take + that name, else we rewrite the URL to its original state.

+ + +
+#   backward compatibility ruleset for
+#   rewriting document.html to document.phtml
+#   when and only when document.phtml exists
+#   but no longer document.html
+RewriteEngine on
+RewriteBase   /~quux/
+#   parse out basename, but remember the fact
+RewriteRule   ^(.*)\.html$              $1      [C,E=WasHTML:yes]
+#   rewrite to document.phtml if exists
+RewriteCond   %{REQUEST_FILENAME}.phtml -f
+RewriteRule   ^(.*)$ $1.phtml                   [S=1]
+#   else reverse the previous basename cutout
+RewriteCond   %{ENV:WasHTML}            ^yes$
+RewriteRule   ^(.*)$ $1.html
+
+
+
+ + + +
top
+
+

Content Handling

+ + + +

From Old to New (intern)

+ + + +
+
Description:
+ +
+

Assume we have recently renamed the page + foo.html to bar.html and now want + to provide the old URL for backward compatibility. Actually + we want that users of the old URL even not recognize that + the pages was renamed.

+
+ +
Solution:
+ +
+

We rewrite the old URL to the new one internally via the + following rule:

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^foo\.html$  bar.html
+
+
+
+ + + +

From Old to New (extern)

+ + + +
+
Description:
+ +
+

Assume again that we have recently renamed the page + foo.html to bar.html and now want + to provide the old URL for backward compatibility. But this + time we want that the users of the old URL get hinted to + the new one, i.e. their browsers Location field should + change, too.

+
+ +
Solution:
+ +
+

We force a HTTP redirect to the new URL which leads to a + change of the browsers and thus the users view:

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^foo\.html$  bar.html  [R]
+
+
+
+ + + +

Browser Dependent Content

+ + + +
+
Description:
+ +
+

At least for important top-level pages it is sometimes + necessary to provide the optimum of browser dependent + content, i.e. one has to provide a maximum version for the + latest Netscape variants, a minimum version for the Lynx + browsers and a average feature version for all others.

+
+ +
Solution:
+ +
+

We cannot use content negotiation because the browsers do + not provide their type in that form. Instead we have to + act on the HTTP header "User-Agent". The following condig + does the following: If the HTTP header "User-Agent" + begins with "Mozilla/3", the page foo.html + is rewritten to foo.NS.html and and the + rewriting stops. If the browser is "Lynx" or "Mozilla" of + version 1 or 2 the URL becomes foo.20.html. + All other browsers receive page foo.32.html. + This is done by the following ruleset:

+ +
+RewriteCond %{HTTP_USER_AGENT}  ^Mozilla/3.*
+RewriteRule ^foo\.html$         foo.NS.html          [L]
+
+RewriteCond %{HTTP_USER_AGENT}  ^Lynx/.*         [OR]
+RewriteCond %{HTTP_USER_AGENT}  ^Mozilla/[12].*
+RewriteRule ^foo\.html$         foo.20.html          [L]
+
+RewriteRule ^foo\.html$         foo.32.html          [L]
+
+
+
+ + + +

Dynamic Mirror

+ + + +
+
Description:
+ +
+

Assume there are nice webpages on remote hosts we want + to bring into our namespace. For FTP servers we would use + the mirror program which actually maintains an + explicit up-to-date copy of the remote data on the local + machine. For a webserver we could use the program + webcopy which acts similar via HTTP. But both + techniques have one major drawback: The local copy is + always just as up-to-date as often we run the program. It + would be much better if the mirror is not a static one we + have to establish explicitly. Instead we want a dynamic + mirror with data which gets updated automatically when + there is need (updated data on the remote host).

+
+ +
Solution:
+ +
+

To provide this feature we map the remote webpage or even + the complete remote webarea to our namespace by the use + of the Proxy Throughput feature + (flag [P]):

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^hotsheet/(.*)$  http://www.tstimpreso.com/hotsheet/$1  [P]
+
+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^usa-news\.html$   http://www.quux-corp.com/news/index.html  [P]
+
+
+
+ + + +

Reverse Dynamic Mirror

+ + + +
+
Description:
+ +
...
+ +
Solution:
+ +
+
+RewriteEngine on
+RewriteCond   /mirror/of/remotesite/$1           -U
+RewriteRule   ^http://www\.remotesite\.com/(.*)$ /mirror/of/remotesite/$1
+
+
+
+ + + +

Retrieve Missing Data from Intranet

+ + + +
+
Description:
+ +
+

This is a tricky way of virtually running a corporate + (external) Internet webserver + (www.quux-corp.dom), while actually keeping + and maintaining its data on a (internal) Intranet webserver + (www2.quux-corp.dom) which is protected by a + firewall. The trick is that on the external webserver we + retrieve the requested data on-the-fly from the internal + one.

+
+ +
Solution:
+ +
+

First, we have to make sure that our firewall still + protects the internal webserver and that only the + external webserver is allowed to retrieve data from it. + For a packet-filtering firewall we could for instance + configure a firewall ruleset like the following:

+ +
+ALLOW Host www.quux-corp.dom Port >1024 --> Host www2.quux-corp.dom Port 80
+DENY  Host *                 Port *     --> Host www2.quux-corp.dom Port 80
+
+ +

Just adjust it to your actual configuration syntax. + Now we can establish the mod_rewrite + rules which request the missing data in the background + through the proxy throughput feature:

+ +
+RewriteRule ^/~([^/]+)/?(.*)          /home/$1/.www/$2
+RewriteCond %{REQUEST_FILENAME}       !-f
+RewriteCond %{REQUEST_FILENAME}       !-d
+RewriteRule ^/home/([^/]+)/.www/?(.*) http://www2.quux-corp.dom/~$1/pub/$2 [P]
+
+
+
+ + + +

Load Balancing

+ + + +
+
Description:
+ +
+

Suppose we want to load balance the traffic to + www.foo.com over www[0-5].foo.com + (a total of 6 servers). How can this be done?

+
+ +
Solution:
+ +
+

There are a lot of possible solutions for this problem. + We will discuss first a commonly known DNS-based variant + and then the special one with mod_rewrite:

+ +
    +
  1. + DNS Round-Robin + +

    The simplest method for load-balancing is to use + the DNS round-robin feature of BIND. + Here you just configure www[0-9].foo.com + as usual in your DNS with A(address) records, e.g.

    + +
    +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
    +
    + +

    Then you additionally add the following entry:

    + +
    +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.
    +
    + +

    Notice that this seems wrong, but is actually an + intended feature of BIND and can be used + in this way. However, now when www.foo.com gets + resolved, BIND gives out www0-www6 + - but in a slightly permutated/rotated order every time. + This way the clients are spread over the various + servers. But notice that this not a perfect load + balancing scheme, because DNS resolve information + gets cached by the other nameservers on the net, so + once a client has resolved www.foo.com + to a particular wwwN.foo.com, all + subsequent requests also go to this particular name + wwwN.foo.com. But the final result is + ok, because the total sum of the requests are really + spread over the various webservers.

    +
  2. + +
  3. + DNS Load-Balancing + +

    A sophisticated DNS-based method for + load-balancing is to use the program + lbnamed which can be found at + http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html. + It is a Perl 5 program in conjunction with auxilliary + tools which provides a real load-balancing for + DNS.

    +
  4. + +
  5. + Proxy Throughput Round-Robin + +

    In this variant we use mod_rewrite + and its proxy throughput feature. First we dedicate + www0.foo.com to be actually + www.foo.com by using a single

    + +
    +www    IN  CNAME   www0.foo.com.
    +
    + +

    entry in the DNS. Then we convert + www0.foo.com to a proxy-only server, + i.e. we configure this machine so all arriving URLs + are just pushed through the internal proxy to one of + the 5 other servers (www1-www5). To + accomplish this we first establish a ruleset which + contacts a load balancing script lb.pl + for all URLs.

    + +
    +RewriteEngine on
    +RewriteMap    lb      prg:/path/to/lb.pl
    +RewriteRule   ^/(.+)$ ${lb:$1}           [P,L]
    +
    + +

    Then we write lb.pl:

    + +
    +#!/path/to/perl
    +##
    +##  lb.pl -- load balancing script
    +##
    +
    +$| = 1;
    +
    +$name   = "www";     # the hostname base
    +$first  = 1;         # the first server (not 0 here, because 0 is myself)
    +$last   = 5;         # the last server in the round-robin
    +$domain = "foo.dom"; # the domainname
    +
    +$cnt = 0;
    +while (<STDIN>) {
    +    $cnt = (($cnt+1) % ($last+1-$first));
    +    $server = sprintf("%s%d.%s", $name, $cnt+$first, $domain);
    +    print "http://$server/$_";
    +}
    +
    +##EOF##
    +
    + +
    A last notice: Why is this useful? Seems like + www0.foo.com still is overloaded? The + answer is yes, it is overloaded, but with plain proxy + throughput requests, only! All SSI, CGI, ePerl, etc. + processing is completely done on the other machines. + This is the essential point.
    +
  6. + +
  7. + Hardware/TCP Round-Robin + +

    There is a hardware solution available, too. Cisco + has a beast called LocalDirector which does a load + balancing at the TCP/IP level. Actually this is some + sort of a circuit level gateway in front of a + webcluster. If you have enough money and really need + a solution with high performance, use this one.

    +
  8. +
+
+
+ + + +

New MIME-type, New Service

+ + + +
+
Description:
+ +
+

On the net there are a lot of nifty CGI programs. But + their usage is usually boring, so a lot of webmaster + don't use them. Even Apache's Action handler feature for + MIME-types is only appropriate when the CGI programs + don't need special URLs (actually PATH_INFO + and QUERY_STRINGS) as their input. First, + let us configure a new file type with extension + .scgi (for secure CGI) which will be processed + by the popular cgiwrap program. The problem + here is that for instance we use a Homogeneous URL Layout + (see above) a file inside the user homedirs has the URL + /u/user/foo/bar.scgi. But + cgiwrap needs the URL in the form + /~user/foo/bar.scgi/. The following rule + solves the problem:

+ +
+RewriteRule ^/[uge]/([^/]+)/\.www/(.+)\.scgi(.*) ...
+... /internal/cgi/user/cgiwrap/~$1/$2.scgi$3  [NS,T=application/x-http-cgi]
+
+ +

Or assume we have some more nifty programs: + wwwlog (which displays the + access.log for a URL subtree and + wwwidx (which runs Glimpse on a URL + subtree). We have to provide the URL area to these + programs so they know on which area they have to act on. + But usually this ugly, because they are all the times + still requested from that areas, i.e. typically we would + run the swwidx program from within + /u/user/foo/ via hyperlink to

+ +
+/internal/cgi/user/swwidx?i=/u/user/foo/
+
+ +

which is ugly. Because we have to hard-code + both the location of the area + and the location of the CGI inside the + hyperlink. When we have to reorganize the area, we spend a + lot of time changing the various hyperlinks.

+
+ +
Solution:
+ +
+

The solution here is to provide a special new URL format + which automatically leads to the proper CGI invocation. + We configure the following:

+ +
+RewriteRule   ^/([uge])/([^/]+)(/?.*)/\*  /internal/cgi/user/wwwidx?i=/$1/$2$3/
+RewriteRule   ^/([uge])/([^/]+)(/?.*):log /internal/cgi/user/wwwlog?f=/$1/$2$3
+
+ +

Now the hyperlink to search at + /u/user/foo/ reads only

+ +
+HREF="*"
+
+ +

which internally gets automatically transformed to

+ +
+/internal/cgi/user/wwwidx?i=/u/user/foo/
+
+ +

The same approach leads to an invocation for the + access log CGI program when the hyperlink + :log gets used.

+
+
+ + + +

From Static to Dynamic

+ + + +
+
Description:
+ +
+

How can we transform a static page + foo.html into a dynamic variant + foo.cgi in a seamless way, i.e. without notice + by the browser/user.

+
+ +
Solution:
+ +
+

We just rewrite the URL to the CGI-script and force the + correct MIME-type so it gets really run as a CGI-script. + This way a request to /~quux/foo.html + internally leads to the invocation of + /~quux/foo.cgi.

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^foo\.html$  foo.cgi  [T=application/x-httpd-cgi]
+
+
+
+ + + +

On-the-fly Content-Regeneration

+ + + +
+
Description:
+ +
+

Here comes a really esoteric feature: Dynamically + generated but statically served pages, i.e. pages should be + delivered as pure static pages (read from the filesystem + and just passed through), but they have to be generated + dynamically by the webserver if missing. This way you can + have CGI-generated pages which are statically served unless + one (or a cronjob) removes the static contents. Then the + contents gets refreshed.

+
+ +
Solution:
+ +
+ This is done via the following ruleset: + +
+RewriteCond %{REQUEST_FILENAME}   !-s
+RewriteRule ^page\.html$          page.cgi   [T=application/x-httpd-cgi,L]
+
+ +

Here a request to page.html leads to a + internal run of a corresponding page.cgi if + page.html is still missing or has filesize + null. The trick here is that page.cgi is a + usual CGI script which (additionally to its STDOUT) + writes its output to the file page.html. + Once it was run, the server sends out the data of + page.html. When the webmaster wants to force + a refresh the contents, he just removes + page.html (usually done by a cronjob).

+
+
+ + + +

Document With Autorefresh

+ + + +
+
Description:
+ +
+

Wouldn't it be nice while creating a complex webpage if + the webbrowser would automatically refresh the page every + time we write a new version from within our editor? + Impossible?

+
+ +
Solution:
+ +
+

No! We just combine the MIME multipart feature, the + webserver NPH feature and the URL manipulation power of + mod_rewrite. First, we establish a new + URL feature: Adding just :refresh to any + URL causes this to be refreshed every time it gets + updated on the filesystem.

+ +
+RewriteRule   ^(/[uge]/[^/]+/?.*):refresh  /internal/cgi/apache/nph-refresh?f=$1
+
+ +

Now when we reference the URL

+ +
+/u/foo/bar/page.html:refresh
+
+ +

this leads to the internal invocation of the URL

+ +
+/internal/cgi/apache/nph-refresh?f=/u/foo/bar/page.html
+
+ +

The only missing part is the NPH-CGI script. Although + one would usually say "left as an exercise to the reader" + ;-) I will provide this, too.

+ +
+#!/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##
+
+
+
+ + + +

Mass Virtual Hosting

+ + + +
+
Description:
+ +
+

The <VirtualHost> feature of Apache is nice + and works great when you just have a few dozens + virtual hosts. But when you are an ISP and have hundreds of + virtual hosts to provide this feature is not the best + choice.

+
+ +
Solution:
+ +
+

To provide this feature we map the remote webpage or even + the complete remote webarea to our namespace by the use + of the Proxy Throughput feature (flag [P]):

+ +
+##
+##  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
+
+ +
+##
+##  httpd.conf
+##
+    :
+#   use the canonical hostname on redirects, etc.
+UseCanonicalName on
+
+    :
+#   add the virtual host in front of the CLF-format
+CustomLog  /path/to/access_log  "%{VHOST}e %h %l %u %t \"%r\" %>s %b"
+    :
+
+#   enable the rewriting engine in the main server
+RewriteEngine on
+
+#   define two maps: one for fixing the URL and one which defines
+#   the available virtual hosts with their corresponding
+#   DocumentRoot.
+RewriteMap    lowercase    int:tolower
+RewriteMap    vhost        txt:/path/to/vhost.map
+
+#   Now do the actual virtual host mapping
+#   via a huge and complicated single rule:
+#
+#   1. make sure we don't map for common locations
+RewriteCond   %{REQUEST_URI}  !^/commonurl1/.*
+RewriteCond   %{REQUEST_URI}  !^/commonurl2/.*
+    :
+RewriteCond   %{REQUEST_URI}  !^/commonurlN/.*
+#
+#   2. make sure we have a Host header, because
+#      currently our approach only supports
+#      virtual hosting through this header
+RewriteCond   %{HTTP_HOST}  !^$
+#
+#   3. lowercase the hostname
+RewriteCond   ${lowercase:%{HTTP_HOST}|NONE}  ^(.+)$
+#
+#   4. lookup this hostname in vhost.map and
+#      remember it only when it is a path
+#      (and not "NONE" from above)
+RewriteCond   ${vhost:%1}  ^(/.*)$
+#
+#   5. finally we can map the URL to its docroot location
+#      and remember the virtual host for logging puposes
+RewriteRule   ^/(.*)$   %1/$1  [E=VHOST:${lowercase:%{HTTP_HOST}}]
+    :
+
+
+
+ + + +
top
+
+

Access Restriction

+ + + +

Blocking of Robots

+ + + +
+
Description:
+ +
+

How can we block a really annoying robot from + retrieving pages of a specific webarea? A + /robots.txt file containing entries of the + "Robot Exclusion Protocol" is typically not enough to get + rid of such a robot.

+
+ +
Solution:
+ +
+

We use a ruleset which forbids the URLs of the webarea + /~quux/foo/arc/ (perhaps a very deep + directory indexed area where the robot traversal would + create big server load). We have to make sure that we + forbid access only to the particular robot, i.e. just + forbidding the host where the robot runs is not enough. + This would block users from this host, too. We accomplish + this by also matching the User-Agent HTTP header + information.

+ +
+RewriteCond %{HTTP_USER_AGENT}   ^NameOfBadRobot.*
+RewriteCond %{REMOTE_ADDR}       ^123\.45\.67\.[8-9]$
+RewriteRule ^/~quux/foo/arc/.+   -   [F]
+
+
+
+ + + +

Blocked Inline-Images

+ + + +
+
Description:
+ +
+

Assume we have under http://www.quux-corp.de/~quux/ + some pages with inlined GIF graphics. These graphics are + nice, so others directly incorporate them via hyperlinks to + their pages. We don't like this practice because it adds + useless traffic to our server.

+
+ +
Solution:
+ +
+

While we cannot 100% protect the images from inclusion, + we can at least restrict the cases where the browser + sends a HTTP Referer header.

+ +
+RewriteCond %{HTTP_REFERER} !^$
+RewriteCond %{HTTP_REFERER} !^http://www.quux-corp.de/~quux/.*$ [NC]
+RewriteRule .*\.gif$        -                                    [F]
+
+ +
+RewriteCond %{HTTP_REFERER}         !^$
+RewriteCond %{HTTP_REFERER}         !.*/foo-with-gif\.html$
+RewriteRule ^inlined-in-foo\.gif$   -                        [F]
+
+
+
+ + + +

Host Deny

+ + + +
+
Description:
+ +
+

How can we forbid a list of externally configured hosts + from using our server?

+
+ +
Solution:
+ +
+

For Apache >= 1.3b6:

+ +
+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]
+
+ +

For Apache <= 1.3b6:

+ +
+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
+
+ +
+##
+##  hosts.deny
+##
+##  ATTENTION! This is a map, not a list, even when we treat it as such.
+##             mod_rewrite parses it for key/value pairs, so at least a
+##             dummy value "-" must be present for each entry.
+##
+
+193.102.180.41 -
+bsdti1.sdm.de  -
+192.76.162.40  -
+
+
+
+ + + +

Proxy Deny

+ + + +
+
Description:
+ +
+

How can we forbid a certain host or even a user of a + special host from using the Apache proxy?

+
+ +
Solution:
+ +
+

We first have to make sure mod_rewrite + is below(!) mod_proxy in the Configuration + file when compiling the Apache webserver. This way it gets + called before mod_proxy. Then we + configure the following for a host-dependent deny...

+ +
+RewriteCond %{REMOTE_HOST} ^badhost\.mydomain\.com$
+RewriteRule !^http://[^/.]\.mydomain.com.*  - [F]
+
+ +

...and this one for a user@host-dependent deny:

+ +
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST}  ^badguy@badhost\.mydomain\.com$
+RewriteRule !^http://[^/.]\.mydomain.com.*  - [F]
+
+
+
+ + + +

Special Authentication Variant

+ + + +
+
Description:
+ +
+

Sometimes a very special authentication is needed, for + instance a authentication which checks for a set of + explicitly configured users. Only these should receive + access and without explicit prompting (which would occur + when using the Basic Auth via mod_auth).

+
+ +
Solution:
+ +
+

We use a list of rewrite conditions to exclude all except + our friends:

+ +
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend1@client1.quux-corp\.com$
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend2@client2.quux-corp\.com$
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend3@client3.quux-corp\.com$
+RewriteRule ^/~quux/only-for-friends/      -                                 [F]
+
+
+
+ + + +

Referer-based Deflector

+ + + +
+
Description:
+ +
+

How can we program a flexible URL Deflector which acts + on the "Referer" HTTP header and can be configured with as + many referring pages as we like?

+
+ +
Solution:
+ +
+

Use the following really tricky ruleset...

+ +
+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]
+
+ +

... in conjunction with a corresponding rewrite + map:

+ +
+##
+##  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/
+
+ +

This automatically redirects the request back to the + referring page (when "-" is used as the value + in the map) or to a specific URL (when an URL is specified + in the map as the second argument).

+
+
+ + + +
top
+
+

Other

+ + + +

External Rewriting Engine

+ + + +
+
Description:
+ +
+

A FAQ: How can we solve the FOO/BAR/QUUX/etc. + problem? There seems no solution by the use of + mod_rewrite...

+
+ +
Solution:
+ +
+

Use an external RewriteMap, i.e. a program which acts + like a RewriteMap. It is run once on startup of Apache + receives the requested URLs on STDIN and has + to put the resulting (usually rewritten) URL on + STDOUT (same order!).

+ +
+RewriteEngine on
+RewriteMap    quux-map       prg:/path/to/map.quux.pl
+RewriteRule   ^/~quux/(.*)$  /~quux/${quux-map:$1}
+
+ +
+#!/path/to/perl
+
+#   disable buffered I/O which would lead
+#   to deadloops for the Apache server
+$| = 1;
+
+#   read URLs one per line from stdin and
+#   generate substitution URL on stdout
+while (<>) {
+    s|^foo/|bar/|;
+    print $_;
+}
+
+ +

This is a demonstration-only example and just rewrites + all URLs /~quux/foo/... to + /~quux/bar/.... Actually you can program + whatever you like. But notice that while such maps can be + used also by an average user, only the + system administrator can define it.

+
+
+ + + +
+
+

Available Languages:  en  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/rewriteguide.html.ko.euc-kr b/rubbos/app/apache2/manual/misc/rewriteguide.html.ko.euc-kr new file mode 100644 index 00000000..694b8f01 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/rewriteguide.html.ko.euc-kr @@ -0,0 +1,2013 @@ + + + +URL ÀçÀÛ¼º Áöħ¼­ - Apache HTTP Server + + + + + +
<-
+

URL ÀçÀÛ¼º Áöħ¼­

+
+

°¡´ÉÇÑ ¾ð¾î:  en  | + ko 

+
+
ÀÌ ¹®¼­´Â ÃÖ½ÅÆÇ ¹ø¿ªÀÌ ¾Æ´Õ´Ï´Ù. + ÃÖ±Ù¿¡ º¯°æµÈ ³»¿ëÀº ¿µ¾î ¹®¼­¸¦ Âü°íÇϼ¼¿ä.
+ +
+

¿øÀúÀÚ
+ Ralf S. Engelschall <rse@apache.org>
+ 1997³â 12¿ù

+
+ +

ÀÌ ¹®¼­´Â mod_rewrite ÂüÁ¶ ¹®¼­¸¦ º¸ÃæÇÑ´Ù. + ÀÌ ¹®¼­´Â À¥°ü¸®ÀÚ°¡ ½ÇÁ¦ ÀÛ¾÷¿¡¼­ ºÎµúÄ¡°ÔµÇ´Â ÀüÇüÀûÀÎ + URL°ü·Ã ¹®Á¦¸¦ ÇØ°áÇϱâÀ§Çؼ­ ¾î¶»°Ô ¾ÆÆÄÄ¡ + mod_rewrite¸¦ »ç¿ëÇÏ´ÂÁö ¼³¸íÇÑ´Ù. URL + ÀçÀÛ¼º ±ÔÄ¢À» ¼³Á¤ÇÏ¿© ¹®Á¦¸¦ ÇØ°áÇÏ´Â ¹æ¹ýÀ» ÀÚ¼¼È÷ ¼³¸íÇÑ´Ù.

+ +
+ +
top
+
+

mod_rewrite ¼Ò°³

+ + + +

¾ÆÆÄÄ¡ mod_rewrite ¸ðµâÀº ±²ÀåÇÏ´Ù. + Áï, URLÀ» Á¶ÀÛÇÒ ¼ö ÀÖ´Â °­·ÂÇÏ°í ½Ç·Î Á¤±³ÇÑ ¸ðµâÀÌ´Ù. + »ó»óÇØ¿Ô´ø °ÅÀÇ ¸ðµç Á¾·ùÀÇ URL Á¶ÀÛÀÌ °¡´ÉÇÏ´Ù. ±×·¯³ª + ±× ´ë°¡·Î »ç¿ëÇϱ⠺¹ÀâÇÏ´Ù. mod_rewriteÀÇ + ÃÖ´ë ´ÜÁ¡Àº Ãʺ¸ÀÚ°¡ ÀÌÇØÇÏ°í »ç¿ëÇϱ⠽±Áö ¾Ê´Ù´Â Á¡ÀÌ´Ù. + ½ÉÁö¾î ¾ÆÆÄÄ¡ Àü¹®°¡µµ Á¾Á¾ mod_rewriteÀÇ + »õ·Î¿î ¿ëµµ¸¦ ¹ß°ßÇÑ´Ù.

+ +

´Ù¸¥ ¸»·Î: mod_rewrite¿¡ ´ëÇØ ´ç½ÅÀº + óÀ½¿¡ °ÌÀ» ¸Ô°í Àý´ë·Î ´Ù½Ã »ç¿ëÇÏÁö ¾Ê°Å³ª, °­·ÂÇÔ¿¡ ¸Å·áµÇ¾î + ¾ÕÀ¸·Î »î µ¿¾È »ç¶û¿¡ ºüÁú °ÍÀÌ´Ù. ÀÌ ±ÛÀº ù¹ø° °æ¿ì¸¦ + ¸·±âÀ§ÇØ ÀÌ¹Ì ¾Ë·ÁÁø ¸î°¡Áö ¼º°ø»ç·Ê¸¦ ¼Ò°³ÇÏ·Á°í ÇÑ´Ù.

+ +
top
+
+

½Ç¿ëÀûÀÎ ÇØ°áÃ¥

+ + + +

ÀÌÁ¦ ³»°¡ Á÷Á¢ ¸¸µé¾ú°Å³ª ´Ù¸¥ »ç¶÷µéÀÌ ¸¸µç ¸¹Àº ½Ç¿ëÀûÀÎ + ÇØ°áÃ¥ÀÌ ³ª¿Â´Ù. ¿¹Á¦¿¡¼­ URL ÀçÀÛ¼ºÀÇ È渶¼úÀ» ¸¶À½²¯ ¹è¿ì±æ + ¹Ù¶õ´Ù.

+ +
ÁÖÀÇ: ¼­¹ö ¼³Á¤¿¡ µû¶ó »óȲ¿¡ ¸Â°Ô + ¿¹Á¦¸¦ Á¶±Ý ¼öÁ¤ÇØ¾ß ÇÒ °æ¿ì°¡ ÀÖ´Ù. ¿¹¸¦ µé¾î, Ãß°¡·Î + mod_alias, mod_userdir + µîÀ» »ç¿ëÇÑ´Ù¸é [PT] Ç÷¡±×¸¦ Ãß°¡ÇÑ´Ù. ȤÀº + ÁÖ¼­¹ö¼³Á¤/°¡»óÈ£½ºÆ® »ç¿ëÀå¼Ò°¡ ¾Æ´Ñ .htaccess + »ç¿ëÀå¼Ò¿¡ ¾Ë¸Â°Ô ±ÔÄ¢À» ¼öÁ¤ÇÒ ¼öµµ ÀÖ´Ù. »ç¿ëÇϱâ Àü¿¡ + Ç×»ó ±ÔÄ¢ÀÌ ¾î¶² ±â´ÉÀ» ÇÏ´ÂÁö ÀÌÇØÇϵµ·Ï Çضó. ±×·¯¸é ¹®Á¦¸¦ + ÇÇÇÒ ¼ö ÀÖ´Ù.
+ +
top
+
+

URL ±¸Á¶

+ + + +

±âÁØÀÌ µÇ´Â URL

+ + + +
+
»óȲ¼³¸í:
+ +
+

ÇÑ ¸®¼Ò½º¿¡ ´ëÇØ ¿©·¯ URLÀ» °¡Áö´Â À¥¼­¹ö°¡ ÀÖ´Ù. + º¸Åë (½ÇÁ¦ »ç¿ëÇÏ°í ¾Ë·ÁÁ®¾ß ÇÒ) ±âÁØÀÌ µÇ´Â URL°ú, + ´ÜÃà ȤÀº ³»ºÎ ¿ëµµÀÇ URLÀÌ ÀÖ´Ù. »ç¿ëÀÚ°¡ ¿äû¿¡ + ¾î¶² URLÀ» »ç¿ëÇÏ´øÁö ±âÁØÀÌ µÇ´Â URL¸¸À» º¸¿©Áà¾ß + ÇÑ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

±âÁØÀÌ µÇÁö¾Ê´Â ¸ðµç URLÀ» ºê¶ó¿ìÀú°¡ ¾Ëµµ·Ï °íÄ¡±âÀ§ÇØ + ¿ÜºÎ HTTP ¸®´ÙÀÌ·º¼ÇÇÑ´Ù. ¿¹¸¦ µé¾î ¾Æ·¡ ±ÔÄ¢Àº + /~user¸¦ ±âÁØÀÌ µÇ´Â /u/user·Î + ´ëüÇÏ°í, /u/user ¸¶Áö¸·¿¡ ½½·¡½¬°¡ ¾ø´Ù¸é + Ãß°¡ÇÑ´Ù.

+ +
+RewriteRule   ^/~([^/]+)/?(.*)    /u/$1/$2  [R]
+RewriteRule   ^/([uge])/([^/]+)$  /$1/$2/   [R]
+
+
+
+ + + +

±âÁØÀÌ µÇ´Â È£½ºÆ®¸í

+ + + +
+
»óȲ¼³¸í:
+ +
ÀÌ ±ÔÄ¢Àº µ¿ÀÏÇÑ »çÀÌÆ®¿¡ µµ´ÞÇÒ ¼ö ÀÖ´Â ´Ù¸¥ È£½ºÆ®¸í + ´ë½Å ƯÁ¤ È£½ºÆ®¸íÀ» »ç¿ëÇϵµ·Ï °­Á¦ÇÑ´Ù. ¿¹¸¦ µé¾î, + example.com ´ë½Å + www.example.comÀ» »ç¿ëÇϵµ·Ï °­Á¦ÇÏ°í + ½Í´Ù¸é ´ÙÀ½°ú °°Àº ±ÔÄ¢À» »ç¿ëÇÒ ¼ö ÀÖ´Ù.
+ +
ÇØ°áÃ¥:
+ +
+
+# 80¹øÀÌ ¾Æ´Ñ Æ÷Æ®¿¡¼­ ½ÇÇàÇÏ´Â »çÀÌÆ®¿ë
+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]
+
+# ±×¸®°í, 80¹ø Æ÷Æ®¿¡¼­ ½ÇÇàÇÏ´Â »çÀÌÆ®¿ë
+RewriteCond %{HTTP_HOST}   !^fully\.qualified\.domain\.name [NC]
+RewriteCond %{HTTP_HOST}   !^$
+RewriteRule ^/(.*)         http://fully.qualified.domain.name/$1 [L,R]
+
+
+
+ + + +

DocumentRoot¸¦ ¿Å±ä °æ¿ì

+ + + +
+
»óȲ¼³¸í:
+ +
+

À¥¼­¹öÀÇ DocumentRoot´Â º¸Åë URL + "/"°ú Á÷Á¢ °ü·ÃÀÖ´Ù. ±×·¯³ª ÀÌ°÷¿¡ ¸ðµç + ÀÚ·á°¡ ÀÖÁö ¾Ê°í, ÀÚ·á°¡ ´Ù¸¥ ¿©·¯ °÷¿¡ Èð¾îÁ®ÀÖ´Â + °æ¿ì°¡ ÀÖ´Ù. ¿¹¸¦ µé¾î ÀÎÆ®¶ó³Ý »çÀÌÆ®¿¡ (¿ÜºÎ¸¦ À§ÇÑ + ȨÆäÀÌÁö) /e/www/¿Í (ÀÎÆ®¶ó³ÝÀ» À§ÇÑ + ȨÆäÀÌÁö) /e/sww/°¡ ÀÖ´Ù°í ÇÏÀÚ. ÀÌÁ¦ + DocumentRoot°¡ + /e/www/À̱⶧¹®¿¡, ¿äû¿¡¼­ ÆäÀÌÁö¿¡ + Æ÷ÇÔµÈ ±×¸² µîÀ» ÀÌ°÷¿¡¼­ °¡Á®¿Í¾ß ÇÑ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

¿ì¸®´Â URL /¸¦ /e/www/·Î + ¸®´ÙÀÌ·º¼Ç¸¸ ÇÏ¸é µÈ´Ù. »ç¼ÒÇØ º¸ÀÌÁö¸¸ ½ÇÁ¦·Î + mod_rewrite¸¦ »ç¿ëÇؼ­¸¸ °¡´ÉÇÏ´Ù. + (mod_alias µîÀÌ Á¦°øÇÏ´Â) URL + Alias °°Àº ÀüÇüÀûÀÎ ¹æ¹ýÀº ¾ÕºÎºÐ¸¸ + ã´Â´Ù. DocumentRoot°¡ + ¸ðµç URLÀÇ ¾ÕºÎºÐÀ̱⶧¹®¿¡ ÀÌ ¹æ¹ýÀ» »ç¿ëÇÏ¿© ¸®´ÙÀÌ·º¼ÇÀ» + ÇÒ ¼ö ¾ø´Ù. mod_rewrite¸¦ »ç¿ëÇϸé + ÁøÂ¥ °£´ÜÇÏ´Ù:

+ +
+RewriteEngine on
+RewriteRule   ^/$  /e/www/  [R]
+
+
+
+ + + +

¸¶Áö¸· ½½·¡½¬ ¹®Á¦

+ + + +
+
»óȲ¼³¸í:
+ +
+

µð·ºÅ丮¸¦ ÁöĪÇÏ´Â URLÀÇ ¸¶Áö¸· ½½·¡½¬ ¹®Á¦°¡ + ¾ø´Ù¸é ¸ðµç À¥°ü¸®Àڴ ȯȣÇÒ °ÍÀÌ´Ù. ½½·¡½¬°¡ ¾ø´Ù¸é, + Áï /~quux/foo/ ´ë½Å /~quux/foo¸¦ + »ç¿ëÇÏ¸é ¼­¹ö°¡ foo¶ó´Â ÆÄÀÏÀ» + ã±â¶§¹®¿¡ ¿À·ù°¡ ¹ß»ýÇÑ´Ù. ÆÄÀÏÀÌ µð·ºÅ丮À̱⶧¹®¿¡ + ¹Þ¾ÆµéÀÌÁö ¾Ê´Â´Ù. ´ëºÎºÐÀÇ °æ¿ì º¸Åë ¼­¹ö°¡ ÀÚµ¿À¸·Î + URLÀ» °íÄ¡Áö¸¸, °¡²û Á÷Á¢ ÇØÁà¾ß ÇÒ °æ¿ì°¡ ÀÖ´Ù. ¿¹¸¦ + µé¾î, CGI ½ºÅ©¸³Æ® µîÀ¸·Î º¹ÀâÇÑ URL ÀçÀÛ¼ºÀ» ÇÑ ÈÄ¿¡ + ±×·¯ÇÏ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

ÀÌ ¹Ì¹¦ÇÑ ¹®Á¦ÀÇ ÇØ°á¹æ¹ýÀº ¼­¹ö°¡ ÀÚµ¿À¸·Î ¸¶Áö¸· + ½½·¡½¬¸¦ Ãß°¡ÇÏ´Â °ÍÀÌ´Ù. ºê¶ó¿ìÀú°¡ ³ª¸ÓÁö ±×¸² µîÀ» + ¿Ã¹Ù·Î ¿äûÇÒ ¼ö ÀÖµµ·Ï, ¿ÜºÎ ¸®´ÙÀÌ·º¼ÇÀ» ÇØ¾ß ÇÑ´Ù. + ³»ºÎ ¸®´ÙÀÌ·º¼ÇÀ» ÇÑ´Ù¸é µð·ºÅ丮 ÆäÀÌÁö¿¡¸¸ µ¿ÀÛÇÏ¿© + ÀÌ ÆäÀÌÁö°¡ »ó´ë URL·Î Æ÷ÇÔÇÏ´Â ±×¸²À» ºê¶ó¿ìÀú°¡ + ¿äûÇÒ¶§ ãÀ» ¼ö ¾ø´Ù. ¿¹¸¦ µé¾î, ¿ÜºÎ ¸®´ÙÀÌ·º¼ÇÀ» + »ç¿ëÇÏÁö ¾ÊÀ»¶§ /~quux/foo/index.html¿¡¼­ + image.gif¸¦ ¿äûÇϸé + /~quux/image.gif¸¦ ¿äûÇÏ°Ô µÈ´Ù!

+ +

±×·¡¼­ À̸¦ ÇØ°áÇϱâÀ§ÇØ ´ÙÀ½°ú °°ÀÌ ¼³Á¤ÇÑ´Ù:

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^foo$  foo/  [R]
+
+ +

Ȩµð·ºÅ丮ÀÇ ÃÖ»óÀ§ .htaccess ÆÄÀÏ¿¡ + ´ÙÀ½°ú °°ÀÌ ¼³Á¤ÇÒ ¼öµµ ÀÖ´Ù. ±×·¯³ª ó¸®Çϴµ¥ ºÎ´ãÀÌ + µÈ´Ù.

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteCond    %{REQUEST_FILENAME}  -d
+RewriteRule    ^(.+[^/])$           $1/  [R]
+
+
+
+ + + +

ÀÏ°üµÈ URL ±¸Á¶·Î ¸¸µç À¥Å¬·¯½ºÅÍ

+ + + +
+
»óȲ¼³¸í:
+ +
+

ÀÎÆ®¶ó³Ý À¥¼­¹ö±ºÀÇ ¸ðµç À¥¼­¹ö¿¡ µ¿ÀÏÇÏ°í ÀÏ°üµÈ + URL ±¸Á¶¸¦ ¸¸µé°í ½Í´Ù. Áï, ¸ðµç (Á¤ÀÇ»ó ¼­¹ö¿¡ ¼ÓÇÏ¿© + ¼­¹ö¿¡ ÀÇÁ¸ÀûÀÎ!) URLÀ» ¼­¹ö µ¶¸³ÀûÀ¸·Î ¸¸µç´Ù! + À¥ À̸§°ø°£¿¡ ¼­¹öµ¶¸³ÀûÀÎ µ¿ÀÏÇÑ ±¸Á¶¸¦ ºÎ¿©ÇØ¾ß ÇÑ´Ù: + URLÀº ½ÇÁ¦ ¼­¹ö¸¦ ÁöĪÇÏ¸é ¾ÈµÈ´Ù. ¼­¹ö±ºÀÌ ÀÚµ¿À¸·Î + ½ÇÁ¦ ¼­¹ö·Î À¯µµÇÑ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

¸ÕÀú »ç¿ëÀÚ, ±×·ì, µ¶¸³Ã¼ÀÇ À§Ä¡ Á¤º¸¸¦ ÀúÀåÇÑ + (ºÐ»êµÈ) ¿ÜºÎ¸Ê¿¡ ½ÇÁ¦ ¼­¹ö Á¤º¸¸¦ ¾ò¾î¿Â´Ù. ¿ÜºÎ¸ÊÀº + ´ÙÀ½°ú °°Àº Çü½ÄÀÌ´Ù

+ +
+user1  server_of_user1
+user2  server_of_user2
+:      :
+
+ +

¿ì¸®´Â ÀÌ Á¤º¸¸¦ °¢°¢ map.xxx-to-host + ÆÄÀÏ¿¡ ÀúÀåÇß´Ù. ´ÙÀ½À¸·Î ¸ðµç ¼­¹ö¿¡¼­ URLÀÌ ¼­¹ö¿¡ + ¾ø´Ù¸é ´ÙÀ½°ú °°Àº URLÀ»,

+ +
+/u/user/anypath
+/g/group/anypath
+/e/entity/anypath
+
+ +

´ÙÀ½°ú °°ÀÌ ¸®´ÙÀÌ·º¼ÇÇÑ´Ù

+ +
+http://physical-host/u/user/anypath
+http://physical-host/g/group/anypath
+http://physical-host/e/entity/anypath
+
+ +

¾Æ·¡ ±ÔÄ¢Àº ¸ÊÆÄÀÏÀ» »ç¿ëÇÏ¿© ÀÌ ÀÛ¾÷À» ÇÑ´Ù (server0Àº + ¸Ê¿¡ Ç׸ñÀÌ ¾ø´Â °æ¿ì »ç¿ëÇÒ ±âº»¼­¹ö¶ó°í °¡Á¤ÇÑ´Ù):

+ +
+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/([^/]+)/?(.*)   http://${user-to-host:$1|server0}/u/$1/$2
+RewriteRule   ^/g/([^/]+)/?(.*)  http://${group-to-host:$1|server0}/g/$1/$2
+RewriteRule   ^/e/([^/]+)/?(.*) http://${entity-to-host:$1|server0}/e/$1/$2
+
+RewriteRule   ^/([uge])/([^/]+)/?$          /$1/$2/.www/
+RewriteRule   ^/([uge])/([^/]+)/([^.]+.+)   /$1/$2/.www/$3\
+
+
+
+ + + +

Ȩµð·ºÅ丮¸¦ ´Ù¸¥ À¥¼­¹ö·Î ÀÌÀü

+ + + +
+
»óȲ¼³¸í:
+ +
+

¸¹Àº À¥°ü¸®ÀÚ´Â À¥¼­¹öÀÇ ¸ðµç Ȩµð·ºÅ丮¸¦ ´Ù¸¥ + À¥¼­¹ö·Î ÀÌÀüÇÑ °æ¿ì ÇØ°áÃ¥À» ¹°¾îº»´Ù. ÀÌ ¹æ¹ýÀº + ÀÌÀü ¼­¹ö¸¦ ´ëüÇÒ »õ·Î¿î ¼­¹ö¸¦ ±¸¼ºÇϴµ¥ ½Ã°£ÀÌ + °É¸®´Â °æ¿ì¿¡ ÇÊ¿äÇÏ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

mod_rewrite¸¦ »ç¿ëÇÏ¸é °£´ÜÇÏ´Ù. + ÀÌÀü À¥¼­¹ö´Â ¸ðµç /~user/anypath URLÀ» + http://newserver/~user/anypath·Î + ¸®´ÙÀÌ·º¼ÇÇÏ¸é µÈ´Ù.

+ +
+RewriteEngine on
+RewriteRule   ^/~(.+)  http://newserver/~$1  [R,L]
+
+
+
+ + + +

Ȩµð·ºÅ丮 ±¸Á¶ ¸¸µé±â

+ + + +
+
»óȲ¼³¸í:
+ +
+

»ç¿ëÀÚ°¡ ¼öõ¸íÀÎ »çÀÌÆ®´Â º¸Åë Ȩµð·ºÅ丮 ±¸Á¶¸¦ + ¸¸µç´Ù. Áï, ¿¹¸¦ µé¾î À̸§ÀÌ »ç¿ëÀÚ¸íÀÇ Ã¹¹ø° ¹®ÀÚÀÎ + ÇÏÀ§µð·ºÅ丮¿¡ Ȩµð·ºÅ丮¸¦ µÐ´Ù. ±×·¡¼­, + /~foo/anypath´Â + /home/f/foo/.www/anypathÀÌ°í, + /~bar/anypath´Â + /home/b/bar/.www/anypathÀÌ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

¹°°áÇ¥½Ã°¡ ÀÖ´Â URLÀ» À§¿Í °°Àº ±¸Á¶·Î º¯È¯ÇϱâÀ§ÇØ + ´ÙÀ½ ±ÔÄ¢À» »ç¿ëÇÑ´Ù.

+ +
+RewriteEngine on
+RewriteRule   ^/~(([a-z])[a-z0-9]+)(.*)  /home/$2/$1/.www$3
+
+
+
+ + + +

ÆÄÀϽýºÅÛ À籸¼º

+ + + +
+
»óȲ¼³¸í:
+ +
+

ÀÌ ¿¹´Â ½Ç·Î ÇϵåÄÚ¾îÀûÀÌ´Ù: µð·ºÅ丮º° + RewriteRules¸¦ ¸Å¿ì ¸¹ÀÌ »ç¿ëÇÏ¿© ÀÚ·á + ÀÚü´Â ±×´ë·Î µÐü·Î À¥¿¡ ÀڷḦ ÀÚ¿¬½º·´°Ô ºê¶ó¿ì¡Çϵµ·Ï + ÇÑ´Ù. ¹è°æ: ³ª´Â 1992³â ºÎÅÍ ÀÚÀ¯·Ó°Ô »ç¿ëÇÒ ¼ö ÀÖ´Â + À¯´Ð½º ¼ÒÇÁÆ®¿þ¾îµéÀ» net.sw¿¡ + ¸ð¾ÆµÎ°í ÀÖ¾ú´Ù. ÀÌ´Â ³»°¡ ÄÄÇ»ÅÍ°úÇÐÀ» °øºÎÇϸ鼭 + ¿©·¯Çص¿¾È ¿©°¡½Ã°£¿¡ ½Ã½ºÅÛ °ü¸®ÀÚ¿Í ³×Æ®¿÷ °ü¸®ÀÚ¸¦ + ÇؿԱ⶧¹®¿¡ ³» Ãë¹ÌÀÌÀÚ ÀÏÀÌ´Ù. ¸ÅÁÖ¸¶´Ù »õ·Î ¼ÒÇÁÆ®¿þ¾î°¡ + Ãß°¡µÉ ¶§¸¶´Ù µð·ºÅ丮¸¦ ±í°Ô ¸¸µé¾î¿Ô´Ù:

+ +
+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/
+
+ +

1996³â 7¿ù ÀÌ ÀúÀå¼Ò¸¦ ¸ÚÀÖ´Â À¥ ÀÎÅÍÆäÀ̽º¸¦ ÅëÇØ + ¼¼»ó¿¡ °ø°³Çϱâ·Î °áÁ¤ÇÞ´Ù. "¸ÚÀÖ´Ù"´Â ¸»Àº, ÃÖ»óÀ§ + µð·ºÅ丮¿¡ CGI ½ºÅ©¸³Æ®¸¦ µÎÁö ¾Ê°íµµ, ÀúÀå¼Ò °èÃþ±¸Á¶¸¦ + Á÷Á¢ ºê¶ó¿ìÁúÇÏ±æ ¹Ù¶õ´Ù´Â ¶æÀÌ´Ù. ¿Ö? ÀúÀå¼Ò¸¦ ³ªÁß¿¡ + FTP·Îµµ Á¢±ÙÇÒ ¼ö ÀÖµµ·Ï ¸¸µé ¿¹Á¤ÀÌ¿´±â¶§¹®¿¡ À¥À̳ª + CGI¿Í °ü·ÃµÈ ³»¿ëÀ» °°ÀÌ µÎ±â ½È¾ú´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

ÇØ°áÃ¥Àº µÎ ºÎºÐÀ¸·Î ³ª´¶´Ù: ¸ÕÀú µð·ºÅ丮 ¼öÁØ¿¡¼­ + ÇÊ¿äÇÑ ¸ðµç ÆäÀÌÁö¸¦ µ¿ÀûÀ¸·Î ¸¸µå´Â CGI ½ºÅ©¸³Æ®°¡ + ÇÊ¿äÇÏ´Ù. ³ª´Â ÀÌ ½ºÅ©¸³Æ®µéÀ» ´ÙÀ½°ú °°ÀÌ + /e/netsw/.www/¿¡ µÎ¾ú´Ù:

+ +
+-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
+
+ +

DATA/ ÇÏÀ§µð·ºÅ丮¿¡ À§¿¡¼­ ¸»ÇÑ ÀúÀå¼Ò°¡ + ÀÖ´Ù. ½ÇÁ¦ net.swÀÇ ³»¿ëÀº º¸Åë + rdist¸¦ »ç¿ëÇÏ¿© ÀÚµ¿À¸·Î °¡Á®¿Â´Ù. µÎ¹ø° + ºÎºÐÀÌ ³²¾Ò´Ù: ¾î¶»°Ô ÀÌ µÎ ±¸Á¶¸¦ ÇϳªÀÇ ÀÚ¿¬½º·¯¿î + URL ±¸Á¶·Î ¿¬°áÇϴ°¡? »ç¿ëÀÚ¿¡°Ô DATA/ + µð·ºÅ丮¸¦ °¨Ãß°í, URL¸¶´Ù ÀûÀýÇÑ CGI ½ºÅ©¸³Æ®¸¦ ½ÇÇàÇÏ°í + ½Í´Ù. ÇØ°áÃ¥Àº ´ÙÀ½°ú °°´Ù: ¸ÕÀú ¼­¹öÀÇ DocumentRoot¿¡¼­ °ø°³µÈ + URL /net.sw/¸¦ ³»ºÎ °æ·Î /e/netsw·Î + ÀçÀÛ¼ºÇϱâÀ§ÇØ µð·ºÅ丮º° ¼³Á¤ÆÄÀÏ¿¡ ´ÙÀ½°ú °°ÀÌ ¼³Á¤ÇÑ´Ù:

+ +
+RewriteRule  ^net.sw$       net.sw/        [R]
+RewriteRule  ^net.sw/(.*)$  e/netsw/$1
+
+ +

ù¹ø° ±ÔÄ¢Àº ¸¶Áö¸·¿¡ ½½·¡½¬°¡ ¾ø´Â ¿äûÀ» À§Çؼ­ + »ç¿ëÇß´Ù! µÎ¹ø° ±ÔÄ¢ÀÌ ½ÇÁ¦ ÀÛ¾÷À» ÇÑ´Ù. ±×¸®°í µð·ºÅ丮º° + ¼³Á¤ÆÄÀÏ /e/netsw/.www/.wwwacl¿¡ °áÁ¤ÀûÀÎ + ¼³Á¤ÀÌ ³ª¿Â´Ù:

+ +
+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
+
+ +

Çؼ®À» À§ÇÑ ÈùÆ®:

+ +
    +
  1. ³×¹ø° ºÎºÐ¿¡¼­ ´ëü Çʵå('-')°¡ + ¾ø°í L (last) Ç÷¡±×°¡ ÀÖÀ½À» ÁÖ¸ñÇ϶ó
  2. + +
  3. ¸¶Áö¸· ºÎºÐ¿¡¼­ ù¹ø° ±ÔÄ¢¿¡ ! + (not) ¹®ÀÚ¿Í C (chain) Ç÷¡±×¸¦ ÁÖ¸ñÇ϶ó
  4. + +
  5. ¸¶Áö¸· ±ÔÄ¢¿¡¼­ ±âŸ ÇØ´çÇÏÁö ¾Ê´Â ¸ðµç °æ¿ì¸¦ + Àâ¾Æ³»´Â ÆÐÅÏÀ» ÁÖ¸ñÇ϶ó
  6. +
+
+
+ + + +

NCSA imagemapÀ» ¾ÆÆÄÄ¡ mod_imapÀ¸·Î

+ + + +
+
»óȲ¼³¸í:
+ +
+

»ç¶÷µéÀº NCSA À¥¼­¹ö¿¡¼­ Çö´ëÀûÀÎ ¾ÆÆÄÄ¡ À¥¼­¹ö·Î + ÀÚ¿¬½º·´°Ô ¿Å°Ü°¡±æ ¹Ù¶õ´Ù. ±×·¡¼­ ¿À·¡µÈ NCSA + imagemap ÇÁ·Î±×·¥À» »ç¿ëÇÑ ÆäÀÌÁö¸¦ Çö´ëÀûÀÎ + ¾ÆÆÄÄ¡ mod_imap·Î ó¸®ÇÏ±æ ¹Ù¶õ´Ù. + ¹®Á¦´Â imagemap ÇÁ·Î±×·¥À» + /cgi-bin/imagemap/path/to/page.map°ú + °°ÀÌ ÂüÁ¶ÇÏ´Â ÇÏÀÌÆÛ¸µÅ©°¡ ¸¹´Ù´Â °ÍÀÌ´Ù. ¾ÆÆÄÄ¡´Â + /path/to/page.map°ú °°Àº ¿äûÀ» ¹Þ¾Æ¾ß + ÇÑ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

¸ðµç ¿äû¿¡¼­ ¾ÕºÎºÐÀ» µ¿ÀûÀ¸·Î Á¦°ÅÇÏ´Â Àü¿ª ±ÔÄ¢À» + »ç¿ëÇÑ´Ù:

+ +
+RewriteEngine  on
+RewriteRule    ^/cgi-bin/imagemap(.*)  $1  [PT]
+
+
+
+ + + +

¿©·¯ µð·ºÅ丮¿¡¼­ ÆäÀÌÁö °Ë»ö

+ + + +
+
»óȲ¼³¸í:
+ +
+

°¡²û À¥¼­¹ö°¡ ¿©·¯ µð·ºÅ丮¿¡¼­ ÆÄÀÏÀ» ã¾Æ¾ß ÇÒ + ¶§°¡ ÀÖ´Ù. ÀÌ °æ¿ì MultiViews³ª ´Ù¸¥ ¹æ¹ýÀº µµ¿òÀÌ + ¾ÈµÈ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

¿©·¯ µð·ºÅ丮¿¡¼­ ÆÄÀÏÀ» ã´Â ±ÔÄ¢À» Á÷Á¢ ÇÁ·Î±×·¥ÇÑ´Ù.

+ +
+RewriteEngine on
+
+#   ¸ÕÀú custom/¿¡¼­ ã±æ ½ÃµµÇÏ°í...
+#   ...ãÀ¸¸é ³¡!
+RewriteCond         /your/docroot/dir1/%{REQUEST_FILENAME}  -f
+RewriteRule  ^(.+)  /your/docroot/dir1/$1  [L]
+
+#   µÎ¹ø°·Î pub/¿¡¼­ ã±æ ½ÃµµÇÑ´Ù...
+#   ...ãÀ¸¸é ³¡!
+RewriteCond         /your/docroot/dir2/%{REQUEST_FILENAME}  -f
+RewriteRule  ^(.+)  /your/docroot/dir2/$1  [L]
+
+#   ¸øãÀ¸¸é ´Ù¸¥ Alias³ª ScriptAlias Áö½Ã¾î µîÀ¸·Î ÁøÇàÇÑ´Ù.
+RewriteRule   ^(.+)  -  [PT]
+
+
+
+ + + +

URL¿¡ µû¶ó ȯ°æº¯¼ö¸¦ ¼³Á¤ÇÑ´Ù

+ + + +
+
»óȲ¼³¸í:
+ +
+

¿äûµé°£¿¡ »óÅÂÁ¤º¸¸¦ À¯ÁöÇϱâÀ§ÇØ URL¿¡ Á¤º¸¸¦ + ÀÎÄÚµùÇÏ´Â ¹æ¹ýµµ ÀÖ´Ù. ±×·¯³ª ´ÜÁö ÀÌ Á¤º¸¸¦ Á¦°ÅÇϱâÀ§ÇØ + ¸ðµç ÆäÀÌÁö¿¡ CGI wrapper¸¦ »ç¿ëÇÏ°í ½ÍÁö ¾Ê´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

ÀçÀÛ¼º ±ÔÄ¢À» »ç¿ëÇÏ¿© »óÅÂÁ¤º¸¸¦ ÃßÃâÇÏ°í, ÃßÃâÇÑ + Á¤º¸¸¦ ³ªÁß¿¡ XSSI³ª CGI¿¡¼­ »ç¿ëÇϱâÀ§ÇØ È¯°æº¯¼ö¿¡ + ÀúÀåÇÑ´Ù. ±×·¡¼­ URL /foo/S=java/bar/´Â + /foo/bar/·Î º¯È¯µÇ°í STATUS¶ó´Â + ȯ°æº¯¼ö °ªÀ» "java"·Î ¼³Á¤ÇÑ´Ù.

+ +
+RewriteEngine on
+RewriteRule   ^(.*)/S=([^/]+)/(.*)    $1/$3 [E=STATUS:$2]
+
+
+
+ + + +

°¡»ó »ç¿ëÀÚ È£½ºÆ®

+ + + +
+
»óȲ¼³¸í:
+ +
+

°¡»óÈ£½ºÆ®¸¦ »ç¿ëÇÏÁö ¾Ê°í °°Àº ÄÄÇ»ÅÍ·Î DNS A + ·¹Äڵ带 ¼³Á¤ÇÏ¿© + www.username.host.domain.comÀ» + »ç¿ëÀÚÀÇ È¨ÆäÀÌÁö·Î Á¦°øÇÏ°í ½Í´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

HTTP/1.0 ¿äûÀÇ °æ¿ì ¹æ¹ýÀÌ ¾øÁö¸¸, Host: HTTP + Çì´õ¸¦ Æ÷ÇÔÇÑ HTTP/1.1 ¿äûÀº ´ÙÀ½ ±ÔÄ¢À» »ç¿ëÇÏ¿© + ³»ºÎÀûÀ¸·Î http://www.username.host.com/anypath¸¦ + /home/username/anypath·Î ÀçÀÛ¼ºÇÒ ¼ö + ÀÖ´Ù:

+ +
+RewriteEngine on
+RewriteCond   %{HTTP_HOST}                 ^www\.[^.]+\.host\.com$
+RewriteRule   ^(.+)                        %{HTTP_HOST}$1          [C]
+RewriteRule   ^www\.([^.]+)\.host\.com(.*) /home/$1$2
+
+
+
+ + + +

Ȩµð·ºÅ丮¸¦ ¿ÜºÎ ¼­¹ö·Î ¸®´ÙÀÌ·º¼Ç

+ + + +
+
»óȲ¼³¸í:
+ +
+

Áö¿ª µµ¸ÞÀÎ ourdomain.com ¹Û¿¡¼­ ¿äûÀÌ + µé¾î¿À¸é Ȩµð·ºÅ丮 URLÀ» ´Ù¸¥ À¥¼­¹ö + www.somewhere.comÀ¸·Î ¸®´Ù¸®·º¼ÇÇϱæ + ¹Ù¶õ´Ù. Á¾Á¾ °¡»óÈ£½ºÆ® »ç¿ëÀå¼Ò¿¡¼­ »ç¿ëÇÑ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

ÀçÀÛ¼º Á¶°ÇÀ» »ç¿ëÇÏ¸é µÈ´Ù:

+ +
+RewriteEngine on
+RewriteCond   %{REMOTE_HOST}  !^.+\.ourdomain\.com$
+RewriteRule   ^(/~.+)         http://www.somewhere.com/$1 [R,L]
+
+
+
+ + + +

½ÇÆÐÇÑ URLÀ» ´Ù¸¥ À¥¼­¹ö·Î ¸®´ÙÀÌ·º¼Ç

+ + + +
+
»óȲ¼³¸í:
+ +
+

URL ÀçÀÛ¼º¿¡ ´ëÇؼ­ À¥¼­¹ö A¿¡ ÇØ´ç ÆÄÀÏÀÌ ¾ø´Â + °æ¿ì À¥¼­¹ö B·Î ¿äûÀ» ¸®´ÙÀÌ·º¼ÇÇÏ´Â ¹æ¹ýÀ» ÀÚÁÖ + ¹°¾îº»´Ù. º¸Åë Perl·Î ÀÛ¼ºÇÑ ErrorDocument CGI ½ºÅ©¸³Æ®¸¦ + »ç¿ëÇÏÁö¸¸, mod_rewrite¸¦ »ç¿ëÇÏ´Â + ¹æ¹ýµµ ÀÖ´Ù. ±×·¯³ª ¼º´ÉÀº ErrorDocument CGI ½ºÅ©¸³Æ®º¸´Ù + ¶³¾îÁüÀ» ¸í½ÉÇ϶ó!

+
+ +
ÇØ°áÃ¥:
+ +
+

ù¹ø° ¹æ¹ýÀº ºü¸£Áö¸¸ À¯¿¬¼ºÀÌ ¶³¾îÁö°í ¿ÏÀüÇÏÁö + ¾Ê´Ù:

+ +
+RewriteEngine on
+RewriteCond   /your/docroot/%{REQUEST_FILENAME} !-f
+RewriteRule   ^(.+)                             http://webserverB.dom/$1
+
+ +

ÀÌ ¹æ¹ýÀÇ ´ÜÁ¡Àº DocumentRoot ¾È¿¡ ÀÖ´Â ÆäÀÌÁö¸¸ + °¡´ÉÇÏ´Ù´Â Á¡ÀÌ´Ù. (¿¹¸¦ µé¾î Ȩµð·ºÅ丮 µîÀ» À§ÇØ) + Á¶°ÇÀ» Ãß°¡ÇÒ ¼ö ÀÖÁö¸¸, ´õ ÁÁÀº ¹æ¹ýÀÌ ÀÖ´Ù:

+ +
+RewriteEngine on
+RewriteCond   %{REQUEST_URI} !-U
+RewriteRule   ^(.+)          http://webserverB.dom/$1
+
+ +

mod_rewriteÀÇ URL Àü¹æÂüÁ¶(look-ahead)¸¦ + »ç¿ëÇÑ´Ù. ±×·¡¼­ ¸ðµç URL¿¡ µ¿ÀÛÇÏ°í ¾ÈÀüÇÏ´Ù. ±×·¯³ª + ¸ðµç ¿äû¸¶´Ù ³»ºÎ ÇÏÀ§¿äûÀ» Çѹø ´õ Çϱ⶧¹®¿¡ À¥¼­¹ö + ¼º´É¿¡ ¾Ç¿µÇâÀ» ÁØ´Ù. ±×·¡¼­ °­·ÂÇÑ CPU¿¡¼­ À¥¼­¹ö¸¦ + ½ÇÇàÇÑ´Ù¸é »ç¿ëÇ϶ó. ÄÄÇ»ÅÍ°¡ ´À¸®´Ù¸é ù¹ø° ¹æ¹ýÀ̳ª + ´õ ³ªÀº ErrorDocument + CGI ½ºÅ©¸³Æ®¸¦ »ç¿ëÇ϶ó.

+
+
+ + + +

È®Àå ¸®´ÙÀÌ·º¼Ç

+ + + +
+
»óȲ¼³¸í:
+ +
+

°¡²û ¸®´ÙÀÌ·º¼ÇÇÏ´Â URLÀ» ´õ Á¶ÀýÇÒ ÇÊ¿ä°¡ ÀÖ´Ù. + ¾ÆÆÄÄ¡ ³»ºÎ URL escape ÇÔ¼ö´Â "url#anchor" + °°Àº URLÀÇ anchorµµ escapeÇÑ´Ù. ¾ÆÆÄÄ¡ÀÇ + uri_escape() ÇÔ¼ö´Â ¿ì¹°Á¤ÀÚ(#)µµ °°ÀÌ + escapeÇϹǷΠ»ç¿ëÇÒ ¼ö ¾ø´Ù. ±×·¯¸é ¾î¶»°Ô ÀÌ·± URL·Î + ¸®´ÙÀÌ·º¼ÇÇÒ ¼ö ÀÖ³ª?

+
+ +
ÇØ°áÃ¥:
+ +
+

Á÷Á¢ ¸®´ÙÀÌ·º¼ÇÇÏ´Â NPH-CGI ½ºÅ©¸³Æ®¸¦ »ç¿ëÇÑ ÇØ°áÃ¥ÀÌ + ÇÊ¿äÇÏ´Ù. escape¸¦ ÇÏÁö ¾Ê±â¶§¹®ÀÌ´Ù (NPH=non-parseable + headers). ¸ÕÀú ´ÙÀ½ ¼­¹ö¼³Á¤À» ÇÏ¿© (ÀçÀÛ¼º ±ÔÄ¢ÀÇ + ³¡ºÎºÐ¿¡ »ç¿ëÇØ¾ß ÇÑ´Ù) »õ·Î¿î URL scheme + xredirect:¸¦ µµÀÔÇÑ´Ù:

+ +
+RewriteRule ^xredirect:(.+) /path/to/nph-xredirect.cgi/$1 \
+            [T=application/x-httpd-cgi,L]
+
+ +

±×·¯¸é xredirect:·Î ½ÃÀÛÇÏ´Â ¸ðµç URLÀº + nph-xredirect.cgi ÇÁ·Î±×·¥À» ÅëÇÏ°Ô µÈ´Ù. + ÇÁ·Î±×·¥Àº ´ÙÀ½°ú °°´Ù:

+ +
+#!/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##
+
+ +

±×·¯¸é mod_rewrite°¡ Á÷Á¢ ¹ÞÁö¸øÇÏ´Â + ¸ðµç URL schemeÀ¸·Î ¸®´ÙÀÌ·º¼ÇÇÒ ¼ö ÀÖ´Ù. ¿¹¸¦ µé¾î, + ´ÙÀ½°ú °°ÀÌ news:newsgroupÀ¸·Î ¸®´ÙÀÌ·º¼ÇÇÒ + ¼ö ÀÖ´Ù

+ +
+RewriteRule ^anyurl  xredirect:news:newsgroup
+
+ +
ÁÖÀÇ: À§ÀÇ Æ¯º°ÇÑ "Åë°ú" ±ÔÄ¢À» »ç¿ëÇÏ¿© + xredirect:¸¦ ¸¶Áö¸·¿¡ È®ÀåÇØ¾ß Çϱ⶧¹®¿¡ + ±ÔÄ¢¿¡ [R]À̳ª [R,L]À» »ç¿ëÇϸé + ¾ÈµÈ´Ù.
+
+
+ + + +

ÀúÀå¼Ò Á¢±Ù Áß°è(multiplexer)

+ + + +
+
»óȲ¼³¸í:
+ +
+

http://www.perl.com/CPAN¿¡ + ÀÖ´Â ´ë´ÜÇÑ CPAN (Comprehensive Perl Archive Network)À» + ¾Æ´Â°¡? ÀÌ ÁÖ¼Ò´Â ¼¼°è¿¡ Èð¾îÁø ¿©·¯ CPAN ¹Ì·¯ FTP + ¼­¹öÁß Å¬¶óÀ̾ðÆ®¿¡ °¡±îÀÌ ÀÖ´Â ¼­¹ö·Î ¸®´ÙÀÌ·º¼ÇÇÑ´Ù. + À̸¦ FTP Á¢±Ù Áß°è ¼­ºñ½º¶ó°í ÇÑ´Ù. CPANÀº CGI ½ºÅ©¸³Æ®¸¦ + »ç¿ëÇÏÁö¸¸, mod_rewrite¸¦ »ç¿ëÇÏ¿© + ºñ½ÁÇÏ°Ô ¸¸µé ¼ö ÀÖÀ»±î?

+
+ +
ÇØ°áÃ¥:
+ +
+

¸ÕÀú mod_rewrite 3.0.0 ¹öÀüºÎÅÍ + ¸®´ÙÀÌ·º¼Ç¿¡ "ftp:" schemeÀ» »ç¿ëÇÒ ¼ö + ÀÖ´Ù. ´ÙÀ½À¸·Î Ŭ¶óÀ̾ðÆ®ÀÇ ÃÖ»óÀ§ µµ¸ÞÀÎÀ» RewriteMap°ú °°ÀÌ + »ç¿ëÇÏ¿© À§Ä¡¸¦ ÃßÁ¤ÇÒ ¼ö ÀÖ´Ù. º¹ÀâÈ÷ ¿«ÀÎ ±ÔÄ¢¿¡¼­ + ÃÖ»óÀ§ µµ¸ÞÀÎÀ» Áß°è¸ÊÀÇ Å°·Î »ç¿ëÇÑ´Ù.

+ +
+RewriteEngine on
+RewriteMap    multiplex                txt:/path/to/map.cxan
+RewriteRule   ^/CxAN/(.*)              %{REMOTE_HOST}::$1                 [C]
+RewriteRule   ^.+\.([a-zA-Z]+)::(.*)$  ${multiplex:$1|ftp.default.dom}$2  [R,L]
+
+ +
+##
+##  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##
+
+
+
+ + + +

½Ã°£¿¡ µû¸¥ ÀçÀÛ¼º

+ + + +
+
»óȲ¼³¸í:
+ +
+

½Ã°£¿¡ µû¶ó ´Ù¸¥ ³»¿ëÀ» ¼­ºñ½ºÇÏ´Â °æ¿ì ¸¹Àº À¥°ü¸®ÀÚ´Â + Àá½Ã Ưº°ÇÑ ÆäÀÌÁö·Î ¸®´ÙÀÌ·º¼ÇÇϱâÀ§ÇØ CGI ½ºÅ©¸³Æ®¸¦ + »ç¿ëÇÑ´Ù. mod_rewrite·Î´Â ¾î¶»°Ô + ÇÒ ¼ö Àִ°¡?

+
+ +
ÇØ°áÃ¥:
+ +
+

ÀçÀÛ¼º Á¶°Ç¿¡¼­ »ç¿ëÇÒ ¼ö ÀÖ´Â ¿©·¯ TIME_xxx + º¯¼ö°¡ ÀÖ´Ù. º¯¼ö¿Í Ưº°ÇÑ »çÀü¼ø¼­ ºñ±³ + <STRING, >STRING, + =STRINGÀ» »ç¿ëÇÏ¿© ½Ã°£¿¡ µû¶ó ¸®´ÙÀÌ·º¼ÇÇÒ + ¼ö ÀÖ´Ù:

+ +
+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
+
+ +

URL foo.htmlÀ» ¿äûÇϸé + 07:00-19:00 µ¿¾È foo.day.html + ³»¿ëÀ» ¼­ºñ½ºÇÏ°í, ³ª¸ÓÁö ½Ã°£ µ¿¾È + foo.night.html ³»¿ëÀ» ¼­ºñ½ºÇÑ´Ù. ȨÆäÀÌÁö¿¡¼­ + »ç¿ëÇϱâ ÁÁÀº ±â´ÉÀÌ´Ù...

+
+
+ + + +

YYYY¸¦ XXXX·Î ÀÌÀüÇÑ °æ¿ì ¿ªÈ£È¯

+ + + +
+
»óȲ¼³¸í:
+ +
+

¿©·¯ .html ÆÄÀÏÀ» .phtml·Î + º¯È¯ÇÏ´Â µî document.YYYY¸¦ + document.XXXX·Î ÀÌÀüÇÑÈÄ ¿ªÈ£È¯(backward + compatibility) URLÀ» (°¡»óÀûÀ¸·Î Á¸ÀçÇÏ°Ô) ¸¸µé ¼ö + ÀÖ³ª?

+
+ +
ÇØ°áÃ¥:
+ +
+

À̸§À» ±âº»À̸§À¸·Î ÀçÀÛ¼ºÇÑÈÄ »õ·Î¿î È®ÀåÀÚ¸¦ + °¡Áø ÆÄÀÏÀÌ ÀÖ´ÂÁö °Ë»çÇÑ´Ù. ÀÖ´Ù¸é ±× ÆÄÀϸíÀ» »ç¿ëÇÏ°í, + ¾øÀ¸¸é URLÀ» ¿ø·¡ »óÅ·ΠÀçÀÛ¼ºÇÑ´Ù.

+ + +
+#   ¹®¼­.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
+
+
+
+ + + +
top
+
+

ÄÁÅÙÃ÷ ´Ù·ç±â

+ + + +

»õ·Î ÀÌÀü (°¨Ãß±â)

+ + + +
+
»óȲ¼³¸í:
+ +
+

ÃÖ±Ù foo.htmlÀ» bar.html·Î + º¯°æÇÏ°í ¿ªÈ£È¯¼ºÀ» À§ÇØ ÀÌÀü URLÀ» °è¼Ó Á¦°øÇÏ°í + ½Í´Ù°í °¡Á¤ÇÏÀÚ. »ç¿ëÀÚ´Â ÀÌÀü URLÀÌ º¯°æµÇ¾ú´Ù´Â + »ç½ÇÀ» ´«Ä¡Ã¤Áö ¸øÇÑ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

´ÙÀ½ ±ÔÄ¢À¸·Î ÀÌÀü URLÀ» ³»ºÎÀûÀ¸·Î »õ·Î¿î URL·Î + ÀçÀÛ¼ºÇÑ´Ù:

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^foo\.html$  bar.html
+
+
+
+ + + +

»õ·Î ÀÌÀü (¾Ë¸®±â)

+ + + +
+
»óȲ¼³¸í:
+ +
+

´Ù½Ã foo.htmlÀ» bar.html·Î + º¯°æÇÏ°í ¿ªÈ£È¯¼ºÀ» À§ÇØ ÀÌÀü URLÀ» °è¼Ó Á¦°øÇÏ°í + ½Í´Ù°í °¡Á¤ÇÏÀÚ. ±×·¯³ª ÀÌÁ¦´Â ÀÌÀü URLÀ» »ç¿ëÇϸé + »ç¿ëÀÚ¿¡°Ô »õ·Î¿î URLÀ» ÈùÆ®·Î ¾Ë·ÁÁØ´Ù. Áï, ºê¶ó¿ìÀú + ÁÖ¼ÒâÀÌ º¯ÇÑ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

»õ·Î¿î URL·Î HTTP ¸®´ÙÀÌ·º¼ÇÇÏ´Ù. ±×·¯¸é ºê¶ó¿ìÀú°¡ + »õ·Î¿î URL¸¦ º¸ÀÌ°í º¯°æ»ç½ÇÀ» »ç¿ëÀÚ°¡ ¾Ë°ÔµÈ´Ù:

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^foo\.html$  bar.html  [R]
+
+
+
+ + + +

ºê¶ó¿ìÀú¿¡ µû¸¥ ³»¿ë

+ + + +
+
»óȲ¼³¸í:
+ +
+

ÃÖ¼ÒÇÑ Áß¿äÇÑ ÃÖ»óÀ§ ÆäÀÌÁö´Â ºê¶ó¿ìÀú¿¡ ÃÖÀûÈ­µÈ + ³»¿ëÀ¸·Î ¼­ºñ½ºÇؾßÇÒ °æ¿ì°¡ ÀÖ´Ù. Áï, ÃֽŠNetscape + ºê¶ó¿ìÀú¿¡°Ô´Â ÃÖ»óÀÇ ¹öÀüÀ», Lynx ºê¶ó¿ìÀú¿¡°Ô´Â + ÃÖÀú ¹öÀüÀ», ³ª¸ÓÁö ºê¶ó¿ìÀú¿¡´Â Æò±ÕÀûÀÎ ¹öÀüÀ» + Á¦°øÇÑ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

ºê¶ó¿ìÀú°¡ ³»¿ëÇù»óÀ» À§ÇØ ÀÚ½ÅÀÇ Á¾·ù¿¡ ´ëÇÑ Á¤º¸¸¦ + Á¦°øÇÏÁö ¾Ê±â¶§¹®¿¡ ³»¿ëÇù»óÀ» »ç¿ëÇÒ ¼ö ¾ø´Ù. ´ë½Å + HTTP "User-Agent" Çì´õ¸¦ »ç¿ëÇÑ´Ù. ´ÙÀ½ ±ÔÄ¢Àº HTTP + "User-Agent" Çì´õ°¡ "Mozilla/3"À¸·Î ½ÃÀÛÇϸé + foo.html ÆäÀÌÁö¸¦ foo.NS.html·Î + ÀçÀÛ¼ºÇÏ°í ÀçÀÛ¼ºÀ» Áß´ÜÇÑ´Ù. ºê¶ó¿ìÀú°¡ "Lynx"³ª + "Mozilla" ¹öÀü 1 ȤÀº 2¶ó¸é URLÀº + foo.20.htmlÀÌ µÈ´Ù. ³ª¸ÓÁö ºê¶ó¿ìÀú´Â + foo.32.html ÆäÀÌÁö¸¦ ¹Þ´Â´Ù. ¾Æ·¡ ±ÔÄ¢ÀÌ + ÀÌ ÀÛ¾÷À» ÇÑ´Ù:

+ +
+RewriteCond %{HTTP_USER_AGENT}  ^Mozilla/3.*
+RewriteRule ^foo\.html$         foo.NS.html          [L]
+
+RewriteCond %{HTTP_USER_AGENT}  ^Lynx/.*         [OR]
+RewriteCond %{HTTP_USER_AGENT}  ^Mozilla/[12].*
+RewriteRule ^foo\.html$         foo.20.html          [L]
+
+RewriteRule ^foo\.html$         foo.32.html          [L]
+
+
+
+ + + +

µ¿Àû ¹Ì·¯

+ + + +
+
»óȲ¼³¸í:
+ +
+

¿ÜºÎ È£½ºÆ®¿¡ ¿ì¸® »çÀÌÆ®·Î °¡Á®¿À°í ½ÍÀº ÁÁÀº + À¥ÆäÀÌÁö°¡ ÀÖ´Ù°í °¡Á¤ÇÏÀÚ. FTP ¼­¹öÀÇ °æ¿ì Á÷Á¢ ¿ÜºÎ + ÀÚ·áÀÇ Ãֽź¹»çº»À» À¯ÁöÇÏ´Â mirror ÇÁ·Î±×·¥À» + »ç¿ëÇÒ ¼ö ÀÖ°í, À¥¼­¹ö¶ó¸é HTTP·Î ºñ½ÁÇÑ ÀÛ¾÷À» ÇÏ´Â + webcopy ÇÁ·Î±×·¥À» »ç¿ëÇÒ ¼ö ÀÖ´Ù. ±×·¯³ª + µÎ ¹æ¹ý ¸ðµÎ ´ÜÁ¡ÀÌ ÀÖ´Ù: º¹»çº»Àº °¡²û¾¿ ÇÁ·Î±×·¥À» + ½ÇÇàÇØÁÙ ¶§¸¸ ÃÖ½ÅÆÇÀ¸·Î À¯ÁöµÈ´Ù. Á÷Á¢ ±¸¼ºÇؾßÇÏ´Â + Á¤ÀûÀÎ ¹Ì·¯°¡ ¾Æ´Ï¶ó¸é ÁÁ°Ú´Ù. ´ë½Å (¿ÜºÎ È£½ºÆ®¿¡¼­ + ÀÚ·á°¡ °»½ÅµÇ¸é) ÇÊ¿äÇÒ¶§ ÀÚµ¿À¸·Î ÀڷḦ °»½ÅÇÏ´Â + µ¿Àû ¹Ì·¯°¡ ÇÊ¿äÇÏ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

À̸¦ À§ÇØ Proxy Throughput ±â´ÉÀ» (Ç÷¡±× + [P]) »ç¿ëÇÏ¿© ¿ÜºÎ À¥ÆäÀÌÁö ȤÀº ¿ÜºÎ + À¥°ø°£ Àüü¸¦ ¿ì¸® À̸§°ø°£À¸·Î ´ëÀÀÇÑ´Ù:

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^hotsheet/(.*)$  http://www.tstimpreso.com/hotsheet/$1  [P]
+
+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^usa-news\.html$   http://www.quux-corp.com/news/index.html  [P]
+
+
+
+ + + +

µ¿Àû ¿ª¹Ì·¯

+ + + +
+
»óȲ¼³¸í:
+ +
...
+ +
ÇØ°áÃ¥:
+ +
+
+RewriteEngine on
+RewriteCond   /mirror/of/remotesite/$1           -U
+RewriteRule   ^http://www\.remotesite\.com/(.*)$ /mirror/of/remotesite/$1
+
+
+
+ + + +

¾ø´Â ÀڷḦ ÀÎÆ®¶ó³Ý¿¡¼­ °¡Á®¿À±â

+ + + +
+
»óȲ¼³¸í:
+ +
+

½ÇÁ¦ ÀڷḦ ¹æÈ­º®ÀÌ º¸È£ÇÏ´Â (³»ºÎ) ÀÎÆ®¶ó³Ý À¥¼­¹ö¿¡ + (www2.quux-corp.dom) ÀúÀåÇϸ鼭, ±â¾÷ÀÇ + (¿ÜºÎ) ÀÎÅÍ³Ý À¥¼­¹ö¸¦ (www.quux-corp.dom) + ½ÇÇàÇÏ´Â °Íó·³ º¸ÀÌ°Ô ÇÑ´Ù. ¿ÜºÎ À¥¼­¹ö´Â ¿äûÇÑ + ÀڷḦ ³»ºÎ À¥¼­¹ö¿¡¼­ °¡Á®¿Â´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

¸ÕÀú ¹æÈ­º®ÀÌ ³»ºÎ À¥¼­¹ö¸¦ º¸È£ÇÏ°í ¿ÜºÎ À¥¼­¹ö¸¸ÀÌ + ³»ºÎ À¥¼­¹ö¿¡¼­ ÀڷḦ ¾òÀ» ¼ö ÀÖ°Ô ÇÑ´Ù. ´ÙÀ½°ú °°ÀÌ + ÆÐŶÇÊÅ͸µ ¹æÈ­º®À» ¼³Á¤ÇÑ´Ù:

+ +
+ALLOW Host www.quux-corp.dom Port >1024 --> Host www2.quux-corp.dom Port 80
+DENY  Host *                 Port *     --> Host www2.quux-corp.dom Port 80
+
+ +

½ÇÁ¦ ¼³Á¤¹®¹ý¿¡ ¾Ë¸Â°Ô °íÃĶó. ¾ø´Â ÀڷḦ ³»ºÎÀûÀ¸·Î + proxy throughput ±â´ÉÀ» ÅëÇØ ¿äûÇÏ´Â + mod_rewrite ±ÔÄ¢À» ÀÛ¼ºÇÑ´Ù:

+ +
+RewriteRule ^/~([^/]+)/?(.*)          /home/$1/.www/$2
+RewriteCond %{REQUEST_FILENAME}       !-f
+RewriteCond %{REQUEST_FILENAME}       !-d
+RewriteRule ^/home/([^/]+)/.www/?(.*) http://www2.quux-corp.dom/~$1/pub/$2 [P]
+
+
+
+ + + +

·Îµå¹ë·±½Ì (ºÎÇÏ ºÐ»êÇϱâ)

+ + + +
+
»óȲ¼³¸í:
+ +
+

www.foo.comÀÇ Åë½Å·®À» + www[0-5].foo.com (ÃÑ ¼­¹ö 6´ë)À¸·Î ºÐ»êÇÏ°í + ½Í´Ù. ¾î¶»°Ô Çϴ°¡?

+
+ +
ÇØ°áÃ¥:
+ +
+

¸Å¿ì ´Ù¾çÇÑ ¹æ¹ýÀ¸·Î ÀÌ ¹®Á¦¸¦ ÇØ°áÇÒ ¼ö ÀÖ´Ù. + ¸ÕÀú DNS¸¦ »ç¿ëÇÑ Àß ¾Ë·ÁÁø ¹æ¹ýÀ» ¼³¸íÇÏ°í, + mod_rewrite¸¦ »ç¿ëÇÏ´Â °æ¿ì¸¦ »ìÆ캸ÀÚ:

+ +
    +
  1. + DNS Round-Robin + +

    °¡Àå °£´ÜÇÑ ·Îµå¹ë·±½Ì ¹æ¹ýÀº BINDÀÇ + DNS round-robin ¹æ½ÄÀ» »ç¿ëÇÏ´Â °ÍÀÌ´Ù. ´ÙÀ½°ú + °°ÀÌ DNS A(address) ·¹Äڵ忡 + www[0-9].foo.comÀ» ¼³Á¤ÇÑ´Ù.

    + +
    +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
    +
    + +

    ±×¸®°í ´ÙÀ½ Ç׸ñÀ» Ãß°¡ÇÑ´Ù:

    + +
    +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.
    +
    + +

    À߸øµÈ °Íó·³ º¸ÀÌÁö¸¸, ½ÇÁ¦·Î BINDÀÇ + ÀǵµµÈ ±â´ÉÀÌ´Ù. ÀÌÁ¦ www.foo.comÀ» + ãÀ¸¸é, BIND´Â ¸Å¹ø ¼ø¼­¸¦ Á¶±Ý¾¿ + ¹Ù²ã°¡¸ç www0-www6À» ¹ÝȯÇÑ´Ù. ±×·¡¼­ + Ŭ¶óÀ̾ðÆ®µéÀ» ¿©·¯ ¼­¹ö·Î ºÐ»êÇÑ´Ù. ±×·¯³ª DNS + °Ë»ö °á°ú°¡ ³×Æ®¿÷ÀÇ ´Ù¸¥ ³×ÀÓ¼­¹ö¿¡ ij½¬µÇ¿© + www.foo.comÀ» ãÀº °á°ú°¡ ƯÁ¤ + wwwN.foo.comÀ̸é Ŭ¶óÀ̾ðÆ®ÀÇ ´ÙÀ½ + ¿äûµéµµ °°Àº wwwN.foo.comÀ¸·Î + º¸³»Áö±â¶§¹®¿¡ ¿Ïº®ÇÑ ·Îµå¹ë·±½Ì ±â¹ýÀÌ ¾Æ´ÔÀ» + ÁÖÀÇÇ϶ó. ±×·¯³ª Å©°Ô º¸¸é ¿äûÀÌ ¿©·¯ À¥¼­¹ö¿¡ + ºÐ»êµÇ¹Ç·Î È¿°ú°¡ ÁÁ´Ù.

    +
  2. + +
  3. + DNS ·Îµå¹ë·±½Ì + +

    http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html¿¡ + ÀÖ´Â lbnamed ÇÁ·Î±×·¥À» »ç¿ëÇÏ¿© + Á¤±³ÇÑ DNS±â¹Ý ·Îµå¹ë·±½ÌÀ» ÇÒ ¼ö ÀÖ´Ù. DNS°¡ + ½ÇÁ¦ ·Îµå¹ë·±½ÌÀ» Çϵµ·Ï ¸¸µå´Â ¿©·¯ µµ±¸¿Í Perl + 5 ÇÁ·Î±×·¥ÀÌ´Ù.

    +
  4. + +
  5. + Proxy Throughput Round-Robin + +

    ÀÌ ¹æ¹ýÀº mod_rewrite¿Í proxy + throughput ±â´ÉÀ» »ç¿ëÇÑ´Ù. ¸ÕÀú DNS¿¡ ´ÙÀ½ Ç׸ñÀ» + »ç¿ëÇÏ¿© www0.foo.comÀÌ ½ÇÁ¦ + www.foo.comÀ» Àü´ãÇÏ°Ô ÇÑ´Ù

    + +
    +www    IN  CNAME   www0.foo.com.
    +
    + +

    ±×¸®°í www0.foo.comÀ» ÇÁ·Ï½ÃÀü¿ë + ¼­¹ö·Î º¯°æÇÑ´Ù. Áï, URLÀ» ¹ÞÀ¸¸é ¼­¹ö´Â ³»ºÎ + ÇÁ·Ï½Ã¸¦ ÅëÇØ ´Ù¸¥ 5´ë ¼­¹öÁß (www1-www5) + ÇÑ´ë·Î º¸³»±â¸¸ ÇÑ´Ù. À̸¦ À§ÇØ ¸ÕÀú ¸ðµç URLÀ» + ·Îµå¹ë·±½Ì ½ºÅ©¸³Æ® lb.pl·Î º¸³»´Â + ±ÔÄ¢À» ¸¸µç´Ù.

    + +
    +RewriteEngine on
    +RewriteMap    lb      prg:/path/to/lb.pl
    +RewriteRule   ^/(.+)$ ${lb:$1}           [P,L]
    +
    + +

    lb.plÀ» ÀÛ¼ºÇÑ´Ù:

    + +
    +#!/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##
    +
    + +
    ¸¶Áö¸· ÁÖÀÇ: ¿Ö ÀÌ ¹æ¹ýÀÌ À¯¿ëÇÑ°¡? + www0.foo.com¿¡ ºÎ´ãÀÌ °¡Áö¾Ê´Â°¡? + ¹°·Ð, ºÎ´ãÀÌ µÈ´Ù. ±×·¯³ª ´Ü¼øÇÑ proxy throughput + ¿äû¸¸ Çϱ⶧¹®¿¡ ±¦Âú´Ù! ¸ðµç SSI, CGI, ePerl + µîÀº ÀüÀûÀ¸·Î ´Ù¸¥ ¼­¹ö°¡ ó¸®ÇÑ´Ù. ÀÌ°ÍÀÌ ÇÙ½ÉÀÌ´Ù.
    +
  6. + +
  7. + Çϵå¿þ¾î/TCP Round-Robin + +

    Çϵå¿þ¾î¸¦ »ç¿ëÇÑ ÇØ°áÃ¥µµ ÀÖ´Ù. Cisco´Â TCP/IP + ¼öÁØ¿¡¼­ ·Îµå¹ë·±½ÌÀ» ÇÏ´Â LocalDirector¶ó´Â ±«¹°À» + ÆÇ´Ù. ½ÇÁ¦·Î´Â À¥¼­¹ö±º ¾Õ´Ü¿¡ À§Ä¡ÇÏ´Â ÀÏÁ¾ÀÇ + ȸ·Î¼öÁØ °ÔÀÌÆ®¿þÀÌ´Ù. ÀÚ±ÝÀÌ ÃæºÐÇÏ°í °í¼º´É + ÇØ°áÃ¥ÀÌ ÇÊ¿äÇÏ´Ù¸é ÀÌ°ÍÀ» »ç¿ëÇ϶ó.

    +
  8. +
+
+
+ + + +

»õ·Î¿î MIME-type, »õ·Î¿î ¼­ºñ½º

+ + + +
+
»óȲ¼³¸í:
+ +
+

³×Æ®¿÷¿¡´Â ¸ÚÁø CGI ÇÁ·Î±×·¥µéÀÌ ¸¹´Ù. ±×·¯³ª »ç¿ëÇϱâ + ¹ø°Å·¯¿ö¼­ ¸¹Àº À¥°ü¸®ÀÚ°¡ »ç¿ëÇÏÁö ¾Ê´Â´Ù. ¾ÆÆÄÄ¡ÀÇ + MIME-type¿¡ µû¸¥ Action Çڵ鷯 ±â´Éµµ CGI ÇÁ·Î±×·¥ÀÌ + Ưº°ÇÑ URLÀ» (Á¤È®È÷ PATH_INFO¿Í + QUERY_STRINGS) ÇÁ·Î±×·¥ÀÇ ÀÔ·ÂÀ¸·Î »ç¿ëÇÏÁö + ¾ÊÀ» ¶§¸¸ ÀûÀýÇÏ´Ù. ¸ÕÀú, È®ÀåÀÚ°¡ (secure CGI¸¦ ÁÙ¿©) + .scgiÀÎ ÆÄÀÏÀ» À¯¸íÇÑ cgiwrap + ÇÁ·Î±×·¥À¸·Î ó¸®ÇϱâÀ§ÇØ »õ·Î¿î typeÀ» ¼³Á¤ÇÑ´Ù. + ¹®Á¦´Â (À§¿¡¼­ º») ÀÏ°üµÈ URL ±¸Á¶¸¦ »ç¿ëÇÏ´Â °æ¿ì + »ç¿ëÀÚ È¨µð·ºÅ丮°¡ /u/user/foo/bar.scgi°°Àº + URLÀÎ Á¡ÀÌ´Ù. cgiwrap´Â + /~user/foo/bar.scgi/ Çü½ÄÀÇ URLÀ» + ¿øÇϱ⶧¹®ÀÌ´Ù. ´ÙÀ½ ±ÔÄ¢ÀÌ ¹®Á¦¸¦ ÇØ°áÇÑ´Ù:

+ +
+RewriteRule ^/[uge]/([^/]+)/\.www/(.+)\.scgi(.*) ...
+... /internal/cgi/user/cgiwrap/~$1/$2.scgi$3  [NS,T=application/x-http-cgi]
+
+ +

ÀÌÁ¦ ´Ù¸¥ ¸ÚÁø ÇÁ·Î±×·¥, (URL ÇÏÀ§Æ®¸®¿¡ ´ëÇÑ + access.log¸¦ Ãâ·ÂÇÏ´Â) wwwlog¿Í + (URL ÇÏÀ§Æ®¸®¿¡ Glimpse¸¦ ½ÇÇàÇÏ´Â) wwwidx°¡ + ÀÖ´Ù°í °¡Á¤ÇÏÀÚ. ¿ì¸®´Â ÇÁ·Î±×·¥¿¡°Ô ÀÛ¾÷ÇÒ ´ë»óÀÎ + URL ¿µ¿ªÀ» ¾Ë·ÁÁà¾ß ÇÑ´Ù. ±×·¯³ª ¿äûÇÒ¶§¸¶´Ù Ç×»ó + Àû¾îÁà¾ß Çϱ⶧¹®¿¡ ±ò²ûÇÏÁö ¾Ê´Ù. Áï, º¸Åë + /u/user/foo/¿¡ ´ëÇØ swwidx + ÇÁ·Î±×·¥À» ½ÇÇàÇÑ´Ù¸é ´ÙÀ½°ú °°Àº ¸µÅ©¸¦ »ç¿ëÇÑ´Ù

+ +
+/internal/cgi/user/swwidx?i=/u/user/foo/
+
+ +

±ò²ûÇÏÁö ¾Ê´Ù. ¸µÅ©¿¡ ¿µ¿ªÀÇ À§Ä¡¿Í + CGI À§Ä¡¸¦ ¸ðµÎ Àû¾î¾ß Çϱ⶧¹®ÀÌ´Ù. + ¿µ¿ªÀ» À籸¼ºÇÑ´Ù¸é ¿©·¯ ÇÏÀÌÆÛ¸µÅ©¸¦ ¼öÁ¤Çϴµ¥ ¸¹Àº + ½Ã°£ÀÌ °É¸± °ÍÀÌ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

ÇØ°áÃ¥Àº ÀÚµ¿À¸·Î ÀûÀýÇÑ CGI¸¦ ½ÇÇàÇÏ´Â »õ·Î¿î + Ưº°ÇÑ URL Çü½ÄÀ» ¸¸µå´Â °ÍÀÌ´Ù. ´ÙÀ½°ú °°ÀÌ ¼³Á¤ÇÑ´Ù:

+ +
+RewriteRule   ^/([uge])/([^/]+)(/?.*)/\*  /internal/cgi/user/wwwidx?i=/$1/$2$3/
+RewriteRule   ^/([uge])/([^/]+)(/?.*):log /internal/cgi/user/wwwlog?f=/$1/$2$3
+
+ +

ÀÌÁ¦ /u/user/foo/À» °Ë»öÇÏ´Â ¸µÅ©´Â + ´ÙÀ½°ú °°´Ù

+ +
+HREF="*"
+/u/user/foo/* (???)
+
+ +

³»ºÎÀûÀ¸·Î ´ÙÀ½°ú °°ÀÌ ÀÚµ¿º¯È¯µÈ´Ù

+ +
+/internal/cgi/user/wwwidx?i=/u/user/foo/
+
+ +

°°Àº ¹æ¹ýÀ¸·Î ¸µÅ© µÚ¿¡ :log¸¦ »ç¿ëÇÏ¿© + Á¢±Ù ·Î±× CGI ÇÁ·Î±×·¥À» ½ÇÇàÇÒ ¼ö ÀÖ´Ù.

+
+
+ + + +

Á¤Àû¿¡¼­ µ¿ÀûÀ¸·Î

+ + + +
+
»óȲ¼³¸í:
+ +
+

¾î¶»°Ô ºê¶ó¿ìÀú¿Í »ç¿ëÀÚ°¡ ¸ð¸£°Ô ÀÚ¿¬½º·´°Ô Á¤Àû + ÆäÀÌÁö foo.htmlÀ» µ¿ÀûÀÎ foo.cgi·Î + º¯°æÇÒ ¼ö ÀÖ³ª.

+
+ +
ÇØ°áÃ¥:
+ +
+

URLÀ» CGI ½ºÅ©¸³Æ®·Î ÀçÀÛ¼ºÇÏ°í, MIME-typeÀ» ¼öÁ¤ÇÏ¿© + CGI ½ºÅ©¸³Æ®·Î ½ÇÇàÇÏ°Ô ÇÑ´Ù. ±×·¡¼­ + /~quux/foo.html¸¦ ¿äûÇÏ¸é ³»ºÎÀûÀ¸·Î + /~quux/foo.cgi¸¦ ½ÇÇàÇÏ°Ô µÈ´Ù.

+ +
+RewriteEngine  on
+RewriteBase    /~quux/
+RewriteRule    ^foo\.html$  foo.cgi  [T=application/x-httpd-cgi]
+
+
+
+ + + +

Áï¼® ÄÁÅÙÃ÷ Àç»ý¼º

+ + + +
+
»óȲ¼³¸í:
+ +
+

ÀÌ ¹æ¹ýÀº ½Ç·Î ºñ±âÀÌ´Ù: µ¿ÀûÀ¸·Î ÆäÀÌÁö¸¦ »ý¼ºÇÏÁö¸¸, + Á¤ÀûÀ¸·Î ÆäÀÌÁö¸¦ ¼­ºñ½ºÇÑ´Ù. Áï, ÆäÀÌÁö´Â ¼ø¼öÇÏ°Ô + (ÆÄÀϽýºÅÛ¿¡¼­ ÀÐÀº ³»¿ëÀ» ±×´ë·Î) Á¤Àû ÆäÀÌÁö·Î + Àü´ÞµÇÁö¸¸, ¾øÀ» °æ¿ì À¥¼­¹ö°¡ µ¿ÀûÀ¸·Î »ý¼ºÇÑ´Ù. + ±×·¯¸é ´©°¡ (ȤÀº cron ÀÛ¾÷ÀÌ) Á¤Àû ÄÁÅÙÃ÷¸¦ Áö¿ìÁö¾Ê´Â + ÇÑ CGI°¡ »ý¼ºÇÑ ÆäÀÌÁö¸¦ Á¤ÀûÀ¸·Î ¼­ºñ½ºÇÑ´Ù. ÄÁÅÙÃ÷¸¦ + Áö¿ì¸é ³»¿ëÀ» °»½ÅÇÑ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+ ´ÙÀ½ ±ÔÄ¢À» »ç¿ëÇÑ´Ù: + +
+RewriteCond %{REQUEST_FILENAME}   !-s
+RewriteRule ^page\.html$          page.cgi   [T=application/x-httpd-cgi,L]
+
+ +

¿©±â¼­ page.html¸¦ ¿äûÇÒ¶§ + page.htmlÀÌ ¾ø°Å³ª ÆÄÀÏÅ©±â°¡ 0ÀÎ °æ¿ì + ³»ºÎÀûÀ¸·Î page.cgi¸¦ ½ÇÇàÇÑ´Ù. ¿©±â¼­ + ºñ°áÀº page.cgi°¡ ÀϹÝÀûÀÎ CGI ½ºÅ©¸³Æ®¿Í + °°ÀÌ STDOUT¿¡ Ãâ·ÂÇÏ°í, Ãß°¡·Î Ãâ·ÂÀ» + page.html ÆÄÀÏ¿¡ Àû´Â´Ù. Çѹø ½ÇÇàÇÑÈÄ + ¼­¹ö´Â page.htmlÀÇ Á¤º¸¸¦ º¸³½´Ù. À¥°ü¸®ÀÚ°¡ + °­Àç·Î ³»¿ëÀ» °»½ÅÇÏ°í ½Í´Ù¸é, (º¸Åë cron ÀÛ¾÷ÀÌ) + page.htmlÀ» Áö¿ì±â¸¸ ÇÏ¸é µÈ´Ù.

+
+
+ + + +

ÀÚµ¿À¸·Î »õ·Î °íħÇÏ´Â ¹®¼­

+ + + +
+
»óȲ¼³¸í:
+ +
+

º¹ÀâÇÑ À¥ÆäÀÌÁö¸¦ ¸¸µé¶§ ÆíÁýÀÚ°¡ ³»¿ëÀ» ¼öÁ¤ÇÒ + ¶§¸¶´Ù ÀÚµ¿À¸·Î ÆäÀÌÁö¸¦ »õ·Î °íħÇÏ´Â À¥ºê¶ó¿ìÀú°¡ + ÀÖÀ¸¸é ¾ó¸¶³ª ÁÁÀ»±î? ºÒ°¡´ÉÇÑ°¡?

+
+ +
ÇØ°áÃ¥:
+ +
+

°¡´ÉÇÏ´Ù! MIME multipart ±â´É°ú À¥¼­¹ö NPH ±â´É, + mod_rewriteÀÇ URL Á¶ÀÛ ´É·ÂÀ» °áÇÕÇϸé + µÈ´Ù. ¸ÕÀú, »õ·Î¿î URL ±â´ÉÀ» ¸¸µç´Ù: URL¿¡ + :refresh¸¦ Ãß°¡Çϱ⸸ Çϸé ÆÄÀϽýºÅÛ¿¡¼­ + ¼öÁ¤µÉ ¶§¸¶´Ù »õ·Î °íħÇÑ´Ù.

+ +
+RewriteRule   ^(/[uge]/[^/]+/?.*):refresh  /internal/cgi/apache/nph-refresh?f=$1
+
+ +

ÀÌÁ¦ ´ÙÀ½ URL¿¡ Á¢±ÙÇϸé

+ +
+/u/foo/bar/page.html:refresh
+
+ +

´ÙÀ½ URLÀ» ³»ºÎÀûÀ¸·Î ºÎ¸¥´Ù

+ +
+/internal/cgi/apache/nph-refresh?f=/u/foo/bar/page.html
+
+ +

ÀÌÁ¦ NPH-CGI ½ºÅ©¸³Æ®¸¸ ³²¾Ò´Ù. º¸Åë "µ¶ÀÚ¿¡°Ô + ¿¬½ÀÀ¸·Î ³²°ÜµÒ"À̶ó°í ¸»ÇÏÁö¸¸ ;-) ³ª´Â À̰͵µ Á¦°øÇÑ´Ù.

+ +
+#!/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##
+
+
+
+ + + +

´ë·®ÀÇ °¡»óÈ£½ºÆ®

+ + + +
+
»óȲ¼³¸í:
+ +
+

°¡»óÈ£½ºÆ®°¡ ¸î°³¸¸ ÀÖ´Ù¸é ¾ÆÆÄÄ¡ÀÇ <VirtualHost> + ±â´ÉÀÌ Àß µ¿ÀÛÇÑ´Ù. ±×·¯³ª °¡»óÈ£½ºÆ®°¡ ¼ö¹é°³ ÀÖ´Â + ISP¶ó¸é ÀÌ ±â´ÉÀÌ ÃÖ¼±Àº ¾Æ´Ï´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

ÀÌ ±â´ÉÀ» Á¦°øÇÏ·Á¸é Proxy Throughput + ±â´ÉÀ» (Ç÷¡±× [P]) »ç¿ëÇÏ¿© ¿ÜºÎ À¥ÆäÀÌÁö + ȤÀº Àüü ¿ÜºÎ À¥¿µ¿ªÀ» ¿ì¸®ÀÇ À̸§°ø°£¿¡ ´ëÀÀÇÑ´Ù:

+ +
+##
+##  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
+
+ +
+##
+##  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_URI}  !^/commonurl1/.*
+RewriteCond   %{REQUEST_URI}  !^/commonurl2/.*
+    :
+RewriteCond   %{REQUEST_URI}  !^/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}}]
+    :
+
+
+
+ + + +
top
+
+

Á¢±Ù Á¦ÇÑ

+ + + +

·Îº¿ ¸·±â

+ + + +
+
»óȲ¼³¸í:
+ +
+

¾î¶»°Ô Çϸé ƯÁ¤ À¥°ø°£ÀÇ ÆäÀÌÁö¸¦ ±Ü¾î¸ðÀ¸´Â ±ÍÂúÀº + ·Îº¿À» ¸·À» ¼ö ÀÖ³ª? "Robot Exclusion Protocol" Ç׸ñÀ» + ÀúÀåÇÑ /robots.txt ÆÄÀÏÀº º¸Åë ÀÌ·± ·Îº¿À» + ¸·´Âµ¥ ÃæºÐÇÏÁö ¾Ê´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

(¾Æ¸¶µµ µð·ºÅ丮°¡ ±í¾î¼­ ·Îº¿ÀÌ µ¹¾Æ´Ù´Ï¸é ¼­¹ö¿¡ + ºÎ´ãÀÌ Å« °æ¿ì) À¥°ø°£ /~quux/foo/arc/¿¡ + ÀÖ´Â URLµéÀ» °ÅºÎÇÏ´Â ±ÔÄ¢À» »ç¿ëÇÑ´Ù. ¿ì¸®´Â ƯÁ¤ + ·Îº¿ÀÇ Á¢±ÙÀ» ¸·¾Æ¾ß ÇÑ´Ù. Áï, ·Îº¿À» ½ÇÇàÇϴ ȣ½ºÆ®¸¦ + ¸·´Â °ÍÀ¸·Î´Â ºÒÃæºÐÇϸç, ±× È£½ºÆ®ÀÇ »ç¿ëÀÚµµ ¸·¾Æ¹ö¸®°Ô + µÈ´Ù. User-Agent HTTP Çì´õ Á¤º¸µµ ºñ±³ÇÑ´Ù.

+ +
+RewriteCond %{HTTP_USER_AGENT}   ^NameOfBadRobot.*
+RewriteCond %{REMOTE_ADDR}       ^123\.45\.67\.[8-9]$
+RewriteRule ^/~quux/foo/arc/.+   -   [F]
+
+
+
+ + + +

±×¸² ÆÛ°¡±â ¹æÁö

+ + + +
+
»óȲ¼³¸í:
+ +
+

http://www.quux-corp.de/~quux/¿¡ ÀÖ´Â + ÆäÀÌÁöµéÀÌ GIF ±×¸²À» Æ÷ÇÔÇÑ´Ù°í °¡Á¤ÇÏÀÚ. ÀÌ ±×¸²ÀÌ + ¸ÚÀ־, ´Ù¸¥ »ç¶÷µéÀÌ ÀÚ½ÅÀÇ ÆäÀÌÁö¿¡ Á÷Á¢ ¸µÅ©¸¦ + °Ç´Ù. ¼­¹ö¿¡ ºÒÇÊ¿äÇÑ ºÎ´ãÀÌ µÇ¹Ç·Î ¸·°í ½Í´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

±×¸²À» 100% º¸È£ÇÒ ¼ö´Â ¾øÁö¸¸, ÃÖ¼ÒÇÑ ºê¶ó¿ìÀú°¡ + HTTP Referer Çì´õ¸¦ º¸³»´Â °æ¿ì Á¦ÇÑÇÒ ¼ö ÀÖ´Ù.

+ +
+RewriteCond %{HTTP_REFERER} !^$
+RewriteCond %{HTTP_REFERER} !^http://www.quux-corp.de/~quux/.*$ [NC]
+RewriteRule .*\.gif$        -                                    [F]
+
+ +
+RewriteCond %{HTTP_REFERER}         !^$
+RewriteCond %{HTTP_REFERER}         !.*/foo-with-gif\.html$
+RewriteRule ^inlined-in-foo\.gif$   -                        [F]
+
+
+
+ + + +

È£½ºÆ® °ÅºÎ

+ + + +
+
»óȲ¼³¸í:
+ +
+

¾î¶»°Ô ¿ÜºÎ¿¡¼­ ¼­¹ö¿¡ Á¢±ÙÇÒ ¼ö ¾ø´Â È£½ºÆ® ¸ñ·ÏÀ» + ¼³Á¤ÇÒ ¼ö ÀÖ³ª?

+
+ +
ÇØ°áÃ¥:
+ +
+

¾ÆÆÄÄ¡ >= 1.3b6¿¡¼­:

+ +
+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]
+
+ +

¾ÆÆÄÄ¡ <= 1.3b6¿¡¼­:

+ +
+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
+
+ +
+##
+##  hosts.deny
+##
+##  ÁÖÀÇ! ÀÌ°ÍÀº ¸ñ·Ïó·³ º¸ÀÌÁö¸¸ ¸ñ·ÏÀÌ ¾Æ´Ï¶ó ¸ÊÀÌ´Ù.
+##        mod_rewrite´Â ÀÌ Á¤º¸¸¦ Å°/°ª ½ÖÀ¸·Î Çؼ®Çϱ⶧¹®¿¡,
+##        °¢ Ç׸ñÀÇ °ª ÀÚ¸®¿¡ ÃÖ¼ÒÇÑ "-"°¡ ÇÊ¿äÇÏ´Ù.
+##
+
+193.102.180.41 -
+bsdti1.sdm.de  -
+192.76.162.40  -
+
+
+
+ + + +

ÇÁ·Ï½Ã °ÅºÎ

+ + + +
+
»óȲ¼³¸í:
+ +
+

¾î¶»°Ô ƯÁ¤ È£½ºÆ® ȤÀº ƯÁ¤ È£½ºÆ®ÀÇ »ç¿ëÀÚ°¡ + ¾ÆÆÄÄ¡ ÇÁ·Ï½Ã¸¦ »ç¿ëÇÒ ¼ö ¾øµµ·Ï Çϳª?

+
+ +
ÇØ°áÃ¥:
+ +
+

¸ÕÀú ¾ÆÆÄÄ¡ À¥¼­¹ö¸¦ ÄÄÆÄÀÏÇÒ¶§ ±¸¼ºÆÄÀÏ¿¡¼­ + mod_rewrite°¡ mod_proxy + ¾Æ·¡¿¡(!) ÀÖ¾î¾ß ÇÑ´Ù. ±×·¯¸é mod_rewrite´Â + mod_proxy ÀÌÀü¿¡ ºÒ¸°´Ù. + ÀÌÁ¦ ´ÙÀ½°ú °°ÀÌ Æ¯Á¤ È£½ºÆ®¸¦ °ÅºÎÇϵµ·Ï ¼³Á¤ÇÑ´Ù...

+ +
+RewriteCond %{REMOTE_HOST} ^badhost\.mydomain\.com$
+RewriteRule !^http://[^/.]\.mydomain.com.*  - [F]
+
+ +

...±×¸®°í ´ÙÀ½Àº user@host¿¡ µû¶ó °ÅºÎÇÑ´Ù:

+ +
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST}  ^badguy@badhost\.mydomain\.com$
+RewriteRule !^http://[^/.]\.mydomain.com.*  - [F]
+
+
+
+ + + +

Ưº°ÇÑ ÀÎÁõ ¹æ½Ä

+ + + +
+
»óÈ°¼³¸í:
+ +
+

°¡²û ¸Å¿ì Ưº°ÇÑ ÀÎÁõÀÌ ÇÊ¿äÇÒ ¶§°¡ ÀÖ´Ù. ¿¹¸¦ + µé¾î, ¹Ì¸® ¼³Á¤ÇصР»ç¿ëÀÚÀÎÁö °Ë»çÇÑ´Ù. À̵鿡°Ô¸¸ + (mod_authÀÇ Basic Auth¸¦ »ç¿ëÇÑ + °æ¿ì¿Í ´Þ¸®) º°´Ù¸¥ ¹°À½¾øÀÌ Á¢±ÙÀ» Çã¿ëÇÑ´Ù.

+
+ +
ÇØ°áÃ¥:
+ +
+

Ä£±¸¸¸ Á¢±ÙÀÌ °¡´ÉÇϵµ·Ï ÀçÀÛ¼º ±ÔÄ¢µéÀ» »ç¿ëÇÑ´Ù:

+ +
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend1@client1.quux-corp\.com$
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend2@client2.quux-corp\.com$
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend3@client3.quux-corp\.com$
+RewriteRule ^/~quux/only-for-friends/      -                                 [F]
+
+
+
+ + + +

Referer±â¹Ý º¯È¯±â(deflector)

+ + + +
+
»óȲ¼³¸í:
+ +
+

"Referer" HTTP Çì´õ¿¡ µû¶ó ¿øÇϴ´ë·Î ÂüÁ¶ÆäÀÌÁö¸¦ + ¼³Á¤ÇÒ ¼ö ÀÖ´Â À¯¿¬ÇÑ URL º¯È¯±â¸¦ ¸¸µé ¼ö Àִ°¡?

+
+ +
ÇØ°áÃ¥:
+ +
+

´ÙÀ½°ú °°ÀÌ º¹ÀâÇÑ ±ÔÄ¢À»...

+ +
+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]
+
+ +

... ÀçÀÛ¼º ¸Ê°ú °°ÀÌ »ç¿ëÇÑ´Ù:

+ +
+##
+##  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/
+
+ +

±×·¯¸é ¿äûÀ» ÀÚµ¿À¸·Î (¸Ê¿¡¼­ °ªÀ¸·Î "-"¸¦ + »ç¿ëÇÑ °æ¿ì) ÂüÁ¶ÆäÀÌÁö³ª (URLÀÌ ¸Ê¿¡ ÀÖ´Â °æ¿ì µÎ¹ø° + ¾Æ±Ô¸ÕÆ®·Î) ƯÁ¤ URL·Î ¸®´ÙÀÌ·º¼ÇÇÑ´Ù.

+
+
+ + + +
top
+
+

±âŸ

+ + + +

¿ÜºÎ ÀçÀÛ¼º ¿£Áø

+ + + +
+
»óȲ¼³¸í:
+ +
+

FAQ: ¾î¶»°Ô ÀÌ·±Àú·± Àâ´ÙÇÑ ¹®Á¦¸¦ Ç® ¼ö Àִ°¡? + mod_rewrite·Î´Â ÇØ°áÃ¥ÀÌ ¾Èº¸ÀδÙ...

+
+ +
ÇØ°áÃ¥:
+ +
+

¿ÜºÎ RewriteMapÀ» »ç¿ëÇ϶ó. + Áï, ÇÁ·Î±×·¥ÀÌ RewriteMap ¿ªÇÒÀ» + ÇÑ´Ù. ÇÁ·Î±×·¥Àº ¾ÆÆÄÄ¡°¡ ½ÃÀÛÇÒ¶§ ½ÃÀÛÇÏ¿© + STDIN¿¡¼­ ¿äûÇÑ URLÀ» ¹Þ°í, (°°Àº ¼ø¼­·Î!) + °á°ú (º¸Åë ÀçÀÛ¼ºµÈ) URLÀ» STDOUT¿¡ Ãâ·ÂÇÑ´Ù.

+ +
+RewriteEngine on
+RewriteMap    quux-map       prg:/path/to/map.quux.pl
+RewriteRule   ^/~quux/(.*)$  /~quux/${quux-map:$1}
+
+ +
+#!/path/to/perl
+
+#   ¾ÆÆÄÄ¡ ¼­¹ö°¡ ¸ØÃßÁö ¾Êµµ·Ï
+#   ÀÔÃâ·Â ¹öÆÛ¸¦ »ç¿ëÇÏÁö ¾Ê´Â´Ù
+$| = 1;
+
+#   stdin¿¡¼­ ÇÑÁÙ¾¿ URLÀ» Àаí
+#   stdout¿¡ º¯È¯ÇÑ URLÀ» Ãâ·ÂÇÑ´Ù
+while (<>) {
+    s|^foo/|bar/|;
+    print $_;
+}
+
+ +

¼³¸íÇϱâÀ§ÇØ ¸ðµç /~quux/foo/... URLÀ» + /~quux/bar/...·Î ÀçÀÛ¼ºÇÏ´Â ½ºÅ©¸³Æ®¸¦ + ¿¹·Î µé¾ú´Ù. ½ÇÁ¦·Î ¸¶À½´ë·Î ÇÁ·Î±×·¡¹ÖÇÒ ¼ö ÀÖ´Ù. + ±×·¯³ª ÀÏ¹Ý »ç¿ëÀÚ°¡ ÀÌ·± ¸ÊÀ» »ç¿ëÇÒ + ¼ö ÀÖ´Ù°í ÇÏ´õ¶ó°í, ¿ÀÁ÷ ½Ã½ºÅÛ °ü¸®ÀÚ¸¸ÀÌ ¸ÊÀ» + Á¤ÀÇÇØ¾ß ÇÔÀ» ÁÖÀÇÇ϶ó.

+
+
+ + + +
+
+

°¡´ÉÇÑ ¾ð¾î:  en  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/security_tips.html b/rubbos/app/apache2/manual/misc/security_tips.html new file mode 100644 index 00000000..893872b5 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/security_tips.html @@ -0,0 +1,13 @@ +# GENERATED FROM XML -- DO NOT EDIT + +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 + +URI: security_tips.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 diff --git a/rubbos/app/apache2/manual/misc/security_tips.html.en b/rubbos/app/apache2/manual/misc/security_tips.html.en new file mode 100644 index 00000000..560c8259 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/security_tips.html.en @@ -0,0 +1,354 @@ + + + +Security Tips - Apache HTTP Server + + + + + +
<-
+

Security Tips

+
+

Available Languages:  en  | + ko  | + tr 

+
+ +

Some hints and tips on security issues in setting up a web server. + Some of the suggestions will be general, others specific to Apache.

+
+ +
top
+
+

Keep up to Date

+ +

The Apache HTTP Server has a good record for security and a + developer community highly concerned about security issues. But + it is inevitable that some problems -- small or large -- will be + discovered in software after it is released. For this reason, it + is crucial to keep aware of updates to the software. If you have + obtained your version of the HTTP Server directly from Apache, we + highly recommend you subscribe to the Apache + HTTP Server Announcements List where you can keep informed of + new releases and security updates. Similar services are available + from most third-party distributors of Apache software.

+ +

Of course, most times that a web server is compromised, it is + not because of problems in the HTTP Server code. Rather, it comes + from problems in add-on code, CGI scripts, or the underlying + Operating System. You must therefore stay aware of problems and + updates with all the software on your system.

+ +
top
+
+

Permissions on ServerRoot Directories

+ + + +

In typical operation, Apache is started by the root user, and it + switches to the user defined by the User directive to serve hits. As is the + case with any command that root executes, you must take care that it is + protected from modification by non-root users. Not only must the files + themselves be writeable only by root, but so must the directories, and + parents of all directories. For example, if you choose to place + ServerRoot in /usr/local/apache then it is suggested that + you create that directory as root, with commands like these:

+ +

+ mkdir /usr/local/apache
+ cd /usr/local/apache
+ mkdir bin conf logs
+ chown 0 . bin conf logs
+ chgrp 0 . bin conf logs
+ chmod 755 . bin conf logs +

+ +

It is assumed that /, /usr, and + /usr/local are only modifiable by root. When you install the + httpd executable, you should ensure that it is + similarly protected:

+ +

+ cp httpd /usr/local/apache/bin
+ chown 0 /usr/local/apache/bin/httpd
+ chgrp 0 /usr/local/apache/bin/httpd
+ chmod 511 /usr/local/apache/bin/httpd +

+ +

You can create an htdocs subdirectory which is modifiable by other + users -- since root never executes any files out of there, and shouldn't + be creating files in there.

+ +

If you allow non-root users to modify any files that root either + executes or writes on then you open your system to root compromises. + For example, someone could replace the httpd binary so + that the next time you start it, it will execute some arbitrary code. If + the logs directory is writeable (by a non-root user), someone could replace + a log file with a symlink to some other system file, and then root + might overwrite that file with arbitrary data. If the log files + themselves are writeable (by a non-root user), then someone may be + able to overwrite the log itself with bogus data.

+ +
top
+
+

Server Side Includes

+ + + +

Server Side Includes (SSI) present a server administrator with + several potential security risks.

+ +

The first risk is the increased load on the server. All + SSI-enabled files have to be parsed by Apache, whether or not + there are any SSI directives included within the files. While this + load increase is minor, in a shared server environment it can become + significant.

+ +

SSI files also pose the same risks that are associated with CGI + scripts in general. Using the exec cmd element, SSI-enabled + files can execute any CGI script or program under the permissions of the + user and group Apache runs as, as configured in + httpd.conf.

+ +

There are ways to enhance the security of SSI files while still + taking advantage of the benefits they provide.

+ +

To isolate the damage a wayward SSI file can cause, a server + administrator can enable suexec as + described in the CGI in General section.

+ +

Enabling SSI for files with .html or .htm + extensions can be dangerous. This is especially true in a shared, or high + traffic, server environment. SSI-enabled files should have a separate + extension, such as the conventional .shtml. This helps keep + server load at a minimum and allows for easier management of risk.

+ +

Another solution is to disable the ability to run scripts and + programs from SSI pages. To do this replace Includes + with IncludesNOEXEC in the Options directive. Note that users may + still use <--#include virtual="..." --> to execute CGI + scripts if these scripts are in directories designated by a ScriptAlias directive.

+ +
top
+
+

CGI in General

+ + + +

First of all, you always have to remember that you must trust the + writers of the CGI scripts/programs or your ability to spot potential + security holes in CGI, whether they were deliberate or accidental. CGI + scripts can run essentially arbitrary commands on your system with the + permissions of the web server user and can therefore be extremely + dangerous if they are not carefully checked.

+ +

All the CGI scripts will run as the same user, so they have potential + to conflict (accidentally or deliberately) with other scripts e.g. User + A hates User B, so he writes a script to trash User B's CGI database. One + program which can be used to allow scripts to run as different users is + suEXEC which is included with Apache as of + 1.2 and is called from special hooks in the Apache server code. Another + popular way of doing this is with + CGIWrap.

+ +
top
+
+

Non Script Aliased CGI

+ + + +

Allowing users to execute CGI scripts in any directory should only be + considered if:

+ +
    +
  • You trust your users not to write scripts which will deliberately + or accidentally expose your system to an attack.
  • +
  • You consider security at your site to be so feeble in other areas, + as to make one more potential hole irrelevant.
  • +
  • You have no users, and nobody ever visits your server.
  • +
+ +
top
+
+

Script Aliased CGI

+ + + +

Limiting CGI to special directories gives the admin control over what + goes into those directories. This is inevitably more secure than non + script aliased CGI, but only if users with write access to the + directories are trusted or the admin is willing to test each + new CGI script/program for potential security holes.

+ +

Most sites choose this option over the non script aliased CGI + approach.

+ +
top
+
+

Other sources of dynamic content

+ + + +

Embedded scripting options which run as part of the server itself, + such as mod_php, mod_perl, mod_tcl, + and mod_python, run under the identity of the server itself + (see the User directive), and + therefore scripts executed by these engines potentially can access + anything the server user can. Some scripting engines may provide + restrictions, but it is better to be safe and assume not.

+ +
top
+
+

Protecting System Settings

+ + + +

To run a really tight ship, you'll want to stop users from setting + up .htaccess files which can override security features + you've configured. Here's one way to do it.

+ +

In the server configuration file, put

+ +

+ <Directory />
+ AllowOverride None
+ </Directory> +

+ +

This prevents the use of .htaccess files in all + directories apart from those specifically enabled.

+ +
top
+
+

Protect Server Files by Default

+ + + +

One aspect of Apache which is occasionally misunderstood is the + feature of default access. That is, unless you take steps to change it, + if the server can find its way to a file through normal URL mapping + rules, it can serve it to clients.

+ +

For instance, consider the following example:

+ +

+ # cd /; ln -s / public_html
+ Accessing http://localhost/~root/ +

+ +

This would allow clients to walk through the entire filesystem. To + work around this, add the following block to your server's + configuration:

+ +

+ <Directory />
+ Order Deny,Allow
+ Deny from all
+ </Directory> +

+ +

This will forbid default access to filesystem locations. Add + appropriate Directory blocks to + allow access only in those areas you wish. For example,

+ +

+ <Directory /usr/users/*/public_html>
+ Order Deny,Allow
+ Allow from all
+ </Directory>
+ <Directory /usr/local/httpd>
+ Order Deny,Allow
+ Allow from all
+ </Directory> +

+ +

Pay particular attention to the interactions of Location and Directory directives; for instance, even + if <Directory /> denies access, a + <Location /> directive might overturn it.

+ +

Also be wary of playing games with the UserDir directive; setting it to + something like ./ would have the same effect, for root, as + the first example above. If you are using Apache 1.3 or above, we strongly + recommend that you include the following line in your server + configuration files:

+ +

+ UserDir disabled root +

+ +
top
+
+

Watching Your Logs

+ + + +

To keep up-to-date with what is actually going on against your server + you have to check the Log Files. Even though + the log files only reports what has already happened, they will give you + some understanding of what attacks is thrown against the server and + allow you to check if the necessary level of security is present.

+ +

A couple of examples:

+ +

+ grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
+ grep "client denied" error_log | tail -n 10 +

+ +

The first example will list the number of attacks trying to exploit the + Apache Tomcat + Source.JSP Malformed Request Information Disclosure Vulnerability, + the second example will list the ten last denied clients, for example:

+ +

+ [Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied + by server configuration: /usr/local/apache/htdocs/.htpasswd +

+ +

As you can see, the log files only report what already has happened, so + if the client had been able to access the .htpasswd file you + would have seen something similar to:

+ +

+ foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1" +

+ +

in your Access Log. This means + you probably commented out the following in your server configuration + file:

+ +

+ <Files ~ "^\.ht">
+ Order allow,deny
+ Deny from all
+ </Files> +

+ +
+
+

Available Languages:  en  | + ko  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/security_tips.html.ko.euc-kr b/rubbos/app/apache2/manual/misc/security_tips.html.ko.euc-kr new file mode 100644 index 00000000..58c56f14 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/security_tips.html.ko.euc-kr @@ -0,0 +1,345 @@ + + + +º¸¾È ÆÁ - Apache HTTP Server + + + + + +
<-
+

º¸¾È ÆÁ

+
+

°¡´ÉÇÑ ¾ð¾î:  en  | + ko  | + tr 

+
+
ÀÌ ¹®¼­´Â ÃÖ½ÅÆÇ ¹ø¿ªÀÌ ¾Æ´Õ´Ï´Ù. + ÃÖ±Ù¿¡ º¯°æµÈ ³»¿ëÀº ¿µ¾î ¹®¼­¸¦ Âü°íÇϼ¼¿ä.
+ +

À¥¼­¹ö¸¦ ¿î¿µÇÒ¶§ µµ¿òÀÌ µÉ º¸¾È °ü·Ã ÈùÆ®¿Í ÆÁÀÌ´Ù. + ¾î¶² °ÍÀº ÀϹÝÀûÀÌ°í, ¾î¶² °ÍÀº ¾ÆÆÄÄ¡¿¡¸¸ ÇØ´çÇÏ´Â °ÍÀÌ´Ù.

+
+ +
top
+
+

ÃÖ½ÅÆÇÀ¸·Î À¯ÁöÇϱâ

+ +

¾ÆÆÄÄ¡ À¥¼­¹ö´Â ¾ÈÀü°ú º¸¾È ¹®Á¦¿¡ °ü½ÉÀÌ ¸¹Àº °³¹ßÀÚ + °øµ¿Ã¼·Î À¯¸íÇÏ´Ù. ±×·¯³ª Å©°Ç ÀÛ°Ç ¹ßÇ¥ÈÄ ¹ß°ßµÇ´Â ¹®Á¦µéÀ» + ÇÇÇÒ ¼ö ¾ø´Ù. ±×·¡¼­ ¼ÒÇÁÆ®¿þ¾î¸¦ ÃֽŹöÀüÀ¸·Î À¯ÁöÇÏ´Â + °ÍÀÌ Áß¿äÇÏ´Ù. ¾ÆÆÄÄ¡¿¡¼­ Á÷Á¢ À¥¼­¹ö¸¦ ´Ù¿î·ÎµåÇß´Ù¸é, + »õ·Î¿î ¹öÀü°ú º¸¾È ¾÷µ¥ÀÌÆ®¸¦ ¾Ë·ÁÁÖ´Â ¾ÆÆÄÄ¡ + À¥¼­¹ö ¹ßÇ¥ ¸ÞÀϸµ¸®½ºÆ®¸¦ ±¸µ¶ÇÏ±æ °­·ÂÈ÷ ±ÇÇÑ´Ù. + ¾ÆÆÄÄ¡ ¼ÒÇÁÆ®¿þ¾î¸¦ ¹èÆ÷ÇÏ´Â ¸¹Àº Á¦»ïÀڵ鵵 ºñ½ÁÇÑ ¼­ºñ½º¸¦ + Á¦°øÇÑ´Ù.

+ +

¹°·Ð À¥¼­¹ö Äڵ嶧¹®¿¡ À¥¼­¹ö°¡ °ø°ÝÀ» ´çÇÏ´Â °æ¿ì´Â + ¸¹Áö ¾Ê´Ù. ±×º¸´Ù Ãß°¡ ÄÚµå, CGI ½ºÅ©¸³Æ®, ÇÏÀ§ ¿î¿µÃ¼Á¦ÀÇ + ¹®Á¦·Î °ø°ÝÀ» ´çÇÏ´Â °æ¿ì°¡ ¸¹´Ù. ±×·¯¹Ç·Î Ç×»ó ÁÖÀÇÇϸç + ½Ã½ºÅÛÀÇ ¸ðµç ¼ÒÇÁÆ®¿þ¾î¸¦ ¾÷µ¥ÀÌÆ®ÇØ¾ß ÇÑ´Ù.

+ +
top
+
+

ServerRoot µð·ºÅ丮 ±ÇÇÑ

+ + + +

º¸Åë root »ç¿ëÀÚ°¡ ¾ÆÆÄÄ¡¸¦ ½ÃÀÛÇÑ ÈÄ, ¿äûÀ» ¼­ºñ½ºÇϱâÀ§ÇØ + User Áö½Ã¾î·Î + ÁöÁ¤ÇÑ »ç¿ëÀÚ·Î º¯È¯ÇÑ´Ù. root°¡ ½ÇÇàÇÏ´Â ¸í·É¾î°¡ ÀÖ´Ù¸é, + root ÀÌ¿ÜÀÇ »ç¿ëÀÚ°¡ ¼öÁ¤ÇÏÁö ¸øÇϵµ·Ï ÁÖÀÇÇØ¾ß ÇÑ´Ù. ÀÌ + ÆÄÀϵéÀ» root¸¸ ¾µ ¼ö ÀÖ¾î¾ß ÇÏ°í, µð·ºÅ丮¿Í ¸ðµç »óÀ§µð·ºÅ丮µµ + ¸¶Âù°¡Áö´Ù. ¿¹¸¦ µé¾î, ServerRoot·Î /usr/local/apache¸¦ + »ç¿ëÇÑ´Ù¸é root »ç¿ëÀÚ°¡ ´ÙÀ½°ú °°ÀÌ µð·ºÅ丮¸¦ ¸¸µé±æ + Á¦¾ÈÇÑ´Ù:

+ +

+ mkdir /usr/local/apache
+ cd /usr/local/apache
+ mkdir bin conf logs
+ chown 0 . bin conf logs
+ chgrp 0 . bin conf logs
+ chmod 755 . bin conf logs +

+ +

±×·¯¸é /, /usr, /usr/local Àº root¸¸ÀÌ ¼öÁ¤ÇÒ ¼ö ÀÖ´Ù. + httpd ½ÇÇàÆÄÀÏÀ» ¼³Ä¡ÇÒ¶§ ´ÙÀ½°ú °°ÀÌ º¸È£ÇØ¾ß ÇÑ´Ù:

+ +

+ cp httpd /usr/local/apache/bin
+ chown 0 /usr/local/apache/bin/httpd
+ chgrp 0 /usr/local/apache/bin/httpd
+ chmod 511 /usr/local/apache/bin/httpd +

+ +

htdocs ÇÏÀ§µð·ºÅ丮´Â ´Ù¸¥ »ç¿ëÀÚµéÀÌ ¼öÁ¤ÇÒ ¼ö ÀÖµµ·Ï + ¸¸µé ¼ö ÀÖ´Ù -- root´Â ±×°÷¿¡ ÀÖ´Â ÆÄÀÏÀ» ½ÇÇàÇÏÁöµµ, ¸¸µéÁöµµ + ¾Ê¾Æ¾ß ÇÑ´Ù.

+ +

root°¡ ¾Æ´Ñ »ç¿ëÀÚ°¡ root°¡ ½ÇÇàÇϰųª ¾²±â°¡´ÉÇÑ ÆÄÀÏÀ» + ¼öÁ¤ÇÒ ¼ö ÀÖ´Ù¸é ½Ã½ºÅÛÀÇ root ±ÇÇÑÀ» ÈÉÄ¥ ¼ö ÀÖ´Ù. ¿¹¸¦ + µé¾î, ´©±º°¡ httpd ½ÇÇàÆÄÀÏÀ» º¯°æÇÏ¿´´Ù¸é ´ÙÀ½¹ø ½ÃÀÛÇÒ¶§ + ÀÓÀÇÀÇ Äڵ带 ½ÇÇàÇÏ°Ô µÈ´Ù. logs µð·ºÅ丮°¡ (root°¡ ¾Æ´Ñ + »ç¿ëÀÚ¿¡°Ô) ¾²±â°¡´ÉÇÏ´Ù¸é ´©±º°¡ ·Î±×ÆÄÀÏÀ» ´Ù¸¥ ½Ã½ºÅÛÆÄÀÏ·Î + ½Éº¼¸µÅ©¸¦ °É¾î¼­ root°¡ ÆÄÀÏ¿¡ ÀÓÀÇÀÇ ÀڷḦ µ¤¾î¾µ ¼ö + ÀÖ´Ù. ·Î±×ÆÄÀÏÀÌ (root°¡ ¾Æ´Ñ »ç¿ëÀÚ¿¡°Ô) ¾²±â°¡´ÉÇÏ´Ù¸é + ´©±º°¡ ·Î±×¿¡ ÀÌ»óÇÑ ÀڷḦ ±â·ÏÇÒ ¼ö ÀÖ´Ù.

+ +
top
+
+

Server Side Includes

+ + + +

Server Side Includes (SSI)´Â ¼­¹ö °ü¸®ÀÚ¿¡°Ô º¸¾È»ó ¸î°¡Áö + ÀáÀçÀûÀÎ À§ÇèÀÌ´Ù.

+ +

ù¹ø° À§ÇèÀº ¼­¹öÀÇ ºÎÇϸ¦ ´Ã¸®´Â Á¡ÀÌ´Ù. ¾ÆÆÄÄ¡´Â ÆÄÀÏ¿¡ + SSI Áö½Ã¾î°¡ ÀÖ´ÂÁö ¿©ºÎ¿Í °ü°è¾øÀÌ ¸ðµç SSI ÆÄÀÏÀ» ºÐ¼®ÇØ¾ß + ÇÑ´Ù. Á¶±Ý ºÎÇÏ°¡ ´ÃÁö¸¸, ¼­¹ö¸¦ ¿©·¯ »ç¶÷ÀÌ °°ÀÌ »ç¿ëÇÏ´Â + ȯ°æ¿¡¼­´Â ½É°¢ÇÒ ¼ö ÀÖ´Ù.

+ +

¶Ç, SSI ÆÄÀÏÀº ÀϹÝÀûÀÎ CGI ½ºÅ©¸³Æ®¿Í µ¿ÀÏÇÑ À§ÇèÀ» + °¡Áø´Ù. SSI ÆÄÀÏ¿¡¼­ "exec cmd"¸¦ »ç¿ëÇϸé httpd.conf¿¡¼­ + ¾ÆÆÄÄ¡¸¦ ½ÇÇàÇϵµ·Ï ¼³Á¤ÇÑ »ç¿ëÀÚ¿Í ±×·ì ±ÇÇÑÀ¸·Î CGI + ½ºÅ©¸³Æ®³ª ÇÁ·Î±×·¥À» ½ÇÇàÇÒ ¼ö ÀÖ´Ù.

+ +

ÀåÁ¡À» È°¿ëÇϸ鼭 SSI ÆÄÀÏÀÇ º¸¾ÈÀ» Çâ»ó½ÃÅ°´Â ¹æ¹ýÀÌ + ÀÖ´Ù.

+ +

SSI ÆÄÀÏÀÌ °¡Á®¿Ã ¼ö ÀÖ´Â ÇÇÇظ¦ °Ý¸®ÇϱâÀ§ÇØ ¼­¹ö°ü¸®ÀÚ´Â + ÀϹÝÀûÀÎ CGI Àý¿¡¼­ ¼³¸íÇÏ´Â ¹æ¹ýÀ¸·Î + suexec¸¦ »ç¿ëÇÒ ¼ö ÀÖ´Ù

+ +

.htmlÀ̳ª .htm È®ÀåÀÚ¸¦ SSI ÆÄÀÏ·Î »ç¿ëÇÏ´Â °ÍÀº À§ÇèÇÏ´Ù. + ƯÈ÷ ¿©·¯ »ç¶÷ÀÌ °øÀ¯Çϰųª Åë½Å·®ÀÌ ¸¹Àº ¼­¹ö ȯ°æ¿¡¼­ + À§ÇèÇÏ´Ù. SSI ÆÄÀÏÀº ÀϹÝÀûÀ¸·Î ¸¹ÀÌ »ç¿ëÇÏ´Â .shtml °°Àº + º°µµÀÇ È®ÀåÀÚ¸¦ °¡Á®¾ß ÇÑ´Ù. ±×·¯¸é ¼­¹ö ºÎÇϸ¦ ÃÖ¼ÒÈ­ÇÏ°í + À§Çè¿ä¼Ò¸¦ ½±°Ô °ü¸®ÇÒ ¼ö ÀÖ´Ù.

+ +

´Ù¸¥ ¹æ¹ýÀº SSI ÆäÀÌÁö°¡ ½ºÅ©¸³Æ®³ª ÇÁ·Î±×·¥À» ½ÇÇàÇÏÁö + ¸øÇϵµ·Ï ¸¸µå´Â °ÍÀÌ´Ù. Options Áö½Ã¾î¿¡¼­ Includes + ´ë½Å IncludesNOEXEC¸¦ »ç¿ëÇÑ´Ù. ±×·¡µµ ½ºÅ©¸³Æ®°¡ + ScriptAlias Áö½Ã¾î·Î + ÁöÁ¤ÇÑ µð·ºÅ丮¿¡ ÀÖ´Ù¸é <--#include virtual="..." -->¸¦ + »ç¿ëÇÏ¿© CGI ½ºÅ©¸³Æ®¸¦ ½ÇÇàÇÒ ¼ö ÀÖÀ½À» ÁÖÀÇÇ϶ó.

+ +
top
+
+

ÀϹÝÀûÀÎ CGI

+ + + +

°á±¹ ´ç½ÅÀº Ç×»ó CGI ½ºÅ©¸³Æ®/ÇÁ·Î±×·¥ÀÇ ÀúÀÚ¸¦ ½Å·ÚÇØ¾ß + ÇÏ°í, °íÀÇ°Ç ½Ç¼öÀÌ°Ç CGIÀÇ ÀáÀçÀûÀÎ º¸¾È»ó ÇãÁ¡À» ¹ß°ßÇÒ + ¼ö ÀÖ¾î¾ß ÇÑ´Ù. ±âº»ÀûÀ¸·Î CGI ½ºÅ©¸³Æ®´Â À¥¼­¹ö »ç¿ëÀÚ + ±ÇÇÑÀ¸·Î ½Ã½ºÅÛ¿¡¼­ ¾î¶² ¸í·É¾î¶óµµ ½ÇÇàÇÒ ¼ö Àֱ⶧¹®¿¡ + ÁÖÀÇÀÖ°Ô È®ÀÎÇÏÁö ¾ÊÀ¸¸é ¸Å¿ì À§ÇèÇÏ´Ù.

+ +

¸ðµç CGI ½ºÅ©¸³Æ®°¡ °°Àº »ç¿ëÀÚ·Î ½ÇÇàµÇ±â¶§¹®¿¡ ´Ù¸¥ + ½ºÅ©¸³Æ®¿Í (°íÀÇ°Ç ½Ç¼öÀÌ°Ç) Ãæµ¹ÇÒ °¡´É¼ºÀÌ ÀÖ´Ù. ¿¹¸¦ + µé¾î, »ç¿ëÀÚ A´Â »ç¿ëÀÚ B¸¦ ¸Å¿ì ½È¾îÇÏ¿©, »ç¿ëÀÚ BÀÇ CGI + µ¥ÀÌÅͺ£À̽º¸¦ Áö¿ö¹ö¸®´Â ½ºÅ©¸³Æ®¸¦ ÀÛ¼ºÇÒ ¼ö ÀÖ´Ù. ¾ÆÆÄÄ¡ + 1.2 ¹öÀüºÎÅÍ Æ÷ÇԵǾú°í ¾ÆÆÄÄ¡ ¼­¹ö¿¡¼­ Ưº°ÇÑ ÈÅ(hook)À¸·Î + µ¿ÀÛÇÏ´Â suEXEC´Â ½ºÅ©¸³Æ®¸¦ + ´Ù¸¥ »ç¿ëÀÚ·Î ½ÇÇàÇÏ´Â ¹æ¹ýÁß Çϳª´Ù. ´Ù¸¥ ´ëÁßÀûÀÎ ¹æ¹ý¿¡´Â + CGIWrapÀÌ ÀÖ´Ù.

+ +
top
+
+

ScriptAliasÇÏÁö ¾ÊÀº CGI

+ + + +

´ÙÀ½ Á¶°ÇÀ» ¸¸Á·ÇÒ¶§¸¸ »ç¿ëÀÚ°¡ ¾î¶² µð·ºÅ丮¿¡¼­¶óµµ + CGI ½ºÅ©¸³Æ®¸¦ ½ÇÇàÇϵµ·Ï Çã¿ëÇÒ ¼ö ÀÖ´Ù:

+ +
    +
  • ´ç½ÅÀº °íÀÇ°Ç ½Ç¼öÀÌ°Ç »ç¿ëÀÚ°¡ ½Ã½ºÅÛÀ» °ø°Ý¿¡ ³ëÃâ½ÃÅ°´Â + ½ºÅ©¸³Æ®¸¦ ÀÛ¼ºÇÏÁö ¾Ê´Â´Ù°í ¹Ï´Â´Ù.
  • +
  • ½Ã½ºÅÛÀÇ ´Ù¸¥ ºÎºÐÀÇ º¸¾ÈÀÌ ¾àÇؼ­, ÀáÀçÀûÀÎ ÇãÁ¡À» + Çϳª ´õ ¸¸µé¾îµµ ³ªºüÁú °ÍÀÌ ¾ø´Ù°í »ý°¢ÇÏ´Â °æ¿ì.
  • +
  • »ç¿ëÀÚ°¡ ¾ø°í, ¾Æ¸¶ ¾Æ¹«µµ ¼­¹ö¸¦ ¹æ¹®ÇÏÁö¾Ê´Â °æ¿ì.
  • +
+ +
top
+
+

ScriptAliasÇÑ CGI

+ + + +

ƯÁ¤ µð·ºÅ丮¿¡¼­¸¸ CGI¸¦ ½ÇÇàÇÒ ¼ö ÀÖµµ·Ï Á¦ÇÑÇÏ¸é °ü¸®ÀÚ´Â + ÀÌµé µð·ºÅ丮¸¦ ÅëÁ¦ÇÒ ¼ö ÀÖ´Ù. ÀÌ °æ¿ì´Â scriptaliasÇÏÁö + ¾ÊÀº CGIº¸´Ù È®½ÇÈ÷ ¾ÈÀüÇÏ´Ù. ´Ü, ½Å·ÚÇÏ´Â »ç¿ëÀÚ¸¸ µð·ºÅ丮¿¡ + Á¢±ÙÇÒ ¼ö ÀÖ°í, °ü¸®ÀÚ°¡ »õ·Î¿î CGI ½ºÅ©¸³Æ®/ÇÁ·Î±×·¥ÀÇ + ÀáÀçÀûÀÎ º¸¾È»ó ÇãÁ¡À» °Ë»çÇÒ ¿ëÀÌ°¡ ÀÖ´Ù¸é.

+ +

´ëºÎºÐÀÇ »çÀÌÆ®´Â scriptaliasÇÏÁö ¾ÊÀº CGI ¹æ½Ä ´ë½Å + ÀÌ ¹æ½ÄÀ» »ç¿ëÇÑ´Ù.

+ +
top
+
+

µ¿Àû ³»¿ëÀ» »ý¼ºÇÏ´Â ´Ù¸¥ ¹æ¹ý

+ + + +

+ mod_php, mod_perl, mod_tcl, mod_python °°ÀÌ ¼­¹öÀÇ ÀϺηΠ+ µ¿ÀÛÇÏ´Â ÀÓº£µðµå ½ºÅ©¸³Æ®´Â ¼­¹ö¿Í °°Àº »ç¿ëÀÚ·Î (User Áö½Ã¾î Âü°í) ½ÇÇàµÇ±â¶§¹®¿¡, + ½ºÅ©¸³Æ® ¿£ÁøÀÌ ½ÇÇàÇÏ´Â ½ºÅ©¸³Æ®´Â ÀáÀçÀûÀ¸·Î ¼­¹ö »ç¿ëÀÚ°¡ + Á¢±ÙÇÒ ¼ö ÀÖ´Â ¸ðµç °Í¿¡ Á¢±ÙÇÒ ¼ö ÀÖ´Ù. ¾î¶² ½ºÅ©¸³Æ® ¿£ÁøÀº + ¾î´ÀÁ¤µµ Á¦ÇÑÀ» ÇÏÁö¸¸, ¾ÈÀüÇÏ´Ù°í °¡Á¤ÇÏÁö ¾Ê´Â °ÍÀÌ ÁÁ´Ù.

+ +
top
+
+

½Ã½ºÅÛ ¼³Á¤ º¸È£Çϱâ

+ + + +

Á¤¸»·Î ¾ÈÀüÇÑ ¼­¹ö¸¦ ¿î¿µÇÏ·Á¸é »ç¿ëÀÚ°¡ + .htaccess ÆÄÀÏÀ» »ç¿ëÇÏ¿© ´ç½ÅÀÌ ¼³Á¤ÇÑ º¸¾È±â´ÉÀ» + º¯°æÇÏ±æ ¹Ù¶óÁö ¾ÊÀ» °ÍÀÌ´Ù. ±×·¯±âÀ§ÇØ ´ÙÀ½°ú °°Àº ¹æ¹ýÀÌ + ÀÖ´Ù.

+ +

¼­¹ö ¼³Á¤ÆÄÀÏ¿¡ ´ÙÀ½À» Ãß°¡ÇÑ´Ù

+ +

+ <Directory />
+ AllowOverride None
+ </Directory> +

+ +

±×·¯¸é »ç¿ë°¡´ÉÇϵµ·Ï ¸í½ÃÀûÀ¸·Î Çã¿ëÇÑ µð·ºÅ丮¸¦ Á¦¿ÜÇÏ°í´Â + .htaccess ÆÄÀÏÀ» »ç¿ëÇÒ ¼ö ¾ø´Ù.

+ +
top
+
+

±âº»ÀûÀ¸·Î ¼­¹ö¿¡ ÀÖ´Â ÆÄÀÏ º¸È£Çϱâ

+ + + +

»ç¶÷µéÀº Á¾Á¾ ¾ÆÆÄÄ¡ÀÇ ±âº» Á¢±Ù¿¡ ´ëÇØ À߸ø ¾Ë°íÀÖ´Ù. + Áï, ¼­¹ö°¡ ÀϹÝÀûÀÎ URL ´ëÀÀ ±ÔÄ¢À» »ç¿ëÇÏ¿© ÆÄÀÏÀ» ãÀ» + ¼ö ÀÖ´Ù¸é, Ưº°È÷ Á¶Ä¡¸¦ ÇÏÁö ¾Ê´ÂÇÑ Å¬¶óÀ̾ðÆ®¿¡°Ô ÆÄÀÏÀÌ + ¼­ºñ½ºµÉ ¼ö ÀÖ´Ù.

+ +

¿¹¸¦ µé¾î, ¾Æ·¡¿Í °°Àº °æ¿ì:

+ +

+ # cd /; ln -s / public_html
+ http://localhost/~root/ ¿¡ Á¢±ÙÇÑ´Ù +

+ +

±×·¯¸é Ŭ¶óÀ̾ðÆ®´Â Àüü ÆÄÀϽýºÅÛÀ» µ¹¾Æ´Ù´Ò ¼ö ÀÖ´Ù. + À̸¦ ¸·±âÀ§ÇØ ¼­¹ö¼³Á¤¿¡¼­ ´ÙÀ½°ú °°Àº Á¶Ä¡¸¦ ÇÑ´Ù:

+ +

+ <Directory />
+ Order Deny,Allow
+ Deny from all
+ </Directory> +

+ +

±×·¯¸é ÆÄÀϽýºÅÛ À§Ä¡¿¡ ´ëÇØ ±âº» Á¢±ÙÀÌ °ÅºÎµÈ´Ù. + ¿øÇÏ´Â ¿µ¿ª¿¡ Á¢±ÙÇÒ ¼ö ÀÖµµ·Ï ´ÙÀ½°ú °°Àº Directory ºí·ÏÀ» Ãß°¡ÇÑ´Ù.

+ +

+ <Directory /usr/users/*/public_html>
+ Order Deny,Allow
+ Allow from all
+ </Directory>
+ <Directory /usr/local/httpd>
+ Order Deny,Allow
+ Allow from all
+ </Directory> +

+ +

Location°ú Directory Áö½Ã¾î¸¦ °°ÀÌ »ç¿ëÇÏ´Â + °æ¿ì Ưº°È÷ ÁÖÀǸ¦ ±â¿ï¿©¶ó. ¿¹¸¦ µé¾î, <Directory + />°¡ Á¢±ÙÀ» °ÅºÎÇÏ´õ¶óµµ <Location + /> Áö½Ã¾î°¡ À̸¦ ¹«½ÃÇÒ ¼ö ÀÖ´Ù

+ +

UserDir Áö½Ã¾î¸¦ + »ç¿ëÇÏ´Â °æ¿ì¿¡µµ ÁÖÀÇÇ϶ó. Áö½Ã¾î¸¦ "./" °°ÀÌ ¼³Á¤Çϸé + root »ç¿ëÀÚ¿¡ ´ëÇØ ¹Ù·Î À§ÀÇ °æ¿ì¿Í °°Àº ¹®Á¦°¡ ¹ß»ýÇÑ´Ù. + ¾ÆÆÄÄ¡ 1.3 ÀÌ»óÀ» »ç¿ëÇÑ´Ù¸é ¼­¹ö ¼³Á¤ÆÄÀÏ¿¡ ¾Æ·¡ ÁÙÀ» Ãß°¡Çϱæ + °­·ÂÈ÷ ±ÇÇÑ´Ù:

+ +

+ UserDir disabled root +

+ +
top
+
+

·Î±× »ìÆ캸±â

+ + + +

½ÇÁ¦·Î ¼­¹ö¿¡¼­ ¹«½¼ ÀÏÀÌ À־°í ÀÖ´ÂÁö ¾Ë·Á¸é ·Î±×ÆÄÀÏÀ» »ìÆìºÁ¾ß ÇÑ´Ù. ·Î±×ÆÄÀÏÀº + ÀÌ¹Ì ÀϾ Àϸ¸À» º¸°íÇÏÁö¸¸, ¼­¹ö¿¡ ¾î¶² °ø°ÝÀÌ ÀÖ¾ú´ÂÁö + ¾Ë·ÁÁÖ°í ÇöÀç ÇÊ¿äÇÑ ¸¸Å­ ¾ÈÀüÇÑÁö È®ÀÎÇÏ°Ô ÇØÁØ´Ù.

+ +

¿©·¯°¡Áö ¿¹:

+ +

+ grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
+ grep "client denied" error_log | tail -n 10 +

+ +

ù¹ø° ¿¹´Â À߸øµÈ + Source.JSP ¿äûÀ¸·Î ¼­¹öÁ¤º¸¸¦ ¾Ë¾Æ³¾ ¼ö ÀÖ´Â TomcatÀÇ + Ãë¾àÁ¡¸¦ ÀÌ¿ëÇÏ·Á´Â °ø°Ý Ƚ¼ö¸¦ ¾Ë·ÁÁÖ°í, µÎ¹ø° ¿¹´Â + Á¢±ÙÀÌ °ÅºÎµÈ Ãֱ٠Ŭ¶óÀ̾ðÆ® 10°³¸¦ ´ÙÀ½°ú °°ÀÌ º¸¿©ÁØ´Ù:

+ +

+ [Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied + by server configuration: /usr/local/apache/htdocs/.htpasswd +

+ +

Àß ¾Ë µíÀÌ ·Î±×ÆÄÀÏÀº ÀÌ¹Ì ¹ß»ýÇÑ »ç°Ç¸¸À» º¸°íÇÑ´Ù. + ±×·¡¼­ Ŭ¶óÀ̾ðÆ®°¡ .htpasswd ÆÄÀÏ¿¡ Á¢±ÙÇÒ + ¼ö ÀÖ¾ú´Ù¸é Á¢±Ù ·Î±×¿¡ + ´ÙÀ½°ú °°Àº ±â·ÏÀÌ ³²À» °ÍÀÌ´Ù:

+ +

+ foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1" +

+ +

Áï, ´ç½ÅÀº ¼­¹ö ¼³Á¤ÆÄÀÏ¿¡¼­ ´ÙÀ½ ºÎºÐÀ» ÁÖ¼®Ã³¸®ÇßÀ» + °ÍÀÌ´Ù:

+ +

+ <Files ~ "^\.ht">
+ Order allow,deny
+ Deny from all
+ <Files> +

+ +
+
+

°¡´ÉÇÑ ¾ð¾î:  en  | + ko  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/security_tips.html.tr.utf8 b/rubbos/app/apache2/manual/misc/security_tips.html.tr.utf8 new file mode 100644 index 00000000..7257521f --- /dev/null +++ b/rubbos/app/apache2/manual/misc/security_tips.html.tr.utf8 @@ -0,0 +1,344 @@ + + + +Güvenlik İpuçları - Apache HTTP Sunucusu + + + + + +
<-
+

Güvenlik İpuçları

+
+

Mevcut Diller:  en  | + ko  | + tr 

+
+ +

Bir HTTP Sunucusunu ayarlarken dikkat edilmesi gerekenler ve bazı + ipuçları. Öneriler kısmen Apache’ye özel kısmen de genel olacaktır.

+
+ +
top
+
+

Güncel Tutma

+ +

Apache HTTP Sunucusu iyi bir güvenlik sicilinin yanında güvenlik + konularıyla oldukça ilgili bir geliştirici topluluğuna sahiptir. Fakat, + bir yazılımın dağıtılmasının ardından küçük ya da büyük bazı sorunların + keşfedilmesi kaçınılmazdır. Bu sebeple, yazılım güncellemelerinden + haberdar olmak oldukça önem kazanır. HTTP sunucunuzu doğrudan + Apache’den temin ediyorsanız yeni sürümler ve güvenlik güncellemeleri + ile ilgili bilgileri tam zamanında alabilmek için Apache + HTTP Sunucusu Duyuru Listesine mutlaka üye olmanızı öneririz. + Apache yazılımının üçüncü parti dağıtımlarını yapanların da buna benzer + hizmetleri vardır.

+ +

Şüphesiz, bir HTTP sunucusu, sunucu kodunda bir sorun olmasa da + tehlike altındadır. Eklenti kodları, CGI betikleri hatta işletim + sisteminden kaynaklanan sorunlar nedeniyle bu ortaya çıkabilir. Bu + bakımdan, sisteminizdeki tüm yazılımların sorunları ve güncellemeleri + hakkında bilgi sahibi olmalısınız.

+ +
top
+
+

ServerRoot Dizinlerinin Ä°zinleri

+ + +

Normalde, Apache root kullanıcı tarafından başlatılır ve hizmetleri + sunarken User yönergesi + tarafından tanımlanan kullanıcının aidiyetinde çalışır. Root tarafından + çalıştırılan komutlarda olduğu gibi, root olmayan kullanıcıların + yapacakları değişikliklerden korunmak konusunda da dikkatli + olmalısınız. Dosyaların sadece root tarafından yazılabilir olmasını + sağlamak yeterli değildir, bu dizinler ve üst dizinler için de + yapılmalıdır. Örneğin, sunucu kök dizininin + /usr/local/apache olmasına karar verdiyseniz, bu dizini + root olarak şöyle oluşturmanız önerilir:

+ +

+ mkdir /usr/local/apache
+ cd /usr/local/apache
+ mkdir bin conf logs
+ chown 0 . bin conf logs
+ chgrp 0 . bin conf logs
+ chmod 755 . bin conf logs +

+ +

/, /usr, /usr/local + dizinlerinde sadece root tarafından değişiklik yapılabileceği kabul + edilir. httpd çalıştırılabilirini kurarken de benzer + bir önlemin alındığından emin olmalısınız:

+ +

+ cp httpd /usr/local/apache/bin
+ chown 0 /usr/local/apache/bin/httpd
+ chgrp 0 /usr/local/apache/bin/httpd
+ chmod 511 /usr/local/apache/bin/httpd +

+ +

Diğer kullanıcıların değişiklik yapabileceği bir dizin olarak bir + htdocs dizini oluşturabilirsiniz. Bu dizine root + tarafından çalıştırılabilecek dosyalar konulmamalı ve burada root + tarafından hiçbir dosya oluşturulmamalıdır.

+ +

Diğer kullanıcılara root tarafından yazılabilen ve çalıştırılabilen + dosyalarda değişiklik yapma hakkını tanırsanız, onlara root + kullanıcısını ele geçirilebilme hakkını da tanımış olursunuz. Örneğin, + biri httpd çalıştırılabilirini zararlı bir programla + değiştirebilir ve o programı tekrar çalıştırdığınız sırada program + yapacağını yapmış olur. Günlükleri kaydettiğiniz dizin herkes + tarafından yazılabilen bir dizin olduğu takdirde, birileri bir günlük + dosyasını bir sistem dosyasına sembolik bağ haline getirerek root + kullanıcısının bu dosyaya ilgisiz şeyler yazmasına sebep olabilir. + Günlüklerin dosyaları herkes tarafından yazılabilir olduğu takdirde ise + birileri dosyaya yanıltıcı veriler girebilir.

+
top
+
+

Sunucu Taraflı İçerik Yerleştirme

+ + +

SSI sayfaları bir sunucu yöneticisi açısından çeşitli olası risklere + kaynaklık edebilir.

+ +

İlk risk, sunucu yükündeki artış olasılığıdır. Tüm SSI sayfaları, SSI + kodu içersin içermesin Apache tarafından çözümlenir. Bu küçük bir artış + gibi görünürse de bir paylaşımlı sunucu ortamında önemli bir yük haline + gelebilir.

+ +

SSI sayfaları, CGI betikleriyle ilgili riskleri de taşır. exec + cmd elemanı kullanılarak bir SSI sayfasından herhangi bir CGI + betiğini veya bir sistem programını Apache’nin aidiyetinde olduğu + kullanıcının yetkisiyle çalıştırmak mümkündür.

+ +

SSI sayfalarının yararlı özelliklerinden yararlanırken güvenliğini de + arttırmanın bazı yolları vardır.

+ +

Sunucu yöneticisi, bir başıbozuk SSI sayfasının sebep olabileceği + zararları bertaraf etmek için CGI Genelinde + bölümünde açıklandığı gibi suexec’i etkin + kılabilir.

+ +

SSI sayfalarını .html veya .htm + uzantılarıyla etkinleştirmek tehlikeli olabilir. Bu özellikle + paylaşımlı ve yüksek trafikli bir sunucu ortamında önemlidir. SSI + sayfalarını normal sayfalardan farklı olarak .shtml gibi + bildik bir uzantıyla etkinleştirmek gerekir. Bu, sunucu yükünü asgari + düzeyde tutmaya ve risk yönetimini kolaylaştırmaya yarar.

+ +

Diğer bir çözüm de SSI sayfalarından betik ve program çalıştırmayı + iptal etmektir. Bu, Options + yönergesine değer olarak Includes yerine + IncludesNOEXEC vererek sağlanır. Ancak, eğer betiklerin + bulunduğu dizinde ScriptAlias + yönergesiyle CGI betiklerinin çalışması mümkün kılınmışsa, + kullanıcıların <--#include virtual="..." --> ile bu + betikleri çalıştırabileceklerine dikkat ediniz.

+ +
top
+
+

CGI Genelinde

+ + +

Herşeyden önce ya CGI betiğini/programını yazanlara ya da kendinizin + CGI'deki güvenlik açıklarını (ister kasıtlı olsun ister tesadüfi) + yakalama becerinize güvenmek zorundasınız. CGI betikleri esasen + sisteminizdeki komutları site kullanıcılarının izinleriyle + çalıştırırlar. Bu bakımdan dikkatle denenmedikleri takdirde oldukça + tehlikeli olabilirler.

+ +

CGI betiklerinin hepsi aynı kullanıcının aidiyetinde çalışırsa diğer + betiklerle aralarında çelişkilerin ortaya çıkması ister istemez + kaçınılmazdır. Örneğin A kullanıcısının B kullanıcısına garezi varsa + bir betik yazıp B’nin CGI veritabanını silebilir. Bu gibi durumların + ortaya çıkmaması için betiklerin farklı kullanıcıların aidiyetlerinde + çalışmasını sağlayan ve 1.2 sürümünden beri Apache ile dağıtılan suEXEC diye bir program vardır. Başka bir yol + da CGIWrap kullanmaktır.

+ +
top
+
+

ScriptAlias’sız CGI

+ + +

Kullanıcıların sitenin her yerinde CGI betiklerini çalıştırmalarına + izin vermek ancak şu koşullarda mümkün olabilir:

+ +
    +
  • Kullanıcılarınızın kasıtlı ya da kasıtsız sistemi saldırıya açık + hale getirecek betikler yazmayacaklarına tam güveniniz vardır.
  • +
  • Sitenizin güvenliÄŸi zaten o kadar kötüdür ki, bir delik daha + açılmasının mahzuru yoktur.
  • +
  • Sitenizin sizden baÅŸka kullanıcısı yoktur ve sunucunuzu sizden + baÅŸka hiç kimsenin ziyaret etmesi mümkün deÄŸildir.
  • +
+ +
top
+
+

ScriptAlias’lı CGI

+ + +

CGI’yi belli dizinlerle sınırlamak yöneticiye bu dizinlerde daha iyi + denetim imkanı sağlar. Bu kaçınılmaz olarak ScriptAlias’sız CGI’den çok daha + güvenlidir, ancak bu dizinlere yazma hakkı olan kullanıcılarınız + güvenilir kişiler olması ve site yöneticisinin de olası güvenlik + açıklarına karşı CGI betiklerini ve programlarını denemeye istekli + olması şartıyla.

+ +

Çoğu site yöneticisi ScriptAlias’sız CGI yerine bu + yaklaşımı seçer.

+ +
top
+
+

Devingen içerikli kaynaklar

+ + +

Sunucunun bir parçası gibi çalışan, mod_php, + mod_perl, mod_tcl ve mod_python + gibi gömülü betik çalıştırma seçenekleri sunucuyu çalıştıran + kullanıcının aidiyetinde çalışırlar (User yönergesine bakınız). Bu bakımdan bu betik + yorumlayıcılar tarafından çalıştırılan betikler, sunucu kullanıcısının + eriştiği herşeye erişebilirler. Bazı betik yorumlayıcıların getirdiği + bazı sınırlamalar varsa da bunlara pek güvenmemek, gerekli sınamaları + yine de yapmak gerekir.

+ +
top
+
+

Sistem Ayarlarının Korunması

+ + +

Güvenliği gerçekten sıkı tutmak istiyorsanız, kullanıcılarınızın + yapılandırmanızdaki güvenlik ayarlarını geçersiz kılmak için + .htaccess dosyalarını kullanabilmelerinin de önüne + geçmelisiniz. Bunu yapmanın tek bir yolu vardır.

+ +

Sunucu yapılandırma dosyanıza şunu yerleştirin:

+ +

+ <Directory /> + + AllowOverride None + + </Directory> +

+ +

Böylece, belli dizinlerde özellikle etkinleştirilmedikçe bütün + dizinlerde .htaccess dosyalarının kullanımını engellemiş + olursunuz.

+ +
top
+
+

Sunucu dosyalarının öntanımlı olarak korunması

+ + +

Apache’nin ister istemez yanlış anlaşılan yönlerinden biri öntanımlı erişim özelliğidir. Yani siz aksine bir şeyler yapmadıkça, sunucu normal URL eşleme kurallarını kullanarak bir dosyayı bulabildiği sürece onu istemciye sunacaktır.

+ +

Örneğin, aşağıdaki durumu ele alalım:

+ +

+ # cd /; ln -s / public_html +

+ +

Ve, tarayıcınıza http://localhost/~root/ yazın.

+ +

Böylece, istemcilerin tüm dosya sisteminizi gezmelerine izin vermiş olursunuz. Bu işlemin sonuçlarının önünü almak için sunucu yapılandırma dosyanıza şunları yazın:

+ +

+ <Directory /> + + Order Deny,Allow
+ Deny from all +
+ </Directory> +

+ +

Bu suretle, dosya sisteminize öntanımlı erişimi yasaklamış olursunuz. Erişime izin vermek istediğiniz dizinler için uygun Directory bölümleri eklemeniz yeterli olacaktır. Örnek:

+ +

+ <Directory /usr/users/*/public_html> + + Order Deny,Allow
+ Allow from all +
+ </Directory>
+ <Directory /usr/local/httpd> + + Order Deny,Allow
+ Allow from all +
+ </Directory> +

+ +

Location ve Directory yönergelerinin etkileşimine de özellikle önem vermelisiniz; örneğin <Directory /> erişimi yasaklarken bir <Location /> yönergesi bunu ortadan kaldırabilir.

+ +

UserDir yönergesi de size buna benzer bir oyun oynayabilir; yönergeye ./ atamasını yaparsanız, root kullanıcısı söz konusu olduğunda yukarıda ilk örnekteki durumla karşılaşırız. Apache 1.3 veya üstünü kullanıyorsanız, sunucu yapılandırma dosyanızda aşağıdaki satırın mutlaka bulunmasını öneririz:

+ +

+ UserDir disabled root +

+ +
top
+
+

Günlüklerin İzlenmesi

+ + +

Sunucunuzda olup biteni günü gününe bilmek istiyorsanız günlük dosyalarına bakmalısınız. Günlük dosyaları sadece olup biteni raporlamakla kalmaz, sunucunuza ne tür saldırılar yapıldığını ve güvenlik seviyenizin yeterli olup olmadığını anlamanızı da sağlarlar.

+ +

Bazı örnekler:

+ +

+ grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
+ grep "client denied" error_log | tail -n 10 +

+ +

İlk örnek, Apache Tomcat + Source.JSP Bozuk İstek Bilgilerini İfşa Açığını istismar etmeyi deneyen saldırıların sayısını verirken ikinci örnek, reddedilen son on istemciyi listeler; örnek:

+ +

+ [Thu Jul 11 17:18:39 2002] [error] [client falan.filan.dom] client denied + by server configuration: /usr/local/apache/htdocs/.htpasswd +

+ +

Gördüğünüz gibi günlük dosyaları sadece ne olup bittiğini raporlar, bu bakımdan eğer istemci .htpasswd dosyasına erişebiliyorsa erişim günlüğünüzde şuna benzer bir kayıt görürsünüz:

+ +

+ falan.filan.dom - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1" +

+ +

Bu, sunucu yapılandırma dosyanızda aşağıdaki yapılandırmayı iptal ettiğiniz anlamına gelir:

+ +

+ <Files ~ "^\.ht"> + + Order allow,deny
+ Deny from all +
+ </Files> +

+ +
+
+

Mevcut Diller:  en  | + ko  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/misc/tutorials.html b/rubbos/app/apache2/manual/misc/tutorials.html new file mode 100644 index 00000000..e17505c2 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/tutorials.html @@ -0,0 +1,5 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: tutorials.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 diff --git a/rubbos/app/apache2/manual/misc/tutorials.html.en b/rubbos/app/apache2/manual/misc/tutorials.html.en new file mode 100644 index 00000000..0b9f2d12 --- /dev/null +++ b/rubbos/app/apache2/manual/misc/tutorials.html.en @@ -0,0 +1,211 @@ + + + +Apache Tutorials - Apache HTTP Server + + + + + +
<-
+

Apache Tutorials

+
+

Available Languages:  en 

+
+ + +

Warning:

+

This document has not been fully updated + to take into account changes made in the 2.0 version of the + Apache HTTP Server. Some of the information may still be + relevant, but please use it with care.

+
+ +

The following documents give you step-by-step instructions + on how to accomplish common tasks with the Apache HTTP server. + Many of these documents are located at external sites and are + not the work of the Apache Software Foundation. Copyright to + documents on external sites is owned by the authors or their + assignees. Please consult the official Apache + Server documentation to verify what you read on external + sites.

+ +
+ +
top
+
top
+
+

Basic Configuration

+ + + + +
top
+
top
+
+

Logging

+ + + + +
top
+
+

CGI and SSI

+ + + + +
top
+
+

Other Features

+ + + + + +

If you have a pointer to an accurate and well-written + tutorial not included here, please let us know by submitting it + to the Apache Bug + Database.

+
+
+

Available Languages:  en 

+
+ \ No newline at end of file -- cgit 1.2.3-korg