This section introduces the transport layer and the two standard protocols that run on it: TCP and UDP. This is the first layer to actually address an aspect of connection, namely that between two processes (note that these don't necessarily have to be on separate computers, they could be two local processes). We will also introduce packet sniffers, a very important class of tools in network security. This section assumes you have already read StackIntro.

Before delving into the transport layer, let's first examine an important collection of documents that has shaped the internet as we know it. RFCs, or Request For Comments, are generally proposals for a new concept in internet technology. These cover most of the protocols and standards in use today, and number in the thousands. Each RFC has a unique number identifier. For example, the TCP protocol is defined in RFC 793. Everything we discuss about TCP in this section and much more can be found somewhere in that document, including packet design, the state diagram, and motivation for its design. A database of all RFCs is maintained at [1].

To understand the transport layer, we must first define ports and sockets. The terms are often used interchangeably, which is not wholly correct. A socket is a numbered identifier used by an operating system to provide networking. It can be bound to a single process, which then allows the OS to pass data to and from it. This is only an abstract concept --there aren't thousands of little ports built into your computer or sitting around idly in memory. A port is also a numbered identifier, but is defined in terms of the protocol using it, namely either TCP or UDP.

The distinction is in which side we're looking at it from. An application is bound to a socket, not a port, since it is interfacing with the OS. The OS does not just use TCP by default. When binding to a socket we CAN and generally DO specify a protocol. However, sockets can also be used to communicate between processes on a local machine without resorting to any protocol beyond the application layer. Generally we will refer to ports, but remember to use sockets when writing networked applications.

TCP stands for Transmission Control Protocol. This protocol utilizes the concept of an "established connection" through means of a three-way handshake, which occurs before any payload data is transmitted. This handshake is the transmitting of three packets (we'll define a packet in just a moment): a SYN packet, a SYN/ACK packet, and an ACK packet. SYN is short for "synchronize", and is sent by the client. As we will see, data may arrive out of order, so to reassemble it, each chunk must be numbered. SYN informs the server which number the client is going to begin transmitting data on. SYN/ACK stands for "syncronize/acknowledge", and, as the name suggests, both acknowledges that the server has received the client's SYN, and set's the server's synchronize number. Finally the ACK is the client's acknowledgment of the server's sync number. Once this process is completed, the connection is "established", since both parties can be assured that the other is ready and waiting for them. The connection remains until one party sends a "reset" packet or both send a "finish" packet.

When transmitting data via the internet, we rarely do it all in one big chunk. There are many reasons for this. First, we generally want to guarantee our data is arriving at its destination (though not always --see UDP below), and that it has arrived un-altered. If we wait until we've transmitted an entire 100MB file before checking, we're going to be very upset when we find out it hasn't all arrived or *has* but has been corrupted in transit. Smaller pieces make it easier to monitor the connection and retransmit as necessary. Second, a wire or any other physical medium has a limited amount of data that can be passed over it at any time. If data was transmitted in a constant stream, a few lucky users would get very fast transfer speeds for a while, while other ones would be forced to wait for some time (hours or days if they're especially unlucky) just to check their email.

The transport, network and link layers all divide data into chunks (meaning we often get chunks of chunks). On the transport and network layer, these chunks are called packets. Note that while they have the same name, they serve different purposes. A packet is divided into sections: a header and a data section, the header containing some information on what to do with its data. This is much like an envelope. An envelope has information on who to send its contents to, a date, and optionally an "air mail" or "handle with care" stamp. Like a postal envelope, if a packet's header has missing or incorrect information, it can't be delivered correctly.

The TCP packet header contains several sections including source and destination port numbers, sequence and acknowledgment numbers, a checksum for error detection, and several single bit "flags" that can be set. It also contains other information that we will not cover. A more detailed description can be found in [2]. Our SYN, SYN/ACK, and ACK packets have an empty data section, but have sequence and acknowledgment numbers (except for SYN, which has do acknowledgment number) and set SYN and/or ACK flags corresponding to the current step. Other important flags are RST (reset) and FIN (finish).

For each packet one party receives, it sends a response packet with acknowledgment number corresponding to the received packet's sequence number (note that the ACK flag is set only for setting up the communication, not for each acknowledgment). Because it verifies that all data arrives, TCP is called a reliable protocol.

TCP also has a concept of a window, which affects which sequence numbers can be received at a given moment. This reduces overhead, since a party can send bunches of packets rather than waiting for each individual acknowledgment. Say for example party A sends packets 1-10 to party B. Unfortunately packet 1 never arrives. Party B doesn't want to just discard the nine packets it received however. The implementation must have some method for dealing with this. There are more than one, and they're rather complicated, so we'll skip them. The curious and daring reader should go to [3] for a very technical and detailed look at this subject.

UDP is the User Datagram Protocol. Like TCP, it divides data into packets with a header and data section. Unlike TCP however, it has no notion of an established connection or a window. This means the protocol has no checks that data arrives, so we say it is an unreliable protocol. The header is also much simpler, containing only a source and destination port number, a checksum, and a length. Despite its simplicity though, this is a very important protocol and very common today.

At first UDP may seem primitive when compared to TCP. While it is unreliable however, it IS significantly faster. While windowing *reduces* overhead in TCP, overhead is still inherently built in. This is non-existent in UDP. We find that there are many situations where raw speed is more advantageous than reliability. Most of these are media related. For example, while watching streaming video, our eyes won't catch a few lost frames of animation, but we WILL pick up on a half-second jitter while we wait for a single missed packet. As the internet becomes a continuously more media-rich environment, UDP's usefulness only increases.

Then again, in situations where all data is essential, UDP can be disastrous. An unfortunately corrupted or lost instant message packet could lead to an unpleasant misunderstanding between friends. A dropped packet in an encrypted communication generally makes the entire message indecipherable. It should be clear that understanding both protocols' strengths and weaknesses is essential for their effective use.

A packet sniffer is a tool attempts to examine every packet that passes through a specified network interface. This, like many of the tools we will examine, can be used for both good and evil. Administrators can use it to monitor their network for suspicious traffic or to compile statistical information (i.e. "when does traffic peak?" or "what protocols are most common?"). Malicious users on the other hand might use it for spying purposes.

A network device usually only keeps packets addressed to it. This is an issue of practicality, since passing someone else's packet up the stack wastes valuable computer resources. This means under normal usage, a packet sniffer will only receive information addressed to the computer it's running on. Usually this isn't horribly interesting, since we already have this information. Instead we want ALL packets our network interface receives. Most modern devices can be put in promiscuous mode, i.e. a mode that accepts everything.

Note that won't necessarily mean you'll see all packets on a network. As both a speed and a security measure, most sizable networks these days use switches between computers. Switches actively choose where to send traffic, so if you're connected to one, you'll generally still only see your own traffic. Also, if you *are* receiving a lot of traffic, its possible that your interface will not be able to read them as fast as they come.

Ethereal is a common open-source packet sniffer with some powerful features. Like most sniffers, it offers logging and filter abilities. It is also able to recognize and translate a large number of common application layer protocols, making it quite useful for inspecting data. For detailed usage instructions, the docs section at [4] is very helpful, but basic functionality is not hard to figure out.

1) http://www.rfc-editor.org/
2) Stevens, W. R., TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley, 1994
3) Kurose, J. F. & Ross, K. W., Computer Networking: A Top-down Approach Featuring the Internet,
Addison-Wesley, 2003
4) http://www.ethereal.com/

http://cs.marlboro.edu/ courses/ fall2006/networking/ private/ tableofcontents/ TransportLayer
last modified Tuesday December 5 2006 4:52 pm EST