简体繁体 English

慢速HTTP与Web套接字-资源利用率

[英]Slow HTTP vs Web Sockets - Resource utilization

原文 2015-02-20 04:18:20 7 1 websocket/ denial-of-service

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? 如果一堆与服务器的“慢速HTTP”连接会消耗大量资源以致导致拒绝服务，为什么一堆Web套接字与服务器不会引起相同的问题？

The accepted answer to a different SO question says that it is almost free to maintain a idle connection. 对另一个SO问题的公认答案是，保持空闲连接几乎是免费的。

If it costs nothing to maintain an open TCP connection, why does a "Slow HTTP" cause denial of service? 如果维护开放的TCP连接不花任何钱，为什么“慢速HTTP”会导致拒绝服务？

1 个解决方案

A WebSocket and a "slow" HTTP connection both use an open connection. WebSocket和“慢速” HTTP连接都使用开放连接。 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. 典型的HTTP服务器不需要处理大量打开的连接，而是根据打开连接的数量很少的假设进行设计的。 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. 如果一次只运行几个HTTP请求，则每个连接都可以使用线程。 This is not a good design for a WebSocket server. 对于WebSocket服务器，这不是一个好的设计。
The default file descriptor limits are often adequate for typical HTTP scenarios, but not for a large numbers of connections. 默认文件描述符限制通常足以满足典型的HTTP场景，但不适用于大量连接。

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. 可以设计一个HTTP服务器来处理大量打开的连接，而几个服务器则是开箱即用的。