Lecture 2-bis.
Internet Transport
Protocols
As seen by the application developer
point of view
G.Bianchi, G.Neglia, V.Mancuso
The primary (in principle unique)
role of Internet transport protocols
Î Extend IP's delivery service (between two end systems)
to a deliver service between two APPLICATION
PROCESSES running on the end systems
Î MAPPING to OSI language:
Ö Port number = TSAP (Transport Service Access Point)
Ö IP address = NSAP (Network Service Access Point)
My app
httpd
Transport
layer
25
Internet
layer
G.Bianchi, G.Neglia, V.Mancuso
80
3211
131.175.15.1
...
Port
IP address
Transport Layer Protocols
Entire network seen as a pipe
Internet
G.Bianchi, G.Neglia, V.Mancuso
...
The Internet level view
Information units travelling in the network: IP packets
Header IP
src & dest IP addr
IP Data
Header transport
src & dest ports
Transport data
App prot
header
G.Bianchi, G.Neglia, V.Mancuso
Data
Where are port numbers?
App prot
header
Data
Transport Header
TCP or UDP
Port
src
Port
dest
…
Transport data
IP Header
Ipaddr Ipaddr
prtc
src dest
G.Bianchi, G.Neglia, V.Mancuso
…
IP Data
Transport Control Protocol (TCP)
Îconnection oriented
ÖTCP connections
Îreliable transfer service.
ÎTCP functions
Appl.
Æapplication addressing (ports)
Æerror recovery (acks and retransmission)
Æreordering (sequence numbers)
Æflow control
Appl.
Æcongestion control
TCP
TCP
IP
IP
IP
IP
IP
G.Bianchi, G.Neglia, V.Mancuso
Services Provided by TCP
ÖConnection-oriented service: preliminary
handshaking procedure creates a full duplex TCP
connection
ÖReliable transport service: communicating
processes can rely on TCP to deliver all the messages
sent without error and in the proper order.
ÎTCP does not provide:
Öa minimum transmission rate guaranteed (sending
rate is regulated by TCP congestion control)
Öany sort of delay guarantees (the World Wide Wait …)
G.Bianchi, G.Neglia, V.Mancuso
User Datagram Protocol (UDP)
ÎConnectionless
ÖUDP packets
Îoffers unreliable transfer service (send
and pray).
ÎUDP functions
Æapplication addressing (ports)
Æerror checking
proc
proc
UDP
UDP
IP
IP
IP
IP
IP
G.Bianchi, G.Neglia, V.Mancuso
Services Provided by UDP
Öconnectionless (no handshaking)
Öarbitrary sending rate service
» no congestion control mechanism present
ÎUDP minimalist lightweight service
model does not provide:
Öany guarantee of reception, any guarantee of order
Öany guarantee on delay
G.Bianchi, G.Neglia, V.Mancuso
UDP
ÎConnectionless
ÖUDP packets
Îunreliable transfer
service
Ösend and pray
ÎUDP functions
Öapplication addressing
(ports)
Öerror checking
G.Bianchi, G.Neglia, V.Mancuso
TCP
Îconnection oriented
ÖTCP connections
Îreliable transfer
service
Öall bytes sent are recv
ÎTCP functions
Öapplication addressing
(ports)
Öerror recovery (acks and
retransmission)
Öreordering (sequence
numbers)
Öflow control
Öcongestion control
Service Requirements
Application
Data Loss Bandwidth
Time sensitive?
file transfer
no loss
elastic
no
electronic mail
no loss
elastic
no
Web documents
no loss
elastic
no
real-time
audio/video
losstolerant
audio: few Kbps to 1Mbps
video: 10's Kbps to 5 Mbps
yes: 100's of msec
stored audio/video
losstolerant
same as interactive
audio/video
yes: few seconds
interactive games
losstolerant
few Kbps to 10's Kbps
yes: 100's msecs
financial
applications
no loss
elastic
yes and no
G.Bianchi, G.Neglia, V.Mancuso
Common Applications and
related transport
Application
Application-layer
protocol
Underlying
Transport Protocol
electronic mail
SMTP (RFC 821)
TCP
remote terminal
Telnet (RTC 854)
access
TCP
Web
HTTP (RFC 2068)
TCP
file transfer
FTP (RFC 959)
TCP
remote file
server
NFS
UDP or TCP
streaming
multimedia
Proprietary (e.g., Real
Networks)
UDP or TCP
Internet
telephony
proprietary (e.g.
Vocaltec)
typically UDP
G.Bianchi, G.Neglia, V.Mancuso
A closer look at applications:
The Socket Interface
Client
(HTTP example)
Server
HTTP request
HTTP
Application
Process
(Browser)
HTTP response
Socket
TCP software
Socket
TRANSPORT PROTOCOL
(for HTTP: TCP)
INTERNET
G.Bianchi, G.Neglia, V.Mancuso
HTTP
Application
Process
(HTTP Daemon)
TCP software
Sockets in Unix OSs
ÎJust file descriptors (everything is a
file in Unix!)
Γstream sockets” using TCP
Γdatagram sockets” using UDP
ÎCommon I/O file functions: read(),
write()
ÎMore powerful I/O functions: send(),
receive()
ÎOther specific function: socket(), bind(),
connect(), listen(), accept()
G.Bianchi, G.Neglia, V.Mancuso
The application developer view
Îthe only mean for apps to send/receive messages is through sockets
Γdoors” that hide transportation infrastructure to processes
ÎVery limited control on transport protocol (buffer sizing, variables)
Application
Process SW
(a normal software program!)
Send
receive
Socket: door to transport SW
G.Bianchi, G.Neglia, V.Mancuso
Why it is trivial (!) to write
networking apps?
INTERNET
Î Application software duties:
Ö open socket (e.g. C, C++, JAVA function call, OS call, external library primitive)
Ö Injects message in its own socket
Ö being confident message is received on the other side
Î TCP software: in charge of managing segments!
Ö reliable message transport when TCP used
Ö Segmentation performed by TCP transmitter
Ö Receive buffer necessary to ensure proper packet’s order & reassembly
G.Bianchi, G.Neglia, V.Mancuso
An open question
ÎSocket: OS interface between the
application and the transport
level
ÎPorts: numbers in the transport
header to identify the specific
application
ÎWhich is the relation?
ÎWe focus on the server
G.Bianchi, G.Neglia, V.Mancuso
A first hypothesis
Îone-to-one mapping
socket
G.Bianchi, G.Neglia, V.Mancuso
port #
Trivial refinement
ÎThe socket is on a specific host,
Îi.e. port# has a local meaning
socket
G.Bianchi, G.Neglia, V.Mancuso
(IP address,port #)
How to reach server socket:
pair of IP Address and Port Number
Mail srv
Web srv
Socket
Incoming
request
Transport
layer
Internet
layer
Socket
Socket
25
80
Proprietary
app
3211
131.175.15.1
...
Port number: univocally
specifies SW process
within the node
IP address (univocally
specifies node)
Î(IP,port): a unique identification of an application layer service to
which requests need to be sent
ÎThe first contact needs well known port #
G.Bianchi, G.Neglia, V.Mancuso
Demultiplexing at receiver (1)
app
app
app
…
Transport SW
IP SW
http
http payload
header
IP packet
Port #
IP addr
G.Bianchi, G.Neglia, V.Mancuso
Information entering app
Software (managed by app
Developer)
Transport data
Transport SW: checks segment;
Sends to application sw based on
Port number
Application demux
IP Data
IP SW: checks IP packet;
Sends to transport sw
Transport demux
Demultiplexing at receiver (2)
app
app
UDP SW
app
…
TCP SW
IP SW
http
http payload
header
IP packet
Port #
IP addr
G.Bianchi, G.Neglia, V.Mancuso
Transport data
IP Data
Information entering app
Software (managed by app
Developer)
Transport SW: checks segment;
Sends to application sw based on
Port number
Application demux
IP SW: checks IP packet;
Sends to transport sw
selects whether UDP or TCP
Transport demux
Does IP software know about
transport protocol?
App prot
header
Data
Transport Header
TCP or UDP
Port
src
Port
dest
…
Transport data
IP Header
Ipaddr Ipaddr
prtc
src dest
…
YES
G.Bianchi, G.Neglia, V.Mancuso
IP Data
Remarks
ÎWhen opening socket, needs to specify
which transport to use!
ÎUDP port numbers are independent from
TCP ones!
Ö This means that TCP looks at TCP ports, while UDP looks at UDP ones
ÎNormally (for pure convenience) port number
= same meaning for TCP and UDP
Ö if a well known service is offered by both TCP and UDP, the port number
is the same
Ö if a well known (low port number) service is offered for one protocol only,
the corresponding port for the other protocol is generally unused
ÎBUT possibly the same port number has
different meaning for TCP and UDP….
Ö Details in RFC1700 or http://www.iana.org/assignments/port-numbers
G.Bianchi, G.Neglia, V.Mancuso
Consequence
Î If two applications employ
different protocols, they can
employ the same port #
Î Mapping refinement
socket
(protocol,IP addr., port #)
Î Is it enough? Not always
G.Bianchi, G.Neglia, V.Mancuso
(TCP) Connections
identified by sockets at its ends
CLIENT
WEB SERVER
IP: 151.100.37.9
Socket
G.Bianchi, G.Neglia, V.Mancuso
IP: 131.175.21.1
Socket
Managing multiple connections
CLIENT A
IP: 151.100.37.9
ÎA socket for each connection is needed,
because each connection has its own
status
Î It is not true for UDP (connectionless)
WEB SERVER
Socket
CLIENT B
IP: 193.47.31.18
IP: 131.175.21.1
Socket A
Socket B
Socket
G.Bianchi, G.Neglia, V.Mancuso
Managing multiple connections
CLIENT A
IP: 151.100.37.9
Port: 3124
CLIENT B
IP: 193.47.31.18
If each port identifies a socket...
ÎHow can a new client know the listen port?
ÎAre the port numbers enough?
WEB SERVER
IP: 131.175.21.1
Port: 80
Port: 81
Port: 12134
G.Bianchi, G.Neglia, V.Mancuso
Managing multiple connections
CLIENT A
IP: 151.100.37.9
Port: 3124
Connections can be distinguished by
client and server IP addresses and ports
Connection A
[<151.100.37.9,3124>,<131.175.21.1,80>]
CLIENT B
IP: 193.47.31.18
Port: 12134
G.Bianchi, G.Neglia, V.Mancuso
SERVER
IP: 131.175.21.1
Port: 80
Connection B
[<193.47.37.9,12134>,<131.175.21.1,80>]
Managing multiple connections
CLIENT 1
IP: 151.100.37.9
Port: 3124
Socket
Two sockets for the same server port!
Connection A
[<151.100.37.9,3124>,<131.175.21.1,80>]
CLIENT 2
IP: 193.47.31.18
SERVER
IP: 131.175.21.1
Socket A
Port: 80
Socket B
Port: 12134
Socket
G.Bianchi, G.Neglia, V.Mancuso
Connection B
[<193.47.37.9,12134>,<131.175.21.1,80>]
Demultiplexing at receiver (3)
app
app
UDP SW
app
…
TCP SW
IP SW
http
http payload
header
IP packet
Port #
Also information about the
IP addresses is
needed at the
transport level
IP addr
G.Bianchi, G.Neglia, V.Mancuso
Transport data
IP Data
Information entering app
Software (managed by app
Developer)
Transport SW: checks segment;
Sends to application sw based on
IP addresses and Port numbers
Application demux
IP SW: checks IP packet;
Sends to transport sw
selects whether UDP or TCP
Transport demux
Conclusions
ÎA socket always identifies
unique protocol and port
socket
(protocol,IP addr, port #)
ÎIt can identify also address and
port of the remote application
socket
G.Bianchi, G.Neglia, V.Mancuso
(prot, src IP addr, src port,
dest IP addr, dest port)
Conclusions
ÎProtocol and port can identify a
unique socket
socket
(protocol,IP addr, port #)
listen ports/sockets
Îbut in general more information
is required
(prot., src IP addr, src port,
socket
dest IP addr, dest port)
connection ports/sockets
G.Bianchi, G.Neglia, V.Mancuso
How to reach client socket
another pair of IP Address and Port Number
ÎThe server needs to know:
ÖThe host to which send a response
Æsrc IP address
ÖThe application software process at client side
capable of correctly interpret the response
Æsrc port #
ÎGenerally client DOES NOT use a well
known port #
ÖIt is not needed (the client starts talking)
ÖOS just assigns one available (Ephemeral ports)
Typical question: WHY every PC needs an IP address?
More complex issue: HOW your home PC gets an IP address?
G.Bianchi, G.Neglia, V.Mancuso
Port numbers
Î16 bit address (0-65535)
Îwell known port numbers for common
servers
ÖFTP 20, TELNET 23, SMTP 25, HTTP 80, POP3 110, … (full
list: http://www.iana.org/assignments/port-numbers)
Înumber assignment
Ö0-1023 (system) well known ports: service contact ports
assigned by IANA, on most systems they can only be used
by system (or root) processes or by programs executed by
privileged users.
Ö1024-49151 (user) registered ports: service contact ports
listed by IANA, on most systems they can be used by
ordinary user processes or programs executed by ordinary
users.
Ö49152-65535 dynamic/private ports.
G.Bianchi, G.Neglia, V.Mancuso
Last remark about terminology
Î Sometimes socket is considered
synonym of the quintet:
(prot., src IP addr, src port,
dest IP addr, dest port)
Ipaddr Ipaddr
prtc
src
dest
G.Bianchi, G.Neglia, V.Mancuso
…
Port
src
Port
dest
…
Data