首页 文章 精选 留言 我的

精选列表

搜索[网络通信],共1599篇文章
优秀的个人博客,低调大师

一文搞懂 Kubernetes 网络通信原理

接下来,我将用一个系列的文章对 Kubernetes 中的核心技术进行一一的探秘,话不多说,一起进入今天的内容吧。 名词解释 1、网络的命名空间:Linux 在网络栈中引入网络命名空间,将独立的网络协议栈隔离到不同的命名空间中,彼此间无法通信;Docker 利用这一特性,实现不容器间的网络隔离。 2、Veth 设备对:也叫虚拟网络接口对。Veth设备对的引入是为了实现在不同网络命名空间的通信。 3、Iptables/Netfilter:Netfilter 负责在内核中执行各种挂接的规则(过滤、修改、丢弃等),运行在内核 模式中;Iptables模式是在用户模式下运行的进程,负责协助维护内核中 Netfilter 的各种规则表;通过二者的配合来实现整个 Linux 网络协议栈中灵活的数据包处理机制。 4、网桥:网桥是一个二层网络设备,通过网桥可以将 linux 支持的不同的端口连接起来,并实现类似交换机那样的多对多的通信。 5、路由:Linux 系统包含一个完整的路由功能,当IP层在处理数据发送或转发的时候,会使用路由表来决定发往哪里。 令人头大的网络模型 Kubernetes对集群内部的网络进行了重新抽象,以实现整个集群网络扁平化。我们可以理解网络模型时,可以完全抽离物理节点去理解,我们用图说话,先有基本印象。 其中,重点讲解以下几个关键抽象概念。 一个 Service Service 是 Kubernetes 为屏蔽这些后端实例(Pod)的动态变化和对多实例的负载均衡而引入的资源对象。Service 通常与 deployment 绑定,定义了服务的访问入口地址,应用(Pod)可以通过这个入口地址访问其背后的一组由 Pod 副本组成的集群实例。Service 与其后端 Pod 副本集群之间则是通过 Label Selector 来实现映射。 Service的类型(Type)决定了 Service 如何对外提供服务,根据类型不同,服务可以只在Kubernetes cluster中可见,也可以暴露到集群外部。Service有三种类型,ClusterIP,NodePort 和 LoadBalancer。具体的使用场景会在下文中进行阐述。 在测试环境查看: $ kubectl get svc --selector app=nginxNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEnginx ClusterIP 172.19.0.166 <none> 80/TCP 1m$ kubectl describe svc nginxName: nginxNamespace: defaultLabels: app=nginxAnnotations: <none>Selector: app=nginxType: ClusterIPIP: 172.19.0.166Port: <unset> 80/TCPTargetPort: 80/TCPEndpoints: 172.16.2.125:80,172.16.2.229:80Session Affinity: NoneEvents: <none> 上述信息中该 svc 后端代理了2个Pod实例:172.16.2.125:80,172.16.2.229:80 二个 IP Kubernetes 为描述其网络模型的 IP 对象,抽象出 Cluster IP和Pod IP的概念。 Pod IP 是 Kubernetes 集群中每个 Pod 的 IP 地址。它是 Docker Engine 根据 docker0网桥的IP地址段进行分配的,是一个虚拟的二层网络。Kubernetes 中 Pod 间能够彼此直接通讯,Pod 里的容器访问另外一个Pod里的容器,是通过Pod IP所在进行通信。 Cluster IP仅作用于 Service,其没有实体对象所对应,因此 Cluster IP 无法被ping通。它的作用是为 Service 后端的实例提供统一的访问入口。当访问 Cluster IP 时,请求将被转发到后端的实例上,默认是轮询方式。Cluster IP 和 Service一样由 kube-proxy 组件维护,其实现方式主要有两种,iptables 和 IPVS。在 1.8 版本后 kubeproxy 开始支持IPVS 方式。在上例中,SVC的信息中包含了Cluster IP。 这里未列出 node ip 概念,由于其本身是物理机的网卡IP。因此可理解为nodeip就是物理机IP。 三个 Port 在 Kubernetes 中,涉及容器,Pod,Service,集群各等多个层级的对象间的通信,为在网络模型中区分各层级的通信端口,这里对Port进行了抽象。 Port 该Port非一般意义上的TCP/IP中的Port概念,它是特指Kubernetes中Service的port,是Service间的访问端口,例如Mysql的Service默认3306端口。它仅对进群内容器提供访问权限,而无法从集群外部通过该端口访问服务。 nodePort nodePort为外部机器提供了访问集群内服务的方式。比如一个Web应用需要被其他用户访问,那么需要配置type=NodePort,而且配置nodePort=30001,那么其他机器就可以通过浏览器访问scheme://node:30001访问到该服务,例如http://node:30001。 targetPort targetPort是容器的端口(最根本的端口入口),与制作容器时暴露的端口一致(DockerFile中EXPOSE),例如 http://docker.io 官方的 nginx 暴露的是80端口。 举一个例子来看如何配置 Service 的 port: kind: ServiceapiVersion: v1metadata: name: mallh5-service namespace: abcdockerspec: selector: app: mallh5web type: NodePort ports: - protocol: TCP port: 3017 targetPort: 5003 nodePort: 31122 这里举出了一个service的yaml,其部署在abcdocker的namespace中。这里配置了nodePort,因此其类型Type就是NodePort,注意大小写。若没有配置nodePort,那这里需要填写ClusterIP,即表示只支持集群内部服务访问。 集群内部通信 单节点通信 集群单节点内的通信,主要包括两种情况,同一个 pod 内的多容器间通信以及同一节点不同 pod 间的通信。由于不涉及跨节点访问,因此流量不会经过物理网卡进行转发。 通过查看路由表,也能窥见一二: root@node-1:/opt/bin# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0 172.23.100.1 0.0.0.0 UG 0 0 0 eth010.1.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel.1 #flannel 网络内跨节点的通信会交给 flannel.1 处理10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0 #flannel 网络内节点内的通信会走 docker0 1 Pod 内通信 如下图所示: 这种情况下,同一个pod内共享网络命名空间,容器之间通过访问 127.0.0.1:(端口)即可。图中的 veth* 即指veth对的一端(另一端未标注,但实际上是成对出现),该veth对是由 Docker Daemon 挂载在 docker0 网桥上,另一端添加到容器所属的网络命名空间,图上显示是容器中的eth0。 图中演示了 bridge 模式下的容器间通信。docker1 向 docker2 发送请求,docker1,docker2 均与 docker0 建立了 veth 对进行通讯。 当请求经过 docker0 时,由于容器和 docker0 同属于一个子网,因此请求经过 docker2与docker0的veth*对,转发到docker2,该过程并未跨节点,因此不经过eth0。 2 Pod 间通信 同节点 pod 间通信 由于 Pod 内共享网络命名空间(由 pause 容器创建),所以本质上也是同节点容器间的通信。同时,同一 Node 中 Pod 的默认路由都是 docker0 的地址,由于它们关联在同一个 docker0 网桥上,地址网段相同,所有它们之间应当是能直接通信的。来看看实际上这一过程如何实现。如上图,Pod1 中容器 1和容器 2 共享网络命名空间,因此对pod 外的请求通过 pod1 和 Docker0 网桥的 veth对(图中挂在eth0和ethx上)实现。 访问另一个pod内的容器,其请求的地址是PodIP而非容器的ip,实际上也是同一个子网间通信,直接经过veth对转发即可。 跨节点通信 CNI:容器网络接口 CNI 是一种标准,它旨在为容器平台提供网络的标准化。不同的容器平台(比如目前的 kubernetes、mesos 和 rkt)能够通过相同的接口调用不同的网络组件。 目前kubernetes支持的CNI组件种类很多,例如:bridge calico calico-ipam dhcp flannel host-local ipvlan loopback macvlan portmap ptp sample tuning vlan。在docker中,主流的跨主机通信方案主要有一下几种: 1)基于隧道的overlay网络:按隧道类型来说,不同的公司或者组织有不同的实现方案。docker原生的overlay网络就是基于vxlan隧道实现的。ovn则需要通过geneve或者stt隧道来实现的。flannel最新版本也开始默认基于vxlan实现overlay网络。 2)基于包封装的overlay网络:基于UDP封装等数据包包装方式,在docker集群上实现跨主机网络。典型实现方案有weave、flannel的早期版本。 3)基于三层实现SDN网络:基于三层协议和路由,直接在三层上实现跨主机网络,并且通过iptables实现网络的安全隔离。典型的方案为Project Calico。同时对不支持三层路由的环境,Project Calico还提供了基于IPIP封装的跨主机网络实现 通信方式 集群内跨节点通信涉及到不同的子网间通信,仅靠docker0无法实现,这里需要借助CNI网络插件来实现。图中展示了使用flannel实现跨节点通信的方式。 简单说来,flannel的用户态进程flanneld会为每个node节点创建一个flannel.1的网桥,根据etcd或apiserver的全局统一的集群信息为每个node分配全局唯一的网段,避免地址冲突。同时会为docker0和flannel.1创建veth对,docker0将报文丢给flannel.1,。 Flanneld维护了一份全局node的网络表,通过flannel.1接收到请求后,根据node表,将请求二次封装为UDP包,扔给eth0,由eth0出口进入物理网路发送给目的node。 在另一端以相反的流程。Flanneld解包并发往docker0,进而发往目的Pod中的容器。 外部访问集群 从集群外访问集群有多种方式,比如loadbalancer,Ingress,nodeport,nodeport和loadbalancer是service的两个基本类型,是将service直接对外暴露的方式,ingress则是提供了七层负载均衡,其基本原理将外部流量转发到内部的service,再转发到后端endpoints,在平时的使用中,我们可以依据具体的业务需求选用不同的方式。这里主要介绍nodeport和ingress方式。 Nodeport 通过将 Service 的类型设置为 NodePort,就可以在 Cluster 中的主机上通过一个指定端口暴露服务。注意通过 Cluster 中每台主机上的该指定端口都可以访问到该服务,发送到该主机端口的请求会被 Kubernetes 路由到提供服务的 Pod 上。采用这种服务类型,可以在 Kubernetes cluster 网络外通过主机 IP:端口的方式访问到服务。 这里给出一个 influxdb 的例子,我们也可以针对这个模板去修改成其他的类型: kind: ServiceapiVersion: v1metadata: name: influxdbspec: type: NodePort ports: - port: 8086 nodePort: 31112 selector: name: influxdb Ingress Ingress 是推荐在生产环境使用的方式,它起到了七层负载均衡器和 Http 方向代理的作用,可以根据不同的 url 把入口流量分发到不同的后端Service。外部客户端只看到 http://foo.bar.com 这个服务器,屏蔽了内部多个 Service 的实现方式。采用这种方式,简化了客户端的访问,并增加了后端实现和部署的灵活性,可以在不影响客户端的情况下对后端的服务部署进行调整。 其部署的 yaml 可以参考如下模板: apiVersion: extensions/v1beta1kind: Ingressmetadata: name: test annotations: ingress.kubernetes.io/rewrite-target: /spec: rules: - host: test.name.com http: paths: - path: /test backend: serviceName: service-1 servicePort: 8118 - path: /name backend: serviceName: service-2 servicePort: 8228 这里我们定义了一个ingress模板,定义通过 http://test.name.com 来访问服务,在虚拟主机http://test.name.com下面定义了两个Path,其中/test被分发到后端服务s1,/name被分发到后端服务s2。 集群中可以定义多个ingress,来完成不同服务的转发,这里需要一个ingress controller来管理集群中的Ingress规则。Ingress Contronler 通过与 Kubernetes API 交互,动态的去感知集群中 Ingress 规则变化,然后读取它,按照自定义的规则,规则就是写明了哪个域名对应哪个service,生成一段 Nginx 配置,再写到 Nginx-ingress-control的 Pod 里,这个 Ingress Contronler 的 pod 里面运行着一个nginx服务,控制器会把生成的nginx配置写入 /etc/nginx.conf 文件中,然后 reload使用配置生效。 Kubernetes 提供的 Ingress Controller 模板如下: apiVersion: extensions/v1beta1kind: Ingressmetadata: name: test annotations: ingress.kubernetes.io/rewrite-target: /spec: rules: - host: foo.bar.com http: paths: - path: /foo backend: serviceName: s1 servicePort: 80 - path: /bar backend: serviceName: s2 servicePort: 80 总结及展望 本文针对 Kubernetes 的网络模型,从一个 service,二个IP,三个 port 出发进行图解。详解 Kubernetes 集群内及集群外部访问方式。

