Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

Heading

<h1>First Topic</h1>

<h2>Subtopic</h2>

Defines section headings, to allow information in a

long document to be displayed in hierarchical form.

Six sets of tags are defined, from <h1> and </h1> to

<h6> and </h6>. Browsers will automatically display

the “higher-level” headings in more prominent ways,

by using larger fonts, underlining the text, or similar.

List

<p>Shopping list:

<ul>

<li>Milk

<li>Eggs

<li>Sushi

</ul>

</p>

Allows information to be presented as a list. The tag

“<ul>” means “unnumbered list” and causes the list

items to be shown usually as bullet points. Alter-

nately, “<ol>” (“ordered list”) can be used to show the

items preceded by 1, 2, 3 and so on.

Horizontal

Rule

…end of this part of the story.</p>

<p>Start of next part of story…

Draws a horizontal line across the page; the “size”

parameter controls its thickness. Used to separate

logical sections in a document.

Image

<img src=”companylogo.gif”

alt=”XYZ Industries Logo”

align=“center”>

Displays an inline image in the appropriate section of

the text. The “src” parameter is a relative or absolute

URL for the image, and numerous other parameters

can be included to define the image's alignment, size,

“alternate text” to display if the browser is non-

graphical (as shown here with the “alt” parameter)

and much more.

Link

<a href=“http://

www.PCGuide.com”>Click here to

visit The PC Guide</a>

Hyperlinks to another document. The “a” in the tag

stands for “anchor”, which is the formal name for a

hyperlink. the “href” parameter specifies the URL of

the link.

Most browsers will underline or otherwise highlight

the text between the start and end tags to make it

clear that the text represents a hyperlink. It is also

possible to give a hyperlink to an image by combining

the “<img>” and “<a>” tags.

Bookmark

<a name=“Step4”>Step 4: Remove

paint using scrubbing tool.</a>

Creates a bookmark that can be used to hyperlink to

a particular section in a document. For example, if the

bookmark in this example was in a document at URL

“http://www.homefixitup.com/repainting.htm”, the URL

“http://www.homefixitup.com/repainting.htm#Step4”

refers to this particular place in the document. See

the next topic on URLs for more details.

Table 274: Common Hypertext Markup Language (HTML) Elements (Page 2 of 3)

Element Example Element and Tags Description

Common Text Formatting Tags

There are also numerous tags that are used to format the appearance of text within a

document; some of the more common ones:

☯ <b>text</b>: Present the enclosed text in bold.

☯ <i>text</i>: Present the enclosed text in italics.

☯ <u>text</u>: Present the enclosed text underlined.

☯ <font (parameters)>text</font>: Present the enclosed text using the indicated font

type, size or color.

Again, this is just the tip of the iceberg when it comes to HTML. If you are not familiar with

HTML, however, knowing these basic tags should be enough to help you interpret basic

HTML documents and learn how HTTP works.

Tab le

<table>

<tr>

<td>1st row, 1st column.</td>

<td>1st row, 2nd column.</td>

</tr>

<tr>

<td>2nd row, 1st column.</td>

<td>2nd row, 2nd column.</td>

</tr>

</table>

Displays information in tabular form. Each “<tr>” and

“</tr>” tag set defines one row of the table; within

each row, each “<td>” and “</td>” pair defines one

table data element. Many different parameters can be

provided for each of these tags to control table size

and appearance.

Form

<form method="POST"

action="https://

www.myfavesite.com/order.php">

<input type="hidden"

name="PRODUCT"

value="widget">

<input type=”text”

name=”QUANTITY” size="3">

<input type="submit" value="Click

Here to Proceed to the Secure

Processing Site">

</form>

Defines an HTML form, allowing various sorts of infor-

mation to be submitted by a client to a program on a

Web site designed to process forms. The form

consists of the initial “<form>” tag that describes what

action to be taken when the submission button is

pressed, and other form items such as predefined

variables, text entry fields, and buttons; one example

of each of these items is shown here.

Script

(Javascript code)

</script>

Allows instructions in a scripting language to be

included in an HTML document. Most often used for

Javascript.

Table 274: Common Hypertext Markup Language (HTML) Elements (Page 3 of 3)

Element Example Element and Tags Description

Key Concept: The language used by World Wide Web hypertext documents is

