bridge

STP的操作 1.每个广播域选择一个根桥（Root） Root bridge Bridge ID（桥ID）8个 字节 桥优先级（2字节） 桥Mac地址（6字节） 桥优先级越小 Mac地址越小 2.每个非根桥上选择一个根端口（Root port） 根端口：具有最低根路径的接口 考虑因素： 最低的跟桥ID 最低的根路径代价 最低发送者路径代价 最低端口ID Sep路径开销 根端口：到达根桥开销（sost）最小的接口，通过cost值计算。 RP不断收budp包 3.每个段选择一个指定端口 （Designated port） 指定端口：具有最低路径的接口 考虑因素： 最低的根桥ID 最低的根路径代价 最低发送者桥ID 最低端口ID Dp不断发budp包 4.阻塞一个非指定端口 Stp 端口状态 Blocking：阻塞状态 不转发frame ，接收budp Listening ：侦听状态，不转发frame，侦听frame Blocking：禁止状态，不接受budpl Learning：学习状态，学习Mac Frowarding：转发frame ，学习Mac地址 来源： oschina 链接： https://my.oschina.net/u/4328202/blog/3476655

本文通过docker的网络介绍容器网络的原理以及一些实践，通过实践一遍相信大家会对网络底层的原理有个更深的理解，最后给出对接ovs的教程，这对下一篇k8s对接ovn的原理理解打下一个基础。 网络概述 端口映射： $ docker run -p 8080:80 nginx:latest 如果没有这个-p，会发现启动了nginx但是无法通过宿主机访问到web服务，而使用了-p参数后就可以通过访问主机的8080断开去访问nginx了。 端口映射的原理是作了net转发 共享主机网络: $ docker run --net=host nginx:latest 这种容器没有自己的网络，完全共享主机的网络，所以可以通过主机ip直接访问容器服务。 坏处是容器与其它容器端口冲突 link网络 $ docker run --name mysql mysql:latest $ docker run --link=mysql nginx:latest 这样nginx可以通过容器名去访问mysql，其原理是在nginx容器中的/etc/hosts中加入了mysql主机名解析。这种共享不可跨主机 $ docker run --rm -it --name c1 centos:latest /bin/bash $ docker run --rm -it --name c2 --link c1 centos:

一，准备环境 物理机 虚拟机 操作系统 CentOS 6.8 x64 CentOS 6.8 x64 CPU/ 内存 10 核超线程 x2/64G 2 核 /4G 外网 IP -- 内网 IP eth1_192.168.0.85 eth0_192.168.0.91-100 硬盘 1T 100G 二，安装服务 1、 检查当前物理机是否支持虚拟化技术： # egrep 'vmx|svm' /proc/cpuinfo 如果输出的结果包含 VMX ，它是 Intel 处理器虚拟机技术标志：如果包含 SVM ，它是 AMD 处理器虚拟机技术的标志，如果你什么都没有得到，那应你的系统并没有支持虚拟化的处理，不能使用 KVM ，另处 linux 发行版本必须在 64bit 环境中才能使用 KVM 。 2、 准备相应程序包： # yum install kvm python-virtinst libvirt bridge-utils virt-manager qemu-kvm-tools virt-viewer virt-v2v tunctl tigervnc-server 3、 关闭 selinux ： # vi /etc/selinux/config SELINUX=disabled 此处更改后需重新服务器。 4、 查看 libvirtd 虚拟化进程是否启动： # /etc/init.d

上周，Filecoin Liftoff Week举行了许多讲座，演示，研讨会和更多内容。我们知道发生了很多事情，因此我们想花一点时间来总结本周的重点，最重要的公告以及可以在其中找到更多信息的地方。 公告 🤝Filecoin与ConsenSys合作 上周，我们宣布了协议实验室与ConsenSys的扩展合作，ConsenSys是以太坊领域最受信任的软件工程领导者之一。ConsenSys Labs和Protocol Labs之间的新合作将Filecoin和以太坊生态系统整合在一起，以驱动下一代网络。合作已经宣布了来自ConsenSys Codefi的Filecoin存储和Filecoin Defi Bridge，MetaMask的Snaps，Infura的Filecoin网络API，与ConsenSys R＆D进行的二次检索挖掘研究以及去年夏天的Tachyon Launchpad Accelerator。 📂 Filecoin存档和建议 该Filecoin归档是Filecoin和协作的互联网档案馆项目选择的重要信息数据集和保存他们Filecoin网络上。这种由社区推动的工作需要您的帮助来决定选择哪些信息！任何人都可以通过发推并标记#FilecoinArchives来提出一个想法。Internet存档和协议实验室将收集您的建议，发布完整列表，并整理一个子集以保存在Filecoin网络上

本复习笔记基于谢希仁的《计算机网络》第五版教材整理。 由于一些原因笔记并不完整，后来考研复习时的复习PPT可以作为补充：计算机网络笔记 文章目录 《计算机网络》复习笔记 @[toc] 绪论 1.1 计算机网络 1.2 因特网概述 1.3 互联网的组成 P8 1.4 计算机网络的类别 P17 1.5 计算机网络的体系结构 P25 物理层 2.1 物理层下的传输媒体 2.2 关于信道的几个基本概念 2.3 信道复用技术 数据链路层 3.1 使用点对点信道的数据链路层 3.2点对点协议 PPP P70 3.3 使用广播信道的数据链路层 P76 3.4 以太网的MAC层 3.5 扩展的以太网 网络层 4.1 网际协议IP 4.1.1 虚拟互连网络 4.1.2 分类的IP地址 P113 4.1.3 IP地址与硬件地址 4.1.4 地址解析协议ARP 4.1.5 IP数据报 4.2 划分子网 P128 4.3 构造超网（无分类编址CIDR） 4.4 网际控制报文协议ICMP 4.5 路由选择协议 运输层 5.1 运输层协议概述 5.2 用户数据报协议 UDP 5.3 传输控制协议 TCP 5.4 可靠运输的工作原理 绪论 1.1 计算机网络 计算机网络向用户提供的两个最重要的功能： 连通性 共享 1.2 因特网概述 因特网发展的三个阶段： 第一阶段：从单个网络 ARPANET

