In previous releases of Oracle Cloud Infrastructure (OCI) Load Balancing service, you were limited to a routing traffic using hostname and URL path only. We previously only supported HTTP version 1.1, which limited HTTP traffic to a synchronous flow over TCP.
To meet our customers’ needs in these areas, we recently launched two new features on OCI load balancer as a service (LBaaS): HTTP/2 and request routing policy. The feature includes the following key benefits:
Advanced routing policy enables you to route your load balancer traffic based on conditions such as HTTP headers, methods and query string, as well as URL path and hostnames. The routing policy enables you to deliver different user experiences based on these conditions and route to a specific backend server.
As part of this release, we’re introducing support for HTTP/2 on our flexible load balancer listeners. HTTP/2 provides a multiplexed traffic flow over TCP and significant performance improvement over the previous versions, especially for clients connecting over low-bandwidth networks.
In this blog, I describe some specific scenarios where you can implement these features to provide enhanced routing and performance experiences.
Our fictitious customer MuShop has two versions of their image gallery, represented as the blue and green photos in the following graphic, and is in the process of doing A-B testing on them to identify which drives the most user engagement and conversion.
They’ve configured the following set of rules in their green routing policy.
They’re using a query string called Test with a value of Green. This configuration routes requests that match this condition to the green backend set. All requests that don’t match are routed to the default backend set called Blue.
MuShop has decided that they also want to test Red photos. They want to be able to send users to the Red photo, based on the presence of a particular cookie. To achieve this routing, they add another rule to their policy. At the bottom of the page, click + Another rule.
We start by naming the rule Red. We can select the condition type from a list of either, path, request cookies, request header, and url query as the primary types, as well as nested conditions.
A nested condition allows you to use multiple match types. For example, if your primary rule is to match all condition, you can have a nested condition to match any condition. You can match on a request cookie, request header, or query string instead of having to match all of them.
For this example, we use request cookies, which have a key of Color and value of Red. In the actions section, we route these requests to the backend set named Red. To complete this addition, click Next and Save Changes.
Now that we’ve shown you the advanced routing feature, let’s move on to our HTTP2 demo. Let’s look at an example image grid in MuShop’s gallery where one is hosted behind HTTP/1 and another is behind a HTTP/2 listener.
As you can see, the HTTP/2 image is finished while the HTTP/1 version is still loading.
The process to enable HTTP2 is simple. Navigate to a listener that’s currently configured for HTTP 1.1. Under protocol, select HTTP/2, then click Update Listener.
We saw how easy it is to utilize our advanced routing feature and enable HTTP/2 support on our flexible load balancer. Check back for more announcements, and follow our Architecture Center for design concepts that utilize these features. For more information about these releases, check out our documentation.