計(jì)算機(jī)種類繁多。實(shí)際來看，計(jì)算機(jī)總體上是處理信息的工具。根據(jù)圖靈機(jī)理論，一部具有最基本功能的計(jì)算機(jī)應(yīng)當(dāng)能夠完成任何其它計(jì)算機(jī)能做的事情。下面是學(xué)習(xí)啦小編給大家推薦的大學(xué)計(jì)算機(jī)專業(yè)相關(guān)論文范文，希望大家喜歡!

　　大學(xué)計(jì)算機(jī)專業(yè)相關(guān)論文范文篇一

　　《淺析軟件項(xiàng)目過程管理矩陣模型研究與實(shí)踐》

　　關(guān)鍵詞：軟件項(xiàng)目管理;過程控制;矩陣模型;需求管理

　　摘要：軟件項(xiàng)目由于應(yīng)用的領(lǐng)域不同，一般涉及眾多的業(yè)務(wù)知識領(lǐng)域，項(xiàng)目成果也應(yīng)以軟件的邏輯產(chǎn)品來體現(xiàn)，其最終成果及實(shí)現(xiàn)過程的可見性、可度量性相對較弱。因此，軟件項(xiàng)目管理比一般工程項(xiàng)目要復(fù)雜得多?；谲浖?xiàng)目管理的特點(diǎn)分析，并結(jié)合軟件項(xiàng)目開發(fā)管理經(jīng)驗(yàn)，討論了軟件項(xiàng)目組織架構(gòu)、計(jì)劃與過程控制等軟件項(xiàng)目管理要素，提出了矩陣式項(xiàng)目管理模型，分析了該模型中業(yè)務(wù)知識與計(jì)算機(jī)技術(shù)共同作用所能達(dá)到的最佳效果，討論了需求管理模型及其應(yīng)用，實(shí)踐證明該模型是行之有效的。

　　O引言

　　項(xiàng)目管理是伴隨著項(xiàng)目進(jìn)行而進(jìn)行的，是一種為了滿足甚至超越項(xiàng)目所有者對項(xiàng)目的期望而將理論知識、技能、工具和技巧應(yīng)用到項(xiàng)目中的管理活動，是一門關(guān)于項(xiàng)目資金、時(shí)間、人力等資源控制的管理科學(xué)。

　　顧名思義，軟件項(xiàng)目管理就是項(xiàng)目管理在軟件領(lǐng)域的應(yīng)用，是一種為了能夠按照預(yù)定的工期、質(zhì)量順利完成軟件項(xiàng)目而對成本、人員、進(jìn)度、質(zhì)量、風(fēng)險(xiǎn)等進(jìn)行控制管理的活動。其核心在于通過有效的管理，明確項(xiàng)目范圍，合理調(diào)配人力資源，提高項(xiàng)目團(tuán)隊(duì)的整體開發(fā)能力，優(yōu)化項(xiàng)目執(zhí)行過程，控制項(xiàng)目成本，為用戶提供滿意的軟件產(chǎn)品。

　　1軟件項(xiàng)目管理的特點(diǎn)

　　軟件是一種特殊的產(chǎn)品，這種產(chǎn)品的特殊性之一就是它的生產(chǎn)活動是以項(xiàng)目的形式進(jìn)行的，因此，項(xiàng)目管理對軟件生產(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)去剛性的度量評價(jià)。而軟件產(chǎn)品客觀上具有“不可見性”，表現(xiàn)在它沒有一個(gè)可見的實(shí)物，還表現(xiàn)在其度量指標(biāo)也不能像度量實(shí)物那樣具有明確性。有效的項(xiàng)目管理就是要使軟件及其生產(chǎn)過程由不可見、不可度量變成可見和可度量。

　　(2)重視應(yīng)用領(lǐng)域的業(yè)務(wù)知識。

　　對于計(jì)算機(jī)應(yīng)用軟件來說，它并不單純是計(jì)算機(jī)技術(shù)問題，更多地表現(xiàn)在它所服務(wù)的業(yè)務(wù)領(lǐng)域的知識技能。如企業(yè)ERP、SCM等應(yīng)用軟件項(xiàng)目，計(jì)算機(jī)只是它的載體，計(jì)算機(jī)技術(shù)往往并不起決定作用，而與之相關(guān)的業(yè)務(wù)知識、管理知識顯得更加重要。

