精华内容
下载资源
问答
  • 网络概念- IPRAN的含义及来历——转载

    万次阅读 多人点赞 2019-04-09 14:39:21
    引言:偶然看到了IPRAN这个词,不知道什么意思,然后查了一下,结果出现了连锁反应。参考链接如下: https://zhidao.baidu.com/question/560342510.html ...wfr=spider&for=pc 一 含义 IPRAN中的IP 指的是...

    引言:偶然看到了IPRAN这个词,不知道什么意思,然后查了一下,结果出现了连锁反应。参考链接如下:

    https://zhidao.baidu.com/question/560342510.html

    https://baijiahao.baidu.com/s?id=1610549300903624530&wfr=spider&for=pc


    一 含义

    IPRAN中的IP 指的是互联协议,RAN指的是Radio Access Network。相对于传统的SDH传送网,IPRAN 的意思:“无线接入网IP化”, 是基于IP的传送网。网络IP化趋势是近年来电信运营商网络发展中最大的一个趋势,在该趋势的驱使下,移动网络的IP化进程也在逐步的展开,作为移动网络重要的组成部分,移动承载网络的IP化是一项非常重要的内容。

    传统的移动运营商的基站回传网络是基于TDM/SDH建成的,但是随着3GLTE等业务的部署与发展,数据业务已成为承载主体,其对带宽的需求在迅猛增长。SDH传统的TDM独享管道的网络扩容模式难以支撑,分组化的承载网建设已经成为一种不可逆转的趋势。

    二 来历

    在开始之前,先要解释一下TDM的概念。

    TDM,就是时分复用,就是将一个标准时长(1秒)分成若干段小的时间段(8000),每一个小时间段(1/8000=125us)传输一路信号。

    SDH系统的电路调度均以TDM为基础,所以看到很多人说SDH业务就是TDM业务,就是传统的电路调度,是有理论依据的。

    SDH全称叫做同步数字传输体制,是一种传输的体制协议。你可以把SDH简单的理解为集装箱运输。
    以2M业务为例。每个2M业务就是一件货物。先把货物装在一个标准的盒子里(VC12),然后给盒子贴上一个指示其位置的标识标签(TU-12),再把三个这样的贴了标签的盒子装在一个大一点的盒子里(TUG2),再把七个大盒子装在一个更大的盒子里(TUG3),再把三个更大的盒子装在一个货箱中(VC4)。然后在货箱上加上有关这箱货物中各个盒子的一些附加信息(段开销和指针),这样就组成了一个集装箱运输车(STM-1)。多个集装箱运输车还可以合在一起形成更长的集装箱运输车队(STM-N)。这样的集装箱车队就在光纤组成的高速公路上行驶,运输货物。在货物的接收端,就按上面相反的方式把货物(2M业务)取出来。

    但在SDH大红大紫的时候,另一场战争在以太网和ATM(不是取款机,是“异步传输模式”,一种以信元为基础的分组交换和复用技术)之间开打。

    在这场大战中,以太网取得全面胜利,从而大行其道。其中又以IP最为强势,导致后来很多业务侧都IP化了,可以说是“当红炸子鸡”。

    这样的话,SDH是一个大红人,以太网是另一个大红人,能否合作一下???一拍即合,MSTP诞生!

    MSTP(Multi-Service Transfer Platform)(基于SDH 的多业务传送平台)是指基于SDH 平台同时实现TDM、ATM、以太网等业务的接入、处理和传送,提供统一网管的多业务节点。

    在合资公司MSTP中,股份分配不太均匀:SDH占股70%,以太网占股20%,其它包括ATM占股10%。

    可以看出来,掌权的还是SDH,内核还是TDM,TDM的一切劣势都依旧保留,如刚性管道。

    以太网和ATM因为股权问题,都没有拿出像样的东西,只是须有其表(提供相应接口)而已。

    随着互联网的大力普及,电脑、手机、电视等终端都能上网了,带宽的需求急剧增加,电信运营商们赚钱的机会来了。

    但是,挑战也来了,以前1*155M(STM-1)可以供好上千人打电话,现在人们在打电话时还要上网,带宽需求增长和现网资源出现激烈的矛盾。要解决这个矛盾,我们就来看看SDH这位红人平时是如何与人相处的:

    SDH这位红人一直都是我行我素,唯我独尊,从不与人分享公共资源,比如二环批给我跑,二环就不许有其它车辆经过,上面就我一辆车。刚开始,我这个车能拉1个客人(STM-1),那么二环的效率就是运送了一个人(155M--STM-1),后来把车吨位升级了,我能拉64个客人(64*STM-1),那么二环的效率就是(10G-STM-64),这就是环速率。如果有个时间段没有人需要运送,那么我就空跑,沿路看看风景、美女什么的,这时的效率就是0,其它道路就是堵死了也和我没关。

    由于比较固执,自己也有很多的无奈,比如你的车能装64位客人,但现在有65位客人,对不起,我也只能运64人,我们把这种低效率运作方式叫刚性管道。

    现在需要运送的客人越来越多了,忙不过来了,解决方法有三个:

    第一种:多修几条路(新建光缆),进行人员分流;缺点:成本和周期太长--------PASS

    第二种:升级汽车吨位(提高速率);缺点:汽车厂还没研发出更大载重的车辆(电子元器件受限)-PASS

    第三种:将二环划分成多个车道(波道),多个车辆共享道路

    领导看后,立即批示:方案三可行,立即执行!

    于是乎,波分产生。

    波分,就是波分复用,WDM。

    波分就是将多个车道(波道)的车辆(信号)放到同一条道路(光纤)中进行传送。

    • 高速公路: 光纤
    • 巡逻车: 监控信号
    • 加油站: 光中继(放大)站
    • 灰色汽车: 不同的客户侧业务
    • 彩色汽车: 不同通道(波长)内的承载业务
    • 车道: 光波长

    这里又根据车道间隔大小,分为两类:

    车道间隔为20nm的,为稀疏波分,又称粗波分。

    车道间隔小于等于0.8nm的,为密集波分。

    这样带宽成倍增加了,暂时解决了带宽不足的问题!可以休息休息了……

    WDM得到重用后,各地纷纷仿效,现在的WDM不仅在城市主干道里使用(城域波分),还用在跨市、跨省道路上(长途波分)。

    它的具体工作方式是各种类型的货物或乘客(业务信号)都被装载到一辆辆汽车中,汽车按照预先分配的车道(波道)行驶。中间汽车需要加油我们还设置了加油站(光放站OLA)。司乘人员需要吃饭休息补充体力,我们为他们设置临时休息区(中继站)。当然我们还是离不开交警系统的支持(光监控OSC或电监控ESC)。

    随着人们需求的不断增加,车道数也由刚开始的16或32一下子扩充到40、80、160,目前施工水平(制造工艺)已经突破200个车道数(波道)。

    但我们的管理水平还是很低的,主要体现在一下几个方面:

    1、交通管理消息传递不畅(OAM缺乏,操作维护管理(Operation Administration and Maintenance)是指根据运营商网络运营的实际需要,通常将网络的管理工作划分为3大类:操作(Operation)、管理(Administration)、维护(Maintenance),简称OAM。):

    WDM的初衷就是为了解决带宽不够问题,没有考虑到带宽提高后,管理也要跟上呀。

    现在最大的问题是车辆多了,如何对每一辆车的状态做到了如指掌,交警(OSC)感到力不从心。

    这时,有几位SDH的司乘人员在小声谈论:我们SDH公交系统,都有统一的管理机构,每一辆车上都有司机和售票员,分工明确,还用实时视频监控(在线监测),公司时刻都能了解每一辆车的运行状况,WDM你差的太远了。

    2、调度不够灵活:

    WDM在设计之初就有一个严重缺陷:比如一个货物要从西安运到北京,预先分配的车道是10车道(第10波),那么从西安到北京全程都是第10车道,不能更改,除非你经过了好几个高速段(光再生段),如西安-郑州、郑州-北京,那么你在郑州可以有一次更换车道的机会,而且这种更换车道的代价是为你这次的行为专门修一条小路(布放光纤)。

    以前SDH遇到类似的情况时就在郑州修一个大的调度中心,所有问题都解决了。

    3、容易堵死(保护不完善):

    在城市主干道或省际快速道路上,为了提高效率,在公路设计时就考虑到与普通道路的区别,只设置几个很少的出口,其它全是封闭的。

    这样带来的后果是一旦发生拥堵或交通事故,乘客就会闹得不可开交(业务中断)。

    想想我们的城市公交SDH,司机一看到前面堵车,马上就抄小路了。可能会有几个乘客不能在目的地下车(少量业务中断),但是绝大部分乘客都能顺利到达。究其原因,就是有大量可用迂回路由,再加上灵活调度(司机就可决定)。

    交通运输局(ITU-T,中文名称是国际电信联盟电信标准分局(ITU-T for ITU Telecommunication Standardization Sector), 它是国际电信联盟管理下的专门制定电信标准的分支机构。)看到问题所在,从以下几个方面进行改革:

    1、为所有上路车辆增加监控设备以及必要的安全管理员----增加OAM开销。

    2、在交通枢纽节点增设调度枢纽-----增加业务调度(车道间调度【光层调度】和货物或乘客间调度【电层调度】)。

    3、依托调度枢纽,加上在道路上预留一部分车道或一部分车辆,为所有车辆提供完善的保障-----完善保护机制。

    SDH笑道:这是什么改革,我们一直都是这样做的,就是容量没你大而已。

    WDM回应道:我容量确实比你大得多,但这些方面没你们做得好。

    他们握手言欢,优势互补,一个全新的模式诞生了------OTN(光传送网,OpticalTransportNetwork)。

    概况一下OTN:

    OTN是在WDM基础上,融合了SDH的一些优点,如丰富的OAM开销、灵活的业务调度、完善的保护方式等。

    OTN对业务的调度分为:光层调度和电层调度。

    光层调度可以理解为是WDM的范畴;电层调度可以理解为SDH的范畴。

    所以简单的说:OTN=WDM+SDH

    但OTN的电层调度工作方式与SDH还是有些不同的地方——

    回顾一下SDH的特点:

    1、统一发车频率,1秒发车8000次,制度规定,无法更改(沿袭PDH制度,PDH采用准同步数字系列(PDH)的系统,是在数字通信网的每个节点上都分别设置高精度的时钟,这些时钟的信号都具有统一的标准速率。)。

    2、通过研发更大吨位的车辆来提高容量,高容量的车一般是由4辆低一个容量级别的车拼接而成,所以不同容量的车结构是不一样的。

    OTN电层调度的工作特点:

    1、所有车辆的大小、规格、容量均统一,外形尺寸:4*4080。

    2、根据需求提高发车频率。

    优点:

    1、无需不断研发更大容量的车,减低开发成本。

    2、统一结构,便于管理。

    3、跨区域运输方便(异厂家互通方便)。

    4、理论上,可以通过提高发车频率就可以无限提高容量,实现方式更简单明了。

    花开两朵,各表一支,我们对以前的红人SDH在江湖的发展做了详细的描述。现在的SDH也只相当于OTN掌门下的一个堂主而已了,那么另一位红人它现在发展的如何呢?

    话说当年,以太网和ATM,就像华山派,以剑术精妙独步武林,在武林中有较高的声望,但在华山派中有分为以剑为主以气为辅的剑宗和以气为主以剑为辅的气宗。以太网就像剑宗,ATM就像气宗。

    以太网以简单著称,容易上手引来众多门徒;ATM因其内功心法太过高深,修炼之人寥寥。最后的争斗中以太网获得大胜,这与小说中的情节不相符,令人费解……

    直到有一天,以太网在为如何将本门派再发扬光大烦恼,同时ATM也在为有如此高深的武功没人赏识郁闷。二位昔日的对手,偶遇并交谈后,ATM想借以太网来提高影响,以太网想借ATM的内功精髓来壮大声势,一拍即合。

    两人经过数月秘密商讨,并在一年之后,共同发布了一本新的武功秘笈——MPLS(多协议标签交换)。

    该部武功秘笈后来被改编为多个版本,是其它武功的重要基础,这是后话!

    以太网的声势越来越大,再加上又有MPLS助阵,逐渐有了可以抗衡SDH的实力,所以才有了SDH与以太网的初步融合,诞生了MSTP。但MSTP因为股权问题,还是SDH主导,以太网、ATM只能是配角,以太网并不高兴,发誓要有所改观……

    为了对抗SDH阵营,以太网大力发展自己的势力范围,走农村包围城市的策略,先将末端IP化(业务侧IP化)。IP可以作为SDH的货物,通过SDH进行传输。

    但问题出来了:

    SDH当初开发时就对货物有严格的外形要求,必须是“块状结构”,而且大小也是标准的,每一个座位也是按照这个要求做的,这样运输的效率最高。

    后来IP这种长相奇特(格式不同)的货物越来越多,就算是专门开发出了MSTP。

    说白了MSTP就是在SDH车辆上给IP和ATM留了几个专座而已,IP还是不能很好的运输!

    原因是IP是以太网门下的得力弟子,以太网就是因为简单、无拘无束、尽力而为等特点为其创派宗旨。所以IP也有此特性,有的小巧,有的肥大(IP帧长可变)。如果SDH/MSTP中的IP较少,问题不大。如果IP占到一半以上,恐怕车辆的改造成本就太大了。

    MSTP:如果分组业务低于50%,仍有成本优势。

    但现在的问题是IP货物越来越多,我要自己成立运输公司,而且要我说了算,不能再受制于SDH了。

    同时SDH也再想,能不能将车厢分成二层,一层给原来的业务,一层专门给IP预留,这样就可以兼顾了。

    现在真是百家争鸣的时期,各种新公司、新技术都涌现出来。

    我们先说SDH阵营,由于先前MSTP成立时,股权分配不均,有很多遗留问题,导致现在以太网严重不满意。

    现在SDH集团研究后推出MSTP+(也叫Hybrid MSTP),50/50股权分配,车辆变成二层,二层分开管理和调度,两套调度体系(双内核交叉);也不失为一种好的补偿措施。

    再说以太网阵营,自由散漫惯了,现在出现了两种大的分歧:

    一种认为我们自己成立的运输公司不让SDH的客户(TDM业务)上车,如果一定要进来,必须改头换面-伪装(仿真),同时我们没有时间上的保证(无时间同步),我们纯粹为我们以太网服务,我们的公司名叫IP-RAN。

    一种认为我们应该吸收一些SDH的客户,SDH经营了这么多年,它的客户还是很多的(还有很多TDM业务需求),同样进来后还是要改头换面-伪装(仿真),然后再我们的帮派里活动,出帮派后再去掉伪装还原成自己原来的模样,这个公司取名叫PTN。PTN(分组传送网,Packet Transport Network)是一种光传送网络架构和具体技术。

    无论哪种方式,伪装-易容术总少不了,随后就开发了PWE3易容术。

    在PTN公司中又有2大派别:

    一派是融合MPLS、易容术PWE3和MSTP的产物--------MPLS-TP派别。

    一派是融合了QinQ和MSTP的产物------------------PBT派别。

    对于MPLS-TP派别,当年支持者众多,有华为、中兴、烽火、阿朗、爱立信、中移动等重量级明星。

    对于PBT派别,支持者仅有北电网络,人单势孤。

    所以我们现在看到的PTN绝大部分是MPLS-TP派别。

    随着相互学习,现在的IP-RAN和PTN的差别也越来越小了,IP-RAN的优势是三层无连接服务,但PTN现在也可以实现了;以前PTN为了传输SDH的客户TDM业务,专门开发了时间和时钟同步系统叫1588系统。IP-RAN也学过来了,也支持这一系统了。

    真应了那句话:分久必合,合久必分啊!

    展开全文
  • 我们希望让它继续满下去,能满则保持,提高网络的利用率,我们知道TCP的发送窗口(即可以发送多少数据)是ACK驱动的,ACK就像时钟一样,我们希望数据可以持续发送以保持网络满载,就要保证ACK源源不断地到来,因此在这...
    本文主要阐述TCP拥塞控制中ssthresh的来历以及为什么拥塞避免探测到丢包的时候,ssthresh会被设置为当前窗口的一半。
    
    进入证实内容之前,不得不再次吐槽!目前在网上搜的,任何资料上看的,甚至RFC上,都没有讲明白到底什么是ssthresh,它的值有什么讲究,几乎所有的资料都是在说,如果窗口大于ssthresh,那么就执行线性增窗的拥塞避免阶段,否则执行慢启动...这让几乎所有人记住了这个结论,并且在长期被洗涤之后,很多人对这个不知所以然的事实却表现的不以为然,其实也包括我自己。因此当我明白了ssthresh到底是怎么一回事的时候,当我知道了丢包后ssthresh的1/2系数与公平性之间的关系的时候,我便迫不及待地想把这些东西分享出来!

    TCP数据段填满端节点之间的网络

    假设端系统A和B之间在进行TCP通信,那么只要A和B之间存在空间距离,由于光速的传播时延,一定意味着A和B之间存在一定的容量,可以容纳若干的数据段,你可以将其想做是一般的缓存,另外,为了更具普遍性,我们认为A和B之间的所有路由器,交换机等中间节点的队列缓存,也包含在A和B的网络缓存之中。如下图所示:




    为了达到最高的网络利用率,我们希望A和B之间的缓存(包括节点队列以及网络本身)中完全充盈着TCP的数据段,并且是持续维持。

    TCP数据段无间隙地持续流动

    如上图所示,当A,B之间的网络被填满时,A和B之间一共有N个数据段,发送端还可以继续发送数据吗?事实上是可以的,因为在网络被填满之后,发送端每发送一个数据段,接收端同时也会消费掉一个数据段,同时发出一个ACK,直到填满A,B间网络的那个数据段的ACK到达发送端为止,依照假定,ACK的速率和数据段的速率一致,我们算一下,发送端一共可以持续发送2*N个数据段,这2*N个数据段发送的开始时间点是第1个数据段发送的时间,结束时间点是第一个数据段的ACK回到发送端的时间,正好是一个RTT,设发送速率为r,那么以下的等式显而易见:
    2*N = r*RTT
    过程如下图所示:




    我们还可以看到,前N个段是为了填满A,B之间的网络,后N个段是在“A,B之间已经满载的情况下”TCP的ACK clock驱动的pacing。紧随着这2*N个数据段的是一个新的周期,又是一个RTT内2*N个数据段,这就是理想情况下的情景,数据段充盈着网络,不间断地源源不断从发送端发出,ACK亦不间断地从接收端返回。

    两个区域(safe & dangerous)

    我其实不想现在就把谜底揭穿,但是我也不想卖关子,毕竟现在也不早了。
    请注意上图中的t28这个时间点,在t28之前,A和B之间并不总是被充满,而在t28之后,却总是满的。这意味着,t28之前的数据段是可以缓冲的,即网络中还存在一些空闲的空间可以提供给数据进行缓冲,从而不至于数据被丢弃,然而在t28之后,网络满载了,我们看到没有丝毫的空白区域可供数据包缓冲,这意味一旦发生拥塞,数据包必然丢失!
    显而易见,t28之前是安全的,而t28之后则是危险的,这就是safe area和dangerous area的由来!划分二者的是什么?正是网络的容量!在上述图示的例子中,就是4!当Flight的数据段小于4的时候,意味着可以激进的传输,当Flight数据一旦越过4,就必须保守传输了!
            何谓激进?何谓保守?激进就是可以让窗口最快的速度增加到safe和dangerous的边界,由于TCP由ACK来驱动,只要收到一个ACK,就意味着通道是畅通的,窗口就可以递增一个MSS,而所谓的保守就是,必须等待当前窗口的数据全部都被ACK了之后,说明刚才发送的数据是可以到达对端的,此时才能将窗口增加一个MSS。现在来总结以下两个区域的增窗方式:
    safe区域:




    dangerous区域:





    我们来比对一下窗口在这两个区域时的特性,如果说安全区域的目标是填满网络的话,那么在安全区域我们已知的是网络并未被填满,此时只要有ACK到来就可以增窗,直到网络被填满,现在我们来看危险区域,此时我们已知的事实是网络已经满了,我们希望让它继续满下去,能满则保持,提高网络的利用率,我们知道TCP的发送窗口(即可以发送多少数据)是ACK驱动的,ACK就像时钟一样,我们希望数据可以持续发送以保持网络满载,就要保证ACK源源不断地到来,因此在这个阶段继续发送数据的目标仅仅是为了消除ACK时钟的空白期,或者称作 停摆期,因为只有这样,源源不断的ACK才能驱动数据源源不断地被发送。
            回过头来再看一下增窗过程图的t20这个时间点,网络被4,5,6,7这四个数据包已经充满,但是在下一个时刻t21,随着4被接收,由于没有到达的ACK,网络被清空了1个MSS,理论上,我们知道最终的窗口肯定就是2*N,此例中,N就是4,在例子中,最终也确实窗口增加到了8,然而在现实中,拥塞随时都会发生,也就是说在窗口从4增加到8的期间,随时会发生丢包,这也就意味着窗口可能永远都增加不到8!那么我们怎么可以知道当前的窗口是合理的,然后尝试继续增加窗口呢?答案就是前一个窗口的数据全部被确认!这就是拥塞避免的由来,这个过程很慢,并不是设计的问题,而是它必须这么慢。拥塞避免这个名字非常好,确实在避免!
            理解了上面的描述,我们可以给出TCP管道的概念了,然后所有的真相就大白了。

    TCP管道的概念

    事实上,TCP管道包含两个部分,按照公式2*N=r*RTT,2*N便是管道的容量,这两部分的第一部分是网络被填满之前的容量,只要知道尚未被填满,尽情地填,使用慢启动足矣,第二部分是网络被填满之后的容量,完全按照ACK来驱动,采用拥塞避免方式探测窗口,理想情况下,理论上,这两部分的容量是相等的。因此,我们可以就可以知道事情的真相了。
    问题1:N是什么?
    答:N就是ssthresh!
    问题2:为什么探测到拥塞后,ssthresh要下降为当前窗口的一半?
    答:探测到拥塞说明管道的容量为当前窗口C,而C=2*N,因此N=(1/2)*C!
    问题3:为什么在拥塞避免阶段要加性增?即AI
    答:只有当一窗的数据被确认,才可以确保之前的窗口是有效的,毕竟网络已经塞满,而ACK有可能不对称返回,拥塞随时可能发生。
    问题4:为什么乘性减?
    答:见问题2.
    问题5:慢启动阶段为什么可以指数级增窗?
    答:因为此时可以确保窗口小于N,即网络还没有塞满,即便发生拥塞,也还有富余的缓存可用。
    问题6:还有问题吗?
    答:如果一切都如上那般美好,当然就没有问题了,问题是,ssthresh从来就没有估计准确过。


    回到现实中的TCP

    TCP在设计之处的愿景十分美好,然而现实世界并不是一个友好的世界,不过,TCP本身就是自适应的,它并没有规定ssthresh的值的大小,甚至都没有建议,它完全靠在TCP自行发现丢包或者拥塞后,以当前窗口的一半作为ssthresh的当前值,随着连接的继续,ssthresh也会动态调整,因为不管现实多么残酷,理想中的反馈系统总归是一个万物收敛的目标,那就是实际的带宽总是趋向于ssthresh的2倍的大小,令人惊讶的是,ssthresh就是依靠拥塞避免算法计算出来的。当然,随着TCP的发展,这个 C=2*N=r*RTT经典公式也历经了诸多的变化形成了各种变体,比如cubic就不再以2作为ssthresh的系数来计算管道容量。

    慢启动的hystatr优化

    我们知道,ssthresh的设置是以丢包作为反馈信号的,现在问题是,连接刚刚建立的时候,没有丢包作为反馈信号的时候,如何来设置ssthresh?
    一般而言,默认的实现都是将其设置为一个巨大的值,然后最快的速度历经一次丢包,然后设置ssthresh为丢包时窗口的一半,然后像ssthresh的2倍缓慢逼近。但是这会带来问题,由于没有ssthresh作为阈值限制,用丢包作为代价,太高昂。因此在慢启动过程中如果可以探测到ssthresh的值,那就可以随时退出慢启动状态了。那么我们如何来探测呢?
    还是 C=2*N=r*RTT这个公式,关键看看我们怎么使用它。由于我们只是探测网络被塞满时的情况,即N的值,因此:
    N=r*(RTT/2)
    我们看看r是什么?所谓速率其实就是一定的事务量除以做这些事务的时间,如果说我们发出去了N'个数据包,一共用了时间段T,那么:
    r=N'/T
    代入后得到:
    N=(N'/T)*(RTT/2)
    理想情况下,在毕竟网络容量的时候,N=N',那么就可以很简单得到T等于RTT/2的时候,就说明达到了ssthresh,该退出慢启动了!
    那么如何来实现它呢?由于我们无法单独探测N个数据段到达接收端并计时,我们可以变相等价使用ACK来计算,以一个窗口的第一个数据段作为计时开始Tstart,每收到一个ACK即更新以下数值:
    RTTmin:采样周期内最小的RTT,以最大限度地表示A和B之间的理想往返时延。
    Tcurr:当前时间
    如果下列条件成立,则可以退出慢启动了:
    Tcurr - Tstart >= RTTmin/2
    非常简单易懂。然而现实并不是理想的,大多数情况下,以上的算法并没有带来比较好的效果,为什么呢?因为整个带宽不是一个TCP连接独享的,而是全世界的所有TCP连接甚至包括UDP共享的,因此以上的公式基本上无法表示任何真实的情况,所以实际当中,更倾向于使用RTT来预估网络已经被塞满。使用RTT来估算网络容量ssthresh更加实际一些,因为它充分考虑了拥塞时的排队延时,因此在该方法下,退出慢启动的条件便成了:
    Tcurr_rtt > RTTmin + fixed_value

    以上旨在解决首次慢启动在还没有ssthresh值的时候预测ssthresh的方式,其实在此后的任何时候,只要是慢启动,都可以用以上的算法来预测当前的ssthresh,而不是说必须要用拥塞算法给出的ssthresh或者说仅仅是1/2丢包窗口(虽然你已经看到,这个1/2是多么地合理!)

    ssthresh的快速穿越问题

    我们知道,慢启动的时候,增窗速度非常快(基本就是根据ACK的反馈,将数据段翻倍突突出去的),那么在窗口增加到接近到仍然小于ssthresh的时候,会出现如下图所示的情况:




    然而这在实现中是不易发生的,是什么限制住它的发生呢?以下几点:

    1.TCP的延迟确认机制最多只能延迟2个MSS

    慢启动增窗,收到一个ACK递增1个MSS,即便在使用ABC的时候,也就是说窗口最多只能超越ssthresh 2个MSS,这是由下述代码保证的:
    if (sysctl_tcp_abc > 1 && tp->bytes_acked >= 2*tp->mss_cache)
    	cnt <<= 1;

    2.即便发生了ACK大量丢失,TCP的默认实现也是数ACK的个数,而不是数被ACK的字节数

    3.发生大量ACK丢失又启用ABC时,见方法1.

    4.两段处理方式

    Linux的4.x版本内核中默认使用ACK的字节数来计数增窗值(ABC方案),在穿越ssthresh的时候,TCP拥塞控制逻辑会将被ACK的字节数分为两个部分,ssthresh以下的部分用来计数慢启动,而ssthresh以上的部分用来计数拥塞避免。综上所述,下图总结了ssthresh穿越的情况:



    AIMD的公平性收敛

    为了简单起见,我们假设有TCP1和TCP2两个连接共享一个链路,现在看它们是怎么“收敛到公平”的,下面的图示清晰显示了一切:




    如果你看不懂这个图,请自行google。我们可以肯定,在公平线的下方,红色的减窗线的斜率是恒小于公平线(斜45度角)的斜率的,两个链接的每一次降窗,其降窗线的斜率都会越来越接近公平线的斜率,即收敛到公平,最终,它将在绿色粗线上震荡,永葆公平(虽然利用率不是那么高!)。

            我们还可以看到,TCP1和TCP2是等比例降窗的,在此例中比例是0.5,它们非得是0.5吗?非也!只要保持等比例,图中的注解1就永远成立,最终的收敛也会永远成立,不同的仅仅是最终收敛额绿色粗线的长度和范围!虽然说按照最初的Reno TCP,保持0.5的降窗比例是多么得合理(见上述推论),然而考虑到现实的复杂情况,比例不再是0.5也是合理的。
             现在我们来看看如果TCP1和TCP2的降窗比例不同会怎样。假设TCP2降窗依然为0.5的比例,而TCP2则小于0.5,那么上图将会变成下面的样子:




    我们可以看到,竞争者中降窗比率最小的将会最终抢占几乎所有的带宽,它会将所有的其它连接的带宽逐渐往左上角挤兑,最终归零。这么说来,如果想让自己的TCP具有侵略性,减少降窗比率是不是就可以了呢?没这么这简单!要知道,我上面的两幅图有一个共同的前提,那就是竞争者的RTT是相等的!但是现实中,会这样吗??非常难!如果RTT相等,比如它们的源头和目标都在同一个地点,那么它们十有八九是合作关系,而不是竞争!爆炸!

            那么,RTT将会是一个十分重要的角色!确实是这样,实际的TCP在运行中,RTT的波动非常大,这就几乎将我上面的论述全部推翻了,显然很令人心碎!然而,上述的分析作为一个理论模型还是有意义的,它起码让你理解了TCP的本质行为。至于说实际情况,RTT的波动是一个有意义的信号,它让端系统看到了中间路由器交换机的排队行为,因此会出现RTT所谓的“噪点”,很多人想除掉它们,平滑掉它们,但是这同时也意味着你屏蔽了重要的信号。
            RTT的波动非常具有动感且性感,它用数值表征了整个排队理论,或者你可以推出马尔科夫到达过程,或者你只是觉得它们是令人难过的噪点...于是,现实中的TCP几乎完全改进了Reno的指导,除了Reno几乎没有什么拥塞算法在发现丢包时把ssthresh降为当前窗口的一半。这就是TCP的进化,但是这种进化始终围绕着一个内核,这个内核就是我上面说的这些,简单,易懂,然而却令人惊讶的东西。
    展开全文
  • 行主序:在数组中按照a[0][0]、a[0][1]、a[0][2]…a[1][0]、a[1][1]、a[1][2]…依次存储数据 列主序:在数组中按照a[0][0]、a[1][0]、a[2][0]…a[0][1]、a[1][1]、a[2][1]…依次存储数据 基地址:即数组首元素地址,...

    行主序:在数组中按照a[0][0]、a[0][1]、a[0][2]…a[1][0]、a[1][1]、a[1][2]…依次存储数据
    列主序:在数组中按照a[0][0]、a[1][0]、a[2][0]…a[0][1]、a[1][1]、a[2][1]…依次存储数据
    基地址:即数组首元素地址,数组的起始地址。

    展开全文
  • 官网原文标题《Concepts and Architecture--Messaging Concepts》 翻译时间:2018-10-04 ... 译者:本文介绍了Pulsar消息系统中的核心概念,是入门学习pulsar的开篇...他的核心概念和其他消息系统类似,尤其是kafka,...

    官网原文标题《Concepts and Architecture--Messaging Concepts》

    翻译时间:2018-10-04

    官网原文地址:http://pulsar.apache.org/docs/en/concepts-messaging/

    译者:本文介绍了Pulsar消息系统中的核心概念,是入门学习pulsar的开篇文档。他的核心概念和其他消息系统类似,尤其是kafka,但是又都有所不同。只有深刻理解好这些基础的概念,将来对pulsar的学习才能更为轻松!

     

    1 消息概念

    Pular采用了发布订阅的设计模式,也称作pub-sub。producer发布消息到topic,consumer可以订阅这些topic,处理发布过来的消息,在处理完成后发送确认。

    一旦订阅被创建,所有的消息都将被Pulsar保存,即使consumer已断开了连接。只有在consumer确认消息已经被成功处理后,保存下来的消息才会被丢弃。

     

    1.1 消息

    消息是Pulsar的基础单元。producer发给topic的内容,consumer从topic消费的内容,就是消息。和邮政系统类比,消息就相当于信件。

    组成用途
    value/data payload消息携带的数据,所有pulsar的消息携带原始bytes,但是消息数据也需要遵循数据shcema
    Key消息可以被Key打标签。这可以对topic压缩之类的事情起作用
    properties可选的,用户定义属性 的key/value map
    Producer Name生产消息的producer的名称(producer被自动赋予默认名称,但你也可以请求自己指定)
    Sequence ID在topic中,每个Pulsar消息属于一个有序的序列。消息的sequence ID是他在序列中的次序
    Publish time消息发布的时间戳
    Event time可选的时间戳,应用可以附在消息上,代表某个事件发生的时间,例如,消息被处理时。如果没有
    明确的设置,那么event time为0

    若想了解Pulsar消息内容的更深入分解,请参考Pulasr的binary protocol文档

     

    1.2 生产者

    生产者是关联到topic的程序,它发布消息到Pulsar的broker上。

    1.2.1 发送模式

    producer可以以同步或者异步的方式发布消息到broker。

    模式描述
    同步发送发送消息后,producer等待broker的确认。如果没有收到确认,producer会认为发送失败。
    异步发送producer将会把消息放入blocking队列,然后马上返回。客户端类库将会在背后把消息发送给broker。
    如果队列满了,根据传给producer的参数,producer可能阻塞或者直接返回失败。

    1.2.2 压缩

    为了节省带宽,在传输过程中,producer发布的消息可以被压缩。目前pulsar支持两种压缩类型:

    1.2.3 批处理

    如果批处理开启,producer将会累积一批消息,然后通过一次请求发送出去。批处理的大小取决于最大的消息数量及最大的发布延迟。

     

    1.3 消费者

    消费者通过订阅关联到主题,然后接收消息的程序。

    1.3.1 接收模式

    消息可以通过同步或者异步的方式从broker接受。

    模式描述
    同步接收同步接收将会阻塞,直到消息可用
    异步接收异步接收立即返回future值--java中的CompletableFuture,一旦新消息可用,他即刻完成

    1.3.2 确认

    消费者成功处理了消息,需要发送确认给broker,以让broker丢掉这条消息(否则它将存储着此消息)。

    消息的确认可以一个接一个,也可以累积一起。累积确认时,消费者只需要确认最后一条他收到的消息。所有之前(包含此条)的消息,都不会被重新发给那个消费者。

    累积消息确认不能用于shared 订阅模式,因为shared订阅为同一个订阅引入了多个消费者。

    1.3.3 监听

    客户端类库提供了他们对于consumer的监听实现。举一个Java客户端的例子,它提供了MessageListener接口。在这个接口中,一旦接受到新的消息,received方法将被调用。

     

    1.4 主题(Topic)

    和其他的发布订阅系统一样,Pulsar中的topic是带有名称的通道,用来从producer到consumer传输消息。Topic的名称是符合良好结构的URL。

    {persistent|non-persistent}://tenant/namespace/topic
    Topic名称组成描述
    persistent/ non-persistent定义了topic类型,Pulsar支持两种不同topic:持久和非持久
    (默认是持久类型,如果你没有指明类型,topic将会是持久类型)。持久topic的所有消息都会保存在硬盘上
    (这意味着多块硬盘,除非是单机模式的broker),反之,非持久topic的数据不会存储到硬盘上
    tenant实例中topic的租户。tenant是Pulsar多租户的基本要素。可以被跨集群的传播。
    namespacetopic的管理单元,相关topic组的管理机制。大多数的topic配置在namespace层面生效。
    每个tenant可以有多个namespace
    topic主题名称的最后组成部分,topic的名称很自由,没有什么特殊的含义。

    不需要显式的创建topic

    你并不需要显式的创建topic。如果客户端尝试从一个还不存在的topic写或者接受消息,pulsar将会按在topic名称提供的namnespace下自动创建topic。

     

    1.5 命名空间(namespace)

    命名空间是租户内部逻辑上的命名术语。一个租户可以通过admin API创建多个命名空间。例如,一个对接多个应用的租户,可以为每个应用创建不同的namespace。

     

    1.6 订阅模型

    订阅是命名过的配置规则,指导消息如何投递给消费者。Pulsar有三种订阅模式:exclusive,shared,failover,下图展示了这三种模式:

    1.6.1 Exclusive(独占)

    独占模式,只能有一个消费者绑定到订阅(subscription)上。如果多于一个消费者尝试以同样方式去订阅主题,消费者将会收到错误。

    上面的图中,只有Consumer A可以消费。

    Exclusive模式为默认订阅模式。

    1.6.2 Shared(共享)

    shared或者round robin模式中,多个消费者可以绑定到同一个订阅上。消息通过round robin轮询机制分发给不同的消费者,并且每个消息仅会被分发给一个消费者。当消费者断开连接,所有被发送给他,但没有被确认的消息将被重新安排,分发给其它存活的消费者。

    第一幅图中,Consumer-B-1和Consumer-B-2都可以订阅主题,其实Consumer-C-1或者其它Consumer也可以订阅。

    Shared模式的限制

    使用shared模式时,需要重点注意以下两点:

    • 消息的顺序无法保证
    • 你不可以使用累积确认

    1.6.3 Failover(灾备)

    Failover模式中,多个consumer可以绑定到同一个subscription。consumer将会按字典顺序排序,第一个consumer被初始化为唯一接受消息的消费者。这个consumer被称为master consumer。

    当master consumer断开时,所有的消息(未被确认和后续进入的)将会被分发给队列中的下一个consumer。

    第一个图中,Consumer-C-1是master consumer,当Consumer-C-1断开连接时,由于Consumer-C-2在队列中下一个位置,那么它将会开始接收消息。

     

    1.7 多主题订阅

    当consumer订阅pulsar的主题,默认情况下,它订阅了一个指定的主题,例如:persistent://public/default/my-topic。从Pulsar的1.23.0-incubating的版本,Pulsar消费者可以同时订阅多个topic。你可以用以下两种方式定义topic的列表:

    • 通过基础的正则表达式(regex),例如 persistent://public/default/finance-.*
    • 通过明确定义的topic列表

    通过正则订阅多主题时,所有的主题必须在同一个命名空间(namespace)

    当订阅多主题时,pulsar客户端会自动调用Pulsar的API来发现匹配表达式的所有topic,然后全部订阅。如果此时有暂不存在的topic,那么一旦这些topic被创建,conusmer会自动订阅。

    不能保证顺序性

    当消费者订阅多主题时,pulsar所提供对单一主题订阅的顺序保证,就hold不住了。如果你在使用pulsar的时候,遇到必须保证顺序的需求,我们强烈建议不要使用此特性

    下面是多主题订阅在java中的例子:

    import java.util.regex.Pattern;
    
    import org.apache.pulsar.client.api.Consumer;
    import org.apache.pulsar.client.api.PulsarClient;
    
    PulsarClient pulsarClient = // Instantiate Pulsar client object
    
    // Subscribe to all topics in a namespace
    Pattern allTopicsInNamespace = Pattern.compile("persistent://public/default/.*");
    Consumer allTopicsConsumer = pulsarClient.subscribe(allTopicsInNamespace, "subscription-1");
    
    // Subscribe to a subsets of topics in a namespace, based on regex
    Pattern someTopicsInNamespace = Pattern.compile("persistent://public/default/foo.*");
    Consumer someTopicsConsumer = pulsarClient.subscribe(someTopicsInNamespace, "subscription-1");

    代码例子,请见:

    1.8 主题分区

    通常一个topic仅被一个broker服务,这限制了topic最大吞吐量。分区topic是特殊的topic类型,他可以被多个broker处理,这让topic有更高的吞吐量。

    其实在背后,分区的topic通过N个内部topic实现,N是分区的数量。当向分区的topic发送消息,每条消息被路由到其中一个broker。Pulsar自动处理跨broker的分区分布。

    下图对此做了阐明(partition译为分区):

    此处,Topic1有5个分区(P0到P4),分布在三个broker上。因为分区多于broker数量,其中有两个broker要处理两个分区。第三个broker则只处理一个。(再次强调,分区的分布是自动处理的)

    这个topic的消息被广播给两个consumer。路由模式决定哪个broker处理哪个partition, 订阅模式决定哪条消息送到哪个consumer。

    在大多数境况下,路由和订阅模式可以分开制定。通常来讲,吞吐能力的要求,决定了 分区/路由 的方式。订阅模式则应该由应用的需求来做决定。

    分区topic和普通topic,对于订阅模式如何工作,没有任何不同。分区只是决定了从生产者生产消息到消费者处理及确认消息过程中发生的事情。

    分区topic需要通过admin API指定创建。创建的时候可以指明分区的数量。

     

    1.9 路由模式

    当发布消息到分区topic,你必须要指定路由模式。路由模式决定了每条消息被发布到的分区(其实是内部主题)。

    下面是三种默认可用的路由模式

    模式描述顺序保证
    Key hash如果message指定了key,producer将会把key hash,然后把他分配给指定分区同一个key下有序
    single default partition如果没有key,每个生产者的消息将会被路由分发给专用的分区。初始时候随机选择同一个生产者下有序
    round robin分发如果没有key,所有的消息通过round-robin方式被路由到不同的分区,以达到最大的生产能力

    这些默认的模式之外,你还可以创建客制化的路由模式,如果你在使用Java client,可以通过实现MessageRouter接口来做到。

     

    1.10 非持久topic

    默认的,Pulsar保存所有没有确认的消息到多个BookKeeper的bookies中(存储节点)。持久topic的消息数据可以在broker重启或者订阅者出问题的情况下存活下来。

    Pulsar也提供了非持久topic。非持久topic的消息不会被保存在硬盘上,只存活于内存中。当使用非持久topic分发时,杀掉Pulsar的broker或者关闭订阅者,意味着客户端可能会遭遇消息丢失。

    非持久topic有如下格式的名称(注意名字中的non-persistent):

    non-persistent://tenant/namespace/topic

    使用非持久topic的更多信息,请参考 Non-persistent messaging cookbook.

    非持久topic中,broker会立即发布消息给所有连接的订阅者,而不会在BookKeeper中存储。如果有一个订阅者断开连接,broker将无法重发这些瞬时消息。订阅者将永远也不能收到这些消息了。去掉持久化存储的步骤,在某些情况下,使得非持久topic的消息比持久topic稍微变快。但是同时,Pulsar的一些核心优势也丧失掉了。

    非持久topic,消息数据仅存活在内存。如果broker挂掉或者其他情况不能从内存取出,你的消息数据就可能会丢失。只有真的觉得你的使用场景符合,并且你可以忍受时,才可去使用非持久topic。

    默认非持久topic在broker上是开启的,你可以通过broker的配置关闭。你可以通过使用pulsar-admin-topics接口管理非持久topic。

    1.10.1 性能

    非持久消息通常比持久消息会更快,因为broker无须持久化消息,当消息被分发给所有订阅者时,会立即发送ack给producer。非持久topic让producer有更低的发布延迟。

    1.10.2 Client API

    producer和consumer以连接持久topic同样的方式连接到非持久topic。重要的区别是topic的名称必须以non-persistent开头。三种订阅模式--exclusive,shared,failover对于非持久topic都是支持的。

    下面是一个非持久topic的java consumer例子:

    PulsarClient client = PulsarClient.create("pulsar://localhost:6650");
    
    String npTopic = "non-persistent://public/default/my-topic";
    
    String subscriptionName = "my-subscription-name";
    
    
    
    Consumer consumer = client.subscribe(npTopic, subscriptionName);

    这里还有一个非持久topic的java producer例子: 

    Producer producer = client.createProducer(npTopic);

     

    1.11 消息存留和过期

    Pulsar broker默认如下:

    • 立即删除所有已经被cunsumer确认过的的消息
    • 以消息backlog的形式,持久保存所有的未被确认消息

    Pulsar有两个特性,这使得你可以覆盖上面的默认行为。

    • 消息存留让你可以保存consumer确认过的消息
    • 消息过期让你可以给未被确认的消息设置存活时长(TTL)。

    所有消息存留和过期在namespace层面管理。具体操作请查看Message retention and expiry 

    下图说明了这两种概念:

    图中上面的是消息存留,存留规则会被用于某namespace下所有的topic,指明一些消息会被持久存储,即使已经被确认过。没有被留存规则覆盖的消息将会被删除。没有留存规则的话,所有被确认的消息都会被删除。

    图中下面的是消息过期,有些消息还没有被确认,也被删除掉了。因为根据设置在namespace上的TTL,他们已经过期了。(例如,TTL为5分钟,过了十分钟消息还没被确认)

     

    1.12 消息去重

    当消息被Pulsar持久化多于一次的时候,会发生数据重复。消息去重是Pulsar可选的特性,阻止不必要的消息重复,每条消息仅处理一次。

    下图展示了开启和关闭消息去重的场景:

    最上面的场景中,消息去重被关闭。producer发布消息1到一个topic,消息到达broker后,被持久化到BookKeeper。然后producer又发送了消息1(可能因为某些重试逻辑),然后消息被接收后又持久化在BookKeeper。消息重复发生了。

    在第二个场景中,producer发送了消息1,消息被broker接收然后持久化,和第一个场景是一样的。当producer再次发送消息时,broker知道已经收到个消息1,所以不会再持久化消息1.

    消息去重在命名空间层面处理。更多介绍请参考message deduplication cookbook.

    1.12.1 生产者幂等

    消息去重的另外一种方法是确保每条消息仅被生产一次。这种方法通常被叫做生产者幂等。这种方式的缺点是,把消息去重的工作推给了应用去做。在Pulsar中,这是被broker处理的,这意味着你不需要修改你的客户端代码,你只需要做一些管理上的变化(参考Managing message deduplication

    1.12.2 去重和实际一次语义

    消息去重,使Pulsar成为与流处理引擎(SPE)或者其他寻求“实际一次”处理语义的系统连接的完美消息系统。消息系统若不提供自动消息去重,则需要SPE或者其他系统保证去重。这意味着严格的消息顺序来自于让程序承担额外的去重工作。使用Pulsar,严格的顺序保证不会带来任何应用层面的消耗。

    更深入的信息可以参考 this post及 Streamlio blog

    展开全文
  • 机器学习深度学习概念入门

    万次阅读 多人点赞 2017-06-03 11:27:28
     对于很多初入学习人工智能的学习者来说,对机器学习、深度学习、人工智能的概念和区别还不是很了解,那么接下来就给大家从概念和特点上进行阐述。先看下三者的关系。  人工智能包括了机器学习,机器学习包括...
  • AI基本概念和应用

    万次阅读 2017-11-09 22:13:58
    AI 的发展势头 5.17日美国旧金山Google I/O 大会上,Google CEO 开场就再次强调了公司战略从“Mobile first to AI first”,称 Google 会因此重新思考自己的所有产品,还要...迪拜机场 CEO:AI 时代,机场安检入...
  • 数据库的视图索引的概念和区别

    万次阅读 2016-07-19 15:39:04
    视图是从一个或多个表中导出来的表,是一种不是一种真正存在的概念。 视图就像一个窗口,通过这个窗口可以看到系统专门提供的数据。 这样,用户可以不用看到整个数据库中的数据,而之关心对自己有用的数据。 ...
  • 业务建模和概念模型设计

    千次阅读 2018-11-28 09:36:56
    按照层次关系划分,数据路径上包括业务建模,概念模型设计,逻辑模型设计物理模型设计。 业务建模是针对公司或者部门级的业务进行全方面的梳理分解。 概念建模是对业务模型进行抽象出来实体以及实体与实体之.....
  • 工作组的概念以及区别

    千次阅读 2019-05-05 17:11:29
    局域网上的资源需要管理,“域”“工作组”就是两种不同的网络资源管理模式。那么二者有何区别呢? 工作组 Work Group 在一个网络内,可能有成百上千台电脑,如果这些电脑不进行分组,都列在“网上邻居”内,...
  • 接口概念和作用

    万次阅读 多人点赞 2018-08-16 22:33:23
    一、接口概念和作用 1.接口语法 interface 接口名{  // 静态常量,抽象方法 } 说明:① 声明一个接口使用关键字interface,而不是class,class是用来声明一个类,classinterface是属于同一个级别的。  ② 接口...
  • DAOORM概念

    千次阅读 2018-11-15 15:43:09
    2.而ORM是针对开发而言的,就像面向过程面向对象开发一样,是一种处理问题的方式。ORM的目的是使数据操作能像操作对象那样方便(其实有时候不一定更方便,更准确地说,应该是让程序员能够运用过面向对象...
  • 转载: cesium编程入门(十二)camera控制 | cesium中文网 ...cesium提供了三种方式,可以对camera...如果有些人加载了室内模型,可能还要用WASDQR像在游戏中一样的行走,cesium也能实现此功能,且听下回分解。
  • 我就问你1MB1Mb能一样吗

    千次阅读 2019-11-02 12:37:07
    概念 1MB=1Byte B是Byte(字节)的缩写,1MB读“1兆字节” ,1MB是量单位。我们所说的硬盘容量是40GB、80GB、100GB,这里的B指是的Byte也就是“字节”。 1Mb=1Mbit b是Bit(比特)的缩写,1Mb读“1兆比特”,1...
  • 时间复杂度空间复杂度的概念及各种算法的时间复杂度 及举例 算法的复杂度可分为俩种 一种时间复杂度 另一种是空间复杂度。 俩者的概念:时间复杂度是指执行这个算法所需要的计算工作量;而空间复杂度是指执行这个...
  • 面向对象概念和基本特征

    千次阅读 2018-07-23 16:24:51
    所谓的面向对象就是基于对象概念,以对象为中心,以类继承为构造机制,来认识、理解刻画客观世界设计、构建相应的软件系统。 OO (Object Oriented, 面向对象)是当前计算机界关心的重点,它是90年代软件开发的...
  • 数据结构基础概念

    万次阅读 多人点赞 2017-11-14 13:44:24
    数据结构一些概念 数据结构就是研究数据的逻辑结构物理结构以及它们之间相互关系,并对这种结构定义相应的运算,而且确保经过这些运算后所得到的新结构仍然是原来的结构类型。数据:所有能被输入到计算机中,且能...
  • 原创ZooKeeper入门实战教程(一)-介绍与核心概念

    万次阅读 多人点赞 2018-10-14 07:59:27
    本原创入门教程,涵盖ZooKeeper核心内容,通过实例大量图表,结合实战,帮助学习者理解运用,任何问题欢迎留言。...本章是后续学习的基石,只有充分理解了分布式系统的概念和面临的问题,以及Z...
  • 从神经网络说起:深度学习初学者不可不知的25个术语和概念(上)  关键词:大数据 神经网络 来源:网络整理 作者:IOTER 2017-06-11 05:54 人工智能,深度学习机器学习,不论你现在是否能够理解...
  • 角频率Ω数字频率w的物理含义

    千次阅读 2020-03-22 18:41:08
    角频率Ω数字频率w的物理含义 频率f,角频率Ω数字频率w的物理含义–附MATLAB仿真 古人云:基础不牢,地动山摇。勿在浮沙筑高台。此话真不假,比如MATLAB中下标从1开始而物理概念t从0开始,结果往往会差一点,做...
  • 抓取网页的过程其实读者平时使用IE浏览器浏览网页的道理是一样的。 比如说你在浏览器的地址栏中输入 www.baidu.com  这个地址。 打开网页的过程其实就是浏览器作为一个浏览的“客户端”,向服务器端发送了 一次...
  • 路由表中preference metric的含义

    千次阅读 2016-10-12 15:24:29
    路由表中preference metric的含义这里提到与其他路由协议的配合是因为在路由器上往往支持多路由协议,多路由协议的支持就有一个多种路由的选择配合问题。为了解决这个问题,在路由的参数中引入了优先级...
  • TCPUDP概念及区别

    千次阅读 2019-03-27 17:01:08
    一、TCP、UDP概念 TCP(Transmission Control Protocol,传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793定义。在简化的计算机网络OSI模型中,它完成第四层传输层所指定的...
  • 对象序列化的含义和意义

    万次阅读 2018-06-03 19:48:03
    程序需要序列化实现Externalizable接口的对象, 一样调用ObjectOutputStream 的writeObject()方法输出该对象;反序列化该对象 ,调用ObjectInputStream 的readObject()方法即可.  2.需要实现序列化的类,最好给出无参...
  • P、NP、NPCNP-Hard相关概念的图形解释

    万次阅读 多人点赞 2015-10-15 19:48:27
    P、NP、NPCNP-Hard相关概念的图形解释 一、相关概念   P: 能在多项式时间内解决的问题  NP: 不能在多项式时间内解决或不确定能不能在多项式时间内解决,但能在多项式时间验证的问题  NPC: ...
  • MVC设计模式含义和优点

    万次阅读 2014-02-21 17:12:48
    MVC模式(Model-View-Controller)是软件工程中的一种软件架构模式,把软件系统分为三个基本部分:模型(Model)、视图(View)控制器(Controller)。  MVC模式最早由Trygve Reenskaug在1978年提出[1] ,是...
  • 时域频域的概念

    千次阅读 2008-06-22 09:20:00
    最近在上数字图像处理,时域频域的概念我没有直观的概念,搜索一下,归纳如下: 1.最简单的解释频域就是频率域,平常我们用的是时域,是时间有关的,这里只频率有关,是时间域的倒数。时域中,X轴是时间,...
  • 深度学习基本概念

    千次阅读 2017-06-16 10:55:41
    一、实验介绍 ...本次实验将会带大家学习深度学习中的一些最基本的概念,本次实验很重要,理解这些概念是继续深入学习的基础。 1.2 实验知识点 如何让机器“学习”神经网络的概念有监督与无监督学习
  • TCP拥塞控制流量控制区别含义深刻理解 因为最近学习了TCP/IP协议,学习TCP其中内部的两个很大的特点,就是流量控制拥塞控制两个优化数据传输的方法,因为两者有很多细节的知识,所以再这里记录一下,希望能很直白...
  • 程序的基本概念

    千次阅读 2017-09-13 14:32:39
    程序的基本概念1.1. 程序编程语言程序(Program)告诉计算机应如何完成一个计算任务,这里的计算可以是数学运算,比如解方程,也可以是符号运算,比如查找替换文档中的某个单词。从根本上说,计算机是由数字电路...
  • LSB概念

    千次阅读 2018-11-15 19:48:49
    精度又叫做精密度,是跟准确度相对应的一个概念。就像打靶一样,打的准,那就说它的准确度比较高;而每两个靶之间能打出的偏移越小,那它的精密度就越高。精密度与准确度合起来称为精确度。但是鉴于大家都将精度指代...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 192,491
精华内容 76,996
关键字:

含义和概念一样吗