P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?

 

P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?

 

P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?

1、HTTP/HTTPS 下载

有小伙伴会问,这个协议不是用来浏览网页的时候用的吗?

其实不然,用来下载文件一样可以,本质上都是从服务器拉取资源到本地,不同的是网页内容被渲染到浏览器上,而文件直接放在你的下载目录。

将文件资源放到服务器上,然后由服务器传送到不同的用户机器上,称为 Client-Server Model 简称 C/S 模式,或者叫一对多模式,这是一种中心化的下载模式。

缺点很明显:因为服务器的上行带宽(上传速度)有限,如果同一时刻下载同一文件的用户太多,会影响到下载速度。

正因如此,大容量文件如电影一般不会使用 HTTP 协议进行下载。

P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?

例如一些常见软件的下载用的就是 HTTP 协议的方式:

P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
右键复制得到的下载链接:
http://down.crsky.com/soft/201909/TencentVideo-v10.23.4705.0.zip

2、FTP/SFTP 下载

全称 File Transfer Protocol,即文件传输协议

这个其实跟 http 一样,都为中心化的下载模式。不过看名字也知道,这个是比较专业的下载协议,主要区别如下:

  • ftp 一般有身份验证,http 一般没有
  • ftp 是压缩传输,http 一般不压
  • ftp 可以上传,http 一般不能
  • ftp 是双 TCP 连接,http 单的
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?

3、BT 下载

BT,即 Bit Torrent 协议:俗称比特洪流、BT 下载(变态下载??)。采用的 P2P 模式,专门为大容量文件的共享而设计。

弄懂 BT 下载,先来了解 P2P。它全称 Peer to Peer,意为“对等”:

  1. 它是无中心服务器的对等网络系统,而上文说的 C/S 模式是有中心服务器的中央网络系统
  2. 对等网络的每个节点既是客户端,也是服务端。所以用户既可以自己下载文件,也可以上传文件给别人下载。
  3. 所以它叫用户群对用户群( peer-to-peer )模式。用户越多,下载同一文件的人越多,下载该文件的速度就越快

注意:这里跟之前暴雷的 P2P 网贷有相似之处,本质上都是对等网络的思想,所以人们习惯把这种模式的都叫做 P2P。

这里再举个例子充分说明下:为什么下载同一文件的人越多,下载该文件的速度就越快?

假设现在有 6 台电脑,分别叫一毛,二毛……六毛, 他们互相连接着,组成了一个网络。

有一天一毛得到一部小电影,其他五个毛都想要,于是一毛就把小电影复印了五份分别给了其他五个毛。

这就是传统下载。

但是其实还能这样,一毛先把小电影给二毛,后面三毛也想要。

于是一毛跟二毛分别复印小电影的一半同时给三毛,以此类推,四毛想要小电影,那么一二三毛就分别复制小电影不同的三分之一给四毛,四毛再把它们合并起来。

等到五毛想要小电影的时候,由于另外四个毛都有小电影了,那么其下载获取的速度会更快。

不是有首歌在传唱它们的故事吗?

” 啊二毛,你比一毛多一毛 ~ 啊啊,二毛,你比三少一毛~ ” 

P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?

这种去中心化的方式,其好处不言而喻:

  • 速度快。众人拾柴火焰高。
  • 减轻服务器压力。众人平摊了。

与此同时的坏处就是:盗版泛滥。与有中央服务器的网络系统不同,BT 下载节点能遍布整个互联网,所以资源也是分散的,因此无法进行处理。

P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?

一个简单的 BT 种子包含了文件的名字、大小,分块后每块文件的大小、哈希值,以及 Tracker 服务器的地址。(种子:即 .torrent 文件。)

Tracker,即追踪服务器,它对于 BT 下载来说非常重要,通过 Tracker 我们才能找到此资源其他下载者的联系方式,它相当于指路人。

当你用下载软件打开种子,就会开始联系种子文件里内置的 Tracker 服务器,告诉 Tracker 我要下载这个文件,服务器会记录下你的 IP,并把其他正在下载或下载完成此资源的人的 IP 返回给你,这样你们就可以相互成就,在获取发布者该资源的同时,彼此之间也交换该资源。

