Web

Browser
FTP
Transport Layer: Motivation
Client
Web
Server

Transport Transport
Network
Network Network Network Network
Network
Link
Link Link Link Link
Link
Physical
Physical Physical Physical Physical
Physical

FTP
B
A R1 R2 Server
Transport
Network
Network

Layer 4: Transport Layer

Link
Link
C Physical
Physical

 Recall that NL is responsible for forwarding a packet

from one HOST to another HOST
 But it is the applications that communicate!
 How do you make applications on HOSTs to communicate?

 Need a new layer, called the “Transport Layer”

 Responsible for providing communication between applications
running in different hosts
 A Web Browser talking to a Web Server

1
 Transport services and protocols Transport vs. network layer
 provide logical communication
between app processes running
Household analogy:
application

on different hosts
transport
network
 network layer: logical
data link
physical
network
data link communication 12 kids sending letters to
between hosts 12 kids
network physical
 transport protocols run in end data link
physical
systems network
data link  processes = kids
 send side: breaks app
physical network
data link
 transport layer: logical  app messages = letters
messages into segments, physical

passes to network layer

network
data link
communication in envelopes
 rcv side: reassembles
physical
between processes  hosts = houses
segments into messages, application
relies on, enhances,
 transport protocol =
transport

passes to app layer network
network layer services
data link
physical Ann and Bill
 more than one transport
 network-layer protocol
protocol available to apps = postal service
 Internet: UDP, TCP, SCTP

2
 Transport Layer Functions
 Demultiplexing to upper layer -- Obligatory
 Deliver an incoming packet to the correct
application
 Define Delivery Sematics and Implement them
Internet transport-layer protocols
 User Datagram Protocol (UDP)
 unreliable (“best-effort”),
 unordered
 unicast or multicast delivery
 no flow, no congestion control

 Reliable vs. unreliable  Transmission Control Protocol (TCP)

 reliable
 Unicast vs. multicast
 in-order
 Ordered vs. unordered
 unicast
 Flow control -- Optional  flow & congestion control

 Do not allow sender to overrun receiver’s buffer  Stream Control Transport Protocol (SCTP) (will not cover in class)
resources  RFC 2960
reliable
 Congestion control -- Optional

 optional ordering
 Do not allow the sender to overrun the network  unicast
capacity  flow & congestion control

3
 Multiplexing/demultiplexing – Why? Demultiplexing: How?
 host receives IP datagrams
 Why need demultiplexing? P1 P2 P3
 Assume you are running 3 network  each datagram has source IP
applications all using the same transport transport address, destination IP 32 bits
protocol, e.g., TCP address
• FTP Server, Telnet Client, Web Browser network  each datagram carries 1 source port # dest port #
transport-layer segment
When a packet arrives at a host, it moves link

 each segment has source, other header fields
up the protocol stack until it reaches the
transport layer, e.g., TCP
physical destination port number
(well-known port numbers for
Demultiplexing specific applications)
 Now, the transport layer needs a way to
determine which application the packet P1 P2 P3  Port #s: 16 bits application
needs to be delivered. This is the • 65535 ports data
demultiplexing problem. transport • 0-1023 are called well-known (message)
and are reserved
 Recall that all protocol layers perform network – HTTP uses port 80
multiplexing/demultiplexing: – Telnet uses port 23
• e.g., IP needs to determine which transport link TCP/UDP segment format
protocol a given packet needs to be – RFC 1700 lists the reserved
delivered, UDP or TCP? physical ports
Multiplexing

4
 UDP: User Datagram Protocol
 “bare bones”, “best effort”
transport protocol
 connectionless:
 no handshaking between
UDP sender, receiver
before packets start
being exchanged
UDP: User Datagram Protocol
 each UDP segment
handled independently
of others
 Just provides
multiplexing/demultiplexing
[RFC 768]
Pros:
 No connection establishment
 No delay to start
sending/receiving packets
 Simple
 no connection state at sender,
receiver
 Small segment header
 Just 8 bytes of header
Cons:
 “best effort” transport service
means, UDP segments may be:
 lost
 delivered out of order to app
 no congestion control: UDP can
blast away as fast as desired
5
 UDP more UDP Demultiplexing
Used for
Mux/Demux
 often used for streaming
multimedia apps  Create sockets with port  When host receives
 loss tolerant
32 bits numbers: UDP segment:
 rate sensitive Length, in source port # dest port # DatagramSocket mySocket1 = new  checks destination port
bytes of UDP length checksum
DatagramSocket(6428); number in segment
segment, DatagramSocket mySocket2 = new  directs UDP segment to
 other UDP uses including DatagramSocket(4567);
socket with that port
header number
 DNS
 SNMP  UDP socket identified by
Application
data two-tuple:  IP datagrams with
 reliable transfer over UDP: (message) (dest IP address, dest port number) different source IP
add reliability at
addresses and/or
application layer
source port numbers
 application-specific UDP segment format
error recovery! directed to same
socket

6
 UDP Demultiplexing Example UDP checksum
