0% found this document useful (0 votes)
13 views12 pages

03-Phil and Apps

The document provides an overview of a lecture about applications and application-layer protocols. It discusses client-server applications, application requirements like data loss, timing, and bandwidth needs, and how servers and clients exchange messages over a network through sockets and ports.

Uploaded by

Pedro Lopes
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)
13 views12 pages

03-Phil and Apps

The document provides an overview of a lecture about applications and application-layer protocols. It discusses client-server applications, application requirements like data loss, timing, and bandwidth needs, and how servers and clients exchange messages over a network through sockets and ports.

Uploaded by

Pedro Lopes
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
You are on page 1/ 12

Lecture Overview

• Last time:
• Protocol stacks and layering
15-441: Computer Networking • OSI and TCP/IP models

• Application requirements

Lecture 3: Design Philosophy & • Application examples


Applications • ftp
• http

• Internet Architecture & Performance intro


Copyright © CMU, 2007-2011. F' 11 Lecture 3: Applications 2

Applications and Application-Layer


Protocols Client-Server Paradigm
• Application: communicating, Typical network app has two pieces: client and server
distributed processes application
transport Client:
network
• Running in network hosts in data link • Initiates contact with server application
transport
physical
“user space” (“speaks first”) network
data link

• Exchange messages to • Typically requests service from


physical

implement app server, request


• e.g., email, file transfer, the • For Web, client is implemented in
Web browser; for e-mail, in mail
reader
• Application-layer protocols
• One “piece” of an app application
application Server: reply
transport
• Define messages exchanged
transport
network
network • Provides requested service to application
data link
by apps and actions taken
data link
physical
physical client transport
network

• e.g., Web server sends data link


physical
requested Web page, mail server
delivers e-mail
F' 11 Lecture 3: Applications 3 F' 11 Lecture 3: Applications 4

1
Aside: "Client-Server" does not Server and Client
mean "Local-Remote"
Server and Client exchange messages over the
Case in point: network through a common Socket API
• X Windows Server Clients
• Basis for Linux Desktops user
Server
ports space
• Runs on local machine (attached
to keyboard, mouse, screen)
• Clients are application programs
• Clients can be remote TCP/UDP TCP/UDP
Socket API kernel
space
• Servers typically:
• are shared IP IP
• manage resources
• are contacted by client Ethernet Adapter Ethernet Adapter hardware

F' 11 Lecture 3: Applications 5 F' 11 Lecture 3: Applications 6

Network Addressing Analogy What Service Does an


Application Need?
Telephone Call Network Programming Data loss Timing
nuclear plants?
Professors at CMU Applications/Servers • Some apps (e.g., audio) can • Some apps (e.g., Internet
tolerate some loss telephony, interactive
412-268-8000 412-268-8000
ext.123 ext.654 Web Mail games) require low delay to
• Other apps (e.g., file transfer,
Port 80 Port 25 be “effective”
telnet) require 100% reliable
Extension Port No. data transfer

Telephone No IP Address Bandwidth


Area Code Network No. • Some apps (e.g., multimedia) require minimum amount of
Exchange Host Number bandwidth to be “effective”
Central Number • Other apps (“elastic apps”) make use of whatever bandwidth they
get
15-441 Students Clients

F' 11 Lecture 3: Applications 7 F' 11 Lecture 3: Applications 8

2
Transport Service Requirements Other Requirements
of Common Apps
Application Data loss Bandwidth Time Sensitive • Network reliability
• Network service must always be available
file transfer no loss elastic no
e-mail no loss elastic no
• Security: privacy, denial of service,
web documents no loss elastic no authentication, …
interactive loss-tolerant audio: 5Kb-1Mb yes, 100’s msec
audio/video (often) video:10Kb-5Mb • Scalability.
non-interactve loss-tolerant same as above yes, few secs • Scale to large numbers of users, traffic flows, …
audio/video (sometimes)
interactive games loss-tolerant few Kbps yes, 100’s msec • Manageability: monitoring, control, …
financial apps no loss elastic yes and no: µs?

F' 11 Lecture 3: Applications 9 F' 11 Lecture 3: Applications 10

User Datagram Protocol (UDP): Transmission Control Protocol


