0% found this document useful (0 votes)
4 views

Chapter 2 Application Layer

Chapter 2 of 'Computer Networking: A Top-Down Approach' covers the application layer of computer networks, focusing on various protocols such as HTTP, FTP, and SMTP. It discusses client-server and peer-to-peer architectures, the process of creating network applications, and the role of sockets in communication. Additionally, it highlights the importance of transport service requirements for different applications and provides an overview of HTTP connections and messages.

Uploaded by

khoabossbaby5876
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

Chapter 2 Application Layer

Chapter 2 of 'Computer Networking: A Top-Down Approach' covers the application layer of computer networks, focusing on various protocols such as HTTP, FTP, and SMTP. It discusses client-server and peer-to-peer architectures, the process of creating network applications, and the role of sockets in communication. Additionally, it highlights the importance of transport service requirements for different applications and provides an overview of HTTP connections and messages.

Uploaded by

khoabossbaby5876
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 98

Chapter 2:

Application Layer
Computer Networking: A Top-Down
Approach
6th edition
Jim Kurose, Keith Ross
Addison-Wesley

8/10/2022 1
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with UDP and TCP

8/10/2022 2
Chapter 2: Application Layer
• learn about protocols by
Our goals: examining popular
• conceptual, implementation application-level
aspects of network application protocols
– HTTP
protocols
– FTP
• transport-layer service models
– SMTP / POP3 / IMAP
• client-server paradigm
– DNS
• peer-to-peer paradigm
• creating network
applications
– socket API

8/10/2022 3
Some network apps
• e-mail • voice over IP
• web • real-time video conferencing
• instant messaging • cloud computing
• remote login • Social networking
• P2P file sharing • streaming stored video
• multi-user network games (YouTube)

8/10/2022 4
Creating a network app
application

write programs that: transport


network
data link
• run on (different) end systems physical

• communicate over network


e.g., web server software communicates
with browser software

no need to write software for


network-core devices
• network-core devices do not run
user applications application
transport

• applications on end systems allows network


data link application

for rapid app development, physical transport


network

propagation
data link
physical

8/10/2022 5
Application architectures

•client-server
•peer-to-peer (P2P)
•hybrid of client-server and P2P

8/10/2022 6
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
with each other

8/10/2022
7
P2P architecture
• no always-on server
• arbitrary end systems
directly communicate
• peers are intermittently
connected and change IP
addresses
➢highly scalable but difficult
to manage

8/10/2022 8
Hybrid of client-server and P2P
Skype
• voice-over-IP P2P application
• centralized server: finding address of remote party
• client-client connection: direct (not through server)
Instant messaging
• chatting between two users is P2P
• centralized service: client presence detection/location
• user registers its IP address with central server when it comes online
• user contacts central server to find IP addresses of buddies

8/10/2022 9
Processes communicating
• client process: process
process: program running within a that initiates
host. communication
• within same host, two processes • server process: process
communicate using inter- that waits to be contacted
process communication (defined
by OS). • aside: applications with
P2P architectures have
• processes in different hosts client processes & server
communicate by exchanging processes
messages

8/10/2022 10
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 which brings message to socket at receiving process

application application
socket controlled by
process process app developer

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

8/10/2022 11
Addressing processes
• example port numbers:
• to receive messages, – HTTP server: 80
process must have – mail server: 25
identifier • to send HTTP message to
• host device has unique tdtu.edu.vn web server:
32-bit IP address – IP address: 128.119.245.12
– port number: 80
• identifier includes both
• A list of well-known port
IP address and port
number can be found at
numbers associated http://www.iana.org
with process on host. • We’ll examine port number in
detail in Chapter 3.

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

8/10/2022 13
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
minimum amount of
100% reliable data transfer throughput to be
• other apps (e.g., audio) can “effective”
tolerate some loss ❖ other apps (“elastic apps”)
make use of whatever
timing throughput they get
• some apps (e.g., Internet
telephony, interactive
security
games) require low delay
❖ encryption, data integrity,
to be “effective”

8/10/2022 14
Transport service requirements of
common apps

application data loss throughput time sensitive

file transfer no loss elastic no


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

