老程序员分享:OSI七层模型

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
密钥管理服务KMS,1000个密钥,100个凭据,1个月
简介: 老程序员分享:OSI七层模型

一、OSI七层模型


1.1 物理层


主要功能:利用传输介质为数据链路层提供物理连接,实现比特流的透明传输。有IEEE 802.1A(定义局域网体系结构)、IEEE 802.2(包括工作频段、移动速率、上下行传输速率等)、IEEE 802.11(无线局域网通用标准)等标准。


1.2 数据链路层


主要功能:物理寻址,把数据封装成MAC帧、在物理层提供的比特流的基础上,通过差错控制、流量控制方法,使有差错的物理线路变成无差错的数据链路,即提供可靠的通过物理介质传输数据的方法。有点对点传输协议PPP(Point-to-Point Protocol)等。


1.3 网络层


主要功能:控制子网的运行,如逻辑编址、分组传输、路由选择。有IP、国际控制报文协议ICMP(Internet Control Message Protocol)、路由选择协议,路由选择协议有分为内部网关协议IGP(Interior Gateway Protocol, 如RIP,OSPF)P和外部网关协议EGP(External GateWay Protocol,如BGP),网路层还有网际组管理协议IGMP(Internet Group Management Protocol)、地址解析协议ARP(Address Resolution Protocol)、逆向地址解析协议RARP(Reverse Address Resolution Protocol)等。


一般地,数据链路层是解决同一网络内节点之间的通信,而网络层主要解决不同子网间的通信。


1.4 传输层


主要功能:向用户提供可靠的端到端的差错和流量控制,保证报文的正确传输,在必要的时候把数据进行分割,并将这些数据交给网络层。传输层的作用是向高层屏蔽下层数据通信的细节,即向用户透明地传送报文。有传输控制协议TCP(Transmission Contro Proto)、用户数据报协议UDP(User Datagram Protocol)。


1.5 会话层


主要功能:不同机器上的用户之间建立及管理会话。没有协议。


1.6 表示层


主要功能:处理用户信息的表示问题,如编码、数据格式转换和加密解密等。没有协议。


1.7 应用层


主要功能:直接向用户提供服务,完成网络用户提供的各种网络服务及应用所需的监督、管理和服务等各种协议,负责协调各个应用程序间的工作。有文件传送协议FTP(File Transfer Protocol)、超文本传输协议HTTP、简单网络管理协议SNMP(Simple Network Management Proto)、简单邮件传送协议SMTP(Simple Mail Transfer Protocol)、域名系统DNS(Domain Name Syste,主要用户域名与IP地址的转换)、远程终端协议Telnet等。


二、网络层


网络层提供的是数据报(IP数据报)服务,也称网际层、IP层。在网络层,互联网设计的思路是这样的:网络层向上只提供简单灵活的、无连接的、尽最大努力交付的数据报服务。


网络层不提供服务质量的承诺 ,也就是说,所传送的分组可能出错、丢失、重复和失序,当然也不保证分组交付的时限。


将网络互联起来要使用一些中间设备,根据中间设备所在的层次,可以有以下四种不同的设备:


(1)物理层使用的中间设备叫做转发器(repeater);


(2)数据链路层使用的中间设备叫做网桥或桥接器(bridge);


(3)网络层使用的中间设备叫做路由器(router);


(4)在网络层以上使用的中间设备叫做网关(gateway),用网关连接两个不兼容的系统需要在高层进行协议的转换。


在IP网中,互连起来的各种物理网络的异构性本来是客观存在的,但是我们利用IP协议就可以使这些性能各异的网络在网络层上看起来好像是一个统一的网络。如果在这种覆盖全球的IP网的上层使用TCP协议,那么就是现在的互联网(Internet)。


2.1 IP地址


整个互联网就是一个单一的、抽象的网络。IP地址就是给互联网上的每一台主机(或路由器)的每一个接口分配一个在全世界范围内是唯一的32位的标识符。IP地址可以记为:


