Coen366 Module2

Chapter 2
Application Layer
A note on the use of these Powerpoint slides:

We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you see the animations; and can add, modify,
and delete slides (including this one) and slide content to suit your needs.
They obviously represent a lot of work on our part. In return for use, we only
ask the following: Computer
§ If you use these slides (e.g., in a class) that you mention their source
(after all, we’d like people to use our book!) Networking: A Top
§ If you post any slides on a www site, that you note that they are adapted
from (or perhaps identical to) our slides, and note our copyright of this Down Approach
material.
7th edition
Thanks and enjoy! JFK/KWR Jim Kurose, Keith Ross
Pearson/Addison Wesley
All material copyright 1996-2016
April 2016
J.F Kurose and K.W. Ross, All Rights Reserved
Application Layer 2-1
Chapter 2: outline
2.1 principles of network 2.5 P2P applications
applications 2.6 video streaming and
2.2 Web and HTTP content distribution
2.3 electronic mail networks
• SMTP, POP3, IMAP 2.7 socket programming
2.4 DNS with UDP and TCP

Chapter 2: application layer
our goals: § learn about protocols by
§ conceptual, examining popular
implementation aspects application-level
of network application protocols
protocols • HTTP
• transport-layer • FTP
service models • SMTP / POP3 / IMAP
• DNS
• client-server
paradigm § creating network
applications
• peer-to-peer
paradigm • socket API
• content distribution
networks

Some network apps
§ e-mail § voice over IP (e.g., Skype,
§ web Facetime, …)
§ text messaging § real-time video
§ remote login (Telnet) conferencing (zoom,
meetings….)
§ P2P file sharing
§ social networking (FB,
(BitTorrent)
Twitter, …)
§ multi-user network
games (Roblox, …) § Many many mobile apps
(Yelp, Tinder, etc.), e-
§ streaming stored payment (Apple pay, ..),
video (YouTube, Hulu, messaging (WhatsApp,
Netflix) WeChat…)
§ … Application Layer 2-4
Creating a network app application
transport
network
data link
physical
write programs that:
§ run on (different) end systems
§ communicate over network
§ e.g., web server software
communicates with browser
software
no need to write software

application
transport
network
for network-core devices data link
physical
application
transport
network
§ network-core devices do not data link
physical
run user applications
§ applications on end systems
allows for rapid app
development, propagation
Application architectures
possible structure of applications:
§ client-server
§ peer-to-peer (P2P)
Not a network architecture!

which provides services to applications

Client-server architecture
server:
§ always-on host
§ permanent IP address
§ data centers for scaling
clients:
§ communicate with server
client/server § may be intermittently
connected
§ may have dynamic IP
addresses
§ do not communicate directly
Telnet, Web, email, ….
with each other
Often (many) servers (rather than one) needed Application Layer 2-7
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
Example: Torrent Application Layer 2-8
Processes communicating
process: program running clients, servers
within a host client process: process that
§ within same host, two initiates communication
processes communicate server process: process that
using inter-process waits to be contacted
communication (defined by
OS)
§ processes in different hosts
communicate by exchanging § aside: applications with P2P
messages architectures have client
processes & server
processes

and sockets. A process is analogous to a house and its socket is analogous to its door.
When a process wants to send a message to another process on another host, it shoves
the message out its door (socket). This sending process assumes that there is a trans-
Sockets
portation infrastructure on the other side of its door that will transport the message to
the door of the destination process. Once the message arrives at the destination host,
the message passes through the receiving process’s door (socket), and the receiving
process then acts on the message.
Figure 2.3 illustrates socket communication between two processes that com-
§ process sends/receives messages to/from its socket
municate over the Internet. (Figure 2.3 assumes that the underlying transport protocol
used by the processes is the Internet’s TCP protocol.) As shown in this figure, a socket
§ socket analogous to door
is the interface between the application layer and the transport layer within a host. It
is also referred to as the Application Programming Interface (API) between the
• sending process shoves message out door
application and the network, since the socket is the programming interface with which
network applications are built. The application developer has control of everything on
• sending process relies on transport infrastructure on
the application-layer side of the socket but has little control of the transport-layer side
of the socket. The only control that the application developer has on the transport-
other side of door to deliver message to socket at
layer side is (1) the choice of transport protocol and (2) perhaps the ability to fix a few
receiving process
Host or Host or
server server
Controlled Controlled
by application Process Process by application
developer developer
Socket Socket
Controlled TCP with TCP with Controlled

by operating buffers, buffers, by operating
system variables variables system
Internet
Figure 2.3 ♦ Application processes, sockets, and underlying transport protocol

Addressing processes
§ to receive messages, § identifier includes both IP
process must have identifier address and port numbers
§ host device has unique 32- associated with process on
bit IP address host.
§ Q: does IP address of host § example port numbers:
on which process runs • HTTP server: 80
suffice for identifying the • mail server: 25
process? § to send HTTP message to
§ A: no, many processes gaia.cs.umass.edu web
can be running on same server:
host • IP address: 128.119.245.12
• port number: 80
§ more shortly…

App-layer protocol defines
§ types of messages open protocols:
exchanged, § defined in RFCs
• e.g., request, response § allows for interoperability
§ message syntax: § e.g., HTTP, SMTP
• what fields in messages proprietary protocols:
& how fields are
delineated § e.g., Skype
§ message semantics
• meaning of information
in fields
§ rules for when and how
processes send & respond
to messages

What transport service does an app need?
data integrity throughput
§ some apps (e.g., file transfer, § some apps (e.g.,
web transactions) require multimedia) require
100% reliable data transfer minimum amount of
§ other apps (e.g., audio) can throughput to be
tolerate some loss “effective”
§ other apps (“elastic apps”)
timing make use of whatever
§ some apps (e.g., Internet throughput they get
telephony, interactive security
games) require low delay § encryption, data integrity,
to be “effective” …

Transport service requirements: common apps
2.1 • PRINCIPLES OF NETWORK APPLICATIONS 91
Application Data Loss Throughput Time-Sensitive
File transfer/download No loss Elastic No

E-mail No loss Elastic No
Web documents No loss Elastic (few kbps) No
Internet telephony/ Loss-tolerant Audio: few kbps–1 Mbps Yes: 100s of msec
Video conferencing Video: 10 kbps–5 Mbps
Streaming stored Loss-tolerant Same as above Yes: few seconds
audio/video
Interactive games Loss-tolerant Few kbps–10 kbps Yes: 100s of msec
Smartphone messaging No loss Elastic Yes and no
Figure 2.4 ♦ Requirements of selected network applications
Internet, one of the first decisions you have to make is whether to use UDP or TCP.
Each of these protocols offers a different set of services to the invoking applications.
Figure 2.4 shows the service requirements for some selected applications.
Internet transport protocols services
TCP service: UDP service:
§ reliable transport between § unreliable data transfer
sending and receiving between sending and
process receiving process
§ flow control: sender won’t § does not provide: reliability,
overwhelm receiver flow control, congestion
§ congestion control: throttle control, timing,
sender when network throughput guarantee,
overloaded security, or connection
§ does not provide: timing, setup,
minimum throughput
guarantee, security
§ connection-oriented: setup
required between client and
server processes
cations. We see that e-mail, remote terminal access, the Web, and file transfer all use
TCP. These applications have chosen TCP primarily because TCP provides reliable
data transfer, guaranteeing that all data will eventually get to its destination. Because
Internet apps: application, transport protocols
Internet telephony applications (such as Skype) can often tolerate some loss but
require a minimal rate to be effective, developers of Internet telephony applications
Application Application-Layer Protocol Underlying Transport Protocol
Electronic mail SMTP [RFC 5321] TCP