8/10/2022 15
Internet transport protocols services
TCP service: UDP service:
• reliable transport between
sending and receiving • unreliable data transfer
process between sending and
• flow control: sender won’t receiving process
overwhelm receiver
• does not provide: reliability,
• congestion control: throttle
sender when network flow control, congestion
overloaded control, timing,
• does not provide: timing, throughput guarantee,
minimum throughput security, or connection
guarantee, security
• connection-oriented: setup setup,
required between client and
server processes
8/10/2022 16
Internet apps: application,
transport protocols
application underlying
application layer protocol transport protocol

e-mail SMTP [RFC 2821] TCP


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

8/10/2022 17
Securing TCP
TCP & UDP
• no encryption SSL is at app layer
• cleartext passwds sent • Apps use SSL libraries, which
into socket traverse “talk” to TCP
Internet in cleartext SSL socket API
SSL ❖ cleartext passwds sent into
socket traverse Internet
• provides encrypted TCP
encrypted
connection
❖ See Chapter 7
• data integrity
• end-point authentication
8/10/2022 18
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with UDP and TCP

8/10/2022 19
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
❖ example URL:
www.someschool.edu/someDept/pic.gif

host name path name


8/10/2022 20
HTTP overview
HTTP: hypertext
transfer protocol
❖ Web’s application layer PC running
protocol Firefox browser

❖ client/server model
▪ client: browser that
requests, receives, server
“displays” Web objects running
Apache Web
▪ server: Web server server
sends objects in
response to requests iphone running
Safari browser

8/10/2022 21
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
protocols that maintain
❖ HTTP messages (application- “state” are complex!
layer protocol messages)
❖ past history (state) must
exchanged between browser
be maintained
(HTTP client) and Web
server (HTTP server) ❖ if server/client crashes,
their views of “state” may
❖ TCP connection closed
be inconsistent, must be
reconciled

8/10/2022 22
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

8/10/2022 23
Nonpersistent 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 1b. HTTP server at host
(process) at www.someSchool.edu waiting for
www.someSchool.edu on port TCP connection at port 80.
80 “accepts” connection, notifying
client
2. HTTP client sends HTTP request
message (containing URL) into TCP
connection socket. Message 3. HTTP server receives request
indicates that client wants object message, forms response message
someDepartment/home.index containing requested object, and
sends message into its socket

time
8/10/2022 24
Nonpersistent HTTP (cont.)
4. HTTP server closes TCP connection.

5. HTTP client receives response


message containing html file,
displays html. Parsing html file,
finds 10 referenced jpeg objects

time
6. Steps 1-5 repeated for each of 10
jpeg objects

8/10/2022 25
Non-Persistent HTTP: Response time
definition of RTT: time for a small
packet to travel from client to
server and back. initiate TCP
response time: connection

❖ one RTT to initiate TCP RTT

connection request
file
❖ one RTT for HTTP request and time to
RTT
first few bytes of HTTP transmit
response to return file
file

❖ file transmission time received


❖ Non-persistent HTTP response time
total = 2RTT+transmit time time time

8/10/2022 26
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 parallel ❖ subsequent HTTP messages
TCP connections to fetch between same
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

8/10/2022 27
HTTP request message
❖ two types of HTTP messages: request, response
❖ HTTP request message:
▪ ASCII (human-readable format) carriage return character
line-feed character
request line
(GET, POST, GET /index.html HTTP/1.1\r\n
HEAD commands) Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
header Accept-Language: en-us,en;q=0.5\r\n
lines Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
carriage return, Connection: keep-alive\r\n
line feed at start \r\n
of line indicates
end of header lines
8/10/2022 28
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

8/10/2022 29
Uploading form input
POST method:
❖ web page often
includes form input
❖ input is uploaded to
server in entity body
URL method:
❖ uses GET method
❖ input is uploaded in
URL field of request
line: www.somesite.com/animalsearch?monkeys&banana

8/10/2022 30
Method types

HTTP/1.0 HTTP/1.1
❖ GET ❖ GET, POST, HEAD
❖ POST ❖ PUT
❖ HEAD ▪ uploads file in entity
body to path specified
▪ asks server to leave
in URL field
requested object out of
response ❖ DELETE
▪ deletes file specified in
the URL field

8/10/2022 31
HTTP response message
status line
(protocol
status code HTTP/1.1 200 OK\r\n
status phrase) Date: Sun, 26 Sep 201020:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02
GMT\r\n
header ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
lines Content-Length:2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-
1\r\n
\r\n
data data data data data ...
data, e.g.,
requested
HTML file
8/10/2022 32
HTTP response status codes
❖ status code appears in 1st line in server->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
8/10/2022 33
Trying out HTTP (client side) for yourself

