This blog is the third in a 5-part series on APMdigest where I discuss web application performance and how new protocols like SPDY, HTTP/2, and QUIC will hopefully improve it so we can have happy website users.
Common HTTP/1.1 Workarounds
Regarding the HTTP/1.1 limitations outlined in my last blog, it was known that an update was needed to address them. But this did not happen, until recently. With the need for better performance, a number of workarounds were created to get around the limitations.
Open Multiple Connections
As web technology developed, it became clear that more connections were needed to help improve web performance by opening up more than one connection to the server at the same time. For years, Internet Explorer allowed only 2 concurrent connections. As Firefox and Chrome entered the scene, this number went up to 6.
At this point, most modern browsers allow for 6 concurrent TCP connections. All of these connections will help to reduce the impact of TCP slow start on the overall website.
With the ability to have multiple connections to the server, developers soon realized that they could improve performance if website resources were placed on various domain servers. They would then be able to allow for up to 6 concurrent connections for each domain.
The content for a website, domain.com, for example, could be spread across three domains - one.domain.com, two.domain.com and three.domain.com.
With this configuration, a browser can now have up to 18 concurrent connections to make HTTP requests!
What's better than having the browser open up more connections across many domains? Using those same connections to send more data.
In my previous blog, Web Performance 101: 4 Recommendations to Improve Web Performance, I mentioned that you don't want to have too many connections. With 18 connections from one browser to 3 domains, the PC may run into some resource issues. Opening and closing more connections can cause CPU slowdown, for example.
The ability to include some scripting data directly into the HTML, known as resource inlining, allowed the browser to download CSS and JS file information along with the HTML and not have to open up a new connection to do it. This not only reduced the number of connections, but also reduced the need for another round-trip across the network to get more data.
To help solve the HTTP/1.1 limitations, in November 2009, Google released its first draft defining a new protocol called SPDY, which is pronounced "SPeeDY".
Get it? Speedy? Haha!
The primary goal that Google stated for this protocol was to reduce page load times by at least 50%.
The plan to achieve this goal was in the following ways:
■ Multiplexing requests onto one TCP connection
■ Prioritizing requests
■ Compressing headers
■ Enabling server pushes
■ Ensuring better security with TLS
SPDY is not an outright replacement of HTTP. Instead it runs as an application layer protocol that sits between TCP and HTTP.
Google also ensured that every request would be secure, so part of the SPDY implementation included TLS for data encryption, by default. Google was able to accomplish this goal when it saw up to 64% decreases in page load times across its Google properties that were tested, when compared to HTTP/1.1.
Now to HTTP/2
The performance gains that were experienced with SPDY were so great that Google submitted SPDY to the IETF for consideration in the HTTP/1.1 upgrade. This was accepted, and when the initial draft of the HTTP/2 standard was published in 2012, it was an exact of the copy of SPDY.
HTTP/2 is meant to be a more efficient version of the HTTP/1.1 protocol. But rather than a simple dot upgrade, like HTTP/1.2, HTTP/2 was used due to the binary framing layer (more on this later) of the upgraded protocol.
So SPDY was used as a starting point to build on HTTP/2.
The following capabilities were used as goals to accomplish:
■ Multiplexing of requests via request/response streams
■ Flow control and prioritization of multiplexed streams
■ Interaction mode via server push
■ Data compression of HTTP headers
After many months, the updated HTTP protocol was published as the proposed standard (RFC 7540) in May 2015.
Not Your Average SPDY
While HTTP/2 was based on Google's SPDY protocol at the outset, there were a couple of capabilities removed by the time it became a standard.
SPDY was only implemented with the TLS protocol enabled for security. The HTTP/2 protocol can be implemented with or without TLS.
This means that both ports 80 and 443 can be used as default ports to implement the protocol. HTTP/2 defines a version ID in the HTTP header so that you can verify what version is being used.
■ H2 version is for encrypted HTTP/2.
■ H2C version is for unencrypted HTTP/2.
But the de facto standard implementation will be H2 to ensure that as many websites as possible are always using HTTP with TLS encryption.
Read Web Performance and the Impact of SPDY, HTTP/2 & QUIC - Part 4, covering HTTP/2 in more detail.
For businesses with vast and distributed computing infrastructures, one of the main objectives of IT and network operations is to locate the cause of a service condition that is having an impact. The more human resources are put into the task of gathering, processing, and finally visual monitoring the massive volumes of event and log data that serve as the main source of symptomatic indications for emerging crises, the closer the service is to the company's source of revenue ...
Our digital economy is intolerant of downtime. But consumers haven't just come to expect always-on digital apps and services. They also expect continuous innovation, new functionality and lightening fast response times. Organizations have taken note, investing heavily in teams and tools that supposedly increase uptime and free resources for innovation. But leaders have not realized this "throw money at the problem" approach to monitoring is burning through resources without much improvement in availability outcomes ...
Although 83% of businesses are concerned about a recession in 2023, B2B tech marketers can look forward to growth — 51% of organizations plan to increase IT budgets in 2023 vs. a narrow 6% that plan to reduce their spend, according to the 2023 State of IT report from Spiceworks Ziff Davis ...
Users have high expectations around applications — quick loading times, look and feel visually advanced, with feature-rich content, video streaming, and multimedia capabilities — all of these devour network bandwidth. With millions of users accessing applications and mobile apps from multiple devices, most companies today generate seemingly unmanageable volumes of data and traffic on their networks ...
In Italy, it is customary to treat wine as part of the meal ... Too often, testing is treated with the same reverence as the post-meal task of loading the dishwasher, when it should be treated like an elegant wine pairing ...
In order to properly sort through all monitoring noise and identify true problems, their causes, and to prioritize them for response by the IT team, they have created and built a revolutionary new system using a meta-cognitive model ...
As we shift further into a digital-first world, where having a reliable online experience becomes more essential, Site Reliability Engineers remain in-demand among organizations of all sizes ... This diverse set of skills and values can be difficult to interview for. In this blog, we'll get you started with some example questions and processes to find your ideal SRE ...
US government agencies are bringing more of their employees back into the office and implementing hybrid work schedules, but federal workers are worried that their agencies' IT architectures aren't built to handle the "new normal." They fear that the reactive, manual methods used by the current systems in dealing with user, IT architecture and application problems will degrade the user experience and negatively affect productivity. In fact, according to a recent survey, many federal employees are concerned that they won't work as effectively back in the office as they did at home ...
Users today expect a seamless, uninterrupted experience when interacting with their web and mobile apps. Their expectations have continued to grow in tandem with their appetite for new features and consistent updates. Mobile apps have responded by increasing their release cadence by up to 40%, releasing a new full version of their app every 4-5 days, as determined in this year's SmartBear State of Software Quality | Application Stability Index report ...
In this second part of the blog series, we look at how adopting AIOps capabilities can drive business value for an organization ...