k8s中pod的status：Pending Pod未调度,或者pod己调度正在拉取镜像Running Pod已经运行Failed Pod内容器运行停止Success Pod内容器运行成功结束Unknown Master与Node失联, Pod状态无法正常获取到restart policy：Always：只要容器失效退出就重启容器(默认配置)onFailure：当容器以非正常退出后重新启动容器Never：无论容器状态如何，都不重新启动容器k8s状态监控只能对pod进行监控，但是不能对pod上跑的应用监控。所以就需要有健康检查机制，对应用是否运行良好/就绪/启动进行检查。这有点类似于wcdma的双栈，部署初期信令延续2G的ATM，就不能感知另一条通路IP是否可达，需要软件跑个进程模拟实时可达性监控。k8s支持三种健康检查途径：ExecAction：在容器中执行指定的命令，如果能成功执行，则探测成功。HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP Get方法，如果响应的状态码200-400，则认为容器探测成功TCPSocketAction：通过容器IP地址和端口号执行TCP检查，如果能建立TCP连接，则探测成功。

一、概述1、解释协议、接口、服务协议规则的集合。这些规则规定所交换的数据格式及有关的同步问题。是水平的。实质：PDU(协议数据单元)+逻辑(信息内容格式+交互逻辑)基本要素：语义（规定所要完成的功能）+语法（传输数据的格式）+同步（执行各种操作的条件、时许关系等）接口同一结点内相邻两层交换信息的连接点，是一个系统内部的规定每层只能为紧邻的层次之间定义接口，不能跨层定义接口在典型的接口上，同一结点相邻两层的实体通过服务访问点 (Service Access Point，SAP)进行交互服务下层为紧邻的上层提供的功能调用。垂直的。对等实体在协议的控制下，使得本层能为上一层提供服务，但要实现本层协议还需要使用下一层所提供的服务2、计算机网络的性能指标带宽：通信线路允许通过的信号频带范围时延（计算）传输时延：分组长度/链路带宽(火车从车头到车尾进入山洞的时间)传播时延：物理链路长度/介质信号传播速度(火车在山洞里开的时间)处理时延：数据在交换节点为存储转发而进行的一些必要的处理所花费的时间排队时延：等待被发送到链路上的时间,取决于路由器的拥塞程度时延带宽积：发送端发送的第一个比特即将到达终点时，发送端发送除了多少个比特（时延带宽积 = 传播时延 x 信道带宽）往返时延(Round-Trip Time,RTT) 从发送端发送数据开始，到接收到接收端的确认总共经历的时延吞吐量：单位时间内整个网络传输数据的速率或分组数。一般小于带宽，受限于小的链路速率：数字信道上传送数据的速率信道利用率 ：有数据通信时间/（有+无）数据通信时间3、OSI模型、五层协议、TCP/IP模型服务层名称    作用    常见协议应用层    为特定应用程序提供数据传输服务    FTP, SMTP, STTP,HTTP表示层    数据压缩、加密以及数据描述    会话层    建立及管理会话    传输层    主机进程数据段传送    TCP,UDP网络层    主机(源目标节点)间分组传送    IP,路由协议链路层    相邻网络节点间的数据帧传送    PPP,Ethernet物理层    物理机制上的比特传送    区别OSI模型精确定义了服务、协议和接口的概念。而TCP/IP在这三个概念上没有明确的区分OSI参考模型产生在协议发明之前，没有偏向于任何特定的协议。TCP/IP模型正相反，实际上是对已有协议的描述CP/IP模型在设计之初就考虑到了多种异构网的互联问题，并将网际协议(IP)作为一个单独的重要层次OSI参考模型在网络层支持无连接和面向连接的通信，但在传输层仅有面向连接的通信。而TCP/IP模型认为可靠性是端到端的问题，因此它在网际层仅有一种无连接的通信模式，但传输层支持无连接和面向连接两种模式。这个不同点常常作为考查点。二、物理层三、链路层四、网络层五、传输层1、TCP和UDP及区别六、应用层1、http和https，及其区别区别：2、DNS域名系统，IP地址的域名映射功能：主机名到ip地址的转换主机别名:一个主机可以有一个规范主机名和多个主机别名邮件服务器别名负载分配:DNS实现冗余服务器:一个IP地址集合可以对应于同一个规范主机名查询方式：递归：层层递进知道查到结果再返回迭代：查询一次，就将查询结果返回本地DNS服务器3、输入网址获取页面的过程输入域名后，浏览器查找域名的IP地址浏览器先查找浏览器缓存，如果有域名的IP地址就返回，没有就继续查找系统查找系统缓存，如果有域名的IP地址就返回，没有就继续查找路由器查找路由器缓存，同上如果都没有找到，就从本地域名服务器开始进行DNS查询。本地域名服务器采用迭代的方式，先向根服务器查询，根服务器返回下一次查询的顶级域名服务器的IP地址。本地服务器向顶级域名服务器查询，顶级域名服务器告诉下一次应查询的权限域名服务器的IP地址反复直至到某一级服务器查询到了域名对应的IP地址本地域名服务器将结果告诉主机主机浏览器获取Web服务器的IP地址后，与服务器建立TCP连接（三次挥手）浏览器所在的客户机向服务器发出连接请求报文服务器接收报文后，同意建立连接，向客户机发送确认报文客户机接收确认报文后再次向服务器发送报文，确认已经收到确认报文TCP连接建立成功，开始通信浏览器发出取文件命令：GET服务器给出相应反馈，将指定文件发送到浏览器浏览器释放TCP连接（四次挥手）浏览器所在的主机向服务器发送连接释放报文，然后停止发送数据服务器收到确认释放报文后返回确认报文，然后将服务器上未发送的数据发送完发送完毕后，向客户机发送连接释放报文客户机收到报文后，发出确认，等待一段时间，释放TCP连接浏览器渲染页面内容

云平台在线调试时总是显示下发命令给设备失败，而且设备端打印命令也是空，不知道是云平台没有设置好还是硬件的问题。