1. Telnet to your favorite Web server:

telnet cis.poly.edu 80 opens TCP connection to port 80


(default HTTP server port) at cis.poly.edu.
anything typed in sent
to port 80 at cis.poly.edu

2. type in a GET HTTP request:


GET /~ross/ HTTP/1.1 by typing this in (hit carriage
Host: cis.poly.edu return twice), you send
this minimal (but complete)
GET request to HTTP server

3. look at response message sent by HTTP server!


(or use Wireshark to look at captured HTTP request/response)
8/10/2022 34
User-server state: cookies

many Web sites use example:


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

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
8/10/2022 36
Web caches (proxy server)
goal: satisfy client request without involving origin server
• user sets browser: Web
accesses via cache
• browser sends all HTTP proxy
requests to cache server
client
origin
– object in cache: cache server
returns object
– else cache requests
object from origin
server, then returns
client
object to client origin
server

8/10/2022 38
More about Web caching

• cache acts as both why Web caching?


client and server
• reduce response time for
– server for original client request
requesting client
• reduce traffic on an
– client to origin institution’s access link
server
• Internet dense with
• typically cache is caches: enables “poor”
installed by ISP content providers to
(university, company, effectively deliver
residential ISP) content (so too does P2P
file sharing)
8/10/2022 39
Web Caching Example (1)
Assumptions: origin
• Avg object size: 1 Mbits servers
• Avg request rate from browsers to origin servers: 15 Public
request/sec Internet
• Avg data rate to browsers: 1.50 Mbps
• RTT from institutional router to any origin server: 2
sec
• Access link rate: 15 Mbps
15 Mbps
Consequences: access link
- (15 req/sec).(1 Mbits/req)/(100 Mbps) = 0.15 Institutional
- (15 req/sec).(1 Mbits/req)/(15 Mbps) = 1 network
100Mbps LAN
problem!
• Total delay = Internet delay + access delay + LAN
delay
= 2 sec + minutes + microseconds

8/10/2022 40
Web Caching Example (1)
Assumptions: origin
• Avg object size: 1 Mbits servers
• Avg request rate from browsers to origin servers: 15 Public
request/sec Internet
• Avg data rate to browsers: 1.50 Mbps
• RTT from institutional router to any origin server: 2
sec
• Access link rate: 15 Mbps = 100 Mbps
15 Mbps 100 Mbps
Consequences: access link
- (15 req/sec).(1 Mbits/req)/(100 Mbps) = 0.15 Institutional
- (15 req/sec).(1 Mbits/req)/(100 Mbps) = 0.15 network
• Total delay = Internet delay + access delay + LAN 100Mbps LAN
delay
= 2 sec + microseconds+ microseconds

Cost: increased access link speed (not cheap!)


8/10/2022 41
Web Caching Example (3)
Assumptions:
❖ Avg object size: 1 Mbits
❖ Avg request rate from browsers to origin origin
servers: 15/sec servers
❖ Avg data rate to browsers: 1.50 Mbps Public
❖ RTT from institutional router to any Internet
origin server: 2 sec
❖ Access link rate: 15 Mbps
Consequences: 15 Mbps
❖ LAN utilization: 0.15% access link
❖ ?
Access link utilization = 100%
❖ Total delay = Internet
? delay + access Institutional
delay + LAN delay network 100 Mbps LAN
= 2 sec + minutes + usecs
How to compute link Local web
utilization, delay? cache
Cost: Web cache (cheap!)
8/10/2022 42
Web Caching Example (4)
Calculating access link utilization, delay
with cache:
• Suppose cache hit rate is 0.4 origin
– 40% requests satisfied at cache, 60% servers
requests satisfied at origin Public
Internet

• Access link utilization:


– 60% of requests use access link
• Data rate to browsers over access 1.54 Mbps
link = 0.6*1.50 Mbps = 0.9 Mbps access link
– Utilization = 0.9/1.54 = 0.58
Institutional
• Total delay network 100 Mbps LAN
– = 0.6 * (delay from origin servers)
+0.4 * (delay when satisfied at cache) Local web
– = 0.6 .(2) + 0.4 (~msecs)
– = ~ 1.2 secs cache
– Less than with 15 Mbps link
(and cheaper too!)
8/10/2022 43
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with UDP and TCP

