我们通过向提供者的服务器发送cURL请求来使用XML Datafeed。 他们不允许我们caching，所以每个网页浏览是一个新的cURL请求。 今年两次，我们的服务器崩溃了，从我们的服务器公司的解释是，属于提供商的域名的IP正在给我们发送大量的stream量。 现在，在我看来，通过“发送大量的stream量”，这可能意味着他们对我们的请求的答案，但是，如果它实际上是他们向我们发送请求，我需要确定，在我开始讨论他们之前技术人员来解决一个可能在我们这边的问题。 如果问题在我们这边，我可以限制请求吗？ （这是用PHP定制的，如果这个问题太多了，请告诉我，我将把它分成更小的块。）
编辑：这是我的托pipe服务提供商说：（他们以前认为/ dev / sda驱动器失败。）
将服务器重新启动到单用户模式后，驱动器不报告任何错误。 另外，所有的文件系统都是完整的。 我们重新启动服务器，一切恢复正常。 我发现在服务器停止响应的时候，服务器上出现了大量的负载峰值，在那段时间，IP 208.215.218.15有很多连接。 现在还有很多来自这个知识产权的联系。 这是关于该IP的信息：
Quick Technologies Inc. UU-208-215-218（NET-208-215-218-0-1）208.215.218.0 – 208.215.218.255 MCI Communications Services，Inc. d / b / a Verizon Business UUNET1996B（NET-208- 208-092-1）208.192.0.0-208.255.255.255
- git拒绝通过http发送凭据？
- 是否有必要在curl成功时validation文件的完整性
- ShellShocktesting显示wget和curl访问
- 将P12证书导入NSS数据库（带有别名）
- 构buildcurl，httpd和其他自定义openssl构build，同时避免默认的系统openssl
来自这个IP的连接迅速填满了你的networking，并且我被迫从这个IP空路由连接为了保持networking。 如果这是合法的，让我知道，我可以取消阻止这个IP。
目前，您的网站已经启动 如果您有任何问题，或者我还能为您做点什么，请告诉我。
然后他们给了我一个这样的日志：（本地IP更改为隐私）
root @ fbs [〜/ system-snapshot / system-snapshot-HG-backup-20120604-144747]＃grep 208.215.218.15 112.log tcp 0 0 123.123.123.198:45948 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123。 123.198：45946 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:45922 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:45921 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:45974 208.215。 218.15：443 TIME_WAIT – tcp 0 0 123.123.123.198:45973 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:46037 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:46036 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:46033 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:46032 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:46030 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123。 123.198：46029 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:46028 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:46026 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:46067 208.215。 218.15：4 43 TIME_WAIT – tcp 0 0 123.123.123.198:46063 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:46062 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:46061 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:46060 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:46059 208.215.218.15:443 TIME_WAIT – tcp 0 0 123.123.123.198:40448 208.215.218.15:80 TIME_WAIT – tcp 0 0 123.123.123.198： 40449 208.215.218.15:80 TIME_WAIT – tcp 0 0 123.123.123.198:40450 208.215.218.15:80 TIME_WAIT – tcp 0 0 123.123.123.198:40451 208.215.218.15:80 TIME_WAIT – tcp 0 0 123.123.123.198:40452 208.215.218.15： 80 TIME_WAIT –
下面有很多类似的线条。 他们终于在另一个答复中回答：
以下是该IP的networkingstream量的随机样本，箭头显示从您的服务器或从该IP到您的服务器的方向（和数据量）：
fbs.foobar.net => 208.215.218.15 5.84Kb 3.51Kb 3.19Kb <= 16.7Kb 181Kb 92.1Kb
fbs.foobar.net => 208.215.218.15 11.3Kb 23.1Kb 16.2Kb <= 0b 27.9Kb 152Kb …
目前从208.215.218.15开始有27个连接，但是目前的stream量很小，如上所述（5-16.7Kbs）
所以看起来从他们到我们的stream量可能仅限于响应我们的curl请求，但我仍然不是100％清楚，或者为什么或如果这导致服务器停止响应。