网络层借助于已有的网络通信系统可以完成信息交互，把感知层感知到的信息快速、可靠地传送到相应的数据库，使物品能够进行远距离、大范围的通信。网络层是物联网的神经系统，主要进行信息的传递，网络层包括接入网和核心网。网络层根据感知层的业务特征优化网络，更好地实现物与物之间的通信、物与人之间的通信以及人与人之间的通信。物联网中接入设备有很多类型，接入方式也是多种多样，接入网有移动通信网络、无线通信网络、固定网络和有线电视网络HFC。移动通信网具有覆盖广、部署方便、具备移动性等特点.缺点是成本和耗电问题。有时还要借助有线和无线的技术，实现无缝透明的接入。随着物联网业务种类的不断丰富、应用范围的扩大、应用要求的提高，对于通信网络也会从简单到复杂、从单一到融合方向过渡。一、互联网与NGI体系架构互联网是由网络与网络之间串联成的庞大网络，这些网络以一组通用的协议相连，形成逻辑上的单一巨大国际网络。将计算机网络互相联结在一起，在这基础上发展出覆盖全世界的互联网络称互联网。互联网并不等同万维网，万维网只是一个基于超文本相互链接而成的全球性系统，是互联网所能提供的服务之一。开放系统互连参考模型(Open System Interconnect，OSI)是国际标准化组织(ISO)和国际电报电话咨询委员会(CCITT)联合制定的一个用于计算机或通信系统间开放系统互连参考模型，一般称为OSI参考模型或七层模型，CSI为开放式互连信息系统提供了一种功能结构的框架。它从低到高分别是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。七层模型目的是为异种计算机互连提供一个共同的基础和标准框架，并为保持相关标准的一致性和兼容性提供共同的参考。开放系统指的是遵循OSI参考模型和相关协议能够实现互连的具有各种应用目的的计算机系统。OSI参考模型如图1所示。从图1可见，整个开放系统环境由信源端和信宿端开放系统及若干中继开放系统通过物理介质连接构成。这里的端开放系统和中继开放系统相当于资源子网中的主机和通信子网中的节点机（IMP）。主机需要包含所有七层的功能，通信子网中的IMP一般只需要最低三层或者只要最低两层的功能即可。OSI参考模型是计算机网络体系架构发展的产物。基本内容是开放系统通信功能的分层结构。模型把开放系统的通信功能划分为七个层次，从物理媒体层开始，上面分别是数据链路层、网络层、传输层、会话层、表示层和应用层。每一层的功能是独立的。它利用其下一层提供的服务并为其上一层提供服务，而与其他层的具体实现无关。服务是下一层向上一层提供的通信功能和层之间的会话规定，一般用通信原语实现。两个开放系统中的同等层之间的通信规则和约定称为协议。第一层：物理层。提供为建立、维护和拆除物理链路所需要的机械的、电气的、功能的和规程的特性；有关的物理链路上传输非结构的位流以及故障检测指示。第二层：数据链路层。建立逻辑连接、进行硬件地址寻址、差错校验等功能，将比特组合成字节进而组合成帧，用MAC地址访问介质。在网络层实体间提供数据发送和接收的功能和过程；提供数据链路的流控，如802.2、802.3ATM、HDLC、FRAME RELAY。第三层：网络层。控制分组传送系统的操作、路由选择、用户控制、网络互连等功能，如IP、IPX、APPLETALK、ICMP。第四层：传输层。提供建立、维护和拆除传送连接的功能；选择网络层提供最合适的服务；在系统之间提供可靠的、透明的数据传送，提供端到端的错误恢复和流量控制，如TCP、UDP、SPX。第五层：会话层。提供两进程之间建立、维护和结束会话连接的功能；提供交互会话的管理功能，如RPC、SQL、NFS、X WINDOWS、ASP。第六层：表示层。代表应用进程协商数据表示；完成数据转换、格式化和文本压缩，如ASCLL、PICT、TIFFJPEG、MIDI、MPEG0第七层：应用层。提供用户服务，如文件传送协议和网络管理等（如HTTP、FTP、SNMP、TFTP、DNS、TELNET、POP3、DHCP）。模型中数据的实际传送过程如图2所示。数据由发送进程送给接收进程：经过发送方各层从上到下传递到物理介质；通过物理介质传输到接收方后，再经过从下到上各层的传递，最后到达接收进程。在发送方从上到下逐层传递的过程中，每层加上该层的头信息首部，即图2中的H7、H6、…、H1。到底层为由0或1组成的数据比特流（即位流），然后再转换为电信号或光信号在物理介质上传输至接收方，这个过程还可能采用伪随机系列扰码便于提取时钟。接收方在向上传递时的过程正好相反，要逐层剥去发送方相应层加上的头部信息。因接收方的某一层不会收到底下各层的头信息，而高层的头信息对于它来说又只是透明的数据，所以它只阅读和去除本层的头信息，并进行相应的协议操作。发送方和接收方的对等实体看到的信息是相同的，就像这些信息通过虚通道直接给了对方一样。开放系统互连参考模型各层的功能可以简单地概括为：物理层正确利用媒质，数据链路层协议走通每个节点，网络层选择走哪条路，传输层找到对方主机，会话层指出对方实体是谁，表示层决定用什么语言交谈，应用层指出做什么事。互联网的基础是TCP/IP协议。TCP/IP协议也可以看成四层的分层体系架构，从底层开始分别是物理数据链路层、网络层、传输层和应用层，为了和OSI的七层协议模型对应，物理数据链路层还可以拆分成物理层和数据链路层，每一层都通过调用它的下一层所提供的网络任务来完成自己的需求。TCP/IP分层模型的四个协议层有以下功能：第一层：物理数据链路层（Physical Data Link），又称网络接口层，还可以划分为物理层和数据链路层，包括用于协作IP数据在已有网络介质上传输的协议。TCP/IP标准并不定义与OSI数据链路层和物理层相对应的功能，而是定义像地址解析协议（Address Resolution Protocol，ARP）这样的协议，提供TCP/IP协议的数据结构和实际物理硬件之间的接口。物理层规定了通信设备的机械的、电气的、功能的等特性，用来建立、维护和拆除物理链路连接，如电气特性规定了物理连接上传输比特流时线路上信号电平强度、驻波比、阻抗匹配等。物理层规范有RS-232、V.35、RJ-45等。数据链路层实现了网卡接口的网络驱动程序，处理数据在物理媒介上的传输。数据链路层两个常用的协议是ARP和RARP（Reverse Address Resolve Protocol，逆地址解析协议）。这些协议实现IP地址和物理地址之间的相互转换。网络层通过IP地址寻址一台机器，而数据链路层通过物理地址寻址一台机器，因此网络层先将目标机器的IP地址转化为其物理地址，才能使用数据链路层提供的服务，这是ARP的用途。RARP协议仅用于网络上某些无盘工作站（无存储盘）。因为没有存储设备，无盘工作站只能利用网卡上的物理地址来向网络管理者查询自身IP地址。运行RARP服务的网络管理者通常存有该网络上所有机器的物理地址到IP地址的映射表。第二层：网络层（Network Layer），对应于OSI七层参考模型的网络层。本层包含IP协议、RIP协议（Routing Information Protocol，路由信息协议），负责数据的包装、寻址和路由。包含网间控制报文协议（Internet Control Message Protocol，ICMP，即互联网控制报文协议）用来提供网络诊断信息。网络层实现数据报的选路和转发。网络层的任务是确定两台主机之间的通信路径，对上层协议隐藏网络拓扑连接的细节，使得在传输层和网络应用程序看来，通信双方是直接相连的。网络层最核心的协议是IP协议。IP协议根据数据包的目的IP地址来决定如何投递它。网络层另外一个重要协议是ICMP，ICMP主要用来检查网络连接，可以分为两类：一类是差错报文，用来回应网络错误；另一类是查询报文，用来查询网络信息。ping程序就是使用ICMP报文查看目标报文是否可达。第三层：传输层（Transport Layer），对应于OSI七层参考模型的传输层，传输层为两台主机的应用程序提供端到端的通信服务。与网络层使用的逐跳方式不同，传输层只关心通信的起始端和目的端。传输层负责数据的收发、链路的超时重发等功能。传输层主要有三个协议；TCP协议（Transmission Control Protocol，传输控制协议）、UDP协议（User Datagram Protocol，用户数据报文）和SCTP协议（Stream Control Transmission Protocol，流控制协议）。TCP协议为应用层提供可靠的、面向连接的和基于流的服务。UDP协议为应用层提供不可靠、无连接和基于数据报的服务，优点是实时性比较好。SCTP协议是为在互联网上传输电话信号设计的。第四层：应用层（Application Layer），对应于OSI七层参考模型的应用层、表示层和会话层。应用层负责应用程序的逻辑。物理数据链路层、网络层、传输层协议系统负责处理网络通信细节，要稳定高效。应用层在用户空间实现。应用层协议有Finger、Whois、FTP（文件传输协议）、Gopher、HTTP（超文本传输协议）、SMTP（简单邮件传送协议）、IRC（互联网中继会话）、NNTP（网络新闻传输协议）、ping应用程序（不是协议，利用ICMP报文检测网络连接）、Telnet（远程终端登录协议）、OSPF（Open Shortest Path First，开放最短路径优先，协议提供动态路由更新协议，用于路由器之间的通信，告知对方各自的路由信息）、DNS（Domain Name Service，域名服务协议提供机器域名到IP地址的转换）等。应用层协议可跳过传输层直接使用网络层提供的服务，如ping。例如，DNS协议既可以使用TCP服务，又可以使用UDP服务。应用程序数据在发送到物理层之前，沿着协议栈从上往下依次传递。每层协议都将在上层数据的基础上加上自己的头部信息（有时包括尾部）完成封装，以实现该层的功能。当数据帧到达目的主机时，将沿着协议栈从下向上依次传递。各层协议处理数据帧中本层负责的头部数据，以获取所需信息，并将最终处理后的数据帧交给目标应用程序，这个过程叫作分用（demultiplexing）。分用是依靠头部信息中的类型字段实现的。OSI七层模型和TCP/IP四个协议层的关系：（1）OSI引入了服务、接口、协议、分层等概念；TCP/IP借鉴了OSI的这些概念并建立TTCP/IP模型。（2）OSI是先有模型，后有协议，先有标准，后进行实践；而TCP/IP是先有协议和应用，再参考OSI模型提出了自己的四个协议层模型。（3）OSI是一种理论模型，而TCP/IP已广泛使用，成为网络互联事实上的标准。TCP/IP模型可以通过IP层屏蔽掉多种底层网络的差异（IP over Everything），向传输层提供统一的IP数据包服务，进而向应用层提供多种服务（Everything over IP），因而具有很好的灵活性。随着互联网全球广泛应用，互联网网络节点数目呈现几何级数的增长。互联网上使用的网络层协议IPv4，其地址空间为32位，理论上支持40亿台终端设备的互联，随着互联网的迅速发展，这样的IP地址空间正趋于枯竭。1996年美国克林顿政府出台“下一代互联网”研究计划（Next Generation Internet，NGI），T一代互联网络协议IPv6具有以下优势。1.地址空间巨大IPv6的地址空间由IPv4的32位扩大到128位，2的128次方形成了一个巨大的地址空间，可以让地球上每个人拥有1600万个IP地址，甚至可以给世界上每一粒沙子分配一个IP地址。采用IPv6地址后，未来的移动电话、冰箱等信息家电都可以拥有自己的IP地址，基本实现给生活中的每一个东西分配一个自己的IP地址，让数字化生活无处不在。任何人、任何东西都可以随时、随地联网，成为数字化网络化生活的一部分，为物联网终端地址提供了保障。2.地址层次丰富IPv6用128位地址中的高64位表示网络前缀，如图2-6所示，低64位表示主机，为支持更多地址层次，网络前缀又分成多个层次的网络，包括13位的顶级聚类标识（TLA-ID）.24位的次级聚类标识（NLA-ID）和16位的网点级聚类标识（SLA-ID）0IPv6的管理机构将某一确定的TLA分配给某些骨干网ISP，骨干网ISP再灵活为各个中小ISP分配NLA，用户从中小ISP获得IP地址。3.实现IP层网络安全IPv6要求强制实施安全协议IPSec(Internet ProtocolSecurity)，并已将其标准化。IPSec在IP层可实现数据源验证、数据完整性验证、数据加密、抗重播保护等功能；支持验证头协议(Authentication Header，AH)、封装安全性载荷协议(Encapsulating Security Payload，ESP)和密钥交换IKE协议(Internet Key Exchange)，这三种协议将是未来互联网的安全标准。4.无状态自动配置IPv6通过邻居发现机制能为主机自动配置接口地址和缺省路由器信息，使得从互联网到最终用户之间的连接不经过用户干预就能够快速建立起来。IPv6在QoS服务质量保证、移动IP等方面也有明显改进。中国的下一代互联网CNGI：中国从1998年开始下一代互联网研究。1998年4月，中国教育和科研计算机网CERNET建立中国第一个IPv6试验网。1999年5月，CERNET正式接入全球性IPv6研究和教育网6RENO2000年3月，正式与国际下一代互联网签署互联协议。2001年3月，首次实现了与国际下一代互联网的互联。2003年8月，国务院批复启动“中国下一代互联网示范工程CNGI”。2004年3月，中国第一个下一代互联网主干网——CERNET2试验网在北京正式开通并提供服务，标志着中国下一代互联网建设的全面启动。CERNET2是中国下一代互联网示范工程最大的核心网，也是唯一的全国性学术网。CERNET2主干网采用IPv6协议。二、传输网与传感网的融合传感器网络是由大量部署在物理世界中的，具备感知、计算和通信能力的微小传感器组成，对物理环境和各种事件进行感知、检测和控制的网络。传感器网络采集到的物理世界的信息，可通过互联网、电信网等传输网传输到后台服务器，并融入到传输网络的业务平台之中。

