SDN实战团分享(三十一):Segment Routing meet SDN

一、介绍

在1990年代Yakov, Eric Rosen, Kompella很多业界先驱(仅列举了Juniper公司的MPLS业界领袖,其他公司也有 很多Fellow推动MPLS发展)的引入MPLS之后,作为一个业务传送协议,MPLS取得了极大的成功。MPLS发展出很多不同的协议,简单的LDP/RSVP-TE,组播等,承载各种VPN业务,结合各种OAM功能,甚至扩展到光传输领域。

为什么我们需要一个新的IETF协议来指挥MPLS转发呢? 下面会介绍一下这个名叫『春天』的IETF工作组。Source Packet Routing in Networking 简称为SPRING,也有叫做Segment Routing(段式路由),我们下文一般称为SR。

在介绍SR之前,我们先来看一下SDN2.0.

2008年左右提出的Openflow促进了第一代SDN的热潮,大家都想用Openflow(ACL)去控制网络中的应用流量。Openflow在数据中心领域取得了一定的成功。 扩展到广域网和运营商网络时有了一些Hyberid SDN的部署,也遇到了重重的困难。

其中一个重要问题是Openflow对网络抽象不够,网络核心设备中网络状态信息随着应用数目的成指数增长。无法在广域网中得到大规模的部署。并且Openflow控制的网络,往往需要控制器控制路径中的多个关键设备,网络中的Touch Point增多,导致运维困难,信令压力增大。

采用SR来作为传输协议的时候,SDN控制器仅仅需要跟Ingress PE通讯,在Source路由器上已经通过携带多个标签,定义好了完整的路径信息。网络中的Touch Point仅有一个,就能影响到这个应用APP流量的转发。同时网络核心设备中网络状态信息完全跟承载的应用业务无关。采用SR

的运营商可以轻松的为百万级别的应用在头端(source)路由器选用不同的路径,同时保持核心设备没有任何应用状态。(Edge Intelligence, Stateless Core)。

二、SR协议介绍

SR的基本概念类似Lego,把网络分为不同的段(Segment),然后拼接起来。首先把网络分为三中基本组件。

◆ 邻接段(Adj-SID),连接另一个路由器邻居,local有效。

◆ 节点段(Node SID),指示如何到达另一个本地/远端(local/Remote) 路由器

◆ 网段(Prefix SID),指示如何到达一个IP prefix.

在头节点(Ingress Router)就用这不同的组件来组织一个完整的LSP Path。为了避免各个厂家设备采用不同的标签块,SR借鉴了传统的K.Kompella提出的BGP VPLS的基本概念。每个路由器宣告一个SRGB(SR Global Block全局块),在同一个区域(Domain AS/Area)中的每个路由器有个唯一的Index。

以ISIS扩展的SR为例,每个路由器都可能会宣告这三种基本的SID(还有一些其他类型的SID,比如Anycast SID等)。

每个路由器会计算SPF路径树,来构建节点段(Node SID)的一个完整路由器互联的拓扑(跟传统ISIS一样)。

SR路由器继承了MPLS的转发平面,仅仅是优化了控制平面。采用IGP/BGP来分发标签,取消了之前的LDP/RSVP-TE。

第一步,建立拓扑:下面介绍SR网络关键的第一步,如何建立转发表和拓扑关系。

在一个支持SR的路由器里面,MPLS转发表会包含Node SID,Adj-SID 等(Prefix SID没有在图中显示)

Node SID表:如果路由器都采用相同的SRGB,对于任何一个远端路由器在转发表中会有一个独特的In/Out label 完全相同,也就是说Label SWAP操作之后还是相同的标签。每个标签代表唯一的一个节点。如果是相邻节点的Node,会有POP操作。

Adj SID表: 这个转发表也只有POP操作,所有收到的Adj label最后都被POP出来。

总结一下,SR的转发表,如果是相邻的Node/Adj会被POP弹出标签栈。所有的Node/Adj/Anycast/Prefix SID 都是IGP扩展来宣告给其他的路由器。每个路由器收到Node SID进行SPF计算,计算出一个树型MPLS转发表(跟正常OSPF/ISIS计算出来的拓扑一样),路由器收到Adj SID信息直接产生Adj POP操作。

第二步在基础IGP转发拓扑之上,控制器或者VPN等应用会来构建一个LSP Path,还记得前面提到,路由器收到Adj SID/相邻的Node SID label会POP出来,移掉最外层的标签。在图中的例子里面,如果在Node 11上加上4个 Adj Node SID,在1/7/4/14节点都会移除最外层的标签。最后把Payload发送到Node14节点上。同样你也可以在头端路由器压上Adj SID标签,这样每个接口转发之后移除一个标签。

