Content Delivery Infrastructure. HTTP Overview. A Web Page. Computer Networks. Lecture 9: HTTP

Similar documents
Protocolo HTTP. Web and HTTP. HTTP overview. HTTP overview

The Web: some jargon. User agent for Web is called a browser: Web page: Most Web pages consist of: Server for Web is called Web server:

Network Technologies

Content'Delivery'Infrastructure' HTTP'Overview' A'Web'Page' Computer Networks. Lecture'9:'HTTP'

Application Layer: HTTP and the Web. Srinidhi Varadarajan

CS640: Introduction to Computer Networks. Applications FTP: The File Transfer Protocol

1 Introduction: Network Applications

CONTENT of this CHAPTER

The Web History (I) The Web History (II)

1. When will an IP process drop a datagram? 2. When will an IP process fragment a datagram? 3. When will a TCP process drop a segment?

DATA COMMUNICATOIN NETWORKING

HTTP. Internet Engineering. Fall Bahador Bakhshi CE & IT Department, Amirkabir University of Technology

Project #2. CSE 123b Communications Software. HTTP Messages. HTTP Basics. HTTP Request. HTTP Request. Spring Four parts

Web Caching and CDNs. Aditya Akella

Internet Technologies. World Wide Web (WWW) Proxy Server Network Address Translator (NAT)

The Hyper-Text Transfer Protocol (HTTP)

By Bardia, Patit, and Rozheh

reference: HTTP: The Definitive Guide by David Gourley and Brian Totty (O Reilly, 2002)

How To Understand The Power Of A Content Delivery Network (Cdn)

Internet Technologies 4-http. F. Ricci 2010/2011

Review of Networking Basics. Yao Wang Polytechnic University, Brooklyn, NY11201

HTTP Protocol. Bartosz Walter

Application Layer. CMPT Application Layer 1. Required Reading: Chapter 2 of the text book. Outline of Chapter 2

Internet Content Distribution

DATA COMMUNICATOIN NETWORKING

Computer Networks. Lecture 7: Application layer: FTP and HTTP. Marcin Bieńkowski. Institute of Computer Science University of Wrocław

Distributed Systems. 25. Content Delivery Networks (CDN) 2014 Paul Krzyzanowski. Rutgers University. Fall 2014

Final for ECE374 05/06/13 Solution!!

Distributed Systems 19. Content Delivery Networks (CDN) Paul Krzyzanowski

Application-layer protocols

Communications Software. CSE 123b. CSE 123b. Spring Lecture 13: Load Balancing/Content Distribution. Networks (plus some other applications)

Web. Services. Web Technologies. Today. Web. Technologies. Internet WWW. Protocols TCP/IP HTTP. Apache. Next Time. Lecture # Apache.

CS514: Intermediate Course in Computer Systems

M3-R3: INTERNET AND WEB DESIGN

Lecture 3: Scaling by Load Balancing 1. Comments on reviews i. 2. Topic 1: Scalability a. QUESTION: What are problems? i. These papers look at

Distributed Systems. 23. Content Delivery Networks (CDN) Paul Krzyzanowski. Rutgers University. Fall 2015

World Wide Web. Before WWW

Hypertext for Hyper Techs

1. Comments on reviews a. Need to avoid just summarizing web page asks you for:

Distributed Systems. 24. Content Delivery Networks (CDN) 2013 Paul Krzyzanowski. Rutgers University. Fall 2013

The Different Types of TCPIP and Their Uses

ICP. Cache Hierarchies. Squid. Squid Cache ICP Use. Squid. Squid

Data Communication I

Evolution of the WWW. Communication in the WWW. WWW, HTML, URL and HTTP. HTTP Abstract Message Format. The Client/Server model is used:

HTTP Caching & Cache-Busting for Content Publishers

Chapter 27 Hypertext Transfer Protocol

Front-End Performance Testing and Optimization

Computer Networks - CS132/EECS148 - Spring

SiteCelerate white paper

Indirection. science can be solved by adding another level of indirection" -- Butler Lampson. "Every problem in computer

Computer Networks. Instructor: Niklas Carlsson

CTIS 256 Web Technologies II. Week # 1 Serkan GENÇ

Outline Definition of Webserver HTTP Static is no fun Software SSL. Webserver. in a nutshell. Sebastian Hollizeck. June, the 4 th 2013

Content Delivery Networks

D. SamKnows Methodology 20 Each deployed Whitebox performs the following tests: Primary measure(s)

