Rotem Epelbaum on HTTP 2.0 and Video Streaming

March 31, 2015 1:34 pm

Giraffic - Rotem - Headshot-4

In the post Teaching Pipelines to Dance – and Think, Giraffic VP of R&D Rotem Epelbaum wrote about the evolution of HTTP. He explained how AVA tapped the pipelining capabilities that were introduced in HTTP/1.1 to boost video streaming performance. Please read the post to learn more.

Meanwhile, HTTP/2 was recently announced.  We thought that we would ask Rotem to share his understanding about the new version, and explain implications for streaming.

What is HTTP/2?

HTTP/2 is the latest version of HTTP that was published by the IETF. It is based on a protocol called SPDY, which was created by Google in 2009. It promises faster web page loading time.

What changes does it bring?

Key changes include support for:

  1. Multiple requests: Several requests can be sent quickly on the same TCP connection, and responses can be received out of order – eliminating the need for multiple connections between the client and the server at the web browser application.
  2. Header compression: The HTTP header size is drastically reduced.
  3. Stream dependencies: The client can indicate to the server which of the resources are more important than the others.

Does Giraffic support HTTP/2?

We are following the spec and performing the required extras for full support of HTTP/2.

What does HTTP/2 mean for video streaming?

At first glance, it seemed like HTTP/2 might be able to improve adaptive video streaming performance – the player can download future fragments of the video with no need to wait for the current one to finish. But it is not really solving this at all:

  1. At max, this can save the connection latency – very significant for tiny files, much less effective for large files (for example, save 100ms at HLS 10sec fragment = 1% improvement).
  2. The next fragment may be at a different resolution – so the player can’t really ask for a future fragment.

What about large file downloads?

Absolutely not relevant – HTTP/2 improves downloading of tiny files (e.g., html, css, icons). For large files, where there is a single request – there is no effect.

The bottom line / what’s next?

HTTP/2 was made for web page performance improvements. But most Internet bandwidth consists of video and large files, and HTTP/2 doesn’t help there.

It can’t answer the throughput utilization need, and can’t really enable streaming of 4K video content.

I think the next real milestone will be to find the solution that addresses tiny files as well as large content. Maybe implementing AVA inside HTTP/3 will be the optimal answer (which hopefully will arrive 16 times faster than the release time between HTTP/1.1 and 2).