CSCD58 W INTER 2018 W EEK 3 - A PPLICATION L AYER Brian Harrington - - PowerPoint PPT Presentation

▶
cscd58 w inter 2018
SMART_READER_LITE
LIVE PREVIEW

CSCD58 W INTER 2018 W EEK 3 - A PPLICATION L AYER Brian Harrington - - PowerPoint PPT Presentation

Oct 19, 2022 131 likes •517 views

Admin Protocol Stack Application Layer Break HTTP DNS P2P CSCD58 W INTER 2018 W EEK 3 - A PPLICATION L AYER Brian Harrington University of Toronto Scarborough January 23, 2018 Admin Protocol Stack Application Layer Break HTTP DNS P2P

slide-1
SLIDE 1

Admin Protocol Stack Application Layer Break HTTP DNS P2P

CSCD58 WINTER 2018

WEEK 3 - APPLICATION LAYER Brian Harrington

University of Toronto Scarborough

January 23, 2018

slide-2
SLIDE 2

Admin Protocol Stack Application Layer Break HTTP DNS P2P

ADMIN

  • Midterm
  • Feb 27
  • In class
  • More info closer to the date
slide-3
SLIDE 3

Admin Protocol Stack Application Layer Break HTTP DNS P2P

AIR TRAVEL ANALOGY

slide-4
SLIDE 4

Admin Protocol Stack Application Layer Break HTTP DNS P2P

POSTAL ANALOGY

slide-5
SLIDE 5

Admin Protocol Stack Application Layer Break HTTP DNS P2P

WHY LAYERING?

  • Each layer can provide a service
  • Don’t care about layers above
  • Don’t worry about layers below
  • Modular Design
  • Changes to baggage handling procedures doesn’t affect

ticketing

  • Changes to postal routing doesn’t affect addressing
slide-6
SLIDE 6

Admin Protocol Stack Application Layer Break HTTP DNS P2P

INTERNET PROTOCOL STACK

slide-7
SLIDE 7

Admin Protocol Stack Application Layer Break HTTP DNS P2P

INTERNET PROTOCOL STACK

  • Application:
  • User-end application protocols
  • FTP

, SMTP , HTTP

  • Transport:
  • Process to process data transfer
  • TCP

, UDP

  • Network:
  • Routing from source to destination
  • IP
  • Link:
  • Transferring data between adjacent

points

  • Ethernet, WiFi, PPP
  • Physical:
  • Moving bits “Along the wire”
slide-8
SLIDE 8

Admin Protocol Stack Application Layer Break HTTP DNS P2P

APPLICATION LAYER

  • Example Network Applications
  • E-mail
  • Web Pages
  • Instant Messaging (IM)
  • P2P File Sharing
  • Multiplayer Games
  • Streaming Store Video (Netflix, YouTube, etc)
  • Voice over IP (Skype)
  • Video over IP (Skype)
  • Facebook
  • Google Search
  • Google... everything else
slide-9
SLIDE 9

Admin Protocol Stack Application Layer Break HTTP DNS P2P

APPLICATION LAYER

  • Remember: Assume that Transport (& Below) layers are

present & working

  • Run on different end systems
  • Don’t have to care about network core
  • Just “post the letter” and assume it will get there
  • Or not...
  • Application Layer protocols define messages sent between

end systems and actions taken

  • Deployment controlled by users, not network
slide-10
SLIDE 10

Admin Protocol Stack Application Layer Break HTTP DNS P2P

APPLICATION ARCHITECTURES

  • Client-Server
  • Always-on server
  • Constant address
  • More traffic = More data centres
  • Peer-to-Peer (P2P)
  • Arbitrary end systems communicating
  • Peers come and go/change IPs
  • Quid-pro-quo
  • Self-scalable
  • Hybrid
  • Skype (central server, calls are P2P)
  • Most instant messaging (user data on server, chats are

P2P)

  • Napster (oops)
slide-11
SLIDE 11

Admin Protocol Stack Application Layer Break HTTP DNS P2P

PROCESS COMMUNICATION

  • Process: Program running on a specific host (computer)
  • same host: inter-process communication defined by OS
  • different hosts: need to pass messages
  • Client Process:
  • Initiates communication
  • Server Process:
  • Waits to be contacted
  • IP address uniquely identifies host
  • To identify a process, need to add a port number
  • HTTP: 80
  • Mail: 25
slide-12
SLIDE 12

Admin Protocol Stack Application Layer Break HTTP DNS P2P

SOCKETS

  • Socket: “door” through which process sends/receives

messages

  • Mailbox analogy
slide-13
SLIDE 13

Admin Protocol Stack Application Layer Break HTTP DNS P2P

