☰

偶尔会发生不同的 curl 错误

tag-icon • tag-icon centos curl
偶尔会发生不同的 curl 错误

我有一个运行 Centos7 的 Web 服务器，它向其他资源发出 curl 请求。以每秒 5-10 个请求的速度，一切都运行正常，只是我每 2-10 分钟就会收到不同的 curl 错误。我认为，随着请求数量的增加，这种情况开始随着时间的推移而发生，这让我认为它与网络有关，但我在这方面完全是新手。如何找出导致这些错误的原因以及我该怎么做？

Network: CURL error 56: TCP connection reset by peer
Network: CURL error 7: Failed to connect to ip: Network is unreachable
Network: CURL error 18: transfer closed with 1473 bytes remaining to read

答案1

最有可能的是，导致这些错误的原因可以概括地归类为“SNAFU”......情况正常，全都搞砸了。

互联网是一个由相互连接的计算机和联网设备组成的庞大网络。其他那些你无法控制的机器并不总是能正常工作。它们会遭遇电源故障。它们会遭遇硬件故障。它们会受到宇宙辐射的侵袭。各种意外情况时有发生。

支撑互联网的网络技术就是为此而设计的。互联网之所以能够运行，是因为其冗余度非常高。如果通过一条路由连接到目的地的尝试失败……该链中最后一个“跳转”将记住失败，并尝试不同的“下一跳转”进行未来的通信。实际上，情况比这复杂得多……但您已经明白了要点。

大多数 Web 应用程序都会重试失败的连接，以充分利用这种冗余。但并非所有 Web 应用程序都会这样做。应用程序越简单，失败的可能性就越大。对于应用 *nix 小型单任务工具原则的终端应用程序来说尤其如此。重试是另一个工具的工作。curl就是这样一个应用程序。根据手册curl页：

- 重试

如果 curl 尝试执行传输时返回瞬态错误，它将重试此次数，直到放弃。将数字设置为 0 会使 curl 不再重试（这是默认设置）。 瞬态错误意味着：超时、FTP 4xx 响应代码或 HTTP 408 或 5xx 响应代码。

我不确定您使用哪种用例来curl检索资源，但如果您使用 curl 以自动化方式提供资源，则肯定需要使用--retry值为 3-5 的标志对其进行配置。因为您显示的错误完全正常……并且需要考虑在内。

2.为什么你的生产服务器的可靠性比本地计算机的差？

在完美的世界里生产服务器与互联网资源的连接始终比任何家庭或办公室互联网连接都更可靠。既然情况并非如此，那么您对原因的关注是正确的。但是，这仍然不一定意味着您应该担心，因为，再说一遍，这不一定是由您的服务器引起的问题。

请记住，您的本地计算机和服务器几乎肯定不会共享到相关资源的相同路由。例如。如果我traceroute从本地家庭服务器执行以下操作...superuser.com我会得到以下结果：

user@home ~ $ sudo traceroute -I superuser.com
traceroute to superuser.com (151.101.1.69), 30 hops max, 60 byte packets
 1  rtr.scrapyard.local (10.5.0.1)
 2  96.120.58.37 (96.120.58.37)
 3  po94-sr22.dothan.al.pancity.comcast.net (68.85.202.165)
 4  162.151.221.209 (162.151.221.209)
 5  be-3666-cr02.56marietta.ga.ibone.comcast.net (68.86.90.209)
 6  * * *
 7  50.242.151.138 (50.242.151.138)
 8  151.101.1.69 (151.101.1.69)

但是，如果我从我的一台生产服务器执行同样的命令，我会得到这样的结果：

user@production ~ $ sudo traceroute -I superuser.com
traceroute to superuser.com (151.101.1.69), 30 hops max, 60 byte packets
 1  * * *
 2  ae-20-202.gw-distp-a.slr.lxa.us.oneandone.net (74.208.138.130)
 3  ae-10-0.bb-a.ga.mkc.us.oneandone.net (74.208.1.237)
 4  kanc-b1-link.telia.net (80.239.196.109)
 5  dls-b22-link.telia.net (62.115.125.159)
 6  fastly-ic-340339-dls-b22.c.telia.net (62.115.166.191)
 7  151.101.1.69 (151.101.1.69)

这两条路由唯一的共同点是目的地。它们经过的每台机器都不同。因此，如果dls-b22-link.telia.net出现故障，它会影响我的服务器与 superuser.com 通信的尝试……但不会影响我的家用电脑进行相同尝试。

