DockOne微信分享(一二二):探索Kubernetes的网络原理及方案

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
全局流量管理 GTM,标准版 1个月
简介: 本文讲的是DockOne微信分享(一二二):探索Kubernetes的网络原理及方案【编者的话】2016年ClusterHQ容器技术应用调查报告显示,一年来容器技术应用于生产的比例增长了96%,Kubernetes的使用率达到了40%,成为了最受欢迎的容器编排工具;那么Kubernetes到底是什么呢?它是一个用于容器集群的自动化部署、扩容以及运维的开源平台;那么通过Kubernetes能干什么呢?它能快速而有预期地部署你的应用,极速地扩展你的应用,无缝对接新的应用功能,节省资源,优化硬件资源的使用。
本文讲的是DockOne微信分享(一二二):探索Kubernetes的网络原理及方案【编者的话】2016年ClusterHQ容器技术应用调查报告显示,一年来容器技术应用于生产的比例增长了96%,Kubernetes的使用率达到了40%,成为了最受欢迎的容器编排工具;那么Kubernetes到底是什么呢?它是一个用于容器集群的自动化部署、扩容以及运维的开源平台;那么通过Kubernetes能干什么呢?它能快速而有预期地部署你的应用,极速地扩展你的应用,无缝对接新的应用功能,节省资源,优化硬件资源的使用。随着Kubernetes王者时代的到来,计算、网络、存储、安全是Kubernetes绕不开的话题,本次交流与大家分享下Kubernetes网络原理及方案。

【3 天烧脑式 Docker 训练营 | 上海站】随着Docker技术被越来越多的人所认可,其应用的范围也越来越广泛。本次培训我们理论结合实践,从Docker应该场景、持续部署与交付、如何提升测试效率、存储、网络、监控、安全等角度进行。

一、Kubernetes网络模型

在Kubernetes网络中存在两种IP(Pod IP和Service Cluster IP),Pod IP 地址是实际存在于某个网卡(可以是虚拟设备)上的,Service Cluster IP它是一个虚拟IP,是由kube-proxy使用Iptables规则重新定向到其本地端口,再均衡到后端Pod的。下面讲讲Kubernetes Pod网络设计模型:

1、基本原则

每个Pod都拥有一个独立的IP地址(IPper Pod),而且假定所有的Pod都在一个可以直接连通的、扁平的网络空间中。

2、设计原因

用户不需要额外考虑如何建立Pod之间的连接,也不需要考虑将容器端口映射到主机端口等问题。

3、网络要求

所有的容器都可以在不用NAT的方式下同别的容器通讯;所有节点都可在不用NAT的方式下同所有容器通讯;容器的地址和别人看到的地址是同一个地址。

二、Docker网络基础

Linux网络名词解释

  1. 网络的命名空间:Linux在网络栈中引入网络命名空间,将独立的网络协议栈隔离到不同的命令空间中,彼此间无法通信;Docker利用这一特性,实现不同容器间的网络隔离。
  2. Veth设备对:Veth设备对的引入是为了实现在不同网络命名空间的通信。
  3. Iptables/Netfilter:Netfilter负责在内核中执行各种挂接的规则(过滤、修改、丢弃等),运行在内核模式中;Iptables模式是在用户模式下运行的进程,负责协助维护内核中Netfilter的各种规则表;通过二者的配合来实现整个Linux网络协议栈中灵活的数据包处理机制。
  4. 网桥:网桥是一个二层网络设备,通过网桥可以将Linux支持的不同的端口连接起来,并实现类似交换机那样的多对多的通信。
  5. 路由:Linux系统包含一个完整的路由功能,当IP层在处理数据发送或转发的时候,会使用路由表来决定发往哪里。

Docker生态技术栈

下图展示了Docker网络在整个Docker生态技术栈中的位置:
1.png

Docker网络实现

  1. 单机网络模式:Bridge 、Host、Container、None,这里具体就不赘述了。
  2. 多机网络模式:一类是Docker在1.9版本中引入Libnetwork项目,对跨节点网络的原生支持;一类是通过插件(plugin)方式引入的第三方实现方案,比如 Flannel,Calico 等等。

三、Kubernetes网络基础

1、容器间通信

同一个Pod的容器共享同一个网络命名空间,它们之间的访问可以用localhost地址 + 容器端口就可以访问。
2.png

