Subnet Mask

A mask used to determine what subnet an IP address belongs to. An IP address has two components, the network address and the host address. For example, consider the IP address 150.215.017.009. Assuming this is part of a Class B network, the first two numbers (150.215) represent the Class B network address, and the second two numbers (017.009) identify a particular host on this network.

Subnetting enables the network administrator to further divide the host part of the address into two or more subnets. In this case, a part of the host address is reserved to identify the particular subnet. This is easier to see if we show the IP address in binary format. The full address is:

10010110.11010111.00010001.00001001

The Class B network part is:

10010110.11010111

and the host address is

00010001.00001001

If this network is divided into 14 subnets, however, then the first 4 bits of the host address (0001) are reserved for identifying the subnet.

The subnet mask is the network address plus the bits reserved for identifying the subnetwork. (By convention, the bits for the network address are all set to 1, though it would also work if the bits were set exactly as in the network address.) In this case, therefore, the subnet mask would be 11111111.11111111.11110000.00000000. It's called a mask because it can be used to identify the subnet to which an IP address belongs by performing a bitwise AND operation on the mask and the IP address. The result is the subnetwork address:

Subnet Mask	255.255.240.000	11111111.11111111.11110000.00000000
IP Address	150.215.017.009	10010110.11010111.00010001.00001001
Subnet Address	150.215.016.000	10010110.11010111.00010000.00000000

The subnet address, therefore, is 150.215.016.000.

IP address

- This definition is based on Internet Protocol Version 4. See Internet Protocol Version 6 (IPv6) for a description of the newer 128-bit IP address. Note that the system of IP address classes described here, while forming the basis for IP address assignment, is generally bypassed today by use of Classless Inter-Domain Routing (CIDR) addressing.

In the most widely installed level of the Internet Protocol (IP) today, an IP address is a 32-bit number that identifies each sender or receiver of information that is sent in packets across the Internet. When you request an HTML page or send e-mail, the Internet Protocol part of TCP/IP includes your IP address in the message (actually, in each of the packets if more than one is required) and sends it to the IP address that is obtained by looking up the domain name in the Uniform Resource Locator you requested or in the e-mail address you're sending a note to. At the other end, the recipient can see the IP address of the Web page requestor or the e-mail sender and can respond by sending another message using the IP address it received.

An IP address has two parts: the identifier of a particular network on the Internet and an identifier of the particular device (which can be a server or a workstation) within that network. On the Internet itself - that is, between the router that move packets from one point to another along the route - only the network part of the address is looked at.

The Network Part of the IP Address

