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

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

　　《淺析軟件項目過程管理矩陣模型研究與實踐》

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

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

　　O引言

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

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

　　1軟件項目管理的特點

　　軟件是一種特殊的產(chǎn)品，這種產(chǎn)品的特殊性之一就是它的生產(chǎn)活動是以項目的形式進行的，因此，項目管理對軟件生產(chǎn)具有決定性的意義。軟件項目管理除了具有一般項目管理的特點外，還有其獨特之處，主要表現(xiàn)在：

　　(1)軟件產(chǎn)品缺乏硬性度量指標(biāo)。

　　軟件的最大特點在于一個“軟”字，它不像建筑項目，最終可以有一個實物，可以用某一個標(biāo)準(zhǔn)去剛性的度量評價。而軟件產(chǎn)品客觀上具有“不可見性”，表現(xiàn)在它沒有一個可見的實物，還表現(xiàn)在其度量指標(biāo)也不能像度量實物那樣具有明確性。有效的項目管理就是要使軟件及其生產(chǎn)過程由不可見、不可度量變成可見和可度量。

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

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

　　(3)管理比技術(shù)本身更重要。

　　軟件項目是一項計算機技術(shù)、信息技術(shù)、管理科學(xué)等多學(xué)科交叉的系統(tǒng)工程。隨著信息技術(shù)的發(fā)展，軟件項目應(yīng)用領(lǐng)域不斷擴張、項目規(guī)模不斷擴大、項目業(yè)務(wù)日趨復(fù)雜，一個軟件從構(gòu)想到完成，需要大量的從事不同工作的人共同努力，個人單打獨斗的作坊式開發(fā)方式顯然已經(jīng)無法適應(yīng)這種信息技術(shù)發(fā)展的需要。在一個大型信息系統(tǒng)工程項目里，需要系統(tǒng)策劃人員、分析設(shè)計人員、編程人員、測試人員和用戶等眾多人員的共同參與和密切配合，如何將可用資源有效地結(jié)合在一起，并使之發(fā)揮最大效率，如何保證項目按照預(yù)定的時間將預(yù)先約定的軟件產(chǎn)品提交給客戶是軟件項目管理的核心任務(wù)。項目管理往往成為決定軟件項目成敗的重要因素。

　　(4)強調(diào)文檔的重要性。

　　文檔是軟件產(chǎn)品的重要組成部分，軟件項目管理以工程化的管理方法，強調(diào)規(guī)范文檔的重要性，在軟件生命周期的各個階段，強調(diào)對里程碑文檔的評審，并把文檔作為階段成果的重要體現(xiàn)和下階段的基礎(chǔ)。

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

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

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

　　規(guī)范化的管理體現(xiàn)在：有完整的基于軟件開發(fā)標(biāo)準(zhǔn)(如CMM、ISO等)的開發(fā)流程;有基于這個流程的完整詳細(xì)的開發(fā)計劃;有基于開發(fā)計劃的成本預(yù)算和成本控制方法;有明確的階段檢查措施和評價標(biāo)準(zhǔn);有明確的質(zhì)量管理體系和質(zhì)量保證實施手段，保證項目在可控狀態(tài)下進行。而這一切都需要有一個組織有效的管理團隊和運作規(guī)范的管理架構(gòu)。

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

　　眾所周知的事實是，找一個既懂專業(yè)又有項目管理經(jīng)驗的專家往往比較困難，但如果找?guī)讉€或懂專業(yè)或懂項目管理的專家也許并不困難。一個好的軟件項目團隊就應(yīng)該是它可以有效整合各成員的能力，使集體的能量達(dá)到最大化。因此，與其找一個所謂全才的項目經(jīng)理，還不如構(gòu)建規(guī)范的管理架構(gòu)。根據(jù)筆者多年的軟件開發(fā)、項目管理的實踐和經(jīng)驗，提出了“矩陣式”軟件項目管理模型。在這個模型中，項目經(jīng)理也只是其中的一個角色而已。他并不需要面面俱到，也不需要掌握項目的全部細(xì)節(jié)，他要做的全部工作就是按管理規(guī)范要求完成項目經(jīng)理這個角色所特有的工作。在這個架構(gòu)下，更便于發(fā)揮項目團隊中備人所長，使集體的智慧得以充分張揚。每個人所做的工作(包括他的知識)都已經(jīng)留存下來了，即使項目經(jīng)理因故離職，接任者也可以從容接手，從而降低了因為人員流動可能對項目造成的風(fēng)險。

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