IP地址 ::= {, }


IP地址分为网络号字段和主机号字段,A类、B类、C类都是单播地址(一对一通信),D类是多播地址,E类保留为以后所用。IP地址的指派范围如下:


按照互联网的观点,一个网络是指具有相同网络号 net-id 的主机的集合。因此,用转发器或网桥连接起来的若干个局域网仍为一个网络,因为这些局域网都具有同样的网络号。具有不同网络号的局域网必须使用路由器进行互联。


我们需要注意:


1,在同一个局域网上的主机或路由器IP地址中的网络号必须是一样的;


2,用网桥(工作再链路层)互连的网络仍然是一个局域网,只能有一个网络号;


3,路由器总是具有两个或两个以上的IP地址。即路由器的每一个接口都有一个不同网络号的IP地址;


4,路由器仅根据目的主机所连接的网络号来转发分组,这样可以减小路由表所占的存储空间以及查找路由表的时间。


2.2 IP地址与硬件地址


从层次的角度看,物理地址(也叫 硬件地址、MAC地址)是数据链路层和物理层使用的地址,而IP地址是网络层和以上各层使用的地址,是一种逻辑地址(因为IP地址是用软件实现的)。


在局域网中,硬件地址是固化在网卡上的ROM中的独一无二的48位串行号,在网络上的每一个计算机都必须拥有一个独一无二的MAC地址。IEEE为网络接口控制器(也叫 网络适配器,网卡)销售商分配唯一的MAC地址。IP地址与硬件地址的区别如下图所示:


我们需要强调一下几点:


(1)在IP层抽象的互联网上只能看到IP数据报;


(2)虽然IP报首部有源站IP地址,但路由器只根据目的站的IP地址的网络号进行路由选择;


(3)在局域网的链路层,只能看见MAC帧;


(4)尽管互连在一起的网络的硬件地址体系各不相同,但IP层抽象的互联网却屏蔽了下层这些很复杂的细节。我们在网络层上讨论问题,就能够使用统一的、抽象的IP地址研究主机和主机或路由器之间的通信。


2.3 地址解析协议ARP


地址解析协议ARP的作用:从网络层使用的IP地址,解析出在数据链路层使用的硬件地址,如下图所示:


要实现地址解释功能,我们需要考虑一下问题:


1,IP地址有32位,而局域网的硬件地址是48位,两者之间不存在简单的映射关系;


2,在一个网络上经常有新的主机加入,旧的主机撤走,或主机更换网络适配器也会改变其物理地址;


每一台主机都设有一个ARP高速缓存(ARP //代码效果参考:http://hnjlyzjd.com/xl/wz_24001.html

cache),里面有本局域网上的各主机和路由器的IP地址到硬件地址的映射表,这些都是该主机目前知道的一些地址,并且这个映射表还经常动态更新(新增或超时删除)。

新增:如果在主机A的映射表中查不到主机B的IP地址的项目,就进行新增,如下图所示:


超时删除:映射表中的每个地址项目都设置生存时间(例如10-20分钟),凡超过生存时间的项目就从高速缓存中删除掉。


这里需要注意,ARP是解决同一个局域网上的主机或路由器的IP地址和硬件地址的映射问题。经过以上分析,我们肯定会问:既然在网络链路上传送的帧最终是按照硬件地址找到目的主机的,那么为什么我们还要使用抽象的IP地址,而不直接使用硬件地址进行通信?


全世界存在着各种各样的网络,它们使用不同的硬件地址。要是这些异构网络能够相互通信就必须进行非常复杂的硬件地址转换工作;


形象地说,我们主机的地理位置是可以变动的,主机的网卡也是可以更换的,这就导致MAC地址是不断变化的,如果直接使用硬件地址进行通信,将会带来非常复杂的转换工作;而IP地址是软件实现的,相对来说比较固定的,比如你家的网线,所以IP地址就将MAC地址的差异性和变化性限定在本局域网内,对其它网络(具有不同网络号的网络)隐藏这种差异性和变化性。因此,在虚拟的IP网络上用IP地址进行通信给广大计算机用户带来很大的方便。


