The transport layer is defined in both the Internet protocol suite and the OSI model, although the functions assigned to it differ between the two architectures. In the OSI model, the transport layer is Layer 4 (L4). The layers of the Internet protocol suite are not formally numbered.
Transport layer services are conveyed to an application via a programming interface to the transport layer protocols. The services may include the following features:
Same order delivery: The network layer doesn't generally guarantee that packets of data will arrive in the same order that they were sent, but often this is a desirable feature. This is usually done through the use of segment numbering, with the receiver passing them to the application in order. This can cause head-of-line blocking.
Reliability: Packets may be lost during transport due to network congestion and errors. By means of an error detection code, such as a checksum, the transport protocol may check that the data is not corrupted, and verify correct receipt by sending an ACK or NACK message to the sender. Automatic repeat request schemes may be used to retransmit lost or corrupted data.
Flow control: The rate of data transmission between two nodes must sometimes be managed to prevent a fast sender from transmitting more data than can be supported by the receiving data buffer, causing a buffer overrun. This can also be used to improve efficiency by reducing buffer underrun.
Congestion avoidance: Congestion control can control traffic entry into a telecommunications network, so as to avoid congestive collapse by attempting to avoid oversubscription of any of the processing or link capabilities of the intermediate nodes and networks and taking resource reducing steps, such as reducing the rate of sending packets. For example, automatic repeat requests may keep the network in a congested state; this situation can be avoided by adding congestion avoidance to the flow control, including slow start. This keeps the bandwidth consumption at a low level in the beginning of the transmission, or after packet retransmission.
Multiplexing: Ports can provide multiple endpoints on a single node. For example, the name on a postal address is a kind of multiplexing and distinguishes between different recipients of the same location. Computer applications will each listen for information on their own ports, which enables the use of more than one network service at the same time. It is part of the transport layer in the TCP/IP model, but of the session layer in the OSI model.
Analysis
In the Internet protocol suite, transport-layer protocols provide communication between application programs running on different hosts. TCP uses port numbers to identify application services and to multiplex distinct flows between hosts; UDP similarly defines source and destination port fields, with the destination port interpreted in the context of a particular Internet destination address. A socket address combines an Internet address with a transport-layer port; in TCP, a connection is identified by a pair of sockets.
TCP provides a connection-oriented, reliable, in-order byte-stream service. The application byte stream is carried over the network in TCP segments, each sent as an IP datagram; TCP reliability is based on sequence numbers, checksums, acknowledgments, and retransmission of lost or corrupted segments. TCP also includes flow-control mechanisms based on advertised windows, and TCP endpoints are required to implement basic congestion-control algorithms such as slow start, congestion avoidance, and exponential backoff of retransmission timeouts.
UDP provides a minimal, connectionless, message-oriented transport service. RFC768 describes UDP as providing a procedure for application programs to send messages with a minimum of protocol mechanism, without guarantees of delivery or duplicate protection; applications that require ordered, reliable streams of data are directed to use TCP instead. RFC8085 similarly describes UDP as a minimal, unreliable, best-effort message-passing transport, and notes that applications using UDP may need to implement additional mechanisms for reliability, congestion control, checksums, or other functions depending on their use case.
UDP is also commonly used for multicast and broadcast applications, but such uses complicate congestion control, flow control, and reliability because a sender may transmit to many receivers over heterogeneous paths. The IETF has defined reliable multicast frameworks and building blocks, so reliability is not impossible for multicast applications; rather, it is not provided by UDP itself and must be supplied by the application or by additional protocols.
The OSI connection-mode transport protocol specification defines five classes of transport protocol, designated class 0 (TP0) through class 4 (TP4). Class 0 provides no error recovery and was designed for use over network services that provide error-free connections, while class 4 includes error recovery and can operate over less reliable network services.
Due to protocol ossification, TCP and UDP have been described as the only widely used transport protocols on the Internet. To avoid middlebox intolerance, new transport protocols may mimic the wire image of a tolerated protocol, or be encapsulated in UDP, accepting some overhead. QUIC follows the latter approach: the QUIC specification defines it as a UDP-based transport protocol whose packets are carried in UDP datagrams, while QUIC itself provides connections, streams, reliable delivery, flow control, and congestion control.
↑RUDP is not officially standardized. There have been no standard-related developments since 1999.
↑Excluding data chunk headers and overhead chunks. Without embedded chunks, an SCTP packet is essentially useless.
↑Counted as follows: 12 bytes SCTP header + 16 bytes DATA chunk header or 20 bytes I-DATA chunk header + 16+ bytes SACK chunk. Additional non-data chunks (e.g., AUTH) or headers for additional data chunks, which might easily increase the overhead by 50 bytes or more, are not counted.
ISO/IEC 8073/ITU-T Recommendation X.224, "Information Technology - Open Systems Interconnection - Protocol for providing the connection-mode transport service", defines five classes of connection-mode transport protocols designated class 0 (TP0) to class 4 (TP4). Class 0 contains no error recovery and was designed for use on network layers that provide error-free connections. Class 4 is closest to TCP, although TCP contains functions, such as the graceful close, which OSI assigns to the session layer. All OSI connection-mode protocol classes provide expedited data and preservation of record boundaries. Detailed characteristics of the classes are shown in the following table:
Service
TP0
TP1
TP2
TP3
TP4
Connection-oriented network
Yes
Yes
Yes
Yes
Yes
Connectionless network
No
No
No
No
Yes
Concatenation and separation
No
Yes
Yes
Yes
Yes
Segmentation and reassembly
Yes
Yes
Yes
Yes
Yes
Error recovery
No
Yes
No
Yes
Yes
Reinitiate connection (if an excessive number of PDUs are unacknowledged)
No
Yes
No
Yes
No
Multiplexing and demultiplexing over a single virtual circuit
No
No
Yes
Yes
Yes
Explicit flow control
No
No
Yes
Yes
Yes
Retransmission on timeout
No
No
No
No
Yes
Reliable Transport Service
No
Yes
No
Yes
Yes
There is also a connectionless transport protocol, specified by ISO/IEC 8602/ITU-T Recommendation X.234.
↑"RFC 8200". Retrieved June 15, 2025. Unlike IPv4, the default behavior when UDP packets are originated by an IPv6 node is that the UDP checksum is not optional.
