0

If a bunch of "Slow HTTP" connection to a server can consume so much resources so as to cause a denial of service, why wouldn't a bunch of web sockets to a server cause the same problem?

The accepted answer to a different SO question says that it is almost free to maintain a idle connection.

If it costs nothing to maintain an open TCP connection, why does a "Slow HTTP" cause denial of service?

Community
  • 1
  • 1
Vijay Purush
  • 322
  • 1
  • 12
  • if everything was fine with the web socket connections then there wouldn't be any problems. Slow HTTP is a deliberate attack which is why it'll lag the server. A websocket connection that is not being attacked is a working websocket. – Rafael Feb 20 '15 at 04:21
  • @Rafael I'm still not clear on what makes a "slow" HTTP connection an attack. TCP connection remains open in both cases, but web sockets don't seem to cause an attack. – Vijay Purush Feb 20 '15 at 10:08

1 Answers1

2

A WebSocket and a "slow" HTTP connection both use an open connection. The difference is in expectations of the server design.

Typical HTTP servers do not need to handle a large number of open connections and are designed around the assumption that the number of open connections is small. If the server does not protect against slow clients, then an attacker can force a server designed around this assumption to hit a resource limit.

Here are a couple of examples showing how the different expectations can impact the design:

  • If you only have a few HTTP requests in flight at a time, then it's OK to use a thread per connection. This is not a good design for a WebSocket server.

  • The default file descriptor limits are often adequate for typical HTTP scenarios, but not for a large numbers of connections.

It is possible to design an HTTP server to handle a large number of open connections and several servers do so out of the box.

  • Well, can you please elaborate your statement "not designed to handle a large number of open connections"? I want to know the technical difference between a server that would suffer from slow HTTP connections and the ones that would continue to operate properly even after accepting a large number of web socket connections. – Vijay Purush Feb 20 '15 at 17:40
  • Thanks. I think i understand the difference now. One thread per http connection - but not one thread per web socket connection. – Vijay Purush Feb 21 '15 at 05:53