Domain Name System Alias DNS

b

DNS: The Most famous Support application-layer Protocol

There are several applications in the application layer of the Internet model that follow the client/server paradigm. The client/server programs can be divided into two categories:

1. those that can be directly used by the user, such as e-mail, and 
2. those that support other application programs. The Domain Name System (DNS) is a supporting program that is used by other programs such as e-mail.

Figure 25.1 shows an example of how a DNS client/ server program can support an e-mail program to find the IP address of an e-mail recipient. A user of an e-mail program may know the e-mail address of the recipient; however, the IP protocol needs the IP address. The DNS client program sends a request to a DNS server to map the e-mail address to the corresponding IP address.

To identify an entity, TCP/IP protocols use the IP address, which uniquely identifies the connection of a host to the Internet. However, people prefer to use names instead of numeric addresses. 

Therefore, we need a system that can map a name to an address or an address to a name.

When the Internet was small, mapping was done by using a host file:

1. The host file had only two columns: name and address. 
2. Every host could store the host file on its disk and update it periodically from a master host file. 
3. When a program or a user wanted to map a name to an address, the host consulted the host file and found the mapping.

Today, however, it is impossible to have one single host file (anyway still works well for a small LAN but the trend is to use DHCP+DNS) to relate every address with a name and vice versa.

1. The host file would be too large to store in every host. 
2. In addition, it would be impossible to update all the host files in every host every time there was a change.

One solution would be to store the entire host file in a single computer and allow
access to this centralized information to every computer that needs mapping. But we know that this would create a huge amount of traffic on the Internet.

Another solution, the one used today, is to

  divide this huge amount of information into smaller parts and store each part on a different computer. In this method, the host that needs mapping can contact the closest computer holding the needed information. 

This method is used by the Domain Name System (DNS). Here, we first discuss the concepts and ideas behind the DNS. We then describe the DNS protocol itself.

NAME SPACE
To be unambiguous, the names assigned to machines must be carefully selected from a name space with complete control over the binding between the names and IP addresses.

In other words, the names must be unique because the addresses are unique.

A name space that maps each address to a unique name can be organized in two ways: 

1. flat or
2. hierarchical.

Flat Name Space
In a flat name space, a name is assigned to an address.

A name in this space is a sequence of characters without structure. 

The names may or may not have a common section; if they do, it has no meaning.

The main disadvantage of a flat name space is that it cannot be used in a large system such as the Internet because it must be centrally controlled to avoid ambiguity and duplication.

Hierarchical Name Space
In a hierarchical name space, each name is made of several parts.

1. The first part can define the nature of the organization, 
2. the second part can define the name of an organization, 
3. the third part can define departments in the organization, and so on. 

In this case, the authority to assign and control the name spaces can be decentralized.

A central authority can assign the part of the name that defines the nature of the organization and the name of the organization. The responsibility of the rest of the name can be given to the organization itself. 

The organization can add suffixes (or prefixes) to the name to define its host or resources.

The management of the organization need not worry that the prefix chosen for a host is taken by another organization because, even if part of an address is the same, the whole address is different. 

For example, assume two colleges and a company call one of their computers challenger.

1. The first college is given a name by the central authority such as jhda.edu, 
2. the second college is given the name berkeley.edu, and 
3. the company is given the name smart.com.

When these organizations add the name challenger to the name they have already been given, the end result is three distinguishable names:

1. challenger.jhda.edu
2. challenger.berkeley.edu and 
3. challenger.smart.com

The names are unique without the need for assignment by a central authority.

The central authority controls only part of the name, not the whole.

DOMAIN NAME SPACE
To have a hierarchical name space, a domain name space was designed. In this design the names are defined in an inverted-tree structure with the root at the top.

The tree can have only 128 levels(7 bits: 2^7=128): level 0 (root) to level 127 (see Figure 25.2).

Label

1. Each node in the tree has a label, which is a string with a maximum of 63 characters(6 bits). 
2. The root label is a null string (empty string). 
3. DNS requires that children of a node (nodes that branch from the same node) have different labels, which guarantees the uniqueness of the domain names.

Domain Name
Each node in the tree has a domain name.

A full domain name is a sequence of labels separated by dots (.). 

1. The domain names are always read from the node up to the root. 
2. The last label is the label of the root (null). 

This means that a full domain name always ends in a null label, which means the last character is a dot because the null string is nothing. Figure 25.3 shows some domain names.

Fully Qualified Domain Name
If a label is terminated by a null string, it is called a fully qualified domain name (FQDN).

An FQDN is a domain name that contains the full name of a host. It contains all labels, from the most specific to the most general, that uniquely define the name of the host. 

For example, the domain name:

challenger.atc.tbda.edu.

is the FQDN of a computer named challenger installed at the Advanced Technology Center (ATC) at De Anza College.

A DNS server can only match an FQDN to an address. 

Note that the name must end with a null label, but because null means nothing, the label ends with a dot (.).