called the Hypertext Markup Language (HTML). HTML documents are as ASCII text

files, but are arranged using a special structure of HTML elements that define the

different parts of the document and how they should be displayed to the user. Each element

is described using special text tags that define it and its characteristics.

World Wide Web Addressing: HTTP Uniform Resource Locators (URLs)

The main reason that hypertext is so powerful and useful is that it allows related documents

to be linked together. In the case of the World Wide Web, this is done using a special set of

Hypertext Markup Language (HTML) tags that specifies in one document the name of

another document that is related in some important way. A user can move from one

document to the next using a simple mouse click. The Web has succeeded largely on the

basis of this simple and elegant method of referral.

The notion of hyperlinking has some important implications on how Web documents and

other resources are addressed. Even though the Web is at its heart a message transfer

protocol similar to the File Transfer Protocol (FTP), the need to be able to define hyperlinks

meant that the traditional FTP model of using a set of commands to specify how to retrieve

a resource had to be abandoned. Instead, a system was needed whereby a resource could

be uniquely specified using a simple, compact string.

The result of this need was the definition of one of the three primarily elements of the World

Wide Web: the Uniform Resource Identifier (URI). URIs are divided into two categories:

Uniform Resource Locators (URLs) and Uniform Resource Names (URNs). While URIs,

URLs and URNs grew out of the development of the Web, they have now been generalized

to provide an addressing mechanism for a wide assortment of TCP/IP application layer

protocols. They are thus described in detail in a separate section; this topic will provide

more information on how they are used specifically for the Web.

At the present time, the Web uses URLs almost exclusively; URNs are still in development.

Web URLs specify the use of the Hypertext Transfer Protocol (HTTP) for resource retrieval,

and are thus normally called HTTP URLs. These URLs allow a resource such as a

document, graphical image or multimedia file to be uniquely addressed by specifying the

host name, directory path and file name where it is located.

Key Concept: Uniform Resource Identifiers (URIs) were developed to allow World

Wide Web resources to be easily and consistently identified; they are also now used

for other protocols and applications. The type of URI currently used on the Web is

the Uniform Resource Locator (URL), which identifies the use of HTTP to retrieve a

resource, and provides information on where and how it can be found and retrieved.

HTTP URL Syntax

HTTP URLs may be absolute or relative. Absolute URLs are usually used for hyperlinks

from one Web site to another, or by users requesting a new document without any prior

context. Absolute HTTP URLs are based on the following common Internet URL syntax:

For the Web, the scheme is “http:” and the semantics of the different URL elements is

defined to have meanings that are relevant to the Web. The general structure of an HTTP

URL is thus:

http://<user>:<password>@<host>:<port>/<url-path>?<query>#<bookmark>

The following shows how these syntactic elements are specifically defined for HTTP

absolute URLs:

☯ <user> and <password>: Optional authentication information, for resources located

on password-protected servers. This construct is rarely used in practice and so most

people don't realize it is an option; it has thus become a target of abuse by con artists

who use it to obscure undesirable URLs.

☯ <host>: The host name of the Web server upon which the resource is located. This is

usually a fully-qualified DNS domain name, but may also be an IP address.

☯ <port>: The TCP port number to use for connecting to the Web server. This defaults to

80 for HTTP and is usually omitted. Rarely, you may see some other port number

used, sometimes to allow two copies of Web server software devoted to different uses

on the same IP address; port 8080 is especially common as an alternative.

☯ <url-path>: The path pointing to the specific resource to be retrieved using HTTP. This

is usually a full directory path expressing the sequence of directories to be traversed

from the root directory to the place where the resource is located, and then the

resource's name. It’s important to remember that the path is case-sensitive, even

though DNS domain names are not.

☯ <query>: An optional query or other information to be passed to the Web server. This

feature is commonly used to implement interactive functions, because the query value

can be specified by the user and then be passed from the Web browser to the Web

server. The alternative method is by using the HTTP POST method.

☯ <bookmark>: Identifies a particular location within an HTML document. This is

commonly used in very large HTML documents to allow a user to click a hyperlink and

scroll to a particular place in the document. See the example in the previous topic

(near the end of Table 274).

Although the URL syntax for the Web is quite “rich” and potentially complex, most Web

URLs are actually quite short. The vast majority of these components are omitted,

