0% found this document useful (0 votes)
15 views58 pages

Application Layer in Computer Networks

The document outlines the course COMPSCI 453 on Computer Networks, focusing on the application layer and its protocols such as HTTP, SMTP, and DNS. It discusses the client-server and peer-to-peer architectures, the creation of network applications, and the role of sockets in communication. Additionally, it covers HTTP's functionality, including persistent and non-persistent connections, and introduces concepts like cookies for maintaining state in web transactions.

Uploaded by

c9borg
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views58 pages

Application Layer in Computer Networks

The document outlines the course COMPSCI 453 on Computer Networks, focusing on the application layer and its protocols such as HTTP, SMTP, and DNS. It discusses the client-server and peer-to-peer architectures, the creation of network applications, and the role of sockets in communication. Additionally, it covers HTTP's functionality, including persistent and non-persistent connections, and introduces concepts like cookies for maintaining state in web transactions.

Uploaded by

c9borg
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

COMPSCI 453 Computer Networks

Professor Jim Kurose


College of Information and Computer Sciences
1 University of Massachusetts

Computer Networks Class textbook:


Computer Networking: A

Chapter 2: Application Layer Top-Down Approach (8th ed.)


J.F. Kurose, K.W. Ross
Pearson, 2020
[Link]

Instructors:
Anas Abudaqa
Leen Alharbi
Application Layer COMPSCI 453 Computer Networks
Professor Jim Kurose
College of Information and Computer Sciences

▪ Principles of network applications University of Massachusetts

▪ Web and HTTP


▪ E-mail, SMTP, IMAP Class textbook:


Computer Networking: A
The Domain Name System: DNS Top-Down Approach (8th ed.)
J.F. Kurose, K.W. Ross
Pearson, 2020
[Link]
Application layer: overview
Our goals: ▪ learn about protocols by
examining popular
▪ conceptual and application-layer protocols
implementation aspects of and infrastructure
application-layer protocols • HTTP
•transport-layer service • SMTP, IMAP
models • DNS
• video streaming systems, CDNs
•client-server paradigm
▪ programming network
•peer-to-peer paradigm applications
• socket API
Some network apps
▪ social networking ▪ voice over IP (e.g., Skype)
▪ Web ▪ real-time video conferencing
▪ text messaging (e.g., Zoom)
▪ e-mail ▪ Internet search
▪ multi-user network games ▪ remote login
▪ streaming stored video ▪…
(YouTube)
Q: your favorites?
▪ P2P file sharing
Creating a network app
application
transport

write programs that: mobile network


network
data link
physical

▪ run on (different) end systems


national or global ISP

▪ communicate over network


▪ e.g., web server software
communicates with browser software
local or
no need to write software for regional ISP

network-core devices home network content


application
provider
▪ network-core devices do not run user transport
network network datacenter
application
data link network
applications physical
transport
network
data link
▪ applications on end systems allows physical

for rapid app development, enterprise


network
propagation
Client-server paradigm
server: mobile network
▪ always-on host national or global ISP

▪ permanent IP address
▪ often in data centers, for scaling
clients: local or

▪ contact, communicate with server regional ISP

▪ may be intermittently connected home network content


provider
▪ may have dynamic IP addresses network datacenter
network

▪ do not communicate directly with


each other
▪ examples: HTTP, IMAP, FTP
enterprise
network
Peer-peer architecture
▪ no always-on server
mobile network
national or global ISP
▪ arbitrary end systems directly
communicate
▪ peers request service from other
peers, provide service in return to local or
other peers regional ISP

• self scalability – new peers bring new home network content


service capacity, as well as new service provider
network datacenter
demands network

▪ peers are intermittently connected


and change IP addresses enterprise
• complex management network

▪ example: P2P file sharing