P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?

4、磁力下载

传统的 BT 下载由于 Tracker 服务器中心化的问题,导致被毁灭打击。那有没有办法让这个所谓的 Tracker 服务器的功能去中心化呢?

当然有的,那就是DHT网络技术

先来看看网上的解释:

DHT 全称为分布式哈希表(Distributed Hash Table),是一种分布式存储方法。在不需要服务器的情况下,每个客户端负责一个小范围的路由,并负责存储一小部分数据,从而实现整个 DHT 网络的寻址和存储。使用支持该技术的 BT 下载软件,用户无需连上Tracker 就可以下载,因为软件会在 DHT 网络中寻找下载同一文件的其他用户并与之通讯,开始下载任务。

举个例子解释:

  • 把 DHT 网络比作一个朋友圈子,当你被 A 带进这个朋友圈,此刻你就只认识 A 而已
  • 但是你的目的是想找普京总统,所以你就问 A 要普京的联系方式,但是 A 也没有普京的联系方式, 他介绍了一个俄罗斯朋友 B 给你认识
  • 于是你去问 B 要普京的联系方式,B 其实也没有普京的联系方式,但是 B 认识一个莫斯科市长 C于是你又得到了 C 的联系方式,C 把普京的联系方式告诉你之后,你就可以写信给普京了

通过上面的例子我们可以得知,DHT 的作用实际是把所有网络的所有节点都变成一个小型 Tracker 服务器,这样就成功解决了传统 BT 下载的问题了。

注:

  1. BT 下载和磁力下载,在本质都是 P2P 下载;区别仅仅是寻找其他下载者的方式不同
  2. 磁力链接并不是取代 BT 种子文件,而是在没有 Tracker 服务器的情况下,可以用一小段链接方便的在 DHT 中找到种子文件
磁力链接示例:
magnet:?xt=urn:btih:761185c0724de8db4362941571ea2c1e16ea950b&dn=Love%2C+Simon+%282018%29+%5BWEBRip%5D+%5B1080p%5D+English&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Ftracker.zer0day.to%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?

5 ED2k 下载

P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?

eD2k 链接对应的客户端,如 eMule 电骡是共享软件,而 Magnet 磁链对应的 BT 软件则是下载软件。这让它们在使用上,有着很多根本性的区别:

  • BT 使用的时候,只要你不下载东西你就不会上传
  • eMule 电骡不同,比如,开启 eMule 电骡后,第一件事做的并不是什么下载,而是设置共享目录,该目录中的所有文件,都会实时共享到 eD2k 网络中。
  • 目录中共享了的文件都会生成 eD2k 链接,所有人通过相应的 eD2k 链接,都能够拿到你共享的文件,一旦有人下载相应文件,那么你的 eMule 客户端就会上传数据,换言之,你想下载别人的文件,需要别人开着 eMule 客户端

由于客户端对于大部分人来说配置起来十分复杂,加上更多人只想单纯的索取,如今使用 eD2k 分享资源的人已经很少了,这里我们就不再继续深入了解。

P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?
P2P、BT、ED2k、FTP、磁力链接下载到底是什么鬼?

转自:https://mp.weixin.qq.com/s/7PxG2SU-nBIZRSnPNi6cgw

一文搞懂主流的扫码登录技术原理

 

转自:imtech

https://my.oschina.net/u/4231722/blog/3154805

1、引言

扫码登录这个功能,最早应该是微信的PC端开始搞,虽然有点反人类的功能(不扫码也没别的方式登录),但不得不说还是很酷的。

下面这张图,不管是IM开发者还是普通用户,应该很熟悉:

一文搞懂主流的扫码登录技术原理

于是,搞IM产品的老板和产品经理们,从此又多了一个要抛给程序员们的需求——“为什么微信有扫一扫登录,而我们的没有?”。