especially the user, password, port and bookmark elements; queries are also used only for

special purposes. This leaves the more simplified form you will usually encounter for URLs:

http://<host>/<url-path>

Resource Paths and Directory Listings

The <url-path> used to reference a particular document can also be omitted. This provides

a convenient way for a user to see what content is offered on a Web site without needing to

know what particular document to request. For example, a user who wants to just see what

the current headlines are on CNN would just go to “http://www.cnn.com”. In this case, the

request is sent to the Web server for the null document “/” (which is implied if it is not

specified; technically you are supposed to specify “http://www.cnn.com/”).

How such a “/” request is handled depends on the server. Technically, such a request is

actually asking the server “please show me the contents of the root directory of the server”.

However, this is both ugly (a listing of file names is not the best way to make a first

impression) and a potential security issue (as anyone can see the name of every file on the

server). Instead, most HTTP servers are set up to automatically recognize such requests

and return a default document, often named something like “index.html” or “default.html”.

Many servers will similarly return a default document of some sort if any other directory is

specified in a URL; for example, “http://www.pcguide.com/ref” actually returns “http://

www.pcguide.com/ref/index.htm”.

The forms above apply to absolute HTTP URLs. URLs may also be relative; this is the norm

for links between closely related documents, such as graphics that go with a document, or

between documents in a set or project. In this case, usually only a fractional portion of a

URL path is specified; this is described fully in the topic on relative URLs.

Note that while it is technically incorrect to leave the “http://” off an HTTP URL, most Web

browsers will add it automatically if omitted. As a result, many Web users are in the habit of

entering “URLs” that are simply a host name, such as just “www.pcguide.com”.

TCP/IP Hypertext Transfer Protocol (HTTP)

The success of the World Wide Web is a result of the efficiency and usefulness of the

complete hypermedia system it implements. We examined in the last section the basic

concepts behind hypertext, and looked at two of the three major components that comprise

the World Wide Web system: HTML and URLs. The third major component of the Web is

arguably the most important: the protocol that actually transfers hypertext documents and

other files between Web servers and Web clients (browsers). This is one of the most widely-

known software protocols in all of networking: the Hypertext Transfer Protocol (HTTP).

In this section I provide a detailed description of the Hypertext Transfer Protocol. I begin

with an overview of HTTP and a discussion of its history and versions, and the standards

that define them. I then describe the operation of the protocol in five subsections. The first

discusses HTTP's operation in general terms, focusing on how connections are established

and maintained. The second describes HTTP messages and how they are formatted, and

describes HTTP methods (commands) and status codes. The third details the many HTTP

headers, which are critically important as they are the primary way that information is

communicated between HTTP servers and clients. The fourth subsection provides infor-

mation about how resources, called entities, are encoded and transferred in HTTP. The final

subsection describes special features and capabilities of the modern HTTP protocol.

Background Information: Like so many TCP/IP protocols, when HTTP was

designed, its creators “borrowed” elements from other application protocols. In this

case, HTTP uses certain elements from e-mail, especially the Multipurpose

Internet Mail Extensions (MIME). I would recommend familiarity with both the RFC 822 e-

mail message format and MIME, especially MIME headers and media types, before reading

this section. The relationship between HTTP and MIME is covered in the topic discussing

HTTP entities and media types.

HTTP Overview, History, Versions and Standards

The World Wide Web had humble beginnings, as a research project at the Swiss research

institute, CERN. The primary goal of the project was to allow hypertext documents to be

electronically linked, so selecting a reference in one document to a second one would

cause it to be retrieved. To implement this system, some sort of mechanism was needed to

allow a client computer to tell a server to send it a document. To fill this function, the early

developers of the Web created a new TCP/IP application layer protocol: the Hypertext

Transfer Protocol (HTTP).

HTTP/0.9

The original version of HTTP was intended only for the transfer of hypertext documents,

and was designed to be very simple to make implementation of the fledgling Web easier.

This early HTTP specifies that an HTTP client establishes a connection to an HTTP server

using TCP. The client then issues a single “GET” request specifying a resource to be

retrieved. The server responds by sending the file as a stream of text bytes, and the

connection is terminated. The entire document defining this version of HTTP is only a

couple of pages long!

This first version of HTTP was functional, but extremely limited in its capabilities. It didn't

support the transfer of any types of data other than hypertext, and it provided no

mechanism for any sort of “intelligent” communication between the client and server. This

early HTTP prototype was not up to the task of providing the basis for data transfer for the

future of the World Wide Web. It was never made an official RFC standard, and in fact,

never even had a formal version number; it is known today as HTTP version 0.9, or “HTTP/

0.9” using the version format used by HTTP. I believe this number has no particular signifi-

cance other than being a bit smaller than the number of the first official version of the

protocol.

HTTP/1.0

The skeleton of functionality that HTTP/0.9 formed the basis for a rapid evolution of HTTP

in the early 1990s. As the World Wide Web grew in size and acceptance, many new ideas

and features were incorporated into HTTP. The result of a great deal of development effort

was the formalization of the first HTTP standard: version 1.0. This much enhanced HTTP

was published in May 1996 as RFC 1945, Hypertext Transfer Protocol — HTTP/1.0. It had

been in use for several years prior to that formal publication date, however.

HTTP/1.0 transformed HTTP from a trivial request/response application to a true

messaging protocol. It described a complete message format for HTTP, and explained how

it should be used for client requests and server responses. One of the most important

changes in HTTP/1.0 was the generalization of the protocol to handle many types of

different media, as opposed to strictly hypertext documents. This was done by borrowing

concepts and header constructs from the Multipurpose Internet Mail Extensions (MIME)

standard defined for e-mail. At the same time that it defined much more capable Web

servers and clients, HTTP/1.0 retained backwards compatibility with servers and clients still

using HTTP/0.9.

HTTP/1.0 was the version of HTTP that was widely implemented in the mid-1990s as the

Web exploded in popularity. After only a couple of years, HTTP accounted for the majority

of the traffic on the burgeoning Internet. The popularity of HTTP was in fact so great that it

single-handedly prompted the installation of a lot of new hardware to handle the load of

browser requests and Web server replies.

Unfortunately, much of this huge load of traffic was due to some limitations in HTTP itself.

These only became apparent due to the tremendous growth in the use of the protocol

which, combined with the normal growing pains of the Internet, led to many frustrated Web

users. The inefficiencies of HTTP version 1.0 were a result of design limitations such as the

need for each site to be hosted on a different server, the fact that each HTTP session

handled only one client request, and a general lack of support for necessary performance-

enhancing features such as caching, proxying and partial resource retrieval.

HTTP/1.1

While impatient pundits coined sarcastic terms such as the “World Wide Wait”, the IETF

continued to work to improve HTTP. In January 1997, the first draft version of HTTP/1.1

appeared: in RFC 2068. This document was later revised and published as RFC 2616,

Hypertext Transfer Protocol — HTTP/1.1, in June 1999. HTTP/1.1 retains backwards

compatibility with both HTTP/1.0 and HTTP/0.9. It is accompanied by RFC 2617, HTTP

Authentication: Basic and Digest Access Authentication, which deals with security and

authentication issues.

HTTP/1.1 introduces several significant improvements over version 1.0 of the protocol,

most of which specifically address the performance problems I just described. Some of the

more important improvements in version 1.1 are:

☯ Multiple Host Name Support: In HTTP/1.0, there was no way to specify the host

name of the server to which the client needed to connect. As a result, the Web server

at a particular IP address could only support one domain name. This was not only

inefficient, it was exacerbating the depletion of IP addresses in the 1990s, because

each new Web server to come online required a new IP address. HTTP/1.1 allows one

Web server to handle requests for dozens or even hundreds of different virtual hosts.

☯ Persistent Connections: HTTP/1.1 allows a client to send multiple requests for

related documents to a server in a single TCP session. This greatly improves perfor-

mance over HTTP/1.0, where each request required a new connection to the server.

☯ Partial Resource Selection: In HTTP/1.1, a client can ask for only part of a resource

rather than the entire document, which reduces the load on the server and saves

transfer bandwidth.

☯ Better Caching and Proxying Support: HTTP/1.1 includes many provisions to make

caching and proxying more efficient and effective than they were in HTTP/1.0. These

techniques can improve performance by providing clients with faster replies to their

requests while reducing the load on servers, as well as enhancing security and imple-

menting other functionality.

☯ Content Negotiation: A negotiation feature was added that allows the client and

server to exchange information to help select the best resource or version of a

resource when multiple variants are available.

☯ Better Security: HTTP/1.1 defines authentication methods and is generally more

“security aware” than HTTP/1.0 was.

In addition to these notable improvements, many other minor enhancements were made in

HTTP/1.1. Several of these take the form of new headers that can be included in client

requests to better control under what circumstances resources are retrieved from the

server, and headers in server responses to provide additional information to the client.

Future HTTP Versions

HTTP/1.1 continues to be the current version of the Hypertext Transfer Protocol, even

though it is now several years old. This may seem somewhat surprising, given how widely

used HTTP is. Then again, it may be the fact that so many millions of servers and clients

implement HTTP/1.1 that no new version has been created. For a while there was specu-

lation that version 1.2 of HTTP would be developed, but this has not happened.

In the late 1990s, work began on a method of expanding HTTP through extensions to the

existing version 1.1. Development of the HTTP Extension Framework proceeded for a

number of years, and in 1998 a proposed draft for a new Internet standard was created.

However, as I just said, HTTP/1.1 is so widely deployed and so important that it was very

difficult to achieve consensus on any proposal to modify it. As a result, when the HTTP

Extension Framework was finally published in February 2000 as RFC 2774, the universal

acceptance required for a new standard did not exist. The framework was given “experi-

mental” status, and never became a formal standard.

Key Concept: The engine of the World Wide Web is the application protocol that

defines how Web servers and clients exchange information: the Hypertext Transfer

Protocol (HTTP). The first version of HTTP, HTTP/0.9, was part of the early World

Wide Web and was a very simple request/response protocol with limited capabilities that

could transfer only text files. The first widely-used version was HTTP/1.0, which is a more

complete protocol that allows the transport of many types of files and resources. The

current version is HTTP/1.1, which expands HTTP/1.0’s capabilities with several features

that improve the efficiency of transfers and address many of the needs of the rapidly

growing modern World Wide Web.

HTTP General Operation and Connections

The Hypertext Transfer Protocol (HTTP) began as an extremely basic protocol, designed to

do just one thing: allow a client to send a simple request for a hypertext file and receive it

back from the server. Modern HTTP remains at its heart a straight-forward request/reply

protocol, but now includes many new features and capabilities to support the growing size

of the World Wide Web and the ever-increasing variety of ways that people have found to

use it. The best place to start in explaining HTTP is thus by looking at its operation as a

whole and how communication takes place between a Web server and a Web client.

In this section I introduce the Hypertext Transfer Protocol by describing its operation in

general terms. I begin with a high-level overview of HTTP and discussion of its operational

model. I explain the two types of connections that are supported between HTTP clients and

servers, and the method by which requests can be pipelined in HTTP/1.1. I then provide

more information about how persistent connections are established, managed and termi-

nated in the current version of HTTP.

HTTP Operational Model and Client/Server Communication

The Hypertext Transfer Protocol is the application-layer protocol that implements the World

Wide Web. While the Web itself has many different facets, HTTP is only concerned with one

basic function: the transfer of hypertext documents and other files from Web servers to Web

clients. In terms of actual communication, clients are chiefly concerned with making

requests to servers, which respond to those requests.

Thus, even though HTTP includes a lot of functionality to meet the needs of clients and

servers, when you boil it down, what see is a very simple, client/server, request/response

protocol. In this respect, HTTP more closely resembles a rudimentary protocol like BOOTP

or ARP than it does other application-layer protocols like FTP and SMTP, which all involve

multiple communication steps and command/reply sequences.

Basic HTTP Client/Server Communication

In its simplest form, the operation of HTTP involves only an HTTP client, usually a Web

browser on a client machine, and an HTTP server, more commonly known as a Web server.

After a TCP connection is created, the two steps in communication are as follows:

1. Client Request: The HTTP client sends a request message formatted according to

the rules of the HTTP standard—an HTTP Request. This message specifies the

resource that the client wishes to retrieve, or includes information to be provided to the

server.

2. Server Response: The server reads and interprets the request. It takes action

relevant to the request and creates an HTTP Response message, which it sends back

to the client. The response message indicates whether the request was successful,

and may also contain the content of the resource that the client requested, if

appropriate.