Processes communicating
process: program running within clients, servers
a host client process: process that
initiates communication
▪within same host, two server process: process
processes communicate using that waits to be contacted
inter-process communication
(defined by OS)
▪ note: applications with
▪processes in different hosts P2P architectures have
communicate by exchanging client processes &
messages server processes
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
• two sockets involved: one on each side

application application
proce socket proce controlled by
ss ss app developer

transport transport
network network controlled
link by OS
link Internet
physical physical
Addressing processes
▪ to receive messages, process ▪ identifier includes both IP address
must have identifier and port numbers associated with
▪ host device has unique 32-bit process on host.
IP address ▪ example port numbers:
▪ Q: does IP address of host on • HTTP server: 80
which process runs suffice for • mail server: 25
identifying the process? ▪ to send HTTP message to
▪ A: no, many processes [Link] web server:
can be running on • IP address: [Link]
same host • port number: 80
▪ more shortly…
:An application-layer protocol defines
▪ types of messages exchanged, open protocols:
• e.g., request, response ▪ defined in RFCs, everyone
▪ message syntax: has access to protocol
• what fields in messages & definition
how fields are delineated ▪ allows for interoperability
▪ message semantics ▪ e.g., HTTP, SMTP
• meaning of information in proprietary protocols:
fields
▪ e.g., Skype, Zoom
▪ rules for when and how
processes send & respond to
messages
Transport
service requirements: common
apps
application data loss throughput time sensitive?

file transfer/download 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, 10’s msec
video:10Kbps-5Mbps
streaming audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant Kbps+ yes, 10’s msec
text messaging no loss elastic yes and no
Internet transport protocols
TCP service: UDP service:
▪ reliable transport between sending ▪ unreliable data transfer
and receiving process between sending and receiving
process
Internet applications, and transport
protocols
application
application layer protocol transport protocol

file transfer/download FTP [RFC 959] TCP


e-mail SMTP [RFC 5321] TCP
Web documents HTTP 1.1 [RFC 7320] TCP
Internet telephony SIP [RFC 3261], RTP [RFC TCP or UDP
3550], or proprietary
streaming audio/video HTTP [RFC 7320], DASH TCP
interactive games WOW, FPS (proprietary) UDP or TCP
Application Layer COMPSCI 453 Computer Networks
Professor Jim Kurose
College of Information and Computer Sciences

▪ Principles of network applications University of Massachusetts

▪ Web and HTTP (part 1)


▪ E-mail, SMTP, IMAP Class textbook:


Computer Networking: A
The Domain Name System: DNS Top-Down Approach (8th ed.)
J.F. Kurose, K.W. Ross
Pearson, 2020
[Link]
Web and HTTP
First, a quick review…
▪ web page consists of objects, each of which can be stored on
different Web servers
▪ object can be HTML file, JPEG image, Java applet, audio
file,…
▪ web page consists of base HTML-file which includes several
referenced objects, each addressable by a URL, e.g.,
[Link]/someDept/[Link]

host name path name


HTTP overview
HTTP: hypertext transfer protocol
▪ Web’s application-layer protocol HT
▪ client/server model: PC running
TP
r equ
est
HT
• client: browser that requests, Firefox browser TP
res
pon
se
receives, (using HTTP protocol) and
“displays” Web objects ue
st
r e q
• server: Web server sends (using HT
TP
po
nse server running
r es Apache Web
HTTP protocol) objects in response H TTP server
to requests
iPhone running
Safari browser
HTTP overview (continued)
HTTP 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 connections: two types
Non-persistent HTTP Persistent HTTP
1. TCP connection opened ▪TCP connection opened to a
2. at most one object sent server
over TCP connection ▪multiple objects can be sent
3. TCP connection closed over single TCP connection
between client, and that
downloading multiple objects server
required multiple connections ▪TCP connection closed
Non-persistent HTTP: example
User enters URL: [Link]/someDepartment/[Link]
(containing text, references to 10 jpeg images)

1a. HTTP client initiates TCP