并且我的这个cmd->payload里面是空的，出错的原因是什莫。

本文转自：捷配电子工程师笔记 ## 什么是PD快充? 大街上、地铁里，你总能看到许多“低头族”，ta们手捧着手机，一刻也不能分离。 现在，手机等电子设备的电量续航成为了人们比较关注的话题，众多快充技术也渐渐风靡起来。 众所周知，苹果从iPhone 8开始就支持PD快充了，但是苹果为什么会从一众快充技术中选择PD快充呢？  PD的全名应该叫做USB Power Delivery Specification，是USB的标准化组织推出的一个快速充电标准。 这个快充标准已经运行了有几年的时间，目前已经到了3.0的版本，所以我们现在谈到的PD快充通常就是指PD 3.0。但是这个协议是干嘛的呢?它“归化”了市面上的很多快充协议，由于手机充电都是通过USB接口充电的，所以USB标准化规定必须通过USB PD协议来调节电压和电流。 这样的一个统一的协议，让各个手机用户都可以更好地享受快速充电技术，方便了大家的使用。 像iPhone，支持了PD协议之后，就也可以享受快速充电功能了。根据充电头网给出的测试数据，iPhone 8可以在PD快充下实现峰值19W的快速充电。 **本文转自：捷配电子工程师笔记** 快充的兴起也带动了MOSFET的需求增长 消费电子市场的火爆场面拉动了快充的内需，而快充的兴起也带动了MOSFET的需求增长。 用于整流同步的MOS管，可以保证在快充电源提高电压来达到高电流高功率充电时的用电安全性。而低电压高电流充电的“闪充”对整流同步的MOS管要求更为严苛，MOS管用量也呈上升趋势。

请问传输层网络层以及应用层之间协议如何实现数据的传递

