Presentation is loading. Please wait.

Presentation is loading. Please wait.

Web acceleration: PoP Infrastructures

Similar presentations


Presentation on theme: "Web acceleration: PoP Infrastructures"— Presentation transcript:

1 Web acceleration: PoP Infrastructures
Erv Johnson Director of Technical Marketing ArrowPoint Communications May 9, 2000 (978)

2 Summary Looking at the big picture
Analysis of network topologies and web interactions Potential sources of delay Technologies that can mitigate this delay.

3 How Delayed Binding Works
Step 1: User clicks: - Browser talks to DNS for IP Address - Browser sends TCP SYN (connect?) Internet Step 2: Switch Sends TCP SYN ACK to browser Step 3: Browser sends URL: Step 4: Switch determines Best Server for the content being requested Step 5: Switch connects to Best Server and “splices” TCP connection Current Layer 4 switches and load balancers, route incoming requests based on the combination of destination IP address, and TCP port. They immediately “bind” a Web browser to a Web server based on the initial TCP SYN request. Therefore the content request is routed before the switch receives the actual HTTP request, making it incapable of optimizing flows based on URL. This can be problematic in a Web environment. To a Layer 4 load balancer, all Web applications appear to be using TCP port 80 (well-known port for HTTP), making them indistinguishable from one another. Therefore, a CGI request looks no different from a Web-enabled SAP application or streaming audio request, even though all of these requests have very different requirements or may be found on different servers. In contrast, Web switches use URLs to route incoming requests to target servers. By looking deep into the HTTP payload, down to the URL and cookie, a Web switch “knows” what content is being requested. This provides unprecedented flexibility in defining policies for security and traffic prioritization – enabling tiered services and ensuring Service Level Agreements are met. Further, the ability to use cookies enables sticky connections – a critical requirement for e-commerce. There are 5 basic steps involved in web switching: 1. User makes a content request by typing a URL into a browser. 2. Web switch with virtual IP of the requested URL intercepts the request. 3a. Web switch spoofs TCP ACK back to client. 3b. The Web switch examines HTTP header and URL and compares to current content rules to select best server or cache to satisfy the request. 4. A flow is created between the switch and the optimal server and “snaps” together with the flow from the client to the switch. 5. All subsequent packets for that Web flow are forwarded without intervention by the switch controllers. Step 6: With HTTP 1.0 there is one HTTP request/response per TCP session With version 1.1, there can be many GETs per TCP session

4 What is Content Intelligence?
Content Routing based on: Host Tag Entire URL Dynamic Cookie location File extension # of rules # of services # of services per content rule Layer 5-7 (content) Session load balancing based on IP address and TCP port Network Address Translation (NAT) Policies based on TCP port Layer 4 (TCP) Switching on MAC address, VLANs IP Routing 802.1 P/Q policy Layer 3 (IP) ArrowPoint Web switches are unique in their ability to perform content discovery, the key to achieving content or name-based switching. Content discovery requires: 1) spoofing the TCP using the entire URL and cookie; 2) providing content based keep-alives to detect changes in content; 3) probing the server automatically to determine content attributes then dynamically selecting the best connection for the keep alive. Conventional load balancers and Layer 4 switches were designed for address-based switching, and differentiate applications based on identity of well-known TCP ports: Port 80 for HTTP and Port 21 for FTP. However, even as more and more information is based on HTTP requests, load balancers cannot differentiate between multiple HTTP requests for different content. ArrowPoint’s Web switches were designed for name-based switching and are the only switches to use the entire URL and cookie to select the best site and server.

5 Applications Local and Distributed Content Routing Internet
Select Best site/server Route HTTP request to best location Deliver content from best location Push/pull content from origin server Customer Web Site Internet Boston PoP London PoP Atlanta PoP San Jose CS-150 CS-50

6 Local Server Selection Methods
Select server group based on URL/cookie, other Select “best” server based on response time Build normalized load factor for every server Send requests to fastest server having the requested content Internet With a combination of high speed HTTP flow setups and URL routing, ArrowPoint goes beyond traditional load balancing. ArrowPoint provides the broadest selection of server selection rules, but only ACA automatically balances the load based on actual server response time at any given point in time, with no user intervention. Because content requests are directed based on the URL, redirection of HTTP requests can be off loaded from the Web server. For example, a CGI request can be sent directly to the CGI server rather than being sent to the main HTTP server and then redirected. In fact, Web servers are further optimized by only handing TCP connections and HTTP requests once the switch determines it to be the best source for the requested content. ACA monitors the flow until it sees a TCP FIN message from the server, at which point the switch creates a tear down report containing statistics for the flow. This allows the switch to aggregate statistics which can be the basis for service level agreements and billing. There is a dedicated slide on SLAs and management statistics later in the presentation. Traditional load balancers and L4 switches use simple static methods for distributing server load, including Round Robin and Weighted Round Robin. They can also use (Least) session connection count to measure server load, but this is limited in several respects. Least connections misses the significant difference in actual server performance between processing 100 HTTP requests for the home page and processing 100 HTTP requests for CGI or ASP pages. Also, in the Internet, session connection count is misleading and inaccurate for TCP traffic where the TCP inactivity timer is very long, leaving most TCP circuits in WAIT-state when the connection is idle. ArrowPoint supports all of these algorithms, and in certain situations they can be useful. For instance, servers processing ASP requests may perform with consistent response time up to a point, but then hit the wall. In this case distributing load using a Least Connections rule would be appropriate with a MAX connections limitation. *.html Other methods Weighted Round Robin Least Connections Max connections limits *.ram *.cgi

