@TOCTCP连接的建立-三次握手第一步客户端TCP向服务器TCP发送一个不含应用层数据的特殊TCP报文该报文首部的一个标志位(SYN)被置为1,因此该报文被称为SYN报文段客户随机选择一个初始序号置于该报文段的序号字段中报文段封装进一个IP数据报中,发送给服务器第二步服务器TCP接收到客户发来的SYN报文后,为该TCP分配TCP缓存和变量,并向客户发送允许连接的报文(确认报文)该允许报文SYN标志置为1该允许报文确认号置为客户的初始序号+1该允许报文携带了服务器自己选择的初始序号该确认报文也被称为SYNACK 报文段 (SYNACK segment)第三步客户收到服务器的SYNACK报文后，给该TCP分配缓存以及变量，并向服务器发送该SYNACK的确认报文确认报文确认号为服务器选择的初始序号因为已建立连接，所以标志SYN置为0这段报文可以携带应用层数据三次握手的原因确保双方都已经准备就绪了TCP连接的拆除-四次挥手概述在连接结束后，主机中的资源(缓存和变量)都将被释放客户首先发送一个特殊报文,该报文标志FIN置为1服务接收到FIN报文后,就像发送方回送一个确认报文服务器继续发送自己的数据服务器向客户发送自己的FIN报文(在这里FIN报文还是遵循超时间隔的规则的!,所以可能会多次发送)客户接收后向服务器回送FIN的ACK报文服务器接收到回送的ACK后直接关闭连接要注意到连接的关闭也可以由服务器发起SYN洪泛攻击现有的一种有效的防御系统:SYN cookie正常的过程, 半连接队列未满SYN foold攻击, 半连接队列满服务前端接收到 SYN(seq_a), 判断队列有没有如果没有满, 按照正常的处理过程, 将 SYN 放到半连接队列中, 回应SYN(seq_b)+ACK(seq_a+1)客户端回应ACK(seq_b+1), 服务端接受到客户端 ACK, 去检查半连接队列里是否有对应的 SYN, 如果有建立连接, 放到连接完成队列接收到 SYN, 判断半连接队列是否满, 是否开启了syncookie, 按照syncookie进行接下来处理将接收到的 SYN 进行算法hash, 将关键的字段加密成 服务端回应的SYN的seq , 发送给客户端ACK+SYN(此时seq=hash后的而关键数值), 并丢弃SYN. (可以类比seq为base64-encode过程)如果客户端是正常的客户端会对服务器端的SYN(seq)回应ACK(seq+1)服务端接收到 ACK(seq+1), 先检查半连接队列是否存在该ACK对应的SYN, 如果不存在, 继续检查是否开启了syncookie, 如果开启了, 就检查seq是否为合法cookie, 如果是则对其进行逆运算, 恢复之前SYN, 继续操作.(可以类比base64-decode)SYN洪泛攻击是攻击方大量发送SYN报文而不回复SYNACK的ACK报文,使服务器为这些SYN分配资源建立大量半连接.应对手段

@TOC流量控制服务的来源我们讲过TCP每一侧主机在建立连接时都会设置接收缓存当TCP连接收到正确,按序的字节后,就将数据放入接收缓存相关应用进程可以从缓存中读取数据,但不一定是刚到就去读如果进程读取数据的速度小于发送的速度就会造成接收缓存溢出流量控制服务( flow- control service) 就是TCP为其应用程序提供的消除发送方使接收方缓存溢出的可能性的服务什么是流量控制服务流量控制服务其实就是一个速度匹配服务,用来匹配发送方的发送速率与接收方应用程序的读取速率区分于拥塞控制,两者起因不同,拥塞控制是因为网络的拥塞流量控制服务的实现TCP 通过让发送方维护一个称为接收窗口 (receive window) 的变量来提供流量控制,即接收窗口用于给发送方一个指示一一该接收方还有多少可用的缓存空间举例实现rwnd = RcvBuffer - [LastByteRcvd - LastßyteRead ]LastByteReadLastByteRcvd"  LasLByteRcvd - LastByteRead ~ RcvBuffer   "明显必须成立主机 B 上的应用进程从缓存读出的数据流的最后一个字节的编号 。从网络中到达的并且已放人主机 B 接收缓存巾的数据流的最后 一个字节的编号。接收窗口用于给发送方一个指示一一该接收方还有多少可用的缓存空间主机 B 接收缓存为 RcvBuffer定义变量接收窗口用 rwnd 表示接收窗口rwnd 必须满足思考一个问题假设主机 B 的接收缓存已经存满，使得 rwnd =0 。 在将 rwnd =0 通告给主机 A 之后，还要假设主机 B 没有任何数据要发给主机 A 。 此时，考虑会发生什么情况 。因为主机 B 上的应用进程将缓存清空， TCP 并不向主机 A 发送带有 rwnd 新值的新报文段;事实上 ， TCP 仅当在它有数据或有确认要发时才会发送报文段给主机 A 。 这样，主机 A 不可能知道主机 B 的接收缓存已经有新的空间了，即主机 A 被阻塞而不能再发送数据!为了解决这个问题， TCP 规范中要求:当主机 B 的接收窗口为 0 时，主机 A 继续发送只有一个字节数据的报文段 。 这些报文段将会被接收方确认 。 最终缓存将开始清空，并且确认报文里将包含 一个非 0 的rwnd 值 。作者：北海以北没有小王链接：https://juejin.im/post/6844904152959549447来源：掘金著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

