3: transport layer 3a-1 7: transport layer overview and udp last modified: 10/21/2015 9:17:26 pm
Post on 02-Jan-2016
234 Views
Preview:
TRANSCRIPT
3: Transport Layer 3a-1
7: Transport Layer Overview and UDP
Last Modified: 04/20/23 02:36 AM
3: Transport Layer 3a-2
Transport Layer
Overview: transport layer services
multiplexing/demultiplexing (socket to socket delivery) checksum
Roadmap UDP: connectionless transport principles of reliable data transfer TCP: connection-oriented transport, flow control,
congestion control
3: Transport Layer 3a-3
Transport services and protocols
provide logical communication between processes running on different hosts
transport protocols run in end systems
transport vs network layer services:
network layer: data transfer between end systems
transport layer: data transfer between processes relies on, enhances,
network layer services
application
transportnetworkdata linkphysical
application
transportnetworkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysical
networkdata linkphysicalnetwork
data linkphysical
logical end-end transport
3: Transport Layer 3a-4
Transport protocol example
A bit like volunteer at sorority or fraternity house that collects all outgoing mail and delivers to post office and takes incoming mail from post
Analogy to the Internet Hosts = House Processes = people’s mailboxes Application messages = letters in envelopes Network layer protocol = postal service Transport layer protocol = person who volunteers to
multiplex/demultiplex• TCP? Make a copy of each outgoing letter, expect a return
receipt for each one and if not send a new copy, send return receipts for each letter received
• If just hand out whatever comes in then like UDP
3: Transport Layer 3a-5
UDP: User Datagram Protocol [RFC 768]
“no frills,” “bare bones” Internet transport protocol “best effort” service, UDP segments may be:
lost delivered out of order to app
connectionless: no handshaking between UDP sender, receiver each UDP segment handled independently of
others
3: Transport Layer 3a-6
UDP Datagram Format
source port # dest port #
32 bits
Applicationdata
length checksum
Length, inbytes of UDP
datagram,including
header
Entire UDP header is 8 bytes
Ports ( 16 bits each) used for multiplexing and demultiplexing
Length (16 bits) used to find end of data
Checksum (16 bits) used to detect errors
3: Transport Layer 3b-7
TCP segment structure
source port # dest port #
32 bits
applicationdata
(variable length)
sequence number
acknowledgement numberrcvr window size
ptr urgent datachecksum
FSRPAUheadlen
notused
Options (variable length)
Also 16 bits for each
source and destination
ports
Also checksum
No length – relies on
length in IP header
(UDP could the same)
3: Transport Layer 3a-8
Multiplexing/demultiplexing
Demultiplexing based on IP addresses and port number for both the sender and receiver Can distinguish traffic
coming to same port but part of separate conversations (like multiple client connections to a web server)
gathering data from multiple application processes on the same host and sending outthe same network interface
source port # dest port #
32 bits
applicationdata
(message)
other header fields
TCP/UDP segment format
Multiplexing:
Stream of incoming data into one machine separated into smaller streams destined for individual processes
Demultiplexing:
3: Transport Layer 3a-9
Port Implementation
Message queue Append incoming message to the end Much like a mailbox file Choose which message queue based on <src ip+
port, dest ip +port> If queue full, ,message can be discarded
why is that ok? Best effort delivery The network doesn’t guarantee not to drop, so the
OS needn’t guarantee that either When application, reads from socket,
operating system removes some bytes from the head of the queue
If queue empty, application blocks waiting
Transport Layer 3-10
Connectionless demultiplexing recall: create sockets with
host-local port numbers:DatagramSocket mySocket1 = new
DatagramSocket(12534);
DatagramSocket mySocket2 = new DatagramSocket(12535);
recall: when creating datagram to send into UDP socket, must specify
(dest IP address, dest port number)
when host receives UDP segment: checks destination port
number in segment directs UDP segment to
socket with that port number
IP datagrams with different source IP addresses and/or source port numbers directed to same socket
Transport Layer 3-11
Connection-oriented demux
TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number
recv 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 different sockets for each connecting client non-persistent HTTP will
have different socket for each request
3: Transport Layer 3a-12
Multiplexing/demultiplexing example
Two Web browsers on host Aeach open 1 socket
Webserver B
One Web browser onhost C opens 2 sockets
Source IP: CDest IP: B
source port: y
dest. port: 80
Source IP: CDest IP: B
source port: x
dest. port: 80
Source IP: ADest IP: B
source port: x
dest. port: 80
<C,x> to<B,80><A,x> to<B,80> <C,y> to<B,80>
Source IP: ADest IP: B
source port: t
dest. port: 80
<A,t> to<B,80>
3: Transport Layer 3a-13
Demultiplexing Packets arrive
on network interface, copied up into system memory
Placed in message queue by transport protocol, dest IP and port number, src IP and port number
Copied to user level when app reads socket
Drop?
Process A2 ports
Process B1 port
User level
Kernel level
Incoming messages
3: Transport Layer 3a-14
Demultiplexing (cont)
Receiving process may specify combinations of <srcaddr, srcport, destaddr, destport> it will receive or ANY
Demultiplexing by port numbers and IP address: other choices? Ip address and process id? high overhead of
coordination and couldn’t have multiple streams per process
Additional level of addressing by port number provides level of indirection and finer granularity addressing
3: Transport Layer 3a-15
How many ports?
Port field is 16 bits; so 216 or 64K possible ports -not enough for whole Internet, why ok? Just for the single host!
Plenty for even NAT
source port # dest port #
32 bits
Applicationdata
(message)
UDP datagram format
length checksumLength, in
bytes of UDPdatagram,
includingheader
3: Transport Layer 3a-16
UDP header field: checksum
Sender: treat segment contents
as sequence of 16-bit integers (add 0 pad to get even 16 bit chunks if necessary)
One's complement of the sum of all the 16-bit words in the segment.
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. But
maybe errors nonetheless? More later ….
Errors could be anywhere – in data, in headers, even in checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
3: Transport Layer 3a-17
Example
Ones complement sum of : 0110011001100110 0101010101010101 0000111100001111
1’s complement of first two (notice the carry) 0110011001100110 + 0101010101010101 ----------------- 1011101110111011
Add in third 1011101110111011 + 0000111100001111 ----------------- 1100101011001010
Take 1’s complement (ie flip all bits) to get final checksum 0011010100110101
3: Transport Layer 3a-18
Pseudo-header
Checksum over UDP header and the “pseudo header” – not just the data
12 byte Pseudo header precedes UDP header Source and destination IP addresses from IP headers ( 4
bytes each) Protocol ID from IP header ( 1 bytes) Duplicated UDP length from UDP header ( 2 bytes) –
why? 1 byte of padding
Pseudo header to double-check message correctly delivered between endpoints. Ex.Detect if IP address modified in transit
Borrowing from the IP header is terribly un-modular, but decided too expensive to do a checksum at both layers!
3: Transport Layer 3a-19
UDP checksum optional?
Actually optional If sender does not compute set checksum field to 0 If calculated checksum is 0? Store it as all one bits
(65535) which is equivalent in ones-complement arthimetic
If checksum is non-zero and receiver computes a different value, silently drop packet; no error msg generated
Shouldn’t do this unless end-to-end transfer on a very reliable LAN like wired Ethernet
Note: We will talk about more about error detection and correction at the link layer….
3: Transport Layer 3a-20
UDP Header: length
Length of data and header (min value 8 bytes = 0 bytes data)
16 bit length field => max length of 65535 bytes
Can you really send that much? May be limited by kernel send buffer (often
<= 8192 bytes) May be limited by kernel’s IP
implementation (possibly <= 512 bytes) ; Hosts required to receive 576 bytes of UDP data so senders may limit themselves to that as well
3: Transport Layer 3a-21
Why is there a UDP? Why wouldn’t everyone want reliable TCP? UDP has less overhead
UDP has no connection establishment (which can add delay) UDP has small segment header no congestion control: UDP can blast away as fast as desired No connection state at sender, receiver
If don’t need all TCP services DNS: small, retransmit if necessary reliable transfer over UDP: add reliability at application layer application-specific error recover!
Also TCP is based on a full duplex connection so can’t use to send to multiple receivers at once (I.e. broadcast or multicast)
UDP often used for streaming multimedia apps for multicast/broadcast and to avoid overhead
3: Transport Layer 3a-22
Experimenting with UDP
Programs like sock, ttcp or pcattcp allow you to generate streams of TCP or UDP data according to your specifications (total amount of data to send, size of each segment sent, etc.)
Normally, procedure is as follows Start tracer like Ethereal
• Consider a filter like (ip.addr eq senderIPaddress) Start server process (ex. pcattcp –r –u) Start client process sending traffic (ex. pcattcp –t –u <ip
address of server)• Note: loopback or own IP address may not appear in
Ethereal Experiment with different size sends –l bytes (default is
8192) or number of buffers to send –n sends (default is 2048)
• On Ethernet 1473 causes fragmentation, 1472 does not
3: Transport Layer 3a-23
UDP Performance Experiments Vary buffer size , keep total data size the same Should see higher overall throughput when
sending in larger units Why? Many overheads are fixed Packet headers Kernel processing Grabbing channel at physical layer
Also interesting to repeat experiment across different network conditions (on same hub, in same AS, across ASes) Throughout? Data loss
3: Transport Layer 3a-24
TCP vs UDP on a LAN
Compare overall throughput for TCP vs UDP
Expect much lower throughput for TCP – Why? Connection establishment Slowstart Header overhead
On a LAN, TCP shouldn’t see many retransmissions
3: Transport Layer 3a-25
TCP vs UDP on a WAN
Should see retransmissions and thus more slow start/congestion avoidance overhead
Quantify the effect
3: Transport Layer 3a-26
Roadmap
UDP is a very thin layer over IP multiplexing /demultiplexing error detection
TCP does these things also and then adds some other significant features
TCP is quite a bit more complicated and subtle
We are not going to jump right into TCP Start gently thinking about principles of
reliable message transfer in general
top related