　　矩陣管理可以更好地發(fā)揮各專業(yè)人員的業(yè)務(wù)專長，又能更好地發(fā)揮各技術(shù)層面技術(shù)人員的特長，項目經(jīng)理重要的工作就是協(xié)調(diào)，重點在于如何結(jié)合眾多資源控制整個開發(fā)進程。矩陣模型也有利于軟件公司人才戰(zhàn)略，有利于組織內(nèi)部人才的培養(yǎng)，充分展現(xiàn)個人的發(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ù)專家。這樣，在人盡其才的同時，又有利于留住人才，穩(wěn)定了軟件開發(fā)隊伍。

　　3計劃與過程控制

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

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

　　(1)階段檢查。

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

　　(2)定期檢查。

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

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

　　4需求管理矩陣模型

　　軟件項目的最大難點往往在于需求的不確定性，所以，有人認(rèn)為好的需求是軟件項目成功的一半。需求的困難主要表現(xiàn)在計算機技術(shù)人員與用戶業(yè)務(wù)人員由于不同的語境，存在溝通困難。用戶業(yè)務(wù)人員可能不清楚計算機系統(tǒng)實現(xiàn)細(xì)節(jié)，或并不知道需求人員到底需要了解什么，而計算機技術(shù)人員可能由于不熟悉業(yè)務(wù)，往往又缺乏引導(dǎo)用戶表達(dá)需求的業(yè)務(wù)素質(zhì)和技巧，所以，影響了雙方溝通和交流，造成的結(jié)果可能是用戶往往不能清楚地描述自己的需求或計算機人員不能準(zhǔn)確地理解需求，從而影響了需求的最終描述。另一方面，對于管理信息系統(tǒng)來說，需求的不確定還表現(xiàn)在業(yè)務(wù)流程的變化上，特別對于現(xiàn)階段還處于不斷變革時期的我國企業(yè)來說，情況更是如此。

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

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

　　5結(jié)束語

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