DatagramSocket serverSocket = new DatagramSocket(6428); Goal: detect “errors” (e.g., flipped bits) in transmitted
segment Receiver:
P P1P  compute checksum of received
P
Sender: segment
 treat segment contents  check if computed checksum
as sequence of 16-bit equals checksum field value:
SP: 6428 SP: 6428
integers  NO - error detected
DP: 9157 DP: 5775
 checksum: addition (1’s  YES - no error detected. But
complement sum) of maybe errors nonetheless?
SP: 9157 SP: 5775 segment contents • Reordered bytes
client DP: 6428 server DP: 6428 Client  sender puts checksum
IP: A IP: C IP:B value into UDP checksum
field  Why checksum at UDP if LL
provides error checking?
Source Port (SP) provides “return address”: Identifies  IP is supposed to run over
the process at the other end of the line ANY LL, so UDP does its own
error checking

7
 How to program using the UDP? Socket Creation
Socket Layer
TCP UDP  mySock = socket(family, type, protocol);
IP Socket Layer
LL
PL
TCP
IP
UDP
 UDP/TCP/IP-specific sockets
LL
PL

Family Type Protocol

TCP SOCK_STREAM IPPROTO_TCP

Socket Layer PF_INET
TCP UDP
 Socket Layer: IP UDP SOCK_DGRAM IPPROTO_UDP
LL
 Programmer’s API to PL

the protocol stack

 Typical network app has two pieces: client and server  Socket reference
 Server: Passive entity. Provides service to clients  File (socket) descriptor in UNIX
 e.g., Web server responds with the requested Web page  Socket handle in WinSock
 Client: initiates contact with server (“speaks first”)
 typically requests service from server, e.g., Web Browser

8
 UDP Client/Server Interaction UDP Client/Server Interaction

/* Create socket for incoming messages */