Lecture 8a: WWW Proxy Servers and Cookies

sessionx Desarrollo de Aplicaciones en Red Web Applications History (1) Content History (2) History (3)

CS 5480/6480: Computer Networks Spring 2012 Homework 1 Solutions Due by 9:00 AM MT on January 31 st 2012

Lecture 8a: WWW Proxy Servers and Cookies

WHAT IS A WEB SERVER?

CSCI-1680 CDN & P2P Chen Avin

Cookies Overview and HTTP Proxies

Measuring the Web: Part I - - Content Delivery Networks. Prof. Anja Feldmann, Ph.D. Dr. Ramin Khalili Georgios Smaragdakis, PhD

Research of Web Real-Time Communication Based on Web Socket

Cleaning Encrypted Traffic

Content Distribu-on Networks (CDNs)

Transport Layer Protocols

Question: 3 When using Application Intelligence, Server Time may be defined as.

No. Time Source Destination Protocol Info HTTP GET /ethereal-labs/http-ethereal-file1.html HTTP/1.

Layer 7 Load Balancing and Content Customization

Lecture 33. Streaming Media. Streaming Media. Real-Time. Streaming Stored Multimedia. Streaming Stored Multimedia

First Midterm for ECE374 03/09/12 Solution!!

Internet Technology. 03. Application layer protocols. Paul Krzyzanowski. Rutgers University. Spring 2016

1. The Web: HTTP; file transfer: FTP; remote login: Telnet; Network News: NNTP; SMTP.

Cyber Security Workshop Ethical Web Hacking

Chapter 2 Application Layer

Overlay Networks. Slides adopted from Prof. Böszörményi, Distributed Systems, Summer 2004.

Single Pass Load Balancing with Session Persistence in IPv6 Network. C. J. (Charlie) Liu Network Operations Charter Communications

Streaming Stored Audio & Video

Datagram-based network layer: forwarding; routing. Additional function of VCbased network layer: call setup.

Introduction to Computer Security

Large-Scale Web Applications

Internet Firewall CSIS Packet Filtering. Internet Firewall. Examples. Spring 2011 CSIS net15 1. Routers can implement packet filtering

EE 7376: Introduction to Computer Networks. Homework #3: Network Security, , Web, DNS, and Network Management. Maximum Points: 60

Instructor: Betty O Neil

Testing & Assuring Mobile End User Experience Before Production. Neotys

internet technologies and standards

Note! The problem set consists of two parts: Part I: The problem specifications pages Part II: The answer pages

Content Delivery Networks

Request Routing, Load-Balancing and Fault- Tolerance Solution - MediaDNS

Debugging With Netalyzr

Internet Technologies Internet Protocols and Services

Web Security. Mahalingam Ramkumar

CDN and Traffic-structure

Challenges of Sending Large Files Over Public Internet

Varnish Tips & Tricks, 2015 edition

Application Layer -1- Network Tools

Application Example: WWW. Communication in the WWW. WWW, HTML, URL and HTTP. Loading of Web Pages. The Client/Server model is used in the WWW

CMPE 80N: Introduction to Networking and the Internet

Internet Control Protocols Reading: Chapter 3

Transcription:

Content Delivery Infrastructure Computer Networks Lecture 9: HTTP Peer-to-peer (p2p): hybrid p2p with a centralized server pure p2p hierarchical p2p end-host (p2p) multicast Content-Distribution Network (CDN) HTTP Overview HTTP Performance HTTP Caching Content Distribution Network A Web Page A web page consists of a base HTML-file which may include references to one or more objects an object can be another HTML file, a JPEG image, a Java applet, an audio file, a flash video, etc. each object is addressable by a URL example URL: http://www.mgoblue.com/images/pic.gif protocol host name path name HTTP Overview HTTP: HyperText Transfer Protocol Web s application-layer protocol client/server model client: browser that requests, receives, and displays Web objects server: sends objects in response to requests HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068 HTTP/2: RFC 7540 (May 2015) PC running Firefox Mac running Safari Server running Apache Web server