优秀的个人博客,低调大师

源码分析Dubbo网络通信篇NettyServer、HeaderExchangeServer

本文主要分析一下NettyServer,HeaderExchangeServer实现细节。 1、NettyServer NettyServer整个类图如下: 首先从全貌上大概看一下NettyServer对象所持有的属性: AbstractPeer private final ChannelHandler handler 事件处理Handler。 private volatile URL url 该协议的第一个服务提供者的URL, Server只需要用到 URL中的参数,与具体某一个服务没什么关系。 AbstractEndpoint private Codec2 codec 编码解码器。 private int timeout 超时时间 private int connectTimeout 连接超时时间 AbstractServer private InetSocketAddress localAddress :url host:port地址。 private InetSocketAddress bindAddress:如果是多网卡,并且指定了 bind.ip、bind.port,如果为空,与localAddress相同。 private int accepts : AbstractServer#accepts未使用到。 private int idleTimeout = 600; AbstractServer#accepts未使用到。 NettyServer private Map< String, Channel> channels:< ip:port, channel> 所有通道。 private ServerBootstrap bootstrap : netty 服务端启动器。 private io.netty.channel.Channel channel:服务端监听通道。 private EventLoopGroup bossGroup;Netty boss线程组(负责连接事件) private EventLoopGroup workerGroup : nety work线程组(负责IO事件) 1.1 NettyServer 构造方法 public NettyServer(URL url, ChannelHandler handler) throws RemotingException { super(url, ChannelHandlers.wrap(handler, ExecutorUtil.setThreadName(url, SERVER_THREAD_POOL_NAME))); } 直接调用父类的public AbstractServer(URL url, ChannelHandler handler)方法,从前面的文章中得知, ChannelHandlers.wrap方法会对ChannelHandler handler进行封装,主要是加入事件分发模式(Dispatch)。 1.1.1 AbstractServer构造方法 public AbstractServer(URL url, ChannelHandler handler) throws RemotingException { super(url, handler); // @1 localAddress = getUrl().toInetSocketAddress(); // @2 String bindIp = getUrl().getParameter(Constants.BIND_IP_KEY, getUrl().getHost()); int bindPort = getUrl().getParameter(Constants.BIND_PORT_KEY, getUrl().getPort()); if (url.getParameter(Constants.ANYHOST_KEY, false) || NetUtils.isInvalidLocalHost(bindIp)) { bindIp = NetUtils.ANYHOST; } bindAddress = new InetSocketAddress(bindIp, bindPort); // @3 this.accepts = url.getParameter(Constants.ACCEPTS_KEY, Constants.DEFAULT_ACCEPTS); this.idleTimeout = url.getParameter(Constants.IDLE_TIMEOUT_KEY, Constants.DEFAULT_IDLE_TIMEOUT); // @4 try { doOpen(); // @5 if (logger.isInfoEnabled()) { logger.info("Start " + getClass().getSimpleName() + " bind " + getBindAddress() + ", export " + getLocalAddress()); } } catch (Throwable t) { throw new RemotingException(url.toInetSocketAddress(), null, "Failed to bind " + getClass().getSimpleName() + " on " + getLocalAddress() + ", cause: " + t.getMessage(), t); } //fixme replace this with better method DataStore dataStore = ExtensionLoader.getExtensionLoader(DataStore.class).getDefaultExtension(); executor = (ExecutorService) dataStore.get(Constants.EXECUTOR_SERVICE_COMPONENT_KEY, Integer.toString(url.getPort())); } 代码@1:调用父类的构造方法,主要初始化AbstractPeer(channelHandler、url)和AbstractEndpoint(codec2、timeout、idleTimeout ) 代码@2:根据URL中的host与端口,创建localAddress。 代码@3:如果配置了< dubbo:parameter key = "bind.ip" value = ""/> 与 < dubbo:parameter key = "bind.port" />,则用该IP与端口创建bindAddress,通常用于多网卡,如果未配置,bindAddress与 localAddress绑定的IP与端口一样。 代码@4:初始化accepts与idleTimeout ,这两个参数未被其他地方使用。 代码@5,调用doOpen方法,正式在相应端口建立网络监听。 1.2、源码分析NettyServer#doOpen protected void doOpen() throws Throwable { NettyHelper.setNettyLoggerFactory(); bootstrap = new ServerBootstrap(); // @1 bossGroup = new NioEventLoopGroup(1, new DefaultThreadFactory("NettyServerBoss", true)); // @2 workerGroup = new NioEventLoopGroup(getUrl().getPositiveParameter(Constants.IO_THREADS_KEY, Constants.DEFAULT_IO_THREADS), new DefaultThreadFactory("NettyServerWorker", true)); // @3 final NettyServerHandler nettyServerHandler = new NettyServerHandler(getUrl(), this); // @4 channels = nettyServerHandler.getChannels(); bootstrap.group(bossGroup, workerGroup) // @5 .channel(NioServerSocketChannel.class) .childOption(ChannelOption.TCP_NODELAY, Boolean.TRUE) .childOption(ChannelOption.SO_REUSEADDR, Boolean.TRUE) .childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT) .childHandler(new ChannelInitializer<niosocketchannel>() { @Override protected void initChannel(NioSocketChannel ch) throws Exception { NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec(), getUrl(), NettyServer.this); ch.pipeline()//.addLast("logging",new LoggingHandler(LogLevel.INFO))//for debug .addLast("decoder", adapter.getDecoder()) .addLast("encoder", adapter.getEncoder()) .addLast("handler", nettyServerHandler); } }); // bind ChannelFuture channelFuture = bootstrap.bind(getBindAddress()); // @6 channelFuture.syncUninterruptibly(); channel = channelFuture.channel(); } 代码@1:创建Netty服务端启动帮助类ServerBootstrap. 代码@2:创建服务端Boss线程,线程名:.NettyServerBoss,主要负责客户端的连接事件,主从多Reactor线程模型中的主线程(连接事件)。 代码@3:创建服务端Work线程组,线程名:NettyServerWorker-序号,线程个数取自参数:iothreads,默认为(CPU核数+1)与32取小值,顾名思义,IO线程数,主要处理读写事件,编码、解码都在IO线程中完成。 代码@4:创建用户Handler,这里是NettyServerHandler。 代码@5:Netty启动的常规写法,关注如下内容: addLast("decoder", adapter.getDecoder()) : 添加解码器 addLast("encoder", adapter.getEncoder()) :添加编码器 addLast("handler", nettyServerHandler) :添加业务Handler。 这里简单介绍一下流程: 客户端建立与服务端连接,此时Boss线程的连接事件触发,建立TCP连接,并向IO线程注册该通道(Channel0)的读事件。 当客户端向服务端发送请求消息后,IO线程中的读事件触发,会首先调用adapter.getDecoder() 根据对应的请求协议(例如dubbo)从二进制流中解码出一个完整的请求对象,然后传入到业务handler,例如nettyServerHandler,执行相应的事件方法,例如recive方法。 当服务端向Channel写入响应结果时,首先编码器会按照协议编码成二进制流,供客户端解码。 如果对Netty想深入学习的话,请移步到作者的《源码分析Netty系列》 2、HeaderExchangeServer 根据 Dubbo 服务端初始化流程,我们可知,Dubbo 为了封装各种不同的网络实现客户端(netty、mina)等,引入了 Exchangers 层,存在 ExchangeServer,其实现 Server 并内部持有具体的 Server 实现端,例如 NettyServer。 接下来,我们重点来关注一下 HeaderExchangeServer. 核心属性如下: ScheduledExecutorService scheduled:心跳线程数,线程名称前缀,dubbo-remoting-server-heartbeat-thread-序号 private final Server server:具体的Server实现类,例如NettyServer。 private ScheduledFuture< ?> heartbeatTimer:心跳调度Future,可以通过future取消心跳等动作。 private int heartbeat:心跳间隔时间 private int heartbeatTimeout:心跳超时时间,至少为heartbeat的两倍 2.1 构造函数 public HeaderExchangeServer(Server server) { if (server == null) { throw new IllegalArgumentException("server == null"); } this.server = server; this.heartbeat = server.getUrl().getParameter(Constants.HEARTBEAT_KEY, 0); this.heartbeatTimeout = server.getUrl().getParameter(Constants.HEARTBEAT_TIMEOUT_KEY, heartbeat * 3); if (heartbeatTimeout &lt; heartbeat * 2) { throw new IllegalStateException("heartbeatTimeout &lt; heartbeatInterval * 2"); } startHeartbeatTimer(); } 说明,主要是通过heartbeat参数设置心跳间隔,如果不配置,则不启动心跳检测。从上面看来HeaderExchangeServer内部持有Server,并封装了心跳的功能,在这里就不细细分析了。 >作者介绍:丁威,《RocketMQ技术内幕》作者,RocketMQ 社区优秀布道师、CSDN2019博客之星TOP10,维护公众号:中间件兴趣圈目前已陆续发表源码分析Java集合、Java 并发包(JUC)、Netty、Mycat、Dubbo、RocketMQ、Mybatis等源码专栏。可以点击链接加入中间件知识星球 ,一起探讨高并发、分布式服务架构,交流源码。 </niosocketchannel>

