Download Chapter 5

Chapter 5
Transport Layer: UDP, TCP
Professor Rick Han
University of Colorado at Boulder
[email protected]
Announcements
• Netstat portion of Homework #3 on Web,
due March 12 (two weeks)
• Programming Assignment #2 due Friday
March 22 by midnight
• Midterm March 14
•
Only through Network Layer, Chapter 4
• OH changed today – 4:45-5:45 due to
BACTAC talk
• Next, transport layer
Prof. Rick Han, University of
Colorado at Boulder
Recap of Previous Lecture
• IP Multicast
•
•
•
•
•
1->N
Link-State Multicast: MOSPF
• Piggyback off of Dijkstra’s shortest path tree
Distance-Vector Multicast: DVMRP
• Reverse-path flooding to all nodes
• Reverse-path pruning
Protocol Independent Multicast: PIM
• For sparse wide-area trees
• Unicast to Rendezvous Point, RP then multicasts
• Tree built by explicit joins
Internet Group Management Protocol (IGMP)
• How leaf nodes join a multicast group
Prof. Rick Han, University of
Colorado at Boulder
The Layered Network Stack
Application Layer
OSI Stack
Internet Stack
Presentation Layer
Application Layer
Session Layer
Transport Layer (TCP/UDP)
Transport Layer
Network Layer (IP)
Network Layer
Data Link Layer
Data Link Layer
Physical Layer
Prof. Rick Han, University of
Colorado at Boulder
Physical Layer
UDP: Unreliable Transport
Protocols
• IP Provides Best-Effort unreliable datagram
delivery
• User Datagram Protocol (UDP) provides besteffort unreliable datagram delivery
•
•
•
Packets may be lost
• Due to congestion
• In routers
• At receiver and/or sender
• Due to fading
Packets may be reordered
Packets may be duplicated
Prof. Rick Han, University of
Colorado at Boulder
UDP (2)
• UDP “Features”
•
Transport protocol above IP
• simply passes IP through to the upper (application)
layers
• UDP “Features”:
•
•
•
•
•
•
Gives app’s the option to send packets unreliably
• Useful for multicast app’s
Low delay transmission for interactive
text/audio/video
Minimal connection setup time
Minimal connection state: “connectionless”
No congestion control – blast away
Build own application-level protocol on top of UDP
Prof. Rick Han, University of
Colorado at Boulder
UDP (3)
16
32
Source Port #
Dest. Port #
UDP length
Checksum
UDP payload data
UDP payload
IP
hdr
• UDP Header:
•
•
•
•
•
UDP
hdr
Only 8 bytes! (vs. IP 20 bytes header)
Source port for UDP sending process
Dest port for UDP receiving process
Length in bytes of UDP header + payload
Checksum over UDP header + payload
Prof. Rick Han, University of
Colorado at Boulder
UDP (4)
• UDP Checksum calculation
•
•
UDP creates a “pseudo-header” containing IP header
info
Doublechecks that the packet has the correct IP
address and UDP port #
16
32
32-bit IP source address
32-bit IP destination address
Pseudo-Header
Protocol UDP length
0
UDP Header
•
Discarded if
checksum fails
Source Port #
Dest. Port #
UDP length
Checksum
UDP payload data
Prof. Rick Han, University of
Colorado at Boulder
UDP Multiplexing/Demultiplexing
Host 1
Host 2
UDP
Port 5100
UDP
Port 5200
IP
•
•
Eth.
MAC
UDP
Port 6001
IP layer inspects
Protocol field = UDP
Sends to buffer of
waiting UDP process
with matching port #
Phys.
UDP
Port 433
IP
Eth
MAC
Phys.
Prof. Rick Han, University of
Colorado at Boulder
TCP: Transmission Control
Protocol – Reliable Delivery
• TCP provides:
•
•
•
Reliable delivery of packets, AND
Stream or in-order delivery
Also, full-duplex service
•
Many applications require reliable in-order delivery of
packets
• Web pages, email, file transfer, …
Why should each application reinvent the wheel?
Can concentrate expert knowledge into building one
reliable protocol provided to every application
• Why TCP, when we can build reliable protocols on
top of UDP?
•
•
Prof. Rick Han, University of
Colorado at Boulder
TCP (2)
• TCP is a true transport protocol, above IP
• TCP “Features”:
TCP payload
•
•
•
•
•
Flow control
Congestion control
IP
TCP
Connection setup
hdr hdr
Connection state machine
Reliability, at the cost of some delay
•
Retransmission of a segment after a timeout or
duplicate ACK
Sliding window with sequence #’s
• Achieves reliability by:
•
Prof. Rick Han, University of
Colorado at Boulder
TCP (3)
• TCP Header:
•
•
•
•
•
20 bytes
Source port for TCP sending process
Dest port for TCP receiving process
32-bit Sequence # (host is sender)
32-bit ACK # (host is receiver ACK’ing data sent by
other endpoint)
16
32
Source Port #
Dest. Port #
32-bit Sequence #
32-bit Acknowledgement #
Flags
Window Size
Checksum
Urgent Pointer
Prof. Rick Han, University of
Colorado at Boulder
TCP (3)
• TCP Header:
•
Flags:
• SYN: synchronize sequence #’s to initiate
connection
• FIN: sender is finished sending data
• RST: reset the connection,
• More…
16
32
Source Port #
Dest. Port #
32-bit Sequence #
32-bit Acknowledgement #
Flags
Window Size
Checksum
Urgent Pointer
Prof. Rick Han, University of
Colorado at Boulder
TCP (4)
• TCP Header:
•
•
•
Flow control window size: Receiver advertises how
many bytes it is willing to accept into its buffer
Checksum: computed over TCP header + payload
• Similar to UDP, prepends an IP Pseudo-Header
Urgent Pointer points to where there is emergency
data in payload
16
32
Source Port #
Dest. Port #
32-bit Sequence #
32-bit Acknowledgement #
Flags
Window Size
Checksum
Urgent Pointer
Prof. Rick Han, University of
Colorado at Boulder
TCP (5)
• TCP Header:
•
•
•
Variable-sized (not just 20 bytes), can have Options
after the Urgent Pointer field
Signalled in Flags field
Most common option: Maximum Segment Size (MSS)
exchanged during setup
16
Source Port #
32
Dest. Port #
32-bit Sequence #
32-bit Acknowledgement #
Flags
Window Size
Checksum
Urgent Pointer
Prof. Rick Han, University of
Colorado at Boulder
High-Level TCP
Characteristics
• Protocol implemented entirely at the ends
– Fate sharing
• Protocol has evolved over time and will continue
to do so
– Nearly impossible to change the header
– Uses options to add information to the header
– Change processing at endpoints
– Backward compatibility is what makes it TCP
Prof. Rick Han, University of
Colorado at Boulder
Connection Setup
• A and B must agree on initial sequence number
selection
• Use 3-way handshake
A
B
SYN + Seq A
SYN+ACK-A + Seq B
ACK-B
Prof. Rick Han, University of
Colorado at Boulder
Connection Setup (2)
• Why a three-way handshake?
– Three-way handshake is necessary and sufficient
for unambiguous setup/teardown even under
conditions of
• Loss
• Duplication
• Delay
Prof. Rick Han, University of
Colorado at Boulder
Two-Way Handshake
Handshake pictures courtesy of UMass Amherst
Prof. Rick Han, University of
Colorado at Boulder
Two-Way Handshake: Old Accepts
Prof. Rick Han, University of
Colorado at Boulder
Two-Way Handshake: Duplicate
Requests
Prof. Rick Han, University of
Colorado at Boulder
Two-Way Handshake: Failure
Prof. Rick Han, University of
Colorado at Boulder
Two-Way Handshake W/ Timers
Prof. Rick Han, University of
Colorado at Boulder
3-way Handshake: Unique ID’s
Server
(passive)
Client:
(active)
• Both sender and receiver choose unique ID’s to
label their (x,y) connection
• x chosen by Sender, y by receiver
• Prevents Failure scenario in two-way handshakes w/o
Prof. Rick Han, University of
timers
Colorado at Boulder