　　(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ú)斗的作坊式開發(fā)方式顯然已經(jīng)無法適應(yīng)這種信息技術(shù)發(fā)展的需要。在一個(gè)大型信息系統(tǒng)工程項(xiàng)目里，需要系統(tǒng)策劃人員、分析設(shè)計(jì)人員、編程人員、測試人員和用戶等眾多人員的共同參與和密切配合，如何將可用資源有效地結(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)對里程碑文檔的評審，并把文檔作為階段成果的重要體現(xiàn)和下階段的基礎(chǔ)。

　　(5)重視培訓(xùn)與服務(wù)的價(jià)值。

　　培訓(xùn)與服務(wù)是發(fā)掘軟件產(chǎn)品價(jià)值的重要手段。一個(gè)軟件產(chǎn)品，如果沒有人使用就不能形成價(jià)值，如果不會使用，就可能降低軟件的價(jià)值。服務(wù)的優(yōu)劣已經(jīng)直接影響軟件的使用價(jià)值并決定軟件產(chǎn)品的生命周期?？傊浖?xiàng)目管理重視培訓(xùn)與服務(wù)在軟件增值中的意義。

　　2管理架構(gòu)矩陣模型

　　規(guī)范化的管理體現(xiàn)在：有完整的基于軟件開發(fā)標(biāo)準(zhǔn)(如CMM、ISO等)的開發(fā)流程;有基于這個(gè)流程的完整詳細(xì)的開發(fā)計(jì)劃;有基于開發(fā)計(jì)劃的成本預(yù)算和成本控制方法;有明確的階段檢查措施和評價(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)目管理過程中，項(xiàng)目經(jīng)理起著至關(guān)重要的作用。對于項(xiàng)目經(jīng)理，目前有兩種觀點(diǎn)：一種認(rèn)為軟件項(xiàng)目經(jīng)理應(yīng)該是計(jì)算機(jī)某方面的應(yīng)用專家，能夠?qū)?xiàng)目組成員給予技術(shù)指導(dǎo)，如此才有能力合理安排工作。另一種觀點(diǎn)則認(rèn)為，項(xiàng)目經(jīng)理應(yīng)該是職業(yè)經(jīng)理，他可以不是計(jì)算機(jī)技術(shù)專家，但應(yīng)該是管理專家，具備輕松調(diào)配各部門資源的技巧和有效地組織、管理開發(fā)隊(duì)伍、協(xié)調(diào)溝通的能力，他的作用主要體現(xiàn)在協(xié)調(diào)、管理、合理安排成員的工作，控制項(xiàng)目進(jìn)度和費(fèi)用，與用戶溝通，等等。事實(shí)上，在一般意義上，不管是技術(shù)型專家還是管理型專家都無法滿足現(xiàn)代軟件項(xiàng)目管理的需要。在傳統(tǒng)的垂直型管理模式中，項(xiàng)目經(jīng)理要直接管理到具體的程序員，一般只適用于不太復(fù)雜的技術(shù)型項(xiàng)目，它忽視了中間層的作用，不便于發(fā)揮員工的積極性。而扁平化管理意味著要面對很多的直接下級，對管理者提出了很高的管理要求，特別對于大型項(xiàng)目來說，可能涉及到很多業(yè)務(wù)領(lǐng)域知識，他都要面面俱到，這對于一個(gè)不管是技術(shù)型還是管理型項(xiàng)目經(jīng)理來說似乎都很難做到，即使對于所謂既懂專業(yè)又懂管理的全才專家來說，也不可能要求他在各個(gè)方面都是最優(yōu)秀的。

