分类: 协议

  • 🔒 Merkle DAG的可验证性

    在构建去中心化网络的数据结构时,使用加密强度的哈希算法来生成内容标识符(CID),为我们的数据提供了高度的可验证性。当用户通过内容地址检索数据时,他们总是可以自己计算CID,以确保获得了所需的内容。这种机制不仅保证了数据的永久性(通过内容地址的数据永远不会改变),还提供了防止恶意篡改的保护(恶意行为者无法在用户未意识到的情况下诱使其下载错误的文件)。

    🌳 Merkle DAG的特点

    在Merkle DAG中,每个节点的CID依赖于其每个子节点的CID。因此,根节点的CID不仅唯一标识该节点,还独特地标识整个DAG。这意味着我们可以将CID的安全性、完整性和永久性保障扩展到整个数据结构,而不仅仅是它所包含的数据。

    想象一下,你在编辑过程中临时备份了一个文件目录,几个月后发现这两个目录并不相同。这时,你可以计算每个备份的Merkle DAG:如果根目录的CID匹配,你就可以安全地删除一个备份,从而释放硬盘空间!

    🌟 任何节点都可以是根节点

    DAG可以视为递归数据结构,每个DAG由更小的DAG构成。在我们的示例中,CID “baf…8″标识一个DAG,而CID “baf…6″也标识一个DAG,只是它识别的是一个更小的子图。只要在正确的上下文中,这两个节点都是根节点。

    这一特性极为强大且实用。当我们检索结构为DAG的内容时,我们不必检索整个DAG:我们可以选择检索一个子图,使用其顶节点的CID来识别(这个子图的顶节点将成为其根节点)。如果我们想与他人分享这个子图,我们只需发送子图的CID,而无需包含我们原本检索的数据的上下文。如果我们想将这个子图嵌入到一个不同的、更大的DAG中,我们也可以做到,因为DAG的CID(即其根节点的CID)依赖于其后代的根节点,而不是其祖先。

    🔄 确保存在根节点

    有时,我们的数据没有立即呈现单一的根节点:这并不是DAG的严格要求。例如,考虑以下员工层级结构,其中有两个没有上级的经理和一个有两个经理的员工。

    在这种情况下,没有单一节点可以作为所有五个节点的根节点,因此无法使用任何baf…1-5来共享或检索整个DAG。然而,这并不妨碍我们创建一个新的DAG:我们可以通过创建一个附加节点,使“Asif”和“Ciara”节点作为其子节点,从而使用这个新节点作为根节点。

    另一种选择是将“Asif”或“Ciara”作为各自的根节点,创建两个独立的数据结构(Padma的节点将同时包含在这两个DAG中)。重要的区别在于,这将构成两个独立的Merkle DAG,因为你无法从其中一个根节点导航到该数据集中的所有节点(DAG中的链接是有向的,而“Padma”和“Ciara”之间没有链接,因此无法从“Asif”的根节点到达“Ciara”或“Aiden”)。


    参考文献

    1. ProtoSchool. (n.d.). IPLD Tutorial | Merkle DAGs: Structuring Data for the Distributed Web (Lesson 5).
    2. Protocol Labs. (n.d.). Overview of IPFS and Filecoin.

    通过了解Merkle DAG的可验证性和灵活性,我们能够更有效地构建和管理去中心化网络中的数据结构,确保数据的安全性和完整性。让我们继续深入探索更多精彩内容!

  • 🌟 正确结构化数据的优势

    在去中心化网络的世界里,数据的结构与组织显得尤为重要。我们在ProtoSchool的《Merkle DAG教程》中了解到,数据结构的选择将直接影响我们与数据的互动方式。想象一下,一个包含数年照片的图库,每张图片展现了不同的人、地方和事件。我们可以用多种方式来构建这个数据,甚至选择不构建任何结构!然而,每一种选择都将产生重要的后果。

    📂 结构的意义

    数据的结构不仅是为了美观,它更像是一个索引,直接影响我们找到和检索特定图片的速度。结构还可以为数据增加语义,通过将相关对象进行分组,帮助我们更好地理解和管理信息。

    例如,考虑以下的目录结构:

    pics
    ├── cats
    │   ├── 2018-02-23-tabby.png
    │   └── 2019-12-16-black.png
    └── fish
        ├── 2017-03-05-freshwater.png
        ├── 2018-04-14-tropical.png
        └── 2020-10-02-blowfish.png

    在这个示例中,我们有一个名为“pics”的根目录,里面包含了我们的整个照片集合。我们将照片分为“cats”和“fish”两个子目录,以便根据主题进行分类。每张照片的文件名还反映了拍摄日期,这种结构帮助我们快速识别文件的相关性。例如,“2018-04-14-tropical”与“fish”和“pics”有直接的联系,而“pics”则是这个文件所包含集合的更一般描述。

    🔄 结构化的权衡

    没有一种绝对最佳的数据结构方式;每种选择都伴随着显著的权衡。随着数据集的规模扩大,量身定制其结构以适应我们的使用和访问方式变得尤为重要。在这个例子中,按照动物类型组织照片使我们能够轻松查找特定动物的图片。但如果我们想要找到所有文件中时间戳最早的图片,这就会变得相对困难,需要逐个查看所有目录。

    如果我们的目录中有成千上万的照片,这种查找将会极其繁琐。相反,如果我们将照片按照拍摄日期的先后进行组织,情况将会完全不同。

    🛠️ 数据结构与CID的结合

    结构赋予我们的数据意义和组织,而内容标识符(CID)让我们能够在去中心化网络中以安全、可验证且无需协调的方式引用数据。在接下来的课程中,我们将看到如何构建可内容寻址的数据结构,使我们能够同时拥有这两种强大的能力!

    通过理解数据结构的重要性和优势,我们能够更有效地管理和访问信息,使去中心化网络的潜力得以充分发挥。


    参考文献

    1. ProtoSchool. (n.d.). IPLD Tutorial | Merkle DAGs: Structuring Data for the Distributed Web (Lesson 2).
    2. Protocol Labs. (n.d.). Overview of IPFS and Filecoin.

  • 🌐 数据的结构性:深入探索Merkle DAG

    在当今的去中心化网络中,数据不仅仅是无序的二进制流,而是潜藏着结构与意义的宝贵信息。正如我们在ProtoSchool的《内容寻址在去中心化网络中的应用》教程中提到的,内容标识符(CID)就像数据的指纹,独特而简洁。CID的核心是数据本身的加密哈希,使其成为一个可靠的链接,指向特定的数据块。

    🔗 链接的力量

    链接不仅仅是用来识别特定内容的工具,它们还在组织和遍历结构化信息方面发挥着重要作用。想象一下,电话簿、书目、思维导图等,这些日常生活中常见的对象和系统都是数据结构的具体体现。链接在这些结构中扮演着关键角色,帮助我们理解各种数据之间的关系。

    📚 数据结构的基础

    无论你是程序员还是普通用户,结构化数据无处不在。列表、字典和目录等都帮助我们组织信息,并考虑到不同数据片段之间的关系。随着我们对数据的深入理解,逐渐需要对数据属性进行正式描述,这便催生了数据结构这一概念。根据维基百科的定义,数据结构是一种数据组织、管理和存储的格式,能够实现高效的访问和修改。

    在编程中,数据结构无处不在。如何将数据组织成变量以便在程序中使用,通常涉及从数十种到数百万种数据结构。例如,常见的数据结构如数组、对象和图等,都是程序设计的基石。

    🌍 去中心化网络中的信任问题

    在去中心化网络中,我们直接从同行那里访问数据,而不是依赖中央权威。在一个孤立的环境中,比如个人的笔记本电脑,我们可以对内存或磁盘上的数据结构有很高的信任。然而,在去中心化系统中,同行之间的信任度可能很低,甚至为零。因此,我们需要一种高效的方式来链接数据结构,同时保留验证其完整性的能力(这是CID的一个重要特性)。

    例如,当我们遍历从去中心化网络获得的链表时,我们希望能确保没有恶意行为者能够在中间插入项目而不被发现。

    🏗️ Merkle DAG的构建

    在本教程中,我们将探索如何开发一种特殊的数据结构,称为Merkle DAG,以适应这些需求。Merkle DAG为一个值得信赖的分布式数据网络提供了基础,允许数据之间的可靠链接。

    这样的结构不仅能够保证数据的完整性和安全性,还使去中心化网络的应用变得更加安全和高效。Merkle DAG的出现标志着数据结构发展的新阶段,它为我们提供了一种新的视角来理解去中心化网络中的数据组织。


    参考文献

    1. ProtoSchool. (n.d.). IPLD Tutorial | Merkle DAGs: Structuring Data for the Distributed Web (Lesson 1).
    2. Wikipedia. (n.d.). Data Structure.
    3. Protocol Labs. (n.d.). Overview of IPFS and Filecoin.

  • DWeb教程:去中心化网络上的内容寻址(第四课)

    欢迎来到ProtoSchool的第四课!今天我们将深入探讨密码学哈希内容标识符(CIDs)。准备好了吗?让我们一起揭开这些概念的神秘面纱。

    🖼️ 不只是可爱的图片

    在之前的课程中,我们一直在讨论可爱的图片,但内容寻址不仅限于此。实际上,它可以应用于所有类型的文件和数据,从JSON对象到论文再到视频,内容寻址的应用范围非常广泛。为了使密码学哈希正常工作,我们需要了解正在处理的数据格式,并使用适当的工具。

    🔑 什么是内容标识符(CID)?

    内容标识符(CID)是去中心化网络中一种特定形式的内容寻址。它是为IPFS(一个去中心化网络协议)开发的,但它的应用前景非常广泛。CID的魅力在于它是一个单一的标识符,包含了一个密码学哈希和一个编解码器(codec),后者提供了有关如何解释该数据的信息。编解码器的作用是对数据进行编码和解码。

    +-------+------------------------------+
    | Codec | Multihash                    |
    +-------+------------------------------+

    许多格式和协议已经在使用内容寻址,例如Git、以太坊和比特币,但它们在解释数据和使用的加密哈希函数方面有所不同。CID使我们能够为任何这些系统创建一个通用标识符。

    🔍 CID的构成

    每个CID都是一个标识符,包含用于解释数据的编解码器和一个自描述哈希(multihash),即一个告诉你使用了哪种哈希函数来创建它的哈希值。

    +------------------------------+
    | Codec                        |
    +------------------------------+
    |                              |
    | Multihash                    |
    | +----------+---------------+ |
    | |Hash Type | Hash Value    | |
    | +----------+---------------+ |
    |                              |
    +------------------------------+

    如果你想了解更多关于CID如何在IPFS中构建的细节,可以查看我们的《CID的解剖》教程。

    🌐 小结

    今天我们探讨了CID的概念,它为我们在去中心化网络中标识和处理各种类型的数据提供了便利。通过结合密码学哈希和编解码器,CID为内容寻址带来了新的可能性。

    在接下来的课程中,我们将继续深入探讨如何在去中心化网络上利用这些工具。若你在学习过程中有任何疑问,ProtoSchool非常欢迎你的反馈,以帮助我们改进课程内容。准备好迎接最后一课的挑战了吗?

    参考文献

    • ProtoSchool. (n.d.). DWeb Tutorial | Content Addressing on the Decentralized Web (Lesson 4). Retrieved from ProtoSchool.
  • DWeb教程:去中心化网络上的内容寻址(第三课)

    欢迎回到ProtoSchool!在这一课中,我们将深入探讨去中心化网络中的内容寻址。准备好揭开这一崭新世界的面纱了吗?

    🔗 走出中心化的阴影

    在中心化网络中,我们依赖可信的权威机构来托管我们的数据,使用基于位置的URL来访问。然而,在去中心化网络中,我们有了另一种选择:每个人都可以托管彼此的数据,这种链接方式更加安全,从而使我们更容易信任我们的“邻居”。

    🔐 密码学哈希:去中心化的核心工具

    密码学哈希是去中心化数据结构中最重要的工具。它为我们打开了一种新的链接形式——内容寻址,使我们不再依赖中心化的权威。

    哈希过程会将任何大小和类型的数据转换为一个固定大小的“哈希值”。这个哈希值就像是数据的独特名称,虽然看起来像是一串乱码(例如:bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi),但它的安全性却让人印象深刻。

    🖼️ 哈希的神奇之处

    密码学哈希是基于数据本身生成的,这意味着使用相同算法处理相同数据的人会得到相同的哈希。例如,如果Ada和Grace都在使用IPFS共享同一张小猫的照片,那么两张照片的哈希值将完全相同。通过比较这些哈希,我们可以确认这两张照片每一个像素都是一致的。

    而且,哈希是唯一的。如果Grace在Photoshop中删除了一根猫胡子,更新后的图像将生成一个新的哈希。即使不访问文件本身,仅通过哈希,我们也能轻易识别出文件内容已经不同。

    🛡️ 去中心化网络中的信任

    在中心化网络中,我们习惯于信任某些权威机构,而不信任其他机构。虽然我们尽力从URL中获取线索,但仍然有一些恶意行为者利用位置寻址的缺陷来欺骗我们。

    然而,在去中心化网络中,我们共同托管彼此的数据,内容寻址使我们能够信任共享的信息。我们可能对托管数据的同伴知之甚少,但哈希可以防止恶意行为者欺骗我们。这就是密码学哈希在去中心化网络中如此重要的原因。

    🕵️‍♀️ 向节点请求内容

    在传统的基于位置的寻址中,我们知道需要访问puppies.com来找到存储为beagle.jpg的内容。如果puppies.com域名出现问题,我们将失去访问那张图片的权限。

    然而,在去中心化网络中,情况就大不相同。当我们想要获取一张可爱的宠物照片时,我们是通过内容地址(哈希)来请求的。我们要向谁询问呢?整个网络!如果Ada在线,我们会看到她拥有我们需要的内容,并且由于哈希匹配,我们知道这正是我们需要的文件。如果她下线,我们可能仍然可以从Grace或其他节点获取同样的照片。

    在去中心化网络上,由于我们使用哈希来请求数据,我们可以将哈希视为一种链接,而不仅仅是一个名称。

    参考文献

    • ProtoSchool. (n.d.). DWeb Tutorial | Content Addressing on the Decentralized Web (Lesson 3). Retrieved from ProtoSchool.
  • DWeb教程:去中心化网络上的内容寻址(第一课)

    欢迎来到ProtoSchool!在这里,我们将为你揭开去中心化网络的神秘面纱。准备好了吗?让我们一起探索如何识别和检索网络上的数据。

    📚 什么是内容寻址?

    在我们深入之前,你可能在想:什么是内容寻址?简单来说,它是我们在去中心化网络中识别和获取数据的方式。与我们熟悉的中心化网络不同,去中心化网络有其独特的方式来处理数据。

    🏙️ 位置寻址与内容寻址的对比

    想象一下,你有两个朋友,Lars和Courtney,他们向你推荐同一本书。Lars告诉你:“去纽约市的Strand书店,在二楼的儿童区找到第三个书架,去左边16英寸的地方找书。”而Courtney则说:“看一下Anna Claybourne写的《Cutest Kittens Ever》,它的ISBN-13是9781682972168。”

    如果你的目标是获取这本书,你会更倾向于哪个描述呢?是Lars的详细位置,还是Courtney的内容信息?

    • 位置寻址:Lars的描述指向的是一个特定的地点,他希望书店依然有这本书。这在中心化网络中是常见的,数据定位依赖于特定实体。
    • 内容寻址:Courtney的方式则是基于内容提供一个独特的标识符。通过ISBN号,你可以在多个来源中确认找到的书籍,这就是去中心化网络的强大之处。

    🔍 深入理解这两种模型

    在去中心化网络中,内容寻址让我们能够从多个来源检索数据,而不必依赖单一的存储位置。这种方式提高了数据的可访问性和灵活性,使得用户能够更自由地获取信息。

    🌐 小结

    总而言之,去中心化网络与中心化网络的最大不同在于如何识别和获取数据。位置寻址依赖于特定的存储位置,而内容寻址则通过内容的唯一标识符使数据的获取变得更加灵活。

    如果你对这些概念还有疑问,ProtoSchool非常乐意听取你的反馈,以不断改进我们的课程。准备好迎接下一课的挑战了吗?让我们继续探索去中心化网络的奇妙世界吧!

    参考文献

    • ProtoSchool. (n.d.). DWeb Tutorial | Content Addressing on the Decentralized Web (Lesson 1). Retrieved from ProtoSchool.
  • 🔒 WP-WebAuthn:密码的终结者

    在这个快节奏的数字时代,密码就像过时的老派舞蹈,虽然我们都在努力坚持,但实际上谁不想换一种更酷、更安全的方式呢?这里,WP-WebAuthn 应运而生,带来了新时代的网络认证技术。让我们一起探索这一令人兴奋的技术,看看它如何颠覆我们对密码的依赖。

    🌐 什么是 WebAuthn?

    WebAuthn 是一个新生的网络认证技术,其目标是通过 USB 认证器、指纹识别、Windows Hello、FaceID/TouchID 等手段,取代传统的密码。想象一下,你不再需要在每次登录时输入复杂的密码,只需轻触一下认证器,几秒钟内便可完成身份验证,真是太神奇了!image.png

    🛡️ 安全性与隐私

    WebAuthn 于2019年3月成为W3C建议,旨在帮助Web应用程序创建和使用基于公钥的强大凭证。它的设计理念是确保安全与隐私并重。通过这种方式,用户的隐私数据根本不需要被传输,简直是网络认证的未来之星!

    📦 WP-WebAuthn 插件

    WP-WebAuthn 是一个极其方便的 WordPress 插件,能让你的网站轻松启用 WebAuthn。这意味着你可以通过简单的安装,体验到最新的网络验证技术。想象一下,用户只需轻松点击一次按钮,就能完成登录,完全不需要输入密码,简直是懒人福音!

    ⚙️ 安装步骤

    1. 确保你的服务器已安装 PHP 扩展 gmp 和 mbstring。
    2. releases 下载插件并上传安装。
    3. 或者在 WordPress 后台搜索安装 WP-WebAuthn

    📜 插件功能

    WP-WebAuthn 插件包含 4 个短代码和 4 个 Gutenberg 区块,用户可以非常方便地在前端页面中插入认证器注册表单等组件。无论是初学者还是开发者,都能轻松上手。

    🎉 许可证与感谢

    WP-WebAuthn 使用 GPL v3.0 许可证开源,任何人都可以自由使用和修改这个插件。在此特别感谢所有的贡献者,正是你们的努力,让这个项目得以成功。

    结语

    在网络安全日益重要的今天,WP-WebAuthn 为我们提供了一种全新的认证方式,摒弃传统密码的麻烦,迎接更安全、更便捷的数字生活。谁说密码是不可或缺的?让我们一起拥抱无密码的未来吧!


    参考文献

    1. WebAuthn 官方文档
    2. W3C WebAuthn 推荐
    3. WP-WebAuthn GitHub 页面

    你还没有登录。

  • OpenVidu:快速集成视频通话的利器

    在当今数字化时代,实时视频通话已经成为许多应用的核心功能之一。无论是远程医疗、在线教育、客户服务,还是虚拟会议,视频通话的需求都在不断增加。今天,我要向大家介绍的是一款强大的开源平台——OpenVidu,它能帮助开发者快速且低成本地将视频通话功能集成到他们的应用中。

    什么是 OpenVidu?

    OpenVidu 是一个旨在简化视频通话集成的开源平台。它提供了一整套技术栈,方便开发者快速将实时通讯功能添加到他们的应用中。无论你是开发网页应用还是移动应用,OpenVidu 都能满足你的需求。

    主要特性

    1. WebRTC 视频会议:支持一对一、一对多以及多对多的各种组合,几乎可以实现你能想到的任何场景。
    2. 开源:OpenVidu 是一个开源项目,使用 Apache License v2 许可证,完全免费。
    3. 多平台兼容:支持 Chrome、Firefox、Safari、Opera、Edge、Android、iOS 以及桌面应用,所有这些平台都能相互兼容。
    4. 易于使用:提供即用型组件,只需简单地粘贴代码即可快速实现视频通话。如果你需要更多的自定义,OpenVidu 的 API 也是非常简单且强大的。
    5. 易于部署:支持在最流行的云服务提供商上进行快速部署,或是通过 Docker 进行本地部署,过程非常简便。

    快速入门

    开始使用 OpenVidu 非常简单。你可以参考 OpenVidu 文档 中的“Getting started”部分,了解如何安装和配置 OpenVidu。以下是一些关键步骤:

    1. 安装 OpenVidu Server:你可以选择在 AWS 上一键部署 OpenVidu,也可以使用 Docker 在本地部署。
    2. 集成前端和后端:OpenVidu 提供了多种前端技术的示例,如 JavaScript、Angular、React、Vue.js 等。后端技术则包括 Java、Node.js 以及 REST API,方便你选择适合的技术栈。

    开发你的视频应用

    OpenVidu 提供了丰富的教程和示例,帮助你快速上手。以下是一些推荐的步骤:

    1. 学习基础知识:文档中提供了“Hello World”示例,帮助你快速了解基本的 API 调用和使用方法。
    2. 探索高级功能:你可以查看“Advanced features”部分,了解如何实现录制视频、屏幕共享、音视频滤镜等高级功能。
    3. 使用现成组件:如果你希望快速实现某些功能,可以使用 OpenVidu 提供的即用型组件,如自定义 UI、自定义工具栏等。

    安全性和隐私保护

    OpenVidu 非常重视用户的隐私和安全。它通过 WebRTC 加密、服务器 API 和客户端基于角色的系统,确保所有通话内容都是完全私密的。此外,OpenVidu 还允许你限制客户端的能力,通过预定义角色来决定用户是否可以订阅、发布或管理视频流。

    适用场景

    OpenVidu 的应用场景非常广泛,包括但不限于以下几种:

    • 客户服务:集成一对一视频通话中心,提供面对面的客户服务。
    • 远程医疗:医生可以通过视频通话直接与患者进行交流,确保私密和安全。
    • 在线教育:教师可以通过视频通话向学生讲解课程,支持多名学生同时在线。
    • 会议服务:支持演讲者实时应用音视频滤镜,提高会议质量。
    • 安防系统:接收来自安防摄像头的视频流,实现监控功能。

    结语

    无论你是想开发一个简单的视频聊天应用,还是一个复杂的视频会议系统,OpenVidu 都能提供强大的支持。它不仅简化了开发过程,还提供了丰富的功能和高水平的安全性,是你开发视频通话应用的不二选择。

    更多详细信息和教程,请访问 OpenVidu 文档


    参考文献:

  • Adobe RTMP 规范:实时消息传递协议详解

    Adobe 的实时消息传递协议(RTMP),是一种应用层协议,旨在通过适当的传输协议(如 TCP)多路复用和打包多媒体传输流(如音频、视频和交互内容)。以下是对 RTMP 规范的详细解析。

    文档概述

    文件状态

    本文档是 2012 年 12 月 21 日发布的 “Adobe 的实时消息传递协议” 规范的机器可读版本。自 2012 年 PDF 版本以来,规范内容并未发生实质性变化,仅在格式和文字编辑上有所调整。

    引言

    RTMP 提供了在可靠的流传输(如 TCP)上的双向消息多路复用服务,旨在携带视频、音频和数据消息的并行流,并附带相关的时间信息。实现通常会为不同类别的消息分配不同的优先级,这会影响在传输容量受限时消息入队到底层流传输的顺序。

    术语

    • MUST: 必须
    • REQUIRED: 必需
    • SHALL: 应该
    • SHOULD: 建议
    • MAY: 可以

    贡献者

    • Rajesh Mallipeddi:原 Adobe Systems 编辑,提供了大部分原始文本。
    • Mohit Srivastava:Adobe Systems 贡献者。

    定义

    • Payload: 包含在数据包中的数据,如音频样本或压缩视频数据。
    • Packet: 由固定头和负载数据组成的数据包。
    • Port: 传输协议用来区分主机内多个目的地的抽象。
    • Transport address: 用于识别传输层端点的网络地址和端口的组合。

    字节顺序、对齐和时间格式

    • 所有整数字段按网络字节顺序(大端序)传输。
    • 时间戳以毫秒为单位,相对于一个未指定的纪元。

    RTMP 块流

    消息格式

    消息格式应包含以下必要字段:

    • Timestamp: 消息的时间戳(4 字节)。
    • Length: 消息负载的长度(3 字节)。
    • Type ID: 消息类型 ID(1 字节)。
    • Message Stream ID: 消息流 ID(4 字节,小端序)。

    握手

    RTMP 连接从握手开始,客户端和服务器各发送相同的三个块(C0、C1、C2 和 S0、S1、S2)。

    块化

    在握手后,连接多路复用一个或多个块流。每个块流携带一种类型的消息。每个块都有唯一的块流 ID。块的传输顺序必须完整发送。接收端根据块流 ID 重新组装消息。

    块格式

    每个块由一个头和数据组成。头有三个部分:

    • Basic Header: 编码块流 ID 和块类型(1-3 字节)。
    • Message Header: 编码关于消息的信息(0、3、7 或 11 字节)。
    • Extended Timestamp: 编码完整的 32 位时间戳(0 或 4 字节)。

    RTMP 消息格式

    消息头

    消息头包含以下字段:

    • Message Type: 消息类型(1 字节)。
    • Length: 负载大小(3 字节)。
    • Timestamp: 消息的时间戳(4 字节)。
    • Message Stream ID: 消息流 ID(3 字节)。

    用户控制消息

    RTMP 使用消息类型 ID 4 进行用户控制消息。这些消息包含 RTMP 流层使用的信息。

    RTMP 消息类型

    命令消息

    携带客户端和服务器之间的 AMF 编码命令。命令消息有两个类型值:20 表示 AMF0 编码,17 表示 AMF3 编码。

    数据消息

    用于发送元数据或用户数据。类型值为 18(AMF0)和 15(AMF3)。

    共享对象消息

    用于管理多个客户端和服务器之间的分布式数据。类型值为 19(AMF0)和 16(AMF3)。

    音频消息

    用于发送音频数据,类型值为 8。

    视频消息

    用于发送视频数据,类型值为 9。

    聚合消息

    包含一系列RTMP 子消息的单一消息。类型值为 22。

    消息交换示例

    发布录制视频

    此示例说明发布者如何发布流并将视频流发送到服务器。其他客户端可以订阅此发布的流并播放视频。

    +--------------------+                     +-----------+
    |  Publisher Client  |        |            |   Server  |
    +----------+---------+        |            +-----+-----+
              |           Handshaking Done           |
              |                  |                  |
              |                  |                  |
    ---+---- |----- Command Message(connect) ----->|
       |     |                                     |
       |     |<----- Window Acknowledge Size ------|
    Connect |     |                                     |
       |     |<------ Set Peer BandWidth ----------|
       |     |                                     |
       |     |------ Window Acknowledge Size ----->|
       |     |                                     |
       |     |<----- User Control(StreamBegin) ----|
       |     |                                     |
    ---+---- |<-------- Command Message -----------|
              |   (_result- connect response)       |
              |                                     |
    ---+---- |--- Command Message(createStream) -->|
    Create |     |                                     |
    Stream |     |                                     |
    ---+---- |<------- Command Message ------------|
              | (_result- createStream response)    |
              |                                     |
    ---+---- |---- Command Message(publish) ------>|
       |     |                                     |
       |     |<----- User Control(StreamBegin) ----|
       |     |                                     |
       |     |---- Data Message (Metadata) ------->|
    Publishing|     |                                     |
    Content   |     |------------ Audio Data ------------>|
       |     |                                     |
       |     |------------ SetChunkSize ---------->|
       |     |                                     |
       |     |<--------- Command Message ----------|
       |     |      (_result- publish result)      |
       |     |                                     |
       |     |------------- Video Data ----------->|
       |     |                  |                  |
       |     |                  |                  |
              |    Until the stream is complete     |
              |                  |                  |

    广播共享对象消息

    此示例说明在创建和更改共享对象期间交换的消息。它还说明了共享对象消息广播的过程。

    +----------+                       +----------+
    |  Client  |           |           |  Server  |
    +-----+----+           |           +-----+----+
           |   Handshaking and Application    |
           |          connect done            |
           |                |                 |
           |                |                 |
           |                |                 |
           |                |                 |
    Create and ---+---- |---- Shared Object Event(Use)---->|
    connect       |     |                                  |
    Shared Object |     |                                  |
    ---+---- |<---- Shared Object Event --------|
           |       (UseSuccess,Clear)         |
           |                                  |
    ---+---- |------ Shared Object Event ------>|
    Shared object |     |         (RequestChange)          |
    Set Property  |     |                                  |
    ---+---- |<------ Shared Object Event ------|
           |            (Success)             |
           |                                  |
    ---+---- |------- Shared Object Event ----->|
    Shared object|     |           (SendMessage)          |
    Message      |     |                                  |
    Broadcast ---+---- |<------- Shared Object Event -----|
           |           (SendMessage)          |
                              |                 |
                              |                 |

    从录制流发布元数据

    此示例描述了发布元数据的消息交换。

    +------------------+                       +---------+
    | Publisher Client |         |             |   FMS   |
    +---------+--------+         |             +----+----+
           |     Handshaking and Application     |
           |            connect done             |
           |                  |                  |
           |                  |                  |
    ---+--- |-- Command Messsage (createStream) ->|
    Create |    |                                     |
    Stream |    |                                     |
    ---+--- |<-------- Command Message -----------|
           |   (_result - command response)      |
           |                                     |
    ---+--- |---- Command Message (publish) ----->|
    Publishing |    |                                     |
    metadata |    |<----- UserControl (StreamBegin) ----|
    from file |    |                                     |
              |    |---- Data Message (Metadata) ------->|
           |                                     |

    参考文献

    • RFC0791: Postel, J. , “Internet Protocol”, STD 5, RFC 791, September 1981.
    • RFC0793: Postel, J. , “Transmission Control Protocol”, STD 7, RFC 793, September 1981.
    • RFC1982: Elz, R. and R. Bush, “Serial Number Arithmetic”, RFC 1982, August 199
  • RTMP协议(Real-Time Messaging Protocol)

    RTMP协议(Real-Time Messaging Protocol)是一种用于在互联网上流式传输音频、视频和数据的通信协议[1]。最初由Macromedia开发为Flash Player和Flash Communication Server之间的流媒体传输的专有协议,后来被Adobe(收购了Macromedia)发布了该协议的不完整版本供公众使用[1]

    RTMP协议有多个变种:

    • RTMP:在Transmission Control Protocol(TCP)之上工作的“纯”协议,默认使用1935端口号。
    • RTMPS:在Transport Layer Security(TLS/SSL)连接上的RTMP。
    • RTMPE:使用Adobe自己的安全机制对RTMP进行加密。虽然实现的细节是专有的,但该机制使用行业标准的加密原语[1]
    • RTMPT:封装在HTTP请求中以穿越防火墙。RTMPT通常使用TCP端口80和443上的明文请求来绕过大多数企业流量过滤。封装的会话可以在内部携带纯RTMP、RTMPS或RTMPE数据包[1]
    • RTMFP:在User Datagram Protocol(UDP)上的RTMP,取代了RTMP Chunk Stream。Secure Real-Time Media Flow Protocol套件由Adobe Systems开发,使终端用户能够直接连接和通信(P2P. [1]

    RTMP的基本操作是基于TCP的,它维持持久连接并允许低延迟通信。为了平稳地传输流并尽可能多地传输信息,它将流分割成片段,并且片段的大小在客户端和服务器之间动态协商。有时,片段的大小保持不变;音频数据的默认片段大小为64字节,视频数据和大多数其他数据类型的默认片段大小为128字节。来自不同流的片段可以交错和多路复用到单个连接上。由于较长的数据块,该协议每个片段仅携带一个字节的头部,因此开销非常小。然而,在实践中,通常不会交错单个片段。相反,交错和多路复用是在数据包级别上完成的,以确保每个通道满足其带宽、延迟和其他服务质量要求。以这种方式交错的数据包被视为不可分割的,不会在片段级别上交错[1]

    RTMP定义了几个虚拟通道,可以在这些通道上发送和接收数据包,并且这些通道彼此独立运行。例如,有一个用于处理RPC请求和响应的通道,一个用于视频流数据的通道,一个用于音频流数据的通道,一个用于带外控制消息(片段大小协商等)的通道等。在典型的RTMP会话期间,多个通道可能同时处于活动状态。当对RTMP数据进行编码时,会生成一个数据包头部。数据包头部指定了要发送的通道的ID、生成时间戳(如果需要)以及数据包有效载荷的大小。然后,在将其发送到连接上之前,将其实际有效载荷内容(媒体数据)根据当前协商的片段大小进行分段。数据包头部本身永远不会被分段,其大小不计入数据包的第一个片段中的数据。换句话说,只有实际的数据包有效载荷(媒体数据)会被分段[1]

    在更高的层次上,RTMP封装了MP3或AAC音频和FLV1视频多媒体流,并可以使用Action Message Format进行远程过程调用(RPC)。所需的任何RPC服务都是异步进行的,使用单个客户端/服务器请求/响应模型,因此不需要实时通信[2]

    RTMP会话可以使用以下两种方法进行加密:

    • 使用行业标准的TLS/SSL机制。底层的RTMP会话只是包装在正常的TLS/SSL会话中。
    • 使用RTMPE,在RTMP会话中包装一个轻量级的加密层。

    在RTMP Tunneled(RTMPT)中,RTMP数据通过HTTP进行封装和交换,客户端(媒体播放器)的消息被发送到服务器上的80端口(HTTP的默认端口)[1]。RTMPT中的消息由于HTTP头部的原因比等效的非隧道化RTMP消息要大,但在客户端位于阻止非HTTP和非HTTPS出站流量的防火墙后,RTMPT可能有助于使用RTMP的场景,否则将无法使用非隧道化的RTMP。

    RTMP协议的数据包结构如下:

    • 数据包通过TCP连接发送,首先在客户端和服务器之间建立连接。
    • 数据包包含一个头部和一个主体,在连接和控制命令的情况下,主体使用Action Message Format(AMF)进行编码。
    • 头部分为基本头部(从图表中分离出来)和块消息头部。基本头部是数据包的唯一固定部分,通常由一个复合字节组成,其中最高的两个有效位是块类型(在规范中称为fmt),其余部分形成流ID。根据前者的值,可以省略消息头部的某些字段,并且可以从先前的数据包中派生它们的值,而根据后者的值,基本头部可以扩展为一个或两个额外的字节。如果基本头部的剩余六个位(最低有效位)的值为0,则基本头部为两个字节,表示从流ID 64到319(64+255);如果值为1,则基本头部为三个字节(最后两个字节编码为16位小端),表示从流ID 64到65599(64+65535);如果值为2,则基本头部为一个字节,保留用于低级协议控制消息和命令。块消息头部包含元数据信息,例如消息大小(以字节为单位)、时间戳增量和消息类型。最后一个值是一个字节,定义数据包是音频、视频、命令还是“低级”RTMP数据包,例如RTMP Ping[1]

    Learn more:

    1. Real-Time Messaging Protocol – Wikipedia
    2. RTMP协议深度
  • 实时消息协议 – 维基百科,自由的百科全书
人生梦想 - 关注前沿的计算机技术 acejoy.com