From fe39ffb8b90ae4e002ed73fe98617cd590abb467 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 27 Apr 2024 08:33:50 +0200 Subject: Adding upstream version 2.4.56. Signed-off-by: Daniel Baumann --- docs/manual/misc/index.html | 25 + docs/manual/misc/index.html.en | 94 ++ docs/manual/misc/index.html.es | 100 ++ docs/manual/misc/index.html.fr.utf8 | 99 ++ docs/manual/misc/index.html.ko.euc-kr | 95 ++ docs/manual/misc/index.html.tr.utf8 | 96 ++ docs/manual/misc/index.html.zh-cn.utf8 | 85 ++ docs/manual/misc/password_encryptions.html | 9 + docs/manual/misc/password_encryptions.html.en | 259 +++++ docs/manual/misc/password_encryptions.html.fr.utf8 | 273 +++++ docs/manual/misc/perf-tuning.html | 17 + docs/manual/misc/perf-tuning.html.en | 986 ++++++++++++++++++ docs/manual/misc/perf-tuning.html.fr.utf8 | 1058 ++++++++++++++++++++ docs/manual/misc/perf-tuning.html.ko.euc-kr | 1006 +++++++++++++++++++ docs/manual/misc/perf-tuning.html.tr.utf8 | 1021 +++++++++++++++++++ docs/manual/misc/relevant_standards.html | 13 + docs/manual/misc/relevant_standards.html.en | 234 +++++ docs/manual/misc/relevant_standards.html.fr.utf8 | 253 +++++ docs/manual/misc/relevant_standards.html.ko.euc-kr | 221 ++++ docs/manual/misc/security_tips.html | 17 + docs/manual/misc/security_tips.html.en | 491 +++++++++ docs/manual/misc/security_tips.html.fr.utf8 | 513 ++++++++++ docs/manual/misc/security_tips.html.ko.euc-kr | 373 +++++++ docs/manual/misc/security_tips.html.tr.utf8 | 485 +++++++++ 24 files changed, 7823 insertions(+) create mode 100644 docs/manual/misc/index.html create mode 100644 docs/manual/misc/index.html.en create mode 100644 docs/manual/misc/index.html.es create mode 100644 docs/manual/misc/index.html.fr.utf8 create mode 100644 docs/manual/misc/index.html.ko.euc-kr create mode 100644 docs/manual/misc/index.html.tr.utf8 create mode 100644 docs/manual/misc/index.html.zh-cn.utf8 create mode 100644 docs/manual/misc/password_encryptions.html create mode 100644 docs/manual/misc/password_encryptions.html.en create mode 100644 docs/manual/misc/password_encryptions.html.fr.utf8 create mode 100644 docs/manual/misc/perf-tuning.html create mode 100644 docs/manual/misc/perf-tuning.html.en create mode 100644 docs/manual/misc/perf-tuning.html.fr.utf8 create mode 100644 docs/manual/misc/perf-tuning.html.ko.euc-kr create mode 100644 docs/manual/misc/perf-tuning.html.tr.utf8 create mode 100644 docs/manual/misc/relevant_standards.html create mode 100644 docs/manual/misc/relevant_standards.html.en create mode 100644 docs/manual/misc/relevant_standards.html.fr.utf8 create mode 100644 docs/manual/misc/relevant_standards.html.ko.euc-kr create mode 100644 docs/manual/misc/security_tips.html create mode 100644 docs/manual/misc/security_tips.html.en create mode 100644 docs/manual/misc/security_tips.html.fr.utf8 create mode 100644 docs/manual/misc/security_tips.html.ko.euc-kr create mode 100644 docs/manual/misc/security_tips.html.tr.utf8 (limited to 'docs/manual/misc') diff --git a/docs/manual/misc/index.html b/docs/manual/misc/index.html new file mode 100644 index 0000000..af26b8b --- /dev/null +++ b/docs/manual/misc/index.html @@ -0,0 +1,25 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: index.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: index.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + +URI: index.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: index.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR + +URI: index.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 + +URI: index.html.zh-cn.utf8 +Content-Language: zh-cn +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/misc/index.html.en b/docs/manual/misc/index.html.en new file mode 100644 index 0000000..ee71fa2 --- /dev/null +++ b/docs/manual/misc/index.html.en @@ -0,0 +1,94 @@ + + + + + +Apache Miscellaneous Documentation - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Apache Miscellaneous Documentation

+
+

Available Languages:  en  | + es  | + fr  | + ko  | + tr  | + zh-cn 

+
+ + +

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

+ +

Warning

+

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

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

+
+ +
Relevant Standards
+ +
+

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

+
+ +
Password Encryption Formats
+ +
+

Discussion of the various ciphers supported by Apache for + authentication purposes.

+
+
+ +
+
+
+

Available Languages:  en  | + es  | + fr  | + ko  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/misc/index.html.es b/docs/manual/misc/index.html.es new file mode 100644 index 0000000..a0c8f29 --- /dev/null +++ b/docs/manual/misc/index.html.es @@ -0,0 +1,100 @@ + + + + + +Documentación Variada de Apache - Servidor HTTP Apache Versión 2.4 + + + + + + +
+

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versión 2.4 del Servidor HTTP Apache

+
+
<-
+

Documentación Variada de Apache

+
+

Idiomas disponibles:  en  | + es  | + fr  | + ko  | + tr  | + zh-cn 

+
+ + +

A continuación verá una lista de páginas adicionales de documentación que + aplican al proyecto de desarrollo del servidor web Apache.

+ +

Atención

+

Los documentos no han sido completamente actualizados para tener en cuenta + los cambios realizados en la versión 2.1 del Servidor Apache HTTP. Alguna + información todavía puede ser relevante, por favor revísela con cuidado.

+
+ +
+
Notas de Rendimiento - Mejorando Apache +
+ +
+

Notas sobre como configurar (en tiempo real y tiempo de compilación) + Apache para el mejor rendimiento. Notas explicando por qué Apache hace + ciertas cosas y por qué no hace otras (que le hacen ser más lento/rápido). +

+
+ +
Escalado de Rendimiento
+ +
+

Alguna configuración de fácil acceso y opciones de mejora para Apache + httpd 2.2 y 2.4 así como herramientas de motorización.

+
+ +
Consejos de Seguridad
+ +
+

Algunas de las cosas que se deben y no deben hacer para mantener seguro + su sitio web Apache.

+
+ +
Estándares Relevantes
+ +
+

Este documento actúa como una página de referencia para la mayor parte + de estándares relevantes que Apache sigue.

+
+ +
Formatos de Cifrado de Contraseñas
+ +
+

Discusión de los distintos cifrados soportados por Apache para el proceso + de autenticación.

+
+
+ +
+
+
+

Idiomas disponibles:  en  | + es  | + fr  | + ko  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/misc/index.html.fr.utf8 b/docs/manual/misc/index.html.fr.utf8 new file mode 100644 index 0000000..eba9551 --- /dev/null +++ b/docs/manual/misc/index.html.fr.utf8 @@ -0,0 +1,99 @@ + + + + + +Documentations diverses sur Apache - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Documentations diverses sur Apache

+
+

Langues Disponibles:  en  | + es  | + fr  | + ko  | + tr  | + zh-cn 

+
+ + +

Vous trouverez plus loin une liste de pages de documentation + additionnelles concernant le projet de développement du serveur web + Apache.

+ +

Avertissement

+

La mise à jour des documents ci-dessous permettant de prendre en + compte les modifications apportées par la version 2.1 du serveur + HTTP Apache n'a pas été entièrement menée à bien. Certaines + informations sont probablement encore pertinentes, mais utilisez-les tout de même avec + précautions.

+
+ +
+
Notes à propos des performances - + Réglages fins d'Apache
+ +
+

Notes à propos de la configuration d'Apache pour de plus + hautes performances (à l'exécution et à la compilation). Notes + expliquant pourquoi Apache accomplit certaines choses et + n'en accomplit pas certaines autres (les premières l'accélérant + et les deuxièmes le ralentissant).

+
+ +
Conseils concernant la + sécurité
+ +
+

Quelques conseils de type "faites" ou "ne faites pas" pour + que votre site web Apache reste sécurisé.

+
+ +
Standards concernés
+ +
+

Ce document constitue une page de référence pour la plupart + des standards concernés par Apache.

+
+ +
Formats de chiffrement des + mots de passe
+ +
+

Discussion à propos des divers algorithmes de chiffrement + supportés par Apache à des fins d'authentification.

+
+
+ +
+
+
+

Langues Disponibles:  en  | + es  | + fr  | + ko  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/misc/index.html.ko.euc-kr b/docs/manual/misc/index.html.ko.euc-kr new file mode 100644 index 0000000..39e5417 --- /dev/null +++ b/docs/manual/misc/index.html.ko.euc-kr @@ -0,0 +1,95 @@ + + + + + +Ÿ ġ - Apache HTTP Server Version 2.4 + + + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.4

+
+
<-
+

Ÿ ġ

+
+

:  en  | + es  | + fr  | + ko  | + tr  | + zh-cn 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+ + +

Ʒ ġ Ʈ ߰ + ̴.

+ +

+

Ʒ ġ 2.1 + ʴ. ȿ , ؼ + ϱ ٶ.

+
+ +
+
ġ
+ +
+

ְ ġ (, Ͻ) + ϴ ٷ. ġ  ۾ ϰ + (ġ ų )  ۾ ʴ + Ѵ.

+
+ +
+ +
+

ġ ϰ ϱ " " " + ƾ ".

+
+ +
URL ۼ ħ
+ +
+

mod_rewrite Ѵ. + ڰ ۾ εġԵǴ + URL ذϱؼ  ġ + mod_rewrite ϴ Ѵ.

+
+ +
ǥ
+ +
+

ġ ǥص Ѵ.

+
+
+ +
+
+
+

:  en  | + es  | + fr  | + ko  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/misc/index.html.tr.utf8 b/docs/manual/misc/index.html.tr.utf8 new file mode 100644 index 0000000..bc261a5 --- /dev/null +++ b/docs/manual/misc/index.html.tr.utf8 @@ -0,0 +1,96 @@ + + + + + +Çeşitli Belgeler - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + +
+

Modüller | Yönergeler | SSS | Terimler | Site Haritası

+

Apache HTTP Sunucusu Sürüm 2.4

+
+
<-
+

Çeşitli Belgeler

+
+

Mevcut Diller:  en  | + es  | + fr  | + ko  | + tr  | + zh-cn 

+
+ + +

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

+ +

Uyarı

+

Aşağıdaki belgeler, Apache HTTP Sunucusunun 2.1 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.

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

+
+ +
İlgili Standartlar
+ +
+

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

+
+ +
Parola Şifreleme Biçimleri +
+ +
+

Belgede, kimlik doğrulama amacıyla Apache tarafından desteklenen + çeşitli şifreleme tekniklerinden bahsedilmiştir.

+
+
+ +
+
+
+

Mevcut Diller:  en  | + es  | + fr  | + ko  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/misc/index.html.zh-cn.utf8 b/docs/manual/misc/index.html.zh-cn.utf8 new file mode 100644 index 0000000..6a68f35 --- /dev/null +++ b/docs/manual/misc/index.html.zh-cn.utf8 @@ -0,0 +1,85 @@ + + + + + +Apache 杂项文档 - Apache HTTP 服务器 版本 2.4 + + + + + + +
+

模块 | 指令 | 常见问题 | 术语 | 网站导航

+

Apache HTTP 服务器版本 2.4

+
+
<-
+

Apache 杂项文档

+
+

可用语言:  en  | + es  | + fr  | + ko  | + tr  | + zh-cn 

+
+ + +

下面是适用于 Apache 服务器开发项目的附加文档。

+ +

警告

+

下面的文档尚未完全更新，以反映自 Apache HTTP 服务器版本 2.1 + 之后的修改。某些信息可能仍旧适用，但请小心使用它。

+
+ +
+
Apache 性能调谐
+ +
+

对如何在编译或运行时，配置 Apache，以便性能更高的说明。 + 解释了为什么 Apache 这样做，而不那样做 (这会让它更慢或更快)。

+
+ +
安全技巧
+ +
+

做和不做 - 如何让你的 Apache 站点保持安全。

+
+ +
相关标准
+ +
+

这篇文档是 Apache 遵循的相关标准的参考页面。

+
+ +
密码加密格式
+ +
+

对 Apache 身份认证支持的各种密码加密格式的讨论。

+
+
+ +
+
+
+

可用语言:  en  | + es  | + fr  | + ko  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/misc/password_encryptions.html b/docs/manual/misc/password_encryptions.html new file mode 100644 index 0000000..8a5b19c --- /dev/null +++ b/docs/manual/misc/password_encryptions.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: password_encryptions.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: password_encryptions.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/misc/password_encryptions.html.en b/docs/manual/misc/password_encryptions.html.en new file mode 100644 index 0000000..129bae8 --- /dev/null +++ b/docs/manual/misc/password_encryptions.html.en @@ -0,0 +1,259 @@ + + + + + +Password Formats - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Password Formats