An Analogy (TCP): An Analogy
UDP Postal Mail
Postal Mail TCP Telephone Call
• Single socket to receive • Single mailbox to receive • Reliable – guarantee
messages letters • Guaranteed delivery
messages delivery
• No guarantee of delivery • Unreliable ! • In-order delivery
• Byte stream – in-order
• Not necessarily in-order • Not necessarily in-order delivery • Connection-oriented
delivery delivery • Connection-oriented – • Setup connection
• Datagram – independent • Letters sentisindependently
Each letter independent single socket per followed by
packets •• Must
Must address each
address each letter connection
reply conversation
• Must address each packet • Setup connection
followed by data transfer

Example UDP applications Example TCP applications


Multimedia, voice over IP Web, Email, Telnet
F' 11 Lecture 3: Applications 11 F' 11 Lecture 3: Applications 12

3
FTP: The File Transfer Protocol Ftp: Separate Control, Data
Connections

• Ftp client contacts ftp server at


FTP file transfer port 21, specifying TCP as
FTP FTP
user client server transport protocol
interface
user • Two parallel TCP connections TCP control connection
at host local file remote file port 21
system
opened:
system
• Control: exchange commands,
responses between client, server.
TCP data connection
• Transfer file to/from remote host “out of band control” FTP FTP
port 20
• Client/server model • Data: file data to/from server client server
• Client: side that initiates transfer (either to/from remote) • Ftp server maintains “state”:
• Server: remote host current directory, earlier
• ftp: RFC 959 authentication
• ftp server: port 21

F' 11 Lecture 3: Applications 13 F' 11 Lecture 3: Applications 14

Ftp Commands, Responses HTTP Basics

Sample Commands: Sample Return Codes • HTTP layered over bidirectional byte stream
• sent as ASCII text over control • status code and phrase • Almost always TCP
channel • 331 Username OK, • Interaction
• USER username password required • Client sends request to server, followed by response from server to
• PASS password • 125 data connection client
• LIST return list of files in
already open; transfer • Requests/responses are encoded in text
starting
current directory • Stateless
• 425 Can’t open data
• RETR filename retrieves • Server maintains no information about past client requests
connection
(gets) file
• 452 Error writing file
• STOR filename stores (puts)
file onto remote host

F' 11 Lecture 3: Applications 15 F' 11 Lecture 3: Applications 16

4
How to Mark End of Message? HTTP Request

• Size of message " Content-Length


• Must know size of transfer in advance
• Delimiter " MIME style Content-Type
• Server must “escape” delimiter in content
• Close connection
• Only server can do this

F' 11 Lecture 3: Applications 17 F' 11 Lecture 3: Applications 18

HTTP Request HTTP Request

• Request line • Request headers


• Method • Authorization – authentication info
• GET – return URI • Acceptable document types/encodings
• HEAD – return headers only of GET response • From – user email
• POST – send data to the server (forms, etc.) • If-Modified-Since
• URI • Referrer – what caused this page to be requested
• E.g. http://www.intel-iris.net/index.html with a proxy • User-Agent – client software
• E.g. /index.html if no proxy • Blank-line
• HTTP version
• Body

F' 11 Lecture 3: Applications 19 F' 11 Lecture 3: Applications 20

5
HTTP Request Example HTTP Response

GET / HTTP/1.1 • Status-line


