docs/manual/mod/mod_unique_id.html.fr.utf8 - httpd - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!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=UTF-8" http-equiv="Content-Type" />
 <!--
         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
               This file is generated from xml source: DO NOT EDIT
         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
       -->
 <title>mod_unique_id - Serveur HTTP Apache Version 2.4</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/directives.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 HTTP Apache Version 2.4</p>
 <img alt="" src="../images/feather.png" /></div>
 <div class="up"><a href="./"><img title="&lt;-" alt="&lt;-" src="../images/left.gif" /></a></div>
 <div id="path">
 <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.4</a> &gt; <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">&nbsp;en&nbsp;</a> |
 <a href="../fr/mod/mod_unique_id.html" title="Français">&nbsp;fr&nbsp;</a> |
 <a href="../ja/mod/mod_unique_id.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a> |
 <a href="../ko/mod/mod_unique_id.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</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"><a href="https://www.apache.org/foundation/contributing.html" class="badge"><img src="https://www.apache.org/images/SupportApache-small.png" alt="Support Apache!" /></a><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>Traitement des bugs</h3><ul class="seealso"><li><a href="https://www.apache.org/dist/httpd/CHANGES_2.4">Journal des modifications de httpd</a></li><li><a href="https://bz.apache.org/bugzilla/buglist.cgi?bug_status=__open__&amp;list_id=144532&amp;product=Apache%20httpd-2&amp;query_format=specific&amp;order=changeddate%20DESC%2Cpriority%2Cbug_severity&amp;component=mod_unique_id">Problèmes connus</a></li><li><a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2&amp;component=mod_unique_id">Signaler un 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">&nbsp;en&nbsp;</a> |
 <a href="../fr/mod/mod_unique_id.html" title="Français">&nbsp;fr&nbsp;</a> |
 <a href="../ja/mod/mod_unique_id.html" hreflang="ja" rel="alternate" title="Japanese">&nbsp;ja&nbsp;</a> |
 <a href="../ko/mod/mod_unique_id.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</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&amp;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 <a href="https://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/2.4/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 2022 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/directives.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>
	<?xml version="1.0" encoding="UTF-8"?>
	<!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=UTF-8" http-equiv="Content-Type" />
	<!--
	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
	This file is generated from xml source: DO NOT EDIT
	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
	-->
	<title>mod_unique_id - Serveur HTTP Apache Version 2.4</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/directives.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 HTTP Apache Version 2.4</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.4</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"><a href="https://www.apache.org/foundation/contributing.html" class="badge"><img src="https://www.apache.org/images/SupportApache-small.png" alt="Support Apache!" /></a><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>Traitement des bugs</h3><ul class="seealso"><li><a href="https://www.apache.org/dist/httpd/CHANGES_2.4">Journal des modifications de httpd</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">Problèmes connus</a></li><li><a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2&component=mod_unique_id">Signaler un 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 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 <a href="https://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/2.4/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 2022 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/directives.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>