Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Connection Management
Networked Systems 3Lecture 13
Lecture Outline
• Modelling protocol behaviour
• Managing transport connections• Connection establishment
• Reliable data transfer
• Connection tear down
2
Modelling Protocol Behaviour
• Can model protocols using a finite state machine• A set of states with transitions between
them
• The current state indicates what the system is doing at any time
• Transitions show occurrence of events and the response of the system
• Can be used to define the behaviour of a protocol
Disconnected
Request sent
Connected
Send “connection requested”
Get “accepted”
Sen
d “c
lose
con
nect
ion”
Example: partial state machine for opening and closing a connection
Get“declined”
3
Managing Connections
• One role of transport layer: provide reliability
• How to reliably manage transport connections?• Setup a reliable connection over an unreliable connectionless network
• Transport data without loss over an unreliable network
• Agree to tear down a connection
4
Disconnected
Connection Establishment
• How do two hosts agree to communicate?
Host A
Tim
e
Host B
Tim
e
Connectionrequested
Connectionaccepted
Request sent
Connected
Listening
Connected
Disconnected Listening
Request sent
Connected
Connected
5
Disconnected
Connection Establishment
• What if the initial request is lost?
Host A
Tim
e
Host B
Tim
e
Connectionrequested
Connectionaccepted
Request sent
Connected
Listening
Connected
Disconnected Listening
Request sent
Connected
Connected
x
Timeout &retransmit
6
Disconnected
Connection Establishment
• What if the “connection accepted” reply is lost?
Host A
Tim
e
Host B
Tim
e
Connectionrequested
Connectionaccepted
Request sent
Connected
Listening
Connected
Disconnected Listening
Request sent
Connected
Connected
xTimeout &retransmit
Error: already connected!
7
Disconnected
Connection Establishment
• What if the “connection accepted” reply is lost?• Sequence number in messages; random initial value
Host A
Tim
e
Host B
Tim
e
Connectionrequested
Connectionaccepted
Request sent
Connected
Listening
Connected
Disconnected Listening
Request sent
Connected
Connected
xTimeout &retransmit
Duplicate requestRetransmit “connection accepted”
seq = x
seq = x
Connected
8
Connection Establishment
• What if data from an old connection is still in the network?
Disconnected
Host A
Tim
e
Host B
Tim
e
Connectionrequested
Connectionaccepted
Request sent
Connected
Listening
Connected
Disconnected Listening
Request sent
Connected
Connected
Delayed connectionaccepted message
Error: alreadyconnected!
seq = x
9
Accepting connectionAccepting connection
Connection Establishment
• Solution for robust connection establishment: use a three-way handshake
Disconnected
Host A
Tim
e
Host B
Tim
e
Connectionrequested
Connectionaccepted
Request sent
Connected
Listening
Connected
Disconnected Listening
Request sent
Connected
seq = x
ack = x, seq = y
ack = y
Connected
10
Three Way Handshake
• Three way handshake ensures robustness• Delayed control messages generate an acknowledgement with incorrect
sequence number
• This is detected, and stops the connection establishment
• Hosts cannot reuse initial sequence number until the maximum packet lifetime passed
• Requires hosts to keep state regarding previous connections, to avoid reuse
• Randomly chosen initial sequence number makes collisions unlikely if a host crash causes state to be lost
11
SYN, ACK = x, seq = y
SYN, seq = x
Example: TCP Connections
• TCP connections use a three way handshake• Use the SYN and ACK flags in the
TCP header to signal connection progress
• Packets contain sequence number and acknowledgement number
Host A
Tim
e
Host B
Tim
e
ACK = y
12
Example: TCP Connections
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31Version = 4 Header Len DSCP ECN Total Length
Packet Identifier DF MF Fragment OffsetTTL Upper Layer Protocol Header Checksum
Source AddressDestination Address
Source Port Destination Port
Sequence Number
Acknowledgement Number
Data Offset Reserved Urg Ack Psh Rst Syn Fin Window
Checksum Urgent Pointer
[options - variable length]
[data - variable length]
IP
TCP
Data
13
TCP State Machine
Established
Listen
Closed
SYN recv’d SYN sent
Connect/SYN
Close/-Close/-Listen/-
SYN/SYN+ACK
RST/- Send/SYN
SYN/SYN+ACK
SYN+ACK/ACKACK/-
(simultaneous open)
Action/Effect
• Shows client and server on same state diagram
• Additional transitions allow simultaneous open
14
Reliable Data Transfer
• Two approaches to reliable data transfer at the transport layer• End-to-end ARQ
• Positive or negative acknowledgements
• End-to-end FEC
• Within each network layer packet
• Across several network layer packets
• Conceptually identical to operation at data link layer
15
Example: TCP
• TCP packets include sequence number and an (optional) acknowledgement number• Sequence number counts bytes
transmitted
• Send cumulative positive acknowledgements• Acknowledgement specifies the next byte expected
• Only acknowledge contiguously data packets (sliding window protocol, so several data packets in flight)
• Duplicate acknowledgement implies loss
• Retransmit lost packets
Host A
Tim
e
Host B
Tim
e
x
seq = 5seq = 6seq = 7seq = 8seq = 9
seq = 10seq = 11
ack = 6ack = 7
ack = 8
ack = 8ack = 8
ack = 8seq = 8seq = 9
16
Example: TCP
• Packet reordering also causes duplicate ACKs• Gives appearance of loss, when
the data was merely delayed
• TCP uses triple duplicate ACK to indicate loss• Three identical ACKs in a row
• Slightly delays response to loss, but makes TCP more robust to reordering
Host ATi
me
Host B
Tim
e
seq = 5seq = 6seq = 7seq = 8seq = 9
seq = 10seq = 11
ack = 6ack = 7ack = 7
ack = 10ack = 11ack = 12
ack = 9
17
Example: TCP
• Problem with cumulative ACKs: don’t signal any packets received after the highest contiguously received packet• E.g. if packets 1, 2, 3, 5, 6, and 7 are received, the ACK will show 4 as the
next packet outstanding, but won’t mention packets 5, 6, and 7
• Leads to unnecessary retransmissions
• Solution: Selective ACK (“SACK”) option to TCP
• But only supported by 68% of web servers, ten years after standardisation... [Medina, Allman, & Floyd, ACM CCR, Apr 2005]
18
Connection Tear Down
• Three way handshake to tear down a connection
• What happens if the last ACK is lost?• A has closed the connection, so cannot
resend the ACK; B is still waiting
• Unavoidable problem → B must eventually give up, without knowing if the last packet arrived
• Data sent on last packet is potentially lost
FIN, ACK = x, seq = y
FIN, seq = x
Host A
Tim
e
Host B
Tim
e
ACK = y
19
TCP State Machine
Established
SYN recv’d
Closing
Time Wait
Close wait
Last ACK
FIN wait 1
FIN wait 2
Closed
Close/FIN Close/FIN FIN/ACK
Close/FIN
FIN/ACK
FIN+ACK/ACK
FIN/ACKACK/- ACK/-
ACK/-
Timeout/-
(passive close)(active close)
• TCP uses a three way handshake to close connection
• Signalled by the FIN bit in the packet header
20
TCP State Machine
Established
Listen
Closed
SYN recv’d SYN sent
Closing
Time Wait
Close wait
Last ACK
FIN wait 1
FIN wait 2
Closed
Connect/SYN
Close/-Close/-Listen/-
SYN/SYN+ACK
RST/- Send/SYN
SYN/SYN+ACK
SYN+ACK/ACKACK/-
Close/FIN Close/FIN FIN/ACK
Close/FIN
FIN/ACK
FIN+ACK/ACK
FIN/ACKACK/- ACK/-
ACK/-
Timeout/-
(passive close)(active close)
(simultaneous open)
Complete TCP finite state machine: connection establishment and tear down
Note: RFC 793 has a mistake in this diagram 21
TCP Connection Progress
Open connection:192.168.0.4.49159 > 130.209.240.1.80: S 1033471698:1033471698(0) win 65535130.209.240.1.80 > 192.168.0.4.49159: S 3518203430:3518203430(0) ack 1033471699 win 5792192.168.0.4.49159 > 130.209.240.1.80: . ack 3518203431 win 65535Send “GET /index.html HTTP/1.1”:192.168.0.4.49159 > 130.209.240.1.80: P 1033471699:1033471725(26) ack 3518203431 win 65535130.209.240.1.80 > 192.168.0.4.49159: . ack 1033471725 win 5792Send “Host: www.dcs.gla.ac.uk”:192.168.0.4.49159 > 130.209.240.1.80: P 1033471725:1033471746(21) ack 3518203431 win 65535130.209.240.1.80 > 192.168.0.4.49159: . ack 1033471746 win 5792Send blank line:192.168.0.4.49159 > 130.209.240.1.80: P 1033471746:1033471748(2) ack 3518203431 win 65535130.209.240.1.80 > 192.168.0.4.49159: . ack 1033471748 win 5792Receive web page:130.209.240.1.80 > 192.168.0.4.49159: . 3518203431:3518204879(1448) ack 1033471748 win 5792130.209.240.1.80 > 192.168.0.4.49159: . 3518204879:3518206327(1448) ack 1033471748 win 5792192.168.0.4.49159 > 130.209.240.1.80: . ack 3518206327 win 65160Server closes connection:130.209.240.1.80 > 192.168.0.4.49159: FP 3518206327:3518207344(1017) ack 1033471748 win 5792192.168.0.4.49159 > 130.209.240.1.80: . ack 3518207345 win 64143130.209.240.1.80 > 192.168.0.4.49159: . ack 1033471748 win 5792192.168.0.4.49159 > 130.209.240.1.80: F 1033471748:1033471748(0) ack 3518207345 win 65535130.209.240.1.80 > 192.168.0.4.49159: . ack 1033471749 win 5792
22
Questions?
23