好吧,每次只要是微信有的功能,IM程序员们想甩锅,难度就有点大了,毕竟老板们都都会想当然认为,微信有的“我”的IM产品里也得有。

一文搞懂主流的扫码登录技术原理

既然无法回避,那就只能老老实实搞懂技术原理,然后自已使劲撸吧。

本文将简要的介绍扫码登录功能的技术实现逻辑,并实际结合淘宝、微信的扫码登录功能,学习和研究大厂主流应用的技术实现思路。

2、基本技术原理

2.1 扫码登录功能到底是什么样的?

首先介绍下什么是扫码登录。现在大部分同学手机上都装有微信、qq和淘宝这一类的软件。而这些app都有他们相对应的网页端。为了让用户在使用他们的网页时登录更加方便和安全,使用手机扫一扫就可以登录的服务,就显得自然而然了。

几个主流大厂应用扫码登录时的界面效果如下:

一文搞懂主流的扫码登录技术原理

有很多小伙伴可能会感到很神奇,网页上只是显示了个二维码,它怎么就知道是哪个手机扫到了二维码,并且进行登录的呢?而且,登录完成以后,还能直接把用户信息显示给用户,真的是很神奇啊。

2.2 扫码登录功能的完整技术逻辑

1)网页端与服务器的配合逻辑:

接下来就是对于这个服务的详细实现。

首先用户打开网站的登录页面的时候,向浏览器的服务器发送获取登录二维码的请求。服务器收到请求后,随机生成一个uuid,将这个id作为key值存入redis服务器,同时设置一个过期时间,再过期后,用户登录二维码需要进行刷新重新获取。

同时,将这个key值和本公司的验证字符串合在一起,通过二维码生成接口,生成一个二维码的图片(二维码生成,网上有很多现成的接口和源码,这里不再介绍)。然后,将二维码图片和uuid一起返回给用户浏览器。

浏览器拿到二维码和uuid后,会每隔一秒向浏览器发送一次,登录是否成功的请求。请求中携带有uuid作为当前页面的标识符。这里有的同学就会奇怪了,服务器只存了个uuid在redis中作为key值,怎么会有用户的id信息呢?

这里确实会有用户的id信息,这个id信息是由手机服务器存入redis中的。具体请继续阅读“手机端与服务器的配合逻辑”。

2)手机端与服务器的配合逻辑:

话说,浏览器拿到二维码后,将二维码展示到网页上,并给用户一个提示:请掏出您的手机,打开扫一扫进行登录。

用户拿出手机扫描二维码,就可以得到一个验证信息和一个uuid(扫描二维码获取字符串的功能在网上同样有很多demo,这里就不详细介绍了)。

由于手机端已经进行过了登录,在访问手机端的服务器的时候,参数中都携带一个用户的token,手机端服务器可以从中解析到用户的userId(这里从token中取值而不是手机端直接传userid是为了安全,直接传userid可能会被截获和修改,token是加密的,被修改的风险会小很多)。手机端将解析到的数据和用户token一起作为参数,向服务器发送验证登录请求(这里的服务器是手机服务器,手机端的服务器跟网页端服务器不是同一台服务器)。

服务器收到请求后,首先对比参数中的验证信息,确定是否为用户登录请求接口。如果是,返回一个确认信息给手机端。

手机端收到返回后,将登录确认框显示给用户(防止用户误操作,同时使登录更加人性化)。用户确认是进行的登录操作后,手机再次发送请求。服务器拿到uuId和userId后,将用户的userid作为value值存入redis中以uuid作为key的键值对中。

3)登录成功时的逻辑:

然后,浏览器再次发送请求的时候,浏览器端的服务器就可以得到一个用户Id,并调用登录的方法,生成一个浏览器端的token,再浏览器再次发送请求的时候,将用户信息返回给浏览器,登录成功。这里存储用户id而不是直接存储用户信息是因为,手机端的用户信息,不一定是和浏览器端的用户信息完全一致。

4)详细的技术原理总结如下图所示:

一文搞懂主流的扫码登录技术原理

3、淘宝的扫码登录技术实现

