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="en" xml:lang="en"><head><!--
4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
5 This file is generated from xml source: DO NOT EDIT
6 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
7 --><title>mod_unique_id - Apache HTTP Server</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="../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="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p><p class="apache">Apache HTTP Server Version 2.0</p><img alt="" src="../images/feather.gif" /></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/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.0</a> > <a href="./">Modules</a></div><div id="page-content"><div id="preamble"><h1>Apache Module mod_unique_id</h1><table class="module"><tr><th><a href="module-dict.html#Description">Description:
8 </a></th><td>Provides an environment variable with a unique
9 identifier for each request</td></tr><tr><th><a href="module-dict.html#Status">Status:
10 </a></th><td>Extension</td></tr><tr><th><a href="module-dict.html#ModuleIdentifier">Module Identifier:
11 </a></th><td>unique_id_module</td></tr><tr><th><a href="module-dict.html#SourceFile">Source File:
12 </a></th><td>mod_unique_id.c</td></tr></table><h3>Summary</h3>
14 <p>This module provides a magic token for each request which is
15 guaranteed to be unique across "all" requests under very
16 specific conditions. The unique identifier is even unique
17 across multiple machines in a properly configured cluster of
18 machines. The environment variable <code>UNIQUE_ID</code> is
19 set to the identifier for each request. Unique identifiers are
20 useful for various reasons which are beyond the scope of this
22 </div><div id="quickview"><h3 class="directives">Directives</h3><p>This module provides no directives.</p><h3>Topics</h3><ul id="topics"><li><img alt="" src="../images/down.gif" /> Theory</li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2>Theory</h2>
25 <p>First a brief recap of how the Apache server works on Unix
26 machines. This feature currently isn't supported on Windows NT.
27 On Unix machines, Apache creates several children, the children
28 process requests one at a time. Each child can serve multiple
29 requests in its lifetime. For the purpose of this discussion,
30 the children don't share any data with each other. We'll refer
31 to the children as httpd processes.</p>
33 <p>Your website has one or more machines under your
34 administrative control, together we'll call them a cluster of
35 machines. Each machine can possibly run multiple instances of
36 Apache. All of these collectively are considered "the
37 universe", and with certain assumptions we'll show that in this
38 universe we can generate unique identifiers for each request,
39 without extensive communication between machines in the
42 <p>The machines in your cluster should satisfy these
43 requirements. (Even if you have only one machine you should
44 synchronize its clock with NTP.)</p>
47 <li>The machines' times are synchronized via NTP or other
48 network time protocol.</li>
50 <li>The machines' hostnames all differ, such that the module
51 can do a hostname lookup on the hostname and receive a
52 different IP address for each machine in the cluster.</li>
55 <p>As far as operating system assumptions go, we assume that
56 pids (process ids) fit in 32-bits. If the operating system uses
57 more than 32-bits for a pid, the fix is trivial but must be
58 performed in the code.</p>
60 <p>Given those assumptions, at a single point in time we can
61 identify any httpd process on any machine in the cluster from
62 all other httpd processes. The machine's IP address and the pid
63 of the httpd process are sufficient to do this. So in order to
64 generate unique identifiers for requests we need only
65 distinguish between different points in time.</p>
67 <p>To distinguish time we will use a Unix timestamp (seconds
68 since January 1, 1970 UTC), and a 16-bit counter. The timestamp
69 has only one second granularity, so the counter is used to
70 represent up to 65536 values during a single second. The
71 quadruple <em>( ip_addr, pid, time_stamp, counter )</em> is
72 sufficient to enumerate 65536 requests per second per httpd
73 process. There are issues however with pid reuse over time, and
74 the counter is used to alleviate this issue.</p>
76 <p>When an httpd child is created, the counter is initialized
77 with ( current microseconds divided by 10 ) modulo 65536 (this
78 formula was chosen to eliminate some variance problems with the
79 low order bits of the microsecond timers on some systems). When
80 a unique identifier is generated, the time stamp used is the
81 time the request arrived at the web server. The counter is
82 incremented every time an identifier is generated (and allowed
85 <p>The kernel generates a pid for each process as it forks the
86 process, and pids are allowed to roll over (they're 16-bits on
87 many Unixes, but newer systems have expanded to 32-bits). So
88 over time the same pid will be reused. However unless it is
89 reused within the same second, it does not destroy the
90 uniqueness of our quadruple. That is, we assume the system does
91 not spawn 65536 processes in a one second interval (it may even
92 be 32768 processes on some Unixes, but even this isn't likely
95 <p>Suppose that time repeats itself for some reason. That is,
96 suppose that the system's clock is screwed up and it revisits a
97 past time (or it is too far forward, is reset correctly, and
98 then revisits the future time). In this case we can easily show
99 that we can get pid and time stamp reuse. The choice of
100 initializer for the counter is intended to help defeat this.
101 Note that we really want a random number to initialize the
102 counter, but there aren't any readily available numbers on most
103 systems (<em>i.e.</em>, you can't use rand() because you need
104 to seed the generator, and can't seed it with the time because
105 time, at least at one second resolution, has repeated itself).
106 This is not a perfect defense.</p>
108 <p>How good a defense is it? Suppose that one of your machines
109 serves at most 500 requests per second (which is a very
110 reasonable upper bound at this writing, because systems
111 generally do more than just shovel out static files). To do
112 that it will require a number of children which depends on how
113 many concurrent clients you have. But we'll be pessimistic and
114 suppose that a single child is able to serve 500 requests per
115 second. There are 1000 possible starting counter values such
116 that two sequences of 500 requests overlap. So there is a 1.5%
117 chance that if time (at one second resolution) repeats itself
118 this child will repeat a counter value, and uniqueness will be
119 broken. This was a very pessimistic example, and with real
120 world values it's even less likely to occur. If your system is
121 such that it's still likely to occur, then perhaps you should
122 make the counter 32 bits (by editing the code).</p>
124 <p>You may be concerned about the clock being "set back" during
125 summer daylight savings. However this isn't an issue because
126 the times used here are UTC, which "always" go forward. Note
127 that x86 based Unixes may need proper configuration for this to
128 be true -- they should be configured to assume that the
129 motherboard clock is on UTC and compensate appropriately. But
130 even still, if you're running NTP then your UTC time will be
131 correct very shortly after reboot.</p>
133 <p>The <code>UNIQUE_ID</code> environment variable is
134 constructed by encoding the 112-bit (32-bit IP address, 32 bit
135 pid, 32 bit time stamp, 16 bit counter) quadruple using the
136 alphabet <code>[A-Za-z0-9@-]</code> in a manner similar to MIME
137 base64 encoding, producing 19 characters. The MIME base64
138 alphabet is actually <code>[A-Za-z0-9+/]</code> however
139 <code>+</code> and <code>/</code> need to be specially encoded
140 in URLs, which makes them less desirable. All values are
141 encoded in network byte ordering so that the encoding is
142 comparable across architectures of different byte ordering. The
143 actual ordering of the encoding is: time stamp, IP address,
144 pid, counter. This ordering has a purpose, but it should be
145 emphasized that applications should not dissect the encoding.
146 Applications should treat the entire encoded
147 <code>UNIQUE_ID</code> as an opaque token, which can be
148 compared against other <code>UNIQUE_ID</code>s for equality
151 <p>The ordering was chosen such that it's possible to change
152 the encoding in the future without worrying about collision
153 with an existing database of <code>UNIQUE_ID</code>s. The new
154 encodings should also keep the time stamp as the first element,
155 and can otherwise use the same alphabet and bit length. Since
156 the time stamps are essentially an increasing sequence, it's
157 sufficient to have a <em>flag second</em> in which all machines
158 in the cluster stop serving and request, and stop using the old
159 encoding format. Afterwards they can resume requests and begin
160 issuing the new encodings.</p>
162 <p>This we believe is a relatively portable solution to this
163 problem. It can be extended to multithreaded systems like
164 Windows NT, and can grow with future needs. The identifiers
165 generated have essentially an infinite life-time because future
166 identifiers can be made longer as required. Essentially no
167 communication is required between machines in the cluster (only
168 NTP synchronization is required, which is low overhead), and no
169 communication between httpd processes is required (the
170 communication is implicit in the pid value assigned by the
171 kernel). In very specific situations the identifier can be
172 shortened, but more information needs to be assumed (for
173 example the 32-bit IP address is overkill for any site, but
174 there is no portable shorter replacement for it). </p>
175 </div></div><div id="footer"><p class="apache">Maintained by the <a href="http://httpd.apache.org/docs-project/">Apache HTTP Server Documentation Project</a></p><p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div></body></html>