Partially Qualified Domain Name
If a label is not terminated by a null string, it is called a partially qualified domain name (PQDN).

A PQDN starts from a node, but it does not reach the root. It is used when the name to be resolved belongs to the same site as the client. Here the resolver can supply the missing part, called the suffix, to create an FQDN.

For example, if a user at the jhda.edu. site wants to get the IP address of the challenger computer, he or she can define the partial name challenger. The DNS client adds the suffix atc.jhda.edu. before passing the address to the DNS server.

The DNS client normally holds a list of suffixes. 

The following can be the list of suffixes at De Anza College:

The null suffix defines nothing. This suffix is added when the user defines an FQDN.

• atc.fhda.edu
• fhda.edu
• null

Figure 25.4 shows some FQDNs and PQDNs.

Domain
A domain is a subtree of the domain name space.

The name of the domain is the domain name of the node at the top of the subtree. 

Figure 25.5 shows some domains. Note that a domain may itself be divided into domains (or subdomains as they are sometimes called).


DISTRIBUTION OF NAME SPACE
The information contained in the domain name space must be stored. However, it is very inefficient and also unreliable to have just one computer store such a huge amount of information.

1. It is inefficient because responding to requests from all over the world places a heavy load on the system. 
2. It is unreliable because any failure makes the data inaccessible.

Hierarchy of Name Servers
The solution to these problems is to distribute the information among many computers called DNS servers. One way to do this is to divide the whole space into many domains based on the first level.

In other words, we let the root stand alone and create as many domains (subtrees) as there are first-level nodes.

Because a domain created in this way
could be very large, DNS allows domains to be divided further into smaller domains (subdomains). Each server can be responsible (authoritative) for either a large or a small domain. In other words, we have a hierarchy of servers in the same way that we have a hierarchy of names (see Figure 25.6).

Zone
Since the complete domain name hierarchy cannot be stored on a single server, it is divided among many servers.

What a server is responsible for or has authority over is called a zone. We can define a zone as a contiguous part of the entire tree. 

If a server accepts responsibility for a domain and does not divide the domain into smaller domains, the domain and the zone refer to the same thing.

The server makes a database called a zone file and keeps all the information for every node under that domain.

However, if a server divides its domain into subdomains and delegates part of its authority to other servers, domain and zone refer to different things.

The information about the nodes in the subdomains is stored in the servers at the lower levels, with the original server keeping some sort of reference to these lower-level servers.

Of course the original server does not free itself from responsibility totally: It still has a zone, but the detailed information is kept by the lower-level servers (see Figure 25.7).

A server can also divide part of its domain and delegate responsibility but still keep part of the domain for itself. In this case, its zone is made of detailed information for the part of the domain that is not delegated and references to those parts that are delegated.


Root Server
A root server is a server whose zone consists of the whole tree.

A root server usually does not store any information about domains but delegates its authority to other servers, keeping references to those servers. 

There are several root servers, each covering the whole domain name space. The servers are distributed all around the world.

Primary and Secondary Servers
DNS defines two types of servers: primary and secondary.

1. A primary server is a server that stores a file about the zone for which it is an authority. It is responsible for creating, maintaining, and updating the zone file. It stores the zone file on a local disk.
2. A secondary server is a server that transfers the complete information about a zone from another server (primary or secondary) and stores the file on its local disk. The secondary server neither creates nor updates the zone files. 
3. If updaying is required, it must be done by the primary server, which sends the updated version to the secondary.

The primary and secondary servers are both authoritative for the zones they serve.

The idea is not to put the secondary server at a lower level of authority but to create redundancy for the data so that if one server fails, the other can continue serving clients.

Note also that a server can be a primary server for a specific zone and a secondary server for another zone. Therefore, when we refer to a server as a primary or secondary server, we should be careful to which zone we refer.

A primary server loads all information from the disk file; the secondary server loads all information from the primary server.

When the secondary downloads information from the primary, it is called zone transfer.

DNS IN THE INTERNET
DNS is a protocol that can be used in different platforms. In the Internet, the domain name space (tree) is divided into three different sections(see Figure 25.8):

1. generic domains, 
2. country domains, and the 
3. inverse domain 

Generic Domains
The generic domains define registered hosts according to their generic behavior. Each node in the tree defines a domain, which is an index to the domain name

space database (see Figure 25.9).

Looking at the tree, we see that the first level in the generic domains section allows 14 possible labels(4 bits). These labels describe the organization types as listed in Table 25.1.

Country Domains

The country domains section uses two-character country abbreviations (e.g., us for United States).

Second labels can be organizational, or they can be more specific, national designations. The United States, for example, uses state abbreviations as a subdivision of us (e.g., ca.us.). Figure 25.10 shows the country domains section. The address anza.cup.ca.us can be translated to De Anza College in Cupertino, California, in the United States.

Inverse Domain
The inverse domain is used to map an IP address to a name. This may happen, for example, when a server has received a request from a client to do a task.

