Lecture 04:

Application Layer (1/3)

Principles of network applications &

Web and HTTP

CSIM603154 - Jaringan Komunikasi Data

Fakultas Ilmu Komputer UI
Lecture 04: Roadmap
Chapter 02:
 2.1 Principles of network applications
 2.2 Web and HTTP

2
Some network apps
 e-mail  voice over IP (e.g.,
 web Skype)
 text messaging  real-time video
 remote login
conferencing
 P2P file sharing
 social networking
 multi-user network
 search
games  …
 streaming stored video  …
(YouTube, Hulu,
Netflix)

Application Layer 2-3

Creating a network app application
transport
network
data link

write programs that: physical

 run on (different) end systems

 communicate over network
 e.g., web server software
communicates with browser
software

no need to write software for

application
network-core devices transport
network
 network-core devices do not data link
physical
application
transport
run user applications network
data link

 applications on end systems

physical

allows for rapid app

development, propagation

Application Layer 2-4

 Application architectures

possible structure of applications:

 client-server
 peer-to-peer (P2P)

Application Layer 2-5

Client-server architecture
server:
 always-on host
 permanent IP address
 data centers for scaling

clients:
 communicate with server
 may be intermittently
client/server
connected
 may have dynamic IP
addresses
 do not communicate directly
with each other

Application Layer 2-6

P2P architecture
 no always-on server peer-peer
 arbitrary end systems
directly communicate
 peers request service from
other peers, provide service
in return to other peers
❖ self scalability – new
peers bring new service
capacity, as well as new
service demands
 peers are intermittently
connected and change IP
addresses
❖ complex management

Application Layer 2-7

Processes communicating

process: program clients, servers

running within a host client process: process
that initiates
 within same host, two
communication
processes communicate
server process: process
using inter-process that waits to be contacted
communication (defined
by OS)
❖ aside: applications with
 processes in different P2P architectures have
hosts communicate by client processes &
exchanging messages server processes

Application Layer 2-8

Sockets
 process sends/receives messages to/from its socket
 socket analogous to door
❖ sending process shoves message out door
❖ sending process relies on transport infrastructure
on other side of door to deliver message to socket
at receiving process
application application
socket controlled by
process process app developer

transport transport
network network controlled
link by OS
link Internet
physical physical

Application Layer 2-9

Addressing processes
 to receive messages,  identifier includes both
process must have IP address and port
identifier numbers associated with
 host device has unique process on host.
32-bit IP address  example port numbers:
 Q: does IP address of ❖ HTTP server: 80
host on which process ❖ mail server: 25
runs suffice for  to send HTTP message
identifying the process? to gaia.cs.umass.edu web
▪ A: no, many server:
processes can be ❖ IP address: 128.119.245.12
running on same host ❖ port number: 80
 more shortly…
Application
2-10 Layer
What transport service does an app need?
data integrity throughput
 some apps (e.g., file ❖ some apps (e.g.,
transfer, web multimedia) require
transactions) require minimum amount of
100% reliable data throughput to be
transfer “effective”
 other apps (e.g., audio) can ❖ other apps (“elastic
tolerate some loss apps”) make use of
timing whatever throughput
they get
 some apps (e.g.,
Internet telephony, security
interactive games) ❖ encryption, data
require low delay to be integrity, …
“effective”
Application
2-11 Layer
 Transport service requirements: common apps

application data loss throughput time sensitive

file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s
video:10kbps- msec
stored audio/video loss-tolerant 5Mbps
interactive games loss-tolerant same as above yes, few secs
text messaging no loss few kbps up yes, 100’s
elastic msec
yes and no

Application
2-12 Layer
Internet transport protocols services
TCP service: UDP service:
 reliable transport  unreliable data transfer
between sending and between sending and
receiving process receiving process
 flow control: sender  does not provide:
won’t overwhelm reliability, flow control,
receiver
congestion control, timing,
 congestion control: throughput guarantee,
throttle sender when security, or connection
network overloaded
setup,
 does not provide: timing,
minimum throughput
guarantee, security Q: why bother? Why is
 connection-oriented: there a UDP?
setup required between
client and server
processes
Application
2-13 Layer
 Internet apps: application, transport protocols

application underlying
application layer protocol transport protocol

e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia HTTP (e.g., YouTube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) TCP or UDP

Application
2-14 Layer
Securing TCP

TCP & UDP SSL is at app layer

 no encryption  Apps use SSL libraries,
 cleartext passwds sent into which “talk” to TCP
socket traverse Internet in
cleartext SSL socket API
SSL ❖ cleartext passwds sent

 provides encrypted TCP into socket traverse

connection Internet encrypted
 data integrity ❖ See Chapter 7
 end-point authentication

Application
2-15 Layer
Lecture 04: Roadmap
Chapter 02:
 2.1 Principles of network applications
 2.2 Web and HTTP

16
Web and HTTP
First, a review…
 web page consists of objects
 object can be HTML file, JPEG image, Java
applet, audio file,…
 web page consists of base HTML-file which
includes several referenced objects
 each object is addressable by a URL, e.g.,

www.someschool.edu/someDept/pic.gif

host name path name

Application
2-17 Layer
HTTP overview
HTTP: hypertext
transfer protocol
 Web’s application
layer protocol PC running
Firefox browser
 client/server model
❖ client: browser that
requests, receives,
(using HTTP server
protocol) and running
“displays” Web Apache Web
objects server
❖ server: Web server
sends (using HTTP iphone running
protocol) objects in Safari browser
response to
requests
Application Layer 2-18
HTTP overview (continued)
uses TCP:
 client initiates TCP
connection (creates socket)
to server, port 80
 server accepts TCP
connection from client
 HTTP messages (application-
layer protocol messages)
exchanged between browser
(HTTP client) and Web
server (HTTP server)
 TCP connection closed
HTTP is “stateless”
 server maintains no
information about past
client requests
aside
protocols that maintain
“state” are complex!
❖ past history (state) must
be maintained
❖ if server/client crashes,
their views of “state” may
be inconsistent, must be
reconciled
Application Layer 2-19
HTTP connections
non-persistent HTTP persistent HTTP
 at most one object sent  multiple objects
over TCP connection can be sent over
❖ connection then closed single TCP
 downloading multiple
connection between
objects required multiple client, server
connections

Application Layer 2-20

 Nonpersistent HTTP
