How Web Servers Work, Internet Protocols (Tcp/Ip) and Http

HOW WEB SERVERS WORK, INTERNET PROTOCOLS (TCP/IP) AND HTTP

We have learned that PHP web pages are a mixture of plain text, HTML code and PHP script. We also learned that PHP pages are stored as .php files on the server – when a user requests aPHP page, the PHP script contained in the .PHP file is processed on the server before the resulting HTML is sent to the browser.

What we haven't done is discuss the workings of PHP in any detail, or how web servers interpret PHP. We will now gain an understanding of the workings of PHP, by describing three different models. First, we'll look at how information is transmitted between the browser and web server; second, we'll examine how the web server handles web page requests; and third, we will see how the PHPinterpreter on your web server actually handles lines of PHP script code.

We will also look at the two ways at which script can be handled, either on the web server or the browser; and we will explain why PHP script can only be handled on the server. Once we've looked at how PHP works, we will look in greater depth at PHP itself and break it up into its individual objects. So we will be explaining the following:

• How do web servers work? What do they do?
• What is a web application?
• What is a request? What is a response? And how do they relate to the roles of the browser and web server?
• What's the difference between server-side scripting and client-side scripting?
• What other methods, apart from PHP, can be used to generate dynamic web pages?

How the Web Server Works

A web server is a piece of software running on a computer that distributes web pages to users on demand, and provides an area in which to store and organize the pages of a web site. The machine that runs the web server software could be a remote machine sitting at the other side of your network, or even on the other side of the world, or it could be your very own home machine. The user's browser is the client in this relationship, and we have seen how PHP fits into this 'client–server' relationship.

These days, the term client–server is probably overused; but in fact, when used to describe the workings of the web, it's almost perfect. In a nutshell, the client–server relationship describes the distribution of tasks between a server (which stores, processes and distributes data, like an ATM or cashpointmachine) and the clients that access the server (like customers queuing to get their money out), in order to achieve universal access for the network on which they are connected.

The client–server scenario is also commonly known as a two-tiersystem. More generally, application architecture has talked in terms of n-tiersystems, where n refers to the number of layers in the system. In the client–server scenario, there are two layers. Later, we'll introduce a third layer – the databaselayer – and we'll start to think in terms of three-tier examples. But for now, let us expand on the two-tier or client–server system, as it relates to web pages.

How the Web Server and Browser Communicate

We have discussed an over-simplified picture of the communication between web server and browser. In particular, we side-stepped any explanation of the physical processes involved in the transfer of information across the Internet. We now will look at the topic in more depth. We'll look at the physical workings of the Internet and intranet networks.

Internet Protocols

The Internet is a network of interconnected nodes, in the same way that the underground system of a large city is a network of interconnected railway stations. The underground system is designed to carry people from one place to another; by comparison, the Internet is designed to carry information from one place to another.

While a underground system is built on a basis of steel (and other materials), the Internet uses a suite of networking protocols (known as TCP/IP) to transfer information around the Internet. A networkingprotocol is simply a method of describing information packets so they can be sent down your telephone, cable, or T1-line from node to node, until it reaches its intended destination.

One advantage of the TCP/IP protocol is that it can reroute information very quickly if a particular node or route is broken or is just plain slow. The perfectly-designed railway system would work in much the same way – taking passengers efficiently by a different route whenever one of the stations or tracks was closed down for repair.

When the user tells the browser to go fetch a web page, the browser parcels up this instruction using a protocol called the TransmissionControlProtocol (or TCP). TCP is a transport protocol, which provides a reliable transmission format for the instruction. It ensures that the entire message is correctly packaged up for transmission (and also that it is correctly unpacked and put back together after it reaches its destination).

Before the parcels of data are sent out across the network, they need to be addressed. Therefore, a second protocol called Hypertext Transfer Protocol (or HTTP) puts an address label on it. HTTP is the protocol used by the World Wide Web in the transfer of information from one machine to another – when you see a URL prefixed with you know that the internet protocol being used is HTTP.

Internet protocols (such as HTTP and FTP) control addressing and delivery, while transport protocols (such as TCP) ensure that each message is broken down, transported and reassembled correctly.

So if the Internet is like a railway system, then a web page request is like a non-stop train journey from A to B. Here, TCP is like the seating system that breaks down a group of passengers and freight into different sections of the train; while HTTP or FTP is like the intended destination instruction that is given to the train driver before the train departs.

The message passed from the browser to the web server is known as an HTTPrequest. When the web server receives this request, it checks its stores to find the appropriate page. If the web server finds the page, it parcels up the HTML contained within (using TCP), addresses these parcels to the browser (using HTTP), and sends them back across the network. If the web server cannot find the requested page, it issues a page containing an error message (in this case, the dreaded Error404: PageNotFound) – and it parcels up and dispatches that page to the browser. The message sent from the web server to the browser is known as the HTTPresponse.