connection to HTTP server (process) 1b. HTTP server at host [Link]
at [Link] on port 80 waiting for TCP connection at port 80
“accepts” connection, notifying client

2. HTTP client sends HTTP request


message (containing URL) into
TCP connection socket. 3. HTTP server receives request message,
Message indicates that client forms response message containing
time wants object requested object, and sends message
someDepartment/[Link] into its socket
Non-persistent HTTP: example (cont.)
User enters URL: [Link]/someDepartment/[Link]
(containing text, references to 10 jpeg images)

4. HTTP server closes TCP


5. HTTP client receives response connection.
message containing html file, displays
html. Parsing html file, finds 10
referenced jpeg objects

6. Steps 1-5 repeated for


each of 10 jpeg objects
time
Non-persistent HTTP: response time

RTT (Round Trip Time): time for a small


packet to travel from client to server initiate TCP
and back connection
RTT
HTTP response time (per object):
▪ one RTT to initiate TCP connection request file
▪ one RTT for HTTP request and first few RTT time to
transmit
bytes of HTTP response to return file
file received
▪ obect/file transmission time

time time
Non-persistent HTTP response time = 2RTT+ file transmission time
Persistent HTTP (HTTP 1.1)
Non-persistent HTTP issues: Persistent HTTP (HTTP1.1):
▪ requires 2 RTTs per object ▪ server leaves connection open after
▪ OS overhead for each TCP sending response
connection ▪ subsequent HTTP messages between
▪ browsers often open multiple same client/server sent over open
parallel TCP connections to fetch connection
referenced objects in parallel ▪ client sends requests as soon as it
encounters a referenced object
▪ as little as one RTT for all the
referenced objects (cutting response
time in half)
HTTP Versions ( HTTP/1.0)
TCP SYN
• Non-persistent connectivity.
• A separate TCP connection for each http TCP SYN-ACK

request/response exchange. TCP ACK+ HT


TP request
• Each Objects needs 2 RTT (1 TCP handshake
+1 HTTP). HTTP respons
e

• For our example, the overall response time


= 10 RTT. TCP SYN

TCP SYN-ACK

TCP ACK+ HT
TP request

e
HTTP respons
HTTP Versions ( HTTP/1.1)
TCP SYN

• Persistent connectivity (“Keep-Alive”) TCP SYN-ACK


• The TCP connection , after getting the basic TCP ACK+ HT
HTML page, keeps open. TP request

• Other objects are requested over the same HTTP respons


e
connection.
HTTP request
• Each object incurs 1 RTT
e
• For our example, the overall response time HTTP respons

= 1 RTT (TCP handshake)+ 5 RTT= 6 RTT. HTTP request

e
HTTP respons
HTTP request message
▪ two types of HTTP messages: request, response
▪ HTTP request message:
• ASCII (human-readable format)

request line (GET, POST,


GET /[Link] HTTP/1.1\r\n
HEAD commands)
HTTP response
status line (protocol HTTP/1.1 200 OK
status code status phrase) data data data data data ...
Secure HTTP (HTTPS)
• The original HTTP exchanges request/response message
in pure plaintexts.
HTTPS Stack
• HTTP is prone to security breaches (e.g.,
Man-in-The-Middle and DNS Spoofing Attacks) HTTP
• Messages can be intercepted and read clearly (No TLS
confidentiality).
• Messages can be altered or modified (NO Integrity). TCP
• Entity can be Impersonated (NO Authentication).
IP
• HTTP can be secured by the services provided by
Transport Secure Layer (TLS)
• HTTPS = HTTP + TLS
• TLS adds more overhead to HTTP
Transport Layer Security (TLS)
• Tasks:
• Entity Authentication (Protect against DNS Spoofing).
• Data Encryption (Protect against passive MITM).
• Data Integrity (Protect against Active MITM).

• Steps (Phases)
• Handshake (Entity Authentication)
• Key derivation and exchange
• Data transmission
Maintaining user/server state: cookies
Recall: HTTP , by default, is stateless protocol.