　　眾所周知的事實(shí)是，找一個(gè)既懂專業(yè)又有項(xiàng)目管理經(jīng)驗(yàn)的專家往往比較困難，但如果找?guī)讉€(gè)或懂專業(yè)或懂項(xiàng)目管理的專家也許并不困難。一個(gè)好的軟件項(xiàng)目團(tuán)隊(duì)就應(yīng)該是它可以有效整合各成員的能力，使集體的能量達(dá)到最大化。因此，與其找一個(gè)所謂全才的項(xiàng)目經(jīng)理，還不如構(gòu)建規(guī)范的管理架構(gòu)。根據(jù)筆者多年的軟件開發(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ì)中備人所長，使集體的智慧得以充分張揚(yáng)。每個(gè)人所做的工作(包括他的知識)都已經(jīng)留存下來了，即使項(xiàng)目經(jīng)理因故離職，接任者也可以從容接手，從而降低了因?yàn)槿藛T流動可能對項(xiàng)目造成的風(fēng)險(xiǎn)。

　　如表1所示，是某項(xiàng)目管理架構(gòu)的矩陣模型。每個(gè)業(yè)務(wù)子系統(tǒng)有一個(gè)業(yè)務(wù)專家負(fù)責(zé)，他們一般都精通某一個(gè)方面的業(yè)務(wù)，由他們直接面對用戶，可以與用戶業(yè)務(wù)人員有更多的共同語言，便于交流，更容易捕獲用戶需求。而在軟件開發(fā)的每個(gè)階段，按軟件工程生命周期，各階段由具有技術(shù)專長的技術(shù)人員負(fù)責(zé)。所以，整體上可以充分發(fā)揮各業(yè)務(wù)負(fù)責(zé)人精通業(yè)務(wù)領(lǐng)域知識和階段負(fù)責(zé)人精通相關(guān)技術(shù)的優(yōu)勢，使項(xiàng)目團(tuán)隊(duì)整體成為名副其實(shí)的既懂專業(yè)又懂管理的專家。

　　矩陣管理可以更好地發(fā)揮各專業(yè)人員的業(yè)務(wù)專長，又能更好地發(fā)揮各技術(shù)層面技術(shù)人員的特長，項(xiàng)目經(jīng)理重要的工作就是協(xié)調(diào)，重點(diǎn)在于如何結(jié)合眾多資源控制整個(gè)開發(fā)進(jìn)程。矩陣模型也有利于軟件公司人才戰(zhàn)略，有利于組織內(nèi)部人才的培養(yǎng)，充分展現(xiàn)個(gè)人的發(fā)展空間。大多數(shù)軟件企業(yè)也許都很難有精通所有專業(yè)的全才，但都擁有為數(shù)眾多精通某一類業(yè)務(wù)的系統(tǒng)分析師，或精通某一類專門技術(shù)的專門人才。根據(jù)矩陣模型，公司可以培養(yǎng)員工向不同方向發(fā)展，有技術(shù)特長的，培養(yǎng)他發(fā)展技術(shù)的深度，有其他專業(yè)特長的，比如精通稅務(wù)、金融、企業(yè)管理等，則培養(yǎng)成業(yè)務(wù)專家。這樣，在人盡其才的同時(shí)，又有利于留住人才，穩(wěn)定了軟件開發(fā)隊(duì)伍。

　　3計(jì)劃與過程控制

　　項(xiàng)目計(jì)劃包括風(fēng)險(xiǎn)管理計(jì)劃、質(zhì)量管理計(jì)劃、人力資源計(jì)劃、環(huán)境資源計(jì)劃等。軟件項(xiàng)目計(jì)劃和過程控制為消除或削弱軟件的“不可見”帶來的不確定性提供了很好的保障措施?；谌蝿?wù)分解(WBS)的工作分配和項(xiàng)目組織結(jié)構(gòu)，明確每個(gè)項(xiàng)目開發(fā)人員的責(zé)任以及他們之間的連接，把整個(gè)項(xiàng)目周期劃分為若干個(gè)小的階段，每個(gè)階段都有明確的目標(biāo)和階段成果及其確認(rèn)準(zhǔn)則。由于把每個(gè)階段要完成的工作、預(yù)期的成果都清晰地描述出來了，一方面，可以使用戶不斷看到一個(gè)個(gè)階段成果，而不是在項(xiàng)目全部完工后才看到一個(gè)大的成果，增強(qiáng)了用戶的信心;另一方面。通過明確的階段結(jié)果，隨時(shí)收集有關(guān)項(xiàng)目進(jìn)程數(shù)據(jù)，按計(jì)劃規(guī)定進(jìn)行進(jìn)度管理，使開發(fā)過程和階段成果都是可見的，也便于發(fā)現(xiàn)問題、控制開發(fā)過程，不至于什么問題都要到最后才一次暴露，減少了項(xiàng)目風(fēng)險(xiǎn)。

