BLOG

August 06, 2019
3 min read

HTTP/2 Support in WSO2 API Microgateway 3.0.1

WSO2 API Microgateway 3.0.1 supports HTTP/2 allowing you to expose your HTTP/2 services to clients directly via the microgateway, where the client can communicate using either HTTP/1.1 or HTTP/2. It also allows you to expose your HTTP/1.1 service as an HTTP/2 service via the microgateway, allowing clients to communicate via HTTP/2 - making the communication between the client and the microgateway HTTP/2 by keeping the communication between the microgateway and the backend service in HTTP/1.1. All these transformations are supported by WSO2 API Microgateway. This blog discusses use cases and how HTTP/2 can be enabled in the microgateway.

What is HTTP/2?

HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web, which is officially standardized as a result of SPDY protocol developed by Google. Refer to (1) and (2) for more details.

Source: https://coolicehost.com/http2-protocol.html

HTTP/1.1 vs. HTTP/2

HTTP/2 is released to address the problems in HTTP/1.1 as explained below:

  • HTTP/2 is binary instead of textual. Binary protocols are more efficient to parse, more compact “on the wire”, and most importantly, they are much less error-prone, compared to textual protocols like HTTP/1.x.
  • HTTP/2 is fully multiplexed instead of ordered and blocking. Multiplexing allows multiple files and requests to be in flight at the same time, as opposed to HTTP/1.1 which only accepted one single request/connection at a time.
  • HTTP/2 uses one TCP connection for parallelism. With HTTP/1.1, browsers open between four and eight connections per origin, and with a single page having multiple origins, it might lead to more than thirty connections opened at a time which in turn causes a huge overhead. HTTP/2 opens one connection between the client and the server to reduce this overhead.
  • HTTP/2 uses header compression to reduce overhead. With HTTP/1.1, it retrieves different resources from the same or multiple web browsers and each request has a collection of headers, and it takes at least 7-8 round trips to get the headers out “on the wire.” In comparison, even mild compression on headers allows those requests to get onto the wire within one round trip.
  • HTTP/2 allows servers to “push” responses proactively into client caches without allowing the client browser to request files when needed.

Main Use Cases of HTTP/2 with WSO2 API Microgateway

The following use cases explains how the WSO2 API Microgateway works when HTTP/2 is enabled. Since HTTP/2 is enabled in WSO2 API Microgateway, when a request is received by the microgateway, it sends the following set of headers along with the request to the backend to determine whether the backend supports HTTP/2 or not.

If the backend supports HTTP/2, it responds to the microgateway with the following set of headers including "HTTP/1.1 101 Switching Protocols" header. Then the microgateway and the backend start communicating via the HTTP/2 protocol.

If the microgateway does not receive the "HTTP/1.1 101 Switching Protocols" header, then it concludes that the backend does not support HTTP/2 and starts communicating with the backend using HTTP/1.1.

Both Client and Backend Supports HTTP/2

In this use case, the HTTP/2 backend service is exposed via WSO2 API Microgateway as a HTTP/2 service and the users/clients communicate with the backend service via HTTP/2 protocol through the microgateway. When a client sends an HTTP/2 request, WSO2 API Microgateway forwards that request to the HTTP/2 backend, including the following HTTP/2 headers to determine the protocol of the connection between WSO2 API Microgateway and the backend.

The backend accepts the request and sends an HTTP/2 response back to WSO2 API Microgateway with the connection upgrade header as well as the "HTTP/1.1 101 Switching Protocols" header. Receiving this header indicates that the backend supports HTTP/2.

As a result, an HTTP/2 connection between WSO2 API Microgateway and the backend is established. Finally the backend sends an HTTP/2 response with the payload to the microgateway, which then forwards that HTTP/2 response back to the client.

The Client Does Not Support HTTP/2 but the Backend Supports HTTP/2

In this use case, the HTTP/2 backend service is exposed via WSO2 API Microgateway as a HTTP/2 service and the users/clients communicate with the backend service via the HTTP/1.1 protocol through the microgateway. When a client sends an HTTP/1.1 request to the WSO2 API Microgateway, this in turn sends the request back to the backend service after including the HTTP/2 headers to determine the protocol of the connection between WSO2 API Microgateway and the backend.

