我个人近期遇到了一个问题，正如标题所说“关于Win11系统PC连上WiFi后能正常使用各大App，但浏览器无法正常上网访问”，这个bug困扰过不少开发者，今天来简单分享一下解决办法小伙伴们可能也遇到过类似的情况，就是电脑明明连上wifi了，并且wifi正常可用、显示有Internet，可以使用QQ、WX等App，但是打开浏览器还是无法正常访问网址，这类问题也同样困扰我很久了，在多番询问身边的大佬、资深同行后才找到了解决办法。出现这类问题的原因就是自身PC的网络代理被恶意篡改了，我们首先需要鼠标右击wifi图标，进入网络和Internet设置。接着下滑找到代理，然后进入代理。进入后大家可以看到自动检测、脚本设置、手动代理，目前我的这三个都已经被恶意篡改了，大家如果有类似问题那说明至少有一个设置被恶意篡改了，我们就需要把它手动调整回来。第一步我们先把自动检测关闭；第二步我们把脚本设置关闭并保存；第三步我们把手动代理关闭并保存；全部关闭之后应该像上图这样。然后不出意外情况的话我们就可以正常上网啦，今天就暂时分享到这里，谢谢大家~

 TCP/IP协议 应用层协议 自定义应用层协议 为啥要自定义协议？ 当前的应用程序要解决的业务场景是错综复杂的，不同的公司有不同的业务，不同的业务有不同的流程，业务复杂，要用程序来解决这个复杂的业务，程序也就复杂了。因此很难有一个通用的协议满足所有的业务需求。  怎样进行自定义协议？ 1)结合需求，分析清楚请求响应(客户端服务器之间)要传递哪些信息  2)明确传递的信息是以什么样的格式来组织  可选的方案是很多的。  约定好协议得格式内容之后，客户端就能够按照这个格式构造数据并发送，服务器按照这个格式解析处理。  约定的协议的内容(传递的信息)是和业务相关性非常大的。但是协议的数据组织的格式(传递的格式)和业务关系不大.  典型的用来组织数据的格式：  XML 标签化的数据组织格式。使用标签来表示键值对，以及树形结构  开始标签和结束标签需要成对出现，标签中间的部分就是标签的内容，内容可以是数字，字符串，还可以嵌套放别的标签。  HTML 是 XML 的特殊情况  XML中标签名字叫啥都是自定义的  json  上述 xml 和 json 都是按照文本的方式来组织的，  优点是可读性好，用户不需要借助其他工具，肉眼能看懂。  缺点是效率不高，占用较多的网络带宽。  xml 要额外传很多标签，json 要额外传很多的key  protobuffer (谷歌) 二进制的表示数据的方式，针对上述的数据信息，通过二进制的形式进行压缩表示了。  特点是肉眼观察不了(二进制直接用记事本打开乱码)，但是占用空间小了，占用的带宽也就降低了。  DNS 域名解析系统  域名，网址。  eg：www.baidu.com  要访问网络上的服务器，需要 IP 地址。IP地址不好记，于是就使用一些简单的字符串来表示这个地址。  每个域名都对应了 1/N 个IP 地址。   最原始的做法，是使用一个 hosts 文件  C:\Windows\System32\drivers\etc  像 hash 表一样，建立了 IP 和域名之间的映射关系，当然现在打开 hosts 文件，基本都是空的， # 表示注释  当访问某个域名的时候，就自动请求下 DNS 服务器，DNS 就会进行查询，将得到的结果(具体的 IP 地址)返回给你。  如果你电脑的 DNS 服务器配置的不对，或者 DNS 服务器挂了，此时就会出现一个典型的现象：QQ 能用，但是网页打不开。  当前要求网站的域名不能重复(保证唯一)。  全世界这么多网站，如何保证唯一呢？ 一级域名，二级域名，三级域名…  pic.sogou.com  .com(公司) 一级域名，类似的一级域名还有 org，cn，us…  sogou 二级域名，表示 搜狗这个公司  pic 三级域名  域名分级了，DNS 服务器也是分级了，有 一级域名 的 DNS 服务器，还有 二级域名，三级域名…  一般常见的就是 三级，四级左右。  www.  具体 www 算 三级还是 四级还是 五级，看域名具体咋写的，  www 是"万维网"的缩写，我们现在使用的这个网络就是 万维网  传输层协议 端口号 端口号：数据库 mysql 默认端口 3306。  端口号起到的效果就是区分一个主机上的具体的应用程序。  所以，同一台主机上，一个端口号不能被多个进程绑定。  使用 IP 地址来区分主机。  eg ：进程 A 绑定了 3306，此时进程 B 也尝试绑定 3306，进程 B 绑定操作就会失败 (抛异常)  端口号是传输层协议的概念，TCP 和 UDP 协议的报头中都会包含 源端口 和 目的端口。  TCP 和 UDP 都是用 2 个字节，16 个 bit 位来表示端口号的，一个端口号的取值范围：0 ~ 65535  最初学习 C 语言，就得知道不同长度字节数表示的数据范围。  1 个字节，8 bit , -128 ~ 127 128 就是 2 ^ 7, 127 就是 2 ^ 7 - 1  ​ 0 ~ 255 255 就是 2 ^ 8 - 1  2 个字节 , 16 bit, -32768 ~ 32767 32768 就是 2 ^ 15  ​ 0 ~ 65535 65535 就是 2 ^ 16 - 1  4 个字节，32 bit， -21亿 ~ 21亿  ​ 0 ~ 42 亿 9 千万  但是自己写程序，绑定的端口号，得是从1024 起的。  0 ~ 1023 这个范围的端口称为"知名端口号/具名端口号"，这些端口号已经分配给了一些知名的广泛使用的应用程序了。  那么我写代码就非要指定 0 ~ 1023 的端口号，行不行呢 ?  1.先确定你这个端口号没有被别的程序绑定  2.你有管理员权限  1023 以下的端口，也不是完全不能用，只是不建议，这些端口虽然被分配给了特定程序，但是这个程序是否在你电脑上运行着，电脑上是否安装了这些程序都是不一定的。  UDP协议 UDP 的特点：无连接，不可靠传输，面向数据报，全双工。  不可靠传输：没有任何安全机制，发送端发送数据报以后，如果因为网络故障该段无法发到对方，UDP协议层也不会 给应用层返回任何错误信息。  UDP协议端格式  UDP 协议报文结构，这张图，任何一个计算机网络的教科书上都有，而且都是这么画的，但是实际上这么画不够严谨(为了书排版方便，变形了)   UDP 就会把载荷数据(就是通过 UDP socket ，也就是 send 方法拿来的数据)再在前面拼装上几个字节的报头,相当于字符串拼接(此处是二进制的，不是文本的)  UDP 报头里包含了一些特定的属性，携带了一些重要的信息。不同的协议功能不同，报头中的属性信息不同。  对于 UDP 来说，报头 一共 8 个字节，分成 4 个部分(每部分 2 字节)  UDP 报文长度 这个长度也是用 2 个字节表示的，2 个字节表示的范围是 0 ~ 65535(64 KB).  也就是说一个 UDP 数据报只能传输 64 KB 的数据。  报文长度是整个报文的长度，不是载荷长度。  如果 应用层数据报超过 64 KB ，怎么办？  方案 1: 就需要在应用层，通过代码的方式针对应用层数据报进行手动的分包，拆成多个包通过多个 UDP 数据报进行传输(本来是 send 一次，现在需要 send 多次了)  方案2：不用 UDP 了，换成 TCP(TCP 没有这样的限制)  校验和 作用是验证传输的数据是否是正确的。  网络传输，本质上就是光信号/电信号，这些可能会受到一些物理环境的影响(电场/磁场/高能射线)，在这些干扰下可能会出现"比特翻转"的情况。(1->0，0->1)  一旦数据变了，对于数据的含义可能是致命的。  这种现象是客观存在的，不可避免，我们要做的就是及时识别出当前数据是否出现问题。  校验和是针对数据内容进行一系列数学运算，得到一个比较短的结果(2 个字节)。  如果数据内容一定，校验和结果就一定；如果数据变了，得到的校验和结果就变了。   是否有这样的情况，假设数据传输中出错了，但是计算的 校验和 和之前的 校验和 恰好一样？  “要发射导弹” => 0xaabb  “不要发射导弹” => 0xaabb  这个情况理论上存在，工程上出现这种情况的概率极小，忽略不计了。  如果内容相同，得到的校验和一定相同；  如果校验和相同，内容不一定相同(小概率事件)  实际网络传输过程中，往往是把数据的所有字节都参与生成校验和的运算，这样任何一个字节出问题就都能发现了。  针对网络传输的数据来说，生成校验和的算法有很多种。其中比较知名的有几个。  CRC 循环冗余校验，把数据的每个字节，循环往上累加，如果累加溢出了，高位就不要了。  好酸但是校验结果不理想，如果数据同时变动了 2 个 bit 位，前一个字节少 1 后一个字节 多 1 这种，就会出现内容变了但是校验和没变这种情况。  MD5 MD5 不是简单的相加，有一系列公式来进行更加复杂的数学运算。  MD5算法的特点：  1)定长：无论原始数据多长，得到的 MD5都是固定长度(4/8字节)  2)冲突概率很小：原始数据哪怕只变动一个地方，算出的 MD5 都会差别很大(让 MD5 值更分散了)  3)不可逆：通过原始数据计算 MD5 很容易，通过 MD5 还原成原始数据很难，理论上是不可实现的(计算极大)  MD5 的这些特点使得 MD5 作用更多了：校验和，作为计算 hash 值的方式，加密  SHA1 SHA1的特点和 MD5 相同，区别是计算方式不同。  TCP协议 特点是有连接，可靠传输，面向字节流，全双工。  这里的可靠传输是 TCP 的内部机制，和编码关系不大。  TCP协议段格式  4位首部长度 TCP 报文 = TCP 报头(首部) header + TCP 载荷 payload/body  一个TCP 报头长度是可变的，不是像 UDP 报头固定是 8 个字节  选项 option (选项) ， optional (可选的，可有可无的)  此处的选项是对 TCP 报文的一些属性进行解释说明的。  首部长度描述了 TCP 报头有多长，选项之前的长度是固定的(20 字节)，首部长度 - 20 = 选项长度  首部长度的单位是 4 字节，  如果首部长度值是 5，表示整个 TCP 报头长度是 20 字节，没有选项；  如果首部长度值是 15 ，表示整个 TCP 报头长度是 60 字节，选项长度是 40 字节  保留( 6 位) reserved  C 语言中，有一类单词，叫做关键字，除了关键字之外，还有一些单词，叫做保留字。  保留字就是现在还没使用，但是保不齐以后要是用，所以现在这占个位置你现在先别用  咱们进行程序开发的时候，其中一个重点考虑的事情就是可扩展性，有些功能可能暂时不需要，保不齐未来需要  16 位检验和 和 UDP 校验和同理  TCP工作机制 TCP 是一个复杂的协议，里面有很多机制，这里主要讨论 TCP 提供的 10 个比较核心的机制。  确认应答(安全机制) TCP 是可靠传输。  可靠，不是说发送方 100% 能把消息发给接收方，而是尽可能把数据传过去，发送方能知道自己的消息是发过去了还是丢了。  确认应答是实现可靠传输的最核心机制。  举个栗子：  张三在追一个女生，有一天张三给女生发消息说"我请你吃饭好嘛？“女生回复他说"好啊”。  当张三收到"好啊"的时候，说明张三发的消息已经顺利被女生看到了(没有丢包)  如果过了好久张三没收到女生的回应，说明丢包了(也可能是已读不回doge)  这里女生回复的"好啊"就称为"应答报文"，也叫作 ack(acknowledge)  TCP 进行可靠性传输，最主要考的就是这个确认应答机制。  A 给 B 发了个消息，B 收到之后就会返回一个 应答报文(ACK)，此时 A 收到应答之后就知道刚才发的数据已经顺利到达 B 了。  考虑更复杂的情况(发送方发多条消息)：   张三可能连续发 2 条消息，张三没等第 1 条消息的回应就发了第 2 条消息。  网络上可能存在"后发先至"的情况，这个情况下收到消息的顺序可能是有变数的。   由于"后发先至"，张三先收到了"滚"，后收到了"好啊"。  很明显这里应答错乱导致出现歧义。  网络中数据的"先发后至"，两个主机之间，路线存在多条，数据报1和数据报2走的都是不同的路线，数据报1的转发路径上的交换机/路由器和数据报2也不一样，有的转发速率快有的转发速率慢，此时这2 个数据报的到达顺序可能会有变数。  网络中的"后发先至"是客观存在的，因此应答报文到达的顺序也是存在变数的，此时就需要考虑如何规避这种顺序错乱带来的歧义。  解决办法是给传输的数据和应答报文都进行编号。  “后发先至”：  eg: 结婚时候新郎的车队可能会后发先至  32位序号/确认序号  引入序号之后就不怕顺序错乱了，即使顺序上乱了，也可以通过序号来区分当前应答报文是针对哪个数据进行的。  任何一条数据(包括应答报文)都是有序号的，确认序号则是只有应答报文有(普通报文确认序号里的值无意义)。  报文是否是应答报文，取决于6个标志位中的 ACK，如果 ACK 这个标志位为 1 ，表示是应答报文，如果为 0 表示不是应答报文。   应答报文的序号仅仅是一个身份标识，不需要应答 应答报文，要是应答 应答报文就无限套娃了…  TCP 的序号是按照字节来编写的。   这一条数据是 1000 个字节，假设是从 1 开始编号，此时第一个字节序号就是 1，第 2 个字节序号就是 2…但是由于这 1000 个字节都属于同一个 TCP 报文，TCP 报头里就只记录当前的第1 个字节的序号，此处报头的序号写的是 1。接下来发第 2 条数据，此时第 2 个TCP 数据报的第 1 个字节序号是 1001，如果长度是 1000，此时最后一个字节序号是 2000，这1001~2000都属于一个 TCP 数据报，那么这个TCP 数据报报头的序号就是 1001。  TCP 的字节的序号是依次累加的，这个依次累加的过程对于后一条数据的第 1 个字节序号就是上一条数据的最后一个字节序号再加 1 。每个 TCP 数据报报头只需要填写 TCP 数据 第 1 个字节的序号即可。  TCP 知道了第 1 个字节的序号，再结合报文的长度就可以知道每个字节的序号。  确认序号的取值，是收到的数据的最后一个字节 + 1。  如上图，确认序号写的是 1001，就是在 1000的基础上 +1。  表示的含义：  < 1001的数据都已经确认收到了。 主机 A 接下来应该从 1001 这个序号开始继续发送 总结：TCP 的可靠传输，最主要就是通过确认应答来保证的，通过应答报文，就可以让发送方清楚地知道传输是否成功，进一步引入了序号和确认序号，针对多组数据进行区分。  超时重传(安全机制) 前面讨论确认应答，只是讨论了顺利传输的情况。如果丢包了呢？  丢包，涉及 2 种情况：  1.发的数据丢了  2.返回的 ack 丢了   发送方看到的结果就是没有收到 ack ，不能区分是哪一种情况。  丢包是一个概率性事件，通常情况下丢包的概率是很小的，因此如果重新发一遍这个数据还是有很大可能传输成功的。  因此 TCP 就引入了 重传机制。  在丢包的时候，重新传一遍数据。  到底这次传输是丢包了，还是 ack 传的慢？  TCP 就引入了时间阈值。  发送方发出数据后，就会等待 ACK，此时开始计时。只要超过了这个时间，不管是丢包了还是 ack 在路上都视为是丢包了。  比如寒假作业，没带等于没写，虽然你写了，你超过了这个规定提交时间就当做没写处理。  超时重传：超过一定时间还没响应就重新传输。  这个超时时间具体是多少 ms ，因为这个时间是可配置的，不同系统上的默认值可能都存在差别。  如果是 ack 丢了这种情况  对于主机 B 来说，1~1000 就收到了 2 次，如果你发的这个数据是一个支付请求？(寄了)  TCP 对于这种重复数据的传输，是有去重处理的，  TCP 存在一个"接收缓冲区"这样的存储空间(接收方操作系统内核里的一段内存)，  每个 TCP socket 对象都有一个接收缓冲区(其实也有一个发送缓冲区)  主机 B 收到主机 A 的数据  其实是 B 的网卡读到数据了，然后把这个数据放到 B 的对应 socket 的接收缓冲区(想象成阻塞队列)，后续应用程序使用 getInputStream，进一步使用 read，从接收缓冲区里读数据。  在接收缓冲区里，根据数据的序号，TCP 很容易识别当前接收缓冲区里的这 2 条数据是否是重复的，如果重复就把后来的数据丢弃，保证 应用程序调用 read 读到的数据一定是不重复的。  去重可以理解为是一个优先级队列，有序队列。  前面说了，网络上传输的数据可能"后发先至", TCP 利用这个接收缓冲区，对收到的数据重新进行排序，是应用程序 read 的数据都是有序的(保证和发送顺序一致）  根据序号排序，序号相同就去重  eg：结婚当天新郎的车队出现"后发先至"，然后车队都到了新娘家门口的时候要整队，排序  这时候我们可以利用前面提到的序列号，就可以很容易做到去重的效果。  总结：由于去重和重新排序机制的存在，发送方只要发现 ACK 没有及时到达，就会重传数据，即使重复了，即使数据乱了，接收方都能去重和排序(依赖 TCP 报头的序号)。  重传的数据是否可能又丢包了呢？ 有可能，超时重传可能传多次，如果重传好几次都没传过去，此时再重传意义不大了。  从数学角度来理解：  假设一次传输丢包概率是 10%，传输成功概率是 90%；  如果第1次传输丢包，第 2 次传输也丢包了，概率是 10% * 10% = 1%  如果 3 次都丢了，概率是 0.1%  连续重传都丢包，此时的概率原则上讲是非常低的，如果这个情况真的出现了，只能说明此时丢包概率远远不止 10% => 你当前网络出现重大故障  因此，重传达到一定次数时，就不会继续重传，会认为网络出现故障。  接下来 TCP 会尝试 重置连接(相当于断开重连)，如果重置还是失败就彻底断开连接了。  具体重传几次 N，也是可配置的，不去研究  重传的时候，第 1 次重传和第 2 次重传，超时时间间隔不一样。一般来说，重传轮次越大，超时时间间隔就越大。超时时间越大，重传频率就越低。(因为重传次数越多，说明重传成功概率越低，此时你重传的太快也是白浪费系统资源)  总结：可靠传输是 TCP 最核心的部分，TCP 的可靠传输就是通过 确认应答 + 超时重传来体现的。其中确认应答描述的是传输顺利的情况；而超时重传描述的传输出现问题的情况。  连接管理(安全机制)  什么是断开连接？  A 和 B 把自己存储的连接信息(数据结构)删除了，连接就断开了。  JDBC 是基于 TCP 建立的连接  连接(Connection)  链接(Link) 快捷方式，比如电脑开始菜单的图标就是快捷方式，比如我想打开 QQ，QQ本来是 在 C 盘某个目录里，我每次打开 QQ 都要到这个目录去找未免太麻烦所以就创建一个快捷方式，这个快捷方式就是一个文件，这个文件里保存了这个可执行文件的真实路径  管理：  就是描述了连接如何创建，如何断开。  TCP 三次握手和四次挥手  滑动窗口(效率机制) 确认应答，超时重传，连接管理，都是给 TCP 可靠性提供的支持。  引入了可靠性，也付出了相应的"代价"(传输效率)  可靠性和效率是冲突的。  因此 UDP 虽然没有 可靠性，但是传输效率比 TCP 高  所以 TCP 在竭尽可能的提高传输效率(本质上是补救措施)。再怎么提高，也不可能比 UDP 这种不考虑可靠性的效率高。  滑动窗口本质上是降低了确认应答，等待 ACK 消耗的时间。  在进行 IO 操作的时候，其实时间成本主要是 2 个部分： 1.等  2.数据传输(数据拷贝)  大多数情况下，IO 操作消耗的时间大部分在"等"上面  举个栗子： 放寒假从学校回家，如果两地比较远，坐飞机回家的情况下。  真正坐飞机的时间很短，但是因为机场一般离市区很远，从学校到机场要花时间，到了机场后换登机牌、托运行李、安检、候机又要花上不少时间，飞机到达目的地，取行李，从机场到家里又要花上不少时间。  这里真正坐飞机的时间就相当于 数据传输的时间，较短。  而其他花在路上的时间，等待时间，比较长。  具体怎么缩短？ 批量发送，批量等待，把多份等待时间合并成一份。   滑动窗口的本质就是不等待的批量发送一组数据，然后使用一份等待时间来等待一组数据的多个 ack。  举个例子：  我打算去买肉夹馍，炒饭，烤肠。  方案一：先去买肉夹馍，肉夹馍做好了，再去买炒饭，炒饭做好了，再去买烤肠。  方案二：先去买肉夹馍，不等了立即去买炒饭，也不等立即去买烤肠。  方案一就是用了 3 份等待时间，而方案二只用了 1 份等待时间  把不需要等待，就能直接发送数据的最大的量，叫做"窗口大小"。上面第 2张图里"窗口大小"就是 4000。  当批量发送了 窗口大小的这些数据之后，发送方就要等待 ack 了。  啥时候往下发送？等待啥时候结束？ 不是说等所有的 ack 都到达才往下发，而是收到一条 ack 就往下发 1 条。(这样就让我们等待的 ack 始终都是 4 条)   在上述情况下，如果丢包了咋办？  ack 丢了   上述丢包重传的机制，叫做 “快速重传”(重传操作只重传了丢失的数据)  这个可以视为是 超时重传 机制在滑动窗口下的变形。  如果当前传输数据密集，按照滑动窗口的方式传输，此时就按照快速重传来处理丢包；  如果当前传输数据稀疏，不再按照滑动窗口的方式传输，此时就按照之前的超时重传来处理丢包。  流量控制(安全机制) 是一种干预发送的窗口大小的机制。  滑动窗口，窗口越大，传输效率越高(一份时间等的 ack 越多)。  但是窗口也不能无限大  1.完全不等 ack ， 可靠性难以保证  2.窗口太大也会消耗大量的系统资源  3.发送速度太快，接收方接收不过来，发了也白发，接收缓冲区有上限。  接收方的处理能力，是一个重要的约束依据。发送方发的速度不能超过接收方的处理能力。  流量控制就是，根据接收方的处理能力，来协调发送方的发送速率。  如何衡量接收方的处理能力？  一个量化的方法：计算接收方一秒钟能处理多少个字节…(这种方式实现起来有些困难)  更简单的办法：  直接看接收方接收缓冲区里剩余空间的大小。  每次 A 给 B 发了个数据，B 就需要算一下缓存区里剩余空间，然后把这个值，通过 ack 报文返回给 A。  A 就根据这个值来决定接下来发送的速率是多少(窗口大小是多少)   窗口大小 16 位，是否意味着，窗口大小最大是 16 kb ？ 不是！  TCP 为了让窗口更大，在选项部分引入了窗口扩展因子。  比如窗口大小已经是 64 kb，扩展因子里写了个 2 ，意思就是让 64 kb << 2 = 256kb  由于接收方缓存区剩余空间是一直在动态变化的，所以每次返回 ack 带的窗口大小都在变化，发送方也要进行动态调整。   当窗口大小为0，发送方就要暂停发送。暂停发送的等待过程中，会给 B 定期发送窗口探测报文，这个报文不携带具体的业务数据，只是为了触发 ack 查询窗口大小。  拥塞控制(安全机制) 流量控制和拥塞控制共同决定发送方的窗口大小是多少。  流量控制考虑的是接收方的处理能力。  拥塞控制描述的是传输过程中中间节点的处理能力。  木桶效应：一只水桶能装多少水取决于它最短的那块木板。  接收方的处理能力，好量化衡量。但是中间节点不好衡量。  设计 TCP 的大佬们，想出了一个相当 天才的办法，  既然不好直接量化，那么可以通过"实验"的方式，来测试出一个合适的量   拥塞窗口不是固定数值，而是一直动态变化的。随着时间的推移，逐渐到达一个动态平衡的过程。  这样既能够把问题解决，同时也能随着网络的动态变化而动态变化。  拥塞窗口和流量控制窗口，共同决定了发送方实际的发送窗口。(取拥塞窗口和流量控制窗口的较小值)  延时应答(效率机制) 就是在 滑动窗口的基础上，做点别的操作。  收到数据之后，不是立即返回 ack ，而是稍微等会再返回。等待的时间里，接收方的应用程序就能把接收缓存区的数据给消费一些，此时剩余的空间就更大了。   实际上延时应答采取的方式，就是在滑动窗口下，ack 不再每一条数据都返回了，比如上图是隔一条返回一个 ack。  实际上剩余空间大小，既取决于发送方的发送，也取决于接收方的处理。  捎带应答(效率机制) 也是提高效率的一种方式。  在延时应答的基础之上引入的捎带应答。  服务器客户端程序，最典型的模型就是，“一问一答”。业务的请求和响应。   本来是不同时机，在延时应答下，可能成为相同时机，就合并了。  而 TCP 的三次握手本身是相同时机一定会合并，此处是有一定概率合并，此处和四次挥手的合并更像。  延时应答提高了合并的概率。  面向字节流 面向字节流，引入了一件麻烦事，  粘包问题。 举个栗子：   接收缓冲区是把刚才收到的多个数据都放到一起了，应用程序 read 读取的时候，读到哪里才算是一个完整的应用层数据报呢?  由于 TCP 是面向字节流的，可以一次读 1 个字节也可以一次读 N 个字节。  这就导致一次读取的时候，可能读到的是半个应用层数据报，也可能是 1 个应用层数据报，还可能是多个应用层数据报。   应用程序调用 read，  如果 read 的是 7 个字节，此时正好读出的是 aaaaaaa，这是一个完整的应用层数据报；  如果 read 的是 8 个字节，此时正好读出的是 aaaaaaab，这是"一个半"的应用层数据报；  如果 read 的是 6 个字节，此时正好读出的是 aaaaaa，这是半个应用层数据报。  在 TCP 层次，没有在 socket api 中告诉我们要读几个字节，具体怎么读都是人为操作。  期望读到的是整个的应用层数据报，后续才好处理。  解决方案是 ：约定好应用层协议即可，尤其是明确应用层数据报和应用层数据报之间的界限。 1.约定好分隔符  2.约定每个包的长度  二选一即可。  异常情况 传输过程中出现了不可抗力。  1.进程崩溃  2.主机关机(按照正常流程关机)  3.主机掉电  4.网线断开  1 和 2 是一类，3 和 4 是一类。  1.进程崩溃：进程没了，对应的 PCB 没了，对应的 文件描述符表就释放了，相当于 socket.close()。此时内核会继续完成四次挥手，此时仍然是一个正常断开的过程。  2.主机关机：主机关机要先关闭进程，然后才正式关机。(关闭进程的过程中，也和上面一样触发四次挥手)  3.主机掉电：显然是来不及挥手了。  假设是接收方掉电了。发送方仍然在传数据，发完数据要等 ack , ack 等不到…超时重传，再怎么重传还是收不到 ack。重传几次还没有应答，尝试重置 TCP 连接，(复位报文段…RST)。显然这个重置也会失败。放弃连接。(单方面放弃)  如果是发送方掉电。接收方发现没有数据了，没数据是发送方挂了？还是发送方在组织语言要稍等会再发？接收方不知道，先等。接收方需要周期性的给发送方发送一个消息(“心跳包”)，确认下对方是否还工作正常。  心跳包(保活机制) 1.心跳是周期性的；  2.心跳如果没了就是挂了。  心跳包是一个非常常见的机制，分布式系统中还会涉及到心跳包  心跳包来确认通信双方是否工作正常。  4.网线断开：发送方尝试重传，接收方尝试发心跳包。  TCP 是个非常复杂的协议，不仅仅是这 10 个特性，这是 TCP 比较核心的特性。  了解 TCP 更多的特性，应该去翻阅 RFC 文档，翻阅操作系统内核源码  RFC 9293: Transmission Control Protocol (TCP) (ietf.org)  UDP 和 TCP 对比 TCP 的优势在于，可靠传输，绝大部分场景中，都需要可靠传输。  UDP 优势在于，更高效率，如果某些场景对于性能要求更苛刻。  同一个机房内部，服务器之间通信。网络结构相对简单，网络带宽比较充裕，转发设备也是比较好的设备。整体丢包的可能性比较小。  UDP 还有一个优势，天然支持广播。  IP 地址中有一种特殊的地址，“广播 IP”  通过 UDP 往广播 IP 上发送数据，此时该局域网内所有的设备都能够收到数据。  传输层的协议并非只有这 2 个。除了 TCP ，UDP 之外，还有一些其他的传输层协议。有的传输层协议，属于能够专门为游戏场景量身打造的(可靠性 + 效率) , 典型的协议，以 KCP 为代表的一系列协议。  网络层协议 在复杂的网络环境中确定一个合适的路径。  1.地址管理  快递系统要想要建立起来，就需要把世界上的地址能够以一定的规范定义出来。  2.路由选择  规划路径  网络层的代表，IP协议。  IP协议 IP协议报头格式如下：  IPv4协议(v4 版本的意思)  4 位版本 此处的取值只有 2 个。4 或 6。  IPv4，IPv6  4 位首部长度 描述了 IP 报头多长(IP 报头是变长的)  此处的单位也是 4 字节。  IP 报头有一个选项部分，是变长的，是可有可无的。  8 位服务类型(TOS) 说是 8 位，实际上只有 4 位有效，这 4 位中只有 1 位可以是 1，其他的都是 0。  4 位就表示 IP 协议的四种形态/4 种工作模式。  最小延时，最大吞吐量，最高可靠性，最小成本。  最小延时，包裹会最快速度送达。  最大吞吐量，单位时间内你可以送更多的包裹。  最高可靠性，包裹丢的概率是最小的。(和 TCP 的可靠性不是一个概念)  最小成本，让运费最低。  实际开发中就可以根据需要，来切换 IP 的模式，来达到最优的效果。  16位总长度(字节数) 描述了一个 IP 数据报的长度。(头 + 载荷)  这个长度减去 IP 报头长度，剩下的就是载荷长度，就是一个完整的 TCP/UDP 数据报长度。  16 位总长度，是否意味着一个 IP 数据报，最多只能支持 64 KB？ 确实有这个限制，但是 IP 自身就支持对 包的拆分和组装。  举个栗子：  在淘宝上买了个床，快递公司怎么运？把床拆开，以散件的形式发过来，送到了家里，有师傅上门组装。  一个 IP 数据报携带的数据载荷太大了，超过了 64KB，就会在网络层针对数据进行拆分，把一个数据拆分成多个IP 数据报，再分别发送，接收方再重新组装。  比如，发送方：把 100KB 的数据交给传输层(封装)，传输层交给网络层(封装)，网络层就把这个 100KB 的数据拆包，比如拆成两份 64KB + 36KB。这两份再交给数据链路层，由以太网分装成两个数据帧。接收方：数据链路层针对两个数据帧进行分用，得到两个 IP 数据包交给网络层，网络层针对这俩 IP 数据包进行解析，把里面的载荷拼成一个，交给传输层  此处说是 64 KB，实际上 IP 协议拆包不一定就按照64 KB为单位进行拆分，实际的单位往往更小(取决于数据链路层的情况)   8位生存时间(TTL) 一个数据包在网络上能够传输的最大时间。  这个时间的单位不是秒，而是次数  一个数据报构造出来，会有一个初始的 TTL 数值(比如32或者64或者128)这个包每次经过一个路由器转发 TTL - 1，如果一直减到 0 了，还没有到达目标，此时就认为这个报永远都到不了了，就可以丢弃了。  8 位协议 描述了当前载荷部分内容是属于哪个协议的(TCP/UDP)  16 位首部检验和 此处只需要针对首部进行检验。  载荷部分(TCP/UDP数据报)自身已经有校验和了。  如果校验和不一致，直接丢弃  32 位源 IP 地址  32 位目的 IP 地址  此处看到的 IP 地址是 32 位的整数，  而日常见到的 IP 则是一串数字 ， eg：111.183.72.219  点分十进制：使用 3 个"."把32位四个字节的数字给分隔开，分成四个部分，每个部分分别使用0 - 255 十进制整数表示。  地址，期望每个设备都不相同，但是32位数字只能表示42亿9千万个数字.  期望使用这个表示全世界上所有的上网设备。(智能手机，PC，服务器，路由器，其他杂七杂八的网络设备，物联网)  为了解决IP地址不够用的问题，想了很多办法。 动态分配IP地址，此时就可以省下一批 IP 地址，这个方案没有从根本上增加 IP 地址，只是提高了利用率。  NAT 网络地址转换。本质是使用一个 IP 代表一批设备，也能够大大提高 IP 地址的利用率。使用端口号区分。  在NAT的背景下，就把 IP 地址分成两个大类：  1)内网 IP (私有 IP) 10.* 172.16.* - 172.31.* 192.168.*  2)外网 IP (公网IP) 剩下的是公网 IP  NAT要求，公网 IP 必须是唯一的。私网 IP 可以在不同的局域网中重复出现。  如果某个私网里的设备想访问公网设备，就需要对应的 NAT 设备(路由器)，把 IP 地址进行映射，从而完成网络访问。  反之，公网的设备，无法直接访问私网的设备。不同局域网的私网的设备没法直接相互访问。  cmd - ipconfig   内网 IP 只要在局域网内部不重复即可，不同局域网中则是允许重复的。  111.183.72.219 这是一个外网 IP  这些接入运营商路由器的电脑去访问外部服务器，都会被路由器替换成路由器自己的外网 IP 。  此时只要这个电脑是经过运营商路由器转发给服务器，服务器看到的源 IP 就都一样，如果是多个电脑同时访问同一个服务器，服务器的响应就会先发给路由器，路由器根据这些电脑不同的端口号来区分，决定发给哪个设备。  因此，服务器能拿到的只是路由器的 IP 不能拿到我电脑的内网 IP ，如果我电脑不主动和服务器联系，服务器就不知道我的端口，从而无法主动找到我。  NAT机制能够有效的解决 IP 不够用的问题，但是带来的副作用就是网络环境更加复杂了。  IPv6 : 根本上解决了IP不够用的问题。 使用16字节表示IP地址，128位。  16字节表示的地址的个数：(42亿)^4  IPv6 虽然看起来非常好，但是世界上仍然是以 NAT + IPv4 + 动态分配来进行网络组建的，真正使用 IPv6的地方非常非常少。  因为 IPv6 贵，IPv6和IPv4不兼容，如果你想要支持IPv6，就需要更换路由器等网络设备，花钱，这个钱花的就没啥收益。因此大家都不愿意去升级。  IPv6 中国已经普及80%，背后原因  地址管理 IP地址分为两个部分，网络号和主机号。  网络号：标识网段，保证相互连接的两个网段具有不同的标识；  主机号：标识主机，同一网段内，主机之间具有相同的网络号，但是必须有不同的主机号。   一个 IP 地址前面从哪儿到哪儿是网络号，后面从哪儿到哪儿是主机号，分界线是怎么定的？ 有一个单独的概念，  子网掩码   网络号不一定就是前三个字节，都是可以调整变化的。  此处的 255.255.255.0 就是子网掩码。  32位  1111 1111 1111 1111 1111 1111 0000 0000  左侧都是 1，右侧都是 0，1的部分就描述了 IP 有多少位是网络号。  对于家用设备来说，子网掩码最常见的就是 255.255.255.0  将IP地址中的主机地址全部设为0，就成为了网络号，代表这个局域网；192.168.0.0  将IP地址中的主机地址全部设为1，就成为了广播地址，用于给同一个链路中相互连接的所有 主机发送数据包;(192.168.0.255 使用udp往这个地址上发数据报,整个局域网所有设备都能收到)  127.*的IP地址用于本机环回（loop back）测试，通常是127.0.0.1  主机号为 1，比如 192.168.0.1 通常是"网关 IP"(不绝对，都可以配置)  将 IP 地址和子网掩码进行“按位与”操作（二进制相同位，与操作，两个都是1结果为1，否则为0），得到的结果就是网络号。 将子网掩码二进制按位取反，再与 IP 地址位与计算，得到的就是主机号。  路由选择 路由选择就是规划路径。  相当于你使用地图导航一下，由于网络环境非常复杂，任何一个节点(路由器)都是无法感知到网络环境的全貌。一个路由器，最多只认识它的一些"邻居"或者"邻居"的"邻居"，进行一个比较长的路径的转发就比较麻烦，需要一边走一边问。  路由选择，核心思路是"问路"。每个路由器都会保存一定的周围设备的信息(路由表)，每次有一个 IP 数据报经过，路由器就需要匹配路由表，看看接下来咋走，如果路由表上有匹配的项(该路由器认识路)，直接按照要求走就行了；如果没有匹配的项，路由器不认识路会提供一个默认路径，大体方向是不会错的，沿着这个方向继续走，继续问。  每经过一个路由器问一次， TTL- 1，如果减到零了，还没到说明这个包就永远都到不了了，这个地址没人知道了，就被丢弃了。  六度空间理论：你和任何一个陌生人之间所间隔的人不会超过六个，也就是说，最多通过6个中间人你就能够认识任何一个陌生人。  正常情况下，像 32 这样的 TTL 足以让我们把数据报转发给世界上任何一个地址。  数据链路层协议 以太网 以太网帧格式  目的地址，源地址 此处不是用 IP 地址 表示了，而是用 mac 地址。  mac 地址  物理地址。这个是和 IP 地址完全独立的另外一套地址体系。  6 个字节，(比 IPv4 地址大很多)当前每个设备都会有唯一的 mac 地址。不是动态分配的，而是网卡出厂的时候就被设置好了的。   当前 IP 和 mac 是怎么相互配合的？  IP 用来描述整个传输过程的起点终点，mac 则是用来描述两个相邻结点的起点终点。  类型  ARP 协议 通过这个协议，让某个 路由器/交换机 能够认识局域网里的其他设备。通过 ARP 协议会在 路由器/交换机 里建立出一个 表，这个表相当于一个 hash 表，能够建立出 IP 和 mac 之间的映射关系。  MTU MTU 是数据链路层的一个数据帧能够承载数据的最大长度。(载荷长度)   载荷具体多长，和使用的物理介质有很大关系，也和数据链路层使用的协议有关系。比如以太网协议，MTU 1500字节(这个和物理层有很大关系)  正是这个 MTU 引起了 IP 协议拆包组包，IP 协议的分包组包通常不是根据 这个 IP 最大长度 64KB 来分的。大概率情况下，MTU 比 64 KB 小。 ———————————————— 版权声明：本文为CSDN博主「银河罐头」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/qq_63983125/article/details/129271484 

一、使用背景有一些命令的使用上涉及到网络请求，如果运行环境上配置有网络代理，就会因为相关代理问题导致原有请求失败。这时就需要将相关网络代理信息配置到脚本项目中，使相关命令的网络请求带上代理信息，从而请求成功。二、涉及的命令1、OnlineOcrAutoForm, SetOnlineOcrWindow3.3.0版本及以上的Studio中基于在线OCR的自动化部分下的OnlineOcrAutoForm(在线OCR智能表单)SetOnlineOcrWindow(设置在线OCR操作窗口)2、inform.sendSmsHic, inform.voiceCallHic, eSpace.sendMessage3.3.0版本及以上的Studio中华为内部模块消息部分的inform.sendSmsHic(发送短信)inform.voiceCallHic(语言电话)eSpace.sendMessage(使用eSpace应用号发送信息)3、CV.setWindow3.3.0版本及以上的Studio中基于机器视觉自动化模块的通用CV部分的CV.setWindow(设置CV目标窗口)4、Manas引擎部分所有命令3.3.0版本及以上的Studio中人工智能模块Manas引擎部分所有命令图像识别：getpicinfo_online、getIdCardInfoOcr、getTrainTicketInfoOcr、getVatInfoOcr、getMarriageCertificateInfoOcr、getTableInfoOcr自然语言处理：textSegmentationNLP、textKeyWordsNLP、textSimilarityNLP5、企业微信部分所有命令3.3.0版本及以上的Studio中社交软件模块企业微信部分所有命令qywx.get_accesstoken、qywx.send_text_msg、qywx.send_textcard_msg、qywx.send_file_msg、qywx.send_video_msg6、基于selenium驱动创建的浏览器2.18版本及以上的Studio中为selenium驱动创建的浏览器配置网络代理UI通用处理(不建议使用)模块网页部分的命令三、全局代理配置在Studio全局变量中的第一行配置一个类型为Object，名称为ProxyParameter的变量变量值的格式如下:{ "proxy_user": "user_account", "proxy_pwd": "password", "proxy_host": "proxy.host.com", "proxy_port": "1234" }说明：proxy_user、proxy_pwd表示账号和密码proxy_host表示的是代理服务器域名，不包含http协议的前缀proxy_port表示代理服务器的端口

iMaster NCE-CampusIMaster NCE-FabricIMaster NCE-IP以上三个，哪些支持AOC?

RRT算法，是近十几年应用比较广泛的一种运动规划算法。它的大致原理为：原始的RRT算法通过一个初始点作为根节点，通过随机采样，增加叶子节点的方式，生成一个随机扩展数，当随机树中的叶子节点包含了目标点或进入了目标区域，边可以在随机树中通过回溯的方式，找到这条从初始点到目标点的路径。RRT总体是一种基于概率采样的搜索方法，通过状态空间的随机采样点，把搜索导向空白区域，从而孕照到一条从起始点到目标点的规划路径，通过对状态空间中的采样点进行碰撞检测，避免了对空间的建模，当然它也有自身的缺点，这个做完后续的实验便可以体会到。RRT 适用于涉及非完整约束场合下的路径规划问题。RRT 算法为一种递增式的构造方法，在构造过程中，算法不断在搜索空间中随机生成状态点，如果该点位于无碰撞位置，则寻找搜索树中离该节点最近的结点为基准结点，由基准结点出发以一定步长朝着该随机结点进行延伸，延伸线的终点所在的位置被当做有效结点加入搜索树中。这个搜索树的生长过程一直持续，直到目标结点与搜索树的距离在一定范围以内时终止。随后搜索算法在搜索树中寻找一条连接起点到终点的最短路径。总体步骤1.建立树，根节点为起始点，指定目标点2.读取地图数据3.在地图中随机得到一个点，记作p_rand4.遍历当前的整个树，找到距离随机点最近的点，记作p_near5.由p_near向随机点p_rand扩展一个步长的距离，记步长的记录为Delta，扩展后的点记作p_new6.检测此p_new点是否在障碍物上，如果在障碍物上，则跳出本次循环，从第3步重新开始7.将新产生的点p_new插入到整个树中8.当p_new点距离目标点小于某个范围时，退出搜索，然后将整个路径画出来

心之所向，行之所往。 凡是过去，皆为序章， 所有将来，皆是可盼。 以诚挚之心，乘风破浪， 你我奔赴未来， 追梦路上，自由翱翔！---------------------------------------------------------------------------------------------------序号事件时间点链接1欢喜闹元宵活动2022年2月cid:link_262端午节情有独“粽”活动2022年5月cid:link_273AOC表情包第一期2022年10月cid:link_214社区先锋上线2022年11月cid:link_235年度调查问卷2023年1月——序号事件时间点链接1可编程时代网络工程师技能转型视频发布2022年1月https://devzone.huawei.com/cn/enterprise/aoc/videos/aocEvolution.html?id=120&number=1&from=allVideos2Python基础与AOC Open-api视频发布2022年1月https://devzone.huawei.com/cn/enterprise/aoc/videos/aocEvolution.html?id=120&number=1&from=allVideos3AOC模板2022年3月https://devzone.huawei.com/cn/enterprise/aoc/videos/aoc-template.html?id=128&number=1&from=allVideoshttps://devzone.huawei.com/cn/enterprise/aoc/videos/aoc-template.html?id=128&number=1&from=allVideos4AOC YANG存储模型2022年3月https://devzone.huawei.com/cn/enterprise/aoc/videos/aoc-yang.html?id=129&number=1&from=allVideos5开发HillStone防火墙SND2022年6月https://devzone.huawei.com/cn/enterprise/aoc/videos/hillstoneSND.html?id=136&number=1&from=allVideos6开发防火墙封禁GND2022年6月https://devzone.huawei.com/cn/enterprise/aoc/videos/hillstoneGND.html?id=137&number=1&from=allVideos7Master NCE的开放可编程平台（AOC）用积木搭建式编程实现业务上线“3个1”2022年9月https://devzone.huawei.com/cn/enterprise/aoc/videos/index.html?id=154&number=1&from=allVideos8Netconf SND Builder2022年9月https://devzone.huawei.com/cn/enterprise/aoc/videos/index.html?id=154&number=1&from=allVideos9事件中心之状态刷新2022年12月https://devzone.huawei.com/cn/enterprise/aoc/videos/index.html?id=156&number=1&from=allVideos10开发异构网络RPC SSP视频2022年12月https://devzone.huawei.com/cn/enterprise/aoc/videos/index.html?id=158&number=1&from=allVideos11开发异构网络Netconf&CLI2022年12月https://devzone.huawei.com/cn/enterprise/aoc/videos/index.html?id=157&number=1&from=allVideos序号事件时间点链接12022年第一季度AOC新特性发布会2022年3月https://devzone.huawei.com/cn/enterprise/aoc/videos/2022-Q1_2.html?id=131&number=1&from=allVideos2防火墙一键封堵，对星夜驰骋说NO2022年4月https://devzone.huawei.com/cn/enterprise/aoc/videos/aoc-2022-05-262.html?id=134&number=1&from=allVideos3华为携手银联，共筑网络数字化运维基座2022年6月https://devzone.huawei.com/cn/enterprise/aoc/videos/UnionpayLive.html?id=140&number=1&from=allVideos4AOC新特性发布会之事件中心2022年8月https://devzone.huawei.com/cn/enterprise/aoc/videos/aocCharacter.html?id=150&number=1&from=allVideos5与学长共话成长 领跑毕业新未来2022年9月https://devzone.huawei.com/cn/enterprise/aoc/videos/index.html?id=152&number=1&from=allVideos6AOC新特性发布会之开发者的舒适秘笈2022年12月cid:link_25序号名称四件套链接1网络服务化代码样例•HillStone防火墙SG6000 SND样例包• 防火墙封禁IP GND样例包•管理三方防火墙Runbook样例cid:link_24开发指导视频开发Netconf&CLI SND：https://devzone.huawei.com/cn/enterprise/aoc/videos/hillstoneSND.html?id=136&number=1&from=allVideos开发RPC SSP：https://devzone.huawei.com/cn/enterprise/aoc/videos/hillstoneGND.html?id=137&number=1&from=allVideos最佳实践介绍手册cid:link_2客户直播回放https://devzone.huawei.com/cn/enterprise/aoc/videos/aoc-2022-05-261.html?id=135&number=1&from=allVideos2异构网络设备代码样例• 异构网络Netconf&CLI SND代码样例包•查询服务RPC SSP样例包https://devzone.huawei.com/cn/enterprise/aoc/heterogeneousNetwork.html开发指导视频开发Netconf&CLI SND：https://devzone.huawei.com/cn/enterprise/aoc/videos/index.html?id=157&number=1开发RPC SSP：https://devzone.huawei.com/cn/enterprise/aoc/videos/index.html?id=158&number=1最佳实践介绍手册cid:link_3客户直播回放https://devzone.huawei.com/cn/enterprise/aoc/videos/UnionpayLive.html?id=140&number=1&from=allVideos序号事件时间点链接1iMaster NCE AOC 开放可编程平台iMaster NCE AOC 开放可编程平台2022年6月cid:link_42打造网络数字化运维基座2022年8月cid:link_13华为iMaster NCE AOC配置管理研究获SIGCOMM 2022最佳论文2022年10月cid:link_22

你女神爱不爱你，你问她，她可能不会告诉你。 但网通不通，你 ping 一下就知道了。 可能看到标题，你就知道答案了，但是你了解背后的原因吗？ 那如果把 127.0.0.1 换成 0.0.0.0 或 localhost 会怎么样呢？你知道这几个IP有什么区别吗？ 以前面试的时候就遇到过这个问题，大家看个动图了解下面试官和我当时的场景，求当时我的心里阴影面积。 话不多说，我们直接开车。  拔掉网线，断网。  断开wifi  网线一拔，恩怨去了  然后在控制台输入ping 127.0.0.1。  $ ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.080 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.093 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.074 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.079 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.079 ms ^C --- 127.0.0.1 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.074/0.081/0.093/0.006 ms 说明，拔了网线，ping 127.0.0.1  是能ping通的。  其实这篇文章看到这里，标题前半个问题已经被回答了。但是我们可以再想深一点。  为什么断网了还能 ping 通 127.0.0.1 呢？  这能说明你不用交网费就能上网吗？  不能。  首先我们需要进入基础科普环节。  不懂的同学看了就懂了，懂的看了就当查漏补缺吧。  什么是127.0.0.1 首先，这是个 IPV4 地址。  IPV4 地址有 32 位，一个字节有 8 位，共 4 个字节。  其中127 开头的都属于回环地址，也是 IPV4 的特殊地址，没什么道理，就是人为规定的。  而127.0.0.1是众多回环地址中的一个。之所以不是 127.0.0.2 ，而是 127.0.0.1，是因为源码里就是这么定义的，也没什么道理。  /* Address to loopback in software to local host.  */ #define    INADDR_LOOPBACK     0x7f000001  /* 127.0.0.1   */  回环地址  IPv4 的地址是 32 位的，2的32次方，大概是40+亿。地球光人口就76亿了，40亿IP这点量，塞牙缝都不够，实际上IP也确实用完了。  所以就有了IPV6， IPv6 的地址是 128 位的，大概是2的128次方≈10的38次方。据说地球的沙子数量大概是 10的23次方，所以IPV6的IP可以认为用不完。  IPV4以8位一组，每组之间用 . 号隔开。  IPV6就以16位为一组，每组之间用 : 号隔开。如果全是0，那么可以省略不写。   ipv6回环地址  在IPV4下的回环地址是 127.0.0.1，在IPV6下，表达为 ::1 。中间把连续的0给省略了，之所以不是7个 冒号，而是2个冒号: ， 是因为一个 IPV6 地址中只允许出现⼀次两个连续的冒号。  多说一句：在IPV4下用的是 ping 127.0.0.1 命令。在IPV6下用的是 ping6  ::1 命令。  什么是 ping ping 是应用层命令，可以理解为它跟游戏或者聊天软件属于同一层。只不过聊天软件可以收发消息，还能点个赞什么的，有很多复杂的功能。而 ping 作为一个小软件，它的功能比较简单，就是尝试发送一个小小的消息到目标机器上，判断目的机器是否可达，其实也就是判断目标机器网络是否能连通。  ping应用的底层，用的是网络层的ICMP协议。   IP和ICMP和Ping所在分层  虽然ICMP协议和IP协议都属于网络层协议，但其实ICMP也是利用了IP协议进行消息的传输。   ip和icmp的关系  所以，大家在这里完全可以简单的理解为 ping 某个IP 就是往某个IP地址发个消息。  TCP发数据和ping的区别 一般情况下，我们会使用 TCP 进行网络数据传输，那么我们可以看下它和 ping 的区别。   ping和普通发消息的关系  ping和其他应用层软件都属于应用层。  那么我们横向对比一下，比方说聊天软件，如果用的是TCP的方式去发送消息。  为了发送消息，那就得先知道往哪发。linux里万物皆文件，那你要发消息的目的地，也是个文件，这里就引出了socket 的概念。  要使用 socket , 那么首先需要创建它。  在 TCP 传输中创建的方式是  socket(AF_INET, SOCK_STREAM, 0);，其中 AF_INET 表示将使用 IPV4 里 host:port 的方式去解析待会你输入的网络地址。SOCK_STREAM 是指使用面向字节流的 TCP 协议，工作在传输层。  创建好了 socket 之后，就可以愉快的把要传输的数据写到这个文件里。调用 socket 的sendto接口的过程中进程会从用户态进入到内核态，最后会调用到 sock_sendmsg 方法。  然后进入传输层，带上TCP头。网络层带上IP头，数据链路层带上 MAC头等一系列操作后。进入网卡的发送队列 ring buffer ，顺着网卡就发出去了。  回到 ping ， 整个过程也基本跟 TCP 发数据类似，差异的地方主要在于，创建 socket 的时候用的是  socket(AF_INET,SOCK_RAW,IPPROTO_ICMP)，SOCK_RAW 是原始套接字 ，工作在网络层， 所以构建ICMP（网络层协议）的数据，是再合适不过了。ping 在进入内核态后最后也是调用的  sock_sendmsg 方法，进入到网络层后加上ICMP和IP头后，数据链路层加上MAC头，也是顺着网卡发出。因此 本质上ping 跟 普通应用发消息 在程序流程上没太大差别。  这也解释了为什么当你发现怀疑网络有问题的时候，别人第一时间是问你能ping通吗？因为可以简单理解为ping就是自己组了个数据包，让系统按着其他软件发送数据的路径往外发一遍，能通的话说明其他软件发的数据也能通。  为什么断网了还能 ping 通 127.0.0.1 前面提到，有网的情况下，ping 最后是通过网卡将数据发送出去的。  那么断网的情况下，网卡已经不工作了，ping 回环地址却一切正常，我们可以看下这种情况下的工作原理。   ping回环地址  从应用层到传输层再到网络层。这段路径跟ping外网的时候是几乎是一样的。到了网络层，系统会根据目的IP，在路由表中获取对应的路由信息，而这其中就包含选择哪个网卡把消息发出。  当发现目标IP是外网IP时，会从"真网卡"发出。  当发现目标IP是回环地址时，就会选择本地网卡。  本地网卡，其实就是个"假网卡"，它不像"真网卡"那样有个ring buffer什么的，"假网卡"会把数据推到一个叫 input_pkt_queue 的 链表 中。这个链表，其实是所有网卡共享的，上面挂着发给本机的各种消息。消息被发送到这个链表后，会再触发一个软中断。  专门处理软中断的工具人"ksoftirqd" （这是个内核线程），它在收到软中断后就会立马去链表里把消息取出，然后顺着数据链路层、网络层等层层往上传递最后给到应用程序。   工具人ksoftirqd  ping 回环地址和通过TCP等各种协议发送数据到回环地址都是走这条路径。整条路径从发到收，都没有经过"真网卡"。之所以127.0.0.1叫本地回环地址，可以理解为，消息发出到这个地址上的话，就不会出网络，在本机打个转就又回来了。所以断网，依然能 ping 通 127.0.0.1。  ping回环地址和ping本机地址有什么区别 我们在mac里执行 ifconfig 。  $ ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384     inet 127.0.0.1 netmask 0xff000000     ... en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500     inet 192.168.31.6 netmask 0xffffff00 broadcast 192.168.31.255     ... 能看到 lo0，表示本地回环接口，对应的地址，就是我们前面提到的 127.0.0.1 ，也就是回环地址。  和 eth0，表示本机第一块网卡，对应的IP地址是192.168.31.6，管它叫本机IP。  之前一直认为ping本机IP的话会通过"真网卡"出去，然后遇到第一个路由器，再发回来到本机。  为了验证这个说法，可以进行抓包，但结果跟上面的说法并不相同。   ping 127.0.0.1   ping 本机地址  可以看到 ping 本机IP 跟 ping 回环地址一样，相关的网络数据，都是走的  lo0，本地回环接口，也就是前面提到的"假网卡"。  只要走了本地回环接口，那数据都不会发送到网络中，在本机网络协议栈中兜一圈，就发回来了。因此 ping回环地址和ping本机地址没有区别。  127.0.0.1 和 localhost 以及 0.0.0.0 有区别吗 回到文章开头动图里的提问，算是面试八股文里的老常客了。  以前第一次用 nginx 的时候，发现用这几个 IP，都能正常访问到 nginx 的欢迎网页。一度认为这几个 IP 都是一样的。   访问127.0.0.1:80   访问localhost:80   访问0.0.0.0:80   访问本机的IP地址  但本质上还是有些区别的。  首先 localhost 就不叫 IP，它是一个域名，就跟 "baidu.com",是一个形式的东西，只不过默认会把它解析为 127.0.0.1 ，当然这可以在 /etc/hosts 文件下进行修改。  所以默认情况下，使用 localhost  跟使用  127.0.0.1  确实是没区别的。  其次就是 0.0.0.0，执行 ping 0.0.0.0  ，是会失败的，因为它在IPV4中表示的是无效的目标地址。  $ ping 0.0.0.0 PING 0.0.0.0 (0.0.0.0): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host 但它还是很有用处的，回想下，我们启动服务器的时候，一般会 listen 一个 IP 和端口，等待客户端的连接。  如果此时 listen 的是本机的 0.0.0.0 , 那么它表示本机上的所有IPV4地址。  /* Address to accept any incoming messages. */ #define    INADDR_ANY      ((unsigned long int) 0x00000000) /* 0.0.0.0   */ 举个例子。刚刚提到的 127.0.0.1 和 192.168.31.6 ，都是本机的IPV4地址，如果监听 0.0.0.0  ，那么用上面两个地址，都能访问到这个服务器。  当然， 客户端 connect 时，不能使用 0.0.0.0 。必须指明要连接哪个服务器IP。  总结 127.0.0.1 是回环地址。localhost是域名，但默认等于 127.0.0.1。  ping 回环地址和 ping 本机地址，是一样的，走的是lo0 "假网卡"，都会经过网络层和数据链路层等逻辑，最后在快要出网卡前狠狠拐了个弯， 将数据插入到一个链表后就软中断通知 ksoftirqd 来进行收数据的逻辑，压根就不出网络。所以断网了也能 ping 通回环地址。  如果服务器 listen 的是 0.0.0.0，那么此时用127.0.0.1和本机地址都可以访问到服务。 ———————————————— 版权声明：本文为CSDN博主「Java知识库」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/mxt51220/article/details/128257629 

AOC生态伙伴直播间，大咖面对面，专家近距离！这里“吹拉弹唱”样样强，还有满身正能量！  特性能力惊时光，产品科技亮全场！走过路过不错过，来来来~请多关注，感谢捧场！2022年序号直播主题直播时间直播嘉宾直播主题回顾链接6AOC新特性发布会之开发者的舒适秘笈2022.12.22•艾克 NCE AOC开发工程师•珍珍 NCE AOC信息体验工程师•晴卡卡 生态运营工程师iMaster NCE's AOC新特性抢先看！包管理Linux指令+一键部署+API Catalog，带你体验开发者的舒适秘笈！cid:link_85与学长共话成长 领跑毕业新未来2022.9.8•饶家鼎 华为天才少年•梅子 人力资源专家•Kiki 信息体验专家•晴卡卡 生态运营工程师本次直播通过hr介绍华为面试流程、通过学长分享岗位工作心得，助力高校毕业生秋招获得心动offerhttps://devzone.huawei.com/cn/enterprise/aoc/videos/index.html?id=152&number=1&from=allVideos4AOC新特性发布会之事件中心2022.8.31•展工程师 NCE AOC技术布道师•静远 NCE AOC信息体验工程师•晴卡卡 生态运营工程师实时感知，保障业务连贯；按需定制，灵活定义需求。iMaster NCE AOC，新特性抢先看！“事件中心”带你领略全新运维体验，不容错过！https://devzone.huawei.com/cn/enterprise/aoc/videos/aocCharacter.html?id=150&number=1&from=allVideos3华为携手银联，共筑网络数字化运维基座2022.6.16•袁航 中国银联金融科技研究院高级研究员•蒋艳 华为NCE AOC解决方案架构师•晴卡卡 生态运营工程师中国银联基于华为iMaster NCE AOC，构建新一代数据中心网络统一管控平台，实现网络运维数字化转型https://devzone.huawei.com/cn/enterprise/aoc/videos/UnionpayLive.html?id=140&number=1&from=allVideos2防火墙一键封堵，对星夜驰骋说NO2022.4.28•文茂 南天软件架构专家•Kiki 华为AOC开发工程师•晴卡卡 生态运营工程师利用AOC的SND开放设备场景能力，并通过GND屏蔽异构厂商设备差异，再由Runbook进行可视化图形编排，实现防火墙设备统一管理。https://devzone.huawei.com/cn/enterprise/aoc/videos/aoc-2022-05-262.html?id=134&number=1&from=allVideos12022年第一季度AOC新特性发布会直播2022.3.29•Jessica 数通网络开放可编程专家AOC第一季度三大亮点新特性抢先看(低代码网络运维、设备无关统一模型、业务配置一致性保障)。 带你全面了解新特性实现方案、 使用场景和应用价值 ！https://devzone.huawei.com/cn/enterprise/aoc/videos/2022-Q1_2.html?id=131&number=1&from=allVideos2021年序号直播主题直播时间直播嘉宾直播主题回顾链接32021年AOC新特性发布会2021.12.23•Jessica 数通网络开放可编程专家倾力展现AOC六大亮点新特性（华为设备自适配、零代码纳管设备、极速网络运维、设备平滑升级、网络配置全联动、超大网络管理）https://devzone.huawei.com/cn/enterprise/aoc/videos/2021AOCNewFeatureLive.html?id=121&number=1&from=allVideos2AOC一触即发，玩转L3VPN业务开发2021.8.20•WeiWei老师   华为数通开放可编程专家综合运用YANG、python、Jinja能力，通过AOC社区“在线开发”云上平台，快捷创建虚拟网元，完成L3VPN业务包的实战开发。https://devzone.huawei.com/cn/enterprise/aoc/videos/aocL3vpnLive.html?id=115&number=1&from=allVideos1数通网络开放可编程之Hello World2021.5.28•WeiWei老师   华为数通开放可编程专家介绍网络编程的基础知识：YANG、python和Jinja模板，并在AOC社区的“在线开发”环境上，通过一个实例完成hello world的编写和运行。https://devzone.huawei.com/cn/enterprise/aoc/videos/aocUsePackageLive.html?id=109&number=1&from=allVideos

文 / 吉林银行首席信息官  邹帮山吉林银行科技部总经理  严彪我国《“十四五”规划和2035年远景目标纲要》指出要“稳妥发展金融科技，加快金融机构数字化转型”，在金融科技从“立柱架梁”全面迈入“积厚成势”新发展阶段，如何谋篇布局赋能业务发展，是我行信息科技建设新的机遇与挑战。在人民银行和银保监会《金融科技发展规划（2022-2025年）》《关于银行业保险业数字化转型的指导意见》政策指导下，吉林银行结合自身经营策略，规划生态场景层、渠道服务层、智能数据层、能力资源层、技术支撑层的金融科技“XMART”架构体系。该体系充分利用“ABCDI”五大金融科技手段，建设七大业务领域科技能力，规划三阶段实施路径，统筹制定金融科技发展规划暨“五七三”工程，秉承“集中力量推进关键核心技术攻关，适度超前部署数字基础设施建设，全面加强网络安全和数据安全保护”三大原则，赋能业务数字化转型。业务快速增长给数据中心网络运维随着金融业务、互联网业务的快速增长，业务变更更加频繁，加之我行数据中心向多地多中心的方向发展，网络的运维面临了更高的挑战：一是数据中心存量设备的自动化程度较低，增加新业务需要手动配置多厂商、多类型设备，且大多数变更为重复性的策略开通等工作，费时费力。二是异构多云跨厂商业务开通，各厂商设备配置命令千差万别，协议繁复，配置极其复杂,不具备端到端的统一的自动化工具，维护成本高。三是多数据中心、多资源池的网络资源离散，无法实现多数据中心资源统一管理。四是行内的网络资源主要还是以离线文件方式进行管理，维护投入高，易出错，且该管理分配模式已经无法进行快速响应和准确分配。五是应用和网络的运维视图割裂，业务故障场景无法快速定界，耗费大量的时间在各领域的自检自查上。构建“一网多云”的数字化运维体系经过在金融行业的广泛调研，结合我行多年运维经验，总结了数字化时代数据中心网络数字化运维应具备以下三个特性。1.管控更全面。数据中心发展迅速，设备更新换代快，在网的上一代的存量设备仍要被合理利用，运维工具需要能够兼容管理。另外，对于边界墙、大核心等一些不具备SDN自动化能力，却又涉及频繁割接的设备，也要能够统一管控。数字化运维，应具备对全网不同厂商、不同类型、不同角色的新建及存量设备的统一管控能力，建立管控更全面的数字化运维体系。2.服务更敏捷。云计算带来的网络虚拟化和云化形态，让网络复杂化、业务变更高频化，从而凸显工单低效化，导致网络人力吃紧，网络体验下滑。数字化运维，应具备网络变更自助化流程设计，涵盖互联网业务、外联网业务、内联网业务、跨区域东西向等业务场景，立足现在并面向未来，实现架构合理、扩展性好的“一站式业务自助变更”的运维服务，满足现有业务的自动化诉求，以及未来业务自动化的演进，建立服务更敏捷的数字化运维体系。3.运维更智能。传统的例行化维护难以保障网络隐患及时排除，网络资产文档化，运维数据多处离线收集，临时汇总分析，难以确保全面性，缺失事件相关性分析，故障定位效率低。数字化运维，应具备体系化评估网络，快速识别风险，及时消除隐患，加速故障定位能力，建立运维更智能的数字化运维体系。自动驾驶网络引领数字运维新模式我行组织多方专家进行深入研讨，经过不断的DEMO演练，通过详实的技术研究，决定采用华为数据中心L3.5网络自动驾驶解决方案。该方案依托华为自研芯片及平台的产品iMaster NCE-Fabric意图网络SDN控制器，基于Runbook（北向开放服务）+AOC（南向开放服务）的南北向开放可编程网络自动化平台能力，以及基于数字地图的网络数据平台能力，联合华为专业服务团队的定制化的运维方案，开启了我行基于意图网络数字运维新模式（如图所示）。图    Runbook+AOC开放可编程网络自动化架构基础网络服务层：主要体现在网络自动化工具的南向接口，将不同厂家网络设备的命令行差异进行统一，向上层提供一类模型，由此来屏蔽厂商差异。业务意图编排层：利用基础网络服务层提供的原子积木，根据实际业务场景进行编排搭建，实现基于业务意图的端到端下发。网络服务目录层：不同的业务场景类型定义目录，如基础搭建服务、业务发放服务、故障与应急服务等。简单理解为就是菜单，给网络运维团队内部或者其他周边团队进行使用。网元层：各厂商网络设备。图    数字地图网络数据平台架构网络动态拓扑：采用智能还原技术，构建了一张数字化的网络地图。互访路径导航：在具备精准的地图后，可以将两点之间的应用路径在地图上进行展示。直接输入A、B两个IP，平台会根据其安全策略、路由算法进行路径还原。搜索精准定位：对IP所在的设备、虚拟机、虚拟网络设备等快速查询，同时在数字地图中，对于该定位的设备周边互联、上下关联的属性一并显示。服务器拓扑：将接入交换机下挂的所有服务器进行展示。应用动态拓扑：在“业务路径导航”功能的基础上，引入并叠加NPM的数据能力，将重要业务之间的告警和监控附加到网络设备上。HCS逻辑拓扑：将拓扑能力延伸到云资源环境中，进行HCS逻辑网络的统一管理。图    吉林银行自动驾驶网络数字运维逻辑架构我行网络运维团队联合华为专业服务，以金标委、人民银行等规范要求为基准，抽象出多个常用业务意图，如手机银行访问HCS综合积分系统业务意图、分支机构访问HCS新开通的ATM柜员机业务意图、分支机构访问HCS新开通的OA办公自动化业务意图、HCS云部署办公邮件系统业务意图、排队叫号系统业务意图等，通过Runbook开放可编程平台实现了灵活的业务意图流程编排，通过AOC开放可编程平台覆盖了防火墙、负载均衡、交换机等多家厂商网络设备，实现了端到端的网络设备自动化配置。此外，基于自动可控的平台，拖拽式编排，低代码化开发，即插即用动态加载新增网元设备的驱动包，大大缩短了迭代周期，提升了业务敏捷上线效率。动态数字地图是数字化运维的基础。我行通过数字地图，使得网络数据从离线表格转移到线上，从静态绘制拓扑转换为动态智能还原，实现了全网IP等网络资源的快速搜索；从网络数据平台看到了HCS云平台的逻辑网络，也看到了IT系统业务应用，大大缩短了应用报障定界定位时长，减少了业务受损时间。未来展望未来，吉林银行将从深化数字技术提升自主可控、构建数据中台释放数据潜能、打造开放银行融合场景生态三个维度打造科技赋能、数据驱动、业务联动的实体经济服务能力。我行将充分利用与华为联合成立“自动驾驶网络应用实验室”的契机，对网络数字化转型做持续演进的探索。未来，将重点开展L3.5向L4和L5自动驾驶能力的创新研究和探索，持续迭代和孵化意图网络数字运维新模式，意图网络、数字孪生等技术与AI结合，逐步消除数据中心网络运维的人工断裂点，基于海量数据提升网络预测和预防能力，基于数据驱动差异化的产品服务，使数据中心的网络运维能实现高度自动化和智能化。同时，在测试和生产网中分期分批试点应用Runbook和数字地图等关键特性，提升我行数据中心网络自动化率和可视化体验，探索网络数字化转型。根据市场和行业发展需要，从“全网一张图”，逐步推进至“全行一张网”的“一网多云”运维架构，通过更加自动化的方式进行网络变更、优化、性能分析与预测，在提升业务敏捷性的同时驱动业务的创新发展，并实现数字运维的产品化和产业化目标，为金融行业数字化转型提供更多助力。（栏目编辑：魏亚楠）文章来源：https://mp.weixin.qq.com/s/DkDsvW5k9lmL3jK9MvPj8Q

绘画 创新 新时代 科技 意境之美

【直播回顾】回放地址：cid:link_2精彩问题：问题一（Linux包管理指令）：在使用linux指令做包管理操作时候，如果指令输错了，或者格式不正确，会有提示指导吗？答：每一条包管理Linux指令都会在指导文档中详细注明规格，如果没有按照固定的参数格式输入的话，会在窗口报错弹出具体错误信息，指导用户更正输入。例如没有填写必填参数，窗口会提示缺少了哪些参数；或是填写上传文件的名称错误，窗口会提示文件不存在；导出模板指令的多个参数还具有正则格式校验，如果输入的格式不正确的话，窗口会弹出报错还有正确的格式提示。问题二（一键部署）：使用一键部署功能的时候，如果不填写配置文件，还能实现类似的功能吗？答：刚才演示的一键部署的前期准备，主要是为了设定一些默认的参数，添加触发事件，这样能够实现修改代码提交的同时，能够自动触发多条指令的执行。如果我们不进行前面的这些配置，也是可以手动输入一键部署指令来实现同样效果的功能的，刚才演示过程中的配置文件中的参数，都可以直接写进指令中，相关的指令指导也在指导文档中有说明。如果用户没有使用远端仓库，也可以通过手动输入一键部署指令的方式去实现相同的功能。问题三（API Catalog）：对yang文件结构不熟悉，自己开发的插件包不确定格式是否能够正常生成接口，有没有什么方法能帮忙检查我写的文件格式呢？答：我们的AOC开放可编程网站为开发者提供了Yang文件自检工具，可以在开放可编程网站的资源下载页面，下载YANG检查工具，下载到本地后，把自行开发的yang文件批量放置到工具的目录下，启动校验，就会进行格式校验，返回校验结果。如果通过了格式校验，就可以正常编包上传进行验证。【预热前线】videovideovideovideo  一、直播转发有奖活动规则：         ①   1）移动端直接转发本帖               2）PC端扫描右侧分享二维码打开并转发本帖；         ②  写上直播相关话语，不屏蔽公开分享至任意渠道（包括但不限于微信群、朋友圈、微博、welink等）；         ③  保存24小时后截图上传本帖；         ④  直播结束后两周内，发放 400码豆 ；活动时间：2022年12月14日—2022年12月22日截图上传举例：*注意：如有无法上传图片问题，可以将图片大小控制在100k以下尝试，或联系体验官解决二、直播报名有奖直播报名链接：  cid:link_0在 本主题 帖盖楼，帖子内容：报名截图+华为云开发者账号，得 200码豆 活动时间：2022年12月14日—2022年12月22日报名截图举例：*注意：如有无法上传图片问题，可以将图片大小控制在100k以下尝试，或联系体验官解决  三、直播间抽奖官方直播链接：  cid:link_212月22日19:00-20:00直播过程中，登录华为云官方直播间，按照小助手发布的抽奖口令，进行互动抽奖，共3轮抽奖环节。礼品：背包、保温杯、自拍杆--------------------------------------------------------------------  注意事项：1. 转发有奖和报名有奖活动于12月22日结束，本帖不关闭评论区功能，超出活动时间视为活动失效，但各活动独立，大家可以同时参加。2. 本活动最终解释权归iMaster NCE AOC社区所有  什么是码豆？     - 会员中心入口：cid:link_4     - 码豆奖励活动规则：码豆只能用于会员中心的礼品兑换，不得转让，具体规则请到会员中心阅读“码豆规则”。————  关于我们 ————iMaster NCE AOC (Agile Open Container)集成了华为网络云化平台，以及从网络运维中抽象总结出的业务框架，以Yang模型为基础，提供了对网络的开放可编程能力。iMaster NCE AOC已经广泛的应用于中国银联、华为云等网络中。中国银联：华为iMaster NCE AOC有效解决了金融行业在自动化转型过程中的痛点问题，满足了Bank4.0时代智能金融服务对网络平稳支撑的诉求。华为云：在华为云项目中，iMaster NCE AOC完美匹配了南北向快速集成和网络变更自动化高可靠的需求，显著提升了运营效率。  中英文社区首页入口：    中文版社区      /    英文版社区 邮箱联系： aocconsult@huawei.comiMaster NCE AOC服务体验官微信：huawei520aoc

【开发菌】：已经发布的版本资料领导说写的不错，怎么又要更新了？【AOC资料专家】：是啊，专业、高效、精准是我们的追求，需要为用户提供更高质量价值内容，所以资料需要不断打磨。【开发菌】：那么这次又为用户提供了哪些精彩内容呢？【AOC资料专家】：可多了，这次主要针对R22C00版本的开发指南和产品简介做了更新，增加了GND代码示例、开发常用接口参数、优化了描述、内容更接地气….，详细了解快往下看吧~【开发菌】：诶，那可得了解下~—————————3分钟了解新变更—————————一、开发指南 文档架构按照用户场景优化：按照包类型/协议/业务调整，一站式提供各种包类型的开发全过程内容。 内容优化点1：软件包开发内容基于用户导出的软件包文件开始，对新手用户更加友好。内容优化点2： 梳理补充软件包开发常用接口和参数，并提供关键参数获取方式。内容优化点3：补充丰富的代码实战样例。内容优化点4：按照软件包功能详细描述内容优化点5： 删减重复内容，内容更加精炼开发指南：cid:link_0二、产品简介架构优化：按照功能特性优化架构。内容优化点1基于用户视角描述功能特性，价值点清晰。内容优化点2：优化业务映射逻辑描述，介绍清楚GND和SSP的差别。产品简介：cid:link_1———— 关于我们 ————iMaster NCE AOC (Agile Open Container)集成了华为网络云化平台，以及从网络运维中抽象总结出的业务框架，以Yang模型为基础，提供了对网络的开放可编程能力。iMaster NCE AOC已经广泛的应用于中国银联、华为云等网络中。中国银联：华为iMaster NCE AOC有效解决了金融行业在自动化转型过程中的痛点问题，满足了Bank4.0时代智能金融服务对网络平稳支撑的诉求。华为云：在华为云项目中，iMaster NCE AOC完美匹配了南北向快速集成和网络变更自动化高可靠的需求，显著提升了运营效率。中英文社区首页入口： 中文版社区 / 英文版社区 邮箱联系： aocconsult@huawei.comiMaster NCE AOC服务体验官微信：huawei520aoc

