The Modern Internet

【敲黑板】Elastos Carrier为啥这么牛!

亦来云《听大牛讲Elastos Carrier的故事》社区分享会,我们邀请了牛靖宇老师为大家做分享,交流,产生灵感,碰撞,才会有火花。这次关于Elastos Carrier碰撞出了怎样的火花~一起来看看牛靖宇老师的思考。

《【敲黑板】Elastos Carrier为啥这么牛!》

1

Carrier是什么?亦来云为什么做Carrier平台

Carrier本身是很基础的,去中心化的通讯平台,在亦来云整个架构里,Carrier作为去中心化平台,它是整个亦来云基础平台的基础服务之一。

Carrier作为亦来云的基础平台并不直接外露给应用开发者使用。整个平台形态会把Carrier分装在ElastosRT的运行式环境里,由RT来暴露整个Carrier功能接口。虽然现在Carrier对外提供了API,但是也是中间状态,当然也支持开发者在现在Carrier平台API之上开发一些应用,做一些开发,但是最终的形态会是整合在RT内部。目前亦来云内部也有Team专门做RT整合,主要把Carrier所有的通讯能力都整合在RT内部,大家开发的时候只要关注RT的API,使用RT的API就可以使用Carrier所有的功能。

2

Carrier目前包含哪些层次的功能

Carrier目前的技术架构,本身是基于DHT去中心化、分布式的网络基础,在这之上做了friend to frined基础通讯网络,在这个通讯网络上我们提供了几层不同层次的功能接口。

目前Carrier包含以下几个层面的能力:

首先Carrier包含了节点之间的关联关系的支持,在Carrier之上所有的节点都在一个DHT网络中。但是节点和节点相对比较孤立,要建立节点和节点之间的通讯,首先要建立节点之间的关系,所以Carrier有一组API,帮助你必要的节点之间建立关联关系,有点像现实世界的friend一样,或者像微信里的friend。

A和B如果要通讯的话,首先A和B一定是friend的关系,Carrier有基础的API来支持建立节点的关系,这是基础的API。在这个基础上,Carrier还提供了面向消息的API,就是说一旦节点之间建立了关系,就可以使用最基本的消息,这个消息是没有连接的,是透过网络来做的,A和B是friend的话,A和B可以随时发消息,B和A也可以。这个消息在AB之间是不需要建立连接的,直接可以透过DHT网络来中转,实现A和B之间的消息传输,这是消息。

其次,在消息之上提供面向大数据的传输,比如说A和B之间除了消息之外,应用之间还要传输一些大块的数据,大块的数据就有点像我需要建立类似socket这样的通讯机制,Carrier也提供了Session的API,来帮助建立类似这种面向连接或者UDP数据报的数据传输,在Carrier这个体系里我们把它叫stream。

Carrier提供的session的通话能力其实分为两层,一层是类UDP数据报的模式,另外是类TCP流式的模式,这两个模式都是在stream之上实现的,你可以拉选项选定是数据报的模式还是流式的模式。这两种模式从接口上来讲使用是一模一样的,但是其实下面两个工作机制,一个是类TCP,一个是类UDP。

再次,提供了数据的加解密,多路复用,甚至接口转发上层语意,方便Carrier开发者更好的做应用支持,使用起来更方便。同时因为Carrier是一个完全去中心化的网络,它没有中间的或者一组中央服务器来运作,所以说Carrier本身这个网络不会存储任何用户的信息。比如说用户发的任何消息,节点之间的通讯记录,friend的关系,所有这些都是保存在节点自身。

Carrier的接口本身涉及到大量的IO,它下面实现的复杂度比传统网络程序要复杂很多,所以说整个实现是基于异步IO的,下面会有个工作线程,所有用户接口都是异步的。正向的调用归正向调用,反向调用都是call back形式体现出来的,比如说有消息来了,流上数据来了,这些都是透过call back来实现的,这样做相对有好处,就是用户不太关心下面的线程模型。但是对用户来讲,会有些同步和事件处理的复杂度。

