[测试版] 3.6.0a，新增 Cloudflare Workers 服务端

[SeaHOH]

https://github.com/SeaHOH/GotoX/releases/tag/v3.6.0a

没有部署过 GAE 服务端的新用户可以直接使用，部署方法可查看 wiki。但建议老用户暂时仍然使用 GAE，直到 CFWorkers 服务端更加完善易用。

同时，欢迎反馈错误和建议。

测试阶段会随时调整代码，反馈前请先看看你是否需要更新。

现已发现问题，勾选代表已解决：

• 无法上传数据。
• 无法转发 WebSocket。
• 大图片下载过慢。
• 混淆的邮件地址无法自动解码。
• 无法正确处理 Range 请求返回的响应。
• 不支持非标准端口（存疑，请求更多测试样本）。
• 标准不支持 chunked 上传，fetch() 要读取全部数据才开始发出请求，对大量数据是个障碍，造成多余的延时和内存使用，单个 Worker 内存使用上限为 128 MB。

[standritsu]

纯CFW模式的话8086还是要走GAE

[SeaHOH]

现在没有纯 CFW 模式，等完善之后，如果测试性能足够的话会增加此种模式。

[lshilshi]

需要有域名？还是说可以自由输入？

[SeaHOH]

Cloudflare 为 Workers 提供有免费域名，参考 wiki 部署即可。

[hg123]

youtube视频看一会后就会出现错误

[k79e]

https://developers.cloudflare.com/workers/reference/apis/streams/
这里有几个chunk词出现 还提到buffer

read: A promise that returns the next available chunk of data being passed through the reader queue.

read(buffer): Returns a promise with the next available chunk of data read into a passed-in buffer.

https://blog.cloudflare.com/edge-side-includes-with-cloudflare-workers/
In this portion, we’re receiving the chunks and searching for ESI blocks and if found, getting the dynamic parts. You can see that when the regex is matching, we’re calling a subRequest() function. This function will fetch the content of the ESI destination and return + encode the received payload.

[k79e]

#143 那里我发现png变渐进的了. 是不是什么压缩规则出了问题呢.
应该只压缩文本. 资源文件等排除才对.

//我直接下的master版

[SeaHOH]

上面提到的是 fetch() 无法实现用 chunked 方式发起请求，其结果 Response 和最终返回都能正常支持。 https://fetch.spec.whatwg.org/#http-network-fetch 这个解释有点谜，为什么 HTTP/2 不能用？fetch() 发起于内部网络，肯定不是 HTTP/1.X。

关于图片，你可以查看 header，应该没有压缩，只是大文件下载速度太慢。fetch() 有几个优化开关，其中图片可以被优化，但是这样只能得到压缩过的，以后可以支持设置部分开关，感兴趣的可以查看 worker 源码 fetch() 的 cf 选项并提出建议，我把能用的都写进去了，具体解释参考 https://developers.cloudflare.com/workers/reference/apis/request/ 。

另，暂时不建议用来看 U2B 等视频网站，大文件优化属于收尾部分的工作。

[k79e]

图片我就是看他非渐进的图片变成渐进了. 载入的时候很明显是变成模糊的. 而且速度很快 然后慢慢变清晰. 我也不知道为啥. 正常情况下是从上到下载入的. 用了代理才那样....

Responses over an HTTP/2 connection will always have the empty byte sequence as status message as HTTP/2 does not support them.

他不是说的支持h2么 如果不支持怎么会有通过h2的响应.
h2不支持的应该是一种状态信息. 所以用空字节代替.

[k79e]

关于图片 很诡异 看起来是cf处理过的. 因为源文件不属于cf网络 没有cdn.

Last-Modified: Sun, 0
Cf-Cache-Status: MISS

第二次载入之后发现多了头部
Last-Modified: Sun,
Cf-Cache-Status: HIT
Cf-Bgj: imgq:100
Cf-Polished: origSize=885498
.....
Content-Length: 778518

所以优化图片的一个参数好像默认开启了. 能关闭的话建议默认关闭. 或者来个开关能控制也好.

//发现开关了 当前开关是无损. 我改下去. 见鬼了配置off也关不掉 不知道为啥 这跟浏览器缓存有关系么
过段时间我再看看去.....

图片压缩bug大了 昨天测试大图发现就小的有渐进效果 其他都没什么变化.(原来是cf会自动忽略)

现在我发现有效果了 原来是cf把资源给缓存了 内容更新有点延时

原来是缓存里面已经有无损压缩的资源 压缩还关闭的话 他还是会返回更小的那个资源.

[k79e]

在这个页面里面提到了 写chunk 不知道是不是发起请求/上传的意思
https://developers.cloudflare.com/workers/reference/apis/streams/
write(chunk): Writes a chunk of data to the writer and returns a promise to indicate if the operation succeeded or failed.

