新一代通信协议

一、简介

Socket.D 是一种二进制字节流传输协议，位于 OSI 模型中的5~6层，底层可以依赖 TCP、UDP、KCP、WebSocket 等传输层协议。由 Noear 开发。支持异步流处理。其开发背后的动机是用开销更少的协议取代超文本传输协议(HTTP)，HTTP 协议对于许多任务(如微服务通信)来说效率低下。

二、设计目标

协议接口丰富，包括 Send, SendAsRequest, SendAndSubscribe，Reply，ReplyEnd
支持应用层流量控制
支持单连接双向、多次复用
支持断连后自动重连
可以更好的使用 WebSocket 协议

三、消息驱动

网络通信是异步的，Socket.D 协议包含这一点，并将所有通信建模为在单个网络连接（TCP）上的、多路复用的消息流，在等待响应时从不同步阻塞。

响应式宣言指出：

反应式系统依赖异步的消息传递，从而确保了松耦合、隔离、位置透明的组件之间有着明确边界。 这一边界还提供了将失败作为消息委托出去的手段。 使用显式的消息传递，可以通过在系统中塑造并监视消息流队列， 并在必要时应用回压， 从而实现负载管理、 弹性以及流量控制。 使用位置透明的消息传递作为通信的手段， 使得跨集群或者在单个主机中使用相同的结构成分和语义来管理失败成为了可能。 非阻塞的通信使得接收者可以只在活动时才消耗资源， 从而减少系统开销。

此外，HTTP/2 FAQ 很好地解释了在持久连接上采用多路复用的面向消息的协议的动机：

HTTP/1.x 有一个叫做 “head-of-line blocking（队头阻塞）” 的问题，在这种情况下，即在一个连接上一次只能有一个未完成请求。
HTTP/1.1 试图通过流水线（Pipelining）来解决这个问题，但它并没有完全解决这个问题(大的或慢的响应仍然会阻塞后面的其他响应)。此外，人们发现流水线很难部署，因为许多代理和服务器不能正确地处理它。

在HTTP/1中使用并发连接和域名分片来缓解HOL问题
并发连接，浏览器针对每个源（域名）可以打开4-8个TCP连接，提升并发度。
域名分片，浏览器和HTTP/1限制了并发连接的数量，那么就把多个域名指向一台服务器，从而提升连接数量。

这迫使客户端使用一些启发式方法（通常是猜测）来确定什么请求在什么时候放在与源站的哪个连接上；由于加载一个页面的次数通常是可用连接数量的10倍或者更多。这会导致被阻塞的请求“瀑布式”的增长，从而严重的影响性能。

多路复用通过允许多个请求和响应消息在一个连接上同时传输来解决这些问题；甚至可以将一条消息的部分与另一条消息的部分混合在一起。

使用HTTP/1，浏览器为每个源打开4-8个连接，由于许多站点使用多个源，这可能意味着打开单个页面要加载30多个TCP连接。

一个应用程序同时打开如此多的连接，打破了TCP所建立的许多假设；由于每个连接都会在响应中传输大量的数据，因此TCP缓冲区很大可能会溢出，从而导致拥塞事件和超时重传。

一个应用程序同时打开如此多的连接，此外，使用如此多的连接不公平地垄断了网络资源，“窃取”了其他性能更好的应用程序（如VoIP）的资源。

四、协议交互模型

不合适的协议会增加系统开发的成本。它可能是一个不匹配的抽象，但是我们必须将系统设计强加到他允许的交互模型中。这迫使开发人员花费额外的时间来解决它的缺点，以处理错误并获得可接受的性能。在多语言环境中，这个问题被放大了，因为不同的语言将使用不同的方法来解决这个问题，这需要团队之间的额外协调。到目前为止，通信协议事实上的标准是HTTP，它只支持请求/响应的交互模式。在某些情况下，这可能不是最理想通信模型。

Send（只管发送，不要结果）

发完就不管是请求/响应的优化，在不需要响应时很有用。它允许显着的性能优化，不仅仅是通过跳过响应来节省网络使用，而且还可以减少客户端和服务器的处理时间，因为客户端不需要记录和等待请求关联的响应和取消请求。

此交互模型对于支持有损的用例非常有用，例如非关键事件日志记录、或者设备信息上报。

像这样使用：

clientSession.send("/demo", entity);

SendAsRquest（发送一个请求，并要求一个响应）

仍然支持标准请求/响应语义，并且仍有望代表 Socket.D 连接上的大多数请求。这些请求/响应交互可以被认为是优化的“只有 1 个响应的流”，并且是在单个连接上多路复用的异步消息。

消费者“等待”响应消息，所以它看起来像一个典型的请求/响应，但它从不同步阻塞。

就像 http 一样使用：

//同步等待

let response = clientSession.sendAndRequest("/demo", entity).await();

//异步回调

clientSession.sendAndRequest("/demo", entity).thenReply(response => {

});

SendAndSubscribe（发送一个订阅，可以接收多个答复）

从一个请求一个响应那儿延伸出来的是多个响应，它允许多条消息流回。将此视为“集合”或“列表”响应，但不是将所有数据作为单个响应返回，而是按顺序流回每个元素。

用例可能包括以下内容：获取视频列表，在目录中获取产品，逐行检索文件。

可能有点像 mq，还可能通过 range 指定数据区间（或者不指定）：

//异步回调

clientSession.sendAndSubscribe("/demo", entity.range(0,5)).thenReply(reply => {

      if(reply.isEnd()){

          //如果需要识别最后一个？

      }else{

          //

      }

});

五、协议形式

连接上传输的数据可称之为流，每个消息都会有一个 sid（流Id）
流（Stream）由帧（Frame）组成
帧（Frame）包含了流Id（Sid）、事件（Event）、元数据字符串（MetaString）及数据（Data）

帧码结构为：

[len:int][flag:int][sid:str(<64)][\n][event:str(<512)][\n][metaString:str(<4k)][\n][data:byte(<16m)]

Socket.D 是一个二进制协议，也就是说在一个 Socket.D 连接上传输的消息体对数据格式没有任何要求，应用程序可以为所欲为的压缩数据量的大小。

这样的二进制协议通常来说能给性能带来极大的提升，但是产生的代价是，网络中间件也会因为无法解读消息体中的数据，丧失了在对具体应用流量进行监控，日志和路由的能力。Socket.D 通过把每个消息体分成 metaString 和 data 的方式，在保证高效传输的前提下，提供了暴露少量元数据给网络中间件的能力。

data 一般作为应用本身需要传递的业务数据，采取自定义的高效序列化方式，且对网络基础设施不可见。
metaString 采用标准的 urlQueryString 格式。在分布式传输的过程中，这些中间件可以按需求对 metaString 进行读写，然后监控应用健康状况或者调整路由。

Socket.D 有哪些适用的场景？

移动设备与服务器的连接
数据双向传输，且支持流量控制。
支持连接修复，比如手机进地铁之后，网络断开一段时间，其他协议需要重新建立连接，Socket.D 会自动修复连接。
微服务场景