2.4 IP数据报的格式


总长度:指首部和数据之和的长度,总长度字段为16位,因此IP数据报的最大长度为 2^16 - 1 = 65535字节,然而实际上传送这样长的数据报在现实中是极少遇到的。


生存时间:占8位,英文缩写TTL(Time To Live),表明数据报在网络中的寿命。其目的是防止无法交付的数据报无限制地在互联网中兜圈子,因为白白浪费网络//代码效果参考:http://hnjlyzjd.com/xl/wz_23999.html

资源。随着技术的进步,后来把TTL字段的功能改为“跳数限制”,显然,最大跳数值是255。若将TTL设为1,就表示这个数据报只能在本局域网中传送。

2.5 子网划分


两级IP地址的缺点:


1,IP地址空间的利用率有时很低;


2,给每一个物理网络分配一个网络号会使路由表变得太大因为使网络性能变坏;


3,两级IP地址不够灵活;


为解决以上问题,1985年IP地址又增加了一个“子网号字段”,使两级IP地址变成三级IP地址,但不改变IP地址原来的网络号。三级IP地址表示如下:


IP地址 ::= {, , }


子网掩码


子网掩码的作用 方便找到子网的网络地址,好处是:不管网络有没有划分子网,只要把子网掩码和IP地址进行逐位的“与”运算,就可以立即得出子网的网络地址来。在不划分网络时,也需要使用子网掩码。子网掩码是一个网络或一个子网的重要属性。


2.6 IPv6


到2011年2月,IPv4的地址已经耗尽,解决IP地址耗尽的根本措施就是采用具有更大地址空间的新版本的IP,即IPv6。IPv6把地址从IPv4的32位增加到128位,IPv6一般的数据报格式:


2.7 虚拟专用网VPN


为什么要建立虚拟专用网?


1,由于IP地址的紧缺,一个机构能够申请到的IP地址数远远小于本机构所拥有的主机数;


2,考虑到互联网并不很安全,而有的机构对数据的安全性要求很高;


3,一个机构内也并不需要把所有的主机接入到外部的互联网,这些不需要接入外部互联网的内部计算机可以自行分配IP地址,称为本地地址。


但本地地址也不能任意选择,否则在某些情况下可能会引起一些麻烦。因此,RFC 1918指明了一些专业地址,如下图所示。在互联网中的所有路由器,对目的地址是专用地址的数据报一律不进行转发。


为了保证数据的安全性,如果专用网不同网络点之间的通信必须经过公用的互联网,但又有保密要求,那么所有通过互联网传送的数据都必须加密。


2.8 网络地址转换NAT


如果VPN内部的一些主机本来已经分配到了本地IP地址,但又想和互联网上的主机通信(并不需要加密),那怎么办呢?


解决办法是:在VPN连接到互联网的路由器上安全NAT软件,将本地IP地址转换成NAT路由器拥有的全球IP地址。


三、传输层


从通信和信息处理的角度看,传输层向它上面的应用层提供通信服务。当网络中的两台主机进行通信时,只有主机的协议栈才有传输层,而网络中的路由器在转发分组时都只有用到下三层(网络层、数据链路层、物理层)的功能。


从传输层的角度看,通信的真正端点是应用进程之间的通信。在一个主机中通常有多个应用进程同时分别和另一台主机中的多个应用进程通信。网络层为主机之间提供逻辑通信,而传输层为应用进程之间提供端到端的逻辑通信。传输层和网络层协议的主要区别如下图所示:


传输层是整个网络体系结构中的关键层次之一,我们先弄清楚一下一些概念:


(1)传输层为相互通信的应用进程提供逻辑通信;


