Django Channels 的负载尖峰保护
Load spike protection for Django Channels
是否可以采取任何具体措施来帮助 Django Channels 服务器不易受到 轻度或意外 DDoS 攻击或来自 websocket/HTTP 客户端的一般负载增加？由于 Channels 并不是真正的异步（仍然是幕后工作人员），我觉得关闭基于 Channels 的网站会很容易——即使使用相当简单的硬件。我目前正在 Django Channels 上构建一个应用程序，稍后将 运行 进行一些测试以查看其运行情况。
Daphne 是否内置了某种形式的节流？我应该实施一些应用程序级别的节流吗？这仍然会很慢，因为工作人员仍在处理受限的请求，但请求可以快得多。我还能做些什么来阻止这些攻击吗？
我的一个想法是始终确保为特定通道指定工作人员 - 这样，如果 websocket 通道过载，HTTP 仍会响应。
编辑：我很清楚低级别 DDoS 保护是一个理想的解决方案，并且我了解 DDoS 攻击的工作原理。我正在寻找的是一种内置于通道的解决方案，可以帮助处理这样增加的负载。也许 Daphne 能够扩大一个通道并缩小另一个通道以进行补偿，或者是一种节流方法，可以在某个点之后减少每个请求的权重。
我正在寻找 daphne/channels 特定答案 - 关于 DDoS 或一般负载处理的一般答案不是我要找的 - 还有很多其他关于此的问题。
我还可以根据谁登录谁未登录来控制限制 - 对未登录用户的限制可能会有所帮助。
再次编辑：请阅读整题！我不是在寻找一般的 DDoS 缓解建议或低级别方法的解释。我想知道达芙妮是否支持类似的东西：
- 节流
- 基于队列大小的动态工作器分配
- 为经过身份验证的请求提供优先级的中间件
或者类似的东西。我还将就此问题直接联系 Channels 社区，因为 SO 可能不是解决此问题的最佳场所。
我只回答第一个问题。所以基本上不可能 100% 免受 ddos 攻击，因为它总是归结为资源之争。如果服务器端资源大于攻击者端资源，则服务器不会宕机（虽然性能可能会降低），但如果不是，则服务器会宕机 [无需参考]。您可能会问，为什么不可能 100% 受到保护。所以基本上你的服务器 "crashes" 如果人们无法连接到它 [https://en.wikipedia.org/wiki/Crash_(computing)#Web_server_crashes --- Web server crashes sentence 1.]. So if you try to protect your server by shutting it down for 5 mins every time 10000 connections are made in a second, the ddos succeeded. It "crashed" your server. The only ddos protection that I know of that should work is Cloudfare (https://www.cloudflare.com/lp/ddos-b/?_bt=207028074666&_bk=%2Bddos%20%2Bprotection&_bm=b&_bn=g&gclid=EAIaIQobChMIu5qv4e-Z1QIVlyW9Ch2YGQdiEAAYASAAEgJbQ_D_BwE)。它通过其 10Tbps 网络吸收了 ddos 攻击的影响 backbone。但即使它不提供 100% ddos 保护，因为一旦它的 10Tbps 下降，你的服务器也会下降。所以，希望对您有所帮助。
DDoS = 分布式拒绝服务
'Distributed' 部分是关键：您不知道自己正受到特别是 'someone' 的攻击，因为请求来自各地。
您的服务器将只接受一定数量的连接。如果攻击者设法创建了很多其他人都无法连接的连接，那么您就会遭到 DDoS 攻击。
因此，本质上您需要能够检测到连接不合法，或者您需要能够快速扩展以弥补连接数量的限制。
祝你好运！
DDoS 保护实际上应该是您的云提供商在负载均衡器级别提供的一项服务。
像 OVH 这样的公司使用复杂的机器学习技术来检测非法流量并以准实时的方式禁止 IP。
对你来说，建立这样一个检测机器是一项巨大的投资，可能不值得你花时间（除非你的网站非常重要，如果它宕机一点就会损失数百万美元）
关于 DDOS，有很多事情是您不能做的。但是有一些巧妙的事情 'tricks' 取决于您拥有多少资源，以及有多少人想让您脱机。
您是否提供总计 public 需要直接连接到您要保护的资源的服务？
如果是这样，您只需要 'soak up' 使用您拥有的资源进行 DDOS，通过扩展和扩展......甚至弹性......无论哪种方式都会花费你钱！
或者让攻击者更难消耗你的资源。有很多方法可以做到这一点。
如果您的服务需要某种身份验证，请将您的身份验证服务与您试图保护的资源分开。
许多应用程序，身份验证和'service' 运行 在同一硬件上。那是等待发生的 DOS。
只允许经过完全身份验证的用户访问您尝试使用动态防火墙过滤规则保护的资源。如果您通过身份验证，那么资源的大门就会打开（QOS 到位）！如果您是知名的、长期受信任的用户，请全力以赴访问该资源。
有一种审计用户资源行为（网络、内存、cpu）的方法，如果您发现特定帐户使用了奇怪的数量，禁止它们或施加限制，最终导致防火墙丢弃策略他们的流量。
与 ISP 合作，该 ISP 的系统可以在 ISP 边界丢弃符合您的规范的流量……OVH 是您最好的选择。一个将过滤器和流量丢弃作为 API 公开的 ISP，我希望它们存在......基本上将你的防火墙过滤规则移动到 AS 边界...... niiiiice！ （幻想）
它不会阻止 DDOS，但会为您提供一些工具，以将攻击者消耗的资源浪费控制在可管理的水平。 DDOS 必须求助于您的身份验证服务器...（可能），或危及许多用户帐户....在已经通过身份验证的用户仍然可以访问 :-)
如果您的 DDOS 正在消耗您所有的 ISP 带宽，那就是一个更难的问题，请转移到更大的 ISP！或移动 ISP 的... :-)。隐藏你的主要资源，让它动态移动，继续前进！ :-)。
将问题分解成小块...对小块应用 DDOS 控制。 :-)
我已经尝试了一个最一般的答案，但有很多取决于，每个 DDOS 缓解都需要一些皮肤，而不是锡方法..真的，你的团队需要一个反 ddos 忍者。 ;-)
看看分布式协议....DP 可能是 DDOS 的答案。
玩得开心。
让我们对您的问题进行一些分析。 DDoS 类似于 DoS，但有朋友。如果你想避免 DDoS 攻击，你需要最小化 DoS 的可能性。谢谢 capitan 显而易见。
首先要做的是列出系统中发生的事情以及受影响的资源：
- 执行 tcp 握手（SYN_COOKIES 受到影响）
- 稍后进行 ssl 握手（熵，cpu）
- 连接到通道层...
然后监控每个资源并尝试实施反制措施：
- 保护SYN_FLOOD 配置您的内核参数和防火墙
- 使用熵发生器
- 配置您的防火墙以在短时间内限制 open/closed 连接（最小化 ssl 握手的简单方法）
- ...
将您的大问题 (DDoS) 分解为许多简单且易于纠正的任务。困难的部分是获取详细的步骤和资源列表。
请原谅我糟糕的英语。
我收到了 answer from Andrew Godwin。他不使用 Whosebug，所以我代表他在这里发布。
Hi Jamie,
At the moment Channels has quite limited support for throttling - it pretty much consists of an adjustable channel size for incoming connections which, when full, will cause the server to return a 503 error. Workers are load-balanced based on availability due to the channels design, so there's no risk of a worker gaining a larger queue than others.
Providing more advanced DoS or DDoS protection is probably not something we can do within the scope of Channels itself, but I'd like to make sure we provide the appropriate hooks. Were there particular things you think we could implement that would help you write some of the things you need?
(It's also worth bearing in mind that right now we're changing the worker/consumer layout substantially as part of a major rewrite, which is going to mean different considerations when scaling, so I don't want to give too precise advice just yet)
Andrew
他还在 blog 中写了关于 2.0 迁移的文章。
是否可以采取任何具体措施来帮助 Django Channels 服务器不易受到 轻度或意外 DDoS 攻击或来自 websocket/HTTP 客户端的一般负载增加？由于 Channels 并不是真正的异步（仍然是幕后工作人员），我觉得关闭基于 Channels 的网站会很容易——即使使用相当简单的硬件。我目前正在 Django Channels 上构建一个应用程序，稍后将 运行 进行一些测试以查看其运行情况。
Daphne 是否内置了某种形式的节流？我应该实施一些应用程序级别的节流吗？这仍然会很慢，因为工作人员仍在处理受限的请求，但请求可以快得多。我还能做些什么来阻止这些攻击吗？
我的一个想法是始终确保为特定通道指定工作人员 - 这样，如果 websocket 通道过载，HTTP 仍会响应。
编辑：我很清楚低级别 DDoS 保护是一个理想的解决方案，并且我了解 DDoS 攻击的工作原理。我正在寻找的是一种内置于通道的解决方案，可以帮助处理这样增加的负载。也许 Daphne 能够扩大一个通道并缩小另一个通道以进行补偿，或者是一种节流方法，可以在某个点之后减少每个请求的权重。
我正在寻找 daphne/channels 特定答案 - 关于 DDoS 或一般负载处理的一般答案不是我要找的 - 还有很多其他关于此的问题。
我还可以根据谁登录谁未登录来控制限制 - 对未登录用户的限制可能会有所帮助。
再次编辑：请阅读整题！我不是在寻找一般的 DDoS 缓解建议或低级别方法的解释。我想知道达芙妮是否支持类似的东西：
- 节流
- 基于队列大小的动态工作器分配
- 为经过身份验证的请求提供优先级的中间件
或者类似的东西。我还将就此问题直接联系 Channels 社区，因为 SO 可能不是解决此问题的最佳场所。
我只回答第一个问题。所以基本上不可能 100% 免受 ddos 攻击，因为它总是归结为资源之争。如果服务器端资源大于攻击者端资源，则服务器不会宕机（虽然性能可能会降低），但如果不是，则服务器会宕机 [无需参考]。您可能会问，为什么不可能 100% 受到保护。所以基本上你的服务器 "crashes" 如果人们无法连接到它 [https://en.wikipedia.org/wiki/Crash_(computing)#Web_server_crashes --- Web server crashes sentence 1.]. So if you try to protect your server by shutting it down for 5 mins every time 10000 connections are made in a second, the ddos succeeded. It "crashed" your server. The only ddos protection that I know of that should work is Cloudfare (https://www.cloudflare.com/lp/ddos-b/?_bt=207028074666&_bk=%2Bddos%20%2Bprotection&_bm=b&_bn=g&gclid=EAIaIQobChMIu5qv4e-Z1QIVlyW9Ch2YGQdiEAAYASAAEgJbQ_D_BwE)。它通过其 10Tbps 网络吸收了 ddos 攻击的影响 backbone。但即使它不提供 100% ddos 保护，因为一旦它的 10Tbps 下降，你的服务器也会下降。所以，希望对您有所帮助。
DDoS = 分布式拒绝服务
'Distributed' 部分是关键：您不知道自己正受到特别是 'someone' 的攻击，因为请求来自各地。
您的服务器将只接受一定数量的连接。如果攻击者设法创建了很多其他人都无法连接的连接，那么您就会遭到 DDoS 攻击。
因此，本质上您需要能够检测到连接不合法，或者您需要能够快速扩展以弥补连接数量的限制。
祝你好运！
DDoS 保护实际上应该是您的云提供商在负载均衡器级别提供的一项服务。
像 OVH 这样的公司使用复杂的机器学习技术来检测非法流量并以准实时的方式禁止 IP。 对你来说，建立这样一个检测机器是一项巨大的投资，可能不值得你花时间（除非你的网站非常重要，如果它宕机一点就会损失数百万美元）
关于 DDOS，有很多事情是您不能做的。但是有一些巧妙的事情 'tricks' 取决于您拥有多少资源，以及有多少人想让您脱机。
您是否提供总计 public 需要直接连接到您要保护的资源的服务？
如果是这样，您只需要 'soak up' 使用您拥有的资源进行 DDOS，通过扩展和扩展......甚至弹性......无论哪种方式都会花费你钱！
或者让攻击者更难消耗你的资源。有很多方法可以做到这一点。
如果您的服务需要某种身份验证，请将您的身份验证服务与您试图保护的资源分开。
许多应用程序，身份验证和'service' 运行 在同一硬件上。那是等待发生的 DOS。
只允许经过完全身份验证的用户访问您尝试使用动态防火墙过滤规则保护的资源。如果您通过身份验证，那么资源的大门就会打开（QOS 到位）！如果您是知名的、长期受信任的用户，请全力以赴访问该资源。
有一种审计用户资源行为（网络、内存、cpu）的方法，如果您发现特定帐户使用了奇怪的数量，禁止它们或施加限制，最终导致防火墙丢弃策略他们的流量。
与 ISP 合作，该 ISP 的系统可以在 ISP 边界丢弃符合您的规范的流量……OVH 是您最好的选择。一个将过滤器和流量丢弃作为 API 公开的 ISP，我希望它们存在......基本上将你的防火墙过滤规则移动到 AS 边界...... niiiiice！ （幻想）
它不会阻止 DDOS，但会为您提供一些工具，以将攻击者消耗的资源浪费控制在可管理的水平。 DDOS 必须求助于您的身份验证服务器...（可能），或危及许多用户帐户....在已经通过身份验证的用户仍然可以访问 :-)
如果您的 DDOS 正在消耗您所有的 ISP 带宽，那就是一个更难的问题，请转移到更大的 ISP！或移动 ISP 的... :-)。隐藏你的主要资源，让它动态移动，继续前进！ :-)。
将问题分解成小块...对小块应用 DDOS 控制。 :-)
我已经尝试了一个最一般的答案，但有很多取决于，每个 DDOS 缓解都需要一些皮肤，而不是锡方法..真的，你的团队需要一个反 ddos 忍者。 ;-)
看看分布式协议....DP 可能是 DDOS 的答案。
玩得开心。
让我们对您的问题进行一些分析。 DDoS 类似于 DoS，但有朋友。如果你想避免 DDoS 攻击，你需要最小化 DoS 的可能性。谢谢 capitan 显而易见。
首先要做的是列出系统中发生的事情以及受影响的资源：
- 执行 tcp 握手（SYN_COOKIES 受到影响）
- 稍后进行 ssl 握手（熵，cpu）
- 连接到通道层...
然后监控每个资源并尝试实施反制措施：
- 保护SYN_FLOOD 配置您的内核参数和防火墙
- 使用熵发生器
- 配置您的防火墙以在短时间内限制 open/closed 连接（最小化 ssl 握手的简单方法）
- ...
将您的大问题 (DDoS) 分解为许多简单且易于纠正的任务。困难的部分是获取详细的步骤和资源列表。
请原谅我糟糕的英语。
我收到了 answer from Andrew Godwin。他不使用 Whosebug，所以我代表他在这里发布。
Hi Jamie,
At the moment Channels has quite limited support for throttling - it pretty much consists of an adjustable channel size for incoming connections which, when full, will cause the server to return a 503 error. Workers are load-balanced based on availability due to the channels design, so there's no risk of a worker gaining a larger queue than others.
Providing more advanced DoS or DDoS protection is probably not something we can do within the scope of Channels itself, but I'd like to make sure we provide the appropriate hooks. Were there particular things you think we could implement that would help you write some of the things you need?
(It's also worth bearing in mind that right now we're changing the worker/consumer layout substantially as part of a major rewrite, which is going to mean different considerations when scaling, so I don't want to give too precise advice just yet)
Andrew
他还在 blog 中写了关于 2.0 迁移的文章。