Carlife Iphone IAP2连接与认证过程

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最终的外观有一个相当好的认识。

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之上运行。确切的外观还没有最终确定，但是我们正在实现。