调优思路 本章主要是围绕优化网卡性能和利用网卡的能力分担CPU的压力来提升性能。在高并发的业务场景下，推荐使用两块网卡，减少跨片内存访问的次数。即将两块网卡分别绑定在服务器的不同CPU上，每个CPU只处理对应的网卡数据。高并发场景还可以为网卡选择x16的 PCIe 卡。 二、 介绍 ethtool是一个Linux下功能强大的网络管理工具，目前几乎所有的网卡驱动程序都有对ethtool的支持，可以用于网卡状态/驱动版本信息查询、收发数据信息查询及能力配置以及网卡工作模式/链路速度等查询配置。 安装方式 以CentOS为例，使用如下命令安装： yum -y install ethtool net-tools 使用方式 命令格式：ethtool [参数] 常用参数如下： 参数 说明  ethX 查询ethx网口基本设置，其中x是对应网卡的编号，如eth0、eth1等。  -k  查询网卡的Offload信息。 -K 修改网卡的Offload信息。  -c 查询网卡聚合信息。  -C 修改网卡聚合信息。  -l 查看网卡队列数。  -L 设置网卡队列数。  输出格式：  ethtool -k eth0 Features for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: on ethtool -l eth0 Channel parameters for eth0: Pre-set maximums: … Current hardware settings: … Combined: 8 ethtool -c eth0 Coalesce parameters for eth0: Adaptive RX: off TX: off … rx-usecs：30 rx-frames：50 … tx-usecs：30 tx-frames：1 参数含义如下： 参数 说明 rx-checksumming 接收包校验和。 tx-checksumming 发送包校验和。 scatter-gather 分散-聚集功能，是网卡支持TSO的必要条件之一。 tcp-segmentation-offload 简称为TSO，利用网卡对TCP数据包分片。 Combined 网卡队列数。 adaptive-rx 接收队列的动态聚合执行开关。 adaptive-tx 发送队列的动态聚合执行开关。 tx-usecs 产生一个中断之前至少有一个数据包被发送之后的微秒数。 tx-frames  产生中断之前发送的数据包数量。 rx-usecs 产生一个中断之前至少有一个数据包被接收之后的微秒数。 rx-frames 产生中断之前接收的数据包数量。 三、 介绍 strace 是Linux环境下的程序调试工具，用来跟踪应用程序的系统调用情况。strace命令执行的结果就是按照调用顺序打印出所有的系统调用，包括函数名、参数列表以及返回值等。  安装方式 以CentOS为例，使用如下命令安装： yum -y install strace 使用方式 命令格式：strace [参数] 常用参数如下：  参数 说明 -T 显示每一调用所耗的时间。 -tt 在输出中的每一行前加上时间信息，微秒级。 -p 跟踪指定的线程ID。 输出格式： 18:25:47.902439 epoll_pwait(716, [{EPOLLIN, {u32=1052576880, u64=281463144385648}}, {EPOLLIN, {u32=1052693569, u64=281463144502337}}, {EPOLLOUT, {u32=1052638657, u64=281463144447425}}, {EPOLLIN|EPOLLOUT|EPOLLRDHUP, {u32=1052673241, u64=281463144482009}}, {EPOLLIN|EPOLLOUT|EPOLLERR|EPOLLHUP|EPOLLRDHUP, {u32=1052636016, u64=281463144444784}}], 512, 1, NULL, 8) = 5 <0.000038> 参数含义如下： 参数 说明 18:25:47.902439 为系统调用发生的时间。 epoll_pwait 为系统调用的函数名。 （716…）  括号内的值为函数参数。 =5 为系统调用的返回值。 <0.000038> 为系统调用的执行时间。 四、 原理 网卡自带的内存和CPU使用的内存进行数据传递时，是通过PCIe总线进行数据搬运的。Max Payload Size为每次传输数据的最大单位（以字节为单位），它的大小与PCIe链路的传送效率成正比，该参数越大，PCIe链路带宽的利用率越高。 Transaction Layer Packet Header  Data Payload ECRC 修改方式 按照进入BIOS界面的步骤进入BIOS，选择“Advanced > Max Payload Size”，将“Max Payload Size”的值设置为“512B”。

从模拟器相册中选择一个JPG图片，通过POST方式上传到服务器，服务器端用servlet负责接收，用servletInputStream输入流接收上传的图片内容，后来发现保存的图片格式不对，不知道哪里出了问题？

乾坤终端的设置里面可以增加设置网络功能吗？比如通过代理上网