https://developer.mozilla.org/zh-CN/docs/Web/API/Streams_API/%E4%BD%BF%E7%94%A8%E5%8F%AF%E8%AF%BB%E6%96%87%E4%BB%B6%E6%B5%81
Creating your own custom readable stream
这里提到构造一个自定义可读的流 不知道是不是发送数据.

这数据post出去他不会自动分块么?

https://javascript.info/fetch
这地方提到post二进制数据
POST requests
Blob/BufferSource to send binary data,

whatwg/fetch#966
好像他们说那个功能还没做好......

[k79e]

我下载一个文件 然后停止 重复几次程序卡了
不知道这是不是bug

[SeaHOH]

已经找到转发 websocket 的具体条件，等我再完善下细节就更新。

图片的事情先不着急，后面我再专门测试，你也可以试着自己修改 CF 开关选项。

fetch() 要完全读取 body 负载才开始发送请求，这个实在是个大问题。

我下载一个文件 然后停止 重复几次程序卡了
不知道这是不是bug

这确实算 bug，我已经打算转移到原生 async 框架，到时只支持 py37+。

[k79e]

图片没问题了 我改了代码里面的设置. 改off就没事了.

[lshilshi]

@SeaHOH config.ini中 [cfw] 段的password设置为自己worker的登录密码？

[hg123]

最近时不时地会连不上服务端
104.17.175.78 _create_ssl_connection 'xxx.xxx.workers.dev' 返回 timeout('timed out')，重试
104.17.176.17 _create_ssl_connection 'xxx.xxx.workers.dev' 返回 timeout('timed out')，重试
这时域名网址无法直连却可以通过其他代理访问 过一段时间后又能恢复正常
是我的网络原因吗？

这段时间基本上连不上服务端了 如果长时间不用 可以短暂连一会 然后很快就断开了
另外好像只要与cloudflare有关的其他网站也都打不开了

[SeaHOH]

我这里没发现此类现象，可能你的网络不稳定，同时发起的请求是否特别多，其它国外服务能否正常访问？

[hg123]

我之前都是浏览同样的网页却没有出现这个问题 ，近一个月来却极不稳定 。
连不上服务器后，好像国内使用cloudflare的cdn的网站也打不开了
你说的其它国外服务器是指没有被墙的吗？

应该是我网络的问题 ，家里的宽带只是偶尔会出现这种情况 ，但很快就会恢复。
但办公室的电脑只要一连被墙网站，很快就会被防火墙之类的切断连接似的

[hg123]

刚刚把通过cfw代理的网站全部换到gae代理，速度极快。前段时间一直很慢。

[SeaHOH]

你说的其它国外服务器是指没有被墙的吗？

是的。

刚刚把通过cfw代理的网站全部换到gae代理，速度极快。

谷歌经常折腾，反正免费的越来越不好用了。用的人少了，线路丢包情况可能会比之前好。

[hg123]

刚才试了下 如果用了cfw被阻断后 国外没有被墙的网站全都上不了

如果用gae的话就不会出现这种情况

[SeaHOH]

明显是你的网络问题。以后会尝试增加更多的远程代理，暂时就这样吧。

[k79e]

现在看起来支持chunk了?
https://streams.spec.whatwg.org/#read-request-chunk-steps

[SeaHOH]

具体没看太明白，反正要服务器添加支持才能使用，有没有具体实现还是问号。
想来也不可能很快大规模普及，尤其考虑到安全和兼容问题，大部分没有实际需求的服务商都不愿意部署吧。

[k79e]

Chunks are enqueued into the stream by the stream’s underlying source. They can then be read one at a time via the stream’s > public interface, in particular by using a readable stream reader acquired using the stream’s getReader() method.

getReader() https://streams.spec.whatwg.org/#rs-get-reader
有样例的样子

还有可写数据流
Chunks are written to the stream via its public interface, and are passed one at a time to the stream’s underlying sink. For web developer-created streams, the implementation details of the sink are provided by an object with certain methods that is passed to the WritableStream() constructor.

看样子最新版是能读能写chunk的样子
参考
2.2. Writable streams
5.2.3. The underlying sink API
5.2.4. Constructor, methods, and properties

[k79e]

https://developer.mozilla.org/en-US/docs/Web/API/Streams_API

https://developer.mozilla.org/zh-CN/docs/Web/API/ReadableStream
https://developer.mozilla.org/zh-CN/docs/Web/API/WritableStream

[k79e]

就关于你提到的非标准端口 我前段时间测了 用的反代 可以连上 (我随便填了好几个端口 都连上了 应该没啥问题)
//但是不可以回接国内 这个影响不大
所以worker是支持那个的 cdn就不行了 只有那么几个端口可以用

[SeaHOH]

好像只是接口变化，但 Request 本质没变，还是要完全接收数据才开始。

[SeaHOH]

不支持非标准端口，是指被代理的请求端口，不是指连接 worker 服务器使用的端口。

[k79e]

就是目标地址 可以是其他端口的
worker不是只有web端口 怎么能随便输入端口呢....