上述过程可以想象为一个行李标签,比如我定了个机票:新加坡到洛杉矶,我买了个复杂的机票:11(新加坡)-1(香港)-7(北京)-4(旧金山)-14(洛杉矶)在新加坡时候我checkin行李,会拿到香港-北京-旧金山-洛杉矶行李Tag,行李托运之后,在中转的每个城市取下一个行李Tag,最后行李安全到达洛杉矶。在每个城市,仅仅根据最外层的Tag转发到下个城市。在头结点(source)行李的路径已经确定。

当然SR可以压多个标签栈,也可以类似RSVP-TE/LDP似的仅仅采用一个标签也可以Follow IGP达到终点。比如右边的图,可以采用标签114顺利到达节点14,中间的每个路由器都收到label114,然后转发出label114,继续下个节点,直到节点14pop。

上图可以看出来,SR转发可以采用不同的混合机制,灵活的采用标签栈来指导每一跳的转发,也可以根据IGP路径采用一个标签来跨越一个很大的网络。也可以添加各种流量工程的策略,来进行ECMP转发或者避免哪些SRLG来转发。

2.1 采用Anycast进行节点保护

接下来介绍一个非常好用的功能,Anycast节点保护。

传统的MC-LAG和Virtual Chassis功能作为节电保护,总是存在各种问题,多厂家无法互通,两个设备同样版本,设备间交换私有信息无法进行ISSU,无法多个设备备份,上下行流量保护问题等等。

SR推出了一个全新的功能Anycast SID能有效的解决这个问题。你可以选用一组设备2+,每个路由器在发布正常的Node SID的同时,还发布相同的Anycast SID。这样在R1节点收到5100的标签时,R1就会发送给4个路由器中的任意一个(outlabel 8100)。假设A1收到8100,会Pop出来8100,A3看到8070。A3就转发给R2(keep8070)。R2收到8070之后会POP,剩下Payload转发。假设A1节点失效,R1会发送给A2/A3然后发送8070到R2。

Anycast SID适用于任何拓扑,环形/Hub&Spoke etc.也适用于ABR/ASBR保护,同时适用于Seamless MPLS(后续会继续讲解)。

2.2 100% TI-LFA节点/Link保护

SR的另一大优点是可以提供针对任何拓扑100%的FRR保护。

大家知道LFA和Remote LFA都只能覆盖80-90%的拓扑,针对复杂的环形网络无法提供100%的拓扑情景的支持。

针对这种场景,Juniper最早提出了TI-FRR的解决方案。采用Target LDP和RSVP-TE结合的方式,可以做到100%拓扑的50ms快速重路由。

解决的思路是计算PQ节点集合。P节点集合:从E1出发,可以达到的节点集合,不需要经过中断路径。比如{E2,E3}是P节点集合。从E1出发到E4就可能经过中断路径。

Q节点集合:到达C1的节点中,不需要经过终端路径的节点,以C1为根计算的反向生成树,{E4,C2}是Q节点集合。

如果采用普通的R-LFA,PQ集合没有交集,也就是说R-LFA就不能保护这个拓扑。采用TI-FRR需要直接在E1到Q节点创建一个RSVP-TE Tunnel,这样被保护的流量就没有microloop回来,到达E4之后采用Target LDP session来确保流量流向C1。从而TI-LFA可以做到100%的拓扑保护。

采用SR的保护机制不太一样,在disjoint PQ集合里面,首先利用Node SID选择P(E3)节点,然后压上Adj标签(E3-E4),也就是告诉流量首先发送到E3,正常情况下有可能会回流到E1-C1链路。这时候SR要求流量到了E3之后,继续转发给E4。也就是两个label,两个动作确保了100% FRR.

2.3 利用Binding SID扩展网络规模

采用SR的一个很重要的顾虑是硬件能压几个标签?比如B厂商的商业芯片一次只能压三个标签,可能通过recircle来压多个标签但是会带来性能的损耗,同时带来其他问题。

为了让SR可以在各种场合适用(比如运营商汇聚),SR开发了Binding SID。 通过IGP/BGP来发布一条SR-LSP(从R22到R30,标签栈为{332|331|330})的标签,假设这条SR-LSP的标签为510.在R21处只需压入两个标签{22|510},当R22收到22时pop标签22,露出来510,R22会把510去掉,同时压入3个标签{332|331|330},这样报文最后会抵达R30。

