|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
WEB Servers
Windows XP Professional contains Internet Information Services (IIS)
version 5.1. IIS 5.1 includes Web and FTP server support, as well as support for
Microsoft FrontPage transactions, Active Server Pages, and database connections.
Available as an optional component, IIS 5.1 is installed automatically if you upgrade
from versions of Windows with PWS installed.
PWS 4.0 is included with the Microsoft Windows NT 4.0 Option Pack and was designed
for Microsoft Windows 95 and Microsoft Windows NT Workstation 4.0 with Microsoft
Internet Explorer 4.01 or later. PWS is not supported and cannot be installed on
any version of Windows XP.
NOTE: Microsoft FrontPage 2002 can use disk-based Web pages in Windows XP Home Edition
as an alternative.
Notes:
- Those pages are written by people for whom English is not a
native language. Some amount of grammar and spelling errors
should be expected.
- This is a Spartan WHYFF (We Help You For Free) site. It
cannot replace the best teachers and
the
best books.
- The site contain some obsolete pages as it develops like a
living tree... Some links on older pages
are broken. Please
try to use Google, Open directory, etc. to find a replacement link
(see
HOWTO search the WEB for details).
We would appreciate if you can
mail us a correct link.
|
|
About: httping is a "ping"-like tool for HTTP requests. Give it a
URL and it will show how long it takes to connect, send a request, and retrieve
the reply (only the headers). It can be used for monitoring or statistical purposes
(measuring latency).
Changes: Binding to an adapter did not work and "SIGPIPE" was not
handled correctly. Both of these problems were fixed.
About: nginx is an HTTP server and mail proxy server. It has been
running for more than two years on many heavily loaded Russian sites, including
Rambler (RamblerMedia.com). In March 2007, about 20% of all Russian virtual
hosts were served or proxied by nginx.
Changes: The STARTTLS in SMTP mode is now working. In HTTPS mode,
some requests fail with a "bad write retry" error. The "If-Range" request header
line is now supported. uname(2) is now used on Linux systems instead of procfs.
Until now FastCGI was behind mod_php, java and mod_perl in
terms of popularity among web server administrators and web developers. But
times have changed and changed for good.
In the early days of web development when the CGI interface was the leader and
web servers were quite slow, developers felt that they needed a faster server
technology, that can be used to run their web applications on high-traffic web
sites. The solution to the problem seemed obvious – the developers had to take
their CGI-based code and put it into the web server process.
With this solution, the operating system didn’t have to start a new process
every time a request had been received, which is very expensive, and you could
write your application with a persistent functionality in mind and ability to
cache data between several different http requests.
These were the days when some of the most popular web server APIs were born
– Internet Information Server’s ISAPI, Netscape Server’s NSAPI, and Apache’s
module API. This trend created some of the best known and quite often used technologies
in web development like mod_php, mod_python, java servlets (and later jsp),
asp. But the conception that stays behind these technologies is not flawless.
There are many problems with applications that run inside your average web server.
For example mod_perl’s high memory usage per child process can suck the available
ram, php’s problems with threads can kill the whole web server, and many security
problems arising from the fact that the most popular web server (Apache) can’t
do simple things like changing the OS user it executes the request with. For
quite some time there have been solutions, like putting a light-weight proxy
server in front of apache, installing third-parity software for IIS or using
php’s safe mode and OpenBasedir (Oh GOD!) on apache, but these are not elegant
and pose other problems on their own. Also the hardware progress in the last
few years made the server modules obsolete.
In the mean time, when the server modules were gaining glory and fame, a little-known
technology with a different conception and implementation was born. It was called
FastCGI and the basic problem it was designed to solve was to make CGI programs
run faster. Later, it became clear that FastCGI solves many other problems and
design flaws that the server modules had.
How FastCGI works?
FastCGI runs in the web server process, but doesn’t handle the request itself.
Instead it manages a pool of the so-called FastCGI servers outside of the web
server process and when a request arrives, the FastCGI manager sends the http
data through a socket to one of the available fastcgi servers to handle this
request. This strategy is quite simple and has the following advantages:
- The FastCGI servers can be written in any language that has an api to
communicate through sockets
- The FastCGI servers run outside of the web server thus improving stability
and allowing the web server to handle only requests for static data with
very little overhead. You won’t need a front-end proxy for this. Thread-unsafe
applications can be run with
threaded web servers.
- The FastCGI manager can change the owner of the FastCGI servers, which
allows the web administrator to have different virtual hosts served by different
OS users. (Anyone remember Apache2’s
perchild MPM?)
- The FastCGI servers are persistent processes, which serve requests many
times faster than standard CGIs.
In the beginning FastCGI was not so popular, because
its use of external processes and communication through sockets required more
resources to be allocated on the host system. Today this is not the case, because
for the last few years the hardware development made huge leaps ahead and system
memory is not so expensive anymore. In present days many of the
web servers have full support for FastCGI and the trend is to migrate the current
web applications to run under it. These are some of the most popular web servers
that have support for FastCGI:
In November Microsoft announced support for FastCGI on IIS 5, IIS 6 and IIS
7 (Beta).
Click
here to read the announcement.
Recently I needed a test-bed for scripts that generate HTML, and file access
didn't suffice. As usually, the first attempt at awk-ing the request
from a socket(1) executed script soon grew big and ugly with ever more
special cases being added. As the need to support ISINDEX and FORMs came up,
I re-wrote the whole thing in perl. Now the simple test aid has become
a program that can be used in similar situations when you need an HTTP server
quickly without worrying to install a CERN or NCSA server.
This one does not have all the features needed; in particular, it knows only
about text, HTML and GIF files and the support for CGI scripts is limited (just
enough to check if they work and produce correct output). It supports only HTTP
1.0 and only GET and POST requests.
|
(Aug 5, 2001, 18:00 UTC) (742 reads) (0 talkbacks) (Posted
by mhall)
Dialup connections can be frustrating.
Squid, a very popular piece of 'net caching software does a lot to cut bandwidth
demands, but it isn't built for dialups. This article shows how to change
that.
|
Apache Today - Web Servers of the Fortune 500 A Dissection and Analysis IIS
if the king of large company Webserver farms with iPlanet is a distant second.
I was minding my own business, checking my snail
mail at the office, when all of a sudden I was assaulted: "IIS Most Used Web
Server Among Fortune 500 Sites" slapped me upside the head like a two-liter
shot of Mountain Dew. For those of you who haven't read the cover story of Volume
5 Number 10 of ENT or seen
the
article on their website--go do that first, and then come back.
After recovering from what I though must have
been wrong, biased marketing research, I set out to prove ENT wrong
Results
I set about this study with a mission: To objectively
collect data on the "brochure sites" of the Fortune 500. My secondary objective,
of course, was to disprove the ENT study. My results were almost identical
to theirs, however. If you look at the entire Fortune 500, from
General Motors all the way
to ReliaStar Financial,
IIS reigns king. If you, however, look at subsets of the Fortune 500 and the
types of companies represented, the picture is much different. Netscape Enterprise
Server dominates until the Fortune 300 is looked at as an aggragate, where both
Netscape and Microsoft share 41 percent of the market. This information
was embedded in the ENT article as well.
Some Apache-related news
The C10K problem -- very
interesting info on various servers performance issues
Web Servers Feature Chart contains an interesting table on features of virtually
all the Web Server software packages.
Netcraft's Web Server
Survey shows the market share of different Web Server software on Internet connected
computers.
In case of broken links
please try to use Google search. If you find the page please notify
us about new location
W3C Open Source
Releases
Tutorials
Serving Up Web
Server Basics
Perl, Sockets
and TCP-IP Networking.
Network
Programming in Perl - a well-written introduction to network programming with
practical examples.
The documentation of the Socket and IO::Socket modules
that comes with your perl distribution should be a valuable reference.
filehandle
multiplexing with select() describe a method to manage multiple sockets
on the same thread.
HTTPDaemon
- a simple http server class
Table of Contents
Plexus HTTP -- Perl-based server
TinyHTTPD
Recently I needed a test-bed for scripts that generate HTML, and file access
didn't suffice. As usually, the first attempt at awk-ing the request
from a socket(1) executed script soon grew big and ugly with ever more
special cases being added. As the need to support ISINDEX and FORMs came up,
I re-wrote the whole thing in perl. Now the simple test aid has become
a program that can be used in similar situations when you need an HTTP server
quickly without worrying to install a CERN or NCSA server.
This one does not have all the features needed; in particular, it knows only
about text, HTML and GIF files and the support for CGI scripts is limited (just
enough to check if they work and produce correct output). It supports only HTTP
1.0 and only GET and POST requests.
New
Architect Make the Simple Things Simple
An HTTP server (a Web server) is an application that "listens"
for connection requests from client processes (usually on other machines). Upon
receiving a request, the server creates a new connection for the client, and
then goes back to listening for other requests. This new connection is created
in its own process on the server because the act of waiting for a connection
is usually a "blocking" action during which no other processing can take place.
As I'll show you later, there are some obstacles and detours when building such
an application with Win32 Perl.
A lot of the pain in writing an HTTP server can be eased by
using the libwww-perl library for Perl. For those of you who have used it before,
Listing 1 may look a little odd. I'm actually using the new LWPng module,
which supports many HTTP 1.1 features, including persistent connections (see
the sidebar titled "
Using LWPng").
A persistent connection maintains an open communication channel
between the client and server until one side or the other forces the connection
to be closed. Using such a connection, it's possible to create a Win32 server
process that can fork and maintain communications with the client.
Then we can establish several clients talking to the same server, each one in
a conversational loop.
The scenario plays out like this: An HTTP daemon (we'll use
the HTTP::Daemon module) is set up to listen for connection requests on a specified
port. Clients (such as LWP::UA) contacting the server know they can expect to
find an HTTP daemon listening at this socket, so they send a valid HTTP request
(LWP::Request). The server binds the local and remote sockets to form a connection
(HTTP::Daemon::ClientConn). Once the connection is established, bidirectional
communication can take place. At this point, the server can close the connection,
or start a new process on the server to handle communication with the client.
This is the moment of truth—the server needs to do three things
to successfully hand off the client to another process:
- Create the new process
- Transfer the open connection to the new process
- Let the new process access the parent process "environment"
The fork command in UNIX is used to start a new
process. It does this by creating a child process that is a clone of the calling,
or parent, process. The new process not only shares the open connections, but
the same data space, call stack, and memory heap as well. Both the parent and
child processes continue executing the code that follows the fork
command. If we want the child process to take on a new identity, we can call
exec, which replaces the running process with a new program, usually
pulled from a disk file.
Win32 programmers have a rougher go at it, because the Win32
process model differs greatly from UNIX. First, Win32 has no concept of "parent"
or "child" processes. One process can create another, but they are essentially
peers. The Win32 architecture doesn't allow the creation of a new process that
shares the environment of another process. For example, each new process in
Win32 maintains its own instances of referenced DLLs. The Win32 API call
CreateProcess essentially combines the fork and
exec functions of UNIX into a single action called a spawn.
(For more information about Win32 processes in a Perl context, see Win32 Perl
Programming: The Standard Extensions by Dave Roth.)
However, the usefulness of the fork hasn't been
lost on the Win32 crowd, and there are emulations available for those who want
to compile Perl using Cygwin32, or wait for ActiveState's next major release
of its Win32 Perl implementation. It should be noted that these solutions are
emulations of a core UNIX function that is simply not supported at the operating
system level. The implementation-specific solution I came up with is just that—specific
to a Perl HTTP::Daemon in Win32. With the disclaimers out of the way, let's
look at the code.
|
(Aug 5, 2001, 18:00 UTC) (742 reads) (0 talkbacks) (Posted
by mhall)
Dialup connections can be frustrating.
Squid, a very popular piece of 'net caching software does a lot to cut bandwidth
demands, but it isn't built for dialups. This article shows how to change
that.
|
|
Web Caching Documentation |
| In an effort to make users (web publishers)
more aware of the issues and benefits of designing for Web caches, instead
of trying to circumvent them, there is now a document that explains the
why, what and how of caching in (hopefully) easy-to-understand language.
It's particularly important to get this document to an audience of high-volume
Web sites and hosting services.
|
|
Mark Nottingham @ 11/19/98
- 11:41 EST |
Copyright © 1996-2008 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with. We do not warrant the correctness
of the information provided or its fitness for any purpose.
Last modified:
July 16, 2008
