Closed GoogleCodeExporter closed 9 years ago
这个依赖服务端支持情况,并不是所有服务端都执行分段文��
�请求的
你可以看一下代码,你所说的检测byte字段逻辑是有的,而且�
��点续传在服务端支持的情况下也是可行的
Original comment by yinqiwen@gmail.com
on 26 Nov 2010 at 2:03
抱歉可能是我没说明白,我说的是服务器是GAE的时候。
GAE不能够支持断点续传吗?现在的版本似乎不能哦,我看到Ga
ppproxy那个项目,有另外一个人搞了一个分支,叫Gappproxy2是能
够支持断点续传的啊?
这个项目在这里:
http://www.fcicq.net/wp/?p=881
Original comment by mengq...@gmail.com
on 26 Nov 2010 at 3:33
[deleted comment]
多谢您的回复,我还有个问题,您有没有考虑过用mingw32-gcj编
译一个二进制的版本?这样会速度会比较快一点,似乎rpc框��
�问题消耗的效率过多了,我觉得比gappproxy慢。如果是2进制的
版本(不是打包的假二进制)会快很多吧。
我尝试过,但是我不太懂java失败了(搞不定ant和java的各种依
赖库等等),我听说gcj现在还不能支持swing,所以GUI版本的可
能很难,但是console的应该没问题吧。
Original comment by mengq...@gmail.com
on 26 Nov 2010 at 3:35
1.
gcj现在比JVM慢,这个是业内已经证明了的,原因在于即时编��
�的效率已经很高了;
2. rpc损失的效率微乎其微,在大部分情况下反而更快
3
目前主要的效率问题是你当前机器和google服务的直连情况,��
�果X.appspot.com无法直连,默认是google.hk作为中间proxy的,可以�
��测一下google.hk的直连情况(google.hk经常被连接重置也会影响
hyk-proxy实际运行)
效率的问题要具体分析,像这种IO占主要因素的应用,在运行
环境一致的情况下,用C,JAVA甚至python是不会有太大的差别的
,即使考虑到语言的性能因素,我估计彼此差别在20%以内,��
�接用户是感觉不到这个差别的。另外一个,以语言的效率比�
��,Java是超过python的,这个也是业内已经证明的
Original comment by yinqiwen@gmail.com
on 26 Nov 2010 at 6:12
断点续传肯定是支持的,很早之前就测试过的
linux下你可以用wget通过代理下载一个大文件,比如appengine的SD
K
windows下可以用一些可以设置代理的工具,比如xunlei什么的
Original comment by yinqiwen@gmail.com
on 26 Nov 2010 at 6:14
下载大文件是没问题的,出问题的是从中间下载大文件,这��
�我尝试过很多次都不行?
这是我下载GAE
JAVA的SDK时的情况,我先下载,然后暂停,之后接着下载,就�
��失败。(系统Windows XP SP3 浏览器FF3.6,hyk-proxy的版本是0.9)
我用live http header插件抓了交互包头,如下:
GET /files/GoogleAppEngine-1.3.8.msi HTTP/1.1
Host: googleappengine.googlecode.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.12)
Gecko/20101026 Ant.com Toolbar 2.0.1 Firefox/3.6.12 ( .NET CLR 3.5.30729;
.NET4.0E)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn
Accept-Encoding: gzip,deflate
Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Proxy-Connection: keep-alive
Referer: http://code.google.com/intl/zh-CN/appengine/downloads.html
Range: bytes=1228800-
If-Unmodified-Since: Fri, 15 Oct 2010 01:44:28 GMT
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: public, max-age=604800
Content-Disposition: attachment; filename="GoogleAppEngine-1.3.8.msi"
Content-Length: 9930752
Content-Range: bytes 1228800-9930751/9930752
Content-Type: application/octet-stream
Date: Fri, 26 Nov 2010 06:44:22 GMT
Expires: Fri, 03 Dec 2010 06:44:22 GMT
Last-Modified: Fri, 15 Oct 2010 01:44:28 GMT
Server: DFE/largefile
Via: HTTP/1.1 GWA
x-google-cache-control: remote-fetch
可以看到,我浏览器的请求中包含了Range:
bytes=1228800-,这是断点续传的请求,此时需要一个206回复,但
是代理却回复了一个200,从而导致了下载的失败?
Original comment by mengq...@gmail.com
on 26 Nov 2010 at 6:50
这个不是下载成功了吗?(9930752-1 = 9930751)
Content-Range: bytes 1228800-9930751/9930752
Original comment by yinqiwen@gmail.com
on 26 Nov 2010 at 6:57
没成功,虽然代理返回了数据,但是由于回复给浏览器的是HT
TP/1.1 200 OK而不是HTTP/1.1 206 Partial
Content,所以浏览器会认为服务器不支持断点续传而导致失败�
��迅雷也会这么判断,但是迅雷会重新重头下载,FF就直接报�
��了。
在HTTP 1.1定义中,HTTP
的GET中如果带了Range头,那么服务器需要用HTTP/1.1
206响应,而不是200。
你可以自己拿FF
3.6下一个大文件试试,中途暂停,然后继续,看能不能继续��
�
Original comment by mengq...@gmail.com
on 26 Nov 2010 at 7:03
当初是直接用wget测的,返回206时,wget认为没有完成,返回200
才成功;
这个后续有空再看一下
Original comment by yinqiwen@gmail.com
on 26 Nov 2010 at 7:17
这是因为wget并不是一个完全的HTTP/1.1客户端,这点可以看它��
�wiki,HTTP是一个 HTTP/1.0客户端
但是它支持一些HTTP/1.1的特性。
这是我用wget进行断点续传时的情况,用了-d开关打开了调试��
�息,wget版本1.12,系统是Fedora Core 13,如下:
wget -c -d
http://googleappengine.googlecode.com/files/GoogleAppEngine-1.3.8.msi
DEBUG output created by Wget 1.12 on linux-gnu.
--2010-11-26 15:53:11--
http://googleappengine.googlecode.com/files/GoogleAppEngine-1.3.8.msi
正在连接 10.3.1.87:8000... 已连接。
Created socket 4.
Releasing 0x0000000001d3cc40 (new refcount 0).
Deleting unused 0x0000000001d3cc40.
---request begin---
GET http://googleappengine.googlecode.com/files/GoogleAppEngine-1.3.8.msi
HTTP/1.0
Pragma: no-cache
Range: bytes=153600-
User-Agent: Wget/1.12 (linux-gnu)
Accept: */*
Host: googleappengine.googlecode.com
---request end---
已发出 Proxy 请求,正在等待回应...
---response begin---
HTTP/1.1 200 OK
accept-ranges: bytes
cache-control: public, max-age=604800
content-disposition: attachment; filename="GoogleAppEngine-1.3.8.msi"
content-length: 9930752
Content-Range: bytes 153600-9930751/9930752
content-type: application/octet-stream
date: Fri, 26 Nov 2010 08:10:18 GMT
expires: Fri, 03 Dec 2010 08:10:18 GMT
last-modified: Fri, 15 Oct 2010 01:44:28 GMT
server: DFE/largefile
via: HTTP/1.1 GWA
x-google-cache-control: remote-fetch
---response end---
200 OK
长度:9930752 (9.5M),9777152 (9.3M) 字节剩余 [application/octet-stream]
正在保存至: “GoogleAppEngine-1.3.8.msi”
2% [+ ] 204,800 --.-K/s eta(英国中部时
可以看到,wget的请求时HTTP/1.0的,但是代理的响应是HTTP/1.1的
,这本身就是有问题的,也就是说代理并没有看客户端的HTTP�
��议类型?但是wget是HTTP/1.0的,所以它不认识206的应答,他只
认识这种200并带有Range的应答。
综上,如果要解决这个问题,需要首先看请求的HTTP协议类型�
��如果是1.0,那就回复HTTP1.0头并且应答码为200,头字段可以��
�有Range。如果是1.1,那就回复HTTP1.1头并且应答码为206,头字�
��可以带有Range。
Original comment by mengq...@gmail.com
on 26 Nov 2010 at 8:17
这是因为wget并不是一个完全的HTTP/1.1客户端,这点可以看它��
�wiki,HTTP是一个 HTTP/1.0客户端
但是它支持一些HTTP/1.1的特性。
这是我用wget进行断点续传时的情况,用了-d开关打开了调试��
�息,wget版本1.12,系统是Fedora Core 13,如下:
wget -c -d
http://googleappengine.googlecode.com/files/GoogleAppEngine-1.3.8.msi
DEBUG output created by Wget 1.12 on linux-gnu.
--2010-11-26 15:53:11--
http://googleappengine.googlecode.com/files/GoogleAppEngine-1.3.8.msi
正在连接 10.3.1.87:8000... 已连接。
Created socket 4.
Releasing 0x0000000001d3cc40 (new refcount 0).
Deleting unused 0x0000000001d3cc40.
---request begin---
GET http://googleappengine.googlecode.com/files/GoogleAppEngine-1.3.8.msi
HTTP/1.0
Pragma: no-cache
Range: bytes=153600-
User-Agent: Wget/1.12 (linux-gnu)
Accept: */*
Host: googleappengine.googlecode.com
---request end---
已发出 Proxy 请求,正在等待回应...
---response begin---
HTTP/1.1 200 OK
accept-ranges: bytes
cache-control: public, max-age=604800
content-disposition: attachment; filename="GoogleAppEngine-1.3.8.msi"
content-length: 9930752
Content-Range: bytes 153600-9930751/9930752
content-type: application/octet-stream
date: Fri, 26 Nov 2010 08:10:18 GMT
expires: Fri, 03 Dec 2010 08:10:18 GMT
last-modified: Fri, 15 Oct 2010 01:44:28 GMT
server: DFE/largefile
via: HTTP/1.1 GWA
x-google-cache-control: remote-fetch
---response end---
200 OK
长度:9930752 (9.5M),9777152 (9.3M) 字节剩余 [application/octet-stream]
正在保存至: “GoogleAppEngine-1.3.8.msi”
2% [+ ] 204,800 --.-K/s eta(英国中部时
可以看到,wget的请求时HTTP/1.0的,但是代理的响应是HTTP/1.1的
,这本身就是有问题的,也就是说代理并没有看客户端的HTTP�
��议类型?但是wget是HTTP/1.0的,所以它不认识206的应答,他只
认识这种200并带有Range的应答。
综上,如果要解决这个问题,需要首先看请求的HTTP协议类型�
��如果是1.0,那就回复HTTP1.0头并且应答码为200,头字段可以��
�有Range。如果是1.1,那就回复HTTP1.1头并且应答码为206,头字�
��可以带有Range。
Original comment by mengq...@gmail.com
on 26 Nov 2010 at 8:36
惭愧,没有你研究的这么深入;正如你所看到,断点续传情��
�下目前的逻辑就是只是回200 OK
Original comment by yinqiwen@gmail.com
on 26 Nov 2010 at 9:54
希望能尽快更新啊!修正这个BUG。Hyk-proxy真的挺好用的,比ss
l-vpn使用简单,带宽高,虽然现在主要用sslvpn,但是这个在下
载文件的时候还是无可替代啊!
Original comment by mengq...@gmail.com
on 27 Nov 2010 at 4:31
近段时间会更新一下
Original comment by yinqiwen@gmail.com
on 27 Nov 2010 at 12:48
patch:
替换hyk-proxy安装目录下的plugins/gae/lib/hyk-proxy-gae-client.jar
临时解决近期appspot关键字问题以及本issue
Original comment by yinqiwen@gmail.com
on 9 Dec 2010 at 1:32
Attachments:
用了这个补丁以后好像GAE的plugin的配置界面不好用了啊,点co
nfig按钮后不出来啊。
Original comment by meng...@gmail.com
on 10 Dec 2010 at 1:29
试了一下appspot关键字的patch 还是不能用阿 0.90版本 log如下
Load plugin:GAE ... Success
Load plugin:SPAC ... Success
Active plugin:GAE ... Success
Active plugin:SPAC ... Success
Dec 11, 2010 9:40:35 AM org.jboss.netty.channel.SimpleChannelUpstreamHandler
WARNING: EXCEPTION, please implement
com.hyk.proxy.client.application.gae.rpc.HttpClientRpcChannel$HttpResponseHandle
r.exceptionCaught() for proper handling.
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.net.SocketInputStream.read(SocketInputStream.java:182)
at java.io.FilterInputStream.read(FilterInputStream.java:66)
at java.io.PushbackInputStream.read(PushbackInputStream.java:122)
at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:77)
at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
2010-12-11 09:41:35,466 ERROR
[com.hyk.proxy.framework.Framework.restart(Framework.java:131)] - Failed to
launch local proxy server.
com.hyk.rpc.core.Rpctimeout:
at com.hyk.rpc.core.session.Session$SessionTimeoutTask.run(Session.java:244)
at com.hyk.timer.standard.StandardTimer$1.run(StandardTimer.java:34)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Press <Enter> to exit...
Original comment by zhuyan...@gmail.com
on 11 Dec 2010 at 1:42
Fixed in V0.9.1
Original comment by yinqiwen@gmail.com
on 11 Dec 2010 at 7:47
Original issue reported on code.google.com by
mengq...@gmail.com
on 26 Nov 2010 at 1:54