The transport layer is responsible for providing reliable data transfer services to the upper layers of the OSI stack. It is at this stage that we start to consider actually sending the data. This layer also involves the segmentation/desegmentation of data into smaller chunks. It is very rare that a network will be configured to take a large payload from one source node to a destination node. This is why we will segment the overall data payload into smaller pieces. This is also the first place in the stack where we start to apply some addressing so the destination node understands which listening receiver the data is intended to reach. This address comes in the form of a port number. The destination node may be simultaneously listening for (or have the ability to connect to) different network services and the way we distinguish between these services is by giving them a different port number. For example, web server usually listen on port 80 where email servers will listen on port 25.
Connection-Orientated vs Connection-less Protocols
There are essentially two flavours of protocols that exist in this layer. Connection-orientated protocols will involve communications that must be received without data loss with the data arriving in a certain sequence. Transmission of legal or financial documents would fit into this category. The applications at both sending and receiving end have an expectation that the documents will be received in full and with the correct format. An example of a connection orientated protocol is the TCP (Transmission Control Protocol) protocol which makes up the TCP out of the TCP/IP suite. The TCP sender will break down data into TCP segments. It will send each of these across what may possibly be an unreliable network. Due to the nature of packet switching networks, although each of these packets may have been sent in sequence it is possible that they may get routed differently and arrive out of sequence. At the receiving end, the TCP receiver will take the data re-sequence it if the packets have been received in the wrong order and also send a request back to the source, if any of the packets are missing.
Connection-less protocols, such as the UDP (User Datagram Protocol) don’t have the same level of error-checking and control. In a connection-less transmission, packets are sent in sequence but they are sent with the best effort approach. There is no checking to see if the packets were received and no resequencing of packets at the destination node. So why use connection-less? Well, not all applications need data transmissions to be without loss. For example, if you are streaming online video and the packets for that live video are received slightly out of sequence, or the occasional packet is dropped; this doesn’t make much difference to the overall viewing experience at the destination node. A huge benefit of this approach is that the protocol is much less chatty, therefore can provide better performance with less bandwidth.
The Pirate Ship: To continue our analogy, let’s imagine that I have a transport manager in my office and Rich has a transport manager in his office. In this case my transport manager is going to use the connection-orientated TCP protocol. This is because he needs to break down the Lego bricks into segments (individual blocks) and send them reliably across to the destination. All the blocks must be received at the other end and they must be reassembled in the right sequence in order to reconstruct the ship. To do this he takes each individual block and puts it in a small parcel, he then writes on the parcel the protocol (TCP), a port number and sequence number. This is where the transport manager’s responsibility ends, he will listen to find out if any segments were not received and then resend these, but for the actual movement of the parcels other entities further down the stack will take over.