Suppose user enters URL
www.someSchool.edu/someDepartment/home.index
1a. HTTP client initiates TCP
connection to HTTP server
(process) at
www.someSchool.edu on port 80
2. HTTP client sends HTTP
request message (containing
URL) into TCP connection
socket. Message indicates
that client wants object
someDepartment/home.index
time
(contains text,
references to 10
jpeg images)
1b. HTTP server at host
www.someSchool.edu waiting
for TCP connection at port 80.
“accepts” connection, notifying
client
3. HTTP server receives request
message, forms response
message containing requested
object, and sends message
into its socket
21
 Nonpersistent HTTP (cont.)

4. HTTP server closes TCP

connection.
5. HTTP client receives response
message containing html file,
displays html. Parsing html
file, finds 10 referenced jpeg
objects
time 6. Steps 1-5 repeated for each
of 10 jpeg objects

22
Non-persistent HTTP: response time

RTT (definition): time for a

small packet to travel from
client to server and back
HTTP response time: initiate TCP
 one RTT to initiate TCP connection
connection RTT
 one RTT for HTTP request request
file
and first few bytes of HTTP time to
response to return RTT transmit
file
 file transmission time
file
 non-persistent HTTP received
response time =
2RTT+ file transmission time time
time

Application
2-23 Layer
Persistent HTTP

non-persistent HTTP persistent HTTP:

issues:  server leaves connection
open after sending
 requires 2 RTTs per response
object  subsequent HTTP messages
 OS overhead for each between same
TCP connection client/server sent over
open connection
 browsers often open  client sends requests as
parallel TCP soon as it encounters a
connections to fetch referenced object
referenced objects  as little as one RTT for all
the referenced objects

Application Layer 2-24

 HTTP request message

 two types of HTTP messages: request, response

 HTTP request message:
❖ ASCII (human-readable format)
carriage return character
line-feed character
request line
(GET, POST, GET /index.html HTTP/1.1\r\n
HEAD commands) Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
header Accept-Language: en-us,en;q=0.5\r\n
lines Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
carriage return, Keep-Alive: 115\r\n
line feed at start Connection: keep-alive\r\n
\r\n
of line indicates
end of header lines
Application
2-25 Layer
HTTP request message: general format

method sp URL sp version cr lf request

line
header field name value cr lf
header
~
~ ~
~ lines

header field name value cr lf

cr lf

~
~ entity body ~
~ body

Application
2-26 Layer
Uploading form input
POST method:
 web page often
includes form input
 input is uploaded to
server in entity body
URL method:
 uses GET method
 input is uploaded in
URL field of request
line: www.somesite.com/animalsearch?monkeys&banana

Application Layer 2-27

Method types

HTTP/1.0: HTTP/1.1:
 GET  GET, POST, HEAD
 POST  PUT
 HEAD ❖ uploads file in
❖ asks server to leave entity body to path
requested object specified in URL
out of response field
 DELETE
❖ deletes file
specified in the
URL field
Application Layer 2-28
 HTTP response message
status line
(protocol
status code HTTP/1.1 200 OK\r\n
status phrase) Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n
ETag: "17dc6-a5c-bf716880"\r\n
header Accept-Ranges: bytes\r\n
Content-Length: 2652\r\n
lines
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-1\r\n
\r\n
data data data data data ...

data, e.g.,
requested
HTML file
Application
2-29 Layer
HTTP response status codes
❖ status code appears in 1st line in server-to-
client response message.
❖ some sample codes:
200 OK
❖ request succeeded, requested object later in this msg
301 Moved Permanently
❖ requested object moved, new location specified later in this
msg (Location:)
400 Bad Request
❖ request msg not understood by server
404 Not Found
❖ requested document not found on this server
505 HTTP Version Not Supported
Application Layer 2-30
Review
 What is
❖ Client-server ❖ Put method
❖ Peer-to-peer ❖ Head method
❖ TCP ❖ Delete method
❖ UDP ❖ Http Non-persistent
❖ Socket ❖ Http Persistent
❖ SSL
❖ http
❖ Post method
❖ Get method

31
 Lecture 05

Application Layer (2/3)

Cookies, FTP,
Electronic Mail & DNS

CSIM603154 - Jaringan Komunikasi Data

Fakultas Ilmu Komputer UI
Lecture 05: Roadmap
Chapter 2:
❖ 2.2 Web and HTTP
❖ 2.3 FTP
❖ 2.4 Electronic Mail
▪ SMTP, POP3, IMAP
❖ 2.5 DNS

2
User-server state: cookies
many Web sites use cookies example:
❖ Susan always access Internet
four components:
from PC
1) cookie header line of
❖ visits specific e-commerce
HTTP response
site for first time
message
❖ when initial HTTP requests
2) cookie header line in arrives at site, site creates:
next HTTP request
message ▪ unique ID
▪ entry in backend
3) cookie file kept on
database for ID
user’s host, managed
by user’s browser
4) back-end database at
Web site
Application Layer2-3
 Cookies: keeping “state” (cont.)
client server

ebay 8734
usual http request msg Amazon server
cookie file creates ID
usual http response
1678 for user create backend
ebay 8734
set-cookie: 1678 entry database
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
usual http response msg action

one week later:

access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
specific
usual http response msg action
Application Layer2-4
Cookies (continued)
aside
what cookies can be used cookies and privacy:
for: ❖ cookies permit sites to
❖ authorization learn a lot about you
❖ shopping carts
❖ you may supply name and
❖ recommendations
e-mail to sites
❖ user session state (Web
e-mail)

how to keep “state”:

❖ protocol endpoints: maintain state at
sender/receiver over multiple
transactions
❖ cookies: http messages carry state

Application Layer2-5
Web caches (proxy server)
goal: satisfy client request without involving origin server

❖ user sets browser: Web

accesses via cache
❖ browser sends all HTTP proxy
requests to cache server
client
▪ object in cache: cache origin
server
returns object
▪ else cache requests
object from origin
server, then returns
object to client client origin
server

Application Layer2-6
More about Web caching
❖ cache acts as both why Web caching?
client and server ❖ reduce response time
▪ server for original for client request
requesting client
▪ client to origin server ❖ reduce traffic on an
❖ typically cache is institution’s access link
installed by ISP ❖ Internet dense with
(university, company, caches: enables “poor”
residential ISP) content providers to
effectively deliver
content (so too does
P2P file sharing)

Application Layer2-7
Conditional GET
client server
❖ Goal: don’t send object if
cache has up-to-date
cached version HTTP request msg
object
If-modified-since: <date>
▪ no object transmission not
delay modified
▪ lower link utilization HTTP response
before
HTTP/1.0
❖ cache: specify date of 304 Not Modified <date>
cached copy in HTTP
request
If-modified-since:
<date> HTTP request msg
❖ server: response contains If-modified-since: <date> object
modified
no object if cached copy after
HTTP response
is up-to-date: HTTP/1.0 200 OK <date>
HTTP/1.0 304 Not <data>
Modified
Application Layer2-8
Lecture 05: Roadmap
Chapter 2:
❖ 2.2 Web and HTTP
❖ 2.3 FTP
❖ 2.4 Electronic Mail
▪ SMTP, POP3, IMAP
❖ 2.5 DNS