所以说整个P2P模式的程序开发会和传统网络应用开发相比有一定复杂度,需要按照异步IO的模式来考虑这个问题,这是Carrier唯一使用的门槛。

3

Carrier下面穿透如何实现?下面具体做的协议是不是采用UDP

Carrier下面具体最底层传输协议一定是UDP,因为在互联网环境里如果做端到端,P2P的通讯只有采用P2P是最经济的,因为TCP穿透力很低,UDP穿透力相对比较高。在国内的网络环境里,这个穿透力基本在70%—80%场景下可以做P2P穿透的,剩下20%—30%的网络场景往往需要人类。

具体的支持在亦来云Carrier环境里,亦来云首先有一些公共节点,在这些节点上都会有relay的支持,后面随着Carrier的落地和应用部署,也会有越来越多的支持relay服务,这是一个人人为我,我为人人的网络。

虽然下面的基础传输协议采用了UDP,但是在CarrierAPI之上我们提供了数据报和流式对等传输能力,这个是通过Carrier内部通讯协议站实现的。应用不管下面实做协议是不是UDP,可以根据应用的需要,采用数据报的形式还是采用流式的形式传输数据,加密和不加密这些都可以应用选择,其实不依赖于Carrier最下层传输协议的选择。

如果关注原代码仓库的话,我们可以完全构建出完整的API参考,现在都有线上API参考,我们可以按照仓库里的说明来建立API参考文档, Carrier的API数量虽然不是很多,但是涵盖的功能还是比较全面的,可以满足大多数应用场景的开发,包括了消息到串流层面的所有支持。

4

Carrier目前接近完成状态了吗

Carrier目前不能说是接近完成状态了,只能说是可用的状态,功能相对稳定、可用,满足大多数应用场景的需要,后续Carrier会有一系列功能加入,这也是跟着社区应用的开发,包括跟着亦来云的需求逐步完善。目前Carrier只是一个起步,后续还会跟着亦来云整体技术框架的演进继续演进,所以不能说是完成的状态,只能说是一个可用的状态。

后面亦来云内部也会针对Carrier去开发一些直接基于Carrier的应用范例,比如说近期会有一个个人云盘的个人范例,仓库开放以后都可以去了解。给出一些典型的应用场景,包括对传统应用的支持,Carrier怎么使用,代码怎么写等等都有很规范的范例出来。

关于端点续传这个不在Carrier层面来考虑,因为Carrier提供的传输通道是类TCP或者类UDP的通道,不太指望socket能支持断点续传,断点续传是你在socket之上应用支持的,针对Carrier也是一样的。Carrier提供这个通道,这个通道是传数据、音频、视频,支不支持断点续传都是由你的应用来决定的。

5

关于应用场景,Carrier有哪些切入点

Carrier本身可以把网络透明化,可以在局域网、互联网,可以在任何网络场景下把两个节点连通,但是我们不鼓励拿着Carrier做翻墙。大家可以跟着自己的应用,跟着需求发散性的设想,说不定有一些比较好的想法,比较好的应用场景出来,

其实从应用场景上来讲,Carrier还是有比较多的应用场景的切入点。比方说基于Carrier做一个去中心化的IM是有可能的,包括现在的家庭设备智能网关,现在讲到智能网关是挺有痛点的切入场景。

因为我有一个朋友做智能家居的,前两年他选择了当时看起来还不错的设备和供应商,把他们的产品作为集成方案里的构成部分推给最终客户。但是两年以后到今天,有些厂商倒闭了,他们的平台也不再运作了,这时候他们家的手机也就不能再开关灯了,不能工作了。为什么呢?因为没有中央平台的支持。

