3rd Edition: Chapter 2
Computer Networking: A Top Down Approach
Copyright By PowCoder代写 加微信 powcoder
7th edition
April 2016
Application Layer
The Powerpoint slides are from Kurose and Ross’s book’s website.
Application Layer
Chapter 2: outline
2.1 principles of network applications
2.2 Web and HTTP
2.3 electronic mail
SMTP, POP3, IMAP
2.7 socket programming with UDP and TCP
Application Layer
Chapter 2: application layer
our goals:
conceptual, implementation aspects of Internet application protocols
client-server paradigm
transport-layer service models
learn about protocols by examining popular application-level protocols
SMTP / POP3 / IMAP
programming network applications
socket API
Application Layer
Some Internet apps
text messaging
remote login
P2P file sharing
multi-user network games
streaming stored video (YouTube, Netflix)
voice over IP (e.g., Skype)
real-time video conferencing
social networking
Application Layer
Creating an Internet app
need to write programs that:
run on (different) end systems
communicate over network
e.g., browser software communicates with web server software
no need to write software for network-core devices
network-core devices do not run user applications
writing applications on end systems allows for rapid app development
application
application
application
Application Layer
Application architectures
possible application structures:
client-server
peer-to-peer (P2P)
Application Layer
Client-server architecture
always-on host
permanent IP address
communicate with server
may be intermittently connected
may have dynamic IP addresses
do not communicate directly with each other
client/server
Application Layer
P2P architecture
no permanent always-on server
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
need complex management
Application Layer
Inter-process communication
process: program running in a host
within same host, two processes can communicate using inter-process communication (defined by OS)
processes in different hosts communicate by exchanging messages
client process: process that initiates communication
server process: process that waits to be contacted
aside: applications with P2P architecture have both client processes and server processes
clients, servers
Application Layer
process sends/receives messages to/from its socket
socket analogous to door
sending process pushes message out door
sending process relies on transport service out of the door to deliver message to door at receiving process
controlled
controlled by
app developer
application
application
Application Layer
Addressing processes
to receive messages, process must have identifier
host device has unique 32-bit IP address
IP address of a host cannot identify a process which runs on the host
many processes can be running on same host
identifier includes both IP address and port numbers associated with process on host
example port numbers:
HTTP server: 80
mail server: 25
to send HTTP message to comp.polyu.edu.hk web server:
IP address: 158.132.10.2
port number: 80
Application Layer
What transport service does an app need?
some apps (e.g., file transfer, stock transaction) require 100% reliable data transfer
some other apps (e.g., audio) can tolerate some loss
delay sensitive
some apps (e.g., Internet telephony, interactive games) require low delay to be usable
some other apps (e.g., e-mail) don’t care
some apps (e.g., video) require minimum bandwidth to be usable
some other apps (e.g., web) make use of whatever bandwidth they get
Application Layer
Transport service requirements: common apps
application
file transfer
Web documents
real-time audio/video
stored audio/video
interactive games
text messaging
loss-tolerant
loss-tolerant
loss-tolerant
audio: 5kbps-1Mbps
video:10kbps-5Mbps
same as above
few kbps up
delay sensitive
yes, 100’s ms
yes, few secs
yes, 100’s ms
yes and no
Application Layer
Internet transport layer services
TCP service:
connection-oriented: setup is required between client and server processes
reliable data transfer between sending and receiving processes
flow control: sender won’t overwhelm receiver
congestion control: throttle sender when network overloaded
does not provide: timing, minimum bandwidth guarantee
UDP service:
unreliable data transfer between sending and receiving processes
does not provide:
reliability,
flow control,
congestion control,
bandwidth guarantee,
or connection setup
Q: why bother? Why is there a UDP?
Application Layer
Internet apps: application / transport layer protocols
application
remote terminal access
file transfer
streaming multimedia
Internet telephony
application
layer protocol
SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
HTTP (e.g., YouTube),
RTP [RFC 1889]
SIP, RTP, proprietary
(e.g., Skype)
Underlying transport layer protocol
TCP or UDP
TCP or UDP
Application Layer
Chapter 2: outline
2.1 principles of network applications
2.2 Web and HTTP
2.3 electronic mail
SMTP, POP3, IMAP
2.7 socket programming with UDP and TCP
Application Layer
Web and HTTP
First, some terms…
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 (Uniform Resource Locator), e.g.,
www.someschool.edu/someDept/pic.gif
Application Layer
HTTP overview
HTTP: hypertext transfer protocol
Web’s application layer protocol
client/server model
client: browser that requests / receives (using HTTP protocol), and displays Web objects
server: Web server sends objects (using HTTP protocol) in response to client’s requests
two types of messages: request, response
PC running
Firefox browser
Apache Web
iPhone running
Safari browser
HTTP request
HTTP response
HTTP request
HTTP response
Application Layer
HTTP overview
client initiates TCP connection (creates socket) to server, port 80
server accepts TCP connection from client
HTTP messages (application-layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server)
TCP connection closed
HTTP is “stateless”
server maintains no information about past client requests
protocols that maintain “state” are complex!
past history (state) must be maintained
if server/client crashes, their views of “state” may be inconsistent, must be reconciled
Application Layer
HTTP connections
non-persistent HTTP
at most one object sent over TCP connection
TCP connection then closed
downloading multiple objects requires multiple connections
persistent HTTP
multiple objects can be sent over single TCP connection between client and server
Application Layer
Non-persistent HTTP
suppose user enters URL:
1a. HTTP client initiates TCP connection to HTTP server (process) at www.someSchool.edu on port 80
2. HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object someDepartment/home.index
1b. HTTP server at host www.someSchool.edu waiting for TCP connection at port 80. “accepts” connection, notifies client
3. HTTP server receives request message, forms response message containing requested object, and sends message into its socket
(contains text,
references to 10
jpeg images)
www.someSchool.edu/someDepartment/home.index
Application Layer
Non-persistent HTTP (cont’d)
5. HTTP client receives response message containing html file, displays html; further parses html file, finds 10 referenced jpeg objects
6. Steps 1-5 repeated for each of 10 jpeg objects
4. HTTP server closes TCP connection.
Application Layer
Non-persistent HTTP: response time
RTT (round-trip time): time for a small packet to travel from client to server and back
HTTP response time:
one RTT to initiate TCP connection
one RTT for HTTP request and first few bytes of HTTP response to return
file transmission time
initiate TCP
connection
non-persistent HTTP response time = 2RTT+ file transmission time
Application Layer
Persistent HTTP
non-persistent HTTP issues:
requires 2 RTTs per object
overhead for each TCP connection
browsers often open parallel TCP connections to fetch referenced objects
persistent HTTP:
server leaves connection open after sending response
subsequent HTTP messages between same 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
Application Layer
HTTP request message
HTTP request message:
ASCII (human-readable format)
Application Layer
header field name
header field name
entity body
HTTP request message (example)
request line
(GET, POST,
HEAD commands)
carriage return,
line feed at start
of line indicates
end of header lines
GET /index.html HTTP/1.1\r\n
Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
carriage return character
line-feed character
Application Layer
Uploading form input
POST method:
web page can include form input
input is uploaded to server in entity body
URL method:
uses GET method
input is uploaded in URL field of request line:
www.somesite.com/animalsearch?monkeys&banana
Application Layer
Method types
asks server to leave requested object out of response
GET, POST, HEAD
uploads file in entity body to path specified in URL field
deletes file specified in the URL field
Application Layer
HTTP response message
status line
status code
status phrase)
data, e.g.,
HTTP/1.1 200 OK\r\n
Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n
ETag: “17dc6-a5c-bf716880″\r\n
Accept-Ranges: bytes\r\n
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
data data data data data …
Application Layer
HTTP response status codes
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
status code appears in 1st line in server-to-client response message.
some sample codes:
Application Layer
User-server state: cookies
many Web sites use cookies
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
Susan always access Internet from PC
visits specific e-commerce site for first time
when initial HTTP request arrives at site, site creates:
entry in back-end database for ID
Application Layer
Cookies: keeping “state”
usual http response msg
usual http response msg
cookie file
one week later:
usual http request msg
cookie: 1678
usual http request msg
Amazon server
creates ID
1678 for user
usual http response
set-cookie: 1678
amazon 1678
usual http request msg
cookie: 1678
amazon 1678
Application Layer
what cookies can be used for:
authorization
shopping carts
recommendations
user session state (Web e-mail)
cookies and privacy:
cookies permit sites to learn a lot about you
you may supply name and e-mail to sites
how to keep “state”:
protocol endpoint entities: maintain state at sender/receiver over multiple transactions
cookies: http messages carry state
Application Layer
Web caches (proxy server)
user sets browser: Web accesses via cache
browser sends all HTTP requests to cache
object found in cache: cache returns object
else (object not found in cache): cache requests object from origin server, then returns object to client
goal: satisfy client request without involving origin server
HTTP request
HTTP response
HTTP request
HTTP request
HTTP response
HTTP response
Application Layer
More about Web caching
cache acts as both client and server
server for original requesting client
client to origin server
typically cache is installed by ISP (university, company, residential ISP)
why Web caching?
reduce response time for client request
reduce traffic on an institution’s access link
Internet dense with caches: enables “poor” content providers to effectively deliver content (so does P2P file sharing)
Application Layer
Caching example:
institutional
100Mbps LAN
access link
assumptions:
avg object size: 1M bits
avg request rate from browsers to origin servers:15/sec
avg data rate to browsers: 15 Mbps
RTT from institutional router to any origin server: 2 sec
access link rate: 15 Mbps
consequences:
LAN utilization: 15%
access link utilization = 100%
total delay
= Internet delay + access delay + LAN delay
= 2 sec + minutes + msecs
Application Layer
assumptions:
avg object size: 1M bits
avg request rate from browsers to origin servers:15/sec
avg data rate to browsers: 15 Mbps
RTT from institutional router to any origin server: 2 sec
access link rate: 15 Mbps
consequences:
LAN utilization: 15%
access link utilization = 100%
total delay = Internet delay + access delay + LAN delay
= 2 sec + minutes + msecs
Caching example: wider access link
access link
Cost: increased access link speed (not cheap!)
institutional
100 Mbps LAN
Application Layer
institutional
100Mbps LAN
Caching example: install local cache
access link
assumptions:
avg object size: 1M bits
avg request rate from browsers to origin servers:15/sec
avg data rate to browsers: 15 Mbps
RTT from institutional router to any origin server: 2 sec
access link rate: 15 Mbps
consequences:
LAN utilization: 15%
access link utilization = 100%
total delay = Internet delay + access delay + LAN delay
= 2 sec + minutes + usecs
How to compute link
utilization, delay?
Cost: web cache (cheap!)
Application Layer
Caching example: install local cache
Calculating access link utilization, delay with cache:
suppose cache hit rate is 0.4
40% requests satisfied at cache, 60% requests satisfied at origin
access link
access link utilization:
60% of requests use access link
data rate to browsers over access link
= 0.6*15 Mbps = 9 Mbps
utilization = 9/15 = 60%
total delay
= 0.6 * (delay from origin servers) +0.4 * (delay when satisfied at cache)
= 0.6 (2.01) + 0.4 (~msecs) = ~ 1.2 secs
less than with 150 Mbps access link (and cheaper too!)
institutional
100Mbps LAN
Application Layer
Conditional GET
Goal: don’t send object if cache has up-to-date cached version
no object transmission delay
lower down link usage
cache: specify date of cached copy in HTTP request
If-modified-since:
server: response contains no object if cached copy is up-to-date:
HTTP/1.0 304 Not Modified
HTTP request msg
If-modified-since:
HTTP response
304 Not Modified
HTTP request msg
If-modified-since:
HTTP response
HTTP/1.0 200 OK
Application Layer
Chapter 2: outline
2.1 principles of network applications
2.2 Web and HTTP
2.3 electronic mail
SMTP, POP3, IMAP
2.7 socket programming with UDP and TCP
Application Layer
Electronic mail
Three major components:
user agents
mail servers
simple mail transfer protocol: SMTP
User Agent
a.k.a. “mail reader”
composing, editing, reading mail messages
e.g., Outlook, Thunderbird, iPhone mail client
outgoing, incoming messages stored on server
user mailbox
message queue
Application Layer
Electronic mail: mail servers
mail servers:
mailbox contains incoming messages for user
message queue of outgoing (to be sent) mail messages
SMTP protocol between mail servers to send email messages
client: sending mail server
“server”: receiving mail server
Application Layer
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
command/response interaction (like HTTP)
commands: ASCII text
response: status code and phrase
messages must be in 7-bit ASCII
Application Layer
Scenario: Alice sends message to Bob
1) Alice uses UA to compose message “to”
2) Alice’s UA sends message to her mail server; message placed in message queue
3) client side of SMTP opens TCP connection with Bob’s mail server
4) SMTP client sends Alice’s message over the TCP connection
5) Bob’s mail server places the message in Bob’s mailbox
6) Bob invokes his user agent to read message
Alice’s mail server
Bob’s mail server
Application Layer
Sample SMTP interaction
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM:
S: 250 Sender ok
C: RCPT TO:
S: 250 … Recipient ok
S: 354 Enter mail, end with “.” on a line by itself
C: Do you like ketchup?
C: How about pickles?
S: 250 Message accepted for delivery
S: 221 hamburger.edu closing connection
Application Layer
SMTP: final words
SMTP uses persistent connections
SMTP requires message (header & body) to be in 7-bit ASCII
SMTP server uses CRLF.CRLF to determine end of message
comparison with HTTP:
HTTP: pull
SMTP: push
both have ASCII command/response interaction, status codes
HTTP: each object encapsulated in its own response message
SMTP: multiple objects sent in multipart message
Application Layer
Mail message format
SMTP: protocol for exchanging email messages
RFC 822: standard for text message format:
header lines, e.g.,
different from SMTP
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com