大學(xué)計(jì)算機(jī)專(zhuān)業(yè)相關(guān)論文范文
計(jì)算機(jī)種類(lèi)繁多。實(shí)際來(lái)看,計(jì)算機(jī)總體上是處理信息的工具。根據(jù)圖靈機(jī)理論,一部具有最基本功能的計(jì)算機(jī)應(yīng)當(dāng)能夠完成任何其它計(jì)算機(jī)能做的事情。下面是學(xué)習(xí)啦小編給大家推薦的大學(xué)計(jì)算機(jī)專(zhuān)業(yè)相關(guān)論文范文,希望大家喜歡!
大學(xué)計(jì)算機(jī)專(zhuān)業(yè)相關(guān)論文范文篇一
《淺析軟件項(xiàng)目過(guò)程管理矩陣模型研究與實(shí)踐》
關(guān)鍵詞:軟件項(xiàng)目管理;過(guò)程控制;矩陣模型;需求管理
摘要:軟件項(xiàng)目由于應(yīng)用的領(lǐng)域不同,一般涉及眾多的業(yè)務(wù)知識(shí)領(lǐng)域,項(xiàng)目成果也應(yīng)以軟件的邏輯產(chǎn)品來(lái)體現(xiàn),其最終成果及實(shí)現(xiàn)過(guò)程的可見(jiàn)性、可度量性相對(duì)較弱。因此,軟件項(xiàng)目管理比一般工程項(xiàng)目要復(fù)雜得多?;谲浖?xiàng)目管理的特點(diǎn)分析,并結(jié)合軟件項(xiàng)目開(kāi)發(fā)管理經(jīng)驗(yàn),討論了軟件項(xiàng)目組織架構(gòu)、計(jì)劃與過(guò)程控制等軟件項(xiàng)目管理要素,提出了矩陣式項(xiàng)目管理模型,分析了該模型中業(yè)務(wù)知識(shí)與計(jì)算機(jī)技術(shù)共同作用所能達(dá)到的最佳效果,討論了需求管理模型及其應(yīng)用,實(shí)踐證明該模型是行之有效的。
O引言
項(xiàng)目管理是伴隨著項(xiàng)目進(jìn)行而進(jìn)行的,是一種為了滿足甚至超越項(xiàng)目所有者對(duì)項(xiàng)目的期望而將理論知識(shí)、技能、工具和技巧應(yīng)用到項(xiàng)目中的管理活動(dòng),是一門(mén)關(guān)于項(xiàng)目資金、時(shí)間、人力等資源控制的管理科學(xué)。
顧名思義,軟件項(xiàng)目管理就是項(xiàng)目管理在軟件領(lǐng)域的應(yīng)用,是一種為了能夠按照預(yù)定的工期、質(zhì)量順利完成軟件項(xiàng)目而對(duì)成本、人員、進(jìn)度、質(zhì)量、風(fēng)險(xiǎn)等進(jìn)行控制管理的活動(dòng)。其核心在于通過(guò)有效的管理,明確項(xiàng)目范圍,合理調(diào)配人力資源,提高項(xiàng)目團(tuán)隊(duì)的整體開(kāi)發(fā)能力,優(yōu)化項(xiàng)目執(zhí)行過(guò)程,控制項(xiàng)目成本,為用戶提供滿意的軟件產(chǎn)品。
1軟件項(xiàng)目管理的特點(diǎn)
軟件是一種特殊的產(chǎn)品,這種產(chǎn)品的特殊性之一就是它的生產(chǎn)活動(dòng)是以項(xiàng)目的形式進(jìn)行的,因此,項(xiàng)目管理對(duì)軟件生產(chǎn)具有決定性的意義。軟件項(xiàng)目管理除了具有一般項(xiàng)目管理的特點(diǎn)外,還有其獨(dú)特之處,主要表現(xiàn)在:
(1)軟件產(chǎn)品缺乏硬性度量指標(biāo)。
軟件的最大特點(diǎn)在于一個(gè)“軟”字,它不像建筑項(xiàng)目,最終可以有一個(gè)實(shí)物,可以用某一個(gè)標(biāo)準(zhǔn)去剛性的度量評(píng)價(jià)。而軟件產(chǎn)品客觀上具有“不可見(jiàn)性”,表現(xiàn)在它沒(méi)有一個(gè)可見(jiàn)的實(shí)物,還表現(xiàn)在其度量指標(biāo)也不能像度量實(shí)物那樣具有明確性。有效的項(xiàng)目管理就是要使軟件及其生產(chǎn)過(guò)程由不可見(jiàn)、不可度量變成可見(jiàn)和可度量。
(2)重視應(yīng)用領(lǐng)域的業(yè)務(wù)知識(shí)。
對(duì)于計(jì)算機(jī)應(yīng)用軟件來(lái)說(shuō),它并不單純是計(jì)算機(jī)技術(shù)問(wèn)題,更多地表現(xiàn)在它所服務(wù)的業(yè)務(wù)領(lǐng)域的知識(shí)技能。如企業(yè)ERP、SCM等應(yīng)用軟件項(xiàng)目,計(jì)算機(jī)只是它的載體,計(jì)算機(jī)技術(shù)往往并不起決定作用,而與之相關(guān)的業(yè)務(wù)知識(shí)、管理知識(shí)顯得更加重要。
(3)管理比技術(shù)本身更重要。
軟件項(xiàng)目是一項(xiàng)計(jì)算機(jī)技術(shù)、信息技術(shù)、管理科學(xué)等多學(xué)科交叉的系統(tǒng)工程。隨著信息技術(shù)的發(fā)展,軟件項(xiàng)目應(yīng)用領(lǐng)域不斷擴(kuò)張、項(xiàng)目規(guī)模不斷擴(kuò)大、項(xiàng)目業(yè)務(wù)日趨復(fù)雜,一個(gè)軟件從構(gòu)想到完成,需要大量的從事不同工作的人共同努力,個(gè)人單打獨(dú)斗的作坊式開(kāi)發(fā)方式顯然已經(jīng)無(wú)法適應(yīng)這種信息技術(shù)發(fā)展的需要。在一個(gè)大型信息系統(tǒng)工程項(xiàng)目里,需要系統(tǒng)策劃人員、分析設(shè)計(jì)人員、編程人員、測(cè)試人員和用戶等眾多人員的共同參與和密切配合,如何將可用資源有效地結(jié)合在一起,并使之發(fā)揮最大效率,如何保證項(xiàng)目按照預(yù)定的時(shí)間將預(yù)先約定的軟件產(chǎn)品提交給客戶是軟件項(xiàng)目管理的核心任務(wù)。項(xiàng)目管理往往成為決定軟件項(xiàng)目成敗的重要因素。
(4)強(qiáng)調(diào)文檔的重要性。
文檔是軟件產(chǎn)品的重要組成部分,軟件項(xiàng)目管理以工程化的管理方法,強(qiáng)調(diào)規(guī)范文檔的重要性,在軟件生命周期的各個(gè)階段,強(qiáng)調(diào)對(duì)里程碑文檔的評(píng)審,并把文檔作為階段成果的重要體現(xiàn)和下階段的基礎(chǔ)。
(5)重視培訓(xùn)與服務(wù)的價(jià)值。
培訓(xùn)與服務(wù)是發(fā)掘軟件產(chǎn)品價(jià)值的重要手段。一個(gè)軟件產(chǎn)品,如果沒(méi)有人使用就不能形成價(jià)值,如果不會(huì)使用,就可能降低軟件的價(jià)值。服務(wù)的優(yōu)劣已經(jīng)直接影響軟件的使用價(jià)值并決定軟件產(chǎn)品的生命周期??傊浖?xiàng)目管理重視培訓(xùn)與服務(wù)在軟件增值中的意義。
2管理架構(gòu)矩陣模型
規(guī)范化的管理體現(xiàn)在:有完整的基于軟件開(kāi)發(fā)標(biāo)準(zhǔn)(如CMM、ISO等)的開(kāi)發(fā)流程;有基于這個(gè)流程的完整詳細(xì)的開(kāi)發(fā)計(jì)劃;有基于開(kāi)發(fā)計(jì)劃的成本預(yù)算和成本控制方法;有明確的階段檢查措施和評(píng)價(jià)標(biāo)準(zhǔn);有明確的質(zhì)量管理體系和質(zhì)量保證實(shí)施手段,保證項(xiàng)目在可控狀態(tài)下進(jìn)行。而這一切都需要有一個(gè)組織有效的管理團(tuán)隊(duì)和運(yùn)作規(guī)范的管理架構(gòu)。
在軟件項(xiàng)目管理過(guò)程中,項(xiàng)目經(jīng)理起著至關(guān)重要的作用。對(duì)于項(xiàng)目經(jīng)理,目前有兩種觀點(diǎn):一種認(rèn)為軟件項(xiàng)目經(jīng)理應(yīng)該是計(jì)算機(jī)某方面的應(yīng)用專(zhuān)家,能夠?qū)?xiàng)目組成員給予技術(shù)指導(dǎo),如此才有能力合理安排工作。另一種觀點(diǎn)則認(rèn)為,項(xiàng)目經(jīng)理應(yīng)該是職業(yè)經(jīng)理,他可以不是計(jì)算機(jī)技術(shù)專(zhuān)家,但應(yīng)該是管理專(zhuān)家,具備輕松調(diào)配各部門(mén)資源的技巧和有效地組織、管理開(kāi)發(fā)隊(duì)伍、協(xié)調(diào)溝通的能力,他的作用主要體現(xiàn)在協(xié)調(diào)、管理、合理安排成員的工作,控制項(xiàng)目進(jìn)度和費(fèi)用,與用戶溝通,等等。事實(shí)上,在一般意義上,不管是技術(shù)型專(zhuān)家還是管理型專(zhuān)家都無(wú)法滿足現(xiàn)代軟件項(xiàng)目管理的需要。在傳統(tǒng)的垂直型管理模式中,項(xiàng)目經(jīng)理要直接管理到具體的程序員,一般只適用于不太復(fù)雜的技術(shù)型項(xiàng)目,它忽視了中間層的作用,不便于發(fā)揮員工的積極性。而扁平化管理意味著要面對(duì)很多的直接下級(jí),對(duì)管理者提出了很高的管理要求,特別對(duì)于大型項(xiàng)目來(lái)說(shuō),可能涉及到很多業(yè)務(wù)領(lǐng)域知識(shí),他都要面面俱到,這對(duì)于一個(gè)不管是技術(shù)型還是管理型項(xiàng)目經(jīng)理來(lái)說(shuō)似乎都很難做到,即使對(duì)于所謂既懂專(zhuān)業(yè)又懂管理的全才專(zhuān)家來(lái)說(shuō),也不可能要求他在各個(gè)方面都是最優(yōu)秀的。
眾所周知的事實(shí)是,找一個(gè)既懂專(zhuān)業(yè)又有項(xiàng)目管理經(jīng)驗(yàn)的專(zhuān)家往往比較困難,但如果找?guī)讉€(gè)或懂專(zhuān)業(yè)或懂項(xiàng)目管理的專(zhuān)家也許并不困難。一個(gè)好的軟件項(xiàng)目團(tuán)隊(duì)就應(yīng)該是它可以有效整合各成員的能力,使集體的能量達(dá)到最大化。因此,與其找一個(gè)所謂全才的項(xiàng)目經(jīng)理,還不如構(gòu)建規(guī)范的管理架構(gòu)。根據(jù)筆者多年的軟件開(kāi)發(fā)、項(xiàng)目管理的實(shí)踐和經(jīng)驗(yàn),提出了“矩陣式”軟件項(xiàng)目管理模型。在這個(gè)模型中,項(xiàng)目經(jīng)理也只是其中的一個(gè)角色而已。他并不需要面面俱到,也不需要掌握項(xiàng)目的全部細(xì)節(jié),他要做的全部工作就是按管理規(guī)范要求完成項(xiàng)目經(jīng)理這個(gè)角色所特有的工作。在這個(gè)架構(gòu)下,更便于發(fā)揮項(xiàng)目團(tuán)隊(duì)中備人所長(zhǎng),使集體的智慧得以充分張揚(yáng)。每個(gè)人所做的工作(包括他的知識(shí))都已經(jīng)留存下來(lái)了,即使項(xiàng)目經(jīng)理因故離職,接任者也可以從容接手,從而降低了因?yàn)槿藛T流動(dòng)可能對(duì)項(xiàng)目造成的風(fēng)險(xiǎn)。
如表1所示,是某項(xiàng)目管理架構(gòu)的矩陣模型。每個(gè)業(yè)務(wù)子系統(tǒng)有一個(gè)業(yè)務(wù)專(zhuān)家負(fù)責(zé),他們一般都精通某一個(gè)方面的業(yè)務(wù),由他們直接面對(duì)用戶,可以與用戶業(yè)務(wù)人員有更多的共同語(yǔ)言,便于交流,更容易捕獲用戶需求。而在軟件開(kāi)發(fā)的每個(gè)階段,按軟件工程生命周期,各階段由具有技術(shù)專(zhuān)長(zhǎng)的技術(shù)人員負(fù)責(zé)。所以,整體上可以充分發(fā)揮各業(yè)務(wù)負(fù)責(zé)人精通業(yè)務(wù)領(lǐng)域知識(shí)和階段負(fù)責(zé)人精通相關(guān)技術(shù)的優(yōu)勢(shì),使項(xiàng)目團(tuán)隊(duì)整體成為名副其實(shí)的既懂專(zhuān)業(yè)又懂管理的專(zhuān)家。
矩陣管理可以更好地發(fā)揮各專(zhuān)業(yè)人員的業(yè)務(wù)專(zhuān)長(zhǎng),又能更好地發(fā)揮各技術(shù)層面技術(shù)人員的特長(zhǎng),項(xiàng)目經(jīng)理重要的工作就是協(xié)調(diào),重點(diǎn)在于如何結(jié)合眾多資源控制整個(gè)開(kāi)發(fā)進(jìn)程。矩陣模型也有利于軟件公司人才戰(zhàn)略,有利于組織內(nèi)部人才的培養(yǎng),充分展現(xiàn)個(gè)人的發(fā)展空間。大多數(shù)軟件企業(yè)也許都很難有精通所有專(zhuān)業(yè)的全才,但都擁有為數(shù)眾多精通某一類(lèi)業(yè)務(wù)的系統(tǒng)分析師,或精通某一類(lèi)專(zhuān)門(mén)技術(shù)的專(zhuān)門(mén)人才。根據(jù)矩陣模型,公司可以培養(yǎng)員工向不同方向發(fā)展,有技術(shù)特長(zhǎng)的,培養(yǎng)他發(fā)展技術(shù)的深度,有其他專(zhuān)業(yè)特長(zhǎng)的,比如精通稅務(wù)、金融、企業(yè)管理等,則培養(yǎng)成業(yè)務(wù)專(zhuān)家。這樣,在人盡其才的同時(shí),又有利于留住人才,穩(wěn)定了軟件開(kāi)發(fā)隊(duì)伍。
3計(jì)劃與過(guò)程控制
項(xiàng)目計(jì)劃包括風(fēng)險(xiǎn)管理計(jì)劃、質(zhì)量管理計(jì)劃、人力資源計(jì)劃、環(huán)境資源計(jì)劃等。軟件項(xiàng)目計(jì)劃和過(guò)程控制為消除或削弱軟件的“不可見(jiàn)”帶來(lái)的不確定性提供了很好的保障措施?;谌蝿?wù)分解(WBS)的工作分配和項(xiàng)目組織結(jié)構(gòu),明確每個(gè)項(xiàng)目開(kāi)發(fā)人員的責(zé)任以及他們之間的連接,把整個(gè)項(xiàng)目周期劃分為若干個(gè)小的階段,每個(gè)階段都有明確的目標(biāo)和階段成果及其確認(rèn)準(zhǔn)則。由于把每個(gè)階段要完成的工作、預(yù)期的成果都清晰地描述出來(lái)了,一方面,可以使用戶不斷看到一個(gè)個(gè)階段成果,而不是在項(xiàng)目全部完工后才看到一個(gè)大的成果,增強(qiáng)了用戶的信心;另一方面。通過(guò)明確的階段結(jié)果,隨時(shí)收集有關(guān)項(xiàng)目進(jìn)程數(shù)據(jù),按計(jì)劃規(guī)定進(jìn)行進(jìn)度管理,使開(kāi)發(fā)過(guò)程和階段成果都是可見(jiàn)的,也便于發(fā)現(xiàn)問(wèn)題、控制開(kāi)發(fā)過(guò)程,不至于什么問(wèn)題都要到最后才一次暴露,減少了項(xiàng)目風(fēng)險(xiǎn)。
當(dāng)然,如果僅僅有好的項(xiàng)目計(jì)劃而缺乏有效的執(zhí)行機(jī)制和監(jiān)督措施,項(xiàng)目仍然可能失去控制。成功項(xiàng)目的標(biāo)志是在規(guī)定的時(shí)間、合理開(kāi)支的條件下,完成約定的需求,實(shí)現(xiàn)系統(tǒng)的最終目標(biāo)。有效實(shí)施項(xiàng)目進(jìn)度控制是項(xiàng)目成功的重要保障,是每一個(gè)項(xiàng)目經(jīng)理必須非常重視的工作。實(shí)現(xiàn)有效項(xiàng)目過(guò)程控制的方法主要是通過(guò)定期和不定期的檢查體現(xiàn)的。
(1)階段檢查。
不定期的階段性檢查,一般在關(guān)鍵任務(wù)或里程碑任務(wù)的計(jì)劃完成時(shí)進(jìn)行的,即在項(xiàng)目的每個(gè)階段結(jié)束時(shí)都要經(jīng)過(guò)詳細(xì)的評(píng)估。檢查的重點(diǎn)是該階段里程碑任務(wù)是否完整地實(shí)現(xiàn)了,是否可以轉(zhuǎn)入下階段的工作。
(2)定期檢查。
為了隨時(shí)掌控項(xiàng)目進(jìn)度執(zhí)行情況,建立定期信息報(bào)告制度是一個(gè)行之有效的措施。定期的檢查一般分周例會(huì)和月例會(huì),例會(huì)檢查的重點(diǎn)是:需求列表、風(fēng)險(xiǎn)列表、計(jì)劃執(zhí)行情況、質(zhì)量保證情況等。通過(guò)周報(bào)月報(bào),溝通并掌握各方信息,對(duì)存在的問(wèn)題和困難進(jìn)行匯總,提交例會(huì)處理解決,降低不確定性因素對(duì)項(xiàng)目工期的影響,保證項(xiàng)目順利進(jìn)行。
定期或不定期地對(duì)項(xiàng)目進(jìn)度計(jì)劃表進(jìn)行檢查,對(duì)于不合格的項(xiàng)目進(jìn)度計(jì)劃表或未按照項(xiàng)目進(jìn)度計(jì)劃表執(zhí)行的項(xiàng)目給予相應(yīng)處理,及時(shí)發(fā)現(xiàn)問(wèn)題,盡早調(diào)整計(jì)劃偏差,最大限度地避免損失。這樣,在項(xiàng)目進(jìn)行過(guò)程中就比較容易把握每個(gè)階段項(xiàng)目的進(jìn)展情況,方便對(duì)項(xiàng)目組成員的績(jī)效進(jìn)行階段性評(píng)估,便于統(tǒng)一項(xiàng)目經(jīng)理和客戶的認(rèn)識(shí)。增加項(xiàng)目風(fēng)險(xiǎn)的可控性。
4需求管理矩陣模型
軟件項(xiàng)目的最大難點(diǎn)往往在于需求的不確定性,所以,有人認(rèn)為好的需求是軟件項(xiàng)目成功的一半。需求的困難主要表現(xiàn)在計(jì)算機(jī)技術(shù)人員與用戶業(yè)務(wù)人員由于不同的語(yǔ)境,存在溝通困難。用戶業(yè)務(wù)人員可能不清楚計(jì)算機(jī)系統(tǒng)實(shí)現(xiàn)細(xì)節(jié),或并不知道需求人員到底需要了解什么,而計(jì)算機(jī)技術(shù)人員可能由于不熟悉業(yè)務(wù),往往又缺乏引導(dǎo)用戶表達(dá)需求的業(yè)務(wù)素質(zhì)和技巧,所以,影響了雙方溝通和交流,造成的結(jié)果可能是用戶往往不能清楚地描述自己的需求或計(jì)算機(jī)人員不能準(zhǔn)確地理解需求,從而影響了需求的最終描述。另一方面,對(duì)于管理信息系統(tǒng)來(lái)說(shuō),需求的不確定還表現(xiàn)在業(yè)務(wù)流程的變化上,特別對(duì)于現(xiàn)階段還處于不斷變革時(shí)期的我國(guó)企業(yè)來(lái)說(shuō),情況更是如此。
一般來(lái)說(shuō),用戶在看到最終系統(tǒng)以后,通過(guò)不斷地應(yīng)用實(shí)踐,激發(fā)了用戶的聯(lián)想,就可能提出新的或改進(jìn)的需求。所以,在項(xiàng)目一開(kāi)始,技術(shù)人員就必須對(duì)此有充分的認(rèn)識(shí),既要盡可能全面了解現(xiàn)有需求,也要充分預(yù)計(jì)到可能的需求變更,為系統(tǒng)設(shè)計(jì)留有變更或擴(kuò)充的余地。另一方面,應(yīng)該盡可能讓用戶盡早介入,直接參與階段評(píng)審和驗(yàn)收,以便及時(shí)發(fā)現(xiàn)需求執(zhí)行偏失,不至于什么都等到全部完工后才發(fā)現(xiàn)問(wèn)題,才一并解決問(wèn)題。在項(xiàng)目的后期改正一個(gè)錯(cuò)誤的代價(jià)往往是在前期的數(shù)倍。所以,需求管理成為軟件項(xiàng)目成敗的另一個(gè)關(guān)鍵因索之一。
根據(jù)筆者的經(jīng)驗(yàn),建立需求矩陣跟蹤表是進(jìn)行需求管理很好的工具。通過(guò)跟蹤表,項(xiàng)目涉眾可以隨時(shí)了解關(guān)于軟件需求的實(shí)現(xiàn)過(guò)程。用戶可以從中隨時(shí)看到階段性成果,方便用戶及時(shí)測(cè)試、確認(rèn)已實(shí)現(xiàn)的需求,便于用戶積極參與,便于及時(shí)發(fā)現(xiàn)問(wèn)題,改正問(wèn)題。
5結(jié)束語(yǔ)
當(dāng)代信息技術(shù)正以超乎尋常的速度發(fā)展,軟件項(xiàng)目規(guī)模不斷擴(kuò)大,應(yīng)用日趨復(fù)雜,失敗的案例屢見(jiàn)不鮮,人們逐漸把眼光聚焦到關(guān)于軟件項(xiàng)目管理方法的研究,項(xiàng)目管理正逐漸成為當(dāng)今世界解決軟件危機(jī)的一種主流管理方法。矩陣模型已在大量的工程實(shí)踐中被證明是行之有效的。
大學(xué)計(jì)算機(jī)專(zhuān)業(yè)相關(guān)論文范文篇二
《基于TCP的擁塞控制策略研究》
摘要:隨著網(wǎng)絡(luò)技術(shù)的發(fā)展,網(wǎng)絡(luò)擁塞日益嚴(yán)重,如何解決擁塞,充分、高效地利用網(wǎng)絡(luò)資源,成為當(dāng)今急需解決的問(wèn)題。由于Internet上大多數(shù)業(yè)務(wù)都采用TCP協(xié)議,因此TCP的擁塞控制機(jī)制對(duì)控制網(wǎng)絡(luò)擁塞具有特別重要的意義。本文分析了TCP的四個(gè)交互式擁塞控制算法:慢啟動(dòng)、擁塞避免、快速重傳和快速恢復(fù),介紹了TCP基于窗口的擁塞控制策略和目前常用端到端擁塞控制算法,并對(duì)它們的性能進(jìn)行仿真比較。
關(guān)鍵字:AIMD;擁塞控制;TCP;NS
1引言
在Internet上,隨著信息傳送量的逐漸增大和網(wǎng)絡(luò)組成的日益復(fù)雜,網(wǎng)絡(luò)發(fā)生擁塞的可能性越來(lái)越大。網(wǎng)絡(luò)中的擁塞來(lái)源于網(wǎng)絡(luò)資源和網(wǎng)絡(luò)流量分布的不均衡性,它不會(huì)隨著網(wǎng)絡(luò)處理能力的提高而消除。目前為止擁塞問(wèn)題還沒(méi)有得到很好的解決,因此網(wǎng)絡(luò)擁塞的避免和控制成為越來(lái)越重要和急待解決的問(wèn)題。
Internet中擁塞控制的大部分工作是由TCP完成的,目前標(biāo)準(zhǔn)的TCP協(xié)議實(shí)現(xiàn)都包含了一些避免和控制網(wǎng)絡(luò)擁塞的算法。當(dāng)今Internet的可靠性和穩(wěn)定性與TCP擁塞控制機(jī)制密不可分,而TCP的成功也要?dú)w功于其穩(wěn)固的擁塞控制機(jī)制。擁塞控制是確保Internet魯棒性(robustness)的關(guān)鍵因素,因此成為當(dāng)前網(wǎng)絡(luò)研究的一個(gè)熱點(diǎn)問(wèn)題。
2TCP基于窗口的擁塞控制策略2.1加法增加乘法減少(AIMD)窗口算法
TCP是Internet中最流行的端到端傳輸協(xié)議,為主機(jī)之間提供可靠按序的傳輸服務(wù)。在現(xiàn)有的TCP/IP協(xié)議體系下,TCP擁塞控制機(jī)制主要基于加法增加乘法減少(AIMD)算法。在該算法中主要用到三個(gè)窗口變量:
(1)擁塞窗口(cwnd):限定源端在擁塞控制中在一定時(shí)間內(nèi)允許傳送的最大數(shù)據(jù)量,是來(lái)自源端的流量控制。
(2)通告窗口(awnd):連接建立及傳輸過(guò)程中,接收端向源端通告的最大可接收速率,是來(lái)自接收端的流量控制。
(3)有效窗口(win):源端數(shù)據(jù)發(fā)送的實(shí)際窗口大小,限定為win=min(cwnd,awnd)。
由于計(jì)算機(jī)計(jì)算能力和存儲(chǔ)能力的提高,通告窗口一般都比較大,因此當(dāng)前發(fā)送窗口的大小大多數(shù)情況下等于擁塞窗口的大小。
AIMD的具體工作過(guò)程為:
(1)源端每收到一個(gè)ACK,擁塞窗口按下式增加:
Incr=MSS×(MSS/cwnd)(MSS為分組大小)
cwnd=cwnd+Incr
也就是,如果每個(gè)發(fā)出的分組都在最近的RTT(往返時(shí)延)時(shí)間內(nèi)獲得確認(rèn),源端就將cwnd增加1,即加法增加。
(2)當(dāng)發(fā)生超時(shí),TCP將超時(shí)看作擁塞的標(biāo)志,并減小發(fā)送速率。每發(fā)生一次超時(shí),源端重新計(jì)算擁塞窗口值:
cwnd=cwnd/2
也就是,一次超時(shí),擁塞窗口值減為當(dāng)前值的一半,即乘法減少。
2.2TCP擁塞控制的四個(gè)階段
2.2.1啟動(dòng)階段
當(dāng)連接剛建立或超時(shí)時(shí),進(jìn)入慢啟動(dòng)階段。
當(dāng)新建TCP連接時(shí),擁塞窗口(cwnd)被初始化為一個(gè)數(shù)據(jù)包大小。源端按cwnd大小發(fā)送數(shù)據(jù),每收到一個(gè)ACK確認(rèn),就增加一個(gè)數(shù)據(jù)包發(fā)送量,這樣慢啟動(dòng)階段cwnd隨RTT呈指數(shù)級(jí)增長(zhǎng)。
慢啟動(dòng)采用逐漸增大cwnd的方法,可以防止TCP在啟動(dòng)一個(gè)連接時(shí)向網(wǎng)絡(luò)發(fā)送過(guò)多的數(shù)據(jù)包而造成不必要的數(shù)據(jù)丟失和網(wǎng)絡(luò)擁塞,并且它還能夠避免采用單純的AIMD算法造成的吞吐量增加過(guò)慢的問(wèn)題。
為了防止cwnd的無(wú)限制增長(zhǎng)引起網(wǎng)絡(luò)擁塞,引入一個(gè)狀態(tài)變量:慢啟動(dòng)閾值ssthresh。
當(dāng)cwnd
當(dāng)cwnd>ssthresh時(shí),使用擁塞避免算法,減緩cwnd的增長(zhǎng)速度。
2.2.2擁塞避免階段
當(dāng)TCP源端發(fā)現(xiàn)超時(shí)或收到3個(gè)相同的ACK確認(rèn)幀時(shí),即認(rèn)為網(wǎng)絡(luò)將發(fā)生擁塞,此時(shí)進(jìn)入擁塞避免階段。
在擁塞避免階段,慢啟動(dòng)域值ssthresh將被設(shè)置為當(dāng)前cwnd的一半,當(dāng)發(fā)生超時(shí)時(shí),cwnd被置為初始值1。此時(shí),如果cwnd=ssthresh,則執(zhí)行擁塞避免算法,即cwnd在每次收到一個(gè)ACK確認(rèn)時(shí)只增加1/cwnd個(gè)數(shù)據(jù)包。擁塞避免階段cwnd隨RTT呈線性增長(zhǎng)。
2.2.3快速重傳和快速恢復(fù)階段
在擁塞避免階段,當(dāng)數(shù)據(jù)包超時(shí)時(shí),cwnd被置為1,重新進(jìn)入慢啟動(dòng)階段,這會(huì)導(dǎo)致過(guò)大地減小發(fā)送窗口尺寸,降低TCP連接的吞吐量。因此,引入了快速重傳和快速恢復(fù)機(jī)制。
在快速重傳階段,當(dāng)源端收到3個(gè)或3個(gè)以上重復(fù)的ACK時(shí),就判定數(shù)據(jù)包丟失,同時(shí)將ssthresh設(shè)置為當(dāng)前cwnd的一半,并重傳丟失的包,進(jìn)入快速恢復(fù)階段。
在快速恢復(fù)階段,每收到重復(fù)的ACK,則cwnd加1;收到非重復(fù)ACK時(shí),置cwnd=ssthresh,轉(zhuǎn)入擁塞避免階段;如果發(fā)生超時(shí)重傳,則置ssthresh為當(dāng)前cwnd的一半,cwnd=1,重新進(jìn)入慢啟動(dòng)階段。
這種方法避免了數(shù)據(jù)包超時(shí)后就重新進(jìn)入慢啟動(dòng)階段,提高了TCP連接的吞吐量。
3典型TCP擁塞控制算法分析
3.1TCPTahoe算法
Tahoe算法是TCP的早期版本。它的核心思想是:讓cwnd以指數(shù)增長(zhǎng)方式迅速逼進(jìn)可用信道容量,然后慢慢接近均衡。Tahoe包括3個(gè)基本的擁塞控制算法:“慢啟動(dòng)”、“擁塞避免”和“快速重傳”。
(1)慢啟動(dòng):避免了連接建立時(shí)突發(fā)數(shù)據(jù)流對(duì)網(wǎng)絡(luò)的沖擊。
初始設(shè)置cwnd為1,并按指數(shù)型方式增長(zhǎng),直至cwnd超過(guò)ssthresh。
當(dāng)cwnd>=ssthresh時(shí),Tahoe進(jìn)入擁塞避免階段。
(2)擁塞避免:限制傳輸過(guò)程中無(wú)限制的速率增長(zhǎng),避免由此可能導(dǎo)致的擁塞。
cwnd以線性方式增長(zhǎng)。
如果發(fā)生超時(shí)或者連續(xù)收到3個(gè)重復(fù)ACK,Tahoe認(rèn)為發(fā)生了擁塞。
對(duì)于超時(shí),置ssthresh為當(dāng)前擁塞窗口的一半,cwnd=1,轉(zhuǎn)入慢啟動(dòng)。
如果收到3個(gè)連續(xù)ACK,則Tahoe進(jìn)入快速重傳階段。
(3)快速重傳:根據(jù)3個(gè)重復(fù)的應(yīng)答報(bào)文來(lái)判斷丟包,減少了超時(shí)重傳的發(fā)生,加快了源端對(duì)擁塞的響應(yīng),使得擁塞能快速消除。立即重傳丟失的分組,同時(shí)置ssthresh為當(dāng)前擁塞窗口的一半,cwnd=1,轉(zhuǎn)入慢啟動(dòng)。
Tahoe算法存在著不足之處:在收到3個(gè)重復(fù)ACK或在超時(shí)的情況下,Tahoe置cwnd為1,然后進(jìn)入慢啟動(dòng)階段。這一方面會(huì)引起網(wǎng)絡(luò)的激烈振蕩,另一方面大大降低了網(wǎng)絡(luò)的利用率。
3.2TCPReno
針對(duì)Tahoe算法的不足之處,1990年Jacobson在Tahoe的基礎(chǔ)上提出了改進(jìn)算法Reno。改進(jìn)主要有兩個(gè)方面:一是對(duì)于收到連續(xù)3個(gè)重復(fù)ACK,算法不經(jīng)過(guò)慢啟動(dòng),而直接進(jìn)入擁塞避免階段;二是增加了快速重傳/快速恢復(fù)機(jī)制。具體實(shí)現(xiàn)過(guò)程為:
(1)收到三個(gè)重復(fù)的ACK,進(jìn)入快速重傳/快速恢復(fù),此時(shí)ssthresh設(shè)置為當(dāng)前擁塞窗口的一半。
(2)重傳丟失的數(shù)據(jù)包,并置cwnd=cwnd+ndup(ndup為收到的重復(fù)ACK數(shù))。
(3)發(fā)送新的數(shù)據(jù)包。
(4)當(dāng)收到非重復(fù)的ACK時(shí),cwnd=ssthresh。
(5)進(jìn)入擁塞避免階段。
從上面的過(guò)程可以看出,Reno在收到3個(gè)重復(fù)ACK后,就轉(zhuǎn)入快速重傳/快速恢復(fù)階段;而遇到超時(shí)時(shí),Reno和Tahoe一樣進(jìn)入慢啟動(dòng)階段。
Reno目前被廣泛采用,以其算法的簡(jiǎn)單、有效和魯棒性成為T(mén)CP源算法的主流。但是如果在一個(gè)發(fā)送窗口內(nèi)有多個(gè)包丟失時(shí),該算法不能有效恢復(fù)出來(lái),為此提出了一些改進(jìn),如NewReno、Sack等。
3.3 TCP NewReno
NewReno對(duì)Reno中“快速恢復(fù)”算法進(jìn)行了補(bǔ)充,它考慮了一個(gè)發(fā)送窗口內(nèi)多個(gè)報(bào)文同時(shí)丟失的情況。在Reno算法中,發(fā)送方收到一個(gè)不重復(fù)的應(yīng)答后就退出“快速恢復(fù)”狀態(tài)。而在NewReno中,只有當(dāng)所有報(bào)文都被應(yīng)答后才退出“快速恢復(fù)”狀態(tài)。
具體執(zhí)行過(guò)程是:在快速恢復(fù)期間,TCP發(fā)送端收到一個(gè)ACK后,發(fā)送端通過(guò)此ACK應(yīng)答推斷出下一個(gè)丟失的數(shù)據(jù)包序列號(hào),并且立即重傳那個(gè)數(shù)據(jù)包。這樣,NewReno在每個(gè)RTT內(nèi)重傳一個(gè)丟失的數(shù)據(jù)包,直到發(fā)生多個(gè)數(shù)據(jù)包丟失的窗口中所有丟失數(shù)據(jù)包被重傳,而不是等到超時(shí)。在這個(gè)期間如果還有其它重復(fù)的ACK到來(lái),則繼續(xù)快速恢復(fù)算法,直到在快速恢復(fù)初始時(shí)所有未確認(rèn)數(shù)據(jù)包都被確認(rèn)。
NewReno的實(shí)現(xiàn)只要修改TCP發(fā)送端的實(shí) 現(xiàn)代碼,實(shí)現(xiàn)簡(jiǎn)單。
3.4 SACK(selective acknowledgement,選擇性應(yīng)答)
SACK也關(guān)注一個(gè)窗口內(nèi)有多個(gè)報(bào)文的丟失,它使用“選擇性重傳”策略,提高TCP在擁塞較嚴(yán)重且一個(gè)窗口中有多個(gè)分組丟失時(shí)的性能。SACK的基本思想是:接收方TCP發(fā)送SACK分組來(lái)通知發(fā)送方接收數(shù)據(jù)的情況,這樣源端就能準(zhǔn)確的知道哪些數(shù)據(jù)包被正確的傳到接收端,從而避免不必要的重傳,減少時(shí)延,提高網(wǎng)絡(luò)吞吐量。
SACK算法是對(duì)Reno算法的改進(jìn)。它的改進(jìn)之處在于:在快速恢復(fù)階段,SACK保持一個(gè)變量pipe來(lái)表示出現(xiàn)在路由器上報(bào)文的估計(jì)數(shù)量。當(dāng)pipe小于擁塞窗口大小時(shí),源端只發(fā)送一個(gè)新報(bào)文分組或重發(fā)一個(gè)老報(bào)文,pipe加1;當(dāng)發(fā)送端接收到一個(gè)帶SACK選項(xiàng)的重復(fù)ACK時(shí),表明新數(shù)據(jù)已被接收端接收,pipe減1;此外,對(duì)收到的“恢復(fù)ACK”使用特殊的處理方法,對(duì)pipe變量值減2。
SACK算法降低了不必要的重傳,能有效的從多個(gè)數(shù)據(jù)包丟失中恢復(fù)。但是它的實(shí)現(xiàn)需要修改TCP發(fā)送端和接收端的實(shí)現(xiàn)代碼,增加了TCP的復(fù)雜性,不易大規(guī)模的應(yīng)用。
3.5Vegas算法
Vegas算法是一個(gè)得到普遍認(rèn)可,但是未能獲得廣泛應(yīng)用的算法。Vegas與上述介紹的算法不同,它以RTT的變化作為擁塞信號(hào),調(diào)節(jié)源端的發(fā)送速率。如果發(fā)現(xiàn)RTT變大,Vegas就認(rèn)為網(wǎng)絡(luò)發(fā)生擁塞,開(kāi)始減小cwnd;如果RTT變小,Vegas則解除擁塞,再次增加cwnd。這樣,在理想情況下,cwnd值會(huì)穩(wěn)定在一個(gè)合適的范圍內(nèi)。Vegas的重傳策略與上述算法也不同,它是在收到一個(gè)重復(fù)ACK后,比較數(shù)據(jù)包發(fā)出的時(shí)間和當(dāng)前時(shí)間,然后決定是否重發(fā)。這樣能更及時(shí)地重傳丟失的數(shù)據(jù)包,提高響應(yīng)速度。
該算法采用RTT的改變來(lái)判斷網(wǎng)絡(luò)的可用帶寬,能較好的預(yù)測(cè)網(wǎng)絡(luò)帶寬的使用情況,其公平性、效率都較好。但是,由于Vegas與其它算法在競(jìng)爭(zhēng)帶寬方面存在不公平現(xiàn)象,因此未能在Internet上普遍采用,還需不斷改進(jìn)。
4算法性能比較
在上述介紹的幾種擁塞控制算法中,Tahoe在快速重傳后轉(zhuǎn)向慢啟動(dòng)算法,這樣不能有效地利用網(wǎng)絡(luò)帶寬并且還引入較大的時(shí)延;Reno在Tahoe的基礎(chǔ)上提出了快速恢復(fù)算法,對(duì)于單個(gè)數(shù)據(jù)包的丟失在傳輸性能上有顯著的提高,但是它不能有效的處理多個(gè)包丟失的情況;于是提出了改進(jìn)算法NewReno和SACK,兩種改進(jìn)措施都大大提高了TCP的傳輸性能;Vegas在理論上是可行的,但是在實(shí)際應(yīng)用中存在著局限性,因而未能得到廣泛應(yīng)用。TCP的擁塞控制算法還在不斷的改進(jìn)。
5總結(jié)
端到端的擁塞控制是網(wǎng)絡(luò)擁塞控制的基本前提,只有將端到端的擁塞控制工作做好,才能為網(wǎng)絡(luò)中的整體擁塞控制措施打下良好的基礎(chǔ)。隨著Internet的迅速擴(kuò)展,網(wǎng)絡(luò)中的數(shù)據(jù)流負(fù)載處理會(huì)快速加重,如果端節(jié)點(diǎn)與網(wǎng)絡(luò)擁塞控制關(guān)系能夠很好的配合,網(wǎng)絡(luò)負(fù)載將會(huì)大大減輕,有利于傳輸性能和資源利用。如何建立有限的協(xié)調(diào)機(jī)制,有待于進(jìn)一步研究。
現(xiàn)有的TCP擁塞控制算法都存在一些局限性,因此,對(duì)網(wǎng)絡(luò)擁塞控制的進(jìn)一步研究具有極其重要的理論和應(yīng)用價(jià)值。
參考文獻(xiàn)
[1]馮波,基于NS的TCP/IP擁塞控制算法研究,燕山大學(xué)碩士學(xué)位論文,2003.9
[2]徐恪,吳建平,徐明偉高等計(jì)算機(jī)網(wǎng)絡(luò)—體系結(jié)構(gòu)、協(xié)議機(jī)制、算法設(shè)計(jì)與路由器技術(shù),機(jī)械工業(yè)出版社,2003.9,Page299-322
[3]章淼,吳建平,林闖互聯(lián)網(wǎng)端到端擁塞控制研究綜述,軟件學(xué)報(bào),2002.13,Page354-363
[4] Sally Floyd,A Report on Some Recent Developments in TCP Congestion Control,IEEE Communications Magazine,April 2001,Page1-7
[5] Sally Floyd,Senior Member,IEEE,and Kevin Fall,Promoting the Use of End-to-End Congestion Control in the Internet,IEEE/ACM TRANSACTIONS ON NETWORKING,August 1999,Page458-472