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