## 1. 前言 随着社会的不断发展和人们生活水平的逐渐提高，人们逐渐追求高质量的生活，很多人都会选择在家里或办公室种植一些花卉以净化家庭空气，陶冶情操，但是很多人忙于工作、学习、出差、旅游或者一些其他的原因，不能及时地对花卉进行照料，短时间内导致很多花卉因缺水分而影响正常生长，长时间不照料有些名贵的花卉直接死亡。基于上述状况，提出了此基于物联网的智慧浇花系统。该系统采用工业级高精度土壤温湿度传感器采集花盆中的突然温湿度，环境的温度湿度，通过ESP8266 WIFI实时上传当前的土壤温湿度、环境光照度等数据到华为云物联网云平台，可以通过 app实时查看花卉的土壤湿度、环境温度等信息，并且本地通过OLED显示屏实时显示这些信息，可以设定某种花适宜的生长的土壤湿度条件，实现自动控制给花浇水，即能让花卉生长在适宜的湿度下，与目前市场上的自动浇花系统相比，该系统的特点具有远程控制，低成本、极高的资源利用率、操作简单和反应灵敏等。 ## 2. 整体系统设计 主控MCU选择STM32F103芯片，通过土壤湿度传感器、环境温湿度传感器，检测整个周边环境信息，再通过ESP8266 WIFI传递到物联网平台。程序里可以预设湿度阀值，当检测到土壤湿度低于阀值就自动浇花。在手机APP上可以实现远程控制水泵浇花，本地在搭载一个TFT小尺寸显示屏，可以实时显示测量检测的数据，在办公室里也可以通过TFT彩屏显示屏解周围环境的信息。 ## 3. 应用侧软件运行效果    ## 4. 硬件运行效果          ### 5. 创建产品、设备    ### 6.硬件核心代码--ESP8266 ```cpp #include "esp8266.h" u8 ESP8266_IP_ADDR[16]; //255.255.255.255 u8 ESP8266_MAC_ADDR[18]; //硬件地址 /* 函数功能: ESP8266命令发送函数 函数返回值:0表示成功 1表示失败 */ u8 ESP8266_SendCmd(char *cmd) { u8 i,j; for(i=0;i10;i++) //检测的次数--发送指令的次数 { USARTx_StringSend(USART2,cmd); for(j=0;j100;j++) //等待的时间 { delay_ms(50); if(USART2_RX_FLAG) { USART2_RX_BUFFER[USART2_RX_CNT]='\0'; USART2_RX_FLAG=0; USART2_RX_CNT=0; if(strstr((char*)USART2_RX_BUFFER,"OK")) { return 0; } } } } return 1; } /* 函数功能: ESP8266硬件初始化检测函数 函数返回值:0表示成功 1表示失败 */ u8 ESP8266_Init(void) { //退出透传模式 USARTx_StringSend(USART2,"+++"); delay_ms(100); //退出透传模式 USARTx_StringSend(USART2,"+++"); delay_ms(100); return ESP8266_SendCmd("AT\r\n"); } /* 函数功能: 一键配置WIFI为AP+TCP服务器模式 函数参数: char *ssid 创建的热点名称 char *pass 创建的热点密码 （最少8位） u16 port 创建的服务器端口号 函数返回值: 0表示成功 其他值表示对应错误值 */ u8 ESP8266_AP_TCP_Server_Mode(char *ssid,char *pass,u16 port) { char *p; u8 i; char ESP8266_SendCMD[100]; //组合发送过程中的命令 /*1. 测试硬件*/ if(ESP8266_SendCmd("AT\r\n"))return 1; /*2. 关闭回显*/ if(ESP8266_SendCmd("ATE0\r\n"))return 2; /*3. 设置WIFI模式*/ if(ESP8266_SendCmd("AT+CWMODE=2\r\n"))return 3; /*4. 复位*/ ESP8266_SendCmd("AT+RST\r\n"); delay_ms(1000); delay_ms(1000); delay_ms(1000); /*5. 关闭回显*/ if(ESP8266_SendCmd("ATE0\r\n"))return 5; /*6. 设置WIFI的AP模式参数*/ sprintf(ESP8266_SendCMD,"AT+CWSAP=\"%s\",\"%s\",1,4\r\n",ssid,pass); if(ESP8266_SendCmd(ESP8266_SendCMD))return 6; /*7. 开启多连接*/ if(ESP8266_SendCmd("AT+CIPMUX=1\r\n"))return 7; /*8. 设置服务器端口号*/ sprintf(ESP8266_SendCMD,"AT+CIPSERVER=1,%d\r\n",port); if(ESP8266_SendCmd(ESP8266_SendCMD))return 8; /*9. 查询本地IP地址*/ if(ESP8266_SendCmd("AT+CIFSR\r\n"))return 9; //提取IP地址 p=strstr((char*)USART2_RX_BUFFER,"APIP"); if(p) { p+=6; for(i=0;*p!='"';i++) { ESP8266_IP_ADDR[i]=*p++; } ESP8266_IP_ADDR[i]='\0'; } //提取MAC地址 p=strstr((char*)USART2_RX_BUFFER,"APMAC"); if(p) { p+=7; for(i=0;*p!='"';i++) { ESP8266_MAC_ADDR[i]=*p++; } ESP8266_MAC_ADDR[i]='\0'; } //打印总体信息 printf("当前WIFI模式:AP+TCP服务器\n"); printf("当前WIFI热点名称:%s\n",ssid); printf("当前WIFI热点密码:%s\n",pass); printf("当前TCP服务器端口号:%d\n",port); printf("当前TCP服务器IP地址:%s\n",ESP8266_IP_ADDR); printf("当前TCP服务器MAC地址:%s\n",ESP8266_MAC_ADDR); return 0; } /* 函数功能: TCP服务器模式下的发送函数 发送指令: */ u8 ESP8266_ServerSendData(u8 id,u8 *data,u16 len) { u8 i,j,n; char ESP8266_SendCMD[100]; //组合发送过程中的命令 for(i=0;i10;i++) { sprintf(ESP8266_SendCMD,"AT+CIPSEND=%d,%d\r\n",id,len); USARTx_StringSend(USART2,ESP8266_SendCMD); for(j=0;j10;j++) { delay_ms(50); if(USART2_RX_FLAG) { USART2_RX_BUFFER[USART2_RX_CNT]='\0'; USART2_RX_FLAG=0; USART2_RX_CNT=0; if(strstr((char*)USART2_RX_BUFFER,">")) { //继续发送数据 USARTx_DataSend(USART2,data,len); //等待数据发送成功 for(n=0;n200;n++) { delay_ms(50); if(USART2_RX_FLAG) { USART2_RX_BUFFER[USART2_RX_CNT]='\0'; USART2_RX_FLAG=0; USART2_RX_CNT=0; if(strstr((char*)USART2_RX_BUFFER,"SEND OK")) { return 0; } } } } } } } return 1; } /* 函数功能: 配置WIFI为STA模式+TCP客户端模式 函数参数: char *ssid 创建的热点名称 char *pass 创建的热点密码 （最少8位） char *p 将要连接的服务器IP地址 u16 port 将要连接的服务器端口号 u8 flag 1表示开启透传模式 0表示关闭透传模式 函数返回值:0表示成功 其他值表示对应的错误 */ u8 ESP8266_STA_TCP_Client_Mode(char *ssid,char *pass,char *ip,u16 port,u8 flag) { char ESP8266_SendCMD[100]; //组合发送过程中的命令 //退出透传模式 //USARTx_StringSend(USART2,"+++"); //delay_ms(50); /*1. 测试硬件*/ if(ESP8266_SendCmd("AT\r\n"))return 1; /*2. 关闭回显*/ if(ESP8266_SendCmd("ATE0\r\n"))return 2; /*3. 设置WIFI模式*/ if(ESP8266_SendCmd("AT+CWMODE=1\r\n"))return 3; /*4. 复位*/ ESP8266_SendCmd("AT+RST\r\n"); delay_ms(1000); delay_ms(1000); delay_ms(1000); /*5. 关闭回显*/ if(ESP8266_SendCmd("ATE0\r\n"))return 5; /*6. 配置将要连接的WIFI热点信息*/ sprintf(ESP8266_SendCMD,"AT+CWJAP=\"%s\",\"%s\"\r\n",ssid,pass); if(ESP8266_SendCmd(ESP8266_SendCMD))return 6; /*7. 设置单连接*/ if(ESP8266_SendCmd("AT+CIPMUX=0\r\n"))return 7; /*8. 配置要连接的TCP服务器信息*/ sprintf(ESP8266_SendCMD,"AT+CIPSTART=\"TCP\",\"%s\",%d\r\n",ip,port); if(ESP8266_SendCmd(ESP8266_SendCMD))return 8; /*9. 开启透传模式*/ if(flag) { if(ESP8266_SendCmd("AT+CIPMODE=1\r\n"))return 9; //开启 if(ESP8266_SendCmd("AT+CIPSEND\r\n"))return 10; //开始透传 if(!(strstr((char*)USART2_RX_BUFFER,">"))) { return 11; } //如果想要退出发送: "+++" } printf("WIFI模式:STA+TCP客户端\r\n"); printf("Connect_WIFI热点名称:%s\r\n",ssid); printf("Connect_WIFI热点密码:%s\r\n",pass); printf("TCP服务器端口号:%d\r\n",port); printf("TCP服务器IP地址:%s\r\n",ip); return 0; } /* 函数功能: TCP客户端模式下的发送函数 发送指令: */ u8 ESP8266_ClientSendData(u8 *data,u16 len) { u8 i,j,n; char ESP8266_SendCMD[100]; //组合发送过程中的命令 for(i=0;i10;i++) { sprintf(ESP8266_SendCMD,"AT+CIPSEND=%d\r\n",len); USARTx_StringSend(USART2,ESP8266_SendCMD); for(j=0;j10;j++) { delay_ms(50); if(USART2_RX_FLAG) { USART2_RX_BUFFER[USART2_RX_CNT]='\0'; USART2_RX_FLAG=0; USART2_RX_CNT=0; if(strstr((char*)USART2_RX_BUFFER,">")) { //继续发送数据 USARTx_DataSend(USART2,data,len); //等待数据发送成功 for(n=0;n200;n++) { delay_ms(50); if(USART2_RX_FLAG) { USART2_RX_BUFFER[USART2_RX_CNT]='\0'; USART2_RX_FLAG=0; USART2_RX_CNT=0; if(strstr((char*)USART2_RX_BUFFER,"SEND OK")) { return 0; } } } } } } } return 1; } ```

通信协议是指双方实体完成通信或服务所必须遵循的规则和约定。通过通信信道和设备互连起来的多个不同地理位置的数据通信系统，要使其能协同工作实现信息交换和资源共享，它们之间必须具有共同的语言。交流什么、怎样交流及何时交流，都必须遵循某种互相都能接受的规则。这个规则就是通信协议。 相信应该有很多读者都买过一些基于串口通信的模块，市面上很多基于串口通信的模块都是自定义通信协议，有的比较简单，有的相对复杂一点。

