66

4. Transport layer
 67

OSI – Transport layer

Application

Presentation

Session
• Multiplexing/demultiplexing
Transport • UDP
Network
• TCP

Datalink

Physical
 68

Transport services and protocols

application
provide logical communication transport
network
between app processes running on data link
different hosts physical

transport protocols run in end

systems
send side: breaks app
messages into
segments, passes to
network layer
rcv side: reassembles
segments into
messages, passes to application
transport

app layer network

data link
physical
more than one transport protocol
available to apps
Internet: TCP and UDP
 69

Transport layer
• Cung cấp kết nối định hướng (connection-oriented).
• Xử lý địa chỉ IP và tên miền.
• Các giao thức tiêu biểu: TCP, UDP, FCP, RDP…
• Chịu trách nhiệm kiểm tra dữ liệu đã được gửi thành
công hay không (error-free).
 70

Transport layer
• Cung cấp các cơ chế kiểm tra lỗi gói tin và điều hướng
luồng dữ liệu (flow control) giữa các kết nối.
• End-to-end connection: chia gói tin lớn thành các
segment nhỏ tại nơi gửi và ráp lại đúng thứ tự tại nơi
nhận dựa vào segment sequencing.
 71

Multiplexing/demultiplexing
multiplexing at sender:
handle data from multiple
sockets, add transport header
(later used for demultiplexing)
demultiplexing at receiver:
use header info to deliver
received segments to correct
socket

application

application P1 P2 application socket

P3 transport P4
process
transport network transport
network link network
link physical link
physical physical
 72

How demultiplexing works

host receives IP datagrams 32 bits

 each datagram has source IP
address, destination IP address source port # dest port #
 each datagram carries one
transport-layer segment
 each segment has source, other header fields
destination port number
host uses IP addresses & port
numbers to direct segment to
appropriate socket application
data
(payload)

TCP/UDP segment format

 73

Internet transport-layer protocols

• reliable, in-order application
transport

delivery (TCP)
network
data link
physical

•congestion control network

network
data link

•flow control
data link physical
physical
network

•connection setup data link

physical

• unreliable, unordered network

data link

delivery: UDP physical

network

•no-frills extension of data link

physical

“best-effort” IP
network
data link application
physical transport
network
• services not available: data link
physical
network
data link

•delay guarantees
physical

•bandwidth
guarantees
 74

UDP: User Datagram Protocol [RFC 768]

• “no frills,” “bare bones” Internet
transport protocol
 UDP use:
• “best effort” service, UDP  streaming multimedia
segments may be: apps (loss tolerant, rate
• lost sensitive)
• delivered out-of-  DNS
order to app  SNMP
• connectionless:
• no handshaking  reliable transfer over
between UDP sender, UDP:
receiver  add reliability at
• each UDP segment application layer
handled
independently of  application-specific error
others recovery!
 75

UDP: segment header

length, in bytes of
32 bits UDP segment,
source port # dest port # including header

length checksum
why is there a UDP?
no connection
application establishment (which can
data add delay)
(payload) simple: no connection
state at sender, receiver
small header size
UDP segment format
no congestion control:
UDP can blast away as fast
as desired

UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted
segment
sender:
• treat segment contents,
including header fields, as
sequence of 16-bit integers
• checksum: addition (one’s
complement sum) of
segment contents
• sender puts checksum value
into UDP checksum field
76
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 ….
 77

Internet checksum: example

example: add two 16-bit integers

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

Note: when adding numbers, a carryout from the most

significant bit needs to be added to the result
 78

Why Would Anyone Use UDP?

• Finer control over what data is sent and when
• As soon as an application process writes into the socket
• … UDP will package the data and send the packet
• No delay for connection establishment
• UDP just blasts away without any formal preliminaries
• … which avoids introducing any unnecessary delays
• No connection state
• No allocation of buffers, parameters, sequence #s, etc.
• … making it easier to handle many active clients at once
• Small packet header overhead
• UDP header is only eight-bytes long
 79

Popular Applications That Use UDP

•Multimedia streaming
• Retransmitting lost/corrupted packets is not worthwhile
• By the time the packet is retransmitted, it’s too late
• E.g., telephone calls, video conferencing, gaming
•Simple query protocols like Domain Name System
• Overhead of connection establishment is overkill
• Easier to have application retransmit if needed
“Address for www.cnn.com?”

“12.3.4.15”
 80

TCP: Overview RFCs: 793,1122,1323, 2018, 2581

• point-to-point: full duplex data:

• one sender, one receiver bi-directional data flow
• reliable, in-order byte in same connection
steam: MSS: maximum
• no “message segment size
boundaries” connection-oriented:
• pipelined: handshaking (exchange
• TCP congestion and flow of control msgs) inits
control set window size sender, receiver state
before data exchange
flow controlled:
sender will not
overwhelm receiver
 81

Transmission Control Protocol (TCP)

• Connection oriented
• Explicit set-up and tear-down of TCP session
• Stream-of-bytes service
• Sends and receives a stream of bytes, not messages
• Reliable, in-order delivery
• Checksums to detect corrupted data
• Acknowledgments & retransmissions for reliable delivery
• Sequence numbers to detect losses and reorder data
• Flow control
• Prevent overflow of the receiver’s buffer space
• Congestion control
• Adapt to network congestion for the greater good
 82

TCP segment structure

32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments!)
head not
PSH: push data now len used
UAP R S F receive window
(generally not used) # bytes
checksum Urg data pointer
rcvr willing
RST, SYN, FIN: to accept
options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)
 83

TCP Support for Reliable Delivery

• Checksum
• Used to detect corrupted data at the receiver
• …leading the receiver to drop the packet
• Sequence numbers
• Used to detect missing data
• ... and for putting the data back in order
• Retransmission
• Sender retransmits lost or corrupted data
• Timeout based on estimates of round-trip time
• Fast retransmit algorithm for rapid retransmission
 84

Three-way handshake

Học viện Hàng không Việt Nam

 85

Three-way handshake

Học viện Hàng không Việt Nam

 86

Three-way handshake
•Step 1 (SYN) : establish a connection with server
•Step 2 (SYN + ACK): server responds to the client
request with SYN-ACK signal bits set.
•Step 3 (ACK) : client acknowledges the response
of server and they both establish a reliable
connection starting to transfer data.

Học viện Hàng không Việt Nam