Chapter p 2: Application pp Layer y Our goals:  Conceptual aspects of network application protocols  transport transport-layer layer service models  client-server paradigm  peer-to-peer paradigm

 learn about protocols

by examining some application-level protocols     

HTTP SMTP DNS P2P Content distribution networks (CDNs)

 programming network

applications  sockets API

9/27/2016

Application Layer (SSL)

1

1

Chapter 2: outline 2 1 principles of 2.1 network applications pp 2.2 Web and HTTP 2.3 electronic mail •

SMTP

2.4 DNS

2.5 P2P applications 2.6 video streaming and content distribution networks (CDNs) 2.7 socket programming with UDP and d TCP

Application Layer

2-2

2

Creating a network app Write programs that   

run on (different) end systems communicate over network e.g., web server software communicates i t with ith b browser software

No need to write software for network-core devices 

This approach allows for p app pp development pm rapid

9/27/2016

application transport network data link physical

application t transport t network data link physical

application transport network data link physical

Application Layer (SSL)

3

3

Application architectures  Client-server  to scale –> racks of servers in a datacenter  to improve throughput and response time -> geographically distributed clusters of servers in CDNs  Peer-to-peer (P2P)  difficult to manage -> super nodes (with some server characteristics) needed in addition to regular peers 9/27/2016

Application Layer (SSL)

4

4

Client-server architecture server:  always-on host  permanent IP P address dd  data centers for scaling clients: 

client/server

  

9/27/2016

communicate with server ( (speak kf first)) may be intermittently connected may have dynamic IP addresses do not communicate directly with each other Application Layer (SSL)

5

5

Pure P2P architecture  no always-on l server  arbitrary end systems

directly communicate  peers are intermittently connected and may change h IP addresses dd  difficult to manage 



find content or another peer by broadcast (flooding) NAT traversal problem

peer-peer

Example: BitTorrent has trackers (super nodes that manage the peers and chunks of a torrent) 9/27/2016

Application Layer (SSL)

6

6

Processes communicating Process: program running within a host.  within same host, two processes communicate using inter inter-process process communication (defined by OS).  processes in different

hosts communicate by exchanging messages

Client process: process that initiates communication i ti Server process: process that waits to be contacted  Note: N t client li t & server

processes run in P2P as well as client-server apps

N Note: A process iin these h slides lid may b be a thread h d iinstead d 9/27/2016

Application Layer (SSL)

7

7

Addressing processes  to receive messages,

process must have an identifier  host device has unique 32-bit IP address  Q: Is IP address of host on which process runs enough for identifying the process?  A: No, many processes can be running g on same m host 9/27/2016

 identifier d f includes l d both h

IP address and port number um associated w with process on host.  Example port numbers:  

HTTP H P server: 80 0 Mail server: 25

 to send HTTP message

to gaia.cs.umass.edu web server:  

IP address: dd ss: 128.119.245.12 128 119 245 12 Port number: 80

 more shortly… y Application Layer (SSL)

8

8

App-layer protocol specs  Types of messages

exchanged, g 

e.g., request, response

 Message syntax:  what h t fields fi ld iin messages & how fields are delineated  Message semantics  meaning of information in fields

Public-domain p protocols:  defined in RFCs which enable interoperability e.g., HTTP, SMTP Proprietary protocols:  e.g., Skype

 Rules for when and how

processes send & respond to messages

9/27/2016

Application Layer (SSL)

9

9

What transport service does an app need? Data loss  some apps (e.g., audio) can tolerate some loss  other apps (e.g., file transfer, telnet, email) require i 100% reliable li bl d data t transfer Timing  some apps (e.g., Internet telephony, i t interactive ti games)) require low delay to be “effective” 9/27/2016

Throughput  some apps (e.g., audio, video) require minimum amount of throughput to be “effective”  other apps (“elastic apps”) make use of whatever throughput they get Security  Encryption, yp , data integrity, … (in app layer, e.g. SSL/TLS) Application Layer (SSL)

10

10

Transport service requirements of common apps Data loss

Throughput

Time Sensitive

file transfer e-mail Web documents interactive audio/video

no loss no loss no loss loss-tolerant

no no no yes, 100’s of ms

streaming stored audio/video interactive games i t t messaging instant i

loss-tolerant

elastic elastic elastic (few kbps) audio: 5kbps-1Mbps p p video:10kbps-5Mbps same as above

loss-tolerant no loss

few kbps up elastic

yes, 100’s of ms yes and d no

Application

