]> granicus.if.org Git - apache/blob - docs/manual/mod/mod_unique_id.html.fr
Update transformations.
[apache] / docs / manual / mod / mod_unique_id.html.fr
1 <?xml version="1.0" encoding="ISO-8859-1"?>
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3 <html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head><!--
4         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
5               This file is generated from xml source: DO NOT EDIT
6         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
7       -->
8 <title>mod_unique_id - Serveur Apache HTTP</title>
9 <link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
10 <link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
11 <link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
12 <link href="../images/favicon.ico" rel="shortcut icon" /></head>
13 <body>
14 <div id="page-header">
15 <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p>
16 <p class="apache">Serveur Apache HTTP Version 2.3</p>
17 <img alt="" src="../images/feather.gif" /></div>
18 <div class="up"><a href="./"><img title="&lt;-" alt="&lt;-" src="../images/left.gif" /></a></div>
19 <div id="path">
20 <a href="http://www.apache.org/">Apache</a> &gt; <a href="http://httpd.apache.org/">Serveur HTTP</a> &gt; <a href="http://httpd.apache.org/docs/">Documentation</a> &gt; <a href="../">Version 2.3</a> &gt; <a href="./">Modules</a></div>
21 <div id="page-content">
22 <div id="preamble"><h1>Module Apache mod_unique_id</h1>
23 <div class="toplang">
24 <p><span>Langues Disponibles: </span><a href="../en/mod/mod_unique_id.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
25 <a href="../fr/mod/mod_unique_id.html" title="Français">&nbsp;fr&nbsp;</a> |
26 <a href="../ja/mod/mod_unique_id.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a> |
27 <a href="../ko/mod/mod_unique_id.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a></p>
28 </div>
29 <table class="module"><tr><th><a href="module-dict.html#Description">Description:</a></th><td>Fournit une variable d'environnement contenant un
30 identifiant unique pour chaque requête</td></tr>
31 <tr><th><a href="module-dict.html#Status">Statut:</a></th><td>Extension</td></tr>
32 <tr><th><a href="module-dict.html#ModuleIdentifier">Identificateur de Module:</a></th><td>unique_id_module</td></tr>
33 <tr><th><a href="module-dict.html#SourceFile">Fichier Source:</a></th><td>mod_unique_id.c</td></tr></table>
34 <h3>Sommaire</h3>
35
36
37     <p>Ce module fournit un identifiant dont l'unicité est garantie
38     parmi "toutes" les requêtes sous des conditions très précises.
39     L'identifiant unique le sera aussi parmi plusieurs machines
40     appartenant à un cluster correctement configuré. L'identifiant est
41     affecté à la variable d'environnement <code>UNIQUE_ID</code> pour
42     chaque requête. Les identifiants uniques sont utiles pour diverses
43     raisons dont la nature se situe au delà de la portée de ce
44     document.</p>
45 </div>
46 <div id="quickview"><h3 class="directives">Directives</h3>
47 <p>Ce module ne fournit aucune directive.</p>
48 <h3>Sujets</h3>
49 <ul id="topics">
50 <li><img alt="" src="../images/down.gif" /> <a href="#theory">Théorie</a></li>
51 </ul></div>
52 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
53 <div class="section">
54 <h2><a name="theory" id="theory">Théorie</a></h2>
55     
56
57     <p>Tout d'abord un bref rappel de la manière dont le serveur Apache
58     fonctionne sous Unix (cette fonctionnalité n'étant actuellement pas
59     supportée sous Windows NT). Sous Unix, Apache crée plusieurs
60     processus enfants, ces derniers traitant les requêtes une par une.
61     Chaque processus enfant peut traiter plusieurs requêtes pendant sa
62     durée de vie. Dans le cadre de cette discussion, nous supposerons
63     que les différents processus enfants ne s'échangent pas de données
64     entre eux. Nous nous référerons aux processus enfants sous le nom de
65     <dfn>processus httpd</dfn>.</p>
66
67     <p>Votre site web est réparti entre une ou plusieurs machines dont
68     vous êtes l'administrateur, et que nous nommerons cluster de
69     serveurs. Chaque serveur peut exécuter plusieurs instances d'Apache.
70     L'ensemble de ces dernières sera considéré comme "l'Univers", et
71     sous certaines hypothèses, nous montrerons qu'il est possible dans
72     cet univers, de générer des identifiants uniques pour chaque
73     requête, sans pour autant nécessiter une communication importante
74     entre les différents serveurs du cluster.</p>
75
76     <p>Les machines de votre cluster doivent satisfaire ces conditions
77     (même si le cluster ne comporte qu'une machine, vous devez
78     synchroniser son horloge avec NTP) :</p>
79
80     <ul>
81       <li>Les temps des machines sont synchronisés via NTP ou tout autre
82       protocole de synchronisation du temps en réseau.</li>
83
84       <li>Les nom d'hôtes des machines sont tous différents, de façon à
85       ce que le module puisse recevoir une adresse IP différente pour
86       chaque machine du cluster en effectuant une recherche sur le nom
87       d'hôte.</li>
88     </ul>
89
90     <p>Au vu des caractéristiques actuelles du système d'exploitation,
91     nous supposerons que les pids (identifiants processus) sont codés
92     sur 32 bits. Si le système d'exploitation utilise plus de 32 bits
93     pour un pid, la correction est triviale mais doit être effectuée
94     dans le code.</p>
95
96     <p>Ces hypothèses posées, à un instant donné, nous pouvons
97     distinguer tout processus httpd sur toute machine du cluster de tous
98     les autres processus httpd. Pour ce faire, il suffit d'utiliser
99     l'adresse IP de la machine et le pid du processus httpd. Un
100     processus httpd peut traiter plusieurs requêtes simultanément si
101     vous utilisez un module MPM multi-threadé. Pour identifier les
102     threads, Apache httpd utilise en interne un index de threads. Ainsi,
103     afin de générer des identifiants uniques pour chaque requête, il
104     suffit d'effectuer une distinction en fonction du temps.</p>
105
106     <p>Pour déterminer le temps, nous utiliserons un repère de temps
107     Unix (les secondes écoulées depuis le 1er janvier 1970 UTC), et un
108     compteur 16 bits. La précision du repère de temps n'étant que d'une
109     seconde, le compteur va représenter 65536 valeurs par seconde. Le
110     quadruplet <em>(adresse IP, pid, repère de temps, compteur)</em> est
111     en mesure de distinguer 65536 requêtes par seconde par processus
112     httpd. Il peut cependant arriver que le même pid soit réutilisé au
113     cours du temps, et le compteur est là pour pallier cet
114     inconvénient.</p>
115
116     <p>Lorsqu'un processus enfant httpd est créé, le compteur est
117     initialisé avec (nombre de microsecondes actuel divisé par 10)
118     modulo 65536 (cette formule a été choisie pour éliminer certains
119     problème de variance avec les bits de poids faibles du compteur de
120     microsecondes sur certains systèmes). Lorsqu'un identifiant unique
121     est généré, le repère de temps utilisé est le moment où la requête
122     arrive sur le serveur web. Le compteur est incrémenté à chaque
123     création d'identifiant (et peut repasser à 0 lorsqu'il a atteint sa
124     valeur maximale).</p>
125
126     <p>Le noyau génère un pid pour chaque processus lors de sa création,
127     et le compteur de pid est réinitialisé à une certaine valeur
128     lorsqu'il a atteint sa valeur maximale (les pid sont codés sur 16
129     bits sous de nombreux Unixes, mais les systèmes les plus récents les
130     ont étendus à 32 bits). La même valeur de pid pourra donc être
131     réutilisée au cours du temps. Cependant, tant qu'elle n'est pas
132     réutilisée dans la même seconde, elle ne remet pas en cause
133     l'unicité de notre quadruplet. Nous supposerons donc que le système
134     ne créera pas plus de 65536 processus en une seconde (ce nombre peut
135     être de 32768 sous certains Unixes, mais même dans ce cas, on est en
136     général loin de cette situation).</p>
137
138     <p>Il est possible que le temps se répète pour une raison
139     quelconque.
140     Supposons par exemple que l'horloge système soit retardée et repasse
141     par un temps passé (ou bien, comme elle avançait, elle a été remise
142     à l'heure, et elle repasse par un temps futur). Dans ce cas, il peut
143     être facilement démontré que le couple pid/repère de temps peut être
144     réutilisé. Le choix de la formule d'initialisation du compteur a
145     été effectué dans l'intention de pallier ce problème. Notez qu'un
146     nombre vraiment aléatoire serait souhaitable pour initialiser le
147     compteur, mais il n'existe pas de tel nombre directement lisible sur
148     la plupart des systèmes (c'est à dire que vous ne pouvez pas
149     utiliser rand() car vous devez déclencher le générateur avec une
150     valeur unique, et vous ne pouvez pas utiliser le temps à cet effet
151     car celui-ci , au moins à la seconde près, s'est répété). Il ne
152     s'agit donc pas d'une défense parfaite.</p>
153
154     <p>Même si elle n'est pas parfaite, quel est le degré d'efficacité
155     de cette défense ? Supposons
156     qu'une de vos machines serve au plus 500 requêtes par seconde (ce
157     qui constitue une limite supérieure très raisonnable au moment où ce
158     document est écrit, car les systèmes ne se contentent en général pas
159     de débiter des fichiers statiques). Pour y parvenir, un certain nombre
160     de processus enfants sera nécessaire, qui dépendra du nombre de
161     clients simultanés présents. Mais soyons pessimiste et supposons
162     qu'un seul processus enfant soit capable de servir 500 requêtes par
163     secondes.
164     Il existe 1000 valeurs de démarrage possibles du compteur pour
165     lesquelles deux séquences de 500 requêtes puissent se recouvrir. Il
166     y a donc 1,5% de chance que le processus enfant répète une valeur de
167     compteur si le temps se répète (avec une résolution d'une seconde),
168     et l'unicité sera alors remise en cause. C'est cependant un exemple
169     très pessimiste, et avec les valeurs du monde réel, il y a bien
170     moins de chances que cela ne se produise. Si vous estimez que ceci a
171     tout de même quelque chances de se produire sur votre système, vous
172     pouvez migrer vers un compteur à 32 bits (en modifiant le code).</p>
173
174     <p>On pourrait supposer que ceci a plus de chance de se produire
175     lors du passage à l'heure d'hiver où l'horloge est "retardée". Cela
176     ne constitue cependant pas un problème car les temps pris en compte
177     ici sont des temps UTC, qui vont "toujours" de l'avant. Notez que
178     les Unixes à base de processeur x86 peuvent nécessiter une
179     configuration particulière pour que ceci soit vrai -- il doivent
180     être configurés pour assumer que l'horloge système est en UTC et
181     compenser de manière appropriée. Mais même dans ce cas, si vous
182     utilisez NTP, votre temps UTC sera correct peu après le
183     redémarrage.</p>
184
185     
186     <p>La variable d'environnement <code>UNIQUE_ID</code> est construite
187     par codage du quadruplet de 144 bits (adresse IP sur 32 bits, pid
188     sur 32 bits, repère de temps sur 32 bits, compteur 16 bits et index
189     de threads sur 32 bits) en
190     utilisant l'alphabet <code>[A-Za-z0-9@-]</code> d'une manière
191     similaire à celle du codage MIME base64, et sa valeur se présente
192     sous la forme d'une chaîne de 24 caractères. L'alphabet MIME base64
193     est en fait <code>[A-Za-z0-9+/]</code> ; cependant, les caractères
194     <code>+</code> et <code>/</code> nécessitent un codage particulier
195     dans les URLs, ce qui rend leur utilisation peu commode. Toutes les
196     valeurs sont codées dans l'ordre des octets d'une adresse réseau de
197     façon à ce
198     que le codage soit comparable entre des architectures où l'ordre des
199     octets est différent. L'ordre réel de codage est : repère de temps,
200     adresse IP, pid, compteur. Cet ordre de codage possède un but
201     précis, mais il faut souligner que les applications n'ont aucun
202     intérêt à entrer dans les détails de ce codage. Les applications
203     doivent se contenter de traiter la variable <code>UNIQUE_ID</code>
204     comme un symbole opaque, qui peut être comparé avec d'autres
205     <code>UNIQUE_ID</code>s en ne testant que leur égalité.</p>
206
207     <p>L'ordre a été choisi de façon à ce qu'il soit possible de
208     modifier le codage dans le futur sans avoir à se préoccuper de
209     conflits éventuels avec une base de données de
210     <code>UNIQUE_ID</code>s existante. Les nouveaux codages doivent
211     conserver le repère de temps comme premier élément, et pour le
212     reste, utiliser les même alphabet et longueur en bits. Comme les
213     repères de temps constituent essentiellement un séquence croissante,
214     il suffit que toutes les machines du cluster arrêtent de servir et
215     de requérir dans la même <em>seconde repère</em>, et n'utilisent
216     alors plus l'ancien format de codage. Ensuite, elles peuvent
217     reprendre le traitement des requêtes en utilisant les nouveaux
218     codages.</p>
219
220     <p>Nous pensons que ceci apporte une solution relativement portable
221     au problème. Les
222     identifiants générés possèdent une durée de vie pratiquement infinie
223     car les identifiants futurs pourront être allongés selon les
224     besoins. Pratiquement aucune communication n'est requise entre les
225     machines du cluster (seule la synchronisation NTP est requise, ce
226     qui représente une charge très faible), et aucune communication
227     entre les processus httpd n'est nécessaire (la communication est
228     implicite et incluse dans le pid assigné par le noyau). Dans des
229     situations très spécifiques, l'identifiant peut être raccourci, mais
230     dans ce cas, d'avantage d'informations doivent être admises (par
231     exemple, les 32 bits de l'adresse IP sont excessifs pour la plupart
232     des sites, mais il n'existe pas de valeur de remplacement portable
233     plus courte).</p>
234 </div>
235 </div>
236 <div class="bottomlang">
237 <p><span>Langues Disponibles: </span><a href="../en/mod/mod_unique_id.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
238 <a href="../fr/mod/mod_unique_id.html" title="Français">&nbsp;fr&nbsp;</a> |
239 <a href="../ja/mod/mod_unique_id.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a> |
240 <a href="../ko/mod/mod_unique_id.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a></p>
241 </div><div id="footer">
242 <p class="apache">Copyright 2010 The Apache Software Foundation.<br />Autorisé sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
243 <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p></div>
244 </body></html>