Anda di halaman 1dari 13

A web server is a piece of software that enables a website to be viewed using HTTP.

HTTP (HyperText Transfer Protocol) is the key protocol for the transfer of data on the web. You know when you're using HTTP because the website URL begins with "http://" (for example, "http://www.quackit.com"). You might be thinking "I always thought a web server was a special, high-powered computer". Well, you'd be right too. Some high-powered computers are referred to as web servers as they have been built with web hosting in mind. But in most cases, when someone refers to a web server, they are referring to a piece of software that you install on a computer.

What Does a Web Server Look Like?


That depends on which web server you choose to install. Here's an example of Microsoft Internet Information Services (IIS) 5.1 looks like:

The left pane represents the various websites, FTP sites, and SMTP virtual servers. When an item in the left pane is selected, the contents are displayed in pane on the right hand side. In the above screenshot, there is one website (called "Default Web Site"), one FTP site (called "Default FTP Site"), and one SMTP virtual server (called "Default SMTP Virtual Server"). You can right click on an item to display it's properties. For example, you can right click on "Default Web Site" to display (and configure) the properties of that website.

Do I Need A Web Server?

If you maintain your own web site I recommend you install a web server on your own development machine. That way you can configure your development environment to be closer to your live environment. Also, if you intend to use server-side technologies such as PHP or ColdFusion, you will definitely need a web server.

Web Servers are Easy!


You might also be thinking that web servers are way too advanced for you - that they are only used by professional web developers and/or hosting companies. Please don't think that! Think of a web server as simply another piece of software you can install on your machine. Once you install it, you can configure it to suit your needs. And, depending on your computer set up, you may even find that you already have a web server on your machine. Now, having declared that "web servers are easy!", there are many advanced topics regarding web servers. I won't be going into any detail in this tutorial. You can get a web server up and running on your machine with a minimum of technical knowledge. Then once you've done that, you'll start to become familiar with the various options available to you. Then if required, you can research the more advanced topics to suit your needs (such as security, load issues, logging etc)

Web Servers - Advantages


There are many advantages to using a web server within your development environment. Of course, in a production hosting environment, a web server is essential. And, depending on your website, a web server could indeed be essential in your development environment. When I say "development environment", I'm referring to a copy of your website, usually on your local machine, that you use to perform updates before you commit them to the live (production) environment. In practice, you could have many copies of your website for different purposes (such as testing, training, protypes etc), but let's just call it "development environment" for now. Here are some advantages of using a web server within your development environment:

Your local website behaves more like the live one. For example, you can configure directory security, test your custom error pages etc before commiting them to the production environment. You can use server-side scripting languages such as PHP and ColdFusion. Allows you to standardize your coding. For example, you can use root-relative paths for your image references and hyperlinks (i.e. "/directory/image.gif"). In other words, your paths can represent the website structure, rather than the directory structure of your computer. Knowledge. The knowledge you gain from using your own web server will help you understand how it works in the live environment. This will most certainly help you when you need to communicate with your hosting provider - you'll be able to use terminology that makes it easier for them to understand your request/issue.

Viewing HTML Files Without a Web Server


When someone learns how to code HTML, chances are, one of the first things they learn to do is how to view their (newly created) HTML file. They will learn that you can simply double click on the HTML file, and this will launch it in their web browser. And from that point on, they can view their web page/website as it was intended to be viewed. Here are some examples of what the URL could look like when viewing a web page without a web server:

file:///C:/Documents%20and%20Settings/Homer%20Simpson/My%20Documents/index.html file:///C:/Inetpub/wwwroot/index.html

These examples are using the file protocol in order to display the files.

Viewing HTML Files With a Web Server


One problem with the above method is that, you're not viewing the website using the HTTP protocol (you're using the file protocol instead). Now, this isn't normally a problem if you're only using client side languages such as HTML, CSS, and clientside JavaScript. But it is a problem if you're trying to use a server-side language such as PHP, ColdFusion etc. Also, even if you're not using a server-side language, it could still cause you problems with developing a website that behaves exactly how it should on the web. When you view a web page via a web server, the URL begins with "http://". Also, the URL will consist of either an IP address or a domain name/host name. Here are some examples of what the URL could look like when viewing a web page via a web server:

http://127.0.0.1 http://localhost http://www.quackit.com http://dev.quackit.com

When you first set up a web server, you can usually navigate to your default web site using http://localhost or http://127.0.0.1. When you add more websites, you'll need to create your own URLs for them (via a DNS server or Hosts file), then assign that URL to your websites via your web server.

Web Servers - Features


There's a common set of features that you'll find on most web servers. Because web servers are built specifically to host websites, their features are typically focussed around setting up and maintaining a website's hosting environment. Most web servers have features that allow you to do the following:

Create one or more websites. (No I don't mean build a set of web pages. What I mean is, set up the website in the web server, so that the website can be viewed via HTTP) Configure log file settings, including where the log files are saved, what data to include on the log files etc. (Log files can be used to analyse traffic etc) Configure website/directory security. For example, which user accounts are/aren't allowed to view the website, which IP addresses are/aren't allowed to view the website etc. Create an FTP site. An FTP site allows users to transfer files to and from the site. Create virtual directories, and map them to physical directories Configure/nominate custom error pages. This allows you to build and display user friendly error messages on your website. For example, you can specify which page is displayed when a user tries to access a page that doesn't exist (i.e. a "404 error"). Specify default documents. Default documents are those that are displayed when no file name is specified. For example, if you open "http://localhost", which file should be displayed? This is typically "index.html" or similar but it doesn't need to be. You could nominate "index.cfm" if your website is using ColdFusion. You could also nominate a 2nd choice (in case there is no index.cfm file), and a 3rd choice, and so on.

Example Web Server


Here's an example of the "Properties" dialog box from Microsoft IIS. This box is displaying the properties for a single website. To display the box, I simply right-clicked on the website and selected "Properties". You can see that the website has been configured to use the local path of c:\inetpub\wwwroot. What this means is that when you update your website, you need to place your files and folders within that directory. As soon as you do that, your changes will take effect on your website. Of course, if this is your development environment, you can simply edit the files straight from that directory.

How Web Servers Work


Whenever you view a web page on the internet, you are requesting that page from a web server. When you type a URL into your browser (for example, "http://www.quackit.com/html/tutorial/index.cfm"), your browser requests the page from the web server and the web server sends the page back:

The above diagram is a simplistic version of what occurs. Here's a more detailed version: 1. Your web browser first needs to know which IP address the website "www.quackit.com" resolves to. If it doesn't already have this information stored in it's cache, it requests the information from one or more DNS servers (via the internet). The DNS server tells the browser which IP address the website is located at. Note that the IP address was assigned when the website was first created on 2. 3. 4. the web server. Now that the web browser knows which IP address the website is located at, it can request the full URL from the web server. The web server responds by sending back the requested page. If the page doesn't exist (or another error occurs), it will send back the appropriate error message. Your web browser receives the page and renders it as required.

When referring to web browsers and web servers in this manner, we usually refer to them as a client (web browser) and a server (web server).

Multiple Websites
A web server can (and usually does) contain more than one website. In fact, many hosting companies host hundreds, or even thousands of websites on a single web server. Each website is usually assigned a unique IP address which distinguishes it from other websites on the same machine. This IP address is also what the DNS server uses to resolve the domain name. It is also possible to configure multiple websites without using different IP addresses using host headers and/or different ports. This can be useful in a development environment and is quite easy to do.

Page Not Found


If the requested page isn't found, the web server sends the appropriate error code/message back to the client.

You can create user friendly error messages, then configure your web server to display that page instead of the usual error page. This can add a nice touch to your website. How many times have you (or even worse, your visitors) encountered a plain white page with some cryptic error message on it? It's very easy to create custom error pages, then configure your web server to use them.

Default Documents
If you've ever created a website, you may have found that if you have an "index" file (index.html for example), you don't need to specify the name of the file. For example, the following URLs both load the same page: 1. 2. http://www.quackit.com/html/tutorial http://www.quackit.com/html/tutorial/index.cfm

In this example, "index.cfm" is the default document. You can configure your web server so that any file name can be the default document. For example, you could configure your web server to use "index.cfm" in the event no filename has been specified, or if you use PHP, "index.php". You could even specify different default documents for different directories if you like.

SSL Certificates
You can apply SSL certificates against a website via the web server. First you need to generate the certificate either by yourself (i.e. using a certificate generator), or by a Certificate Authority (CA). Then, once it has been generated, you apply it to your website via your web server. Applying an SSL certificate to a website is a straight forward task. Once you've applied an SSL certificate against a website, you can navigate it using HTTPS (as opposed to HTTP). HTTPS encrypts any data that is transferred over the internet. This reduces the possibility of some malicious person being able to read your users' sensitive information. To navigate a website using HTTPS, you simply replace the HTTP with HTTPS at the start of the URL in your browsers' location bar ("https://www.quackit.com")

<< Previous Next Lesson >>

Web Servers - Examples


This page contains information about three of the most popular web servers on the web.

Apache HTTP Server


Apache HTTP Server (also referred to as simply "Apache") has, at the time of writing, been the most popular web server on the web since 1996. Apache is developed and maintained by the Apache Software Foundation, which consists of a decentralized team of developers. The software is produced under the Apache licence, which makes it free and open source.

Apache is available for a range of operating systems, including Unix, Linux, Novell Netware, Windows, Mac OS X, Solaris, and FreeBSD. Apache HTTP Server website: http://httpd.apache.org

Microsoft Internet Information Services (IIS)


IIS is, at the time of writing, the second most popular web server on the web. It is however, gaining market share, and if the current trend continues, it won't be long before it overtakes Apache. IIS comes as an optional component of most Windows operating systems. You can install IIS by using Add/Remove Windows Components from Add or Remove Programs in the Control Panel. Microsoft IIS website: http://www.microsoft.com/iis

Sun Java System Web Server


Based on the Sun One Web Server, the Sun Java System Web Server is designed for medium to large business applications. Sun Java System Web Server is available for most operating systems. Sun Java System Web Server website: http://www.sun.com/software/products/web_srvr/home_web_srvr.xml

Web server tutorial - Part 1


Mon, 06/04/2001 - 08:40 | admin

Email: content@vansinfo.com Basically for communication where there is a client-server flavor, the server process creates a socket and the client socket accesses the server through client socket techniques. Socket A socket is fundamentally nothing but an end point of communication. It can be of two types: Physical socket and Logical socket. In Logical socket operating system has its system calls, which creates them. Now for client-server access the socket needs three things to provide service or ask for service. 1) Service name (example: telnet) 2) Protocol (TCP-stream) 3) Port no (23) The service uses protocol and protocol uses port number to provide service at server end and to get service at client end. Ultimately we find that the port number is mainly responsible for a client server communication. The protocols supported by Linux is shown by /etc/protocols and the services can be seen in /etc/services. Let's take few more examples then start with Web server. * telnet service uses TCP/IP protocol and communicate through port no. 23 * ftp service uses TCP/IP protocol and communicate through 20,21 port numbers * www service uses http protocol and communicate through port no 80. Web communication Web communication deals with a browser type of client process and Web server type of server process. What actually happens when a user writes http://www.yahoo.com? Well, the browser transfers the URL to current machine's operating system with a destination address' operating system, which is responsible for extracting protocol i.e. "http" from the client socket (browsers) and then it packets data using layer software and over the packet it attaches the header http. This enables the remote machine to hand over the request to Web server of remote machine. Why so? Because there can be many a server running on the same machine so the particular services are distinguished by their protocol. But how should we explain when telnet and ftp both are using same protocol but have different server Processes? The answer is that they are distinguished by their port numbers. Services may have same protocol but not the same port number. After this the operating system throws the data to network interface card through the ram and then network interface card gives it to nearest gateway, which sends the data to the server machine at server end.

