iap1 iap2协议区别_IAP：HTTP的快速，多功能替代品

iap1 iap2协议区别

如果我们能够保留当今行业的累积知识，而又从新技术开始，而不受传统技术和协议的束缚，那么现代云平台将如何发展？ 如果该云平台能够支持下一代互联网-万物互联（IoE），该怎么办？

在Jenkov Aps和Worpcloud Ltd.，这些正是促使我们去年年初与我们的新云项目VStack.co合作的问题。 在整个2015年，我们分析了现代应用程序堆栈的大部分，从高层架构方面到具体技术，例如数据库，查询语言，消息队列，备份解决方案，分布式计算模型，甚至是网络协议。

分析和概念验证的实施工作是一项持续不断的工作，但是在这一点上，我们可以看到，最终的技术堆栈看起来将与现有的云平台大不相同。 实际上，我们发现可以用更好的替代方法替代当今的几种互联网技术。

因为该平台尚未完全实施，所以说该项目的结果是否能够达到我们的期望还为时过早。 随着了解的更多，我们自然不得不多次更改设计，但是，现在这些设计已经足够稳定，可以开始与开发人员社区进行讨论了。

我们无法在一篇文章中描述整个体系结构，也无法对其进行讨论，因为部分仅在内部可见。 因此，本文仅关注体系结构的一个中心方面，IAP，即我们建议的HTTP替代品。

IAP-互联网应用协议

Internet应用协议（IAP）旨在成为Web 3.0的通用网络协议。 我们认为，在适当的Internet应用程序协议上进行标准化可能会对USB对PC和外围硬件所具有的应用程序和设备产生类似的影响，与Internet连接的应用程序和设备只需将它们连接到Internet即可进行交互。

IAP尚未完全指定，但是我们非常了解IAP的核心应该如何工作。 IAP规范的最新版本在此处提供 。

IAP解决了HTTP 1.1忽略的许多用例。 尽管HTTP2和WebSockets确实解决了HTTP 1.1不能解决的几个问题，但是我们认为仍然需要做更多的事情，正如我们在博客中所描述的： 为什么HTTP2和Websockets不够用 。

IAP是基于自由流消息的协议。 通信节点交换消息，就像HTTP请求和响应一样。 但是，IAP不需要每个消息都具有响应。 作为自由流协议，IAP仅指定节点交换消息。 消息可以在网络连接的两个方向上自由流动，因为通信节点认为适合进行通信。 在我们的教程IAP消息流中，我们已经详细描述了一些核心消息流 。

为了使IAP逐步完成，我们认为是时候向社区介绍有关替换HTTP的讨论，并提出建议的解决方案了。 实际上，本文将主要关注ION，即IAP中使用的二进制对象表示法。 我们选择此重点的原因有以下三个：

首先，ION规范比整个IAP规范更接近稳定。 因此，从ION开始讨论更加有意义。

其次，ION可以独立于IAP使用，这意味着您可以将ION与HTTP一起使用，以作为所有非浏览器通信的更紧凑，性能更好的替代HTTP / JSON的方法。 示例包括用例，例如与后端通信的移动应用程序，或后端到后端的通信。

最后，ION对IAP的用途有影响。 因此，即使在完成IAP规范之前，了解ION和基本的IAP消息结构也将使您对IAP最终的外观有一个相当好的认识。

ION简介

正如我们提到的，IAP是基于消息的网络协议。 所有IAP消息均以称为ION的二进制格式编码； IAP对象表示法的简称。 与XML和JSON之类的文本数据格式相比，二进制表示形式的消息导致更紧凑的消息和更高的解析速度。

ION是TLV（类型长度值）格式。 每个ION字段按该顺序包含其类型，长度和值。 我们在这里有ION编码的更详细规范。

ION的编码类似于二进制表示格式CBOR和MessagePack的编码，但是ION在一些关键方面偏离了这些格式。 首先，CBOR和MessagePack最初都被设计为JSON的二进制表示形式，并具有携带原始二进制数据（例如文件）的附加功能。

