代码之家 › 专栏 › 技术社区 › Accountant Ù

在cURL中,多接口有时会出错“连接超时”,总时间比超时选项短得多

curl-multi php-curl curl php

0

Accountant Ù · 技术社区 · 7 年前

issue 3602 on GitHub

我正在做一个收集和测试公共/免费代理的项目,注意到当我使用curl_multi接口测试这些代理时,有时会得到很多 28(timeout) 错误。如果我单独测试每个代理,就不会发生这种情况。

问题是,这个问题是不可靠的再现,它没有总是出现, 可能是卷曲的东西 .

不幸的是,我不是一个深度网络调试器,我不知道如何在更深层次上调试这个问题,但是我编写了两个C测试程序(其中一个最初是 written by Daniel Stenberg

对于许多线程上的curl,每个curl操作一个线程。(没有问题)

These are the 2 C programs I wrote for testing

这是 original PHP class 一个月前我用来转载这期杂志的。

以及 these are the 2 C programs tests results

这是测试结果的样本。 请注意第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-timeout与大多数连接不一致,而curl线程却从不这样做?

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

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

curl_多程序联合国

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

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

你可以打开 .pcapng

关于带宽的说明:

打开

我复制了数据并保存了它们 here 在GitHuB上,现在计算 Sum

正常工作所需的整个带宽约为692.8kb。

0 回复 | 直到 6 年前

1

2

S.S. Anne 6 年前

我已经得到了可复制的行为,我正在等待獾对GitHub的答复。尝试运行一个类似Ettercap的程序来获取更多信息。

2

1

Jimmix 7 年前

在我看来,curl本身没有问题,但是如果连接被拒绝,那么并发到代理服务器的连接就太多了。你可能会被永久列入黑名单,或者被列入黑名单一段时间。

如果您仍然想检查这是否是curl,那么您可以设置一个具有多个服务的测试环境。这个测试环境可以传递给curl维护者,这样他就可以复制错误。您可以使用docker创建10、20或100个代理服务器,并连接到它们以查看curl是否有问题。

你需要 docker 它可以安装在Win/Mac/Linux上
其中一个 proxy image 创建代理
创建网络 tutorial 对于集装箱(桥应该可以)
--network
--ip
通过使用 --volume
所有代理容器都应该运行

您可以通过两种方式连接到正在容器中运行的代理。如果你想把卷曲物放在这些容器外面,那么你需要用 -p

或

Alpine linux + curl

在每个步骤中,您都可以发出一个命令

docker ps -a

停止并移除所有容器(不是它们来自的图像,而是正在运行的容器),以防退出的容器出现错误。

docker stop $(docker ps -aq) && docker rm $(docker ps -aq)

或停止并从列表中移除特定容器

docker stop <container-id>
docker rm <container-id>

查看连接到网桥网络的所有容器(默认)

docker network inspect bridge

如果您确认与本地机器上的代理的连接确实有问题,那么curl的维护者可以复制这个内容。

replicate.sh 脚本以

#!/bin/sh

and your comands here

保存该文件并发出then命令

chmod +x ./replicate.sh

使之可执行。

你可以运行它来再次检查是否一切正常

./replicate.sh

并将curl的维护者发送到复制您遇到问题的环境。

docker compose

如果运行大量容器,可以限制资源,例如 memory 他们每个人消费,可能会帮助你在这么多代理的情况下

在cURL中,多接口有时会出错“连接超时”,总时间比超时选项短得多

curl_多程序 联合国

curl_多程序联合国