Web sites and client browser use cookies to maintain


some state between transactions
four components:
1) cookie header line of HTTP response message
2) cookie header line in next HTTP request message
3) cookie file kept on user’s host, managed by user’s browser
4) back-end database at Web site
Maintaining user/server state: cookies
client
server
ebay 8734 usual HTTP request msg Amazon server
cookie file creates ID
usual HTTP response 1678 for user backend
create
ebay 8734 set-cookie: 1678 entry databas
amazon 1678
e
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
time time
HTTP cookies: comments
aside
What cookies can be used for: cookies and privacy:
▪ authorization ▪ cookies permit sites to
▪ shopping carts learn a lot about you on
their site.
▪ recommendations ▪ third party persistent
▪ user session state (Web e-mail) cookies (tracking cookies)
allow common identity
(cookie value) to be
Challenge: How to keep state? tracked across multiple
▪ at protocol endpoints: maintain state at web sites
sender/receiver over multiple
transactions Summary
▪ in messages: cookies in HTTP messages Cookies change HTTP from stateless
carry state to a stateful protocol.
Application Layer COMPSCI 453 Computer Networks
Professor Jim Kurose
College of Information and Computer Sciences

▪ Principles of network applications University of Massachusetts

▪ Web and HTTP (part 2)


▪ E-mail, SMTP, IMAP Class textbook:


Computer Networking: A
The Domain Name System: DNS Top-Down Approach (8th ed.)
J.F. Kurose, K.W. Ross
▪ P2P applications Pearson, 2020
[Link]

▪ video streaming, CDNs


▪ socket programming with UDP and TCP
Web caches
Goal: satisfy client requests without involving origin server

▪ user configures browser to point


to a (local) Web cache HTT
P re
Web
q u est
que cache P re
▪ browser sends all HTTP requests client HTTP st TT e
resp
H
s pons origin
ons
e TT P re server
to cache e st
H
u
• if object in cache: cache P req se
H TT o n
resp
returns object to client HT
TP

• else cache requests object


client
from origin server, caches
received object, then returns
object to client
Web caches (aka proxy servers)
▪ Web cache acts as both Why Web caching?
client and server
▪ reduce response time for client
• server for original
requesting client request
• client to origin server • cache is closer to client
▪ reduce traffic on an institution’s
access link
▪ Internet is dense with caches
• enables “poor” content providers to
more effectively deliver content
Caching example
Scenario:
▪ access link rate: 1.54 Mbps origin
servers
public
Internet

1.54 Mbps
access link
institutional
network
1 Gbps LAN
Option 1: buy a faster access link
Scenario: 154 Mbps
▪ access link rate: 1.54 Mbps origin
servers
public
Cost: faster access link (expensive!) Internet

154 Mbps
1.54 Mbps
access link
institutional
network
1 Gbps LAN
Option 2: install a web cache
Scenario:
▪ access link rate: 1.54 Mbps origin
▪ Setup web cache servers
public
Internet

1.54 Mbps
access link
Cost: web cache (cheap!)
institutional
network
1 Gbps LAN

local web cache


Conditional GET client server

Goal: don’t send object if cache has


HTTP request msg
up-to-date cached version If-modified-since: <date> object
not
• no object transmission delay (or use of modified
network resources) HTTP response
before
HTTP/1.0
▪ client: specify date of cached copy 304 Not Modified <date>

in HTTP request
If-modified-since: <date>
▪ server: response contains no object HTTP request msg
If-modified-since: <date> object
if cached copy is up-to-date: modified
HTTP/1.0 304 Not Modified HTTP response after
HTTP/1.0 200 OK <date>
<data>
Application Layer COMPSCI 453 Computer Networks
Professor Jim Kurose
College of Information and Computer Sciences

▪ Principles of network applications University of Massachusetts

▪ Web and HTTP