2、同一Node中Pod间通信

同一Node中Pod的默认路由都是docker0的地址,由于它们关联在同一个docker0网桥上,地址网段相同,所有它们之间应当是能直接通信的。

3.png

3、不同Node中Pod间通信

不同Node中Pod间通信要满足2个条件: Pod的IP不能冲突; 将Pod的IP和所在的Node的IP关联起来,通过这个关联让Pod可以互相访问。

4.png

4、Service介绍

Service是一组Pod的服务抽象,相当于一组Pod的LB,负责将请求分发给对应的Pod;Service会为这个LB提供一个IP,一般称为ClusterIP。
5.png

6.png

7.png

8.png

5、Kube-proxy介绍

Kube-proxy是一个简单的网络代理和负载均衡器,它的作用主要是负责Service的实现,具体来说,就是实现了内部从Pod到Service和外部的从NodePort向Service的访问。

实现方式:
  • User space是在用户空间,通过kuber-proxy实现LB的代理服务,这个是kube-proxy的最初的版本,较为稳定,但是效率也自然不太高。
  • Iptables是纯采用Iptables来实现LB,是目前kube-proxy默认的方式。

下面是Iptables模式下kube-proxy的实现方式:
9.png

  • 在这种模式下,kube-proxy监视Kubernetes主服务器添加和删除服务和端点对象。对于每个服务,它安装iptables规则,捕获到服务的clusterIP(虚拟)和端口的流量,并将流量重定向到服务的后端集合之一。对于每个Endpoints对象,它安装选择后端Pod的iptables规则。
  • 默认情况下,后端的选择是随机的。可以通过将service.spec.sessionAffinity设置为“ClientIP”(默认为“无”)来选择基于客户端IP的会话关联。
  • 与用户空间代理一样,最终结果是绑定到服务的IP:端口的任何流量被代理到适当的后端,而客户端不知道关于Kubernetes或服务或Pod的任何信息。这应该比用户空间代理更快,更可靠。然而,与用户空间代理不同,如果最初选择的Pod不响应,则Iptables代理不能自动重试另一个Pod,因此它取决于具有工作准备就绪探测。

6、Kube-dns介绍

Kube-dns用来为Kubernetes Service分配子域名,在集群中可以通过名称访问Service;通常kube-dns会为Service赋予一个名为“service名称.namespace.svc.cluster.local”的A记录,用来解析Service的ClusterIP。

Kube-dns组件:
  • 在Kubernetes v1.4版本之前由“Kube2sky、Etcd、Skydns、Exechealthz”四个组件组成。
  • 在Kubernetes v1.4版本及之后由“Kubedns、Dnsmasq、exechealthz”三个组件组成。
    10.png

KubeDNS
  • 接入SkyDNS,为dnsmasq提供查询服务。
  • 替换etcd容器,使用树形结构在内存中保存DNS记录。
  • 通过Kubernetes API监视Service资源变化并更新DNS记录。
  • 服务10053端口。

Dnsmasq

Dnsmasq是一款小巧的DNS配置工具。

在kube-dns插件中的作用是:
  1. 通过kubedns容器获取DNS规则,在集群中提供DNS查询服务
  2. 提供DNS缓存,提高查询性能
  3. 降低kubedns容器的压力、提高稳定性

Dockerfile在GitHub上Kubernetes组织的contrib仓库中,位于dnsmasq目录下。

在kube-dns插件的编排文件中可以看到,dnsmasq通过参数--server=127.0.0.1:10053指定upstream为kubedns。

Exechealthz
  • 在kube-dns插件中提供健康检查功能。
  • 源码同样在contrib仓库中,位于exec-healthz目录下。
  • 新版中会对两个容器都进行健康检查,更加完善。

四、Kubernetes网络开源组件

1、技术术语

IPAM :IP地址管理;这个IP地址管理并不是容器所特有的,传统的网络比如说DHCP其实也是一种IPAM,到了容器时代我们谈IPAM,主流的两种方法: 基于CIDR的IP地址段分配地或者精确为每一个容器分配IP。但总之一旦形成一个容器主机集群之后,上面的容器都要给它分配一个全局唯一的IP地址,这就涉及到IPAM的话题。

Overlay :在现有二层或三层网络之上再构建起来一个独立的网络,这个网络通常会有自己独立的IP地址空间、交换或者路由的实现。

