大學計算機專業相關論文範文

　　計算機種類繁多。實際來看，計算機總體上是處理資訊的工具。根據圖靈機理論，一部具有最基本功能的計算機應當能夠完成任何其它計算機能做的事情。下面是小編給大家推薦的，希望大家喜歡!

　　篇一

　　《淺析軟體專案過程管理矩陣模型研究與實踐》

　　關鍵詞：軟體專案管理;過程控制;矩陣模型;需求管理

　　摘要：軟體專案由於應用的領域不同，一般涉及眾多的業務知識領域，專案成果也應以軟體的邏輯產品來體現，其最終成果及實現過程的可見性、可度量性相對較弱。因此，軟體專案管理比一般工程專案要複雜得多。基於軟體專案管理的特點分析，並結合軟體專案開發管理經驗，討論了軟體專案組織架構、計劃與過程控制等軟體專案管理要素，提出了矩陣式專案管理模型，分析了該模型中業務知識與計算機技術共同作用所能達到的最佳效果，討論了需求管理模型及其應用，實踐證明該模型是行之有效的。

　　O引言

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

　　顧名思義，軟體專案管理就是專案管理在軟體領域的應用，是一種為了能夠按照預定的工期、質量順利完成軟體專案而對成本、人員、進度、質量、風險等進行控制管理的活動。其核心在於通過有效的管理，明確專案範圍，合理調配人力資源，提高專案團隊的整體開發能力，優化專案執行過程，控制專案成本，為使用者提供滿意的軟體產品。

　　1軟體專案管理的特點

　　軟體是一種特殊的產品，這種產品的特殊性之一就是它的生產活動是以專案的形式進行的，因此，專案管理對軟體生產具有決定性的意義。軟體專案管理除了具有一般專案管理的特點外，還有其獨特之處，主要表現在：

　　***1***軟體產品缺乏硬性度量指標。

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

　　***2***重視應用領域的業務知識。

　　對於計算機應用軟體來說，它並不單純是計算機技術問題，更多地表現在它所服務的業務領域的知識技能。如企業ERP、SCM等應用軟體專案，計算機只是它的載體，計算機技術往往並不起決定作用，而與之相關的業務知識、管理知識顯得更加重要。

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

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

　　***4***強調文件的重要性。

　　文件是軟體產品的重要組成部分，軟體專案管理以工程化的管理方法，強調規範文件的重要性，在軟體生命週期的各個階段，強調對里程碑文件的評審，並把文件作為階段成果的重要體現和下階段的基礎。

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

　　培訓與服務是發掘軟體產品價值的重要手段。一個軟體產品，如果沒有人使用就不能形成價值，如果不會使用，就可能降低軟體的價值。服務的優劣已經直接影響軟體的使用價值並決定軟體產品的生命週期。總之，軟體專案管理重視培訓與服務在軟體增值中的意義。

　　2管理架構矩陣模型

　　規範化的管理體現在：有完整的基於軟體開發標準***如CMM、ISO等***的開發流程;有基於這個流程的完整詳細的開發計劃;有基於開發計劃的成本預算和成本控制方法;有明確的階段檢查措施和評價標準;有明確的質量管理體系和質量保證實施手段，保證專案在可控狀態下進行。而這一切都需要有一個組織有效的管理團隊和運作規範的管理架構。

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

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

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

　　矩陣管理可以更好地發揮各專業人員的業務專長，又能更好地發揮各技術層面技術人員的特長，專案經理重要的工作就是協調，重點在於如何結合眾多資源控制整個開發程序。矩陣模型也有利於軟體公司人才戰略，有利於組織內部人才的培養，充分展現個人的發展空間。大多數軟體企業也許都很難有精通所有專業的全才，但都擁有為數眾多精通某一類業務的系統分析師，或精通某一類專門技術的專門人才。根據矩陣模型，公司可以培養員工向不同方向發展，有技術特長的，培養他發展技術的深度，有其他專業特長的，比如精通稅務、金融、企業管理等，則培養成業務專家。這樣，在人盡其才的同時，又有利於留住人才，穩定了軟體開發隊伍。

　　3計劃與過程控制

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

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

　　***1***階段檢查。

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

　　***2***定期檢查。

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

　　定期或不定期地對專案進度計劃表進行檢查，對於不合格的專案進度計劃表或未按照專案進度計劃表執行的專案給予相應處理，及時發現問題，儘早調整計劃偏差，最大限度地避免損失。這樣，在專案進行過程中就比較容易把握每個階段專案的進展情況，方便對專案組成員的績效進行階段性評估，便於統一專案經理和客戶的認識。增加專案風險的可控性。

　　4需求管理矩陣模型

　　軟體專案的最大難點往往在於需求的不確定性，所以，有人認為好的需求是軟體專案成功的一半。需求的困難主要表現在計算機技術人員與使用者業務人員由於不同的語境，存在溝通困難。使用者業務人員可能不清楚計算機系統實現細節，或並不知道需求人員到底需要了解什麼，而計算機技術人員可能由於不熟悉業務，往往又缺乏引導使用者表達需求的業務素質和技巧，所以，影響了雙方溝通和交流，造成的結果可能是使用者往往不能清楚地描述自己的需求或計算機人員不能準確地理解需求，從而影響了需求的最終描述。另一方面，對於管理資訊系統來說，需求的不確定還表現在業務流程的變化上，特別對於現階段還處於不斷變革時期的我國企業來說，情況更是如此。

　　一般來說，使用者在看到最終系統以後，通過不斷地應用實踐，激發了使用者的聯想，就可能提出新的或改進的需求。所以，在專案一開始，技術人員就必須對此有充分的認識，既要儘可能全面瞭解現有需求，也要充分預計到可能的需求變更，為系統設計留有變更或擴充的餘地。另一方面，應該儘可能讓使用者儘早介入，直接參與階段評審和驗收，以便及時發現需求執行偏失，不至於什麼都等到全部完工後才發現問題，才一併解決問題。在專案的後期改正一個錯誤的代價往往是在前期的數倍。所以，需求管理成為軟體專案成敗的另一個關鍵因索之一。

　　根據筆者的經驗，建立需求矩陣跟蹤表是進行需求管理很好的工具。通過跟蹤表，專案涉眾可以隨時瞭解關於軟體需求的實現過程。使用者可以從中隨時看到階段性成果，方便使用者及時測試、確認已實現的需求，便於使用者積極參與，便於及時發現問題，改正問題。

　　5結束語

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

　　篇二

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

　　摘要：隨著網路技術的發展，網路擁塞日益嚴重，如何解決擁塞，充分、高效地利用網路資源，成為當今急需解決的問題。由於Internet上大多數業務都採用TCP協議，因此TCP的擁塞控制機制對控制網路擁塞具有特別重要的意義。本文分析了TCP的四個互動式擁塞控制演算法：慢啟動、擁塞避免、快速重傳和快速恢復，介紹了TCP基於視窗的擁塞控制策略和目前常用端到端擁塞控制演算法，並對它們的效能進行模擬比較。

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

　　1引言

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

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

　　2TCP基於視窗的擁塞控制策略2.1加法增加乘法減少***AIMD***視窗演算法

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

　　***1***擁塞視窗***cwnd***：限定源端在擁塞控制中在一定時間內允許傳送的最大資料量，是來自源端的流量控制。

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

　　***3***有效視窗***win***：源端資料傳送的實際視窗大小，限定為win=min***cwnd，awnd***。

　　由於計算機計算能力和儲存能力的提高，通告視窗一般都比較大，因此當前傳送視窗的大小大多數情況下等於擁塞視窗的大小。

　　AIMD的具體工作過程為：

　　***1***源端每收到一個ACK，擁塞視窗按下式增加：

　　Incr=MSS×***MSS/cwnd******MSS為分組大小***

　　cwnd=cwnd+Incr

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

　　***2***當發生超時，TCP將超時看作擁塞的標誌，並減小發送速率。每發生一次超時，源端重新計算擁塞視窗值：

　　cwnd=cwnd/2

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

　　2.2TCP擁塞控制的四個階段

　　2.2.1啟動階段

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

　　當新建TCP連線時，擁塞視窗***cwnd***被初始化為一個數據包大小。源端按cwnd大小發送資料，每收到一個ACK確認，就增加一個數據包傳送量，這樣慢啟動階段cwnd隨RTT呈指數級增長。

　　慢啟動採用逐漸增大cwnd的方法，可以防止TCP在啟動一個連線時向網路傳送過多的資料包而造成不必要的資料丟失和網路擁塞，並且它還能夠避免採用單純的AIMD演算法造成的吞吐量增加過慢的問題。

　　為了防止cwnd的無限制增長引起網路擁塞，引入一個狀態變數：慢啟動閾值ssthresh。

　　當cwnd

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

　　2.2.2擁塞避免階段

　　當TCP源端發現超時或收到3個相同的ACK確認幀時，即認為網路將發生擁塞，此時進入擁塞避免階段。

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

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

　　在擁塞避免階段，當資料包超時時，cwnd被置為1，重新進入慢啟動階段，這會導致過大地減小發送視窗尺寸，降低TCP連線的吞吐量。因此，引入了快速重傳和快速恢復機制。