ION被设计为通用数据格式，旨在对以下常见数据结构进行建模：

• 原始字节 （文件）
• 原始二进制值 （布尔值，整数，浮点数，UTF-8字符串，UTC日期时间）。
• 独立价值流 （无限）
• 独立值数组 （有界）
• 映射 （键，值对）
• 对象
• 具有循环引用的对象图
• 桌子

这些结构可以相互嵌套。 因此，例如，您可以通过在表内嵌套表来对紧凑的对象图进行建模。 这些基本数据结构可以为JSON，XML，CSV或原始二进制数据建模，并且您实际上可以将JSON，XML或CSV转换为ION并再次转换。

桌子

ION和MessagePack / CBOR之间最大的区别是表格数据的紧凑表示。 一些示例包括：

• 相同类型的对象数组
• 数据库表
• CSV文件。

能够紧凑地表示表格数据可以在性能，带宽和内存使用方面带来巨大的好处。 我们的测量结果表明，ION表的数据大小通常比序列化为JSON对象数组的相同数据小50-80％。 同样，ION表通常比相应的MessagePack或CBOR编码数据小25-50％。 许多服务都通过网络发送和接收结果列表，因此在这种常见的用例中，压缩会严重影响性能。

ION表的读写速度比Jackson / CBOR的相应读写速度快2.75倍，比Jackson / JSON的相应读写速度快5倍。

灵活的对象

ION与JSON，MessagePack和CBOR的另一个不同之处在于，ION对象可以包含应用程序认为合适的任意ION字段序列。 ION对象（如JSON）可以包含属性名称值对，但也可以包含其他字段的混合序列。 例如，一个ION对象可能包含一系列UTF-8字段和ION对象字段，以模拟与XML元素混合的XML文本节点。

ION对象只能限制为属性值。 这导致单个对象的表示非常紧凑，并且可以实现与Google协议缓冲区匹配的读写速度（更快的写入，更慢的读取），但是具有无模式的优点，而无需将数据大小归因于Protobufs（Protobuf承认对于诸如文件之类的原始字节，它不是一种很好的编码。）

使用仅包含属性值的ION对象需要您了解对象内部字段的顺序。 对于公共API来说，这可能不是一个好主意，但对于紧密耦合且需要高性能的内部服务，使用此选项很有用。

任意层次导航

前面提到的基准测试测量了将ION读取到Java对象中以及将Java对象写入ION的速度。 但是，为了获得最大速度，建议不要直接将ION解析为二进制形式的数据，而应将ION解析为Java对象。 ION在设计时就考虑了这种使用模型。

所有ION字段都包含字段值的长度（以字节为单位）。 首先，知道ION字段的字节长度使从二进制数据中提取值变得更加容易和快捷。 您无需检查（解析）该值的每个字节来查看它的结尾，就像使用JSON和XML这样的文本格式一样。 其次，了解字段值的字节长度使跳过您可能不想处理的任何字段变得更加容易和快捷。

可以包含其他ION字段（例如Object，Table或Array）的任何ION字段也包含其值的字节长度。 这使得跳过对象图的整个“分支”变得更加轻松快捷，而不必解析其中的字段。 这就是我们所说的“任意层次导航”：您可以快速，轻松地导航进出类似图形的数据结构。

任意分层导航是ION相对于MessagePack和CBOR有了显着改进的领域之一，仅在编码方面有细微差别。 在MessagePack中，可以包含嵌套元素的元素列出了包含元素内的元素数-而不是字节数。 因此，要跳过MessagePack或CBOR中具有嵌套元素的元素，您需要遍历所有嵌套元素以查找包含元素的结尾。

我们创建了一个简单的读取和使用基准，以显示ION数据在使用之前解析为对象与直接以其二进制形式使用ION数据之间的速度差异。 该基准读取一个包含10个对象的表，每个对象具有一个long类型的属性，并计算总和。

基准的第一个版本在将long属性汇总之前，将ION数据（通过我们的Java反射API）读取到Java对象图中。 基准测试的第二个版本直接从原始ION数据中汇总了长属性。