9
FTP: the file transfer protocol
file transfer
FTP FTP FTP
user client server
interface
user
at host remote file
local file system
system

❖ transfer file to/from remote host

❖ client/server model
▪ client: side that initiates transfer (either to/from remote)
▪ server: remote host
❖ ftp: RFC 959
❖ ftp server: port 21
Application Layer2-10
FTP: separate control, data connections

❖ FTP client contacts FTP server TCP control connection,

server port 21
at port 21, using TCP
❖ client authorized over control TCP data connection,
connection FTP server port 20 FTP
client server
❖ client browses remote
directory, sends commands
over control connection ❖ server opens another TCP
data connection to transfer
❖ when server receives file another file
transfer command, server
opens 2nd TCP data ❖ control connection: “out of
connection (for file) to client band”
❖ after transferring one file, ❖ FTP server maintains
server closes data connection “state”: current directory,
earlier authentication

Application Layer2-11
FTP commands, responses
sample commands:
❖ sent as ASCII text over
control channel
❖ USER username
❖ PASS password
❖ LIST return list of file in
current directory
❖ RETR filename
retrieves (gets) file
❖ STOR filename stores
(puts) file onto remote
host
sample return codes
❖ status code and phrase (as
in HTTP)
❖ 331 Username OK,
password required
❖ 125 data
connection
already open;
transfer starting
❖ 425 Can’t open
data connection
❖ 452 Error writing
file
Application Layer2-12
Lecture 05: Roadmap
Chapter 2:
❖ 2.2 Web and HTTP
❖ 2.3 FTP
❖ 2.4 Electronic Mail
▪ SMTP, POP3, IMAP
❖ 2.5 DNS

13
Electronic mail outgoing
message queue
user mailbox
Three major components: user
❖ user agents agent

❖ mail servers mail user

❖ simple mail transfer protocol: server agent
SMTP
SMTP mail user
User Agent server agent

❖ a.k.a. “mail reader” SMTP

❖ composing, editing, reading mail user
messages SMTP
agent
mail
❖ e.g., Outlook, Thunderbird, server
iPhone mail client user
❖ outgoing, incoming messages agent
stored on server user
agent

Application Layer2-14
Electronic mail: mail servers
mail servers: user
agent
❖ mailbox contains incoming
messages for user mail user
server
❖ message queue of outgoing agent

(to be sent) mail messages SMTP mail user

❖ SMTP protocol between server agent
mail servers to send email SMTP
messages user
▪ client: sending mail SMTP
agent
mail
server server
▪ “server”: receiving mail user
agent
server
user
agent

Application Layer2-15
Electronic Mail: SMTP [RFC 2821]
❖ uses TCP to reliably transfer email message from
client to server, port 25
❖ direct transfer: sending server to receiving
server
❖ three phases of transfer
▪ handshaking (greeting)
▪ transfer of messages
▪ closure
❖ command/response interaction (like HTTP, FTP)
▪ commands: ASCII text
▪ response: status code and phrase
❖ messages must be in 7-bit ASCI
Application Layer2-16
Scenario: Alice sends message to Bob
1) Alice uses UA to compose
message “to”
bob@someschool.edu
2) Alice’s UA sends message
to her mail server; message
placed in message queue
3) client side of SMTP opens
TCP connection with Bob’s
mail server
4) SMTP client sends Alice’s
message over the TCP
connection
5) Bob’s mail server places the
message in Bob’s mailbox
6) Bob invokes his user agent
to read message

1 user mail user

mail agent
agent server server
2 3 6
4
5
Alice’s mail server Bob’s mail server
Application Layer2-17
Sample SMTP interaction
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

Application Layer2-18
SMTP: final words
❖ SMTP uses persistent comparison with HTTP:
connections
❖ HTTP: pull
❖ SMTP requires message
(header & body) to be in ❖ SMTP: push
7-bit ASCII ❖ both have ASCII
❖ SMTP server uses command/response
CRLF.CRLF to interaction, status codes
determine end of message
❖ HTTP: each object
encapsulated in its own
response msg
❖ SMTP: multiple objects
sent in one msg

Application Layer2-19
Mail message format

SMTP: protocol for

exchanging email msgs header
blank
RFC 822: standard for text line
message format:
❖ header lines, e.g.,
▪ To: body
▪ From:
▪ Subject:
different from SMTP MAIL
FROM, RCPT TO:
commands!
❖ Body: the “message”
▪ ASCII characters only

Application Layer2-20
Mail access protocols
user
mail access user
SMTP SMTP protocol
agent agent
(e.g., POP,
IMAP)

sender’s mail receiver’s mail

server server

❖ SMTP: delivery/storage to receiver’s server

❖ mail access protocol: retrieval from server
▪ POP: Post Office Protocol [RFC 1939]: authorization,
download
▪ IMAP: Internet Mail Access Protocol [RFC 1730]: more
features, including manipulation of stored msgs on
server
▪ HTTP: gmail, Hotmail, Yahoo! Mail, etc.

Application Layer2-21
POP3 protocol
S: +OK POP3 server ready
C: user bob
authorization phase S:
C:
+OK
pass hungry
❖ client commands: S: +OK user successfully logged on
▪ user: declare username
▪ pass: password C: list
S: 1 498
❖ server responses
S: 2 912
▪ +OK S: .
▪ -ERR C: retr 1
transaction phase, client: S:
S:
<message 1 contents>
.
❖ list: list message numbers C: dele 1
❖ retr: retrieve message by C: retr 2
number S: <message 1 contents>
❖ dele: delete S: .
❖ quit C: dele 2
C: quit
S: +OK POP3 server signing off
Application Layer2-22
POP3 (more) and IMAP
more about POP3 IMAP
❖ previous example uses ❖ keeps all messages in one
POP3 “download and place: at server
delete” mode ❖ allows user to organize
▪ Bob cannot re-read e- messages in folders
mail if he changes ❖ keeps user state across
client sessions:
❖ POP3 “download-and- ▪ names of folders and
keep”: copies of messages mappings between
on different clients message IDs and folder
❖ POP3 is stateless across name
sessions

