免费的上网工具

免费的上网工具赞扬一波CloudflareCloudflare是我用过的最良心的CDN厂商了,功能多还免费。最近似乎各大厂商都在搞边缘计算,CF也不例外,这不搞了个worker的概念,还给每个用户提供每天免费的10万请求量。太长不看版本直接访问 https://jsproxy.e

大家好,欢迎来到IT知识分享网。免费的上网工具"

赞扬一波 Cloudflare

Cloudflare 是我用过的最良心的 CDN 厂商了,功能多还免费。最近似乎各大厂商都在搞边缘计算,CF 也不例外,这不搞了个 worker 的概念,还给每个用户提供每天免费的 10 万请求量。

太长不看版本

直接访问 https://jsproxy.endpot.workers.dev,测试所谓新概念的在线代理 & CF Worker。

注意:该站点仅用于测试,请勿用于非法用途,否则后果自负!

Worker 是什么鬼?

光看了前面的赞扬,可能你还觉得云里雾里的。简单的说,CF 提供的 worker 就是可以运行用户自定义代码的计算容器。按照 官方文档 可以很方便地把一个纯计算型的站点重写并迁移到 CF 上,从此再也不需要自掏腰包付服务器的费用。

JSProxy

介绍 JSProxy 之前,得先介绍下在线代理相关内容。由于实在是太懒了,我就从 JSProxy 项目中照搬作者原话吧。

什么是在线代理

所谓在线代理,即可通过某个网站访问另一个网站(通常无法直接访问)。不用安装任何插件,不用修改任何配置,仅仅打开一个网页即可。

类似的网站,或许大家都曾见过,并且印象中应该都不怎么好用。相比 ss/v2 这些网络层代理,在线代理的成熟度显然要低得多,只能临时凑合着用。

为什么在线代理不好用

因为要实现一个完善的在线代理,难度非常大!也许你会说,用 nginx 搭个反向代理不就可以了。其实并没有这么简单。举个例子,假如我们用 a.com 反向代理 b.com,并且 b.com 有如下网页:

1
2
<img src="/foo.gif">
<img src="http://b.com/bar.gif">
 

第一个 img 是相对路径。由于当前实际地址是 a.com,因此最终访问的 URL 是 http://a.com/foo.gif。我们的后端服务器收到请求后,抓取 http://b.com/foo.gif 的内容并返回给用户。这没有问题。

第二个 img 是绝对路径,这就有问题了!浏览器会直接访问 b.com,根本不经过我们的后端。而 b.com 是无法直接访问的,于是图片加载失败。

因此后端在代理网页时,还需要对其中的内容进行处理,将那些 绝对路径 URL 替换成自己的地址。例如:

1
2
<img src="/foo.gif">
<img src="http://a.com/proxy?url=http://b.com/bar.gif">
 

这样才能确保图 2 走我们的站点,而不是连接 b.com 导致逃脱代理。

由此可见,衡量一个在线代理完不完善,很重要的一点就是:能否覆盖网页中尽可能多的 URL,减少逃逸现象。

虽然替换网页中的 URL 并不困难,但是,这极其麻烦!

做过 Web 开发的都清楚,网页里的 URL 有千奇百怪的存在形式,可存在于 HTML、CSS、JS 甚至是动态加载的 JSON、XML 等资源中,因此后端只处理 HTML 是不够的,还必须处理各种文本资源!这对服务器是个不小的开销。

除了内容处理,其实还有很多额外开销。互联网上的文本资源大多都是压缩传输,而压缩的数据是无法直接处理的,因此还得先解压;最后处理完的数据,还得再压缩回去。一来一往,消耗不少 CPU。当然也可以不压缩,但这又会增加流量开销。

像过去的 gzip 压缩开销尚可接受,而如今流行的 brotli 压缩开销非常大。假如用户频繁访问大体积的文本资源,代理服务器 CPU 将严重消耗。

不过,上述问题还不是最严重的。事实上 HTML、CSS 等资源都好说,唯独 JS 是个坑 —— 因为 JS 是程序,它可以动态产生 URL。例如:

1
2
var site = 'b';
document.write('<img src=http://' + site + '.com/foo.gif>');
 

遇到这种场合,任何字符串层面的替换都是无解的!

除了动态产生 URL,还有动态获取 URL 的情况。因为有很多 API 是和 URL 相关的,例如:

  • document.domaindocument.URLdocument.cookie
  • 超链接 href 属性,表单 action 属性,各种元素 src 属性
  • 消息事件 origin 属性
  • 省略数十个 …

在我们 a.com 页面里调用这些 API,返回自然是 a.com 的 URL,而不会是 b.com。假如网页里的业务逻辑仍以 b.com 作为标准处理,很可能就会出现问题。

这类情况现实中很普遍,而传统的在线代理,对此则无能为力。

新概念在线代理

讲了那么多在线代理的坑,终于到 JSProxy 上场了。至于作者是如何一步步填坑的,可以看 基于 JS Hook 技术,打造最先进的在线代理,我就不抄过来了。

免费代理

得益于 JSProxy 作者的良心之作,以及 CF 的免费政策,我把 JSProxy 跑在了 CF 的 worker 上,每天有 10 万的免费请求数。

抛个网址 https://jsproxy.endpot.workers.dev 出来,欢迎大家测试,请勿用于违法用途,否则后果自负。

免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/34052.html

(0)

相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注微信