我是一名 dev-ops 网络开发人员，我的网站在 AWS 上的负载均衡器后面运行两个 ec2.small。
最近我们发现每秒有 3-4 个请求导致我们客户的网站瘫痪。
网站已瘫痪，在多次服务器重启和错误日志扫描查找可能导致问题的任何脚本后仍无法恢复，尽管最近没有推送任何更改。
打开负载均衡器日志记录后，我发现对单个页面的数千个请求都来自一个 IP 地址。
我们使用 X-forwarded-for 将请求从负载均衡器转发到处理请求的服务器，并使用 .htaccess 规则阻止 IP。
在与客户 IT 部门沟通时，他们被告知，导致大量请求的 IP 地址实际上是他们公司内部的一台机器。
负责的机器被远程重启，所有请求停止。网站重新上线。
对此官方的解释是“计算机出现故障”。
网络浏览器或 Windows 机器是否可以每秒向负载平衡的网页发出 3-4 个请求，并将其关闭 5 个多小时？
请求内容如下：
2017-01-14T01:00:46.170447Z west-ssl XX.XXX.XX.XXX:33370 - -1 -1 -1 503 0 0 0 "GET https://www.example.com:443/example/12 HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" ECDHE-RSA-AES128-SHA256 TLSv1.2
答案1
当然这是可能的——尽管这取决于许多因素：
1) 听起来服务器端应用程序存在并发问题。可能值得查看瓶颈是否是应用程序服务器，或者瓶颈是否是上游（例如 DB），并且由于 apache 配置刷新线程速度不够快而导致应用程序服务器内存不足。如果是应用程序服务器，可能值得进行一些调整 - 在 ELB 之外启动一台相同的机器，并使用 JMeter 向其施加一些负载以找出瓶颈。
如果是数据库，您可能能够使用 memcache/elasticache（因为看起来您正在检索特定对象）来缓存实际查询。这样，数据库连接可以快速响应，Apache 可以快速响应，并终止线程，而不是填满应用程序机器的内存池。
如果您真的觉得自己很脆弱，可以将 Varnish 置于上游，以 1-5 秒的 TTL 缓存请求，以防止出现大量请求洪流。但要小心，因为 VCL 是不可原谅的，可能会导致重大问题和痛苦（缓存中毒/泄漏）。
2) 至于“目标”机器本身。显然它可能已被入侵 - 绝对应该进行调查。我让你来判断 IT 人员是否诚实 - 这超出了 serverfault 的范围。
假设它没有被破坏，那么可能是一些糟糕的 JavaScript 代码 - 如果您进行轮询刷新并且以某种方式修改了时间参数，它很可能会开始每秒发送许多请求。同样，JS 可能表现良好，但该人可能打开了 25 个选项卡并晚上回家 - 如果每个选项卡每 5 秒发送 1 个请求，那就是 5req/秒。