设计模式简介 设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。 设计模式的类型 总共有 23 种设计模式。这些模式可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns） 创建型模式 这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。 - 工厂模式（Factory Pattern） - 抽象工厂模式（Abstract Factory Pattern） - 单例模式（Singleton Pattern） - 建造者模式（Builder Pattern） - 原型模式（Prototype Pattern） 结构型模式 这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。 - 适配器模式（Adapter Pattern） - 桥接模式（Bridge Pattern） - 过滤器模式（Filter、Criteria Pattern） -

什么是桥接？ 简单来说，桥接就是把一台机器上的若干个网络接口“连接”起来。其结果是，其中一个网口收到的报文会被复制给其他网口并发送出去。以使得网口之间的报文能够互相转发。 交换机就是这样一个设备，它有若干个网口，并且这些网口是桥接起来的。于是，与交换机相连的若干主机就能够通过交换机的报文转发而互相通信。 如下图：主机A发送的报文被送到交换机S1的eth0口，由于eth0与eth1、eth2桥接在一起，故而报文被复制到eth1和eth2，并且发送出去，然后被主机B和交换机S2接收到。而S2又会将报文转发给主机C、D。 交换机在报文转发的过程中并不会篡改报文数据，只是做原样复制。然而桥接却并不是在物理层实现的，而是在数据链路层。交换机能够理解数据链路层的报文，所以实际上桥接却又不是单纯的报文转发。 交换机会关心填写在报文的数据链路层头部中的Mac地址信息（包括源地址和目的地址），以便了解每个Mac地址所代表的主机都在什么位置（与本交换机的哪个网口相连）。在报文转发时，交换机就只需要向特定的网口转发即可，从而避免不必要的网络交互。这个就是交换机的“地址学习”。但是如果交换机遇到一个自己未学习到的地址，就不会知道这个报文应该从哪个网口转发，则只好将报文转发给所有网口（接收报文的那个网口除外）。 比如主机C向主机A发送一个报文，报文来到了交换机S1的eth2网口上。假设S1刚刚启动

RFC 7348 ToR: Top of Rack （一种数据中心的布线方式，就是在机柜的最上面安装接入交换机） VNI: VXLAN Network Identifier(or VXLAN Segment ID), The term is used as a representation of a 24-bit NVO instance identifier,with the understanding that VNI will refer to a VXLAN Network Identifier in VXLAN,or Virtual Netowrk Identifier in GENEVE,etc. （VXLAN网络中的标识符。一个VNI标识一个VXLAN网络？） VTEP: VXLAN Tunnel End Point.An entity that originates and/or terminates VXLAN tunnels. (VXLAN隧道的发起点 和/或 VXLAN隧道的结束点) VXLAN: Virtual eXtensible Local Area Network.（虚拟扩展局域网络） VXLAN Gateway: An entity that forwards traffic between VXLANs. （在VXLAN中转发流量的实体） RFC

目前，Apache Kafka 使用 Apache ZooKeeper 来存储它的元数据，比如分区的位置和主题的配置等数据就是存储在 ZooKeeper 集群中。在 2019 年社区提出了一个 计划 ，以打破这种依赖关系，并将元数据管理引入 Kafka 本身。 所以 Apache Kafka 为什么要移除 Zookeeper 的依赖？Zookeeper 有什么问题？实际上，问题不在于 ZooKeeper 本身，而在于外部元数据管理的概念。 拥有两个系统会导致大量的重复。毕竟，Kafka 是一个分布式的发布-订阅消息系统，而 ZooKeeper 其实也是一个分布式日志系统，其上有一个文件系统 API。每种方法都有自己的网络通信、安全、监视和配置方法。如果同时使用这两个系统，则系统的总体复杂性大约会增加一倍，这导致了不必要的学习曲线，并增加了错误配置导致安全漏洞的风险。 同时，在外部存储元数据并不是很好的。我们至少需要运行三个额外的 Java 进程，有时甚至更多。事实上，我们经常看到具有与 Kafka 节点一样多的 ZooKeeper 节点的 Kafka 集群！此外，ZooKeeper 中的数据还需要缓存在 Kafka 控制器上，这导致了双重缓存。 更糟糕的是，在外部存储元数据限制了 Kafka 的可伸缩性。当 Kafka 集群启动时，或者一个新的控制器被选中时，控制器必须从

XTP.rs 来源于: https://github.com/dovahcrow/xtp-rs 一、从RUST ->C++： 当Rust需要把指令传入XTP中时，以register_spi为例 1、rust中.rs文件中 let mut api = QuoteApi::new(1, &args.path, XTPLogLevel::Trace); info!("XTP Version: {:?}", api.get_api_version()); info!("Trading Day: {:?}", api.get_trading_day()); api.register_spi(MySpi); 2、quote_api.rs pub fn register_spi<T: QuoteSpi>(&mut self, spi: T) { let trait_object_box: Box<Box<dyn QuoteSpi>> = Box::new(Box::new(spi)); let trait_object_pointer = Box::into_raw(trait_object_box) as *mut Box<dyn QuoteSpi> as *mut c_void; let quote_spi_stub = unsafe { QuoteSpiStub::new(trait