本节我们以淘宝的扫码登录为例,来实际研究分析一下淘宝的扫码登录实现逻辑。

登录界面 https://login.taobao.com/member/login.jhtml 传回来的参数为:

一文搞懂主流的扫码登录技术原理

然后请求(GET)报文是这样的:

https://qrlogin.taobao.com/qrcodelogin/qrcodeLoginCheck.do?
lgToken=2c3b4d53ef0513787bf4ce711ea5ba53&defaulturl=&_ksTS=1540106757739_2804&callback=jsonp2805

关键的就是lgToken,是网页的唯一ID,当打开了二维码登录的时候,网页在轮询(应该是长轮询long polling)调用接口去请求服务器。扩展:彻底理解cookie,session,token

如果没有扫码,返回的为:

一文搞懂主流的扫码登录技术原理

如果扫了的话则会返回:

{

    "code""10001",

    "message""mobile scan QRCode success",

    "success"true

}

长时间没有扫码的话,网页端会停止轮询,二维码失效!

当手机端确认登录后,接口返回的是:


"code""10006"
"success"true,
 "url""https://login.taobao.com/member/loginByIm.do?uid=cntaobaoxxx&token=ff82fc0d1d395a33d3b38ec5a4981336&time=1530179143250&asker=qrcodelogin&ask_version=1.0.0&defaulturl=https://www.taobao.com&webpas=0b7aed2d43f01825183e4a49c6cae47d1479929926"
}

表示登录成功,当然手机端与服务端在点击”确认登录”之间的交互可能就是这样:网页端生成的lgToken去请求服务端,服务端记住了这个lgToken并认为登录了,当网页端再次轮询请求接口时,就返回真正的登录态Token,网页端此时就可以凭着这个Token来登录了。

详细的技术逻辑如下图所示:

一文搞懂主流的扫码登录技术原理

4、微信的扫码登录技术实现

4.1 技术原理流程图

一文搞懂主流的扫码登录技术原理

微信的网页版访问地址是:https://wx.qq.com/,有兴趣也可以自行深入研究。

4.2 实际的技术实现逻辑

1)获取唯一的uuid, 以及包含uid信息的二维码:

一文搞懂主流的扫码登录技术原理

// 获取uuid

getUUID: function() {

    vare = t.defer();

    returnwindow.QRLogin = {},

    $.ajax({

        url: i.API_jsLogin,

        dataType"script"

    }).done(function() {

        200 == window.QRLogin.code ? e.resolve(window.QRLogin.uuid) : e.reject(window.QRLogin.code)

    }).fail(function() {

        e.reject()

    }),

    e.promise

}

2)浏览器轮询服务器,获取扫码状态:

// 查看扫码状态

checkLogin: function(e, a{

    varn = t.defer()

        , a = a || 0;

    returnwindow.code = 0,

    window.checkLoginPromise = $.ajax({

        url: i.API_login + "?loginicon=true&uuid="+ e + "&tip="+ a + "&r="+ ~newDate,

        dataType"script",

        timeout35e3

    }).done(function() {

        newRegExp("/"+ location.host + "/");

        if(window.redirect_uri && window.redirect_uri.indexOf("/"+ location.host + "/") < 0)

            returnvoid (location.href = window.redirect_uri);

        vare = {

            codewindow.code,

            redirect_uriwindow.redirect_uri,

            userAvatarwindow.userAvatar

        };

        n.resolve(e)

    }).fail(function() {

        n.reject()

    }),

    n.promise

}

3)根据服务器返回的扫码状态,进行相应的操作:

408 扫码超时:如果手机没有扫码或没有授权登录,服务器会阻塞约25s,然后返回状态码 408 -> 前端继续轮询

一文搞懂主流的扫码登录技术原理

一文搞懂主流的扫码登录技术原理

400 二维码失效:大约5分钟的时间内不扫码,二维码失效

一文搞懂主流的扫码登录技术原理

201 已扫码:如果手机已经扫码,服务器立即返回状态码和用户的基本信息 (window.code=201,window.code.userAvator=”…”),-> 前端继续轮询