@TOC往返时间的估计指数加权移动平均 (Exponential Weighted Moving Average , EWMA)在 EWMA中的"指数"一词看起来是指一个给定的 SampleRTT 的权值在更新的过程中呈指数型快速衰减 。RTT(Round-Trip Time),表示为SampleRTT,在TCP协议中只会被在某个时刻测量一次,而非对所有报文段进行测量,且对于重传的报文段绝不做测量由于路由器和端系统的变化,我们测量的SampleRTT明显都会发生波动,是非典型的,我们要对SampleRTT取平均值每当获得一个新的SampleRTT,就采用如下公式更新EstimatedRTTEstÌmatedRTT = (1 -α) . EstimatedRTT +α. SampleRTT可见 EstimatedRTT 的新值是由以前的 EstimatedRTT 值与 SampleRTT 新值加权组合而成的 。在[RFC 6298]中给出的 α 参考值是α=0.125 (即 1/8)往返偏差的计算测量RTT的变化,DevRTT表示RTT 偏差公式: DevRTT = (1 -β) . DevRTT +β. I SampleRTT 一 EstimatedRTT Iβ 的推荐值为 0.25设置和管理重传超时间隔很明显我们的超时间隔应大于我们的EstimatedRTT,但也不能大太多以免造成时延过大公式:TimeoutInterval =EstimatedRTT+4 * DevRTT

@TOCTCP报文段由首部字段和一个数据字段组成结构图例首部字段源端口号目的端口号这两个端口号都是用于多路分解和多路复用的,即报文段准确送达指定套接字,具体可以看我之前的博文-一文带你看懂多路复用与多路分解。检验和字段用于检测在传输过程中报文段中的数据是否发生比特错误,具体可看我之前的博文-没搞清运输层的UDP协议? -哎呀, 早来这看就好了啊，在这篇博文的第四个副标题下提到了关于检验和的出现原因以及计算方式。32 比特的序号字段 (sequence number field)序号依赖于传输的字节流,而非传送的报文段序号受MMS(最大报文段长度)的限制，例如现在有一个50 000字节的文件带传送，MMS为1000字节，则TCP会将其分为50个报文段，其中第一个报文段假设初始序号为0（但不一定是0，是随机选择的一个数以防止跟其他程序的报文段序号重复），则第二个报文段序号为1000（0+MMS * 1）,第三个报文段序号为2000序号的选择通常在确定连接时由双方确定，均可随机选择图例32 比特的确认号字段( acknowledgment number field)累积确认：A已经收到序号为（N-1）及之前的所有字节A接下来希望收到来自B的序号为N的报文段确认号只会有一个，即流中第一个丢失字节（或者最后一个确认的字节后面一个）由于TCP的全双工特性，两个端系统之间互相都会发送数据（报文段）假设主机 A 填充进报文段的确认号为N16 比特的接收窗口字段 (receive window field)4 比特的首部长度字段 (header length field)可选与变长的选项字段 ( options field)用于发送方与接收方协商最大报文段长度 (MSS) 时或在高速网络环境下用作窗口调节因子时使用 。6 比特的标志字段 (fLag field)Telnet: 序号和确认号的一个学习案例Telnet简介假设主机 A 发起一个与主机 B 的 Telnet 会话 。(在客户端的)用户键人的每个字符都会被发送至远程主机;远程主机将回送每个字符的副本给客户，并将这些字符显示在 Telnet 用户的屏幕上。这种"回显" (echo back) 用于确保由 TelneL 用户发送的字符已经被远程主机收到并在远程站点上得到处理。因此，在从用户击键到字符被显示在用户屏幕上这段时间内，每个字符在网络中传输了两次 。图解第一个报文段传输的字符在建立连接时双方确定主机B的初始序号为79，所以主机A发送的第一个确认号就是79，表示接下来希望收到来自B的序号为79的报文段在建立连接时双方确定主机A的初始序号为42，所以主机A发送的第一个报文段序号就是42序号为42确认号为79数据字段为字符C第二个报文段回显字符2.接下来希望收到来自A的序号为43的报文段在建立连接时双方确定主机B的初始序号为79，所以主机B发送的第一个报文段序号就是79序号为79确认号为431.已经收到序号为42及之前（在这里没有之前）的报文段（字节）数据字段为字符C第三个报文段已经收到序号为79及之前（在这里没有之前）的报文段（字节）接下来希望收到来自B的序号为80的报文段(即是后面没了,但是他还是需要填入一个序号)表示这个由A发送的报文段序号为43序号为43确认号为80