如果引入Carrier来解决这个问题,用户不用在意最终这个厂商是不是倒掉,只要互联网在,开关就可以控制,手机就不会哑掉,这是Carrier的优势。去中心化的思路和中心化的思路,不是完全的对立面,有时候具有非常强的互补性,大家在考虑应用的时候原来传统的基于中心化思路的方案,转变到Carrier这种去中心化的方案上来,可能别有一番洞天。

其实互补性这一说法是亦来云一个外围的伙伴提出来的,因为他们考虑中心化和去中心化的能不能形成一个互补的方案,给用户提供最好、最优的解决方案。从亦来云的角度讲,未来的大趋势应该是去中心化的,中心化本身和去中心化也并不是很矛盾。按照陈榕老师的一些提法,如果给客户一些可选择的中心化,是不是一种去中心化呢?值得推敲,大家可以读一读陈榕老师关于中心化和去中心化的一些观点、看法,会有启发。

具体到relay怎么实现,就涉及到Carrier内部实现P2P穿透的一些基础协议。Carrier实现P2P的穿透基础协议还是采用了标准化的rfcde的规范,我们follow这个规范,所以relay的部分也是按照这个实现的,只是把这个relay的发现、查找以及使用结合DHT能够自动完成,而不需要指定一个中心化的relay类。因为在Carrier网络上会有很多relay,Carrier本身下面的算法会在这个网络上选择一个最自身来讲最优的relay使用,这些具体的机制在RFC都是有规范的。

具体到Carrier的P2P化,在消息层面,消息的整个传输是基于DHT网络来广播传输的。在P2P的section的会话通过是ICE来实做的,所以P2P化分两个层面。一个是DHT本身的运作,另外通过ICE来实现P2P的直连数据传输,提供一个最优的方案,它是一个结合的方案。在这个结合的过程中,中间relay踩了这两边,section会使用relay,relay又通过DHT来部署和发现。

目前Carrier的API接口稳定可靠,因为我们有自动化测试,每天都会跑test cases,从稳定性和AIP的可用性上讲已经达到相当可用的程度了。亦来云做大的一个目标是把亦来云的生态做大,目前亦来云对整个DApp的生态有很大的扶持力度,可以基于亦来云的基础设施做一些DApp开发,因为扶持生态、支持生态我想是亦来云最基本的责任和义务。

6

在Carrier里需要建立UID和ElaID的关联吗

在Carrier里UID就是Carrier的ID,是唯一的,在这个网络上你的ID本身就是唯一的。所有消息的传送和stream的建立都是围绕这个ID完成的,所以你其实不需要一个UID和ElaID的关联,本身Carrier的ID就是在这个网络上唯一的ID。

具体到网络层面包括socket是完全透明,我们看到的完全就是这个ID,透过这个ID就可以访问Carrier所有资源。比如说给ID代表对端发消息,发起所有呼叫,做流的传输,都是通过ID完成的。

Carrier提供的API分成两个层次,一个call的层次,一个section的层次。call本身是必需的,section是可选的,可以根据应用需要选择只引入call还是引入section,通过这个可以控制你的应用规模,可以有选择的引用一些部分,比如说只用到消息就引入call,用到流式数据传输再引入section,这样比较容易控制应用规模。

关于UID的问题,Carrier的节点一点属地化,就会由Carrier自动创建一个节点ID,这就代表了这个节点自身的身份,不需要再额外有ID了。如果在应用层面有所谓UID,那是应用层面需要考虑的,可以由应用来完成真正用户层面表现出来的UID到CarrierID的影射。

关于浏览器直接调用CarrierAPI的支持,可以关注一下北美Kevin在做的一些成果,他是把Carrier提供了一套NodeJS的API分装,同时变成Local可用的服务,比较方便在H5应用调用Carrier的能力。这个仓库在Elastos里有开源, 在这个项目里本身是把Carrier的native的API分装到了NodeJS里,同时希望透过NodeJS提供一个可以供H5访问的服务,在浏览器的应用里可以透个NodeJS提供的服务接口来使用Carrier的API。

