From a Java perspective, I’ve been the beneficiary of some pretty amazing features over the years: Generics (Java 5)
Streams and Lambda Expressions (Java 8)
Enhanced Collection Functionality (Java 9)
Sealed Classes (Java 17) As key features become available, I’ve been able to reduce development time as I implement features, while also seeing benefits in performance and supportability. However, one area that seems to have lagged behind is the adoption of a key internet protocol: HTTP/2. While the second major release has been around for over nine years, migration from the 1.x version has been slower than expected. I wanted to explore HTTP/2 to understand not only the benefits but also what it looks like to adopt this new version. In this article, we’ll look at my anecdotal experience, plus some challenges I found too. About HTTP/2 HTTP/2 was released in May 2015 and included the following improvements over the prior version of HTTP: Multiplexing: Allows multiple requests and responses to be sent over a single connection.
Header compression: Reduces the overhead of HTTP headers by using compression.
Server push: Enables servers to send resources to a client proactively.
Resource prioritization: Allows consumers to specify the importance of given resources, affecting the order in which they’re loaded.
Binary protocol: Provides an alternative to the text-based format of HTTP/1.x Additionally, HTTP/2 is backward compatible with HTTP/1.x. Common Use Cases for HTTP/2 Below are just some of the strong use cases for HTTP/2: A full-stack application that contains a chatty consumer, consistently communicating with the service tier.
An application that relies heavily on content being stored inside the HTTP headers.
A solution that is dependent on server-initiated events to broadcast updates to consumers.
A client application that can benefit from providing prioritization instructions to the underlying service.
A web client which requires large amounts of data to be retrieved from the service tier. Migrating to HTTP/2 for any of these use cases could provide noticeable improvements from a consumer perspective. What’s Involved with HTTP/2 Adoption? When I think about a lower-than-expected adoption rate of 45%-50% (as noted in this Cloudflare blog), I wonder if developers believe the upgrade to HTTP/2 won’t be easy. But I don’t get why they feel that way. After all, HTTP/2 is backward compatible with HTTP/1.x. Using Spring Boot 3.x (which requires Java 17+ and uses the default Jetty server) as an example, upgrading to HTTP/2 is actually kind of easy. The biggest hurdle is making sure you are using SSL/TLS — which is honestly a good idea for your services anyway. server.port=8443
server.ssl.key-store=classpath:keystore.p12
server.ssl.key-store-password=<your_password_goes_here>
server.ssl.key-store-type=PKCS12
server.ssl.key-alias=<your_alias_goes_here> With SSL/TLS in place, you just need to enable HTTP/2 via this property: server.http2.enabled=true At this point, your service will start and utilize HTTP/2. By default, all of the features noted above will be ready for use. Is that all there is to it? But Wait … There’s More to the Story Depending on where your service is running, the effort to upgrade to HTTP/2 might not yield the results you were expecting. This is because network infrastructure often stands between your service and the consumers wanting to take advantage of HTTP/2 greatness. That layer needs to fully support HTTP/2 as well. What does this mean? It means your service could receive the request and provide an HTTP/2 response, only for a router to downgrade the protocol to HTTP/1.1. Here’s the big takeaway: before you get all excited about using HTTP/2 and spend time upgrading your services, you should confirm that your network layer supports it. Recently, Heroku announced support of HTTP/2 at the router level. They’re addressing this exact scenario, and HTTP/2 is now available in a public beta. The illustration below demonstrates how they make HTTP/2 service responses available to consumers: This initial push from Heroku makes it possible for service developers like me to build applications that can take advantage of HTTP/2 features like header compression and multiplexing. This means faster delivery to consumers while potentially reducing compute and network loads. If your cloud provider doesn’t have infrastructure that supports HTTP/2, requests to your HTTP/2-enabled service will result in an HTTP/1.x response. As a result, you won’t get the HTTP/2 benefits you’re looking for. Challenges With HTTP/2 While my own experience of upgrading my Spring Boot services to leverage HTTP/2 hasn’t run up against any significant challenges—especially with support now at the cloud provider network level—I am reading more about others who’ve struggled with the adoption. Based on some of the customer experiences I’ve found, here are some items to be aware of during your journey to HTTP/2: Increase in compute cost: These features can lead to more processing power than what you may have needed for HTTP/1.x.
Impact on other portions of the response: After adding SSL/TLS to your service, expect that more time will be required to perform this layer of processing.
Advanced features can be misconfigured: You’ll want to understand concepts like multiplexing, stream prioritization, flow control, and header compression, as these items can impact performance in a negative manner if not configured correctly. If your path to production includes dev, QA, and staging environments, you should be able to identify and mitigate any of these hurdles long before your code reaches production. Conclusion My readers may recall my personal mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” — J. Vester Upgrading to HTTP/2 certainly adheres to my mission statement by giving service owners features like multiplexing, header compression, resource prioritization, and binary responses—all of which can impact the overall performance of a service or the consuming application. At the same time, cloud providers who support HTTP/2—like Heroku—also get credit for adhering to my mission statement. Without this layer of support, applications that interact with these services wouldn’t be able to take advantage of these benefits. When I reflect on my personal experience with Java, I can’t imagine a world where I am writing Java code without using generics, streams, lambdas, enhanced collections, and sealed classes. All of these features are possible because I took the time to see the benefits and perform the upgrade. The question really isn’t if you should upgrade to HTTP/2, but rather which upcoming development iteration will cover this enhancement. Have a really great day! From a Java perspective, I’ve been the beneficiary of some pretty amazing features over the years: Generics (Java 5) Streams and Lambda Expressions (Java 8) Enhanced Collection Functionality (Java 9) Sealed Classes (Java 17) Generics (Java 5) Generics Streams and Lambda Expressions (Java 8) Streams and Lambda Expressions Enhanced Collection Functionality (Java 9) Enhanced Collection Functionality Sealed Classes (Java 17) Sealed Classes As key features become available, I’ve been able to reduce development time as I implement features, while also seeing benefits in performance and supportability. However, one area that seems to have lagged behind is the adoption of a key internet protocol: HTTP/2. While the second major release has been around for over nine years, migration from the 1.x version has been slower than expected. I wanted to explore HTTP/2 to understand not only the benefits but also what it looks like to adopt this new version. In this article, we’ll look at my anecdotal experience, plus some challenges I found too. About HTTP/2 HTTP/2 was released in May 2015 and included the following improvements over the prior version of HTTP: Multiplexing: Allows multiple requests and responses to be sent over a single connection. Header compression: Reduces the overhead of HTTP headers by using compression. Server push: Enables servers to send resources to a client proactively. Resource prioritization: Allows consumers to specify the importance of given resources, affecting the order in which they’re loaded. Binary protocol: Provides an alternative to the text-based format of HTTP/1.x Multiplexing: Allows multiple requests and responses to be sent over a single connection. Multiplexing: Header compression: Reduces the overhead of HTTP headers by using compression. Header compression: Server push: Enables servers to send resources to a client proactively. Server push: Resource prioritization: Allows consumers to specify the importance of given resources, affecting the order in which they’re loaded. Resource prioritization: Binary protocol: Provides an alternative to the text-based format of HTTP/1.x Binary protocol: Additionally, HTTP/2 is backward compatible with HTTP/1.x. Common Use Cases for HTTP/2 Below are just some of the strong use cases for HTTP/2: A full-stack application that contains a chatty consumer, consistently communicating with the service tier. An application that relies heavily on content being stored inside the HTTP headers. A solution that is dependent on server-initiated events to broadcast updates to consumers. A client application that can benefit from providing prioritization instructions to the underlying service. A web client which requires large amounts of data to be retrieved from the service tier. A full-stack application that contains a chatty consumer, consistently communicating with the service tier. An application that relies heavily on content being stored inside the HTTP headers. A solution that is dependent on server-initiated events to broadcast updates to consumers. A client application that can benefit from providing prioritization instructions to the underlying service. A web client which requires large amounts of data to be retrieved from the service tier. Migrating to HTTP/2 for any of these use cases could provide noticeable improvements from a consumer perspective. What’s Involved with HTTP/2 Adoption? When I think about a lower-than-expected adoption rate of 45%-50% (as noted in this Cloudflare blog ), I wonder if developers believe the upgrade to HTTP/2 won’t be easy. But I don’t get why they feel that way. After all, HTTP/2 is backward compatible with HTTP/1.x. this Cloudflare blog Using Spring Boot 3.x (which requires Java 17+ and uses the default Jetty server) as an example, upgrading to HTTP/2 is actually kind of easy. The biggest hurdle is making sure you are using SSL/TLS — which is honestly a good idea for your services anyway. server.port=8443
server.ssl.key-store=classpath:keystore.p12
server.ssl.key-store-password=<your_password_goes_here>
server.ssl.key-store-type=PKCS12
server.ssl.key-alias=<your_alias_goes_here> server.port=8443
server.ssl.key-store=classpath:keystore.p12
server.ssl.key-store-password=<your_password_goes_here>
server.ssl.key-store-type=PKCS12
server.ssl.key-alias=<your_alias_goes_here> With SSL/TLS in place, you just need to enable HTTP/2 via this property: server.http2.enabled=true server.http2.enabled=true At this point, your service will start and utilize HTTP/2. By default, all of the features noted above will be ready for use. Is that all there is to it? But Wait … There’s More to the Story Depending on where your service is running, the effort to upgrade to HTTP/2 might not yield the results you were expecting. This is because network infrastructure often stands between your service and the consumers wanting to take advantage of HTTP/2 greatness . That layer needs to fully support HTTP/2 as well. network infrastructure often stands between your service and the consumers wanting to take advantage of HTTP/2 greatness What does this mean? It means your service could receive the request and provide an HTTP/2 response, only for a router to downgrade the protocol to HTTP/1.1. Here’s the big takeaway: before you get all excited about using HTTP/2 and spend time upgrading your services, you should confirm that your network layer supports it. Recently, Heroku announced support of HTTP/2 at the router level. They’re addressing this exact scenario, and HTTP/2 is now available in a public beta. The illustration below demonstrates how they make HTTP/2 service responses available to consumers: announced This initial push from Heroku makes it possible for service developers like me to build applications that can take advantage of HTTP/2 features like header compression and multiplexing. This means faster delivery to consumers while potentially reducing compute and network loads. If your cloud provider doesn’t have infrastructure that supports HTTP/2, requests to your HTTP/2-enabled service will result in an HTTP/1.x response. As a result, you won’t get the HTTP/2 benefits you’re looking for. Challenges With HTTP/2 While my own experience of upgrading my Spring Boot services to leverage HTTP/2 hasn’t run up against any significant challenges—especially with support now at the cloud provider network level—I am reading more about others who’ve struggled with the adoption. Based on some of the customer experiences I’ve found, here are some items to be aware of during your journey to HTTP/2: Increase in compute cost: These features can lead to more processing power than what you may have needed for HTTP/1.x. Impact on other portions of the response: After adding SSL/TLS to your service, expect that more time will be required to perform this layer of processing. Advanced features can be misconfigured: You’ll want to understand concepts like multiplexing, stream prioritization, flow control, and header compression, as these items can impact performance in a negative manner if not configured correctly. Increase in compute cost: These features can lead to more processing power than what you may have needed for HTTP/1.x. Increase in compute cost: Impact on other portions of the response: After adding SSL/TLS to your service, expect that more time will be required to perform this layer of processing. Impact on other portions of the response: Advanced features can be misconfigured: You’ll want to understand concepts like multiplexing, stream prioritization, flow control, and header compression, as these items can impact performance in a negative manner if not configured correctly. Advanced features can be misconfigured: If your path to production includes dev, QA, and staging environments, you should be able to identify and mitigate any of these hurdles long before your code reaches production. Conclusion My readers may recall my personal mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” — J. Vester “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” — J. Vester Upgrading to HTTP/2 certainly adheres to my mission statement by giving service owners features like multiplexing, header compression, resource prioritization, and binary responses—all of which can impact the overall performance of a service or the consuming application. At the same time, cloud providers who support HTTP/2—like Heroku—also get credit for adhering to my mission statement. Without this layer of support, applications that interact with these services wouldn’t be able to take advantage of these benefits. When I reflect on my personal experience with Java, I can’t imagine a world where I am writing Java code without using generics, streams, lambdas, enhanced collections, and sealed classes. All of these features are possible because I took the time to see the benefits and perform the upgrade. The question really isn’t if you should upgrade to HTTP/2, but rather which upcoming development iteration will cover this enhancement. Have a really great day!

The Power of Market Disruption: How to Detect Fraud With Graph Data

Leveling Up My GraphQL Skills: Real Time Subscriptions

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

Why Haven’t You Upgraded to HTTP/2?

Why Haven’t You Upgraded to HTTP/2?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

5 Signs You’ve Built a Secretly Bad Architecture (And How to Fix It)

Building Reproducible, Verifiable Binaries with Golang

Comparing the performance of various serializers

Fenwick Tree Explained

How to Create Executable Files and Produce Debug Information

5 Signs You’ve Built a Secretly Bad Architecture (And How to Fix It)

Building Reproducible, Verifiable Binaries with Golang

Comparing the performance of various serializers

Fenwick Tree Explained

How to Create Executable Files and Produce Debug Information

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps