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

　　大學計算機專業(yè)相關論文范文篇一

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

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

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

　　O引言

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

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

　　1軟件項目管理的特點

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

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

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

　　(2)重視應用領域的業(yè)務知識。

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

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

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

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

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

　　(5)重視培訓與服務的價值。

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

　　2管理架構矩陣模型

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

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

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

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

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

　　3計劃與過程控制

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

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

　　(1)階段檢查。

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

　　(2)定期檢查。

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

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

　　4需求管理矩陣模型

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

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

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

　　5結束語

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

　　大學計算機專業(yè)相關論文范文篇二

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

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

　　關鍵字：AIMD;擁塞控制;TCP;NS

　　1引言

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

　　Internet中擁塞控制的大部分工作是由TCP完成的，目前標準的TCP協(xié)議實現(xiàn)都包含了一些避免和控制網(wǎng)絡擁塞的算法。當今Internet的可靠性和穩(wěn)定性與TCP擁塞控制機制密不可分，而TCP的成功也要歸功于其穩(wěn)固的擁塞控制機制。擁塞控制是確保Internet魯棒性(robustness)的關鍵因素，因此成為當前網(wǎng)絡研究的一個熱點問題。

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

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

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

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

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

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

　　AIMD的具體工作過程為：

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

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

　　cwnd=cwnd+Incr

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

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

　　cwnd=cwnd/2

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

　　2.2TCP擁塞控制的四個階段

　　2.2.1啟動階段

　　當連接剛建立或超時時，進入慢啟動階段。

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

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

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

　　當cwnd

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

　　2.2.2擁塞避免階段

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

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

　　2.2.3快速重傳和快速恢復階段

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

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

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

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

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

　　3.1TCPTahoe算法

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

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

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

　　當cwnd>=ssthresh時，Tahoe進入擁塞避免階段。

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

　　cwnd以線性方式增長。

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

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

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

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

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

　　3.2TCPReno

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

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

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

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

　　(4)當收到非重復的ACK時，cwnd=ssthresh。

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

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

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

　　3.3 TCP NewReno

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

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

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

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

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

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

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

　　3.5Vegas算法

　　Vegas算法是一個得到普遍認可，但是未能獲得廣泛應用的算法。Vegas與上述介紹的算法不同，它以RTT的變化作為擁塞信號，調(diào)節(jié)源端的發(fā)送速率。如果發(fā)現(xiàn)RTT變大，Vegas就認為網(wǎng)絡發(fā)生擁塞，開始減小cwnd;如果RTT變小，Vegas則解除擁塞，再次增加cwnd。這樣，在理想情況下，cwnd值會穩(wěn)定在一個合適的范圍內(nèi)。Vegas的重傳策略與上述算法也不同，它是在收到一個重復ACK后，比較數(shù)據(jù)包發(fā)出的時間和當前時間，然后決定是否重發(fā)。這樣能更及時地重傳丟失的數(shù)據(jù)包，提高響應速度。

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

　　4算法性能比較

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

　　5總結

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

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

　　參考文獻

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

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

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