NFC技术由免接触式射频识别(RFID)演变而来，RFID的传输范围可以达到几米、甚至几十米，只能实现信息的读取以及判定，而NFC技术则强调的是信息交互。近场通信是工作在13.56MHz频率运行于20厘米距离内，其传输速度有106Kbit/秒、212Kbit/秒或者424Kbit/秒三种。　　近场通信论坛定义了三种操作模式(PDF)：　　点 对点模式(P2P mode)：支持两个近场通信设备之间相互通讯，实现信息交换和文件共享。　　读卡器模式(Reader/writer mode)：使近场能讯设备能从海报或者展览信息电子标签上读取相关信息。　　卡模式(Card emulation)：近场通信设备能像智能卡一样，允许用户支付零售购物和交通费用。　　NFC手机内置NFC芯片，组成RFID模块的一部分，可以当作RFID无源标签使用，用来支付费用;也可以当作RFID读写器用作数据交换与采集。　　从应用模式上分NFC卡模拟、读写器、点对点三种模式。卡模拟模式通常又被称为被读模式，手机终端可以模拟成为一张普通的非接触卡被POS机读取，此模式下通常是继承了现在广泛使用的应用，例如银行卡、门禁卡、公交卡等，以NFC手机作为载体并发挥手机在网络、多媒体、人机交互方面的优势，应用场景也与现有方式类似;读写器模式通常又被称为主读模式，手机终端可以读取一张非接触卡或者一个非接触标签中的内容，此模式下既可能继承了现有的应用，例如将NFC手机当做POS机去读取现有的银行卡、公交卡，又可以是NFC最新定义的应用场景，例如利用NFC手机读取NFC定义的标　　签中的标准数据，实现电子名片、电子海报、WIFI连接等功能;点对点模式是指两个手机终端在近距离内通过触碰直接传递数据，这是NFC定义的一种新模式，与蓝牙、WIFI相比有近距离和配置简单两个特点，理论上可以通过简单触碰实现两部手机间任何数据的交互，例如同步日程表、位置共享、名片交换等功能。　　NFC原理　　NFC架构及涉及的标准　　手机终端的NFC功能由NFC Controller、NFC协议栈、SE、SE访问API、SE访问控制及AP访问SE芯片构成，其主要功能如下：　　1. NFC Controller：即NFC芯片，实现NFC卡模拟、读写器、点对点模式所定义的模拟、数字协议的处理;　　2. NFC协议栈：配置NFC芯片工作模式并实现NFC Forum定义的各项标准;　　3. SE：即安全芯片，所有涉及敏感数据、加密运算等业务(如银行卡、公交卡)均需要单独安全芯片处理;　　4. SE访问API：向客户端开放访问SE的接口，以实现余额读取、空中充值等功能;　　5. SE访问控制：对SE访问进行控制和授权，保障SE安全;　　6. AP访问SE芯片：客户端通过应用处理器访问SE时的接口芯片，采用SE种类不同时该芯片也会有所不同，如SIM卡为SE时，此芯片即为Modem。 上述不同模块是可以组合的，从而实现不同的NFC功能，大致可分为简单NFC、具有SE的NFC两种类型：　　简单NFC是指仅具有NFC Controller和NFC协议栈的NFC终端，由于不具备SE，这种终端仅能支持上篇博文中提到的NFC读写器和点对点功能，实现诸如名片交换、标签读取等与安全无关的NFC功能。由于构成简单，且Android 2.3以上原生系统即已经实现这些功能，目前市场上多数的NFC终端都是这种简单NFC。相比简单NFC，具有SE的NFC终端均集成了单独的安全芯片SE，除读写器、点对点模式外，可支持卡模拟模式引入的安全应用(如银行卡、公交卡等)，既可支持POS机上的非接触刷卡，又可以支持客户端对SE的访问，实现SE中存储的银行卡、公交卡的余额读取、空中充值等功能。　　毫无疑问，具有SE功能的NFC终端是目前用户、运营商、银行更为关注的，不同机构在推动NFC终端时，采取的SE方式也是不同，目前看SE主要有三种类型，即SIM卡、终端内置SE芯片和MicroSD卡，分别代表运营商、终端厂家、银行从自身在产业链中所处位置，及在推动NFC终端初期时很自然的反应。应该讲从目前发展的情况看，运营商推动的以SIM卡为SE的NFC终端方案(即俗称的SWP方案)发展最快最好，以运营商行业组织GSMA协会牵头，世界上超过50家运营商(包括中国移动、中国联通及欧洲、美国、日韩主流运营商)宣布支持该方案，目前全球销售的终端近4000万部，预计13年会有持续的发展。后续将以目前最为主流的以SIM卡为SE的NFC终端方案(SWP方案)谈一下NFC终端具体支持的协议。NFC-SWP终端指的是支持SWP-SIM卡的NFC终端，也即以SIM卡做为SE的NFC终端。NFC-SWP终端从架构上看分为NFC非接触部分与SIM卡访问接口两部分：　　NFC-SWP终端架构　　(一)NFC非接触部分　　由图1中NFC Controller、NFC协议栈及SIM卡组成，提供NFC卡模拟、读写器及点对点功能，其中SIM卡主要在卡模式下起到了一个安全模块的作用，目前在读写器及点对点模式下尚未发挥作用。NFC终端不同模式下信息路由机制是不同的，在NFC终端工作在卡模拟模式时，外界POS机发送的信号会通过NFC Controller转发到SIM卡中处理，而当NFC终端工作在读写器、点对点模式时，从外部卡片或手机读取的信息将通过NFC Controller转发到NFC协议栈解析，最终转交给操作系统或客户端应用程序处理。　　NFC非接触部分的技术标准及测试标准相对较为完善，主要由ISO、NFC Forum、ETSI等标准化组织完成，其中：　　l ISO主要负责NFC空中接口底层的模拟、数字协议，ISO定义的射频协议已广泛应用在公交、银行、政府等行业　　l NFC Forum主要使命是定义新型的NFC设备，并保证其互通性，NFC Forum主要在ISO协议之上定义新型NFC设备之间数据交换所需的数据结构及链路层协议　　l ETSI主要负责制定NFC Controller与SE的接口规范，最初ETSI制定的接口规范仅限于SIM卡，但目前已作为一种通用的接口规范广泛使用在其它形态的SE中。　　NFC的标准相对是比较复杂的，且在不同NFC工作模式下遵循的标准是不尽相同的，以下是不同模式下应遵循的协议。　　模式射频协议中间协议(1)应用协议其它协议应用场景卡模拟模式ISO 14443无行业规定(2)ETSI 102.613(SWP)ETSI 102.622(HCI)兼容现有设备读写器模式ISO 14443无行业规定无兼容现有设备ISO 14443NFC Forum Tag Type 1-4NFC Forum NDEFNFC Forum RTDRTD外自定义应用协议(3)与NFC Forum设备互通点对点模式ISO 18092NFC Forum LLCPNFC Forum SNEPNFC Forum RTDRTD外自定义应用协议与NFC Forum设备互通注1：中间协议指NFC Forum设备间通信所需的链路层及数据格式协议注2：指由不同行业标准具体规定，不在NFC规范体系内，如PBOC、EMV等注3：NFC RTD规定了URI、联系人等几种常用的应用，这些应用已可被Android系统认知，不需要特殊的客户端支持;同时，不同应用方也可自定义应用协议，如GPS位置共享，但这些自有的应用协议需要配套的私有客户端软件才能识别　　从上表也可以看出，一部NFC终端不仅可以与符合NFC Forum协议的、全新的NFC Forum设备互通，也可以模拟成一个与普通非接触IC卡相同的设备，被存量非接触POS读取，从而可以在用户熟悉的现有非接触环境中广泛使用，减少用户的进入门槛，这对一个新型设备初期的推广是非常关键的。　　(二)SIM卡访问接口　　由图1中SE访问API、SE访问控制及Modem组成。手机与普通非接触IC卡最大的不同体现在拥有网络功能和人机交互两部分，因此，NFC手机可以从事传统非接触IC所不能完成的丰富业务，如空中充值、余额查询。所有这些业务均需要一个技术前提即需要一个标准的SIM卡访问接口，能够使得应用客户端访问SIM卡并与SIM卡中的applet进行通信。具体讲，需要在手机中支持三个标准：　　1、 SIM Alliance Open Mobile API：为应用客户端提供与SIM卡通信的通道　　2、 Global Platform/GSMA：Secure Element Access Control：授权应用客户端访问SIM卡中对应的applet　　3、 Modem：需完全支持3GPP 27.007标准，支持打开SIM卡逻辑通道，并能够在逻辑通信上真正实现APDU的透传。　　目前，NFC-SWP终端中相关标准化进行的较好，也有不少NFC-SWP手机已经支持这些标准，但实事求是的讲，由于缺乏上述三个标准对应的测试标准和测试工具，目前NFC手机对SIM卡访问接口的支持差强人意。Modem在逻辑通道上对APDU透传的支持特别需要引起重视，传统上Modem传递的都是ETSI 102.221电信标准中规定的APDU，但在新的NFC手机架构下，Modem的逻辑通道上可能还会传输银行、公交等行业的APDU，这些APDU的定义可能会与电信标准有一定的差别，也可能超出Modem提供商传统的知识范围。因此，从目前情况看，一方面需要手机特别是Modem提供商能够充分理解NFC业务的特点，特别是逻辑通道上与传统电信应用的差别，提高产品对逻辑通道上透传APDU的支持，另一方面，也需要标准化组织、运营商及各厂家一起完善测试标准及测试工具，从而促进并保证产品的成熟。　　终端所产生的无线电频率正弦波传递能量给标签然后从标签中读取数据。NFC启动后，持续产生信号中心频率13.56MHz的正弦波。如果有标签在该正弦波产生的磁场扰动范围内，标签由磁场扰动就会获得能量，产生原正弦波反频率或改变频率属性的波。手机探测到这种改变，以知道附近有标签。RFID在很近的距离通信通常被称为近配对系统。近配对系统的范围通常是0到1厘米。这意味着标签挨着读取器或按在读取器上。这么近距离的好处是标签的电池厂可以发出很大的能量。这能量足以支持标签通信，而不需要内置电源。近配对也利于高度保密的场合。例如带NFC功能的手机，带一个能产生13.56MHz无线电频率的集成电路，带有编码器，解码器，天线，比较器，还有传输能量到标签，并读取反向散射中的调制信息的硬件。读取器持续产生射频信号，并观察收到的射频信号，读取其中的信息。　　支持NFC的设备可以在主动或被动模式下交换数据。在被动模式下，启动NFC通信的设备，也称为NFC发起设备(主设备)，在整个通信过程中提供射频场(RF-field)，如图2所示。它可以选择106kbps、212kbps或424kbps其中一种传输速度，将数据发送到另一台设备。另一台设备称为NFC目标设备(从设备)，不必产生射频场，而使用负载调制(load modulation)技术，即可以相同的速度将数据传回发起设备。　　该标准规定了一个13.56MHz的工作频率，这是一个免许可国际通用频带，是美国ISM带15/18频带之一。数据传输速率为106、212或424kbps，取决于通讯范围，在20cm或大约8英寸时传输速率最大，实际通讯范围只有几英寸或不大于10cm，该标准规定了多种工作模式。　　在主动模式下，通讯双方收发器加电后，任何一方可以采用“发送前侦听”协议来发起一个半双工发送。在一个以上NFC设备试图访问一个阅读器时这个功能可以防止冲突，其中一个设备是发起者，而其它设备则是目标。　　在被动模式下，像RFID标签一样，目标是一个被动设备。标签从发起者传输的磁场获得工作能量，然后通过调制磁场将数据传送给发起者(后扫描调制，AM的一种)。　　在使用上因为NFC的使用通常会遇到使用尖峰时期，会了避免不同的发起端或目标端同时沟通造成数据链路错误，所以NFC采用了一种机制listen before talk。此机制会让当发起端设备要发出询问信号前，先侦测外界磁场强度来判断是否有其它的设备正在沟通中，这种机制的实现称为RF Collision Avoidance (RFCA)，其动作行为是在每次发起端发出询问信号时会侦测外界磁场，当磁场强度超过门坎强度时(Hthreshold=0.1875A/m)则会停止询问，直至外界强度降至门坎值以下。若是低于临界值才会开始发出询问指令，侦测的时间为TIDT+nTRFW，n为0～3的机率取样：TRFW=512/fc(RF waiting time)，TIDT>4096/fc(initial delay time)。当发起设备在TIDT+nTRFW内没有侦测到超过门坎强度的磁场，则会先发射TIRFG的未调变RF field之后再发出询问信号，其中TIRFG必须大于5ms。　　由于NFC 106kbps为100% ASK调变，所以对整个High/Low信号的封包结构都有相当详细的定义。其中几个参数包括从100%下降到5% Am时间(t1)、5% Am持续时间(t2)、Am由5%上升至60%时间(t4)即overshoot 的范围。而212/424kbps则是8%～30%的调变率。　　RF测试　　RF测试kit　　1. Calibration coil：coil的功能在于验证测试过程中，待测物所发射出的信号是否为正确的强度与调变。此Coil为一简单的天线架构，当然EMCA也详细的规定了所有的尺寸，由此coil所测出的值为0.32V (RMS)=1A/m(磁场强度)。　　2. Field Generating Antenna：kit用于磁场的发射，图中还包含了一组天线匹配线路。　　3. Sense coil：sense coil用于量测待测物的磁场强度与调变。　　4. Reference device：reference device用于测试DUT的标准件。　　RF测试程序　　1. 发起设备power测试：　　此测项在测试由发起设备所供给的磁场强度是否供给目标物足够的工作电源。　　将信号由generating antenna调整发射，于右端的calibration coil量测到的强度为Hmax(7.5A/m)，此时再将reference device配合power测试线路调整C2使线路共振点位于19MHz(此部份在规范中并无详述为何调整至19MHz，在此推论若19MHz可达到3V输出则当目标物为13.56MHz时其电压一定会超高3V，此因该为取其下限值)，放置于DUT位置，调整线路R2使的由C3所得到之电压值为3V。此时Reference device已经完成，之后再将此卡用来量测发起设备，将此卡放至于发起设备所标注之超作范围，在此超作范围内任意位置所量测到的电压值(C3)皆不可超过3V。至于Hmin测试则与max大致相同，不同处为将reference device共振频率调至13.56MHz及所量测知电压值皆须超过3V。　　2. 目标物的load modulation 测试：　　(1)被动模式　　● 106kbps：此测试为验证目标物可正确调变出波形，先将calibration coil放置于下侧外缘，确定generating antenna所发射之波形与强度正确无误，此时再将待测目标物放置于上侧外缘，编辑一个ECMA340 所定义之SENS_REQ波型由generating antenna发射并在待测目标物会回送一个SENS_RES信号，如此即可透过二个sense coil量测到信号，此量测架构因考量回传之负载调变信号微弱，所以利用两个sense coil之间电压差做计算，由于兼容系问题，所以在106kbps延续MiFARE使用副载波(subcarrier)的调变作被动目标物的回传信号，所以量测点应于fc+fs与fc-fs(fc=13.56MHz，fs=fc/16)。　　● 212/424kbps：高速的调变信号量测方式则与106kbps十分相似，只是将量测撷取位置改为fc，因为此两种传输速度下并无使用副载波调变　　(2)主动模式　　主动模式的测试与被动模式上并无太大的差异，由于是主动模式所以加测了目标物的RF field发射的时间，指令下达的时间……等。　　3. 发起设备的load modulation 测试：此测试在于验证发起设备的调变机制，可分为主动模式发射与被动模式接收两种。　　(1) 主动模式发射：将calibration coil放置于发起设备所定义的任意位置，而所量测的波型皆需符合ECMA340所定的规范。　　(2) 被动模式接收：此为测试发起设备可以正确的接收被动目标物所回传的信号。利用图7-2的load modulation 测试线路所做成的reference device，先将对应C3电压与距离的关系以图8的架构校正好，之后即可将此卡与发起设备的待测物做量测，测试由reference device所发出的调变信号于待测物端的接收情况。在此只能对部分的测试项目做讨论而详细的测试请参考ECMA。