▪ E-mail, SMTP, IMAP Class textbook:


Computer Networking: A
The Domain Name System: DNS Top-Down Approach (8th ed.)
J.F. Kurose, K.W. Ross
▪ P2P applications Pearson, 2020
[Link]

▪ video streaming, CDNs


▪ socket programming with UDP and TCP
E-mail
user
Three major components: agent
▪ user agents mail user
▪ mail servers server agent
▪ simple mail transfer protocol: SMTP SMTP mail user
server agent
SMTP
User Agent user
▪ a.k.a. “mail reader” SMTP agent
mail
▪ composing, editing, reading mail messages server
user
▪ e.g., Outlook, iPhone mail client agent
▪ outgoing, incoming messages stored on user
agent
server outgoing
message queue
E-mail: mail servers user
agent
mail servers: mail user
server
▪ mailbox contains incoming agent

messages for user SMTP mail user


server agent
▪ message queue of outgoing (to be SMTP
sent) mail messages user
SMTP agent
SMTP protocol between mail mail
server
servers to send email messages user
agent
▪ client: sending mail server user
▪ “server”: receiving mail server agent
outgoing
message queue
user mailbox
SMTP RFC (5321) “client”
SMTP server
“server”
SMTP server

▪ uses TCP to reliably transfer email message initiate TCP


from client (mail server initiating connection
RTT
connection) to server, port 25 TCP connection
▪ direct transfer: sending server (acting like client) initiated
to receiving server
22
▪ three phases of transfer SMTP 0
HELO
• SMTP handshaking (greeting) handshaking
• SMTP transfer of messages 250 Hello

• SMTP closure
▪ command/response interaction (like HTTP) SMTP
transfers
• commands: ASCII text
time
• response: status code and phrase
Scenario: Alice sends e-mail to Bob
1) Alice uses UA to compose e-mail 4) SMTP client sends Alice’s message
message “to” bob@[Link] over the TCP connection
2) Alice’s UA sends message to her 5) Bob’s mail server places
mail server using SMTP; message the message in Bob’s
placed in message queue mailbox
3) client side of SMTP at mail server 6) Bob invokes his user
opens TCP connection with Bob’s mail agent to read message
server

1user mail user


mail agent
agent server server
2 3 6
4
5
Alice’s mail server Bob’s mail server
Retrieving email: mail access protocols
user e-mail access user
SMTP SMTP protocol
agent agent
(e.g., IMAP,
HTTP)

sender’s e-mail receiver’s e-mail


server server

▪ SMTP (Simple Mail Transfer Protocol): delivery/storage of e-mail messages


to receiver’s server.
▪ mail access protocol: retrieval from server
• IMAP (Internet Mail Access Protocol): messages stored on server, IMAP
provides retrieval, deletion, folders of stored messages on server
Application Layer COMPSCI 453 Computer Networks
Professor Jim Kurose
College of Information and Computer Sciences

▪ Principles of network applications University of Massachusetts

▪ Web and HTTP


▪ E-mail, SMTP, IMAP Class textbook:


Computer Networking: A
The Domain Name System: DNS Top-Down Approach (8th ed.)
J.F. Kurose, K.W. Ross
Pearson, 2020
[Link]
DNS: Domain Name System
people: many identifiers: Domain Name System (DNS):
• SSN, name, passport # ▪ distributed database implemented in
Internet hosts, routers: hierarchy of many name servers
• IP address (32 bit) - used for ▪ application-layer protocol: hosts, DNS
addressing datagrams
servers communicate to resolve
• “name”, e.g., [Link] - names (address/name translation)
used by humans
Q: how to map between IP
address and name, and vice
versa ?
DNS: services, structure
DNS services: Q: Why not centralize DNS?
▪ hostname-to-IP-address translation ▪ single point of failure
▪ traffic volume
▪ mail server aliasing
▪ distant centralized database
▪ load distribution ▪ maintenance
• replicated Web servers: many IP
addresses correspond to one A: doesn‘t scale!
name ▪ Comcast DNS servers alone:
600B DNS queries/day
▪ Akamai DNS servers alone:
2.2T DNS queries/day
Thinking about the DNS
humongous distributed database:
▪ ~ billion records, each simple
handles many trillions of queries/day:
▪ many more reads than writes
▪ performance matters: almost every
Internet transaction interacts with
DNS - msecs count!
organizationally, physically decentralized:
▪ millions of different organizations
responsible for their records
“bulletproof”: reliability, security
DNS: a distributed, hierarchical database
Root DNS Servers Root
… …
.com DNS servers .org DNS servers .edu DNS servers Top Level Domain
… … … …
[Link] [Link] [Link] [Link] [Link]
DNS servers DNS servers DNS servers DNS servers DNS servers Authoritative