　　當(dāng)然，如果僅僅有好的項(xiàng)目計(jì)劃而缺乏有效的執(zhí)行機(jī)制和監(jiān)督措施，項(xiàng)目仍然可能失去控制。成功項(xiàng)目的標(biāo)志是在規(guī)定的時(shí)間、合理開支的條件下，完成約定的需求，實(shí)現(xiàn)系統(tǒng)的最終目標(biāo)。有效實(shí)施項(xiàng)目進(jìn)度控制是項(xiàng)目成功的重要保障，是每一個(gè)項(xiàng)目經(jīng)理必須非常重視的工作。實(shí)現(xiàn)有效項(xiàng)目過程控制的方法主要是通過定期和不定期的檢查體現(xiàn)的。

　　(1)階段檢查。

　　不定期的階段性檢查，一般在關(guān)鍵任務(wù)或里程碑任務(wù)的計(jì)劃完成時(shí)進(jìn)行的，即在項(xiàng)目的每個(gè)階段結(jié)束時(shí)都要經(jīng)過詳細(xì)的評估。檢查的重點(diǎn)是該階段里程碑任務(wù)是否完整地實(shí)現(xiàn)了，是否可以轉(zhuǎn)入下階段的工作。

　　(2)定期檢查。

　　為了隨時(shí)掌控項(xiàng)目進(jìn)度執(zhí)行情況，建立定期信息報(bào)告制度是一個(gè)行之有效的措施。定期的檢查一般分周例會和月例會，例會檢查的重點(diǎn)是：需求列表、風(fēng)險(xiǎn)列表、計(jì)劃執(zhí)行情況、質(zhì)量保證情況等。通過周報(bào)月報(bào)，溝通并掌握各方信息，對存在的問題和困難進(jìn)行匯總，提交例會處理解決，降低不確定性因素對項(xiàng)目工期的影響，保證項(xiàng)目順利進(jìn)行。

　　定期或不定期地對項(xiàng)目進(jìn)度計(jì)劃表進(jìn)行檢查，對于不合格的項(xiàng)目進(jìn)度計(jì)劃表或未按照項(xiàng)目進(jìn)度計(jì)劃表執(zhí)行的項(xiàng)目給予相應(yīng)處理，及時(shí)發(fā)現(xiàn)問題，盡早調(diào)整計(jì)劃偏差，最大限度地避免損失。這樣，在項(xiàng)目進(jìn)行過程中就比較容易把握每個(gè)階段項(xiàng)目的進(jìn)展情況，方便對項(xiàng)目組成員的績效進(jìn)行階段性評估，便于統(tǒng)一項(xiàng)目經(jīng)理和客戶的認(rèn)識。增加項(xiàng)目風(fēng)險(xiǎn)的可控性。

　　4需求管理矩陣模型

　　軟件項(xiàng)目的最大難點(diǎn)往往在于需求的不確定性，所以，有人認(rèn)為好的需求是軟件項(xiàng)目成功的一半。需求的困難主要表現(xiàn)在計(jì)算機(jī)技術(shù)人員與用戶業(yè)務(wù)人員由于不同的語境，存在溝通困難。用戶業(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)確地理解需求，從而影響了需求的最終描述。另一方面，對于管理信息系統(tǒng)來說，需求的不確定還表現(xiàn)在業(yè)務(wù)流程的變化上，特別對于現(xiàn)階段還處于不斷變革時(shí)期的我國企業(yè)來說，情況更是如此。