HTTP之请求消息Request客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。Http请求消息结构.png●请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本。Get请求例子，使用Charles抓取的request：GET /562f25980001b1b106000338.jpg HTTP/1.1Host img.mukewang.comUser-Agent Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Accept image/webp,image/*,*/*;q=0.8 Referer http://www.imooc.com/ Accept-Encoding gzip, deflate, sdch Accept-Language zh-CN,zh;q=0.8第一部分：请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本.GET说明请求类型为GET,[/562f25980001b1b106000338.jpg]为要访问的资源，该行的最后一部分说明使用的是HTTP1.1版本。第二部分：请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息从第二行起为请求头部，HOST将指出请求的目的地.User-Agent,服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础.该信息由你的浏览器来定义,并且在每个请求中自动发送等等第三部分：空行，请求头部后面的空行是必须的即使第四部分的请求数据为空，也必须有空行。第四部分：请求数据也叫主体，可以添加任意的其他数据。这个例子的请求数据为空。POST请求例子，使用Charles抓取的request：POST / HTTP1.1Host:www.wrox.comUser-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) Content-Type:application/x-www-form-urlencoded Content-Length:40 Connection: Keep-Alive name=Professional%20Ajax&publisher=Wiley第一部分：请求行，第一行明了是post请求，以及http1.1版本。第二部分：请求头部，第二行至第六行。第三部分：空行，第七行的空行。第四部分：请求数据，第八行。HTTP之响应消息Response一般情况下，服务器接收并处理客户端发过来的请求后会返回一个HTTP的响应消息。HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。http响应消息格式.jpg例子HTTP/1.1 200 OKDate: Fri, 22 May 2009 06:07:21 GMTContent-Type: text/html; charset=UTF-8​<html>      <head></head>      <body>            <!--body goes here-->      </body></html>第一部分：状态行，由HTTP协议版本号， 状态码， 状态消息 三部分组成。第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为（ok）第二部分：消息报头，用来说明客户端要使用的一些附加信息第二行和第三行为消息报头，Date:生成响应的日期和时间；Content-Type:指定了MIME类型的HTML(text/html),编码类型是UTF-8第三部分：空行，消息报头后面的空行是必须的第四部分：响应正文，服务器返回给客户端的文本信息。空行后面的html部分为响应正文。HTTP之状态码状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:1xx：指示信息--表示请求已接收，继续处理2xx：成功--表示请求已被成功接收、理解、接受3xx：重定向--要完成请求必须进行更进一步的操作4xx：客户端错误--请求有语法错误或请求无法实现5xx：服务器端错误--服务器未能实现合法的请求常见状态码：200 OK                        //客户端请求成功400 Bad Request               //客户端请求有语法错误，不能被服务器所理解401 Unauthorized              //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用403 Forbidden                 //服务器收到请求，但是拒绝提供服务404 Not Found                 //请求资源不存在，eg：输入了错误的URL500 Internal Server Error     //服务器发生不可预期的错误503 Server Unavailable        //服务器当前不能处理客户端的请求，一段时间后可能恢复正常HTTP请求方法根据HTTP标准，HTTP请求可以使用多种请求方法。HTTP1.0定义了三种请求方法：GET, POST 和 HEAD方法。HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT方法。GET     请求指定的页面信息，并返回实体主体。HEAD     类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头POST     向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。PUT     从客户端向服务器传送的数据取代指定的文档的内容。DELETE      请求服务器删除指定的页面。CONNECT     HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。OPTIONS     允许客户端查看服务器的性能。TRACE     回显服务器收到的请求，主要用于测试或诊断。HTTP工作原理HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。以下是 HTTP 请求/响应的步骤：1、客户端连接到Web服务器一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.oakcms.cn。2、发送HTTP请求通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。3、服务器接受请求并返回HTTP响应Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。4、释放连接TCP连接若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;5、客户端浏览器解析HTML内容客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：1、浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;2、解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;3、浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;4、服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;5、释放 TCP连接;6、浏览器将该 html 文本并显示内容; 　　GET和POST请求的区别GET请求GET /books/?sex=man&name=Professional HTTP/1.1Host: www.wrox.comUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)Gecko/20050225 Firefox/1.0.1Connection: Keep-Alive注意最后一行是空行POST请求POST / HTTP/1.1Host: www.wrox.comUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)Gecko/20050225 Firefox/1.0.1Content-Type: application/x-www-form-urlencodedContent-Length: 40Connection: Keep-Alive​name=Professional%20Ajax&publisher=Wiley1、GET提交，请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，多个参数用&连接；例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。POST提交：把提交的数据放置在是HTTP包的包体中。上文示例中红色字体标明的就是实际的传输数据因此，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变2、传输数据的大小：首先声明：HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。而在实际开发中存在的限制主要有：GET:特定浏览器和服务器对URL长度有限制，例如 IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系 统的支持。因此对于GET提交时，传输数据就会受到URL长度的 限制。POST:由于不是通过URL传值，理论上数据不受 限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。3、安全性POST的安全性要比GET的安全性高。比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存；(2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery攻击4、Http get,post,soap协议都是在http上运行的（1）get：请求参数是作为一个key/value对的序列（查询字符串）附加到URL上的查询字符串的长度受到web浏览器和web服务器的限制（如IE最多支持2048个字符），不适合传输大型数据集同时，它很不安全（2）post：请求参数是在http标题的一个不同部分（名为entity body）传输的，这一部分用来传输表单信息，因此必须将Content-type设置为:application/x-www-form- urlencoded。post设计用来支持web窗体上的用户字段，其参数也是作为key/value对传输。但是：它不支持复杂数据类型，因为post没有定义传输数据结构的语义和规则。（3）soap：是http post的一个专用版本，遵循一种特殊的xml消息格式Content-type设置为: text/xml 任何数据都可以xml化。Http协议定义了很多与服务器交互的方法，最基本的有4种，分别是GET,POST,PUT,DELETE. 一个URL地址用于描述一个网络上的资源，而HTTP中的GET, POST, PUT, DELETE就对应着对这个资源的查，改，增，删4个操作。 我们最常见的就是GET和POST了。GET一般用于获取/查询资源信息，而POST一般用于更新资源信息.我们看看GET和POST的区别1、GET提交的数据会放在URL之后，以?分割URL和传输数据，参数之间以&相连，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的数据放在HTTP包的Body中.2、GET提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST方法提交的数据没有限制.3、GET方式需要使用Request.QueryString来取得变量的值，而POST方式通过Request.Form来获取变量的值。4、GET方式提交数据，会带来安全问题，比如一个登录页面，通过GET方式提交数据时，用户名和密码将出现在URL上，如果页面可以被缓存或者其他人可以访问这台机器，就可以从历史记录获得该用户的账号和密码.转载http://bbs.lierda.com/forum.php?mod=viewthread&tid=11446&extra=page%3D1

