La transition vers HTTP/2, l'envisager, s'y préparer, la réaliser
HTTP/2 est désormais un standard avec son support intégré dans les browsers modernes. Les serveurs Web, proposent aussi dans leurs dernières versions, la compatiliblité avec cette évolution. Ce qu'il faut retenir est qu'HTTP/2 vient accéler le transport du contenu Web en maintenant la confidentialité à travers SSL. Un des bénéfices pour les developpeurs et fournisseurs de contenu est la capacité à se rendre compte des apports de ce protocole sans remettre en cause toute son infrastructure. Les démonstrations montrent bien les gains à travers un browser sur un ordinateur portable, choses encore plus appréciables sur les plateformes mobiles. La version 12.0 de TMOS permet de se comporter comme un serveur HTTP/2 vis à vis des clients tout en continuant à solliciter le contenu en HTTP/1.0 et HTTP/1.1 auprès des serveurs. Pour trouver des raisons de s'interesser à ce protocole, plusieurs sources d'information peuvent y aider : Making the journey to HTTP/2 HTTP/2 homeWhiteboard Wednesday: Basic F5 BIG-IP Nomenclature
In this neck of the woods, we have historically primarily focused on deep dives into the programmability features in the BIG-IP. We break occasionally from this mold, and we're constantly requesting feedback on how to better meet the needs of the community. In recent surveys, both online and in person at conferences, we are getting more requests for the low hanging fruit--basic nuts and bolts of how the product works. To an extent we have done this with some of our more popular series of articles like the SSL and TCP profiles, the basics of F5 BIG-IP Application Security Manager, and our introduction to F5 BIG-IP Application Acceleration Manager (formerly WebAccelerator.) I say all that to say...we hear you. And we want to start with a bare bones understanding of the product nomenclature. In this video, Jason Rahm and John Wagnon discuss some of the foundational objects of the BIG-IP: interfaces, vlans, self ips, nodes, pools, and virtual servers. This video is an overview of these topics. For details please see the resources below. So…what other basic nomenclature would you like us to talk about? Route domains? Auto-lasthop? Host/TMM relationship? TMOS fundamentals? Drop a comment below and let us know! Resources Self IP Vlans & Vlan Groups Manual Sample Implementation with Link Aggregation Nodes Pools Virtual Servers
F5 Synthesis: Your gateway to the future (of HTTP)
#SDAS #HTTP #webperf #SSL De facto standards can be as difficult to transition off of as official ones If you haven't heard about HTTP 2.0 it's time to start paying attention. It is anticipated that in November the latest version of the specification will become "the standard" for applications. It includes enhancements designed to improve the security and performance of web applications, which have become critical strategic components to just about every organization on the planet. Go ahead, name an organization that doesn't rely on at least one web-based application to conduct business today. Exactly. Performance and security being imperatives along with the presence of applications means that HTTP 2.0 should be a welcome addition to the family of Internet protocols. But it will likely be met with some amount of trepidation by those tasked with supporting it on the data center side of applications because one of the downsides of updating standard protocols after so many years (HTTP 1.1 was ratified in RFC 2616 in 1999) is that they're rarely compatible. That's because in technology years, that 15 years is more like 75 years. Consider for a moment IPv6, which was officially standardized way back in 1995 (RFC1883). Yes, I said 1995. Before the great dot bomb. Before Web 2.0. Before mobile apps. And how's that been going for us? Well, as of May 2014 more than 96% of all Internet traffic was still carried via IPv4. Go ahead, read that again because you're right - a 4% adoption rate over nearly 20 years is somewhat hard to swallow, isn't it? But, you might think, IP affects everything. We're only talking about apps, here. And web apps, at that. Well, let's consider that for a moment. According to our data, 65% of all apps are delivered via HTTP right now. in other words, HTTP is pretty darned important to app delivery and it'd be pretty hard to convince someone to upgrade all the things that need upgrading in order to support HTTP 2.0 (particularly with its requirement for encryption via SSL or TLS). And yet major browsers (and consumer demand for speed, more speed and even MOAR SPEED) are already pushing adoption by broadly supporting SPDY (the protocol upon which HTTP 2.0 is based and which is the primary cause behind compatibility headaches). According to this site, which tracks SPDY adoption across browsers, all major browsers already have at least partial (if not full) support for SPDY. They're ready to go. The app side? Not so much. That's where an app gateway comes into play. App Gateway: Bridging the Old and the New Like IPv6, the answer to the conundrum of transitioning from one protocol to another is a gateway. In the case of HTTP, it's an app gateway because HTTP is an app layer protocol. In the latest release of the ADC platform on which F5 Synthesis High Performance Services Fabric is built we've included both SPDY 1.3 and HTTP 2.0 support, enabling a gateway architectural approach to supporting the latest (soon to be) standard and the existing, more prominent one. This architectural feat is accomplished by way of BIG-IP's full proxy architecture, which lets our ADC speak one version a protocol on the outside (the client) and another on the inside (to the app). But what about all that security stuff you might ask. The requirement for SSL and TLS is as disruptive as the changes to the core protocol, after all. You're right, it is, but again - the nature of being a full proxy means we can support SSL or TSL on the outside and plain old HTTP on the inside, sans encryption. While some organizations require end-to-end encryption of all traffic, those that don't will benefit from the ability to leverage client-side (outside) encryption without doing so on the inside (server-side) where lots of Layer 4-7 services may need visibility into traffic to do their respective jobs. Using a gateway approach also enables a mix of HTTP 2.0 and HTTP 1.x on the inside (server side). That means organizations can take a transitory approach to adoption of the latest app protocol, moving if and when it seems most prudent based on upgrade and refresh cycles, not standards body meeting schedules. The performance and security (and let's not forget business) benefits to moving to HTTP 2.0 with its SSL/TLS requirements and improvements in core transport of data between client and server are worth exploring. But it's understandable that a protocol so entrenched like HTTP 1.x is not easily ripped out and replaced with something new. Taking a gateway approach to adoption enables organizations to support the old while exploring the new and making sure that consumers and employees using the latest and greatest browsers will be able to enjoy improved performance and productivity. Additional Resources: F5 Synthesis Demo of F5 HTTP 2.0 Gateway with Sr. Product Manager Dawn Parzych @ Velocity 2014Why think about HTTP 2.0?
#webperf #HTTP #mobile The problem with web application performance is directly related to the increasing page size and number of objects comprising pages today. Increasing corporate bandwidth (the pipe between the Internet and the organization) doesn't generally help. The law of diminishing returns is at work; at some point more bandwidth (like more hardware) just isn't enough because the problem isn't in how fast bits are traveling, but how many times bits are traversing the network. And for some clients - like mobile - it doesn't matter. They're getting 1-4Mbps and there's nothing you can do to change that. The problem is HTTP isn't utilizing TCP efficiently, and thus the round trip - the time it takes for clients to talk to the application - is almost always the real culprit when looking for the source of web application performance issues. Especially for mobile clients, where a round trip carries with it an average latency of 150-300 ms. More efficient use of TCP, better connection management, compression and other acceleration techniques are a must if we're going to really address web application performance. And that's what HTTP 2.0 is designed to do.Hourly Licensing Model – F5 delivers in AWS Marketplace
#cloud #SDAS #AWS And you can try it out for free... June 30, 2014 (The Internet) Today F5 Networks, which delivers solutions for an application world, announced it had completed jumping through the hoops necessary to offer an hourly (utility) billing model for its BIG-IP VE (Virtual Edition) in the Amazon Web Services (AWS) cloud. Not only has F5 announced availability of the industry's leading application delivery services for deployment in AWS with a utility billing model, but the offering includes a variety of options which organizations can take advantage of: Three sizes of BIG-IP VE including 25 Mbps, 200 Mbps and 1Gbps. Two BYOL (Bring Your Own License) options as well as a modular option A free 30 day trial offering with Best licensing and 200 Mbps of throughput BIG-IP VE for AWS includes not only the industry's most trusted load balancing service but also the following capabilities and Software Defined Application Services (SDAS) designed to protect and enhance application security and performance: An integrated WAF (Web Application Firewall) DDoS Protection Caching, compression and acceleration Advanced Load Balancing Algorithms including least connections and weighted round robin. Additionally, BIG-IP VE for AWS supports the use of iApps for rapid provisioning in the cloud or on-premise. iApps are application-driven service templates that encapsulate best practice configurations as determined by lengthy partnerships with leading application providers as well as hundreds of thousands of real deployments across a broad set of verticals including 94% of the Fortune 50. The availability of BIG-IP VE for AWS further supports F5 Synthesis' vision to leave no application behind, regardless of location or service requirements. Through Synthesis' Intelligent Service Orchestration, organizations can enjoy seamless licensing, deployment and management of F5 services across on-premise and cloud-based environments. The availability of BIG-IP VE for AWS extends F5 service fabric into the most popular cloud environment today, and gives organizations the ability to migrate applications to the cloud without compromising on security or performance requirements. To celebrate this most momentous occasion you can try out BIG-IP in the AWS marketplace for free (for 30 days) or receive $100 credit from AWS by activating participating products between July 1 and July 31, 2014: These offers apply to the F5 BIG-IP Virtual Edition for AWS 200Mbps Hourly (Best) through AWS Marketplace: 30 Day Free Trial Available The BIG-IP Virtual Edition is an application delivery services platform for the Amazon Web Services cloud. From traffic management and service offloading to acceleration and security, the BIG-IP Virtual Edition delivers agility - and ensures your applications are fast, secure, and available. Options include: - BIG-IP Local Traffic Manager, Global Traffic Manager, Application Acceleration Manager, Advanced Firewall Manager, Access Policy Manager, Application Security Manager, SDN Services and Advanced Routing, including support for AWS CloudHSM for cryptographic operations and key storage. AWS – Offer (Credit) Customers who activate a free trial for any participating product (that includes F5 BIG-IP) between July 1 and July 31, 2014 and use the product for a minimum of 120 hours before August 31, 2014 , will receive a $100 AWS Promotional Credit. Limit two, $100 AWS Promotional Credits per customer; one per participating software seller. . For more information: F5 Synthesis F5 Solutions Available in the AWS Marketplace F5 BIP-IP Virtual EditionsA Tale of Testing, SPDY, browsers and the other F5.
You shouldn't be surprised to learn that when we create Reference Architectures we actually test them. The settings you find in the Configuration Best Practice Guides have been created, tested and documented pretty carefully to work well in most environments. Recently I've moved my testing environment to a new cloud provider. It's a great service, providing exactly what you need from a cloud: elasticity, speed, and ease of use. I don't need to ask anyone to create me a new network, or provision me a server, and I've got access to a cool catalog of application and infrastructure images. My first job was to recreate my application acceleration test rig. Not a problem, I've documented the setup and it's deliberately simple - my reference architecture is big on returns and small on investment (in both your time and money). In an hour or so I have my design up and running - this cloud stuff is a real boon for the lazy. Now to run some testing. Hmm. That's not right - my acceleration test page is being pretty inconsistent - it's sometimes only marginally faster than the baseline un-accelerated version. Now I know from my previous test results this setup, despite being pretty simple (TCP optimization, SPDY gateway and a very basic layer 7 acceleration policy) can give good, measurable improvements. To be honest, at this point I'm starting to worry. I'm about to push out a reference architecture that suddenly isn't working right. So back to my help desk and sysadmin days (see, I used to have a proper job). First thing to check when something breaks - what have you changed? In this case the list is quite long - I've moved environments entirely, I'm using a different version of the web server O/S and a different WAN emulation component, plus I've altered my test page to have more JavaScript. The only thing that's 100% the same is my BIG-IP version and configuration. Looks like I’ll have to actually work out what’s going on. Now I’m of the opinion that any time you are breaking out analysis tools like Wireshark or HTTPWatch (both excellent tools, of course) you’re having a bad day. But in this case there seemed no alternative. Running the tests on a new browser session – the SPDY advantage is clear – all the images load almost concurrently and the trace shows all the page objects being loaded together. However when I’ve used CTRL + F5 to reload the page without the browser cache the behavior has reverted to the classic HTTP 1.1 waterfall with a few objects being requested in parallel, then another few. No wonder my test results bad. Shutting down the browser and reloading the page restores the proper SPDY behavior, my test page loads about twice as quick through the accelerated config. I’m going to test this behavior out some different versions and browsers, but for now I can sleep at night knowing that our forthcoming acceleration Reference Architecture actually works and I’ve learnt some valuable testing methodology lessons.Web Accelerator / AAM – fonctionnalité IBR
Faisant suite à la vidéo de découverte du module WA / AAM (https://devcentral.f5.com/s/articles/dcouverte-de-web-accelerator-aam-7341), voici une vidéo présentant l’une des principales fonctionnalités du module WA / AAM. Cette fonctionnalité nommé IBR - Intelligent Browser Referencing – permet d’optimiser le cache côté client. Le BIGIP va modifier les informations de cache control et va modifier le contenu web afin que les navigateurs gardent en cache les objets bien plus longtemps que prévu initialement par le serveur WEB. Un mécanisme de réécriture permet d'éviter les faux positifs au niveau du cache. Voici l’explication et la démonstration en images.Web Accelerator / AAM – fonctionnalité Multi-Connect
Faisant suite à la vidéo de découverte du module WA / AAM (https://devcentral.f5.com/s/articles/dcouverte-de-web-accelerator-aam-7341), voici une vidéo présentant la fonctionnalité Multi-Connect. Il faut savoir qu’un navigateur ne peut télécharger qu’entre 6 à 9 objets simultanément par hostname. Donc si une page comporte 18 objets, il faudra ouvrir 3 connections les unes après les autres. La fonctionnalité Multi-Connect permet de passer outre cette limite en modifiant le hostname joint par le client. Une vidéo vaut mieux qu’un long discours. L’explication en images.Découverte de Web Accelerator / AAM
Web Accelerator, renommé AAM à partir de la release 11.4, est un module malheureusement peu connu de nos clients et partenaires. Pourtant, celui-ci a de quoi séduire. Son rôle est simple, c’est une “Reverse Proxy Cache & Optimization”. Voici une liste non exhaustive de ses capacités et de ses fonctionnalités : Mise en cache du contenu web des serveurs dans le disque dur et la RAM du BIGIP. Réécriture des headers de “Cache Control” et du contenu web afin d’optimiser le cache côté navigateur client Optimisation du code source HTML afin de supprimer tout code superflu Optimisation des images par conversion ou compression Et bien plus encore … Cette vidéo vous permettra de comprendre son fonctionnement et surtout d’être capable de créer votre première politique d’optimisation WA / AAM. Vous trouverez ensuite les autres vidéos autour de WA / AAM sous le tag “france”.Caching, CDNs and Optimization: a bit like a trip to the store.
We know that people like fast websites. So how do you speed yours up? Recently I’ve been having conversations with customers and my colleagues in the field about caching appliances, content delivery networks (CDNs), and web application optimization. What’s the best approach? Caching appliances place the most commonly requested objects in a cache upstream of the origin web servers. Objects (like images, JavaScript files etc.) requested by browsers can be served straight from cache without ever hitting the backend servers. CDN’s go a step further, they place commonly requested objects into multiple caches around the world with the aim to position the objects as near as possible to the browsers. Web application Optimization solutions use a range of tools and techniques to deliver applications more effectively, by doing things like shrinking content and manipulating browser caches (and there I’ve just oversimplified the life’s work of a number of F5’ers, but this blog is all about trying to make things simple so bite me Dawn Parzych.) After a long and technical debate I’ve decided it all comes down to a trip to a grocery store. Hang with me readers, I’m 70% sure this is all going to make sense. Caching appliances simply put the most common things you need at the edge of the parking lot. It’s all the same size as it was in the store, but it’s a little bit closer and you don’t clog up the aisles. You still have to head back to the store after a few hours to check your food is still in date. Good for the store, not so useful for you. CDNs deliver your shopping most of the way home, but then charge the store every time you check your food is still fresh. Good for you, not so hot for the store who get faced with extra charges. Plus the shopping still takes up as much space as it did before. Web application optimization tools (like Application Acceleration Manager) shrink the size of your shopping, remove the excess packaging you don’t need and then let you know when it’s out of date. More of your shopping stays fresh for longer and it can even make your drive home faster. Just as I’ve tried to simplify some of the choices for web application acceleration, we’re shortly going to release a new reference architecture to make actually implementing web application optimization just as easy.
