本地与云服务器互联互通，如何解决？本地与A区云服务通过专线互联，A区云服务器与B区服务器通过云专线互联。B区服务器需要与本地互联（最好直接互联互通，有1000个端口要互通），求问各位专家应该如何操作？

 前言 本文是对UDP协议的知识总结  UDP协议 UDP协议格式如下：  16位源端口号：标识发送数据报的应用程序所在的端口。 16位目的端口号：标识接收数据报的应用程序所在的端口。 16位UDP长度：表示整个UDP数据报的长度，包括UDP头部和数据部分。 16位UDP检验和：表示整个UDP数据报的长度，包括UDP头部和数据部分。 这里我们有几个问题？  报头和有效载荷分离的问题 UDP协议使用固定报头长度(8字节)的方式，来分离报头和有效载荷。  有效载荷向上交付的问题，也就是交给哪个进程？ UDP报头字段中16位目的端口号就是标识接受数据报的进程。  怎么确定把报文收全了？ UDP协议，对于小于8字节的报文会直接丢弃，毕竟光是UDP报头大小就是8字节；对于大于8字节的报文，会用 16位UDP长度 - 报头大小 = 数据长度 和 16位UDP检验和 的方式来确定报文是否收全。  UDP报头是如何封装的呢？ 报头是一个结构化字段，也就是结构体。  如果我们一次接受大量的UDP报文，那操作系统要不要对这些报文进行管理？要进行管理。如何管理？先描述，在组织。内核中，为了管理报文，定义了sk_buff结构体。  知道了上面两个结构体，我们就可以以使用 udp 发送 hello 给127.0.0.1:8888为列子，来了解UDP报头是如何封装的。  定义一个 sk_buff 和 一个缓冲区。刚开始 data 和 tail指向同一个地址。  data指针向前移动5个字节(hello 的长度)，也就是开辟了5个字节的空间，然后，将 hello 从用户层拷贝到内核层。  定义一个 struct udphdr 结构体，在将16位原端口号，16位目的端口号，16位UDP长度，16位UDP检验和信息填充。然后，data再前移8个字节，再见报头字段拷贝到缓冲区。  到这里，对报文进行UDP封装就完成了。 以下是 linux-2.6.11.10下的udphdr结构体 和 sk_buff结构体   UDP特点 无连接：知道对端的IP和端口号就直接进行传输，不需要建立链接 不可靠：没有确认应答机制，没有重传机制，如果因为网络故障导致报文无法发到对方，UDP协议也不会给应用层返回任何错误信息 面向数据报：不能够灵活的控制读写数据的次数和数量(应用层交给UDP多长的有效载荷，UDP会加上报头直接发送，不会拆分，也不会合并) UDP的缓冲区 UDP没有真正意义上的发送缓冲区，调用sendto会直接交给内核，由内核将数据传给网络层协议进行后续传输动作 UDP具有接收缓冲区，但是这个接收缓冲区不能保证收到的UDP报文的顺序和发送UDP报文顺序的一致；如果缓冲区满了，再到达的接收端主机的UDP报文就会被丢弃 基于UDP的应用层协议 NFS：网络文件系统 TFTP：简单文件传输协议 DHCP：动态主机配置协议 BOOTP：启动协议 DNS：域名解析协议 总结 以上就是我对于UDP协议的知识总结 ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/li209779/article/details/142261253 

 1. 概述 日常浏览互联网时，是否遇到过访问某些网站（如GitHub）非常缓慢？是否遇到过某些网站（如OpenAPI）停止服务？这些问题有时就可以通过使用代理IP来解决。那么，什么是代理IP呢？这篇文章将以通俗易懂的语言，解释关于代理IP的一切，包含概念、作用、代理IP池，以及如何使用它们。  1.1 什么是代理IP？ 简单来说，代理IP就是一种中介，帮我们访问互联网资源，而不是直接通过我们自己的IP地址去访问。当我们通过浏览器访问一个网站时，网络请求会包含我们的IP地址，这就是我们在网络上的“身份标识”。然而，有时我们可能不想暴露自己的IP地址，或者访问某些因为地区差异而导致无法直接访问的网络公开信息，此时，代理IP就派上用场了。 举个简单的例子，就懂了：当我们购买二手房，一般都是通过某家房产中介去带头我们查找房源并和原房东取得联系，并不是我们自己查找房源，这里房产中介的作用跟我们访问网络时使用到的代理IP是一样的。  1.2 代理IP的工作原理 我们可以把代理IP想象成一个“中间人”：  向代理服务器发送网络请求。 代理服务器接收到请求后，转而向目标网站发送请求。 目标网站把响应发送给代理服务器。 最后，代理服务器把响应内容传回给我们。 这样，目标网站看到的是代理服务器的IP地址，而不是我们的真实IP地址了，从而大大增强了爬虫操作的匿名性。代理IP是爬虫技术中的重要工具，它可以帮助我们合理地控制请求频率、提高请求效率、减少被目标网站识别和拦截的风险等，是构建高效爬虫系统的重要组成部分。 1.3 爬虫的应用场景 1.3.1 搜索引擎，最大的爬虫 爬虫的最典型应用就是搜索引擎。像我们平时常用的百度、必应、Google等搜索引擎，本质上就是一个超大规模的爬虫系统。这些庞大的爬虫系统全天候24小时会自动访问全球互联网网络，抓取内容，然后交由搜索引擎的索引系统留存处理。等到我们在Google或百度查询某关键词时，就能够从索引系统中找到相关的网站数据并进行展示了。  1.3.2 数据采集，市场分析利器 爬虫在数据采集和分析领域有着广泛的应用。企业可以利用爬虫技术从互联网上收集各种数据，如市场行情、竞争对手的动向、产品信息等，用于商业数据分析、市场调研等。同时，爬虫还可以用于科学研究、舆情分析等领域，为数据分析提供更多的信息来源。  1.3.3 舆情监控，品牌营销手段 舆情监控是企业常用的一种市场调研手段，通过对社交媒体、新闻网站等信息源进行监控和分析，了解公众对企业、产品或服务的舆论趋势。爬虫可以帮助企业及时获取各种网络信息，并进行分析和汇总，快速了解公众对企业的看法，及时处理负面舆情，制定合适的品牌营销策略。  1.3.4 价格监测，全网比价神器 在电商行业，价格是消费者购买产品时非常重要的考量因素。企业可以利用爬虫技术监测竞争对手的价格变化，也可以根据市场行情进行实时调整，以更好地制定价格和促销策略。而消费者也可以利用爬虫技术来监测商品价格的变动，以获取最优惠的购买时机。  2. 代理IP池 2.1 什么是代理IP池？ 在上一章中，我们介绍了爬虫的一些常见应用场景，他们有2个共同的特点： 一是数据量巨大，二是需要频繁请求。 从安全性和稳定性等角度来说，一个运营成熟的站点，一般都具有验证机制，比如会限制短时间内来自同一ip地址/ip端的大量请求，严重的时候会直接拒绝来源ip的访问甚至上升到法律层面。   举个很实际的例子：据传，阿里内部网络已经被山姆识别并标记，使用阿里内部网络将无法访问山姆APP。这本质上就是企业的防护手段之一。  综上所述，使用单一的代理IP已经很难满足真实的爬虫需求，特别是在进行频繁的公开网页爬虫或大量数据抓取时，需要大量代理IP来帮助提高爬虫的效率。此时，代理IP池就显得尤为重要。代理IP池一般包含多个代理IP地址，可以按需从中取出使用，即可达到以下几个效果：  负载均衡：分散网络请求，防止单个IP被识别标记而无法进行爬虫任务。 提高稳定性：当某个代理IP不可用时，可以迅速轮换到其他可用的IP。 匿踪效果：通过代理服务器发起来自当地真实的请求，使得数据抓取时不易被检测到真实IP，从而达到匿名保护的效果。 提高效率：通过快速轮换IP地址，短时间内使用多个来源地IP实现大量公开数据抓取。 2.2 手动建立代理IP池 可以手动收集并维护一批代理IP，将它们存储在数组或数据库中，根据需要进行使用。 一个简单的示例代码（Python）：  import requests import random  # 创建一个代理IP池 proxy_pool = [     'http://123.123.123.123:8080',     'http://124.124.124.124:8080',     'http://125.125.125.125:8080' ]  # 随机选择一个代理IP使用 proxy = random.choice(proxy_pool) proxies = {     'http': proxy,     'https': proxy }  url = 'http://www.baidu.com'  response = requests.get(url, proxies=proxies) print(response.content) 2.3 使用商用代理IP池 除了自建代理IP池之外，也可以选择跟代理IP池服务商合作，直接使用它们提供的大量代理IP。这些服务有付费和免费的，付费服务通常更加可靠和稳定，根据我实际测试，IPIDEA的代理ip池质量非常好，代理IP很纯净、运行稳定、不限并发、负载也很均衡，非常适合用于爬虫商业化应用开发。而且他们提供最高17.5G的免费测试，用来测试他们代理是否满足你的项目需求，足够了。  3. 获取代理IP并用于实战抓取 3.1 提取IP 完成IPIDEA的账号注册和实名认证之后（根据国家网络安全与个人信息保护的相关法律要求，需进行实名认证），免费测试额度就到账了。  如下图所示（看原文），到API提取页面提取IP。我先测试提取10组代理，格式直接使用txt。点击生成链接，就可以在右侧看到提取代理ip的地址了。 是我通过生成的链接提取到的10组代理ip地址： 3.2 案例实战：代理IP模式抓取亚马逊美国网站商品信息 我们将通过下面这段代码，使用前面获取到的代理IP列表，来抓取亚马逊美国站点关于MacBook的搜索商品信息，作为大数据分析的数据来源。  import requests import time import random from bs4 import BeautifulSoup import pandas as pd  # 代理IP字典 proxies = {     "https": "http://45.43.62.24:19217",     "https": "http://43.159.28.48:19335",     "https": "http://45.43.62.24:19219",     "https": "http://43.159.26.218:19038",     "https": "http://43.159.26.218:19040",     "https": "http://45.43.62.24:19216",     "https": "http://43.159.28.48:19336",     "https": "http://45.43.62.24:19218",     "https": "http://43.159.28.48:19337",     "https": "http://43.159.26.218:19039" }  # 请求头 headers = {     "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36",     "Accept-Encoding": "gzip, deflate",     "Accept-Charset": "utf-8" }  def fetch_page_content(url):     response = requests.get(url, headers=headers, proxies=proxies, timeout=10)     return BeautifulSoup(response.text, "html.parser")  def extract_product_details(soup):     product_list = []     for item in soup.select(".s-result-item"):         try:             product_name = item.select_one(".s-line-clamp-2").get_text(strip=True)             product_price = float(item.select_one(".a-price .a-offscreen").get_text(strip=True).replace(",", "").replace("$", ""))             product_list.append({"name": product_name, "price": product_price})         except Exception as e:             continue     return product_list  def scrape_amazon(keyword):     search_url = f"https://www.amazon.com/s?k={keyword}"     soup = fetch_page_content(search_url)     all_products = extract_product_details(soup)     next_page_link = soup.select_one(".s-pagination-container .s-pagination-next a")          while next_page_link:         next_url = f"https://www.amazon.com{next_page_link.get('href')}"         soup = fetch_page_content(next_url)         all_products.extend(extract_product_details(soup))         next_page_link = soup.select_one(".s-pagination-container .s-pagination-next a")              return all_products  if __name__ == "__main__":     search_keyword = "MacBook"     product_data = scrape_amazon(search_keyword)     product_dataframe = pd.DataFrame(product_data)     product_dataframe.to_csv(f"{search_keyword}.csv", index=False) 结果如下图所示，我们就可以根据这些商品信息来进行分析，从而为我们自己的商品营销策略提供数据支撑。[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QKWw44Gh-1722519946214)(https://i-blog.csdnimg.cn/direct/68adc667e8be45b680be304f69b8dfb9.png)]  4. 总结 合理使用代理IP不仅可以帮助我们保护隐私，还可以高效完成大量且复杂的爬虫任务。而IPIDEA代理IP池则进一步解决了单一代理IP的局限性，提供了更加稳定和高效的解决方案。无论是日常浏览还是复杂的数据抓取任务，理解并灵活运用代理IP能为我们带来巨大的帮助。但我们在执行爬虫任务时，也要需要遵守法规，遵守网站的使用政策，避免对网站造成不必要的压力或侵犯隐私等问题。 ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/g310773517/article/details/140689163 

 1.数据链路层 数据链路层是网络协议栈中最底层的内容，而在之前对其他层次的学习让我们知道传输层可以保证数据的可靠性问题，网络层保证数据跨网络转发的路由问题，而数据链路层解决的就是局域网内两台主机间通信的问题。   2.以太网 2.1什么是以太网 以太网属于一种局域网通信技术。  不同局域网所采用的通信技术可能是不同的，常见的局域网技术有以下三种：  以太网：以太网是一种计算机局域网技术，一种应用最普遍的局域网技术。 令牌环网：令牌环网常用于IBM系统中，在这种网络中有一种专门的帧称为“令牌”，在环路上持续地传输来确定一个节点何时可以发送包。 无线LAN/WAN：无线局域网是有线网络的补充和扩展，现在已经是计算机网络的一个重要组织部分。 虽然网络中各个局域网所采用的通信技术可能的不同的，但是IP屏蔽了底层网络的差异，对于网络通信双方的IP层及其往上的协议来说，它们并不关心底层具体使用的是哪种局域网技术。  网络中的路由器会不断去掉数据旧的局域网报头，并添加上新的局域网报头，因此数据在进行跨网络传输时，就算所需跨越的网络采用的是不同的局域网技术，最终也能够正确实现跨越。  （1）以太网通信原理  以太网”不是一种具体的网络，而是一种技术标准，它既包含了数据链路层的内容，也包含了一些物理层的内容。例如，以太网规定了网络拓扑结构，访问控制方式，传输速率等。 以太网中的网线必须使用双绞线，传输速率有10M，100M，1000M等。 以太网中所有的主机共享一个通信信道，当局域网中的一台主机发出数据后，该局域网中的所有主机都能够收到该数据。  比如当局域网中的主机A想要发送数据给主机B时，其实局域网当中的每一台主机都能收到主机A发出去的数据，只不过最终只有主机B会将主机A发来的数据向上进行交付。 局域网当中的其他主机虽然也收到了主机A发出的数据，但经过识别后发现这个数据不是发送给自己的，于是就会直接将该数据丢弃而不会向上进行交付。 （2）数据碰撞  由于以太网中的所有的主机共享一个通信信道，因此在同一时刻只允许有一台主机发送数据，否则各个主机发送的数据就会相互干扰。站在系统的角度来看，这里各个主机所共享的通信信道就是一种临界资源，这个临界资源同一时刻只允许一台主机使用。  对于这个问题，以太网的做法就是先不限制各个主机发送数据的能力，局域网中的每个主机想发数据的时候直接发就行了，但是只要发送出去的数据与其他主机发送的数据产生了碰撞，那就得执行碰撞避免算法。 所谓的碰撞避免算法就是，当主机发送出去的数据产生碰撞时，该主机需要等待一段时间后再进行数据重发，在主机等待的时候就能够就能够尽可能让局域网当中的数据消散。 一个局域网就是一个碰撞域。 （3）交换机  交换机通过维护一个MAC地址表来记录每个端口连接的设备的MAC地址。当数据帧到达交换机时，它会根据目的MAC地址查找MAC地址表，以确定将数据帧转发到哪个端口。这种机制减少了数据帧被错误地发送到多个端口的可能性，从而降低了碰撞的概率。  交换机支持VLAN技术，可以将网络划分为多个逻辑上独立的广播域。每个VLAN内的设备只能与同一VLAN内的其他设备通信，从而减少了广播流量和碰撞的可能性。  （4）令牌环网  令牌环网（Token-ring network）的传输方法在物理上采用了星形拓扑结构，但逻辑上是环形拓扑结构。 令牌环网的通信传输介质可以是无屏蔽双绞线、屏蔽双绞线和光纤等。 令牌环网中各节点间采用多站访问部件（Multistation Access Unit，MAU）连接在一起，MAU是一种专业化集线器，用来围绕工作站计算机的环路进行传输。 在令牌环网中有一种专门的帧称为“令牌”，这个“令牌”会在环路上持续地传输，只有拿到“令牌”的主机才能发送数据，因此发送出去的数据不会发生碰撞。  令牌环网当中的“令牌”就像系统当中用于保护临界资源的互斥锁一样，“令牌”与互斥锁一样也有“忙”和“闲”两种状态，“忙”表示令牌已经被占用，而“闲”则表示令牌没有被占用。 想要发送数据的计算机必须首先检测到“闲”令牌，并将其置为“忙”状态，然后才可以发送数据，这就和申请互斥锁的过程很像。 此外，由于“令牌”在网环上是按顺序依次传递的，因此对于所有入网的计算机而言，它们获取令牌的机会都是相等的，因此不会造成某台主机发送数据的饥饿问题。 2.2MAC帧格式 MAC帧是数据链路层的一种数据数据格式，用于在局域网（以太网）传递数据。   源地址和目的地址是指网卡的硬件地址（也叫MAC地址），长度是48位，是在网卡出厂时固化的。 帧协议类型字段有三种值，分别对应IP协议（0800）、ARP协议（0806）和RARP协议（8035）。 帧末尾是CRC校验码。 （1）MAC帧如何将报头与有效载荷进行分离？  以太网MAC帧的帧头和帧尾都是固定长度的，因此当底层收到一个MAC帧后，直接提取出MAC帧当中固定长度的帧头和帧尾，此时剩下的就是有效载荷了。  （2）MAC帧如何决定将有效载荷交付给上层的哪一个协议？  以太网MAC帧对应的上层协议不止一种，因此在将MAC帧的报头和有效载荷分离后，还需要确定应该将分离出来的有效载荷交付给上层的哪一个协议。  在MAC帧的帧头当中有2个字节的类型字段，因此在分离出报头和有效载荷后，根据该字段将有效载荷交付给对应的上层协议即可。  （3）数据传输过程  假设局域网当中的主机A想要将IP数据报发送给同一局域网当中的主机B，那么主机A封装MAC帧当中的目的地址就是主机B的MAC地址，源地址就是主机A的MAC地址，而帧协议的类型对应就是0800，紧接着就是要发送的IP数据报，帧尾部分对应就是CRC校验。  当主机A将该MAC帧发送到局域网当中后，局域网当中的所有主机都可以收到这个MAC帧，包括主机A自己。  主机A收到该MAC帧后，可以对收到的MAC帧进行CRC校验，如果校验失败则说明数据发送过程中产生了碰撞，此时主机A就会执行碰撞避免算法，后续进行MAC帧重发。 主机B收到该MAC帧后，提取出MAC帧当中的目的地址，发现该目的地址与自己的MAC地址相同，于是在CRC校验成功后就会将有效载荷交付给上层IP层（0800）进行进一步处理。 局域网中的其他主机收到该MAC帧后，也会提取出MAC帧当中的目的地址，但发现该目的地址与自己的MAC地址不匹配，于是就会直接将这个MAC帧丢弃掉。 也就是说，当底层收到一个MAC帧后，会根据MAC帧当中的目的地址来判断该MAC帧是否是发给自己的，如果是发送给自己的则会再对其进行CRC校验，如果校验成功则会根据该MAC帧的帧协议类型，将该MAC交付给对应的上层协议进行处理，如果不是发送给自己的则在数据链路层直接将数据丢弃。  （4）认识MAC地址  MAC地址用来识别数据链路层中相连的节点。 长度为48位，及6个字节，一般用16进制数字加上冒号的形式来表示，例如：08:00:27:03:fb:19。 在网卡出厂时就确定了，不能修改，MAC地址通常是唯一的（虚拟机中的MAC地址不是真实的MAC地址，可能会冲突；也有些网卡支持用户配置MAC地址）。 我们可以通过ifconfig命令来查看我们的MAC地址。   ether：以太。  （5）对比理解MAC地址和IP地址  实际数据在路由过程中会存在两套地址，一套是源IP地址和目的IP地址，还有一套是源MAC地址和目的MAC地址。  IP地址描述的是数据通信总体的起点和终点。 MAC地址描述的是数据通信上的每一个区间的起点和终点。 比如唐僧取经，源IP地址就是东土大唐，目的IP地址就是西天，而源MAC地址就是取经路途上一个区间内的起点，目的MAC地址就是取经路途上一个区间内的终点。  因此数据在路由过程中，源IP地址和目的IP地址可以理解成是不会变化的（但实际上由于NAT技术，源IP地址也是会发生变化的），而数据每进行一跳后其源MAC地址和目的MAC地址都会变化。  （6）认识MTU  MTU（Maximum Transmission Unit，最大传输单元）描述的是底层数据帧一次最多可以发送的数据量，这个限制是不同的数据链路层对应的物理层产生的。  以太网对应MTU的值一般是1500字节，不同的网络类型有不同的MTU，如果一次要发送的数据超过了MTU，则需要在IP层对数据进行分片（fragmentation）。 此外，以太网规定MAC帧中数据的最小长度为46字节，如果发送数据量小于46字节，则需要在数据后面补填充位，比如ARP数据包的长度就是不够46字节的。 （7）认识MSS  由于数据链路层限制了单次数据传输的数据量（MTU），所以为了避免数据在网络层进行IP分片，我们应在传输层对向网络层交付的数据大小加以控制。  我们将TCP的单个数据报的最大报文长度，称为MSS（Max Segment Size）。  TCP通信双方在建立连接的过程中，就会进行MSS协商，最终选取双方支持的MSS值当中的较小值作为最终MSS。  MSS的值实际就是在TCP首部的40字节的选项字段当中的（kind=2）。  最理想的情况下，MSS的值正好就是在数据不会在IP层进行分片的最大长度。  MSS和MTU的关系如下：   3.ARP协议 地址解析协议（Address Resolution Protocol，ARP）协议，是根据IP地址获取MAC地址的一个TCP/IP协议。  3.1为什么有ARP协议？ ARP 协议建立了主机 IP 地址 和 MAC 地址 的映射关系。  在网络通讯时，源主机的应用程序知道目的主机的 IP 地址和端口号，却不知道目的主机的硬件地址（MAC地址）； 数据包首先是被网卡接收到再去处理上层协议的，如果接收到的数据包的硬件地址与本机不符，则直接丢弃； 因此在通讯前必须获得目的主机的硬件地址。 3.2ARP的定位 在TCP/IP四层模型中，网络协议栈自顶向下分为应用层、传输层、网络层和数据链路层。  其中应用层最典型的协议有HTTP、HTTPS和DNS等，传输层最典型的协议有TCP和UDP，网络层最典型的协议就是IP，数据链路层最典型的协议就是MAC帧协议，但实际数据链路层还有两种协议叫做ARP和RARP。   ARP、RARP和MAC帧协议虽然都属于数据链路层的协议，但ARP协议和RARP协议属于MAC帧的上层协议。  也就是说，MAC帧的上层协议不一定就直接是网络层的协议，MAC帧的上层协议有可能也属于数据链路层的协议，但就是位于MAC帧的上层。  网络层当中的ICMP协议和IGMP协议，这两个协议虽然与IP协议都属于网络层，但这两个协议属于IP的上层协议。  3.3ARP协议工作流程  源主机发出 “ARP请求”，询问“IP 地址是 172.20.1.2 的主机的硬件地址是多少”，并将这个请求广播到本地网段（以太网帧首部的硬件地址填 FF:FF:FF:FF:FF:FF 表示广播）。 目的主机接收到广播的 ARP请求，发现其中的 IP 地址与本机相符，则发送一个 “ARP应答” 数据包 给源主机，将自己的硬件地址填写在应答包中； 每台主机都维护一个 ARP 缓存表，可以用arp -a命令查看。 缓存表中的表项有过期时间（一般为 20 分钟），如果 20 分钟内没有再次使用某个表项，则该表项失效，下次还要发 ARP 请求来获得目的主机的硬件地址。  3.4ARP数据格式  硬件类型指链路层的网络类型，1为以太网。 协议类型指要将什么类型的地址转换为MAC地址，0800为IP地址。 硬件地址长度对于以太网地址为6字节，因为MAC地址是48位的，该字段如果硬件类型为以太网，则填6。 协议地址长度对于IP地址为4字节，因为IP地址是32位的，该字段如果协议类型为IP，则填4。 op字段为1表示ARP请求，op字段为2表示ARP应答。 从ARP的数据格式也可以看出，ARP是MAC帧协议的上层协议，ARP数据格式中的前3个字段和最后一个字段对应的就是以太网首部，但由于ARP数据包的长度不足46字节，因此ARP数据包在封装成为MAC帧时还需要补上18字节的填充字段。  所以根据MAC帧中的类型字段，可以决定将该MAC帧交付给上层的哪一个协议：IP协议、ARP协议还是RARP协议。  4.RARP协议 RARP（Reverse Address Resolution Protocol，反向地址转换协议），是根据MAC地址获取IP地址的一个TCP/IP协议。  也就是说，某些情况下我们可能只知道一台主机的MAC地址，此时要得知该主机的IP地址就可以使用RARP协议。  理论上来说，RARP协议一定比ARP协议简单，因为既然我们已经知道一台主机的MAC地址了，那么我们就已经可以直接向给主机发送消息了，因此我们可以直接发消息询问对方的IP地址就行了。  不了解自我，我们的内心便没有办法得到完全的满足。 —斯瓦米·拉玛 ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/2301_77112634/article/details/141597539 

 Gazelle是一款高性能用户态协议栈。它基于DPDK（Data Plane Development Kit，数据平面开发工具集）在用户态直接读写网卡报文，共享大页内存传递报文，使用轻量级LwIP协议栈。能够大幅提高应用的网络I/O吞吐能力。专注于数据库网络性能加速，如MySQL、redis等。 高性能 报文零拷贝，无锁，灵活scale-out，自适应调度。 通用性 完全兼容POSIX，零修改，适用不同类型的应用。 单进程且网卡支持多队列时，只需使用liblstack.so，以缩短报文路径。其余场景使用ltran进程分发报文到各个线程。 安装 配置openEuler的yum源，直接使用yum命令安装。 yum install dpdkyum install libconfigyum install numactlyum install libboundscheckyum install libpcapyum install gazelle 使用方法 配置运行环境，使用Gazelle加速应用程序步骤如下：  使用root权限安装ko 根据实际情况选择使用ko，提供虚拟网口、绑定网卡到用户态功能。 若使用虚拟网口功能，则使用rte_kni.ko。 modprobe rte_kni carrier=“on” 配置NetworkManager不托管kni网卡。 [root@localhost ~]# cat /etc/NetworkManager/conf.d/99-unmanaged-devices.conf[keyfile]unmanaged-devices=interface-name:kni[root@localhost ~]# systemctl reload NetworkManager 网卡从内核驱动绑为用户态驱动的ko，根据实际情况选择一种。 #若IOMMU能使用modprobe vfio-pci#若IOMMU不能使用，且VFIO支持noiommumodprobe vfio enable_unsafe_noiommu_mode=1modprobe vfio-pci#其他情况modprobe igb_uio 说明: 可根据机器BIOS配置，查看是否启用IOMMU。 dpdk绑定网卡 将网卡绑定到步骤1选择的驱动。为用户态网卡驱动提供网卡资源访问接口。 #使用vfio-pcidpdk-devbind -b vfio-pci enp3s0#使用igb_uiodpdk-devbind -b igb_uio enp3s0 大页内存配置 Gazelle使用大页内存提高效率。使用root权限配置系统预留大页内存，可选用任意页大小。因每页内存都需要一个fd，使用内存较大时，建议使用1G的大页，避免占用过多fd。 根据实际情况，选择一种页大小，配置足够的大页内存即可。配置大页操作如下： #配置2M大页内存：在node0上配置 2M * 1024 = 2Gecho 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages#配置1G大页内存：在node0上配置1G * 5 = 5Gecho 5 > /sys/devices/system/node/node0/hugepages/hugepages-1048576kB/nr_hugepages 说明： cat查询实际预留页个数，连续内存不足时可能比预期少。 挂载大页内存 创建两个目录，分别给lstack进程、ltran进程访问大页内存使用。操作步骤如下： mkdir -p /mnt/hugepages-ltranmkdir -p /mnt/hugepages-lstackchmod -R 700 /mnt/hugepages-ltranchmod -R 700 /mnt/hugepages-lstackmount -t hugetlbfs nodev /mnt/hugepages-ltran -o pagesize=2Mmount -t hugetlbfs nodev /mnt/hugepages-lstack -o pagesize=2M 说明： /mnt/hugepages-ltran和/mnt/hugepages-lstack必须挂载同样pagesize的大页。 应用程序使用Gazelle 有两种使用Gazelle方法，根据需要选择其一。 重新编译应用程序，替换sockets接口 #makefile中添加Gazelle的Makefile-include /etc/gazelle/lstack.Makefile#编译添加LSTACK_LIBS变量gcc test.c -o test ${LSTACK_LIBS} 使用LD_PRELOAD加载Gazelle库 GAZELLE_BIND_PROCNAME环境变量指定进程名，LD_PRELOAD指定Gazelle库路径。 GAZELLE_BIND_PROCNAME=test LD_PRELOAD=/usr/lib64/liblstack.so ./test 配置文件 lstack.conf用于指定lstack的启动参数，默认路径为/etc/gazelle/lstack.conf，配置文件参数如下： 选项 参数格式 说明 dpdk_args --socket-mem（必需） –huge-dir（必需） –proc-type（必需） –legacy-mem –map-perfect -d dpdk初始化参数，参考dpdk说明 –map-perfect为扩展特性，用于防止dpdk占用多余的地址空间，保证ltran有额外的地址空间分配给lstack。 -d参数加载指定so库文件。 listen_shadow 0/1 是否使用影子fd监听。单listen线程，多协议栈线程时使能。 use_ltran 0/1 是否使用ltran 。 num_cpus “0,2,4 …” lstack线程绑定的cpu编号，编号的数量为lstack线程个数(小于等于网卡多队列数量)。可按NUMA选择cpu。 low_power_mode 0/1 是否开启低功耗模式，暂不支持。 kni_switch 0/1 rte_kni开关，默认为0。只有不使用ltran时才能开启。 unix_prefix “string” gazelle进程间通信使用的unix socket文件前缀字符串，默认为空，和需要通信的ltran.conf的unix_prefix或gazellectl的-u参数配置一致。不能含有特殊字符，最大长度为128。 host_addr “192.168.xx.xx” 协议栈的IP地址，也是应用程序的IP地址。 mask_addr “255.255.xx.xx” 掩码地址。 gateway_addr “192.168.xx.1” 网关地址。 devices “aa:bb:cc:dd:ee:ff” 网卡通信的mac地址，需要与ltran.conf的bond_macs配置一致。 app_bind_numa 0/1 应用的epoll和poll线程是否绑定到协议栈所在的numa，默认值是1，即绑定。 send_connect_number 4 设置为正整数，表示每次协议栈循环中发包处理的连接个数。 read_connect_number 4 设置为正整数，表示每次协议栈循环中收包处理的连接个数。 rpc_number 4 设置为正整数，表示每次协议栈循环中rpc消息处理的个数。 nic_read_num 128 设置为正整数，表示每次协议栈循环中从网卡读取的数据包的个数。 mbuf_pool_size 1024000 设置为小于5120000的正整数，表示初始化时申请的mbuf地址池大小，需要根据网卡硬件支持进行合理配置，配置过小会启动失败。 

 调优思路 本章主要是围绕优化网卡性能和利用网卡的能力分担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。