优秀的个人博客,低调大师

关于交换机网络通信故障排除

思科的catalyst交换机一般不容易产生故障,一但产生故障,对于CCNA认证标准的学员通常都不太好检测和排除,在本小节将总结在交换机使用过程中常出现的一些小故障,以帮助学员通过认证并适应简单的工作环境。 关于物理层线路连接的故障: 物理层线路连接是网络正常使用的提前,不得不指出,很多时候所谓的网络故障是因为物理层线路接连所导致,比如:连接相应桌面计算机的双绞线连接了错误的交换机接口、RJ45连接头松脱、没有连接物理线缆等。在这里需要特别提出的是思科的交换机连接交换机使用交叉双绞线、交换机与路由器或者计算机相连使用直通双绞线。如果您需要交换机在某个接口上进行自适应介质接口,就必须在相关的接口模式下启动auto-MDIX指令,auto-MDIX的全称叫做automatic medium-dependent interface crossover自动介质接口交叉,当启动这个功能后,无论接口连接的是哪种类型的线缆,交换机都能自动调节该接口使其保持正常的工作。启动auto-MDIX有一个要求:该接口必须能自动协商速率与双工模式。 关于双工模式的故障: 双式模式不匹配可能会产生相关的故障。以本书出版的时间为界线,现今网络市场上几乎所有的设备都支持全双工模式,当然除了传统的集线器(HUB)设备外,应该让所有的网络设备处于全双式的模式下。默认情况下,思科建议将交换机的接口配置成自动协商速度与双工模式,这样做的理由是:如果发生一个半双工的设备去连接思科的交换机,那么,思科的交换机将把自己的全双工降级成半双工模式以适应该设备的运行,如果管理员强制要求交换机接口工作在全双工模式下,将产生接口错误。排除的依据是使用show interfaces fastEthernet 0/1 counters errors查看接口上的错误。如图14.27所示。 关于接口出错的故障: 交换机的接口出错通常会导致大量的数据帧,比如:当用户发现基于TCP的应用变得非常缓慢时,从表面看上去TCP的应用变慢是乎与交换机接口故障无关,但是进一步思考,TCP变慢的更多原因是由于TCP慢启动所致,在TCP慢启动的状态下TCP的滑动窗口尺寸将变小,而这种现象往往是交换机丢包所致,在这种状况下,基于UDP的应用就更可怕,因为UDP根本不会重传,所以网络质量将严重下降。所以在排除这种故障时,我们需要知道,交换机为什么丢包,这往往与交换机的接口错误有关,必须查看交换机接口的错误统计消息,关于交换机接口的错误统计消息,可以通过show interface x/y counters errors来得到如上图14.27所示,现在来理解每个错误统计器的意义: nAlign-Err(对齐错误):如果数据帧不是以偶数个八位组结束就会出现对齐错误,指示是物理层差错,一般是由于布线、交换机接口故障所引发。 nFCS-Err(帧校验错误):帧校验错误,通常也发生在物理层,并伴随Align-Err现象。 nXmit-Err(发送错误):指示交换机的接口发送缓存溢出,这通常是入站和出站速率不匹配所造成的。 nRcv-Err(接收错误):指示交换机的接口接收缓存溢出,这通常是交换机的背板发生拥塞,导致接收缓存被堆满。在很多时候接收错误也暗示了双工模式不匹配。 nUnderSize(超短帧):指示校验和有效,但是帧尺寸小于64字节,这表示连接到该接口的主机正在发送无效的数据帧尺寸。 nSingle-Col(单一冲突):指示在该接口成功发送数据帧之前,产生了一次冲突时会发生单一冲突错误,产生这种错误的原因是链路的使用率过高或者双工不匹配。 nMulti-Col(多次冲突):指示在该接口成功发送数据帧之前,产生了多次冲突时会发生多次冲突错误,产生这种错误的原因是链路的使用率过高或者双工不匹配。 nLate-Col(后期冲突):指示转发数据帧以后,才检测到的冲突,产生这种错误的原因是物理介质(比如:线缆)过长、或者双工不匹配。 nExcess-Col(过载冲突):当数据帧连续遇到16次冲突后会被丢弃,此时就会出现过载冲突错误,产生这种错误的主要原因是链路的使用率过高、双工不匹配、网络中的设备特别是半双工设备太多。 nCarri-Sen(载波侦听):指示该接口工作在半双工状态,根据CSMA/CD的工作原理,在半双工状态下发送数据时,需要进行冲突检测这将增加carri-sen计数器,在全双工的模式下是不使用CSMA/CD。 nRunts(残帧):帧的尺寸小于64个字节,而且CRC错误,出现残帧的错误一般是由物理层故障或者双工模式不匹配所导致的。 nGiants(超长帧):帧的尺寸大于1518个字节,通常出现超长帧错误是主机NIC故障所导致。 关于交换机CPU的使用率过高的故障: 如图14.28所示的交换机架构,通常交换机的架构由两个层面组成:一个控制层面、一个转发层面。控制层面负责运行交换机的操作系统,STP、路由协议、维护路由表、执行ACL等,控制层面包括交换机的CPU和内存。转发层面包括交换机的转发逻辑和背板,交换机的转发逻辑是交换机用于做出转发决定的硬件,该硬件负责重写数据帧头;而交换机的背板负责物理连接到交换机的端口,它依赖于交换机的体系统架构,数据帧从交换机的入站接口进入,然后转发给交换机的背板,最后通过出站接口转发数据帧。注意在这个过程中控制平面并不直接参与数据帧的转发操作。所以在交换机正常工作的情况下,即便是流量转发的高峰期,交换机的CPU占用率也应该很低,因为它不直接参加流量转发。 图14.28交换机的架构 虽然控制层面不直接参与流量转发,但是由于转发层面中的转发逻辑却来自于控制层面,因为数据帧思转发与控制层面还是存在一定的间接关系的,这样的话,如果控制层面出现持续性的高负载,比如CPU占用率过高,这将影响交换机转发数据的速率。所以从交换机的架构来讲,控制层面不会影响交换机的性能,但是在故障排除时还必须考虑控制层面的因素。 交换机的转发逻辑以一个叫做TCAM的专用内存体现,TCAM与交换机的CEF功能相结合,数据转发的速度将非常快,但是一旦转发逻辑故障,比如:TCAM内存溢出,转发逻辑将无法转发流量,此时将由交换机的CPU来完成转发流量,这将增加交换机CPU的开销,转发能力也会被降低。或者换一句话来讲,如果交换机的CPU占用率过高,这表示交换机已经没有使用转发逻辑转发数据帧,需要及时排查故障。 本文转自 kingsir827 51CTO博客,原文链接:http://blog.51cto.com/7658423/1371766,如需转载请自行联系原作者