直接从原始ION数据中汇总长属性的速度大约比使用基于反射的API首先将其解析为Java对象快10倍。 这比使用Google协议缓冲区（还将Protobuf消息解析为Java对象）快大约三倍，并且比将JSON解析为Java对象并使用对象（使用基于Jackson的基于反射的API）快大约15至40倍。

此外，基准测试使用了所有ION数据图。 如果计算仅使用对象图的一部分，则在首先将二进制数据解析为对象与直接使用二进制数据之间的性能改进可能会更加显着。

ION作为文件格式

ION被设计为网络消息的数据格式，但也可以用作文件格式。 在VStack.co，我们将ION用作数据文件和日志文件。 单一数据格式使我们更轻松地处理数据。 可以将网络消息写入磁盘以供以后分析或稍后重放，并且文件中的数据可以轻松地包含在网络消息中。

有关ION与其他数据格式的更多信息

在性能基准测试文本中 ，我们有ION的序列化长度和读/写性能的更多详细信息。

在文本“ ION vs. Other Formats ”中，我们还有关于ION与其他数据格式比较的更多详细信息。

IAP消息结构

IAP消息被编码为单个ION对象字段。 通过IAP通信的两个节点交换ION对象字段。 ION对象字段在其中包含嵌套的ION字段。 嵌套字段构成了邮件头和邮件正文。

因为IAP消息是ION对象字段，所以接收IAP消息的服务器最多知道消息的前16个字节（通常是前4到5个字节）内的完整消息的长度。 这使服务器很容易为小消息分配正确的内存量，从而使服务器可以接收大量小消息，从而更好地利用其内存。

每个IAP消息都是单个ION对象字段，这也使得跟踪接收到完整消息的时间变得容易。 一旦收到ION对象字段声明的字节数，便知道已收到完整消息。

我们当前的IAP服务器实现可以通过一个单线程服务器运行在一个内核上，而四个连接的客户端与IAP服务器运行在同一台物理服务器上，每秒回显（ping-pong）消息大约200K（36字节）。 该服务器是一种商用硬件盒，四核CPU，Haswell架构，DDR3 RAM。 客户端发送一条消息，服务器发送回同一条消息。 当客户端从服务器接收到回显时，它将发送下一条消息，服务器将回显等等。

随着客户端对消息进行流水线处理，并且服务器在所有四个内核上而不是一个内核上运行，我们应该能够每秒处理一百万条消息。

由于ION对象字段紧凑且易于解析，因此ION也非常适合CPU和内存资源有限的小型设备。 这使IAP不仅适合作为典型Web应用程序和后端服务的协议，而且还适合物联网。

IAP语义协议

如果不是不可能的话，尝试定义一个单一的网络协议来服务所有当前和将来的用例是困难的。 IAP并非尝试这样做，而是设计为由多个可以结合使用的较小协议组成。 这些协议分为一组核心协议和一组语义协议。

核心协议指定了诸如确认收到的消息，缓存等通用功能。 此功能在广泛的网络协议中很有用，可提供跨协议功能。

语义协议解决了诸如文件交换，流传输，聊天，VoIP等具体用例。IAP将定义一组标准语义协议，但也为您定义自己的自定义语义协议提供了灵活性。

所有核心和语义协议都将使用相同的基本消息结构。 许多语义协议还将使用类似的通信模式。 这意味着应该有可能实现一个面向消息的服务器平台，该服务器平台可用于服务大多数（如果不是全部）核心和语义协议。

核心IAP协议和语义协议尚未最终确定，但是已经做出了重大的设计决策，我们将在稳定核心和语义协议的同时宣布它们。

IAP传输协议

由于一种消息交换模式或一种协议不能满足所有用例，因此一种基础传输协议也不能适合所有情况。 因此，IAP被设计为能够在TCP或UDP之上运行。 确切的外观还没有最终确定，但是我们正在实现。

对IAP的常见React

这不是我们第一次与开发人员讨论IAP。 在以下各节中，我们将收到一些回应和回应。

二进制协议很难调试