WHAT DO WE NEED FROM THE TRANSPORT LAYER?

  • Data Integrity
  • Can we tolerate some loss?
  • Timing
  • Can we tolerate some delay?
  • Throughput
  • Do we need a minimum amount of bandwidth?
  • Security
  • Do we need encryption/redundancy/authentication?
slide-14
SLIDE 14

Admin Protocol Stack Application Layer Break HTTP DNS P2P

APPLICATION LAYER: REQUIREMENTS

Application Data Integrity Throughput Time Sensitive File transfer no loss elastic no E-mail no loss elastic no Static web pages no loss elastic no voice over IP loss-tolerant 5Kb:Audio yes (~100msec) 10Kb:Video stored video loss-tolerant 10Kb yes (~2 sec) stock trading no loss elastic (Time=money)

slide-15
SLIDE 15

Admin Protocol Stack Application Layer Break HTTP DNS P2P

WHAT SERVICES DOES THE TRANSPORT LAYER OFFER?

  • UDP
  • Connectionless: Doesn’t try to set up connection first
  • Unreliable: Send it out and hope for the best
  • No flow or congestion control
  • TCP
  • Connection Oriented: Sets up a connection between server

and client

  • Reliable Transport: Sending process can count on receiving

process getting message

  • Flow Control: Sender won’t overwhelm receiver
  • Congestion Control: throttle sender when network is
  • verloaded
  • Note: Neither protocol provides:
  • Timing
  • Min Bandwidth
  • Security
slide-16
SLIDE 16

Admin Protocol Stack Application Layer Break HTTP DNS P2P

SSL

  • Secure Socket Layer
  • Application Layer protocol
  • Sits “on top” of TCP
  • Pseudo-Transport layer
  • Encrypts data before sending it via TCP
  • What about Timing/Bandwidth?
  • Tough luck!
slide-17
SLIDE 17

Admin Protocol Stack Application Layer Break HTTP DNS P2P

BREAK

slide-18
SLIDE 18

Admin Protocol Stack Application Layer Break HTTP DNS P2P

HTTP: HYPERTEXT TRANSFER PROTOCOL

  • Basic application layer protocol for the web
  • Client-Server based
  • Client: Web browser
  • Server: Web server
  • Uses TCP connection (Port 80)
  • Stateless (server doesn’t remember client requests)
  • Keeping state is hard
  • Cookies used instead
slide-19
SLIDE 19

Admin Protocol Stack Application Layer Break HTTP DNS P2P

HTTP VERSIONS

  • Non-persistent
  • 2RTT + File transfer time per object
  • A good browser will open parallel TCP connections
  • A good server may stop it
  • Persistent
  • 1RTT (connection) + 1RTT/object
  • Need timeout for connection
slide-20
SLIDE 20

Admin Protocol Stack Application Layer Break HTTP DNS P2P

HTTP REQUEST

slide-21
SLIDE 21

Admin Protocol Stack Application Layer Break HTTP DNS P2P

HTTP RESPONSE

slide-22
SLIDE 22

Admin Protocol Stack Application Layer Break HTTP DNS P2P

HTTP: RESPONSE 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
slide-23
SLIDE 23

Admin Protocol Stack Application Layer Break HTTP DNS P2P

HTTP: COOKIES

slide-24
SLIDE 24

Admin Protocol Stack Application Layer Break HTTP DNS P2P

WEB CACHING

  • Majority of WWW is asymmetric
  • Accessed much more frequently than updated
  • Origin server may be (physically) far away (propagation

delay)

  • Solution: Web Caching
  • Typically installed by ISP
  • Less traffic on access link
  • Faster response time for users
  • Reduce stress on “poor” content providers
slide-25
SLIDE 25

Admin Protocol Stack Application Layer Break HTTP DNS P2P

WEB CACHING

  • Assumptions
  • Avg object size: 1Mb
  • Avg request rate: 15/sec
  • Avg LAN bandwidth: 1 Gbps
  • Avg RTT from router to origin server: 2

sec

  • Access Link Rate: 15Mbps
  • Results:
  • LAN utilization: 1.5%
  • Access link utilization: 100%
  • Delay: RTT + Access + LAN
  • 2sec + infinite + negligible
slide-26
SLIDE 26

Admin Protocol Stack Application Layer Break HTTP DNS P2P

WEB CACHING

  • Solution #1: Upgrade
  • Upgrade to 100Mbps access link
  • Access link traffic intensity = 15%
  • Delay: RTT + Access + LAN
  • 2sec + negligible + negligible
  • VERY expensive
  • Solution #2: Web Cache
  • Assume we can satisfy 40% of