9/27/2016

yes, few secs

Application Layer (SSL)

11

11

Internet transport protocols services TCP service: UDP service:  connection-oriented: setup  unreliable data required between client and transfer between server processes; state info

sending and receiving processes

 reliable transport: between sending and receiving process  does not p provide: connection setup,  flow control: sender won’t reliability, flow control, overwhelm receiver congestion control, timing,  congestion control: throughput guarantee, or throttle sender when network security is overloaded  does not provide: timing, timin minimum throughput guarantee, security 9/27/2016

Q: why

bother? Why is there a UDP? Application Layer (SSL)

12

12

Internet apps: pp application pp & transport p protocols p Application e-mail remote terminal access Web file transfer g multimedia streaming Internet telephony

9/27/2016

Application layer protocol

Underlying transport protocol

SMTP [RFC 5321] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] HTTP ((e. g., g , Youtube))

TCP TCP TCP TCP TCP

SIP[RFC 3261],RTP[RFC 3550], proprietary(e.g., Skype) UDP or TCP

Application Layer (SSL)

13

13

Chapter 2: outline 2 1 principles of 2.1 network applications pp 2.2 Web and HTTP 2.3 electronic mail •

SMTP

2.4 DNS

2.5 P2P applications 2.6 video streaming and content distribution networks (CDNs) 2.7 socket programming with UDP and d TCP

Application Layer

214

14

Web and HTTP First some jargon  Web page consists of base HTML-file which includes several referenced objects  Object Obj t can b be HTML file, fil JPEG image, i Java J

applet, audio file,…

 Each object is addressable by a URL, for example

www.someschool.edu/someDept/pic.gif host name 9/27/2016

path name

Application Layer (SSL)

15

15

HTTP overview HTTP: hypertext transfer protocol  Web’s application layer

protocol  client/server model  client: browser that requests, receives, p y Web objects j displays  server: Web server sends objects in p to requests q response

PC running Explorer

Server running Apache Web server Mac running Chrome

9/27/2016

Application Layer (SSL)

16

16

HTTP overview overv ew (continued) (cont nued) Uses TCP:  client initiates TCP

connection (creates socket) p 80 to server,, port  server accepts TCP connection from client  HTTP messages exchanged between browser (HTTP client) and Web server ((HTTP server))  TCP connection closed

9/27/2016

HTTP is “stateless”  server maintains no

information about past client requests p q

aside

Protocols that maintain state are complex “state”  past history (state) must be maintained  if server/client / li t crashes, h their views of “state” may be inconsistent, must be reconciled Application Layer (SSL)

17

17

HTTP connections connect ons Nonpersistent p HTTP  At most one object is sent over a TCP connection ti  Version 0 0.9 9  

only one method (GET) only one object type (HTML)

Pers stent H Persistent HTTP P  Version 1.1  Multiple objects can be sent over single TCP connection between client and server.

 Version 1.0

9/27/2016

Application Layer (SSL)

18

18

Nonpersistent HTTP (contains text, Suppose user enters URL references to 10 www.someSchool.edu/someDepartment/home.index jpeg images)

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 socket. that client wants object someDepartment/home.index

1b. HTTP server at host

S h l d waiting iti www.someSchool.edu for TCP connection at port 80, “accepts” connection, notifying client cl ent

3. HTTP server receives request message, forms response message message containing requested object, and sends message into its socket

time

9/27/2016

Application Layer (SSL)

19

19

Nonpersistent HTTP (cont.) 4. HTTP server closes TCP 5. HTTP client receives response

connection connection.

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

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

9/27/2016

Application Layer (SSL)

20

20

Non-Persistent HTTP: Response time Definition of RTT: time for a small packet to travel from client to server and back. initiate TCP Response p time: connection RTT  one RTT to initiate TCP request connection file  one RTT for f HTTP RTT request and first few file bytes y of HTTP response p received to return time  file response time total = 2RTT+ file transmissi transmission n time 9/27/2016

time to transmit file

time

Application Layer (SSL)

21

21

Nonpersistent vs. Persistent HTTP Nonpersistent HTTP delay  requires 2 additional RTTs f an for n object bj t  most browsers open parallel

TCP P connections to fetch f h referenced objects  

very little additional time f all for ll reference f objects bj ts but OS overhead to allocate host resources for all TCP connections

9/27/2016

Persistent HTTP delay  server leaves connection open after sending response  subsequent HTTP messages between client/server are sent over same connection  client sends a new request as soon as it encounters a referenced object (pipelining)  as little as one additional RTT for all referenced objects (plus their transmission time)