• HTTP version
Accept: */* • 3 digit response code
Accept-Language: en-us • 1XX – informational
• 2XX – success
Accept-Encoding: gzip, deflate • 200 OK

User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) • 3XX – redirection


• 301 Moved Permanently
Host: www.intel-iris.net •

303 Moved Temporarily
304 Not Modified
Connection: Keep-Alive • 4XX – client error
• 404 Not Found
• 5XX – server error
• 505 HTTP Version Not Supported
• Reason phrase

F' 11 Lecture 3: Applications 21 F' 11 Lecture 3: Applications 22

HTTP Response HTTP Response Example


• Headers HTTP/1.1 200 OK
• Location – for redirection Date: Tue, 27 Mar 2001 03:49:38 GMT
• Server – server software Server: Apache/1.3.14 (Unix) (Red-Hat/Linux) mod_ssl/2.7.1 OpenSSL/0.9.5a
• WWW-Authenticate – request for authentication DAV/1.0.2 PHP/4.0.1pl2 mod_perl/1.24
• Allow – list of methods supported (get, head, etc) Last-Modified: Mon, 29 Jan 2001 17:54:18 GMT
• Content-Encoding – E.g x-gzip ETag: "7a11f-10ed-3a75ae4a"
• Content-Length
Accept-Ranges: bytes
• Content-Type
Content-Length: 4333
• Expires
• Last-Modified Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
• Blank-line
Content-Type: text/html
• Body
…..

F' 11 Lecture 3: Applications 23 F' 11 Lecture 3: Applications 24

6
Cookies: Keeping “state” Cookies: Keeping “State”
client Amazon server
Many major Web sites use Cookie file usual http request msg en
server da try
cookies usual http response + creates ID ta in
ba ba
ebay: 8734 se ck
Four components: Example: Set-cookie: 1678 1678 for user en
d
1) Cookie header line in the • Susan accesses Internet
HTTP response message always from same PC Cookie file
2) Cookie header line in HTTP
usual http request msg
• She visits a specific e- amazon: 1678 cookie-
request message cookie: 1678 ess
commerce site for the first ebay: 8734 specific acc
3) Cookie file kept on user’s time usual http response msg
host and managed by user’s
action

ss
• When initial HTTP requests
one week later:

ce
browser arrives at site, site creates a

ac
4) Back-end database at Web unique ID and creates an usual http request msg
Cookie file cookie-
site entry in backend database
cookie: 1678
for ID amazon: 1678 specific
ebay: 8734 usual http response msg action

F' 11 Lecture 3: Applications 25 F' 11 Lecture 3: Applications 26

HTTP 1.1 - new features Packet Delay

• Newer versions of HTTP add several new


features (persistent connections, pipelined
Prop + xmit
transfers) to speed things up.
2*(Prop + xmit)
• Let’s detour into some performance Store & Forward

evaluation and then look at those features Cut-through


2*prop + xmit

When does cut-through matter?


Next: Routers have finite speed (processing delay)
Routers may buffer packets (queueing delay)
F' 11 Lecture 3: Applications 27 F' 11 Lecture 3: Applications 28

7
Packet Delay A Word about Units

• Sum of a number of different delay components. • What do “Kilo” and “Mega” mean?
• Propagation delay on each link. • Depends on context
• Proportional to the length of the link
• Transmission delay on each link. • Storage works in powers of two.
• Proportional to the packet size and 1/link speed
• Processing delay on each router.
• 1 Byte = 8 bits
• Depends on the speed of the router • 1 KByte = 1024 Bytes
• Queuing delay on each router. • 1 MByte = 1024 Kbytes
• Depends on the traffic load and queue size
• Networks work in decimal units.
• Network hardware sends bits, not Bytes
D B C B A A • 1 Kbps = 1000 bits per second
• To avoid confusion, use 1 Kbit/second
• Why? Historical: CS versus ECE.
F' 11 Lecture 3: Applications 29 F' 11 Lecture 3: Applications 30

Application-level Delay Some Examples

• How long does it take to send a 100 Kbit file?


• Assume a perfect world
• And a 100
10 Kbit
Kbitfile
file

Delay of
one packet Size Throughput
100 Kbit/s 1 Mbit/s 100 Mbit/s
Delay* + Latency
Throughput
Average
500 µsec 1.0005
0.1005 0.1005
0.0105 0.0015
0.0006
sustained
throughput 10 msec 1.01
0.11 0.11
0.02 0.0101
0.011
Units: seconds +
bits/(bits/seconds) 100 msec 1.1
0.2 0.11
0.2 0.1001
0.101
* For minimum sized packet
F' 11 Lecture 3: Applications 31 F' 11 Lecture 3: Applications 32

8
Some Examples Some Examples

• How long does it take to send a 100 Kbit file? • How long does it take to send a 10 Kbit file?
• Assume a perfect world • Assume a perfect world
• And a 100 Kbit file • And a 10 Kbit file

Throughput Throughput
Latency 100 Kbit/s 1 Mbit/s 100 Mbit/s Latency 100 Kbit/s 1 Mbit/s 100 Mbit/s
500 µsec 1.0005 0.1005 0.0015 500 µsec 1.0005
0.1005 0.1005
0.0105 0.0015
0.0006
10 msec 1.01 0.11 0.011 10 msec 1.01
0.11 0.11
0.02 0.0101
0.011
100 msec 1.1 0.2 0.101 100 msec 1.1
0.2 0.11
0.2 0.1001
0.101

F' 11 Lecture 3: Applications 33 F' 11 Lecture 3: Applications 34

Sustained Throughput One more detail: TCP

• When streaming packets, the network works like • TCP connections need to be set up
a pipeline. • “Three Way Handshake”:
• All links forward different packets in parallel
• Throughput is determined by the slowest stage. Client Server
• Called the bottleneck link
SYN (Synchronize)
• Does not really matter why the link is slow.
• Low link bandwidth
• Many users sharing the link bandwidth SYN/ACK (Synchronize + Acknowledgement)

ACK
50 …Data…
37 30 104 59 17 267
• TCP transfers start slowly and then ramp up the bandwidth
used (so they don’t use too much)

F' 11 Lecture 3: Applications 35 F' 11 Lecture 3: Applications 36

9
HTTP 0.9/1.0 Single Transfer Example

• One request/response per TCP connection Client Server


0 RTT SYN
• Simple to implement SYN
Client opens TCP
1 RTT
• Disadvantages connection
DAT
ACK
Client sends HTTP request Server reads from
• Multiple connection setups " three-way handshake each time ACK
for HTML DAT disk
FIN
• Several extra round trips added to transfer 2 RTT
ACK
• Multiple slow starts Client parses HTML FIN
Client opens TCP ACK
connection SYN

SYN
3 RTT ACK
Client sends HTTP request DAT
for image Server reads from
ACK disk
4 RTT
DAT
Image begins to arrive

F' 11 Lecture 3: Applications 37 F' 11 Lecture 3: Applications 38

Performance Issues Netscape Solution

• Short transfers are hard on TCP • Mosaic (original popular Web browser) fetched
• Stuck in slow start one object at a time!
• Loss recovery is poor when windows are small • Netscape uses multiple concurrent
• Lots of extra connections connections to improve response time
• Different parts of Web page arrive independently
• Increases server state/processing
• Can grab more of the network bandwidth than other
• Servers also hang on to connection state users
after the connection is closed • Doesn’t necessarily improve response time
• Why must server keep these? • TCP loss recovery ends up being timeout
• Tends to be an order of magnitude greater than dominated because windows are small
# of active connections, why?
F' 11 Lecture 3: Applications 39 F' 11 Lecture 3: Applications 40

10
Persistent Connection Solution Persistent Connection Solution

• Multiplex multiple transfers onto one TCP Server


connection Client
0 RTT
DAT
• How to identify requests/responses Client sends HTTP request
for HTML
ACK Server reads from
disk
DAT
• Delimiter " Server must examine response for delimiter string
1 RTT ACK
• Content-length and delimiter " Must know size of transfer in
advance Client parses HTML DAT
Server reads from
• Block-based transmission " send in multiple length delimited Client sends HTTP request ACK DAT disk
for image
blocks
• Store-and-forward " wait for entire response and then use 2 RTT
content-length Image begins to arrive
• Solution " use existing methods and close connection otherwise

F' 11 Lecture 3: Applications 41 F' 11 Lecture 3: Applications 42

Remaining Problems Back to performance

• Serialized transmission • We examined delay,


• Much of the useful information in first few bytes
• May be better to get the 1st 1/4 of all images than one complete • But what about throughput?
image (e.g., progressive JPEG)
• Can “packetize” transfer over TCP
• Could use range requests
• Important factors:
• Application specific solution to transport protocol • Link capacity
problems. :( • Other traffic
• Solve the problem at the transport layer
• Could fix TCP so it works well with multiple
simultaneous connections
• More difficult to deploy

F' 11 Lecture 3: Applications 43 F' 11 Lecture 3: Applications 44

11
Bandwidth Sharing Fair Sharing of Bandwidth

• Bandwidth received on the • All else being equal, fair


bottleneck link determines BW means that users get equal BW
end-to-end throughput. treatment.
• Router before the bottleneck 100 • Sounds fair
100
link decides how much • When things are not equal,
bandwidth each user gets. we need a policy that
• Users that try to send at a determines who gets how
higher rate will see packet loss much bandwidth.
• User bandwidth can fluctuate • Users who pay more get more
quickly as flows are added or bandwidth
end, or as flows change their Time • Users with a higher “rank” get Time
more bandwidth
transmit rate.
• Certain classes of applications
get priority

F' 11 Lecture 3: Applications 45 F' 11 Lecture 3: Applications 46

But It is Not that Simple Summary

• Application layer
• Each application needs different services
e.g., data loss? Elastic? Timing?
• FTP
Bottleneck • HTTP
• Interaction with TCP: Persistant? Pipelining?
• Delay/Throughput

F' 11 Lecture 3: Applications 47 F' 11 Lecture 3: Applications 48

12

You might also like