8/10/2022 45
FTP: the file transfer protocol
file transfer
FTP FTP FTP
user client server
interface
user
at host remote file
local file system
system

❖ transfer file to/from remote host


❖ client/server model
▪ client: side that initiates transfer (either to/from remote)
▪ server: remote host
❖ ftp: RFC 959
❖ ftp server: port 21

8/10/2022 46
FTP: separate control, data
connections
• FTP client contacts FTP server at TCP control connection,
port 21, using TCP server port 21

• client authorized over control


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

8/10/2022 2-47
FTP commands, responses
sample commands: sample return codes
• sent as ASCII text over • status code and phrase (as in
control channel HTTP)
• USER username • 331 Username OK,
• PASS password password required
• LIST return list of file in • 125 data connection
current directory already open;
• RETR filename transfer starting
retrieves (gets) file • 425 Can’t open data
• STOR filename stores connection
(puts) file onto remote • 452 Error writing
host
file

8/10/2022 48
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with TCP
2.8 Socket programming with UDP

8/10/2022 49
Electronic mail
outgoing
Three major components: user message queue
• user agents agent
user mailbox
• mail servers mail user
• simple mail transfer protocol: server agent
SMTP
SMTP mail user
User Agent server agent

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


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

8/10/2022 50
Electronic mail: mail servers
mail servers: user
agent
• mailbox contains incoming
messages for user mail user
server agent
• message queue of outgoing (to
be sent) mail messages SMTP mail user
• SMTP protocol between mail server agent
servers to send email SMTP
messages user
SMTP
• client: sending mail server mail
agent
• “server”: receiving mail server
server user
agent
user
agent

8/10/2022 51
Electronic Mail: SMTP [RFC 2821]

• uses TCP to reliably transfer email message from client to


server, port 25
• direct transfer: sending server to receiving server
• three phases of transfer
• handshaking (greeting)
• transfer of messages
• closure
• command/response interaction (like HTTP, FTP)
• commands:ASCII text
• response: status code and phrase
• messages must be in 7-bit ASCI

8/10/2022 52
Scenario: Alice sends message
to Bob
1) Alice uses UA to compose 4) SMTP client sends Alice’s
message “to” message over the TCP
[email protected] connection
2) Alice’s UA sends message to 5) Bob’s mail server places the
her mail server; message placed message in Bob’s mailbox
in message queue 6) Bob invokes his user agent to
3) client side of SMTP opens TCP read message
connection with Bob’s mail
server

1 user mail user


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

8/10/2022 2-54
Try SMTP interaction for
yourself:

• telnet servername 25
• see 220 reply from server
• enter HELO, MAIL FROM, RCPT TO, DATA, QUIT
commands

above lets you send email without using email client (reader)

8/10/2022 2-55
Mail access protocols
user
mail access user
SMTP SMTP protocol
agent agent
(e.g., POP,
IMAP)

sender’s mail receiver’s mail


server server

• SMTP: delivery/storage to receiver’s server


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

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

8/10/2022 58
Break Time

8/10/2022 59
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with TCP
2.8 Socket programming with UDP

8/10/2022 60
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,
implemented as application-
Q: how to map between IP layer protocol
address and name, and – complexity at network’s
vice versa ? “edge”
8/10/2022 61
DNS: Services, structure
DNS services Why not centralize DNS?
❖ hostname to IP ❖ single point of failure
address translation ❖ traffic volume
❖ host aliasing ❖ distant centralized
▪ Canonical, alias names database
❖ mail server aliasing ❖ maintenance
❖ load distribution
▪ replicated Web doesn’t scale!
servers: set of IP
addresses for one
canonical name

8/10/2022 62
DNS: Distributed, Hierarchical Database
Root DNS Servers
… …

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu


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

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


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

8/10/2022 63
DNS: Root name servers
• contacted by local name server that can not resolve name
• root name server:
– contacts authoritative name server if name mapping not known
– gets mapping
– returns mapping to local name server
c. Cogent, Herndon, VA (5 other sites)
d. U Maryland College Park, MD k. RIPE London (17 other sites)
h. ARL Aberdeen, MD
j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites)

e. NASA Mt View, CA m. WIDE Tokyo


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

a. Verisign, Los Angeles CA


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