+
+

Available Languages:  en  | + fr 

+
+ +

Notes about the password encryption formats generated and understood by + Apache.

+
+ +
top
+
+

Basic Authentication

+ +

There are five formats that Apache recognizes for basic-authentication + passwords. Note that not all formats work on every platform:

+ +
+
bcrypt
+
"$2y$" + the result of the crypt_blowfish algorithm. + See the APR source file + crypt_blowfish.c + for the details of the algorithm.
+ +
MD5
+
"$apr1$" + the result of an Apache-specific algorithm using an + iterated (1,000 times) MD5 digest of various combinations of a + random 32-bit salt and the password. See the APR source file + apr_md5.c + for the details of the algorithm.
+ +
SHA1
+
"{SHA}" + Base64-encoded SHA-1 digest of the password. Insecure.
+ +
CRYPT
+
Unix only. Uses the traditional Unix crypt(3) function + with a randomly-generated 32-bit salt (only 12 bits used) and the first 8 + characters of the password. Insecure.
+ +
PLAIN TEXT (i.e. unencrypted)
+
Windows & Netware only. Insecure.
+
+ +

Generating values with htpasswd

+ +

bcrypt

+ $ htpasswd -nbB myName myPassword
+ myName:$2y$05$c4WoMPo3SXsafkva.HHa6uXQZWr7oboPiC2bT/r7q1BB8I2s0BRqC +

+ +

MD5

+ $ htpasswd -nbm myName myPassword
+ myName:$apr1$r31.....$HqJZimcKQFAMYayBlzkrA/ +

+ +

SHA1

+ $ htpasswd -nbs myName myPassword
+ myName:{SHA}VBPuJHI7uixaa6LQGWx4s+5GKNE= +

+ +

CRYPT

+ $ htpasswd -nbd myName myPassword
+ myName:rqXexS6ZhobKA +

+ + + +

Generating CRYPT and MD5 values with the OpenSSL + command-line program

+ + +

OpenSSL knows the Apache-specific MD5 algorithm.

+ +

MD5

+ $ openssl passwd -apr1 myPassword
+ $apr1$qHDFfhPC$nITSVHgYbDAK1Y0acGRnY0 +

+ +

CRYPT

+ openssl passwd -crypt myPassword
+ qQ5vTYO3c8dsU +

+ + +

Validating CRYPT or MD5 passwords with the OpenSSL command + line program

+ +

The salt for a CRYPT password is the first two characters (converted to + a binary value). To validate myPassword against + rqXexS6ZhobKA

+ +

CRYPT

+ $ openssl passwd -crypt -salt rq myPassword
+ Warning: truncating password to 8 characters
+ rqXexS6ZhobKA +

+ +

Note that using myPasswo instead of + myPassword will produce the same result because only the + first 8 characters of CRYPT passwords are considered.

+ +

The salt for an MD5 password is between $apr1$ and the + following $ (as a Base64-encoded binary value - max 8 chars). + To validate myPassword against + $apr1$r31.....$HqJZimcKQFAMYayBlzkrA/

+ +

MD5

+ $ openssl passwd -apr1 -salt r31..... myPassword
+ $apr1$r31.....$HqJZimcKQFAMYayBlzkrA/ +

+ + +

Database password fields for mod_dbd

+

The SHA1 variant is probably the most useful format for DBD + authentication. Since the SHA1 and Base64 functions are commonly + available, other software can populate a database with encrypted passwords + that are usable by Apache basic authentication.

+ +

To create Apache SHA1-variant basic-authentication passwords in various + languages:

+ +

PHP

+ '{SHA}' . base64_encode(sha1($password, TRUE)) +

+ +

Java

+ "{SHA}" + new sun.misc.BASE64Encoder().encode(java.security.MessageDigest.getInstance("SHA1").digest(password.getBytes())) +

+ +

ColdFusion

+ "{SHA}" & ToBase64(BinaryDecode(Hash(password, "SHA1"), "Hex")) +

+ +

Ruby

+ require 'digest/sha1'
+ require 'base64'
+ '{SHA}' + Base64.encode64(Digest::SHA1.digest(password)) +

+ +

C or C++

+ Use the APR function: apr_sha1_base64 +

+ +

Python

+ import base64
+ import hashlib
+ "{SHA}" + format(base64.b64encode(hashlib.sha1(password).digest())) +

+ +

PostgreSQL (with the contrib/pgcrypto functions + installed)

+ + '{SHA}'||encode(digest(password,'sha1'),'base64') +

+ + +
top
+
+

Digest Authentication

+

Apache recognizes one format for + digest-authentication passwords - the MD5 hash of the string + user:realm:password as a 32-character string of hexadecimal + digits. realm is the Authorization Realm argument to the + AuthName directive in + httpd.conf.

+ +

Database password fields for mod_dbd

+ +

Since the MD5 function is commonly available, other software can + populate a database with encrypted passwords that are usable by Apache + digest authentication.

+ +

To create Apache digest-authentication passwords in various + languages:

+ +

PHP

+ md5($user . ':' . $realm . ':' .$password) +

+ +

Java

+ byte b[] = java.security.MessageDigest.getInstance("MD5").digest( (user + ":" + realm + ":" + password ).getBytes());
+ java.math.BigInteger bi = new java.math.BigInteger(1, b);
+ String s = bi.toString(16);
+ while (s.length() < 32)
+ + s = "0" + s; + + // String s is the encrypted password +

+ +

ColdFusion

+ LCase(Hash( (user & ":" & realm & ":" & password) , "MD5")) +

+ +

Ruby

+ require 'digest/md5'
+ Digest::MD5.hexdigest(user + ':' + realm + ':' + password) +

+ +

PostgreSQL (with the contrib/pgcrypto functions installed)

+ + encode(digest( user || ':' || realm || ':' || password , 'md5'), 'hex') +

+ + +
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/misc/password_encryptions.html.fr.utf8 b/docs/manual/misc/password_encryptions.html.fr.utf8 new file mode 100644 index 0000000..b7e0f2c --- /dev/null +++ b/docs/manual/misc/password_encryptions.html.fr.utf8 @@ -0,0 +1,273 @@ + + + + + +Formats de mots de passe - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Formats de mots de passe

+
+

Langues Disponibles:  en  | + fr 

+
+ +

Notes à propos des formats de chiffrement des mots de passe + générés et compris par Apache.

+
+ +
top
+
+

Authentification de base

+ +

Voici les cinq formats de mots de passe qu'Apache reconnaît + pour l'authentification de base. Notez que tous les formats ne sont + pas supportés par toutes les plates-formes :

+ +
+ +
bcrypt
+
"$2y$" + the result of the crypt_blowfish algorithm. Dérivé + de l'algorythme de chiffrement crypt_blowfish. Voir le fichier + source APR crypt_blowfish.c + pour plus de détails à propos de cet algorithme.
+ +
MD5
+
"$apr1$" + le résultat d'un algorithme spécifique à Apache + utilisant un condensé MD5 réitéré (1000 fois) de combinaisons + variées du mot de passe et d'une source d'entropie sur 32 bits. + Voir le fichier source APR apr_md5.c + pour les détails de l'algorithme.
+ + +
SHA1
+
"{SHA}" + un condensé SHA-1 du mot de passe codé en + Base64. Non sûr.
+ +
CRYPT
+
Unix seulement. Utilise la fonction Unix traditionnelle + crypt(3) avec une source d'entropie sur 32 bits + (seuls 12 bits sont utilisés), et seulement les 8 premiers + caractères du mot de passe. Non sûr.
+ +
PLAIN TEXT (autrement dit non chiffré)
+
Windows & Netware seulement. Non sûr.
+
+

Générer des mots de passe avec htpasswd

+ +

bcrypt

+ $ htpasswd -nbB monNom monMot-de-passe
+ monNom:$2y$05$c4WoMPo3SXsafkva.HHa6uXQZWr7oboPiC2bT/r7q1BB8I2s0BRqC +

+ +

MD5

+ $ htpasswd -nbm monNom monMot-de-passe
+ monNom:$apr1$r31.....$HqJZimcKQFAMYayBlzkrA/ +

+ +

SHA1

+ $ htpasswd -nbs monNom monMot-de-passe
+ monNom:{SHA}VBPuJHI7uixaa6LQGWx4s+5GKNE= +

+ +

CRYPT

+ $ htpasswd -nbd monNom monMot-de-passe
+ monNom:rqXexS6ZhobKA +

+ + + +

Générer des mots de passe CRYPT and MD5 avec le programme + OpenSSL en ligne de commande

+ + +

OpenSSL connaît l'algorithme MD5 spécifique à Apache.

+ +

MD5

+ $ openssl passwd -apr1 monMot-de-passe
+ $apr1$qHDFfhPC$nITSVHgYbDAK1Y0acGRnY0 +

+ +

CRYPT

+ openssl passwd -crypt monMot-de-passe
+ qQ5vTYO3c8dsU +

+ + +

Valider des mots de passe CRYPT and MD5 avec le programme + OpenSSL en ligne de commande

+ +

La source d'entropie pour un mot de passe CRYPT est constituée + des deux premiers caractères (convertis en valeur binaire). Pour + valider monMot-de-passe par rapport à + rqXexS6ZhobKA

+ +

CRYPT

+ $ openssl passwd -crypt -salt rq monMot-de-passe
+ Warning: truncating password to 8 characters
+ rqXexS6ZhobKA +

+ +

Notez que spécifier monMot-d au lieu de + monMot-de-passe produira le même résultat car seuls + les 8 premiers caractères des mots de passe CRYPT sont pris en + compte.

+ +

La source d'entropie pour un mot de passe MD5 se situe entre + $apr1$ et le caractère $ suivant (sous + la forme d'une valeur binaire codée en Base64 - au maximum 8 + caractères). Pour valider monMot-de-passe par rapport + à $apr1$r31.....$HqJZimcKQFAMYayBlzkrA/

+ +

MD5

+ $ openssl passwd -apr1 -salt r31..... monMot-de-passe
+ $apr1$r31.....$HqJZimcKQFAMYayBlzkrA/ +

+ + +

Champs mot de passe de base de données pour + mod_dbd

+

La variante SHA1 constitue probablement le format le mieux + approprié pour l'authentification DBD. Comme les fonctions SHA1 et + Base64 sont en général disponibles, d'autres logiciels peuvent + renseigner une base de données avec des mots de passe chiffrés + utilisables par l'authentification basique d'Apache.

+ +

Pour créer des mots de passe au format SHA1 pour + l'authentification de base d'Apache dans divers langages :

+ +

PHP

+ '{SHA}' . base64_encode(sha1($password, TRUE)) +

+ +

Java

+ "{SHA}" + new sun.misc.BASE64Encoder().encode(java.security.MessageDigest.getInstance("SHA1").digest(password.getBytes())) +

+ +

ColdFusion

+ "{SHA}" & ToBase64(BinaryDecode(Hash(password, "SHA1"), "Hex")) +

+ +

Ruby

+ require 'digest/sha1'
+ require 'base64'
+ '{SHA}' + Base64.encode64(Digest::SHA1.digest(password)) +

+ +

C ou C++

+ Utilisez la fonction APR : apr_sha1_base64 +

+ +

Python

+ import base64
+ import hashlib
+ "{SHA}" + format(base64.b64encode(hashlib.sha1(password).digest())) +

+ +

PostgreSQL (avec les fonctions contrib/pgcrypto + installées)

+ + '{SHA}'||encode(digest(password,'sha1'),'base64') +

+ + +
top
+
+

Authentification à base de condensés

+

Apache ne reconnaît qu'un format pour les mots de passe + d'authentification à base de condensés - le condensé MD5 de la + chaîne utilisateur:domaine-de-protection:mot-de-passe + sous la forme d'une chaîne de 32 caractères au format hexadécimal. + domaine-de-protection est l'identifiant du domaine de + protection de l'autorisation passé en argument à la directive + AuthName dans + httpd.conf.

+ +

Champs de mot de passe de base de données pour + mod_dbd

+ +

Comme la fonction MD5 est en général disponible, d'autres + logiciels peuvent renseigner une base de données avec des mots de + passe chiffrés utilisables par l'authentification à base de + condensés d'Apache.

+ +

Pour créer des mots de passe pour l'authentification à base de + condensés d'Apache dans divers langages :

+ +

PHP

+ md5($user . ':' . $realm . ':' .$password) +

+ +

Java