当前这篇帖子介绍STM32+BC20连接华为云物联网平台，实现与上位机之间进行数据交互，完成真实的产品开发。 ### 1.1 BC20模块 BC20是一款高性能、低功耗、多频段、支持 GNSS 定位功能的 NB-IoT 无线通信模块。BC20 在设计上兼容移远通信 GSM/GPRS/GNSS 系列的 MC20 模块，方便客户快速、灵活的进行产品设计和升级。BC20 提供丰富的外部接口和协议栈，同时支持中国移动 OneNET 物联网云平台，为客户的应用提供极大的便利。 BC20支持北斗、GPS、QZSS 等多星座卫星系统解调算法，其定位更加精准，抗多路径干扰能力更强，比传统的单GPS 模块具有更多优势。另外，BC20 模块中内置 LNA 和低功耗算法：前者保证更高的灵敏度，后者保证低功耗模式下更低的耗流。 BC20 模块较传统 NB-IoT+GNSS 方案体积减少 40%。凭借其紧凑尺寸、超低功耗和超宽工作温度范围，BC20 在各种应用中占具更大优势；其主要应用领域为：自行车和摩托车防盗、宠物追踪、金融财产追踪及行车记录仪等等。 C20 模块集成了 NB-IoT 和 GNSS（GPS+BeiDou） 双系统，在网络交互的同时， 实现 GNSS 系统的 快速、精准定位， 满足客户低功耗与高定位精度的应用场景。 **相比传统的具有单一 GPS 功能的模块， BC20 的主要优势如下：** a. 内嵌的 GNSS 模块，支持 GPS+BeiDou 双系统定位： 相同环境下可使用的卫星数量更多， 搜星的 b. 时间更短， 可加快定位速度， 提高定位精度； c. NB 和 GNSS 组合的小尺寸模块， 具备优良的环境适应性， 具备低功耗、抗干扰、高精度的特性； d. 内置 Sensor Hub 及领先的 PDR 算法，完美提升定位精度； e. 智能的 AGPS 辅助定位功能，加快冷启动模式下的定位速度 淘宝商店地址: https://m.tb.cn/h.fOCCkgV?sm=5ffdfe?tk=MkB92eHI0ZV  模块上有两排接口，一个是GPS信号输出接口，一个是BC20控制接口。 使用USB转TTL模块，将BC20板子与电脑连起来，调试板子是否正常。 ### 1.2 测试模块 第一步接上之后，串口调试助手选择波特率为115200，勾选软件上的发送新行选项。发送`AT`过去，正常模块会返回`OK`。  ### 1.3 上电初始化操作 ```cpp 查询模块是否正常 AT OK 获取卡号,查询卡是否插好 AT+CIMI 460041052911195 OK 激活网络 AT+CGATT=1 OK 获取网络激活状态 AT+CGATT? +CGATT: 1 OK 查询网络质量 AT+CSQ +CSQ: 26,0 OK AT+CEREG=? //检查网络状态 +CEREG: 0,1 //找网成功 OK ``` ### 1.4 开启GPS定位 **官方文档：**  ```cpp 激活GPS，要等一段时间 AT+QGNSSC=1 OK 查询激活状态，1表示成功激活 AT+QGNSSC? +QGNSSC: 1 OK 获取一次GPS定位语句 AT+QGNSSRD="NMEA/RMC" +QGNSSRD: $GNRMC,120715.00,A,3150.78179,N,11711.93433,E,0.000,,310818,,,A,V*19 OK ``` ### 1.5 连接MQTT服务器 下面通过MC20的AT指令连接华为云服务器，上传数据测试。 官方文档：  ```cpp 连接MQTT服务器 AT+QMTOPEN=0,"a161a58a78.iot-mqtts.cn-north-4.myhuaweicloud.com",1883 OK +QMTOPEN: 0,0 登录MQTT服务器 命令格式: AT+QMTCONN=,,, AT+QMTCONN=0,"6210e8acde9933029be8facf_dev1_0_0_2022021913","6210e8acde9933029be8facf_dev1","6cea55404b463e666cd7a6060daba745bbaa17fe7078dfef45f8151cdf19673d" OK +QMTCONN: 0,0,0 订阅主题 命令格式: AT+QMTSUB=,,"”,[,"”,…] AT+QMTSUB=0,1,"$oc/devices/6210e8acde9933029be8facf_dev1/sys/messages/down",2 OK +QMTSUB: 0,1,0,2 发布主题 命令格式:AT+QMTPUB=,,,,"","" 先发送指令: AT+QMTPUB=0,0,0,0,"$oc/devices/6210e8acde9933029be8facf_dev1/sys/properties/repor" 等待返回 ">" 接着发送数据.不需要加回车。 "{"services": [{"service_id": "gps","properties":{"longitude":12.345,"latitude":33.345}}]}" 数据发送完毕，再发送结束符。 十六进制的值--0x1a 。某些串口调试助手可以适应ctrl+z 快捷键输入0xA 等待模块返回"OK",到此数据发送完成。 OK +QMTPUB: 0,0,0 ```