Application Layer (SSL)

22

22

HTTP request message  two types of HTTP messages messages: request, response  HTTP request message:  ASCII (human-readable format) request line (GET, POST, HEAD commands)

GET /somedir/page.html HTTP/1.1\r\n Host: www www.someschool.edu\r\n someschool edu\r\n User-agent: Mozilla/5.0\r\n header Connection: close\r\n lines Accept-language:fr\r\n Accept language:fr\r\n Carriage return, \r\n line feed indicate end of header lines 9/27/2016

Application Layer (SSL)

23

23

HTTP request q message: g general g format

9/27/2016

Application Layer (SSL)

24

24

Uploading Upload ng form input nput Post method:  Web page often includes form input  Input is uploaded l to server in entity body

GET method:  Uses GET method  Entity body is empty  Input is uploaded in URL field of request line:

www.somesite.com/animalsearch?monkeys&banana

9/27/2016

Application Layer (SSL)

25

25

Method types HTTP/1.0  GET  POST  HEAD 

asks server to leave requested object out of response

HTTP/1.1  GET, POST, HEAD  PUT 

uploads file in entity body to path specified in URL field

 DELETE  deletes file specified in the URL field

 … (others)

9/27/2016

Application Layer (SSL)

26

26

HTTP response p message m g status line (protocol status code status phrase)

HTTP/1.1 200 OK\r\n Connection close\r\n Date: Tue, 09 Aug 2011 12:00:15 GMT\r\n Server: Apache/2.2.3 (CentOS)\r\n header Last-Modified: Tue, 09 Aug 2011...\r\n lines Content-Length: 6821\r\n Content-Type: text/html\r\n /h l\ \ \r\n data, e.g., data data data data data ... requested HTML file

9/27/2016

Aside: several other methods to indicate length of a response Application Layer (SSL)

27

27

Cookies: keeping p g state info client Cookie file ebay: 8734 Cookie file amazon: 1678 ebay: 8734

server

usual http request msg usual http response +

Set-cookie: Set coo e: 1678 6 8 usual http request msg

cookie: 1678 usual http response msg

one week later: Cookie file amazon: 1678 ebay: 8734 9/27/2016

usual http request msg

cookie: 1678 usual http response msg

Amazon server creates ID 1678 for user cookiespecific action cookiespectific action Application Layer (SSL)

28

28

Cook es Cookies  Application end points keep state at client

and server across multiple p transactions  http messages carry state info but http protocol is stateless What cookies can bring:  authorization  shopping carts  recommendations  user session i state t t (Web e-mail)

9/27/2016

Cookies and privacy:  cookies permit sites (including third parties) to learn a lot about you

Application Layer (SSL)

29

29

Web cache (proxy server) Goal: satisfy client request without involving origin servers  user sets browser:

web accesses via cache  browser sends all HTTP requests to cache 



if object is not in cache, request object from origin server, then return object to client else cache returns object

9/27/2016

origin server

client

client

Proxy server

origin server Application Layer (SSL)

30

30

More about Web caching cach ng  cache acts as both

client and server  typically cache is i st ll d b installed by ISP (university, company, residential ISP)

9/27/2016

Why y Web caching? g  reduce response time for client request  reduce traffic on an institution’s access link. n .

Application Layer (SSL)

31

31

Caching example

origin servers

Assumptions  average object size = 1 Mbits  avg. avg request rate from institution’s institution s

browsers to origin servers = 15/sec  Internet delay (ISP router to any origin server and back) = 2 sec

Consequences  utilization on LAN = 15%  utilization on access link = 100%

institutional network

= Internet delay + access link delay + LAN delay = 2 seconds + minutes + 0.01 second

public I t Internet t

15 Mbps access link 100 Mbps LAN

 total delay

 many lost packets in reponses

institutional cache

Assumption: request is very short and takes no time to transmit 9/27/2016

Application Layer (SSL)

32

32

Caching g example mp (cont) ( ) origin servers

possible solution  increase in s b bandwidth nd idth of f access ss

link to, say, 100 Mbps

public Internet

consequence  utilization on LAN = 15%

100 Mbps access link

 utilization on access link = 15%  Total delay

= Internet delay + access link delay + LAN delay = 2 + 0.01 + 0.01 seconds

 often a costly upgrade

9/27/2016

institutional network

100 Mbps LAN

institutional cache Application Layer (SSL)

33

33

Caching example (3) possible solution: install cache