Although the server has a file that contains a list of authorized clients, only the IP address of the client (extracted from the received IP packet) is listed. The server asks its resolver to send a query to the DNS server to map an address to a name to determine if the client is on the authorized list. This type of query is called an inverse or pointer (PTR) query. To handle a pointer query,

1. the inverse domain is added to the domain name space with the first-level node called arpa (for historical reasons). 
2. The second level is also one single node named in-addr (for inverse address). 
3. The rest of the domain defines IP addresses.

The servers that handle the inverse domain are also hierarchical. This means the netid part of the address should be at a higher level than the subnetid part, and the subnetid part higher than the hostid part. In this way, a server serving the whole site is at a higher level than the servers serving each subnet.

This configuration makes the domain look inverted when compared to a generic or country domain. 

To follow the convention of reading the domain labels from the bottom to the top, an IP address such as 132.34.45.121 (a class B address with netid 132.34) is read as 121.45.34.132.in-addr. arpa. See Figure 25.11 for an illustration of the inverse domain configuration.

RESOLUTION
Mapping a name to an address or an address to a name is called name-address resolution.

Resolver
DNS is designed as a client/server application. A host that needs to map an address to a name or a name to an address calls a DNS client called a resolver. The resolver accesses the closest DNS server with a mapping request.

1. If the server has the information, it satisfies the resolver; 
2. otherwise, it either refers the resolver to other servers or asks other servers to provide the information.

After the resolver receives the mapping, it interprets the response to see if it is a real resolution or an error, and finally delivers the result to the process that requested it.

Mapping Names to Addresses
Most of the time, the resolver gives a domain name to the server and asks for the corresponding address. In this case, the server checks the generic domains or the country domains to find the mapping. If the domain name is from the generic domains section, the resolver receives a domain name such as "chal.atc.jhda.edu.". The query is sent by the resolver to the local DNS server for resolution. If the local server cannot resolve the query, it either refers the resolver to other servers or asks other servers directly. If the domain name is from the country domains section, the resolver receives a domain name such as "ch.jhda.cu.ca.us.". The procedure is the same.

1. If the server is the authority for the domain name, it checks its database and responds. 
2. If the server is not the authority, it sends the request to another server (the parent usually) and waits for the response.
3. If the parent is the authority, it responds; otherwise, it sends the query to yet another server. 
4. When the query is finally resolved, the response travels back until it finally reaches the requesting client. 

This is called recursive resolution and is shown in Figure 25.12.

Iterative Resolution

If the client does not ask for a recursive answer, the mapping can be done iteratively:

1. If the server is an authority for the name, it sends the answer. 
2. If it is not, it returns (to the client) the IP address of the server that it thinks can resolve the query. 
3. The client is responsible for repeating the query to this second server. 
4. If the newly addressed server can resolve the problem, it answers the query with the IP address; 
5. otherwise, it returns the IP address of a new server to the client. 
6. Now the client must repeat the query to the third server. 

This process is called iterative resolution because the client repeats the same query to multiple servers. In Figure 25.13 the client queries four servers before it gets an answer from the mcgraw.com server.

Caching
Each time a DNS server receives a query for a name that is not in its domain, it needs to search its database for a server IP address. Reduction of this search time would increase efficiency. DNS handles this with a mechanism called caching:

1. When a server asks for a mapping from another server and receives the response, it stores this information in its cache memory before sending it to the client. 
2. If the same or another client asks for the same mapping, it can check its cache memory and solve the problem. However, to inform the client that the response is coming from the cache memory and not from an authoritative source, the server marks the response as unauthoritative.

Caching speeds up resolution, but it can also be problematic. If a server caches a mapping for a long time, it may send an outdated mapping to the client. To counter this, two techniques are used:

1. First, the authoritative server always adds information to the mapping called time-to-live (TTL). It defines the time in seconds that the receiving server can cache the information. After that time, the mapping is invalid and any query must be sent again to the authoritative server. 
2. Second, DNS requires that each server keep a TTL counter for each mapping it caches. The cache memory must be searched periodically, and those mappings with an expired TTL must be purged.

DNS MESSAGES
DNS has two types of messages:

• query: The query message consists of 
• a header and 
• question records
• response: the response message consists of 
• a header, 
• question records, 
• answer records, 
• authoritative records, and 
• additional records (see Figure 25.14).

Both types have the same format:

Header
Both query and response messages have the same header format with some fields set to zero for the query messages.

The header is 12 bytes, and its format is shown in Figure 25.15.

• The identification subfield is used by the client to match the response with the query. 
• The client uses a different identification number each time it sends a query. 
• The server duplicates this number in the corresponding response. 
• The flags subfield is a collection of subfields that define 
• the type of the message, 
• the type of answer requested, 
• the type of desired resolution (recursive or iterative), and so on. 
• The number of question records subfield contains the number of queries in the question section of the message.
• The number of answer records subfield contains the number of answer records in the answer section of the response message. 
• Its value is zero in the query message. 
• The number of authoritative records subfield contains the number of authoritative records in the authoritative section of a response message. 
• Its value is zero in the query message. 
• Finally, the number of additional records subfield contains the number additional records in the additional section of a response message. 
• Its value is zero in the query message.

