Open PoneyClairDeLune opened 3 weeks ago
Should also support Brotli compression at level 1, because it's...
Can use Content-Encoding: br
under HTTP mode to dynamically adapt.
https://github.com/httptoolkit/brotli-wasm
Potential Brotli implementation.
HTTP/2 fast reset attack: https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
Browser connection limits: https://stackoverflow.com/questions/36835972/is-the-per-host-connection-limit-raised-with-http-2
Potentially, handshakes can timeout after 10 to 30 seconds, while a connection can be considered dead after having no activities for 90 to 150 seconds. Browsers time out after 30 for handshakes, and 120 or 300 for activities. The maximum non-multiplexed allowed connection count between the browser and the server should be 8, as per browser practices (6~8).
Firefox settings (network.http
):
tls-handshake-timeout
: 30
response.timeout
: 300
connection-timeout
: 90
connection-retry-timeout
: 250
keep-alive.timeout
: 115
largeKeepaliveFactor
: 20
max-connections
: 900
max-persistent-connections-per-proxy
: 32
max-persistent-connections-per-server
: 6
max-urgent-start-excessive-connections-per-host
: 3
max_response_header_size
: 393216
network-changed.timeout
: 5
pacing.requests.burst
: 10
pacing.requests.hz
: 80
pacing.requests.min-parallelism
: 6
request.max-attempts
: 10
request.max-start-delay
: 10
tcp_keepalive.long_lived_idle_time
: 600
tcp_keepalive.short_lived_idle_time
: 10
tcp_keepalive.short_lived_time
: 60
http2.chunk-size
: 16000
http2.default-concurrent
: 100
http2.ping-timeout
: 8
http2.ping-threshold
: 58
http2.timeout
: 170
NGINX default timeouts: https://www.baeldung.com/linux/nginx-timeouts#bd-basic-nginx-timeouts
Some considerations to increase throughput or not, taken from designs of NGINX and I2P.
HTTP/2 fast reset attack: https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
Browser connection limits: https://stackoverflow.com/questions/36835972/is-the-per-host-connection-limit-raised-with-http-2
There is another possible attack with client IDs. Since server egress load would be distributed across all underlying connections set with the same client ID, there exists a chance where an attacker could've got some of the victim's S-C messages. Client ID bind messages could've added an extension that allows integration of a simple key verification/challenge if concerned, and rate limits could've been placed to limit how fast client ID binds can happen.
However, with an ID space of 1
to 268435455
(228-1) and with some rate limits set, a collision is unlikely to happen. A successful collision will take 13768938.79 (5th percentile), 28282497.91 (10%), 186065278.45 (50%), 618095475.96 (90%) and 804160754.41 (95%) attempts respectively on average. If a once-per-second rate limit is placed on client ID binds, a collision will happen in 159.36 days under the unluckiest circumstances. Unless proven otherwise, a verification/challenge scheme is largely not needed.
Just a thought: Apart from forcibly offering reconstructed duplex connections, Ditzy could also be used as a multiplexing scheme...