+ byte b[] = java.security.MessageDigest.getInstance("MD5").digest( (user + ":" + realm + ":" + password ).getBytes());
+ java.math.BigInteger bi = new java.math.BigInteger(1, b);
+ String s = bi.toString(16);
+ while (s.length() < 32)
+ + s = "0" + s; + + // La chaîne s contient le mot de passe chiffré +

+ +

ColdFusion

+ LCase(Hash( (user & ":" & realm & ":" & password) , "MD5")) +

+ +

Ruby

+ require 'digest/md5'
+ Digest::MD5.hexdigest(user + ':' + realm + ':' + password) +

+ +

PostgreSQL (avec les fonctions contrib/pgcrypto + installées)

+ + encode(digest( user || ':' || realm || ':' || password , 'md5'), 'hex') +

+ + +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/misc/perf-tuning.html b/docs/manual/misc/perf-tuning.html new file mode 100644 index 0000000..7ff8118 --- /dev/null +++ b/docs/manual/misc/perf-tuning.html @@ -0,0 +1,17 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: perf-tuning.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: perf-tuning.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +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/docs/manual/misc/perf-tuning.html.en b/docs/manual/misc/perf-tuning.html.en new file mode 100644 index 0000000..8047328 --- /dev/null +++ b/docs/manual/misc/perf-tuning.html.en @@ -0,0 +1,986 @@ + + + + + +Apache Performance Tuning - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Apache Performance Tuning

+
+

Available Languages:  en  | + fr  | + 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 MaxRequestWorkers setting so that your server + does not spawn so many children that it starts swapping. The 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 patch level 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

+ + + +
Related ModulesRelated Directives
+ +

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 need 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 for 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 filesystem, the kernel may be unable + to reliably serve the network file through its 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 of 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 it 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 + MaxConnectionsPerChild + setting. By default this is 0, + which means that there is no limit to the number of connections + 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 5 + 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: + 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 event MPM is threaded like the + Worker MPM, but is designed to allow more requests to be + served simultaneously by passing off some processing work + to supporting threads, freeing up the main threads to work + on new requests.
    • + +
  • 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 absence.

+ +

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 Mutex directive can + be used to change the mutex implementation of the + mpm-accept mutex at run-time. Special considerations + for different mutex implementations are documented with that + directive.

+ +

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 that 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 the children + can just block in accept(2) until a connection + arrives, and no starvation results. In practice this hides + almost the same "spinning" behavior 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 behavior + 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 shut down each direction of the + communication independently. (Recall that a TCP connection is + bi-directional. Each half is independent of the other.)

+ +

When this feature was added to Apache, it caused a flurry of + problems on various versions of Unix because of 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 to accomplish 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 behavior 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' 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' 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  | + fr  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/misc/perf-tuning.html.fr.utf8 b/docs/manual/misc/perf-tuning.html.fr.utf8 new file mode 100644 index 0000000..27dbb27 --- /dev/null +++ b/docs/manual/misc/perf-tuning.html.fr.utf8 @@ -0,0 +1,1058 @@ + + + + + +Optimisation des performances d'Apache - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Optimisation des performances d'Apache

+
+

Langues Disponibles:  en  | + fr  | + ko  | + tr 

+
+ + +

Apache 2.x est un serveur web à usage général, conçu dans un but + d'équilibre entre souplesse, portabilité et performances. Bien que non + conçu dans le seul but d'établir une référence en la matière, + Apache 2.x est capable de hautes performances dans de nombreuses situations + du monde réel.

+ +

Comparée à Apache 1.3, la version 2.x comporte de nombreuses + optimisations supplémentaires permettant d'améliorer le débit du serveur + et sa personnalisation. La plupart de ces améliorations sont activées par + défaut. Cependant, certains choix de configuration à la compilation et à + l'exécution peuvent affecter les performances de manière significative. Ce + document décrit les options qu'un administrateur de serveur peut configurer + pour améliorer les performances d'une installation d'Apache 2.x. Certaines + de ces options de configuration permettent au démon httpd de mieux tirer + parti des possibilités du matériel et du système d'exploitation, tandis + que d'autres permettent à l'administrateur de privilégier la vitesse + par rapport aux fonctionnalités.

+ +
+ +
top
+
+

Problèmes matériels et relatifs au système d'exploitation

+ + + +

Le principal problème matériel qui affecte les performances du serveur + web est la mémoire vive (RAM). Un serveur web ne devrait jamais avoir à + utiliser le swap, car le swapping augmente le temps de réponse de chaque + requête au delà du point que les utilisateurs considèrent comme + "trop lent". Ceci incite les utilisateurs à cliquer sur "Stop", puis + "Charger à nouveau", ce qui a pour effet d'augmenter encore la charge + du serveur. Vous pouvez, et même devez définir la valeur de la directive + MaxRequestWorkers de façon à ce que + votre serveur ne lance pas un nombre de processus enfants tel qu'il + commence à faire du swapping. La méthode pour y parvenir est + simple : déterminez la taille de votre processus Apache standard en + consultant votre liste de processus à l'aide d'un outil tel que + top, et divisez votre quantité totale de mémoire disponible + par cette taille, tout en gardant un espace suffisant + pour les autres processus.

+ +

Hormis ce réglage relatif à la mémoire, le reste est trivial : le + processeur, la carte réseau et les disques doivent être suffisamment + rapides, où "suffisamment rapide" doit être déterminé par + l'expérience.

+ +

Le choix du système d'exploitation dépend principalement du + contexte local. Voici cependant quelques conseils qui se sont + généralement avérés utiles :

+ +
    +
  • +

    Exécutez la dernière version stable et le niveau de patches le + plus haut du système d'exploitation que vous avez choisi. De nombreux + éditeurs de systèmes d'exploitation ont amélioré de manière + significative les performances de leurs piles TCP et de leurs + bibliothèques de thread ces dernières années.

    +
    • + +
  • +

    Si votre système d'exploitation possède un appel système + sendfile(2), assurez-vous d'avoir installé la version + et/ou les patches nécessaires à son activation. (Pour Linux, par + exemple, cela se traduit par Linux 2.4 ou plus. Pour les versions + anciennes de Solaris 8, vous pouvez être amené à appliquer un patch.) + Sur les systèmes où il est disponible, sendfile permet + à Apache 2 de servir les contenus statiques plus rapidement, tout en + induisant une charge CPU inférieure.

    +
    • +
+ +
top
+
+

Optimisation de la configuration à l'exécution

+ + + +
Modules ApparentésDirectives Apparentées
+ +

HostnameLookups et autres considérations à propos du DNS

+ + + +

Avant Apache 1.3, la directive + HostnameLookups était positionnée + par défaut à On. Ce réglage augmente le temps de réponse de + chaque requête car il entraîne une recherche DNS et le traitement de la + requête ne pourra pas être achevé tant que cette recherche ne sera + pas terminée. Avec Apache 1.3, ce réglage est défini par défaut à + Off. Si vous souhaitez que les adresses dans vos fichiers + journaux soient résolues en noms d'hôtes, utilisez le programme + logresolve fourni avec Apache, ou un des nombreux + paquets générateurs de rapports sur les journaux disponibles.

+ +

Il est recommandé d'effectuer ce genre de traitement a posteriori + de vos fichiers journaux sur une autre machine que celle qui héberge le + serveur web en production, afin que cette activité n'affecte pas les + performances du serveur.

+ +

Si vous utilisez une directive + Allowfrom domain + ou + Deny from domain + (ce qui signifie que vous utilisez un nom d'hôte ou un nom de domaine à + la place d'une adresse IP), vous devrez compter avec deux recherches + DNS (une recherche inverse suivie d'une recherche directe pour + s'assurer que l'adresse IP n'a pas été usurpée). C'est pourquoi il est + préférable, pour améliorer les performances, d'utiliser des adresses IP + plutôt que des noms lorsqu'on utilise ces directives, du moins chaque + fois que c'est possible.

+ +

Notez qu'il est possible de modifier la portée des directives, en les + plaçant par exemple à l'intérieur d'une section + <Location "/server-status">. Les recherches DNS ne + seront alors effectuées que pour les requêtes qui satisfont aux critères. + Voici un exemple qui désactive les recherches DNS sauf pour les fichiers + .html et .cgi :

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

Mais même dans ce cas, si vous n'avez besoin de noms DNS que dans + certains CGIs, vous pouvez effectuer l'appel à gethostbyname + dans les CGIs spécifiques qui en ont besoin.

+ + + +

FollowSymLinks et SymLinksIfOwnerMatch

+ + + +

Chaque fois que la ligne Options FollowSymLinks sera + absente, ou que la ligne Options SymLinksIfOwnerMatch sera + présente dans votre espace d'adressage, Apache devra effectuer des + appels système supplémentaires pour vérifier la présence de liens + symboliques. Un appel supplémentaire par élément du chemin du fichier. + Par exemple, si vous avez :

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

et si une requête demande l'URI /index.html, Apache + effectuera un appel à lstat(2) pour + /www, /www/htdocs, et + /www/htdocs/index.html. Les résultats de ces appels à + lstat ne sont jamais mis en cache, ils devront donc être + générés à nouveau pour chaque nouvelle requête. Si vous voulez absolument + vérifier la sécurité des liens symboliques, vous pouvez utiliser une + configuration du style :

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

Ceci évite au moins les vérifications supplémentaires pour le chemin + défini par DocumentRoot. Notez que + vous devrez ajouter des sections similaires si vous avez des chemins + définis par les directives + Alias ou + RewriteRule en dehors de + la racine de vos documents. Pour améliorer les performances, et supprimer + toute protection des liens symboliques, ajoutez l'option + FollowSymLinks partout, et n'utilisez jamais l'option + SymLinksIfOwnerMatch.

+ + + +

AllowOverride

+ + + +

Dans toute partie de votre espace d'adressage où vous autoriserez + la surcharge de la configuration (en général à l'aide de fichiers + .htaccess), Apache va tenter d'ouvrir .htaccess + pour chaque élément du chemin du fichier demandé. Par exemple, si vous + avez :

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

et qu'une requête demande l'URI /index.html, Apache + tentera d'ouvrir /.htaccess, /www/.htaccess, + et /www/htdocs/.htaccess. Les solutions sont similaires à + celles évoquées précédemment pour Options FollowSymLinks. + Pour améliorer les performances, utilisez AllowOverride None + pour tous les niveaux de votre espace d'adressage.

+ + + +

Négociation

+ + + +

Dans la mesure du possible, évitez toute négociation de contenu si + vous tenez au moindre gain en performances. En pratique toutefois, + les bénéfices de la négociation l'emportent souvent sur la diminution + des performances. + Il y a cependant un cas dans lequel vous pouvez accélérer le serveur. + Au lieu d'utiliser une directive générique comme :

+ + 
DirectoryIndex index
+ + +

utilisez une liste explicite d'options :

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

où vous placez le choix courant en première position.

+ +

Notez aussi que créer explicitement un fichier de + correspondances de type fournit de meilleures performances + que l'utilisation des MultiViews, car les informations + nécessaires peuvent être simplement obtenues en lisant ce fichier, sans + avoir à parcourir le répertoire à la recherche de types de fichiers.

+ +

Par conséquent, si la négociation de contenu est nécessaire pour votre + site, préférez les fichiers de correspondances de type aux + directives Options MultiViews pour mener à bien cette + négociation. Se référer au document sur la + Négociation de contenu pour une + description complète des méthodes de négociation, et les instructions + permettant de créer des fichiers de correspondances de type.

+ + + +

Transfert en mémoire

+ + + +

Dans les situations où Apache 2.x doit consulter le contenu d'un + fichier en train d'être servi - par exemple à l'occasion du traitement + d'une inclusion côté serveur - il transfère en général le fichier en + mémoire si le système d'exploitation supporte une forme quelconque + de mmap(2).

+ +

Sur certains systèmes, ce transfert en mémoire améliore les + performances. Dans certains cas, ce transfert peut toutefois les dégrader + et même diminuer la stabilité du démon httpd :

+ +
    +
  • +

    Dans certains systèmes d'exploitation, mmap devient + moins efficace que read(2) quand le nombre de + processeurs augmente. Sur les serveurs multiprocesseurs sous Solaris, + par exemple, Apache 2.x sert parfois les fichiers consultés par le + serveur plus rapidement quand mmap est désactivé.

    +
    • + +
  • +

    Si vous transférez en mémoire un fichier localisé dans un système + de fichiers monté par NFS, et si un processus sur + une autre machine cliente NFS supprime ou tronque le fichier, votre + processus peut rencontrer une erreur de bus la prochaine fois qu'il + essaiera d'accéder au contenu du fichier en mémoire.

    +
    • +
+ +

Pour les installations où une de ces situations peut se produire, + vous devez utiliser EnableMMAP off afin de désactiver le + transfert en mémoire des fichiers servis. (Note : il est possible de + passer outre cette directive au niveau de chaque répertoire.)

