Transcript Transport Protocols Basics

Ch. 7 : Internet
Transport Protocols
1
Transport Layer
Our goals:
 understand principles
behind transport
layer services:




Multiplexing /
demultiplexing data
streams of several
applications
reliable data transfer
flow control
congestion control
Transport Layer
Chapter 6:
 rdt principles
Chapter 7:
 multiplex/ demultiplex
 Internet transport layer
protocols:


UDP: connectionless
transport
TCP: connection-oriented
transport
• connection setup
• data transfer
• flow control
• congestion control
2
Transport vs. network layer
Transport Layer
Network Layer
logical communication
between processes
logical communication
between hosts
exists only in hosts
exists in hosts and
in routers
ignores network
routes data through
network
Port #s used for routing
in destination computer
IP addresses used for
routing in network
 Transport layer uses Network layer services
 adds more value to these services
3
Multiplexing &
Demultiplexing
4
Multiplexing/demultiplexing
Multiplexing at send host:
gather data from multiple
sockets, envelop data with
headers (later used for
demultiplexing), pass to L3
application
transport
network
link
P3
P1
P1
Demultiplexing at rcv host:
receive segment from L3
deliver each received
segment to correct socket
= socket
application
transport
network
P2
= process
P4
application
transport
network
link
link
physical
host 1
physical
host 2
physical
host 3
5
each datagram has source
IP address, destination IP
address in its header
 each datagram carries one
transport-layer segment
 each segment has source,
destination port number
in its header
 host uses port numbers, and
sometimes also IP addresses
to direct segment to correct
socket
 from socket data gets to
the relevant application
process

appl. msg
 host receives IP datagrams
L4 header L3 hdr
How demultiplexing works
32 bits
source IP addr dest IP addr.
other IP header fields
source port #
dest port #
other header fields
application
data
(message)
TCP/UDP segment format
6
Connectionless demultiplexing (UDP)
 Processes create sockets
with port numbers
 a UDP socket is identified