(2)端口和套接字的意义;


(3)无连接的UDP的特点;


(4)面向连接的TCP的特点;


(5)在不可靠的网络上实现可靠传输的工作原理,停止等待协议和ARQ协议;


(6)TCP的滑动窗口、流量控制、拥塞控制和连接管理。


传输层的两个主要协议:用户数据报协议UDP(User Datagram Protocol)和 传输控制协议TCP(Transmission Control Proto)。


UDP提供无连接服务,在传送数据之前不需要先建立连接。远地主机的传输层在收到UDP报文后,不需要给出任何确认;


TCP则提供面向连接的服务,在传送数据之前必须先建立连接,数据传送结束之后要释放连接(三次握手、四次挥手)。


3.1 传输控制协议TCP


TCP连接的端点叫做套接字(Socke)或插口。根据RFC 793的定义:端口号拼接到(concatenated with)IP地址即构成了套接字,例如,若IP地址是192.3.4.5,而端口号是80,那么得到的套接字就是(192.3.4.5:80)。即:


套接字scket = (IP地址:端口号)


每条TCP连接唯一地被通信两端的两个端点(即两个套接字)所确定。即:


TCP连接 ::= {socket1, socket2} = {(IP1: ports), (IP2: ports)}


滑动窗口协议比较复杂,是TCP协议的精髓所在。


3.1.1 TCP的可靠传输


3.1.2 TCP的流量控制


流量控制的目的:流量控制就是让发送方的发送速率不要太快,要让接收方来得及接收,是端到端的问题。


流量控制的实现原理:接收方通过TCP首部的窗口字段值,告诉发送方自身的接收窗口值;发送方设置发送窗口不能超过接收方给出的接收窗口的数值。注意:TCP的窗口单位是字节,不是报文段。


流量控制的具体方法:TCP为每一个连接设置了一个持续计时器(persistence timer),避免陷入死锁局面。TCP发送报文段的时机是一个较为复杂的问题,就是应用进程把数据传送到TCP的发送缓存后,剩下的任务交给TCP,但TCP何时发送报文段呢?捎带确认机制,对接收方,收到发送方的报文段后,不是立即发出确认报文,而是等待一段时间,当接收缓存已有足够空间容纳一个最长的报文段或者存储已有一半的空闲时间,再发出确认报文;对发送方,当发送缓存的数据累积成足够大的报文段,或达到接收方缓存空间的一半大小才发送。


3.1.3 TCP的拥塞控制


网络拥塞:对资源的需要 > 可用资源


拥塞控制的目的:防止过多的数据注入到网络中,使网络中的路由器或链路不致过载,是对整个网络而言,是一个全局性的过程。


拥塞控制的实现原理: 是造成网络拥塞的不等式不再成立。


四、Http


Http是超文本传输协议,也就是HyperText Transfer Protocol,它使用计算机能够理解的语言确立了一种计算机之间传输超文本数据的约定和规范。


超文本:超越了简单的字符文字的文本,它是文字、图片、视频等的混合体,最关键的时超链接,能从一个超文本跳转到另一个超文本。


4.1 Http五大类状态码


4.2 Http头部字段


Host:客户端发送请示,用来指定服务器的域名,如 Host:


Content-Length:服务器在返回数据时,表明本次回应的实体(body)长度,如Content-Length:1000;


Connection:最常用于客户端要求服务器使用TCP持久连接,以便其他请求复用,如Connection:keep-alive(默认持久连接),close(关闭持久连接);


Trandfer-Encoding:传输编码,用来改变报文格式,提高TTFB指标,如Trandfer-Encoding: chunked(分块编码),代表这个报文采用了分块编码。