Remote terminal access Telnet [RFC 854] TCP
Web HTTP 1.1 [RFC 7230] TCP
File transfer FTP [RFC 959] TCP
Streaming multimedia HTTP (e.g., YouTube), DASH TCP
Internet telephony SIP [RFC 3261], RTP [RFC 3550], or proprietary UDP or TCP
(e.g., Skype)
Figure 2.5 ♦ Popular Internet applications, their application-layer

protocols, and their underlying transport protocols

Securing TCP
TCP & UDP SSL is at app layer

§ no encryption § apps use SSL libraries, that
§ cleartext passwds sent into “talk” to TCP
socket traverse Internet in SSL socket API
cleartext § cleartext passwords sent
SSL into socket traverse
§ Secure Socket Layer Internet encrypted
§ provides encrypted TCP § see Chapter 8
connection
§ data integrity
§ end-point authentication
Chapter 2: outline

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

HTTP overview
HTTP: hypertext
transfer protocol
HT
§ Web’s application layer TP
r eq
protocol PC running HT
ues
t
Firefox browser TP
§ client/server model r es
pon
se
• client: browser that
requests, receives, s t
(using HTTP protocol) r eq
ue
server
and “displays” Web HT
T P
p on
s e
running
objects T P r es Apache Web
• server: Web server HT server
sends (using HTTP
protocol) objects in iPhone running
response to requests Safari browser

HTTP overview (continued)
uses TCP: HTTP is “stateless”
§ client initiates TCP § server maintains no
connection (creates socket) information about
to server, port 80 past client requests
§ server accepts TCP
connection from client aside
§ HTTP messages protocols that maintain
(application-layer protocol “state” are complex!
messages) exchanged § past history (state) must be
between browser (HTTP maintained
client) and Web server § if server/client crashes, their
(HTTP server) views of “state” may be
inconsistent, must be
§ TCP connection closed reconciled

HTTP connections
non-persistent HTTP persistent HTTP
§ at most one object § multiple objects can
sent over TCP be sent over single
connection TCP connection
• connection then between client, server
closed
§ downloading multiple
objects required
multiple connections

Non-persistent HTTP
suppose user enters URL: (contains text,
www.someSchool.edu/someDepartment/home.index references to 10
jpeg images)
1a. HTTP client initiates TCP
connection to HTTP server
(process) at 1b. HTTP server at host
www.someSchool.edu on port www.someSchool.edu waiting
80 for TCP connection at port 80.
“accepts” connection, notifying
2. HTTP client sends HTTP request client
message (containing URL) into
TCP connection socket. 3. HTTP server receives request
Message indicates that client message, forms response
wants object message containing requested
someDepartment/home.index object, and sends message into
its socket
time
Non-persistent 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

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
connection
§ one RTT to initiate TCP
connection RTT
request
§ one RTT for HTTP request file
and first few bytes of HTTP RTT
time to
response to return transmit
file
§ file transmission time file
received
§ non-persistent HTTP
response time =
time time
2RTT+ file transmission
time

Persistent HTTP
non-persistent HTTP issues: persistent HTTP:

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

in the homework problems of Chapters 2 and 3. You are a
[Heidemann 1997; Nielsen 1997; RFC 7540].
HTTP request
2.2.3message
HTTP Message Format
The HTTP specifications [RFC 1945; RFC 7230; RFC 7540]
§ two types of HTTP messages:
of the request,
HTTP message response
formats. There are two types of HTTP m
§ HTTP request message:
sages and response messages, both of which are discussed bel
• ASCII (human-readable format)
HTTP Request Message
request line
Below we provide a typical HTTP request message:
(GET, POST,
HEAD commands)
GET /somedir/page.html HTTP/1.1
header Host: www.someschool.edu
Connection: close Non-persistent
lines
User-agent: Mozilla/5.0
Accept-language: fr
We can learn a lot by taking a close look at this simple req

all, we see that the message is written in ordinary ASCII text
* Check out the online interactivecomputer-literate
exercises for more human being can read it. Second, we see tha
of five lines, each followed by a carriage Application
examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ return andLayer a line fee
2-27
lowed by an additional carriage return and line feed. Although

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

Uploading form input
POST method:
§ web page often includes form input (e.g. a user
provides search words to google search
engine)
§ 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

Method types
HTTP/1.0: HTTP/1.1:
§ GET § GET, POST, HEAD
§ POST § PUT
§ HEAD • uploads file in entity
• Similar to GET; asks body to path specified
server to leave in URL field
requested object out § DELETE
of response (often • deletes file specified in
used for debugging) the URL field

allows a user to upload an object to a specific path (directory) on a specific
server. The PUT method is also used by applications that need to upload o
HTTP response message

to Web servers. The DELETE method allows a user, or an application, to del
object on a Web server.
HTTP Response Message

status line
Below we provide a typical HTTP response message. This response message
(protocol
be the response to the example request message just discussed.
status code
status phrase) HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
header Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
lines Content-Length: 6821
Content-Type: text/html
(data data data data data ...)
data, e.g., Let’s take a careful look at this response message. It has three sections: an
requested status line, six header lines, and then the entity body. The entity body is the
HTML file of the message—it contains the requested object itself (represented by data
data data data ...). The status line has three fields: the protocol v
field, a status code, and a corresponding status message. In this example, the
line indicates
* Check out the online interactive thatfor
exercises themore
server is using HTTP/1.1 and that everything is OK (that
examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
server has found, and is sending, the requested object).Application Layer 2-32
matches the previous example of a response message. Let’s say a few additional words
about status codes and their phrases. The status code and associated phrase indicate
the result of the request. Some common status codes and associated phrases include:
HTTP response message

• 200 OK: Request succeeded and the information is returned in the response.
• 301 Moved Permanently: Requested object has been permanently moved;
the new URL is specified in Location: header of the response message. The
client software will automatically retrieve the new URL.
Status line version sp status code sp phrase cr lf
header field name: sp value cr lf
Header lines
header field name: sp value cr lf
Blank line cr lf
Entity body
Figure 2.9 ♦ General format of an HTTP response message

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
User-server state: cookies
- HTTP is stateless à no state is
maintained by server à simplifies
design, and make it very efficient
and scalable
- Web servers however can
maintain information that identifies
users (e.g., ebay, google, facebook,
etc. they all track your activities
and tailor commercial based on
your identity!)
- Cookie technology

User-server state: cookies
example:
many Web sites use cookies § 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 • unique ID
message • 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
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
Cookies (continued)
what cookies can be used aside
cookies and privacy:
for:
§ authorization § cookies permit sites to
learn a lot about you
§ shopping carts
§ recommendations § you may supply name and
§ user session state (Web e-mail to sites
e-mail)
how to keep “state”:

§ protocol endpoints: maintain state at
sender/receiver over multiple
transactions
§ cookies: http messages carry state
Cookies create a user session layer on top of stateless HTTP.

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 HT
TP
req server u e st
H ues P r eq
• object in cache: cache client TTP
r es
t HT
T ons
e
p origin
es
returns object pon
se T Pr server
HT
t
• else cache requests u es
r eq s e
object from origin HT T P
es
p on
r
server, then returns H T TP
object to client
client origin
server

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 à no need to upgrade
(university, company, (cost efficient)
residential ISP) § Internet dense with
caches: enables “poor”
content providers to
effectively deliver
content (so too does
P2P file sharing) Application Layer 2-41
located all over the globe. Suppose that the average object size is 1 Mbits and that th
rate from the institution’s browsers to the origin servers is 15 requests per second. S
HTTP request messages are negligibly small and thus create no traffic in the networ
Caching example:
link (from institutional router to Internet router). Also suppose that the amount of time
the router on the Internet side of the access link in Figure 2.12 forwards an HTTP re
datagram) until it receives the response (typically within many IP datagrams) is two s
average. Informally, we refer to this last delay as the “Internet delay.”
assumptions:
§ avg object size: 1Mbits
§ avg request rate from browsers to
origin servers:15/sec
§ RTT from institutional router to any
origin server: 2 sec
theaccess
§the link Let’s
Internet delay. rate:now15Mbps
do a very crude calculation to estimate this delay. The traffic intensity on
Internet delay. Let’s now do a very crude calculation to estimate this delay. The traffic intensity on
the LAN (see Section 1.4.2) is
consequences:
the LAN (see Section 1.4.2) is
(15requests/sec)
(15 requests/sec)(1 (1 Mbits/request)/(100
Mbits/request)/(100 Mbps)=0.15
Mbps)=0.15
whereasthe
the traffic intensity on the access link (from the Internet router to institution
router) isrouter) is
à LAN utilization:
whereas traffic 15%on the
intensity access link (from the Internet router to institution
Figure 2.12 Bottleneck between an institutional network and the Internet

(15requests/sec)
(15 requests/sec)(1 (1 Mbits/request)/(15
Mbits/request)/(15 Mbps)=1
Mbps)=1
ThePossible
à access link utilization =typically
100% ofsolution:
total response time—that is, the time from the browser’s request of an object un
AAtraffic
traffic intensity
intensityof of
0.15 on on
0.15 a LAN
a LANtypically results in, at in,
results most, tens oftens
at most, milliseconds
of delay;of
milliseconds hence,
delay; wehence, we
object—is the sum of the LAN delay, the access delay (that is, the delay between the
cantotal
increased access link speed (not cheap!)
§can neglect
neglect delay
the
theLAN
LAN =delay.
Internet
delay. However,
However, as delay
discussed+inaccess
as discussed Section 1.4.2, as
in Section the traffic
1.4.2, as theintensity approaches
traffic intensity approaches
delay
11(as
(asisisthe
+case
thecase LAN
of of
thethe
delay
access link link
access in Figure 2.12),2.12),
in Figure the delay on a link
the delay a(try
link 100Mbps)
onbecomes very large
becomes andlarge
very grows and grows
without bound. Thus, the average response time to satisfy requests is going to be on the order of
without bound. Thus, the average response time to satisfy requests is going to be on the order of
= 2 sec + minutes + usecs
minutes, if not more, which is unacceptable for the institution’s users. Clearly something must be done.
minutes, if not more, which is unacceptable for the institution’s users. Clearly something must be done.
One possible solution is to increase the access rate from 15 Mbps to, say, 100 Mbps. This
traffic intensity on the access link to 0.15, which translates to negligible delays between th
Caching example:
In this case, the total response time will roughly be two seconds, that is, the Internet delay
solution also means that the institution must upgrade its access link from 15 Mbps to 100 M
proposition.
Same assumptions as before
§ avg object size: 1Mbits
§ avg requestNow consider
rate from browsersthe alternative
to origin solution of not upgrading the access link but instead installing
servers:15/sec
§ RTT from institutional router to any origin server: 2 sec
§ access linkin the
rate: institutional network. This solution is illustrated in Figure 2.13. Hit rates—the fraction
15Mbps
that are satisfied by a cache— typically range from 0.2 to 0.7 in practice. For illustrative pu
consequences:
suppose that the cache provides a hit rate of 0.4 for this institution. Because the clients an
§ Hit rate: fraction of requests satisfied
are connected to the same high-speed LAN, 40 percent of the requests will be satisfied alm
by cache (typically between 0.2 and
0.7) àimmediately,
assume 0.4say, HRwithin 10 milliseconds, by the cache. Nevertheless, the remaining 60 pe
§ 60% ofrequests
requests stillgoes
need to thesatisfied
to be internetby the origin servers. But with only 60 percent of the requ
(originpassing
servers)through the access link, the traffic intensity on the access link is reduced from 1.0
§ Traffic Intensity
Typically, a trafficdrops from
intensity less1.0
than 0.8 corresponds to a small delay, say, tens of millisec
toMbps
0.6 link. This delay is negligible compared with the two-second Internet delay. Given the
§ Translates to access delays in
considerations, average delay therefore is
tens of ms. à average delay Figure 2.13 Adding a cache to the institutional network
becomes:
0.4 (0.01 seconds)+0.6 (2.01 seconds) to upgrade its link to the Internet. The institution does, of course, have to
cache. But this cost is low—many caches use public-domain software th
which is just slightly greater than 1.2 seconds. Thus,

Through this
the use second
of Content
Application
solution
Distribution
Layer
provides
Networks
2-43 Webeven
(CDNs),an cach
important role in the Internet. A CDN company installs many geographic
response time than the first solution, and it doesn’t require the institution
Web caching
§ Copies of objects in
cache may be stale,
and original copies
may have changed
§ HTTP has a
mechanism to deal
with this issue à
“conditional get”

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
HTTP/2
§ Standardized in 2015, many websites already support

HTTP/2 and most browsers do as well.
§ Objective: “..reduce perceived latency by enabling
request and response multiplexing over a single TCP
connection, provide request prioritization and server
push, and provide efficient compression of HTTP header
fields..”
§ HTTP persistent connection: a webpage is transported
over the same TCP connection (fewer sockets used),
but suffers from Head of Line Blocking
§ HOL: html base file, large video and many smaller
objects. à large video may take a lot of time and blocks
the small objects from being transferred

HTTP/2
§ HTTP/1: solve this by opening my TCP connections à

smaller objects will arrive earlier, and this enhances user
perceived latency à 1) more sockets at the server and this
consumes resources 2) browsers can get more BW from
the network than they should!
§ HTTP/2 solution: Framing and Frame interleaving
• Large objects are broken into smaller frames.
• A server receiving requests from a browser, will respond
by sending frames of all requested objects (rather than
keeping busy sending frames from one particular object
and blocking other frames from being transmitted)
• The ability to break down an HTTP message into independent
frames, interleave them, and then reassemble them on the
other end is the single most important enhancement of
HTTP/2.
HTTP/3

Chapter 2: outline

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”
à DNS

application-layer protocol that allows hosts to query the distributed database. The DNS servers are often
DNS: services, structure

UNIX machines running the Berkeley Internet Name Domain (BIND) software [BIND 2016]. The DNS
protocol runs over UDP and uses port 53.
DNS services
DNS is commonly employed by other application-layer protocols—including HTTP and SMTP to
translate user-supplied hostnames to IP addresses. As an example, consider what happens when a
§ hostname to IP address translation
browser (that is, an HTTP client), running on some user’s host, requests the URL
• Example: browser. In
www.someschool.edu/index.html wanting theuser’s
order for the IP address of to send an HTTP request
host to be able
message to thewww.someschool.edu
Web server www.someschool.edu , the user’s host must first obtain the IP address of
www.someschool.edu . This is done as follows.
1. The same user machine runs the client side of the DNS application.
2. The browser extracts the hostname, www.someschool.edu , from the URL and passes the
hostname to the client side of the DNS application.
3. The DNS client sends a query containing the hostname to a DNS server.
4. The DNS client eventually receives a reply, which includes the IP address for the hostname.
5. Once the browser receives the IP address from DNS, it can initiate a TCP connection to the
HTTP server process located at port 80 at that IP address.
We see from this example that DNS adds an additional delay—sometimes substantial—to the Internet
applications that use it. Fortunately, as we discuss below, the desired IP address is often cached in a
“nearby” DNS server, which helps to reduce DNS network traffic as well as the average DNS delay.