+ + + +

Sendfile

+ + + +

Dans les cas où Apache peut se permettre d'ignorer le contenu du + fichier à servir - par exemple, lorsqu'il sert un contenu de fichier + statique - il utilise en général le support sendfile du noyau si le + système d'exploitation supporte l'opération sendfile(2).

+ +

Sur la plupart des plateformes, l'utilisation de sendfile améliore + les performances en éliminant les mécanismes de lecture et envoi séparés. + Dans certains cas cependant, l'utilisation de sendfile peut nuire à la + stabilité du démon httpd :

+ +
    +
  • +

    Certaines plateformes peuvent présenter un support de sendfile + défaillant que la construction du système n'a pas détecté, en + particulier si les binaires ont été construits sur une autre machine + et transférés sur la machine où le support de sendfile est + défaillant.

    +
    • +
  • +

    Dans le cas d'un système de fichiers monté + sous NFS, le noyau peut s'avérer incapable de servir + les fichiers réseau de manière fiable depuis + son propre cache.

    +
    • +
+ +

Pour les installations où une de ces situations peut se produire, + vous devez utiliser EnableSendfile off afin de désactiver + la mise à disposition de contenus de fichiers par sendfile. (Note : il + est possible de passer outre cette directive au niveau de chaque + répertoire.)

+ + + +

Process Creation

+ + + +

Avant Apache 1.3, les directives + MinSpareServers, + MaxSpareServers, et + StartServers avaient des + effets drastiques sur les performances de référence. En particulier, + Apache avait besoin d'un délai de "montée en puissance" afin d'atteindre + un nombre de processus enfants suffisant pour supporter la charge qui lui + était appliquée. Après le lancement initial des processus enfants par + StartServers, seulement un + processus enfant par seconde était créé afin d'atteindre la valeur de la + directive MinSpareServers. Ainsi, + un serveur accédé par 100 clients simultanés et utilisant la valeur par + défaut de 5 pour la directive + StartServers, nécessitait + environ 95 secondes pour lancer suffisamment de processus enfants + permettant de faire face à la charge. Ceci fonctionne en pratique pour + les serveurs en production, car ils sont rarement redémarrés. Ce n'est + cependant pas le cas pour les tests de référence (benchmarks) où le + serveur ne fonctionne que 10 minutes.

+ +

La règle "un processus par seconde" avait été implémentée afin + d'éviter l'enlisement de la machine dans le démarrage de nouveaux + processus enfants. Pendant que la machine est occupée à lancer des + processus enfants, elle ne peut pas traiter les requêtes. Mais cette + règle impactait tellement la perception des performances d'Apache qu'elle + a dû être remplacée. A partir d'Apache 1.3, le code a assoupli la règle + "un processus par seconde". Il va en lancer un, attendre une seconde, + puis en lancer deux, attendre une seconde, puis en lancer quatre et + ainsi de suite jusqu'à lancer 32 processus. Il s'arrêtera lorsque le + nombre de processus aura atteint la valeur définie par la directive + MinSpareServers.

+ +

Ceci s'avère suffisamment réactif pour pouvoir en général se passer + de manipuler les valeurs des directives + MinSpareServers, + MaxSpareServers et + StartServers. Lorsque plus de + 4 processus enfants sont lancés par seconde, un message est émis vers + le journal des erreurs. Si vous voyez apparaître souvent ce genre de + message, vous devez vous pencher sur ces réglages. Pour vous guider, + utilisez les informations délivrées par le module + mod_status.

+ +

À mettre en relation avec la création de processus, leur destruction + est définie par la valeur de la directive + MaxConnectionsPerChild. Sa valeur + par défaut est 0, ce qui signifie qu'il n'y a pas de limite + au nombre de connexions qu'un processus enfant peut traiter. Si votre + configuration actuelle a cette directive réglée à une valeur très basse, + de l'ordre de 30, il est conseillé de l'augmenter de manière + significative. Si vous utilisez SunOs ou une ancienne version de Solaris, + utilisez une valeur de l'ordre de 10000 à cause des fuites + de mémoire.

+ +

Lorsqu'ils sont en mode "keep-alive", les processus enfants sont + maintenus et ne font rien sinon attendre la prochaine requête sur la + connexion déjà ouverte. La valeur par défaut de 5 de la + directive KeepAliveTimeout tend à + minimiser cet effet. Il faut trouver le bon compromis entre la bande + passante réseau et les ressources du serveur. En aucun cas vous ne devez + choisir une valeur supérieure à 60 seconds, car + + la plupart des bénéfices sont alors perdus.

+ + + +
top
+
+

Optimisation de la configuration à la compilation

+ + + +

Choisir un Module Multi-Processus (MPM)

+ + + +

Apache 2.x supporte les modèles simultanés enfichables, appelés + Modules Multi-Processus (MPMs). Vous devez + choisir un MPM au moment de la construction d'Apache. Certaines + plateformes ont des modules MPM spécifiques : + mpm_netware, mpmt_os2 et + mpm_winnt. Sur les systèmes de type Unix, vous avez le + choix entre un grand nombre de modules MPM. Le choix du MPM peut affecter + la vitesse et l'évolutivité du démon httpd :

+ +
    + +
  • Le MPM worker utilise plusieurs processus + enfants possédant chacun de nombreux threads. Chaque thread gère une + seule connexion à la fois. Worker est en général un bon choix pour les + serveurs présentant un traffic important car il possède une empreinte + mémoire plus petite que le MPM prefork.
    • + +
  • Comme le MPM Worker, le MPM event utilise + les threads, mais il a été conçu pour traiter davantage de + requêtes simultanément en confiant une partie du travail à des + threads de support, ce qui permet aux threads principaux de + traiter de nouvelles requêtes.
    • + +
  • Le MPM prefork utilise plusieurs processus enfants + possédant chacun un seul thread. Chaque processus gère une seule + connexion à la fois. Sur de nombreux systèmes, prefork est comparable + en matière de vitesse à worker, mais il utilise plus de mémoire. De par + sa conception sans thread, prefork présente des avantages par rapport à + worker dans certaines situations : il peut être utilisé avec les + modules tiers qui ne supportent pas le threading, et son débogage est plus + aisé sur les platesformes présentant un support du débogage des threads + rudimentaire.
    • + +
+ +

Pour plus d'informations sur ces deux MPMs et les autres, veuillez + vous référer à la documentation sur les + MPM.

+ + + +

Modules

+ + + +

Comme le contrôle de l'utilisation de la mémoire est très important + en matière de performance, il est conseillé d'éliminer les modules que + vous n'utilisez pas vraiment. Si vous avez construit ces modules en + tant que DSOs, leur élimination consiste + simplement à commenter la directive + LoadModule associée à ce + module. Ceci vous permet de vérifier si votre site fonctionne toujours + après la suppression de tel ou tel module.

+ +

Par contre, si les modules que vous voulez supprimer sont liés + statiquement à votre binaire Apache, vous devrez recompiler ce dernier + afin de pouvoir les éliminer.

+ +

La question qui découle de ce qui précède est évidemment de + savoir de quels modules vous avez besoin et desquels vous pouvez vous + passer. La réponse sera bien entendu différente d'un site web à + l'autre. Cependant, la liste minimale de modules nécessaire à + la survie de votre site contiendra certainement + mod_mime, mod_dir et + mod_log_config. mod_log_config est bien + entendu optionnel puisque vous pouvez faire fonctionner un site web + en se passant de fichiers journaux ; ceci est cependant + déconseillé.

+ + + +

Opérations atomiques

+ + + +

Certains modules, à l'instar de mod_cache et des + versions de développement récentes du MPM worker, utilisent l'API + atomique d'APR. Cette API propose des opérations atomiques que l'on + peut utiliser pour alléger la synchronisation des threads.

+ +

Par défaut, APR implémente ces opérations en utilisant les + mécanismes les plus efficaces disponibles sur chaque plateforme cible + (Système d'exploitation et processeur). De nombreux processeurs modernes, + par exemple, possèdent une instruction qui effectue une opération + atomique de type comparaison et échange ou compare-and-swap (CAS) au + niveau matériel. Sur certaines platesformes cependant, APR utilise par + défaut une implémentation de l'API atomique plus lente, basée sur les + mutex, afin d'assurer la compatibilité avec les anciens modèles de + processeurs qui ne possèdent pas ce genre d'instruction. Si vous + construisez Apache pour une de ces platesformes, et ne prévoyez de + l'exécuter que sur des processeurs récents, vous pouvez sélectionner une + implémentation atomique plus rapide à la compilation en utilisant + l'option --enable-nonportable-atomics du + script configure :

+ +

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

+ +

L'option --enable-nonportable-atomics concerne les + platesformes suivantes :

+ +
    + +
  • Solaris sur SPARC
    + Sur Solaris/SPARC, APR utilise par défaut les opérations + atomiques basées sur les mutex. Cependant, si vous ajoutez l'option + --enable-nonportable-atomics au script configure, APR + génère un code qui utilise le code opération SPARC v8plus pour des + opérations de compare-and-swap matériel plus rapides. Si vous + utilisez cette option de configure avec Apache, les opérations + atomiques seront plus efficaces (permettant d'alléger la charge du + processeur et un plus haut niveau de simultanéité), mais + l'exécutable produit ne fonctionnera que sur les processeurs + UltraSPARC. +
    • + +
  • Linux sur x86
    + Sous Linux, APR utilise par défaut les opérations atomiques basées + sur les mutex. Cependant, si vous ajoutez l'option + --enable-nonportable-atomics au script configure, + APR générera un code qui utilise un code d'opération du 486 + pour des opérations de compare-and-swap matériel plus rapides. Le + code résultant est plus efficace en matière d'opérations atomiques, + mais l'exécutable produit ne fonctionnera que sur des processeurs + 486 et supérieurs (et non sur des 386). +
    • + +
+ + + +

Module mod_status et ExtendedStatus On

+ + + +

Si vous incluez le module mod_status à la + construction d'Apache et ajoutez ExtendedStatus On à sa + configuration, Apache va effectuer pour chaque requête deux appels à + gettimeofday(2) (ou times(2) selon votre + système d'exploitation), et (pour les versions antérieures à 1.3) de + nombreux appels supplémentaires à time(2). Tous ces + appels sont effectués afin que le rapport de statut puisse contenir + des indications temporelles. Pour améliorer les performances, utilisez + ExtendedStatus off (qui est le réglage par défaut).

+ + + +

accept Serialization - points de connexion à un programme (sockets) multiples

+ + + +

Mise en garde :

+

Cette section n'a pas été totalement mise à jour car elle ne tient pas + compte des changements intervenus dans la version 2.x du Serveur HTTP + Apache. Certaines informations sont encore pertinentes, il vous est + cependant conseillé de les utiliser avec prudence.

+
+ +

Ce qui suit est une brève discussion à propos de l'API des sockets + Unix. Supposons que votre serveur web utilise plusieurs directives + Listen afin d'écouter + plusieurs ports ou de multiples adresses. Afin de tester chaque socket + pour voir s'il a une connexion en attente, Apache utilise + select(2). select(2) indique si un socket a + zéro ou au moins une connexion en attente. Le modèle + d'Apache comporte plusieurs processus enfants, et tous ceux qui sont + inactifs testent la présence de nouvelles connexions au même moment. + Une implémentation rudimentaire de ceci pourrait ressembler à + l'exemple suivant + (ces exemples ne sont pas extraits du code d'Apache, ils ne sont + proposés qu'à des fins pédagogiques) :

+ + 
        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);
+        }
+ + +

Mais cette implémentation rudimentaire présente une sérieuse lacune. + Rappelez-vous que les processus enfants exécutent cette boucle au même + moment ; ils vont ainsi bloquer sur select s'ils se trouvent + entre deux requêtes. Tous ces processus bloqués vont se réactiver et + sortir de select quand une requête va apparaître sur un des + sockets (le nombre de processus enfants qui se réactivent varie en + fonction du système d'exploitation et des réglages de synchronisation). + Ils vont alors tous entrer dans la boucle et tenter un + "accept" de la connexion. Mais seulement un d'entre eux y + parviendra (en supposant qu'il ne reste q'une seule connexion en + attente), les autres vont se bloquer au niveau de accept. + Ceci verrouille vraiment ces processus de telle sorte qu'ils ne peuvent + plus servir de requêtes que par cet unique socket, et il en sera ainsi + jusqu'à ce que suffisamment de nouvelles requêtes apparaissent sur ce + socket pour les réactiver tous. Cette lacune a été documentée pour la + première fois dans + PR#467. Il existe + au moins deux solutions.

+ +