高阶应用举例——共享网络接入

QoS（Quality of Service）即服务质量。在有限的带宽资源下，QoS为各种业务分配带宽，为业务提供端到端的服务质量保证。例如，语音、视频和重要的数据应用在网络设备中可以通过配置QoS优先得到服务。QoS的重要性在IP网络的业务可以分为实时业务和非实时业务。实时业务往往占据固定带宽，对网络质量变化感知明显，对网络质量的稳定性要求高，例如语音业务。非实时业务所占带宽难以预测，经常会出现突发流量。突发流量会导致网络质量下降，会引起网络拥塞，增加转发时延，严重时还会产生丢包，导致业务质量下降甚至不可用。解决网络拥塞的最好的办法是增加网络的带宽，但从运营、维护的成本考虑，这是不现实的，最有效的解决方案就是应用一个“有保证”的策略对网络流量进行管理。QoS一般针对网络中有突发流量时需要保障重要业务质量的场景。如果业务长时间达不到服务质量要求（例如业务流量长时间超过带宽限制），需要考虑对网络扩容或使用专用设备基于上层应用去控制业务。近几年，视频的应用出现了爆炸式的增长，现在几乎每个人都拥有一部能够随时随地拍摄高分辨率视频的智能手机。同时随着社交网站的涌现，分享和发布视频成了每个人的日常行为，人们不论身在何处都可以将自己制作的视频发布出去与他人分享。对于企业来说，高清视频会议，高清视频监控等应用，也在网络中产生了大量的高清视频流量。与语音流量相比，视频流量占用的带宽更多，也更不稳定，特别是一些交互类视频，对实时性要求非常高。另外，随着无线网络的发展，越来越多的用户和企业都开始使用无线终端，而无线终端会随着用户的移动而不断变化位置，导致网络中的流量更加的不可预测。因此QoS方案设计也面临更多的挑战。QoS的度量指标影响网络质量的因素包括传输链路的带宽、报文传送时延和抖动、以及丢包率等，它们也就成为了QoS的度量指标。带宽带宽也称为吞吐量，是指在一个固定的时间内（1秒），从网络一端传输到另一端的最大数据位数，也可以理解为网络的两个节点之间特定数据流的平均速率。带宽的单位是比特/秒（bit/s）。在网络中，有两个常见的与带宽有关的概念：上行速率和下行速率。上行速率是指用户向网络发送信息时的数据传输速率，下行速率是指网络向用户发送信息时的传输速率。例如，用户通过FTP上传文件到网络，影响上传文件速度的就是上行速率；而从网络下载文件，影响下载文件速度的就是下行速率。时延时延是指一个报文或分组从网络的发送端到接收端所需要的延迟时间，一般由传输延迟及处理延迟组成。以语音传输为例，时延是指从说话者开始说话到对方听到所说内容的时间。一般人们察觉不到小于100毫秒的延迟。当延迟在100毫秒和300毫秒之间时，说话者可以察觉到对方回复的轻微停顿，这种停顿可能会使通话双方都感觉到不舒服。超过300毫秒，延迟就会很明显，用户开始互相等待对方的回复。当通话的一方不能及时接收到期望的回复时，说话者可能会重复所说的话，这样会与远端延迟的回复碰撞，导致重复。抖动如果网络发生拥塞，导致通过同一连接传输的分组延迟各不相同。抖动用来描述延迟变化的程度，也就是最大延迟与最小延迟的时间差。抖动对于实时性的传输是一个重要参数，特别是语音和视频等实时业务是极不容忍抖动的，抖动会造成话音或视频的断续。抖动也会影响一些网络协议的处理。有些协议是按固定的时间间隔发送交互性报文，抖动过大会导致协议震荡。所有传输系统都有抖动，只要抖动在规定容差之内就不会影响服务质量。利用缓存可以克服过量的抖动，但这将增加时延。丢包率丢包率是指在网络传输过程中丢失报文的数量占传输报文总数的百分比。少量的丢包对业务的影响并不大，例如，在语音传输中，丢失一个比特或一个分组的信息，通话双方往往注意不到。在视频的传输中，丢失一个比特或一个分组可能造成在屏幕上瞬间的波形干扰，但能很快恢复正常。使用TCP传送数据可以处理少量的丢包，因为TCP允许丢失的信息重发。但大量的丢包会影响传输效率。在QoS中，我们关注的是丢包的统计数据，也就是丢包率。所以正常传输时，网络丢包率应该控制在一定范围内即可。QoS的应用场景以企业办公为例，除了基本的网页浏览、工作邮件外，在较集中的工作时间段内还需要保证Telnet登录设备、异地的视频会议、实时语音通话、FTP文件的上传和下载，以及视频播放等业务的网络质量。对于不同网络质量要求的业务，可以配置不同的QoS子功能，或者不部署QoS。网络协议和管理协议（如OSPF、Telnet）这类业务要求低时延和低丢包率，但对带宽的要求不高。因此可以通过QoS的优先级映射功能，为此类报文标记较高的服务等级，使网络设备优先转发此类报文。实时业务（如视频会议、VoIP）视频会议要求高带宽、低时延和低抖动。因此可以通过QoS的流量监管功能，为视频报文提供高带宽；通过QoS的优先级映射功能，适当调高视频报文的优先级。VoIP是指通过IP网络进行实时语音通话，它要求网络做到低丢包、低时延和低抖动，否则通话双方可以明显感知质量受损。因此一方面可以调整语音报文的优先级，使其高于视频报文；另一方面通过流量监管功能，为语音报文提供最大带宽，在网络产生拥塞时，可以保证语音报文优先通过。大数据量业务（如FTP、数据库备份、文件转储）大数据量业务是指存在长时间大量数据传输行为的网络业务，这类业务需要尽可能低的网络丢包率。因此可以为这类报文配置流量整形功能，通过数据缓冲区缓存从接口发送的报文，减少由于突发流量导致拥塞而产生的丢包现象。流媒体（如在线音频播放、视频点播）由于这些音视频节目都是提前制作好的，观看者的终端通常可以先进行缓存再进行播放，因此降低了对网络时延、丢包和抖动的要求。如果需要降低这类业务的丢包和时延，可以通过QoS的优先级映射功能，适当提高对应报文的优先级。普通业务（如HTML网页浏览、邮件）这类业务对网络无特殊要求、重要性也不高。管理员可以对其保持默认设置，不需要额外部署QoS功能。QoS的服务模型如何在网络中通过部署来保证QoS的度量指标在一定的合理范围内，从而提高网络的服务质量呢？这就涉及到QoS模型。需要说明的是，QoS模型不是一个具体功能，而是端到端QoS设计的一个方案。例如，网络中的两个主机通信时，中间可能会跨越各种各样的设备。只有当网络中所有设备都遵循统一的QoS服务模型时，才能实现端到端的质量保证。下面介绍主流的三大QoS模型。其中，华为公司的交换机、路由器、防火墙、WLAN等产品均支持配置基于DiffServ服务模型的QoS业务。Best-Effort服务模型：尽力而为Best-Effort是最简单的QoS服务模型，用户可以在任何时候，发出任意数量的报文，而且不需要通知网络。提供Best-Effort服务时，网络尽最大的可能来发送报文，但对时延、丢包率等性能不提供任何保证。Best-Effort服务模型适用于对时延、丢包率等性能要求不高的业务，是现在Internet的缺省服务模型，它适用于绝大多数网络应用，如FTP、E-Mail等。IntServ服务模型：预留资源IntServ模型是指用户在发送报文前，需要通过信令（Signaling）向网络描述自己的流量参数，申请特定的QoS服务。网络根据流量参数，预留资源以承诺满足该请求。在收到确认信息，确定网络已经为这个应用程序的报文预留了资源后，用户才开始发送报文。用户发送的报文应该控制在流量参数描述的范围内。网络节点需要为每个流维护一个状态，并基于这个状态执行相应的QoS动作，来满足对用户的承诺。IntServ模型使用了RSVP（Resource Reservation Protocol）协议作为信令，在一条已知路径的网络拓扑上预留带宽、优先级等资源，路径沿途的各网元必须为每个要求服务质量保证的数据流预留想要的资源，通过RSVP信息的预留，各网元可以判断是否有足够的资源可以使用。只有所有的网元都给RSVP提供了足够的资源，“路径”方可建立。DiffServ服务模型：差分服务DiffServ模型的基本原理是将网络中的流量分成多个类，每个类享受不同的处理，尤其是网络出现拥塞时不同的类会享受不同级别的处理，从而得到不同的丢包率、时延以及时延抖动。同一类的业务在网络中会被聚合起来统一发送，保证相同的时延、抖动、丢包率等QoS指标。Diffserv模型中，业务流的分类和汇聚工作在网络边缘由边界节点完成。边界节点可以通过多种条件（比如报文的源地址和目的地址、ToS域中的优先级、协议类型等）灵活地对报文进行分类，对不同的报文设置不同的标记字段，而其他节点只需要简单地识别报文中的这些标记，即可进行资源分配和流量控制。与Intserv模型相比，DiffServ模型不需要信令。在DiffServ模型中，应用程序发出报文前，不需要预先向网络提出资源申请，而是通过设置报文的QoS参数信息，来告知网络节点它的QoS需求。网络不需要为每个流维护状态，而是根据每个报文流指定的QoS参数信息来提供差分服务，即对报文的服务等级划分，有差别地进行流量控制和转发，提供端到端的QoS保证。DiffServ模型充分考虑了IP网络本身灵活性、可扩展性强的特点，将复杂的服务质量保证通过报文自身携带的信息转换为单跳行为，从而大大减少了信令的工作，是当前网络中的主流服务模型。基于DiffServ模型的QoS组成基于Diffserv模型的QoS业务主要分为以下几大类：报文分类和标记要实现差分服务，需要首先将数据包分为不同的类别或者设置为不同的优先级。报文分类即把数据包分为不同的类别，可以通过MQC配置中的流分类实现。报文标记即为数据包设置不同的优先级，可以通过优先级映射和重标记优先级实现。不同的报文使用不同的QoS优先级，例如VLAN报文使用802.1p，IP报文使用DSCP，MPLS报文使用EXP。流量监管、流量整形和接口限速流量监管和流量整形可以将业务流量限制在特定的带宽内，当业务流量超过额定带宽时，超过的流量将被丢弃或缓存。其中，将超过的流量丢弃的技术称为流量监管，将超过的流量缓存的技术称为流量整形。接口限速分为基于接口的流量监管和基于接口的流量整形。拥塞管理和拥塞避免拥塞管理在网络发生拥塞时，将报文放入队列中缓存，并采取某种调度算法安排报文的转发次序。而拥塞避免可以监督网络资源的使用情况，当发现拥塞有加剧的趋势时采取主动丢弃报文的策略，通过调整流量来解除网络的过载。其中，报文分类和标记是实现差分服务的前提和基础；流量监管、流量整形、接口限速、拥塞管理和拥塞避免从不同方面对网络流量及其分配的资源实施控制，是提供差分服务的具体体现。