Transport Layer

The Session Layer and Presentation Layer can be considered part of this layer

Two perspectives:

Abstraction of clients
- Creates abstraction that intricate networks between clients doesn’t exist
Abstraction of services
- Provides network layer services

Abstraction of Clients

Transport layer abstraction:

Transport protocols:

Logical communication between processes
- Sender divides a message into segments
- Receiver reassembles segments into message
Transport services
- Multiplexing/demultiplexing packets (port numbers)
- Detecting corrupted data (checksums)
- Optionally: reliable delivery, flow control

Demultiplexing at recv host: delivers received segments to correct socket
Multiplexing at send host: uses data header to indicate which socket to send to
- Allows multiple sockets to use same data channel

Also known as mux/demux

Create sockets with port numbers
UDP socket identified by 2-tuple (dest IP addr, dest port number)
When host receives UDP segment:
- Checks destination port number in segment
- Directs UDP segment to socket with that port number

Note

IP datagrams with different source IP addresses and/or source port numbers are still directed to the same socket

TCP socket identified by 4-tuple
- Source IP address
- Source port number
- Destination IP address
- Destination port number
recv host uses all four values to direct segments to appropriate socket
Server host may support many simultaneous TCP sockets
- Each socket identified by its own 4-tuple
Web servers have different sockets for each connecting client
- Non-persistent HTTP will have different socket for each request

Use case: Threaded web server

IP protocol stack: key abstractions

So transport layer is where we need to go from best-effort to reliable

Expectations for end-to-end protocols (UDP doesn’t do all of these, TCP does):

Typical limitations of the network on which the transport protocol will operate:

A reliable protocol is one that does one or more of the following: