The TCPIP Protocol Suite

[Previous] [Next]

Whole books have been written about TCP/IP, and justifiably so. Although most administrators don't need to know every detail of programming a TCP connection or what to expect as a return value from a gethostbyname() call, they do need to understand enough to configure the protocol and make it work properly.

The important thing to remember about TCP/IP is that it isn't a single entity. TCP/IP is short for Transmission Control Protocol/Internet Protocol, but these are only two of the protocols included in the TCP/IP suite. There are a variety of other protocols, each with its own specialized area of importance and use.

Another important fact about TCP/IP is that it's everywhere; it isn't controlled by any one company or vendor. Both Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX) and NetBIOS Enhanced User Interface (NetBEUI) are proprietary protocols, each developed and ultimately controlled by an individual vendor. TCP/IP, on the other hand, is an open standard controlled by the Internet Engineering Task Force (IETF) and by the users of the Internet itself in the form of RFCs (requests for comments). Anyone can submit an RFC for consideration and inclusion into the written definitions of the protocols and policies of the Internet and TCP/IP.

Virtually every kind of computer and operating system in use today has TCP/IP available and supports it as a networking protocol. A particular type of computer may use some other, proprietary protocol as well, but when it comes to connecting multiple computers running multiple operating systems across diverse networking hardware and topology, there's really only one way to get there—TCP/IP.

Internet Protocol

IP, or Internet Protocol, is the core protocol of the TCP/IP suite. To quote from RFC 791, "The Internet Protocol is designed for use in interconnected systems of packet-switched computer communication networks." IP performs only one basic function: to deliver a packet of bits (called a datagram) from point A to point B over any network "wire" it happens to encounter along the way.

NOTE

---

The term "wire" is used very loosely here and elsewhere to indicate the actual—usually physical—network connection between two points. In fact, that wire could just as easily be a piece of optical fiber or even a radio or infrared wave. But in all cases it functions as the transmission medium through which the packets travel.

IP doesn't in and of itself know anything about the information in the datagram it carries, nor does it have any provision beyond a simple checksum to ensure that the data is intact or that it has reached its destination. That is left to the other protocols in the TCP/IP suite.

Transmission Control Protocol

TCP, or Transmission Control Protocol, is, in the words of RFC 793 (the defining RFC for the protocol), "a connection-oriented, end-to-end reliable protocol designed to fit into a layered hierarchy of protocols which support multi-network applications." Let's elaborate on some of those terms.

• Connection-oriented TCP provides for the communication of packets between two points, sending the datagram specifically from one computer or device to another.
• End-to-end Each TCP packet designates a specific endpoint as its destination. Packets are passed along the wire and ignored except by the actual endpoint of the packet and any device that needs to direct it.
• Reliable This is the key point of TCP. When a program such as FTP uses TCP for its protocol, the TCP/IP suite takes responsibility for the reliability of the communications. The protocol itself provides for interprocess communication to ensure that packets that are sent out not only get there, but also that they get there in the order in which they were sent. If a packet is missed, the protocol will communicate with the sending device to ensure a resend of the packet.

Because TCP has to create a reliable connection between two devices or processes, each packet involves substantially more overhead than is needed with other, less reliable protocols within the suite. But by the same token, the programmer writing the application that uses TCP doesn't have to include lots of error checking and handshaking in the application itself.

User Datagram Protocol

The User Datagram Protocol (UDP), another protocol in the TCP/IP suite, is a connectionless, transaction-oriented protocol designed to send packets with a minimum of protocol overhead. It provides no guarantee that its intended recipient received the packet, or that packets were received in the order they were sent. UDP is frequently used in broadcast messages where there is no specific intended recipient, such as Boot Protocol (BOOTP) and Dynamic Host Configuration Protocol (DHCP) requests, but it can also be used by applications that prefer to ensure reliable delivery internally rather than in an underlying protocol. It is defined by RFC 768.

Windows Sockets

Windows Sockets (commonly referred to as Winsock) provides a standard way for application programs to communicate with a TCP/IP stack without having to consider any underlying variations in the TCP/IP stack implementation.

In the past there were many different vendors of TCP/IP protocol and applications suites for MS-DOS-based computers, each slightly different from the others. This situation made it extremely difficult to write an application that required TCP/IP and yet would work with all of the TCP/IP implementations that existed. Winsock was designed to get around this problem by providing a uniform set of application programming interface (API) calls that would be the same regardless of the underlying differences in the actual implementation of TCP/IP.

The original Winsock version 1.0 had a fair number of difficulties, and version 1.1 was released soon after its initial implementation. The current version of Winsock supported by Windows 2000 Server is version 2, which provides for full backward compatibility with earlier versions while offering improved functionality and support for additional features and expandability. Note that Winsock 2 has been around since Microsoft Windows NT 4, so applications are now widely available that use this API, something that will become more important as IP version 6 (discussed later in the chapter) is rolled out.

Requests for Comments

Requests for comments (RFCs) come in many guises, but all of them have the same intent and a somewhat similar format. They are designed to provide a way for an extremely diverse group—the users of the Internet—to communicate and agree on the architecture and functionality of the Internet. Some RFCs are official documents of the IETF, defining the standards of TCP/IP and the Internet; others are simply proposals trying to become standards; and others fall somewhere in between. Some are tutorial in nature, while others are quite technical. But all are a way for the Internet, an essentially anarchic entity, to organize and communicate.

There's no need to list all the RFCs here, and you certainly don't need to read them all, but you should know where to find them and be aware of the most important ones. You can find listings of RFCs in a number of places; an excellent site is http://www.cis.ohio-state.edu/hypertext/information/rfc.html. The RFCs at this location are organized and linked logically to make it easy to find the information you're looking for. This site, however, isn't nearly as up-to-date as the official RFC editor site, http://www.rfc-editor.org/. If you want to be sure you've got the most current information, you should use the latter site. Table 13-1 shows some of the most important RFCs and their subject matter.

Table 13-1. Some key RFCs and what they cover

RFC Number	Subject
RFC 768	User Datagram Protocol (UDP)
RFC 791	Internet Protocol (IP)
RFC 792	Internet Control Message Protocol (ICMP)
RFC 793	Transmission Control Protocol (TCP)
RFC 821	Simple Mail Transfer Protocol (SMTP)
RFC 822	Standard for the Format of ARPA Internet Text Messages
RFC 854	Telnet Protocol
RFC 959	File Transfer Protocol (FTP)
RFC 1011	Official Internet Protocols
RFC 1034	DNS Concepts and Facilities
RFC 1035	DNS Implementation and Specification
RFC 1166	Internet Numbers
RFC 1542	Clarifications and Extensions for the Bootstrap Protocol
RFC 1886	DNS Extensions to Support IP version 6
RFC 1918	Address Allocation for Private Internets
RFC 2052	A DNS Resource Record (RR) for Specifying the Location of Services (DNS SRV)
RFC 2131	Dynamic Host Configuration Protocol (DHCP)
RFC 2136	Dynamic Updates in the DNS System (Dynamic DNS)
RFC 2460	Internet Protocol version 6 (IPv6)—Specification