HTTP Overview Uses TCP: 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 aside if server/client crashes, their views of state may be inconsistent, and must be reconciled HTTP 1.x Request Message Two types of HTTP messages: request, response HTTP request message: in ASCII (human-readable format) general format: GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language: fr (extra carriage return, line feed) example Carriage return, line feed indicates end of message Method Types (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 Uploading form, input alternatives: 1. POST method: web pages often include form input input is uploaded to server in entity body 2. as parameter to GET URL method: input is uploaded in URL field of request line: www.somesite.com/animalsearch?monkeys&banana input parameters HTTP 1.x Response Message Example header lines blank line data, e.g., requested HTML file HTTP/1.1 200 OK Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998... Content-Length: 6821 Content-Type: text/html data data data data data... first line: status line (protocol status code, status phrase)

HTTP 1.x Response: Status Line HTTP-version 3-digit-response-code Reason-phrase 1XX informational 2XX success 200 OK: request succeeded, requested object later in this message 3XX redirection 301 Moved Permanently: requested object moved, new location specified later in this message ( Location: in header ) 303 Moved Temporarily 304 Not Modified 4XX client error 400 Bad Request: request message not understood by server 404 Not Found: requested document not found on this server 5XX server error 505 HTTP Version Not Supported Client-side States: Cookies HTTP is stateless server maintains no information about past client requests but sometimes it may be useful to keep per-client states, for example for: authorization shopping carts wish list recommendations user session state (Web e-mail) States or user ID (to look up server-side states) kept at client side using cookies Client-side States: Cookies Four components: 1. cookie header line in the HTTP response message 2. cookie header line in HTTP request message 3. cookie file kept on client host and managed by client browser 4. back-end database at Web server client Cookie file ebay: 8734 Cookie file amazon: 1678 ebay: 8734 one week later: Cookie file amazon: 1678 ebay: 8734 usual http request msg usual http response + Set-cookie: 1678 usual http request msg cookie: 1678 usual http response msg usual http request msg cookie: 1678 usual http response msg server creates ID 1678 for user cookiespecific action, e.g., wish list cookiespecific action amazon server Abuse of Cookies Excellent marketing opportunities and concerns for privacy: cookies permit sites to learn a lot about you you may unknowingly supply personal info to sites advertising companies tracks your preferences and viewing history across sites, example scenario: ad company contracted with (1) a social networking site, (2) a book store, and (3) a clothing store you view your friend s travel photos to Hawaii at the social networking site when you visit the bookstore, a travel book about Hawaii is pushed to you when you visit the clothing store, a swimming goggle is pushed to you at all three places a travel agency s extra-low price, expiring in 30 seconds, Hawaii vacation package is pushed to you

Object Request Response Time RTT (round-trip time): time for a small packet to travel from client to server and back Response time: 1 RTT to initiate TCP connection 1 RTT for HTTP request and the first few bytes of HTTP response to return file transmission time = 2RTT+transmit time initiate TCP connection RTT request file RTT file received time time time to transmit file HTTP 1.0 HTTP 1.0 uses non-persistent connections: at most one object is sent over a TCP connection object transmission completion detected by recv() returning 0 (connection closed) why is this not a good design? 0 RTT Client opens TCP connection 1 RTT Client sends HTTP request for HTML Client parses HTML Client opens TCP connection 2 RTT 3 RTT Client sends HTTP request for image Image begins to arrive 4 RTT Client SYN FIN SYN Server SYN FIN SYN Server reads from disk Server reads from disk HTTP 1.1 HTTP 1.1 uses persistent connections: server leaves connection open after sending responses subsequent HTTP messages between the same client/server to fetch multiple objects are sent over the same connection 0 RTT Client sends HTTP request for HTML Client parses HTML Client sends HTTP request for image Image begins to arrive 1 RTT 2 RTT Client Server Server reads from disk Server reads from disk How to Mark End of Message? Three options: Content-Length in header: HTTP/1.1 200 OK Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998... Content-Length: 6821 Content-Type: text/html

How to Mark End of Message? Implied length, e.g., 304 (cache fresh) never has content Transfer-Encoding: chunked (HTTP 1.1) after headers, each chunk comprises content length in hex, CRLF, then body; length 0 indicates end-of-chunk HTTP/1.1 200 OK<CRLF> Transfer-Encoding: chunked<crlf> <CRLF> 25<CRLF> This is the data in the first chunk<crlf> 1A<CRLF> and this is the second one<crlf> 0<CRLF> Pipelined and Parallel Connections Persistent without pipelining: client issues new request only when previous response has been received one RTT for each referenced object Persistent with pipelining: client sends requests as soon as it encounters a referenced object as little as one RTT for all referenced objects default in HTTP 1.1 Browsers can open parallel TCP connections to fetch referenced objects (even in HTTP 1.0) HTTP Modeling Assume Web page consists of: 1 base HTML page (of size L bits) M images (each also of size L bits) Non-persistent HTTP: M+1 TCP connections in series response time = (M+1)*2*RTT + (M+1)*L/µ, µ: path speed Persistent HTTP (with pipelining): 2 RTTs to request and receive base HTML file 1 RTT to request and receive M images response time = 3*RTT + (M+1)*L/µ HTTP Modeling Assume Web page consists of: 1 base HTML page (of size L bits) M images (each also of size L bits) Non-persistent HTTP with n parallel connections suppose M/n evenly 1 TCP connection for base file M/n parallel connections for images n-parallel response time = (M/n + 1)*2*RTT + (M/n+1)*L/µ compare: non-persistent response time = (M+1)*2*RTT + (M+1)*L/µ persistent response time = 3*RTT + (M+1)*L/µ

HTTP Response time (in seconds) RTT = 100 msec, L = 5 Kbytes, M = 10, and n = 5 HTTP Response time (in seconds) RTT = 1 sec, L = 5 Kbytes, M = 10, and n = 5 For low bandwidth, transmission time dominates over connection and response time performance of persistent connections comparable to that of parallel connections For larger RTT, TCP establishment and slow start delays dominate over response time persistent connections now give significant improvement: particularly in high bandwidth delay networks HTTP/2 HTTP/2 Based on Google s SPDY (2009) RFC 7540 came out in May 2015 (written by the two authors of SPDY) Chrome browser already has SPDY built-in Problems with HTTP 1.x: pipelining still suffers from head-of-line blocking (if first item is large, the rest has to wait) parallel streams solves HoL blocking, but on bandwidthlimited channel, too many streams clog up the channel Some changes from 1.1: headers no longer in text format separate control and data headers stream multiplexing over a single TCP connection: each stream has an ID, data is tagged with stream ID each stream can also have different priority server push: don t have to wait for client to parse page before initiating download header compression Performance improvement: up to 64% reduction in page load time [Grigorik]

Web Caches (Proxy Server) Goal: satisfy client request without involving origin server user sets browser to direct all web accesses via cache browser sends all HTTP requests to cache if object is not cached, cache requests object from origin server, then returns object to client else cache returns object cache acts as both client and server typically cache is installed by ISP (university, company, residential ISP) must be transparent, allow for plug-n-play client client Proxy server origin server Web Caching Example: No Caching Parameters: average object size = 100,000 bits avg. # of requests to servers = 15/sec Internet latency between a router on the public Internet and any server = 2 secs Resulting performance: utilization on LAN = 15% utilization on access link = 100% institutional network public Internet over-utilized link causes long queue (delay of minutes) total delay = Internet delay + access delay + LAN delay = 2 secs + minutes + milliseconds 1.5 Mbps access link origin servers 10 Mbps LAN Web Caching Example: No Caching Possible solution increase access link bandwidth to, say, 10 Mbps (often a costly upgrade) Performance: utilization on LAN = 15% utilization on access link = 15% institutional network public Internet total delay = Internet delay + access delay + LAN delay = 2 secs + msecs + msecs 10 Mbps access link origin servers 10 Mbps LAN Web Caching Example: With Caching Another solution: install cache assume hit rate of 0.4 Performance: 40% requests will be satisfied almost immediately 60% requests satisfied by origin server utilization of access link reduced to 60%, resulting in negligible delays (say 10 msecs) institutional network public Internet 1.5 Mbps access link avg. total delay = Internet delay + access delay + LAN delay =.6*(2.01) secs + msecs < 1.4 secs origin servers 10 Mbps LAN cache

Conditional GET Goal: don t send object if cache has up-to-date version cache: specifies date of cached copy in HTTP request If-modified-since: <date> server: response contains no object if cached copy is up-to-date: HTTP/1.0 304 Not Modified cache May be used with or without TTL, TTL hard to set, depends on site content HTTP request msg If-modified-since: <date> HTTP response HTTP/1.0 304 Not Modified HTTP request msg If-modified-since: <date> HTTP response HTTP/1.0 200 OK <data> server object not modified object modified Cooperative Caching Multiple caches may form a distributed cache Instead of going directly to origin cse cache server, a cache may query one or more other caches for object first, e.g., cse cache queries ece cache first cse public Internet origin servers To eliminate frequent inter-cache query-reply, each cache may push an index of its contents to other caches, i.e., ece cache tells cse cache all the objects it is holding Frequently, this index is in the form of a Bloom Filter ece ece cache Bloom Filter An efficient, lossy way of describing a set, comprising: a bit vector of length w a family of independent hash functions each maps an element of the set to an integer in [0, w) search: insert: To insert an element: for each hash function, set the bit the element hashes to search: To search for an element: for each hash function, examine the bit the element hashes to if any bit is not set, the element is definitely not in the set if all the bits are set, the element may be in the set (potential for false positive) Bloom Filter The false positive rate is a well-defined, linear function of: 1. width(w), 2. the number of hash functions, and 3. the number of elements in the set wider filters are always more accurate optimal tradeoff between filter storage and accuracy is when about half of the bits are set Bloom Filters also useful in maintaining p2p supernode backbone and distributed storage in data center network

Variable Delay browser cache DNS resolution TCP open Sources of variability of delay 1 st byte response browser cache hit/miss, need for cache revalidation DNS cache hit/miss, multiple DNS servers, errors Last byte response TCP handshake, packet loss, high RTT, server accept queue RTT, busy server, CPU overhead (e.g., CGI script) response size, receive buffer size, congestion Limitations of Web Caching Significant fraction (>50%) of HTTP objects are not cacheable Why not? dynamic data: stock prices, scores, web cams scripts: results based on passed parameters use of cookies: results may be based on passed data advertising / analytics: owner wants to measure #hits random strings in content ensure unique counting HTTPS: encrypted data is not cacheable multimedia: object larger than cache or not allowed to be cached due to intellectual property rights How to ensure scalability of web server when content is not cacheable? Content Distribution Networks (CDNs) Streaming large files (e.g., video) from a single origin server in real time requires large amount of bandwidth Solution: replicate content to hundreds of servers throughout the Internet place servers in edge/access network content pre-downloaded to servers when user downloads content, direct user to the server closest to it placing content close to user avoids network delay and loss of long paths CDN server in S. America origin server in N. America CDN distribution node CDN server in Europe CDN server in Asia CDNs vs. Content Owners Maintaining your own network of such servers is expensive (both CAPEX and OPEX) CDN providers maintain a network of servers and sell content replication service to multiple content owners example of content owners: ABC, HBO, Netflix example of CDN providers: Akamai, Limelight Akamai has ~25K servers spread over ~1K clusters world-wide CDN replicates owners content in CDN servers When owner updates content, CDN updates servers Some large content owners operate their own CDNs: Amazon, Google/YouTube, Netflix (virtual)

Sample Delivery (Example Only) Why don t we store index.html and shirtad.gif at the CDN also? shirtad.gif www3.cdi.ex stadium.mp4, tvlogo.mp4 www1.cdi.ex index.html, logo.gif shirtad.gif index.html, logo.gif www2.cdi.ex stadium.mp4, tvlogo.mp4 Content Distribution Network CDN nodes create applicationlayer overlay network Larger CDNs may have their own WANs, e.g., Google s B4, that interconnect with the rest of the Internet like any other ISP s network CDN directs a request to the server closest to the client (how?) Tier-1 Backbones IXPs ISPs CDNs: e.g., Akamai, Amazon, Google [after Walrand] Access Aggregators [Frank13] Client Redirection How to direct clients to a particular server? As part of application: HTTP redirect pros: application-level, fine-grained control cons: additional load and RTTs, hard to cache As part of naming: DNS pros: well-suited to caching, reduce RTTs cons: relies on proxies and estimations, not accurate DNS-based Redirection Clients are directed to the closest server as part of the DNS name resolution process: 1. client asks its local DNS resolver to resolve CDN s server s name 2. the local DNS resolver is directed to CDN s authoritative name server by DNS 3. CDN s name server either returns the address of server closest to the DNS resolver or an ordered list of addresses, ranked by distance to local DNS resolver Pros and cons of each?

CDN Example 2 5 origin server 1 4 nearby CDN server HTTP request for home.ex/index.html contains cdi.ex/stadium.mp4 client s local name server 3 DNS query for cdi.ex DNS query for cdi.ex CDN s authoritative DNS server HTTP request for cdi.ex/stadium.mp4 Server Selection How to choose which server to direct a client? server load client-server distance CDN maintains a map, estimating distances between access ISPs and CDN nodes CDN s name server uses map to determine server closest to the local DNS resolver DNS resolver used as proxy for client inaccurate location CDN doesn t know client s address at name resolution time distance can be measured using different metrics, e.g., latency, loss rate only estimated delivery cost (ISP pricing)