Cover
Börja nu gratis eitf45 -L7- transport layer TCP and beyond APP.pdf
Summary
# Introduction to the transport layer
The transport layer provides logical end-to-end communication between processes running on different hosts [6](#page=6).
### 1.1 Role of the transport layer
The transport layer is responsible for process-to-process delivery, ensuring that data reaches the correct application on a host. It sits above the network layer (Layer 3) and below the application layer (Layer 5 in some models, implicitly). In the TCP/IP model, the transport layer provides services to the application layer. It handles the encapsulation and decapsulation of data [4](#page=4) [5](#page=5) [6](#page=6) [7](#page=7).
### 1.2 Transport layer protocols
The two primary protocols operating at the transport layer are:
* **Transmission Control Protocol (TCP)**
* **User Datagram Protocol (UDP)**
### 1.3 Process-to-process delivery
The transport layer enables communication between multiple applications running on the same host. This is achieved by using a combination of logical addresses (like IP addresses) and port numbers [7](#page=7).
#### 1.3.1 Logical and port addresses
To achieve process-to-process delivery, the transport layer uses:
* **Logical addresses:** Typically IP addresses, which identify a specific host on a network [8](#page=8).
* **Port numbers:** Which identify a specific process or application running on a host [8](#page=8) [9](#page=9).
#### 1.3.2 Socket addresses
A **socket address** is the unique combination of an IP address and a port number. This combination uniquely identifies a specific process on a host and is used for end-to-end communication [10](#page=10).
> **Tip:** Think of the IP address as the street address of a building, and the port number as the apartment number within that building. Both are needed to reach a specific resident (process).
#### 1.3.3 Port numbers
Port numbers are crucial for multiplexing and demultiplexing data at the transport layer. They are managed by the Internet Cooperation for Assigned Names and Numbers (ICANN) via the Internet Assigned Numbers Authority (IANA). There are three types of port numbers [11](#page=11) [8](#page=8):
* **Well-known ports:** These are assigned and controlled by IANA and are typically used by common system services (e.g., HTTP on port 80) [11](#page=11).
* **Registered ports:** Applications can register these ports with IANA to prevent duplication and ensure proper identification [11](#page=11).
* **Dynamic (or ephemeral) ports:** These are not controlled or registered and are used by applications for temporary communication sessions [11](#page=11).
The port number ranges for TCP and UDP are:
* **TCP:** 0 to 65535 [12](#page=12).
* **UDP:** 0 to 65535 [12](#page=12).
> **Example:** A web server typically listens on port 80 (for HTTP) or port 443 (for HTTPS). When a web browser client connects, it uses a dynamic port to establish communication with the server's well-known port.
### 1.4 Client-server concept
The client-server model is fundamental to network communication and relies heavily on the transport layer.
* **Server:** A server is a process that provides a service and must be continuously reachable on a specific port. It typically listens for incoming connection requests [13](#page=13) [14](#page=14).
* **Client:** A client is a process that requests a service from a server. When a client initiates a connection, it uses its own IP address and a dynamically assigned port number to communicate with the server's IP address and well-known (or registered) port number [14](#page=14).
> **Tip:** The server generally waits for clients, while clients actively initiate contact with servers. This interaction is facilitated by socket addresses at the transport layer.
---
# Transmission Control Protocol (TCP)
Transmission Control Protocol (TCP) provides a connection-oriented, reliable service for data transmission [15](#page=15).
### 2.1 Core characteristics
TCP is defined by its connection-oriented nature, its byte stream service, and its reliability features which include flow control, error control, and congestion control [15](#page=15).
### 2.2 Connection establishment and termination
TCP uses a three-way handshake for connection establishment. This involves the client sending a SYN segment, the server responding with a SYN-ACK segment, and the client finally sending an ACK segment to acknowledge the server's SYN-ACK [18](#page=18).
Connection termination is typically a four-way handshake. Either side can initiate termination by sending a FIN segment, which is then acknowledged by an ACK from the other side. This process continues until both sides have sent and acknowledged their FIN segments, thereby closing the connection. A "half-close" is also possible, where one side closes its sending ability while the other can still send data [20](#page=20) [21](#page=21).
### 2.3 Data transfer
During data transfer, TCP segments data into packets. The sequence numbers within TCP headers are crucial for ordering these segments correctly at the receiver, ensuring the data is presented as a continuous byte stream. Acknowledgements (ACKs) are used to confirm the successful receipt of data segments [19](#page=19) [23](#page=23).
> **Tip:** TCP presents data to applications as a byte stream, abstracting away the packetization process and providing a seamless data flow [15](#page=15).
### 2.4 Error control
TCP offers reliable data transfer by implementing error control mechanisms. This is especially important because the underlying Internet Protocol (IP) provides an unreliable network layer service [22](#page=22).
#### 2.4.1 Mechanisms for error detection and correction
* **Checksum:** TCP includes a checksum in its header to detect corrupted segments [23](#page=23).
* **Acknowledgement (ACK):** The receiver sends ACK segments to acknowledge received data [23](#page=23).
* **Retransmission:** If a segment is lost or corrupted, TCP employs retransmission strategies:
* **After time-out:** If an ACK is not received within a certain time interval, the sender assumes the segment was lost and retransmits it [23](#page=23).
* **After 3 duplicate ACKs:** If the sender receives three duplicate ACKs for the same segment, it infers that the next segment has been lost and initiates a fast retransmission [23](#page=23) [26](#page=26).
#### 2.4.2 Scenarios of packet loss
* **Normal operation:** Data segments and acknowledgements are received successfully, and the connection progresses as expected [24](#page=24).
* **Lost segment:** A data segment sent by the sender is lost in transit. The receiver will not send an ACK for this segment, leading to a timeout at the sender or the reception of duplicate ACKs for previously sent segments [25](#page=25).
* **Fast retransmission:** Triggered by multiple duplicate ACKs, this allows for quicker retransmission of a presumed lost segment without waiting for a full timeout [26](#page=26).
### 2.5 Congestion control
Congestion occurs when the data load exceeds the network's capacity, leading to increased arrival rates compared to processing or departure rates. TCP actively manages congestion to maintain a functioning network and ensure smooth data flow, particularly for real-time applications [27](#page=27) [28](#page=28).
#### 2.5.1 Congestion avoidance
TCP employs various algorithms for congestion avoidance. A fundamental mechanism used is the sliding window approach, which dynamically adjusts the amount of data that can be sent before requiring an acknowledgement [29](#page=29).
### 2.6 Summary and comparison with multimedia performance requirements
TCP is highly sensitive to lost or corrupted packets and less sensitive to delay. This contrasts with multimedia applications, which are often sensitive to delay and jitter but more tolerant of packet loss or corrupted packets. TCP also does not support multicasting [30](#page=30).
> **Example:** A file transfer over TCP will ensure that the entire file is received correctly, even if some packets are lost and need to be retransmitted. This reliability is crucial for data integrity but can introduce delays. In contrast, a video stream might tolerate some dropped frames (packet loss) to maintain a smoother playback experience, prioritizing timeliness over absolute perfection.
---
# User Datagram Protocol (UDP)
User Datagram Protocol (UDP) is a transport layer protocol that provides a connectionless and unreliable service for process-to-process communication [31](#page=31) [34](#page=34).
### 3.1 Core characteristics of UDP
UDP's fundamental characteristics define its operational paradigm:
* **Connectionless:** UDP does not establish a persistent connection before sending data. Each datagram is sent independently, without any session setup or teardown. This means there's no handshake or agreement between sender and receiver to prepare for data transfer [31](#page=31) [32](#page=32).
* **Unreliable:** UDP does not guarantee delivery of datagrams. It lacks mechanisms for error control (detecting and correcting errors) and flow control (managing the rate of data transmission to prevent overwhelming the receiver). Consequently, datagrams can be lost, duplicated, or arrive out of order [31](#page=31) [33](#page=33).
* **Process-to-process delivery:** Like TCP, UDP enables communication between specific processes running on different hosts, using port numbers to identify these processes [34](#page=34).
### 3.2 UDP header format
The UDP header is simple and concise, containing only essential fields to support its connectionless and unreliable nature. The header consists of four fields, each 16 bits in length [33](#page=33):
* **Source Port (16 bits):** Identifies the port number of the sending process [33](#page=33).
* **Destination Port (16 bits):** Identifies the port number of the receiving process [33](#page=33).
* **Length (16 bits):** Specifies the total length of the UDP datagram, including the header and the data. The minimum length is 8 bytes (the size of the header) [33](#page=33).
* **Checksum (16 bits, optional):** Used for error detection. If the sender computes a checksum, the receiver will verify it. If the checksum is zero, it indicates that the checksum field is not used [33](#page=33).
> **Tip:** Because UDP lacks the overhead of connection establishment, error checking, and flow control found in TCP, it offers lower latency and higher throughput, making it suitable for applications where speed is paramount and occasional data loss is acceptable.
### 3.3 Comparison with TCP
The primary differentiator between UDP and TCP lies in their service models and associated trade-offs:
* **Connection:** TCP is connection-oriented, requiring a handshake to establish a connection before data transfer and a termination sequence to close it. UDP is connectionless, sending datagrams without prior setup [31](#page=31) [34](#page=34).
* **Reliability:** TCP provides reliable delivery through mechanisms like acknowledgments, retransmissions, and sequencing. UDP offers no such guarantees, making it unreliable [31](#page=31) [33](#page=33).
* **Ordering:** TCP ensures that data arrives in the order it was sent. UDP datagrams may arrive out of order, as there is no numbering or sequence tracking between them [33](#page=33).
* **Flow Control:** TCP manages the data flow rate to prevent receiver overload. UDP does not implement flow control [31](#page=31).
* **Header Size:** The UDP header is significantly smaller (8 bytes) than the TCP header (typically 20 bytes), contributing to its lower overhead [33](#page=33).
* **Quality of Service (QoS):** UDP's lack of reliability and statefulness makes it less suitable for applications with strict QoS requirements that demand guaranteed delivery and ordering. TCP, with its built-in reliability, is often preferred for such applications. However, UDP can be used in conjunction with application-level mechanisms to achieve specific QoS goals for certain types of real-time traffic.
> **Example:** Applications like online gaming, voice over IP (VoIP), and streaming media often utilize UDP because timely delivery of packets is more critical than guaranteed delivery of every single packet. A dropped voice packet is less disruptive than a delay caused by retransmission.
---
# Application Layer: HTTP Revisited
This section revisits the Hypertext Transfer Protocol (HTTP) to understand its role in the application layer, detailing its text-based nature, the request-response interaction, and its reliance on TCP connections for communication [35](#page=35) [36](#page=36).
### 4.1 Introduction to HTTP
HTTP is a text-based protocol that forms the foundation of data communication on the World Wide Web. It operates at the application layer and defines the structure of messages exchanged between clients (like web browsers) and servers [35](#page=35) [36](#page=36) [41](#page=41).
### 4.2 HTTP Message Types: Requests and Responses
HTTP employs two fundamental types of messages: requests sent by the client to the server, and responses sent by the server back to the client [36](#page=36).
### 4.3 HTTP and TCP Connections
HTTP establishes and utilizes Transmission Control Protocol (TCP) connections for its communication [36](#page=36).
#### 4.3.1 Persistent vs. Non-persistent HTTP
* **Non-persistent HTTP:** In this model, a new TCP connection is established for each HTTP request-response transaction. After the response is delivered, the TCP connection is closed. This means that for a single HTML page containing multiple embedded objects (like images or stylesheets), multiple TCP connections might be opened and closed sequentially [38](#page=38).
* **Persistent HTTP:** With persistent HTTP, a single TCP connection is maintained for multiple request-response transactions. This improves efficiency by reducing the overhead associated with establishing new connections repeatedly [38](#page=38).
#### 4.3.2 Document Retrieval with HTTP
The process of retrieving a document, such as a web page, involves a series of interactions. A client sends an HTTP request to a server. The server processes the request and sends back an HTTP response. If the document contains embedded objects, the client may need to initiate further requests for these objects [37](#page=37) [38](#page=38).
#### 4.3.3 HTTP Request Structure
An HTTP request message typically includes:
* A request line, specifying the HTTP method (e.g., GET, PUT), the URI of the requested resource, and the HTTP version [37](#page=37).
* Header lines, providing additional information about the request, such as the host, user-agent, and acceptable content types.
* An optional message body, used for methods like POST to send data to the server.
#### 4.3.4 HTTP Response Structure
An HTTP response message typically includes:
* A status line, indicating the HTTP version, a status code (e.g., 200 OK, 404 Not Found), and a reason phrase [37](#page=37).
* Header lines, providing information about the response, such as the content type, content length, and server details.
* An optional message body, containing the requested resource (e.g., HTML content, image data).
> **Tip:** Understanding the structure of HTTP requests and responses is crucial for debugging network issues and for developing web applications [37](#page=37).
#### 4.3.5 Methods in HTTP
HTTP supports various methods that define the action to be performed on a resource. Common methods include:
* **GET:** Requests a representation of the specified resource [37](#page=37).
* **PUT:** Uploads a representation of the specified resource [37](#page=37).
* Other methods exist for different operations.
### 4.4 The Role of the Network Model
HTTP fits within the broader context of network models. It operates at the application layer, which is the topmost layer in many network models. This layer is responsible for providing network services directly to end-user applications. Protocols at this layer, like HTTP, enable users to interact with the network [41](#page=41).
> **Tip:** Recall that the application layer provides the interface between the user's applications and the underlying network infrastructure [41](#page=41).
---
## Common mistakes to avoid
- Review all topics thoroughly before exams
- Pay attention to formulas and key definitions
- Practice with examples provided in each section
- Don't memorize without understanding the underlying concepts
Glossary
| Term | Definition |
|------|------------|
| Transport Layer | The layer in the TCP/IP model responsible for logical end-to-end communication between processes running on different hosts, providing services like process-to-process delivery and data segmentation. |
| Process-to-Process Delivery | A service provided by the transport layer that ensures data is delivered from a specific application process on a source host to a specific application process on a destination host. |
| TCP (Transmission Control Protocol) | A connection-oriented, reliable transport layer protocol that provides services such as flow control, error control, and congestion control to ensure accurate data delivery. |
| UDP (User Datagram Protocol) | A connectionless, unreliable transport layer protocol that offers a minimal service, primarily focused on sending datagrams without guarantees of delivery, order, or error checking. |
| Datagram | A self-contained unit of data exchanged at the network layer, consisting of a header and a payload, which is routed independently across the network. |
| Packet | A unit of data transmitted over a network. In the context of the TCP/IP model, "packet" can refer to data at the network layer. |
| Frame | A unit of data at the data link layer, typically containing a network layer packet, along with data link layer headers and trailers for transmission over a physical medium. |
| Segment | A unit of data at the transport layer, specifically referring to data handled by TCP. TCP segments are encapsulated within IP packets. |
| IP Address | A unique numerical label assigned to each device connected to a computer network that uses the Internet Protocol for communication. |
| Port Number | A number used by transport layer protocols (like TCP and UDP) to identify a specific process or service running on a host, enabling multiplexing and demultiplexing of data. |
| Socket Address | A combination of an IP address and a port number, uniquely identifying a specific communication endpoint for a process on a host. |
| Well-known Ports | A range of port numbers (0-1023) assigned by the Internet Assigned Numbers Authority (IANA) for well-established network services like HTTP, FTP, and SMTP. |
| Registered Ports | A range of port numbers (1024-49151) that can be registered with IANA for specific applications to avoid port number conflicts. |
| Dynamic (Ephemeral) Ports | A range of port numbers (49152-65535) that are not controlled or registered and can be used by applications for temporary communication sessions. |
| Connection-Oriented | A type of communication where a dedicated connection is established between two endpoints before data transmission begins, ensuring ordered and reliable delivery. TCP is connection-oriented. |
| Connectionless | A type of communication where data is sent without establishing a prior connection. Each data unit is transmitted independently, and there are no guarantees of delivery or order. UDP is connectionless. |
| Byte Stream Service | A service provided by TCP where data is treated as a continuous stream of bytes, allowing applications to send and receive data without explicit message boundaries. |
| Flow Control | A mechanism used by transport layer protocols to prevent a fast sender from overwhelming a slow receiver, by managing the rate of data transmission. |
| Error Control | A mechanism used to detect and correct errors that may occur during data transmission, ensuring the integrity and reliability of the received data. |
| Congestion Control | A mechanism used by transport layer protocols to manage the amount of data sent into the network, aiming to prevent or alleviate network congestion. |
| Checksum | A value calculated from a block of data used to detect errors that may have been introduced during transmission or storage. |
| Acknowledgement (ACK) | A control message sent by the receiver to the sender to confirm that a specific segment or block of data has been successfully received. |
| Retransmission | The process of sending data again after it has been lost or corrupted during transmission, typically triggered by timeouts or duplicate acknowledgments. |
| Fast Retransmission | A TCP mechanism where a sender retransmits a segment immediately upon receiving multiple duplicate acknowledgments (usually three), indicating that a segment is likely lost. |
| Quality of Service (QoS) | A set of technologies and techniques used to manage network traffic and ensure that performance requirements, such as delay, jitter, and bandwidth, are met for different applications. |
| Congestion | A network condition where the amount of data being transmitted exceeds the network's capacity, leading to increased delays and packet loss. |
| Sliding Window | A flow control and congestion control mechanism used by TCP that allows the sender to transmit multiple segments before waiting for an acknowledgment, dynamically adjusting the window size. |
| Jitter | The variation in the delay of received packets, which can significantly impact the quality of real-time multimedia applications like voice and video. |
| HTTP (Hypertext Transfer Protocol) | An application layer protocol used for transmitting hypermedia documents, such as HTML, on the World Wide Web. It defines how messages are formatted and transmitted. |
| HTTP Request | A message sent from a client to a server asking for a specific resource or action. Common methods include GET and POST. |
| HTTP Response | A message sent from a server to a client in reply to an HTTP request, typically containing the requested resource or a status code indicating the outcome of the request. |