鲍鱼tv

The public phase of the Adaptive Media Streaming over HTTP/2 trial has now formally ended and we are pleased to present some initial results.

Trial recap

The trial (described in our ) presented a public-facing HTTP/2 server that provided access to a number of MPEG-DASH test streams. The server supported both cleartext and encrypted connections for HTTP/1.0, HTTP/1.1 and HTTP/2 draft 14.

The public phase of the trial went live on 8th December 2014 and ran until 14th January 2015. Thanks to everyone who took part. Our server logged all HTTP-related activity following successful TCP and TLS connection setup. We have performed some initial analysis of the data collected during this period and are sharing our early findings here.

When we looked at the logs we found that some search engine bots and security scanners had paid us a visit. Because this activity is not relevant to the purposes of our trial we have excluded these requests from the analysis below. Similarly, we have excluded a burst of requests from a single client which we believe to have experienced an MPEG-DASH player issue.

Total activity

Over the course of the 38 days, our server received a total of 25806 requests originating from 533 unique visitors. (We classify a unique visitor as having the same IP, date and user agent.) We served over 13 GBytes of data across more than 9000 unique resources.

The following graphs show the breakdown of traffic across cleartext and encrypted connections.

Country breakdown

The trial involved participants from across the globe and we saw access from 33 different countries, reflecting a global interest in HTTP/2 and MPEG-DASH. The most active countries were the UK, Japan, the US and France.

User Agent breakdown

Web browsers and other HTTP client software report their identity when making requests. Some are truthful, while others pretend to be something different, so the following should be taken with a pinch of salt.

Unsurprisingly, given the advice in our original blog posting, the majority of traffic originated from Chrome 39 or later. The rest of the traffic was split between the other major browsers (Firefox, Safari, Internet Explorer), plus some requests from tools such as VLC.

The requests in our cleartext logs showed a greater spread of User Agents than TLS, perhaps reflecting the simpler nature of cleartext. TLS connection negotiation has several stages that can fail and prevent a User Agent from making successful requests.

Operating System breakdown

We expected HTTP/2 support to be reasonably independent of the Operating System. However, there can be a coupling to the browser versions available.

Cleartext HTTP saw a more even distribution, with an equal share between Windows and Mac OS X. For encrypted HTTP, the Windows share stayed the same while Linux and Android ate into the Mac OS X slice.

For context, compare with figures for .

HTTP/2 activity

We were interested in comparing the performance of HTTP/2 over cleartext (h2c) and encrypted (h2) connections. Most web browsers do not support the cleartext mode of operation and so we provided a in our original blog post that does support h2c. Unfortunately, it looks like none of our trialists rose to the challenge of compiling this and trying it out, and so we don't have enough performance data to see how the two modes compare at scale in the real world. We plan to do further work internally to simulate this.

Encrypted HTTP fared better, with 83% of requests being made with h2.

HTTP behaviour

HTTP defines status codes to describe the result of requests. We treat 2xx as success, 4xx as a client error and 5xx as a server error.

We observed over 90% of the total HTTP requests succeed with only 1% server error. The remaining client errors are primarily cases of media players getting ahead of themselves when viewing a live DASH stream. Media players like to read ahead as far as possible to maintain a buffer of unplayed material as an insurance against the network slowing down unexpectedly. For live streams, media players following this strategy will eventually request a media segment that isn't yet available on the server and a 404 Not Found error will be returned. In fact, MPEG-DASH provides information that tells the media player when new media segments are due to be published on the server, so a well-implemented DASH player shouldn't fall into this trap

Ongoing work

The public phase of the trial has formally ended. We intend to continue providing public access to our HTTP/2 server, but please be aware that it will be subject to maintenance periods and we may update the test streams available.

The information presented in this post provides only a taste of the results we have gleaned from the trial. We will perform further analysis on the data set and hope to share additional findings in the future.

Contact

Feedback or enquiries can be provided to us at the address http2@rd.bbc.co.uk