　　大學(xué)計算機專業(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的擁塞控制機制對控制網(wǎng)絡(luò)擁塞具有特別重要的意義。本文分析了TCP的四個交互式擁塞控制算法：慢啟動、擁塞避免、快速重傳和快速恢復(fù)，介紹了TCP基于窗口的擁塞控制策略和目前常用端到端擁塞控制算法，并對它們的性能進行仿真比較。

　　關(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é)議實現(xiàn)都包含了一些避免和控制網(wǎng)絡(luò)擁塞的算法。當(dāng)今Internet的可靠性和穩(wěn)定性與TCP擁塞控制機制密不可分，而TCP的成功也要歸功于其穩(wěn)固的擁塞控制機制。擁塞控制是確保Internet魯棒性(robustness)的關(guān)鍵因素，因此成為當(dāng)前網(wǎng)絡(luò)研究的一個熱點問題。

　　2TCP基于窗口的擁塞控制策略2.1加法增加乘法減少(AIMD)窗口算法

　　TCP是Internet中最流行的端到端傳輸協(xié)議，為主機之間提供可靠按序的傳輸服務(wù)。在現(xiàn)有的TCP/IP協(xié)議體系下，TCP擁塞控制機制主要基于加法增加乘法減少(AIMD)算法。在該算法中主要用到三個窗口變量：

　　(1)擁塞窗口(cwnd)：限定源端在擁塞控制中在一定時間內(nèi)允許傳送的最大數(shù)據(jù)量，是來自源端的流量控制。

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

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

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

　　AIMD的具體工作過程為：

　　(1)源端每收到一個ACK，擁塞窗口按下式增加：

　　Incr=MSS×(MSS/cwnd)(MSS為分組大小)

　　cwnd=cwnd+Incr

　　也就是，如果每個發(fā)出的分組都在最近的RTT(往返時延)時間內(nèi)獲得確認(rèn)，源端就將cwnd增加1，即加法增加。

　　(2)當(dāng)發(fā)生超時，TCP將超時看作擁塞的標(biāo)志，并減小發(fā)送速率。每發(fā)生一次超時，源端重新計算擁塞窗口值：

　　cwnd=cwnd/2

　　也就是，一次超時，擁塞窗口值減為當(dāng)前值的一半，即乘法減少。

　　2.2TCP擁塞控制的四個階段

　　2.2.1啟動階段

　　當(dāng)連接剛建立或超時時，進入慢啟動階段。

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

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

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

　　當(dāng)cwnd

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

　　2.2.2擁塞避免階段

　　當(dāng)TCP源端發(fā)現(xiàn)超時或收到3個相同的ACK確認(rèn)幀時，即認(rèn)為網(wǎng)絡(luò)將發(fā)生擁塞，此時進入擁塞避免階段。

　　在擁塞避免階段，慢啟動域值ssthresh將被設(shè)置為當(dāng)前cwnd的一半，當(dāng)發(fā)生超時時，cwnd被置為初始值1。此時，如果cwnd=ssthresh，則執(zhí)行擁塞避免算法，即cwnd在每次收到一個ACK確認(rèn)時只增加1/cwnd個數(shù)據(jù)包。擁塞避免階段cwnd隨RTT呈線性增長。

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

　　在擁塞避免階段，當(dāng)數(shù)據(jù)包超時時，cwnd被置為1，重新進入慢啟動階段，這會導(dǎo)致過大地減小發(fā)送窗口尺寸，降低TCP連接的吞吐量。因此，引入了快速重傳和快速恢復(fù)機制。

　　在快速重傳階段，當(dāng)源端收到3個或3個以上重復(fù)的ACK時，就判定數(shù)據(jù)包丟失，同時將ssthresh設(shè)置為當(dāng)前cwnd的一半，并重傳丟失的包，進入快速恢復(fù)階段。

　　在快速恢復(fù)階段，每收到重復(fù)的ACK，則cwnd加1;收到非重復(fù)ACK時，置cwnd=ssthresh，轉(zhuǎn)入擁塞避免階段;如果發(fā)生超時重傳，則置ssthresh為當(dāng)前cwnd的一半，cwnd=1，重新進入慢啟動階段。

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

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

　　3.1TCPTahoe算法

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

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

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

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

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

　　cwnd以線性方式增長。

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

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

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

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

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

　　3.2TCPReno

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

　　(1)收到三個重復(fù)的ACK，進入快速重傳/快速恢復(fù)，此時ssthresh設(shè)置為當(dāng)前擁塞窗口的一半。

　　(2)重傳丟失的數(shù)據(jù)包，并置cwnd=cwnd+ndup(ndup為收到的重復(fù)ACK數(shù))。

　　(3)發(fā)送新的數(shù)據(jù)包。

　　(4)當(dāng)收到非重復(fù)的ACK時，cwnd=ssthresh。

　　(5)進入擁塞避免階段。

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

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

　　3.3 TCP NewReno

　　NewReno對Reno中“快速恢復(fù)”算法進行了補充，它考慮了一個發(fā)送窗口內(nèi)多個報文同時丟失的情況。在Reno算法中，發(fā)送方收到一個不重復(fù)的應(yīng)答后就退出“快速恢復(fù)”狀態(tài)。而在NewReno中，只有當(dāng)所有報文都被應(yīng)答后才退出“快速恢復(fù)”狀態(tài)。

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

　　NewReno的實現(xiàn)只要修改TCP發(fā)送端的實 現(xiàn)代碼，實現(xiàn)簡單。

　　3.4 SACK(selective acknowledgement，選擇性應(yīng)答)

　　SACK也關(guān)注一個窗口內(nèi)有多個報文的丟失，它使用“選擇性重傳”策略，提高TCP在擁塞較嚴(yán)重且一個窗口中有多個分組丟失時的性能。SACK的基本思想是：接收方TCP發(fā)送SACK分組來通知發(fā)送方接收數(shù)據(jù)的情況，這樣源端就能準(zhǔn)確的知道哪些數(shù)據(jù)包被正確的傳到接收端，從而避免不必要的重傳，減少時延，提高網(wǎng)絡(luò)吞吐量。

　　SACK算法是對Reno算法的改進。它的改進之處在于：在快速恢復(fù)階段，SACK保持一個變量pipe來表示出現(xiàn)在路由器上報文的估計數(shù)量。當(dāng)pipe小于擁塞窗口大小時，源端只發(fā)送一個新報文分組或重發(fā)一個老報文，pipe加1;當(dāng)發(fā)送端接收到一個帶SACK選項的重復(fù)ACK時，表明新數(shù)據(jù)已被接收端接收，pipe減1;此外，對收到的“恢復(fù)ACK”使用特殊的處理方法，對pipe變量值減2。

　　SACK算法降低了不必要的重傳，能有效的從多個數(shù)據(jù)包丟失中恢復(fù)。但是它的實現(xiàn)需要修改TCP發(fā)送端和接收端的實現(xiàn)代碼，增加了TCP的復(fù)雜性，不易大規(guī)模的應(yīng)用。

　　3.5Vegas算法

　　Vegas算法是一個得到普遍認(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)定在一個合適的范圍內(nèi)。Vegas的重傳策略與上述算法也不同，它是在收到一個重復(fù)ACK后，比較數(shù)據(jù)包發(fā)出的時間和當(dāng)前時間，然后決定是否重發(fā)。這樣能更及時地重傳丟失的數(shù)據(jù)包，提高響應(yīng)速度。

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

　　4算法性能比較

　　在上述介紹的幾種擁塞控制算法中，Tahoe在快速重傳后轉(zhuǎn)向慢啟動算法，這樣不能有效地利用網(wǎng)絡(luò)帶寬并且還引入較大的時延;Reno在Tahoe的基礎(chǔ)上提出了快速恢復(fù)算法，對于單個數(shù)據(jù)包的丟失在傳輸性能上有顯著的提高，但是它不能有效的處理多個包丟失的情況;于是提出了改進算法NewReno和SACK，兩種改進措施都大大提高了TCP的傳輸性能;Vegas在理論上是可行的，但是在實際應(yīng)用中存在著局限性，因而未能得到廣泛應(yīng)用。TCP的擁塞控制算法還在不斷的改進。

　　5總結(jié)

　　端到端的擁塞控制是網(wǎng)絡(luò)擁塞控制的基本前提，只有將端到端的擁塞控制工作做好，才能為網(wǎng)絡(luò)中的整體擁塞控制措施打下良好的基礎(chǔ)。隨著Internet的迅速擴展，網(wǎng)絡(luò)中的數(shù)據(jù)流負(fù)載處理會快速加重，如果端節(jié)點與網(wǎng)絡(luò)擁塞控制關(guān)系能夠很好的配合，網(wǎng)絡(luò)負(fù)載將會大大減輕，有利于傳輸性能和資源利用。如何建立有限的協(xié)調(diào)機制，有待于進一步研究。

　　現(xiàn)有的TCP擁塞控制算法都存在一些局限性，因此，對網(wǎng)絡(luò)擁塞控制的進一步研究具有極其重要的理論和應(yīng)用價值。

　　參考文獻(xiàn)

　　[1]馮波，基于NS的TCP/IP擁塞控制算法研究，燕山大學(xué)碩士學(xué)位論文，2003.9

　　[2]徐恪，吳建平，徐明偉高等計算機網(wǎng)絡(luò)—體系結(jié)構(gòu)、協(xié)議機制、算法設(shè)計與路由器技術(shù)，機械工業(yè)出版社，2003.9，Page299-322

　　[3]章淼，吳建平，林闖互聯(lián)網(wǎng)端到端擁塞控制研究綜述，軟件學(xué)報，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