HTTP简介HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。HTTP协议工作于客户端-服务端架构为上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。主要特点1、简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。2、灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。3.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。4.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。5、支持B/S及C/S模式。HTTP之URLHTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息URL,全称是UniformResourceLocator, 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址。以下面这个URL为例，介绍下普通URL的各部分组成：从上面的URL可以看出，一个完整的URL包括以下几部分：1.协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符2.域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用3.端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口4.虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”5.文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名6.锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分7.参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。URI和URL的区别URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的URI一般由三部组成：①访问资源的命名机制②存放资源的主机名③资源自身的名称，由路径表示，着重强调于资源。URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：①协议(或称为服务方式)②存有该资源的主机IP地址(有时也包括端口号)③主机资源的具体地址。如目录和文件名等URN，uniform resource name，统一资源命名，是通过名字来标识资源。URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式。URL和URN都是一种URI。笼统地说，每个 URL 都是 URI，但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。在Java的URI中，一个URI实例可以代表绝对的，也可以是相对的，只要它符合URI的语法规则。而URL类则不仅符合语义，还包含了定位该资源的信息，因此它不能是相对的。在Java类库中，URI类不包含任何访问资源的方法，它唯一的作用就是解析。相反的是，URL类可以打开一个到达资源的流。转载IOT-WIFi-Http协议（1）http://bbs.lierda.com/forum.php?mod=viewthread&tid=11445(出处: 物联网开发者社区)