La première consiste à rendre les sockets non blocants. Dans ce cas, + accept ne bloquera pas les processus enfants, et ils + pourront continuer à s'exécuter immédiatement. Mais ceci consomme des + ressources processeur. Supposons que vous ayez dix processus enfants + inactifs dans select, et qu'une connexion arrive. + Neuf des dix processus vont se réactiver, tenter un accept + de la connexion, échouer, et boucler dans select, tout en + n'ayant finalement rien accompli. Pendant ce temps, aucun de ces processus + ne traite les requêtes qui arrivent sur d'autres sockets jusqu'à ce + qu'ils retournent dans select. Finalement, cette solution + ne semble pas très efficace, à moins que vous ne disposiez d'autant de + processeurs inactifs (dans un serveur multiprocesseur) que de processus + enfants inactifs, ce qui n'est pas une situation très courante.

+ +

Une autre solution, celle qu'utilise Apache, consiste à sérialiser les + entrées dans la boucle interne. La boucle ressemble à ceci (les + différences sont mises en surbrillance) :

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

Les fonctions + accept_mutex_on et accept_mutex_off + implémentent un sémaphore permettant une exclusion mutuelle. Un seul + processus enfant à la fois peut posséder le mutex. Plusieurs choix se + présentent pour implémenter ces mutex. Ce choix est défini dans + src/conf.h (versions antérieures à 1.3) ou + src/include/ap_config.h (versions 1.3 ou supérieures). + Certaines architectures ne font pas ce choix du mode de verrouillage ; + l'utilisation de directives + Listen multiples sur ces + architectures est donc peu sûr.

+ +

La directive Mutex permet + de modifier l'implémentation du mutex mpm-accept à + l'exécution. Des considérations spécifiques aux différentes + implémentations de mutex sont documentées avec cette directive.

+ +

Une autre solution qui a été imaginée mais jamais implémentée, consiste + à sérialiser partiellement la boucle -- c'est à dire y faire entrer un + certain nombre de processus. Ceci ne présenterait un intérêt que sur les + machines multiprocesseurs où plusieurs processus enfants peuvent + s'exécuter simultanément, et encore, la sérialisation ne tire pas + vraiment parti de toute la bande passante. C'est une possibilité + d'investigation future, mais demeure de priorité basse car les serveurs + web à architecture hautement parallèle ne sont pas la norme.

+ +

Pour bien faire, vous devriez faire fonctionner votre serveur sans + directives Listen multiples + si vous visez les performances les plus élevées. + Mais lisez ce qui suit.

+ + + +

accept Serialization - point de connexion à un programme (sockets) unique

+ + + +

Ce qui précède convient pour les serveurs à sockets multiples, mais + qu'en est-il des serveurs à socket unique ? En théorie, ils ne + devraient pas rencontrer les mêmes problèmes car tous les processus + enfants peuvent se bloquer dans accept(2) jusqu'à ce qu'une + connexion arrive, et ils ne sont pas utilisés à ne rien faire. En + pratique, ceci dissimule un même comportement de bouclage + discuté plus haut dans la solution non-blocante. De la manière dont + sont implémentées les piles TCP, le noyau réactive véritablement tous les + processus bloqués dans accept quand une seule connexion + arrive. Un de ces processus prend la connexion en compte et retourne + dans l'espace utilisateur, les autres bouclant dans l'espace du + noyau et se désactivant quand ils s'aperçoivent qu'il n'y a pas de + connexion pour eux. Ce bouclage est invisible depuis le code de l'espace + utilisateur, mais il est quand-même présent. Ceci peut conduire à la + même augmentation de charge à perte que la solution non blocante au cas + des sockets multiples peut induire.

+ +

Pour cette raison, il apparaît que de nombreuses architectures se + comportent plus "proprement" si on sérialise même dans le cas d'une socket + unique. Il s'agit en fait du comportement par défaut dans la plupart des + cas. Des expériences poussées sous Linux (noyau 2.0.30 sur un + biprocesseur Pentium pro 166 avec 128 Mo de RAM) ont montré que la + sérialisation d'une socket unique provoque une diminution inférieure à 3% + du nombre de requêtes par secondes par rapport au traitement non + sérialisé. Mais le traitement non sérialisé des sockets uniques induit + un temps de réponse supplémentaire de 100 ms pour chaque requête. Ce + temps de réponse est probablement provoqué par une limitation sur les + lignes à haute charge, et ne constitue un problème que sur les réseaux + locaux. Si vous voulez vous passer de la sérialisation des sockets + uniques, vous pouvez définir + SINGLE_LISTEN_UNSERIALIZED_ACCEPT et les + serveurs à socket unique ne pratiqueront plus du tout la + sérialisation.

+ + + +

Fermeture en prenant son temps (Lingering close)

+ + + +

Comme discuté dans + draft-ietf-http-connection-00.txt section 8, pour implémenter de + manière fiable le protocole, un serveur HTTP doit fermer + les deux directions d'une communication indépendamment (rappelez-vous + qu'une connexion TCP est bidirectionnelle, chaque direction étant + indépendante de l'autre).

+ +

Quand cette fonctionnalité fut ajoutée à Apache, elle causa une + avalanche de problèmes sur plusieurs versions d'Unix à cause d'une + implémentation à courte vue. La spécification TCP ne précise pas que + l'état FIN_WAIT_2 possède un temps de réponse mais elle ne + l'exclut pas. Sur les systèmes qui n'introduisent pas ce temps de + réponse, Apache 1.2 induit de nombreux blocages définitifs de socket + dans l'état FIN_WAIT_2. On peut eviter ceci dans de nombreux + cas tout simplement en mettant à jour TCP/IP avec le dernier patch mis à + disposition par le fournisseur. Dans les cas où le fournisseur n'a + jamais fourni de patch (par exemple, SunOS4 -- bien que les utilisateurs + possédant une license source puissent le patcher eux-mêmes), nous avons + décidé de désactiver cette fonctionnalité.

+ +

Il y a deux méthodes pour arriver à ce résultat. La première est + l'option de socket SO_LINGER. Mais le sort a voulu que cette + solution ne soit jamais implémentée correctement dans la plupart des + piles TCP/IP. Et même dans les rares cas où cette solution a été + implémentée correctement (par exemple Linux 2.0.31), elle se + montre beaucoup plus gourmande (en temps processeur) que la solution + suivante.

+ +

Pour la plus grande partie, Apache implémente cette solution à l'aide + d'une fonction appelée lingering_close (définie dans + http_main.c). La fonction ressemble approximativement à + ceci :

+ + 
        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);
+        }
+ + +

Ceci ajoute naturellement un peu de charge à la fin d'une connexion, + mais s'avère nécessaire pour une implémentation fiable. Comme HTTP/1.1 + est de plus en plus présent et que toutes les connexions sont + persistentes, la charge sera amortie par la multiplicité des requêtes. + Si vous voulez jouer avec le feu en désactivant cette fonctionnalité, + vous pouvez définir NO_LINGCLOSE, mais c'est fortement + déconseillé. En particulier, comme les connexions persistantes en + pipeline de HTTP/1.1 commencent à être utilisées, + lingering_close devient une absolue nécessité (et les + + connexions en pipeline sont plus rapides ; vous avez donc tout + intérêt à les supporter).

+ + + +

Fichier tableau de bord (Scoreboard file)

+ + + +

Les processus parent et enfants d'Apache communiquent entre eux à + l'aide d'un objet appelé "Tableau de bord" (Scoreboard). Idéalement, cet + échange devrait s'effectuer en mémoire partagée. Pour les systèmes + d'exploitation auxquels nous avons eu accès, ou pour lesquels nous avons + obtenu des informations suffisamment détaillées pour effectuer un + portage, cet échange est en général implémenté en utilisant la mémoire + partagée. Pour les autres, on utilise par défaut un fichier d'échange sur + disque. Le fichier d'échange sur disque est non seulement lent, mais + aussi peu fiable (et propose moins de fonctionnalités). Recherchez dans + le fichier src/main/conf.h correspondant à votre + architecture soit USE_MMAP_SCOREBOARD, soit + USE_SHMGET_SCOREBOARD. La définition de l'un des deux + (ainsi que leurs compagnons respectifs HAVE_MMAP et + HAVE_SHMGET), active le code fourni pour la mémoire + partagée. Si votre système propose une autre solution pour la gestion de + la mémoire partagée, éditez le fichier src/main/http_main.c + et ajoutez la portion de code nécessaire pour pouvoir l'utiliser dans + Apache (Merci de nous envoyer aussi le patch correspondant).

+ +
Note à caractère historique : le portage d'Apache sous Linux + n'utilisait pas la mémoire partagée avant la version 1.2. Ceci entraînait + un comportement très rudimentaire et peu fiable des versions antérieures + d'Apache sous Linux.
+ + + +

DYNAMIC_MODULE_LIMIT

+ + + +

Si vous n'avez pas l'intention d'utiliser les modules chargés + dynamiquement (ce qui est probablement le cas si vous êtes en train de + lire ce document afin de personnaliser votre serveur en recherchant le + moindre des gains en performances), vous pouvez ajouter la définition + -DDYNAMIC_MODULE_LIMIT=0 à la construction de votre serveur. + Ceci aura pour effet de libérer la mémoire RAM allouée pour le + chargement dynamique des modules.

+ + + +
top
+
+

Appendice : Analyse détaillée d'une trace

+ + + +

Voici la trace d'un appel système d'Apache 2.0.38 avec le MPM worker + sous Solaris 8. Cette trace a été collectée à l'aide de la commande :

+ +

+ truss -l -p httpd_child_pid. +

+ +

L'option -l demande à truss de tracer l'ID du LWP + (lightweight process--la version de Solaris des threads niveau noyau) qui + invoque chaque appel système.

+ +

Les autres systèmes peuvent proposer des utilitaires de traçage + des appels système différents comme strace, + ktrace, ou par. Ils produisent cependant tous une + trace similaire.

+ +

Dans cette trace, un client a demandé un fichier statique de 10 ko au + démon httpd. Le traçage des requêtes pour des contenus non statiques + ou comportant une négociation de contenu a une présentation + différente (et même assez laide dans certains cas).

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

Dans cette trace, le thread à l'écoute s'exécute à l'intérieur de + LWP #67.

+ +
Notez l'absence de la sérialisation d'accept(2). Sur + cette plateforme spécifique, le MPM worker utilise un accept non sérialisé + par défaut sauf s'il est en écoute sur des ports multiples.
+ + 
/65:    lwp_park(0x00000000, 0)                         = 0
+/67:    lwp_unpark(65, 1)                               = 0
+ +

Après avoir accepté la connexion, le thread à l'écoute réactive un + thread du worker pour effectuer le traitement de la requête. Dans cette + trace, le thread du worker qui traite la requête est associé à + LWP #65.

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

Afin de pouvoir implémenter les hôtes virtuels, Apache doit connaître + l'adresse du socket local utilisé pour accepter la connexion. On pourrait + supprimer cet appel dans de nombreuses situations (par exemple dans le cas + où il n'y a pas d'hôte virtuel ou dans le cas où les directives + Listen contiennent des adresses + sans caractères de substitution). Mais aucun effort n'a été accompli à ce + jour pour effectuer ces optimisations.

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

L'appel brk(2) alloue de la mémoire dans le tas. Ceci est + rarement visible dans une trace d'appel système, car le démon httpd + utilise des allocateurs mémoire de son cru (apr_pool et + apr_bucket_alloc) pour la plupart des traitements de requêtes. + Dans cette trace, le démon httpd vient juste de démarrer, et il doit + appeler malloc(3) pour réserver les blocs de mémoire + nécessaires à la création de ses propres allocateurs de mémoire.

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

Ensuite, le thread de worker passe la connexion du client (descripteur + de fichier 9) en mode non blocant. Les appels setsockopt(2) + et getsockopt(2) constituent un effet de bord de la manière + dont la libc de Solaris utilise fcntl(2) pour les sockets.

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

Le thread de worker lit la requête du 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
+ +

Ce démon httpd a été configuré avec les options + Options FollowSymLinks et AllowOverride None. Il + n'a donc ni besoin d'appeler lstat(2) pour chaque répertoire + du chemin du fichier demandé, ni besoin de vérifier la présence de fichiers + .htaccess. Il appelle simplement stat(2) pour + vérifier d'une part que le fichier existe, et d'autre part que c'est un + fichier régulier, et non un répertoire.

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

Dans cet exemple, le démon httpd peut envoyer l'en-tête de la réponse + HTTP et le fichier demandé à l'aide d'un seul appel système + sendfilev(2). La sémantique de sendfile varie en fonction des + systèmes d'exploitation. Sur certains autres systèmes, il faut faire un + appel à write(2) ou writev(2) pour envoyer les + en-têtes avant d'appeler sendfile(2).

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