　　在快速重傳階段，當源端收到3個或3個以上重複的ACK時，就判定資料包丟失，同時將ssthresh設定為當前cwnd的一半，並重傳丟失的包，進入快速恢復階段。

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

　　這種方法避免了資料包超時後就重新進入慢啟動階段，提高了TCP連線的吞吐量。

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

　　3.1TCPTahoe演算法

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

　　***1***慢啟動：避免了連線建立時突發資料流對網路的衝擊。

　　初始設定cwnd為1，並按指數型方式增長，直至cwnd超過ssthresh。

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

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

　　cwnd以線性方式增長。

　　如果發生超時或者連續收到3個重複ACK，Tahoe認為發生了擁塞。

　　對於超時，置ssthresh為當前擁塞視窗的一半，cwnd=1，轉入慢啟動。

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

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

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

　　3.2TCPReno

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

　　***1***收到三個重複的ACK，進入快速重傳/快速恢復，此時ssthresh設定為當前擁塞視窗的一半。

　　***2***重傳丟失的資料包，並置cwnd=cwnd+ndup***ndup為收到的重複ACK數***。

　　***3***傳送新的資料包。

　　***4***當收到非重複的ACK時，cwnd=ssthresh。

　　***5***進入擁塞避免階段。

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

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

　　3.3 TCP NewReno

　　NewReno對Reno中“快速恢復”演算法進行了補充，它考慮了一個傳送視窗內多個報文同時丟失的情況。在Reno演算法中，傳送方收到一個不重複的應答後就退出“快速恢復”狀態。而在NewReno中，只有當所有報文都被應答後才退出“快速恢復”狀態。

　　具體執行過程是：在快速恢復期間，TCP傳送端收到一個ACK後，傳送端通過此ACK應答推斷出下一個丟失的資料包序列號，並且立即重傳那個資料包。這樣，NewReno在每個RTT內重傳一個丟失的資料包，直到發生多個數據包丟失的視窗中所有丟失資料包被重傳，而不是等到超時。在這個期間如果還有其它重複的ACK到來，則繼續快速恢復演算法，直到在快速恢復初始時所有未確認資料包都被確認。

　　NewReno的實現只要修改TCP傳送端的實 現程式碼，實現簡單。

　　3.4 SACK***selective acknowledgement，選擇性應答***

　　SACK也關注一個視窗內有多個報文的丟失，它使用“選擇性重傳”策略，提高TCP在擁塞較嚴重且一個視窗中有多個分組丟失時的效能。SACK的基本思想是：接收方TCP傳送SACK分組來通知傳送方接收資料的情況，這樣源端就能準確的知道哪些資料包被正確的傳到接收端，從而避免不必要的重傳，減少時延，提高網路吞吐量。

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

　　SACK演算法降低了不必要的重傳，能有效的從多個數據包丟失中恢復。但是它的實現需要修改TCP傳送端和接收端的實現程式碼，增加了TCP的複雜性，不易大規模的應用。

　　3.5Vegas演算法

　　Vegas演算法是一個得到普遍認可，但是未能獲得廣泛應用的演算法。Vegas與上述介紹的演算法不同，它以RTT的變化作為擁塞訊號，調節源端的傳送速率。如果發現RTT變大，Vegas就認為網路發生擁塞，開始減小cwnd;如果RTT變小，Vegas則解除擁塞，再次增加cwnd。這樣，在理想情況下，cwnd值會穩定在一個合適的範圍內。Vegas的重傳策略與上述演算法也不同，它是在收到一個重複ACK後，比較資料包發出的時間和當前時間，然後決定是否重發。這樣能更及時地重傳丟失的資料包，提高響應速度。

　　該演算法採用RTT的改變來判斷網路的可用頻寬，能較好的預測網路頻寬的使用情況，其公平性、效率都較好。但是，由於Vegas與其它演算法在競爭頻寬方面存在不公平現象，因此未能在Internet上普遍採用，還需不斷改進。

　　4演算法效能比較

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

　　5總結

　　端到端的擁塞控制是網路擁塞控制的基本前提，只有將端到端的擁塞控制工作做好，才能為網路中的整體擁塞控制措施打下良好的基礎。隨著Internet的迅速擴充套件，網路中的資料流負載處理會快速加重，如果端節點與網路擁塞控制關係能夠很好的配合，網路負載將會大大減輕，有利於傳輸效能和資源利用。如何建立有限的協調機制，有待於進一步研究。

　　現有的TCP擁塞控制演算法都存在一些侷限性，因此，對網路擁塞控制的進一步研究具有極其重要的理論和應用價值。

　　參考文獻

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

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

　　[3]章淼，吳建平，林闖網際網路端到端擁塞控制研究綜述，軟體學報，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