IPSesc :一个点对点的一个加密通信协议,一般会用到Overlay网络的数据通道里。

VXLAN :由VMware、Cisco、RedHat等联合提出的这么一个解决方案,这个解决方案最主要是解决VLAN支持虚拟网络数量(4096)过少的问题。因为在公有云上每一个租户都有不同的VPC,4096明显不够用。就有了vxLAN,它可以支持1600万个虚拟网络,基本上公有云是够用的。

网桥Bridge :连接两个对等网络之间的网络设备,但在今天的语境里指的是Linux Bridge,就是大名鼎鼎的Docker0这个网桥。

BGP :主干网自治网络的路由协议,今天有了互联网,互联网由很多小的自治网络构成的,自治网络之间的三层路由是由BGP实现的。

SDN、Openflow :软件定义网络里面的一个术语,比如说我们经常听到的流表、控制平面,或者转发平面都是Openflow里的术语。

2、容器网络方案

隧道方案( Overlay Networking )

隧道方案在IaaS层的网络中应用也比较多,大家共识是随着节点规模的增长复杂度会提升,而且出了网络问题跟踪起来比较麻烦,大规模集群情况下这是需要考虑的一个点。
  • Weave:UDP广播,本机建立新的BR,通过PCAP互通
  • Open vSwitch(OVS):基于VXLAN和GRE协议,但是性能方面损失比较严重
  • Flannel:UDP广播,VxLan
  • Racher:IPsec

路由方案

路由方案一般是从3层或者2层实现隔离和跨主机容器互通的,出了问题也很容易排查。
  • Calico:基于BGP协议的路由方案,支持很细致的ACL控制,对混合云亲和度比较高。
  • Macvlan:从逻辑和Kernel层来看隔离性和性能最优的方案,基于二层隔离,所以需要二层路由器支持,大多数云服务商不支持,所以混合云上比较难以实现。

3、CNM & CNI阵营

容器网络发展到现在,形成了两大阵营,就是Docker的CNM和Google、CoreOS、Kuberenetes主导的CNI。首先明确一点,CNM和CNI并不是网络实现,他们是网络规范和网络体系,从研发的角度他们就是一堆接口,你底层是用Flannel也好、用Calico也好,他们并不关心,CNM和CNI关心的是网络管理的问题。

CNM(Docker LibnetworkContainer Network Model)

Docker Libnetwork的优势就是原生,而且和Docker容器生命周期结合紧密;缺点也可以理解为是原生,被Docker“绑架”。
  • Docker Swarm overlay
  • Macvlan & IP networkdrivers
  • Calico
  • Contiv
  • Weave

CNI(Container NetworkInterface)

CNI的优势是兼容其他容器技术(e.g. rkt)及上层编排系统(Kubernetes & Mesos),而且社区活跃势头迅猛,Kubernetes加上CoreOS主推;缺点是非Docker原生。
  • Kubernetes
  • Weave
  • Macvlan
  • Calico
  • Flannel
  • Contiv
  • Mesos CNI

4、Flannel容器网络

Flannel之所以可以搭建kubernets依赖的底层网络,是因为它可以实现以下两点:
  • 它给每个node上的docker容器分配相互不想冲突的IP地址;
  • 它能给这些IP地址之间建立一个覆盖网络,同过覆盖网络,将数据包原封不动的传递到目标容器内。

Flannel介绍
  • Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务,简单来说,它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。
  • 在默认的Docker配置中,每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是,不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到,也就是相互ping通。
  • Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则,从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址,并让属于不同节点上的容器能够直接通过内网IP通信。
  • Flannel实质上是一种“覆盖网络(overlaynetwork)”,也就是将TCP数据包装在另一种网络包里面进行路由转发和通信,目前已经支持UDP、VXLAN、host-gw、aws-vpc、GCE和Alloc路由等数据转发方式,默认的节点间数据通信方式是UDP转发。

11.png

5、Calico容器网络