Application Layer2-23
Lecture 05: Roadmap
Chapter 2:
❖ 2.2 Web and HTTP
❖ 2.3 FTP
❖ 2.4 Electronic Mail
▪ SMTP, POP3, IMAP
❖ 2.5 DNS

24
DNS: domain name system
people: many identifiers: Domain Name System:
▪ SSN, name, passport # ❖ distributed database
Internet hosts, routers: implemented in hierarchy of
▪ IP address (32 bit) - many name servers
used for addressing ❖ application-layer protocol: hosts,
datagrams name servers communicate to
▪ “name”, e.g., resolve names (address/name
www.yahoo.com - translation)
used by humans ▪ note: core Internet function,
Q: how to map between IP implemented as application-
layer protocol
address and name, and
vice versa ? ▪ complexity at network’s
“edge”

Application Layer2-25
DNS: services, structure
DNS services why not centralize DNS?
❖ hostname to IP address ❖ single point of failure
translation ❖ traffic volume
❖ host aliasing ❖ distant centralized database
▪ canonical, alias names ❖ maintenance
❖ mail server aliasing
❖ load distribution A: doesn’t scale!
▪ replicated Web
servers: many IP
addresses correspond
to one name

Application Layer2-26
DNS: a distributed, hierarchical database
Root DNS Servers

… …

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu

yahoo.com amazon.com
DNS servers DNS serversDNS servers
DNS servers DNS servers

client wants IP for www.amazon.com; 1st approx:

❖ client queries root server to find com DNS server
❖ client queries .com DNS server to get amazon.com DNS server
❖ client queries amazon.com DNS server to get IP address for
www.amazon.com

Application Layer2-27
 DNS: root name servers
❖ contacted by local name server that can not resolve name
❖ root name server:
▪ contacts authoritative name server if name mapping not known
▪ gets mapping
▪ returns mapping to local name server

c. Cogent, Herndon, VA (5 other sites)

d. U Maryland College Park, MD k. RIPE London (17 other sites)
h. ARL Aberdeen, MD
j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites)

e. NASA Mt View, CA m. WIDE Tokyo

f. Internet Software C. (5 other sites)
Palo Alto, CA (and 48 other
sites)

a. Verisign, Los Angeles CA 13 root name

(5 other sites)
b. USC-ISI Marina del Rey, CA
“servers”
l. ICANN Los Angeles, CA worldwide
(41 other sites)
g. US DoD Columbus,
OH (5 other sites)

Application Layer2-28
TLD, authoritative servers
top-level domain (TLD) servers:
▪ responsible for com, org, net, edu, aero, jobs, museums,
and all top-level country domains, e.g.: uk, fr, ca, jp
▪ Network Solutions maintains servers for .com TLD
▪ Educause for .edu TLD
authoritative DNS servers:
▪ organization’s own DNS server(s), providing
authoritative hostname to IP mappings for organization’s
named hosts
▪ can be maintained by organization or service provider

Application Layer2-29
 Local DNS name server
❖ does not strictly belong to hierarchy
❖ each ISP (residential ISP, company, university) has one
▪ also called “default name server”
❖ when host makes DNS query, query is sent to its local DNS server
▪ has local cache of recent name-to-address translation pairs (but may be out
of date!)
▪ acts as proxy, forwards query into hierarchy

Application Layer2-30
DNS name root DNS server
resolution example
2
❖ host at cis.poly.edu 3
TLD DNS server
wants IP address for 4
gaia.cs.umass.edu
5

iterated query: local DNS server

dns.poly.edu
❖ contacted server 7 6
1 8
replies with name of
server to contact
authoritative DNS server
❖ “I don’t know this dns.cs.umass.edu
name, but ask this requesting host
server” cis.poly.edu

gaia.cs.umass.edu

Application Layer2-31
DNS name root DNS server
resolution example
2 3
recursive query: 7
6
❖ puts burden of name TLD DNS
server
resolution on
contacted name local DNS server
server dns.poly.edu 5 4

❖ heavy load at upper 1 8

levels of hierarchy?
authoritative DNS server
dns.cs.umass.edu
requesting host
cis.poly.edu

gaia.cs.umass.edu

Application Layer2-32
DNS: caching, updating records
❖ once (any) name server learns mapping, it caches
mapping
▪ cache entries timeout (disappear) after some time (TTL)
▪ TLD servers typically cached in local name servers
• thus root name servers not often visited
❖ cached entries may be out-of-date (best effort
name-to-address translation!)
▪ if name host changes IP address, may not be known
Internet-wide until all TTLs expire
❖ update/notify mechanisms proposed IETF standard
▪ RFC 2136

Application Layer2-33
DNS records
DNS: distributed db storing resource records (RR)
RR format: (name, value, type, ttl)

type=A type=CNAME
▪ name is hostname ▪ name is alias name for some
▪ value is IP address “canonical” (the real) name
type=NS ▪ www.ibm.com is really
▪ name is domain (e.g., servereast.backup2.ibm.com
foo.com) ▪ value is canonical name
▪ value is hostname of
authoritative name type=MX
server for this domain ▪ value is name of mailserver
associated with name

Application Layer2-34
Inserting records into DNS
❖ example: new startup “Network Utopia”
❖ register name networkuptopia.com at DNS registrar
(e.g., Network Solutions)
▪ provide names, IP addresses of authoritative name server
(primary and secondary)
▪ registrar inserts two RRs into .com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
❖ create authoritative server type A record for
www.networkuptopia.com; type MX record for
networkutopia.com

Application Layer2-35
Review
❖ What is ▪ TLD DNS Server
▪ Cookie ▪ Authoritative DNS Server
▪ Web Proxy ▪ Local DNS Server
▪ FTP ▪ DNS Records
▪ Dual Band Channel in FTP ▪ MX
▪ SMTP Server ▪ CNAME
▪ SMTP Client ▪ NS
▪ User Agent ▪ DNS Query
▪ POP3 ▪ DNS Response
▪ IMAP
▪ DNS
▪ Root DNS Server
Application Layer2-36
 Transport Layer

Socket programming

CSI3601504 - Jaringan Komunikasi

Data
Semester Gasal 2020-2021
Fakultas Ilmu Komputer UI
Lecture 06: Roadmap
Chapter 2:
❖ 2.7 Socket programming with UDP
❖ 2.8 Socket programming with TCP

2
Socket programming
goal: learn how to build client/server applications that
communicate using sockets
socket: door between application process and end-
end-transport protocol

application application
socket controlled by
process process app developer

transport transport
network network controlled
link by OS
link Internet
physical physical

Application Layer 2-3

 Socket programming