requests (typical)

  • Access link traffic intensity = 60%
  • Still results in negligible access time
  • Delay: 0.6 * (RTT + Access + LAN) +

0.4 * (LAN)

  • 0.6 * (2sec + negligible) + 0.4 *

(negligible)

  • ~1.2sec
slide-27
SLIDE 27

Admin Protocol Stack Application Layer Break HTTP DNS P2P

DNS (DOMAIN NAME SYSTEM)

  • Every server has an IP address
  • Can just type: http://74.125.224.72
  • But we’re not very good at memorizing
  • “I don’t know, why don’t you 74.125.224.72 it?”
  • Need a way to translate between the two
slide-28
SLIDE 28

Admin Protocol Stack Application Layer Break HTTP DNS P2P

DNS (DOMAIN NAME SYSTEM)

  • Why not just have one centralized system?
  • Single point of failure
  • Traffic volume
  • Distance
  • Maintenance/updates?
slide-29
SLIDE 29

Admin Protocol Stack Application Layer Break HTTP DNS P2P

DNS (DOMAIN NAME SYSTEM)

  • Want to find IP for web.cs.toronto.edu?
  • Start at top, work your way down
slide-30
SLIDE 30

Admin Protocol Stack Application Layer Break HTTP DNS P2P

ROOT NAME SERVERS

  • 13 Root Name servers
  • Authoritative resource for top level domain servers
  • Now replicated: ~350 mirrored servers
slide-31
SLIDE 31

Admin Protocol Stack Application Layer Break HTTP DNS P2P

DNS EXAMPLE: RECURSIVE MODE

  • Try local first
  • Local DNS requests from

root

  • root requests from

intermediate

  • etc...
  • What’s wrong with this

picture?

  • Too much work for top

level servers

slide-32
SLIDE 32

Admin Protocol Stack Application Layer Break HTTP DNS P2P

DNS: ITERATIVE MODE

  • Push burden of work back

to querier

  • Lower traffic for top level

domains

  • “I don’t know, ask that

server” vs. “I don’t know, I’ll go ask”

slide-33
SLIDE 33

Admin Protocol Stack Application Layer Break HTTP DNS P2P

DNS: CACHING & UPDATING

  • When a DNS server learns a mapping, it caches it
  • What does this imply about root name server traffic?
  • All entry caches are given Time To Live (TTL) based on

their (projected) permanence

  • If host name changes IP

, the whole internet won’t know until all TTLs expire

  • Better solution available (RFC 2136)
  • But still not consistently implemented
  • Remember pros & cons of open standards?
slide-34
SLIDE 34

Admin Protocol Stack Application Layer Break HTTP DNS P2P

DNS: RECORDS

  • Resource Record (RR): (name, value, type[,

ttl])

  • Type is one of:
  • A: hostname –> address
  • NS: domain –> authoritative name server
  • CNAME: common name –> canonical name
  • www.ibm.com –> servereast.backup2.ibm.com
  • MX: domain –> mailserver
  • Example: register d58rocks.com domain with DNS

registrar:

  • (~$10-15/year)
  • registrar inserts into .com TLD server:
  • (d58rocks.com, dns1.d58rocks.com, NS)
  • (dns1.d58rocks.com, 212.212.212.1, A)
  • MX RRs are stored in authoritative name server

(dns1.d58rocks.com)

slide-35
SLIDE 35

Admin Protocol Stack Application Layer Break HTTP DNS P2P

PEER 2 PEER (P2P)

  • No always-on central server
  • End systems (peers) intermittently connected, change IP

address

  • Many uses (not all illegal)
  • File distribution
  • Streaming
  • VoIP
slide-36
SLIDE 36

Admin Protocol Stack Application Layer Break HTTP DNS P2P

PEER 2 PEER (P2P)

  • Distribute a file of size F to N end systems
  • Client/Server:
  • Serialized (N separate downloads)
  • TimeC−S ≥ MAX{ NF

us , F dmin }

  • (With clever scheduling we can get close to this bound)
slide-37
SLIDE 37

Admin Protocol Stack Application Layer Break HTTP DNS P2P

PEER 2 PEER (P2P)

  • Distribute a file of size F to N end systems
  • P2P:
  • Server has to send once
  • Slowest peer still has to download everything
  • Assume total upload capacity = sum of peer upload

capacities

  • TimeP2P ≥ MAX{ F

us , F dmin , NF us+

N

∑

i=1

ui

}

slide-38
SLIDE 38

Admin Protocol Stack Application Layer Break HTTP DNS P2P

CLIENT-SERVER VS. P2P

  • Assuming F/uavg = 1hour, us = 10u, dmin ≥ us