Web 中文兴趣组会议

大家好，我是徐嵩。接下来我的这部分介绍的是W3C的Web与网络组接下来的工作，我本身有个联合汇报人来自阿里巴巴的刘大鹏。

今天分享的内容分为两部分，第一部分是云边端协同，这部分是在W3C Web & Network 兴趣组进行，我会介绍这部分的情况。第二部分是关于云边端协同工作的草案，会请大鹏同学为大家介绍。

首先，Web & Network 兴趣组的使命是探索在万维网的世界，尤其是面向Web开发者涉及到网络相关的技术路线。所以，我们知道在任何一个世界里，很难想象没有网络如何开展业务。所以，我想网络是在座各位比较感兴趣的一点。

另外，在这里并不是漫无目的的探讨科技，主要是探讨当下的情况下，在异构网络和多模态网络下网络的能力，我们主要是为云、边、端等提供更好的资源分配。

在这里，我想介绍一下我们工作组里的具体工作任务。第一部分是对于多路径、多载波、多连接的处理。现在通常讲的网络，服务根据Web应用或者是Web的其他创新业务，基本上可以分为两类：第一类是上行，第二类是下行。在上行里，基于网络快速的分发、内容制作、节目直播，当然也会涉及很多快速的制作或分发，或者是信号弱、人群密集的地方，在网络资源受限的情况下进行快速的内容生产和制作，可能会涉及网络相关的授权和非授权资源的预留，包括切片、QUIC的加速，以及是否需要在一些特殊的影视制作领域，可能会涉及核心网或者是独立的专网。

而在下行，我们会讲音视频的分发，包括单播主播，还有运营商，像电信、移动等5G的模式。

在Web端，我们会根据用户体验和要求提高资源利用率。当然，也会探讨现在已经有的基于HTTP网络下底层的网络技术，包括5G切片、Web Transport以及其他相关的服务，和Web应用之间的关系。

最后，会评价一下Web的度量，增加它的测量、计算的度量，以增加故障排除和网络性能的优化。

这里是这个组的基本发展情况，这个组包括了刚才提到的边缘计算、工作流，第二部分包括了网络的监测、诊断和预测等方面的能力。所以，这是两个主要相关的工作。如果有兴趣的同学，可以去W3C的网站上了解一下这个工作组的基本情况。

以上是关于工作组的基本信息。下一部分是工作组今年最重要的成果输出，是叫云、边、端协同计算工作，在这里请大鹏来介绍。

刘大鹏:

谢谢徐嵩。今天我们的主题是云、边、端协同，我感觉我和徐嵩就是云边端协同了，徐嵩在云端参加，我在线下。

今天下午主要是给大家分享我们在组里孵化的云、边、端，目前是聚焦在场景和需求。解决方案当然也有很多有意思的讨论，在这里也非常欢迎感兴趣的专家加入到组里，和我们一起探讨。

应用场景分了几大类：第一大类，加速的work loads，上午听了很多专家的分享，跟我们也有契合。举个例子，第一个是云的应用，[多媒体演示]第一个图里展示了目前家里经常用的智能音箱，比如对阿里的产品就是“天猫精灵”，这个产品是一个智能音箱硬件的环境，是比较受限。大家，有一些语音识别等功能，需要很大的计算量。现在我们是把这部分计算量放到了云上，更确切的说放在边缘云上，因为有时延的要求。这样的云应用模式，在其他的场景也经常出现。这样的场景会出现一个问题，怎么让编程模型变得更加可用、更加无缝，比如一些work load可以更方便的发现边缘云，需要的时候卸载过去。如果条件不具备的情况可以切换到本地，这是我们想做事情的第一个场景。

第二个是VR和AR，将来戴了眼镜之后肯定有一些渲染的工作，可能是在手机上，也可能放在边缘云进行work load的加速。

另外，非常火的是work Stream，在前端只是效果的展示以及和用户互动的过程，这样可以很大的方便用户使用，另外也是提高整个性能。

接下来的是对于视频的加速。比如现在我们在召开这个会议，徐嵩的头像是可以做一些处理的，比如去背景或者其他的处理。如果这样的工作纯粹放在电脑终端上，有些工作很难处理。比如会场附近有个边缘云，可以把这工作灵活卸载到边缘云上做加速处理，效果就非常好。