Two socket types for two transport services:
▪ UDP: unreliable datagram
▪ TCP: reliable, byte stream-oriented

Application Example:
1. Client reads a line of characters (data) from its
keyboard and sends the data to the server.
2. The server receives the data and converts
characters to uppercase.
3. The server sends the modified data to the client.
4. The client receives the modified data and displays
the line on its screen.
Application Layer 2-4
Socket programming with UDP
UDP: no “connection” between client & server
❖ no handshaking before sending data
❖ sender explicitly attaches IP destination address and
port # to each packet
❖ rcvr extracts sender IP address and port# from
received packet
UDP: transmitted data may be lost or received
out-of-order
Application viewpoint:
❖ UDP provides unreliable transfer of groups of bytes
(“datagrams”) between client and server

Application Layer 2-5

Client/server socket interaction: UDP

server (running on serverIP) client

create socket, port= x:
serverSocket =
socket(AF_INET,SOCK_DGRAM)
read datagram from
serverSocket
create socket:
clientSocket =
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP and
port=x; send datagram via
clientSocket

write reply to
serverSocket read datagram from
specifying clientSocket
client address,
port number close
clientSocket

Application 2-6
 Example app: UDP client
include Python’s socket
library
create UDP socket for
server
get user keyboard
input
Attach server name, port to
message; send into socket
read reply characters from
socket into string
print out received string
and close socket
Python version 2
Python UDPClient
from socket import *
serverName = ‘hostname’
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_DGRAM)
message = raw_input(’Input lowercase sentence:’)
clientSocket.sendto(message,(serverName, serverPort))
modifiedMessage, serverAddress =
clientSocket.recvfrom(2048)
print modifiedMessage
clientSocket.close()
Application Layer 2-7
 Example app: UDP server
create UDP socket
bind socket to local port
number 12000
loop forever
Read from UDP socket into
message, getting client’s
address (client IP and port)
send upper case string
back to this client
Python version 2
Python UDPServer
from socket import *
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_DGRAM)
serverSocket.bind(('', serverPort))
print “The server is ready to receive”
while 1:
message, clientAddress = serverSocket.recvfrom(2048)
modifiedMessage = message.upper()
serverSocket.sendto(modifiedMessage, clientAddress)
Application Layer 2-8
Socket programming with TCP
client must contact server
❖ server process must first be
running
❖ server must have created
socket (door) that
welcomes client’s contact
client contacts server by:
❖ Creating TCP socket,
specifying IP address, port
number of server process
❖ when client creates socket:
client TCP establishes
connection to server TCP
❖ when contacted by client,
server TCP creates new socket
for server process to
communicate with that
particular client
▪ allows server to talk with
multiple clients
▪ source port numbers used
to distinguish clients
(more in Chap 3)
application viewpoint:
TCP provides reliable, in-order
byte-stream transfer (“pipe”)
between client and server
Application Layer 2-9
Client/server socket interaction: TCP
server (running on hostid) client
create socket,
port=x, for incoming
request:
serverSocket = socket()

wait for incoming create socket,

connection request
TCP connect to hostid, port=x
connectionSocket = connection setup clientSocket = socket()
serverSocket.accept()

send request using

read request from clientSocket
connectionSocket

write reply to
connectionSocket read reply from
clientSocket
close
connectionSocket close
clientSocket

Application Layer 2-10

 Example app: TCP client Python version 2

Python TCPClient
from socket import *
serverName = ’servername’
create TCP socket for
serverPort = 12000
server, remote port 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,serverPort))
sentence = raw_input(‘Input lowercase sentence:’)
No need to attach server clientSocket.send(sentence)
name, port
modifiedSentence = clientSocket.recv(1024)
print ‘From Server:’, modifiedSentence
clientSocket.close()

Application Layer 2-11

 Example app: TCP server
create TCP welcoming
socket
server begins listening for
incoming TCP requests
loop forever
server waits on accept()
for incoming requests, new
socket created on return
read bytes from socket (but
not address as in UDP)
close connection to this
client (but not welcoming
socket)
Python version 2
Python TCPServer
from socket import *
serverPort = 12000
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
print ‘The server is ready to receive’
while 1:
connectionSocket, addr = serverSocket.accept()
sentence = connectionSocket.recv(1024)
capitalizedSentence = sentence.upper()
connectionSocket.send(capitalizedSentence)
connectionSocket.close()
Application Layer 2-12
Example app: UDP client Python version 3

Python UDPClient
from socket import *
serverName = 'localhost'
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_DGRAM)

message = input('Input lowercase sentence: ')

clientSocket.sendto(message.encode(),(serverName, serverPort))
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)

print('Answer from server: ',modifiedMessage.decode())

clientSocket.close()

Application Layer 2-13

Example app: UDP server Python version 3

Python UDPServer
from socket import *

serverPort = 12000
serverSocket = socket(AF_INET, SOCK_DGRAM)
serverSocket.bind(('localhost', serverPort))
print ('The server is ready to receive')
while 1:
message, clientAddress = serverSocket.recvfrom(2048)
modifiedMessage = message.upper()
print('Message from client',message)
print('Message answer for client',modifiedMessage)
serverSocket.sendto(modifiedMessage, clientAddress)
Application Layer 2-14
Example app: TCP client Python version 3

Python TCPClient
from socket import *
serverName = 'localhost'
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,serverPort))
sentence = input('Input lowercase sentence: ')
clientSocket.send(sentence.encode())
modifiedSentence = clientSocket.recv(1024)
print('Answer From Server: ', modifiedSentence.decode())
clientSocket.close()

Application Layer 2-15

Example app: TCP server Python version 3

Python TCPServer
from socket import *
serverPort = 12000
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind(('localhost',serverPort))
serverSocket.listen(1)

print('The server is ready to receive')

while(True):
connectionSocket, addr = serverSocket.accept()

sentence = connectionSocket.recv(1024)
capitalizedSentence = sentence.upper()
connectionSocket.send(capitalizedSentence)
connectionSocket.close() Application Layer 2-16
Chapter 2: summary
our study of network apps now complete!
❖ application architectures ❖ specific protocols:
▪ client-server ▪ HTTP
▪ P2P ▪ FTP
❖ application service
requirements: ▪ SMTP, POP3, IMAP
▪ reliability, bandwidth, delay ▪ DNS
❖ Internet transport service ▪ P2P
model ❖ socket programming: TCP,
▪ connection-oriented, UDP sockets
reliable: TCP
▪ unreliable, datagrams: UDP

Application Layer 2-17

