• [技术干货] 物联网通讯协议里面WIFI、蓝牙、ZigBee都有哪些优劣势
    虽说目前物联网处于发展阶段,但是目前已经有越来越多的智能终端设备慢慢走进不少家庭,扮演者我们生活中的智能小帮手。今天我们就来一起聊聊智能家居中通常会用到的一些连接方式还有各个设备之间互联互通的通讯协议,以及它们之间的优劣势。  首先讲讲WiFi这个通讯协议,也就是无线局域网,它的优点呢就是传输速率快,设备响应及时。缺点的话就是同时在线设备不多,多了就容易掉线,一般在十几二十个设备的样子,功耗也是比较大的,一般都需要给设备供电。像现在国内手机厂商小米的大多数生态链产品都是采用WiFi连接通讯。  蓝牙连接方式其优点在于功耗较低,传输速率也比较快。缺点就是传输距离比较短,一般在5-10米,设备间也是点对点之间的通讯传输,所以更多的会用在智能穿戴设备上,像智能手环蓝牙耳机等等。  ZigBee通讯协议呢算是目前市面上家用智能终端中使用最多的通讯协议。其优点在于功耗低,设备之间互联互通,单一设备掉线其他设备之间互不影响,通过网关作为一个中间站来收发终端之间传输过来的信息,各个设备之间组成蜂窝网,可连接节点最多可达300多个,一般家庭场景完全可以满足,所以也深受各大集成商,智能智造厂商的青睐。
  • [技术干货] 物联网通信协议汇总
    随着物联网设备数量的持续增加,这些设备之间的通信或连接已成为一个重要的思考课题。通信对物联网来说十分常用且关键,无论是近距离无线传输技术还是移动通信技术,都影响着物联网的发展。而在通信中,通信协议尤其重要,是双方实体完成通信或服务所必须遵循的规则和约定。本文介绍了几个可用的物联网通信协议,它们具有不同的性能、数据速率、覆盖范围、功率和内存,而且每一种协议都有各自的优点和或多或少的缺点。其中一些通信协议只适合小型家用电器,而其他一些通信协议则可以用于大型智慧城市项目。物联网通信协议分为两大类:一类是接入协议:一般负责子网内设备间的组网及通信一类是通讯协议:主要是运行在传统互联网TCP/IP协议之上的设备通讯协议,负责设备通过互联网进行数据交换及通信。一、物理层、数据链路层协议1、远距离蜂窝通信(1)2G/3G/4G通信协议,分别指第二、三、四代移动通信系统协议。(2)NB-IoT窄带物联网(Narrow Band Internet of Things, NB-IoT)成为万物互联网络的一个重要分支。NB-IoT构建于蜂窝网络,只消耗大约180kHz的带宽,可直接部署于GSM网络、UMTS网络或LTE网络,以降低部署成本、实现平滑升级。NB-IoT聚焦于低功耗广覆盖(LPWA)物联网(IoT)市场,是一种可在全球范围内广泛应用的新兴技术。具有覆盖广、连接多、速率快、成本低、功耗低、架构优等特点。应用场景:NB-IoT网络带来的场景应用包括智能停车、智能消防、智能水务、智能路灯、共享单车和智能家电等。(3)5G第五代移动通信技术,是最新一代蜂窝移动通信技术。5G的性能目标是高数据速率、减少延迟、节省能源、降低成本、提高系统容量和大规模设备连接。应用场景:AR/VR、车联网、智能制造、智慧能源、无线医疗、无线家庭娱乐、联网无人机、超高清/全景直播、个人AI辅助、智慧城市。2、远距离非蜂窝通信(1)WiFi由于前几年家用WiFi路由器以及智能手机的迅速普及,WiFi协议在智能家居领域也得到了广泛应用。WiFi协议最大的优势是可以直接接入互联网。相对于ZigBee,采用Wifi协议的智能家居方案省去了额外的网关,相对于蓝牙协议,省去了对手机等移动终端的依赖。商用WiFi在城市公共交通、商场等公共场所的覆盖,将商用WiFi的场景应用潜力表露无疑。(2)ZigBeeZigBee是一种低速短距离传输的无线通信协议,是一种高可靠的无线数传网络,主要特色有低速、低耗电、低成本、支持大量网上节点、支持多种网上拓扑、低复杂度、快速、可靠、安全。ZigBee技术是一种新型技术,它最近出现,主要是依靠无线网络进行传输,它能够近距离的进行无线连接,属于无线网络通讯技术。ZigBee技术的先天性优势,使得它在物联网行业逐渐成为一个主流技术,在工业、农业、智能 家居等领域得到大规模的应用。(3)LoRaLoRa™(LongRange,远距离)是一种调制技术,与同类技术相比,提供更远的通信距离。LoRa 网关、烟感、水监测、红外探测、定位、排插等广泛应用物联网产品。作为一种窄带无线技术,LoRa 是使用到达时间差来实现地理定位的。LoRa 定位的应用场景:智慧城市和交通监控、计量和物流、农业定位监控。3、近距离通信(1)RFID射频识别(RFID)是 Radio Frequency Identification 的缩写。其原理为阅读器与标签之间进行非接触式的数据通信,达到识别目标的目的。RFID 的应用非常广泛,典型应用有动物晶片、汽车晶片防盗器、门禁管制、停车场管制、生产线自动化、物料管理。完整的RFID系统由读写器(Reader)、电子标签(Tag)和数据管理系统三部分组成。(2)NFCNFC的中文全称为近场通信技术。NFC是在非接触式射频识别(RFID)技术的基础上,结合无线互连技术研发而成,它为我们日常生活中越来越普及的各种电子产品提供了一种十分安全快捷的通信方式。NFC中文名称中的“近场”是指临近电磁场的无线电波。应用场景:应用在门禁、考勤、访客、会议签到、巡更等领域。NFC具有人机交互、机器间交互等功能。(3)Bluetooth蓝牙技术是一种无线数据和语音通信开放的全球规范,它是基于低成本的近距离无线连接,为固定和移动设备建立通信环境的一种特殊的近距离无线技术连接。蓝牙能在包括移动电话、PDA、无线耳机、笔记本电脑、相关外设等众多设备之间进行无线信息交换。利用“蓝牙”技术,能够有效地简化移动通信终端设备之间的通信,也能够成功地简化设备与因特网Internet之间的通信,从而数据传输变得更加迅速高效,为无线通信拓宽道路。4、有线通信(1)USBUSB,是英文Universal Serial Bus(通用串行总线)的缩写,是一个外部总线标准,用于规范电脑与外部设备的连接和通讯。是应用在PC领域的接口技术。(2)串口通信协议串口通信协议是指规定了数据包的内容,内容包含了起始位、主体数据、校验位及停止位,双方需要约定一致的数据包格式才能正常收发数据的有关规范。在串口通信中,常用的协议包括RS-232、RS-422和RS-485。串口通信是指外设和计算机间,通过数据线按位进行传输数据的一种通讯方式。这种通信方式使用的数据线少,在远距离通信中可以节约通信成本,但其传输速度比并行传输低。大多数计算机(不包括笔记本)都包含两个RS-232串口。串口通信也是仪表仪器设备常用的通信协议。(3)以太网以太网是一种计算机局域网技术。IEEE组织的IEEE 802.3标准制定了以太网的技术标准,它规定了包括物理层的连线、电子信号和介质访问层协议的内容。(4)MBusMBus 远程抄表系统(symphonic mbus),是欧洲标准的2线的二总线, 主要用于消耗测量仪器诸如热表和水表系列。二、网络层、传输协议1、IPv 4互联网通信协议第四版,是网际协议开发过程中的第四个修订版本,也是此协议第一个被广泛部署的版本。IPv4是互联网的核心,也是使用最广泛的网际协议版本2、IPv6互联网协议第6版,由于IPv4最大的问题在于网络地址资源有限,严重制约了互联网的应用和发展。IPv6的使用,不仅能解决网络地址资源数量的问题,而且也解决了多种接入设备连入互联网的障碍3、TCP传输控制协议(TCP,Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP旨在适应支持多网络应用的分层协议层次结构。连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。TCP假设它可以从较低级别的协议获得简单的,可能不可靠的数据报服务。4、6LoWPAN6LoWPAN是一种基于IPv6的低速无线个域网标准,即IPv6 over IEEE 802.15.4。三、应用层协议1、MQTT协议MQTT (Message Queue Telemetry Transport),翻译成中文就是,遥测传输协议,其主要提供了订阅/发布两种消息模式,更为简约、轻量,易于使用,特别适合于受限环境(带宽低、网络延迟高、网络通信不稳定)的消息分发,属于物联网(Internet of Thing)的一个标准传输协议。在很多情况下,包括受限的环境中,如:机器与机器(M2M)通信和物联网(IoT)。其在,通过卫星链路通信传感器、偶尔拨号的医疗设备、智能家居、及一些小型化设备中已广泛使用。2、CoAP协议CoAP(Constrained Application Protocol)是一种在物联网世界的类Web协议,适用于需要通过标准互联网网络进行远程控制或监控的小型低功率传感器,开关,阀门和类似的组件,服务器对不支持的类型可以不响应3、REST/HTTP协议RESTful是一种基于资源的软件架构风格。所谓资源,就是网络上的一个实体,或者说是网络上的一个具体信息。一张图片、一首歌曲都是一个资源。RESTful API是基于HTTP协议的一种实现。(HTTP是一个应用层的协议,特点是简捷 快速)。满足Rest规范的应用程序或设计就是RESTful,根据Rest规范设计的API,就叫做RESTful API4、DDS协议DDS(Data Distribution Service)分布式实时数据分发服务中间件协议,它是分布式实时网络里的“TCP/IP”,用来解决实时网络中的网络协议互联,其作用相当于“总线上的总线”。5、AMQP协议AMQP,即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息,并不受客户端/中间件不同产品,不同的开发语言等条件的限制。Erlang中的实现有RabbitMQ等。6、XMPP协议XMPP是一种基于标准通用标记语言的子集XML的协议,它继承了在XML环境中灵活的发展性。因此,基于XMPP的应用具有超强的可扩展性。经过扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求,以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程序。四、部分通信协议比较1、NB-IoT协议和LoRa协议比较第一,频段。LoRa工作在1GHz以下的非授权频段,在应用时不需要额外付费,NB-IoT和蜂窝通信使用1GHz以下的频段是2113授权的,是需要收费的。第二,电池供电寿命。LoRa模块在处理干扰、网络5261重迭、可伸缩性等方面具有独特的特性,但却不能提供像蜂窝协议一样的服务质量4102。NB-IoT出于对服务质量的考虑,不能提供类似LoRa一样的电池寿命。第三,设备成本。对终端节点来说,LoRa协议比NB-IoT更简单,更容易开发并且1653对于微处理器的适用和兼容性更好。同时低成本、技术相对成熟的LoRa模块已经可以在市场上找到了,并且还会有升级版本陆续出来。第四,网络覆盖和部署时间表。NB-IoT标准在2016年公布,除回网络部署之外,相应的商业化和产业链的建立还需要更长的时间和努力去探索。LoRa的整个产业链相对已经较为成熟了,产品也处于“蓄势待答发”的状态,同时全球很多国家正在进行或者已经完成了全国性的网络部署。2、蓝牙、WiFi、ZigBee协议比较目前来说,WiFi的优势是应用广泛,已经普及到千家万户;ZigBee的优势是低功耗和自组网;UWB无载波无线通信技术的优势是传输速率;蓝牙的优势组网简单。然而,这3种技术,也都有各自的不足,没有一种技术能完全满足智能家居的全部要求。蓝牙技术的出现使得短距离无线通信成为可能,但其协议较复杂、功耗高、成本高等特点不太适用于要求低成本、低功耗的工业控制和家庭网络。尤其蓝牙最大的障碍在于传输范围受限,一般有效的范围在10米左右,抗干扰能力不强、信息安全问题等问题也是制约其进一步发展和大规模应用的主要因素。WiFi也是是一种短距离无线传输技术,可以随时接入无线信号,移动性强,比较适合在办公室及家庭的环境下应用。当然WiFi也存在一个致命缺点。由于WiFi采用的是射频技术,通过空气发送和接收数据,使用无线电波传输数据信号,比较容易受到外界的干扰。ZigBee则是国际通行的无线通讯技术,它的每个网络端口可以最多接入6.5万多个端口,适合家居、工业、农业等多个领域使用,而蓝牙和WiFi网端只能接入10个端口,显然不能适应家庭需要。ZigBee还具有低功耗和低成本优势。3、MQTT协议和CoAP协议比较MQTT是多对多通讯协议用于在不同客户端之间通过中间代理传送消息,解耦生产者与消费者,通过使得客户端发布,让代理决定路由并且拷贝消息。虽然MQTT支持一些持久化,最好还是作为实时数据通讯总线。CoAP主要是一个点对点协议,用于在客户端与服务器之间传输状态信息。虽然支持观察资源,CoAP最好适合状态传输模型,不是完全基于事件。MQTT客户端建立长连接TCP,这通常表示没有问题,CoAP客户端与服务器都发送与接收UDP数据包,在NAT环境中,隧道或者端口转发可以用于允许CoAP,或者像LWM2M,设备也许会先初始化前端连接。MQTT不提供支持消息打类型标记或者其他元数据帮助客户端理解,MQTT消息可用于任何目的,但是所有的客户端必须知道向上的数据格式以允许通讯,CoAP,相反地,提供内置支持内容协商与发现,允许设备相互探测以找到交换数据的方式。两种协议各有优缺点,选择合适的取决于自己的应用。————————————————原文链接:https://mp.weixin.qq.com/s/yzoPUVmUsO2nufV7w9fWOQ
  • [技术干货] 关于物联网总结
    在对接别人的物联网命令文档时一些专业用语:  某一个数据,占8Byte  ,那么怎么取呢比如: 00 00 00 00 00 E9 17 46 00 00 00 00 00 8E 1E 64 那么:这个数据就是  00 00 00 00 00 E9 17 46,希望以后能够明白怎么对接别人的文档,以后有什么,还会在这个文章上面进行修改2021-10-23 增加前台使用WebSocket 的方法function webSocket(){  if("WebSocket" in window){    console.log("您的浏览器支持WebSocket");    var ws = new WebSocket("ws://localhost:8080"); //创建WebSocket连接    //...  }else{    console.log("您的浏览器不支持WebSocket");  }}var ws = new WebSocket("ws://localhost:8080"); //申请一个WebSocket对象,参数是服务端地址,同http协议使用http://开头一样,WebSocket协议的url使用ws://开头,另外安全的WebSocket协议使用wss://开头ws.onopen = function(){  //当WebSocket创建成功时,触发onopen事件   console.log("open");  ws.send("hello"); //将消息发送到服务端}ws.onmessage = function(e){  //当客户端收到服务端发来的消息时,触发onmessage事件,参数e.data包含server传递过来的数据  console.log(e.data);}ws.onclose = function(e){  //当客户端收到服务端发送的关闭连接请求时,触发onclose事件  console.log("close");}ws.onerror = function(e){  //如果出现连接、处理、接收、发送数据失败的时候触发onerror事件  console.log(error);}————————————————原文链接:https://blog.csdn.net/Little_Code/article/details/120909508
  • [其他] 集成应用|契约锁与100+管理软件实现集成应用
    2021年,契约锁与100+管理软件实现集成应用,不断深化电子签章应用场景。推动人事、财务、采购、招投标、销售、法务、医保、公积金、房屋交易合同网签备案、不动产登记、诊疗、校园办事、检测、投保、贷款、货运等各类业务实现电子签署,打通业务全程数字化最后一公里!(让更多业务的电子签署需求得以实现)集成展示:软件类型+场景展示通过集成,契约锁电子签章与各类管理软件、移动应用的流程、应用以及信息全面打通,各项业务审批后即可在线调用契约锁数字身份、电子模板、电子印章、电子签名等应用,进行审批签字、在线签约,真正实现全面无纸化管理。1、ERP业务管理软件包括Oracle|SAP|IBM|用友|金蝶|浪潮|南北软件|宝信ERP|红星云等应用场景任意业务节点都能调用电子模板、电子签章;一键生成采购订单、销售订单、财务凭证、销售合同、委托书等电子文件,在线完成内部盖章、远程签约。2、HRM人事管理软件包括用友EHR|PeopleSoft|朗新EHR系统|夏谷HR系统|嘉扬HR系统|北森|SAP SuccessFactors|劳勤|宏景EHR|奉行信息HR系统|勤杰EHR系统|红海EHR等应用场景入职声明书|入职告知书|劳动合同(新签/续签)|在职/离职/收入等各类证明|保密协议|人事竞业限制协议|就业协议|员工手册等实现电子签署。3、CRM客户管理软件包括salesforce|U客APP|销帮帮应用场景客户收费确认函|业务合同|订单|客户需求确认单|验收单实现电子签署。4、客服管理软件包括朗新客服系统应用场景服务合同电子签。5、OA办公软件包括泛微|蓝凌|致远|万户|慧点|通达|榕基|普元|微宏|诺明等应用场景流程审批用印(采购、销售、证明、公文等用印流程审批后自动盖章);印章统一管控,在OA同步管理、分析用印数据。6、移动应用软件包括微信小程序|微信公众号|企业微信|钉钉|华为WeLink|蓝信|手机银行APP等应用场景在手机端打开移动应用软件就能快速申请、审批、使用印章,随时随地查询签署进度。7、财务管理软件包括用友|金蝶EAS|金蝶资金管理系统|浪潮等应用场景询证函|对账单|工资单|报销单|收付款凭证|业务单据实现电子签署,全程可信数字身份保障,有效防篡改,确保财务凭证可信。8、采购管理软件包括汉得SRM系统|瑞特SRM系统|SCM系统|采购系统|订单系统|筑龙系统|奇秦SRM系统|翔桥供应链服务平台等应用场景供应商合同|采购订单|招标文件|询价函|报价单|采购合同|对账单|发货单等实现电子签署。9、招投标管理平台应用场景招投标双方身份认证及核验|招标文件|标书|中标通知书|评标报告|答疑澄清函实现电子签。10、合同管理类软件包括易联云应用场景合同模板制作及管理|合同批量签署|合同远程签署|合同归档|合同验真|合同防伪防篡改,全程数字化。11、档案管理系统包括量子伟业档案管理系统应用场景各类合同、票据、人事、教务档案实现电子签署、自动归档。12、销售业务管理软件包括DMS系统(汽车经销商管理系统)|玄武经销商管理系统|销售易|浪潮EOS等应用场景经销商协议|销售合同|销售订单|物流交接单等实现电子签。13、进销存管理系统包括IBOSS系统|贯信信息系统等应用场景经销商/供应商/客户远程签署|经销商加盟协议|采购订单|销售合同等实现电子签署。14、订单管理软件包括e订通等应用场景经销商合同|订单实现电子签15、BPM流程管理系统包括K2|安码BPM|H3|鼎捷BPM|盟拓BPM等应用场景流程审批后在线签字审批、自动盖章;审批-签署-归档一体化。16、集团法务管理系统应用场景法律意见书|律师函|风险评估意见书|授权委托书|制度文件|律师选聘合同|纠纷案件签字|仲裁合同等借助电子模板一键生成、电子签。格式规范、防伪防篡改,减少法务机械化工作量。17、政务服务系统包括一网通办平台|电子证照系统|电子劳动合同签署平台|公积金管理系统|房产交易平台|不动产登记系统|医保服务系统等应用场景电子劳动合同网签|房屋交易合同网签及备案|不动产登记证明/证照|排污许可证|商铺整改通知|公积金缴存明细|流水表单|缴存证明|党政/计生/住房/户口证明|医保定点合作协议在线签署,政务服务网上办。18、医疗类业务管理软件包括东软云HIS系统|病历系统|Veeva医疗CRM系统|LIS实验室信息系统等应用场景电子病历|电子处方|患者知情同意书|检查报告|医生医嘱|住院信息表|患者信息表|诊断证明|病休证明等实现电子签,自助下载、打印。19、校园管理类软件包括康赛校园信息管理系统|国子软件|校务系统|校园网上办事大厅|学生事务管理系统|学工系统|就业系统等应用场景成绩单|就业协议|在读/学籍/档案/毕业等证明文件|评奖评优申请表|毕业证书|录取通知书|学位证书等实现电子签署。20、LIMS实验室信息管理系统应用场景检测报告|样品接收单|化验单|作废声明等文件在线盖章,批量签发。21、金融类业务管理软件包括小贷系统|顶点软件(投行、证券软件)|龙戈担保业务管理系统|柜面业务系统|跟投系统等应用场景借贷合同|投资合同|企业开户文件|居间合同|担保合同|反担保合同|银行保函|放款通知书|信托合同|电子保单等金融业务文件实现电子签。22、地产/工程类管理软件包括明源云|华腾软件|新中大i8工程项目管理软件|红星云|鲁班BIM系统等应用场景工程承包合同|分包合同|施工合同|工程验收报告|购房合同|线上售楼协议|认购单|认筹单|购房收据|物业服务合同等实现电子化签署。23、智慧水务管理系统包括易维水务系统|国德水务系统等应用场景过户合同|施工合同|供水合同|缴费单据实现电子签署,手机端自助办理。24、租赁服务平台应用场景租赁合同|房源托管合同电子签;平台、房东、租户在线签。25、保险业务系统应用场景电子保单|电子回执|金融分期合同等实现电子签署。26、物流业务管理系统包括蚂蚁物流系统等应用场景承运单|物流交接单|电子运单|发货单|收货单|货运证明等实现电子签署。总结契约锁数字身份、电子签章、印控平台以及电子档案管理等数字可信基础软件具备强大的开放集成能力,可以满足各类组织现有业务软件的电子签章需求,数字可信产品深化应用到更多组织的特色业务中,助力组织数字化转型。
  • [交流吐槽] 网络协议栈源码分析
    此网络协议栈源码分析是基于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 = ops; //pops指向inet_proto_ops结构体                                   pops->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;            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
  • [新手课堂] 网络协议栈源码分析
    此网络协议栈源码分析是基于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 = ops; //pops指向inet_proto_ops结构体                                   pops->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;            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
  • [技术干货] CPE双发选收配置指导
    1.测试组网2.限制和约束AC款型:AC6805和AirEngine9700-M1,仅这两款支持AC版本:V200R021C10网段配置:CPE和AP,下挂STA分别是不同的组网,比如CPE使用网段10,AP使用网段20,下挂STA使用网段30CPE双频使用的网段不一样,比如4G的service-vlan是10,5G的service-vlan就不能是10必须使用AP和CPE建立EOGRE隧道目前配置双发选收,必须在VAP下使能AGV漫游,否则可能出现CPE无法关联问题3.配置指导AC配置1.配置CPE模板2.4G的CPE模板5G的CPE模板2.绑定CPE模板到VAP模板创建两个VAP模板,将步骤一配置的cpe模板绑定到VAP下 CPE配置1.CPE上电登陆使用网线将电脑直连CPE的下行LAN口,修改电脑的以太网的网络为静态地址(192.168.10.10),打开浏览器输入CPE地址192.168.10.1,登陆账号root,密码SuchDo_20202.使能双发选收CPE登陆成功后,点击“上行”->“高级配置”,下滑可以看到双发选收配置,点击使能3.双频关联信号2.4G点击“上行”->“2G上行”,扫描SSID,点击选中然后下一步关联5G点击“上行”->“5G上行”,扫描SSID,点击选中然后下一步关联4.使能EoGRE(默认使能)点击“上行”->“高级配置”,下滑可以看到EoGRE配置,点击保存。不需要配置SIP、DIP和VID这些。5.CPE双频关联成功6.CPE下挂STA可以DHCP获取地址STA可以ping通网关 4.Q&A1.配置好双发选收后,CPE关联失败?AC上VAP下需要使能AGV漫游:autonavigation-roam-optimize enable 2.如何确认EoGRE隧道建立成功?和AP建立隧道,可以登陆AP,诊断视图下,执行dis cpe-tunnel remote-station,双发选收就是两个隧道 3.CPE下挂STA无法DHCP获取地址,或者DHCP获取到地址后,ping网关不通?请认真检查自己的组网,CPE的网段配置,双发选收隧道网段,还有STA下挂网段的配置,这三个网段不可以一样,详见2.限制与约束
  • [技术干货] 【CPE】双发选收配置指导
    测试设备设备类型数量备注AC1无线控制器Access ControllerAP1无线接入点Access PointSW1POE交换机,用于AP供电CPE1Wi-Fi6 CPE测试终端若干终端 测试组网 配置项数据管理VLANVLAN100业务VLAN(2.4G)VLAN200业务VLAN(5G)VLAN300双发选收隧道vlanVLAN301 和 VLAN302CPE有线口VLANVLAN400AC的源接口VLANIF100:192.168.100.1/24DHCP服务器AC作为DHCP服务器为AP分配VLAN100的IP地址;AC作为DHCP服务器为分配终端分配VLAN 200、300和CPE有线口VLAN400的IP地址AC配置指导查看AC和AP版本在AC上执行下列命令,查看AC和AP的版本注意:AC和AP版本全都是R21C10及以后的版本, CPE与AP才能配置双发选收; AC网络配置配置vlan(需要6个vlan,其中vlan100 200 300 400需要有真实地址和dhcp地址池;vlan 301和302只需要有vlanif的名字)AC业务配置1、配置5g信号的cpe模板在模板中放通下挂有线终端使用的vlan,具体vlan数字根据真实使用情况配置(图中301为隧道vlan,400是下挂终端使用的真实vlan;frer表示开启双发选收) 2、在VAP模板中引用cpe模板注:此时AP侧的隧道的IP地址为169.254.1.10,即CPE上需配置EoGRE目的IP地址为169.254.1.10。3、同理配置2.4g信号4、关闭Bss color功能 5、把VAP绑定到AP组(AP组名字按照实际情况写)CPE配置默认账号名密码为user/useradmin 配置设备模式为桥接模式(此时设备会重启,重启后继续配置)配置双发选收配置双发选收漫游关联5g信号关联2.4G信号配置EoGRE(IP由CPE自动填充,不要修改)配置完成。
  • [问题求助] gd32f450 lwip网络协议移植出问题,总是死在了Infinite_Loop
    采用GD32F450,现在在移植LWIP,现在出的问题是参考CLOUD_STM32F429IG那个项目做移植,发现在新建的task后,在网口芯片初始化时,总是跑到Infinite_Loop。我单独把初始化的函数放在HardwareInit()这个函数里,也就是系统还没有启动前,就可以完成初始化工作,但是放到任意一个task中,就不行。现在不清楚是哪影响了。感觉是像是这个初始化是不是导致系统的看门狗什么的重置了还是怎么了。我试着调节了task的堆的值,没有变化。
  • [新手课堂] 计算机网络总结
    1.网络分层七层OSI应用层、表示层、会话层、传输层、网络层、数据链路层、物理层五层协议(主要)应用层、传输层、网络层、数据链路层、物理层四层协议TCP/IP应用层、传输层、网际层、网络接口层2.各层的功能应用层为应用程序提供交互服务。如:HTTP、HTTPS、DNS、SMTP、FTP表示层主要负责数据格式的转换。如:加密解密、压缩解压缩。会话层负责在网络中的两节点之间建立、维持、终止通信。如:服务器验证用户登录运输层/传输层向主机进程提供通用的数据传输服务。如:TCP、UDP网络层路由选择和转发。如:IP数据链路层封装成帧。物理层比特流透明传输。3.传输层3.0TCP的组成源端口、目的端口、序号seq、确认号ack、窗口控制位:ACK、FIN、SYN3.1TCP和UDP的区别TCP面向连接的,可靠的,面向字节流的,主要是一对一连接。场景:FTP文件传输、SMTP邮件发送、远程登陆、HTTP网络请求UDP无连接的,不可靠的,尽最大努力交付的,面向报文段的,包含一对一、一对多、多对多连接。场景:QQ直播、QQ语音、QQ视频3.2TCP的可靠性体现1.确认应答机制每次请求都会根据seq序列号进行“重排、丢掉重复的”,然后发送ACK报文,包含ack确认号。2.重传机制超时重传:对于发送的报文,如果在RTO(超时重传时间)>RTT(往返时延),没有收到ACK确认报文,则需要重新发送这个报文段。--------基于时间快重传:对于发送的报文,如果在一定时间内,连续收到对于同一个报文的确认,说明下一个报文丢失,直接重传下一个报文。---------基于数据3.流量控制局部的思想,主要保证是接受方来限制发送方的发送效率,使得自己来得及接受,在TCP的报文段的窗口来设置。4.滑动窗口不再局限于之前的发送一个报文,应答一个报文;而是可以发送多个报文,接受多个报文;并且只需要对最后一个进行应答即可,这是累计确认,是有一个缓存机制的。发送方窗口组成:已经发送并收到确认的报文、已经发送未收到确认、还未发送的但可以发送的、不可以发送的;发送方窗口大小 = 已经发送未收到确认 + 还未发送的但可以发送的接收方窗口组成:已经接受并发送确认的报文、可以接受还未发送确认的、不可以接受的;接受方窗口大小 = 可以接受还未发送确认的5.拥塞控制基于全局的思想,防止一段时间可能由于需求大于提供而导致的性能变差。变量:拥塞窗口cwnd、慢开始门限ssthresh慢开始cwnd = 1;每一个RTT后,cwnd = cwnd*2拥塞避免cwnd>ssthrensh,cwnd = cwnd +1如果出现网络拥塞:cwnd = 1,ssthresh = cwnd/2快重传对于发送的报文,如果在一定时间内,连续收到对于同一个报文的确认,说明下一个报文丢失,直接重传下一个报文。cwnd = cwnd/2;ssthresh = cwnd-3;快恢复cwnd = ssthresh + 3,重新走到拥塞避免。3.3TCP的三次握手过程:确保通信双方都能发送和接收数据1.发送方发送SYN = 1,seq = x,发送方进入SYN-SENT这里的初始序列号最好是随机的,因为如果有第三方知道双方端口和ip地址,推测出序列号就会产生一定的危害。2.接收方收到请求,发送ACK = 1,SYN =1,seq = y,ack = x+1,接收方进入SYN-RECV3.发送方接收到请求,建立连接;发送ACK = 1,seq= y,ack =y+1此时如果接收方没有收到第三次握手,则第二次会继续发送补充:1.四次握手可以吗?当然可以,但是没有意义,因为四次握手要完成的事情,三次握手已经完成了2.二次握手呢?不可以,如果仅仅两次握手,假设第一次握手的请求因为网络原因,没有及时到达接收方,此时发送方重传,接受方建立连接,但是如果之前的请求再次到达,就会再次建立一个新的请求;而三次握手,在第二次握手的时候,会适当的抛弃。3.SYN泛洪攻击(DOS_Denial of Service)大量发送SYN=1的请求,导致服务器方,很多连接处于半连接队列中,从而导致半连接队列满,而正常的请求被抛弃。解决:对于攻击的ip进行设置,拒绝访问;及时清空半连接队列的请求连接。4.DDOS(Distributed Denial of Service)分布式攻击的泛洪攻击,没什么区别解决:减少SYN的timeout时间;减少SYN的连接数量。5.三次连接可以发送数据吗?第一次和第二次不可以:就是防止SYN攻击的时候,有大量的数据发送,导致服务器崩溃。第三次可以:此时客户端处于建立状态,并且知道服务器可以发送和接受数据。6.第三次握手丢失?重传机制,RTO>RTT的时候,服务端继续重新发送数据,时间指数倍增长。3.4TCP的四次挥手过程:通信双方发送完数据,来断开连接。发送方断开连接1.发送方发送FIN = 1,ACK、seq、ack;发送方进入FIN_WAIT12.接收方收到请求,发送ACK 、seq、ack,接收方进入close_wait,发送方进入FIN_WAIT2接收方断开连接3.接收方数据接收完,请求断开连接;发送FIN=1,ACK ,seq,ack;进入Last_Ack4.发送方接受到请求,发送ACK、seq,ack,进入TIME_WAIT阶段补充:1.为什么需要四次?不同于三次握手,因为要涉及到通信双方的数据2.为什么最后要等待2MSL?MSL:报文段最大存活时间,保证了如果最后一次挥手没有丢失,第三次挥手的报文段重新接受;并且保证了下一次的连接中,不会有上次的存留的报文段3.四次挥手的首次请求方一定是客户端吗?不一定让服务端先退出,然后我们用netstat观察端口的状态,此时我们发现四次挥手过程中服务器和客户端的状态颠倒了, 也就是说,服务端和客户端的进程那个先向对方发送FIN 字段报文,那么哪个就先进入FIN_WAIT2状态。但是下一步:客户端往服务端发送数据就不一样?原因:当服务器进程被终止时,会关闭其打开的所有文件描述符,此时就会向客户端发送一个FIN 的报文,客户端则响应一个ACK 报文,但是这样只完成了“四次挥手”的前两次挥手,也就是说这样只实现了半关闭,客户端仍然可以向服务器写入数据。但是当客户端向服务器写入数据时,由于服务器端的套接字进程已经终止,此时连接的状态已经异常了,所以服务端进程不会向客户端发送ACK 报文,而是发送了一个RST 报文请求将处于异常状态的连接复位; 如果客户端此时还要向服务端发送数据,将诱发服务端TCP向服务端发送SIGPIPE信号,因为向接收到RST的套接口写数据都会收到此信号.所以说,这就是为什么我们主动关闭服务端后,用客户端向服务端写数据,还必须是写两次后连接才会关闭的原因。注:感觉有点问题,不太理解?只需要记住不同于正常关闭即可,并且传输数据会进行两次写,但不成功!参考链接:https://blog.csdn.net/bit_clearoff/article/details/608849054.Time-wait过多怎么办?对于服务器来说,则会严重损耗服务器的资源,导致部分客户端连接不上。解决:设置参数SO_REUSEADDR套接字选项来避免time-wait,进行端口重用对于客户端来说,会导致客户端端口被占用,65536,导致无法创建新的连接解决:发送RST包,直接越过Time-wait,进入closed,这就像上面的服务端主动关闭导致的一样。3.5TCP的心跳机制很多应用层协议都有HeartBeat机制,通常是客户端每隔一小段时间向服务器发送一个数据包,通知服务器自己仍然在线,并传输一些可能必要的数据。使用心跳包的典型协议是IM,比如QQ/MSN/飞信等协议。心跳包之所以叫心跳包是因为:它像心跳一样每隔固定时间发一次,以此来告诉服务器,这个客户端还活着。事实上这是为了保持长连接,至于这个包的内容,是没有什么特别规定的,不过一般都是很小的包,或者只包含包头的一个空包。总的来说,心跳包主要也就是用于长连接的保活和断线处理。一般的应用下,判定时间在30-40秒比较不错。如果实在要求高,那就在6-9秒。实现步骤:TCP的KeepAlive保活机制?1:客户端每隔一个时间间隔发生一个探测包给服务器2:客户端发包时启动一个超时定时器3:服务器端接收到检测包,应该回应一个包4:如果客户机收到服务器的应答包,则说明服务器正常,删除超时定时器5:如果客户端的超时定时器超时,依然没有收到应答包,则说明服务器挂了参考链接:https://blog.csdn.net/qq_33314107/article/details/805741373.6TCP的粘包和拆包问题: TCP报文段传输的时候也会出现报文段分段的现象(主要是报文段太大),类似于网络层的ip分组。现象: 两个包合在一起发送、一个包的前一部分和另一个包一起发送、一个包的后部分单独发送原因: 1.报文段太大,大于MSS(最大分段长度)、2.发送方发送的数据大于发送缓冲区剩余数据的大小、3.发送方发送的数据小于接收方缓冲区空间的大小,多次将数据发送到网络解决: 1.对于报文段固定相同的长度,不足进行填充;2.对于每个报文段进行定界符的填充来进行区分;3.在报文段的首部添加表示报文段长度的标识。3.7UDP会发生粘包和拆包吗?不会,因为其报文段发送的,而TCP是按字节流,并且UDP的首部指示了报文段的长度。3.8UDP怎么实现可靠的?其实现不了,主要在应用层实现的,就像QQ的QICQ,其实现了TCP的各种可靠机制。4.应用层4.1:http常见的状态码100:Continue200:OK、206:部分请求301:永久重定向、302:临时重定向永久:代表访问某个a,会自动跳转到b,url为b;临时:访问a,url不变,但是内容渲染的是b400:客户端语法错误、403:服务器拒绝提供服务(不为请求提供服务,或您没有连接到此站点的权限时)、404:页面没有找到500:服务器内部执行错误,无法完成请求、503:服务器正在维护4.2:http的请求报文、响应报文请求报文组成:请求行、请求头、请求体(其中请求行和请求体之间有空格来区分),如:Post /from/login?xxx HTTP1.1Host:www.baidu.com Connection:keep-alivename = swz & age =37响应报文组成:响应行、响应头、响应体(响应行和响应体之间有空格),如:200 OK HTTP1.1Data:xxxx Content-length:360< h1 > hello,world!< h1 >4.3:Get、Post(前两个为主)、Delete、PutGet:主要用于获取资源;参数传递通过请求行url,所以相对不是安全,并且长度限制;但是从整体上看,其主要是有幂等性的,这个说明多次请求效果一样,保证了对数据库的安全;Post:主要用于传输实体内容;参数传递在请求体中,所以相对安全,长度足够;主要是用于修改数据库内容,无法保证对数据库的安全;注:其实Post、Get这是两种规定,完全可以不按照走,但是处不处理就不一定了;并且相比较而言,Post是比Get有一些好处,但是Get请求,我们的浏览器可以进行缓存,所以多次请求的时候会加快速度。Delete:删除文件Put:上传文件4.4:Http1.0和Http1.1的区别1.前者是短连接,后者是长连接当请求一次连接的时候,如果是短连接的话,对于页面中的其他资源,如:js、image都会建立一次新的连接,而长连接可以共用一个。2.后者增加了很多新的状态码,如206:部分请求3.后者对于网络资源的处理更加优化,如允许部分请求4.后者在请求头中增加了Host字段,之前认为是一台主机一个IP,而因为虚拟机等的出现,多个主机公用一个ip4.5:Http1.1和Http2.0的区别?后者维护一个头部字段表,这样就不用在客户端和服务器端来回传输,只需要每次有修改的东西,传过去即可后者支持自动发送,不需要必须请求,而是在一定的时候,进行自动的推动数据后者利用了多路复用的基础,实现了服务器可以响应多个请求,实现了一条连接不同请求进行复用(这一部分具体实现我也不太懂----)并且2.0是基于二进制格式的,实现方便。4.6:Http3.0和Http2.0的区别?这一部分问的少,加分项吧(一般c++可能会问,之后补充吧)4.7:Cookie和Session和Token的区别?1.Cookie、Session的区别?一般我们会问到Cookie和Session的区别,但是对于Token,可能有些面生Cookie:主要用于客户端,存储在本机上,所以相对不安全Session:主要用于服务器端,相比是安全的,一般两者结合使用,是为了应对http请求的无状态,其实现主要是:在服务器端保存一个SeeionID和Seesion,用来表示每一个会话,以及存储相应的内容,将sessionid及对应的session分别作为key和value保存到缓存中,也可以持久化到数据库中,然后将SessionId返回给客户端,然后每次请求的时候在Cookie中将SessionID传过来,进行用户的跟踪。中途为了保证Cookie的一些信息,我们可以在Cookie进行加密,然后在服务器端进行解密即可。如果浏览器禁用了Cookie,那怎么办?这时候,我们可以通过在url发送的形式,将SessionID进行发送,当然为了安全,可以进行加密。2.Session和Token的区别Token 出现主要是解决Session本身会占用空间来说的流程:对用户id + 数据 进行签名操作,生成token,发送给客户端,下次客户端再次请求的时候,将token也传过来,然后再次使用相同的算法+密钥进行签名,比较两者的token是否相等,如果相等,则认为是同一个用户。区别:Session可以说是空间换时间,而Cookie可以说是时间换空间。3.无状态协议由于HTTP是一种没有状态的协议,它并不知道是谁访问了我们的应用。这里把用户看成是客户端,客户端使用用户名还有密码通过了身份验证,不过下次这个客户端再发送请求时候,还得再验证一下。所以上面的session和token是解决这个问题的(之前一直以为是为了保存数据的,我giao!)4.分布式Session这里在补充下分布式Session的解决方案:共享Session,单独有一个服务器存储Session,然后每台服务器进行响应的读取同步Session,说白了就是每台服务器都要存储一份,实时更新hash(ip),这是负载均衡的一个算法,实现一个客户端之后访问对应的服务器,直接就解决了5.负载均衡在补充下负载均衡算法随机轮询加权轮询hash(ip)6.签名简单说一下:主要是对数据通过哈希算法进行第一步处理,然后利用私钥进行加密生成数字签名CA证书:签名 + 服务器的公钥4.8:Https和Http的区别?简单来说:就是在http和tcp之间,加一层ssl/tls协议。最新版本的TLS 1.0是IETF(工程任务组)制定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本。两者差别极小,可以理解为SSL 3.1,它是写入了RFC的。注:RFC面试问过,但是不会,有兴趣的可以去了解。主要包含三个方面:1.防窃听解决:加密(对称加密(加密解密一个密钥)和非对称加密(公钥解密,私钥解密))过程:首先服务器将公钥传给来,然后客户端将对称加密的密钥利用公钥加密进行传输,服务器获取到利用私钥解密,之后两者利用客户端的公钥进行对称加密传输。分析:因为对称加密相比于非对称加密是更快的,而对称加密本身无法安全的将其传给服务器端,所以最后是两者结合了。2.防伪装解决:CA证书步骤:证书机构,如下面的安信。服务器端将自己的公钥传给CA,然后CA进行hash+私钥加密,生成数字签名,然后数字签名+服务器公钥 = CA证书;客户端获取服务器的证书,并获取CA的公钥,进行数字签名的解密,然后比较相等,则认证成功,获取服务端的公钥,下面的就一样了。分析:因为在上一步中可能会出现一些第三方中途截取的过程,它获取服务器端的公钥,然后把自己的公钥传给客户端,客户端将自己的公钥加密传给第三方,第三方私钥获取,然后利用服务器公钥加密发送给服务器,这样神不知鬼不觉就获到了。3.防篡改前面两个步骤很好的解决了。4.9:Https这么好,为什么不常用?1.CA证书有点贵2.因为多了处理,所以比较慢3.还是会有安全问题(怎么个问题?不知道)5.一些相关协议、过程5.1ARP请求协议这是网络层的一个协议,其主要完成了从ip地址到mac地址的一个映射。每个主机都会有一个ARP高速缓存,就是目的ip地址的mac地址的一个映射表步骤:1.查询Arp高速缓存,有,获得mac地址;没有,则广播发送ARP请求包2.ARP响应包,单播传回到A3.将mac地址写到Arp高速缓存中5.2DNS协议这是应用层的协议,其主要功能:完成url到ip地址的映射主要分为递归查询和迭代查询步骤:(递归+迭代组合查询)1.递归查询搜索浏览器本身的缓存、os的缓存,然后向本地域名服务器进行查找本地域名服务器:2.迭代查询本地域名服务器向根域名服务器进行查询,返回顶级域名的地址本地域名服务器向顶级域名服务器进行查询,返回权限域名服务器的地址本地域名服务器向权限域名服务器进行查询,返回ip地址3.缓存将url-ip的映射保存到os、浏览器缓存中即可。5.3URL过程1.url-ip地址的解析(DNS协议,见上面)2.TCP三次握手(见上面)3.ARP协议(见上面)4.数据传输(数据发送过程)5.页面渲染:将数据从报文拿出来进行页面的渲染。6.四次挥手(见上面)6.网络层的一些简单了解(笔试题)1.有类网相关问题:1.下面的IP地址中A类、B类、C类地址分别有几个?92.168.1.100、129.32.123.54、223.89.201.145、220.18.255.254、124.254.200.254191.64.220.8、66.254.1.100、92.1.100.1、202.15.200.12答:A类:第一位确定为0,范围为:0~127,所以:92.168.1.100 124.254.200.254 66.254.1.100三个属于A类网;B类:前两位确定为10,范围为:128~191,所以:129.32.123.54 191.64.220.8两个属于B类网;C类:前三位确定为110,范围为:192~223,所以:223.89.201.145 220.18.255.254 192.1.100.1 202.15.200.12四个属于C类网2.有类地址191.168.1.2的网络号和主机号分别是什么?答:因为为191开头,所以为B类地址,前16位为网络号,后16位为主机号,所以网络号为191.168.0.0,主机号为0.0.1.23.一个C类网可用的IP地址有多少个?答:根据问题,可知是一个确定的C类网,IP地址为可用主机个数,2^8-2=254个。2.子网划分C类网192.168.1.0划分为四个子网的子网掩码为255.255.255.192,子网号分别为00、 01、 10、 11。主机号为全1或全0的地址被保留,不能使用。子网号为全0或全1的子网现在都可以使用(以前规定不可使用)。子网掩码即将主机号的前n位拿出来作子网号,主机号的剩余部分作主机号。将子网掩码与ip地址作与运算,便可以得到网络地址,将取反后的子网掩码与ip地址作与运算,便可以得到主机地址。相关问题:假设有一个 I P 地址: 192.168.0.1,子网掩码为: 255.255.255.0,求网络地址和主机地址?步骤:化为二进制为: I P 地址 11000000.10101000.00000000.00000001,子网掩码 11111111.11111111.11111111.00000000,将两者做 ’ 与 ’ 运算得: 11000000.10101000.00000000.00000000将其化为十进制得: 192.168.0.0,这便是上面 IP 的网络地址,主机地址以此类推。
  • [新手课堂] WLAN基本知识之802.11标准
    WLAN技术基础1.4 802.11标准介绍1.4.1 IEEE 802.11协议族成员IEEE 805.11无线工作组制定的规范分两部分:一是802.11物理层相关标准二是802.11MAC层相关标准物理层主要是定义了无线协议的工作频段,调制编码方式及最高速度的支持;MAC层主要是做无线网络里面的一些功能,或者是一些具体协议的体现,如QOS是对网络做一个限速,Mesh技术,无线安全标准。1.4.2 IEEE 802.11标准与WiFi的世代2018年10月,WiFi联盟对不同WiFi标准指定了新的命名,802.11ax被命名为WiFi 6,WiFi 4之前不做时代命名。如图所示,基本上所有的标准都是使用OFDM技术,唯有WiFi 6 差异较大, 它的编码方式、空间流数、信道带宽都异于WiFi 4,WiFi 4是四个空间流,WiFi 6 可以做到12条空间流,OFDM(Orthogonal Frequency Division Multiplexing)即正交频分复用技术,实际上OFDM是MCM(Multi Carrier Modulation),多载波调制的一种。通过频分复用实现高速串行数据的并行传输, 它具有较好的抗多径衰弱的能力,能够支持多用户接入。OFDM技术由MCM(Multi-Carrier Modulation,多载波调制)发展而来。OFDM技术是多载波传输方案的实现方式之一,它的调制和解调是分别基于IFFT和FFT来实现的,是实现复杂度最低、应用最广的一种多载波传输方案。1.4.3 802.11a/b/g差异1.4.4 802.11n802.11n是无线传输标准协议,它是划时代的技术。它的目标在于改善先前的两项无线网上标准,包括802.11a与802.11g,在网上流量上的不足。它的最大传输速度理论值为600Mbit/s,与先前的54Mbit/s相比有大幅提升,传输距离也会增加。IEEE 802.11工作组于2002年成立了高吞吐量(HT)研究组着手制定新一代标准,并于2009年正式颁布基于MIMO-OFDM的802.11n标准,其最显著的是在速率上较之前有了突破性的进展。802.11采用多项新技术,带来了全新的用户体验,极大推动了WLAN产业的发展,也使得WiFi的概念深入人心,到现在仍有大量的802.11n终端在网使用。802.11n技术实现了大带宽,给WiFi带来了更大的应用场景。802.11n带来了许多全新技术,802.11n结合物理层和MAC层的优化,来充分提高WLAN技术的吞吐,物理层技术设计的MIMO非常关键,使用MIMO-OFDM 40Mhz、Short GI技术,从而将物理层吞吐提高到600Mbps。GI是指由于多径效应的影响,信息将通过多条路径传递,可能会发生彼此碰撞,导致ISI干扰,为此802.11a g标准,要求在发送信息符号时,必须保证在信息符号间,存在0.8us的时间间隔,这个间隔被称为Guard Interval。802.11n除了物理层优化,还对MAC协议层进行了优化,采用Block Ack块确认,帧聚合等技术,大大提高了MAC的效率。如果不对MAC层协议进行优化,仅仅物理层优化,就好比是修建了宽敞的马路,但是没有做好车道的规划,依然快不起来。1.4.5 802.11n关键技术1.4.6 IEEE 802.11ac标准IEEE 802.11ac标准的颁布,使得WLAN技术正式迈入千兆领域,但是该标准仅支持工作在5Ghz频段。2.4Ghz的干扰对他来说都不生效。之前说到的2.4G信道设备,蓝牙、红外都不会对5G网络产生影响,802.11n突破了原有WiFi标准带宽的瓶颈,它在802.11n基础上,增加了空间流数从4到8,信道从40Mhz增加至160Mhz,更定义了MU-MIMO技术,支持下行多用户并行传输。1.4.7 IEEE 802.ax标准(又称WiFi 6)IEEE 802.11ax,WiFi联盟称为WiFi 6,又称为高效率无线局域网,是无线局域网标准,11ax支持2.4Ghz 和 5Ghz频段,兼容802.11a/b/g/n/ac。802.11ax为了实现更大带宽,采纳了大多数802.11ac技术之上,又重新定义了OFDMA调制与复用技术,支持更窄的子载波间隔,并使用了1024-QAM调制模式,同时还引入上行MU-MIMO技术,使得WiFi 6 AP的整机理论速率突破10Gbps的同时,进一步提升高密场景下的吞吐量和服务质量。OFDMA DL/UL技术:OFDM即正交频分复用;A access接入的意思,适用于多用户同时进行;MU-MIMO DL/UL:增加支持上行1024-QAM:编码技术达到1024-QAM,编码效率变高。基本服务器着色:既属于物理层,又属于MAC层,它在物理层增加了 Color的字段,却提供MAC层的功能,作用就是解决同频干扰的问题。通过着色,让终端区分开来两个AP,以达到提升效率作用。目标唤醒时间:不同手机对应不同需求,如果不用WiFi模块,可休眠该模块,使用时在激活,既灵活使用,又节约设备供电。双NAV机制:数据传输过程中,用于控制是否进行传输,协商与调制的工作机制。1.4.8 WiFi 6理论速率计算理解:空间流数量影响传输速率,子载波编码bit数即每个子载波能传输多少个bit,编码率越高越好,有多少个有效的子载波数用来承载数据传输的子载波数量。1.5 WLAN的关键技术1.5.1 IEEE 802 与TCP/IP对等模型WLAN是一种基于 IEEE 802.11标准的无线局域网技术。802.11标准聚焦在TCP/IP对等模型的下两层:数据链路层:实现各种技术,如信道接入、寻址、数据帧校验、错误检测、安全机制等。物理层:负责在空口(空中接口)传输比特流,例如频段。1.5.2 802.11物理层技术802.11所采用的无线电物理层使用了三种不同的技术:跳频、直接序列、正交频复用(目前主要使用正交频复用,即OFDM)1.5.3 OFDMOFDM是一种特殊的多载波调制技术,其主要思想是将信道分成若干正交子信道,将高速数据信号转换成并行的低速子数据流,调制到在每个子信道上进行传输。各子载波相互正交,扩频调制后的频道可以互相重叠,不但减少了子载波间的干扰,还提高了频谱利用率。当一个子载波到达波峰的时候,另一个子载波幅度为0,即为两个子载波正交无干扰。OFDM之所以能够使用相互重叠的子载波,主要是因为定义了副载波,因此可以轻易区分彼此。信号分三个副载波,每个副载波波峰均为数据编码用,如图圆点。这些副载波之间经过刻意设计,彼此保持正交关系。每个副载波的波峰,此时其它两个副载波的振幅均为0。OFDM 5Ghz信道5Ghz信道有52个子载波,每个子载波有312.5Khz,有48个信道传输数据,4个信道用来做相位参考。OFDM子信道调制技术使用QAM(QAM是Quadrature Amplitude Modulation的缩写,中文译名为“正交振幅调制”),QAM同时利用了载波的振幅和相位来传递信息。1.6 WLAN基本概念1.6.1 BSS和BSA组成WLAN的基本单元是基本服务集(BSS),BSS包含一个固定的AP和多个终端。AP是BSS的中心,位置固定,AP在哪,BSS就在哪,而终端分布在AP周围,位置相对AP不固定AP的覆盖范围称为基本服务区域(BSA),终端可以自由进出BSA,进入BSA的终端才可以和AP通信。SSID相当于无线网络的名称,也是无线网络的身份标识,SSID的作用是便于用户辨识。BSSID是AP的身份标识,它也是通常所说的MAC地址;1.6.2 VAPVAP,即虚拟AP,AP通常支持创建多个虚拟AP(Virtual Access Point),每个VAP对应1个BSS。家用路由器也可以释放两个,2.4G和5G信号。1.6.3 DSDS(Distribution system ,DS)称为BSS的分布式系统,BSS解决了1个区域内多个终端无线通信,但终端通信往往分散在各个地方,甚至地球另一端,这需要AP连接到更大的网络,就是AP的上行网络,它把不同区域的BSS连起来,让终端可以通信。1.6.4 ESS(扩展服务集)BSS覆盖范围一般是15M,为了覆盖更大面积,可以用多个BSS来扩展。为了消除用户对BSS变化的感知,需要让每个BSS使用相同的SSID,这样用户走到哪,都是同一个WLAN。扩展服务集要求:1、两个独立BSS的AP一定要连接到同一个分布式系统2、两个SSDI一定要相同3、两个BSS一定要有重叠的覆盖区域。ESS主要提供漫游服务,意思从一个AP移动到另一个AP的覆盖范围,网络不中断。这种扩展BSS的范围方式称为扩展服务集(Extend services set,ESS),它以BSS为自由单位,让WLAN部署极为灵活。扩展服务集标识(ESSID,即各BSS相同的SSID成了ESS的身份标识,用于对终端通告一个连续的WLAN。1.7 WLAN组网架构即典型组网方案1.7.1 FAT AP架构(胖AP)FAT AP(胖AP)架构,又称为自治式网络架构胖AP架构无需部署集中控制设备(AC),但企业规模大,FAT数量多,且独立工作,缺少统一管理,维护FAT AP十分麻烦,因此,对企业而言,不推荐使用FAT AP架构。1.7.2 AC+FIT架构(瘦AP)AC:负责WLAN的接入控制、转发和统计、AP的配置监控、漫游管理、AP的网管代理、安全控制。FIT AP:负责802.11报文的加解密、802.11物理层功能、接受AC的管理、空口的统计等。AC和AP之间使用的通信协议是CAPWAP相比于FAT AP架构,AC+FIT架构配置和部署更容易、安全性更高、更新和扩展容易。(升级和扩展仅需在AC上操作一次,非常容易)1.7.3 瘦AP组网方式二层与三层组网:二层组网:AC与AP在同一广播域,AP通过本地广播可以找到AC,这种方式组网、配置、管理简单,适用于小范围组网,小型企业网络,不适合大型企业复杂、精细化的WLAN组网。建议:AP不超过200台可以考虑本组网方式。三层组网:AC与AP不在同一网段,中间网络必须保证AP与AC之间路由可达,需要进行额外配置才能使得AP发现AC,组网灵活、易扩展。这种方式适用于中、大型网络,以大型园区为例,每栋楼都会部署AP进行无线覆盖,AC仅放在核心机房进行统一管控,这样AC和FIT AP间必须采用较为复杂的三层网络。直连式与旁挂式组网:直连式组网:AC同时扮演无线控制器和汇聚交换机功能,AP数据业务和管理业务都由AC集中转发和处理,适用于中小规模网络部署。同时负担有线、无线网络数据,压力较大,不建议使用。旁挂式组网:旁挂式组网是指旁挂在现有网络,仅处理AP的管理业务,不做AP的数据业务处理,适用于网络改造、新建大、中型园区网络场景。CAPWAP协议CAPWAP(无线接入点控制和配置协议):本协议定义了如何对AP进行管理、业务配置,即AC通过CAPWAP隧道来实现对AP的集中管控。CAPWAP隧道功能:1、AP对AC的自动发现2、AP与AC间的状态维护3、AC通过CAPWAP隧道对AP进行管理,业务配置下发4、采用隧道转发模式时,AP将STA发出的数据通过CAPWAP隧道实现与AC间的交互。数据转发方式:1、 直接转发:用户数据报文到达AP后,不经过CAPWAP隧道封装而直接转发到上层网络,AC只对AP进行管理,业务数据都是由本地直接转发。优势:数据流量不经过AC,AC负担小,万兆园区网推荐方案。2、 隧道转发:业务数据报文由AP统一封装后到达AC实现转发,AC不但进行对AP管理,还作为AP流量的转发枢纽。用户的数据报文经过CAPWAP隧道封装后,再有AC转发到上层网络。优势:数据流和管理流全部经过AC,可以更容易对无线用户实施安全控制策略。流量从汇聚在进入AC,大流量建议使用直接转发的方式。AC+FIT AP 组网特点对比1.7.4 VLAN与IP规划WLAN中VLAN分:管理VLAN和业务VLAN,管理VLAN负责传输CAPWAP隧道转发的报文,包括管理报文和CAPWAP隧道转发的业务数据报文;而业务VLAN负责传输业务数据报文,业务VLAN可以划分成多个,20个跑A部门,30个跑B部门,还可以基于业务性质、基于员工级别划分需要注意的是,管理VLAN和业务VLAN分离,业务VLAN应该根据实际业务与SSID匹配映射关系。1.7.5 业务VLAN和SSID的映射关系SSID : VLAN = 1 : 1企业需对区域A和区域B进行WLAN覆盖,希望用户搜索到1个SSID,并采用相同的数据转发控制策略,则SSID和VLAN只需要规划一个。SSID : VLAN = 1 :N企业需要对区域A和区域B进行WLAN覆盖,希望用户搜索到WLAN只有1个SSID,同时采用不同的数据转发控制策略,则可规划一个SSID,两个VLAN对应不同区域,此时,SSID : VLAN = 1 : 2。SSID : VLAN = N : M企业需要对区域A和B进行WLAN覆盖,用户搜索到WLAN即可了解地点信息等,同时采用不同的数据转发控制策略,则可规划两个SSID,两个VLAN。1.7.6 IP地址规划AC的源IP:用于管理AP,一般由手工配置,AP的IP地址,用于AC进行CAPWAP通信,由于AP数量较多,一般使用DHCP服务器动态分配地址,终端IP,建议用DHCP分配地址,对固定无线终端(如无线打印机)可以静态配置。
  • [技术干货] RESTful与WebService的区别
    REST是一种架构风格,其核心是面向资源,遵循CRUD原则,这个原则告诉我们对于资源只需要4种行为,分别是:创建,获取,更新和删除,并且这些资源执行的操作时通过HTTP协议规定的而WebService底层是SOAP协议,核心是面向活动,有严格的规范和标准,包括安全,事务等方面
  • [交流分享] 网络基础知识——现代网络实态
    1、网络的构成:在计算机网络中类似高速公路的部分,人们称为“骨干”或“核心”。它们是计算机网络的中心,通常选用高速路由器相互连接使之快速传输大量数据。网络中相应于高速公路出入口的部分被称作“边缘网络”(是一个松散的概念,可以理解为涉及接入层和汇聚层的网络)。常用的设备有多功能路由器(在路由器的基本功能之上增加了按顺序/种类发送数据的功能,可以根据TCP/IP层的协议变换处理方法)和3层交换机。计算机网络中连接“边缘网络”的部分叫做“接入层”或“汇聚层”。这样,骨干网可以专注于如何提高业务传输性能和网络的生存性,而将具有业务智能化的高速路由器和交换机移到网络的边缘。边缘网路的常用设备多为2层交换机或3层交换机。当计算机网络中发生网络拥堵、传输时慢时快的现象时,可以通过增加通信电缆扩大物理层。然而计算机的网络通信不仅仅在物理路线上进行,还会在其上层的逻辑信道上进行传输。正因如此,如果在搭建网络的时候事先做好准备,就可以根据虚拟逻辑信道,按需调整宽度。2、互联网通信:人们在家里或公司连接互联网时,一般会使用互联网接入服务。联网之后,汇集到无线局域网路由器和最近交换机的通信会再次被连接到前面提到的“接入层”。甚至还有可能通过”边缘网络“或”主干网“实现与目标地址之间的通信。3、移动通信:手机一开机,就会自动与距离最近的基站发生无线通信。基站上设有特定手机基站天线,基地本身也相当于网络的“接入层”。基站收集的通信请求被汇集到控制中心(“边缘网络”),之后会再被接入到互连通信控制中心的主干网。LTE与语音呼叫:LTE(长期演进技术)被视作从3G向4G演变的过渡型技术,是3GPP(由各国标准化制定团体组成的制定第3代移动通信标准的组织)制定的一种移动通信规范。它是最大下行300Mbps、上行75Mbps的无线通信。在LTE的标准中,由于声音也被当作IP数据包进行传输(现在,语音通信也基本被数字化,都使用TCP/IP技术进行传输),所以就有必要在整个网络上应用TCP/IP协议。而对于老的硬件设备,可采用CSFB(Circuit Switched FallBack,电路交换回退)技术。这种技术让语音呼叫仅在手机通信网络中传输。使之保持与原来的语音呼叫处理一致。4、从信息发布者的角度看网络:信息发布者通过网络将信息发布到服务器,为了减少访问的延迟,会集合多个存储于一起,通过连接高速网络,以期提高响应速度。这种方式被人们称作数据中心。数据中心由大型服务器、存储以及计算机网络构成。有些大型的数据中心甚至直接连接“主干网”。即使小规模的数据中心,大多数情况下会连接到“边缘网络”。虚拟化和云:利用软件将一些物理设备虚拟化,在有必要增减资源的时候,通过软件按量增减的一种机制。通过此机制实现按需分配、按比例分配,对外提供可靠服务。利用虚拟化技术,根据使用者的情况动态调整必要资源的机制被人们称作“云”。而且,将虚拟化的系统根据需要自动地进行动态管理地部分被称作“智能协调层”。
  • [实例分享] 物联网中几个常用协议总结
    物联网中几个常用协议总结一、HTTP      HTTP ( HyperText Transfer Protocol,超文本传输协议)是用于从 WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效,使网络传输减少。它不仅保证计算机正确快速地传输超文本文档,还确定传输文档中的哪一部分,以及哪部分内容首先显示(如文本先于图形)等。      HTTP是一个应用层协议,由请求和响应构成,是一个标准的客户端服务器模型。      同时HTTP是一个无状态的协议。同一个客户端的这次请求和上次请求是没有对应关系,对http服务器来说,它并不知道这两个请求来自同一个客户端。为了解决这个问题,Web程序引入了Cookie机制来维护状态。      并且HTTP是一种同步协议。客户端需要等待服务器响应。Web浏览器具有这样的要求,但它的代价是牺牲了可伸缩性。在 loT领域,大量设备以及很可能不可靠或高延迟的网络使得同步通信成为问题。异步消息协议更适合loT应用程序。传感器发送读数,让网络确定将其传送到目标设备和服务的最佳路线和时间。      HTTP是一种有许多标头和规则的重量级协议。它不适合受限的网络。建立过程中三次握手:SYN:同步;Seq:序号;ACK:确认;ack:确认序号(1)第一次握手:      当客户端想与服务器建立连接的时候,会发送一个请求连接的报文,此报文首部中的SYN=1(TCP规定,SYN= 1的报文段不能携带数据,并且需要消耗一个序号),同时随机生成初始序列号Seq=X,客户端进入了SYN-SENT(同步以发送状态)。(2)第二次握手:      服务器接收到客户端发送的连接请求报文后,如果同意连接,则发出确认报文,其中确认报文段中SYN=1,ACK=1,同时随机初始化一个序列号Seq=Y,确认号ack=X+1,而且服务器也进入SYN_RCVD(同步接收状态)。(3)第三次握手:      客户端接收到确认报文后,还需要向服务器发出确认报文。确认报文的ACK=1,ack=Y+1,此时,TCP连接建立成功,客户端进入ESTABLISHED(已建立连接)状态。三次握手的重要性:      当客户端发送第一个请求连接的报文的时候,由于网络阻塞原因,导致服务端不能及时收到,直到某个时刻才收到请求连接的报文,此时此刻服务器收到的已经是一个失效的报文了,服务器给客户端发送确认报文,等待客户端的连接,假设采用的是两次握手,客户端不理睬服务器发送的确认报文,而服务器一直等待接收客户端的请求,这样导致服务器很多资源浪费,而如果采用三次握手,服务器接收不到客户端的确认报文,就会断开与客户端的连接,因此采用三次握手更为合适。二、MQTT      MQTT (Message Queuing Telemetry Transport,消息队列遥测传输),是IBM开发的一个即时通讯协议。MQTT协议采用订阅/发布的工作模式,客户端向服务器订阅感兴趣的信息,服务器把信息推送给订阅了这类信息的客户端。MQTT的特点:协议简单,轻量级(消息可以短至两个字节,对终端的硬件配置要求低,适用于CPU等硬件资源有限的场合,有助于降低终端成本,推动产业发展)。基于TCP/IP,消息传递可靠。使用长连接,有心跳保活机制,减少重新建链开销。支持消息实时通知、有丰富的推送内容。心跳机制不利于设备进入休眠模式,设备比较耗电。MQTT的特点非常符合无线传感网、物联网等领域的要求,目前智慧家庭解决方案主要就是用的MQTT协议。客户端(Client):包括发布者或订阅者,两者都是MQTT客户端,分别负责发布或订阅。可以是从微控制器到一个完全成熟的服务器,在设备上运行着MQTT库并且可以通过任何网络连接到MQTT代理服务器。代理服务器(Broker):是任何发布/订阅协议的核心,可以处理多达成千上万的MQTT客户端的并发连接。代理服务器主要负责接收所有消息,将消息发送给所有订阅的客户端。一个职责是保持所有持续连接的客户端的会话,包括订阅和丢失的消息,另一个职责是对窖户端的认证和授权。三、CoAP    CoAP ( Constrained Application Protocol,受限制的应用协议),专门为资源受限设备(如传感器节点)和网络(如NB-loT,LoRa)而设计。CoAP 从 HTTP协议发展而来,CoAP协议也是采用请求/响应工作模式,客户端发起请求,服务器做出响应。为了克服 HTTP对于受限环境的劣势,CoAP既考虑到数据报长度的最优化,又考虑到提供可靠通信。
  • [技术干货] Netconf协议学习第二期
    Netconf建模语言:Schema:Schema是为了描述XML文档而定义的一套规则。Schema文件中定义了设备所有管理对象,以及管理对象的层次关系、读写属性和约束条件。设备通过Schema文件向网管提供配置和管理设备的接口。Schema文件类似于SNMP的MIB文件。YANG:YANG是专门为NETCONF协议设计的数据建模语言,用来为NETCONF协议设计可操作的配置数据、状态数据模型、远程调用(RPCs)模型和通知机制等。YANG数据模型定位为一个面向机器的模型接口,明确定义数据结构及其约束,可以更灵活、更完整的进行数据描述。NETCONF Client和Server之间使用RPC机制进行通信。Client必须和Server成功建立一个安全的、面向连接的会话才能进行通信。Client向Server发送一个RPC请求,Server处理完用户请求后,给Client发送一个回应消息。Client的RPC请求和Server的回应消息全部使用XML编码。NETCONF协议提供了定义capabilities语法语意规范,协议允许Client与Server交互各自支持的capabilities,Client只能发送Server支持的capabilities范围内的操作请求。XML编码:XML作为NETCONF协议的编码格式,用文本文件表示复杂的层次化数据,即支持使用传统的文本编译工具,也支持使用XML专用的编辑工具读取、保存和操作配置数据。基于XML网络管理的主要思想是利用XML的强大数据表示能力,使用XML描述被管理数据和管理操作,使管理信息成为计算机可以理解的数据库,提高计算机对网络管理数据的处理能力,从而提高网络管理能力。XML编码格式文件头为<?xml version="1.0" encoding="UTF-8"?>,其中:<?:表示一条指令的开始。xml:表示此文件是XML文件。version:NETCONF协议版本号。"1.0"表示使用XML1.0标准版本。encoding:字符集编码格式,当前仅支持UTF-8编码。?>:表示一条指令的结束。RPC模式:NETCONF协议使用RPC通信模式,采用XML编码的和元素提供独立于传输层协议的请求和回应消息框架。能力集(Capabliity):NETCONF能力集是补充基本NETCONF规范的一组功能。 该能力由统一资源标识符(URI)标识。能力集扩展了设备的基本操作,描述了附加操作和操作中允许的内容。客户端可以发现服务器的功能,并使用由这些能力集定义的任何其他操作,参数和内容。能力集定义可以命名一个或多个依赖的能力集。 为了支持一种能力集,服务器必须支持它所依赖的任何能力集。
总条数:516 到第
上滑加载中