在这里,其实还是推荐大家更多的关注ElastosRT,因为Carrier作为亦来云的一个基础服务,相对来说它是层级比较低的服务。最后所有的服务,DID、钱包、主链、侧链都会通过接口的形式装到RT里去,所以建议大家还是使用RT,RT未来会包含钱包接口、DID、Carrier,会包含所有Elastos基础的服务,分装到统一的编程层面,给大家提供统一的服务。

马上我们会开源一个个人云盘应用,这个云盘服务采用了标准oncrowd的个人云盘服务,它本身是一个browse server应用。这时候云盘需要在局域网,或者在公共互联网可访问的主机上,访问云盘的时候要提供一个URL。我们透过Carrier把云盘做了一个改造,改造以后不用考虑云盘的服务在什么位置,你可以在家里,在办公室,在任何位置。不需要关注它的IP也不需要关注URL,只要透过Carrier的ID节可以访问云盘。其实就相当于让云盘无处不在,可以随时随地的访问,跨越了网络的限制。现在我们的云盘应用服务端和IOS端都已经可已使用了,而且在仓库里已经共享,大家可以关注一下,安卓版本还没有正式发布,还在准备当中。

目前提供的个人云盘还是一个自服式的个人云盘,就相当于在家里架设一个服务供个人使用,或者供小范围群体使用。而IPFS是一个人人为我,我为人人众包式的存储平台,也就是说有IPFS矿机,run矿机的人提供存储,如果有存储的用户有存储需求的话付钱存文件,所以它是众包模式的存储服务。

7

那么,别人拿到你的CarrierID存在安全问题吗

Carrier的ID是对外你身份的标识,但是别人拿到你的CarrierID是不能直接访问数据的。首先他要跟你ID建立Friend关系,Carrier有一个基本认证,由应用来完成。所以不存在我知道你的ID,我就可以访问你的数据的问题。另外Carrier还提供了一些No Spam的支持,来防止这种垃圾的请求,大家可以关注一下API,里面有相对清晰的文档描述。所以说这里没有安全的问题,即使有你的ID,也不能访问你的数据。

Carrier本身是一个非常基础的通讯框架,它本身没有任何应用特征和应用属性,也就是说它是相对通用的开发接口,具体上面承载什么样的应用,承载什么样的逻辑,是由应用来实现的。

Carrier可以去做云盘,也可以去做IM,也可以去做智能家居的IOT的Getaway,这些都是可能的,所以Carrier的应用还是有不同的形式,不同的形态,都可以在Carrier目前提供的功能接口上实现。

8

Carrier目前提供群组支持吗

Carrier目前是没有提供群组支持的,但是Carrier未来会增加群组支持,这个可能会在Carrier下一版的开发结果上增加关于群组的支持,包括群组的消息。

目前Carrier直接提供了大多数主流平台的支持,从主机上的Linux、MAK到移动端的IOS、安卓都提供了支持,像树莓派这样的平台都有原生的支持。另外在Windows上应该也是可以的,只是我们官方现在没有提供build,如果有需要的话,大家可以直接尝试提供Windows的build环境。

Carrier整个开销相对很小,首先它静态开销大概在1兆左右,运行式的开销可能也就2、3兆。因为它下面是基于DHT的,运作起来以后要一直维持DHT网络运作,所以会有一些带宽层面的开销,维持一定频度网络数据的传输,这是它相对而言移动端需要注意的一点。

现在我们本身官方build环境已经提供了标准树莓派的支持了,提供了树莓派的编译脚本,大家可以从仓库里下载使用。

关于Carrier运行时资源的消耗,之前我们实做过一个很小的开发板,大概只有一块钱硬币的开发板,上面是Arm9,800兆主题的CPU,有62的Arm,64flash,跑Carrier跑得很顺畅。