1. 概述 1.1 ICMPv6介绍 ICMPv6是互联网控制消息协议第6版(Internet Control Message Protocol version 6)的缩写，它是IPv6协议族中的一个重要协议，与IPv4中的ICMPv4协议相对应。ICMPv6同样用于传递网络层的控制和错误信息，辅助IPv6协议完成高效、可靠的数据传输任务。  与ICMPv4类似，ICMPv6报文封装在IPv6数据报中进行传输。报文主要由报头和数据部分组成。报头包含了类型、代码和校验和等重要信息，用于识别报文的类型和检测传输错误，数据部分则携带了与具体报文类型相关的信息。  ICMPv6报文可以分为两大类：差错报告报文和信息报文。  (1) 差错报告报文用于向源节点通知在数据传输过程中遇到的各种错误情况:  目标不可达，数据包无法送达目标地址。 数据包过大，数据包长度超过了链路的MTU。 超时，数据包在网络中存在的时间超过限制。 参数问题，数据包中的某些字段存在错误或不支持。 (2) 信息报文则用于IPv6网络中的各种功能:  回显请求和应答，类似于ICMPv4中的ping，用于检测节点的可达性。 组成员关系查询和报告，用于IPv6组播管理，查询和维护组成员信息。 邻居发现，用于节点在本地链路上发现邻居节点，包括路由器发现、地址解析、重复地址检测等。 路由器重定向，类似于ICMPv4，路由器用它通知源节点有更好的路由路径。 与ICMPv4相比，ICMPv6在功能上有所增强，特别是在支持IPv6的新特性方面，如组播管理、邻居发现等。  1.2 相关RFC文档 以下是与ICMPv6相关的主要RFC文档列表:  RFC 2463 - Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (1998)，定义了ICMPv6协议的基本规范，包括报文格式、类型和代码等。  RFC 4443 - Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (2006)，更新和取代了RFC 2463，对ICMPv6进行了细化和完善。  RFC 4861 - Neighbor Discovery for IP version 6 (IPv6) (2007)，定义了IPv6的邻居发现协议，包括路由器发现、前缀发现、地址解析等，邻居发现协议大量使用ICMPv6报文进行通信。  RFC 4884 - Extended ICMP to Support Multi-Part Messages (2007)，扩展了ICMPv4和ICMPv6，支持多部分消息，增加了对大型诊断消息的传输能力。  RFC 4890 - Recommendations for Filtering ICMPv6 Messages in Firewalls (2007)，为防火墙过滤ICMPv6报文提供了指导和建议，以提高IPv6网络的安全性。  RFC 5837 - ICMP Extensions for Multiprotocol Label Switching (2010)，定义了用于MPLS的ICMPv4和ICMPv6扩展，支持MPLS网络的错误报告和诊断。  RFC 6437 - IPv6 Flow Label Specification (2011)，重新定义了IPv6流标签的用途和处理规则。  RFC 7045 - Transmission and Processing of IPv6 Extension Headers (2013)，规定了IPv6扩展头的处理规则和顺序。  RFC 7112 - Implications of Oversized IPv6 Header Chains (2014)，分析了IPv6过长头部链对网络设备和协议处理的影响。  RFC 8335 - PROBE: A Utility for Probing Interfaces (2018)，定义了一种探测接口的通用机制，使用ICMPv6回显请求进行探测。  2. 报文格式 2.1 ICMPv6首部 ICMPv6报文格式由类型、代码和校验和三个固定字段组成，后面紧跟与具体报文类型相关的数据部分。   字段说明:  ICMPv6报文位于0个或多个扩展头部之后，其中最后一个扩展头部包含值为58的下一个头部字段(Next Header)。  Type(类型，8位)标识ICMPv6报文的类型，不同的类型对应不同的报文格式和用途，如128表示回显请求，129表示回显应答等。ICMPv6类型报文从0127都是差错报文，从128255都是信息类报文。  Code(代码，8位)与类型字段一起标识ICMPv6报文的具体含义，同一类型的报文可能有多个代码值，表示不同的错误原因或附加信息。  Checksum(校验和，16位)用于检测报文在传输过程中是否出现错误，计算方法与ICMPv4类似，但有些不同，ICMPv6除了整个ICMP数据段，还要包含IPv6头部中的源和目的IPv6地址，长度和下一个头部字段。  Message Body(消息体)：长度可变，携带与具体报文类型相关的数据，如错误信息、回显数据等，不同类型的报文有不同的消息体格式。  2.2 ICMPv6报文类型 ICMPv6的主要报文类型如下：  类型    名称    RFC文档    用途描述 1    Destination Unreachable    RFC4443    目标不可达，用于通知源主机 2    Packet Too Big    RFC4443    报文过大，需要分片但IPv6不允许中间设备分片 3    Time Exceeded    RFC4443    超时，用于通知源主机 4    Parameter Problem    RFC4443    参数问题,用于向源主机指出错误 100/101    为私人实验保留    RFC4443    为实验保留 127    为ICMPv6差错报文扩充保留    RFC4443    为更多的差错报文保留 128    Echo Request    RFC4443    回显请求，用于诊断网络连通性 129    Echo Reply    RFC4443    回显应答，用于诊断网络连通性 130    Multicast Listener Query    RFC2710    组播侦听器查询，用于查询链路上的组播组成员 131    Multicast Listener Report    RFC2710    组播侦听器报告，用于主机加入组播组 132    Multicast Listener Done    RFC2710    组播侦听器终止，用于主机离开组播组 133    Router Solicitation    RFC4861    路由器请求，用于主机发现本地路由器 134    Router Advertisement    RFC4861    路由器通告，用于路由器通告其存在及相关链路参数 135    Neighbor Solicitation    RFC4861    邻居请求，用于链路层地址解析、重复地址检测等 136    Neighbor Advertisement    RFC4861    邻居通告，用于响应邻居请求或主动通告链路层变化 137    Redirect    RFC4861    重定向，用于路由器通知主机有更好的下一跳 138    Router Renumbering    RFC2894    路由器重编号，用于管理员重新编址路由器 139    ICMP Node Information Query    RFC4620    ICMP节点信息查询，用于获取相邻节点的名字和地址信息 140    ICMP Node Information Response    RFC4620    ICMP节点信息响应，用于应答节点信息查询 141    Inverse Neighbor Discovery Solicitation    RFC3122    反向邻居发现请求，用于检查IPv6到链路层地址的映射 142    Inverse Neighbor Discovery Advertisement    RFC3122    反向邻居发现通告，用于响应反向邻居发现请求 143    Multicast Listener Discovery (MLDv2) reports    RFC3810    组播侦听器发现(MLDv2)报告，用于MLDv2管理组播组成员 144    Home Agent Address Discovery Request    RFC6275    家乡代理地址发现请求，用于移动IPv6中发现家乡代理 145    Home Agent Address Discovery Reply    RFC6275    家乡代理地址发现响应，用于移动IPv6中响应家乡代理发现 146    Mobile Prefix Solicitation    RFC6275    移动前缀请求，由移动节点请求家乡代理前缀 147    Mobile Prefix Advertisement    RFC6275    移动前缀通告，由家乡代理向移动节点通告移动前缀 148    证书路径请求报文    RFC3971    一条证书路径的保护邻居发现(SEND)请求 149    证书路径通告报文    RFC3971    相应一个证书路径请求的SEND 151    组播路由器通告    RFC4286    提供组播路由器的地址 152    组播路由器请求    RFC4286    请求组播路由器的地址 153    组播路由器终止    RFC4286    组播路由器使用结束 154    FMIPv6    RFC5568    MIPv6快速切换报文 200/201    为私人实验保留    RFC4443    为实验保留 255    为ICMPv6信息类报文扩充保留    RFC4443    为更多的信息类报文保留 2.3 ICMPv6常见代码 类型    代码    名称    描述 1    0    No route to destination    无法路由到目标 1    1    Communication with destination administratively prohibited    与目标通信被管理员禁止 1    2    Beyond scope of source address    超出源地址的作用域 1    3    Address unreachable    地址不可达 1    4    Port unreachable    端口不可达 1    5    Source address failed ingress/egress policy    源地址未通过入口/出口策略 1    6    Reject route to destination    拒绝到目标的路由 1    7    Error in Source Routing Header    源路由头部错误 3    0    Hop limit exceeded in transit    传输过程中超过跳数限制 3    1    Fragment reassembly time exceeded    分片重组超时 4    0    Erroneous header field encountered    遇到错误的头部字段 4    1    Unrecognized Next Header type encountered    遇到无法识别的下一个头部类型 4    2    Unrecognized IPv6 option encountered    遇到无法识别的IPv6选项 类型1的目标不可达有多达8种情况，比如无法路由、地址或端口不可达、通信被禁止、超出作用域等，对应了在数据包转发过程中可能遇到的各种问题。  类型3的超时有2种情况，分别是超过跳数限制和分片重组超时。其中跳数限制反映了IPv6网络直径的限制，防止数据包无限循环转发。  类型4的参数问题有3种情况，分别涉及头部字段错误、无法识别的下一个头部类型和IPv6选项，反映了数据包解析过程中可能遇到的问题。  2.4 ICMPv6差错报文限制 在某些情况下，网络设备不会产生ICMPv6差错报文，以避免网络拥塞、安全问题或无用的错误报告：  组播地址，当IPv6数据报的目标地址是组播地址时，通常不会产生ICMPv6差错报文(数据包太大例外)。 链路层组播和广播报文，数据包太大这种情况例外。 ICMPv6差错报文，为了避免无限循环，当一个ICMP差错报文触发另一个差错时，通常不会再生成新的ICMP差错报文。 ICMPv6重定向报文。 源地址不是唯一识别的单个节点，如未指定的地址、组播地址等。 扩展头处理，当IPv6数据报包含未知的扩展头或扩展头处理错误时，通常不会产生ICMPv6差错报文，以避免信息泄露和网络拥塞。 安全策略，根据网络管理员的安全策略，某些类型的ICMPv6报文可能会被禁用或过滤,如ping请求、路由器通告等。 隐私保护，为了保护网络用户的隐私，某些ICMPv6报文可能会被抑制，如邻居发现协议中的邻居请求和邻居通告报文。 RFC 4443中对ICMPv6差错报文的生成和发送做了一些限制和规定，主要涉及令牌桶限速：  每个ICMP差错报文类型应独立维护一个令牌桶，用于限制该类型差错报文的发送速率。 推荐的限速值为每秒不超过2个差错报文令牌，或每秒不超过目的地的路径MTU(PMTU)大小的令牌数。 对于代码0-127的差错报文，必须严格限速。 对于代码128-255的信息查询报文，可以不限速。 实现可以进一步区分不同代码的差错报文，对每个代码应用独立的令牌桶和限速值。 3. ICMPv6基础消息 ICMPv6基础消息指定义在RFC 4443中的基础控制消息，不涉及IPv6网络地址和路由协商的部分。  3.1 ICMPv6目的不可达 ICMPv6的目的不可达报文(Destination Unreachable Message)是类型1的差错报文，用于在数据包无法送达目标时，由路由器或主机向源端发送，告知其发生了不可达的情况。  RFC 4443报文的格式如下:              Destination Unreachable Message(RFC 4443)    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Type      |     Code      |          Checksum             |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                             Unused                            |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                    As much of invoking packet                 |   +                as possible without the ICMPv6 packet          +   |                exceeding the minimum IPv6 MTU [IPv6]          | 字段说明如下:  Type(8位)，值为1，表示目的不可达报文。 Code(8位)，表示不可达的具体原因，有七个不同原因。 Checksum(16位)，ICMPv6校验和。 unused(32位)，未使用字段，必须置0，接收者需要忽略这个数据。 Original IP Data Datagram，包含引发差错报文的原始IP数据报数据。在不超过1280字节(IPv6最小MTU)的情况下，应尽量的多包涵原始数据。常包括完整的IPv6头部和至少64字节的负载数据。 RFC 4884报文格式如下(支持扩展数据结构):              Destination Unreachable Message(RFC 4884)    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Type      |     Code      |          Checksum             |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |    Length     |                  Unused                       |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                    As much of invoking packet                 |   +                as possible without the ICMPv6 packet          +   |                exceeding the minimum IPv6 MTU [RFC4443]       |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |             ICMPv6扩展头部以及零个或多个关联对象                      |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type、Code、Checksum、unused字段与原有格式相同。 Original IPv6 Header + data，数据部分，包含引发差错报文的原始IP数据报的IP头部和数据。处于兼容性考虑，原始数据报的长度至少为128字节，如果不满足，则需要使用零填充。 Length，指示Original IPv6 Header + data字段的长度，单位为8字节(IPv4和IPv6单位不一样)。 当路由器或主机无法转发或处理接收到的数据包时，就会向源端发送一个相应的目的不可达报文。源端收到该报文后，可以根据Code值判断具体的不可达原因，并结合数据部分携带的原始报文信息进行问题的定位和调整。  code0，无路由到目的地(No route to destination)，该代码表示数据包无法被转发，因为路由表中没有匹配的路由项，或者路由器无法确定下一跳地址。 代码1，与目的地的通信被管理性禁止(Communication with destination administratively prohibited)，该代码表示数据包被网络管理策略阻止，如访问控制列表(ACL)或防火墙规则等。 代码2，超出源地址作用域(Beyond scope of source address)，该代码表示源节点的地址在目的地的作用域之外，常见于使用链路本地地址或唯一本地地址时。 代码3，地址不可达(Address unreachable)，该代码表示路由器能够匹配路由表项，但无法在本地链路上解析目的IPv6地址对应的MAC地址。 代码4，端口不可达(Port unreachable)，该代码表示数据包已到达目的节点，但目的传输层端口没有相应的应用程序在监听。 代码5，源地址失败入口/出口策略(Source address failed ingress/egress policy)，该代码表示数据包被源地址验证或过滤机制丢弃，如反向路径转发(RPF)检查失败等。 代码6，拒绝路由到目的地(Reject route to destination)，该代码表示路由器的路由表中存在到目的地的路由，但该路由被配置为拒绝数据包，如使用了拒绝路由(Reject route)或黑洞路由(Blackhole route)。 3.2 ICMPv6报文太大 ICMPv6的PTB(Packet Too Big)报文是一种重要的错误报告消息，用于通知源节点发送的数据包超过了链路的MTU(最大传输单元)，需要进行分片。              Packet Too Big Message(RFC 4443)    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Type      |     Code      |          Checksum             |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                             MTU                               |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                    As much of invoking packet                 |   +               as possible without the ICMPv6 packet           +   |               exceeding the minimum IPv6 MTU [IPv6]           | Type(8位)，值为2，表示报文太大的消息。 Code(8位)，固定为0。 Checksum(16位)，ICMPv6校验和。 MTU(32位)，表示下一跳链路的MTU值，单位为字节，源节点应根据该值对后续数据包进行分片或调整大小。 Original IP Data Datagram，包含引发差错报文的原始IP数据报数据。在不超过1280字节(IPv6最小MTU)的情况下，应尽量的多包涵原始数据。常包括完整的IPv6头部和至少64字节的负载数据。 PTB报文属于ICMPv6的类型2报文，代码字段固定为0。当路由器收到一个IPv6数据包，且该数据包的大小超过了出接口的MTU时，路由器会丢弃该数据包，并向源节点发送一个PTB报文。  当源节点收到PTB报文时，会更新其路径MTU发现(PMTUD)状态，并根据PTB报文中指示的MTU值对后续数据包进行分片或调整大小，这有助于提高网络效率和避免不必要的数据包丢失。  PTB报文是实现IPv6路径MTU发现(PMTUD)机制的关键，PMTUD允许源节点动态地发现端到端路径上的最小MTU，并相应地调整数据包大小，从而优化网络性能。  为防止PTB报文被恶意节点用于攻击，如欺骗源节点使用较小的MTU导致分片和重组开销增加，源节点通常会对收到的PTB报文进行验证，如检查报文中包含的原始数据包是否为自己发送的。  3.3 ICMPv6超时报文 ICMPv6超时报文是一种错误报告消息，用于通知源节点在数据包传输过程中发生了超时。当路由器或目的节点在规定的时间内未能完成数据包的转发或处理时，就会向源节点发送超时报文。                 Time Exceeded Message(RFC 4443)    0                   1                   2                   3    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Type      |     Code      |          Checksum             |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                             Unused                            |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                    As much of invoking packet                 |   +               as possible without the ICMPv6 packet           +   |               exceeding the minimum IPv6 MTU [IPv6]           | 字段说明:  Type(8位)，对于超时报文，该字段固定为3。 Code(8位)，表示ICMPv6超时报文的代码。 Checksum(16位)，ICMPv6报文的校验和，计算方法与PTB报文相同。 Unused(32位)，未使用字段，必须初始化为0，并在处理时忽略。 As much of invoking packet(可变长度)，包含引发差错报文的原始IP数据报数据。在不超过1280字节(IPv6最小MTU)的情况下，应尽量的多包涵原始数据。常包括完整的IPv6头部和至少64字节的负载数据。 字段说明:  Type(8位)，表示ICMPv6报文的类型，对于组播监听者查询报文,该字段值为130，对于组播监听者报告报文,该字段值为131，对于组播监听者结束报文,该字段值为132。  Code(8位)，表示ICMPv6报文的代码，对于这三种报文，该字段始终为0。  Checksum(16位)，ICMPv6报文的校验和，计算方法与其他ICMPv6报文类似。  Maximum Response Delay(16位，仅出现在查询报文中)，指定主机在发送报告报文之前应该等待的最大延迟时间，以毫秒为单位。  Reserved(16位或32位)，保留字段，必须初始化为0。  Multicast Address(128位)，指定查询、报告或结束消息所针对的组播地址。  MLDv1协议的基本工作原理如下:  路由器定期向链路本地的所有节点组播地址(FF02::1)发送组播监听者查询报文，询问链路上的主机是否有加入任何组播组。 主机收到查询报文后，为其加入的每个组播组发送一个组播监听者报告报文，告知路由器自己的组播组成员身份。 当主机离开某个组播组时，它会向该组播组的地址发送一个组播监听者结束报文，通知路由器自己已经离开该组。 路由器根据收到的报告和结束报文，维护和更新本地的组播组成员关系，并相应地转发或过滤组播流量。 通过使用MLDv1协议，IPv6网络可以高效地管理和优化组播流量的分发，减少不必要的网络开销，常用于支持IPTV、在线会议等大规模组播应用。  4.4 组播侦听发现 RFC 3810中定义的ICMPv6类型143(Multicast Listener Discovery Version 2 Reports)报文及其格式。MLDv2是MLDv1的增强版本,提供了更多的功能和灵活性，如支持源特定组播(SSM)、更细粒度的组播过滤等。  MLDv2协议的基本工作原理与MLDv1类似，但引入了一些新的机制和概念:  过滤模式，MLDv2支持INCLUDE和EXCLUDE两种过滤模式。在INCLUDE模式下，主机只接收来自指定源列表的组播流量。在EXCLUDE模式下，主机接收来自指定源列表之外的所有源的组播流量。 源列表，MLDv2允许主机在报告报文中携带一个源地址列表，指定其希望接收或屏蔽的组播源，这为实现SSM提供了支持。 异步报告，与MLDv1不同，MLDv2中的主机可以在任何时候发送报告报文，而不必等待路由器的查询。 MLDv2协议的实现和部署比MLDv1更加复杂，需要主机和路由器都支持MLDv2的功能。此外，MLDv2报文的长度和处理开销也较MLDv1有所增加。因此，在实际网络中部署MLDv2时，需要仔细评估其必要性和可行性，并采取适当的优化措施，如使用SSM映射、配置合适的查询间隔等。  4.5 组播路由器发现 RFC 4286中定义的ICMPv6类型151、152和153这三种报文用于实现多播路由器广告(Multicast Router Advertisement, MRA)和多播路由器请求(Multicast Router Solicitation, MRS)功能，支持在IPv6网络中发现和管理多播路由器。 以上映射表总结了常见的ICMPv6类型和代码到ICMPv4的转换关系。需要注意的是:  一些ICMPv6消息(如Packet Too Big和Redirect)在ICMPv4中没有完全等价的消息，转换时可能需要近似处理或丢弃。 有些ICMPv6的目的不可达代码被映射到ICMPv4的不同类型和代码组合。 ICMPv6的参数问题消息有更细粒度的错误原因区分，转换到ICMPv4时可能丢失一些信息。 转换过程中需要注意处理ICMPv6特有的扩展头部和选项。 7. 总结 ICMPv6协议涉及的内容相比于ICMPv4复杂很多，ICMPv4最主要用途是链路探测和差错报文。ICMPv6则增加了路由器发现、邻居发现、移动IP、组播管理等多个子模块，协议内容大幅增加。  ICMPv6路由器和邻居发现一定程度上拜托了对DHCP的依赖，并且不再需要ARP这样的中间协议，但这样也导致ICMPv6看起来非常臃肿。可以从ICMPv6基础消息逐步扩展，组播和移动代理相关知识可以先忽略，邻居发现类知识单独总结学习，这样就简单很多了。 ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/Once_day/article/details/139576663 