　　一般來說，用戶在看到最終系統(tǒng)以后，通過不斷地應(yīng)用實(shí)踐，激發(fā)了用戶的聯(lián)想，就可能提出新的或改進(jìn)的需求。所以，在項(xiàng)目一開始，技術(shù)人員就必須對此有充分的認(rèn)識，既要盡可能全面了解現(xiàn)有需求，也要充分預(yù)計(jì)到可能的需求變更，為系統(tǒng)設(shè)計(jì)留有變更或擴(kuò)充的余地。另一方面，應(yīng)該盡可能讓用戶盡早介入，直接參與階段評審和驗(yàn)收，以便及時(shí)發(fā)現(xiàn)需求執(zhí)行偏失，不至于什么都等到全部完工后才發(fā)現(xiàn)問題，才一并解決問題。在項(xiàng)目的后期改正一個(gè)錯(cuò)誤的代價(jià)往往是在前期的數(shù)倍。所以，需求管理成為軟件項(xiàng)目成敗的另一個(gè)關(guān)鍵因索之一。

　　根據(jù)筆者的經(jīng)驗(yàn)，建立需求矩陣跟蹤表是進(jìn)行需求管理很好的工具。通過跟蹤表，項(xiàng)目涉眾可以隨時(shí)了解關(guān)于軟件需求的實(shí)現(xiàn)過程。用戶可以從中隨時(shí)看到階段性成果，方便用戶及時(shí)測試、確認(rèn)已實(shí)現(xiàn)的需求，便于用戶積極參與，便于及時(shí)發(fā)現(xiàn)問題，改正問題。

　　5結(jié)束語

　　當(dāng)代信息技術(shù)正以超乎尋常的速度發(fā)展，軟件項(xiàng)目規(guī)模不斷擴(kuò)大，應(yīng)用日趨復(fù)雜，失敗的案例屢見不鮮，人們逐漸把眼光聚焦到關(guān)于軟件項(xiàng)目管理方法的研究，項(xiàng)目管理正逐漸成為當(dāng)今世界解決軟件危機(jī)的一種主流管理方法。矩陣模型已在大量的工程實(shí)踐中被證明是行之有效的。

　　大學(xué)計(jì)算機(jī)專業(yè)相關(guān)論文范文篇二

　　《基于TCP的擁塞控制策略研究》

　　摘要：隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，網(wǎng)絡(luò)擁塞日益嚴(yán)重，如何解決擁塞，充分、高效地利用網(wǎng)絡(luò)資源，成為當(dāng)今急需解決的問題。由于Internet上大多數(shù)業(yè)務(wù)都采用TCP協(xié)議，因此TCP的擁塞控制機(jī)制對控制網(wǎng)絡(luò)擁塞具有特別重要的意義。本文分析了TCP的四個(gè)交互式擁塞控制算法：慢啟動、擁塞避免、快速重傳和快速恢復(fù)，介紹了TCP基于窗口的擁塞控制策略和目前常用端到端擁塞控制算法，并對它們的性能進(jìn)行仿真比較。

　　關(guān)鍵字：AIMD;擁塞控制;TCP;NS

　　1引言

　　在Internet上，隨著信息傳送量的逐漸增大和網(wǎng)絡(luò)組成的日益復(fù)雜，網(wǎng)絡(luò)發(fā)生擁塞的可能性越來越大。網(wǎng)絡(luò)中的擁塞來源于網(wǎng)絡(luò)資源和網(wǎng)絡(luò)流量分布的不均衡性，它不會隨著網(wǎng)絡(luò)處理能力的提高而消除。目前為止擁塞問題還沒有得到很好的解決，因此網(wǎng)絡(luò)擁塞的避免和控制成為越來越重要和急待解決的問題。

　　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)問題。

　　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ù)量，是來自源端的流量控制。

　　(2)通告窗口(awnd)：連接建立及傳輸過程中，接收端向源端通告的最大可接收速率，是來自接收端的流量控制。

　　(3)有效窗口(win)：源端數(shù)據(jù)發(fā)送的實(shí)際窗口大小，限定為win=min(cwnd，awnd)。

　　由于計(jì)算機(jī)計(jì)算能力和存儲能力的提高，通告窗口一般都比較大，因此當(dāng)前發(fā)送窗口的大小大多數(shù)情況下等于擁塞窗口的大小。

　　AIMD的具體工作過程為：

　　(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)連接剛建立或超時(shí)時(shí)，進(jìn)入慢啟動階段。

　　當(dāng)新建TCP連接時(shí)，擁塞窗口(cwnd)被初始化為一個(gè)數(shù)據(jù)包大小。源端按cwnd大小發(fā)送數(shù)據(jù)，每收到一個(gè)ACK確認(rèn)，就增加一個(gè)數(shù)據(jù)包發(fā)送量，這樣慢啟動階段cwnd隨RTT呈指數(shù)級增長。