目前我们没有提供prebuilt版本出来,但将来正式发布一些稳定的版本之后,会提供标准prebuilt二进制代码出来,可以方便开发者直接下载使用,而不需要从原代码built,但是现在还是需要大家从原代码built。从原代码built,大家可以最优化的根据自己的需要选择选项,而不是构造一个完整的,大而全的包。

另外像安卓平台还有不同的APIlevel选择,可以针对自己项目的需要,来选择最优的APIevel,提供最好的支持。

大家上手Carrier的时候,建议大家看一下Carrier仓库Apps下面有两个应用,一个是Shall,一个是PFD,还有我们马上开放个人云盘的应用,这里有相对比较规范的Carrier使用,都是亦来云官方自己做的一些应用给大家提供比较完备的参考原型,让大家比较容易去上手。特别推荐一下PFD的应用,其实通过PFD的应用大家可以构造出来很多跨网络的应用场景。比方说家里的主机或者办公室的主机,通过PFD可以远程的映射出来ACH的访问,映射出远程桌面等等。

云盘的应用我们是基于标准oncloud做改造的,oncloud本身它有自身的用户和账号体系。整合了Carrier以后,Carrier本身是没有提供账号的,它只提供了一个访问认证。也就是说,你的手机端要访问自己部署的oncloud service的时候,需要透过CarrierAPI做节点之间的关联关系,就是你的手机要和云盘服务做一个配对。这个配对是透过配对码里完成的,你在部署服务service的时候由你自己来设定的,在手机端输入正确的配对码就可以做Carrier的配对。

在做好配对以后才能提供云盘客户端到云盘的访问,没有配对码是不可能实现云盘的访问的。有了配对码以后,还要有正确云盘的账号才能访问oncloud云盘,所以是分成两层,一个是配对的认证,一个是oncloud用户账号认证。

目前Carrier不支持离线消息,也就是说Carrier节点之间发送消息的时候,节点一定要在线。比如说A和B发消息,B不在线的话,这时候这个消息是不能送到B的,网络也没有缓存能力。关于离线消息目前不支持,但是考虑透过一些折中的技术方案未来提供支持,但是当下Carrier还没有提供离线消息的支持。

目前实现现状也是受制于Carrier是完全去中心的网络环境,它没有中央的服务器。也就是说当一个节点不在线的时候,其实这个消息没人替你缓存,除非自己缓存。你应用可以自己缓存,将来等对端上线了以后再发送,其实它不是一个离线消息,还是在上线以后才发送的,这本身是去中心化网络技术本身制约了离线消息的实现。所以未来要实现离线消息的话,也得考虑引入一些其他的新的方案来支持离线消息。

如果在中心化场景里,本身没有任何障碍,但是在去中心化场景里完全没有中心化服务器的话,这就是一个很大的障碍。离线消息是这样,包括类似于安卓、IOS的推送消息,在Carrier体系架构下都会是一些障碍,但是未来这些障碍我们都会通过一些技术方案来回避掉,提供包括离线消息、推送等等。

其实这个问题可以延伸出来中心化、去中心化整个技术方案、技术架构导致的差异。因为有时候中心化有中心化的优势和劣势,去中心化也有自己的优势和劣势。所以在很多技术方案里中心化和去中心化是相对结合的,根据你应用需求让二者统一和谐共存的状态是更合理的一种状态。

9

可选择的中心化是不是一种合适的方案呢

关于这个问题有在考虑,但是这是相对在完全去中心化网络里又比较棘手的问题,和前面离线消息很类似。 Carrier的ID其实是椭圆曲线上的一个密钥对的公钥。可以理解为CarrierID非常类似于钱包的ID。CarrierID是在Carrier节点第一次运行的时候,初始化的时候会生成一个自身的CarrierID。CarrierID是公钥,后面关联着私钥,你所有的通讯都是这个私钥加密的,包括认证。