本文分享自华为云社区《[在TIME_WAIT状态的TCP连接，收到SYN后会发生什么？](https://bbs.huaweicloud.com/blogs/335684?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》，作者：小林coding。 周末跟朋友讨论了一些 TCP 的问题，在查阅《Linux 服务器高性能编程》这本书的时候，发现书上写了这么一句话：  书上说，处于 TIME_WAIT 状态的连接，在收到相同四元组的 SYN 后，会回 RST 报文，对方收到后就会断开连接。 书中作者只是提了这么一句话，没有给予源码或者抓包图的证据。 起初，我看到也觉得这个逻辑也挺符合常理的，但是当我自己去啃了 TCP 源码后，发现并不是这样的。 所以，今天就来讨论下这个问题，「**在 TCP 正常挥手过程中，处于 TIME_WAIT 状态的连接，收到相同四元组的 SYN 后会发生什么？**」 问题现象如下图，左边是服务端，右边是客户端：  # 先说结论 在跟大家分析 TCP 源码前，我先跟大家直接说下结论。 针对这个问题，**关键是要看 SYN 的「序列号和时间戳」是否合法**，因为处于 TIME_WAIT 状态的连接收到 SYN 后，会判断 SYN 的「序列号和时间戳」是否合法，然后根据判断结果的不同做不同的处理。 先跟大家说明下， 什么是「合法」的 SYN？ - **合法 SYN**：客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要大，并且 SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要大。 - **非法 SYN**：客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要小，或者 SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要小。 上面 SYN 合法判断是基于双方都开启了 TCP 时间戳机制的场景，如果双方都没有开启 TCP 时间戳机制，则 SYN 合法判断如下： - **合法 SYN**：客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要大。 - **非法 SYN**：客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要小。 **收到合法 SYN** 如果处于 TIME_WAIT 状态的连接收到「合法的 SYN 」后，**就会重用此四元组连接，跳过 2MSL 而转变为 SYN_RECV 状态，接着就能进行建立连接过程**。 用下图作为例子，双方都启用了 TCP 时间戳机制，TSval 是发送报文时的时间戳：  上图中，在收到第三次挥手的 FIN 报文时，会记录该报文的 TSval （21），用 ts_recent 变量保存。然后会计算下一次期望收到的序列号，本次例子下一次期望收到的序列号就是 301，用 rcv_nxt 变量保存。 处于 TIME_WAIT 状态的连接收到 SYN 后，**因为 SYN 的 seq（400） 大于 rcv_nxt（301），并且 SYN 的 TSval（30） 大于 ts_recent（21），所以是一个「合法的 SYN」，于是就会重用此四元组连接，跳过 2MSL 而转变为 SYN_RECV 状态，接着就能进行建立连接过程**。 **收到非法的 SYN** 如果处于 TIME_WAIT 状态的连接收到「非法的 SYN 」后，就会**再回复一个第四次挥手的 ACK 报文，客户端收到后，发现并不是自己期望收到确认号（ack num），就回 RST 报文给服务端**。 用下图作为例子，双方都启用了 TCP 时间戳机制，TSval 是发送报文时的时间戳：  上图中，在收到第三次挥手的 FIN 报文时，会记录该报文的 TSval （21），用 ts_recent 变量保存。然后会计算下一次期望收到的序列号，本次例子下一次期望收到的序列号就是 301，用 rcv_nxt 变量保存。 处于 TIME_WAIT 状态的连接收到 SYN 后，**因为 SYN 的 seq（200） 小于 rcv_nxt（301），所以是一个「非法的 SYN」，就会再回复一个与第四次挥手一样的 ACK 报文，客户端收到后，发现并不是自己期望收到确认号，就回 RST 报文给服务端**。 客户端等待一段时间还是没收到 SYN + ACK 后，就会超时重传 SYN 报文，重传次数达到最大值后，就会断开连接。 >PS：这里先埋一个疑问，处于 TIME_WAIT 状态的连接，收到 RST 会断开连接吗？ # 源码分析 下面源码分析是基于 Linux 4.2 版本的内核代码。 Linux 内核在收到 TCP 报文后，会执行 tcp_v4_rcv 函数，在该函数和 TIME_WAIT 状态相关的主要代码如下： int tcp_v4_rcv(struct sk_buff *skb) { struct sock *sk; ... //收到报文后，会调用此函数，查找对应的 sock sk = __inet_lookup_skb(&tcp_hashinfo, skb, __tcp_hdrlen(th), th->source, th->dest, sdif, &refcounted); if (!sk) goto no_tcp_socket; process: //如果连接的状态为 time_wait，会跳转到 do_time_wait if (sk->sk_state == TCP_TIME_WAIT) goto do_time_wait; ... do_time_wait: ... //由tcp_timewait_state_process函数处理在 time_wait 状态收到的报文 switch (tcp_timewait_state_process(inet_twsk(sk), skb, th)) { // 如果是TCP_TW_SYN，那么允许此 SYN 重建连接 // 即允许TIM_WAIT状态跃迁到SYN_RECV case TCP_TW_SYN: { struct sock *sk2 = inet_lookup_listener(....); if (sk2) { .... goto process; } } // 如果是TCP_TW_ACK，那么，返回记忆中的ACK case TCP_TW_ACK: tcp_v4_timewait_ack(sk, skb); break; // 如果是TCP_TW_RST直接发送RESET包 case TCP_TW_RST: tcp_v4_send_reset(sk, skb); inet_twsk_deschedule_put(inet_twsk(sk)); goto discard_it; // 如果是TCP_TW_SUCCESS则直接丢弃此包，不做任何响应 case TCP_TW_SUCCESS:; } goto discard_it; } 该代码的过程： 1. 接收到报文后，会调用 __inet_lookup_skb() 函数查找对应的 sock 结构； 2. 如果连接的状态是 TIME_WAIT，会跳转到 do_time_wait 处理； 3. 由 tcp_timewait_state_process() 函数来处理收到的报文，处理后根据返回值来做相应的处理。 先跟大家说下，如果收到的 SYN 是合法的，tcp_timewait_state_process() 函数就会返回 TCP_TW_SYN，然后重用此连接。如果收到的 SYN 是非法的，tcp_timewait_state_process() 函数就会返回 TCP_TW_ACK，然后会回上次发过的 ACK。 接下来，看 tcp_timewait_state_process() 函数是如何判断 SYN 包的。 enum tcp_tw_status tcp_timewait_state_process(struct inet_timewait_sock *tw, struct sk_buff *skb, const struct tcphdr *th) { ... //paws_reject 为 false，表示没有发生时间戳回绕 //paws_reject 为 true，表示发生了时间戳回绕 bool paws_reject = false; tmp_opt.saw_tstamp = 0; //TCP头中有选项且旧连接开启了时间戳选项 if (th->doff > (sizeof(*th) >> 2) && tcptw->tw_ts_recent_stamp) { //解析选项 tcp_parse_options(twsk_net(tw), skb, &tmp_opt, 0, NULL); if (tmp_opt.saw_tstamp) { ... //检查收到的报文的时间戳是否发生了时间戳回绕 paws_reject = tcp_paws_reject(&tmp_opt, th->rst); } } .... //是SYN包、没有RST、没有ACK、时间戳没有回绕，并且序列号也没有回绕， if (th->syn && !th->rst && !th->ack && !paws_reject && (after(TCP_SKB_CB(skb)->seq, tcptw->tw_rcv_nxt) || (tmp_opt.saw_tstamp && //新连接开启了时间戳 (s32)(tcptw->tw_ts_recent - tmp_opt.rcv_tsval) 0))) { //时间戳没有回绕 // 初始化序列号 u32 isn = tcptw->tw_snd_nxt + 65535 + 2; if (isn == 0) isn++; TCP_SKB_CB(skb)->tcp_tw_isn = isn; return TCP_TW_SYN; //允许重用TIME_WAIT四元组重新建立连接 } if (!th->rst) { // 如果时间戳回绕，或者报文里包含ack，则将 TIMEWAIT 状态的持续时间重新延长 if (paws_reject || th->ack) inet_twsk_schedule(tw, &tcp_death_row, TCP_TIMEWAIT_LEN, TCP_TIMEWAIT_LEN); // 返回TCP_TW_ACK, 发送上一次的 ACK return TCP_TW_ACK; } inet_twsk_put(tw); return TCP_TW_SUCCESS; } 如果双方启用了 TCP 时间戳机制，就会通过 tcp_paws_reject() 函数来判断时间戳是否发生了回绕，也就是「当前收到的报文的时间戳」是否大于「上一次收到的报文的时间戳」： - 如果大于，就说明没有发生时间戳绕回，函数返回 false。 - 如果小于，就说明发生了时间戳回绕，函数返回 true。 从源码可以看到，当收到 SYN 包后，如果该 SYN 包的时间戳没有发生回绕，也就是时间戳是递增的，并且 SYN 包的序列号也没有发生回绕，也就是 SYN 的序列号「大于」下一次期望收到的序列号。就会初始化一个序列号，然后返回 TCP_TW_SYN，接着就重用该连接，也就跳过 2MSL 而转变为 SYN_RECV 状态，接着就能进行建立连接过程。 如果双方都没有启用 TCP 时间戳机制，就只需要判断 SYN 包的序列号有没有发生回绕，如果 SYN 的序列号大于下一次期望收到的序列号，就可以跳过 2MSL，重用该连接。 如果 SYN 包是非法的，就会返回 TCP_TW_ACK，接着就会发送与上一次一样的 ACK 给对方。 # 在 TIME_WAIT 状态，收到 RST 会断开连接吗？ 在前面我留了一个疑问，处于 TIME_WAIT 状态的连接，收到 RST 会断开连接吗？ 会不会断开，关键看 net.ipv4.tcp_rfc1337 这个内核参数（默认情况是为 0）： - 如果这个参数设置为 0， 收到 RST 报文会提前结束 TIME_WAIT 状态，释放连接。 - 如果这个参数设置为 1， 就会丢掉 RST 报文。 源码处理如下： enum tcp_tw_status tcp_timewait_state_process(struct inet_timewait_sock *tw, struct sk_buff *skb, const struct tcphdr *th) { .... //rst报文的时间戳没有发生回绕 if (!paws_reject && (TCP_SKB_CB(skb)->seq == tcptw->tw_rcv_nxt && (TCP_SKB_CB(skb)->seq == TCP_SKB_CB(skb)->end_seq || th->rst))) { //处理rst报文 if (th->rst) { //不开启这个选项，当收到 RST 时会立即回收tw，但这样做是有风险的 if (twsk_net(tw)->ipv4.sysctl_tcp_rfc1337 == 0) { kill: //删除tw定时器，并释放tw inet_twsk_deschedule_put(tw); return TCP_TW_SUCCESS; } } else { //将 TIMEWAIT 状态的持续时间重新延长 inet_twsk_reschedule(tw, TCP_TIMEWAIT_LEN); } ... return TCP_TW_SUCCESS; } } TIME_WAIT 状态收到 RST 报文而释放连接，这样等于跳过 2MSL 时间，这么做还是有风险。 sysctl_tcp_rfc1337 这个参数是在 rfc 1337 文档提出来的，目的是避免因为 TIME_WAIT 状态收到 RST 报文而跳过 2MSL 的时间，文档里也给出跳过 2MSL 时间会有什么潜在问题。 TIME_WAIT 状态之所以要持续 2MSL 时间，主要有两个目的： - 防止历史连接中的数据，被后面相同四元组的连接错误的接收； - 保证「被动关闭连接」的一方，能被正确的关闭； 虽然 TIME_WAIT 状态持续的时间是有一点长，显得很不友好，但是它被设计来就是用来避免发生乱七八糟的事情。 《UNIX网络编程》一书中却说道：**TIME_WAIT 是我们的朋友，它是有助于我们的，不要试图避免这个状态，而是应该弄清楚它**。 所以，我个人觉得将 net.ipv4.tcp_rfc1337 设置为 1 会比较安全。 # 总结 在 TCP 正常挥手过程中，处于 TIME_WAIT 状态的连接，收到相同四元组的 SYN 后会发生什么？ 如果双方开启了时间戳机制： - 如果客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要大，并且SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要大。那么就会重用该四元组连接，跳过 2MSL 而转变为 SYN_RECV 状态，接着就能进行建立连接过程。 - 如果客户端的 SYN 的「序列号」比服务端「期望下一个收到的序列号」要小，或者SYN 的「时间戳」比服务端「最后收到的报文的时间戳」要小。那么就会**再回复一个第四次挥手的 ACK 报文，客户端收到后，发现并不是自己期望收到确认号，就回 RST 报文给服务端**。 在 TIME_WAIT 状态，收到 RST 会断开连接吗？ - 如果 net.ipv4.tcp_rfc1337 参数为 0，则提前结束 TIME_WAIT 状态，释放连接。 - 如果 net.ipv4.tcp_rfc1337 参数为 1，则会丢掉该 RST 报文。

在汽车行业复杂的产业链中，上下游各环节的协作都需要“签字、盖章”来推进。签署是否及时、合规，直接关系业务推进效率，完善电子签章应用能力，成为众多车企数字化转型的重要任务之一。契约锁电子签章无缝对接“DMS经销商管理系统、物流系统、生产系统、金融租赁平台以及微信小程序等”，将“数字身份、电子印章、电子签名、电子模板、数据存证等”功能深入应用到“汽车零部件采购、整车运输与仓储、分销授权、购车、融资租赁、售后服务等”各类核心业务中，推动汽车全产业链组织数字化转型。（覆盖汽车全产业链各环节签署需求）30+特色业务签署场景助推汽车全产业链业务签署全面数字化（覆盖行业各项业务环节签署需求）▮▮▮ 分销销售文件文件类型：购车合同、试驾协议、新车订购合约书、保险文件、销售收款凭证、特约店订车折让协议、员工优惠购车协议、贷款协议、阳光协议（廉洁协议）、授权协议、对账单等汽车的销售包括经销商代理分销，以及终端客户购买，从整车制造厂商到4S店、特约店，销售文件材料签署效力关系到汽车流转效率和销售量。>>>解决方案：契约锁帮助集成DMS经销商管理系统、CRM管理系统以及微信小程序等，帮助打造面向经销商以及终端客户的线上签署平台，实现在线订货、购车。纸质签署 VS 电子签署纸质签署：• 客户到了签约下单的最后一环，领导却出差不在，等待时间一长，跑单难防。• 门店打印了大量纸质合同模板供使用，万一内容调整，全部作废，浪费纸张。• 黄金季，门店客户流量大、成单率高，每天有大量合同等着签字盖章，效率低。• 经销商遍布各地，远程签署成难题，订货、授权处理进度慢，服务体验不佳。电子签署：• 客户通过微信小程序一键选车下单，第一时间签合同，提升门店成单率。• 提供合同电子模板，在线便捷编辑、共享，一键套用成文，随需应用，零纸张。• 无论试驾还是买车，无需到场，通过小程序在线申请，远程签署合约，高效办理。• 经销商在线申请订货，审批后快速签订电子合同及订单，供货更及时。1）预约试驾文件将电子签章与汽车4S店微信小程序或者销售APP无缝集成，实现客户、业务员在线预约安排试驾、一键生成试驾协议，双方在线签署，实现远程预约。例如：业务人员通过销售APP或者客户直接通过微信小程序自助预约试驾，上报试驾信息，手机端移动签署协议，高效办理预约。（在线发起试驾，业务人员签字确认）（客户移动签署）2）客户及员工购车文件▶ 客户购车：帮助对接销售小程序或者网上销售平台，完善购车线上签约功能，客户实名认证，在线选定车型、填报个人信息，即可发起购车合同签署，领导随时随地移动签署，2小时内办理，下单更及时。▶ 员工优惠购车：针对车企内部员工的优惠购车，可以将电子签章对接到业务软件，员工自助在线申请，审核后自动调取模板生成优惠购车协议，实名认证签署，在线缴费、获取加盖电子印章缴费通知单，提升内部优惠购车处理效率。例如：员工信息审核通过，在线电子签名，公司可以定期批量完成合同盖章，统一处理、提升审核进度。3）经销商代理分销业务文件4S店以及特约店通过小程序等订货窗口，实名认证发起代理或者订货申请，车企审批后手机端远程签署授权协议以及订货单，定期在线发起对账结算通知，高效电子签署确认，提升经销商服务效率。例如：▶ 经销商结算通知单车企定期要和经销商对账、结算，全国的经销商都要一一起草单据，快递过去，签字确认后采购结算，不仅周期长成本高，一旦出现冒签，追责收款难。现在，车企财务人员通过业务系统调用契约锁模板，一键生成对账单、结算单文件，定期批量发起签署，经销商远程查收、电子签名确认，全程无纸化，更高效。（在线签署结算单）▶ 经销商订车折让协议经销商折扣类文件的“报价、折扣、服务条款等”信息常常修改频繁，纸质合同反复快递确认、修改麻烦，容易丢失甚至被篡改，溯源难。现在，经销商可以通过业务系统自助发起折扣订车申请，企业审核通过后，经销商自动盖章、签字，经办人以及车企审核后签字、批量盖章，高效处理代理订车业务，提升服务效率。例如：>>>客户案例：苏州广隆集团用“1”个印控中心，让“6家”4S店统一用章▮▮▮零部件采购文件：文件类型：价格协议、退补差价协议、采购订单、采购合同、招投标文件、结算单等汽车制造中各类零部件需要全国范围招标采购，和各地供应商签合同、确认订单、单据成难题。>>>解决方案：契约锁帮助集成OA、SRM管理软件，在汽车零部件采购业务中实现“供应商身份认证、合同及单据文件预设电子模板、供应商及车企远程签字盖章”，省去打印、快递的麻烦，批量高效处理与全国数百家供应商签署工作。纸质签署 VS 电子签署纸质签署：• 每年采购招标文件高达数十万份，用纸-打印-邮寄成本高。• 精密零部件材料种类多，合同文件样式复杂，起草中要花大量时间沟通确认内容，期间反复修改耗费大量时间，签署周期长。• 采购文件堆积严重，长期管理成本高，后期查询难。• 全国数百家供应商身份远程确认难，如果发生变更又没及时标记更新，合同难免填错信息，要反复修改，此外，冒签、篡改风险难防。电子签署：• 在线批量发起签署，全国数百家供应商，1天内在线完成签署。• 电子模板支持统一编辑和管理，各类原材料采购文件模板共享使用，一键生成文件，无需人工审核，高效、规范起草文件。• 所有合同、单据文件自动归档保存，线上即可检索。• 供应商信息统一录入系统，一键通知实名认证，确保信息准确，同时，签署中自动进行真实意愿核验，确保本人签署，有效仿冒签。1）采购合同及订单电子签对接汽车制造商SRM等业务软件，借助外部供应商门户打造面向外部零部件供应商的电子签约、数字身份认证平台，采购订单、采购合同等文件通过业务系统发起签署流程，待签消息自动同步到供应商门户，双方在线即可高效对接，2小时内完成签署。（采购合同电子签章场景）例如：· 在订单管理系统调用接口发起签署流程。（业务系统调用接口发起签署）· 零部件厂商通过供应商门户在线签署电子印章。（在线调用电子印章）>>>点击下方文字，查看更多零部件招采电子签方案：您的组织离真正高效的“采购”，只差一套电子签系统国务院推进电子签章在招投标领域应用，实现招投标全流程电子化2）材料退差价协议文件电子签汽车零部件等生产材料价格呈周期性变动，每个周期汽车制造厂商都要和零部件厂商重新签订价格协议以及退差价协议，增加了签署工作量和成本。契约锁帮助集成采购系统与车企内部ERP软件打通，支撑采购补退差价业务全过程中的“价格协议、结算单、明细表”在线签署需求，1天内远程完成差价补退和订单结算。业务人员在采购系统中发起新价格协议签署流程，自动套用模板生成协议文件，并通知供应商线上签署，业务系统内采购结算价格自动根据已签协议更新，生成最新结算单，一条流程驱动退差价、结算办理。（零部件采购补退差价文件签署场景）>>>客户案例：一汽解放汽车打造电子印控中心，助力采购业务全程电子化汉德车桥引入电子签，推动采购-营销-规划-售后-人事业务全程数字化转型▮▮▮物流仓储文件文件类型：商品车委托运输交接确认单、物流单据、到货签收单、送货单、调度单、入库单、验收单等>>>解决方案：对接仓储及物流管理系统，汽车制造商、物流承运方以及经销商接车员、仓储员在线对接，高效完成货运单签署，运单状态、签署状态同步更新、单据自动归档，确保签署可查、高效、安全。（物流单据在线签署场景）纸质签署 VS 电子签署纸质签署：• 纸质单据数量多且易丢失、损坏，管理难度大。• 货运单作为司机结算的重要凭证，不仅要随车携带，同时还要仓储、接车员签字确认，不仅等人签署麻烦，还容易丢。电子签署：• 所有货运单电子化，在线生成、签署，自动存档。• 订单发货后，物流方在线创建运单，司机、特约店接车员、仓储人员在线获取运单，验货后电子签名确认，提升结算效率。>>>点击下方文字查看详细方案：物流行业电子签署方案：平台、网点、司机、货主线上签，降本增效快一步▮▮▮融资租赁文件文件类型：征信授权书、融资租赁协议、贷款合同等通过金融租赁平台分期付款购车的用户，在购车时需要通过金融租赁平台与银行签订贷款合同。>>>解决方案：针对当前流行的金融租赁购车业务，契约锁支持集成金融租赁平台，为金融租赁提供用户身份认证、电子签署以及数据存证支持。融资平台每天数百份协议，几分钟内批量完成内部盖章，银行及客户短信链接移动签署，再也不用一一通知，全面提升购车体验。纸质签署 VS 电子签署纸质签署：客户上报纸质申请材料后，平台线下草拟纸质合同并寄往银行盖章，签署结束后才能收回并二次寄往客户，多次周转，成本高，办理周期长。电子签署：客户用手机随时上报材料，平台审核后，自动驱动银行及客户签署，1天内完成办理，全程可信数字身份保障，零纸张、零快递。▮▮▮售后服务文件：文件类型：接车检查表、售后委托协议、电子结算单、维修维保协议、延保服务协议、维修任务委托书>>>解决方案：维修、改装等各类售后服务所需文件，通过业务系统在线发起，契约锁提供电子模板、电子签署支持，客户、门店线上2分钟内完成签署。支持一键查看保修期，到期自动提醒，帮助提升售后服务质量，提升满意度。纸质签署 VS 电子签署纸质签署：• 纸质服务协议易丢、易损坏，时间一长就找不到了，客户体验不佳。• 保修期是否到期全靠客户自己发现、延保必须实地办理，超期延保麻烦。电子签署：• 延保协议等售后服务单据电子化，下发客户账号，随时查询、下载。• 借助签署时间设置，保修期到期自动提醒，及时在线延保，智能化、更便捷。▮▮▮总结：“签字、盖章”电子化已经成为各行业组织数字化转型的重要基础工作之一。汽车等规模庞大行业组织，通过电子签章的应用可以极大优化内部签署成本，简化业务签署流程，推动上下游产业链签署效率，促进行业合规、高效服务客户。

[中国，东莞，2022年1月29日] 近日，华润电力控股有限公司（以下简称“华润电力”）与华为数字能源技术有限公司（以下简称“华为数字能源”）在东莞签署战略合作框架协议。根据协议，双方将基于能源和电力、信息和通信技术行业，围绕能源项目落地、光伏电站智能大数据平台、智慧电厂、数字化转型、储能系统和集成方案、联合创新和智能安全及通信等领域开展全方位合作，通过发展清洁能源与推动能源数字化、智能化，为早日实现“碳中和”贡献力量。华润电力与华为数字能源签署战略合作框架协议华润电力党委书记、总裁史宝峰，华润电力副总裁、华南大区总经理后永杰，华润电力技术创新分管负责人卜宪斗，华为公司高级副总裁、华为数字能源技术有限公司总裁侯金龙，华为数字能源技术有限公司副总裁、首席战略官张峰等一行出席活动并见证签约。华润电力副总裁许洪波，华为数字能源技术有限公司中国区总裁周建军代表双方签约。华润电力党委书记、总裁史宝峰表示，华为是全球领先的信息与通信技术解决方案供应商，双方基础牢固、优势互补。华润电力将充分发挥企业特点及项目运营优势，与华为数字能源创新发展，加快清洁能源、综合能源的规模布局和技术进步，树立行业标杆，推动行业进步，为实现“碳达峰”、“碳中和”作出贡献。华为公司高级副总裁、华为数字能源技术有限公司总裁侯金龙表示，华润电力与华为有很好的历史合作基础，双方的产业发展体系高度互补，战略高度协同。华为数字能源将发挥融合数字技术与电力电子技术的优势，助力华润电力加快清洁能源规模化发展，加强综合能源服务布局，共同推进产业升级，共建绿色美好未来。

参与活动前请先报名华为伙伴暨开发者大会技术前瞻【点击报名】>>>点击前往瓜分300+份华为周边 IoT专属活动请点击前往>>【华为伙伴暨开发者大会2022】IoT积分夺宝活动，玩学练一体赢开发板活动奖励：奖励一：勇往直前进阶等级 LV+1 级奖励二：在所有完成技术宝典任一任务的用户中抽取40个幸运奖，奖品为文件收纳包。 活动时间：5月23日-6月30日 参与方式：开发者需按照附件文档操作指导手册完成实验，并根据指导手册截图说明将2张实验结果截图回复至本活动帖内视为完成任务，截图需要显示自己的华为云账号及命令数据，回帖示例如下：华为云账号：XXXXXX（需要写在帖子内）打卡截图1：打卡截图2： 活动规则：1. 回复非示例要求图片或其他无效信息，视为无效楼层，并取消抽奖资格。2. 全部活动结束后，将符合抽奖条件的用户名单导入至巨公摇号平台（https://www.jugong.wang/random-portal/）内，抽取40个幸运奖，并截屏公示抽奖过程。如您不同意此抽奖规则，请勿参加本次活动。 Tips：1、请务必使用个人账号参与活动（IAM、企业账号等账号参与无效）。2、所有获得奖项的获奖用户，请于获奖后3日内完成实名认证，否则视为放弃奖励。3、收货信息填写说明：1）为保证您顺利领取活动奖品，请您提前填写奖品收货信息，如您没有填写，视为放弃奖励。收货信息请【点击此处填写】2）填写时间截至2022年7月10日3）在华为伙伴暨开发者社区活动中完成一次填写即可。我们最终将会按照您填写的信息发放奖励。4、活动规则请戳https://bbs.huaweicloud.com/forum/thread-180208-1-1.html 

物联网曾被认为是继计算机、互联网之后，信息技术行业的第三次浪潮。随着基础通讯设施的不断完善，尤其是 5G 的出现，进一步降低了万物互联的门槛和成本。物联网本身也是 AI 和区块链应用很好的落地场景之一，各大云服务商也在纷纷上架物联网平台和服务。物联网通讯是物联网的一个核心内容，目前物联网的通讯协议并没有一个统一的标准，比较常见的有MQTT、CoAP、DDS、XMPP 等，在这其中，MQTT（消息队列遥测传输协议）应该是应用最广泛的标准之一。目前，MQTT 已逐渐成为 IoT 领域最热门的协议，也是国内外各大物联网平台最主流的传输协议，阿里云 IoT 物联网平台很多设备都是通过 MQTT 接入。1、MQTT 简介《MQTT 协议规范中文版》一书中对 MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）进行了描述：MQTT 是一种基于客户端服务端架构的发布/订阅模式的消息传输协议。它的设计思想是轻巧、开放、 简单、规范，易于实现。这些特点使得它对很多场景来说都是很好的选择，特别是对于受限的环境如机器与机器的通信（M2M）以及物联网环境（IoT）。----MQTT 协议中文版与 HTTP 协议一样，MQTT 协议也是应用层协议，工作在 TCP/IP 四层模型中的最上层（应用层），构建于 TCP/IP协议上。MQTT 最大优点在于，可以以极少的代码和有限的带宽，为连接远程设备提供实时可靠的消息服务。作为一种低开销、低带宽占用的即时通讯协议，使其在物联网、小型设备、移动应用等方面有较广泛的应用。如今，MQTT 成为了最受欢迎的物联网协议，已广泛应用于车联网、智能家居、即时聊天应用和工业互联网等领域。目前通过 MQTT 协议连接的设备已经过亿，这些都得益于 MQTT 协议为设备提供了稳定、可靠、易用的通信基础。2、MQTT 的主要特性MQTT 协议是为工作在低带宽、不可靠网络的远程传感器和控制设备之间的通讯而设计的协议，它具 有以下主要的几项特性：①、使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合。②、基于 TCP/IP 提供网络连接。主流的 MQTT 是基于 TCP 连接进行数据推送的，但是同样也有基于 UDP 的版本，叫做 MQTT-SN。③、支持 QoS 服务质量等级。根据消息的重要性不同设置不同的服务质量等级。④、小型传输，开销很小，协议交换最小化，以降低网络流量。这就是为什么在介绍里说它非常适合"在物联网领域，传感器与服务器的通信，信息的收集"，要知道嵌入式设备的运算能力和带宽都相对薄弱，使用这种协议来传递消息再适合不过了，在手机移动应用方面，MQTT 是一种不错的 Android 消息推送方案。⑤、使用 will 遗嘱机制来通知客户端异常断线。⑥、基于主题发布/订阅消息，对负载内容屏蔽的消息传输。⑦、支持心跳机制。3、MQTT 历史MQTT 协议最初版本是在 1999 年建立的，该协议的发明人是的 Andy Stanford-Clark 和 Arlen Nipper。MQTT 最初是用于石油管道的传感器与卫星之间数据传输。他们当时正在开发一个利用卫星通讯监控 输油管道的项目，为了实现这个项目要求，他们需要开发一种用于嵌入式设备的通讯协议，这种通讯协议必须满足以下条件：⚫ 易于实现，服务器必须要实现成千上万个客户端的接入⚫ 数据传输的服务质量可控，根据数据的重要性和特性，设置不同等级的服务质量⚫ 占用带宽小，单次数据量小，但不能出错⚫ 必须能够适应高延迟、掉线、断网等网络通信不可靠的风险⚫ 设备连接状态可知，云端与设备端保持长连接通过以上几个条件可知：⚫ MQTT 服务器可以连接大量的远程传感器和控制设备，与远程客户端保持长连接，具有一定的实 时性。⚫ 云端向设备端发送消息，设备端可以在最短的时间内接收到并作出回应。⚫ MQTT 更适合需要实时控制的场合，尤其适合执行器。⚫ 云端与客户端需要保持长连接，要能够获取到设备的连接状态，就需要时不时地发送心跳包，这就不会省电，所以，MQTT 并不适合低功耗场合。可以看出，MQTT 从诞生之初就是专为低带宽、高延迟或不可靠的网络而设计的。虽然历经几十年的更新和变化，以上这些特点仍然是 MQTT 协议的核心特点。但是与最初不同的是，MQTT 协议已经从嵌入式系统应用拓展到开放的物联网（IoT）领域。4、MQTT 版本目前 MQTT 主流版本有两个，分别是 MQTT3.1.1 和 MQTT5。MQTT3.1.1 是在 2014 年 10 月发布的，而 MQTT5 是在 2019 年 3 月发布的。虽然 MQTT3.1.1 与 MQTT5 在时间相差了将近五年，但是 MQTT3.1.1作为一个经典的版本，目前仍然是主流版本，能够满足大部分实际需求。MQTT5 是在 MQTT3.1.1 的基础上进行了升级，因此 MQTT5 是完全兼容 MQTT3.1.1 的。而 MQTT5 是 在 MQTT3.1.1 的基础上添加了更多的功能、补充完善 MQTT 协议。5、MQTT 协议MQTT 是一种基于客户端-服务端架构（C/S）的消息传输协议，所以在 MQTT 协议通信中，有两个最为重要的角色，它们便是服务端和客户端。1）服务端MQTT 服务端通常是一台服务器（broker），它是 MQTT 信息传输的枢纽，负责将 MQTT 客户端发送来的信息传递给 MQTT 客户端；MQTT 服务端还负责管理 MQTT 客户端，以确保客户端之间的通讯顺畅，保证 MQTT 信息得以正确接收和准确投递。2）客户端MQTT 客户端可以向服务端发布信息，也可以从服务端收取信息；我们把客户端发送信息的行为称为 “发布”信息。而客户端要想从服务端收取信息，则首先要向服务端“订阅”信息。“订阅”信息这一操作 很像我们在使用微信时“关注”了某个公众号，当公众号的作者发布新的文章时，微信官方会向关注了该公众号的所有用户发送信息，告诉他们有新文章更新了，以便用户查看。3）MQTT 主题上面我们讲到了，客户端想要从服务器获取信息，首先需要订阅信息，那客户端如何订阅信息呢？这里我们要引入“主题（Topic）”的概念，“主题”在 MQTT 通信中是一个非常重要的概念，客户端发布信息以及订阅信息都是围绕“主题”来进行的，并且 MQTT 服务端在管理 MQTT 信息时，也是使用“主题”来控制的。客户端发布消息时需要为消息指定一个“主题”，表示将消息发布到该主题；而对于订阅消息的客户端 来说，可通过订阅“主题”来订阅消息，这样当其它客户端或自己（当前客户端）向该主题发布消息时，MQTT 服务端就会将该主题的信息发送给该主题的订阅者（客户端）。服务端如何通过“主题”来控制客户端之间的信息通讯，看下图实例：在以上图示中一共有三个 MQTT 客户端，它们分别是开发板、手机和电脑。MQTT 服务端在管理 MQTT通信时使用了“主题”来对信息进行管理。比如上图所示，假设我们需要利用手机和电脑获取开发板在运行过程中 SoC 芯片的温度，那么首先电脑和手机这两个客户端需要向 MQTT 服务器订阅主题“芯片温度”；接下来，当开发板客户端向服务端的“芯片温度”主题发布信息（假设信息的内容就是当前的温度值）后，服务端就会首先检查都有哪些客户端订阅了“芯片温度”这一主题的信息，而当它发现订阅了该主题的客户端有一个手机和一个电脑，于是服务端就会将刚刚收到的“芯片温度”信息转发给订阅了该主题的手机和电脑客户端。通过以上的这种实例，手机和电脑便可以获取到开发板运行时 SoC 芯片的温度值。以上实例中，开发板是“芯片温度”主题的发布者，而手机和电脑则是该主题的订阅者。值得注意的是，MQTT 客户端在通信时，角色往往不是单一的，一个客户端既可以作为信息发布者也 可以同时作为信息订阅者。如下图所示：上图中的所有客户端都是围绕“LED 控制”这一主题进行通信。此时，对于“LED 控制”这一主题来 说，手机和电脑客户端成为了 MQTT 信息的发布者而开发板则成为了 MQTT 信息的订阅者（接收者）。所以由此可知，针对不同的主题，MQTT 客户端可以切换自己的角色，它们可能对主题 A 来说是信息发布者，但是对于主题 B 就成了信息订阅者，所以一个 MQTT 客户端它的角色并不是固定的，所以大家一定要理解“主题”这个概念。4）MQTT 发布/订阅特性从以上实例我们可以看到，MQTT 通信的核心枢纽是 MQTT 服务端，它负责将 MQTT 客户端发送来的信息传递给 MQTT 客户端，还负责管理 MQTT 客户端，以确保客户端之间的通讯顺畅，保证 MQTT 信息得以正确接收和准确投递。正是因为有了服务端对 MQTT 信息的接收、储存、处理和发送，客户端在发布和订阅信息时，可以相 互独立、且在空间上可以分离、时间上可以异步，这就是 MQTT 发布/订阅的特性：客户端相互独立、空间上可分离、时间上可异步，具体介绍如下：⚫ 客户端相互独立：MQTT 客户端是一个个独立的个体，它们无需了解彼此的存在，依然可以实现信息交流。⚫ 空间上分离：空间上分离相对容易理解，MQTT 客户端以及 MQTT 服务端它们在通信时是处于同一个通信网络中的，这个网络可以是互联网或者局域网；只要客户端联网，无论他们远在天边还是近在眼前，都可以实现彼此间的通讯交流；其实网络通信本就是如此，所以并不是 MQTT 通信所特有的。⚫ 时间上可异步：MQTT 客户端在发送和接收信息时无需同步。这一特点对物联网设备尤为重要，前面我们也介绍了，MQTT 从诞生之初就是专为低带宽、高延迟或不可靠的网络而设计的，高延迟和不可靠网络必然就会导致时间上的异步；物联网设备在运行过程中发生意外掉线是非常正常的情况。6、总结向大家介绍了 MQTT 通信的基本原理，在 MQTT 通信中，1 个服务端、多个客户端之间围绕“主题”进行了通信，所以重要在于大家需要理解各个客户端的相互关系以及服务端在其中所起的作用，并且理解“主题”这个概念以及 MQTT 发布/订阅模式的特性，后面向大家介绍具体的通信过程时，要迅速的反应过来。注意：对于 MQTT 发布/订阅模式的特性，我们总结的几个特点中都有一个“可”字。这 个“可”字意味着客户端彼此之间可以独立，空间可以分离，时间可以异步。在我们实际应用中，客户端之间的关系既可以独立也可以相互依存。在空间上，既可以相距甚远，也可以彼此相邻。在时间上，既可以异步也可以同步。这个“可”字所体现的是 MQTT 通讯的灵活性。————————————————原文链接：https://blog.csdn.net/yangxueyangxue/article/details/122654426

TCP 特性1.确认应答机制 (ACK)2.超时重传3.1建立连接 - 三次握手 ▲3.2.断开连接 - 四次挥手 ▲1.确认应答机制 (ACK)确认应答是可靠传输的最核心机制接收方反馈一个应答报文(ACK)，表示已收到假设现在 A 想去 B 家里玩游戏，于是 A 给 B 发消息，若消息没有出现错误且顺序正确结果如下所示:但网络传输比较复杂，可能存在一种情况"后发先至"由于数据的长度不同或者传输网络不同，先发送的数据不一定先到达，接收方接收到的数据可能是乱序的，如图：当 B 回复 A 的消息时，若存在对应关系，那么即使出现了"后发先至"的情况，也能顺利的确立应答上述方法，虽然可以顺利的确立应答，但额外的信息很多，占用的带宽很多下面如图，针对发送的请求进行编号，应答的时候也针对编号进行应答，这样既能保证数据传输没有歧义，也不会浪费太多的空间和带宽序号和确定序号，在前面 TCP报文格式中提到过上述情况不严谨，真实的 TCP 还不一样，TCP 是面向字节流的，此处的编号并不是按照一条两条来编的，而是按照字节来编号的 (每个字节有一个编号)确认应答是一种特殊的报文(ACK)，所谓的应答报文，本质上就是 ACK 字段为1 的报文，此时报头中的"确认序号"字段才是生效的初始序号是随机的，为了防止网络攻击；如果发送多个数据，每个数据都会带着一个序号接收方收到数据后，是知道数据所带着的序号的，根据序号给出确认序号(告诉发送方下次给我发的序号)，发送给发送方，发送方就知道接收方收到了哪些数据2.超时重传确认应答是比较理想的情况，但数据在传输过程中，可能是会丢包的仍以上面例子为例，A 给 B 发消息，你在家嘛？等了很久，A 也没收到 B 的消息，此时，存在以下几种情况：① B 不想回 A 的消息② B 没收到 A 的消息 (丢包情况1: 发的请求丢失)③ B 回复了消息，但 A 没收到 (丢包情况2: 应答的 ACK 丢失)②③情况：丢包的两种情况，对于发送方来说无法确定是哪种情况，因此，进行统一处理：当发送了一条数据之后，TCP 内部就会自动启动一个定时器，达到一定时间也没收到 ACK，定时器就会自动触发重传消息的动作 —— 超时重传①情况：思考：假设第二次重发没有成功，那么就存在两个超时时间 t1，t2 如图所示：那么，t1 和 t2 时间一样长吗？？在 TCP 中，t2 会比 t1 更长TCP 抱着一种 “悲观的态度”，当一次丢包重传之后，TCP 就觉得大概率后面的重传也没用，所以就隔一个更长的时间，节省带宽上述丢包有两种情况，一种是请求丢失 —— 重传没有问题；一种是 ACK 丢失，重传就意味着接收方收到了相同的数据TCP 会在内部进行数据去重 (以序号为 key 进行去重)，保证应用层读到的数据不是重复数据确认应答 和 超时重传是 TCP 可靠性中最核心的机制3.1建立连接 - 三次握手 ▲为什么要就建立连接？1.更好的保证可靠性: 建立连接的过程其实就是让通信双方验证各自的发送能力和接受能力是否正常2.协商一些重要参数 (如: 序号的初始值)具体怎样建立连接？举例：A 给 B 打电话，打电话同样要验证自己以及对方的话筒和听筒是否正常工作第一次握手： 刚开始，A 不知道自己和 B 手机的听筒和话筒是否正常，所以 A说"喂，你能听到吗?"第二次握手： B 听到后，说明 A 的话筒和 B 的听筒正常，但 B 还需进一步检查自己的话筒和 A 的听筒是否正常；同时 B 把 A 话筒正常和自己听筒正常的消息传递给 A；于是 B “我能听到，你呢？”第三次握手： A 收到 B 的消息后，就证明了 A 听筒正常，B 话筒正常以上三次握手就保证了 A、B 的听筒和话筒都正常，也就保证了通话的正常，这就类似于网络建立连接时的三次握手TCP 中真实的建立连接过程： (假设主机 A 主动发起连接)第一次握手： 客户端向服务器发送 SYN 报文 (SEQ=x，SYN=1)，并进入 SYN_SENT 状态，等待服务器确认第二次握手： 实际上是分两部分来完成的，即 SYN+ACK (请求和确认) 报文服务器收到了客户端的请求，向客户端回复一个确认信息 (ack=x+1)服务器再向客户端发送一个 SYN 包 (SEQ=y)建立连接的请求，此时服务器进入 SYN_RECV 状态第三次握手： 客户端收到服务器的回复 (SYN+ACK 报文0)；此时，客户端也要向服务器发送确认包 (ACK)；此包发送完毕客户端和服务器进入 ESTABLISHED 状态，完成 3 次握手建立连接的过程，相当于通信双方各自给对方发送 SYN，在各自给对方发送给 ACK，只不过中间的 ACK 和 SYN 合二为一了，于是最后就是"三次握手"几个重要的状态:LISTEN: 正在侦听来自远方的 TCP 端口的连接请求，服务端启动后处于 LISTEN 状态用于监听不同客户端的 TCP 请求并建立连接SYN_SEND / SYN_RCVD: 建立连接的中间过程，若连接顺利的话(建立连接过程也可能丢包)，这两个状态就一瞬消失ESTABLISHEN: 连接建立完毕 (验证了通信双方的发送和接受能力都正常)，可以进行数据传输1.两次握手可以吗？？不可以防止已失效的请求报文又传送到了服务端，建立了多余的链接，浪费资源两次握手只能保证单向连接是通畅的 (为了实现可靠数据传输， TCP 协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的；三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤；如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认）.2.为什么是三次？？主要是为了建立可靠的通信通道，保证客户端与服务端同时具备发送、接收数据的能力.3.四次握手可以吗？？可以，但没必要四次握手可以验证双方的发送接收能力正常，但是这样做效率比较低.3.2.断开连接 - 四次挥手 ▲三次握手: 双方各自向对方发起建立连接的请求，再各自给对方回应，只不过，中间的 SYN 和 ACK 能合并在一起四次挥手: 双方各自向对方发起建立连接的请求，再各自给对方回应，只不过，中间的 FIN 和 ACK 不一定能合并在一起仍以打电话为例，如下图：TCP 中真实的断开连接过程： (假设主机 A 主动断开连接)第一次挥手: 客户端向服务器端发送断开 TCP 连接请求的 [FIN，ACK] 报文，在报文中随机生成一个序列号 SEQ=u，表示要断开 TCP 连接此时，客户端进入FIN_WAIT_1 (终止等待1) 状态第二次挥手: 当服务器端收到客户端发来的断开 TCP 连接的请求后，回复发送 ACK 报文，表示已经收到断开请求。回复时，随机生成一个序列号 SEQ=v；由于回复的是客户端发来的请求，所以在客户端请求序列号 SEQ=u 的基础上加 1，得到 ack=u+1此时，服务端就进入了CLOSE_WAIT (关闭等待) 状态，客户端收到ACK后，就进入FIN_WAIT_2 (终止等待2) 状态第三次挥手: 服务器端在回复完客户端的 TCP 断开请求后，不会马上进行 TCP 连接的断开。服务器端会先确认断开前，所有传输到客户端的数据是否已经传输完毕。确认数据传输完毕后才进行断开，向客户端发送 [FIN，ACK] 报文，设置字段值为 1。再次随机生成一个序列号 SEQ=w；由于还是对客户端发来的 TCP 断开请求序列号 SEQ=x 进行回复，因此 ack 依然为 x+1此时，服务器就进入了LAST_ACK (最后确认) 状态第四次挥手: 客户端收到服务器发来的 TCP 断开连接数据包后将进行回复，表示收到断开 TCP 连接数据包。向服务器发送 ACK 报文，生成一个序列号 SEQ=u+1；由于回复的是服务器，所以 ACK 字段的值在服务器发来断开 TCP 连接请求序列号 SEQ=w 的基础上加 1，得到 ack=w+1此时，客户端就进入了TIME_WAIT (时间等待) 状态；注意此时TCP连接还没有释放，必须经过2MSL (最长报文段寿命) 的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态两个重要的状态:CLOSE_WAIT: 表示在等待关闭； 四次挥手挥了一半了，当前可能剩下的两次不挥了(接收方没调用 close 方法，就会导致四次挥手只挥两次，从而没有正确关闭连接)TIME_WAIT: 谁主动断开连接，谁进入 TIME-WAIT 状态，此时该主机已经完成了四次挥手的过程，但仍不能立刻断开连接，而是要以 TIME-WAIT 状态来保持连接一段时间之后，再彻底释放连接 (处理最后一个 ACK 丢包之后重传的问题)为了解决网络的丢包和网络不稳定所带来的其他问题，确保连接方能在时间范围内，关闭自己的连接1.四次挥手，三次挥完行不行？？通常情况下不行，若触发了延时应答机制，就可以三次挥完"不行"，即：上述的 ② ③ 为什么没有合并在一起？？因为中间两次操作的时机不一样ACK 是收到 FIN 之后立刻由内核返回的数据报，FIN 是应用程序处理完接受缓冲区的数据之后，调用的 close 方法触发的.2.为什么四次？？因为要确保客户端和服务端的数据能够完成传输.3.为什么 TIME_WAIT 状态要等待 2MSL？？假设网络上传输数据的最大时间为 MSLMSL 就是 ACK / FIN 从主机 A 到主机 B 的最大时间TIME-WAIT 等待时间，需要分成两个部分：①等待 ACK 经历一个最大时间到达主机 B②万一 ACK 丢了，在等待一个最大时间，主机 B 重传 FIN 到达主机 A因此，TIME_WAIT 就需要等待 2倍的MSL，即：2MSL原因：确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接第四次挥手时，客户端第四次挥手的 ACK 报文不一定会到达服务端；服务端会超时重传 FIN / ACK 报文，此时如果客户端已经断开了连接，那么就无法响应服务端的二次请求，这样服务端迟迟收不到 FIN / ACK 报文的确认，就无法正常断开连接MSL 是报文段在网络上存活的最长时间，客户端等待 2MSL 时间，即「客户端 ACK 报文 1MSL 超时 + 服务端 FIN 报文 1MSL 传输」，就能够收到服务端重传的 FIN / ACK 报文，然后客户端重传一次 ACK 报文，并重新启动 2MSL 计时器；如此保证服务端能够正常关闭如果服务端重发的 FIN 没有成功地在 2MSL 时间里传给客户端，服务端则会继续超时重试直到断开连接防止已失效的连接请求报文段出现在之后的连接中TCP 要求在 2MSL 内不使用相同的序列号；客户端在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以保证本连接持续的时间内产生的所有报文段都从网络中消失；这样就可以使下一个连接中不会出现这种旧的连接请求报文段；或者即使收到这些过时的报文，也可以不处理它————————————————版权声明：本文为CSDN博主「一朵花花」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/m0_47988201/article/details/122308667

北京冬奥会上，中国运动员们努力奋战，技惊四座，目前已摘得3金2银5块奖牌，让国人为之骄傲。其实在正式开始比赛之前，奥运村的各种黑科技服务同样“技惊四座”，让各国运动员惊叹不已，纷纷全网刷屏点赞。就连美国的运动员入住奥运村，也被智能床深深震撼住了，拍摄的一条短视频获赞近百万。还有美媒感叹称：冬奥会的餐厅场景就像一部科幻电影。加拿大媒体人也被送餐机惊到了，表示“这项技术令人难以置信！”给各国运动员带来震撼的，远不止一张智能床，在本次冬奥会的衣食住行各方面的服务上，都让各国运动员震惊不已。美食“从天而降”！“大厨”24小时待命……冬奥村的无人餐厅集合了多种高新科技，从你进入餐厅扫二维码点餐开始，所有的步骤都没有真人参与，可以实现24小时营业，并提供可口的饭菜。图源：CCTV2餐厅有两种不同的上菜系统。没有汤水的菜肴会通过顶部云轨系统传输到顾客面前，而带有汤水的菜肴考虑到溅洒的风险，由地面传输机器人进行运送。这个“智慧餐厅”技术，总体上是机器人、物联网和云计算的集合体。现有的技术实现这一系列操作并不复杂，但是让每一道菜都保持美味可口，则绝对是技术和艺术的深刻融合。360度VR全景式直播！“沉浸式”观看比赛……VR（virtual reality）虚拟现实技术更是360度的应用在了冬奥会上，从运动员的训练，到场馆的虚拟导览，再到全景直播。看比赛直播画面，不用“导播切到什么，大家只能看什么”了。VR技术用高精度扫描和摄像工具进行三维重建和渲染构建VR场景，观众可以根据自己的喜好选择不同的观赛视角，极大地提升了观赛体验。此外，这项技术可以帮助运动员多角度复盘比赛的操作细节，还可以帮助裁判员进行快速和准确的判罚。创可贴实现实时测温只有创可贴大小的作为内置北京芯的可穿戴式连续监测体温设备，贴在腋下就可以实现体温的实时监测与3秒一次的自动上报。图源：北京卫视这项技术是由温度传感器、无线传输装置和电池组成，原理上并不难。但因为只有创可贴大小，很多科技成果要想实现微小化本身就极具难度，同时还要保持相当精准度，更是难上加难。北京冬奥会是一场“宝藏”科技的盛宴，各种频频震惊各国运动员的黑科技的背后，是中国物联网产业的弯道超车。自2008年“智慧地球”提出以来，物联网概念在全球范围内迅速被认可，并成为新一代信息技术的发展方向。如今，物联网连接数实现爆发式增长，据GSMA(全球移动通信系统协会）预计，2018-2025年全球物联网设备连接数的复合增长率为15.66%，预计2025年将达到252亿台。中国是物联网技术的一个巨大市场，虽然我国的物联网2009年才开始进入培育期，起步相对较晚，但近年来在“中国制造2025”、“互联网+双创”等计划的带动下，中国物联网取得长足进步，与物联网相关的产品开始在企业、家庭和个人层面大规模使用，整个行业有从成长期向成熟期过渡的趋势。近年来，中国物联网产业发展不断有新的技术涌现，助推行业快速向前发展。2016年，深圳物芯科技控股集团推出完全自主知识产权的无线组网协议——ADC去中心化协议，填补了中国在自主组网协议领域上的空白。ADC去中心化协议是当今全球少数专为物联网而诞生的组网协议，打破了传统带中控的协议架构，采用 ADC协议的产品具有低成本、高可靠、传输远、可快速部署等特点。2020年，物芯科技完成ADC协议的芯片化，成为中国物联网行业第一颗内置应用场景的物联网芯片缔造者，为传统领域的企业向物联网升级转型安装引擎，为完善物联网生态提供最优解决方案。从互联网到物联网，中国逐渐从模仿者、学习者、转变为追赶者和开拓者，冬奥村各国运动员和记者对中国科技力量的赞叹，也将仅仅是一个开始，相信在未来的物联网产业的发展上，中国将扮演越来越重要的角色，直到独占行业鳌头，直到世界对中国科技力量带来的震撼变得习以为常。物联网将取代互联网成为主流物联网，被视为继互联网之后的又一次信息技术革命浪潮。物联网所带来的产业价值将比互联网大30到50倍，物联网将成为下一个万亿级别的信息产业。物联网平台已经搭建成功，进不进入决定几代人命运 , 改革是中国最大的红利国家给予利润终身分红.先知先觉领导者，先知后觉跟随者，不知不觉消费者.如果你错过了互联网千万不能再错过物联网

此网络协议栈源码分析是基于linux 1.2.13版本的内核源码进行分析的；在分析此代码的过程中，同时深入阅读了linux网络驱动和TCP-IP详解，先理解整体的网络概念和内核网络模块代码齐头并进，梳理出了如下的代码调用流程。如下的代码流程是从内核网络模块初始化，到插口层如何调用到内核的处理过程，针对流程和主要的数据体进行分析展示：start_kernel        sock_init          proto_init                  inet_proto_initstatic struct proto_ops inet_proto_ops = {        AF_INET,        inet_create,        inet_dup,        inet_release,        inet_bind,        inet_connect,        inet_socketpair,        inet_accept,        inet_getname,        inet_read,        inet_write,        inet_select,        inet_ioctl,        inet_listen,        inet_send,        inet_recv,        inet_sendto,        inet_recvfrom,        inet_shutdown,        inet_setsockopt,        inet_getsockopt,        inet_fcntl,};                        sock_register(inet_proto_ops.family, &inet_proto_ops);                              pops[i] = ops; //pops指向inet_proto_ops结构体                                   pops[i]->family = family;                        tcp_prot.sock_array                        udp_prot.sock_array                        raw_prot.sock_array                        tcp_prot.inuse = 0;                        tcp_prot.highestinuse = 0;                        udp_prot.inuse = 0;                        udp_prot.highestinuse = 0;                        raw_prot.inuse = 0;                        raw_prot.highestinuse = 0;                        inet_add_protocol(p);                              inet_protos[hash] = prot;                        arp_init();                        ip_init();          dev_init                  ethif_probe                        ne_probe(dev)                              ne_probe1(dev, base_addr);                                    request_irq (dev->irq, ei_interrupt, 0, wordlength==2 ? "ne2000":"ne1000");                                          ei_receive(dev);                                                ei_block_input(dev, pkt_len, (char *) skb->data,current_offset + sizeof(rx_frame));                                                netif_rx(skb);                                                      mark_bh(NET_BH);                                    ethdev_init(dev);                                          dev->hard_start_xmit = &ei_start_xmit;                                          dev->get_stats      = get_stats;                                          dev->hard_header        = eth_header;                                   dev->rebuild_header = eth_rebuild_header;                            dev->type_trans = eth_type_trans;                                   dev->type               = ARPHRD_ETHER;                            dev->hard_header_len = ETH_HLEN;                            dev->mtu                = 1500; /* eth_mtu */                            dev->addr_len   = ETH_ALEN;                                     /* New-style flags. */                            dev->flags              = IFF_BROADCAST|IFF_MULTICAST;                            dev->family             = AF_INET;                            dev->pa_addr    = 0;                            dev->pa_brdaddr = 0;                            dev->pa_mask    = 0;                            dev->pa_alen    = sizeof(unsigned long);                                   ei_status.reset_8390 = &ne_reset_8390;                                ei_status.block_input = &ne_block_input;                                ei_status.block_output = &ne_block_output;            bh_base[NET_BH].routine= net_bh;            enable_bh(NET_BH);net_bh      dev_transmit      //ptype_base->func = ip_rcv      pt_prev->func(skb, skb->dev, pt_prev);            ip_rcv(skb, skb->dev, pt_prev);                  ip_fw_chk                  ip_forward(skb, dev, is_frag);                  ip_acct_cnt(iph,dev, ip_acct_chain);                  ip_defrag(iph,skb,dev);//处理分片数据包                        ip_find                        ip_create(skb, iph, dev)                             ipqueue//IP fragment queue     全局队列                        ip_frag_create(offset, end, skb, ptr);                        ip_done(qp) //检测分片包是否接收完成                        ip_glue(qp); //将分片的数据包组装起来                raw_rcv //原始套接字                  ipprot->handler //网络层向传输层传输数据包                     tcp_rcv                     udp_rcv                          ip_chk_addr(daddr);                             udp_check(uh, len, saddr, daddr)                             udp_deliver(sk,uh,skb,dev, saddr, daddr, len);                                   sock_queue_rcv_skb(sk,skb).  //将数据包挂接到sk变量表示的套接字的接收队列中                                    //将数据包插入到接收队列尾部，并通知可能等待读取数据被置于睡眠的进程进行数据包的读取 sk->data_ready = def_callback2                                         //def_callback2(sk,skb->len);                                    sk->data_ready(sk,skb->len);  //Now tell the user we may have some data.                               release_sock(sk);                                         sk->prot->icv                     icmp_rcv      dev_transmitsys_socketcall      sock_socket            ops = pops[i];            sock = sock_alloc（）；                  inode = get_empty_inode(); //申请一个文件节点                  sock = &inode->u.socket_i;            sock->type = type;            sock->ops = ops;            sock->ops->create(sock, protocol)                  inet_create(sock, protocol)                        sk = (struct sock *) kmalloc(sizeof(*sk), GFP_KERNEL);           sk->num = 0;              sk->reuse = 0;           switch(sock->type)             case SOCK_STREAM:                     case SOCK_SEQPACKET:                                   protocol = IPPROTO_TCP;                 sk->no_check = TCP_NO_CHECK;                                  prot = &tcp_prot;             case SOCK_DGRAM:                protocol = IPPROTO_UDP;                sk->no_check = UDP_NO_CHECK;                prot=&udp_prot;             case SOCK_RAW:                Sk->reuse = 1;                sk->no_check = 0;                prot=&raw_prot;                sk->num = protocol;             case SOCK_PACKET:                Sk->reuse = 1;                sk->no_check = 0;                prot=&packet_prot;                sk->num = protocol;              sk->socket = sock;           sk->nonagle = 1;           sk->nonagle = 0;           sk->type = sock->type;                 sk->stamp.tv_sec=0;           sk->protocol = protocol;           sk->wmem_alloc = 0;           sk->rmem_alloc = 0;           sk->sndbuf = SK_WMEM_MAX;           sk->rcvbuf = SK_RMEM_MAX;           sk->pair = NULL;           sk->opt = NULL;           sk->write_seq = 0;           sk->acked_seq = 0;           sk->copied_seq = 0;           sk->fin_seq = 0;           sk->urg_seq = 0;           sk->urg_data = 0;           sk->proc = 0;           sk->rtt = 0;                            /*TCP_WRITE_TIME << 3;*/           sk->rto = TCP_TIMEOUT_INIT;             /*TCP_WRITE_TIME*/           sk->mdev = 0;           sk->backoff = 0;           sk->packets_out = 0;           sk->cong_window = 1; /* start with only sending one packet at a time. */           sk->cong_count = 0;           sk->ssthresh = 0;           sk->max_window = 0;               sk->urginline = 0;           sk->intr = 0;           sk->linger = 0;           sk->destroy = 0;           sk->priority = 1;           sk->shutdown = 0;           sk->keepopen = 0;           sk->zapped = 0;           sk->done = 0;           sk->ack_backlog = 0;           sk->window = 0;           sk->bytes_rcv = 0;           sk->state = TCP_CLOSE;           sk->dead = 0;           sk->ack_timed = 0;           sk->partial = NULL;           sk->user_mss = 0;           sk->debug = 0;                        sk->max_unacked = 2048;           sk->max_ack_backlog = 0;           sk->inuse = 0;           sk->delay_acks = 0;           skb_queue_head_init(&sk->write_queue);           skb_queue_head_init(&sk->receive_queue);           sk->mtu = 576;           sk->prot = prot;           sk->sleep = sock->wait;           sk->daddr = 0;           sk->saddr = 0 /* ip_my_addr() */;           sk->err = 0;           sk->next = NULL;           sk->pair = NULL;           sk->send_tail = NULL;           sk->send_head = NULL;           sk->timeout = 0;           sk->broadcast = 0;           sk->localroute = 0;           init_timer(&sk->timer);           init_timer(&sk->retransmit_timer);           sk->timer.data = (unsigned long)sk;           sk->timer.function = &net_timer;                     sk->timer.expires = 10;             add_timer(&sk->timer);           skb_queue_head_init(&sk->back_log);           sk->blog = 0;           sock->data =(void *) sk;           sk->dummy_th.doff = sizeof(sk->dummy_th)/4;           sk->dummy_th.res1=0;           sk->dummy_th.res2=0;           sk->dummy_th.res2=0;           sk->dummy_th.urg_ptr = 0;           sk->dummy_th.fin = 0;           sk->dummy_th.syn = 0;           sk->dummy_th.rst = 0;           sk->dummy_th.psh = 0;           sk->dummy_th.ack = 0;           sk->dummy_th.urg = 0;           sk->dummy_th.dest = 0;           sk->ip_tos=0;           sk->ip_ttl=64;           sk->ip_mc_loop=1;           sk->ip_mc_ttl=1;           *sk->ip_mc_name=0;           sk->ip_mc_list=NULL;           sk->state_change = def_callback1;           sk->data_ready = def_callback2;                     wake_up_interruptible(sk->sleep);             sock_wake_async(sk->socket, 1);           sk->write_space = def_callback3;           sk->error_report = def_callback1;                        //Add a socket into the socket tables by number.          put_sock(sk->num, sk);          sk->dummy_th.source = ntohs(sk->num);           err = sk->prot->init(sk);            fd = get_fd(SOCK_INODE(sock); //fd = get_fd(sock->node);                  file = get_empty_filp();           static struct file_operations socket_file_ops = {        sock_lseek,        sock_read,        sock_write,        sock_readdir,        sock_select,        sock_ioctl,        NULL,                   /* mmap */        NULL,                   /* no special open code... */        sock_close,        NULL,                   /* no fsync */        sock_fasync};             file->f_op = &socket_file_ops;        file->f_mode = 3;        file->f_flags = O_RDWR;        file->f_count = 1;        file->f_inode = inode;        inode->i_count++;        file->f_pos = 0;recvfrom      sys_socketcall            sock_recvfrom                  inet_recvfrom                        udp_recvfrom                             skb_recv_datagram                                   interruptible_sleep_on(sk->sleep);  //阻塞进程进入睡眠                               skb_copy_datagram(skb,sizeof(struct udphdr),to,copied);                               skb_free_datagram(skb);sendto      sys_socketcall            sock_sendto                  udp_sendto(sk, &sin, from, len, flags);                        udp_send(sk, &sin, from, len, flags);                             //ip_queue_xmit(sk, dev, skb, 1);                             sk->prot->queue_xmit(sk, dev, skb, 1);  //queue_xmit = ip_queue_xmit                                   ip_fw_chk                                   ip_loopback(dev,skb);                                         ip_queue_xmit(NULL, dev, newskb, 1);                                   dev_queue_xmit(skb, dev, SOPRI_NORMAL)                                   //ei_start_xmit(skb, dev)                                   dev->hard_start_xmit(skb, dev)  //dev->hard_start_xmit = &ei_start_xmit;                                   ei_start_xmit(skb, dev)read      sock_read            inet_read                  sk->prot->read //udp_read                        udp_read                             udp_recvfrom

NetCat，在网络工具中有“瑞士军刀”美誉，其有Windows和Linux的版本。因为它短小精悍（1.84版本也不过25k，旧版本或缩减版甚至更小）、功能实用，被设计为一个简单、可靠的网络工具，可通过TCP或UDP协议传输读写数据。同时，它还是一个网络应用Debug分析器，因为它可以根据需要创建各种不同类型的网络连接。一、版本通常的Linux发行版中都带有NetCat（简称nc），甚至在拯救模式光盘中也由busybox提供了简版的nc工具。但不同的版本，其参数的使用略有差异。NetCat 官方地址：http://netcat.sourceforge.net/ 引用[root@hatest1 ~]# cat /etc/asianux-releaseAsianux release 2.0 (Trinity SP2)[root@hatest1 ~]# cat /etc/redflag-releaseRed Flag DC Server release 5.0 (Trinity SP2)[root@hatest1 ~]# type -a ncnc is /usr/bin/nc[root@hatest1 ~]# rpm -q ncnc-1.10-22建议在使用前，先用man nc看看帮助。这里以红旗DC Server 5.0上的1.10版本进行简单说明。假设两服务器信息：引用server1: 192.168.228.221server2: 192.168.228.222二、常见使用1、远程拷贝文件从server1拷贝文件到server2上。需要先在server2上，用nc激活监听，server2上运行：引用[root@hatest2 tmp]# nc -lp 1234 > install.logserver1上运行：引用[root@hatest1 ~]# ll install.log-rw-r--r--   1 root root 39693 12月 20   2007 install.log[root@hatest1 ~]# nc -w 1 192.168.228.222 1234 < install.log2、克隆硬盘或分区操作与上面的拷贝是雷同的，只需要由dd获得硬盘或分区的数据，然后传输即可。克隆硬盘或分区的操作，不应在已经mount的的系统上进行。所以，需要使用安装光盘引导后，进入拯救模式（或使用Knoppix工具光盘）启动系统后，在server2上进行类似的监听动作：# nc -l -p 1234 | dd of=/dev/sdaserver1上执行传输，即可完成从server1克隆sda硬盘到server2的任务：# dd if=/dev/sda | nc 192.168.228.222 1234※ 完成上述工作的前提，是需要落实光盘的拯救模式支持服务器上的网卡，并正确配置IP。3、端口扫描可以执行：引用# nc -v -w 1 192.168.228.222 -z 1-1000hatest2 [192.168.228.222] 22 (ssh) open4、保存Web页面# while true; do nc -l -p 80 -q 1 < somepage.html; done5、模拟HTTP Headers引用[root@hatest1 ~]# nc www.linuxfly.org 80GET / HTTP/1.1Host: ispconfig.orgReferrer: mypage.comUser-Agent: my-browserHTTP/1.1 200 OKDate: Tue, 16 Dec 2008 07:23:24 GMTServer: Apache/2.2.6 (Unix) DAV/2 mod_mono/1.2.1 mod_python/3.2.8 Python/2.4.3 mod_perl/2.0.2 Perl/v5.8.8Set-Cookie: PHPSESSID=bbadorbvie1gn037iih6lrdg50; path=/Expires: 0Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0Pragma: no-cacheCache-Control: private, post-check=0, pre-check=0, max-age=0Set-Cookie: oWn_sid=xRutAY; expires=Tue, 23-Dec-2008 07:23:24 GMT; path=/Vary: Accept-EncodingTransfer-Encoding: chunkedContent-Type: text/html[......]在nc命令后，输入红色部分的内容，然后按两次回车，即可从对方获得HTTP Headers内容。6、聊天nc还可以作为简单的字符下聊天工具使用，同样的，server2上需要启动监听：[root@hatest2 tmp]# nc -lp 1234server1上传输：[root@hatest1 ~]# nc 192.168.228.222 1234这样，双方就可以相互交流了。使用Ctrl+D正常退出。7、传输目录从server1拷贝nginx-0.6.34目录内容到server2上。需要先在server2上，用nc激活监听，server2上运行：引用[root@hatest2 tmp]# nc -l 1234 |tar xzvf -server1上运行：引用[root@hatest1 ~]# ll -d nginx-0.6.34drwxr-xr-x 8 1000 1000 4096 12-23 17:25 nginx-0.6.34[root@hatest1 ~]# tar czvf - nginx-0.6.34|nc 192.168.228.222 12348、参数简介这仅是一个1.10版本的简单说明，详细的参数使用还是需要看man：引用想要连接到某处: nc [-options] hostname port[s] [ports] ...绑定端口等待连接: nc -l -p port [-options] [hostname] [port]参数:-g gateway source-routing hop point[s], up to 8-G num source-routing pointer: 4, 8, 12, ...-h 帮助信息-i secs 延时的间隔-l 监听模式，用于入站连接-n 指定数字的IP地址，不能用hostname-o file 记录16进制的传输-p port 本地端口号-r 任意指定本地及远程端口-s addr 本地源地址-u UDP模式-v 详细输出——用两个-v可得到更详细的内容-w secs timeout的时间-z 将输入输出关掉——用于扫描时，其中端口号可以指定一个或者用lo-hi式的指定范围。 9、1.84版本参数简介1. nc [-46DdhklnrStUuvzC] [-i interval] [-p source_port]2.    [-s source_ip_address] [-T ToS] [-w timeout] [-X proxy_protocol] [-x3.    proxy_address[:port]] [hostname] [port[s]]  1. -4 强制使用ipv42. -6 强制使用ipv63. -D 允许socket通信返回debug信息4.       -d 不允许从标准输入中读取5. -h 显示nc帮助文档6. -i interval 7.    指定每行之间内容延时发送和接受，也可以使多个端口之间的连接延时8. -k 当一个连接结束时，强制nc监听另一个连接。必须和-l一起使用9. -l 用于监听传入的数据链接，不能与-p -z -s一起使用。-w 参数的超时也会被忽略10. -n 不执行任何地址，主机名，端口或DNS查询11. -p 指定nc使用的源端口，受权限限制且不能余-l一起使用12. -r 指定nc使用的源端口和目的端口，不能使用系统原来就指定的那些端口13. -S 允许在RFC 2385的TCP MD5签名选项14. -s source_ip_address 15.    指定用于发包的接口的IP地址，不能和-l一起使用16. -T ToS17.    指定链接的IP服务类型（TOS）18. -C 自动换行19. -t 使nc能够与telnet交互20. -U 使用UNIX域socket21. -u 使用udp代替默认的tcp选项22. -v 输出详细报告23. -w timeout24.     一个链接一段时间无操作，则自动断开，默认无超时25. -X proxy_version26.     指定nc使用代理时所采用的协议,可选的有socksv4，socks5以及https。默认socks527. -x proxy_address[:port]28.     指定nc使用的代理地址和端口。默认设置:1080(SOCKS),3128(HTTPS)29. -z 只监听不发送任何包 三、版本差异不用系统上提供的nc版本会有说不同，其提供的参数使用方法也略有差异。例如，红旗Asianux 3.0 SP1拯救光盘上的版本是供使用的参数仅有一部分：引用# nc -hBusyBox v1.2.0 (2008.04.14-01:35+0000) multi-call binaryUsage: nc [OPTIONS] [IP] [port]Netcat opens a pipe to IP:portOptions:         -l               listen mode, for inbound connects         -p PORT         local port number         -i SECS         delay interval for lines sent         -e PROG         program to exec after connect (dangerous!)         -w SECS         timeout for connects and final net reads而在Asianux 3.0 SP1系统中提供的nc版本则是1.84的，按上面的参数用法写会执行不了：引用[root@ftpserver ~]# rpm -q ncnc-1.84-10[root@ftpserver ~]# nc -lp 1234usage: nc [-46DdhklnrStUuvzC] [-i interval] [-p source_port]           [-s source_ip_address] [-T ToS] [-w timeout] [-X proxy_version]           [-x proxy_address[:port]] [hostname] [port[s]]讲查看man文档，可见在这个版本中，-l是不能与-s、-p、-z一起使用的，-w参数也会被忽略，所以，正确的用法是：[root@ftpserver tmp]# nc -l 1234四、用在脚本中nc每次启动监听后，都会在客户端连接完成并退出的同时，服务端一同退出。所以，如果需要不断的使用nc进行数据传输，需要在脚本中使用循环。利用nc实现更多的功能，可参考其rpm提供的参考脚本：引用# rpm -qd nc/usr/share/doc/nc-1.10/Changelog/usr/share/doc/nc-1.10/README/usr/share/doc/nc-1.10/scripts/README/usr/share/doc/nc-1.10/scripts/alta/usr/share/doc/nc-1.10/scripts/bsh/usr/share/doc/nc-1.10/scripts/dist.sh/usr/share/doc/nc-1.10/scripts/irc/usr/share/doc/nc-1.10/scripts/iscan/usr/share/doc/nc-1.10/scripts/ncp/usr/share/doc/nc-1.10/scripts/probe/usr/share/doc/nc-1.10/scripts/web/usr/share/doc/nc-1.10/scripts/webrelay/usr/share/doc/nc-1.10/scripts/websearch/usr/share/man/man1/nc.1.gz转载自https://www.jb51.net/article/106898.htm

源设备满足状态目的端口协议端口说明子系统目的IPssh客户端　22TCPssh服务端口OS所有节点IPntp客户端　123UDP网络时间协议端口OS所有节点IPHTTP客户端　8080TCPWebService提供的供用户访问端口该端口用于：访问Web UI安装时是否缺省启用：是安全加固后是否启用：是ManagerWebService节点IPSNMP网管　20000UDP北向SNMP协议端口该端口用于：连接SNMP网管安装时是否缺省启用：否安全加固后是否启用：NA该端口用户可配置，范围1025~65535。在SNMP Configuration 页面下可以指定(Local port)ManagerWebService节点IPHTTP客户端　20009TCPCAS端口。该端口用于：用户登录认证安装时是否缺省启用：是安全加固后是否启用：是ManagerWebService节点IPHTTPS客户端　20026TCPHTTPD提供的web服务代理端口。该端口用于：通过代理方式访问组件Web UI安装时是否缺省启用：是安全加固后是否启用：是ManagerHTTPD节点的外部平面IPHTTPS客户端　212019190TCPHTTPD提供的HUE代理端口。该端口用于：通过代理方式访问HUE的Web UI安装时是否缺省启用：否安全加固后是否启用：是ManagerHTTPD节点的外部平面IPHTTP客户端　28443TCPWebService提供的供用户访问的端口该端口用于：访问Web UI安装时是否缺省启用：是安全加固后是否启用：是ManagerHTTPD节点的外部平面IPkerberos客户端　缺省值：21732取值范围：21730-21749UDPkerberos认证端口。（ kdc_ports）该端口用于：kerberos认证端口安装时是否缺省启用：是安全加固后是否启用：是KerberosKerberos服务端节点IPMPPDB客户端　25308TCP数据库业务连接端口（MPPDB）该端口用于：客户作业连接MPPDBCoordinate所在节点IP

1.libpq合并 数据结构设计Conn结构体作为内部接口、外部接口的参数之一，保存着连接信息，存在于通信连接的整个生命周期中，上层应用通过Conn结构体中保存的连接信息进行通信。3个模块各自定义了一个Conn结构体（CM_Conn、GTM_Conn、PGconn），libpq合并首先要解决的问题就是如何将3个Conn结构体合并。图 1 三个Conn结构体公共成员图 2 CM_Conn独有成员图 3 GTM_Conn独有成员图 4 PGconn独有成员从图 4‑10、图 4‑11、图 4‑12、图 4‑13可以看出，三个Conn结构体包含大量公共成员，只有少数成员是某个Conn结构体所特有的。因此，通过取并集的方式对三个Conn结构体进行合并，合并以后的Conn结构体命名为pg_conn，位于libpq-int.h头文件中，不对外暴露。图 5 CM_Result结构体定义图 6 GTM_Result结构体定义图 7 PGresult结构体定义Conn结构体包含的result成员与上层定义的通信协议直接相关，从图 4‑14、图 4‑15、图 4‑16中可以看出，由于3个模块各自的应用层交互协议差异很大，导致CM_Result、GTM_Result、PGresult结构体差异很大，除非统一3个模块的交互协议，否则，result结构体难以合并。通过讨论分析，统一3个模块的通信交互协议带来的收益不大，所以，Conn结构体合并以后，result成员类型定义为void，在CM模块、GTM模块、BACKEND模块中访问result成员时进行强制类型转换即可。合并以后的Conn结构体新增conn_type成员，用来标识Conn类型，如下图所示。图 8 LibpqConnType枚举类型图 9 Conn结构体使用方式如图 4‑18所示，3个模块各自的libpq-fe.h头文件中，通过typedef方式对pg_conn进行前置声明，别名分别为CM_Conn、GTM_Conn、PGconn，模块内部都以指针的方式使用Conn结构体，这样就可以在隐藏Conn结构体细节的前提下，使用Conn结构体进行通信。