DNS provides a few other important services in addition to translating hostnames to IP addresses:
2. The browser extracts the hostname, www.someschool.edu , from the URL and passes the
hostname to the client side of the DNS application.
3. The DNS client sends a query containing the hostname to a DNS server.

4. The DNS client eventually receives a reply, which includes the IP address for the hostname.
5. Once the browser receives the IP address from DNS, it can initiate a TCP connection to the
HTTP server process located at port 80 at that IP address.
DNS services
We see from this example that DNS adds an additional delay—sometimes substantial—to the Internet
hostname
§ applications that useto IP address
it. Fortunately, as we discuss below, the desired IP address is often cached in a
translation
“nearby” DNS server, which helps to reduce DNS network traffic as well as the average DNS delay.
host
§ DNS aliasing
provides a few other important services in addition to translating hostnames to IP addresses:
Host aliasing. A host with a complicated hostname can have one or more alias names. For
example, a hostname such as relay1.west-coast.enterprise.com could have, say, two
aliases such as enterprise.com and www.enterprise.com . In this case, the hostname
relay1.west-coast.enterprise.com is said to be a canonical hostname. Alias hostnames,
when present, are typically more mnemonic than canonical hostnames. DNS can be invoked by an
application to obtain the canonical hostname for a supplied alias hostname as well as the IP address
of the host.
Mail server aliasing. For obvious reasons, it is highly desirable that e-mail addresses be mnemonic.
For example, if Bob has an account with Yahoo Mail, Bob’s e-mail address might be as simple as
bob@yahoo.mail . However, the hostname of the Yahoo mail server is more complicated and
much less mnemonic than simply yahoo.com (for example, the canonical hostname might be
something like relay1.west-coast.yahoo.com ). DNS can be invoked by a mail application to
obtain the canonical hostname for a supplied alias hostname as well as the IP address of the host.
In fact, the MX record (see below) permits a company’s mail server and Web server to have identical
the desired IP address is often cached in a “nearby” DNS server, which helps to
reduce DNS network traffic as well as the average DNS delay.
DNS provides a few other important services in addition to translating host-
names to IP addresses:
• Host aliasing. A host with a complicated hostname can have one or more
DNS
alias services
names. For example, a hostname such as relay1.west-coast
.enterprise.com could have, say, two aliases such as enterprise.com
§ hostname to IP address
and www.enterprise.com. In this case, the hostname relay1
translation
.west-coast.enterprise.com is said to be a canonical hostname. Alias
§ host aliasing
hostnames, when present, are typically more mnemonic than canonical host-
names.
§ mailDNSserver
can be invoked
aliasingby an application to obtain the canonical hostname
for a supplied alias hostname as well as the IP address of the host.
• Mail server aliasing. For obvious reasons, it is highly desirable that e-mail
addresses be mnemonic. For example, if Bob has an account with Yahoo Mail,
Bob’s e-mail address might be as simple as bob@yahoo.com. However, the
hostname of the Yahoo mail server is more complicated and much less mnemonic
than simply yahoo.com (for example, the canonical hostname might be some-
thing like relay1.west-coast.yahoo.com). DNS can be invoked by a
mail application to obtain the canonical hostname for a supplied alias hostname
as well as the IP address of the host. In fact, the MX record (see below) permits a
company’s mail server and Web server to have identical (aliased) hostnames; for
example, a company’s Web server and mail server can both be called enter-
prise.com.
• Load distribution. DNS is also used to perform load distribution among repli-
names. DNS can be invoked by an application to obtain
PRINCIPLES INthePRACTICE
canonical hostname
for a supplied alias hostname as well as the IP address of the host.
DNS:
• Mail CRITICAL
server NETWORK
aliasing. For FUNCTIONS
obvious reasons, VIA THE it isCLIENT-SERVER
highly desirablePARADIGMthat e-mail

Likeaddresses
HTTP, FTP, be andmnemonic. For example,
SMTP, the DNS protocol is ifanBob has an account
application-layer with since
protocol Yahoo it Mail,
Bob’s
(1) runs e-mailcommunicating
between address mightend besystems
as simple
using asthe
bob@yahoo.com.
client-server paradigm However,
and the
hostname
(2) relies on anofunderlying
the Yahoo mail server
end-to-end is more
transport complicated
protocol andDNS
to transfer much less mnemonic
messages between
than simplyend
communicating yahoo.com (for example,
systems. In another the canonical
sense, however, the rolehostname
of the DNS might be differ-
is quite some-
ent from DNS services
thingWeb,like file
relay1.west-coast.yahoo.com).
transfer, and e-mail applications. Unlike these DNS can be invoked
applications, the DNSby is a
not mail application withtowhich
obtain the canonical hostname for athesupplied alias hostname
as well § load
an application
distribution
as the IP address
a user directly interacts.
of the host. In fact,
Instead,
the MX
DNS provides
recordIP(see below) for
a core
permits
Internet function—namely, translating hostnames to their underlying addresses, user a
company’s
applications and•mailreplicated
other server
software Web
andinWeb
the serverservers:
Internet. to
We have
noted many
identical
in Section IP
(aliased)
1.2 thathostnames;
much of thefor
example,
complexity in the addresses
a company’s
Internet architecturecorrespond
Web server and mail
is located to one
at theserver
“edges” can name
of both
the be called
network. Theenter-
DNS,
prise.com.
which implements the critical name-to-address translation process using clients and servers
• Load
located distribution.
at the edge of the DNS is also
network, is yetused to perform
another example load distribution
of that among repli-
design philosophy.
cated servers, such as replicated Web servers. Busy sites, such as cnn.com, are
replicated over multiple servers, with each server running on a different end sys-
tem and each having a different IP address. For replicated Web servers, a set of IP
addresses is thus associated with one alias hostname. The DNS database contains
this set of IP addresses. When clients make a DNS query for a name mapped to a
set of addresses, the server responds with the entire set of IP addresses, but rotates
the ordering of the addresses within each reply. Because a client typically sends
its HTTP request message to the IP address that is listed first in the set, DNS rota-
tion distributes the traffic among the replicated servers. DNS rotation is also used
for e-mail so that multiple mail servers can have the same alias name. Also, con-
tent distribution companies such as Akamai have used DNS in more sophisticated
4
ways [Dilley 2002] to provide Web content distribution (see Section 2.6.3). 11/02/20 11:41 AM

The DNS is specified in RFC 1034 and RFC 1035, and updated in several addi-
tional RFCs. It is a complex system, and we only touch upon key aspects of its
DNS services why not centralize DNS?
§ hostname to IP address
translation
§ host aliasing
• canonical, alias names
§ mail server aliasing
§ load distribution
• replicated Web
servers: many IP
addresses correspond
to one name

globe, as well as an application-layer protocol that specifies how the DNS servers and querying hosts
communicate.

A simple design for DNS would have one DNS server that contains all the mappings. In this centralized
design, clients simply direct all queries to the single DNS server, and the DNS server responds directly
DNS services why not centralize DNS?

to the querying clients. Although the simplicity of this design is attractive, it is inappropriate for today’s
Internet, with its vast (and growing) number of hosts. The problems with a centralized design include:
A single point of failure. If the DNS server crashes, so does the entire Internet!
Traffic volume. A single DNS server would have to handle all DNS queries (for all the HTTP
requests and e-mail messages generated from hundreds of millions of hosts).
Distant centralized database. A single DNS server cannot be “close to” all the querying clients. If
we put the single DNS server in New York City, then all queries from Australia must travel to the
other side of the globe, perhaps over slow and congested links. This can lead to significant delays.
Maintenance. The single DNS server would have to keep records for all Internet hosts. Not only
would this centralized database be huge, but it would have to be updated frequently to account for
every new host.
In summary, a centralized database in a single DNS server simply doesn’t scale. Consequently, the
A: doesn‘t scale!
DNS is distributed by design. In fact, the DNS is a wonderful example of how a distributed database can
be implemented in the Internet.
A Distributed, Hierarchical Database Application Layer 2-72

