HTTP/2 Client-Driven Resource Push via Request Headers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current HTTP/2 server push mechanisms require sophisticated knowledge of DASH media presentation description files (MPD) to determine which data to push, leading to resource wastage and inefficient data transmission, as clients and servers may not accurately predict data needs and transmission timing.
Innovation Solution
A method that allows clients to indicate additional resources to be pushed through optional header fields in HTTP requests, enabling servers to identify and send unsolicited resources without requiring extensive application-specific knowledge, using a self-sufficient HTTP request that includes push hints and URI templates to determine additional resources.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If the server device uses sophisticated knowledge of DASH MPD files to determine which data to push, then the data transmission accuracy improves, but the server device complexity increases
Solution Approach 1:
The client device generates push hints based on its own knowledge of upcoming data needs and includes them in HTTP requests to the server. This allows the client to serve its own information needs without requiring the server to have sophisticated DASH MPD parsing capabilities, thereby reducing server complexity while maintaining accurate data delivery.
Solution Approach 2:
Instead of the server determining what data to push based on DASH MPD analysis, the inversion approach has the client indicate what data it needs pushed by including push hints in its requests. This reverses the traditional server-driven push model to a client-guided model, solving the complexity-accuracy contradiction.
2Loss of time
If the server device pushes additional resources proactively, then the web page load time decreases, but the network bandwidth is wasted when data is pushed at undesired times
Solution Approach 1:
The client device provides feedback to the server by including push hints in HTTP requests that indicate what additional resources it wants pushed and when. This feedback mechanism allows the server to push data proactively (reducing load time) while ensuring the client actually needs the data at that time (preventing bandwidth waste).
Solution Approach 2:
The client device performs preliminary action by analyzing its own data needs in advance and encoding these needs in push hints within HTTP requests. This allows the client to prepare the server for upcoming data requests, enabling efficient proactive pushing without wasting bandwidth on unwanted data.
3Device complexity
If the client device requests all linked and sub-linked resources incrementally, then the server device simplicity is maintained, but the web page display speed decreases
Solution Approach 1:
The push hint mechanism acts as an intermediary that carries information about future data needs from the client to the server within existing HTTP requests. This intermediary approach enables the server to proactively push multiple resources without requiring complex server-side resource discovery logic, thus maintaining server simplicity while improving display speed.
Solution Approach 2:
The client device performs preliminary action by encoding information about upcoming resource needs in push hints before making actual requests. This allows the server to prepare and push linked and sub-linked resources in advance, accelerating web page display while keeping the server logic simple through the use of client-provided hints.
Data Source
Figure 1a~1c
Figure 1d~1e
Figure 2
AI summary
The present invention relates to data transmission over HTTP communication networks, for instance data streaming. A method of transmitting data between a server and a client, comprises, at the server: receiving, from the client, an HTTP request to obtain first data, wherein the HTTP request includes first data identifying information allowing identification of the first data on the server and includes one or more additional header fields containing an indication relating to pushing second data; retrieving and sending the first data to the client; and sending acknowledgment data to the client device, the acknowledgment data being representative of the indication relating to pushing second data.