优秀的个人博客,低调大师

盘点:2020上半年网络通信大事件

转眼间,2020年已过去一半。这期间,在疫情“黑天鹅”的煽动下,远程办公迎来发展新风口。新基建按下产业数字化“加速键“,推进 5G、物联网、车联网、工业互联网等新型基础设施投资。网络巨头们的收购案也是层出不穷。接下来,小编就给大家盘点一下,上半年网络界发生的一些热点事件。 一、Wi-Fi联盟公布了Wi-Fi 6E标准,支持6GHz频段 2020年1月,Wi-Fi联盟宣布Wi-Fi 6将从现有的2.4GHz和5GHz频段扩展至6GHz频段,并将支持6GHz频段的Wi-Fi 6将统一命名为“Wi-Fi 6E”。 Wi-Fi 6E中新增的6GHz则透过提供连续的频谱段,来容纳14个额外的80MHz通道,以及7个额外的160MHz通道,可解决Wi-Fi频段不足的问题。 Wi-Fi 6E具备更多的频道、更宽广的频谱空间;Wi-Fi网络间的干扰将会减少;速度更快、更稳定等优势。 IDC研究主管Phil Solis表示“由于6GHz频段的Wi-Fi潜力巨大,所以人们对它的使用可能会迅速增加。” Wi-Fi联盟的总裁兼CEO Edgar Figueroa表示“6GHz将有利于满足智慧设备对Wi-Fi频谱频段增加的需求,并带给用户优良的使用体验。” 二、国家力推新基建投资,5G网络建设大幕拉开 2018年12月,中央经济工作会议重新定义了基础设施建设,把5G、人工智能、工业互联网、物联网定义为“新型基础设施建设”。2019年7月,中共中央政治局召开会议,提出“加快推进信息网络等新型基础设施建设”。 2020年3月,中共中央政治局常务委员会召开会议,强调“要加大公共卫生服务、应急物资保障领域投入,加快5G网络、数据中心等新型基础设施建设进度”。至此,新基建板块“站上风口”。 新基建将加快推动我国第四次产业革命浪潮,它将助推数字经济产业化,为所涉及的信息基础设施、大数据等产业带来天量投资。从根本上改造传统行业,形成具有颠覆意义的产业物联网。在政策加持下,5G等新基建项目在各地加速落地。 三、工信部发布《关于深入推进移动物联网全面发展的通知》 2020年5月,工信部办公厅正式发布了《关于深入推进移动物联网全面发展的通知》。其中,工信部部署了五项重点任务,包括网络建设、技术标准、行业应用、产业体系、安全保障方面的工作内容。 旨在准确把握全球移动物联网技术标准和产业格局的演进趋势,推动2G/3G物联网业务迁移转网,建立NB-IoT(窄带物联网)、4G(含LTE-Cat1,即速率类别1的4G网络)和5G协同发展的移动物联网综合生态体系。 在深化4G网络覆盖、加快5G网络建设的基础上,以NB-IoT满足大部分低速率场景需求,以LTE-Cat1(以下简称Cat1)满足中等速率物联需求和话音需求,以5G技术满足更高速率、低时延联网需求。 到2020年底,NB-IoT网络实现县级以上城市主城区普遍覆盖,重点区域深度覆盖;移动物联网连接数达到12亿;推动NB-IoT模组价格与2G模组趋同,引导新增物联网终端向NB-IoT和Cat1迁移;打造一批NB-IoT应用标杆工程和NB-IoT百万级连接规模应用场景。 四、思科宣布收购Fluidmesh,增强物联网接入能力 2020年4月,思科宣布将收购Fluidmesh Networks,后者主要提供连接物联网设备的无线回程系统。此举将使思科能够向交通运输公司、矿业运营公司和其他希望拥有自己的专用无线网络的企业出售网络连接。 Fluidmesh的技术很有价值,该技术在列车快速移动或在Wi-Fi覆盖范围不完整的情况下,实现零数据传输损失,该公司的平台用于各种运营,包括铁路、港口和公共交通。 思科表示,该计划旨在将Fluidmesh并入思科的物联网业务部门,以便将其工业无线服务扩展到更多行业和客户领域。此外,思科公司计划利用Fluidmesh的专业销售团队和系统集成商关系,扩大其物联网业务的范围。 思科物联网业务副总裁Vikas Butaney表示,“思科已经与FluidmeshNetworks合作了多年,使用该公司的回程技术进行特定的IoT部署。”在过去的几年里,思科对物联网进行了很大的投资,其主要目标是在边缘提供基于意图的网络。 五、VMware收购Nyansa来扩展SD-WAN领域 2020年1月,VMware今天宣布计划收购位于美国加州帕洛阿尔托的Nyansa公司,该公司主要提供基于AI的网络分析。预计这次收购交易将在VMware 2021财年第一季度完成,交易的条款没有对外透露。 VMware计划把用于网络分析和物联网安全的AIOps平台Nyansa Voyance与VeloCloud的VMware SD-WAN相结合。这一组合通过在Wi-Fi和LAN设备上添加软件定义的功能,将有助于VMware把产品组合进一步扩展到企业园区和分支机构,这样用户就可以获得有关网络流量和应用性能的全方位数据。 VMware副总裁、VeloCloud业务部门总经理Sanjay Uppal在声明中表示:“收购Nyansa将加快VMware在行业领先SD-WAN解决方案中为LAN/WAN部署提供端到端监视和故障排除的功能。Nyansa是一套经过验证的解决方案,可以解决当今特定厂商解决方案的许多缺点。” VMware现有的SD-WAN服务基于其2017年对VeloCloud的收购,可在广域网上进行故障排除和优化。Nyansa将将这些服务扩展到LAN,VMware先前还通过其vRealize Network Insight(VRNI)在数据中心提供了优化服务。