Review
❖ What is ▪ NS
▪ POP3 ▪ DNS Query
▪ IMAP ▪ DNS Response
▪ DNS ▪ Socket
▪ Root DNS Server
▪ TLD DNS Server
▪ Authoritative DNS
Server
▪ Local DNS Server
▪ DNS Records
▪ MX
▪ CNAME
Application Layer 2-18
 Lecture 07:

Transport Layer (1/2)

Transport-layer services, Multiplexing,

Demultiplexing, UDP & TCP

CSIM603154 – Jaringan Komputer

Fakultas Ilmu Komputer UI

1
Lecture 07: Roadmap
❖ 3.1 Transport-layer services
❖ 3.2 Multiplexing and demultiplexing
❖ 3.3 Connectionless transport: UDP
❖ 3.4 Connection-oriented transport: TCP
▪ segment structure
▪ reliable data transfer
▪ flow control
▪ connection management

2
Transport services and protocols
❖ provide logical communication application

between app processes transport

network
running on different hosts data link
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 app layer application
❖ more than one transport transport
network
protocol available to apps data link
physical

▪ Internet: TCP and UDP

Transport Layer3-3
Transport vs. network layer
❖ network layer: logical household analogy:
communication
between hosts 12 kids in Ann’s house sending
letters to 12 kids in Bill’s
❖ transport layer: house:
logical ❖ hosts = houses
communication ❖ processes = kids

between processes ❖ app messages = letters in

envelopes
▪ relies on, enhances, ❖ transport protocol = Ann
network layer and Bill who demux to in-
services house siblings
❖ network-layer protocol =
postal service

Transport Layer3-4
Internet transport-layer protocols
application
❖ reliable, in-order transport
network

delivery (TCP) data link

physical
network

▪ congestion control network

data link
data link
physical
physical
▪ flow control network
data link

▪ connection setup physical

network

❖ unreliable, unordered data link

physical

delivery: UDP network

data link
physical
▪ no-frills extension of network
data link application
“best-effort” IP physical
network
data link
transport
network
data link
❖ services not available: physical
physical

▪ delay guarantees
▪ bandwidth guarantees

Transport Layer3-5
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

Transport Layer3-6
How demultiplexing works
❖ host receives IP datagrams 32 bits
▪ each datagram has source IP
source port # dest port #
address, destination IP
address
▪ each datagram carries one other header fields
transport-layer segment
▪ each segment has source,
destination port number application
data
❖ host uses IP addresses & (payload)
port numbers to direct
segment to appropriate
socket TCP/UDP segment format

Transport Layer3-7
Connectionless demultiplexing
❖ recall: created socket has
host-local port #:
clientSocket=socket(AF_INET,
SOCK_DGRAM)
❖ when host receives UDP
segment:
▪ checks destination port #
in segment
▪ directs UDP segment to
socket with that port #
❖ recall: when creating
datagram to send into
UDP socket, must specify
▪ destination IP address
▪ destination port #
IP datagrams with same
dest. port #, but different
source IP addresses
and/or source port
numbers will be directed
to same socket at dest
Transport Layer3-8
Connectionless demux: example
serverSocket=socket
clientSocket=sock mySocket1=socket(A
et(AF_INET,
(AF_INET, F_INET,
SOCK_DGRAM) SOCK_DGRAM) SOCK_DGRAM)
clientSocket.bind serverSocket.bind(( mySocket1.bind((‘’
((‘’,9157)) ‘’,6428)) ,5775))
application
application application
P1
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical

source port: 6428 source port: ?

dest port: 9157 dest port: ?

source port: 9157 source port: ?

dest port: 6428 dest port: ?
Transport Layer3-9
Connection-oriented demux
❖ TCP socket identified ❖ server host may support
by 4-tuple: many simultaneous TCP
▪ source IP address sockets:
▪ source port number ▪ each socket identified by
▪ dest IP address its own 4-tuple
▪ dest port number ❖ web servers have
❖ demux: receiver uses different sockets for
all four values to direct each connecting client
segment to appropriate ▪ non-persistent HTTP will
socket have different socket for
each request

Transport Layer3-10
 Connection-oriented demux: example

application
application P4 P5 P6 application
P3 P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets Transport Layer3-11
 Connection-oriented demux: example
threaded server
application
application application
P4
P3 P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80

Transport Layer3-12
UDP: User Datagram Protocol [RFC 768]
❖ “no frills,” “bare bones” ❖ UDP use:
Internet transport ▪ streaming multimedia
protocol apps (loss tolerant, rate
❖ “best effort” service, sensitive)
UDP segments may be: ▪ DNS
▪ lost ▪ SNMP
▪ delivered out-of-order ❖ reliable transfer over
to app
UDP:
❖ connectionless:
▪ add reliability at
▪ no handshaking application layer
between UDP sender,
receiver ▪ application-specific error
recovery!
▪ each UDP segment
handled independently
of others
Transport Layer3-13
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

Transport Layer3-14
UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted
segment
sender: receiver:
❖ treat segment contents, ❖ compute checksum of
including header fields, received segment
as sequence of 16-bit ❖ check if computed
integers
checksum equals checksum
❖ checksum: addition field value:
(one’s complement
sum) of segment ▪ NO - error detected
contents ▪ YES - no error detected.
❖ sender puts checksum But maybe errors
value into UDP nonetheless? More later
checksum field ….
Transport Layer3-15
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

Transport Layer3-16
TCP: Overview RFCs: 793,1122,1323, 2018, 2581
❖ point-to-point:
▪ one sender, one receiver
❖ reliable, in-order byte
stream delivery:
▪ Deliver message in the
same order they are
sent
❖ pipelined:
▪ TCP congestion and
flow control set window
size
❖ full duplex data:
▪ bi-directional data flow
in same connection
▪ MSS: maximum segment
size
❖ connection-oriented:
▪ handshaking (exchange
of control msgs) inits
sender, receiver state
before data exchange
❖ flow controlled:
▪ sender will not
overwhelm receiver
Transport Layer3-17
 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)

Transport Layer3-18
TCP seq. numbers, ACKs
outgoing segment from sender
sequence numbers: source port # dest port #
sequence number
▪byte stream “number” of acknowledgement number

first byte in segment’s rwnd

data
checksum urg pointer

window size
acknowledgements: N

▪seq # of next byte

expected from other side sender sequence number space
▪cumulative ACK
sent sent, not- usable not
Q: how receiver handles ACKed yet ACKed but not usable
out-of-order segments (“in-
flight”)
yet sent

▪A: TCP spec doesn’t say, incoming segment to sender

- up to implementor source port # dest port #
sequence number
acknowledgement number
A rwnd
checksum urg pointer