Server starts by getting ready to receive client messages… if ((servSock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0)
Error("socket() failed");
Client Server
1. Create a UDP socket 1. Create a UDP socket
2. Communicate (send/receive Assign a port to socket
messages)
2.
Client Server
3. Communicate (receive/send 1. Create a UDP socket 1. Create a UDP socket
3. When done, close the socket
messages) Communicate (send/receive
2. 2. Assign a port to socket
4. When done, close the socket messages)
3. Communicate (receive/send
3. When done, close the socket
messages)
4. When done, close the socket

9
 UDP Client/Server Interaction Specifying Addresses
ServAddr.sin_family = PF_INET; /* Internet address family */  struct sockaddr
ServAddr.sin_addr.s_addr = htonl(INADDR_ANY); /* Any incoming interface */ {

Generic
ServAddr.sin_port = htons(20000); /* Local port 20000 */ unsigned short sa_family; /* Address family (e.g., PF_INET) */
char sa_data[14]; /* Protocol-specific address information */
if (bind(servSock, (struct sockaddr *) &ServAddr, sizeof(ServAddr)) < 0) };
Error("bind() failed");
 struct sockaddr_in
{

Client Server unsigned short sin_family; /* Internet protocol (PF_INET) */

unsigned short sin_port; /* Port (16-bits) */

IP Specific
1. Create a UDP socket 1. Create a UDP socket struct in_addr sin_addr; /* Internet address (32-bits) */
2. Communicate (send/receive 2. Assign a port to socket char sin_zero[8]; /* Not used */
messages) };
3. Communicate (receive/send
3. When done, close the socket struct in_addr
messages) {
4. When done, close the socket unsigned long s_addr; /* Internet address (32-bits) */
};

10
 UDP Client/Server Interaction UDP Client/Server Interaction
struct sockaddr_in peer;
int peerSize = sizeof(peer);
char buffer[65536];
Server is now blocked waiting for a message from a client
recvfrom(servSock, buffer, 65536, 0, (struct sockaddr *)&peer, &peerSize);

Client Server Client Server

1. Create a UDP socket 1. Create a UDP socket 1. Create a UDP socket 1. Create a UDP socket
2. Communicate (send/receive 2. Assign a port to socket 2. Communicate (send/receive 2. Assign a port to socket
messages) messages)
3. Communicate (receive/send 3. Communicate (receive/send
3. When done, close the socket 3. When done, close the socket
messages) messages)
4. When done, close the socket 4. When done, close the socket

11
 UDP Client/Server Interaction UDP Client/Server Interaction

/* Create socket for outgoing messages */

Later, a client decides to talk to the server… if ((clientSock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0)
Error("socket() failed");

Client Server Client Server

1. Create a UDP socket 1. Create a UDP socket 1. Create a UDP socket 1. Create a UDP socket
2. Communicate (send/receive 2. Assign a port to socket 2. Communicate (send/receive 2. Assign a port to socket
messages) messages)
3. Communicate (receive/send 3. Communicate (receive/send
3. When done, close the socket 3. When done, close the socket
messages) messages)
4. When done, close the socket 4. When done, close the socket

12
 UDP Client/Server Interaction UDP Client/Server Interaction
// Initialize server’s address and port
struct sockaddr_in server;
server.sin_family = AF_INET; close(clientSock); close(serverSock);
server.sin_addr.s_addr = inet_addr(“10.10.100.37”);
server.sin_port = htons(20000);

// Send it to the server

sendto(clientSock, buffer, msgSize, 0, (struct sockaddr *)&server, sizeof(server));

Client Server Client Server

1. Create a UDP socket 1. Create a UDP socket 1. Create a UDP socket 1. Create a UDP socket
2. Communicate (send/receive 2. Assign a port to socket 2. Communicate (send/receive 2. Assign a port to socket
messages) messages)
3. Communicate (receive/send 3. Communicate (receive/send
3. When done, close the socket 3. When done, close the socket
messages) messages)
4. When done, close the socket 4. When done, close the socket

13
 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581
application application
writes data reads data
socket socket
door door
TCP TCP
send buffer receive buffer
segment

 point-to-point (unicast):  reliable, in-order byte

Transmission Control Protocol (TCP)  one sender, one receiver steam:
 connection-oriented:  no “message boundaries”
 handshaking (exchange of  send & receive buffers
control msgs) init’s sender,  buffer incoming & outgoing
receiver state before data data
exchange
 flow controlled:
 State resides only at the END
systems – Not a virtual circuit!  sender will not overwhelm
receiver
 full duplex data:
 congestion controlled:
 bi-directional data flow in same
connection (A->B & B->A in the  sender will not overwhelm
same connection) network
 MSS: maximum segment size
27 28

14
 TCP segment structure TCP Connection-oriented demux
32 bits  TCP socket identified by 4-tuple:
URG: urgent data counting
source port # dest port #  source IP address
(generally not used) by bytes
sequence number  source port number
ACK: ACK # of data
(not segments!)  dest IP address
valid acknowledgement number
head not  dest port number
PSH: push data now len used
UA P R S F Receive window
(generally not used) # bytes
checksum Urg data pnter
rcvr willing
RST, SYN, FIN: to accept  receiving host uses all four values to direct segment
Options (variable length)
connection estab to appropriate socket
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)

29 30

15
 TCP Demultiplexing Example Typical TCP Transaction
Client Server
 A TCP Transaction
P P P P1P
consists of 3 Phases
1. Connection Establishment
Connection Establishment  Handshaking between
client and server
SP: 80 SP: 80
DP: 9157 DP: 5775
2. Reliable, In-Order Data
Reliable, In-Order Exchange
SP: 9157 SP: 5775 Data Exchange  Recover any lost data
client DP: 80 server DP: 80 Client through retransmissions
IP: A IP: C IP:B and ACKs

Connection Termination 3. Connection Termination

 Closing the connection

31 time time 32

16
 TCP Connection Establishment Connection Establishment (cont)
 TCP sender, receiver establish “connection” before
Three way handshake: Host A Host B

exchanging data segments Step 1: client host sends TCP

Connection
SYN segment to server request
 specifies a random initial
 initialize TCP variables: seq # host ACKs
and selects
 seq. #s  no data its own
Step 2: server host receives initial seq #
 buffers, flow control info (e.g. RcvWindow)
SYN, replies with SYNACK
segment
 client: connection initiator  server allocates buffers host ACKs

Socket clientSocket = new Socket("hostname", port#);  specifies server initial

seq. #
Step 3: client receives
 server: contacted by client SYNACK, replies with ACK time time
Socket connectionSocket = welcomeSocket.accept(); segment, which may contain
data Three-way handshake
33 34

17
 Connection Establishment (cont) TCP Starting Sequence Number Selection
Host A Host B
 Why a random starting sequence #? Why not simply
choose 0?
Connection
request  To protect against two incarnations of the same connection
Seq. #’s: reusing the same sequence numbers too soon
host ACKs
 byte stream “number” of and selects
first byte in segment’s its own
 That is, while there is still a chance that a segment from an earlier
initial seq #
data incarnation of a connection will interfere with a later incarnation
ACKs: of the connection
 seq # of next byte
host ACKs  How?
expected from other side
 Client machine seq #0, initiates connection to server with seq #0.
 cumulative ACK
 Client sends one byte and client machine crashes
 Client reboots and initiates connection again
time time
 Server thinks new incarnation is the same as old connection

Three-way handshake
35 36

18
 TCP Connection Termination TCP Connection Termination
Step 3: client receives FIN, replies
Closing a connection:
with ACK.
client server client server
client closes socket:  Enters “timed wait” - will respond
clientSocket.close(); close closing
with ACK to received FINs
Step 1: client end system
sends TCP FIN control
Step 4: server, receives ACK.
Connection closed.
segment to server closing
Data
write  Why wait before closing the
Step 2: server receives connection?
FIN, replies with ACK.
Server might send some If the connection were allowed to move

timed wait
timed wait


close
buffered but not sent data to CLOSED state, then another pair of
closed
before closing the application processes might come along
connection. Server then and open the same connection (use the
sends FIN and moves to closed same port #s) and a delayed FIN from closed
Closing state. an earlier incarnation would terminate
the connection.
37 38

19