origin servers

 suppose hit rate is 0.4

consequence

 40% requests will be satisfied

almost immediately  60% requests satisfied by origin servers  utilization of access link reduced d d to 60% 60%, resulting l i iin negligible delay (say 70 ms)  ave. total delay = Internet y + access link delay y + LAN delay delay = 0.6*(2 + 0.07 + 0.01) + 0.4* (0 + 0 + 0.01) seconds = 1.25 1 25 sec 9/27/2016

public Internet

15 Mbps access link institutional network

100 Mbps LAN

institutional cache Application Layer (SSL)

34

34

Conditional GET  Goal: don’t send object if

cache has up-to-date cached version  cache: indicates date of cached copy in HTTP request to server If-modified-since:  server: response contains no

object if cached copy is upto-date: HTTP/1.1 / 304 Not Modified

server

cache HTTP request msg If-modified-since:

HTTP response

object not modified

HTTP/1.1 304 Not Modified

HTTP request msg If-modified-since:

HTTP response

object modified

HTTP/1.1 200 OK

9/27/2016

Application Layer (SSL)

35

35

Chapter 2: outline 2 1 principles of 2.1 network applications pp 2.2 Web and HTTP 2.3 electronic mail •

SMTP

2.4 DNS

2.5 P2P applications 2.6 video streaming and content distribution networks (CDNs) 2.7 socket programming with UDP and d TCP

Application Layer

236

36

Electronic Mail

outgoing message queue

Major components:  user agents

user mailbox user agent

 mail servers  simple mail transfer protocol:

SMTP

User Agent Us A nt  a.k.a. “mail reader”  composing, editing, reading mail messages e.g., Outlook, alpine, Mozilla Thunderbird, iPhone mail client

mail server

SMTP SMTP mail server

user agent 9/27/2016

SMTP

user agent mail server

user agent

user agent

user agent

Application Layer (SSL)

37

37

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”: sender  “server”: server : receiver

Looks like it is the very first (hybrid) P2P system!! 9/27/2016

user agent mail server

SMTP SMTP mail server

user agent

SMTP

user agent mail server

user agent

user agent

user agent

Application Layer (SSL)

38

38

Maill access protocols Ma user agent

SMTP

SMTP

sender’s mail server

Mail access protocol t l

user agent

receiver’s mail server

 SMTP: for delivery to receiver’s server  Mail access p protocol: for retrieval from server

POP: Post Office Protocol [RFC 1939] • authorization (agent server) and download  IMAP: Internet Mail Access Protocol [RFC 3501] • more features (keeps user state across sessions) • manipulation of stored msgs in folders on server  Web W b email: l use HTTP for f b both h send d and d receive 

9/27/2016

Application Layer (SSL)

39

39

Electronic Mail: SMTP  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 h ndsh kin ((greeting) tin )  transfer of messages (persistent connection)  closure command/response interaction  commands: ASCII text  response: status code and phrase messages must be in 7-bit ASCII

9/27/2016

Application Layer (SSL)

40

40

Sample smtp interaction (after TCP connection established) S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: S: 250 [email protected]... Sender ok C: RCPT TO: S: 250 [email protected] ... Recipient ok C: DATA S 354 E S: Enter t mail, il end d with ith "." " " on a line li b by it itself lf C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT g closing g connection S: 221 hamburger.edu 9/27/2016

Application Layer (SSL)

41

41

Try SMTP interaction for yourself 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) Log on a UTCS linux machine. Then do telnet mailbox2.cs.utexas.edu 25

9/27/2016

(opens TCP conn.)

Application Layer (SSL)

42

42

Mail message format SMTP (rfc 5321): protocol for exchanging email msgs rfc f 5322 5322: standard t d df for ttextt message format:

header

blank line

 header lines, e.g.,

To:  From:  Subject: different from SMTP commands and responses  body  the “message”, ASCII characters only 

9/27/2016

body

Application Layer (SSL)

43

43

Message format: multimedia extensions  Multipurpose Internet Mail Extensions (MIME)  additional lines in msg header declare MIME

content type MIME version

method used to encode data multimedia data type subtype, type, subtype parameter declaration encoded data 9/27/2016

From: [email protected] To: [email protected] Subject: Picture of yummy crepe. MIME-Version: MIME Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 b 64 encoded d d data d t ..... ......................... ......base64 encoded data

Application Layer (SSL)

44

44

Chapter 2: outline 2 1 principles of 2.1 network applications pp 2.2 Web and HTTP 2.3 electronic mail •