一文搞懂主流的扫码登录技术原理

200 已授权:如果手机点击了确认登录,服务器返回200及token -> 前端停止轮询, 获取到token,重定向到目标页

一文搞懂主流的扫码登录技术原理

具体的代码示例如下:

// 根据服务器返回的扫码状态,进行相应的操作

functiono(c) {
    switch(c.code) {
    case200:
        t.newLoginPage(c.redirect_uri).then(function(t{
            varo = t.match(/<ret>(.*)</ret>/)
                , r = t.match(/<script>(.*)</script>/)
                , c = t.match(/<skey>(.*)</skey>/)
                , s = t.match(/<wxsid>(.*)</wxsid>/)
                , l = t.match(/<wxuin>(.*)</wxuin>/)
                , d = t.match(/<pass_ticket>(.*)</pass_ticket>/)
                , f = t.match(/<message>(.*)</message>/)
                , u = t.match(/<redirecturl>(.*)</redirecturl>/);
            returnu ? void (window.location.href = u[1]) : o && "0"!= o[1] ? (alert(f && f[1] || "登录失败"),
            i.report(i.AUTH_FAIL_COUNT, 1),
            void location.reload()) : (e.$emit("newLoginPage", {
                Ret: o && o[1],
                SKey: c && c[1],
                Sid: s && s[1],
                Uin: l && l[1],
                Passticket: d && d[1],
                Code: r
            }),

            void (a.getCookie("webwx_data_ticket") || n.report(n.ReportType.cookieError, {
                text"webwx_data_ticket 票据丢失",
                cookiedocument.cookie
            })))
        });
        break;

    case201:
        e.isScan = !0,
        n.report(n.ReportType.timing, {
            timing: {
                scanDate.now()
            }
        }),
        t.checkLogin(e.uuid).then(o, function(t{
            !t && window.checkLoginPromise && (e.isBrokenNetwork = !0)
        });
        break;

    case408:
        t.checkLogin(e.uuid).then(o, function(t{
            !t && window.checkLoginPromise && (e.isBrokenNetwork = !0)
        });
        break;

    case400:

    case500:

    case0:
        vars = a.getCookie("refreshTimes") || 0;
        s < 5 ? (s++,
        a.setCookie("refreshTimes", s, .5),
        document.location.reload()) : e.isNeedRefresh = !0;
        break;

    case202:
        e.isScan = !1,
        e.isAssociationLogin = !1,
        a.setCookie("login_frequency"02),
        window.checkLoginPromise && (window.checkLoginPromise.abort(),
        window.checkLoginPromise = null),
        r()
    }

    e.code = c.code,
    e.userAvatar = c.userAvatar,
    a.log("get code", c.code)

}

4.3 小结

微信网页端扫码登录时,轮询的数据返回采用的是JSONP的形式,这是为了解决跨域问题。如对JSONP不了解的,可以参考:

http://www.52im.net/thread-1038-1-1.html

微信网页端扫码登录时,轮询采用了后台根据扫码情况阻塞前台请求,优化轮询及减少前端的无效轮询。这种技术,请详见:

http://www.52im.net/thread-338-1-1.html

5、本文小结

扫码登录这个功能,现在已经不只出现有IM应用里,各种带有移动端的线上网站也都有了这个功能,所以本文中介绍的技术原理并不局限于只用于实现IM应用中的扫码登录。

另外,为了方便抓取真实的数据进行分析研究,本文中的PC端案例分析是针对的是网页端,但实际上如果你的PC端是富客户端(也就是.exe、.dmg这样的安装版),原理也是一样的,而且还不需要考虑浏览器里的跨域问题等。

阅读本文时,可能涉及到传统的Web端即时通讯技术(为了扫码登录的实时性),比如长轮询等,如果您对这些技术还不太了解的话,可以系统学习一下即时通讯网整理的有关Web端即时通讯方面的资料。

转自:https://mp.weixin.qq.com/s/MaEIwiz5Wti6r0pNrI0T0g