Here is an illustration of the process as we understand it so far.

Going Deeper into HTTP

There's still quite a lot of technical detail missing here, so let's dig further down and look more closely at exactly how HTTP works. When a request for a web page is sent to the server, this request contains more than just the desired URL. There is a lot of extra information that is sent as part of the request. This is also true of the response – the server sends extra information back to the browser.

A lot of the information that is passed within the HTTP message is generated automatically, and the user doesn't have to deal with it directly, so you don't need to worry about transmitting such information yourself. While you don't have to worry about creating this information yourself, you should be aware that this extra information is being passed between machines as part of the HTTP request and HTTP response – because the PHP that we write can allow us to have a direct effect on the exact content of this information.

Every HTTP message assumes the same format (whether it's a client request or a server response). We can break this format down into three sections - the request/response line, the HTTPheader and the HTTPbody. The content of these three sections is dependent on whether the message is an HTTP request or HTTP response – so we'll take these two cases separately.

Let's just pause and illustrate our understanding of the process now:

We can see that the HTTP request and HTTP response have broadly similar structures and that there is information that is common to both, which is sent as part of the HTTP header. There are other pieces of information that can only be known to either the browser or the server, and that are also sent as part of either the request or response. It makes sense to examine their constituent parts in greater detail.

The HTTP Request

The HTTP request is sent by the browser to the web server and it contains the following.

The Request Line

The first line of every HTTP request is the requestline, which itself contains three pieces of information - first, an HTTPcommand known as a method; second, the URL of the file that the client is requesting; third, the versionnumber of HTTP. So, an example request line might look like this:

GET /testpage.htm HTTP/1.1

The method is used to tell the server the amount of information the browser requires, and how much information is being sent. Here are three of the most common methods that might appear in this field:

There are a number of other methods supported by HTTP – including PUT, DELETE, TRACE, CONNECT, OPTIONS. As a rule, you'll find that these are less common; they are beyond the scope of this course. If you want to know more about these, take a look at RFC2068, which you'll find at

The HTTP Header

The next bit of information sent is the header. This contains details of what document types the client will accept back from the server; the type of browser that has requested the page; and the date and general configuration information. The HTTP request's header contains information that falls into three different types:

• General: contains information about either the client or server, but not specific to one or the other
• Entity: contains information about the data being sent between the client and server
• Request: contains information about the client configuration and different types of acceptable documents

An example header might look like this:

ACCEPT:*/*

ACCEPT_LANGUAGE:en-uk

CONNECTION:Keep-Alive

HOST:

REFERER:

USER_AGENT:Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

As you can see, the header is composed of a number of lines. Each line contains the description of a piece of header information, and then its value.

There are a lot of headers, and most of them are optional, so HTTP has to indicate when it has finished transmitting the header information. To do this, a blank line is used.

The HTTP Body

If the POST method was used in the HTTP request line, then the HTTP request body will contain any data that is being sent to the server – for example data that the user typed into an HTML form. Otherwise, the HTTP request body will be empty.

The HTTP Response

The HTTP response is sent by the server back to the client browser, and contains the following.

The Response Line

The response line contains only two bits of information - first, the HTTP version number; and second, an HTTP request code that reports the success or failure of the request. An example response line might look like this:

HTTP/1.0 200 OK

This example returns the HTTPstatuscode200, which represents the message 'OK'. This denotes the success of the request, and that the response contains the required page or data from the server. We previously mentioned the statuscode404 – if the response line contains a 404 then the web server failed to find the requested page. Error code values are three-digit numbers, where the first digit indicates the class of the response. There are five classes of response:

The HTTP Header

The HTTP response header is similar to the request header. In the HTTP response, the header information again falls into three types:

• General: contains information about either the client or server, but not specific to one or the other
• Entity: contains information about the data being sent between the client and the server
• Response: Information about the server sending the response and how it can deal with the response

Once again, the header consists of a number of lines, and uses a blank line to indicate that the header information is complete. Here's a sample of what a header might look like:

HTTP/1.1 200 OK the status line

Date: Mon, 26thJan2011, 16:12:23 GMT the general header

Server: Microsoft-IIS/4.0 the response header

Last-modified: Fri, 19th Dec2010, 12:08:03 GMT the entity header

The first line we have already discussed, the second is self-explanatory. The third line indicates the type of software the web server is running, and as we are requesting a file somewhere on the web server, the last bit of information refers to the last time the page we are requesting was modified.

The header can contain much more information than this, or different information, depending on what exactly is requested. If you want to know more about the different types of information contained in the three parts of the header, you'll find them listed in RFC2068 (Sections4.5, 7.1 and 7.2).

The HTTP Body

If the request was successful, then the HTTP response body contains the HTML code (together with any script that is to be executed by the browser), ready for the browser's interpretation.

A - Introduction to PHP and MySQL - How Web Servers Work, Internet Protocols TCP-IP and HTTP.doc Page 1 of 8 Version 1