SMTP

2.4 DNS

2.5 P2P applications 2.6 video streaming and content distribution networks (CDNs) 2.7 socket programming with UDP and d TCP

Application Layer

245

45

DNS: Domain D D m Name m System y m People: many identifiers: 

SSN,, name,, passport p p #

Internet hosts, routers:  IP address (32 bit) - used df for addressing dd i datagrams



“name”, e.g.,

www.yahoo.com - used by humans

Required: equ red map between name and IP addresses

9/27/2016

Domain Name System:  distributed database implemented as a hierarchy of many name servers  application-layer protocol used to resolve names (address/name translation) 



note: core Internet function, implemented as applicationlayer protocol complexity at network’s “edge”

Application Layer (SSL)

46

46

DNS DNS services  Hostname to IP address translation  Host alias 

Canonical C i l and d alias li names

 Mail server alias  Load distribution  Replicated Web servers: set of IP addresses for one canonical name

9/27/2016

Why not centralized DNS?  single point of failure  traffic volume  distant centralized database 

maintenance/update

doesn’t scale!

Application Layer (SSL)

47

47

Distributed, Hierarchical Database Root DNS Servers

Top-level p domains .com DNS servers yahoo.com amazon.com DNS servers DNS servers

.org DNS servers b pbs.org DNS servers

.edu DNS servers poly.edu poly edu umass edu umass.edu DNS servers DNS servers

Client wants IP address for www www.amazon.com; amazon com; 1st approx:  Client queries a root server to find .com DNS server  Client q queries .com DNS server to g get amazon.com DNS server  Client queries amazon.com DNS server to get IP address dd f for www.amazon.com 9/27/2016

Application Layer (SSL)

48

48

DNS: root name servers

e. NASA Mt View, CA f Internet Software C f. C. Palo Alto, CA (and 48 other sites)

c. Cogent, Herndon, VA (5 other sites) d. U Maryland y College g Park, MD h. ARL Aberdeen, MD j. Verisign, Dulles VA (69 other sites )

13 root name “servers” worldwide

k. RIPE London (17 other sites) i. Netnod, Stockholm (37 other sites)

m. WIDE Tokyo m (5 other sites)

a. Verisign, Los Angeles (5 other sites) b. USC-ISI Marina del Rey, CA l. ICANN Los Angeles, CA (41 other sites) g. US DoD Columbus, OH (5 other sites)

9/27/2016

Application Layer (SSL)

49

49

TLD and Authoritative Servers  Top-level domain (TLD) servers: responsible

for .com, .org, .net, .edu, …, and all top-level country t d domains i .uk, k .fr, f .ca, .jp j Verisign maintains servers for .com TLD  Educause for .edu edu TLD 

 Authoritative DNS servers: organization’s

providing g authoritative DNS servers, p hostname-to-IP mappings for organization’s named hosts (e.g., Web and mail). 

Can be locally maintained by organization or a service provider

9/27/2016

Application Layer (SSL)

50

50

Local Name Server  does not strictly belong to hierarchy  each ISP (residential ISP, company,

university) y) has one. 

also called “default name server”

 when host makes DNS q query, y, query q y is sent

to its local DNS server 

which acts as proxy, forwards query into hi hierarchy h

9/27/2016

Application Layer (SSL)

51

51

DNS name resolution s l ti example l

root DNS server

 Host at cis.poly.edu

wants t IP address dd f for gaia.cs.umass.edu  It sends a recursive query to local DNS server iterated query:

2

4

9/27/2016

TLD DNS server

5 local DNS server dns.poly.edu

1

8

 contacted server

p with name of replies server to contact “I don’t know this name,, but ask this other server”

3

requesting host

7

6

authoritative DNS server dns.cs.umass.edu

cis.poly.edu gaia.cs.umass.edu Application Layer (SSL)

52

52

DNS: caching  when (any) name server learns mapping, it caches

mapping  cached entries timeout (disappear) after some time (e.g., 2 days)  TLD servers typically cached in local name servers -Thus root name servers not often visited  cached entries may be out-of-date (best effort service)  if host changed IP address, this may not be known Internet-wide until all TTLs expire

9/27/2016

Application Layer (SSL)

53

53

