HTTP/2 is a new version of the HTTP protocol currently being specified by the IETF (see HTTP version 2, Internet draft dated Feb. 13, 2014, available at http://tools.ietf.org/html/draft-ietf-httpbis-http2-10).
It is well-known that the HTTP protocol allows a client device and a server device to communicate through the exchange of requests and responses. Conventionally, requests are sent by the client device to the server device, which in return, sends responses.
As defined by the IETF, the HTTP requests and responses are transmitted over a TCP connection established between the client and server devices.
The earliest versions of HTTP relied on different TCP connections to respectively convey each pair of (request, response).
The most recent versions of HTTP allow reusing the same TCP connection to exchange a plurality of pairs of (request, response).
In the particular case of HTTP/2, one and the same TCP connection is used between the client and server devices to exchange all the requests and responses. This makes it possible for HTTP/2 to multiplex requests and responses and even to intermingle parts of them. For instance, the client device may start sending a first request, then sends a second request, and then finishes sending its first request. On the other side, the server device may respond to the requests from the client device in any order, for example by intermingling parts of different responses.
To handle efficiently each pair of request and response, and thus to allow efficient multiplexing, HTTP/2 uses a stream identifier (ID), usually a 31-bit integer value, to identify each of the pairs. A stream can be seen as a bidirectional channel between the client and server devices used to exchange one request and the corresponding response in the established TCP connection.
Each time a new request is sent by the client device, a new stream is created. The request is sent through one or more HTTP/2 frames as defined in the above publication, each of them storing the corresponding stream ID in its frame header. The above multiplexing thus consists in multiplexing such HTTP/2 streams within the same TCP connection.
A stream is usually closed once the response associated with a given request has been received by the client device that originated said request. The closure of the stream means that the stream ID is made available for a new request/response exchange.
Since the stream is provided for a single request and the corresponding response, the words “stream” and “request” or “stream” and “response” are used without distinction in the description below because the processing of a request/response by any of the client and server devices means the same as the processing of the corresponding stream by the same device.
HTTP/2 has also introduced a new feature for transmitting data from the server device to the client device, namely the Push feature.
This feature enables the server device to send, under certain circumstances, a resource (i.e. data) to the client device even if the client device has not requested the resource. In this case, it is said that the resource is pushed to the client device.
Pushing a resource is useful as it enables the client device to obtain more quickly the different resources it needs, typically to render a web page.
This is because web pages generally contain links to other resources, which themselves may contain links to other resources. To fully display a web page, all the linked and sub-linked resources generally need to be retrieved by a client. This incremental discovery may lead to a slow display of a web page, especially on high latency networks such as mobile networks.
Using the Push feature, the server device may push the linked and sub-linked resources to the client device before the latter discovers they are needed and requests them.
In order to push a resource to the client device, the server device must first send a PUSH_PROMISE frame which indicates which resource the server device intends to push. Once the PUSH_PROMISE frame for a resource has been sent, the server device creates a new stream in order to transmit said resource. One may note that the client device has the possibility of rejecting the pushed resource, typically by closing the server-initiated stream used to transmit said pushed resource. Note that the PUSH_PROMISE frames can only be sent on streams that have been initiated by clients.
For instance, when the client device requests resource example.html, the request is made through a client-initiated stream. Consequently, if the server device considers that pushing example.js, example.css and example.jpeg would be advantageous for the client device (typically because these resources are referred to in example.html and because the client device will obtain them faster if they are pushed than if it has to request them after parsing example.html), the server device will use the client-initiated stream to send one PUSH_PROMISE frame for each of those three resources.
It should be noted that the HTTP/2 specification recommends that the PUSH_PROMISE frames should be sent “prior to sending any frames that reference the promised responses”. This is because, still referring to our example above, if example.html is sent prior to sending the PUSH_PROMISE frames, the client device may for instance parse example.html, and discover that example.js is needed to process example.html, and then send a request for obtaining example.js, which is not useful if example.js is going to be pushed.
The HTTP/2 Push feature can be used in the context of DASH (standing for Dynamic Adaptive Streaming over HTTP) which is a new standard that has recently emerged from the MPEG standardization committee (“ISO/IEC 23009-1, Dynamic adaptive streaming over HTTP (DASH), Part1: Media presentation description and segment formats”).
Usually, DASH puts the client device in charge of requesting media data, i.e. resources, such as video. In some cases, having the media data provided to the client device using the push approach (i.e. without specific request for each media data) may allow better efficiency. In particular, it may reduce the latency for the client device to obtain a given video segment since the server device can push the video segment to the client device as soon as the video segment is available.
In the context of DASH and in more general context, an application, for instance a web application, may desire to estimate the current connection quality, in particular the available bandwidth and/or network latency over the network.
This information may be of great importance, for instance to select a media (audio, video, images, etc.) with a best and appropriate resolution.
Conventionally, a web application may evaluate the quality of a connection or of the network based on on-going exchanges.
For instance, a DASH client evaluates the available bandwidth based on previous video segments downloaded.
This approach does not require additional data to be transmitted, and thus does not affect the network layer.
However, the results may not always be accurate. For instance, other data may be transmitted in parallel that can modify the evaluation of the available bandwidth.
In the specific case of a web application, the situation may be worse for instance if some resources are already cached or partially cached (e.g. in a proxy local to the client device). This may happen when the server device is pushing data. The data are then partially cached when the web application requests them, thus making it possible for the web application to retrieve them very quickly. As a consequence, over-optimistic bandwidth estimation is obtained.
Another possibility to evaluate the network quality is to do active probing. For instance, the client device asks the server device to send a big chunk of data. Then, based on the sent data, the client device estimates the available bandwidth.
This approach removes the risk for actual caching and, the data being sufficiently large, the network metrics should be correctly evaluated (because the network capacity should be reached).
However, this approach wastes bandwidth resources and may also disrupt the user experience. For instance, regarding DASH, active probing may impact the transmission of video segments due to available bandwidth, thus resulting in pausing the video playback.
When the Push feature is intensively used by the server device, an estimation of the network quality is made difficult for the client device. This is mainly because it may not be aware of when the data is actually being sent. Indeed, on one hand, the server device decides when to send pushed data, while on the other hand, the client device may also make explicit GET requests which will be competing with the Push responses for the same bandwidth, thus leading to pessimistic bandwidth estimation.
In addition, since some data may already be cached, the estimation of the network quality is sometimes too optimistic.
The present invention has been devised to address at least one of the foregoing concerns.
USPTO Backgrounds
USPTO Backgrounds