8/10/2022 64
TLD 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.:
uk, fr, ca, jp
▪ Network Solutions maintains servers for com TLD
▪ Educause for edu TLD
Authoritative DNS servers:
▪ organization’s DNS servers, providing
authoritative hostname to IP mappings for
organization’s servers (e.g., Web, mail).
▪ can be maintained by organization or service
provider
8/10/2022 65
Local DNS name server

• does not strictly belong to hierarchy


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

8/10/2022 2-66
DNS name resolution example
root DNS server

• host at cis.poly.edu 2
3
wants IP address for TLD DNS server
4
gaia.cs.umass.edu
5
iterated query: local DNS server
❖ contacted server dns.poly.edu
replies with name of 7 6
server to contact 1 8
❖ “I don’t know this
name, but ask this authoritative DNS server
server” requesting host
dns.cs.umass.edu

cis.poly.edu

gaia.cs.umass.edu
8/10/2022 67
DNS name resolution example
root DNS server

recursive query:
❖ puts burden of name 2 3
resolution on
contacted name 7 6
server TLD DNS server
❖ heavy load?
local DNS server
dns.poly.edu 5 4

1 8

authoritative DNS server


dns.cs.umass.edu
requesting host
cis.poly.edu

8/10/2022 gaia.cs.umass.edu 68
DNS records

DNS: distributed db storing resource records (RR)


RR format: (name, value, type, ttl)

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

8/10/2022 2-69
DNS protocol, messages
• query and reply messages, both with same message format
2 bytes 2 bytes

msg header identification flags


❖ identification: 16 bit # for query, # questions # answer RRs
reply to query uses same #
❖ flags: # authority RRs # additional RRs
▪ query or reply
▪ recursion desired questions (variable # of questions)
▪ recursion available
▪ reply is authoritative
answers (variable # of RRs)

authority (variable # of RRs)

additional info (variable # of RRs)

8/10/2022 2-70
DNS protocol, messages

2 bytes 2 bytes

identification flags

# questions # answer RRs

# authority RRs # additional RRs

name, type fields


questions (variable # of questions)
for a query
RRs in response answers (variable # of RRs)
to query
records for
authority (variable # of RRs)
authoritative servers
additional “helpful” additional info (variable # of RRs)
info that may be used
8/10/2022 2-71
Inserting records into DNS
• example: new startup “Network Utopia”
• register name networkuptopia.com at DNS registrar (e.g.,
Network Solutions)
• provide names, IP addresses of authoritative name server (primary
and secondary)
• registrar inserts two RRs into .com TLD server:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
• create authoritative server type A record for
www.networkuptopia.com; type MX record for
networkutopia.com

8/10/2022 2-72
Attacking DNS
DDoS attacks Redirect attacks
• Bombard root servers • Man-in-middle
with traffic • Intercept queries
• Not successful to date • DNS poisoning
• Traffic Filtering • Send bogus relies to DNS
• Local DNS servers cache server, which caches
IPs of TLD servers, Exploit DNS for DDoS
allowing root server
bypass • Send queries with
• Bombard TLD servers spoofed source address:
• Potentially more
target IP
dangerous • Requires amplification
8/10/2022 2-73
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with TCP
2.8 Socket programming with UDP

8/10/2022 74
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)

8/10/2022 75
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

8/10/2022 76
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
ui
• time to send N copies: NF/us

❖ 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
client-server approach Dc-s > max{NF/us,,F/dmin}

increases linearly in N
8/10/2022 77
File distribution time: P2P
• server transmission: must upload
F
at least one copy us
• time to send one copy: F/us di
network
❖ client: each client must ui
download file copy
▪ min client download time: F/dmin
❖ clients: as aggregate must download NF bits
▪ max upload rate (limting max download rate) is us + Sui
time to distribute F
to N clients using
P2P approach
DP2P > max{F/us,,F/dmin,,NF/(us + Sui)}

increases linearly in N …
… but so does this, as each peer brings service capacity
8/10/2022
78
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
8/10/2022 79
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 list
of peers from tracker
… and begins exchanging
file chunks with peers in torrent

8/10/2022 80
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
8/10/2022 81
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
▪ other peers are choked by Alice
• periodically, Alice asks each (do not receive chunks from her)
peer for list of chunks that ▪ re-evaluate top 4 every10 secs
they have ❖ every 30 secs: randomly select
• Alice requests missing another peer, starts sending
chunks from peers, rarest chunks
first ▪ “optimistically unchoke” this peer
▪ newly chosen peer may join top 4

8/10/2022 82
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 !

8/10/2022 83
Outline
2.1 Principles of network applications
2.2 Web and HTTP
2.3 FTP
2.4 Electronic Mail (SMTP, POP3, IMAP)
2.5 DNS
2.6 P2P Applications
2.7 Socket programming with UDP and TCP

8/10/2022 84
2.7 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

8/10/2022 85
2.7 Socket programming
Two socket types for two transport services:
– UDP: unreliable datagram
– TCP: reliable, byte stream-oriented
Application Example:
1. Client reads a line of characters (data) from its
keyboard and sends the data to the server.
2. The server receives the data and converts characters
to uppercase.
3. The server sends the modified data to the client.
4. The client receives the modified data and displays the
line on its screen.
8/10/2022 86
Socket programming with UDP
UDP: no “connection” between client & server
• no handshaking before sending data
• sender explicitly attaches IP destination address and port # to
each packet
• rcvr extracts sender IP address and port# from received packet

UDP: transmitted data may be lost or received


out-of-order
Application viewpoint:
• UDP provides unreliable transfer of groups of bytes
(“datagrams”) between client and server

8/10/2022 87
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

8/10/2022 88
Example app: UDP client
Python UDPClient.py
include Python’s socket
library
from socket import *
serverName = ‘hostname’
serverPort = 12000
create UDP socket for clientSocket = socket(socket.AF_INET,
server

get user keyboard


socket.SOCK_DGRAM)
input message = raw_input(’Input lowercase sentence:’)
Attach server name, port to
message; send into socket clientSocket.sendto(message,(serverName, serverPort))
read reply characters from modifiedMessage, serverAddress =
socket into string
clientSocket.recvfrom(2048)
print out received string print modifiedMessage
and close socket
clientSocket.close()
8/10/2022 89
Example app: UDP server
Python UDPServer
from socket import *
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 1:
Read from UDP socket into message, clientAddress = serverSocket.recvfrom(2048)
message, getting client’s
address (client IP and port) modifiedMessage = message.upper()
send upper case string serverSocket.sendto(modifiedMessage, clientAddress)
back to this client

8/10/2022 90
Socket-programming using TCP
Socket: a door between application process and end-
end-transport protocol (UCP or TCP)
TCP service: reliable transfer of bytes from one
process to another

controlled by
controlled by process application
application process
developer
developer socket socket
TCP with TCP with controlled by
controlled by
operating buffers, buffers, operating
internet variables system
system variables

host or host or
server server

8/10/2022 91
Socket programming
client must contact server
with

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

8/10/2022 93
Client/server socket interaction: TCP

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

8/10/2022 95
Example app: TCP server
Python TCPServer
from socket import *
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 1:
server waits on accept()
for incoming requests, new
connectionSocket, addr = serverSocket.accept()
socket created on return

sentence = connectionSocket.recv(1024)
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) connectionSocket.close()

8/10/2022 96
Chapter 2: Summary
our study of network apps now complete!
• application architectures ❖ specific protocols:
– client-server ▪ HTTP
– P2P ▪ FTP
▪ SMTP, POP, IMAP
• application service requirements: ▪ DNS
▪ P2P: BitTorrent, DHT
– reliability, bandwidth, delay

• Internet transport service model ❖ socket programming:


TCP, UDP sockets
– connection-oriented, reliable: TCP
– unreliable, datagrams: UDP

8/10/2022 97
Chapter 2: summary
most importantly: learned about protocols!

• typical request/reply message important themes:


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

8/10/2022 98
Additional Slides
application
packet (www browser,

analyzer email client)


application

OS
packet Transport (TCP/UDP)
copy of all Network (IP)
capture Ethernet
frames Link (Ethernet)
(pcap) sent/receive
d Physical

8/10/2022 99
Exercises
❑ Ex1. You use Wireshark to investigate and explore several aspects
of the HTTP protocol:
▪ the basic GET/reply interaction,
▪ HTTP message formats,
▪ retrieving large HTML files,
▪ retrieving HTML files with embedded URLs,
▪ persistent and non-persistent connections,
▪ and HTTP authentication and security

8/10/2022 100

You might also like