Cet appel à write(2) enregistre la requête dans le journal + des accès. Notez qu'une des choses manquant à cette trace est un appel à + time(2). A la différence d'Apache 1.3, Apache 2.x utilise + gettimeofday(3) pour consulter l'heure. Sur certains systèmes + d'exploitation, comme Linux ou Solaris, gettimeofday est + implémenté de manière optimisée de telle sorte qu'il consomme moins de + ressources qu'un appel système habituel.

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

Le thread de worker effectue une fermeture "en prenant son temps" + (lingering close) de la connexion.

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

Enfin, le thread de worker ferme le fichier qu'il vient de délivrer et + se bloque jusqu'à ce que le thread en écoute lui assigne une autre + connexion.

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

Pendant ce temps, le thread à l'écoute peut accepter une autre connexion + à partir du moment où il a assigné la connexion présente à un thread de + worker (selon une certaine logique de contrôle de flux dans le MPM worker + qui impose des limites au thread à l'écoute si tous les threads de worker + sont occupés). Bien que cela n'apparaisse pas dans cette trace, + l'accept(2) suivant peut (et le fait en général, en situation + de charge élevée) s'exécuter en parallèle avec le traitement de la + connexion qui vient d'être acceptée par le thread de worker.

+ +
+
+

Langues Disponibles:  en  | + fr  | + ko  | + tr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/misc/perf-tuning.html.ko.euc-kr b/docs/manual/misc/perf-tuning.html.ko.euc-kr new file mode 100644 index 0000000..bf88b86 --- /dev/null +++ b/docs/manual/misc/perf-tuning.html.ko.euc-kr @@ -0,0 +1,1006 @@ + + + + + +ġ - Apache HTTP Server Version 2.4 + + + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.4

+
+
<-
+

ġ

+
+

:  en  | + fr  | + 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 ߸ ǻͷ + 쿡 ϴ.

    +
    • +
  • +

    Ŀ ڽ ij Ͽ 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  | + fr  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/misc/perf-tuning.html.tr.utf8 b/docs/manual/misc/perf-tuning.html.tr.utf8 new file mode 100644 index 0000000..ba8dd90 --- /dev/null +++ b/docs/manual/misc/perf-tuning.html.tr.utf8 @@ -0,0 +1,1021 @@ + + + + + +Apache’de Başarımın Arttırılması - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + +
+

Modüller | Yönergeler | SSS | Terimler | Site Haritası

+

Apache HTTP Sunucusu Sürüm 2.4

+
+
<-
+

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

+
+

Mevcut Diller:  en  | + fr  | + 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. MaxRequestWorkers 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

+ + + +
İlgili Modüllerİlgili Yönergeler
+ +

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.

+ + 
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 "/siteler/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.

+ + 
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ü MaxConnectionsPerChild 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 5 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: + 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.
    • + +
  • event modülü worker modülü gibi + çok evreli bir modüldür, fakat aunı anda dahafazla isteğe yanıt + verecek şekilde tasarlanmıştır. Bunu, evreleri destekleyen bazı + işlemleri yapmamak suretiyle yeni isteklerle çalışacak ana evreleri + serbestleştirerek sağlar.
    • + +
  • 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.

+ +

Mutex yönergesi, + mpm-accept muteks gerçeklenimini çalışma anında değiştirmek + için kullanılabilir. Farklı muteks gerçeklenimleri ile ilgili hususlar + bu yönergede belgelenmiştir.