Client wants IP address for [Link]; 1st approximation:


▪ client queries root server to find .com DNS server
▪ client queries .com DNS server to get [Link] DNS server
▪ client queries [Link] DNS server to get IP address for [Link]
DNS: root name servers
▪ official, contact-of-last-resort by
name servers that can not
resolve name
DNS: root name servers
▪ official, contact-of-last-resort by
name servers that can not 13 logical root name “servers”
worldwide each “server” replicated
resolve name many times (~200 servers in US)
▪ incredibly important Internet
function
• Internet couldn’t function without it!
• DNSSEC – provides security
(authentication, message integrity)
▪ ICANN (Internet Corporation for
Assigned Names and Numbers)
manages root DNS domain
Top-Level Domain, and authoritative servers
Top-Level Domain (TLD) servers:
▪ responsible for .com, .org, .net, .edu, .aero, .jobs, .museums, and all top-level
country domains, e.g.: .cn, .uk, .fr, .ca, .jp
▪ Network Solutions: authoritative registry for .com, .net TLD
▪ Educause: .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
Local DNS name servers
▪ when host makes DNS query, it is sent to its local DNS server
• Local DNS server returns reply, answering:
• from its local cache of recent name-to-address translation pairs (possibly out
of date!)
• forwarding request into DNS hierarchy for resolution
• each ISP has local DNS name server; to find yours:
• MacOS: % scutil --dns
• Windows: >ipconfig /all
▪ local DNS server doesn’t strictly belong to hierarchy
:DNS name resolution
root DNS server
Example: host at [Link]
wants IP address for [Link] 2
3
TLD DNS server
1 4
Iterated query:
▪ contacted server replies 8 5
with name of server to requesting host at local DNS server
contact [Link] [Link]
[Link]
▪ “I don’t know this name, 7 6
but ask this server”
authoritative DNS server
[Link]
DNS: caching, updating records
▪ once (any) name server learns mapping, it caches mapping
• caching improves response time
• cache entries timeout (disappear) after some time (TTL)
• TLD servers typically cached in local name servers
▪ cached entries may be out-of-date
• if named host changes IP address, may not be known
Internet-wide until all TTLs expire!
• best-effort name-to-address translation!
Getting your info into the DNS
example: new startup “Network Utopia”
▪ register name [Link] at DNS registrar (e.g., Network
Solutions)
• provide names, IP addresses of authoritative name server (primary and
secondary)
• registrar inserts NS, A RRs into .com TLD server:
([Link], [Link], NS)
([Link], [Link], A)
▪ create authoritative server locally with IP address [Link]
• type A record for [Link]
• type MX record for [Link]
DNS security
DDoS attacks Spoofing attacks
▪ bombard root servers with ▪ intercept DNS queries,
traffic returning bogus replies
• not successful to date ▪ DNS cache poisoning
▪ RFC 4033: DNSSEC
• traffic filtering authentication services
• local DNS servers cache IPs of TLD
servers, allowing root server
bypass
▪ bombard TLD servers
• potentially more dangerous

You might also like