@TOC我们先讨论一个高度简化版本-其只用超时恢复报文段的缺失。1.1 首先我们看看3 个与发送和重传有关的主要事件1.2 但是这也可能产生一些有趣的情况，考虑下列场景：1.3  超时间隔加倍对于重传的数据报,每次超时间都会加倍当然对于由于从上层接收到数据和收到ACK而启动的定时器还是正常的Timeoutlnterval 由最近的 EstimaledRTT 值与 DevRTT 值推算得到 。这是一种形式受限的拥塞控制接收方发送的确认报文在超时间隔之后才到达，发送方由于超时未接收到确认报文导致重传接收方发送的确认报文丢失，发送方由于超时未接收到确认报文导致重传情况1:收到的序号等于sendbase情况2:收到的序号大于sendbase累积确认若有还未确认的报文段,则重启定时器累计确认若有还未确认的报文段,则重启定时器定时超时重传则相应报文段然后重启定时器收到数据封装进报文段赋予序号交给IP层定时器启动事件1：从上层应用程序接收数据事件2：定时器超时事件3：收到 ACK现在我们来进行一个更全面的描述-超时机制加上冗余确认技术期望序号N的报文按序达到 - ACK延迟最多500ms,等待下一个报文段的是否在时间内到达,没到达则发送对于N的ACK具有所期望序号的按序报文段到达,另一个按序报文段等待ACK传输 - 对应第一种情况,直接发送ACK,以确认两个按序报文段比期望序号大的失序报文段到达，检测出间隔 - 立即发送冗余ACK能部分或完全填充接收数据间隔的报文段到达 - 立即发送最大确认ACK重复发送某个报文段(最后确认字节)的ACK,表示后面的报文可能丢失了允许接收方不丢弃失序报文段一般收到三个冗余ACK,TCPP就执行快速重传,即立即发送丢失的报文段对于超时重传,存在的问题可能是超时周期过长,会增加端到端的时延因此采用发送冗余ACK的技术接收方会遇到的四种情况TCP是选择回退N步还是选择重传'?(若还对回退N步以及选择重传比较模糊可以看我之前的博文-一文带你看流水线协议,回退N步以及选择重传)想想TCP是GBN还是SR？TCP 发送方仅需维持已发送过但未被确认的字节的最小序号( SendBase) 和下一个要发送的字节的序号( NextSeqNum) 。 在这种意义下， TCP 看起来更像一个 GBN 风格的协议。但是TCP又与GBN有一些区别许多TCP 实现会将正确接收但失序的报文段缓存起来 [Stevens 1994 J 。对 TCP 提出的一种修改意见是所谓的选择确认 (selective acknowledgment) [RFC 2018J ,它允许 TCP 接收方有选择地确认失序报文段，而不是累积地确认最后一个正确接收的有序报文段 。 当将该机制与选择重传机制结合起来使用时(即跳过重传那些已被接收方选择性地确认过的报文段)， TCP 看起来就很像我们通常的 SR 协议 。因此， TCP 的差错恢复机制也许最好被分类为 GBN 协议与 SR 协议的混合体 。