DNS records DNS: distributed db storing resource records (RR) RR format: (name, (name  Type=A  name is hostname  value is IP address  T Type=NS NS  name is domain (e.g. foo.com)  value is hostname of authoritative name server for this domain 9/27/2016

value, value type, type ttl)

 Type=CNAME  name is alias l name for f some “canonical” (the real) name e.g., www.ibm.com is really servereast.backup2.ibm.com 

value is canonical name

 Type=MX  value is host name of mail server associated with name Application Layer (SSL)

54

54

DNS protocol messages DNS protocol : query and reply messages, both with same message format msg header  identification: 16 bit #

for query, reply f l to query uses same #  flags:  query or reply  recursion desired  r recursion cur n a available a a  reply is authoritative

9/27/2016

Application Layer (SSL)

55

55

DNS protocol D p messages m g (cont.) ( .) N Name, type t fi fields ld for a query RR iin response RRs to query records for authoritative servers additional “helpful” helpful info that may be used

9/27/2016

Application Layer (SSL)

56

56

Inserting records into DNS  Example: just created startup “Network Utopia”  Register name networkutopia.com at a registrar (e.g.,

Network Solutions) 



Need to provide registrar with names and IP addresses of your authoritative name servers (primary and secondary) Registrar inserts NS and A resource records for each authoritative server into .com TLD servers: (networkutopia.com, dns1.networkutopia.com, NS) (dns1 networkutopia com 212.212.212.1, (dns1.networkutopia.com, 212 212 212 1 A)

 Put into authoritative servers, CNAME record for

www.networkutopia.com, www networkutopia com MX record for networkutopia.com, and …  How do people get the IP address of your Web site? 9/27/2016

Application Layer (SSL)

57

57

Chapter 2: outline 2 1 principles of 2.1 network applications pp 2.2 Web and HTTP 2.3 electronic mail •

SMTP

2.4 DNS

2.5 P2P applications 2.6 video streaming and content distribution networks (CDNs) 2.7 socket programming with UDP and d TCP

Application Layer

258

58

P2P architecture  no always-on server  arbitrary end systems

directly communicate  peers are intermittently connected d and d change h IP addresses peer-peer  Hybrid deployment examples:  

File distribution, e.g., BitTorrent (has trackers) Internet telephony, e.g., original Skype (had super peers) peers),

9/27/2016

Application Layer (SSL)

59

59

File Distribution: Client-Server vs P2P Question : How much time to distribute a file p from one server to N peers? us server upload S Server

us

File, size F

dN uN

9/27/2016

u1 d1

u2

d2

capacity (bps) ui peer i upload capacity (bps) di peer i download capacity (bps)

Network (with abundant bandwidth)

Application Layer (SSL)

60

60

Time to distribute file to N users : Client-Server  server sequentially

sends N copies: 

NF/us time

 client i takes F/di

ti time tto d download l d

Server F

us

u1 d1 u2 d 2

Network (with abundant bandwidth)

dN uN

Time to distribute F to N clients is Tcs ≥ max { NF/us , F/min(d ( i) } i (lower bound) Wh N is large, When l min(d mi (di) > us/N 9/27/2016

i

Application Layer (SSL)

61

61

Time to distribute file to N users: P2P  server must send one

copy: py F/us time  client i takes F/di time to download  NF bits must be uploaded l d d (aggregate)

Server F

u1 d1 u2 d 2

us

Network (with abundant bandwidth)

dN uN

fastest possible upload rate: us + Σ1≤i≤N-1 ui TP2P ≥ max { F/us , F/min(di) , NF/(us + Σui) } i

Largest g value as N ↑

us > ((us + Σui))/N and,, for large g N,, min(d ( i) > ((us + Σui))/N i

9/27/2016

Application Layer (SSL)

62

62

Client-server vs. P2P: example Cli t upload Client l d rate t =uf for all ll ii, F/ F/u = 1 min., i us = 10u, 10 dmin ≥ u Minimum m Distributtion Time

3.5 P2P Client-Server

3 2.5

NF / us = NF / (10u )

2

= N / 10 min.

2 servers

as N → ∞

1.5

N −1

NF / (us +  ui ) = F / u = 1 min. min

1

i =1

0.5 0 0

5

10

15

20

25

30

35

N

What if more than 1 server? I.e., a data center 9/27/2016

Application Layer (SSL)

63

63

Chapter 2: outline 2 1 principles of 2.1 network applications pp 2.2 Web and HTTP 2.3 electronic mail •

SMTP

2.4 DNS

2.5 P2P applications 2.6 video streaming and content distribution networks (CDNs) 2.7 socket programming with UDP and d TCP

Application Layer

264

64

Sockets  process sends/receives

messages to/from its host or socket server  socket analogous to “door”  sending process shoves process message out of door socket  it relies on transport C with wt infrastructure on other TCP buffers, side of door which variables delivers message to socket k t att receiving i i process 9/27/2016

host or server se ve controlled by app developer

process socket

Internet

TCP with buffers, variables

controlled by OS

Application Layer (SSL)

65

65

Socket programming Goal: learn how to write client and server programs which communicate by sending data into sockets, reading di d data t outt of f sockets k t Socket API  introduced in BSD4.1 BSD4 1 UNIX UNIX, 1981  sockets are explicitly created, used, then released by y applications pp  client/server paradigm  API: choice of a transport protocol and ability t specify to if a f few parameters t  reliable byte stream  unreliable datagram 9/27/2016

Application Layer (SSL)

66

66

Socket programming with TCP Before client contact:  server process must first be running runn ng  server must have created socket (door) that welcomes w m client’s contact Client contacts server by:  creating client-local TCP s k t socket  specifying IP address, port number of server process  When h client l makes k connect call: client TCP establishes connection to server TCP 9/27/2016

 When contacted by client,

server TCP creates a new connection socket for server process to communicate with client  allows server to talk with multiple l l clients l  source IP address and port number used to distinguish clients l ( (more in Chap h 3)) application viewpoint CP provides d reliable, l bl in-order d TCP transfer of byte stream between client and server

Application Layer (SSL)

67

67

Socket API for TCP (BSD Unix)  Client side  socket(), returns client socket id  connect(), need to specify server IP address and port port, sends conn req  send(), sends to client socket  recv(), receives from client socket  close(), close() closes connection 

note: OS supplies local IP address and port for client

9/27/2016

 S Server side id  socket(), returns server socket id  bind(), binds server socket to server IP address and port  listen(), willing to accept conn req on server socket  accept(), p accepts p new conn req and returns its connection socket id  recv(), receives from connection socket  send(), sends to connection socket  close(), closes connection Application Layer (SSL)

68

68

Client/server socket interaction: TCP server (running on hostid)

client

create socket: port=x serverSocket = socket() serverSocket.bind() S k t bi d() serverSocket.listen() wait for incoming connection request

TCP connectionSocket = serverSocket.accept() connection setup

recv request from connectionSocket send reply to connectionSocket close connectionSocket 9/27/2016

Note: syntax is neither complete nor precise

create socket: clientSocket = socket() connect to hostid, port=x

send request using clientSocket

recv reply from clientSocket close clientSocket Application Layer 69

69

Socket programming with UDP UDP: no “connection” between client and server  no handshaking h d h k  sender explicitly attaches IP

address and port of destination to each h packet k  server must extract IP address, port of sender from every received i d packet k

application viewpoint provides unreliable transfer UDP p of groups of bytes (“datagrams”) between client and server

UDP: transmitted data may be received out of order order, or lost

9/27/2016

Application Layer (SSL)

70

70

Socket API for UDP (BSD Unix)  Client side  socket(), returns client socket id  sendto(), sends to client socket, need to specify destination’ss IP address destination and port  recvfrom(), receives from client socket: socket data and sender’s IP address and port 

bind(), optional

 note: needs timeout management;

 Server side  socket(), returns server socket id  bind(), binds server socket to server IP port address and p  recvfrom(), receives from server socket: data and sender’s IP address and port  sendto(), sends to server socket,, need to specify destination’s IP address and port

OS supplies local IP address and port for client if bind() not used 9/27/2016

Application Layer (SSL)

71

71

Client/server socket interaction: UDP server (running on serverIP) create socket: port= x serverSocket = socket(AF_INET, SOCK_DGRAM) serverSocket.bind() recv datagram with client’s address from serverSocket send reply with client’s address to serverSocket

client create socket: clientSocket cli ntS ck t = socket(AF_INET, SOCK_DGRAM) create datagram with server IP address and port=x; send datagram to clientSocket recv datagram with server’s address from clientSocket l k close clientSocket

9/27/2016

Note: syntax is neither complete nor precise

Application Layer

72

72

Chapter 2: outline 2 1 principles of 2.1 network applications pp 2.2 Web and HTTP 2.3 electronic mail •

SMTP, POP3, IMAP

2.4 DNS

2.5 P2P applications 2.6 video streaming and content distribution networks (CDNs) 2.7 socket programming with UDP and d TCP

Application Layer

273

73

Video Streaming and CDNs: context  video traffic: major consumer of Internet bandwidth • Netfl Netflix, x, You YouTube: ube 37%, 16% 6% of downstream residential ISP traffic in 2015 • ~1B YouTube users, ~75M Netflix users  challenge: scale ~1B users? • single mega-video server won’t work  challenge: ch ll n : heterogeneity h t n it  different users have different capabilities and bandwidths ((e.g., g , wired versus mobile) m )  solution: distributed, application-level infrastructure Application 2Layer 74

74

Multimedia: video  CBR: (constant bit rate): video encoding rate fixed  VBR: (variable bit rate): video g rate changes g as encoding amount of spatial, temporal coding changes mp examples: • MPEG-1 (CD-ROM) 1.5 Mbps • MPEG-2 (DVD) 3-6 Mbps • MPEG-4 (often used in Internet < 1 Mbps)

spatial coding example: instead of sending N values of same color (all purple) send only two purple), values: color value (purple) and number of repeated values (N)

…………………….. ……………….…….

frame i

temporal coding example: instead of sending complete frame at i+1, send only differences from frame i

frame i+1

Application 2Layer 75

75

Streaming g stored video: simple p scenario:

Internet

video server (stored video)

client

Video can be compressed to essentially any bit rate by trading image quality E.g., Internet video from 100Kbps for low quality to over 3 Mbps for high-definition movies Application 2Layer 76

76

Streaming multimedia: DASH  Dynamic, Adaptive Streaming over HTTP  server:

divides di id video id fil file iinto t multiple lti l chunks h k  each chunk stored, encoded at different rates  manifest file: provides URLs for different chunks  client: p periodically y measures server-to-client bandwidth  consulting manifest, requests one chunk at a time • chooses maximum coding rate sustainable at current bandwidth • can choose different coding rates at different points in time 

Application 2Layer 77

77

Streaming multimedia: DASH  “intelligence” at client:

client determines when to request chunk - so that buffer starvation, or overflow does not occur  what encoding rate to request - higher quality when more bandwidth available 



where to request chunk – may possibly request from f m another server that has higher g available bandwidth (less congested path) [actually client

will need help from CDN]

Application 2Layer 78

78

Content distribution networks  challenge: how to stream content (selected

from millions of videos) to hundreds of thousands of simultaneous users?

 option 1: single, large “mega-server”  single point of failure  point of network congestion  long path to distant clients  multiple lti l copies i of f video id sentt over outgoing t i li links k

….this this solution doesn doesn’tt scale Application 2Layer 79

79

Content distribution networks  option 2: third-party CDN, store/serve

multiple copies of videos at geographically di t ib t d sites: distributed it enter deep: push CDN servers deep into many access networks • close to users • e.g., used by Akamai, 1700 locations  bring home: smaller number (10’s) (10 s) of larger clusters in POPs/IXPs near (but not within) access networks • e.g., used by Limelight 

 option 3: private CDN, e.g., Google and

NetFlix

Application Layer 2-80

80

CDN content access: DNS redirect Bob (client) requests video http://netcinema.com/6Y7B23V  video stored in KingCDN.com

1. Bob clicks on URL for video http://video netcinema com/6Y7B23V http://video.netcinema.com/6Y7B23V

1

on netcinema.com web page

2. Client resolves video.netcinema.com 2 via local DNS

6. request video from 5 KINGCDN server, streamed via HTTP netcinema.com

3. netcinema’s DNS returns hostname 1105 1105.KingCDN.com KingCDN com

4

4&5. Local DNS resolves 1105.KingCDN.com from KingCDN’s authoritative DNS, which returns the IP address of a g server KingCDN

Bob’s client then establishes a direct TCP connection with the KingCDN server and issues an HTTP GET request for video

3

netcinema’s authoratative DNS

Bob’s local DNS server

KingCDN.com

KingCDN authoritative DNS

Application 2Layer 81

81

Content Distribution Networks (CDNs)  copies of f content stored d at CDN D servers  subscriber requests content from CDN

• directed to nearby copy, retrieves content •m may y choose different ff copy py if f network path p is congested

where’s Madmen?

manifest if t fil file

Application 2Layer 82

82

Case study: Netflix Amazon cloud

Netflix registration, g accounting servers 2. Bob browses Netflix video 2 1

3

upload copies of multiple lti l versions i off video to CDN servers

3. Manifest file returned for requested video

1. Bob manages Netflix account

CDN server

CDN ser er server

CDN server 4. DASH streaming Application 2Layer 83

83

End of Chapter 2

9/27/2016

Application Layer (SSL)

84

84