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.
Key changes include support for:
- 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.
- Header compression: The HTTP header size is drastically reduced.
- 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:
- 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).
- 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).