Add conservative traefik rate-limit to strfry #94
Conversation
| @@ -40,6 +40,8 @@ services: | |||
| - "traefik.http.routers.strfry.rule=Host(`{{ domain }}`) && Headers(`Accept`, `application/nostr+json`) || HeadersRegexp(`Connection`, `(?i)Upgrade`) && HeadersRegexp(`Upgrade`, `websocket`)" | |||
| - "traefik.http.routers.strfry.entrypoints=websecure" | |||
| - "traefik.http.services.strfry.loadbalancer.server.port=7777" | |||
| - "traefik.http.middlewares.strfry.ratelimit.average=1" | |||
| - "traefik.http.middlewares.strfry.ratelimit.burst=10" | |||
There was a problem hiding this comment.
That's right, most would be req requests and I'm assuming many will be long lived for at least a second but it should probably be higher than 1 and tweak according to what we see
There was a problem hiding this comment.
There was a problem hiding this comment.
I would prefer to set these a lot higher. I guess I'm not sure how exactly it does rate limits for websockets, but I assume every socket.write call counts as one request. For example when Nos downloads the home feed it will burst out a bunch of requests for the notes, then their profile pics, metadata. Same in the thread view. Something more like burst 100 and average 5 seem "conservative" to me. I'm not sure how much those would insulate from a bad actor or DDoS but I don't think that's necessarily the intention here, I think we are just trying to prevent some runaway script from infinite looping on us.
There was a problem hiding this comment.
oh I just read the docs about the "token bucket" style of rate limiting traefik is using. With the way it works I think the numbers I listed are pretty safe and won't catch normal apps.
There was a problem hiding this comment.
idk a burst of 100 would definitely catch a Nos user scrolling rapidly through a feed because it's kicking off at least one request for each note. Maybe 1000 is better? And if someone is DDosing it would still time them out them pretty quickly? It's hard to draw these lines without real world data.
There was a problem hiding this comment.
I was thinking about these values more as a binary search exploration because I'm not really sure how they are interpreted, I was assuming it was per connection request, not per internal websocket frame. In any case your proposed values seems safe
Just an idea based on this discussion https://planetary-app.slack.com/archives/C04R70H1KD3/p1713540833552479