COMP3310/6331
Transport Layer: TCP/UDP intro
Dr Markus Buchhorn: markus.buchhorn@anu.edu.au
• Moving further up
Where are we?
2
Link (Ethernet, WiFi, …)
Application
Transport
Network (IPv4, v6)
Session
Presentation
Physical
(Cables, Space and Bits)
Messages
Packets
Frames
Bits
Segments/Datagrams
Ignore the network, focus on applications
3
Net(1)
IP
Air Copper
Link(1)
WiFi
Transport
(1)
TCP, UDP, …
Browser
(1)
HTTP
Net(2)
Link(2)
Transport
(2)
Server
(2)
Ethernet
Physical
(1)
Physical
(2)
20
different
LAN links
Applications don’t know nor care. Unless there is a performance question.
Getting into the transport layer
• Leave all the packet to-and-fro to the network layer
• Everything here is a payload for IP packets
– A Segment or Datagram
• Offers rich functionality (or not) to Applications
– Reliability, performance, security, and other quality measures – on unreliable IP
• Routers and other network devices do not get in the way
– They (should) only look at ‘the envelope’ of a message, not the messages
– This is pure host-to-host.
4
Link
e.g. 802.3 IP
Transport T’port Payload
Simple client/server model
• Servers offer something,
• Clients connect
– Send a request
– Server replies
• Servers can handle multiple clients
• There are other models!
5
Transport Services
• What common application needs are there?
• Two options for reliability:
– Reliable - everything has to arrive bit-perfect.
• Transport layer repairs packet loss, mis-ordering (and other damage)
• I can wait!
– Unreliable
• Don’t care about immediate perfection, …
• Do care about performance, simplicity, …
• (and) Two types of communication
– Messages: self-contained command and response (post office)
– Byte-stream: generic flow of bytes, chunked into segments (conversation)
6
Which does what?
Unreliable Reliable
Messages UDP (“Datagrams”)
Byte-stream TCP (“Streams”)
7
• Could have reliable messages - but can build that on top of TCP
• Could have unreliable byte-streams - but that looks like UDP
Transmission Control Protocol: TCP = IP Protocol 6
User Datagram Protocol: UDP = IP Protocol 17
ICMP = 1, IGMP = 2, IPv6 encapsulation = 41, 130+ more
Compare them
UDP TCP
Connectionless
(minimal state in transport layer)
Connection-oriented
(significant state in transport layer @host)
Delivers MESSAGES:
0-n times, any order
Delivers BYTES: once, reliably, in order
(to your application)
Fixed message size Any number of bytes (in a stream)
Don’t care about flow control Flow control
(sender/receiver negotiate)
Don’t care about congestion Congestion control
(sender/network negotiate)
8
• UDP is an enhanced IP packet
• TCP is a lifestyle choice – many features
IP Multicast: UDP
9
2
6
4
3
5
1
A A
A
Connectionless, maybe time-sensitive
Replica packets are fine!
A
A
A A
Ports
10
Operating System
Net. Interface
Process #1
Process #2
Process #5
Process #3
Process #4
IP is (in theory, not practice) “host-to-host”
Applications are process-to-process
Port: 16bit identifier(s) for a process,
on a host, on an interface,
at each end
Well-known (and other) listening ports
• https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
• Opening ports below 1024 requires extra privileges
11
20,21 ftp File transfer
22 ssh Secure shell
25 smtp Email – outbound
80 http Web
110 pop3 Email – inbound
143 imap Email – inbound
443 https Secure-Web
Usually write an application address as IP:port e.g. 150.203.56.90:80
A Port is just a start
• Inetd/xinetd
– Don’t continually run every server-service somebody may eventually talk to
– Single service, launch appropriate service on demand
– Listens to all (registered) ports and protocols (tcp, udp)
– Spawns the service to have the conversation
• Port mapping
– (e.g. remote procedure calls, bittorrent, …)
– Listen on a well-known port
– Accept connections
– Redirect them to a spawned service on another port
• Services can register with the portmapper
12
NAT is actually NA(and Port)T
• NAT has everyone ‘hiding’ behind a single public IP address
• But everyone wants access to/from the Internet at the same time
• So translate addresses and ports
• Router maintains a table
– Dynamically for outbound. Can be static for inbound.
13
Internet
150.203.56.99
10.0.0.2 10.0.0.3
10.0.0.4 10.0.0.5
“150.203.56.99:7882 = 10.0.0.2:80”
“150.203.56.99:7884 = 10.0.0.4:80”
10.0.0.1
UDP
• UDP adds to IP: Ports, payload length and a Checksum
• And nothing else…
14
Ethernet
802.3 IP
UDP UDP Payload
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Source Port Destination Port
Length Checksum
Payload (…)
Byte-streams
• TCP segments carry chunks of a byte-stream
– “Message” boundaries are not preserved
• Sender OS/driver packetises (eventually) on write()
– Multiple writes can be one packet and vice-versa – buffer dependent
• Receiver unpacks
– Applications read() a stream of bytes – in order, without loss
15
DEF BC A …FEDCBA…
…FEDCBA…
TCP segment format
16
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
Source port Destination Port
Sequence Number
Acknowledgement Number
TCP
Header
Length
C
W
R
E
C
E
U
R
G
A
C
K
P
S
H
R
S
T
S
Y
N
F
I
N
Window Size
Checksum Urgent Pointer
Options (0 or more)
Payload (optional…)
Ports
Reliability
Performance Acknowledgement Start&Stop
Programming connections
• “Socket” programming – an address, a port, and a need to communicate
• Connections are uniquely identified in the Operating System by a ‘5-tuple’
– source/destination ip, source/destination port, protocol
17
Host 1 Host 2
connect
request
reply
disconnect
Standard conversation
time
Socket API
18
Primitive (function) What it does
SOCKET Create an object/descriptor
BIND Attach a local address and port (server)
LISTEN (tcp) Tell network layer to get ready (server)
ACCEPT (tcp) Open the door! (server)
CONNECT (tcp) … Connect … (client)
SEND(tcp) or SENDTO(udp) … Send …
RECEIVE(tcp) or RECEIVEFROM(udp) … Receive …
CLOSE Release the connection/socket
So…
• Server needs to be prepared for connections
• Client initiates the connection
19
connect
request
reply
disconnect
Host 1
Client
Host 2
Server
1. socket()
2. bind()
3. listen()
4. accept() *
1. socket()
5. connect() *
6. recv() *
7. send()
8. recv() * 9. send()
10. close()10. close()
* = call blocks
TCP and reliability
• TCP is a reliable, bidirectional byte-stream
– Uses Sequence Numbers and Acknowledgements to provide reliability
• Sequence numbers: N-bit counter that wraps (e.g. …,253, 254, 255, 0, 1, 2…)
– Byte count (pointer) in a stream – where sender is up to
• Can wrap quickly on high-speed links (232 = 4GB) – can use timestamps too
• Does not start from zero (for security)
• Acknowledgements: Which byte is expected (which have been received)
– cumulative ACK
20
TCP and reliability
• Calculate payload length from increase in Seq #
• Losses are obvious
• Bidirectional:
– Piggybacks control information on data segments in reverse direction
– If there’s no data, just sends feedback 21
01000 bytes 200400600700
Seq 200Seq 400Seq 600Seq 700Seq 1000
Receiver
Ack 201Ack 401Ack 601Ack 701Ack 1001
Sender
• TCP is full-duplex = two simplex paths
– Both need to start together(*)
• SYNchronise Sequence numbers in both directions
• Connecting
– Receiving transport layer decides:
• anybody listen()ing on that port?
– If not, ReSeT
– If yes, passed to receiving process listen()ing,
– Transport layer ACKnowledges, and SYNs own #
– Originator ACKs that SYN/ACK
• and off they go
Getting connected – 3 way handshake
22
• Both need to end together
– Ideally…
– Time to flush buffers
• Disconnecting
– One side initiates close()
– Triggers a FIN(alise)
– Other side ACKs and FINs too
• And if FIN is lost? Resend…
Hanging up
23
Socket states:
State Description
LISTEN Accepting connections
ESTABLISHED Connection up and passing data
SYN_SENT Waiting for reply from remote endpoint
SYN_RECV Session requested by remote, for a listen()ing socket
LAST_ACK Closed; remote shut down; waiting for a final ACK
CLOSE_WAIT Remote shut down; kernel waiting for application to close() socket
TIME_WAIT Socket is waiting after close() for any packets left on the network
CLOSED Socket is being cleared
CLOSING Our socket shut; remote shut; not all data has been ACK’ed
FIN_WAIT1 We sent FIN, waiting on ACK
FIN_WAIT2 We sent FIN, got ACK, waiting on their FIN
24
% netstat -n
25
What’s happening on my machine?
TCP Sliding Windows
• Want reliability and throughput (of course!)
• Start with ARQ – stop-and-wait
– Single segment outstanding = problem on high bandwidth*delay networks
• Say one-way-delay=50ms so round-trip-time (RTT)=2d=100ms
• Single segment per RTT = 10 segments/s
• Typical packet ? Say 1000 bytes = ~10,000 bits -> 100kb/s
• Even if bandwidth goes up, throughput doesn’t!
26
TCP Sliding Windows
• Allow W bytes to be ‘outstanding’ (unACKed) per RTT
– Fill a pipeline/conveyor-belt with segments
• Set up a ‘window’ of W bytes
• W=2*Bandwidth*delay (roughly)
• At 100Mb/s, one-way-delay=50ms means W=10Mb (~1MB)
– Assuming 10kb segments => W=1000 segments
– They are out there somewhere!
27
N 2
1
1
Sliding Window approach
Sender buffers up W segments until they are ACKed
28
Acked Un-Acked Waiting
Seq#
W=5
Available
Acked Un-Acked Waiting
Acked Un-Acked Waiting
Available
Window not full, so send a packet
Packet ACKed, so Window not full
Receiver Sender
If(lost) then: ARQ – “Go Back N”
• Receiver buffers just a single segment
• If it’s the next one in sequence, ACK it, everyone happy
• If it’s not, drop it,
• Let sender retransmit what I’m actually waiting for
• Sender has a single timer. After timeout, resend (all) from (first) ACK-less.
• Really simple, but somewhat inefficient
29
1 2 3 4 5
Everybody runs the same TCP…?
• No. There is no single TCP implementation
• Doesn’t impact the network, only hosts, so you can do what you want…
• Many years of various optimisations, experiments, algorithms, …
– Suited to various circumstances
– And as vulnerabilities have been found and mitigated (and found and …)