+ +

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 ö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];
+
+          /* 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);
+        }
+ + +

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  | + fr  | + ko  | + tr 

+
top

Yorumlar

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/misc/relevant_standards.html b/docs/manual/misc/relevant_standards.html new file mode 100644 index 0000000..3b23231 --- /dev/null +++ b/docs/manual/misc/relevant_standards.html @@ -0,0 +1,13 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: relevant_standards.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: relevant_standards.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: relevant_standards.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR diff --git a/docs/manual/misc/relevant_standards.html.en b/docs/manual/misc/relevant_standards.html.en new file mode 100644 index 0000000..58f6f18 --- /dev/null +++ b/docs/manual/misc/relevant_standards.html.en @@ -0,0 +1,234 @@ + + + + + +Relevant Standards - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Relevant Standards

+
+

Available Languages:  en  | + fr  | + 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.
+ +
RFC 4346 + (Standards Track)
+ +
The TLS protocol provides communications security over the + Internet. It provides encryption, and is designed to prevent + eavesdropping, tampering, and message forgery.
+
+ +
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 + (Standards Track)
+ +
"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  | + fr  | + ko 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/misc/relevant_standards.html.fr.utf8 b/docs/manual/misc/relevant_standards.html.fr.utf8 new file mode 100644 index 0000000..12b8663 --- /dev/null +++ b/docs/manual/misc/relevant_standards.html.fr.utf8 @@ -0,0 +1,253 @@ + + + + + +Standards applicables - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Standards applicables

+
+

Langues Disponibles:  en  | + fr  | + ko 

+
+ +

Cette page documente tous les standards applicables que suit le + serveur HTTP Apache, accompagnés d'une brève description.

+ +

Pour compléter les informations fournies ci-dessous, vous pouvez + consulter les ressources suivantes :

+ + + +

Avertissement

+

Ce document n'est pas encore finalisé.

+
+ +
+ +
top
+
+

Recommandations HTTP

+ +

Indépendamment des modules compilés et utilisés, Apache en + tant que serveur web de base respecte les recommandations IETF + suivantes :

+ +
+
RFC 1945 + (Informations)
+ +
Le Protocole de Transfert Hypertexte (Hypertext Transfer + Protocol - HTTP) est un protocole de niveau application avec la + clarté et la vitesse nécessaires pour les systèmes d'informations + distribués, collaboratifs et hypermédia. Cette RFC documente le + protocole HTTP/1.0.
+ +
RFC 2616 + (Série de standards)
+ +
Le Protocole de Transfert Hypertexte (Hypertext Transfer + Protocol - HTTP) est un protocole de niveau application pour les + systèmes d'informations distribués, collaboratifs et hypermédia. + Cette RFC documente le protocole HTTP/1.1.
+ +
RFC 2396 + (Série de standards)
+ +
Un Identificateur de Ressource Uniforme (Uniform Resource + Identifier - URI) est une chaîne de caractères compacte permettant + d'identifier une ressource physique ou abstraite.
+ +
RFC 4346 + (Série de standards)
+ +
Le protocole TLS permet l'utilisation de communications + sécurisées sur l'Internet. Il fournit le chiffrement, et a été + conçu pour se prémunir contre l'interception, la modification et + la falsification de messages.
+
+ +
top
+
+

Recommandations HTML

+ +

En ce qui concerne le langage HTML, Apache respecte les + recommandations IETF et W3C suivantes :

+ +
+
RFC 2854 + (Informations)
+ +
Ce document résume l'historique du développement de HTML, et + définit le type MIME "text/html" en pointant les recommandations + W3C correspondantes.
+ +
Spécification HTML + 4.01 + (Corrections + d'erreurs) +
+ +
Cette spécification définit le Langage à Balises HyperTexte + (HyperText Markup Language - HTML), le langage de publication du + World Wide Web. Elle définit HTML 4.01, qui est une sous-version + de HTML 4.
+ +
Référence HTML + 3.2
+ +
Le langage à Balises HyperTexte (HyperText Markup Language - + HTML) est un langage à balises simple permettant de créer des + documents hypertextes portables. Les documents HTML sont aussi des + documents SGML.
+ +
XHTML 1.1 - + XHTML sous forme de modules + (Corrections + d'erreurs) +
+ +
Cette recommandation définit un nouveau type de document XHTML + basé sur le cadre de développement des modules et les modules + définis dans la modularisation de XHTML.
+ +
XHTML 1.0, le Langage à + Balises Hypertexte Extensible (Extensible HyperText Markup + Language) - Seconde édition + (Corrections + d'erreurs) +
+ +
Cette spécification définit la seconde édition de XHTML 1.0, + une reformulation de HTML 4 en tant qu'application XML 1.0, ainsi + que trois DTDs correspondant à celles définies par HTML 4.
+
+ +
top
+
+

Authentification

+ +

En ce qui concerne les différentes méthodes d'authentification, + Apache respecte les recommandations IETF suivantes :

+ +
+
RFC 2617 + (Le track des standards)
+ +
"HTTP/1.0", y compris la spécification d'un protocole basique + d'authentification et de contrôle d'accès.
+ +
+ +
top
+
+

Codes de langues et de + pays

+ +

Les liens suivants fournissent des informations à propos des + codes de langues et de pays aux normes ISO ou autres :

+ +
+
ISO 639-2
+ +
ISO 639 fournit deux jeux de codes de langues permettant de + représenter les noms des langues ; le premier est + un jeu de codes sur deux lettres (639-1), le second (celui + présenté dans le lien ci-dessus), est un jeu de codes sur trois + lettres (639-2).
+ +
+ ISO 3166-1
+ +
Ce document présente les noms de pays (les noms raccourcis + officiels en anglais) dans l'ordre alphabétique, tels qu'ils sont + présentés dans la norme ISO 3166-1 et les éléments de codes + correspondants de la norme ISO 3166-1-alpha-2.
+ +
BCP 47 + (Les meilleurs pratiques courantes), + RFC 3066
+ +
Ce document décrit une balise de langue permettant de + spécifier la langue utilisé dans un objet contenant des + informations, la manière d'enregistrer des valeurs à utiliser dans + cette balise de langage, et une méthode pour comparer les balises + de langue de ce style.
+ +
RFC 3282 + (Série de standards)
+ +
Ce document définit un en-tête "Content-language:" permettant + de spécifier le langage d'un élément possédant des en-têtes du + style RFC 822, comme les portions de corps MIME ou les documents + Web, et un en-tête "Accept-Language:" permettant de spécifier des + préférences en matière de langue.
+
+ +
+
+

Langues Disponibles:  en  | + fr  | + ko 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/misc/relevant_standards.html.ko.euc-kr b/docs/manual/misc/relevant_standards.html.ko.euc-kr new file mode 100644 index 0000000..c1c8007 --- /dev/null +++ b/docs/manual/misc/relevant_standards.html.ko.euc-kr @@ -0,0 +1,221 @@ + + + + + + ǥ - Apache HTTP Server Version 2.4 + + + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.4

+
+
<-
+

ǥ

+
+

:  en  | + fr  | + 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  | + fr  | + ko 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/misc/security_tips.html b/docs/manual/misc/security_tips.html new file mode 100644 index 0000000..9324c2d --- /dev/null +++ b/docs/manual/misc/security_tips.html @@ -0,0 +1,17 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: security_tips.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: security_tips.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +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/docs/manual/misc/security_tips.html.en b/docs/manual/misc/security_tips.html.en new file mode 100644 index 0000000..1aabfe3 --- /dev/null +++ b/docs/manual/misc/security_tips.html.en @@ -0,0 +1,491 @@ + + + + + +Security Tips - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Security Tips

+
+

Available Languages:  en  | + fr  | + 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
+
+

Denial of Service (DoS) attacks

+ + + +

All network servers can be subject to denial of service attacks + that attempt to prevent responses to clients by tying up the + resources of the server. It is not possible to prevent such + attacks entirely, but you can do certain things to mitigate the + problems that they create.

+ +

Often the most effective anti-DoS tool will be a firewall or + other operating-system configurations. For example, most + firewalls can be configured to restrict the number of simultaneous + connections from any individual IP address or network, thus + preventing a range of simple attacks. Of course this is no help + against Distributed Denial of Service attacks (DDoS).

+ +

There are also certain Apache HTTP Server configuration + settings that can help mitigate problems:

+ +
    +
  • The RequestReadTimeout + directive allows to limit the time a client may take to send the + request.
    • + +
  • The TimeOut directive + should be lowered on sites that are subject to DoS attacks. + Setting this to as low as a few seconds may be appropriate. + As TimeOut is currently + used for several different operations, setting it to a low value + introduces problems with long running CGI scripts.
    • + +
  • The KeepAliveTimeout + directive may be also lowered on sites that are subject to DoS + attacks. Some sites even turn off the keepalives completely via + KeepAlive, which has of course + other drawbacks on performance.
    • + +
  • The values of various timeout-related directives provided by + other modules should be checked.
    • + +
  • The directives + LimitRequestBody, + LimitRequestFields, + LimitRequestFieldSize, + LimitRequestLine, and + LimitXMLRequestBody + should be carefully configured to limit resource consumption + triggered by client input.
    • + +
  • On operating systems that support it, make sure that you use + the AcceptFilter directive + to offload part of the request processing to the operating + system. This is active by default in Apache httpd, but may + require reconfiguration of your kernel.
    • + +
  • Tune the MaxRequestWorkers directive to allow + the server to handle the maximum number of simultaneous + connections without running out of resources. See also the performance tuning + documentation.
    • + +
  • The use of a threaded mpm may + allow you to handle more simultaneous connections, thereby + mitigating DoS attacks. Further, the + event mpm + uses asynchronous processing to avoid devoting a thread to each + connection. Due to the nature of the OpenSSL library the + event mpm is currently incompatible with + mod_ssl and other input filters. In these + cases it falls back to the behaviour of the + worker mpm.
    • + +
  • There are a number of third-party modules available + that can restrict certain client behaviors and thereby mitigate + DoS problems.
    • + +
+ +
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
+
+

Dynamic content security

+ + + +

When setting up dynamic content, such as mod_php, + mod_perl or mod_python, many security considerations + get out of the scope of httpd itself, and you need to consult + documentation from those modules. For example, PHP lets you setup Safe Mode, + which is most usually disabled by default. Another example is Suhosin, a PHP addon for more + security. For more information about those, consult each project + documentation.

+ +

At the Apache level, a module named mod_security + can be seen as a HTTP firewall and, provided you configure it finely enough, + can help you enhance your dynamic content security.

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

+ +

Note that this setting is the default since Apache 2.3.9.

+ +
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 "/">
+    Require all denied
+</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">
+    Require all granted
+</Directory>
+<Directory "/usr/local/httpd">
+    Require all granted
+</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. 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.example.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.example.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*">
+    Require all denied
+</Files>
+ + +
top
+
+

Merging of configuration sections

+ + + +

The merging of configuration sections is complicated and sometimes + directive specific. Always test your changes when creating dependencies + on how directives are merged.

+ +

For modules that don't implement any merging logic, such as + mod_access_compat, the behavior in later sections + depends on whether the later section has any directives + from the module. The configuration is inherited until a change is made, + at which point the configuration is replaced and not merged.

+
+
+

Available Languages:  en  | + fr  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/misc/security_tips.html.fr.utf8 b/docs/manual/misc/security_tips.html.fr.utf8 new file mode 100644 index 0000000..b99e3e9 --- /dev/null +++ b/docs/manual/misc/security_tips.html.fr.utf8 @@ -0,0 +1,513 @@ + + + + + +Conseils sur la sécurité - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Conseils sur la sécurité

+
+

Langues Disponibles:  en  | + fr  | + ko  | + tr 

+
+ +

Ce document propose quelques conseils et astuces concernant les + problèmes de sécurité liés + à l'installation d'un serveur web. Certaines suggestions seront à caractère + général, tandis que d'autres seront spécifiques à Apache.

+
+ +
top
+
+

Maintenez votre serveur à jour

+ +

Le serveur HTTP Apache a une bonne réputation en matière de sécurité + et possède une communauté de développeurs très sensibilisés aux problèmes + de sécurité. Mais il est inévitable de trouver certains problèmes + -- petits ou grands -- une fois le logiciel mis à disposition. C'est pour + cette raison qu'il est crucial de se tenir informé des mises à jour. Si + vous avez obtenu votre version du serveur HTTP directement depuis Apache, + nous vous conseillons grandement de vous abonner à la Liste de diffusion + des annonces du serveur HTTP qui vous informera de + la parution des nouvelles versions et des mises à jour de sécurité. La + plupart des distributeurs tiers d'Apache fournissent des services + similaires.

+ +

Gardez cependant à l'esprit que lorsqu'un serveur web est compromis, le + code du serveur HTTP n'est la plupart du temps pas en cause. Les problèmes + proviennent plutôt de code ajouté, de scripts CGI, ou du système + d'exploitation sous-jacent. Vous devez donc vous tenir informé des + problèmes et mises à jour concernant tous les logiciels présents sur + votre système.

+ +
top
+
+

Attaques de type "Déni de service" + (Denial of Service - DoS)

+ + + +

Tous les services réseau peuvent faire l'objet d'attaques de type + "Déni de service" qui tentent de les empêcher de répondre aux clients en + saturant leurs ressources. Il est impossible de se prémunir totalement + contre ce type d'attaques, mais vous pouvez accomplir certaines actions + afin de minimiser les problèmes qu'elles créent.

+ +

Souvent, l'outil anti-DoS le plus efficace sera constitué par le + pare-feu ou certaines configurations du système d'exploitation. Par + exemple, la plupart des pare-feu peuvent être configurés de façon à + limiter le nombre de connexions simultanées depuis une adresse IP ou un + réseau, ce qui permet de prévenir toute une gamme d'attaques simples. + Bien sûr, ceci n'est d'aucun secours contre les attaques de type + "Déni de service" distribuées (DDoS).

+ +

Certains réglages de la configuration d'Apache peuvent aussi + minimiser les problèmes :

+ +
    +
  • La directive RequestReadTimeout permet de + limiter le temps que met le client pour envoyer sa requête.
    • + +
  • La valeur de la directive + TimeOut doit être diminuée sur les + sites sujets aux attaques DoS. Une valeur de quelques secondes devrait + convenir. Cependant, comme TimeOut + est actuellement concerné par de nombreuses opérations différentes, lui + attribuer une valeur trop faible peut provoquer des problèmes avec les + scripts CGI qui présentent un long temps de réponse.
    • + +
  • La valeur de la directive + KeepAliveTimeout doit aussi être + diminuée sur les sites sujets aux attaques DoS. Certains sites + désactivent même complètement le "maintien en vie" (keepalives) + à l'aide de la directive + KeepAlive, ce qui bien sûr + présente des inconvénients en matière de performances.
    • + +
  • Les valeurs des différentes directives fournies par d'autres modules + et en rapport avec des délais doivent aussi être vérifiées.
    • + +
  • Les directives + LimitRequestBody, + LimitRequestFields, + LimitRequestFieldSize, + LimitRequestLine, et + LimitXMLRequestBody doivent être + configurées avec prudence afin de limiter la consommation de ressources + induite par les demandes des clients. +
    • + +
  • Sur les systèmes d'exploitation qui le supportent, assurez-vous que + la directive AcceptFilter est + activée afin de déléguer une partie du traitement des requêtes au + système d'exploitation. Elle est activée par défaut dans le démon httpd + d'Apache, mais peut nécessiter une reconfiguration de votre noyau.
    • + +
  • Optimisez la directive MaxRequestWorkers de façon à définir le nombre + maximum de connexions simultanées au dessus duquel les ressources + s'épuisent. Voir aussi la documentation sur l'optimisation des + performances.
    • + +
  • L'utilisation d'un module mpm threadé + vous permet de traiter d'avantage de connexions simultanées, ce qui + minimise l'effet des attaques DoS. Dans le futur, le module mpm + event utilisera un traitement asynchrone afin de ne pas + dédier un thread à chaque connexion. De par la + nature de la bibliothèque OpenSSL, le module mpm event est actuellement incompatible + avec le module mod_ssl ainsi que d'autres filtres + en entrée. Dans ces cas, son comportement se ramène à celui + du module mpm worker.
    • + +
  • Il existe de nombreux modules tiers qui peuvent restreindre les + comportements de certains clients et ainsi minimiser les problèmes de + DoS.
    • + +
+ +
top
+
+

Permissions sur les répertoires de la racine du serveur

+ + + +

Typiquement, Apache est démarré par l'utilisateur root, puis il devient + la propriété de l'utilisateur défini par la directive User afin de répondre aux demandes. Comme + pour toutes les commandes exécutées par root, vous devez vous assurer + qu'elle n'est pas modifiable par les utilisateurs autres que root. Les + fichiers eux-mêmes, mais aussi les répertoires ainsi que leurs parents ne + doivent être modifiables que par root. Par exemple, si vous avez choisi de + placer la racine du serveur dans /usr/local/apache, il est conseillé de + créer le répertoire en tant que root, avec des commandes du style :

+ +

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

+ +

Nous supposerons que /, /usr et + /usr/local ne sont modifiables que par + root. Quand vous installez l'exécutable httpd, vous + devez vous assurer qu'il possède des protections similaires :

+ +

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

+ +

Vous pouvez créer un sous-répertoire htdocs modifiable par d'autres + utilisateurs -- car root ne crée ni exécute aucun fichier dans ce + sous-répertoire.

+ +

Si vous permettez à des utilisateurs non root de modifier des fichiers + que root écrit ou exécute, vous exposez votre système à une compromission + de l'utilisateur root. Par exemple, quelqu'un pourrait remplacer le binaire + httpd de façon à ce que la prochaine fois que vous le + redémarrerez, il exécutera un code arbitraire. Si le répertoire des + journaux a les droits en écriture (pour un utilisateur non root), quelqu'un + pourrait remplacer un fichier journal par un lien symbolique vers un autre + fichier système, et root pourrait alors écraser ce fichier avec des données + arbitraires. Si les fichiers journaux eux-mêmes ont des droits en + écriture (pour un utilisateur non root), quelqu'un pourrait + modifier les journaux eux-mêmes avec des données fausses.

+ +
top
+
+

Inclusions côté serveur

+ + + +

Les inclusions côté serveur (Server Side Includes - SSI) exposent + l'administrateur du serveur à de nombreux risques potentiels en matière de + sécurité.

+ +

Le premier risque est l'augmentation de la charge du serveur. Tous les + fichiers où SSI est activé doivent être analysés par Apache, qu'ils + contiennent des directives SSI ou non. L'augmentation de la charge induite + est minime, mais peut devenir significative dans le contexte d'un + serveur partagé.

+ +

Les fichiers SSI présentent les mêmes risques que les scripts CGI en + général. Les fichiers où SSI est activé peuvent exécuter tout script CGI + ou autre programme à l'aide de la commande "exec cmd" avec les permissions + des utilisateur et groupe sous lesquels Apache s'exécute, comme défini + dans httpd.conf.

+ +

Des méthodes existent pour améliorer la sécurité des fichiers SSI, tout + en tirant parti des bénéfices qu'ils apportent.

+ +

Pour limiter les dommages qu'un fichier SSI agressif pourrait causer, + l'administrateur du serveur peut activersuexec + comme décrit dans la section Les CGI en général.

+ +

L'activation des SSI pour des fichiers possédant des extensions + .html ou + .htm peut s'avérer dangereux. Ceci est particulièrement vrai dans un + environnement de serveur partagé ou étant le siège d'un traffic élevé. Les + fichiers où SSI est activé doivent posséder une extension spécifique, telle + que la conventionnelle .shtml. Ceci permet de limiter la charge du serveur + à un niveau minimum et de simplifier la gestion des risques.

+ +

Une autre solution consiste à interdire l'exécution de scripts et + programmes à partir de pages SSI. Pour ce faire, remplacez + Includes par IncludesNOEXEC dans la directive + Options. Notez que les utilisateurs + pourront encore utiliser <--#include virtual="..." --> pour exécuter + des scripts CGI si ces scripts sont situés dans des répertoires spécifiés + par une directive + ScriptAlias.

+ +
top
+
+

Les CGI en général

+ + + +

Tout d'abord, vous devez toujours garder à l'esprit que vous devez + faire confiance aux développeurs de scripts ou programmes CGI ainsi qu'à + vos compétences pour déceler les trous de sécurité potentiels dans les + CGI, que ceux-ci soient délibérés ou accidentels. Les scripts CGI peuvent + essentiellement exécuter des commandes arbitraires sur votre système avec + les droits de l'utilisateur du serveur web, et peuvent par conséquent être + extrèmement dangereux s'ils ne sont pas vérifiés avec soin.

+ +

Tous les scripts CGI s'exécutent sous le même utilisateur, il peuvent + donc entrer en conflit (accidentellement ou délibérément) avec d'autres + scripts. Par exemple, l'utilisateur A hait l'utilisateur B, il écrit donc + un script qui efface la base de données CGI de l'utilisateur B. Vous pouvez + utiliser le programme suEXEC pour faire en + sorte que les scripts s'exécutent sous des utilisateurs différents. Ce + programme est inclus dans la distribution d'Apache depuis la version 1.2 + et est appelé à partir de certaines portions de code du serveur Apache. Une + autre méthode plus connue est l'utilisation de + CGIWrap.

+ +
top
+
+

CGI sans alias de script

+ + + +

Vous ne devez permettre aux utilisateurs d'exécuter des scripts CGI + depuis n'importe quel répertoire que dans l'éventualité où :

+ +
    +
  • Vous faites confiance à vos utilisateurs pour ne pas écrire de + scripts qui vont délibérément ou accidentellement exposer votre + système à une attaque.
    • +
  • Vous estimez que le niveau de sécurité dans les autres parties de + votre site est si faible qu'un trou de sécurité de plus ou de moins + n'est pas très important.
    • +
  • Votre système ne comporte aucun utilisateur, et personne ne visite + jamais votre site.
    • +
+ +
top
+
+

CGI avec alias de script

+ + + +

Le confinement des CGI dans des répertoires spécifiques permet à + l'administrateur de contrôler ce que l'on met dans ces répertoires. Ceci + est bien entendu mieux sécurisé que les CGI sans alias de script, mais + seulement à condition que les utilisateurs avec les droits en écriture sur + les répertoires soient dignes de confiance, et que l'administrateur ait la + volonté de tester chaque programme ou script CGI à la recherche d'éventuels + trous de sécurité.

+ +

La plupart des sites choisissent cette approche au détriment des CGI + sans alias de script.

+ +
top
+
+

Autres sources de contenu dynamique

+ + + +

+ Les options de scripting intégrées qui s'exécutent en tant que partie du + serveur lui-même, comme mod_php, mod_perl, + mod_tcl, et mod_python, + s'exécutent sous le même utilisateur que le serveur (voir la directive + User), et par conséquent, + les scripts que ces moteurs exécutent peuvent accéder aux mêmes ressources + que le serveur. Certains moteurs de scripting peuvent proposer des + restrictions, mais pour plus de sûreté, il vaut mieux partir du principe + que ce n'est pas le cas.

+ +
top
+
+

Protection de la configuration du système

+ + + +

Pour contrôler étroitement votre serveur, vous pouvez interdire + l'utilisation des fichiers .htaccess qui permettent de + passer outre les fonctionnalités de sécurité que vous avez configurées. + Voici un moyen pour y parvenir :

+ +

Ajoutez dans le fichier de configuration du serveur

+ + 
<Directory "/">
+    AllowOverride None
+</Directory>
+ + +

Ceci interdit l'utilisation des fichiers .htaccess dans + tous les répertoires, sauf ceux pour lesquels c'est explicitement + autorisé.

+ +

Notez que c'est la configuration par défaut depuis Apache 2.3.9.

+ +
top
+
+

Protection par défaut des fichiers du serveur

+ + + +

Le concept d'accès par défaut est un aspect d'Apache qui est parfois mal + compris. C'est à dire que, à moins que vous ne changiez explicitement ce + comportement, si le serveur trouve son chemin vers un fichier en suivant + les règles normales de correspondance URL - fichier, il peut le retourner + aux clients.

+ +

Considérons l'exemple suivant :

+ +

+ # cd /; ln -s / public_html
+ puis accès à http://localhost/~root/ +

+ +

Ceci permettrait aux clients de parcourir l'ensemble du système de + fichiers. Pour l'éviter, ajoutez le bloc suivant à la configuration + de votre serveur :

+ + 
<Directory "/">
+    Require all denied
+</Directory>
+ + +

ceci va interdire l'accès par défaut à tous les fichiers du système de + fichiers. Vous devrez ensuite ajouter les blocs + Directory appropriés correspondant + aux répertoires auxquels vous voulez autorisez l'accès. Par exemple,

+ + 
<Directory "/usr/users/*/public_html">
+    Require all granted
+</Directory>
+<Directory "/usr/local/httpd">
+    Require all granted
+</Directory>
+ + +