2.4 • DNS—THE INTERNET’S DIRECTORY SERVICE 1
DNS: a distributed, hierarchical database

Root DNS servers
com DNS servers org DNS servers edu DNS servers
facebook.com amazon.com pbs.org nyu.edu umass.edu

DNS servers DNS servers DNS servers DNS servers DNS servers
Figure 2.17 ♦ Portion of the hierarchy of DNS servers
clientthe
wants IP for www.amazon.com; 1 approximation:
root servers, which returns IP addresses for TLDstservers for the top-level domain
com. The client then contacts one of these TLD servers, which returns the IP address
§ client queries root
of an authoritative server server to find Finally,
for amazon.com. com DNS server
the client contacts one of the
authoritative servers for amazon.com, which returns the IP address for the host-
§ client queries .com DNS server to get amazon.com DNS server
name www.amazon.com. We’ll soon examine this DNS lookup process in more
§ client
detail. queries amazon.com
But let’s first take a closer lookDNS
at theseserver to ofget
three classes DNSIPservers:
address for
www.amazon.com
• Root DNS servers. There are more than 1000 root servers instances scattered all
over the world, as shown in Figure 2.18. These root servers are copies of 13 dif-
ferent root servers, managed by 12 different organizations, and coordinated
through the Internet Assigned Numbers Authority [IANA 2020]. The full list Layer 2-73
Application
of root name servers, along with the organizations that manage them and their
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 logical root name
(5 other sites)
b. USC-ISI Marina del Rey, CA
“servers” worldwide
l. ICANN Los Angeles, CA •each “server” replicated
(41 other sites)
g. US DoD Columbus, many times (more than 1000
OH (5 other sites) root servers instances scattered
all over the world)
DNS: root name servers
128 CHAPTER 2 • APPLICATION LAYER
Key:
0 Servers
1–10 Servers
11–20 Servers
21+ Servers
Figure 2.18 ♦ DNS root servers in 2020
authoritative DNS server of some service provider. Most universities and large
companies implement and maintain their own primary and secondary (backup)
authoritative DNS server. Application Layer 2-75
The root, TLD, and authoritative DNS servers all belong to the hierarchy of
TLD, authoritative servers
top-level domain (TLD) servers:
• responsible for top level domains (e.g., com, .org, .net,
.edu) 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 (e.g., map a mail-server belonging to this
organization to its IP)
• can be maintained by organization or service provider

Local DNS name server
§ does not strictly belong to hierarchy
§ each ISP (residential ISP, company, university) has
one
• also called “default name server”
• ISP provides a host with IP of one or more of its Local
DNS servers (using DHCP) – typically closest to host
§ 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

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
local DNS server

iterated query: 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
cis.poly.edu
server”
gaia.cs.umass.edu

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

DNS: caching, updating records
§ once (any) name server learns mapping, it caches
mapping (why?)
• cache entries timeout (disappear) after some time (TTL)
(why?)
• 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