Web server tutorial - Part 1


Mon, 06/04/2001 - 08:40 | admin

Email: content@vansinfo.com The network card gives a signal back to operating system that a data enclosed with http header using TCP/IP header has arrived. One's operating system checks that data has http wrapper and searches for Web server on that machine. When it finds, it hands over the data and pays attention to other processes. Before the Web server processes the data, it goes through a filtration by the gateway process implemented on the Web server, which actually filters the raw data. This concept implemented is called as common

gateway interface that has the Web server environment variables, which stores the data in different variable. When the user asks for some unnecessary data, headers also get attached with data and so the need for filtration. Apache as Web server Setup: The Web server is meant for keeping Websites. There are three ways a Website can be stored. They are: 1) default directory hosting 2) virtual directory hosting 3) virtual domain hosting We have to first configure the DNS. Then configure the following file (redhat 6.2) /etc/httpd/conf/httpd.conf If we use Apache as a Web server whether on Windows platform or Linux, the main file which is used is called /etc/httpd/conf/httpd.conf The root directory of Web server is /etc/httpd, which is divided into three parts: 1) /etc/httpd/conf (where configuration files stays) 2) /etc/httpd/logs (where the logs of Web server and site accessing stay) 3) /etc/httpd/modules (where the module stays, which enables the server side programmer to do programming in the languages supported by Web server) Lets open the file /etc/httpd/conf/httpd.conf and take a detailed look at the macros to be used. httpd.conf-Apache HTTP server configuration file (Based upon the NCSA server configuration files originally by Rob McCool.) This is the main Apache server configuration file. It contains the configuration directives that give the server its instructions. Note: See http://www.Apache.org/docs for detailed information about the directives. Do not simply read the instructions in here without understanding what they do. They're here as hints or reminders. If you are unsure consult the online docs. After this (httpd.conf) file is processed, the server will look for and process (only in the case of 6.1 the following mentioned file is checked. If it is 6.2 they are not checked): /usr/conf/srm.conf

Web server tutorial - Part 1


Mon, 06/04/2001 - 08:40 | admin

Email: content@vansinfo.com and then /usr/conf/access.conf unless you have overridden these with ResourceConfig and/or AccessConfig directives here. Directives The configuration directives are grouped into three basic sections: 1. Directives that control the operation of the Apache server process as a whole (the 'global environment').