不幸的是，如果有曾是出现问题时dls-b22-link.telia.net我几乎无能为力。而且鉴于问题的间歇性，dls-b22-link.telia.net一开始就很难确定问题的根源。

所以...

2b. 这真的是个问题吗？

您首先应该确认这是否会导致实际问题，而仅仅重试失败的连接无法解决该问题。这意味着您的生产服务器在执行其工作时受到了某种损害。我假设您在设置时心中有一个目标。你不需要采取行动就能实现这个目标吗？这是关键问题。

回到我之前所说的，像这样的间歇性问题只是互联网的一部分。在完美的世界中，它们不会发生，但我们并不生活在完美的世界中……这就是为什么冗余是互联网所基于的所有技术的基本原则。这就是为什么在发生此类连接故障后重试是标准操作程序。以及为什么你不应该太担心此类故障，除非它们会主动损害你的服务器。

2c. 它在你的控制之下吗？

您需要缩小问题的潜在来源。为此，只需执行您已经做过的相同测试（计算给定时间范围内的失败次数），但这次让服务器从完全不同的地方请求资源。我建议在您的家用电脑上设置一个简单的网络服务器，其中包含几个与您一直在使用的文件类似的文件，并curl在您的服务器上使用它们。

如果服务器在执行此操作时没有出现故障，则问题不太可能出在您的服务器或服务器托管提供商上。并且您现有的测试已经排除了您的本地网络和 ISP 以及资源本身托管位置作为问题的潜在来源。这只剩下您的托管提供商和资源托管提供商之间的节点，完全属于“您无法控制的事情”。

如果服务器做如果您在上述测试中遇到问题，那么由于您已经排除了本地网络/ISP 的问题，因此您几乎可以肯定问题出在您的服务器或服务器托管提供商上。这意味着您可以自行修复。这也意味着您需要进行更多故障排除。

2d. 下一步是什么？

如果问题不在于您的服务器、服务器托管提供商或您正在查询的资源……那么原因本身就不在您的控制范围内。在这种情况下，最好的办法是重新定位服务器（联系您的托管提供商，看看他们可以为您提供哪些选项）。希望这样做的好处是，您将不再需要使用有故障节点的路由。但这很麻烦，而且不能保证一定有效。它甚至可能导致新的问题。因此，在采取这一步骤之前，这绝对是一个需要认真考虑的问题。

另一方面，如果你将问题缩小到你的服务器或服务器的托管提供商，那么你很可能可以修复它。如果你有托管协议，那么请致电你的托管提供商并让他们修复它。如果你没有托管协议，那么你需要排除服务器配置的潜在罪魁祸首。不幸的是，这就是我下车的地方。我们已经到达了我专业知识的极限。

一般来说，如果这是由您的服务器引起的间歇性问题，则可能与网络缓冲有关，或是由某种自动化引起的。以下是一些有根据的猜测：

  • 您是否已采取任何措施来加强您的服务器以抵御恶意探测和攻击？
  • 您是否弄乱了您的/etc/sysctl.conf或中的文件/etc/sysctl.d/？
  • 您是否设置了任何类型的状态数据包检查或入侵检测软件（基于 iptables/netfilter 的防火墙、snort 等）？

无论如何，如果你正处于对服务器本身进行故障排除的阶段，我的建议是利用你收集的信息，在服务器故障。那里的人在服务器问题方面比 SuperUser 上的人有更多的经验，并且更有可能知道下一步该尝试什么。

3. 关于错误的表观一致性

现在，为什么你会一遍又一遍地收到相同的错误？很难说。假设它真的每 5 分钟准时发生一次……仍然可能是任何原因。这些设备中有时钟和计时器，可用于各种用途。可能是其中某项设置为每五分钟执行一次的操作导致了这个微小的故障。

这可能是您的服务器的问题。也可能是您的托管服务提供商的问题。也可能是您的托管服务提供商的 ISP 的问题。也可能是您的家庭/办公室 ISP 的问题。或者介于两者之间。如果不是您的服务器的问题（根据您告诉我的情况，可能不是），那么底线是您对此无能为力……除非确保您已设置为重试失败的连接。例如，所有现代 Web 浏览器都会重试几次，然后放弃从 Web 服务器检索资源。

編輯

  1. 添加了第二和第三部分以响应要求进一步澄清的评论
  2. 重写第二部分以解释更正内容。

相关内容