The Internet is really the interconnection of many individual networks (it's sometimes referred to as an internetwork). So the Internet Protocol (IP) is basically the set of rules for one network communicating with any other (or occasionally, for broadcast messages, all other networks). Each network must know its own address on the Internet and that of any other networks with which it communicates. To be part of the Internet, an organization needs an Internet network number, which it can request from the Network Information Center (NIC). This unique network number is included in any packet sent out of the network onto the Internet.

The Local or Host Part of the IP Address

In addition to the network address or number, information is needed about which specific machine or host in a network is sending or receiving a message. So the IP address needs both the unique network number and a host number (which is unique within the network). (The host number is sometimes called a local or machine address.)

Part of the local address can identify a subnetwork or subnet address, which makes it easier for a network that is divided into several physical subnetworks (for examples, several different local area networks or ) to handle many devices.

IP Address Classes and Their Formats

Since networks vary in size, there are four different address formats or classes to consider when applying to NIC for a network number:

• Class A addresses are for large networks with many devices.
• Class B addresses are for medium-sized networks.
• Class C addresses are for small networks (fewer than 256 devices).
• Class D addresses are multicast addresses.

The first few bits of each IP address indicate which of the address class formats it is using. The address structures look like this:

Class A

0

Network (7 bits)

Local address (24 bits)

Class B

10

Network (14 bits)

Local address (16 bits)

Class C

110

Network (21 bits)

Local address (8 bits)

Class D

1110	Multicast address (28 bits)

The IP address is usually expressed as four decimal numbers, each representing eight bits, separated by periods. This is sometimes known as the dot address and, more technically, as dotted quad notation. For Class A IP addresses, the numbers would represent "network.local.local.local"; for a Class C IP address, they would represent "network.network.network.local". The number version of the IP address can (and usually is) represented by a name or series of names called the domain name.

The Internet's explosive growth makes it likely that, without some new architecture, the number of possible network addresses using the scheme above would soon be used up (at least, for Class C network addresses). However, a new IP version, IPv6, expands the size of the IP address to 128 bits, which will accommodate a large growth in the number of network addresses. For hosts still using IPv4, the use of subnets in the host or local part of the IP address will help reduce new applications for network numbers. In addition, most sites on today's mostly IPv4 Internet have gotten around the Class C network address limitation by using the Classless Inter-Domain Routing (CIDR) scheme for address notation.

Relationship of the IP Address to the Physical Address

The machine or physical address used within an organization's local area networks may be different than the Internet's IP address. The most typical example is the 48-bit Ethernet address. TCP/IP includes a facility called the Address Resolution Protocol (ARP) that lets the administrator create a table that maps IP addresses to physical addresses. The table is known as the ARP cache.

Static versus Dynamic IP Addresses

The discussion above assumes that IP addresses are assigned on a static basis. In fact, many IP addresses are assigned dynamically from a pool. Many corporate networks and online services economize on the number of IP addresses they use by sharing a pool of IP addresses among a large number of users. If you're an America Online user, for example, your IP address will vary from one logon session to the next because AOL is assigning it to you from a pool that is much smaller than AOL's base of subscribers.

Static IP Address v/s Dynamic IP Address

A static IP address is a number (in the form of a dotted quad) that is assigned to a computer by an Internet service provider (ISP) to be its permanent address on the Internet. Computers use IP addresses to locate and talk to each other on the Internet, much the same way people use phone numbers to locate and talk to one another on the telephone. When you want to visit whatis.com, your computer asks a domain name system (DNS) server (think telephone information operator) for the correct dotted quad number (think phone number) for whatis.com and your computer uses the answer it receives to connect to the whatis.com server.

It would be simple if every computer that connects to the Internet could have its own static IP number, but when the Internet was first conceived, the architects didn't foresee the need for an unlimited number of IP addresses. Consequently, there are not enough IP numbers to go around. To get around that problem, many Internet service providers limit the number of static IP addresses they allocate, and economize on the remaining number of IP addresses they possess by temporarily assigning an IP address to a requesting Dynamic Host Configuration Protocol (DHCP) computer from a pool of IP addresses. The temporary IP address is called a dynamic IP address.

Requesting DHCP computers receive a dynamic IP address (think temporary phone number) for the duration of that Internet session or for some other specified amount of time. Once the user disconnects from the Internet, their dynamic IP address goes back into the IP address pool so it can be assigned to another user. Even if the user reconnects immediately, odds are they will not be assigned the same IP address from the pool. To keep our telephone telephone analogy going, using a dynamic IP address is similar to using a pay phone. Unless there is a reason to receive a call, the user does not care what number he or she is calling from.

There are times, however, when users who connect to the Internet using dynamic IP wish to allow other computers to locate them. Perhaps they want to use CU-SeeMe or use a VoIP application to make long distance phone calls using their IP connection. In that case, they would need a static IP address. The user has two choices; they can contact their ISP and request a static IP address, or they can use a dynamic DNS service. Either choice will probably involve an additional monthly fee.

Using a dynamic DNS service works as if there was an old-fashioned telephone message service at your computer's disposal. When a user registers with a DNS service and connects to the Internet with a dynamic IP address, the user's computer contacts the DNS service and lets them know what IP address it has been assigned from the pool; the service works with the DNS server to forward the correct address to the requesting DHCP computer. (Think of calling the message service and saying "Hi. I can be reached at 435.44.32.111 right now. Please tell anyone who tries to reach me to call that number.) Using a dynamic DNS service to arrange for computers to find you even though you are using a dynamic IP address is the next-best thing to having a static IP.

IPv6, which has also been called "IPng" (IP Next Generation), lengthens IP addresses from 32 bits to 128 bits and increases the number of available IP addressess significantly, making static IP addresses easier and less expensive to obtain and maintain.

HTTP

Http Request Message Format

The client initiates an HTTP session by opening a TCP connection to the HTTP server with which it wishes to communicate. It then sends request messages to the server, each of which specifies a particular type of action that the user of the HTTP client would like the server to take. Requests can be generated either by specific user action (such as clicking a hyperlink in a Web browser) or indirectly as a result of a prior action (such as a reference to an inline image in an HTML document leading to a request for that image.)

HTTP requests use a message format that is based on the generic message format described in the preceding topic, but specific to the needs of requests. The structure of this format is as follows (see Figure 317):

Figure 317: HTTP Request Message Format

This diagram shows the structural elements of an HTTP request and an example of the sorts of headers a request might contain. Like most HTTP requests, this one carries no entity, so there are no entity headers and the message body is empty. See Figure 318 for the HTTP response format.

Http Response Message Format

Up and down; east and west; black and white; yin and yang. Well, you get the idea. Each request message sent by an HTTP client to a server prompts the server to send back a response message. Actually, in certain cases the server may in fact send two responses, a preliminary response followed by the real one. Usually though, one request yields one response, which indicates the results of the server's processing of the request, and often also carries an entity (file or resource) in the message body.

Like requests, responses use their own specific message format that is based on the HTTP generic message format. The format, shown in Figure 318, is:

Figure 318: HTTP Response Message Format

This figure illustrates the construction of an HTTP response, and includes an example of both message headers and body. The status code “200” indicates that this is a successful response to a request; it contains a brief text HTML entity in the message body. See Figure 317 for the HTTP request format.

Http Methods A request sent by a client to a server obviously… requests that the server do something. All client/server protocols provide a way for the client to prompt the server to take action, generally by having the client give the server a series of commands. HTTP, in contrast, does not have commands but rather methods. Each client request message begins with the specification of the method that is the subject of the request. What is the difference between a method and a command? In practical terms, nothing; they are the same. So why does HTTP use the term “method” instead of “command”? Good question. J The answer can be found in the abstract of the standard defining HTTP/1.0, RFC 1945. It states, in part, that HTTP is: “a generic, stateless, object-oriented protocol which can be used for many tasks…” In highly simplified terms, object-oriented programming is a technique in which software modules are described not as sets of procedures but as objects that possess attributes. These modules send messages to each other to communicate, and to cause actions to be performed, where the action taken depends on the nature of the object. In object-oriented programming, the procedures each object can perform are called methods. HTTP is considered to be object-oriented because in many cases, the action taken by a server depends on the object that is the subject of the request. For example, if you ask a server to retrieve a text document, it will send that document, but if you ask for a directory, the server may instead return a default document for that directory. In contrast, a request that specifies the name of a program will result in the program being executed and its output returned (as opposed to the program’s source code being returned.)

URL v/s URI v/s URN

> This is a short list of URL's
>
> http://www.google.com
> http://www.msn.com
> http://www.irc2k.com
>
> This is a short list of URI's
>
> http://www.google.com/index.html
> http://www.irc2k.com/irc2k/index3.php

Both are lists of URIs and URLs, because by definition a URL
is a URI. The term 'URI', as it is widely employed in
Internet specifications today, comprises the two terms 'URL'
and 'URN' (Locator and Name); that is, 'URI' is the term given
to the superset of URLs and URNs. All three are discussed
formally in RFC3986: 1.1.3 <http://www.ietf.org/rfc/rfc3986>
and in greater detail in <http://www.ietf.org/rfc/rfc3305>.

The presence or not of an explicit path doesn't determine
whether a URI is a URL. The determining factor is whether the
URI specifies the 'location' of the resource. (Some URIs
don't, and aren't URLs; e.g., *.) By
that token, all HTTP URIs are URLs, since they specify the
'primary access mechanism', namely HTTP.

* This URN names /The Cambridge Encyclopedia of the English
Language/ by David Crystal. The URN namespace ISBN is
documented in RFC3187 <http://www.ietf.org/rfc/rfc3187>.

Transitional v/s Strict Markup (HTML v/s XHTML)

When promoting web standards, standardistas often talk about XHTML as being more strict than HTML. In a sense it is, since it requires that all elements are properly closed and that attribute values are quoted. But there are two flavours of XHTML 1.0 (three if you count the Frameset DOCTYPE, which is outside the scope of this article), defined by the Transitional and Strict DOCTYPEs. And HTML 4.01 also comes in those flavours.

The names reveal what they are about: Transitional DOCTYPEs are meant for those making the transition from older markup to modern ways. Strict DOCTYPEs are actually the default – the way HTML 4.01 and XHTML 1.0 were constructed to be used.

A Transitional DOCTYPE may be used when you have a lot of legacy markup that cannot easily be converted to comply with a Strict DOCTYPE. But Strict is what you should be aiming for. It encourages, and in some cases enforces, the separation of structure and presentation, moving the presentational aspects from markup to CSS. From the HTML 4 Document Type Definition:

This is HTML 4.01 Strict DTD, which excludes the presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required.

An additional benefit of using a Strict DOCTYPE is that doing so will ensure that browsers use their strictest, most standards compliant rendering modes.

Tommy Olsson provides a good summary of the benefits of using Strict over Transitional in Ten questions for Tommy Olsson at Web Standards Group:

In my opinion, using a Strict DTD, either HTML 4.01 Strict or XHTML 1.0 Strict, is far more important for the quality of the future web than whether or not there is an X in front of the name. The Strict DTD promotes a separation of structure and presentation, which makes a site so much easier to maintain.

For those looking to start using web standards and valid, semantic markup, it is important to understand the difference between Transitional and Strict DOCTYPEs. For complete listings of the differences between Transitional and Strict DOCTYPEs, see XHTML: Differences between Strict & Transitional, Comparison of Strict and Transitional XHTML, and XHTML1.0 Element Attributes by DTD.

Some of the differences are more likely than others to cause problems for developers moving from a Transitional DOCTYPE to a Strict one, and I’d like to mention a few of those.

Elements that are not allowed in Strict DOCTYPEs

• center
• font
• iframe
• strike
• u

Attributes not allowed in Strict DOCTYPEs

• align (allowed on elements related to tables: col, colgroup, tbody, td, tfoot, th, thead, and tr)
• language
• background
• bgcolor
• border (allowed on table)
• height (allowed on img and object)
• hspace
• name (allowed in HTML 4.01 Strict, not allowed on form and img in XHTML 1.0 Strict)
• noshade
• nowrap
• target
• text, link, vlink, and alink
• vspace
• width (allowed on img, object, table, col, and colgroup)

Content model differences

An element type’s content model describes what may be contained by an instance of the element type. The most important difference in content models between Transitional and Strict is that blockquote, body, and form elements may only contain block level elements. A few examples:

• text and images are not allowed immediately inside the body element, and need to be contained in a block level element like p or div
• input elements must not be direct descendants of a form element
• text in blockquote elements must be wrapped in a block level element like p or div

Go Strict and move all presentation to CSS

Something that can be helpful when doing the transition from Transitional to Strict DOCTYPEs is to focus on what each element of the page you are working on is instead of how you want it to look.

Worry about looks later and get the structure and semantics right first.