Calico介绍
  • Calico是一个纯3层的数据中心网络方案,而且无缝集成像OpenStack这种IaaS云架构,能够提供可控的VM、容器、裸机之间的IP通信。Calico不使用重叠网络比如Flannel和Libnetwork重叠网络驱动,它是一个纯三层的方法,使用虚拟路由代替虚拟交换,每一台虚拟路由通过BGP协议传播可达信息(路由)到剩余数据中心。
  • Calico在每一个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发,而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息像整个Calico网络内传播——小规模部署可以直接互联,大规模下可通过指定的BGP route reflector来完成。
  • Calico节点组网可以直接利用数据中心的网络结构(无论是L2或者L3),不需要额外的NAT,隧道或者Overlay Network。
  • Calico基于iptables还提供了丰富而灵活的网络Policy,保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。

Calico架构图:
12.png

13.png

五、网络开源组件性能对比分析

性能对比分析:
14.png

性能对比总结:

CalicoBGP方案最好,不能用BGP也可以考虑Calico ipip tunnel方案;如果是CoreOS系又能开UDP Offload,Flannel是不错的选择;Docker原生Overlay还有很多需要改进的地方。
15.png

Q&A

Q:A的Pod如何连接B的Pod? kube-dns起到什么作用? kube-dns如果调用kube-proxy?
A:这里说的A和B应当是指Service,A Service中Pod与B Service Pod之间的通信,可以在其容器的环境变量中定义Service IP或是Service Name来实现;由于Service IP提前不知道,使用引入kube-dns做服务发现,它的作用就是监听Service变化并更新DNS,即Pod通过服务名称可以查询DNS;kube-proxy是一个简单的网络代理和负载均衡器,它的作用主要是负责service的实现,具体来说,就是实现了内部从Pod到Service和外部的从NodePort向Service的访问,可以说kube-dns和kube-proxy都是为Service服务的。
Q:网络问题docker default是网桥模式(NAT) 如果用路由的模式,所以Pod的网关都会是docker 0 IP ? 那Pod 1与Pod 2之间也走路由 ,这会使路由表很大? Flannel 网络是不是可以把所有的Node上,相当于一个分布式交换机?
A:Docker实现跨主机通信可以通过桥接和路由的方式,桥接的方式是将docker0桥接在主机的网卡上,而路由直接通过主机网口转发出去;Kubernetes网络有Pod和Server,Pod网络实现的方式很多,可以参考CNI网络模型,Flannel实质上是一种“覆盖网络(Overlay Network)”,也就是将TCP数据包装在另一种网络包里面进行路由转发和通信。
Q:大规模容器集群如何保证安全? 主要从几个方面考虑?
A:一个大规模容器集群从安全性考虑来讲,可以分为几个方面:1、集群安全,包括集群高可用;2、访问安全,包括认证、授权、访问控制等;3、资源隔离,包括多租户等;4、网络安全,包括网络隔离、流量控制等;5、镜像安全,包括容器漏洞等;6、容器安全,包括端口暴露、privileged权限等。
Q:SVC如何进行客户端分流,A网段的访问Pod1 ,B网段的访问Pod2,C网段的访问Pod3,3个Pod都在SVC的Endpoint中?
A:内部从Pod到Service的实现是由kube-proxy(简单的网络代理和负载均衡器)来完成,kube-proxy默认采用轮询方法进行分配,也可以通过将service.spec.sessionAffinity设置为“ClientIP”(默认为“无”)来选择基于客户端IP的会话关联,目前还不能进行网段的指定。
Q:对于Ingress+HAProxy这种实现Service负载均衡的方式,Ingress controller轮询Service后面的Pods状态,并重新生成HAProxy配置文件,然后重启HAProxy,从而达到服务发现的目的。这种原理对于HAProxy来讲是不是服务会暂时间断。有没有好的替代方案?之前看到Golang实现的Træfik,可无缝对接Kubernetes,同时不需要Ingress了。方案可行么?
A:由于微服务架构以及Docker技术和Kubernetes编排工具最近几年才开始逐渐流行,所以一开始的反向代理服务器比如Nginx/HAProxy并未提供其支持,毕竟他们也不是先知,所以才会出现IngressController这种东西来做Kubernetes和前端负载均衡器如Nginx/HAProxy之间做衔接,即Ingress Controller的存在就是为了能跟Kubernetes交互,又能写 Nginx/HAProxy配置,还能 reload 它,这是一种折中方案;而最近开始出现的Traefik天生就是提供了对Kubernetes的支持,也就是说Traefik本身就能跟Kubernetes API交互,感知后端变化,因此在使用Traefik时就不需要Ingress Controller,此方案当然可行。
Q:1、一个POD里面的多个Container是同一个Service的?还是由不同的Service的组成? 是啥样的分配逻辑? 2、Flannel 是实现多个宿主机上的N多的Service以及Pod里面的各个Container的IP的唯一性么? 3、Kubernetes具备负载均衡的效果 。那是否就不用在考虑Nigix?
A:Pod是Kubernetes的基本操作单元,Pod包含一个或者多个相关的容器,Pod可以认为是容器的一种延伸扩展,一个Pod也是一个隔离体,而Pod内部包含的一组容器又是共享的(包括PID、Network、IPC、UTS);Service是Pod的路由代理抽象,能解决Pod之间的服务发现问题;Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则,从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址,并让属于不同节点上的容器能够直接通过内网IP通信;Kubernetes kube-proxy实现的是内部L4层轮询机制的负载均衡,要支持L4、L7负载均衡,Kubernetes也提供了Ingress组件,通过反向代理负载均衡器(Nginx/HAProxy)+Ingress Controller+Ingress可以实现对外服务暴露,另外使用Traefik方案来实现Service的负载均衡也是一种不错的选择。
Q:kube-proxy是怎样进行负载? Service虚拟IP存在哪里?
A:kube-proxy有2个模式实现负载均衡,一种是userspace,通过Iptables重定向到kube-proxy对应的端口上,然后由kube-proxy进一步把数据发送到其中的一个Pod上,另一种是Iptables,纯采用Iptables来实现负载均衡,kube-proxy默认采用轮询方法进行分配,也可以通过将service.spec.sessionAffinity设置为“ClientIP”(默认为“无”)来选择基于客户端IP的会话关联;Service Cluster IP它是一个虚拟IP,是由kube-proxy使用Iptables规则重新定向到其本地端口,再均衡到后端Pod的,通过 apiserver的启动参数--service-cluster-ip-range来设置,由kubernetes集群内部维护。
Q:Kubernetes网络复杂,如果要实现远程调试,该怎么做,端口映射的方式会有什么样的隐患?
A:Kubernetes网络这块采用的是CNI规范,网络插件化,非常灵活,不同的网络插件调试的方法也是不一样的;端口映射方式的最大隐患就是很容易造成端口冲突。
Q:RPC的服务注册,把本机IP注册到注册中心,如果在容器里面会注册那个虚拟IP,集群外面没法调用,有什么好的解决方案吗?
A:Kubernetes Service到Pod的通信是由kube-proxy代理分发,而Pod中容器的通信是通过端口,不同Service间通信可以通过DNS,不一定要使用虚拟IP。
Q:我现在才用的是CoreOS作为底层,所以网络采用的是Flannel 但是上层用Calico作为Network Policy,最近有一个Canal的结构和这个比较类似,能介绍一下么,可以的话,能详细介绍一下CNI原理和Callico的Policy实现么?
A:Canal不是很了解;CNI并不是网络实现,它是网络规范和网络体系,从研发的角度它就是一堆接口,关心的是网络管理的问题,CNI的实现依赖于两种Plugin,一种是CNI Plugin负责将容器connect/disconnect到host中的vbridge/vswitch,另一种是IPAM Plugin负责配置容器Namespace中的网络参数;Calico 的policy是基于Iptables,保证通过各个节点上的 ACLs 来提供workload 的多租户隔离、安全组以及其他可达性限制等功能。
Q:CNI是怎么管理网络的?或者说它跟网络方案之间是怎么配合的?
A:CNI并不是网络实现,它是网络规范和网络体系,从研发的角度它就是一堆接口,你底层是用Flannel也好、用Calico也好,它并不关心,它关心的是网络管理的问题,CNI的实现依赖于两种plugin,一种是CNI Plugin负责将容器connect/disconnect到host中的vbridge/vswitch,另一种是IPAM Plugin负责配置容器Namespace中的网络参数。
Q:Service是个实体组件么?那些个Service配置文件,什么部件来执行呢?
A:Services是Kubernetes的基本操作单元,是真实应用服务的抽象,Service IP范围在配置kube-apiserver服务的时候通过--service-cluster-ip-range参数指定,由Kubernetes集群自身维护。
以上内容根据2017年5月18日晚微信群分享内容整理。分享人 阳运生,有容云产品经理。有着多年的系统、存储、网络、虚拟化、容器等云计算技术相关的工作经验,现主要负责容器平台(Rancher /Kubernetes)及其相关存储、网络、安全、日志、监控等解决方案工作 。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