那是真实的。 但是，首先，大多数数据库使用专有的二进制协议在数据库服务器和客户端API之间传输数据，而且我们还没有听到很多对此的抱怨。

其次，ION可以转换为XML，然后再转换回XML，而不会丢失数据。 这意味着您可以将ION消息转换为XML，并在文本编辑器中查看它们。 甚至可以编辑XML文件并将其转换回ION，以用于单元测试，调试等。ION和XML之间的转换尚未实现，但我们希望在第一季度的某个时候得到解决。

ZIP压缩数据时，紧凑性无关紧要。

反对紧凑数据的一个常见论点是，您只能在线路上使用ZIP压缩。 但是，由于存在CRIME和BREACH攻击，当前建议不要对加密连接（TLS / SSL）使用数据压缩。 从这个角度来看，ION的紧凑表编码可以发挥重大作用。

即使所有这些JSON字节在网络上都经过ZIP压缩，仍然需要对其进行解压缩和解析，这需要占用CPU时间。 ZIP压缩可以减少在线传输时间，但是会增加解析时间。 即使增加很小，也仍然没有必要。

IAP和ION不成熟/生产就绪

的确，IAP和ION没有像HTTP或JSON那样得到广泛使用或证明。 尽管如此，我们还是决定基于IAP而非HTTP建立平台。 所有进出核心VStack.co平台的数据都将通过IAP进行。 如果IAP / ION有问题，我们将是第一个知道的人。

一种尺寸不适合所有人

否-这就是为什么我们将IAP设计为具有可扩展为适合不同语义协议的非常简单的核心消息结构。

您是否看过/比较XYZ格式？

我们已经听到很多这个问题了。 我们已将ION与JSON，MessagePack，CBOR和Protobuf进行了比较。 此外，我们还研究了Cap'n Proto，Avro和Thrift。 编码没有太大不同，因此速度应该是可比的，并且比格式更依赖于实现。

但是，我们做出的使ION与Protobuf和Cap'n Proto不同的一个主要决定是ION应该自我描述，这意味着您可以从ION文件中获得意义而无需单独的模式。 这对于使ION消息可被不知道消息架构的中间节点路由成为必要。

自我描述使ION消息稍大且解析速度稍慢，但使ION易于使用。 您可以在不知道日志消息写入的确切格式的情况下理解数据和日志文件。您不必担心会丢失架构，也不必担心将架构存储在文件的开头。避免丢失它。 您甚至可以将ION消息转换为文本格式，然后在不知道其模式的情况下再次返回。

此外，如果您需要进一步提高传输速度，则可以忽略很多ION的元数据，因此您的消息的大小接近于需要模式的数据格式（例如Protobuf）。 即使这样，您仍然可以对ION消息中的数据有所了解，因为每个字段仍在二进制数据中进行了显式标记。

IAP工具

我们有一个用于IAP和ION的开源API，称为IAP工具。 当前，我们只有Java实现，但我们也希望为D和C＃开发IAP API。 如果这些方法成功，我们也可以考虑移植到其他语言。

您可以在此处找到用于Java的IAP工具。

该代码尚未投入生产，但足以与ION一起使用并为您的系统进行简单的概念验证实现。 我们预计代码的ION相关部分将在第一季度成熟。 与IAP相关的部分将花费更长的时间。

另一个考虑支持ION的工具包是QBit （由Rick Hightower领导），这是一种高速微服务工具包。 QBit服务通过消息在内部进行通信。 如今，QBit服务通常使用JSON作为消息格式。 使用ION代替JSON将提供更小的消息，更高的读/写速度和更大的数据结构选择灵活性。

我们希望您的反馈意见

我们非常想听听您对新网络协议的看法。 我们已经听到许多开发人员抱怨HTTP。 请让我们知道为什么，这样我们才能确保IAP解决了您的问题。

一个新的网络协议将意味着将需要编写许多新软件，但同时也将带来许多新的可能性-尤其是如果我们可以使用比HTTP更通用的网络协议。

翻译自: https://www.infoq.com/articles/IAP-Fast-HTTP-Alternative/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

iap1 iap2协议区别