更新#2:我已经与NOAA的联系人确认,他们在整个NOAA都存在重大的互联问题。例如,他们只获得了两个地点的降水数据。我确信这是相关的。我让美国国家海洋和大气管理局了解了这个线索,以及你们为确定这是一个连接问题所做的工作。
更新:现在wget命令可以在本地服务器上运行,但不能在1and1.com服务器上运行。我想这就解释了为什么它能在我的浏览器中工作。肯定是东部的连接问题,因为你们中的一些人也有同样的问题。希望这会自行澄清,因为看起来我对此无能为力。
编辑:很明显,提取问题我有它
- NOAA地址的独特之处在于,我的代码和其他网站没有问题
- 在普通浏览器中,所有的获取操作都很正常
- 我无法尝试的方法将获取带有代码的文件
我的问题是,我如何制作能够获取文件和浏览器的代码?
我已经用这个命令来获得一个外部网页将近2年了,现在
wget -O <my web site>/data.txt http://www.ndbc.noaa.gov/data/latest_obs/latest_obs.txt
我在两个不同的服务器上尝试过,结果相同,所以我确信我没有被阻止。
今天早上它突然停止工作了。更糟糕的是,它会让进程在服务器上运行,直到有足够的资源关闭我的帐户,我的所有网站都出错,直到我们一次对49
睡眠进程执行一个kill
。
我没有得到1and1
技术支持的帮助。他们说这是我的cron脚本,只是上面的一行。
所以我决定用php重新编写get文件。我试过file_get_contents
。我也试过curl
、fgets
。但这些都不起作用,所以我尝试了lynx
。
没有什么加载这个特定的URL,但我尝试的所有内容在其他URL上都很好。
但如果我只是复制http://www.ndbc.noaa.gov/data/latest_obs/latest_obs.txt进入浏览器,没有问题-文件显示迅速。
很明显,因为浏览器正在读取这个文件。我尝试过Chrome
、IE
和Firefox
,加载这个页面没有问题,但我在代码工作中没有尝试过。
我想做的是读取这个文件并将其写入本地服务器以缓冲它。然后我的代码可以为各种数据请求解析它。
阅读这个外部网页的可靠方法是什么?
有人建议我添加一个用户代理,所以我将代码更改为以下
function read_url($url){
$agent= 'Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)';
$ch = curl_init();
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_VERBOSE, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_USERAGENT, $agent);
curl_setopt($ch, CURLOPT_URL,$url);
$output = curl_exec($ch);
if(curl_errno($ch)){
echo "<!-- curl_error($ch) -->";
}
curl_close($ch);
return $output;
}
同样,它适用于其他外部网站,但不适用于本网站。
我试着手动运行wget
:这是我得到的
(uiserver):u49953355:~ > wget -O <my site>/ships_data.txt http://www.ndbc.noaa.gov/data/realtime2/ship_obs.txt
--2013-11-17 15:55:21-- http://www.ndbc.noaa.gov/data/realtime2/ship_obs.txt
Resolving www.ndbc.noaa.gov... 140.90.238.27
Connecting to www.ndbc.noaa.gov|140.90.238.27|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 690872 (675K) [text/plain]
Saving to: `<my site>/ships_data.txt'
0% [ ] 1,066 --.-K/s eta 7h 14m
它只是停留在0%
注<my-site>
是存储我的数据的网址。我不想公布我的窃听器区域的地址,但它就像mydomain/buffer/
我刚从另一台服务器(不是1和1)上尝试了同样的东西
dad@myth_desktop:~$ wget -O ships_data.txt http://www.ndbc.noaa.gov/data/realtime2/ship_obs.txt
--13:14:32-- http://www.ndbc.noaa.gov/data/realtime2/ship_obs.txt
=> `ships_data.txt'
Resolving www.ndbc.noaa.gov... 140.90.238.27
Connecting to www.ndbc.noaa.gov|140.90.238.27|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 690,872 (675K) [text/plain]
3% [====> ] 27,046 --.--K/s ETA 34:18
这次卡在3%
。
你的两个wget命令都对我有效。
NOAA似乎也没有阻止您的请求,因为您获得了200个响应代码和HTTP标头(内容长度、类型等)以及部分数据(1066字节位于数据的第7-8行)。
可能是您的连接(通常或特别是与NOAA的连接)很慢,或者通过某种缓冲代理。在代理获取全部或大部分数据之前,对wget来说,连接看起来像是过时了。检索此文件是否有效:http://www.ndbc.noaa.gov/robots.txt?
选项--wget的调试也可能有助于找出问题。
无论如何,关于挂起wget进程,您可以使用--timeout=60选项来限制失败前的等待时间(http://www.gnu.org/software/wget/manual/wget.html)。
wget -O ships_data.txt http://www.ndbc.noaa.gov/data/realtime2/ship_obs.txt --timeout=10
如果要设置用户代理(就像在PHP脚本中所做的那样),可以使用"--user-agent=Mozilla/4.0(兼容;MSIE 6.0;Windows NT 5.1;SV1;.NET CLR 1.0.3705;.NET CLR 1.1.4322)"选项。
wget -O ships_data.txt http://www.ndbc.noaa.gov/data/realtime2/ship_obs.txt "--user-agent=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)"
关于curl与wget,您可以将wget命令替换为curl命令(而不是在PHP中执行):
curl -o ships_data.txt http://www.ndbc.noaa.gov/data/realtime2/ship_obs.txt --user-agent "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)"
Andrei
该文件是可用的,但即使它很小,下载也需要很长时间。在几次尝试中,我经历了长达3分47秒的时间来获取这个23KB的小文件。
这显然是他们网络的一些问题,你对此无能为力
考虑使用set_time_limit(600)
让PHP脚本下载文件的时间更长(10分钟),但同时不要太长,这样在失败时就不会卡住。
由于最初OP无法手动运行wget
命令,我猜测服务器IP被阻止了。
手动运行下面的命令挂断了,所以它增加了我所说的猜测的分量。
wget -O <my web site>/data.txt http://www.ndbc.noaa.gov/data/latest_obs/latest_obs.txt on the hosted server
在检查wget
本身是否工作时,OP对一个伪端点执行wget
。CCD_ 20起作用。
由于OP提到下载有时会进行,但并不总是如此,而且它是从同一托管解决方案的另一台服务器上运行的,我认为我们现在可以将其确定为其他网站网络上的问题。
我的猜测是,cron以非常小的频率运行(比如每分钟),就像一样
* * * * * wget -O <my web site>/data.txt http://www.ndbc.noaa.gov/data/latest_obs/latest_obs.txt
(或以类似的小频率),并且由于外部网站的服务器负载,较早的请求要么超时,要么没有在规定的时间内完成(1分钟)。
因此,OP面临着一些竞争条件,在这种情况下,多个cron进程试图写入同一个文件,但由于接收文件数据包的延迟,它们中没有一个能够完全写入(例如,一个进程从12:10 AM挂起,另一个进程在12:11 AM开始,还有一个在12:12 AM开始,它们都没有通过)
对此的解决方案是让它们变得更不频繁,或者如果OP想要使用相同的频率,那么只有在当前没有进行先前版本的下载时才重新下载。要检查进程是否已在运行,请检查此