Question Section
This is a section consisting of one or more question records. It is present on both query and response messages. We will discuss the question records in a following section.

Answer Section
This is a section consisting of one or more resource records. It is present only on response messages.

This section includes the answer from the server to the client (resolver). 

We will discuss resource records in a following section.

Authoritative Section
This is a section consisting of one or more resource records. It is present only on response messages.

This section gives information (domain name) about one or more authoritative servers for the query.

Additional Information Section
This is a section consisting of one or more resource records. It is present only on response messages.

This section provides additional information that may help the resolver. For example, a server may give the domain name of an authoritative server to the resolver in the authoritative section, and include the IP address of the same authoritative server in the additional information section.

TYPES OF RECORDS
As we saw, two types of records are used in DNS.

1. The question records are used in the question section of the query and response messages.
2. The resource records are used in the answer, authoritative, and additional information sections of the response message.

Question Record
A question record is used by the client to get information from a server.

This contains the domain name. 

Resource Record
Each domain name (each node on the tree) is associated with a record called the resource record.

The server database consists of resource records. Resource records are also what is returned by the server to the client.

REGISTRARS
How are new domains added to DNS?  This is done through a registrar, a commercial entity accredited by ICANN. A registrar first verifies that the requested domain name is unique and then enters it into the DNS database. A fee is charged.

Today, there are many registrars; their names and addresses can be found at intenic.net . To register, the organization needs to give the name of its server and the IP address of the server. For example, a new commercial organization

• named wonderful with 
• a server named ws and 
• IP address 200.200.200.5  

needs to give the following information to one of the registrars:

Domain name: WS. wonderful.com
IP address: 200.200.200.5

DYNAMIC DOMAIN NAME SYSTEM (DDNS)
When the DNS was designed, no one predicted that there would be so many address changes. In DNS, when there is a change, such as

1. adding a new host, 
2. removing a host, or 
3. changing an IP address, 

the change must be made to the DNS master file. These types of changes involve a lot of manual updating. The size of today's Internet does not allow for this kind of manual operation.
The DNS master file must be updated dynamically. The Dynamic Domain Name System (DDNS) therefore was devised to respond to this need. In DDNS, when a binding between a name and an address is determined:

1. the information is sent, usually by DHCP  to a primary DNS server. 
2. The primary server updates the zone.
3. The secondary servers are notified either actively or passively. 

In active notification, the primary server sends a message to the secondary servers about the change in the zone, whereas in passive notification, the secondary servers periodically check for any changes. In either case, after being notified about the change, the secondary servers requests information about the entire zone (zone transfer).

To provide security and prevent unauthorized changes in the DNS records, DDNS can use an authentication mechanism.

ENCAPSULATION
DNS can use either UDP or TCP. In both cases the well-known port used by the server is port 53.

• UDP is used when the size of the response message is less than 512 bytes because most UDP packages have a 512-byte packet size limit. 
• If the size of the response message is more than 512 bytes, a TCP connection is used. 

In that case, one of two scenarios can occur:

1. If the resolver has prior knowledge that the size of the response message is more than 512 bytes, it uses the TCP connection. For example, if a secondary name server (acting as a client) needs a zone transfer from a primary server, it uses the TCP connection because the size of the information being transferred usually exceeds 512 bytes.
2. If the resolver does not know the size of the response message, it can use the UDP port. 
1. However, if the size of the response message is more than 512 bytes, the server truncates the message and turns on the TC bit. 
2. The resolver now opens a TCP connection and repeats the request to get a full response from the server.

Resources

Data Communications and Networking
by Behrouz Forouzan 
(McGraw-Hill) 

RECOMMENDED READING
For more details about subjects discussed here:

Books
DNS is discussed in [AL98], Chapter 17 of [For06], Section 9.1 of [PD03], and Section 7.1 of [Tan03].

Sites

internic  Information about registrars
ietf  Information about RFCs

RFCs
The following RFCs are related to DNS:
799, 811, 819, 830, 881, 882, 883, 897, 920, 921, 1034, 1035, 1386, 1480, 1535, 1536, 1537, 1591, 1637, 1664, 1706, 1112, 1713, 1982, 2065, 2137, 2317, 2535, 2671

KEY TERMS
caching, country domain, DNS server, domain, domain name, domain name space, Domain Name System (DNS), Dynamic Domain Name System (DDNS), flat name space, fully qualified domain name (FQDN), generic domain, hierarchical name space, host file, inverse domain, iterative resolution, label, name space, partially qualified domain name (PQDN), primary server, query message, question record, recursive resolution, registrar, resolver, resource record, response message, root server, secondary server, subdomain, suffix, zone