After receiving the request, the backend sends the response back to the microgateway with the following headers indicating that the backend supports HTTP/2.

The backend then sends the response with the payload to the microgateway, which sends the response payload back to the client.

The Client Supports HTTP/2 but the Backend Does Not Support HTTP/2

In this use case, the HTTP/1.1 backend service is exposed via WSO2 API Microgateway and the users/clients communicate with the backend service via HTTP/1.1 or HTTP/2 protocols through the microgateway. When a client sends a request to the microgateway, it sends the request back to the backend including the following headers to determine whether the backend supports HTTP/2.

Since the backend does not support HTTP/2, it does not reply back with the expected "HTTP/1.1 101 Switching Protocols" header; and that notifies the Microgateway that the backend does not support HTTP/2. Then the backend starts communicating with the backend via the HTTP/1.1 protocol and after receiving the response payload from the backend, the microgateway forwards the response payload back to the client.

Since the microgateway uses a keep-alive connection when communicating with the backend server, it sends the following request headers to the backend to determine whether the backend supports HTTP/2 in the initial request in the same connection only. If you send the same request repeatedly, you will not see the particular headers as the microgateway already knows of the backend supported protocol.

Prerequisites

Download and setup WSO2 API Microgateway 3.0.1 as explained in (3).

How to Enable HTTP/2 in WSO2 API Microgateway 3.0.1

Enable HTTP/2 in a Docker Setup

  • Create a microgateway project.
  • Navigate to a preferred workspace folder using the command line. This location is used to run the microgateway commands and to generate microgateway artifacts.
  • Create a project using the command given below:
  • micro-gw init 
    micro-gw init petstore
  • Add the API (open API definition) to the project. Navigate to the /petstore/api_definitions directory and add the API definition(s) to this directory. A sample open API definition can be found here.
  • Build the microgateway distribution for the project using the following command:
  • micro-gw build 
    micro-gw build petstore
  • After the above command is executed, an executable file ( /petstore/target/petstore.balx ) is created to expose the API via WSO2 API Microgateway.
  • Navigate to the <MGW-TOOLKIT-HOME>/resources /conf folder and open the micro-gw.conf file.
  • Locate the (http2) tag in the file and change the enabled value to true.
  • [http2]
    enable=true
  • Run the Microgateway Docker runtime mounting executable file (petstore.balx) and the config file (micro-gw.conf).
  • Now the petstore API is exposed using WSO2 API Microgateway.
  • Invoke the petstore API using a valid JWT token.

Enable HTTP/2 in a VM Setup

  • Create a microgateway project.
  • Navigate to a preferred workspace folder using the command line. This location is used to run the microgateway commands and to generate microgateway artifacts.
  • Create a project using the command given below:
  • micro-gw init 
    micro-gw init petstore
  • Add the API (open API definition) to the project. Navigate to the /petstore/api_definitions directory and add the API definition(s) to this directory. A sample open API definition can be found here.
  • Build the microgateway distribution for the project using the following command:
  • micro-gw build 
    micro-gw build petstore
  • After the above command is executed, an executable file (/petstore/target/petstore.balx) is created to expose the API via WSO2 API Microgateway.
  • Navigate to the <MGW-RUNTME-HOME>/resources /conf folder and open the micro-gw.conf file.
  • Locate the (http2) tag in the file and change the enabled value to true.
  • (http2)
    enable=true
  • Run the Microgateway Runtime mounting executable file (petstore.balx) by navigating to the /bin directory.
  • bash gateway //petstore/target/petstore.balx

Summary

To summarize, WSO2 API Microgateway 3.0.1 allows users to use either HTTP/2 or HTTP/1.0 by supporting multiple transformations. It can expose an HTTP/2 backend service directly to end-users and let them call the service via either HTTP/1.0 or HTTP/2. An HTTP/1.0 backend service can also be exposed as an HTTP/2 backend service letting end-users to invoke via HTTP/2 requests.

Learn more about WSO2 API Microgateway here.

Reference

(1) https://http2.github.io/faq/

(2) https://developers.google.com/web/fundamentals/performance/http2/

(3) https://docs.wso2.com/display/MG301/Quick+Start+Guide