另外就是和machine learing处理，其实像徐嵩所在的中国移动咪咕，他们做专业的媒体处理工具，经常有会议场景的直播，很多特效需要与现场非常低的时延、马上完成视频处理，这项工作处理目前的方式，在本地的计算栈或者终端上做，有了边缘技术，有了非常多的想象力。

刚才那一类统一是对work load的加速，各种各样的加速，有些是终端算力不够，有些是用了machine learning还不够，第二种是增强鲁棒性的应用，像车牌识别应用，不加速可以learning，这是字节的同事贡献的案例，离线做可以达到90%，如果有云端或者边缘加速，准确率可以到99%，这是很好的效果。

第三类是IoT相关的work load，像扫地机器人，有些计算量比较大的任务，比如做路径规划，目前的IoT设备有很多需要在云端，但有些没有必要云，可能在本地或者边缘，其他有计算资源的本地网络进行加速提升它的性能。

最后一类是Persistent work loads，有些应用跑在后台，随着应用关闭，但应用本身还没有结束，也需要在云端持续运行，边缘加速。

通过刚才讲的实际案例，我们总结了一些requirements，这是列了一些high level，这里确保整体体验和性能有优化，这就涉及到tead off和评估的过程。

第二种是可扩展性，可以使用比较成熟业界广泛应用的云计算、边缘计算等技术，让它具有很强的可扩展性。

另外是灵活性，不同的设备对计算资源的需求不一样，它所要求的资源数量也不一样，这就需要满足各种各样的应用场景。

另外很重要的一点是兼容性，和现在的Web标准架构上保持一致，不能说今天定了一个新东西，要对现有的架构有大的修改，那肯定不符合架构要求，我们希望是保持兼容性，另外有足够的见状性，也就是在失败的场景下进行回退，保持应用可用。当然，非常重要的是安全和隐私，因为这里面提到一些work load等代码要放在非常安全可信的环境里。

最后是关于控制，控制也涉及到不同的策略以及其他的细节。这是higher level，细节的需求大家可以看详细资料。

还有一些是在头脑风暴阶段，并没有共识说一定要用什么方案。列了几个例子，第一种是使用云、边、端，它可能是基于Java Stream，都是可以的，但是为了满足云边端的不同协议，都需要非常标准化。

第二个例子更适合于IoT或者其他场景，我们有一个sever是在本地或者是云，它有一些机制发现本地资源，可以把work load卸载在本地资源，还要考虑数据和代码的安全、隐私等机制。

关于标准，刚才稍微提了一下，稍微总结一下。需要做的标准还是挺多的，刚才讲的如何让work load卸载到边缘，需要定义一些新的API以及它们的通信机制，还有对网络发现、计算资源的发现以及什么情况下进行切换等等。当然，有一些需要标准化，有一些可能还是留给应用，让它有一定的灵活性，但它们之间的接口需要标准化，因为云边端需要很长的产业链。

关于下一步的推进趋势，我们在IG里进行了讨论。首先，第一项工作的重要性比较高，第二影响范围比较大，虽然和现在的W3C工作组有关联，但还是希望成立单独的工作组，工作组可以进行联合工作，当然这也只是IG目前的结论，不代表正式的结论，在这里供大家探讨。

最后，引用Tim的一句话，对于创造性，今天的创新制约因素就是我们的想象力，因为我们在IG里，经常做各种头脑风暴。所以，感谢我们共同编辑人，也非常期待参与中文兴趣组的专家们，如果对这个方向的研究感兴趣，请加入我们的兴趣组，关注我们的github一起探讨。

已经加入的工作还是很多，包括阿里巴巴、英特尔、中国移动、字节跳动等等，贡献了非常多有意思的场景和各种解决方案。谢谢大家！

提问：非常有意思的一个需求，学术界讲云端协同讲了很多，我只有一个问题，未来云上的场景在云、边的场景是一套代码在不同地方运行，还是边端模型不一样，要应用层去解决差异？

刘大鹏：这个问题非常好，目前我们想的是一套方式，他还是写一套代码在边上部署，但有一些proccess，由runtime或者是服务商决定这套代码什么情况下可以应用。

提问：现在工业界不断里面的代码是什么，就封到容器里，刚才讲的思路是希望用更白盒的方式用他？

刘大鹏：容器只是一种解决方案，现在各种方案都在考虑，但需求是希望加载速度更快，轻量一点。谢谢！