数据分析服务基于物联网资产模型，整合物联网数据集成，清洗，存储，分析，可视化，为开发者提供一站式服务，降低开发门槛，缩短开发周期，快速实现物联网数据价值变现。将感知层设备的数据先通过存储服务按天或者按大小存储起来，通过数据分析服务进行分析，经常用于预测，比如淘宝，可以通过分析你搜索的关键词之类的信息，从而推算出你需要购买的商品，给你进行推送。所以在今天这个世界，最值钱的东西是“数据”。IoT Studio应用开发服务基于物联网平台开放给北向应用的接口能力，配合华为云其他产品，提供第三方应用推荐、Web在线开发和微服务开发等功能帮助快速构建物联网应用。通过该服务可以快速开发一款App用于为你的各类物联网节点提供图形化控制、数据展示等功能。目前大部分的技术只能做到智能，跟随预先设定的规则让设备之间产生联动，相互控制，通过后面的机器学习等等技术慢慢的就能让设备被变得“智慧”，会自己去学习用户的习惯等等，让用户处于一个舒适的环境。

在编写一个框架时，脑海中一直在想着“如何写才能尽可能的去耦合？”去了耦合之后的模块在可移植性、可拓展性等方面都有较大的提升，模块与模块之间的联系性就降低了，这在框架中是一件好事，但是在学习理论与实践未必是一件好事。大脑是一个很神奇的东西，直接给它一些孤立的点，比如西瓜、报纸、衣服、手机这几个词，大脑一下子是无法记住的，但是给它一张网，例如我在边吃西瓜边看报纸，突然手机响了，我吓了一跳，把衣服弄脏了，这样是不是好记多了，学习一个知识也是这样，最容易学会的方法就是找到正在学习的知识和你已经具备的知识之间的联系，本章的耦合层，就是给大家找一个理论与实践之间的联系。理论与实践可以当作两个模块，本章内容就是为大家在这两个模块中间添加一个耦合层，让大家更容易将理论知识和实际开发联系到一块。物联网和TCP/IP一样，都是分层的，常常将物联网分为感知层、传输层、接入层、应用层，还能更细分，可能你已经清清楚楚记得每一层是什么？作用是什么？但是在实际开发中，看到华为物联网中那么多的服务，已经头昏眼花了，无法马上得知某个服务是对应某一层的。别担心，看完本章你就能深刻理解每种服务及对应的每一层，对物联网架构分析做到庖丁解牛，对物联网开发做到游刃有余。在教授他人一个知识的时候，最先教授的应该是全部的一个概括，而不是孤立的一个点，就好比我们看一份代码，如果你直接看.c文件中对函数的实现，那将痛苦不堪，看了前面完了后面，正确的做法是找一个Demo，看看被人如何使用这份代码的API，再去看看这份代码的.h文件，研究其API的作用，最后才看这些API分别是如何实现的。先复习一下物联网架构，如下图：每一层都是为自己上层提供支持，封装下层的数据，各大物联网云厂商几乎都遵循该架构图来设计自己的物联网体系，每一层对应不同的产品和服务。现在我以一个智能插座的例子，给大家讲解一下每层的作用，这是一个WIFI版本的智能插座，自身并不具备接入核心网的能力，需要通过网关进行接入，智能插座主要的功能是根据手机App下发的指令/定时来控制负载的开或关、检测当前负载的功率通过手机App显示，所以其属于“感知层”的设备。网关可以是家里面的无线路由器、手机热点等等，关于网关的定义是：连接两个或两个以上复杂网络的设备。智能插座的WIFI网络可以称为个人局域网，路由器（网关）可以将个人局域网和广域网（核心网）连接在一起，使不同网络间的设备和产品能相互通讯，所以网关处于“网络层”。数据到了广域网之后经过多个运营商的核心交换机等网络设备的转发，最终发送到“平台层”。平台层对应的是华为云“IoTDA设备接入”服务，将数据处理后转发给“应用层”，应用层最终通过手机App等软件将命令下发和数据上报接口以图形化的方式给用户展现。