2. Directives that define the parameters of the `main' or `default' server, which responds to requests that aren't handled by a virtual host. These directives also provide default values for the settings of all virtual hosts. 3. Settings for virtual hosts, which allow Web requests to be sent to different IP addresses or hostnames and have them handled by the same Apache server process. Section 1: Global Environment The directives in this section affect the overall operation of Apache, such as the number of concurrent requests it can handle or where it can find its configuration files. ServerType: ServerType is either inetd, or standalone. Inetd mode is only supported on Unix platforms. ServerRoot: The top of the directory tree under which the server's configuration, error, and log files are kept. NOTE: If you intend to place this on an NFS (or otherwise network) mounted filesystem then please read the LockFile documentation (available at http://www.Apache.org/docs/mod/core.htmllockfile); You will save yourself a lot of trouble. Do not add a slash at the end of the directory path. ServerRoot "/etc/httpd" LockFile: The LockFile directive sets the path to the lockfile used when Apache is compiled with either USE_FCNTL_SERIALIZED_ACCEPT or USE_FLOCK_SERIALIZED_ACCEPT. This directive should normally be left at its default value. The main reason for changing it is if the logs directory is NFS mounted, since the lockfile must be stored on a local disk. The PID of the main server process is automatically appended to the filename. LockFile /var/lock/httpd.lock PidFile: The file in which the server should record its process identification number when it starts. PidFile /var/run/httpd.pid

Web server tutorial - Part 1


Mon, 06/04/2001 - 08:40 | admin

Email: content@vansinfo.com ScoreBoardFile: File used to store internal server process information. Not all architectures require this. But if yours does (you'll know because this file will be created when you run Apache) then you must ensure that no two invocations of Apache share the same scoreboard file. ScoreBoardFile /var/run/httpd.scoreboard In the standard configuration, the server will process this file, srm.conf, and access.conf in that order. The latter two files are now distributed empty, as it is recommended that all directives be kept in a single file for simplicity. The commented-out values below are the built-in defaults. You can have the server ignore these files altogether by using "/dev/null" (for Unix) or "nul" (for Win32) for the arguments to the directives. ResourceConfig conf/srm.conf AccessConfig conf/access.conf Timeout: The number of seconds before receives and sends time out. Timeout 300 KeepAlive: Whether or not to allow persistent connections (more than one request per connection). Set to "Off" to deactivate. But we keep it :

KeepAlive On MaxKeepAliveRequests: The maximum number of requests to be allowed during a persistent connection. Set to 0 to allow an unlimited amount. We recommend you leave this number high, for maximum performance. MaxKeepAliveRequests 100 KeepAliveTimeout: Number of seconds to wait for the next request from the same client on the same connection. KeepAliveTimeout 15 Server-pool size regulation: Rather than making you guess how many server processes you need, Apache dynamically adapts to the load it sees --- that is, it tries to maintain enough server processes to handle the current load, plus a few spare servers to handle transient load spikes (e.g, multiple simultaneous requests from a single Netscape browser). It does this by periodically checking how many servers are waiting for a request. If there are fewer than MinSpareServers, it creates a new spare. If there are more than MaxSpareServers, some of the spares die off. The default values are probably OK for most sites. MinSpareServers 5 MaxSpareServers 20 Number of servers to start initially should be a reasonable ballpark figure. StartServers 8

Web server tutorial - Part 1


Mon, 06/04/2001 - 08:40 | admin

Email: content@vansinfo.com Limit on total number of servers running: Limit on the number of clients who can simultaneously connect. If this limit is ever reached, clients will be `locked out', so it should not be set too low. It is intended, mainly, as a brake to keep a runaway server from taking the system with it as it spirals down. MaxClients 150 MaxRequestsPerChild: The number of requests each child process is allowed to process before the child dies. The child will exit so as to avoid problems after prolonged use when Apache (and maybe the libraries it uses) leak memory or other resources. On most systems, this isn't really needed, but a few (such as Solaris) do have notable leaks in the libraries. For these platforms, set to something like 10000 or so; a setting of 0 means unlimited. NOTE: This value does not include keepalive requests after the initial request per connection. For example, if a child process handles an initial request and 10 subsequent "keptalive" requests, it would only count as 1 request towards this limit. MaxRequestsPerChild 100 Listen: Allows you to bind Apache to specific IP addresses and/or ports, in addition to the default. See also the directive. Listen 3000 Listen 12.34.56.78:80 BindAddress: You can support virtual hosts with this option. This directive is used to tell the server which IP address to listen to. It can either contain "*", an IP address, or a fully qualified Internet domain name. BindAddress *

Well that's all for now. In the second part we shall look into Dynamic Shared Object (DSO) Support and also 'Main' server configuration.

Anda mungkin juga menyukai