php - 如何在测试公共(public)代理时可靠地重现 curl_multi 超时

Question

相关信息:issue 3602 on GitHub

我正在从事一个收集和测试公共(public)/免费代理的项目，并注意到当我使用 curl_multi 接口(interface)测试这些代理时，有时我会遇到许多 28(timeout) 错误。如果我单独测试每个代理，这永远不会发生。

问题是这个问题的重现性不可靠，它不会总是出现，它可能是 curl 中的某些东西或其他东西。

不幸的是，我不是一个如此深入的网络调试器，我不知道如何在更深层次上调试这个问题，但是我写了 2 个 C 测试程序(其中一个最初是 written by Daniel Stenberg 但我修改了它输出为与其他 C 程序相同的格式)。这 2 个 C 程序使用 curl 测试了 407 个公共(public)代理

1. 使用 curl_multi 接口(interface)(有问题)

2. 在多个线程上使用 curl，每个 curl 在一个线程上运行。 (没问题)

These are the 2 C programs I wrote for testing我不是 C 语言开发人员，所以如果您在这 2 个程序中发现任何错误，请告诉我。

这是 original PHP class我一个月前用来重现问题的。

和these are the 2 C programs tests results .您可以注意到使用 curl_multi 超时完成的测试，而 curl-threads 的超时是稳定的(407 个代理中大约有 50 个在工作)。

这是测试结果的样本。 请注意第 4 列和第 5 列，了解 curl 线程如何超时大约 170 次并成功连接 40 次。其中，curl_multi 在 407 个代理中有 0 次成功连接和超时约 300 次。

column(1) : #
column(2) : time(UTC)
column(3) : total execution time (seconds)
column(4) : no error 0 (how many requests result in no error CURLE_OK)
column(5) : error 28 (how many requests result in error 28 CURLE_OPERATION_TIMEDOUT)
column(6) : error 7 (how many requests result in error 7 CURLE_COULDNT_CONNECT)
column(7) : error 35 (how many requests result in error 35 CURLE_SSL_CONNECT_ERROR)
column(8) : error 56 (how many requests result in error 56 CURLE_RECV_ERROR)
column(9) : other errors (how many requests result in errors other than the above)
column(10) : program that used the curl
column(11) : cURL version

c(1)    c(2)           c(3)c(4)c(5)c(6)c(7)c(8)c(9) c(10)                  c(11)
267 2019-3-28 01:58:01  40  43  176 183 1   4   0   C (curl - threads) (Linux Fedora)   7.59.0
268 2019-3-28 01:59:01  30  0   286 110 1   10  0   C (curl-multi one thread) (Linux Fedora)    7.59.0
269 2019-3-28 02:00:01  30  46  169 181 1   8   2   C (curl - threads) (Linux Fedora)   7.59.0
270 2019-3-28 02:01:01  31  0   331 74  1   1   0   C (curl-multi one thread) (Linux Fedora)    7.59.0
271 2019-3-28 02:02:01  30  42  173 186 1   4   1   C (curl - threads) (Linux Fedora)   7.59.0
272 2019-3-28 02:03:01  30  0   277 116 1   13  0   C (curl-multi one thread) (Linux Fedora)    7.59.0

为什么 curl_multi 超时与大多数连接不一致，而 curl-threads 从不这样做？

我下载了 Wireshark 并用它来捕获每个 2 C 程序运行时的流量，我也 filtered 2 个 C 程序使用的代理列表的流量，并保存了 files在 GitHub 上。

curl-threads 程序(预期行为)

407 个代理中有 63 个成功连接和 158 个连接超时。

• 这是程序output .
• 这是 Wireshark .pcapng raw file .

curl_multi 程序(非预期行为)

407 个代理中有 0 个成功连接和 272 个连接超时。

• 这是程序output .
• 这是 Wireshark .pcapng raw file .

您可以使用 Wireshark 打开 .pcapng 文件，并在出现预期/意外行为时查看我计算机上记录的流量。我过滤了到 407 代理 IP 的流量，并在 30 秒的 curl 限制后让 Wireshark 打开了一会儿，因为我注意到一些数据包仍然出现。我不知道 Wireshark 和这种级别的网络，但我认为这可能会有用。

---

带宽注意事项:

在 wireshark 中打开 curl_threads 程序的 .pcapng 文件(正常行为)并转到 Statistics > Conversations 。你会看到这样的窗口

数据我已经复制保存了here在 GitHuB 上，现在计算从 A->B 和 B->A 发送的字节的 Sum。

The ENTIRE bandwidth needed to work normally is about 692.8 KB.

Answer 1

我得到了可重现的行为，我正在等待 GitHub 上的 badger 回复。尝试运行 Ettercap 等程序以获取更多信息。