通过Binding SID也可以实现RSVP-TE/LDP和SR的互通。还有LDP mapping Server等具体的办法就不详细介绍了。

2.4 基于PCEP/BGP-LS的SDN控制器

最早利用SR来支持SDN的想法来自于PCEP/RSVP-TE类似的做法。在控制器端计算完整的流量工程路径,然后把路径列表通过PCE带给路由器上的Client端(类似RSVP-TE ERO)。非常类似RSVP-TE,好处也明显,不需要沿途的路由器发任何信令去建立LSP(RSVP需要发送 Path/Reserve message)。

首先介绍一下SDN控制器来使用PCEP建立SR-TE tunnel。

非常类似RSVP-TE的PCEP LSP建立过程。控制器的PCEP会通知路由器上的PCC来协调能力,同时采用类似SR-ERO的方式来携带Label Stack,PE收到PCCreate LSP消息之后,不需要像RSVP-TE那样在多个路由器之间传递PATH/Reserve信令消息,仅仅需要下发label 堆栈信息。同时LSP创建的状态汇报通过SR-RRO来传递回去控制器。

采用BGP-LS来传递TEDB,并携带SR label信息送回控制器。

对于VPN业务的映射,可以采用PE-CE之间的Openflow/PBR/QPPB/BGP Flowspec 等。

可以参考Juniper的SDN控制器North Star可以动态的建立SR TE-LSP,并且观测每个链路, LSP的标签信息。同时根据流量分布,可以动态优化SR LSP。

2.5 SR和传统LDP/RSVP-TE的对比

简单的对比一下SR和LDP/RSVP-TE。

首先网络中间节点只需保留很少的网络状态,SR甚至不需要理解网络中的远端状态信息。比如节点3,不需要任何关于link 11-1, 6-7的Non-adj转发信息(而这些信息在LDP里面是存在的)。SR的基础转发表甚至比LDP更简洁。当然比RSVP-TE状态少很多。同时不需要LDP/RSVP信令来建立LSP, ingress node上出现不同的Label Stack组合,马上代表不同的路径选择。

这张图比较了传统MPLS(RSVP-TE/LDP)和SR的多种情况,控制协议,流量工程,FRR,inter-AS/Area,扩展性, OAM,和SDN集成角度,SR有一定的优势。

三、SDN的应用场景

介绍SR的各种SDN应用场景之前,我先来介绍一下云计算如何来无缝对接SR,实现云网合一。

先看传统的Underlay网络,由路由器,交换机,防火墙等组成,连接方式很固定,一旦配置了之后大概半年/一年都不会进行更改。 采用Ansible/Puppet进行配置管理之后,可能需要进行一系列的检测和排错。总之网络比较稳定,运维简单。

但是新的云运营模式,需要全网转去DevOps模式才能适应云计算。

DevOps能帮助客户在物理网络之上创建一个虚拟化的网络。APP/Dockers/VM能够更快的部署在全球网络上,并采用Scale Out的方式实现海量客户的接入,更灵活的做网络的变更。Overlay网络管理的不再是物理的设备,需要管理海量的虚拟路由器(vRouter),OVS,VNF (LB/FW/DPI)等。怎么去维护管理这个虚拟化的网络,需要一个SDN控制器帮忙。

越来越多的客户采用SDN控制器来进行DC内部Service Chaining和跨DCI的选路。

如果在underlay网络中部署SR,云服务就可以通过BGP-LU/PCEP/Netconf等协议来对Source节点进行编程,可以选择DC里面的Leaf/Spine路径,也可以选择DCI的SR-TE LSP来进行跨DCI的流量工程调度。

SR标签可以包含:{APP|Docker|VM|Server }映射关系,还可以包含NFV label进行Service Chaining,还可以包含VPN Label,进行VPN隔离,同时还可以包含Label Stack穿越广域网。采用不同的label组合,在增加任何影响underlay核心路由器转发表的情况下,可以支持百万级别的应用。

关于SR的应用场景,我们看到越来越多的客户选择四个不同的场景来部署SR,比如

数据中心,拓扑比较简单,EBGP来作为IGP协议,同时采用同一厂商的设备,统一的SRGB来管理大规模数据中心。

广域网在核心/边缘路由器上部署SR, FRR特性,同时减少Core Router的状态,采用BGP-LS来上送Controller网络的标签状态。采用BGP-LU,FlowSpec来控制流量 承载在不同的SR LSP。