Transport Layer3-19
TCP seq. numbers, ACKs
Host A Host B

User
types
‘C’ Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
‘C’, echoes
Seq=79, ACK=43, data = ‘C’ back ‘C’
host ACKs
receipt
of echoed
‘C’ Seq=43, ACK=80

simple telnet scenario

Transport Layer3-20
Review
❖ What is ▪ Connection Oriented
▪ TCP ▪ Connectionless
▪ UDP ▪ Three-way Handshake
▪ TCP Window ▪ TCP Sequence Number
▪ Congestion Control ▪ TCP Acknowledgement Number
▪ Flow Control ▪ Maximum Segment Size
▪ Multiplexing ▪ TCP Socket
▪ Demultiplexing ▪ UDP Socket
▪ TCP Timeout Interval ▪ Checksum

Transport Layer3-21
Exercises 01
Consider a TCP connection between host A and host B.
Suppose that the TCP segments traveling from host A to
host B have source port number x and destination port
number y. What are the source and destination port
numbers for the segments traveling from host B to host A?

Transport Layer3-22
Exercises 02
Suppose that a Web server runs in host C on port 80.
Suppose this Web server uses persistent connections, and is
currently receiving requests from two different hosts: A and
B. Are all of the requests being sent through the same socket
at host C? If they are being passed through different sockets,
do both of the sockets have port 80? Discuss and explain.

Transport Layer3-23
Exercise 03
Suppose you have the following two bytes: 00110101 and
01101001. What is the 1s complement of these two bytes?

Transport Layer3-24
Exercise 04
Suppose a process in host C has a UDP socket with port
number 787. Suppose host A and host B, each send a UDP
segment to host C with destination port number 787. Will
both of these segments be directed to the same socket at
host C? If so, how will the process at host C know that these
segments originated from two different hosts?

Transport Layer3-25
 Lecture 07

Transport Layer

Penjelasan
TCP ACK generation [RFC 1122, RFC 2581]

CSI3601504 - Jaringan Komunikasi Data

Semester Gasal 2015-2016
Fakultas Ilmu Komputer UI

1
 TCP ACK generation [RFC 1122, RFC 2581]

event at receiver TCP receiver action

arrival of in-order segment with delayed ACK. Wait up to 500ms
RULE 1 expected seq #. All data up to for next segment. If no next segment,
expected seq # already ACKed send ACK

arrival of in-order segment with immediately send single cumulative

RULE 2 expected seq #. One other ACK, ACKing both in-order segments
segment has ACK pending

arrival of out-of-order segment immediately send duplicate ACK,

RULE 3 higher-than-expect seq. # . indicating seq. # of next expected byte
Gap detected

arrival of segment that immediate send ACK, provided that

RULE 4 partially or completely fills gap segment starts at lower end of gap

Transport Layer 3-2

 TCP ACK generation [RFC 1122, RFC 2581]
event at receiver TCP receiver action
arrival of in-order segment with delayed ACK. Wait up to 500ms
expected seq #. All data up to for next segment. If no next segment,
expected seq # already ACKed send ACK

RULE 1

Transport Layer 3-3

 TCP ACK generation [RFC 1122, RFC 2581]
event at receiver TCP receiver action
arrival of in-order segment with immediately send single cumulative
expected seq #. One other ACK, ACKing both in-order segments
segment has ACK pending

RULE 2

Transport Layer 3-4

 TCP ACK generation [RFC 1122, RFC 2581]
event at receiver
arrival of out-of-order segment
higher-than-expect seq. # .
Gap detected

TCP receiver action

immediately send duplicate ACK,
indicating seq. # of next expected byte

RULE 3
Transport Layer 3-5
 TCP ACK generation [RFC 1122, RFC 2581]
event at receiver
arrival of segment that
partially or completely fills gap

TCP receiver action

immediate send ACK, provided that
segment starts at lower end of gap

RULE 4
Transport Layer 3-6
 Lecture 08

Transport Layer (2/2)

Connection-oriented transport: TCP &
TCP Congestion Control

CSC3601503 - Jaringan Komputer

Fakultas Ilmu Komputer UI

1
Lecture 08: Roadmap
❖ 3.4 Connection-oriented transport: TCP
▪ segment structure
▪ reliable data transfer
▪ flow control
▪ connection management
❖ 3.5 TCP congestion control

2
TCP reliable data transfer
❖ TCP creates rdt service
on top of IP’s unreliable
service
▪ pipelined segments
▪ cumulative acks let’s initially consider
▪ single retransmission simplified TCP sender:
timer ▪ ignore duplicate acks
❖ retransmissions ▪ ignore flow control,
triggered by: congestion control
▪ timeout events
▪ duplicate acks

Transport Layer3-3
TCP sender events:
data rcvd from app: timeout:
❖ create segment with ❖ retransmit segment
seq # that caused timeout
❖ seq # is byte-stream ❖ restart timer
number of first data ack rcvd:
byte in segment ❖ if ack acknowledges
❖ start timer if not previously unacked
already running segments
▪ think of timer as for ▪ update what is known
oldest unacked to be ACKed
segment
▪ start timer if there are
▪ expiration interval: still unacked segments
TimeOutInterval

Transport Layer3-4
TCP: retransmission scenarios
Host A Host B Host A Host B

SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

timeout

timeout
ACK=100
X
ACK=100
ACK=120

Seq=92, 8 bytes of data Seq=92, 8

SendBase=100 bytes of data
SendBase=120
ACK=100
ACK=120

SendBase=120

lost ACK scenario premature timeout

Transport Layer3-5
TCP: retransmission scenarios
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

timeout

ACK=100
X
ACK=120

Seq=120, 15 bytes of data

cumulative ACK
Transport Layer3-6
TCP ACK generation [RFC 1122, RFC 2581]

event at receiver TCP receiver action

arrival of in-order segment with delayed ACK. Wait up to 500ms
expected seq #. All data up to for next segment. If no next segment,
expected seq # already ACKed send ACK

arrival of in-order segment with immediately send single cumulative

expected seq #. One other ACK, ACKing both in-order segments
segment has ACK pending

arrival of out-of-order segment immediately send duplicate ACK,

higher-than-expect seq. # . indicating seq. # of next expected byte
Gap detected

arrival of segment that immediate send ACK, provided that

partially or completely fills gap segment starts at lower end of gap