一、流媒体：RTSP 和RTMP 1、RTSP 和 RTMP的工作原理 1）RTSP工作原理 用户设备向视频流平台发送 RTSP 请求  视频流平台返回可以操作的请求列表，比如播放、暂停等  用户设备向视频流平台发送具体的请求，比如播放  视频流平台解析请求并调用指定机制启动视频流处理  由于 RTSP 依赖于专用服务器，并且依赖于 RTP（底层用到了UDP），因此该协议不支持加密视频内容或重传丢失的数据包。  这里解释一下RTSP中是如何用到UDP和TCP的：  RTP协议，英文全称：Real-time Transport Protocol，中文就是实时传输协议，它的底层其实就是UDP，这样一来就可以实现低延迟。  除了RTP协议，为确保流畅和一致的流传输，RTSP 还使用另外两种网络通信协议：  TCP 收发控制命令（例如播放或停止请求）：TCP可靠传输，比如用户按下播放或者停止播放的时候，这个是个准确的请求，这个需要保证可靠性，这个时候TCP作用就体现了。 UDP传送音频、视频和数据：UDP是低延迟的协议，那么用于传送音频、视频和数据可以达到非常高效的效果。 这里可以通过开源的rtsp服务器可以简单理解：TCP监听端口为8554，UDP监听端口为8000  2）RTMP工作原理 摄像头捕获视频  通过编码器将视频流传输到视频平台服务器  视频平台处理视频流  通过CDN分发到离用户最近的服务器上  最后视频流就能成功的到达用户设备  在视频从摄像头到服务器的过程中，RTMP将大量数据分割成小块并跨多个虚拟通道传输（内容分发网络CDN），在视频源和 RTMP 服务器之间提供了稳定和流畅的视频流。  2、RTSP 和 RTMP的优缺点 1）RTSP的优缺点 RTSP的优点：  1、轻松自定义流：可以通过结合不同的协议来开发自己的视频流解决方案。  2、分段流式传输：RTSP 流使观看者能够在下载完成之前访问的视频内容，而不必下载完整的视频以流式传输内容。  RTSP的缺点：  1、与 HTTP不兼容：没有简单的解决方案可以在 Web 浏览器中播放 RTSP流，因为 RTSP 旨在通过私有网络流式传输视频，必须借用额外软件。  2、使用率低：由于视频播放器和流媒体服务并未广泛支持 RTSP 流媒体，因为使用率比较低。  2）RTMP的优缺点 RTMP的优点：  1、低延迟：RTMP使用独占的 1935 端口，无需缓冲，可以实现低延迟。  2、适应性强：所有 RTMP 服务器都可以录制直播媒体流，同时还允许观众跳过部分广播并在直播开始后加入直播流。  3、灵活性：RTMP 支持整合文本、视频和音频，支持 MP3 和 AAC 音频流，也支持MP4、FLV 和 F4V 视频。  RTMP的缺点：  1、HTML5 不支持：标准HTML5 播放器不支持 RTMP 流。  2、容易受到带宽问题的影响：RTMP 流经常会出现低带宽问题，造成视频中断。  3、HTTP 不兼容：无法通过 HTTP 流式传输 RTMP，必须需要实现一个特殊的服务器，并使用第三方内容交付网络或使用流媒体视频平台。  3）RTSP和RTMP的比较 RTMP 和 RTSP协议 都是流媒体协议：  RTMP（Real Time Message Protocol 实时消息传递协议） 有 Adobe 公司提出，用来解决多媒体数据传输流的多路复用（Multiplexing）和分包（packetizing）的问题，优势在于低延迟，稳定性高，支持所有摄像头格式，浏览器加载 flash插件就可以直接播放。 RTSP （Real-Time Stream Protocol 实时流协议）由Real Networks 和 Netscape共同提出的，基于文本的多媒体播放控制协议。RTSP定义流格式，流数据经由RTP传输；RTSP实时效果非常好，适合视频聊天，视频监控等方向。 RTMP 和 RTSP协议 的区别：  RTSP虽然实时性最好，但是实现复杂，适合视频聊天和视频监控；  RTMP强在浏览器支持好，加载flash插件后就能直接播放，所以非常火，相反在浏览器里播放rtsp就很困难了。  3、RTSP和RTMP如何选择 IP 摄像机选择RTSP：几乎所有 IP 摄像机都支持 RTSP，这是因为 IP 摄像机早在 RTMP 协议创建之前就已经存在，与 RTSP 和 IP 摄像机结合使用时，IP 摄像机本身充当 RTSP 服务器，这意味着要将摄像机连接到 IP 摄像机服务器并广播视频。  物联网设备选择RTSP：RTSP 通常内置在无人机或物联网软件中，从而可以访问视频源，它的好处之一是低延迟，确保视频中没有延迟，这对于无人机来说至关重要。  流媒体应用程序选择RTMP：比如各种短视频软件、视频直播软件等都内置了RTMP，RTMP 是为满足现代流媒体需求而设计的。  4、如何在浏览器上播放RTSP 直播的协议有：rtmp, http, rtsp等等。最常用的有二种：http, rtmp，当使用http协议的时候视频格式需要是m3u8或flv，下面作详细说明各种环境的优缺点。首先，rtsp不能使用于网页环境（包含PC端和移动端），那么直播只能选择rtmp或http。  rtmp协议只支持flashplayer，也就是只能在PC端（或安卓环境中安装了flashplayer组件，这种环境比较少）安装了flashplayer的情况下使用。按现在的趋势，flashplayer是要逐渐被淘汰掉的。当然，在中国还会存在相对长时间。  http协议的直播分二种格式，m3u8和flv。flv是一种即将被淘汰的直播格式。用来做直播已显的力不从心了。所以综合考虑，m3u8相对的比较好点，优点是支持移动端，并且支持PC端上安装了flashplayer的环境。缺点就如同rtmp一样。flashplayer并不是未来的发展趋势。另外一个缺点就是m3u8是有延迟的。并不能实时，实时传输方面不如rtmp协议。因为 m3u8的直播原理是将直播源不停的压缩成指定时长的ts文件（比如9秒，10秒一个ts文件）并同时实时更新m3u8文件里的列表以达到直播的效果。这样就会有一个至少9,10秒的时间延迟。如果压缩的过小，可能导致客户端网络原因致视频变卡。  实现rtsp转http并使用m3u8格式进行直播   具体过程：外接支持rtsp的webcam；使用ffplay命令来播放rtsp流，可以根据参数将实时视频写入到指定文件夹中（分段写入）；xampp开启apache（开启80端口），可以让页面通过保存的m3u8文件实时访问webcam的监控界面。  二、ffmpeg将本地摄像头推流到RTSP服务器  2）RTMP工作原理 摄像头捕获视频  通过编码器将视频流传输到视频平台服务器  视频平台处理视频流  通过CDN分发到离用户最近的服务器上  最后视频流就能成功的到达用户设备  在视频从摄像头到服务器的过程中，RTMP将大量数据分割成小块并跨多个虚拟通道传输（内容分发网络CDN），在视频源和 RTMP 服务器之间提供了稳定和流畅的视频流。  2、RTSP 和 RTMP的优缺点 1）RTSP的优缺点 RTSP的优点：  1、轻松自定义流：可以通过结合不同的协议来开发自己的视频流解决方案。  2、分段流式传输：RTSP 流使观看者能够在下载完成之前访问的视频内容，而不必下载完整的视频以流式传输内容。  RTSP的缺点：  1、与 HTTP不兼容：没有简单的解决方案可以在 Web 浏览器中播放 RTSP流，因为 RTSP 旨在通过私有网络流式传输视频，必须借用额外软件。  2、使用率低：由于视频播放器和流媒体服务并未广泛支持 RTSP 流媒体，因为使用率比较低。  2）RTMP的优缺点 RTMP的优点：  1、低延迟：RTMP使用独占的 1935 端口，无需缓冲，可以实现低延迟。  2、适应性强：所有 RTMP 服务器都可以录制直播媒体流，同时还允许观众跳过部分广播并在直播开始后加入直播流。  3、灵活性：RTMP 支持整合文本、视频和音频，支持 MP3 和 AAC 音频流，也支持MP4、FLV 和 F4V 视频。  RTMP的缺点：  1、HTML5 不支持：标准HTML5 播放器不支持 RTMP 流。  2、容易受到带宽问题的影响：RTMP 流经常会出现低带宽问题，造成视频中断。  3、HTTP 不兼容：无法通过 HTTP 流式传输 RTMP，必须需要实现一个特殊的服务器，并使用第三方内容交付网络或使用流媒体视频平台。  3）RTSP和RTMP的比较 RTMP 和 RTSP协议 都是流媒体协议：  RTMP（Real Time Message Protocol 实时消息传递协议） 有 Adobe 公司提出，用来解决多媒体数据传输流的多路复用（Multiplexing）和分包（packetizing）的问题，优势在于低延迟，稳定性高，支持所有摄像头格式，浏览器加载 flash插件就可以直接播放。 RTSP （Real-Time Stream Protocol 实时流协议）由Real Networks 和 Netscape共同提出的，基于文本的多媒体播放控制协议。RTSP定义流格式，流数据经由RTP传输；RTSP实时效果非常好，适合视频聊天，视频监控等方向。 RTMP 和 RTSP协议 的区别：  RTSP虽然实时性最好，但是实现复杂，适合视频聊天和视频监控；  RTMP强在浏览器支持好，加载flash插件后就能直接播放，所以非常火，相反在浏览器里播放rtsp就很困难了。  3、RTSP和RTMP如何选择 IP 摄像机选择RTSP：几乎所有 IP 摄像机都支持 RTSP，这是因为 IP 摄像机早在 RTMP 协议创建之前就已经存在，与 RTSP 和 IP 摄像机结合使用时，IP 摄像机本身充当 RTSP 服务器，这意味着要将摄像机连接到 IP 摄像机服务器并广播视频。  物联网设备选择RTSP：RTSP 通常内置在无人机或物联网软件中，从而可以访问视频源，它的好处之一是低延迟，确保视频中没有延迟，这对于无人机来说至关重要。  流媒体应用程序选择RTMP：比如各种短视频软件、视频直播软件等都内置了RTMP，RTMP 是为满足现代流媒体需求而设计的。  4、如何在浏览器上播放RTSP 直播的协议有：rtmp, http, rtsp等等。最常用的有二种：http, rtmp，当使用http协议的时候视频格式需要是m3u8或flv，下面作详细说明各种环境的优缺点。首先，rtsp不能使用于网页环境（包含PC端和移动端），那么直播只能选择rtmp或http。  rtmp协议只支持flashplayer，也就是只能在PC端（或安卓环境中安装了flashplayer组件，这种环境比较少）安装了flashplayer的情况下使用。按现在的趋势，flashplayer是要逐渐被淘汰掉的。当然，在中国还会存在相对长时间。  http协议的直播分二种格式，m3u8和flv。flv是一种即将被淘汰的直播格式。用来做直播已显的力不从心了。所以综合考虑，m3u8相对的比较好点，优点是支持移动端，并且支持PC端上安装了flashplayer的环境。缺点就如同rtmp一样。flashplayer并不是未来的发展趋势。另外一个缺点就是m3u8是有延迟的。并不能实时，实时传输方面不如rtmp协议。因为 m3u8的直播原理是将直播源不停的压缩成指定时长的ts文件（比如9秒，10秒一个ts文件）并同时实时更新m3u8文件里的列表以达到直播的效果。这样就会有一个至少9,10秒的时间延迟。如果压缩的过小，可能导致客户端网络原因致视频变卡。  实现rtsp转http并使用m3u8格式进行直播 可以参考RTSP Webcam to HLS Live Streaming using FFMPEG and XAMPP | PART 1  具体过程：外接支持rtsp的webcam；使用ffplay命令来播放rtsp流，可以根据参数将实时视频写入到指定文件夹中（分段写入）；xampp开启apache（开启80端口），可以让页面通过保存的m3u8文件实时访问webcam的监控界面。  二、ffmpeg将本地摄像头推流到RTSP服务器  Note：ffmpeg将本地摄像头推流到rtsp的8554端口上（rtsp-simple-server在处理rtsp时，监听的是8554端口，指定其他端口ffmpeg推流会失败)  1、安装ffmpeg和rtsp-simple-server 大致实现过程：使用rtsp-simple-server作为中转服务器，用于ffmpeg（写客户端）推流，后台服务（读客户端）拉流  1）windows安装rtsp-simple-server和ffmpeg 参考windows环境下，搭建RTSP视频推流服务器即可（记得修改rtsp-simple-server.yml配置文件中的ip地址）  2）linux安装rtsp-simple-server和ffmpeg 安装rtsp-simple-server_v0.20.2_linux_amd64.tar.gz（这里以x86 CPU为例），解压后修改rtsp-simple-server.yml配置文件中的ip地址（vim替换命令为%s:/127.0.0.1/192.168.132.100/g），执行./rtsp-simple-server即可启动rtsp服务器。  如果要想在后台启动rtsp服务器，执行如下命令  nohup ./rtsp-simple-server >> rtsp_server.log 2>&1 &  #非挂起启动命令  tail rtsp_server.log  #查看rtsp-simple-server启动日志文件  ps -aux | grep rtsp_simple_server  #查看rtsp-simple-server进程 dpf        2116  0.0  0.0  13140  1016 pts/0    S+   04:54   0:00 grep --color=auto rtsp_simple_server  ffmpeg安装，解压后执行./ffmpeg即可使用ffmpeg，参考在linux下使用ffmpeg方法  Note：在linux中关于tar.gz，xz，tar的解压操作请自行上网查阅。  2、将本地摄像头推流到RTSP服务器 大致实现过程：使用rtsp-simple-server作为中转服务器，用于ffmpeg（写客户端）推流，后台服务（读客户端）拉流  这里以windows系统作为演示，先解压rtsp-simple-server_v0.19.1_windows_amd64.zip，打开rtsp-simple-server.exe监听RTSP下TCP的8554端口，然后通过ffmpeg将指定摄像头采集到的图像帧向该端口进行推流（即多个客户端与服务器端的socket通信）  1）写客户端：ffmpeg ffmpeg推流视频文件到指定ip + 端口上（-stream_loop -1）：  ffmpeg -re -stream_loop -1 -i 你视频的文件名 -c copy -f rtsp rtsp://127.0.0.1:8554/videoFile_test 1 ffmpeg将本地摄像头的视频流推送到指定ip + 端口上，则需要  //获取本地摄像头名称 ffmpeg -list_devices true -f dshow -i dummy    //ffmpeg向指定端口推流（我的是Integrated Camera） ffmpeg -f dshow -i video="自己的摄像头驱动名称" -vcodec libx264 -preset:v ultrafast -tune:v zerolatency -rtsp_transport tcp -f rtsp rtsp://127.0.0.1:8554/camera_test //libx264编码 ffmpeg -f dshow -i video="Integrated Camera" -vcodec libx264 -preset:v ultrafast -tune:v zerolatency -rtsp_transport tcp -f rtsp rtsp://127.0.0.1:8554/camera_test ）服务器端：RTSP服务器 初启动效果如下：  3）读客户端：读客户端可以通过两种方式来实现 安装VLC，选择流数据播放模式，输入rtsp://127.0.0.1:8554/camera_test，rtsp://127.0.0.1:8554/videoFile_test即可播放；  亦或者使用如下python代码：  import cv2   def capture_video(rtsp_path):     name = rtsp_path.split("/")[-1]     capture = cv2.VideoCapture(rtsp_path)     while capture.isOpened():         ret, frame = capture.read()         if not ret:             break         cv2.imshow(name, frame)         if cv2.waitKey(50) == 27:             break   if __name__ == '__main__':     # rtsp_paths = ['rtsp://127.0.0.1:8554/videoFile_test','rtsp://127.0.0.1:8554/camera_test']     rtsp_paths = ['rtsp://127.0.0.1:8554/videoFile_test']     for rtsp_path in rtsp_paths:         capture_video(rtsp_path)       cv2.waitKey(0)     cv2.destroyAllWindows()  此时会出现两个createby和reading，即开启两个进程进行视频流的读取 ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/aisheisadas/article/details/137669624 

CNM(Container Network Model)是Cisco的一位工程师提出的一个容器网络模型， Docker 1.9在Libnetwork中实现了CNM，现在CNM已经被Kuryr、OVN、Calico、Weave和Contiv等公司和项目所采纳。CNM的示意如图9-8所示，它主要建立在3类组件上: Sandbox、Endpoint和 Network。 1)Sandbox:一个Sandbox 对应一个容器的网络栈，能够对该容器的接口、路由、 DNS等参数进行管理。一个Sandbox中可以有多个Endpoint，这些Endpoint可以属于不同的Network.Sandbox的实现可以为Linux网络命名空间、FreeBSD Jail或其他类似的机制。2)端点: Sandbox通过端点接人网络，一个端点只能属于一个Network。端点的实现可以是veth pair、Open vSwitch内部端点或者其他类似的设备。 3)网络:一个网络由一组端点组成,这些端点彼此间可以直接通信，不同网络间端点的通信彼此隔离。网络的实现可以是Linux Bridge、OpenvSwitch等。 Libnetwork 对于CNM的实现包括以下5类对象。 1)NetworkController:每创建一个网络对象时，就会相应地生成一个Network- Controller对象，NetworkController对象将网络对象的API暴露给用户，以便用户对 libnetwork进行调用，然后驱动特定的Driver对象实现网络对象的功能。NetworkController允许用户绑定网络对象所使用的Driver对象。NetworkController对象可以看作是网络对象的分布式SDN控制器。 2)Network :Network对象是CNMNetwork的一种实现。NetworkController对象通过提供API对Network对象进行创建和管理。NetworkController对象需要操作Network 对象的时候，Network对象所对应的Driver对象会得到通知。一个Network对象能够包含多个端点对象，一个Network对象中包含的各个端点对象间可以通过Driver完成通信，这种通信支持可以是同一主机的，也可以是跨主机的。不同Network对象中的端点对象间彼此隔离。3)Driver:Driver对象能真正实现Network功能(包通和管理)，它并不直接暴露API给用户。Libnetwork支持多种Driver，其中包括内置的bridge，host,container 和 overlay，也支持remote driver(即第三方或用户自定义的网络驱动)。 4)Endpoint:Endpoint对象是CNMEndpoint的一种实现。容器通过Endpoint对象接人Network，并通过Endpoint对象与其他容器进行通信。一个Endpoint对象只能属于一个 Network对象，Network对象的API对于Endpoint对象提供了创建与管理。 5)Sandbox:Sandbox对象是CNMSandbox的一种实现。Sandbox对象代表了一个容器的网络栈，它拥有IP地址、MAC 地址、路由、DNS等网络资源。一个Sandbox对象可以有多个Endpoint对象，这些Endpoint对象可以属于不同的Network对象，Endpoint对象使用Sandbox对象中的网络资源与外界进行通信。Sandbox对象的创建发生在Endpoint对象创建后,(Endpoint对象所属的)Network对象所绑定的Driver对象为该Sandbox对象分配网络资源并返回给libnetwork，然后libnetwork使用特定的机制(如linux netns)配置SandBox对学校中对应的网络资源。

容器这两年可谓风生水起，相比虚拟机来说，容器更轻，一台服务器上可以运行成百上千个容器，这意味着可以有更为密集的计算资源。因此基于容器运行工作负载的模式深受云服务提供商的青睐。 然而对于云管理员来说，管理容器确是一件相当头疼的事情，容器的生命周期更短了，容器的数量更多了，容器间的关系更复杂了。为了简化大规模容器集群的运维，各路容器管理与编排平台应运而生，Docker社区开发了Swarm+Machine+Compose的集群管理套件， Twitter 主推 Apache 的Mesos,Google则开源了自己的Kubernetes。这些平台为大规模的容器集群提供了资源调度、服务发现、缩容等功能，然而这些功能都是策略性的，真正要实现大规模的容器集群，网络才是最基础的一环。 相比于虚拟机网络，容器网络主要具有以下特点，以及相应的技术挑战: 1)虚拟机拥有完善的隔离机制，虚拟网卡与硬件网卡在使用上没有什么区别，而容器则使用network namespace提供网络在内核中的隔离，因此为了保证容器的安全，容器网络的设计需要更为慎重的考虑。 2)出于安全考虑，很多情况下容器会部署在虚拟机内部，这种嵌套部署(nested deployment)需要设计新的网络模型。3)容器的分布不同于虚拟机，一个虚拟机运行的业务可能要拆分到多个容器上运行。根据不同业务的需要，这些容器有时候必须放在一台服务器中，有时候可以分布在网络的各个位置，两种情况对应的网络模型很可能不尽相同。 4)容器的迁移速度更快，网络策略的更新要能够跟得上其速度。5)容器数量更多了，多主机间的ARP泛洪会造成大量的资源浪费。 6)容器生命周期短，重启非常频繁，网络地址的有效管理(IPAM)将变得非常关键。不过，由于容器自身的特征使得它与应用的绑定更为紧密。从交付模式来看，更倾向于PaaS 而非Iaas，因此容器网络并没有成为业界最初关注的焦点。它起步较晚，再加上上述诸多的技术挑战，使得容器网络相比于OpenStack Neutron来说发展的情况要落后不少。 Docker在开始的很长一段时间内只支持使用LinuxBridge +Iptables进行single-host的部署，自动化方面也只有Pipework 这类 shell 脚本。 幸运的是，目前业界已经意识到了可扩展、自动化的网络对于大规模容器环境的重要性:Docker收购了容器网络的创业公司socketplane，随即将网络管理从docker daemon中独立出来形成了 libnetwork，并在Docker 1.9中提供了多种network driver，并支持了 multi-host。一些专业的容器网络(如Flannel、Weave、Calico等)也开始与各个容器编排平台进行集成。OpenStack社区也成立了专门的子项目Kuryr,它提供Neutron network driver(如DragonFlow、OVN、Midonet等)与容器对接。

SDN控制器失效后可以通过集群和角色切换来保证控制平面的高可用，如果数据平面上的链路或者节点失效了，可用性就需要通过快速切换路由来实现了。在本章9.2节中讨论了一些十分复杂的快速重路由机制，而对于OpenFlow来说实现快速重路由则相对简单，大概可以分为Reactive和Proactive两种实现方式。在Reactive方式中，控制器通常会通过 PacketOut/PacketIn LLDP来探测拓扑，一旦发现了拓扑的变化就为相关流量计算新的路径，并下发新的FlowMod实现重路由θ。在Proactive方式中，控制器可以通过Failover Group来卸载上述的处理工作，控制器会预先计算并下发备份路径，交换机在探测到端口Down之后可在本地快速地切换到备份路径上。 不过一般来说，FailoverGroup也只能监测到端口Down，而对于路径的通断一无所知。在传统网络中路径的通断通常是由BFD监测的，BFD是一种特殊的Hello 消息，路径两端的交换机需要为BFD Session维护状态，如果在几个interval 内没有收到BFD消息则认为该路径已断。将OpenFlow结合BFD，需要在交换机中增加BFD的控制机制，这虽然有悖于OpenFlow的设计原则，但是由于一些关键路径对切换有50ms的时间要求，而控制器从发现拓扑变化到重新下发路径需要100ms以上°，因此BFD可能是生产网络中唯一的选择。     在OpenFlow交换机中集成Per LSP BFD的思路，左半部分是BFD发送端的处理流程，右半部分是BFD接收端的处理流程。BFD数据包由一种特殊类型OpenFlowVirtualPort产生，控制器可以控制这些Virtual Port产生的 BFD 数据包类型，以及生成BFD数据包的速率。BFD数据包生成后送入Pipeline中进行处理。通过 ALL Group对其进行处理，可为BFD数据包插入一些用于 OAM 的 Metadata，最后标记OAM Tag并发送出去。接收端匹配OAMTag识别出是一个BFD数据包，然后剥掉OAMTg并终结BFD数据包，终结BFD数据包需要一个新的动作，这个动作能够根据 OAM Metadata来更新BFD Session的状态，如果发现BFD超时则立即切换到备用路径上，并通过一种类型为Notification的OpenFlow Error消息来通知控制器。

这个话题可算是老生常谈了。CLI于网络非常重要，尤其是对于运维，很多时候都需要逐台设备地show，然后靠经验来定位问题。不过，如果敲CLI非要到设备前去插console口连，那实在是一件没有效率的事情，设备多了，人力的成本太高。最早的远程登录技术是Telnet，运维用自己本地的一台服务器就可以登录到远端的设备上去敲命令行。不过 Telnet是明文传输，命令很容易被截获和篡改，后面为了安全提出了SSH。几乎所有的网络设备都支持Telnet和SSH,有了远程登录就可以写一些自动化的工具用于设备的集中式管理了。基于 shell 来写VLAN、ACL，可以说是网络运维的基础技能了。 远程登录只是个简单的通道，设备上有什么就只能用什么。而RPC(Remote Procedure Call，远程过程调用)可以使得这个远程通道上有一些自定义的能力，在远端可以任意地调用这些能力。相比于SSH+shell,RPC+高级编程语言能够描述更为复杂的运维逻辑，但是RPC需要对设备端的系统进行升级，传统的网络设不支持。随着云计算的发展，自动化变得越来越重要，Devops概念日渐盛行，数据中心的网络运维自然也要向更好的自动化方向发展。目前流行的Devops工具，包括基于RPC+Ruby的Puppet/Chef以及基于 Python+SSH的 Ansible，已经被广泛地用于云中，网络设备为了支持与云中其他资源的联合编排，也开始在设备中集成这些能力。 无论是传统的SSH+shell 还是目前的Devops，只是CLI多穿了一件衣服，那么它们算不算是 SDN呢?从严格的意义上来讲自然不是，大抵上只能归为自动化运维。不过，目前很多SDN控制器还在大量地使用CLI，这并不是因为SDN控制器的能力不行，而是由于厂商设备对其他接口协议的支持时至今日仍然不够成熟，很多情况下只有用CLI才能解决实际的问题。 CLI用在SDN中，最大的问题有两个:①不支持事务性配置，虽然可以通过RPC来包装一些状态机制，但是没有形成标准化;②机器的可读性很差，程序想要看设备的状态只能用show，返回来一大堆字符串根本不适合机器去做解析。为了在SDN中更好地对设备进行管理和配置，必须要解决CL1存在的这两个问题，目前以NETCONF为OVSDB最为常见。

RIB可编程就是通过对路由表或其他路由相关信息进行控制，从而间接控制转发。FIB可编程主要面向OPENFlow交换机，RIB可编程则是传统路由器由向SDN演化的常见路线，相比于FIB可编程，RIB的演进思路药平滑一些，在大网上具备广泛的部署基础，目前普遍为厂商和运营商所接受。BGP传统路由中，BGP是绕不开的话题，internet的成功很大程度上药归功于BGP，几乎所有的路由器都可以提供对BGP的支持，BGP如何与SDN相联系呢？首先IBGP中天然的存在RR这种集中式的角色，域内所有BGP路由器都和RR建立IBGP邻居，然后这些路由器把自己知道的路由器告诉RR，再由RR反射给其他路由器，传统网络中，RR都是部署在硬件的路由器上的，如果把RR的代码移植到SDN控制器上，使得它在反射前可以通过一些安全策略对反射路由进行过滤，或者通过一些算法来优化发射的路由，比如改写下一跳、改变local preference等，那么就可以实现几种式的智能选路了，这通常被称为RR+。将RR引入SDN控制器还可以实现openFLow或者其他SDN网络与传统IP网络的互通，控制器一方面通过openflow收集openflow域的状态并未其生成路由信息，一方面通过ibgp手机ip域的路由信息，由控制器作为控制平面的网关将ibgp进行对接的方式，控制器还可以通过将ebgp消息在特定的opengflow端口进行packin和packetout，通过openflow交换机来终极ebgp与传统路由器建立邻居，可以打通物理链接的openflow网络和ip网络。bgp是网络领域的老江湖了，经过30多年的发展，无论是在性能还是可扩展性上，可用性上都已经成为业绩所广泛认可，因此在看到bgp和sdn的结合点后，业界有很多声音都呼吁用bgp取代openFLow。

最近新到了20多台服务器，要组个大模型训练集群，因为之前没有相关的经验，特写一遍文章记录相关操作以备不时之需集群类型：负载均衡集群：用于分发网络流量到多个服务器，提高服务的可用性和响应速度。高性能计算集群：用于提高计算能力，通常用于科学计算和数据分析。高可用性集群：确保关键服务的高可用性，通常包括冗余的硬件和软件。分布式存储集群：用于提供大规模的数据存储服务，如SAN或NAS。选择操作系统：根据您的需求选择合适的操作系统，如Linux发行版（如CentOS、Ubuntu、欧拉、麒麟）、Windows Server等。硬件规划：确保所有服务器的硬件配置相似，以便于管理和维护。 考虑网络硬件，如交换机、路由器和负载均衡器。网络配置：设计网络拓扑，确保所有服务器都能高效通信。 配置IP地址和子网掩码，以及必要的路由和负载均衡策略。集群软件：选择合适的集群软件，如Apache Hadoop、Kubernetes、OpenStack等。 安装和配置集群管理软件，如Cloudera Manager、Kubeadm等。存储解决方案：根据需要选择分布式存储系统，如Ceph、GlusterFS等。安全和认证：配置网络安全策略，如防火墙、SSH密钥认证等。 设置集群内部的安全认证机制，如Kerberos、OAuth等。测试和验证：在集群部署完成后，进行全面的测试，确保所有服务按预期运行。 验证集群的容错能力和负载均衡效果。监控和维护：配置监控系统，如Nagios、Zabbix、Prometheus等，以实时监控集群状态。 定期检查和更新软件，确保系统安全性和稳定性。

Contrail 的转发分为两种模式L3mode和L2_L3 mode。L3mode是完全基于虚拟机的32位IP地址进行转发，无论是跨子网的Inter-Subnet流量还是同一子网内的Intra- Subnet流量，L3 mode的转发采用MPLSoverGRE/MPLSoverUDP的封装。而在L2_L3 mode 中，同一子网内的Intra-Subnet流量是基于MAC进行转发，采用VxLAN封装，而跨子网的Inter-Subnet流量是基于虚拟机的32位IP地址进行转发，采用MPLSoverGRE/ MPLSoverUDP 的封装。在L3 mode 中，vRouter对于Inter-Subnet流量采用32位IP地址转发自然是可以理解的，而对于同一子网内的 Intra-Sunbet流量，vRouter则需要进行ARP代理，当虚拟机向同一子网其他虚拟机发送ARP Request时，vRouter会截获此请求并代理回复ARP Reply发布 vRouter网关的任播MAC地址00:00:5c:00:01:00，因此当通信开始后，vRouter即可截获所有的通信流量，然后根据目的虚拟机的32位IP地址进行路由，然后将流量的IP报文封装在MPLSoverGRE/MPLSoverUDP中，远端的vRouter收到后解掉GRE/UDP的封装，根据MPLS进行标签路由，转发给虚拟机前重新为流量添加二层包头，其源地址为vRouter网关的任播MAC地址00:00:5e:00:01:00，目的地址为目的虚拟机的MAC地址。因此，在 L3 mode中，虚拟机的ARP表中，和自身处于同一网段所有IP地址都被解析为了同一个 MAC地址00:00:5e:00:01:00，这也是将L2转发转化为L3转发的一般实现方法。在L2_L3 mode中，对于Intra-Subnet流量和Inter-Subnet流量，两者的处理办法是有所不同的。对于Intra-Subnet流量，vRouter表现为交换机，vRouter不会代理回复ARP Reply,而是通过头端复制的方式在该子网进行泛洪(这一点的实现其实不是很好，即使 vRouter 不去代理回复ARP Request，也可以将该ARPRequest定向封装单播到目的虚拟机所在的远端vRouter,来避免泛洪造成的开销)，但是与传统二层交换机的区别是vRouter会通过XMPP学习MAC路由而非自学习，通信开始后vRouter会根据学习到的租户MAC路由表来进行二层转发，数据平面的封装采用VxLAN。对于Inter-Subnet流量，L2_L3 mode 的处理方式与L3 mode的处理相同，都是基于32位IP地址进行转发，由于VxLAN内部只能支持L2，因此L2_L3mode下Inter-Subnet流量也只能采用MPLSoverGRE 或者 MPLSoverUDP 的封装。2.服务链流量的处理对于服务链,Contrail从最开始的版本就开始提供了支持，主要是面向运营商接入网和移动核心网的场景设计的，当然数据中心内部的服务链也是自然可以提供支持的。Contrail使用BGP策略来引导服务链流量(draft-fm-bess-service-chaining)，实现方式有两种:1)在服务链路径上的每一跳都使用不同的SFCVRF，如果服务链上有N个节点，那么它就需要使用N-1个VRF，这种方式称为TransitVNModel。Transit VNModel中，控制器向服务链各跳中的egress VRF下发BGP路由将流量送给该跳的ingress VRF2)在服务链路径上只使用流量源所在的VRF和流量目的所在的VRN Two VN Model.Two VN Model中vRouter通过两个VRF来识别SFC流量，然后通过修改BGP下一跳来引导流量。  图4-57 中，租户Red中的VM Red_1A发向Internet间的通信需要依次经过服务节点   subsVM SL_A和VM SI_B的处理，那么在Two VNMode1方式中的转发流程为:Red_1A发出 数据包到vRouter 1上，被识别为VRFRedRed中的流量并从tapX端口送到SI_A的左臂,SL_A完成处理后从右臂送到vRouter1的tapY端口，被识别为VRF Internet:service<SC_ID>_SI_A中的流量并标记label-37送给vRouter 2.vRouter 2匹配 LFIB剥掉label并从 tapZ端口送到SL_B的左臂，SI_B完成处理后从右臂送到vRouter 2的 tapT端口，被识别为VRF Internet-Internet中的流量并标记label=90送给DC GW，之后DC GW再 swap label 送到相邻的 ABSR上。对于Red_1B来说，它发向Internet间的通信需要依次经过SLA和SI_B的处理，Red_IB发出数据包到vRouter2上，被识别为VRFRed:Red 中的流量并标记label=35送给vRouter 1，vRouter 1匹配LFIB剥掉label 并从 tapX端口送到 SI_A的左臂，后面的处理就是一样的了，此处不再赘述。实际上通过修改BGP下一跳的方式对于某些需要精细匹配的服务链场景来说是不够的，因为BGP路由只能匹配目的IP地址，因此需要Contrail需要通过XMPP来模拟 BGP FlowSpec的语义，以实现传统服务链的PBR能够支持的流量识别粒度，实际上这也就趋同于OpenFlow中的NTuple Match 和 Output Action了。对Contrail 的介绍就到这里了，其技术思想的精华可以概括为以下几点:数据平面使用 vRouter 而非vSwitch，从而为网络带来了很多特性支持;Contrail的控制器是分布式的，三类控制模块(Configuration、Control、Analytics)的功能切割与实现解耦为系统提供了完整、清晰的架构;控制平面使用了BGP和类BGP的XMPP，获得了良好的兼容性、可用性和扩展性;服务的功能最开始设计时即被提出，并在各个版本不断进行完善。Contrail的技术轮廓早在2013年就已经形成了，直至今天来看其设计理念和技术架构仍然是业界领先的，无愧于“SDN的技术担当”，希望在市场方面Contrail和OpenContrail未来能有更好的表现。

概念：  TCP传输时每一步都需要进行确认，当传输出错或丢包时，就进行重传，确保了文件传输的正确性。而对于语音、视频等多媒体信息及实时性信息，都使用UDP传输，一旦发现传输有错就简单地丢弃，但当丢弃的包达到一定数量时，传输的质量将会受到严重影响。服务质量(Qualityof Service，QoS)是指在连接点之间某些传输连接的特征，它定义了有关连接性能的一些属性，反映了传输质量及服务的可用性。QoS和CoS(Class of Service)不完全相同，CoS只是将业务区分开，没有准确定义每一个服务的级别，CoS既包含了已经标准化的特性，也包含了其他一些已有效但还没有标准化的业务。但QoS的含义明确，可用一些参数来描述，如连接建立延迟、连接建立失败、吞吐量、输送延迟、残留差错率、连接拆除延迟、连接拆除失败概率、连接回弹率、运输失败率、抖动和丢包率等。用户可以在连接建立时指明所期望的、可接受的或不可接受的QoS参数值。   QoS是网络性能的一种重要体现，它是指通过对资源的分配调度，来保证用户的特定要求。简单来说,QoS能够对数据包进行合理的排队，对含有内容标识的数据包进行优化，并对其中特定的数据包赋予较高的优先级，从而加速传输的进程，并实现实时交互，这可以解决网络带宽本身不能解决的网络拥塞问题。QoS所追求的传输质量是:数据包要到达目标地址，并且要保证数据包的顺序性、完整性和实时性，通过Qos，网络可以按照业务量的类型或缓别加以区分，并能够依次对各级别进行处理。 QoS旨在针对各种应用的不同需求，为其提供不同的服务质量，例如，提供专用带宽、减少报文丢失率、降低报文传送时延及时延科动等。OoS包含下面三种含义，①对通信子网来说,QoS表现为数据传输速率高，误码率低，   对服务提供商来说，QoS表现为用户对服务的满意程度，②对于网络传输技术，QoS表现为数据流的优先级区分，资源预留等; QoS主要是通过取某些策略，在现有资源的基础上，提高资源的利用率，从而改变服 务质量的，QoS主要的度量参数如下。 1)连接建立延迟    连接建立延迟是指在连接请求和连接确认之间允许的最大延迟(时间间隔)。     2)连接失败概率 连接失败概率是指在一次请求建立连接的过程中，失败总数与连接建立的全部尝试次数之比。连接失败主要是指因为服务提供者的原因，造成在规定的连接建立延迟时间内所请求的连接没有成功，但由于用户的原因而造成的连接失败不算在内。3)业务可用性 业务可用性是指用户到Internet业务之间连接的可靠性。4吞吐量 吞吐量是指在某段时间间隔内传输用户数据的字节数，可用最大速率和平均速率表示，5)输送延迟 输送延迟是指在发送和接收数据包之间的时间间隔。6)残留差错率 残留差错率是指在测量期间，所有错误、丢失和重复的用户数据，与用户所求的数据之比。残留差错率是传输失败总数与传输样本总数之比。7)连接拆除延迟 连接拆除延迟是指从用户发起拆除请求到成功地拆除连接之间允许的最大延迟。8)连接拆除失败概率 连接拆除失败概率是指拆除请求失败次数与拆除请求总次数之比。9)连接保护 连接保护是服务提供者为防止用户信息被非法用户监视或操作而采取的措施，保护选项有:无保护特性，被动监视的保护，针对增加、删除和改动的保护等、10)连接优先权 连接优先权是指针对用户的不同应用提供不同的连接优先级的方法。11)连接回弹率 连接回弹率是指在规定的时间间隔内，服务提供者发起的连接拆除(即没有连接拆除请求而进行的连接拆除)的概率， 通常，用户使用连接建立原语，并在用户与传输服务提供者之间协商QoS,协商过的 QoS适用于整个传输连接的生存期。但主呼叫用户请求的QoS可能被运输服务提供者降低，也可能被呼叫用户降低。根据用户要求和差错性质，网络服务按质量可分为以下三种类型:①A型网络服务，具有可接受的残留差错率和故障通知率; ②B型网络服务，具有可接受的残留差错率和不可接受的故障通知率③C型网络服务，具有不可接受的残留差错率。

  VPN 中传输的是企事业单位或公司的内部信息，因此数据的安全性非常重要。VPN保证数据的安全性主要包括三个方面:身份验证(Authentication)、数据保密性(Confidentiality)、数据完整性(Integrity)。身份验证能保证数据是从正确的发送方传输过来的:数据保密性确保数据传输时外人无法看到或截获数据；数据完整性确保数据在传输过程中没有被非法改动过，能够原样到达目的地。    VPN网络中通常还有一个或多个安全服务器，它们除了提供防火墙和地址转换功能，还通过与隧道设备的通信提供加密、身份验证和授权功能，同时也提供带宽、隧道终点、网络策略和服务等级等信息。一个有VPN能力的设备可以承担多项VPN服务，例如，企业可以把拨号访问交给 ISP去做，而自己负责用户的、访问控制、网络地址的审核、安全性和网络变化的管理等工作。   目前VPN 主要采用下面几种技术隧技术(Tunneling)、加解密技术(Encryption & Deoryption)、QoS技术、密钥管理技术(Key-management)和身份认证技术(Authentication), 1.隧道技术 拨号上网方式采用PPP协议，数据包通过专用线路传输。而在VPN中，用隧道替代了实际的专用链路。隧道技术是VPN的基本技术，类似于点对点连接技术，它在公用数据网中建立一条数据通道(隧道)，让数据包通过这条隧道传输。 2.加密技术 数据加密通过变换信息的表示形式来伪装需要保护的数据，使非授权者不能看到被保护信息的内容。加密算法有用于Windows 95的RC4、用于IPSec 的 DES 和三次 DES.RC4 强度比较弱,而DES和三次DES强度比较高，可用于敏感的商业信息。 加密技术能用在协议的任意层，可以对数据或报文头进行加密。在网络层中的加密标准是IPSec，网络层加密最安全的方法是在主机的端到端间进行加密。另一个加密技术是隧道模式，加密只在路由器中进行，而终端与第一跳路由之间不加密。这种方法不太安全，因为数据从终端系统到第一条路由时可能被截取，在数据链路层中，目前还没有统一的加密标准，所有链路层加密方案基本上都是生产厂家自己设计的，需要特别的加密硬件。 3.QoS 技术 通过隧道技术和加密技术，已经建立了一个具有安全性、互操作性的VPN.但是VPN性能不稳定，管理上可能不能满足企业的要求，这就需要加入QoS技术，才能建立一条符合 用户要求的隧道QoS技术能对网络资源分配进行控制，以满足应用的需求。Qos有通信处理机制、供应和设置机制。 

直播间问答1. 第一个问题是命令行模板有哪些能力呢？    ——命令行模板是基于设备命令行格式做了增强，各厂商设备的命令行格式都支持，主要增强四个能力：变量定义、变量约束、if控制语句、for控制语句。2.巡检项定义完成后怎么知道是不是正确的？如果不正确，能知道哪个地方不正确吗？   ——针对巡检项的验证场景，我们提供测试功能，帮助用户验证、调测问题。巡检项定义完成后，用户可以点击测试功能，选择一个在线的设备验证。测试结束后结果信息很丰富，会把关键数据渲染成不同颜色，例如匹配有差异的显示为红色，匹配正确的显示为绿色，帮助用户快速确认和找到问题。3.巡检项能校验两个变量之间的关系吗？    ——能验证。网络巡检功能是在AOC框架上构建的，也具备了开放可编程的能力，两个变量或者更多变量之间的关系都可以校验。简单来说分为两步，第一步用户需要在AOC中导入一个新的SSP包，SSP包由用户开发，在SSP中提供一个校验函数。 第二步定义巡检项，在变量约束中选择函数类型，系统会关联查询出校验函数名称，通过下拉框选择需要的函数即可。巡检时系统会调用SSP中的函数，把匹配到的变量传入到函数中，根据函数返回值检查是否正确。4.网络巡检任务在执行时命令行时会对设备有影响吗？   ——这个对设备没有影响，首先巡检功能下方的命令行会拦截写操作，只能下发读操作，所以是不会修改设备上的任何配置。其次，考虑到频繁的读操作会对设备CPU有一定的压力，我们做了双重保障，第一是短时间之内不允许多次执行重复命令，另一方面相同的命令会在系统缓存一段时间，减少设备的访问次数，所以对设备是没有影响的。5.试用一下网络巡检，到哪里可以体验？   ——网络巡检体验环境预计10月上线数通网络开放可编程社区中，请大家关注社区获取最新动态。精彩问题1. 网络巡检对ipv6的业务配置或者连通性测试支持吗？    ——如果知道ipv6业务在设备上预期的配置就可以检查。当前网络巡检的主要作用是检视设备的资源状态或网络配置，不支持连通性测试。2. 巡检出问题后，有无响应的整改建议呢？   ——整改建议需要在新建巡检项的时候手工录入，如果没有录入则无整改建议。3.这个怎么收费？   ——需要购买数字地图基础包License，巡检项可以由客户自定义，如需定制按照专业服务收费。 直播回顾回放地址：https://devzone.huawei.com/cn/enterprise/aoc/videos/index.html?id=166&number=1&from=allVideos3