ThingsKit文档——设备接入——设备TCP接入

入门介绍 ¶

**TCP协议全称是传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。**有三次握手可以保证数据传输的可靠性。TCP提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。

TCP是由TCP头部和TCP数据两个部分组成。头部是由上图标识的一些字段组成，对上图字段的分析如下：

Source port（源端口）：源主机应用程序所使用的端口号;
Destination port（目的端口）：目的主机使用的端口号;
Sequence Number(序列号)：用于标识从发送端发出的不同的TCP数据段的序号。数据段在传输过程中他们的顺序会发生变化，因此接收端需要根据序列号来对数据进行重组。
Acknowledge Number（确认序列号）：用于标识接收端确认收到的数据段。确认序列号为成功收到的数据序列号+1。
Header length（头部长度）:标识头部占32bit字的数目，他能表达的TCP头部最大长度为60字节。
Window（窗口大小）：表示接收端期望通过单次确认而收到的数据大小。该机制通常用于流量的控制。
Checksum（校验和）：校验整个TCP字段，包括TCP头部和TCP数据。该值由发送端计算和记录并由接收端进行验证。

接下来来看TCP与UDP的区别：

TCP	UDP
面向连接（即需要建立连接）	面向无连接
面向字节流（发送数据时会将数据分解为多个小的数据报文进行发送）	基于数据报（发送数据时会直接打上UDP头部将整个报文发送出去）
有三次握手可以保证数据传输的可靠性	传输数据可能存在丢包
保证数据顺序	无法保证数据顺序
只支持点对点通讯	支持一对一、一对多、多对多通讯
有拥塞机制	无拥塞机制
头部20-60个字节	头部8个字节
要求实时性低，准确度高	要求实时性高，准确度低

提示

Thingskit支持设备直接通过 TCP 接入平台，并支持 JSON、Text、HEX 格式的上下行消息，平台中还提供了脚本函数功能，为更复杂的设备通信提供了便利性。

注册包对平台而言则是访问令牌《AccessToken》。

只要保证设备端的注册包与平台端的访问令牌一致。

注册包是作为设备端与平台鉴权的方式，如果常见的DTU厂家，都有提供配置软件来设置。

当设备和平台成功建立 TCP 连接后，设备必须马上向平台发送身份信息，完成身份认证。若设备端在一定时间内未发送身份信息，平台会自动断开设备的 TCP 连接。

在使用 TCP 透传方式的网关或 DTU 中，同样可以使用该注册包连接到平台。

塔石的DTU注册包设置如下：

银耳达的DTU注册包设置如下：

当设备和平台建立 TCP 连接并完成身份认证后，便可以相互收发消息。但是，如果相当长一段时间内没有消息通信，双方如何判断对方仍然在线呢？因为 TCP 对于一些非正常的连接断开是无法侦测到的，比如设备断电、网线断掉等。

因此，对于消息通信间隔较长的应用场景，为了让双方尽早的知道连接是否已经断开，从而实现重连，就需要有 TCP 保活机制，这是通过设备定期发送心跳包来实现的。

然后，大多数物联网通信场景的数据上报间隔时间并不长，所以也可以起到保活的目的，心跳包不是必须的。

平台提供的 TCP 接入方式，是需要您对 TCP 通道所属的自定义数据流，设置相应的消息规则，实现自定义数据和设备属性之间的解析和处理。

数据上报到平台，则需要通过平台提供的转换函数进行，转码解析处理。

如某厂家的风速传感器，上报到平台的数据为：

0103040150008D3BBB

平台端，则通过转换函数；

var demo = parseInt('0x'+params.substr(6, 4));
if ((demo & 0x8000) > 0) {
  demo = demo - 0x10000;
}
out.speed = (demo*0.1).toFixed(2);

1
2
3
4
5

解析结果为：

{"speed":"33.60"}

设备接入时，咱们得先创建TCP协议的产品，产品创建时，需要绑定对应的转换脚本。

一旦完成上边的 TCP 绑定自定义数据流，设备端就可以通过 TCP socket 发送符合负载格式的数据，例如：类似属性消息结构的 JSON 消息，或者自定义的 HEX 消息。

平台收到 TCP 自定义数据上报后，则通过规则引擎来对数据做各种解析和处理，平台提供了函数等可编程方式。

接下来就是平台下发命令到设备端自定义数据，可以通过如下方式：

设备详情中的命令下发见下图：

规则引擎的命令下发如下图：