Transport layer

Four labeled stacked blocks. The blue block labeled "transport" is the second from the top.
The transport layer in the Internet protocol stack

In computer networking, the transport layer is an abstraction layer in the Internet protocol suite and the OSI model. The protocols of this layer provide end-to-end communication services for applications.[1]:§1.1.3 It can provide services such as connection-oriented communication, reliability, flow control, and multiplexing.

The details of implementation and semantics of the transport layer of the Internet protocol suite,[1] which is the foundation of the Internet, and the OSI model of general networking are different. The protocols in use today in this layer for the Internet all originated in the development of TCP/IP. In the OSI model, the transport layer is often referred to as Layer 4, or L4,[2] while numbered layers are not used in TCP/IP.

The best-known transport protocol of the Internet protocol suite is the Transmission Control Protocol (TCP). It is used for connection-oriented transmissions, whereas the connectionless User Datagram Protocol (UDP) is used for simpler messaging transmissions. TCP is the more complex protocol, due to its stateful design, incorporating reliable transmission and data stream services. Together, TCP and UDP comprise essentially all traffic on the Internet and are the only protocols implemented in every major operating system. Additional transport layer protocols that have been defined and implemented include the Datagram Congestion Control Protocol (DCCP) and the Stream Control Transmission Protocol (SCTP).

Services

Transport layer services are conveyed to an application via a programming interface to the transport layer protocols. The services may include the following features:[4]

  • Connection-oriented communication:[5] It is normally easier for an application to interpret a connection as a data stream rather than having to deal with the underlying connection-less models, such as the datagram model of the User Datagram Protocol (UDP) and of the Internet Protocol (IP).
  • 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

في مجموعة بروتوكولات الإنترنت، توفر بروتوكولات طبقة النقل الاتصال بين برامج التطبيقات التي تعمل على مضيفات مختلفة. يستخدم بروتوكول TCP أرقام المنافذ لتحديد خدمات التطبيقات ودمج تدفقات البيانات المختلفة بين المضيفات؛ وبالمثل، يُحدد بروتوكول UDP حقول منافذ المصدر والوجهة، حيث يُفسر منفذ الوجهة في سياق عنوان وجهة إنترنت محدد. [ 6 ] [ 7 ] يجمع عنوان المقبس بين عنوان إنترنت ومنفذ طبقة النقل؛ في بروتوكول TCP، يُحدد الاتصال بواسطة زوج من المقابس. [ 8 ]

يوفر بروتوكول TCP خدمة تدفق بيانات بايتات موثوقة ومرتبة، تعتمد على الاتصال. يُنقل تدفق بيانات التطبيق عبر الشبكة في مقاطع TCP، يُرسل كل منها كحزمة بيانات IP. وتعتمد موثوقية TCP على أرقام التسلسل، ومجاميع التحقق، وإشعارات الاستلام، وإعادة إرسال المقاطع المفقودة أو التالفة. [ 6 ] [ 9 ] كما يتضمن TCP آليات للتحكم في التدفق تعتمد على النوافذ المُعلنة، ويُشترط على نقاط نهاية TCP تطبيق خوارزميات أساسية للتحكم في الازدحام، مثل البدء البطيء، وتجنب الازدحام، والتراجع الأسي لمهلات إعادة الإرسال. [ 10 ]

يوفر بروتوكول UDP خدمة نقل رسائل بسيطة وغير متصلة. يصف RFC 768 بروتوكول UDP بأنه يوفر إجراءً لبرامج التطبيقات لإرسال الرسائل بأقل قدر من آليات البروتوكول، دون ضمانات للتسليم أو الحماية من التكرار؛ أما التطبيقات التي تتطلب تدفقات بيانات منظمة وموثوقة، فيُنصح باستخدام بروتوكول TCP بدلاً منه. [ 7 ] وبالمثل، يصف RFC 8085 بروتوكول UDP بأنه خدمة نقل رسائل بسيطة وغير موثوقة، تعتمد على بذل قصارى الجهد، ويشير إلى أن التطبيقات التي تستخدم UDP قد تحتاج إلى تطبيق آليات إضافية لضمان الموثوقية، والتحكم في الازدحام، وحساب المجاميع الاختبارية، أو وظائف أخرى حسب حالة استخدامها. [ 11 ]  

يُستخدم بروتوكول UDP بشكل شائع في تطبيقات البث المتعدد والبث العام، إلا أن هذه الاستخدامات تُعقّد التحكم في الازدحام، والتحكم في التدفق، والموثوقية، لأن المُرسِل قد يُرسل إلى العديد من المُستقبِلين عبر مسارات مُتباينة. وقد حددت فرقة عمل هندسة الإنترنت (IETF) أُطر عمل ووحدات بناء موثوقة للبث المتعدد، لذا فإن الموثوقية ليست مُستحيلة في تطبيقات البث المتعدد؛ بل إنها لا تُوفّرها بروتوكولات UDP نفسها، ويجب أن تُوفّرها التطبيقات أو بروتوكولات إضافية. [ 12 ]

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.[13]

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.[14]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.[15]

Protocols

This list shows some protocols that are commonly placed in the transport layers of the Internet protocol suite, the OSI protocol suite, NetWare's IPX/SPX, AppleTalk, and Fibre Channel.

