The transport layer is best known for TCP which is a connection-oriented protocol. The TCP protocol in this layer keeps track of the segments and retransmits those segments that fail in transit. The transport layer protocols can also provide for the acknowledgment of successful data transmission. Most chunks of data are much too large for a single frame so the chunk of application data must be disassembled into smaller chunks of data before they are sent across the network. The target system that receives all of the frames must be able to recognize the incoming packets as one data transmission and reassemble the packets correctly based on information included in the packets by the sending system. In addition, the receiving system must verify that all the packets for that piece of data arrived correctly and inform the sending system that there are no errors.
Transport Layer Protocols
The OSI model defines five classes of transport protocols: TP0, providing the least error recovery, to TP4, which is designed for less reliable networks, such as the Internet. TP4 is closest to the TCP Protocol. The TCP protocol is used on less reliable networks because the protocol itself is used to ensure that the packets are all delivered and are error-free. When packets are missing or contain errors, the TCP protocol will inform the sender that the packets need to be retransmitted. When using less reliable protocols such as UDP, it is up to the application to determine if the packets were delivered and are error-free. UDP provides a “best-effort” delivery. Keep in mind that TCP/IP is not the only protocol suite that can be mapped in the OSI model. The most common protocols found in the transport layer from various suites are TCP (Transmission Control Protocol), UDP (User Datagram Protocol), ATP (AppleTalk Transaction Protocol), and SPX (Sequenced Packet Exchange). There are many others, but these are the most commonly used. When working with TCP/IP, with regard to connection-oriented (TCP) and connection-less (UDP) protocols, there may be some confusion as to the differences between them. The best analogy that can be used to discuss the differences is the US mail delivery system. Priority mail would be the equivalent to TCP. When you ship an item as priority mail, the item is tracked and in some cases, insured. While the priority item is in transit, it can be easily tracked with regard to its last known location and delivery time. The delivery date and time are recorded as well as the receiver’s signature, in some cases. If the package does not arrive or is lost, you can determine where the package was last and who was handling the package. In addition, you can determine if the package was damaged in some way. In the case of sending regular mail, that process can be compared to sending packets over the network using UDP. UDP packets are sent with no guarantee that they will be delivered, nor will the sender know if the packets reached the destination, much like when you send a letter in the mail. You have to depend on the receiver to inform you whether or not there was a problem with receiving your package, if they even knew that they were expecting a package. So if TCP is so great, why isn’t all of the communication on a TCP/IP network required to use TCP? Well, depending on the size and content of the data you are transmitting, the cost of the connection itself (three-way handshake, maintaining the connection, etc..) may be too costly in terms of resources. It may just be easier to require that the application take care of this responsibility. For example, if the sending application has not heard back from the receiving application, you can just have the application assume the data never reached the recipient and resend the information. In addition, some applications may not know to who they are sending the packet. For example, in the case of DHCP packets, when a TCP/IP host first comes on the network, it will send out UDP broadcast packets to any available DHCP server. When a TCP/IP host is first connected to a network, it does not have an IP until it leases one from a DHCP server, or is statically configured with one. So, without an IP and no knowledge of the network it is connected to, it cannot initiate communication with a network peer using a connection-oriented protocol.