上面说到Content-Length字段必须真实反映实体长度,通常如果 Content-Length 比实际长度短,会造成内容被截断;如果比实体内容长,会造成 pending(即网络一直在等待)。但实际应用中,有些时候实体长度并没那么好获得,例如实体来自于网络文件,或者由动态语言生成。这时候要想准确获取长度,只能在服务端开一个足够大的 buffer,等内容全部生成好再计算Content-Length,然后才将内容发送给客户端。但这样做一方面需要更大的内存开销,另一方面也会让客户端等更久。


在做网络性能优化时,有一个重要的指标叫 TTFB(Time To First Byte),它代表的是从客户端发出请求到收到响应的第一个字节所花费的时间。越短的 TTFB 意味着用户可以越早看到页面内容,体验越好。可想而知,服务端为了计算响应实体长度而缓存所有内容,跟更短的 TTFB 理念背道而驰。但在 HTTP 报文中,实体一定要在头部之后,顺序不能颠倒,为此我们需要一个新的机制:不依赖头部的长度信息,也能知道实体的边界。Transfer-Encoding正是用来解决这个问题的。在最新的Http规范里,只定义了一种传输编码:分块编码(chunked)。


当使用分块编码之后,报文中的实体需要改为用一系列分块来传输。每个分块包含十六进制的长度值和数据,长度值独占一行,长度不包括它结尾的 CRLF(\r\n),也不包括分块数据结尾的 CRLF。最后一个分块长度值必须为 0,对应的分块数据没有内容,表示实体结束。分块传输能够使用户能够更快地接收到数据,TTFB指标更好。


因此,Transfer-Encoding字段和Content-Length字段不会同时出现在头部,但Content-Encoding 和 Transfer-Encoding 二者是相辅相成的,对于一个 HTTP 报文,很可能同时进行了内容编码和传输编码。


Accept:客户端请求时,用来声明自己可以接受的数据格式,如 Accept: /,表明客户端可以接受任何格式的数据;


User-Agent:客户端用来告诉服务器,我是通过什么工具来请求的,User-Agent通常格式:Mozilla/5.0 (平台) 引擎版本 浏览器版本号


Content-Encoding:内容编码,通常用于对实体内容进行压缩编码,目的是优化传输,表示服务器返回的数据使用了什么压缩格式,如Accept-Encoding: gzip, deflate。内容编码通常是选择性的,例如jpg / png这类文件一般不开启,因为图片格式已经是高度压缩的,再压一遍没有效果不说,还浪费CPU;


Content-Type:用于服务器回应时,告诉客户端,本次数据是什么格式,如Content-Type:text/html; charset=utf-8;


4.3 GET与POST


GET方法是从服务器获取资源,这个资源可以是文本、页面、图片、视频等;


POST操作则是相反,它向URL(标识、定位任何资源的字符串)指定的资源提交数据,数据就放在报文的body里。


在Http协议里,“安全”是指请求方法不会破坏服务器的资源;“幂等”是多次执行相同的操作,结果都是相同的。很明显,GET方法是只读操作,它是安全且幂等的;POST方法是新增或提交数据的操作,会修改服务器上的资源,所以是不安全的,且多次提交数据就会创建多个资源,所以不幂等的。


4.4 Http特性


Http最突出的优点是 简单、灵活和易于扩展、应用广泛和跨平台;缺点是 无状态、明文传输、不安全;


优点:


简单:Http基本的报文格式是 header + body,头部信息也是 key-value简单文本的形式;


灵活和易于扩展:HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死,都允许开发人员自定义和扩充。


应用广泛和跨平台:Http的应用遍地开花,如手机上的各种APP;


缺点:


无状态:服务器不会去记忆 Http 的状态,所以不需要额外的资源来记录状态信息,这能减轻服务器的负担;但它在完成有关联性的操作时会非常麻烦,例如登录->添加购物车->下单->结算->支付,这系列操作都要知道用户的身份才行,但服务器不知道这些请求是有关联的,每次都要问一遍身份信息。对于无状态,比较简单的解决方式是用Cookie技术;


明文传输:Http的所有信息都是可见的,相当于裸奔;