Attacking DNS (DDOS)
FOCUS ON SECURITY
§ Dbombard
NS VULNERABILITIES
root servers with traffic
We have seen that DNS is a critical component of the Internet infrastructure, with
• not successful to date
many important services—including the Web and e-mail—simply incapable of func-
• traffic
tioning filtering
without it. We therefore naturally ask, how can DNS be attacked? Is DNS a
sitting
• localduck,DNS
waiting to be knocked
servers cacheoutIPs
of service,
of TLD while taking most
servers, Internet applica-
allowing root
tionsserver
down with it?
bypass
The first type of attack that comes to mind is a DDoS bandwidth-flooding attack
(see Section 1.6) against DNS servers. For example, an attacker could attempt to
send to each DNS root server a deluge of packets, so many that the majority of
legitimate DNS queries never get answered. Such a large-scale DDoS attack against
DNS root servers actually took place on October 21, 2002. In this attack, the attack-
ers leveraged a botnet to send truck loads of ICMP ping messages to each of the
13 DNS root IP addresses. (ICMP messages are discussed in Section 5.6. For now,
it suffices to know that ICMP packets are special types of IP datagrams.) Fortunately,
this large-scale attack caused minimal damage, having little or no impact on users’
Internet experience. The attackers did succeed at directing a deluge of packets at the
root servers. But many of the DNS root servers were protected by packet filters, con-
figured to always block all ICMP ping messages directed at the root servers. These
protected servers were thus spared and functioned as normal. Furthermore, most local
DNS servers cache the IP addresses of top-level-domain servers, allowing the query
process to often bypass the DNS root servers.
Internet experience. The attackers did succeed at directing a deluge of packets at the
root servers. But many of the DNS root servers were protected by packet filters, con-
figured to always block all ICMP ping messages directed at the root servers. These
Attacking DNS
protected servers were thus spared and functioned as normal. Furthermore, most local
DNS servers cache the IP addresses of top-level-domain servers, allowing the query
process to often bypass the DNS root servers.
A potentially more effective DDoS attack against DNS is send a deluge of DNS
queries to top-level-domain servers, for example, to top-level-domain servers that
handle the .com domain. It is harder to filter DNS queries directed to DNS servers;
and top-level-domain servers are not as easily bypassed as are root servers. Such an
attack took place against the top-level-domain service provider Dyn on October 21,
2016. This DDoS attack was accomplished through a large number of DNS lookup
requests from a botnet consisting of about one hundred thousand IoT devices such as
printers, IP cameras, residential gateways and baby monitors that had been infected
with Mirai malware. For almost a full day, Amazon, Twitter, Netflix, Github and
Spotify were disturbed.
DNS could potentially be attacked in other ways. In a man-in-the-middle attack,
the attacker intercepts queries from hosts and returns bogus replies. In the DNS poi-
soning attack, the attacker sends bogus replies to a DNS server, tricking the server
into accepting bogus records into its cache. Either of these attacks could be used,
for example, to redirect an unsuspecting Web user to the attacker’s Web site. The
DNS Security Extensions (DNSSEC [Gieben 2004; RFC 4033] have been designed
and deployed to protect against such exploits. DNSSEC, a secured version of DNS,
addresses many of these possible attacks and is gaining popularity in the Internet.
Attacking DNS

Attacking DNS

Attacking DNS

Chapter 2: outline

Pure P2P architecture
§ no always-on server
§ arbitrary end systems
directly communicate
§ peers are intermittently
connected and change
IP addresses
examples:
• file distribution
(BitTorrent)
• Streaming (KanKan)
• VoIP (Skype)

File distribution: client-server vs P2P
Question: how much time to distribute file (size F) from
one server to N peers?
• peer upload/download capacity is limited resource
us: server upload

capacity
di: peer i download

file, size F u1 d1 capacity
us u2 d2
server
di
uN network (with abundant
bandwidth) ui
dN
ui: peer i upload
capacity

File distribution time: client-server
§ server transmission: must
sequentially send (upload) N F
us
file copies:
di
• time to send one copy: F/us
network
• time to send N copies: NF/us ui
§ client: each client must

download file copy
• dmin = min client download rate
• min client download time: F/dmin
time to distribute F
to N clients using Dc-s > max{NF/us,,F/dmin}
client-server approach
increases linearly in N
File distribution time: P2P
§ server transmission: must
upload at least one copy F
us
• time to send one copy: F/us
di
§ client: each client must network
download file copy ui
• min client download time: F/dmin
§ clients: as aggregate must download NF bits
• max upload rate (limiting max download rate) is us + Sui
time to distribute F
to N clients using DP2P > max{F/us,,F/dmin,,NF/(us + Sui)}
P2P approach
increases linearly in N …
… but so does this, as each peer brings service capacity
Client-server vs. P2P: example
client upload rate = u, F/u = 1 hour, us = 10u, dmin ≥ us
3.5
P2P
Minimum Distribution Time
3
Client-Server
2.5
1.5
0.5
0
0 5 10 15 20 25 30 35
N
P2P file distribution: BitTorrent
§ file divided into 256Kb chunks
§ peers in torrent send/receive file chunks
tracker: tracks peers torrent: group of peers
participating in torrent exchanging chunks of a file
Alice arrives …
… obtains (random) list
of peers from tracker
… and begins exchanging
(over TCP conn.) file chunks
with peers in torrent
P2P file distribution: BitTorrent
§ peer joining torrent:
• has no chunks, but will
accumulate them over time
from other peers
• registers with tracker to get
list of peers, connects to
subset of peers
(“neighbors”)
§ while downloading, peer uploads chunks to other peers
§ peer may change peers with whom it exchanges chunks
§ churn: peers may come and go
§ once peer has entire file, it may (selfishly) leave or
(altruistically) remain in torrent

BitTorrent: requesting, sending file chunks
requesting chunks: sending chunks: tit-for-tat

§ at any given time, different § Alice sends chunks to those
peers have different subsets four peers currently sending her
of file chunks chunks at highest rate
§ periodically, Alice asks each • other peers are choked by Alice
peer for list of chunks that (do not receive chunks from her)
they have • re-evaluate top 4 every10 secs
§ Alice requests missing § every 30 secs: randomly select
chunks from peers, “rarest another peer, starts sending
first” chunks
• “optimistically unchoke” this peer
• newly chosen peer may join top 4

BitTorrent: tit-for-tat
(1) Alice “optimistically unchokes” Bob
(2) Alice becomes one of Bob’s top-four providers; Bob reciprocates
(3) Bob becomes one of Alice’s top-four providers
higher upload rate: find better

trading partners, get file faster !

Chapter 2: outline
2.3 electronic mail networks (CDNs)

Video Streaming and CDNs: context
§ video traffic: major consumer of Internet bandwidth
• Netflix, YouTube: 37%, 16% of downstream
residential ISP traffic
• ~1.8B YouTube users (as of 2021), ~222M
Netflix users (2021)
§ challenge: scale - how to reach ~2B
users?
• single mega-video server won’t work
§ challenge: heterogeneity
§ different users have different capabilities (e.g.,
wired versus mobile; bandwidth rich versus
bandwidth poor)
§ solution: distributed, application-level
infrastructure
Multimedia: video
spatial coding example: instead
of sending N values of same
color (all purple), send only two
values: color value (purple) and
number of repeated values (N)
§ video: sequence of images
displayed at constant rate ……………………..
……………….…….
• e.g., 24 images/sec
§ digital image: array of pixels
• each pixel represented
by bits
§ coding: use redundancy frame i
within and between images
to decrease # bits used to
encode image
• spatial (within image) temporal coding example:
instead of sending
• temporal (from one complete frame at i+1,
image to next) send only differences from
frame i frame i+1

Multimedia: video
spatial coding example: instead
of sending N values of same
color (all purple), send only two
values: color value (purple) and
number of repeated values (N)
§ CBR: (constant bit rate):
video encoding rate fixed ……………………..
……………….…….
§ VBR: (variable bit rate):
video encoding rate changes
as amount of spatial,
temporal coding changes
§ examples:
• MPEG 1 (CD-ROM) 1.5 frame i
Mbps
• MPEG2 (DVD) 3-6 Mbps
temporal coding example:
• MPEG4 (often used in instead of sending
Internet, < 1 Mbps) complete frame at i+1,
send only differences from
frame i frame i+1

Streaming stored video:
simple scenario:
Internet
video server client

(stored video)
HTTP streaming à URL, use GET request to obtain the file
Clients receive same encoding

despite the bandwidth variation
among clients
Streaming multimedia: DASH
§ DASH: Dynamic, Adaptive Streaming over HTTP
§ server:
• divides video file into multiple chunks
• each chunk stored, encoded at different rates
• manifest file: provides URLs for different chunks
§ client:
• periodically measures server-to-client bandwidth
• consulting manifest, requests one chunk at a time
• chooses maximum coding rate sustainable given
current bandwidth
• can choose different coding rates at different points
in time (depending on available bandwidth at time)
Streaming multimedia: DASH
§ DASH: Dynamic, Adaptive Streaming over HTTP
§ “intelligence” at client: client determines
• when to request chunk (so that buffer starvation, or
overflow does not occur)
• what encoding rate to request (higher quality when
more bandwidth available)
• where to request chunk (can request from URL server
that is “close” to client or has high available
bandwidth)

Content distribution networks
§ challenge: how to stream content (selected from
millions of videos) to hundreds of thousands of
simultaneous users?
§ option 1: single, large “mega-server”

• single point of failure
• point of network congestion
• long path to distant clients
• multiple copies of video sent over outgoing link
….quite simply: this solution doesn’t scale

Content distribution networks
§ challenge: how to stream content (selected from
millions of videos) to hundreds of thousands of
simultaneous users?
§ option 2: store/serve multiple copies of videos at

multiple geographically distributed sites (CDN)
• enter deep: push CDN servers deep into many access
networks
• close to users
• used by Akamai, 1700 locations
• bring home: smaller number (10’s) of larger clusters in
POPs near (but not within) access networks
• used by Limelight

Content Distribution Networks (CDNs)
§ CDN: stores copies of content at CDN nodes
• e.g. Netflix stores copies of MadMen
§ subscriber requests content from CDN
• directed to nearby copy, retrieves content
• may choose different copy if network path congested
… …
…
manifest file
…
where’s Madmen?
… …
CDN Operation
Having identified the two major approaches toward deploying a CDN, let’s now dive down into the nuts

and bolts of how a CDN operates. When a browser in a user’s
CASE STUDY
GOOGLE’S NETWORK INFRASTRUCTURE
To support its vast array of cloud services—including search, Gmail, calendar, YouTube video,
maps, documents, and social networks—Google has deployed an extensive private network and
CDN infrastructure. Google’s CDN infrastructure has three tiers of server clusters:
Fourteen “mega data centers,” with eight in North America, four in Europe, and two in Asia
[Google Locations 2016], with each data center having on the order of 100,000 servers.
These mega data centers are responsible for serving dynamic (and often personalized)
content, including search results and Gmail messages.
An estimated 50 clusters in IXPs scattered throughout the world, with each cluster consisting
on the order of 100–500 servers [Adhikari 2011a]. These clusters are responsible for
serving static content, including YouTube videos [Adhikari 2011a].
Many hundreds of “enter-deep” clusters located within an access ISP. Here a cluster
typically consists of tens of servers within a single rack. These enter-deep servers perform
TCP splitting (see Section 3.7) and serve static content [Chen 2011], including the static
portions of Web pages that embody search results.
All of these data centers and cluster locations are networked together with Google’s own private
Application
network. When a user makes a search query, often the query is first sent over the local ISP to a Layer 2-112
nearby enter-deep cache, from where the static content is retrieved; while providing the static

An estimated 50 clusters in IXPs scattered throughout the world, with each cluster consisting
Fourteen “mega data centers,” with eight in North America, four in Europe, and two in Asia
[Google Locations 2016], with each data center having on the order of 100,000 servers.
typically
An estimated 50 consists
clusters in IXPs scattered throughout theof
world,tens of servers
with each cluster consisting within a single rack. These enter-deep servers perform
TCP splitting (see Section 3.7) and serve static content [Chen 2011], including the static
typically consists of tens of servers within a single rack. These enter-deep servers perform
portions
TCP splitting (see Section 3.7) and of
serve Web
static contentpages thattheembody
[Chen 2011], including static search results.
portions of Web pages that embody search results.
network. When a user makes a search query, often the query is first sent over the local ISP to a
content to the client, the nearby cache also forwards the query over Google’s private network to
network. When a user makes a search query, often the query is first sent over the local ISP to a
one of the mega data centers, from where the personalized search results are retrieved. For a
YouTube video, the video itself may come from one of the bring-home caches, whereas portions
of the Web page surrounding the video may come from the nearby enter-deep cache, and the
advertisements surrounding the video come from the data centers. In summary, except for the
local ISPs, the Google cloud services are largely provided by a network infrastructure that is
content to the client, the nearby cache also forwards the query over Google’s private network to
independent of the public Internet.
one of the mega data centers, from where the personalized search results are retrieved. For a
host is instructed to retrieve a specific video (identified by a URL), the CDN must intercept the request
so that it can (1) determine a suitable CDN server cluster for that client at that time, and (2) redirect the
client’s request to a server in that cluster. We’ll shortly discuss how a CDN can determine a suitable
YouTube video, the video itself may come from one of the bring-home caches, whereas portions
cluster. But first let’s examine the mechanics behind intercepting and redirecting a request.
of the Web page surrounding the video may come from the nearby enter-deep cache, and the
Most CDNs take advantage of DNS to intercept and redirect requests; an interesting discussion of such
a use of the DNS is [Vixie 2009]. Let’s consider a simple example to illustrate how the DNS is typically
involved. Suppose a content provider, NetCinema, employs the third-party CDN company, KingCDN, to
advertisements surrounding the video come from the data centers. In summary, except for the
distribute its videos to its customers. On the NetCinema Web pages, each of its videos is assigned a
URL that includes the string “video” and a unique identifier for the video itself; for example, Transformers
local ISPs, the Google cloud services are largely provided by a network infrastructure that is
7 might be assigned http://video.netcinema.com/6Y7B23V. Six steps then occur, as shown in Figure
2.25:
independent of the public Internet.

1. The user visits the Web page at NetCinema.
2. When the user clicks on the link http://video.netcinema.com/6Y7B23V, the user’s host sends a
DNS query for video.netcinema.com.
host is instructed to retrieve a specific video (identified by a URL), the CDN must intercept the request
so that it can (1) determine a suitable CDN server cluster for that client at that time, and (2) redirect the
client’s request to a server in that cluster. We’ll shortly discuss how a CDN can determine a suitable
cluster. But first let’s examine the mechanics behind intercepting and redirecting a request.
Most CDNs take advantage of DNS to intercept and redirect requests; an interesting discussion of such
CDN content access: a closer look
Bob (client) requests video http://netcinema.com/6Y7B23V
§ video stored in CDN at http://KingCDN.com/NetC6y&B23V
1. Bob gets URL for video

http://netcinema.com/6Y7B23V
from netcinema.com web page 2. resolve http://netcinema.com/6Y7B23V
2 via Bob’s local DNS
1
6. request video from 5 Bob’s
KINGCDN server, local DNS
streamed via HTTP server
3. netcinema’s DNS returns URL 4&5. Resolve
netcinema.com 4 http://KingCDN.com/NetC6y&B23
http://KingCDN.com/NetC6y&B23V
via KingCDN’s authoritative DNS,
3 which returns IP address of KingCDN
server with video
netcinema’s
authoratative DNS KingCDN.com KingCDN
authoritative DNS Application Layer 2-115
Case study: Netflix Content ingesting () and
processing (e.g., creating
copies, formatting, etc.)
done by these servers, and
User registration, login, billing, movie catalogue, etc. then distribution to CDN
servers
upload copies of
Amazon cloud multiple versions of
video to CDN servers
CDN
server
Netflix registration,
accounting servers
3. Manifest file
2. Bob browses returned for CDN
Netflix video 2 requested video server
3
1 Installed at IXPs
and at ISP
1. Bob manages premises
Netflix account CDN

server
4. DASH
streaming

the client to use a particular CDN server. Furthermore, the Netflix CDN uses push
caching rather than pull caching (Section 2.2.5): content is pushed into the servers at
scheduled times at off-peak hours, rather than dynamically during cache misses.
Case
YouTube
study: Youtube
With hundreds of hours of video uploaded to YouTube every minute and several
billion video views per day, YouTube is indisputably the world’s largest video-
sharing site. YouTube began its service in April 2005 and was acquired by Google
in November 2006. Although the Google/YouTube design and protocols are pro-
prietary, through several independent measurement efforts we can gain a basic
understanding about how YouTube operates [Zink 2009; Torres 2011; Adhikari
2011a]. As with Netflix, YouTube makes extensive use of CDN technology to dis-
tribute its videos [Torres 2011]. Similar to Netflix, Google uses its own private CDN
to distribute YouTube videos, and has installed server clusters in many hundreds
of different IXP and ISP locations. From these locations and directly from its huge
data centers, Google distributes YouTube videos [Adhikari 2011a]. Unlike Netflix,
however, Google uses pull caching, as described in Section 2.2.5, and DNS redirect,
as described in Section 2.6.3. Most of the time, Google’s cluster-selection strategy
directs the client to the cluster for which the RTT between client and cluster is the
lowest; however, in order to balance the load across clusters, sometimes the client is
directed (via DNS) to a more distant cluster [Torres 2011].
YouTube employs HTTP streaming, often making a small number of differ-
ent versions available for a video, each with a different bit rate andApplication
corresponding
Layer 2-117
quality level. YouTube does not employ adaptive streaming (such as DASH), but
data centers, Google distributes YouTube videos [Adhikari 2011a]. Unlike Netflix,
of different
however, IXP and
Google usesISPpulllocations.
caching, as From these locations
described in Sectionand directly
2.2.5, and DNSfromredirect,
its huge
data
as centers,inGoogle
described Section distributes
2.6.3. Most YouTube videosGoogle’s
of the time, [Adhikari 2011a]. Unlikestrategy
cluster-selection Netflix,
Case study: Youtube
however,
directs theGoogle
as described
lowest;
client touses
however,
thepull
in Section
cluster
in order2.6.3.
caching,
Most the
to balance
as described
for which
of the
the RTTinbetween
loadtime,
across
Section client
Google’s
2.2.5, and
and DNS
cluster
clusters,cluster-selection
sometimes the client
redirect,
is the
strategy
is
directs the
directed (viaclient
DNS)totothe cluster
a more for which
distant clusterthe RTT between
[Torres 2011]. client and cluster is the
lowest; however,
YouTube in order
employs HTTPto balance the load
streaming, across
often clusters,
making sometimes
a small numberthe of client
differ-is
directed
ent versions(viaavailable
DNS) to for a more distant
a video, cluster
each with[Torres 2011].
a different bit rate and corresponding
quality YouTube employs does
level. YouTube HTTP notstreaming, often making
employ adaptive streaminga small
(suchnumber of differ-
as DASH), but
ent versions
instead requiresavailable
the user fortoa manually
video, each witha aversion.
select differentInbit rate toand
order corresponding
save bandwidth
quality
and serverlevel. YouTube
resources thatdoeswouldnot beemploy
wastedadaptive streaming or
by repositioning (such
earlyas termination,
DASH), but
instead requires
YouTube uses thethe HTTPuserbyte to manually
range requestselect
to alimit
version. In order
the flow to save bandwidth
of transmitted data after
aand server
target amountresources
of video that would be wasted by repositioning or early termination,
is prefetched.
YouTube
Several uses the HTTP
million videos bytearerange
uploadedrequest to limit theevery
to YouTube flowday.
of transmitted
Not only are dataYou-
after
a target
Tube amount
videos of video
streamed from is server
prefetched.
to client over HTTP, but YouTube uploaders also
upload Several millionfrom
their videos videosclientaretouploaded to YouTube
server over HTTP. YouTubeevery day. Not only
processes arevideo
each You-
itTube videosconverting
receives, streamed it from
to aserver
YouTube to client
videoover HTTP,
format andbut YouTube
creating uploaders
multiple also
versions
atupload theirbitvideos
different rates. from client to server
This processing takesover
placeHTTP. YouTube
entirely processes
within Google dataeach video
centers.
it receives,
(See the caseconverting it to a YouTube
study on Google’s networkvideo format and
infrastructure creating2.6.3.)
in Section multiple versions
at different bit rates. This processing takes place entirely within Google data centers.
(See the case study on Google’s network infrastructure in Section 2.6.3.)
2.7 Socket Programming: Creating Network
Applications
2.7 Socket Programming: Creating Network Application Layer 2-118
Applications
Now that we’ve looked at a number of important network applications, let’s explore
Chapter 2: outline

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

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 data to server
2. server receives the data and converts characters
to uppercase
3. server sends modified data to client
4. client receives modified data and displays line on
its screen
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
§ receiver 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

Client/server socket interaction: UDP
server (running on serverIP) client

create socket:
create socket, port= x: clientSocket =
serverSocket = socket(AF_INET,SOCK_DGRAM)
socket(AF_INET,SOCK_DGRAM)
Create datagram with server IP and
port=x; send datagram via
read datagram from clientSocket
serverSocket
write reply to
serverSocket read datagram from
specifying clientSocket
client address,
port number close
clientSocket
Application 2-123
Example app: UDP client
Python UDPClient
include Python’s socket
library
from socket import *
serverName = ‘hostname’
serverPort = 12000
create UDP socket for clientSocket = socket(AF_INET,
server
SOCK_DGRAM)
get user keyboard
input message = raw_input(’Input lowercase sentence:’)
Attach server name, port to clientSocket.sendto(message.encode(),
message; send into socket
(serverName, serverPort))
read reply characters from modifiedMessage, serverAddress =
socket into string
clientSocket.recvfrom(2048)
print out received string print modifiedMessage.decode()
and close socket
clientSocket.close()
Example app: UDP server
Python UDPServer
serverPort = 12000
create UDP socket serverSocket = socket(AF_INET, SOCK_DGRAM)
bind socket to local port
number 12000
serverSocket.bind(('', serverPort))
print (“The server is ready to receive”)
loop forever while True:
Read from UDP socket into message, clientAddress = serverSocket.recvfrom(2048)
message, getting client’s
address (client IP and port) modifiedMessage = message.decode().upper()
send upper case string serverSocket.sendto(modifiedMessage.encode(),
back to this client
clientAddress)

Socket programming with TCP
client must contact server § when contacted by client,
§ server process must first be server TCP creates new socket
running for server process to
§ server must have created communicate with that
socket (door) that particular client
welcomes client’s contact • allows server to talk with
multiple clients
client contacts server by: • source port numbers used
§ Creating TCP socket, to distinguish clients
specifying IP address, port (more in Chap 3)
number of server process
§ when client creates socket: application viewpoint:
client TCP establishes TCP provides reliable, in-order
connection to server TCP byte-stream transfer (“pipe”)
between client and server

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

Example app: TCP client
Python TCPClient
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.encode())
name, port
modifiedSentence = clientSocket.recv(1024)
print (‘From Server:’, modifiedSentence.decode())
clientSocket.close()