Comparison of Internet transport layer protocols

FeatureUDPUDP-LiteTCPMultipath TCPSCTPDCCPRUDP[a]
Packet header size8 bytes8 bytes20–60 bytes50–90 bytes12 bytes[b]12 or 16 bytes14+ bytes
Typical data-packet overhead8 bytes8 bytes20 bytes?? bytes44–48+ bytes[c]12 or 16 bytes14 bytes
Transport-layer packet entityDatagramDatagramSegmentSegmentDatagramDatagramDatagram
Connection-orientedNoNoYesYesYesYesYes
Reliable transportNoNoYesYesYesNoYes
Unreliable transportYesYesNoNoYesYesYes
Preserve message boundaryYesYesNoNoYesYesYes
DeliveryUnorderedUnorderedOrderedOrderedOrdered / UnorderedUnorderedUnordered
Data checksumOptional[d]YesYesYesYesYesOptional
Checksum size16 bits16 bits16 bits16 bits32 bits16 bits16 bits
Partial checksumNoYesNoNoNoYesNo
Path MTUNoNoYesYesYesYes?
Flow controlNoNoYesYesYesNoYes
Congestion controlNoNoYesYesYesYes?
Explicit Congestion NotificationNoNoYesYesYesYes?
Multiple streamsNoNoNoNoYesNoNo
Multi-homingNoNoNoYesYesNoNo
Bundling / NagleNoNoYesYesYesNo?
  1. RUDP is not officially standardized. There have been no standard-related developments since 1999.
  2. Excluding data chunk headers and overhead chunks. Without embedded chunks, an SCTP packet is essentially useless.
  3. 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.
  4. Optional in IPv4 but compulsory in IPv6.[17]

Comparison of OSI transport protocols

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:[18]

ServiceTP0TP1TP2TP3TP4
Connection-oriented networkYesYesYesYesYes
Connectionless networkNoNoNoNoYes
Concatenation and separationNoYesYesYesYes
Segmentation and reassemblyYesYesYesYesYes
Error recoveryNoYesNoYesYes
Reinitiate connection (if an excessive number of PDUs are unacknowledged)NoYesNoYesNo
Multiplexing and demultiplexing over a single virtual circuitNoNoYesYesYes
Explicit flow controlNoNoYesYesYes
Retransmission on timeoutNoNoNoNoYes
Reliable Transport ServiceNoYesNoYesYes

There is also a connectionless transport protocol, specified by ISO/IEC 8602/ITU-T Recommendation X.234.[19]

References

  1. 12R. Braden, ed. (October 1989). Requirements for Internet Hosts -- Communication Layers. Network Working Group. doi:10.17487/RFC1122. STD 3.RFC1122.Internet Standard 3. Updated by RFC 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029 and 9293.
  2. "Introducing the Internet Protocol Suite". System Administration Guide, Volume 3.
  3. "X.225 : Information technology – Open Systems Interconnection – Connection-oriented Session protocol: Protocol specification". Archived from the original on February 1, 2021. Retrieved March 10, 2023.
  4. "Transport Layer"(PDF). Galgotias University.
  5. Heena, Khera. "Data Communication and networking"(PDF). Galgotias University. p. 9.
  6. 12Eddy, W. (August 2022). Transmission Control Protocol (TCP). IETF. sec. 2.2. doi:10.17487/RFC9293. RFC9293.
  7. 12Postel, J. (August 1980). User Datagram Protocol. IETF. doi:10.17487/RFC0768. RFC768.
  8. Eddy, W. (August 2022). Transmission Control Protocol (TCP). IETF. sec. 4. doi:10.17487/RFC9293. RFC9293.
  9. Eddy, W. (August 2022). Transmission Control Protocol (TCP). IETF. sec. 3.8. doi:10.17487/RFC9293. RFC9293.
  10. Eddy, W. (August 2022). Transmission Control Protocol (TCP). IETF. sec. 3.8.2. doi:10.17487/RFC9293. RFC9293.
  11. Eggert, L.; Fairhurst, G.; Shepherd, G. (March 2017). UDP Usage Guidelines. IETF. sec. 1. doi:10.17487/RFC8085. RFC8085.
  12. Eggert, L.; Fairhurst, G.; Shepherd, G. (March 2017). UDP Usage Guidelines. IETF. sec. 4. doi:10.17487/RFC8085. RFC8085.
  13. Information technology — Open Systems Interconnection — Protocol for providing the connection-mode transport service (Report). International Telecommunication Union. November 1995. ITU-T Recommendation X.224; ISO/IEC 8073:1995. Retrieved July 3, 2026.
  14. Papastergiou et al. 2017, p. 620-624.
  15. Iyengar, J.; Thomson, M. (May 2021). QUIC: A UDP-Based Multiplexed and Secure Transport. IETF. sec. 1. doi:10.17487/RFC9000. RFC9000.
  16. Brian C. Smith, Cyclic-UDP: A Priority-Driven Best-Effort Protocol(PDF), retrieved February 23, 2020
  17. "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.
  18. "ITU-T Recommendation X.224 (11/1995) ISO/IEC 8073". Itu.int. Retrieved January 17, 2017.
  19. "ITU-T Recommendation X.234 (07/1994) ISO/IEC 8602". Itu.int. Retrieved January 17, 2017.

Bibliography