城域网在汇聚路由器,移动回传的网络中,采用环形网络,利用SR的100%拓扑,采用Binding SID来跨越多个Area/AS,并且采用PW来进行业务的承载,简化Cell Site设备协议,取代传统的Seamless MPLS。

下面详细介绍一下各个Use Cases:

3.1 SR在超大规模数据中心的应用

在介绍数据中心应用场景之前,先介绍一种新型的BGP控制器来建立SR-TE LSP的解决方案。

BGP-LU(RFC3107)在业界有多年成功部署应用,大部分厂商设备都支持BGP-LU,包括Metro里面的很多小型Cell Site路由器。

传统的BGP-LU仅仅能够携带一个标签,Juniper的设备扩展了RFC3107,可以在控制器和设备之间传递多个标签栈。

这里我们采用了非常简化的ExaBGP(Github免费BGP,https://github.com/Exa-Networks/exabgp)安装在笔记本电脑上,并且跟路由器建立简单的BGP-LU session。ExaBGP Controller来发送一个BGP 消息给PE1,这个BGP-LU消息携带四个标签栈。可以指导PE1创建不同的SR LSP转发表项。

同时如果采用QPPB/BGP FlowSpec 来映射PE-CE之间的流量到BGP-LU创建的SR LSP上,就只需一个BGP协议,SDN控制器和路由器就能协商业务流的控制。

现代大规模数据中心设计,Underlay刚刚经历了VLAN到VXLAN的演进,很多客户会问,为什么要在DC引入MPLS,为什么要引入SR?引入SR的几个主要的优点如下:

1.越来越多的Overlay采用MPLS,比如Contrail采用MPLSoGRE,MPLSoUDP, EVPN+MPLS等协议。在广域网和DC采用相同的MPLS协议,带来的运维好处显而易见。比如DC GW不需要在VXLAN和MPLS之间进行协议转换(避免性能可能下降)

2.同时由于Telco Cloud,越来越多的NFV采用MPLS VPN协议隔离。

3.可以更好的指导Elephant Flow转发,避免ECMP Hash时候Elephant Flow和Mice Flow竞争同样的资源。

4.可以更好的进行故障隔离,传统TCP Flowlet把网络变为黑盒,拥塞之后就会调低传送速率。如果能够理解网络中拥塞,不需要降低传送速率,仅仅需要重路由到非拥塞链路,会极大的提高App的传送质量。

经典的超大规模DC设计,取消IGP(避免网络链路震荡,路由重算)构建基于BGP 的数据中心。请参考Juniper 白皮书, EVPN IP CLOS for Next Gen DC

在超大规模数据中心里引入SR,是一个比较热门的话题。draft-ietf-spring-segment-routing-msdc在持续讨。草案里面定义的是基础Leaf/Spine架构如何用BGP-LU+SR来构建。我们这里来介绍一下端到端的VM/Docker是如何通讯的。

◆ Leaf 跟控制器建立BGP-LU(3107)session,传递vRouter Prefix SID的标签信息

◆ Leaf/Spine建立BGP-LU session,传递Leaf labels, Spine不需要跟控制器建立session。

◆ 控制器创建VM/Dockers时,在vRouter上给分配标签,通过BGP/XMPP上送到控制器

◆ 在Ingress vRouter上压入三层标签栈,就可以找到egress (TOR,vRouter, VM)

有了这套完整的SDN 控制器体系,配合广域网SDN控制器,可以很扩展到DC互联。在DC互联中,可以采用的技术有如下:

◆ SR可以很容易的利用Node SID来实现ECMP,可以利用Adj SID去精确指导选用哪条Link。

◆ 可以利用SR的Anycast SID去保护DC GW和广域网路由器

◆ 在图中例子可见在Ingress vRouter标签栈依次为:{ DC1 | DCI A-B-C | DC2 | DC2 vRouter | DC2 VM}, 需要说明的是,即便可能压入8-10+个标签,报文头还是比VXLAN(60-70 bytes)小。

3.2 基于SR 的Cloud Peering应用

传统的流量工程仅仅 关注在IGP域部分,越来越多的企业迁移到云服务。如何找到没有拥塞的BGP Peering提高网络云接入能力?基于SR的BGP EPE能提供一个更好的解决方案。

◆ ASBR通过BGP-LU(3107)跟控制器建立BGP邻居,并且给每个Peer分配一个标签。

◆ ASBR通过BGP-LS, Netflow, Telemtry把流量信息上送到控制器。

◆ 控制器计算最优路径(latency/bandwidth/optical SRLG etc)

◆ 控制器在头结点压上多个标签,外层SR标签找到ASBR,内层BGP-LU标签找到Peering,外层隧道也可以采用GRE/LDP等。

在BGP EPE转发路径上有个比较特殊的属性,从AS内部到peer的转发,不需要查询路由表,仅仅需要MPLS转发。利用这个特性可以采用新型态的LSR /Lean Core设备做Internet Peering。

完整的看一下数据中心和WAN的统一控制器,可以控制从数据中心服务器发出的流量,选择不同的ASBR,不同的BGP Peering,从而避免拥塞。 从Internet进入到数据中心的流量,控制器可以监测VM/Dockers的运行状态,从而在ASBR开始压上不同的VM标签,数据流量可以根据VM/Docker分发的不同标签来进行负载均衡。

3.3 基于SR 的下一代接入网

对于运营商来讲如何降低接入网的成本,是一个首要问题。对于采用SR的cell site 路由器,可以实现最小的协议支持,同时承载各种VPN业务。网络的传输部分简化为ISIS协议,网络的业务部分采用BGP承载VPN,甚至采用BGP FlowSpec来映射客户流量。减少Cell Site Router的协议复杂度,就会增加网络可靠性,可维护性。

主流厂商多年前就已经支持Seamless MPLS(UMMT)的Mobile Backhaul解决方案。方案采用RSVP-TE做接入环网的保护,BGP-LU为多个区域粘接在一起,提供端到端的LSP隧道。加上VPN标签,和FRR标签,需要4个标签(经常导致B厂商的商业芯片无法只支持三个标签)。

如果采用SR,可以利用协议简化机制,利用100% FRR保护,利用Anycast SID保护汇聚节点,利用Binding SID在汇聚设备扩展SR LSP跳数。

SDN最早起始于数据中心,就是因为要管理很多TOR和Server。很多客户有上千台Cell Site路由器的规模,引入SDN控制器,并且采用ZTP自动部署SR。越来越被主流运营商接受,成为运营商采用SR的一大驱动力。

3.4 基于SR的Telco Cloud

传统运营商建网思路是以连接性为目的,买路由器,传输设备,提供管道,连通性。网络架构基本不具备智能。

随着5G,虚拟现实,IOT,HealthCare等业务越来越多的业务承载在运营商的网络上。低延时,大带宽,大规模业务,需要运营商建设更多的Micro Data Center,更加靠近客户和应用。驱动运营商的网络从传统的连通(PIPE)导向的建设思路,转型到建设运营商云服务平台(Telco Cloud) 上来。

为了应对新业务的出现,很多业界运营商转变思路借鉴了许多OTT的建网思路实现以超小(Micro),Ultra Low Latency数据中心为网络建设的重点。比如为应对VR/Health Care/自动驾驶等业务的低延时,大数据量应用(自动驾驶汽车需要视频识别,可能每秒钟产生1Gbps的流量),必须要建设全分布式,超小型数据中心更加靠近终端用户 。

把数据中心DC Fabric网络架构应用到城域网,建设很多SP Fabric,通过SR无缝连接起来称为Telco Cloud架构的基础。

典型的Telco Cloud在SP汇聚层会采用BGP-SR添加很多小型数据中心。在SP数据中心中Leaf节点有不同的工作职责:

◆ A-Leaf用来接入用户,比如ONU,Wifi,BNG客户等

◆ C-Leaf用来接服务器,用来虚拟化vEPC,vFW,vDPI, vOLT, vBNG 等

◆ P-Leaf用长距光模块做互联。

采用BGP-SR在SP Fabric,Metro利用OSPF SR,提供端到端的SR LSP,业务采用EVPN承载。

3.5 基于SR的网络虚拟化NFV Service Chaining

网络虚拟化也是运营商最热门的话题。网络分块(Network Slicing)和业务链(Service Chaining)也越来越重要。Service chaining表现出新的趋势:

◆ 不光局限于骨干网DC,往往分布在Front Haul的Micro DC(小微),在城域网BNG附近的中型 DC,和国家骨干网DC分别处理不同的虚拟化业务。

◆ Service Chaining可能无法在一个数据中心处理完毕,需要在城域范围内跨越多个DC。

业界有厂商引入特定的NSH(network service header)头来支持业务链,但是采用专用报文头可能会带来两个问题,很多VNF(比如vFW, vEPC etc)不支持NSH,大部分硬件交换机无法支持NSH。

由于SR可以指定访问网络中的任何节点(通过多层标签栈),同时大部分的虚拟设备和物理设备都可以支持MPLS转发平面,所以很多客户想要采用SR来支持Service Chaining。

四、总结

前面介绍了很多SR的应用场景,作为一个underlay技术,SR可以广泛应用在网络的CPE/Access/Edge/Core/DC里,同时更好的支持SDN/NFV.

最早美国的很多Web/OTT公司Google, Microsoft非常感兴趣SR。还有一些欧洲美国的TOP SP,ATT/Comcast等,最近在亚太区,中国的OTT,日本Softbank/NTT/KDDI,加上澳洲的Telstra都很感兴趣,SR在2017会有更多的客户采用,部署。

最后,分享一下最近的SDN/NFV感想。

最早SDN起源于数据中心的Openflow,目标是通过动态配置管理上千台TOR/Server,建立连通性。数据中心基于简单拓扑,物理冗余性,交换机功能简单,网络超配, SDN Controller不大需要关心网络资源,流量状况。Automation(自动化)称为SDN控制器的最主要特性。

随着SDN影响越来越大,SDWAN, WAN SDN, Cloud SDN需要 SDN/NFV控制器来更好的理解流量和资源分配状况,这时候需要通过Openconfig/gRPC 搜集Telemetry 信息,上送控制器。原始的信息很难被控制器理解,越来越多厂家在SDN控制器之上加入机器学习,人工智能部分,更好的指导控制器进行网络自动化。

举个例子,Juniper最新Appformix解决方案,用来优化Openstack云部署环境,采用了机器学习,当部署新的VM/Docker时,Appformix注意到,尽管某个Server的CPU负载很低(只有20%)但是那些L3 Cache资源已经不足,Appformix会进行迁移把现有的VM移到L3 Cache充足的Server。当有个新的VM/Docker部署要求时,最简单的就是给他分配一个新的Server,但是新的VM/Docker也许和现有的一个VM有很多交互,share相同的资源,如果把新的VM/Docker部署在现有的Server上,而不是每次都分配新的server,可能整个应用更流畅。

从上面的例子可以看出来,现有的SDN控制器仅仅是算是机械手,引入人工智能,引入Telemetry更好的理解网络。形成一个闭环的SDN自愈合控制系统。

前面讲到的各种SR的网络优点,可以看出来采用了SR的智能边缘,无状态核心设备的网络基础架构,不但理解Underlay网络架构,同时理解Overlay云端应用,促进云网融合,会成为今后SDN/NFV发展的坚实基础。

原文发布于微信公众号 - SDNLAB(SDNLAB)

原文发表时间:2017-03-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏编程一生

IO和socket编程

1243
来自专栏程序人生

停下来,歇口气,造轮子

上周四至今,我大概有 50-70% 的时间在造一个轮子,一个叫 merlin 的工具。 事情的起源是这样的 —— 我们内部的一个重要服务,要升级到 elixir...

36116
来自专栏北京马哥教育

SDN有哪些开源项目?

SDN 之所以能够发展的如此之快,其中开源社区的贡献不容忽视。随着SDN 各类社区的不断发展状大,开源项目也在不断增多,从控制器到交换机再到网络虚拟化,开源...

3798
来自专栏待你如初见

相关资源

2701
来自专栏linux驱动个人学习

SMBus与I2C的差别

1462
来自专栏java一日一条

Android开发者必知的开发资源

随着Android平台市场份额的持续猛增 ,越来越多的开发者开始投入Android应用程序的开发大潮。如果您是一位2016年刚刚入行的Android开发新兵,恭...

1922
来自专栏轮子工厂

Linux系统的前世今生

上世纪六十年代,人们还在用批处理计算机,也就是一次性给一批任务到计算机,然后等待结果,中途不能和计算机进行交互,而且准备作业需要耗费大量时间。于是1965年,贝...

1052
来自专栏儿童编程

《爱溜达的小黄猫》——儿童学编程Scratch2”运动(Motion)“部分

Scratch2非常容易上手,无论对儿童还是零基础的成年人来说,都非常有趣。操作起来就像搭积木一样简单有趣。也许你印象里的编程是满屏代码,不知所云。而这里,编写...

3485
来自专栏搜云库

防守式编程的艺术

原文地址:The Art of Defensive Programming 防守式编程的艺术 为什么开发人员不编写安全代码? 我们不再在这里讨论 “干净的代码”...

1999
来自专栏LET

CPU简介

3099

扫码关注云+社区

领取腾讯云代金券