Example app: TCP server
Python TCPServer
create TCP welcoming serverPort = 12000
socket serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((‘’,serverPort))
server begins listening for
incoming TCP requests serverSocket.listen(1)
print ‘The server is ready to receive’
loop forever
while True:
server waits on accept()
for incoming requests, new
connectionSocket, addr = serverSocket.accept()
socket created on return
sentence = connectionSocket.recv(1024).decode()
read bytes from socket (but
not address as in UDP) capitalizedSentence = sentence.upper()
close connection to this connectionSocket.send(capitalizedSentence.
client (but not welcoming
socket) encode())
connectionSocket.close()
Chapter 2: summary
our study of network apps now complete!
§ application architectures § specific protocols:
• client-server • HTTP
• P2P • SMTP, POP, IMAP
§ application service
requirements: • DNS
• reliability, bandwidth, delay • P2P: BitTorrent
§ Internet transport service § video streaming, CDNs
model § socket programming:
• connection-oriented,
TCP, UDP sockets
reliable: TCP
• unreliable, datagrams: UDP

Chapter 2: summary
most importantly: learned about protocols!
§ typical request/reply important themes:

message exchange:
§ control vs. messages
• client requests info or
service • in-band, out-of-band
• server responds with § centralized vs. decentralized
data, status code
§ stateless vs. stateful
§ message formats:
§ reliable vs. unreliable message
• headers: fields giving
info about data transfer
• data: info(payload) § “complexity at network
being communicated edge”