LWM2M协议规范协议简介LwM2M（lightweight Machine to Machine），是由OMA（open Mobile Alliance)定义的物联网协议，主要使用在资源受限(包括存储、功耗等)的NB-IoT终端。协议版本目前中国电信物联网开放平台支持LWM2M标准协议接入，兼容《LWM2M-1.0》和《LWM2M-1.1》版本协议。协议特点LWM2M协议栈如下图所示：LWM2M 把设备上的服务抽象为 Object 和 Resource，并在 XML 文件中定义各种Object 的属性和功能。LWM2M Objects：每个对象对应客户端的某个特定功能实体。LWM2M规范定义了标准Objects，比如urn: oma:lwm2m: oma:1; (LWM2M Server Object)、urn: oma: lwm2m: oma:3; (Device Object)，每个object下可以有很多resource。 比如Device Object可以有Manufacturer，Model Number等resource。LWM2M Protocol定义了一些逻辑操作，比如Read、Write、Execute等。CoAP是IETF定义的Constrained Application Protocol，用来做LWM2M的传输层，下层可以是UDP或者SMS，UDP是必须支持的，SMS可选。DTLS用来保证客户端和服务器间的安全性。平台实现支持IMEI、SM9、SimID、IPV6标识认证等设备认证方式。支持明文、DTLS、SM2等数据加密模式。支持object19透传、非透传(物模型)两种数据交互形式。支持OMA及IPSO标准obeject交互。支持FOTA、SOTA远程升级。接口介绍[td]通信协议地址端口说明LWM2M域名：lwm2m.ctwing.cnipv4：221.229.214.202ipv6: 240e:980:8120:28:dff9:8bb7:6c5b:ef455683UDP/CoAP非加密接口LWM2M+DTLS域名：lwm2m.ctwing.cnipv4：221.229.214.202ipv6: 240e:980:8120:28:dff9:8bb7:6c5b:ef455684UDP/CoAP加密接口NoteDTLS协议可参考《RFC6347》转载自http://bbs.lierda.com/forum.php?mod=viewthread&tid=11457&extra=page%3D1%26filter%3Dtypeid%26typeid%3D2

物联网终端开发由于操作系统需要运行于终端设备之上，但是物联网终端设备的种类非常多，同时所使用的芯片以及架构都不一样，所以碎片化非常严重，比方说ARM、FPGA的嵌入式架构，还有x86、DSP等等架构。开发者在对不同架构的设备进行开发的时候，就要使用不同的接口对它们进行适配。同时，这些终端设备的通信方式也是大不相同。比如，在智能家居当中，使用的设备以及通信协议是非常复杂的。比方说家里的蓝牙音箱用的是低功耗蓝牙协议，在智能灯泡以及恒温器当中所使用的协议是ZigBee、Z-wave这种可以连接大量设备同时安全性能高，可以自组网的协议。在摄像头和空调这一块更多的会去使用Wi-Fi协议，在空气检测器方面会去用基于IPv6的6LowPAN协议等等。因为家里面有这么多不同的场景，有为了照明的，有为了安防的还有为了娱乐的，那么只有合适的才是最好的，所以就衍生出了有这么多种协议以及通信技术，所以开发者就要对他们进行适配对接。物联网终端开发面临的挑战1、物联网终端种类众多，存在芯片和硬件的差异，开发者需要自行适配硬件接口2、物联网终端所采用的通信技术与协议多，同时通信模块迭代快，开发者需要自行选型和适配对接。3、多传感器协同管理复杂4、视频场景下性能、功耗要求高物联网操作系统开发在操作系统本身，开发者同样也遇到了非常大的挑战。以智能手环为例，它里面有非常多不同的传感器，比方说加速度传感器、心率传感器等等，开发者需要对不同的传感器进行统一管理。包括还有在视频场景下，拍摄高清画质的视频时，首先视频的大小是很大的，其次，在拍摄的时候他对于功耗的要求也是很高的。在一般情况下，便携式相机在拍摄4K 60fps这样高画质的视频时，相机最多只能支持拍摄一个小时左右。所以在视频场景下，功耗的要求也是一个非常大的考验。总结来讲，开发者在进行物联网操作系统开发是需要做到终端智能化，让使用操作系统的终端设备具备智能，其中终端智能化又有三个不同的方面。这三个不同的方面可以从物联网这个名字当中的三个字去进行拆解，首先“物”就是管理智能，这一点跟电脑是一样的，电脑的操作系统主要的作用是将电脑各个部分的资源都连接起来进行调用。物联网的操作系统也是一样，它需要把各种各样的物联网终端进行统一的管理并且进行资源的调配。之后的“联”就是连接智能，要让属于不同通信协议的设备互相能够进行通信。最后“网”就是组网智能，开发者可以使用mesh组网这种技术来使所有设备构建一个非常智能并且可以自组织、自连接的网络。

