BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Ed Burns Discusses HTTP/2 and the Java EE Servlet 4 Specification

Ed Burns Discusses HTTP/2 and the Java EE Servlet 4 Specification

At JavaLand 2015, Ed Burns provided an overview of the Java EE Servlet 4.0 specification (JSR 369), the main focus of which is to introduce HTTP/2 support into the Java EE Platform. HTTP/2 aims to overcome problems with the existing HTTP specification, and new features include request/response multiplexing, binary framing, stream prioritisation, server push and header compression.

Burns, a consulting member of the technical staff at Oracle Inc., began the talk by stating that a typical website loads in over 30 different resources, and the inherent limitations in HTTP/1.1 can slow the delivery of these resources to the browser. The primary issue is ‘head-of-line’ (HOL) blocking, which results from the delivery of the resources in the order they were requested. Modern browsers have attempted to work around this issues using techniques such as opening multiple socket connections, domain sharding and file concatenation.

Burns stated that HTTP/2 is essentially a new transport layer underneath HTTP/1.1, which is implemented at the application layer of the OSI model. The protocol still defines the same request/response model, there are no new methods nor headers, no new usage patterns from the application layer, and no new usage of the URL spec and other lower level specs.

The HTTP/1.1 specification states little about how TCP sockets are to be used, and they can be viewed as a throwaway resource. In contrast, the new HTTP/2 specification suggests that sockets are a scarce resource, and states that only a single TCP connection must be opened per server. A ‘stream’ within HTTP/2 is effectively a channel within a TCP connection, over which messages are sent. A frame is the smallest unit of communication in HTTP/2.

The HTTP/2 specification also includes:

  • Request/response multiplexing - each TCP connection is fully bi-directional
  • Binary framing - HTTP/2 is a binary protocol, which makes makes the framing much easier. Determining the start and end of frames is complicated with a text-based protocol, such as HTTP/1.1. Binary framing also solves the HOL blocking problem
  • Stream prioritisation - each stream has a priority, which can be used to the tell the peer which streams are considered most important
  • Server push - this allows the server to populate the browser’s cache in advance of the browser asking for resources
  • Header compression (known as HPACK) - a compression format for efficiently representing HTTP header fields
  • HTTP/2 upgrade from HTTP/1.1 - including the definition of protocol upgrade with transport layers that are both non secure (using port 80 and HTTP status code 101 ‘Switching Protocols’) and secure (using NPN or ALPN)

Burns discussed that there has been criticism of HTTP/2, as this includes the possibility of HOL blocking occurring in the header frames, no support in Firefox or Chrome of protocol upgrades over an non secure transport layer, the increased carbon footprint for HPACK encoding/decoding, the potential for additional DoS attack vectors due to the large surface area of new software that must be written to implement the HTTP/2 specification, and the fact that HTTP/2 is orthogonal to WebSocket.

The presentation concluded by discussing how the new HTTP/2 specification could possibly be exposed in the Java EE Servlet API. Features that could be supported include request/response multiplexing, stream prioritisation, server push, and upgrade from HTTP/1.1.

Stream prioritisation could be implemented by including a new ‘Priority’ class, and accessor and mutator methods could be added to the existing HttpServletRequest and HttpServletResponse classes. Burns also states that server push could be very useful for frameworks such as JSF, and the ability to push resources to a client for a given URL and headers could be implemented.

The Servlet 4.0 specification will bring HTTP/2 to Java EE, and will be a 100% compliant implementation of the HTTP/2 specification. The supporting Java Specification Request, JSR 369, was formed on September 2014, and the tentative proposed final draft could be Q4 2015, leading to a final release in Q3 2016.

Burns encouraged all interested parties to get involved with the creation of Servlet 4.0 via the Adopt-a-JSR program, reading the Aquarium blog and by visiting the GlassFish Java EE reference implementation application server web page. Additional details of accompanying JSR 369 specification can be found on the Java Community Process (JCP) website. JavaLand is an annual Java conference hosted in Brühl, Germany, and details can be found on the JavaLand event website.

Rate this Article

Adoption
Style

BT