Akamai Diversity
Home > Stephen Ludin

Recently by Stephen Ludin

Where is my HTTP/2 Performance?

This blog post is part of an ongoing series where we will discuss a wide range of H2-related topics. In today's post, we talk about some of the misconceptions regarding HTTP/2 being a silver bullet for improved website performance. 

HTTP/2 Turns One: Farewell to SPDY

Akamai was the first CDN to support HTTP/2. This blog post is part of an ongoing series where we will discuss a wide range of H2-related topics. In today's post, we are boding a fond farewell to SPDY.

How Has Let's Encrypt Impacted Web Security?

When Let's Encrypt was founded at the end of 2014 it had a lofty goal: promote the use of TLS everywhere by making certificates free and server configuration painless.  It was noted that for many web administrators, for both large and small sites, TLS was seen as expensive, difficult to configure, and slow.  With that headwind, the return on investment was seen as too low to bother unless you were handling financial or other sensitive information.  As it does, web security quickly evolved in the ensuing years.  Firesheep, Snowden, and Google page ranking: these are just a few things that have changed how people think about the importance of encrypting everything online.  And services like Let's Encrypt and Akamai deal with the problems head on, reducing the pain of Internet security tremendously.

How to Start Optimizing in an H/2 World

If there was ever a truism it is that technology is rapidly evolving under our feet.  What was right today, is likely to be sub-optimal tomorrow.  This situation can cause a sense of paralysis leading to delayed action because next week the "Next Great Thing" is coming soon.  With the advent of HTTP/2 (h2) that translates to holding off on optimizing your web properties.  When you have large portions of your user base on h2 and a similarly large portion on h1, you need to double your efforts to keep up!

Is HTTP/2 worth the performance price of TLS?

HTTP/2 (h2) is incredibly exciting: The first major rev to HTTP in 15 years, focused on modern web development, performance minded, etc., etc.  But one thing that has people looking at it with trepidation is that to use it you effectively need to move your site over to TLS (i.e. HTTPS).  Though not a requirements in the protocol, no major browser has plans to put h2 in the clear.  Whether you think this is a good thing or a bad thing ( I personally am thrilled ) it brings front and center the questions you may have been avoiding: should I move my site to TLS? We have done extensive testing of h2 performance.  Akamai's Foundry team spent time after every significant revision of the draft specification seeing what worked and what did not.  What we saw was consistent: improvements in page load time in the common case between 0% and 25%.  What is significant about these particular numbers is they are comparing an HTTP version of a site against an HTTPS version using TLS and h2.  In other words, the 'goodness' of h2 should make up for the overhead of TLS and then some in most cases.  Performance can be very situational, so mileage will vary in specific scenarios and on specific webpages, but it is exciting to see improvements on the horizon.


Stephen Ludin is a Chief Architect for Akamai's Web Experience group. He currently heads the company's Foundry team - a small group dedicated to innovating on the edge of technology. He joined Akamai in 2002 and works out of Akamai's San Francisco office. His primary focus has been on projects related to the core proxy technology that is responsible for routing, accelerating, and securing Akamai's traffic.

With HTTP/2, Akamai Introduces Next Gen Web

In early 2012 something remarkable happened: a call went out for proposals for a new version of HTTP. From the perspective of an Internet whose warp and weft seemingly shift on a daily basis, this may appear to be just one change amongst many, but because of the importance of HTTP in our daily lives, its impact is difficult to overstate. If you are reading this, it is likely your current job and livelihood would not exist without HTTP. And now, with this call for proposals, the community was about to start work to change and improve that venerable protocol.

HTTP/2.0 - What is it and Why Should You Care?

An Aging Standard

HTTP is old.  How old?  Let's look at a timeline to start:

1991 - HTTP/0.9
1996 - HTTP/1.0
1999 - HTTP/1.1
2013? - HTTP/2.0

Our beloved protocol that has been powering the information age in which we all live has been kicking around for over 21 years. Further, it has not had a major version change in 13!  Using the dog year's metaphor, this puts the invention of HTTP back in the colonial time of the Internet (I have a marvelous proof of this but limitations to the margin property prevent me from including it). It is a rare occurrence when something can stand the test of that sort of time and remain relevant.  Even the United States Constitution has needed a few major tweaks in that time (27 in all). So it should come as no surprise that the current version of HTTP is showing its age.

But before I list off HTTP's deficiencies, let me take a moment to reflect on the wonder of "the Little Protocol That Could."  It is highly likely that every one of you reading this blog would not have the job you have today if not for HTTP. Think of the evolution of a "web page" since 1991. Think of the elements that we today take for granted that were never envisioned back when HTTP first displaced Gopher for file retrieval. The very fact that HTTP has been able to adapt to the rapidly changing web and power our modern marketplace is a testament to the brilliance of the protocol.  

That said, it seems that web developers have been holding HTTP together with dental floss and glue for a number of years. We have desires for "instant" page rendering and good old HTTP/1.1 is seen as one of the bottlenecks.


HTTP is Dead - Long Live HTTP

SPDY and WebSocket Support at Akamai

Now, more than ever, time is money. The four two second rule is a thing of the past and companies today are not simply looking at performance as a specific bar to get over, but rather as an element that has a direct effect on their conversion rates. Akamai has supported this view this for a long time, and to that end have continually come up with new technologies to make the web faster.  End-user expectations do not stand still, and neither will we.

That is what drove us to develop and announce the upcoming SPDY and WebSocket support at the recent 2012 Santa Clara Velocity conference. We have been working with and developing these protocols for a while now and are excited to bring them to our network.  It is a fascinating time in the web world and SPDY and WebSocket are central themes in the raging debates around the direction of the basic protocols that make everything tick. Recently this pair of protocols has been cast as somehow competing for a virtual crown in a race to see who will win a standards war. Here at Akamai we see this as far from the case, and believe that looking at them through that sort of lens will distract from the basic fact that they are two tools for two jobs.

SPDY

SPDY (pronounced speedy), for those who are not familiar with it is a proposal and implementation from Google for a faster version of HTTP. SPDY achieves its performance boost through a number of optimization such as request multiplexing, using fewer connections, and header compression to name a few.  Benchmarks generally show that SPDY consistently improved a web page performance by 10-20%. In our millisecond mattering world, that is huge and worth taking notice.

Akamai's initial SPDY implementation will be targeting version 2 of the protocol.  End users with SPDY speaking browsers will be able to converse with our secure edge network (ESSL) using this latest and greatest web development starting this fall.

Not Pixie Dust

Recent studies, particularly one from at Akamai, show that SPDY is not some magical engine that will remove all of the bottlenecks a web site might have. Do not take our criticism of SPDY as an indicator that we are not supporters of it. On the contrary, we believe in the direction and want to see it get better and better. Different bottlenecks require different solutions, ranging from better caching and route decisions to addressing third party content and Front-End Optimization. For the cases where HTTP between client-and-edge is holding you back, SPDY will come to the rescue.

At Akamai we aim to offer the complete set of tools to address each bottlenecks, and will help you use the right tool for the right job. We're excited to add SPDY to this suite, and help push the web forward.