1
Ch. 7 : Internet Transport Protocols
Transport Layer
Transport LayerOur goals: understand principles
behind transport layer services: Multiplexing /
demultiplexing data streams of several applications
reliable data transfer flow control congestion control
Chapter 6: rdt principlesChapter 7: multiplex/ demultiplex Internet transport layer
protocols: UDP: connectionless
transport TCP: connection-oriented
transport• connection setup• data transfer• flow control• congestion control
22
Transport vs. network layer
Transport layer uses Network layer services adds more value to these services
Transport Layer Network Layerlogical communication
between processes logical communication
between hostsexists only in hosts exists in hosts and
in routersignores network routes data through
network Port #s used for routing in destination computer
IP addresses used for routing in network
3
4
Multiplexing &Demultiplexing
Multiplexing/demultiplexing
application
transport
network
link
physical
P1 application
transport
network
link
physical
application
transport
network
link
physical
P2P3 P4P1
host 1 host 2 host 3
= process= socket
receive segment from L3deliver each received segment to correct socket
Demultiplexing at rcv host:gather data from multiplesockets, envelop data with headers (later used for demultiplexing), pass to L3
Multiplexing at send host:
5
How demultiplexing works host receives IP datagrams
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
source port # dest port #
32 bits
applicationdata
(message)
other header fields
TCP/UDP segment format
L4
head
erap
pl. m
sgL3
hd
r
other IP header fieldssource IP addr dest IP addr.
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
ClientIP:B
SP: 53DP: 5775
S-IP: CD-IP: B
SP = Source port numberDP= Destination port numberS-IP= Source IP AddressD-IP=Destination IP Address
Connectionless demux (cont)
client IP: A
P1
serverIP: C
SP and S-IP provide “return address”
P2
client socket:port=9157, IP=A
P3server socket:port=53, IP = C
message
SP: 9157DP: 53
S-IP: AD-IP: C
IP-HeaderUDP-Header
SP: 53DP: 9157
S-IP: CD-IP: A
SP: 5775DP: 53
S-IP: BD-IP: C
message
client socket:port=5775, IP=B
message message
Wait for application
Getting Service
Reply
Getting Service
Reply
L1
L2
L4
L5
L3
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)
ClientIP: B
client IP: A
P1
serverIP: C
P3
client socket:LP= 9157, L-IP= ARP= 80 , R-IP= C
P1
LP= Local Port , RP= Remote Port L-IP= Local IP , R-IP= Remote IP
P4
server socket:LP= 80 , L-IP= CRP= 9157, R-IP= A
P6
server socket:LP= 80 , L-IP= CRP= 5775, R-IP= B
“L”= Local = My“R”= Remote = Peer
P2
client socket:LP= 5775, L-IP= BRP= 80 , R-IP= C
client socket:LP= 9157, L-IP= BRP= 80 , R-IP= C
P5
server socket:LP= 80 , L-IP= CRP= 9157, R-IP= B
H3
H4SP: 9157DP: 80
S-IP: AD-IP: C
packet:
message
SP: 5775DP: 80
D-IP: CS-IP: B
packet:
message
SP: 9157DP: 80
packet:
D-IP: CS-IP: B
message
L1
L2
L4
L5
L3
10
11
UDP Protocol
UDP: User Datagram Protocol [RFC 768]
simple transport protocol “best effort” service, UDP
segments may be: lost delivered out of order to
applicationwith 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
source port # dest port #
32 bits
applicationdata (variable length)
length
Total length of segment (bytes)
Checksum computed over:• the whole segment• part of IP header:
– both IP addresses– protocol field – total IP packet length
checksum
Checksum usage:• computed at destination to detect
errors• in case of error, UDP will discard
the segment, or
13
14
UDP checksum
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.
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
15
TCP Protocol
16
TCP: Overview 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
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
socketdoor
T C Psend buffer
TC Prece ive buffer
socketdoor
segm en t
applica tionwrites data
applicationreads data
17
TCP segment structure
source port # dest port #32 bits
applicationdata
(variable length)
sequence numberacknowledgement
numberrcvr window sizeptr urgent datachecksum
FSRPAUheadlen
notused
Options (variable length)
URG: urgent data (generally not used)
ACK: ACK #valid
PSH: push data now(generally not used)
RST, SYN, FIN:connection estab(setup, teardown
commands)
# bytes rcvr willingto accept
countingby bytes of data(not segments!)
Internetchecksum
(as in UDP)
hdr length in 32 bit words
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 ACKQn: how receiver handles
out-of-order segments? puts them in receive
buffer but does not acknowledge them
Host A Host B
time
SN=42, AN=79, 100 data bytes
SN=79, AN=142, 50 data bytes
SN=142, AN=129 , no data
host A sends100 data bytes
host ACKsreceipt of data , sends no dataWHY?
host B ACKs 100bytes and sends50 data bytes
simple data transfer scenario (some time after conn. setup)
18
19
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
TCP Connection ManagementSetup: 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 connection(we skip the details)
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 sizeStep 3: client receives
SYNACK, replies with ACK segment, which may contain data
20
TCP Three-Way Handshake (TWH)A
Send Buffer
Receive Buffer
Send Buffer
Receive Buffer
SYN , SN = X
SYNACK , SN = Y, AN = X+1
ACK , SN = X+1 , AN = Y+1
X+1
X+1
Y+1
Y+1
B
21
22
Connection Close Objective of closure
handshake: each side can release
resource and remove state about the connection
• Close the socket
client
I am done. Are you done too?
server
I am done too. Goodbye!
initial close :
close
close
release resource?
release resource
release resource
Top Related