　　慢啟動采用逐漸增大cwnd的方法，可以防止TCP在啟動一個(gè)連接時(shí)向網(wǎng)絡(luò)發(fā)送過多的數(shù)據(jù)包而造成不必要的數(shù)據(jù)丟失和網(wǎng)絡(luò)擁塞，并且它還能夠避免采用單純的AIMD算法造成的吞吐量增加過慢的問題。

　　為了防止cwnd的無限制增長引起網(wǎng)絡(luò)擁塞，引入一個(gè)狀態(tài)變量：慢啟動閾值ssthresh。

　　當(dāng)cwnd

　　當(dāng)cwnd>ssthresh時(shí)，使用擁塞避免算法，減緩cwnd的增長速度。

　　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)入擁塞避免階段。

　　在擁塞避免階段，慢啟動域值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呈線性增長。

　　2.2.3快速重傳和快速恢復(fù)階段

　　在擁塞避免階段，當(dāng)數(shù)據(jù)包超時(shí)時(shí)，cwnd被置為1，重新進(jìn)入慢啟動階段，這會導(dǎo)致過大地減小發(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)入慢啟動階段。

　　這種方法避免了數(shù)據(jù)包超時(shí)后就重新進(jìn)入慢啟動階段，提高了TCP連接的吞吐量。

　　3典型TCP擁塞控制算法分析

　　3.1TCPTahoe算法

　　Tahoe算法是TCP的早期版本。它的核心思想是：讓cwnd以指數(shù)增長方式迅速逼進(jìn)可用信道容量，然后慢慢接近均衡。Tahoe包括3個(gè)基本的擁塞控制算法：“慢啟動”、“擁塞避免”和“快速重傳”。

　　(1)慢啟動：避免了連接建立時(shí)突發(fā)數(shù)據(jù)流對網(wǎng)絡(luò)的沖擊。

　　初始設(shè)置cwnd為1，并按指數(shù)型方式增長，直至cwnd超過ssthresh。

　　當(dāng)cwnd>=ssthresh時(shí)，Tahoe進(jìn)入擁塞避免階段。

　　(2)擁塞避免：限制傳輸過程中無限制的速率增長，避免由此可能導(dǎo)致的擁塞。

　　cwnd以線性方式增長。

　　如果發(fā)生超時(shí)或者連續(xù)收到3個(gè)重復(fù)ACK，Tahoe認(rèn)為發(fā)生了擁塞。

　　對于超時(shí)，置ssthresh為當(dāng)前擁塞窗口的一半，cwnd=1，轉(zhuǎn)入慢啟動。

　　如果收到3個(gè)連續(xù)ACK，則Tahoe進(jìn)入快速重傳階段。

　　(3)快速重傳：根據(jù)3個(gè)重復(fù)的應(yīng)答報(bào)文來判斷丟包，減少了超時(shí)重傳的發(fā)生，加快了源端對擁塞的響應(yīng)，使得擁塞能快速消除。立即重傳丟失的分組，同時(shí)置ssthresh為當(dāng)前擁塞窗口的一半，cwnd=1，轉(zhuǎn)入慢啟動。

　　Tahoe算法存在著不足之處：在收到3個(gè)重復(fù)ACK或在超時(shí)的情況下，Tahoe置cwnd為1，然后進(jìn)入慢啟動階段。這一方面會引起網(wǎng)絡(luò)的激烈振蕩，另一方面大大降低了網(wǎng)絡(luò)的利用率。

　　3.2TCPReno

　　針對Tahoe算法的不足之處，1990年Jacobson在Tahoe的基礎(chǔ)上提出了改進(jìn)算法Reno。改進(jìn)主要有兩個(gè)方面：一是對于收到連續(xù)3個(gè)重復(fù)ACK，算法不經(jīng)過慢啟動，而直接進(jìn)入擁塞避免階段;二是增加了快速重傳/快速恢復(fù)機(jī)制。具體實(shí)現(xiàn)過程為：

　　(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)入擁塞避免階段。