优秀的个人博客,低调大师

AI-多云互联,网络通信的“自动驾驶

数字时代需要可编程的灵活性,敏捷性和互连性 全球国际电信会议PTC称数字化转型将开启“‘连接’的新十年”。Equinix在发布的《全球互联指数》报告中指出,城市化、数据主权、网络安全和全球数字服务贸易等技术的使用,推动了全球数字化的发展趋势。正是在这样的背景下,数字媒体、人工智能/机器学习(AI/ML)、大数据和安全分析、增强/虚拟现实和物联网(IoT)等产业日益增长。 与传统骨干网络相比,这些技术应用的动态性和交互性特征需要更加的弹性、灵活、低延迟和高带宽的连接来处理数字洪流。事实上,全球互连指数预测,到2020年,数字业务将需要5,000 Tbps以上的互连带宽容量,才能满足企业之间数据交换,这一带宽容量需求已经超过了当前全球IP流量、互联网和MPLS网络的总体增长。 这就是为什么业界纷纷转向SDN和NFV技术,从而将其带入数字化时代的未来! 过去十年来,SDN和NFV的供应商和用户一直致力于充分利用这两种不断发展的技术,但仍有很大的增长空间。TBR报告称,近四分之三的领先一级运营商已经或计划采用SDN和NFV。报告预测从2016年到2022年,SDN/NFV总开支将增长94.3%,达到1680亿美元。 为了在新的全球经济中取得成功,企业需要在数字和商业生态系统内部以及之间建立全球互联关系,以便利用邻近性进行直接和安全的数据交换。这种邻近性使他们能够为全球数字用户群创建一个更动态、物理和虚拟的分布式、互连和集成的解决方案。 基于SDN的互连架构使企业能够充分利用混合IT基础架构的重要协同作用,融合本地和厂商中立的多租户数据中心,网络,云,应用程序,数据和安全性,为客户创建全球集成的端到端数字解决方案。 传统的基于运营商的网络和基于SDN的互连结构 我们看到SDN / NFV基础架构在全球数字业务数字化转型中扮演着重要角色。 例如:战略性地为边缘IT流量交换和控制提供可编程互连功能,以访问对延迟敏感的关键IT服务,应用和数据/资产分析。 支持快速访问与应用程序、数据和用户密切相关的的混合和多云服务。这加快了市场速度,和可扩展性,确保了业务连续性和灾难恢复的可靠冗余。 要想实现“能够为全球数字用户群创建一个更动态、物理和虚拟的分布式、互连和集成的解决方案“,跨平台、混合多云服务的网络连接和打通就成为了首要解决的问题。 传统的基于运营商的网络和基于SDN的互连结构目前存在以下问题需要注意和解决: 不同云厂商及IDC平台间由于自身技术机构和程序编排的差异,导致跨平台(跨供应商)间的互联变得更加困难; 随着业务及应用技术的快速扩张和飞速发展,为了适应终端客户或合作伙伴的需求,目前企业对于混合多云的互联需求已经不只停留在点对点或点对多点的互联上,使系统得到一个能够快速实现多点全网状结构的平台或功能; 传统运营商专线组网的业务模式,导致多云互联带宽需求会因可能极少出现但必须得到保证的最高带宽作为购买的基础,无法按需、弹性使用和计费,在全网拓扑下这更成为了意见天大的难事; 多云互联在传统专线接入方式下,固定带宽模式经常会出现过渡使用或资源冗余的情况出现,无法按需分配给需要的节点使用。 SDN/NFV和AI是如何被杠杆和商业化的? 通过SDN平台可以打破不同厂商不同平台的差异,通过简单几步操作快速实现跨平台的混合多云连接服务; 为了迎合多云混合、协同的需求,必须拥有具备建立矩阵式全网状拓扑结构网络的功能; 在全网状拓扑结构下可以实现任意连接端口的实时弹性带宽调整; 建立带宽资源池,打破固定端口或线路带宽的模式,具备一颗超强计算能力的“大脑“,它可以通过端口流量历史情况、突发状态等数据进行分析,从而AI智能的判断和实时调节分布在全球各地的端口限速,直到资源池用量到达阈值后进行告警,将资源利用效率和变化莫测的终端带宽需求完美的融合解决。

优秀的个人博客,低调大师

高性能网络通信框架Netty-基础概念篇

一、前言 Netty是一种可以轻松快速的开发协议服务器和客户端网络应用程序的NIO框架,它大大简化了TCP或者UDP服务器的网络编程,但是你仍然可以访问和使用底层的API,Netty只是对其进行了高层的抽象。 Netty的简易和快速开发并不意味着由它开发的程序将失去可维护性或者存在性能问题。Netty是被精心设计的,它的设计参考了许多协议的实现,比如FTP,SMTP,HTTP和各种二进制和基于文本的传统协议,因此 Netty成功的实现了兼顾快速开发,性能,稳定性,灵活性为一体,不需要为了考虑一方面原因而妥协其他方面。 二、基础概念 Channel也就是通道,这个概念是在JDK NIO类库里面提供的一个概念,JDK中其实现类有客户端套接字通道java.nio.channels.SocketChannel和服务端监听套接字通道java.nio

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册