关于Ddos攻击,因为Carrier的网络是Friend to Friend的网络,也就是说如果这个节点虽然都在DHC网络之上,但是没有建立起任何Friend关系,那这两个节点是不能产生直接通讯的,所以也就无从攻击起。如果这两个节点之间建立Friend可信的关系才能发起通讯,在这种机制下很大程度上制约了Ddos的攻击。

一部手机或者一台电脑可以生成不同的CarrierID,CarrierID本身有点类似于前面提到的钱包。因为Carrier那个节点是没有中央服务器的,所以所有节点的数据都保存在本地,包括你自身的ID和你自身的私钥。所以创建的时候就需要指定一个存储这些信息本地的路径,给定不同的路径都会生成不同的ID。如果给定路径之前已经包含这个ID了,Carrier就会从之前的ID里形成。

Friend的关系是什么呢?因为Carrier的设计原则是采用了Friend to Friend的设计,也就是在Carrier网络之上的节点,只有建立Friend的关系之后才可以直接建立通讯。所有上层API设计都是围绕Friend to Friend的原则展开的,Carrier很适合做IM这种应用,因为它本身是带有Friend to Friend关系的,类似于IOT的Getaway,手机客户端要和Getaway有个数量关系,它适合这样的场景。比如说开放下载,或者作为公共服务提供,Carrier本身设计初衷和设计场景不是为这样的场景服务的,所以这样的场景不太适合采用Carrier来实现,就是有所取,有所不取。你可以根据你应用的需要预先设定一些Friend的关系。另外也可以通过默认的配对码的形式,来后期自动建立这样Friend的关系,也是一个实现方案,这两种都可以,根据你的需要去走。

另外在DH网络里,每一个节点不会存储所有的节点表,会存储由算法决定的临近的节点表。不会存整网的节点表,会存一个片断,而这个片断保存在本地,下次会直接从本地保存的节点表里提取。

目前UDP数据报在开发的定义,我们目前限定是1K。

流式的就没有限制,反正它是个流不是数据报的形式。数据报和流跟UDC和TCP的表现形态是一样的,如果是数据报的形式,你发送多大就完成多大,而流式的就未必了,不能假定这边送了十个那边一定收到十个,它没有所谓报完的概念。

目前Carrier还没有大规模落地推广,所以节点数可能并不是很多,但是具体多少我们目前没有统计。随着未来亦来云对Carrier的推广落地的支持,和越来越应用的落地,这个节点后续会一直有持续的增长。

需要了解到的是,亦来云的节点跟别人是隔离的,所有亦来云的节点是一个独立的DHT网络。亦来云从公益的角度run了自己的bootstrap节点,所以大家bootstrap的时候都是从亦来云标准bootstrap节点起来。目前在开发测试阶段亦来云提供了一组标准的bootstrap,这组标准的bootstrap都buliding in到仓库里了,大家能拿到仓库下的代码,马上能bootstrap起来。

其实在网络上relay的节点越多,公共IP的节点越多,整个网络运行会越健壮。其实在所有DHT网络里都会有这个问题,如果在防火墙内部不能穿透的节点越多,网络的效率会越受影响。在亦来云Carrier的网络也是同样的,希望Carrier会维持一组公共节点来支持整个网络顺畅的运作,包括提供relay的支持,包括提供bootstrap。亦来云未来也会鼓励落地bootstrap节点,就是公共节点,因为公共节点越多对网络性能和健壮性会越好,所以亦来云将来也会奖励大家去run Carrier的公用节点。

Carrier中间所有的数据都有传输加密,比如说节点之间的数据传输,A结点到B节点的数据传输,是拿A和B的公钥、私钥做加密的,它是跟身份有关的加密上下文。所以A发给B的数据只有B能解密,B发给A的数据只有A能解密。因此重点截取数据,对截取者而言没有任何意义,他也不能对数据进行解密,所以不涉及到中间数据的泄露。

点赞
  • 区块链
  • 区块链