TCP/IP

A protocol is simply an agreement between two parties that specifies how to do something.

Communications protocols are refered to by the level(s) of the OSI reference model that they service. The OSI layers are

Application
Presentation
Session
Transport
Network
Data Link
Physical

TCP/IP does not exactly match this model. TCP is a higher level protocol that loosely matches up with the Session and Transport layers of the OSI model. IP is a lower level protocol that is loosely tied to the Network and Data Link layers.

IP is refrred to as a "best effort" protocol. That means that it will do its best to deliver IP datagrams, but that if they do arrive corrupted, or do not arrive at all, IP does not do anything about it. It is up to TCP to ensure that data sent is actually received at the destination, and in the proper sequence.

TCP/IP support is built-in to Windows 95, Windows NT, and Unix. It must be added to DOS and Windows 3.1 in the form of software packages referred to as "TCP/IP Suites" or "TCP/IP Stacks".

Applications must be written to utilize TCP (note that they do not need to be written for IP: only the TCP software communicates with the IP software. This is because the protocols are designed to be modular "black boxes". Examples of TCP applications are FTP, Web Browsers, Telnet, and email.

IP is refered to as a "connectionless protocol", while TCP is a "connection-oriented protocol". To illustrate this, consider a letter versus a telephone call. When you write a letter, you place it in an envelope with a destination address and a source (return) address. You then drop it in a mailbox and that's the last you see of it unless and until the receipient writes you back. This is similar to an IP datagram. When you make a phone call, a circuit is established by the phone company from your phone, directly to the telephone you are dialing. The circuit stays up for the duration of the connection and is used solely by the parties at each end of the connection (unless the FBI has a wiretap). When the conversation ends, you hang-up the phone, signaling the Telco that it is okay for them to tear the circuit down so that its various component circuits and switches may be used by someone else for a call. This is analogous to a TCP session. The connection stays up for the duration of the session, at which time it is torn down, allowing access for someone else. The TCP "port number" is in this case the counterpart of the telephone number in a phone call.

With a letter, you don't know if the receipient receives the letter or not. With a telephone call you find out immediately whether you dialed a wrong-number, and then you redial. The same is true for IP and TCP. With IP, there is no notification that your datagram arrived or not, or if it did arrive, was it damaged in transit. TCP on the other hand, keeps track of the time that has elapsed since it sent a TCP segment and applies a time interval to determine whether it should resend the data after assuming that it never arrived. It also can receive explicit notification from the other end of the TCP connection that the data arrived, but that it was damaged. In this case TCP will resend it.

IP works well as a connectionless protocol that does no error checking or error correcting only because it sends its traffic over relatively error-free digital circuits. When the infrequent error does occur however, it is up to TCP to detect it and act accordingly. Also, different transmission media (fiber, copper, microwave, satellite relay) have different propagation delay times. A file you are transferring via FTP may have some of its content transmitted over all of these media types in some circumstances. Since the slowest is satellite relay, some packets sent first may arrive after other packets sent much later, therefore arriving at the destination out of sequence. TCP will reorder the packets so that they appear in the same order in which they were transmitted.