7 Content and Application Verification
Web Server (IP Address) IP ICMP Ping/Echo Application (TCP port) TCP connect/acknowledge Scripting: TCP connect - request - reply - verify Content (URL) HTTP request, response verification Verifies back-end resources Secure content HTTPs request, response verification Internet ArrowPoint can test server availability using Layer 3 and Layer 4 techniques, plus ArrowPoint can test HTTP GETs, POSTs, and HEADs, comparing the complete response and detecting the most minute change in content. And in the event of a failed HTTP keep alive, the ArrowPoint switch will direct only requests for that particular content or application to another server, continuing to utilize the server for surviving content, application, or services. For example, if a back end cgi process is not responding there is no need to remove the server from rotation for serving HTTP requests for the Home page.

8 E-transaction Assurance
Using cookies optimizes E-transactions Cookie-based sticky connections for non-encrypted transactions Cookie-based priority for users and transactions SSL session ID can be used for sticky connections Must be able to ensure seamless transition between secure and non-secure Internet In order for an e-commerce transaction to be successful, clients must be bound, or "stuck" to a specific server until the transaction is complete. Maintaining persistent connections to a server, called "sticky" connections, is the key to any money-generating e-commerce Web site. ArrowPoint's competitors provide load-balancing solutions that base server connections on IP address parameters. This approach does not scale. ArrowPoint provides the ability to configure persistent connections based on cookies or SSL session IDs, thereby maintaining sticky connections. Having the ability to maintain persistence on cookies, called "cookie-switching," optimizes non-encrypted e-commerce transactions. ArrowPoint Web switches can access information deep in the TCP and HTTP headers, including "mobile" cookies that change location within the header between requests. The most common method of securing Web-based transactions is the use of the popular SSL protocol. Maintaining persistence based on SSL session ID optimizes the integrity of e-commerce transactions and provides a balance between security and performance. In a secure transaction, the Content Smart™ Web switches maintain state during the transition from the user cookie (shopping) to the SSL session ID (checkout), ensuring a successful and secure user transaction. Server 1 Server 3 Server 2

9 Transparent Caching with Content-based rules Bypass
Internet Origin Server Network Cache Transparent - no browser configuration required Improves performance by bypassing cache for non-cacheable content or cache failures Content policy allows include, exclude (bypass), or block actions based on Access Control Lists Based on IP address, TCP port or URL First, instead of just diverting all HTTP (port 80) to the cache, content aware switches inspect the HTTP header to learn about content, so they can bypass the caches entirely for non-cacheable URLs and transmit them directly to the origin server. This maximizes cache hit rate and request/response latency because the cache is caching only cache-able content, and is bypassed completely for non-cacheable requests, or if all of the caches are overloaded. The ArrowPoint switch can also be configured to bypass the cache for any particular domain name and URL, providing more granular control to exclude all or part of a particular customer's content from being diverted to the cache. Proxy caches can be clustered for scalability and redundancy, but the cache cannot be bypassed, since the browser is explicitly defined to talk to the cache. Only ArrowPoint can also bypass Reverse Proxy can be bypassed. Read on...

10 Web Caching Performance with Content-based Cache Bypass
More than 4 times Faster URL rules Layer 4 rules Connections per second In the real world, a significant amount of HTTP requests are for non-cacheable content (as much as 35-45%), including URLs for objects which are dynamically, generated such as CGI scripts and Active Server Pages (ASP), or URLs carrying cookies. Every time these requests are sent to the cache, the cache introduces significant latency and unnecessary processing in evaluating the request, fetching the content from the origin server, and then sending the response to the client. Thus, the hit rate and performance of the cache is inversely proportional to the amount of non-cacheable content sent to the cache. ArrowPoint's content-aware cache bypass mechanism ensures minimum latency and maximum cache hit rate and efficiency, by bypassing the cache for non-cacheable URLs, and sending them directly to the origin server with the client's source IP address. The cache then can apply all resources to serving requests for cacheable content. This fact is dramatically illustrated by a test conducted by ArrowPoint which compared the performance of a layer 4 switch and a ArrowPoint CS-100 Content Smart Web Switch in a transparent caching configuration. The test simulated 180 clients generating HTTP requests and measured the performance impact on the “virtual POP” as the percentage of cacheable content was decreased. % cacheable content

11 Digital Product Distribution and Delivery
San Jose Web hosting Data Center “mymusic.com” HQ Web site Boston Distribution Center Internet Client Requests MP3 file London Distribution Center Paris Distribution Center HQ switch determines best site “Best” distribution site delivers MP3 file Switch delivers New MP3 inventory


Download ppt "Web acceleration: PoP Infrastructures"

Similar presentations


Ads by Google