Portez une attention particulière aux interactions entre les directives + Location et + Directory ; par exemple, si une + directive <Directory ""/> interdit un accès, une + directive <Location "/"> pourra passer outre.

+ +

De même, soyez méfiant en jouant avec la directive + UserDir ; la positionner à + "./" aurait le même effet, pour root, que le premier exemple plus haut. + Nous vous conseillons + fortement d'inclure la ligne suivante dans le fichier de configuration de + votre serveur :

+ + 
UserDir disabled root
+ + +
top
+
+

Surveillez vos journaux

+ + + +

Pour vous tenir informé de ce qui se passe réellement dans votre + serveur, vous devez consulter vos + fichiers journaux. Même si les fichiers journaux + ne consignent que des évènements qui se sont déjà produits, ils vous + informeront sur la nature des attaques qui sont lancées contre le serveur + et vous permettront de vérifier si le niveau de sécurité nécessaire est + atteint.

+ +

Quelques exemples :

+ +

+ grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
+ grep "client denied" error_log | tail -n 10 +

+ +

Le premier exemple listera les attaques essayant d'exploiter la + vulnérabilité + d'Apache Tomcat pouvant provoquer la divulgation d'informations par des + requêtes Source.JSP mal formées, le second donnera la liste des dix + dernières interdictions client ; par exemple :

+ +

+ [Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied + by server configuration: /usr/local/apache/htdocs/.htpasswd +

+ +

Comme vous le voyez, les fichiers journaux ne consignent que ce qui + s'est déjà produit ; ainsi, si le client a pu accéder au fichier + .htpasswd, vous devriez avoir quelque chose du style :

+ +

+ foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1" +

+ +

dans votre journal des accès ; ce + qui signifie que vous avez probablement mis en commentaire ce qui suit dans + le fichier de configuration de votre serveur :

+ + 
<Files ".ht*">
+    Require all denied
+</Files>
+ + +
top
+
+

Fusion des sections de configuration

+ + + +

La fusion des sections de configuration est complexe et dépend + souvent des directives utilisées. Vous devez systématiquement tester + vos modifications pour vérifier la manière dont les directives sont + fusionnées.

+ +

Concernant les modules qui n'implémentent aucune logique de + fusion, comme mod_access_compat, le + comportement des sections suivantes est tributaire de la présence + dans ces dernières de directives appartenant à ces modules. La + configuration est héritée jusqu'à ce qu'une modification soit + effectuée ; à ce moment, la configuration est remplacée et + non fusionnée.

+
+
+

Langues Disponibles:  en  | + fr  | + ko  | + tr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/misc/security_tips.html.ko.euc-kr b/docs/manual/misc/security_tips.html.ko.euc-kr new file mode 100644 index 0000000..f186361 --- /dev/null +++ b/docs/manual/misc/security_tips.html.ko.euc-kr @@ -0,0 +1,373 @@ + + + + + + - Apache HTTP Server Version 2.4 + + + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.4

+
+
<-
+

+
+

:  en  | + fr  | + 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 ũƮ ڷ DZ⶧ ٸ + ũƮ (ǰ Ǽ̰) 浹 ɼ ִ. + , 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 þ ) DZ⶧, + ũƮ ϴ ũƮ ڰ + ִ Ϳ ִ.  ũƮ + , ϴٰ ʴ .

+ +
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  | + fr  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/misc/security_tips.html.tr.utf8 b/docs/manual/misc/security_tips.html.tr.utf8 new file mode 100644 index 0000000..4a46578 --- /dev/null +++ b/docs/manual/misc/security_tips.html.tr.utf8 @@ -0,0 +1,485 @@ + + + + + +Güvenlik İpuçları - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + +
+

Modüller | Yönergeler | SSS | Terimler | Site Haritası

+

Apache HTTP Sunucusu Sürüm 2.4

+
+
<-
+

Güvenlik İpuçları

+
+

Mevcut Diller:  en  | + fr  | + 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
+
+

Hizmet Reddi (DoS) Saldırıları

+ + +

Tüm ağ sunucuları, istemcilerin sistem kaynaklarından yararlanmalarını + engellemeye çalışan hizmet reddi saldırılarına (HRS) maruz kalabilir. + Bu tür saldırıları tamamen engellemek mümkün değildir, fakat + yarattıkları sorunları azaltmak için bazı şeyler yapabilirsiniz.

+ +

Çoğunlukla en etkili anti-HRS aracı bir güvenlik duvarı veya başka bir + işletim sistemi yapılandırmasıdır. Örneğin, çoğu güvenlik duvarı + herhangi bir IP adresinden aynı anda yapılan bağlantıların sayısına bir + sınırlama getirmek üzere yapılandırılabilir. Böylece basit saldırılar + engellenebilir. Ancak bunun dağıtık hizmet reddi saldırılarına (DHRS) + karşı bir etkisi olmaz.

+ +

Bunların yanında Apache HTTP Sunucusunun da sorunları azaltıcı + tedbirler alınmasını sağlayacak bazı yapılandırmaları vardır:

+ +
    +
  • RequestReadTimeout + yönergesi bir istemcinin isteği göndermek için harcadığı zamanı + sınırlamayı sağlar.
    • + +
  • HRS’ye maruz kalması olası sitelerde TimeOut yönergesinin değeri düşürülmelidir. Birkaç + saniye gibi mümkün olduğunca düşük bir ayar uygun olabilir. Ancak + TimeOut başka işlemlerde de + kullanıldığından çok düşük değerler, örneğin, uzun süre çalışan CGI + betiklerinde sorunlar çıkmasına sebep olabilir.
    • + +
  • HRS’ye maruz kalması olası sitelerde KeepAliveTimeout yönergesinin değeri de düşürülebilir. + Hatta bazı siteler başarımı arttırmak amacıyla KeepAlive yönergesi üzerinden kalıcı + bağlantıları tamamen kapatabilirler.
    • + +
  • Zaman aşımıyla ilgili yönergeler bakımından diğer modüller de + araştırılmalıdır.
    • + +
  • LimitRequestBody, + LimitRequestFields, + LimitRequestFieldSize, + LimitRequestLine ve + LimitXMLRequestBody yönergeleri, + istemci girdileri ile tetiklenen özkaynak tüketimini sınırlamak için + yapılandırılırken dikkatli olunmalıdır.
    • + +
  • İşletim sisteminiz desteklediği takdirde, işletim sisteminin isteği + işleyen kısmını yüksüz bırakmak için AcceptFilter yönergesinin etkin olmasını sağlamalısınız. + Bu, Apache HTTP Sunucusunda zaten öntanımlı olarak etkindir. + Yapacağınız şey işletim sistemi çekirdeğini buna göre yapılandırmak + olacaktır.
    • + +
  • Sunucu tarafından özkaynakları tüketmeden aynı anda işlenebilecek + bağlantıların sayısını sınırlamak için MaxRequestWorkers yönergesini kullanın. Ayrıca, başarım arttırma belgesine de + bakabilirsiniz.
    • + +
  • HRS’lerin etkilerini azaltmak için aynı andaki bağlantı sayısını + arttırabilecek evreli MPM’lerden birini + kullanmak iyi olabilir. Dahası, event MPM’i + her bağlantıya yeni bir evre atanmaması için eşzamansız işlem yapar. + OpenSSL kütüphanesinin doğası nedeniyle + event MPM’i mod_ssl ve diğer girdi + süzgeçleri ile henüz uyumlu değildir. Bu durumlarda, + worker MPM'inin davranışına geri döner.
    • + +
  • Belli istemci davranışlarını sınırlayacak ve HRS ile + ilgili sorunları azaltmaya yardımcı olacak üçüncü parti modüller + bulunabilir.
    • +
+
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
+
+

Devingen içeriğin güvenliği

+ + +

mod_php, mod_perl veya + mod_python gibi devingen içeriği yapılandırırken + güvenlikle ilgili değerlendirmelerin çoğu httpd'nin + kapsamından çıkar ve bu modüllerin belgelerini incelemek ihtiyacı + duyarsınız. Örneğin, PHP çoğu zaman kapalı tutulan + Güvenli + Kip ayarını etkin kılmanızı önerir. Daha fazla güvenlik için bir + diğer örnek bir PHP eklentisi olan + Suhosin'dir. Bunlar + hakkında daha ayrıntılı bilgi için her projenin kendi belgelerine + başvurun.

+ +

Apache seviyesinde, mod_security + adı verilen modülü bir HTTP güvenlik duvarı gibi ele alabilir, devingen + içeriğin güvenliğini arttırmanıza yardımcı olmak üzere inceden inceye + yapılandırabilirsiniz.

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

+ +

Bu ayar Apache 2.3.9 itibariyle öntanımlıdır.

+
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 "/">
+    Require all denied
+</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">
+    Require all granted
+</Directory>
+<Directory "/usr/local/httpd">
+    Require all granted
+</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. 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 foo.example.com] 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:

+ +

+ foo.example.com - - [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*">
+    Require all denied
+</Files>
+ + +
top
+
+

Yapılandırma bölümlerinin birleştirilmesi

+ + + +

Yapılandırma bölümlerinin birleştirilmesi karmaşık bir işlem olup bazı + durumlarda yönergelere bağlıdır. Yönergeleri bir araya getirirken + aralarındaki bağımlılıkları daima sınayın.

+ +

mod_access_compat gibi henüz yönerge katıştırma + mantığını gerçeklememiş modüller için sonraki bölümlerdeki davranış, bu + modüllerin yönergelerini içerip içermemesine bağlıdır. Yapılandırmada + yönergelerin yerleri değiştirildiğinde fakat bir katıştırma + yapılmadığında, yapılandırma bir değişiklik yapılana kadar miras + alınır.

+
+
+

Mevcut Diller:  en  | + fr  | + ko  | + tr 

+
top

Yorumlar

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file -- cgit v1.2.3