本文来源:http://www.youruncloud.com/blog/131.html

原文发布时间为:2017-06-02

本文作者:阳运生

本文来自云栖社区合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。

原文标题:DockOne微信分享(一二二):探索Kubernetes的网络原理及方案

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
21天前
|
安全 虚拟化
在数字化时代,网络项目的重要性日益凸显。本文从前期准备、方案内容和注意事项三个方面,详细解析了如何撰写一个优质高效的网络项目实施方案,帮助企业和用户实现更好的体验和竞争力
在数字化时代,网络项目的重要性日益凸显。本文从前期准备、方案内容和注意事项三个方面,详细解析了如何撰写一个优质高效的网络项目实施方案,帮助企业和用户实现更好的体验和竞争力。通过具体案例,展示了方案的制定和实施过程,强调了目标明确、技术先进、计划周密、风险可控和预算合理的重要性。
40 5
|
2月前
|
安全 网络架构
MPLS线路构建稳定、高效网络的优选方案
【10月更文挑战第17天】MPLS线路构建稳定、高效网络的优选方案
58 5
|
2月前
|
网络协议 安全 5G
网络与通信原理
【10月更文挑战第14天】网络与通信原理涉及众多方面的知识,从信号处理到网络协议,从有线通信到无线通信,从差错控制到通信安全等。深入理解这些原理对于设计、构建和维护各种通信系统至关重要。随着技术的不断发展,网络与通信原理也在不断演进和完善,为我们的生活和工作带来了更多的便利和创新。
66 3
|
3月前
|
并行计算 安全 网络协议
探索未来网络:量子互联网的原理与应用
本文深入探讨了量子互联网的基本概念、技术原理及其潜在应用。通过对量子纠缠、量子叠加和量子隐形传态等核心概念的解释,文章展示了量子互联网如何利用量子力学特性来实现超高速、超高安全性的通信。此外,还讨论了量子互联网在金融、医疗、国防等领域的应用前景,以及当前面临的技术挑战和未来的发展方向。
77 2
|
24天前
|
运维 物联网 网络虚拟化
网络功能虚拟化(NFV):定义、原理及应用前景
网络功能虚拟化(NFV):定义、原理及应用前景
41 3
|
1月前
|
网络协议 安全 算法
网络空间安全之一个WH的超前沿全栈技术深入学习之路(9):WireShark 简介和抓包原理及实战过程一条龙全线分析——就怕你学成黑客啦!
实战:WireShark 抓包及快速定位数据包技巧、使用 WireShark 对常用协议抓包并分析原理 、WireShark 抓包解决服务器被黑上不了网等具体操作详解步骤;精典图示举例说明、注意点及常见报错问题所对应的解决方法IKUN和I原们你这要是学不会我直接退出江湖;好吧!!!
网络空间安全之一个WH的超前沿全栈技术深入学习之路(9):WireShark 简介和抓包原理及实战过程一条龙全线分析——就怕你学成黑客啦!
|
2月前
|
机器学习/深度学习 人工智能 监控
深入理解深度学习中的卷积神经网络(CNN):从原理到实践
【10月更文挑战第14天】深入理解深度学习中的卷积神经网络(CNN):从原理到实践
150 1
|
2月前
|
运维 监控 安全
连锁药店网络优化策略:一站式融合方案提升竞争力
在数字化浪潮下,线上药店通过技术创新和线上线下融合,正重塑购药体验,提供24小时服务和医保结算便利。面对激烈竞争,连锁药店和中小药店纷纷通过优化网络架构、提升服务质量和加强合规管理来增强竞争力,实现高效、安全的数字化转型。
|
2月前
|
网络协议 Linux 应用服务中间件
Socket通信之网络协议基本原理
【10月更文挑战第10天】网络协议定义了机器间通信的标准格式,确保信息准确无损地传输。主要分为两种模型:OSI七层模型与TCP/IP模型。
|
2月前
|
Kubernetes 网络协议 网络安全
k8s中网络连接问题
【10月更文挑战第3天】
170 7

推荐镜像

更多