No results found
Netcraft determines the operating system of the queried host by looking in detail at the network characteristics of the HTTP reply received from the web site.
The reported operating system may be different to the one you expected because:
- The site is using a web proxy cache such as Apache Traffic Server or a server running the open source Squid software. In this situation we will be connecting to the reverse web proxy rather than the originating web server, so will detect the cache's O/S rather than the web server's. Some proxy caching systems add headers to web server responses, such as the standard "Via" header. If the "Via" or "X-Cache" headers are found we report that the site is proxied.
- The site is using a server load balancing device (SLB) like Cisco Web NS , Citrix ADC (formerly NetScaler) or f5 BIG-IP . Some of these SLBs handle the TCP connection themselves, so we detect the SLB's operating system. Others use TCP/IP packet level Network Address Translation techniques, where we detect the operating system of one of the back-end web servers.
- The site load shares across multiple servers using different operating systems with round robin DNS. In such cases each query might detect a different operating system.
- The site has changed the default configuration of their TCP/IP stack, perhaps for performance reasons, or have an unusual LAN environment.
- We made a mistake. If you see an operating system & web server combination reported that you know to be wrong, please e-mail us.
We can reliably detect the following operating systems:
- AIX
- AS/400
- BSD/OS
- DG/UX
- Cisco
- Compaq Tru64
- FreeBSD
- HP-UX
- IRIX
- Linux
- MacOSX
- NetApp NetCache
- NetBSD/OpenBSD
- NetWare
- NT3/Windows 95
- NT4/Windows 98
- OpenVMS
- OS/2
- OS/390
- SCO UNIX
- Solaris (both Solaris 2 and Solaris 7)
- Solaris 8
- Solaris 9/10
- SunOS 4
- VM
- Windows 2000, Windows Server 2003, Windows XP
- Windows Server 2008, Windows Server 2012, Windows Server 2016
Although we can identify Windows 2000/Windows Server 2003/Windows XP, they all use the same basic TCP/IP stack, and we cannot reliably distinguish between them. The OS detection does the best it can using the server banner, but for people running web servers other than IIS, Windows Server 2003 may be reported when it is actually Windows 2000 or XP in use.
In the same way, Windows Server 2008/2012/2016 all have similar TCP/IP characteristics, so these are currently reported as Windows Server 2008.
The 'uptime' as presented in these reports is the "time since last reboot" of the front end computer or computers that are hosting a site. We can detect this by looking at the data that we record when we sample a site. We can detect how long the responding computer(s) hosting a web site has been running, and by recording these samples over a long period of time we can plot graphs that show this as a line. Note that this is not the same as the availability of a site.
We do NOT currently monitor 'availability'. The 'availability' of a web site is its ability to serve requests. This can be affected by several factors outside the control of site, such as the routing and network performance.
Whilst being related to the uptime it is not a direct relationship, since a site may actually be served by more than one computer at once, balancing the load of requests coming from the users of the network over a 'farm' or group of computers. If one of the computers is rebooted it is not available to serve requests during its reboot phase. When this is happening the other computers in the 'server farm' are handling the requests. So, as far as the users of the site are concerned, the site still has full availability.
This 'server farm' approach is used by many of the largest profile websites to manage the load, but the most typical approach is to use one computer only. In this single computer case clearly the 'availability' is directly affected by the 'uptime'.
Note that we can only detect the 'front end' machines, i.e the ones serving the home page of the site. If a site uses other 'back end' computers for its own private functions we will be unable to detect them.
Operating systems we can usually work out uptimes for are:
- BSD/OS
- FreeBSD [but not the default configuration in versions 3 to 4.3]
- HP-UX [recent versions]
- IRIX
- Linux on Intel x86 processor, kernel versions 2.1 to 2.5.24
- Linux on ARM, M68k, MIPS, PowerPC, S/390, SH and SPARC processors
- NetApp NetCache
- Solaris 2.6 and later
- Windows 2000
- Windows Server 2003
- Windows XP
- Windows Vista
- Windows Server 2008
- Windows Server 2012
- Windows Server 2016
Operating systems that do not provide uptime information include;
- AIX
- AS/400
- Compaq Tru64
- DG/UX
- Linux before kernel version 2.1
- Linux on Alpha and IA64 processors
- Linux on Intel x86 processor from kernel version 2.5.25 (see below)
- MacOS
- MacOSX
- NT3/Windows 95
- NT4/Windows 98
- NetBSD/OpenBSD
- NetWare
- OS/2
- OS/390
- SCO UNIX
- SunOS 4
- VM
Additionally HP-UX, Linux, NetApp NetCache, Solaris and recent releases of FreeBSD cycle back to zero after 497 days, exactly as if the machine had been rebooted at that precise point. Thus it is not possible to see a HP-UX, Linux or Solaris system with an uptime measurement above 497 days.
The method that Netcraft uses to determine the uptime of a server is bounded by an upper limit of 497 days for some Operating Systems (see above). It is therefore not possible to see uptimes for these systems that go beyond this upper limit. Although we could in theory attempt to compute the true uptime for OS's with this upper limit by monitoring for restarts at the expected time, we prefer not to do this as it can be inaccurate and error prone.
The Linux TCP stack uses the low 32 bits from the system uptime timer, and this timer, in recent kernel releases, runs at 250Hz. This means that the timer value wraps around to 0 after roughly 198 days. Although we could in theory attempt to compute the true uptime for OS's with this upper limit by monitoring for restarts at the expected time, we prefer not to do this as it can be error prone.
We only report uptimes for systems where the operating system's timer runs at 100Hz or less. Because the TCP code only uses the low 32 bits of the timer, if the timer runs at say 1000Hz, the value wraps around every 49.7 days (whereas at 100Hz it wraps after 497 days). As there are large numbers of systems which have a higher uptime than this, it is not possible to report accurate uptimes for these systems.
The Linux kernel switched to a higher internal timer rate at kernel version 2.5.26. Linux 2.4 used a rate of 100Hz. Linux 2.6 used a timer at 1000Hz (some architectures were using 1000Hz before this), until the default was changed back to 250Hz in May 2006.
FreeBSD versions 4 and 5 used a 100Hz timer, but FreeBSD 6 has moved to a customisable timer with a default setting of 1000Hz.
So unfortunately this means that we cannot give reliable uptime figures for many Linux and FreeBSD servers.
Webservers that operate behind a caching system, load balancer, reverse proxy server or a firewall may sometimes report the operating system of the intermediate machine. Hence reports of 'Microsoft/IIS on Linux' may indicate that either the web server is behind a Linux server that is acting as a reverse proxy, or has configured the Akamai caching system such that the first request to the site goes to one of Akamai's servers [which run Linux], or as in the case of www.walmart.com has been configured to send a misleading signature.
We only provide data for servers working on port 80 (http). This is to prevent the uptime service being used for port scanning via Netcraft's web server.
On some regularly monitored sites, reported uptimes may differ significantly from day to day, and the reported operating system and web server may seem to continually change. In these cases the site in question most likely has multiple machines in its pool operating on different Web servers and operating systems. Requests are typically farmed out to the machines by a server load balancing device that hands the TCP requests onto machines in the server pool.
Initially a small set of sites were surveyed, but we are now increasing this set. Any site that is requested through the what's that site running query form at Netcraft.com will be automatically added to the set of sites that are routinely sampled. If you have already done this you do not need to e-mail us. Once we have collected sufficient daily samples, we will be able to plot an uptime graph for the site.
Once we have monitored the host for sufficient time to plot a graph, we will only continue to monitor the host if it is again requested through the site. We cannot routinely monitor all 22 million hosts that we know of for performance reasons.
Each site that is in the set of sites to be monitored is queried only once a day. We only do this once, and if the site is unavailable at the time we do it then it will not have a sample recorded that day.
The 'query now' link can be used to perform a query of the site immediately. This will not update the uptime values, just the OS, Server and Netblock information.
For individual sites we take all of the samples within the time window (default 90 days) that provide a reliable uptime figure and sum them, and divide the sum by the number of samples, giving the arithmetic mean. Samples that do not provide an uptime figure, such as those from NT4, are ignored and play no part in the average calculation.
For hosting locations we take all of the calculated averages of the sites within the assigned hosting company netblock, sum them and take an average. Individual sites that do not provide an average figure are not considered when calculating the hosting location average.
We collect information from several sources,
We then look up the IP address of the site in our database to get the netblocks. We can also map together netblocks. In some cases, where there has been further delegation, we may not be providing the more detailed information that may be available. We are working to improve this functionality.
First you need to ensure that the appropriate NIC entry for your IP address is correct. Follow the links above and navigate to the 'whois' server, and enter your IP address. If your IP address is in a block that has been further delegated we do not currently support a further level of lookup. We are working to improve the depth of coverage of our information in this area.
If the entry is correct and we are not displaying it correctly, please let us know.
The graphs for each site display both the actual times since last reboot (as an X) and a moving average of uptime over time as a solid green area graph. The colour of the X changes in the event of the site switching operating system. A history of the operating system, web server and hosting location is also provided so it is possible to correlate these changes with the uptime of the site. When we are unable to get a valid uptime measurement for a site, a gap will appear in the plots of the raw data points.
Queries are made on a daily basis, so the crosses on single server site will appear as a diagonal line moving forward through time until the next reboot. Sites using multiple front end servers with some form of load balancer will show parallel diagonal lines.
Daily reports are generated showing the sites and hosting locations with the longest uptimes.
Example Site 1 - www.demon.net
Uptime for www.demon.net
- Explanation
- The chart shows the time since May 2001 when we first started monitoring www.demon.net through to May 2009. Each vertical line on the X axis represents several months. Each small 'x' on the chart represents a reading on a particular day. In the first months we can see several blue lines representing the servers servicing the site. Over the years we can see the updates to Solaris being applied.
The current versions of this graph can be seen by querying the site
If you still don't see a reasonable explanation for the data you are looking at, please tell us.
We can update you with the most recent survey results and news of other developments at Netcraft. Details are here.