The World Wide Web: HTTP

The World Wide Web (WWW) is a repository of information linked together from points all over the world. The WWW has a unique combination of flexibility, portability, and user-friendly features that distinguish it from other services provided by the Internet.
The WWW project was initiated by CERN (European Laboratory for Particle Physics) to create a system to handle distributed resources necessary for scientific research.

HTTP: A killer Application level protocol from a networking point of view

In the 1980s the Internet was used by researchers, academics and university students to:

• login to remote hosts, 
• to transfer files from local hosts to remote hosts and vice versa, 
• to receive and send news, and 
• to receive and send electronic mail. 

Although these applications were(and continue to be) extremely useful, the Internet was essentially unknown outside the academic and research communities.

Then in early 1990s the Internet's killer application arrived on the scene -- the World Wide Web.

1. The Web is the Internet application that caught the general public's eye. 
2. It is dramatically changing how people interact inside and outside their work environments. 
3. It has spawned thousands of start-up companies. 
4. It has elevated the Internet from just one of many data networks (including online networks such as Prodigy, America On Line and Compuserve, national data networks such as Minitel/Transpac in France, and private X.25 and frame relay networks) to essentially the one and only data network.

History is sprinkled with the arrival of electronic communication technologies that have had major societal impacts.

1. The first such technology was the telephone, invented in the 1870s. The telephone allowed two persons to orally communicate in real-time without being in the same physical location. It had a major impact on society -- both good and bad. 
2. The next electronic communication technology was broadcast  radio/television, which arrived in the 1920s and 1930s. Broadcast  radio/television allowed people to receive vast quantities of audio and video information. It also had a major impact on society -- both good and bad. 
3. The third major communication technology that has changed the way people live and work is the Web. 

Perhaps what appeals the most to users about the Web is that it is on demand. Users receive what they want, when they want it. This is unlike broadcast radio and television, which force users to "tune in" when the content provider makes the content available. In addition to being on demand, the Web has many other wonderful features that people love and cherish.

• It is enormously easy for any individual to make any content available over the Web; everyone can become a publisher at extremely low cost. 
• Hyperlinks and search engines help us navigate through an ocean of Web sites. 
• Graphics and animated graphics  stimulate our senses. 
• Forms, Java applets, Active X components, as well as many other devices enable us to interact with pages and sites.
• And more and more, the Web provides a menu interface to vast quantities of audio and video material stored in the Internet, audio and video that can be accessed on demand.

Overview of HTTP

The Hypertext Transfer Protocol (HTTP), the Web's application - layer protocol, is at the heart of the Web.

The Hypertext Transfer Protocol (HTTP) is a protocol used mainly to access data on the World Wide Web. HTTP functions as a combination of FTP and SMTP.

It is similar to FTP because it transfers files and uses the services of TCP.

1. However, it is much simpler than FTP because it uses only one TCP connection. 
1. There is no separate control connection; only data are transferred between the client and the server.

HTTP is like SMTP because the data transferred between the client and the server look like SMTP messages. In addition, the format of the messages is controlled by MIME-like headers.

1. Unlike SMTP, the HTTP messages are not destined to be read by humans; 
1. they are read and interpreted by the HTTP server and HTTP client (browser). 
2. SMTP messages are stored and forwarded, but HTTP messages are delivered immediately. 
3. The commands from the client to the server are embedded in a request message. 
4. The contents of the requested file or other information are embedded in a response message.

HTTP uses the services of TCP on well-known port 80.

HTTP is implemented in two programs:

• a client program and 
• server program. 

The client program and server programs, executing on different end systems, talk to each other by exchanging HTTP messages.

HTTP defines the structure of these messages and how the client and server exchange the messages. 

Now, it is useful to review some Web terminology:

The WWW today is a distributed client/server service, in which a client using a browser can access a service using a server. However, the service provided is distributed over many locations called sites.

Each site holds one or more documents, referred to as Web pages. Each Web page can contain a link to other pages in the same site or at other sites. The pages can be retrieved and viewed by using browsers.

1. The client needs to see some information that it knows belongs to site A. It sends a request through its browser, a program that is designed to fetch Web documents. The request, among other information, includes the address of the site and the Web page, called the URL, which we will discuss shortly. 
2. The server at site A finds the document and sends it to the client. When the user views the document, she finds some references to other documents, including a Web page at site B. The reference has the URL for the new site. 
3. The user is also interested in seeing this document. The client sends another request to the new site, and the new page is retrieved. 

In other words a Web page (also called a document) consists of objects. An object is a simply file -- such as a HTML file, a JPEG image, a GIF image, a Java applet, an audio clip, etc. -- that is addressable by a single URL.

Most Web pages consist of a base HTML file and several referenced objects. 

For example, if a Web page contains HTML text and five JPEG images, then the Web page has six objects: the base HTML file plus the five images. The base HTML file references the other objects in the page with the objects' URLs.