MQTT v5 带来了很多新的特性，我们会尽量以通俗易懂的方式展示这些特性，并探讨这些特性对开发者的影响。到目前为⽌，我们已经探讨过这些 MQTT v5 新特性，现在我们将继续讨论：流量控制流量控制通常服务端的资源都是固定且有限的，而客户端的流量则可能是随时随地变化的。正常业务（用户集中访问、设备大量重启）、被恶意攻击、网络波动，都会导致流量出现激增，如果服务端没有对其进行任何限制，就会导致负载迅速上升，进而导致响应速度下降，影响其他业务，甚至导致系统瘫痪。因此，我们需要流量控制，可以是限制发送端的发送速率，也可以是限制接收端的接收速率，但最终目的都是保证系统的稳定。常用的流控算法有滑动窗口计数法、漏桶算法以及令牌桶算法。MQTT v3 没有规范流量控制行为，导致客户端和服务端在实现上百花齐放，进而影响了设备的接入和管理。不过现在，MQTT v5 已经引入了流量控制功能，这也是我们接下来将要探讨的内容。MQTT v5 中的流量控制在 MQTT v5 中，发送端会有一个初始的发送配额，每当它发送一个 QoS 大于 0 的 PUBLISH 报文，发送配额就相应减一，而每当收到一个响应报文（PUBACK、PUBCOMP 或 PUBREC），发送配额就会加一。如果接收端没有及时响应，导致发送端的发送配额减为 0，发送端应当停止发送所有 QoS 大于 0 的 PUBLISH 报文直至发送配额恢复。我们可以将其视为变种的令牌桶算法，它们之间的区别仅仅是增加配额的方式从以固定速率增加变成了按实际收到响应报文的速率增加。这种算法能够更加积极和充分地利用资源，因为它没有在发送速率的层面上进行限制，发送速率完全取决于对端的响应速率和网络情况，如果接收端空闲且网络良好，那么发送端可以得到比较高的发送速率，反之则会被限制到一个比较低的发送速率上。Receive Maximum 属性为了支持流量控制，MQTT v5 新增了一个 Receive Maximum 属性，它存在于 CONNECT 报文与 CONNACK 报文，表示客户端或服务端愿意同时处理的 QoS 为 1 和 2 的 PUBLISH 报文最大数量，即对端可以使用的最大发送配额。如果接收端已收到但未发送响应的 QoS 大于 0 的 PUBLISH 报文数量超过 Receive Maximum 的值，接收端将断开连接避免受到更严重的影响。为什么没有 QoS 0 ？也许你已经发现，前文所有提到 PUBLISH 报文的地方都使用了定语： QoS 大于 0。QoS 0 消息的特性决定了它不存在响应报文，也许是觉得 QoS 0 消息的重要性不高，接收端可以通过强制的接收速率限制来约束 QoS 0 消息，也许是其他原因，总之最后我们看到的 MQTT v5 的流量控制机制完全依赖响应报文，这就导致它的流量控制只能局限在 QoS 1,2 消息中。聊胜于无，MQTT v5 给出了一个并不完美的解决方案，或者说仅仅只是一个建议：当发送配额减为 0 时，发送端可以选择继续发送 QoS 为 0 的 PUBLISH 报文，也可以选择暂停发送。其中暂停发送的行为逻辑是，如果 QoS 1,2 的 PUBLISH 报文的应答速度变慢，通常意味着接收端的消费能力已经下降，继续发送 QoS 0 消息只会令情况变得更糟。结论尽管 MQTT v5 的流量控制机制依然存在一些不足，但我们依然建议用户尽可能地使用它。基于响应报文的发送配额算法使得发送端能够最大程度地利用资源，Receive Maximum 使得通信双方不再需要事先协商发送配额，从而获得更高的透明度和灵活性，这在需要接入多厂商设备时是很有帮助的。作者：EMQX83443链接：https://juejin.im/post/6857318491893170189来源：掘金著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