Coen366 Module2

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Coen366 Module2

Uploaded by

Copyright:

Available Formats

Chapter 2

A note on the use of these Powerpoint slides:

Application Layer 2-2

Application Layer 2-3

no need to write software

Not a network architecture!

Application Layer 2-6

Application Layer 2-9

Controlled TCP with TCP with Controlled

Figure 2.3 ♦ Application processes, sockets, and underlying transport protocol

Application Layer 2-11

Application Layer 2-12

Application Layer 2-13

Application Data Loss Throughput Time-Sensitive

File transfer/download No loss Elastic No

Figure 2.4 ♦ Requirements of selected network applications

Application Application-Layer Protocol Underlying Transport Protocol

Electronic mail SMTP [RFC 5321] TCP

Figure 2.5 ♦ Popular Internet applications, their application-layer

Application Layer 2-16

TCP & UDP SSL is at app layer

Application Layer 2-18

host name path name

Application Layer 2-19

Application Layer 2-20

Application Layer 2-21

Application Layer 2-22

Application Layer 2-24

RTT (definition): time for a

Application Layer 2-25

non-persistent HTTP issues: persistent HTTP:

Application Layer 2-26

We can learn a lot by taking a close look at this simple req

lowed by an additional carriage return and line feed. Although

method sp URL sp version cr lf request

header field name value cr lf

Application Layer 2-29

Application Layer 2-30

Application Layer 2-31

HTTP response message

HTTP Response Message

HTTP response message

Status line version sp status code sp phrase cr lf

header field name: sp value cr lf

header field name: sp value cr lf

Figure 2.9 ♦ General format of an HTTP response message

Application Layer 2-33

Application Layer 2-36

one week later:

how to keep “state”:

Cookies create a user session layer on top of stateless HTTP.

Application Layer 2-40

Figure 2.12 Bottleneck between an institutional network and the Internet

which is just slightly greater than 1.2 seconds. Thus,

Application Layer 2-48

§ Standardized in 2015, many websites already support

Application Layer 2-50

§ HTTP/1: solve this by opening my TCP connections à

Application Layer 2-52

Application Layer 2-65

Application Layer 2-66

DNS: services, structure