A client that wants to access a Web page needs the address. To facilitate the access of documents distributed throughout the world, HTTP uses locators. The uniform resource locator (URL) is a standard for specifying any kind of information on the Internet. The URL defines four things(see Figure 27.3):

1. protocol, 
2. host computer, 
3. (optionally)port, and 
4. path

So each URL has four components:

1. The protocol is the client/server program used to retrieve the document. Many different protocols can retrieve a document; among them are FTP or HTTP. The most common today is HTTP.
2. The host is the computer (that houses the object) on which the information is located, although the name of the computer can be an alias. Web pages are usually stored in computers, and computers are given alias names that usually begin with the characters "www". This is not mandatory, however, as the host can be any name given to the computer that hosts the Web page.
3. The URL can optionally contain the port number of the server. If the port is
   included, it is inserted between the host and the path, and it is separated from the host by a colon.
4. Path is the (object's)pathname of the file where the information is located. Note that the path can itself contain slashes that, in the UNIX operating system, separate the directories from the subdirectories and files. 

For example, the URL www.someSchool.edu/someDepartment/picture.gif
has:

1. www.someSchool.edu for a host name and 
2. /someDepartment/picture.gif for a path name. 

Browsers
A browser is a user agent for the Web; it displays to the user the requested Web page and provides numerous navigational and configuration features.

Web browsers also implement the client side of HTTP. Thus, in the context of the Web, we will interchangeably use the words "browser" and "client".

Popular Web browsers include Mozilla's Firefox , Microsoft's Internet  Explorer , Google's Chrome (Chromium), Opera etc.

Each browser usually consists of three parts:

1. a controller:  receives input from the keyboard or the mouse and uses the client programs to access the document. 
1. After the document has been accessed, the controller uses one of the interpreters to display the document on the screen.
2. client protocol: The client protocol can be one of the protocols described previously such as FTP or HTTP.
3. interpreters: The interpreter can be HTML, Java, or JavaScript, depending on the type of document. We discuss the use of these interpreters based on the document type later in the post's end (see Figure 27.2).

As we say earlier a Web server houses Web objects, each addressable by a URL.The Web page is stored at the server. Each time a client request arrives, the corresponding document is sent to the client.

• To improve efficiency, servers normally store requested files in a cache in memory; memory is faster to access than disk. 
• A server can also become more efficient through multithreading or multiprocessing. In this case, a server can answer more than one request at a time.

Web servers
Web servers also implement the server side of HTTP. Popular Web servers (Netcraft provides a nice survey of Web server penetration) include Apache, Microsoft Internet Information Server(IIS), Nginx, lighttpd, etc. 

HTTP defines how Web clients (i.e., browsers) request Web pages from servers (i.e., Web servers) and how servers transfer Web pages to clients. 

The general idea is illustrated in Figure 2.2-1.

1. When a user requests a Web page (e.g., clicks on a hyperlink), the browser sends HTTP request messages for the objects in the page to the server.
2. The server receives the requests and responds with HTTP response messages that contain the objects. 

Through 1997 essentially all browsers and Web servers implement version HTTP/1.0, which is defined in [RFC 1945].

Beginning in 1998 Web servers and browsers began to implement version HTTP/1.1, which is defined in [RFC 2068].
HTTP/1.1 is backward compatible with HTTP/1.0; a Web server running 1.1 can "talk" with a browser running 1.0, and a browser running 1.1 can "talk" with a server running 1.0.

Both HTTP/1.0 and HTTP/1.1 use TCP as their underlying transport protocol (rather than running on top of UDP). 

The HTTP client:

1. first initiates a TCP connection with the server. 
2. Once the connection is established, the browser and the server processes access TCP through their socket interfaces. 

As we just know, on the client side the socket interface is the "door" between the:

• client process and 
• the TCP connection; 

conversely on the server side it is the "door" between the:

• server process and 
• the TCP connection. 

The client sends HTTP request messages into its socket interface and receives HTTP response messages from its socket interface.

Similarly, the HTTP server receives request messages from its socket interface and sends response messages into the socket interface.

Once the client sends a message into its socket interface, the message is "out of the client's hands" and is "in the hands of TCP".

Recall that TCP provides a reliable data transfer service to HTTP. This implies that each HTTP request message emitted by a client process eventually arrives intact at the server; similarly, each HTTP response message emitted by the server process eventually arrives intact at the client. 

Here we see one of the great advantages of a layered architecture - HTTP need not worry about lost data, or the details of how TCP recovers from loss or reordering of data within the network. That is the job of TCP and the protocols in the lower layers of the protocol stack.

TCP also employs a congestion control mechanism . We only mention here that this mechanism forces each new TCP connection to initially transmit data at a relatively slow rate, but then allows each connection to ramp up to a relatively high rate when the network is uncongested. The initial slow-transmission phase is referred to as slow start.

It is important to note that the server sends requested files to clients without storing any state information about the client. If a particular client asks for the same object twice in a period of a few seconds, the server does not respond by saying that it just served the object to the client; instead, the server resends the object, as it has completely forgotten what it did earlier. Because an HTTP server maintains no information about the clients, HTTP is said to be a stateless protocol.

Non-Persistent and Persistent Connections
HTTP can use both non-persistent connections and persistent connections.

Non-persistent connections is the default mode for HTTP/1.0. Conversely, persistent connections is the default mode for HTTP/1.1.

Non-Persistent Connections
Let us walk through the steps of transferring a Web page from server to client for the case of non-persistent connections. Suppose the page consists of a base HTML file and 10 JPEG images, and that all 11 of these objects reside on the same server. Suppose the URL for the base HTML file is www.someSchool.edu/someDepartment/home.index . Here is what happens:

1. The HTTP client initiates a TCP connection to the server www.someSchool.edu. 
1. Port number 80 is used as the default port number at which the HTTP server will be listening for HTTP clients that want to retrieve documents using HTTP.
2. The HTTP client sends a HTTP request message into the socket associated with the TCP connection that was established in step 1. 
1. The request message either includes the entire URL or simply the path name /someDepartment/home.index.
3. The HTTP server:
1. receives the request message via the socket associated with the connection that was established in step 1, 
2. retrieves the object /someDepartment/home.index from its storage (RAM or disk), 
3. encapsulates the object in a HTTP response message, and 
4. sends the response message into the TCP connection.
4. The HTTP server tells TCP to close the TCP connection. 
1. (But TCP doesn't actually terminate the connection until the client has received the response message intact.)
5. The HTTP client receives the response message.
1. The TCP connection terminates. The message indicates that the encapsulated object is an HTML file. 
2. The client extracts the file from the response message, parses the HTML file and finds references to the ten JPEG objects.
6. The first four steps are then repeated for each of the referenced JPEG  objects.

As the browser receives the Web page, it displays the page to the user. Two different browsers may interpret (i.e., display to the user) a Web page in somewhat different ways.

HTTP has nothing to do with how a Web page is interpreted by a client. The HTTP specifications ([RFC 1945] and [RFC 2068]) only define the communication protocol between the client HTTP program and the server HTTP program.

The steps above use non-persistent connections because each TCP connection is closed after the server sends the object -- the connection does not persist for other objects. Note that each TCP connection transports exactly one request message and one response message. Thus, in this example, when a user requests the Web page, 11 TCP connections are generated.

In general this strategy, for N different objects in different files, the connection must be opened and closed N times.

The non-persistent strategy imposes high overhead on the server because the server needs N different buffers and requires a slow start procedure each time a connection is opened.

In the steps described above, we were intentionally vague about whether the client obtains the 10 JPEGs over ten serial TCP connections, or whether some of the JPEGs are obtained over parallel TCP connections.

Indeed, users can configure modern browsers to control the degree of parallelism. In their default modes, most browsers open five to ten parallel TCP connections, and each of these connections handles one request-response transaction(i.e. in Mozilla Firefox 3.6.16 open per default  6 // (persistent)connections trough -network.http.max-persistent-connections-per-server;6 item --accessible in about:config--). 

If the user prefers, the maximum number of parallel connections can be set to one, in which case the ten connections are established serially. 

As we shall see later, the use of parallel connections:

1. shortens the response time since it cuts out some of the RTT and slow-start delays. 
2. Parallel TCP connections can also allow the requesting browser to steal a larger share of its fair share of the end-to-end transmission bandwidth.

Before continuing, let's do a "back of the envelope calculation" to estimate the amount of time from when a client requests the base HTML file until the file is received by the client.

To this end we define the round-trip time RTT, which is the time it takes for a small packet to travel from client to server and then back to the client.

The RTT includes packet propagation delays, packet queuing delays in intermediate routers and switches, and packet processing delays.  

Now consider what happens when a user clicks on a hyperlink.

1. This causes the browser to initiate a TCP connection between the browser and the Web server; this involves a "three-way handshake" -- the client sends a small TCP message to the server, the server acknowledges and responds with a small message, and finally the client acknowledges back to the server. 
2. One RTT elapses after the first two parts of the three-way handshake. 
3. After completing the first two parts of the handshake, the client sends the HTTP request message into the TCP connection, and 
1. TCP "piggybacks" the last acknowledgment (the third part of the three-way handshake) onto the request message. 
4. Once the request message arrives at the server, the server sends the HTML file into the TCP connection. This HTTP request/response eats up another RTT. 

Thus, roughly, the total response time is 2*RTT plus the transmission time at the server of the HTML file.

Persistent Connections
Non-persistent connections have some shortcomings.

1. First, a brand new connection must be established and maintained for each requested object. For each of these connections, TCP buffers must be allocated and TCP variables must be kept in both the client and server. This can place a serious burden on the Web server, which may be serving requests from hundreds of different clients simultaneously. 
2. Second, as we just described, each object suffers two RTTs -- one RTT to establish the TCP connection and one RTT to request and receive an object. 
3. Finally, each object suffers from TCP slow start because every TCP connection begins with a TCP slow-start phase.

However, the accumulation of RTT and slow start delays is partially alleviated by the use of parallel TCP connections.

With persistent connections, the server leaves the TCP connection open after sending responses. Subsequent requests and responses between the same client and server can be sent over the same connection.

1. In particular, an entire Web page (in the example above, the base HTML file and the ten images) can be sent over a single persistent TCP connection; 
2. moreover, multiple Web pages residing on the same server can be sent over one persistent TCP connection.

Typically, the server can close the connection at the request of a client or if a time-out has been reached(when it isn’t used for a certain time). The timeout interval is often configurable.(in Firefox defaults network.http.keep-alive.timeout;115) The sender usually sends the length of the data with each response. However, there are some occasions when the sender does not know the length of the data. This is the case when a document is created dynamically or actively. In these cases, the server informs the client that the length is not known and closes the connection after sending the data so the client knows that the end of the data has been reached.

There are two versions of persistent connections:

1. without pipelining: 
1. the client issues a new request only when the previous response has been received. In this case, each of the referenced objects (the ten images in the example above) experiences one RTT in order to request and receive the object. Although this is an improvement over non-persistent's two RTTs, the RTT delay can be further reduced with pipelining. 
2. Another disadvantage of no pipelining is that after the server sends an object over the persistent TCP connection, the connection hangs -- does nothing -- while it waits for another request to arrive. This hanging wastes server resources.
2. with pipelining: The default mode of HTTP/1.1 uses persistent connections with pipelining. 
1. In this case, the HTTP client issues a request as soon as it encounters a reference. Thus the HTTP client can make back-to-back requests for the referenced objects. 
2. When the server receives the requests, it can send the objects back-to-back. If all the requests are sent back-to-back and all the responses are sent back-to-back, then only one RTT is expended for all the referenced objects (rather than one RTT per referenced object when pipelining isn't used). 
3. Furthermore, the pipelined TCP connection hangs for a smaller fraction of time. 

In addition to reducing RTT delays, persistent connections (with or without pipelining) have a smaller slow-start delay than non-persistent connections.

This is because that after sending the first object, the persistent server does not have to send the next object at the initial slow rate since it continues to use the same TCP connection. Instead, the server can pick up at the rate where the first object left off. 

The interested reader is also encouraged to see [Heidemann 1997] and [Nielsen 1997].

HTTP Message Format(HTTP Transaction)
The HTTP specifications 1.0 [RFC 1945] and 1.1 [RFC 2068] define the HTTP message formats. There are two types of HTTP messages, request messages and response messages, both of which are discussed below.

Figure 27.12 illustrates the HTTP transaction between the client and server. Although HTTP uses the services of TCP, HTTP itself is a stateless protocol.

1. The client initializes the transaction by sending a request message. 
2. The server replies by sending a response.

Messages
The formats of the request and response messages are similar; both are shown in Figure 27.13. A request message consists of:

1. a request line, 
2. a header, and sometimes 
3. a body.

A response message consists of:

1. a status line, 
2. a header, and 
3. sometimes a body.

Request and Status Lines

for a error the rest is wipe out. If someone has a (few days old) copy of that post please let me know ... Sorry for that

irssi + screen setup, features: a recap

e

So...What's it All About? maybe retro-computing?

Initially i had used (mostly offline) newsgroups as my main discussion mean  because back then was a period that Internet was accessible for all also without contracts but i had to pay my ISP  1€ every 2 hours of connection i guess   trough a 56 Kbps modem(in fact mostly used till 45Kbps).  When Adsl comes(i guess the first 2K)  i start cope with IRC.
 
Irssi was my second textual client after ircII and i love it. The real power of irssi is in his flexibility (alias his config file ~/.irssi/config). Generally speaking a textual client like irssi(relativelly to a Gui irc client) seems more finelly customizable and dynamic.
The first time out of the box a textual client is nothing special for a newbie. Power comes after one spend some time to know about the  IRC  system and start configure irssi. Out there are some reviews and howto's about irssi.
Here's another one diary based on my personal experience on irssi on a Ubuntu 10.4 LTS system (anyway irssi is a multiplatform software). Enough let's go on


Installation and basic use
For install only irssi .deb's users can follow Andrew's guide.
For screen + irssi instead follow the  Matt Sparks's guide or/and Lizzie's guide 


Let's go a bit deeper
Irssi’s /channel, /network, /server and /connect – What It Means
Irssi Handling JOINS/PARTS/QUITS

Resources

1. Aaron Toponce's posts
2. irc-in-extensive-view
3. A list of all Internet Relay Chat commands (from IETF RFCs 1459 and 2812)
4. CTCP spec

to be continued... ;-)