@[TOC](https://bbs.huaweicloud.com/community/usersnew/id_1583552184752389) 物联网产业在发展的过程中面临了一些挑战 * 新业务上线周期长 只能接入自己的平台、应用碎片化严重、产品开发周期长、产品上市慢 * 标准不统一、集成困难 终端传感器厂家多、通信协议众多、标准不统一、集成困难 * 网络联接复杂 物联网环境复杂、网络类型多、厂家开发终端需要适配很多协议、厂家进入物联网领域门槛较高 # 物联网平台之OceanConnect 对于物联网面临的主要挑战，我们要打破瓶颈、降低成本、降低终端和应用的开发成本，也降低厂家进入物联网领域的门槛。 聚焦核心竞争力发展物联网业务，需要一个终端接入解耦、能力开放、安全可靠的平台作为支撑。 IoT管理平台的作用分为两块，第一个作用，终端接入解耦，开放的终端接入，降低厂家终端开发成本；第二个作用，能力开放，开放的业务应用扩展，提供统一的API接口方便厂家开发应用。 ## 协议 ### HTTP **超文本传输协议**（英语：**H**yper**T**ext **T**ransfer **P**rotocol，缩写：**HTTP**）是一种用于分布式、协作式和[超媒体](https://zh.wikipedia.org/wiki/超媒體)信息系统的[应用层](https://zh.wikipedia.org/wiki/应用层)[协议](https://zh.wikipedia.org/wiki/网络传输协议)[[1\]](https://zh.wikipedia.org/wiki/超文本传输协议#cite_note-ietf2616-1)。HTTP是[万维网](https://zh.wikipedia.org/wiki/全球資訊網)的数据通信的基础。 ### MQTT **MQTT**[[1\]](https://zh.wikipedia.org/wiki/MQTT#cite_note-1)**消息队列遥测传输**（英语：Message Queuing Telemetry Transport）是[ISO 标准](https://zh.wikipedia.org/wiki/国际标准化组织)（ISO/IEC PRF 20922）[[2\]](https://zh.wikipedia.org/wiki/MQTT#cite_note-ISO-2)下基于[发布 (Publish)/订阅 (Subscribe)](https://zh.wikipedia.org/wiki/发布/订阅)范式的消息协议，可视为“资料传递的桥梁”[[3\]](https://zh.wikipedia.org/wiki/MQTT#cite_note-3)它工作在 [TCP/IP协议族](https://zh.wikipedia.org/wiki/TCP/IP协议族)上，是为硬件性能低下的远程设备以及网络状况糟糕的情况下而设计的[发布/订阅](https://zh.wikipedia.org/wiki/发布/订阅)型消息协议，为此，它需要一个[消息中间件](https://zh.wikipedia.org/w/index.php?title=消息中间件&action=edit&redlink=1)，以解决当前繁重的资料传输协议，如：[HTTP](https://zh.wikipedia.org/wiki/超文本传输协议)。 [[4\]](javascript:;) * 优点 1. 协议简单 2. 轻量级 3. 消息可以短至2个字节 4. 对终端的硬件配置要求低 5. 有助于降低终端成本 > MQTT非常符合物联网领域的要求，目前智慧家庭解决方案主要用的就是MQTT协议 ### CoAP **受限制的应用协议**（英文：**Constrained Application Protocol**，缩写：**CoAP**）是一种专用的Web传输协议，用于物联网中的受约束节点和受约束的网络。 该协议专为机器对机器（M2M）应用而设计，如智能能源和楼宇自动化。 CoAP有消息重传机制，为了克服HTTP对于受限环境的劣势，CoAP即考虑到数据报长度的最优化，又考虑到提供可靠通信。 ### MQTT和CoAP | | MQTT | CoAP | | ------------ | ------------------------------------------------------------ | -------------------------------------------------- | | 传输层协议 | TCP | UDP | | 消息模式 | 发布/订阅 | 请求/响应 | | 功耗 | 功耗略高 | 功耗较低 | | 长连接方式 | 支持 | 不支持 | | 心跳保活机制 | 是 | 否 | | 优点 | 协议简单轻量级终端的硬件配置要求低支持消息实时通知 | 数据报长度的最优化提供可靠通信节省电量 | | 应用场景 | 智慧家庭 | 智能水表、智能电表智慧农业、智能停车 | ## 平台 物联网平台根据服务层次划分 * 设备管理平台 * 连接管理平台 * 应用使能平台 * 业务分析平台 ### 设备管理平台 1. IoT设备接入 2. 数据的收集 3. 设备状态的监控和维护 ...... ### 连接管理平台 1. SIM卡生命周期管理 2. 状态监控 3. 故障诊断 ...... ### 应用使能平台 1. 快速开发IoT应用 2. 部署IoT应用 ...... ### 业务分析平台 1. 数据集合 2. 数据处理 3. 数据分析 ......

2020-08-19：TCP是通过什么机制保障可靠性的？

@[TOC](https://bbs.huaweicloud.com/community/usersnew/id_1583552184752389)> 我们对之前介绍的物联网无线通信技术做一个简单的对比 

@[TOC](https://bbs.huaweicloud.com/community/usersnew/id_1583552184752389) # 什么是LPWA LPWA（Low Power Wide Area）低功耗广域网，他解决了传统网络不能应对一些物联网场景的通信问题，低功耗广域网中比较为世人熟知的是**Sigfox、LoRa、NB-IoT**  ## Sigfox SigFox这一通信技术由法国的SigFox公司拥有，其主要打造**低功耗、低成本**的无线物联网专用网络，SigFox也是商用化速度比较快的一个LPWA网络技术 SigFox网络利用了**UNB（超窄带）技**术，传输功耗水平非常低，且能维持一个稳定的数据连接，通常他的传输速率只有100bps，其网络拓扑是一个可拓展的**高容量的网络**，具有非常低的能源消耗，同时保持**简单和易于部署**的基于星型单元的基础设施  SigFox无线链路使用免授权Sub-G的ISM射频频段频率根据国家法规有所不同，在欧洲广泛使用868MHz，在美国是915MHz ## LoRa LoRa是基于开源的MAC层协议的低功耗广域网标准，同时基于Sub-GHz的频段使其更易以较低功耗远距离通信  LoRa是美国semtec公司采用和推广的一种基于**扩频技术**的**超远距离无线传输方案**，这一方案改变了以往关于传输距离与功耗的折中考虑方式，为用户提供了一种**远距离、长电池寿命、大容量**的系统进而扩展传统网络。 目前LoRa网络也已经在世界多地进行试点或部署 ## NB-IoT NB-IoT是目前LPWA领域最火的一项技术，是构建于蜂窝网络的窄带物联网，只消耗大约180KHz 的宽带，可直接部署于GSM网络、UMTS网络、LTE网络以降低部署成本，实现平滑升级 | | NB-IoT | SigFox | LoRa | | :--------------------: | :----: | :----: | :--: | | 构建在运营商蜂窝网络上 | √ | × | × | | 基于Sub-GHz | √ | √ | √ | | 授权 | √ | × | × | * NB-IoT聚焦于低功耗广覆盖物联网上  可以广泛应用于**远程抄表、资产追踪、只能停车、智慧农业**等。

@[TOC](https://bbs.huaweicloud.com/community/usersnew/id_1583552184752389) # 百家争鸣的无线通信 无线通信技术可以分为蜂窝移动通信和短距无线通信技术两大类 蜂窝移动通信几位我们常说的2G、3G、4G通信技术 我们生活中的蓝牙（Bluetooth）、WIFI、ZigBee、Z-Wave便用到了短距无线通信技术 ## 蓝牙（Bluetooth）  蓝牙是一种大容量、近距离、无线数字通信技术标准，可以实现固定设备、移动设备和楼宇个人域网之间的短距离信息交换，主要使用2.4~2.485GHz的ISM波段的无线电波，最高数据传输速率1Mbps，最大传输距离为10厘米~10米的数据传输（通过增加发射功率传输距离可达到100米），蓝牙应用广泛，像生活中的手机、蓝牙耳机、蓝牙音箱、家用设备、智能穿戴都是通过蓝牙相互通信的 ## WIFI  Wi-Fi是一种允许电子设备连接到一个无线局域网( WLAN )的技术，通常使用2.4G UHF或5G SHF ISM射频频段 > 以上两种技术都是我们日常生活中比较常用的，下面来介绍ZigBee和Z-Wave两种无线通信技术 ## ZigBee  ### 什么是ZigBee技术？ ZigBee是基于IEEE802.15.4标准的低功耗局域网协议 ### ZigBee和蜂窝移动通信技术的比较 ZigBee与蜂窝移动技术不同的是，ZigBee广泛应用于工业和智慧家庭领域，他必须有简单、使用方便、工作可靠、价格低的特点，而移动通信网主要是为语音通信建立。每个基站价值都在百万元人民币以上，而每个ZigBee基站只要1000块左右。 每个ZigBee网络节点不仅本身可以作为监控对象，例如基座连接的传感器直接进行数据采集和监控，还可以自动中转别的网络节点传过来的数据信息。在较多的物联网应用场景都会使用ZigBee进行通信，一些智能家居的终端，包括网关汇聚的互联网解决方案。 ## Z-Wave  Z-Wave是一种新兴的基于射频的、低成本、低功耗、高可靠的短距离无线通信技术 Z-Wave技术设计用于住宅、照明商用控制以及状态读取应用，例如：照明、抄表和家电控制、接入控制、防盗及火灾警报。 Z-Wave在室内的有效覆盖范围是30米，室外可超过一百米适合于窄宽带应用场合 > 下一期我们详细介绍一下在物联网通信技术中举足轻重的LPWA技术，一起去感受一下他的低功耗远距离\(￣︶￣*\))

@[TOC](https://bbs.huaweicloud.com/community/usersnew/id_1583552184752389) # 稳定可靠的有线通信 ## 以太网 **以太网：**现有局域网采用的最通用的协议标准 主要分为**标准的以太网、快速以太网、10G以太网**，在智慧家庭物联网中，我们通常所熟知的家庭路由器宽带技术就有涉及以太网技术 ## 通信接口RS-232、RS-485 RS-232是个人计算机上的通讯接口之一，由ELA制定的异步传输标准接口，通常以9个引脚（DB-9）和25个引脚（DB-25）的形态出现，目前RS-232和类似的接口在诸如监控和控制系统的应用中得到普遍的应用 RS-485是为了解决RS-232这种接口可以实现点对点通信，但不能实现联网功能的问题而发展起来的 * **RS-232、RS-485**的区别 1. **传输方式的不同：**RS-232采用不平衡的通信方式，即所谓的单端通讯；RS-485采用平衡传输，即差分传输方式 2. **传输距离不同：**RS-232适合本地设备的通信，传输距离一般不超过20m，而RS-485的传输距离为几十米到上千米 3. **通信数量：**RS-232只允许一对一通信，而RS-485接口在总线上允许连接多大128个收发器 ## M-Bus M-Bus（Meter Bus）又称户用仪表总线，是一种用于非电力户用仪表传输的欧洲总线标准，专门为消耗测量仪器和计数器传送信息的数据总线设计，M-Bus在建筑物和工业能源消耗数据采集有多方面的应用 M-Bus总线的概念基于OSI参考模型，但又不是真正意义上的一种网络，在OSI七层网络模型中`M-Bus`只针对物理层、链路层、网络层、应用层进行了功能定义，由于在OSI参考模型总不允许上一层次改变如波特率地址等参数，因此在七层模型之外M-Bus定义了一个管理层，可以不遵守OSI模型对任意层进行管理 M-Bus总线的提出满足了公用事业仪表的组网和远程抄表的需要，同时它还可以满足远程供电或电池供电系统的特殊要求 M-Bus串行通信方式的总线型拓扑结构，非常适合公用事业仪表的可靠和低成本的组网要求，可以在几公里的距离上连接几百个从设备 ## PLC PLC（全称：`PowerLine Communication`，电力线通信）是利用电力线传输数据和媒体信号的一种通信方式，该技术是把载有信息的高频加载于电流，然后由电线传输接受信息的适配器，再把高频从电流中分离出来并传送的计算机或电话以实现信息传递 PLC电力线通信应用形式多种多样，除了我们熟知的可以将电力线通信将电表的数据传输到工业网关上，还可以作为家庭网络，PLC非常便于在传统数据处理设备（如PC机等）与计算机外设之间交换数据，此外信息家电也可以与计算机进行对话，利用PCL可以很方便的从电视机或VPC向PC机发送多媒体数据，PLC还可以用于家庭安全方面，可以把门口监控摄像机获得的图像送至电视机 > 有线通信技术有着稳定性强、可靠性高的特点，在我们的生活中运用的很普遍，但是有线技术的连接受限于连接媒介，满足不了一些远距离的灵活性强的连接 > > 而有限通信的缺点，我们可用于无线通信技术来补足 > > 下一期我们来介绍无线通信技术\(￣︶￣*\))

@[TOC](https://bbs.huaweicloud.com/community/usersnew/id_1583552184752389) # 什么是物联网 **物联网**（英文：`Internet of Things`，缩写：*IoT*）起源于[传媒](https://baike.baidu.com/item/传媒/890707)领域，是信息科技产业的第三次革命。物联网是指通过信息传感设备，按约定的协议，将任何物体与网络相连接，物体通过信息传播媒介进行信息交换和通信，以实现智能化识别、定位、跟踪、监管等功能。 在物联网应用中有三项关键技术，分别是**感知层、网络传输层和应用层**。  物联网的通信技术可以分为有线通信技术和无线通信技术，下面我们将对其做详细介绍 * 常见的有线通信技术  * 常见的无线通信技术  > 了解了物联网的层次划分后，下期我们来详细介绍有线通信技术\(￣︶￣*\))