Transport Layer3-7
TCP fast retransmit
❖ time-out period often
relatively long:
▪ long delay before
resending lost packet
❖ detect lost segments
via duplicate ACKs.
▪ sender often sends
many segments back-
to-back
▪ if segment is lost, there
will likely be many
duplicate ACKs.
TCP fast retransmit
if sender receives 3
ACKs for same data
(“triple duplicate ACKs”),
resend unacked
segment with smallest
seq #
▪ likely that unacked
segment lost, so don’t
wait for timeout
Transport Layer3-8
TCP fast retransmit
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data
X

ACK=100

timeout
ACK=100
ACK=100
ACK=100
Seq=100, 20 bytes of data

fast retransmit after sender

receipt of triple duplicate ACK
Transport Layer3-9
TCP flow control
application
application may process
remove data from application
TCP socket buffers ….
TCP socket OS
receiver buffers
… slower than TCP
receiver is delivering
(sender is sending) TCP
code

IP
flow control code
receiver controls sender, so
sender won’t overflow
receiver’s buffer by transmitting from sender
too much, too fast
receiver protocol stack

Transport Layer3-10
TCP flow control
❖ receiver “advertises” free
buffer space by including to application process
rwnd value in TCP header
of receiver-to-sender
segments RcvBuffer buffered data
▪ RcvBuffer size set via
socket options (typical default rwnd free buffer space
is 4096 bytes)
▪ many operating systems
autoadjust RcvBuffer TCP segment payloads
❖ sender limits amount of
unacked (“in-flight”) data to receiver-side buffering
receiver’s rwnd value
❖ guarantees receive buffer
will not overflow
Transport Layer3-11
Connection Management
before exchanging data, sender/receiver “handshake”:
❖ agree to establish connection (each knowing the other willing
to establish connection)
❖ agree on connection parameters

application application

connection state: ESTAB connection state: ESTAB

connection variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client
connection Variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client

network network

Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port welcomeSocket.accept();
number");

Transport Layer3-12
 TCP 3-way handshake

client state server state

LISTEN
choose init seq num, x
send TCP SYN msg
SYNSENT
received SYNACK(x)
ESTAB indicates server is live;
send ACK for SYNACK;
this segment may contain
client-to-server data
LISTEN
SYNbit=1, Seq=x
choose init seq num, y
send TCP SYNACK
msg, acking SYN SYN RCVD
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
ACKbit=1, ACKnum=y+1
received ACK(y)
indicates client is live
ESTAB

Transport Layer3-13
TCP: closing a connection
❖ client, server each close their side of connection
▪ send TCP segment with FIN bit = 1
❖ respond to received FIN with ACK
▪ on receiving FIN, ACK can be combined with own FIN
❖ simultaneous FIN exchanges can be handled

Transport Layer3-14
TCP: closing a connection
client state server state
ESTAB ESTAB
clientSocket.close()
FIN_WAIT_1 can no longer FINbit=1, seq=x
send but can
receive data CLOSE_WAIT
ACKbit=1; ACKnum=x+1
can still
FIN_WAIT_2 wait for server send data
close

LAST_ACK
FINbit=1, seq=y
TIMED_WAIT can no longer
send data
ACKbit=1; ACKnum=y+1
timed wait
for 2*max CLOSED
segment lifetime

CLOSED

Transport Layer3-15
 TCP congestion control: additive increase
multiplicative decrease
❖ approach: sender increases transmission rate (window
size), probing for usable bandwidth, until loss occurs
▪ additive increase: increase cwnd by 1 MSS every
RTT until loss detected
▪ multiplicative decrease: cut cwnd in half after loss
additively increase window size …
…. until loss occurs (then cut window in half)

congestion window size

cwnd: TCP sender
AIMD saw tooth
behavior: probing
for bandwidth

time
Transport Layer3-16
Chapter 3: summary
❖ principles behind
transport layer services:
▪ multiplexing,
demultiplexing next:
❖ leaving the
▪ reliable data transfer
network “edge”
▪ flow control (application,
▪ congestion control transport layers)
❖ instantiation, ❖ into the network
implementation in the “core”
Internet
▪ UDP
▪ TCP
Transport Layer3-17
Review
❖ What is TCP ▪ Fast Retransmit
▪ Pipeline ▪ Congestion Window
▪ Cumulative Ack
▪ Single Retransmission Timer
▪ Timeout Interval
▪ Duplicate ACK
▪ Flow Control
▪ Premature timeout

Transport Layer3-18
Exercise 01
Consider sending a large file from one host to another over a TCP
connection that has no loss.
❖ Suppose TCP uses AIMD (Additive Increase multiple decrease) for its
congestion control without slow start. Assuming CWND (Congestion
Window) increases by 1 MSS every time an ACK is received and assuming
approximately constant round-trip times, how long does it take for CWND to
increase from 1 MSS to 5 MSS (assuming no loss events and constant RTT)?
❖ What is the average throughput (in terms of MSS and RTT) for this connection
up through time = 4 RTT?

Transport Layer3-19
Exercise 02 (1/2)
Host A and B are communicating over a
TCP connection, and Host B has already
received from A all bytes up through byte
144. Suppose that Host A then sends two
segments to Host B back-to-back. The first
and second segments contain 20 and 40
bytes of data, respectively. In the first
segment, the sequence number is 145,
source port number is 303, and the
destination port number is 80. Host B
sends an acknowledgement whenever it
receives a segment from Host A.

Transport Layer3-20
Exercise 02 (2/2)
a) In the second segment sent from Host A to B, what are the
sequence number, source port number, and destination port
number?
b) If the first segment arrives before the second segment, in the
acknowledgement of the first arriving segment, what is the
acknowledgment number, the source port number, and the
destination port number?
c) If the second segment arrives before the first segment, in the
acknowledgement of the first arriving segment, what is the
acknowledgment number?
d) Suppose the two segments sent by A arrive in order at B. The first
acknowledgement is lost and the second segment arrives after the
first timeout interval, as shown in the figure below. Complete the
diagram, showing all other segments and acknowledgements sent.
(Assume there is no additional packet loss.) For each segment you
add to the diagram, provide the sequence number and number of
bytes of data; for each acknowledgement that you add, provide the
acknowledgement number. Transport Layer3-21
Exercise 3
❖ UDP and TCP use 1s complement for their checksums.
Suppose you have the following three 8-bit bytes:
▪ 01010011
▪ 01100110
▪ 01110100
❖ Q1. What is the 1s complement of the sum of these 8-bit
bytes?

Transport Layer3-22
Exercise 3
❖ Q2. Why is it that UDP takes the 1s complement of the
sum; that is, why not just use the sum?
▪ With the 1s complement scheme, how does the receiver detect
errors?
❖ Q3. Is it possible that a 1-bit error will go undetected?
❖ Q4. How about a 2-bit error?

Transport Layer3-23