Scope
According to RFC 7540 5.3 and RFC 9218 we should schedule or service from the cache requests according to their priority and dependency. Reprioritization also must be implemented. This issue must implement prioritization suitable for both the HTTP/2 and HTTP/3.
Note priority index structure discussed in #1233 (comment) . There are several approaches for priority algorithms and we need a fast O(1) scheduler:
#712 seems also require WFQ, so probably the algorithm should be generic enough to be applied for h2 messages and server queueing. Note that the priority tree is volatile and can be changed during a web page load and requesting new, higher priority, resources.
It seems to avoid TCP HoL blocking, we should move HTTP/2 fragmentation into TLS layer (just as we form TLS records by a TCP callbak). See Reorganizing Website Architecture for HTTP/2 and Beyond slides 15-20.
Need to address equal QoS (root stream prioritization) for different clients. See The ultimate guide to HTTP resource prioritization at 17:00.
Hooks/API for server-side prioritization (as an extension logic) should be implemented, see Better HTTP/2 Prioritization for a Faster Web.
Security
HTTP/2 dependency and priority feature is the subject for security violations, see chapter "Victim 3-Dependency and Priority" from HTTP/2: In-depth analysis of the top four flaws of the next generation web protocol by Imperva. Like nghttp2 we should limit dependency graph size by MAX_CONCURRENT_STREAMS and throw away old streams on reaching the limit.
Testing
The feature is relatively complex, so a functional test must be developed along with the feature. At least following must be tested:
Also the solution must be benchmarked against CloudFlare, H2O, HAProxy and Nginx implementations with ATF resources in mind (see Of the Utmost Importance:Resource Prioritization in HTTP/3 over QUIC for the methodology and references for benchmarking tools).
References
Scope
According to RFC 7540 5.3 and RFC 9218 we should schedule or service from the cache requests according to their priority and dependency. Reprioritization also must be implemented. This issue must implement prioritization suitable for both the HTTP/2 and HTTP/3.
Note priority index structure discussed in #1233 (comment) . There are several approaches for priority algorithms and we need a fast O(1) scheduler:
#712 seems also require WFQ, so probably the algorithm should be generic enough to be applied for h2 messages and server queueing. Note that the priority tree is volatile and can be changed during a web page load and requesting new, higher priority, resources.
It seems to avoid TCP HoL blocking, we should move HTTP/2 fragmentation into TLS layer (just as we form TLS records by a TCP callbak). See Reorganizing Website Architecture for HTTP/2 and Beyond slides 15-20.
Need to address equal QoS (root stream prioritization) for different clients. See The ultimate guide to HTTP resource prioritization at 17:00.
Hooks/API for server-side prioritization (as an extension logic) should be implemented, see Better HTTP/2 Prioritization for a Faster Web.
Security
HTTP/2 dependency and priority feature is the subject for security violations, see chapter "Victim 3-Dependency and Priority" from HTTP/2: In-depth analysis of the top four flaws of the next generation web protocol by Imperva. Like nghttp2 we should limit dependency graph size by
MAX_CONCURRENT_STREAMSand throw away old streams on reaching the limit.Testing
The feature is relatively complex, so a functional test must be developed along with the feature. At least following must be tested:
Also the solution must be benchmarked against CloudFlare, H2O, HAProxy and Nginx implementations with ATF resources in mind (see Of the Utmost Importance:Resource Prioritization in HTTP/3 over QUIC for the methodology and references for benchmarking tools).
References