　　從上面的過程可以看出，Reno在收到3個(gè)重復(fù)ACK后，就轉(zhuǎn)入快速重傳/快速恢復(fù)階段;而遇到超時(shí)時(shí)，Reno和Tahoe一樣進(jìn)入慢啟動階段。

　　Reno目前被廣泛采用，以其算法的簡單、有效和魯棒性成為TCP源算法的主流。但是如果在一個(gè)發(fā)送窗口內(nèi)有多個(gè)包丟失時(shí)，該算法不能有效恢復(fù)出來，為此提出了一些改進(jìn)，如NewReno、Sack等。

　　3.3 TCP NewReno

　　NewReno對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í)行過程是：在快速恢復(fù)期間，TCP發(fā)送端收到一個(gè)ACK后，發(fā)送端通過此ACK應(yīng)答推斷出下一個(gè)丟失的數(shù)據(jù)包序列號，并且立即重傳那個(gè)數(shù)據(jù)包。這樣，NewReno在每個(gè)RTT內(nèi)重傳一個(gè)丟失的數(shù)據(jù)包，直到發(fā)生多個(gè)數(shù)據(jù)包丟失的窗口中所有丟失數(shù)據(jù)包被重傳，而不是等到超時(shí)。在這個(gè)期間如果還有其它重復(fù)的ACK到來，則繼續(xù)快速恢復(fù)算法，直到在快速恢復(fù)初始時(shí)所有未確認(rèn)數(shù)據(jù)包都被確認(rèn)。

　　NewReno的實(shí)現(xiàn)只要修改TCP發(fā)送端的實(shí) 現(xiàn)代碼，實(shí)現(xià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分組來通知發(fā)送方接收數(shù)據(jù)的情況，這樣源端就能準(zhǔn)確的知道哪些數(shù)據(jù)包被正確的傳到接收端，從而避免不必要的重傳，減少時(shí)延，提高網(wǎng)絡(luò)吞吐量。

　　SACK算法是對Reno算法的改進(jìn)。它的改進(jìn)之處在于：在快速恢復(fù)階段，SACK保持一個(gè)變量pipe來表示出現(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;此外，對收到的“恢復(fù)ACK”使用特殊的處理方法，對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的變化作為擁塞信號，調(diào)節(jié)源端的發(fā)送速率。如果發(fā)現(xiàn)RTT變大，Vegas就認(rèn)為網(wǎng)絡(luò)發(fā)生擁塞，開始減小cwnd;如果RTT變小，Vegas則解除擁塞，再次增加cwnd。這樣，在理想情況下，cwnd值會穩(wěn)定在一個(gè)合適的范圍內(nèi)。Vegas的重傳策略與上述算法也不同，它是在收到一個(gè)重復(fù)ACK后，比較數(shù)據(jù)包發(fā)出的時(shí)間和當(dāng)前時(shí)間，然后決定是否重發(fā)。這樣能更及時(shí)地重傳丟失的數(shù)據(jù)包，提高響應(yīng)速度。

　　該算法采用RTT的改變來判斷網(wǎng)絡(luò)的可用帶寬，能較好的預(yù)測網(wǎng)絡(luò)帶寬的使用情況，其公平性、效率都較好。但是，由于Vegas與其它算法在競爭帶寬方面存在不公平現(xiàn)象，因此未能在Internet上普遍采用，還需不斷改進(jìn)。

　　4算法性能比較

　　在上述介紹的幾種擁塞控制算法中，Tahoe在快速重傳后轉(zhuǎn)向慢啟動算法，這樣不能有效地利用網(wǎng)絡(luò)帶寬并且還引入較大的時(shí)延;Reno在Tahoe的基礎(chǔ)上提出了快速恢復(fù)算法，對于單個(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ù)載處理會快速加重，如果端節(jié)點(diǎn)與網(wǎng)絡(luò)擁塞控制關(guān)系能夠很好的配合，網(wǎng)絡(luò)負(fù)載將會大大減輕，有利于傳輸性能和資源利用。如何建立有限的協(xié)調(diào)機(jī)制，有待于進(jìn)一步研究。

　　現(xiàn)有的TCP擁塞控制算法都存在一些局限性，因此，對網(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