by a pair of numbers:
(my IP address , my port number)
 Client decides to contact:
 a server ( peer IP-address) +
 an application ( peer port #)
 Client puts those into the
UDP packet he sends; they
are written as:


dest IP address - in the
IP header of the packet
dest port number - in its
UDP header
 When server receives
a UDP segment:




checks destination port
number in segment
directs UDP segment to
the socket with that port
number
(packets from different
remote sockets directed
to same socket)
the UDP message waits in
socket queue and is
processed in its turn.
answer message sent to
the client UDP socket
(listed in Source fields of
query packet)
7
Connectionless demux (cont)
client socket:
port=5775, IP=B
client socket:
port=9157, IP=A
L5
P2
L4
P3
Reply
L3
L2
message
L1
S-IP: C
S-IP: C
D-IP: A
D-IP: B
SP: 53
SP: 53
DP: 9157
message
DP: 5775
S-IP: A
client
IP: A
server socket:
port=53, IP = C
Wait for
application
SP: 9157 Getting
DP: 53 Service
D-IP: C
SP = Source port number
DP= Destination port number
S-IP= Source IP Address
D-IP=Destination IP Address
P1
Reply
message
server
IP: C
S-IP: B
Getting
Service
IP-Header
D-IP: C
SP: 5775
DP: 53
Client
IP:B
message
UDP-Header
SP and S-IP provide “return address”
8
Connection-oriented demux (TCP)
 TCP socket identified
by 4-tuple:




local (my) IP address
local (my) port number
remote IP address
remote port number
 receiving host uses all
four values to direct
segment to appropriate
socket
 Server host may support
many simultaneous TCP
sockets:

each socket identified by
its own 4-tuple
 Web servers have a
different socket for
each connecting client


If you open two browser
windows, you generate 2
sockets at each end
non-persistent HTTP will
open a different socket
for each request
9
Connection-oriented demux (cont)
client socket:
LP= 9157, L-IP= A
RP= 80 , R-IP= C
L5
server socket:
LP= 80 , L-IP= C
RP= 9157, R-IP= A
P1
L4
P4
server socket:
LP= 80 , L-IP= C
RP= 5775, R-IP= B
P5
P6
S-IP: B
D-IP: C
message
packet:
client
IP: A
S-IP: A
D-IP: C
SP: 9157
DP: 80
H3
H4
server
IP: C
packet:
S-IP: B
D-IP: C
SP: 9157
message
LP= Local Port , RP= Remote Port
L-IP= Local IP , R-IP= Remote IP
P1P3
DP: 80
L2
L1
P2
SP: 5775
server socket:
LP= 80 , L-IP= C
RP= 9157, R-IP= B
L3
packet:
client socket:
LP= 9157, L-IP= B
RP= 80 , R-IP= C
“L”= Local
= My
“R”= Remote = Peer
DP: 80
message
Client
IP: B
client socket:
LP= 5775, L-IP= B
RP= 80 , R-IP= C
10
UDP Protocol
11
UDP: User Datagram Protocol [RFC 768]
 simple transport protocol
 “best effort” service, UDP
segments may be:
 lost
 delivered out of order
to application
with no correction by UDP
 UDP will discard bad
checksum segments if so
configured by application
 connectionless:
 no handshaking between
UDP sender, receiver
 each UDP segment
handled independently
of others
Why is there a UDP?
 no connection establishment
saves delay
 no congestion control:
 better delay & BW
 simple:
 small segment header

 typical usage: realtime appl.
loss tolerant
 rate sensitive
 other uses (why?):



DNS
SNMP
12
UDP segment structure
Total length of
segment (bytes)
32 bits
source port #
length
dest port #
checksum
application
data
(variable length)
Checksum computed over:
• the whole segment
• part of IP header:
– both IP addresses
– protocol field
– total IP packet length
Checksum usage:
• computed at destination to detect
errors
• in case of error, UDP will discard
the segment, or
13
UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted
segment
Sender:
 treat segment contents
as sequence of 16-bit
integers
 checksum: addition (1’s
complement sum) of
segment contents
 sender puts checksum
value into UDP checksum
field
Receiver:
 compute checksum of
received segment
 check if computed checksum
equals checksum field value:
 NO - error detected
 YES - no error detected.
14
TCP Protocol
15
TCP: Overview
 point-to-point:
 one sender, one receiver
 between sockets
 reliable, in-order byte
steam:

no “message boundaries”
 pipelined:
 TCP congestion and flow
control set window size
 send & receive buffers
socket
door
application
writes data
application
reads data
TCP
send buffer
TCP
receive buffer
RFCs: 793, 1122, 1323, 2018, 2581
 full duplex data:
 bi-directional data flow
in same connection
 MSS: maximum segment
size
 connection-oriented:
 handshaking (exchange
of control msgs) init’s
sender, receiver state
before data exchange
 flow controlled:
 sender will not
overwhelm receiver
socket
door
segment
16
TCP segment structure
hdr length in
32 bit words
32 bits
URG: urgent data
(generally not used)
ACK: ACK #
valid
PSH: push data now
(generally not used)
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
Internet
checksum
(as in UDP)
source port #
dest port #
sequence number
acknowledgement number
head not
UA P R S F
len used
checksum
rcvr window size
ptr urgent data
Options (variable length)
counting
by bytes
of data
(not segments!)
# bytes
rcvr willing
to accept
application
data
(variable length)
17
TCP sequence # (SN) and ACK (AN)
SN:

byte stream
“number” of first
byte in segment’s
data
AN:
SN of next byte
expected from other
side
 cumulative ACK
Qn: how receiver handles
out-of-order segments?
 puts them in receive
buffer but does not
acknowledge them
Host A
Host B
host A
sends
100 data
bytes

host ACKs
receipt
of data ,
sends no data
WHY?
host B
ACKs 100
bytes
and sends
50 data
bytes
time
simple data transfer scenario
(some time after conn. setup)
18
Connection Management: Objective
 Agree on initial sequence numbers

a sender should not reuse a seq# before it is
sure that all packets with the seq# are purged
from the network
• the network guarantees that a packet too old will be
purged from the network: network bounds the life
time of each packet

To avoid waiting for seq #s to disappear, start
new session with a seq# far away from previous
• needs connection setup so that the sender tells the
receiver initial seq#
 Agree on other initial parameters
19
TCP Connection Management
Setup: establish connection
between the hosts before
exchanging data segments
 called: 3 way handshake
 initialize TCP variables:
 seq. #s
 buffers, flow control
info (e.g. RcvWindow)
 client : connection initiator

opens socket and cmds OS
to connect it to server
 server : contacted by client



has waiting socket
accepts connection
generates working socket
Teardown: end of
Three way handshake:
Step 1: client host sends TCP
SYN segment to server
 specifies initial seq #
 no data
Step 2: server host receives
SYN, replies with SYNACK
segment (also no data)
allocates buffers
 specifies server initial
SN & window size
Step 3: client receives SYNACK,
replies with ACK segment,
which may contain data

connection
(we skip the details)
20
TCP Three-Way Handshake (TWH)
A
B
X+1
Y+1
Send Buffer
Send Buffer
Y+1
Receive Buffer
X+1
Receive Buffer
21
Connection Close
 Objective of closure
handshake:

each side can release
resource and remove
state about the
connection
• Close the socket
client
server
initial
close :
release
resource?
close
close
release
resource
release
resource
22