首页我们先来了解其他几种常见的协议。RTSP协议：RTSP（Real Time Streaming Protocol），实时流传输协议，是TCP／IP协议体系中的一个应用层协议。RTMP协议：RTMP（ Real Time Messaging Protocol），实时消息传输协议，RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash／AIR平台和支持RTMP协议的流媒体／交互服务器之间进行音视频和数据通信。HLS协议：HLS （HTTP Live Streaming） Apple的动态码率自适应技术。主要用于PC和Apple终端的音视频服务。NDI协议：NDI（Network Device Interface）是种IP网络设备接口协议。就是通过IP网络进行超低延时、无损传输、交互控制的标准协议；NDI是使视频兼容产品通过局域网进行视频共享的开放式协议。NDI的传输相比用同轴电缆传输会更有价格优势，更稳定，抗干扰能力更强。NDI能实时通过IP网络对多重广播级质量信号进行传输和接收，同时具有低延迟、精确帧视频、数据流相互识别和通信等特性。NDI可以灵活获取到任意的信号输入与输出。是一个完全创新的IP工作模式。NDI优势有哪些？NDI能让您轻松地过渡到 IP 工作流，将您的作品和工作流提升到您从未想象过的高度。只需简单地下载，您便能够将更多设备和应用程序整合到工作流，在节目中插入更多内容，并在网络内扩展视频机会。NDI强大的扩展性、灵活性和可靠的性能，可以胜任各种规模的赛制直播。兼容众多设备，让直播画面更为丰富，直播效果更为专业。直播玩法更加随心所欲。以前只有专业的直播团队才可胜任的工作，现在你也可以，随时随地捕捉精彩。抛弃传统流程，让NDI流程颠覆行业，整合所有工作流程。实时流媒体通过网络将直播信号推送到平台，让更多观众收看到精彩的直播。可以录制全分辨率的视频信号，方便后期剪辑处理。也可以分发您的播出内容。