不安全:通信使用明文(不加密),不验证通信方的身份,无法证明报文的完整性。


Http协议是基于TCP/IP的,并且使用了请求-应答的通信模式,那下面就来看看TCP/IP的三次握手,四次挥手过程。


4.5 TCP/IP的三次握手,四次挥手


TCP/IP的报文格式如下:


序列号seq,确认好ack,确认ACK,同步SYN,终止FIN,TCP首部部分字段如下图所示:


窗口:占2字节,指的是发送本报文段的一方的接收窗口。窗口值作为接收方让发送方设置其发送窗口的依据,该字段明确指出了现在允许对方发送的数据量,窗口值经常在动态变化着。


三次握手过程理解


第一次握手:建立连接时,客户端发送syn包(syn=x)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers);


第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;


第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。


四次挥手过程理解


第一次挥手:客户端发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。


第二次挥手:服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。此时处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。


客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。


第三次挥手:服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。


第四次挥手:客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。


服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。


为什么连接的时候是三次握手,关闭的时候是四次挥手?


因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能服务器还需要向客户端发送报文,并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。


即,关闭时需要额外考虑Server端还有报文没发送完的情况,所以需要四次挥手。


为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?


2MSL指的是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。


为什么不能用两次握手进行连接?


3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。


即,只进行两次握手的话,如果Client端发送SYN报文后,没有收到Server端的SYN+ACK报文,容易造成死锁:Server端向Client发送SYN+ACK报文后,开始发送数据分组报文,没有收到CLient端的回应,则一直重复发送相同的数据分组;Client端由于没有收到Server端的SYN+ACK报文(可能网络不可靠),等待连接确定应答分组或重复发送FIN报文,这样就造成了死锁。


如果已经建立了连接,但是客户端突然出现故障了怎么办?


TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。


参考链接:

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
2天前
|
存储 网络协议 安全
30 道初级网络工程师面试题,涵盖 OSI 模型、TCP/IP 协议栈、IP 地址、子网掩码、VLAN、STP、DHCP、DNS、防火墙、NAT、VPN 等基础知识和技术,帮助小白们充分准备面试,顺利踏入职场
本文精选了 30 道初级网络工程师面试题,涵盖 OSI 模型、TCP/IP 协议栈、IP 地址、子网掩码、VLAN、STP、DHCP、DNS、防火墙、NAT、VPN 等基础知识和技术,帮助小白们充分准备面试,顺利踏入职场。
11 2
|
22天前
|
网络协议 数据安全/隐私保护 网络架构
|
2天前
|
运维 网络协议 算法
7 层 OSI 参考模型:详解网络通信的层次结构
7 层 OSI 参考模型:详解网络通信的层次结构
9 1
|
6月前
|
网络协议 网络架构
OSI 模型和 TCP/IP 模型的异同
OSI 模型和 TCP/IP 模型的异同
97 1
|
6月前
|
网络协议 数据安全/隐私保护 网络架构
OSI七层模型和TCPIP五层模型
OSI七层模型和TCPIP五层模型
|
4月前
|
网络协议 安全 网络安全
图解OSI七层模型,2024最强科普!
【7月更文挑战第20天】
347 2
图解OSI七层模型,2024最强科普!
|
3月前
|
网络协议 Java 关系型数据库
16 Java网络编程(计算机网络+网络模型OSI/TCP/IP+通信协议等)
16 Java网络编程(计算机网络+网络模型OSI/TCP/IP+通信协议等)
84 2
|
3月前
|
网络协议 安全 网络性能优化
OSI 模型详解:网络通信的七层架构
【8月更文挑战第31天】
648 0
|
3月前
|
网络协议 网络架构
OSI 和 TCP/IP 模型
【8月更文挑战第24天】
65 0
|
3月前
|
网络协议 数据安全/隐私保护 网络架构
深入理解OSI模型及其层次结构
【8月更文挑战第24天】
112 0