简介蓝牙作为一项发明于上世纪的近距离无线通信技术，在手机，电脑领域已经有了充分地基础，那么这项技术在物联网领域又会有哪些应用场景呢？ 蓝牙技术的优势蓝牙标准是由蓝牙技术联盟(Bluetooth Special Interest Group)制定的，目前最新的协议标准是5.2 版本，其各版本的主要区别如下图所示：对蓝牙技术稍有了解的朋友会知道，在蓝牙协议4.0之前的蓝牙协议都叫做经典蓝牙(Classical Bluetooth)，常用的应用场景是蓝牙耳机，蓝牙鼠标，蓝牙键盘等数码产品的周边设备；而在蓝牙协议4.0之后，蓝牙协议主打的是低功耗蓝牙(Bluetooth Low Energy)，低功耗蓝牙设备的应用场景就宽泛了很多，例如蓝牙体重秤，蓝牙温度计，蓝牙防丢器，不再拘泥于为数码产品做配套设备，更多的可以应用在智能家居，智慧出行这些带有数据传输供能的应用场景，而且在2017年，蓝牙技术联盟也推出了蓝牙网状网络的协议规范——蓝牙mesh，完善了蓝牙技术在大量设备的远距离组网场景的应用缺陷，例如智能楼宇，智能工业等。所以蓝牙技术的第一个优势是协议统一，应用场合广泛蓝牙技术在物联网领域领域的第二个优势是产品价格，由于蓝牙协议已经发展了很多年，而且主打低功耗低速率场景，所以蓝牙芯片的设计和加工生产已经非常成熟，国内外均有非常多的芯片公司推出了自己的蓝牙芯片产品，例如国外的高通，博通，Nordic，Dialog等等，还有国内的泰凌，恒玄，炬芯等公司，所以大家在设计产品的时候可以根据自己的需求选择不同公司的芯片。蓝牙技术应用在物联网领域的第三个优势是有海量的手机或平板作为人机交互终端，从功能机时代开始，蓝牙就作为了手机上的一个标配功能，所以发展到了今天，所有的手机都带有蓝牙功能，这样相比较其他无线通信技术例如zigbee或者Lora，手机或者平板电脑就可以作为整个网络中的人机交互节点，这样就只需要在手机或者平板电脑上开发一个APP作为整个物联网应用的人机交互界面，而不需要重新开发一个人机交互终端作为控制和展示使用。 蓝牙技术的劣势蓝牙技术也并非全能的，他也存在着局限性，下面就来看看在物联网领域蓝牙技术存在有哪些劣势。 通信距离蓝牙是一种无线通信技术，那么通信距离就取决于其发射功率的大小，而蓝牙协议中规定的蓝牙设备最大发射功率如下     经典蓝牙低功耗蓝牙蓝牙1.0/2.0/3.0<100mW(20dbm)/蓝牙4.0<100mW(20dbm)<10mW(10dbm)蓝牙5.0<100mW(20dbm)<100mW(20dbm)而蓝牙芯片厂商为了做到更好的功耗，最大发射功率通常仅仅只有4dbm，所以大家通常使用的蓝牙耳机之类设备的有效通信距离约在10米左右，当然提高功率之后也能够做到更大的覆盖范围，我们尝试过把功率提到20dbm左右，这时蓝牙的通信距离约可以达到200米左右。当然，这个距离和LoRa，4G这类中广域通信技术相比的话，还是显得较小，有一定的使用局限性。 通信速率蓝牙协议主打的是低速场景，所以其最大通信速率如下表所示     经典蓝牙低功耗蓝牙蓝牙1.0<1Mbps/蓝牙2.0<3Mbps/蓝牙3.0<48Mbps/蓝牙4.0<48Mbps<1Mbps蓝牙5.0<48Mbps<2Mbps和同是无线传输的Wi-Fi协议相比，蓝牙的速率可以说是非常低，所以只能适合低数据量的场景，对于类似于视频流，高保真音频流传输这类功能场景就无能为力了。 兼容性前面也说过，现在有非常多的公司都有自己的蓝牙芯片产品，而且蓝牙协议栈也跑在不同的系统上，例如手机就有IOS和安卓，不同蓝牙协议栈的处理逻辑也不一样，那么这么多芯片之间的一个通信兼容性就是一个非常大的问题，尤其是在一个开放场景下，如果我们的物联网应用要接入非常多种类的蓝牙芯片，那么各个节点之间的互相通信和协议处理要做到一致是一件非常复杂的事情，需要经过大量的测试和验证才能够保证整个网络正常工作。 蓝牙技术的应用场景蓝牙技术联盟在2021年发布的最新蓝牙市场行业报告中指出，2020年全球蓝牙设备的总共出货约为40亿，而预计到2025年，蓝牙设备的总出货量将达到64亿。(以下图片数据均来自蓝牙技术联盟发布的《2021年蓝牙市场最新资讯》)蓝牙技术从经典蓝牙的音频传输场景现在扩展到了低功耗数据传输，同时也能满足位置服务和大规模设备网络解决方案的需求。 蓝牙音频传输产品包含蓝牙音箱，蓝牙耳机，蓝牙电视等产品，其实，作为经典蓝牙技术的典型场景，蓝牙音频产品已经陷入了瓶颈，但在2016年，苹果推出第一代airpods，并且在手机上取消了耳机孔，引起了一波蓝牙tws耳机的风潮，其他手机厂商也相继推出了自己的tws耳机产品。可以看到，2017年的音频产品出货量相比2016年有12.5%的提升。而且在去年发布的5.2协议中，低功耗蓝牙音频技术也正式发布，相信低功耗蓝牙耳机这种新技术产品在未来几年会有迅猛发展。 蓝牙数据传输产品包含遥控器，鼠标键盘，智能手环，智能手表，玩具等产品，这类型的设备是典型的物联网应用产品，通过蓝牙遥控器控制家里的电视，风扇，空调等家居设备，通过手环手表持续为人们提供健康监测服务，并且现在还有蓝牙电动牙刷，儿童可以通过手机蓝牙连接玩具上的蓝牙装置进行无线控制，基于蓝牙技术的”万物互联“产品在不断地丰富和拓宽。  蓝牙位置服务类产品人们可能接触的比较少，很典型的一个应用是苹果的ibeacon技术，商场或零售店铺部署了ibeacon基站，手机可以根据收到的附近ibeacon基站的信息来获得定位，甚至多台ibeacon基站联网之后，可以做到室内导航的功能。还有蓝牙实时定位系统能够帮助实现人员和资产的追踪，比如在仓库中定位工具和工人，医院中定位医疗仪器和患者。借助蓝牙协议5.1版本中的AoA/AoD技术，能够实现更高精度的室内寻向和定位导航功能。而且，所有的智能手机都带有蓝牙，蓝牙技术可以将智能手机变成更安全便捷的数字钥匙，让用户可以用手机解锁汽车，家庭，办公室等空间。  蓝牙设备网络设备主要是蓝牙mesh方案，在智能家居领域已经有了广泛的应用，天猫精灵智能家居系统作为全球第一个大规模采用蓝牙mesh方案的智能家居生态，在疫情期间，人们居家时间增多，远程控制和声控家居设备的需求也越来越大。而且蓝牙技术联盟与DALI联盟在商业照明领域也进行了合作，确保了蓝牙mesh网络的设备和传统的使用DALI协议的商业照明系统组件能够互联互通。 总结蓝牙技术是一项历史悠久的近距离无线通信技术，但它也在不断的发展来适应不同的应用场景，在开发过程中可以根据自己手头的业务需求来分析，找到一种合适的通信方案来作为我们物联网应用的连接方案。 

计算机网络体系结构的形成ARPANET层次模型思想 1969年 首个分组交换网IBM系统网络体系结构SNA 1974年 计算机协调工作ISO开放系统互连参考模型OSI/RM 1997年 开放系统互联网TCP/IP参考模型 互联网应用局域网的形成(20世纪80年代初)以太网EthernetIBM Token RingInternet时代的到来(20世纪80年代末)世界上规模最大和增长速率最快的计算机网络计算机网络发展特点第1阶段：计算机网络技术与理论的准备数据通信技术、分组交换技术第2阶段：计算机网络的形成ARPANET、TCP/IP、 DNS、E-mail、FTP、TELNET、BBS第3阶段：网络体系结构的研究OSI参考模型、 TCP/IP协议第4阶段：互联网应用、无线网络与网络安全技术研究的发展互联网、三网融合无线局域网、无线城域网、 P2P、网络安全

按照华为云IoT平台设备接入里的说法，当设备上传的数据是二进制时候需要编解码插件转成JSON格式，这样的话和直接设备传数据是二进制透传到服务器相比，各有什么优劣势呢？求解答！