前言：中文期刊網精心挑選了tcp協(xié)議范文供你參考和學習，希望我們的參考范文能激發(fā)你的文章創(chuàng)作靈感，歡迎閱讀。

tcp協(xié)議范文1

關鍵詞： 流控制傳輸協(xié)議； 傳輸控制協(xié)議； 單路徑； 多路徑； 吞吐率； 延遲

中圖分類號：TP393 文獻標志碼：A 文章編號：1006-8228（2013）05-03-04

Comparison study of tcp and SCTP routing protocol

He Shijie， Tong Mengjun

（School of computer science， Hangzhou Dianzi University， Hangzhou， Zhejiang 310018， China）

Abstract： In order to get better understanding of SCTP protocol performance， the NS-2 network simulation software is utilized to compare TCP and SCTP protocols from a single path and multi path. The experimental results show that， in response to the link's deteriorating condition， the SCTP protocol has a larger throughput capacity ， and also a higher stability， and it can meet the transmission requirement of high performance network.

Key words： stream control transmission protocol； transmission control protocol； single path； multi path； throughput rate； delay

0 引言

SCTP代表的是流控制傳輸協(xié)議，它是由IEFT的信令傳輸工作組（SIGTRAN）新近提出的一種面向多媒體通信的流控制協(xié)議（SCTP），用于在IP網絡上傳輸PSTN信令消息，即通常所說的SS7 over IP。

在國內，1985年是流控制傳輸協(xié)議技術開始萌芽的時期。從1985到1995年，該技術主要局限于計算機網絡中接人端口數據流的控制技術，以防止計算設備之間大量數據互相通信時出現阻塞，保證更高的傳輸效率和可靠性。目前對該技術的研發(fā)仍處于較淺的層次，對整個IP網絡中實規(guī)PSTN信令傳輸的技術還鮮有涉及；國內的SCTP研究還主要側重于應用方面，比如SCTP與TCP的比較、SCTP在移動環(huán)境下的性能研究（例如平滑切換，移動IP，最后一跳性能惡化問題，基于SCTP移動Internet傳輸模型等）、基于獨立路徑擁塞控制的SCTP負荷分擔機制研究、結合SS7的研究，以及SCTP的安全問題研究、軍事應用等。

國外則更側重于起草標準，如：定義SCTP負荷分擔草案（多路徑同時傳輸）；制定部分可靠傳輸標準；提交建立SCTP偶聯(lián)后的動態(tài)地址重配置；提交SCTP API草案；定義SCTP對移動IP的支持；提交單播擁塞控制建議標準；TCP友好可變速率控制等等。目前，IETF致力于把SCTP作為一種通用的傳輸協(xié)議。對SCTP本身的研究集中在對其功能的完善和擴展上，主要是從兩個本質特點入手：多路徑和多流。同時，對SCTP應用的研究主要集中在兩個方面：在移動網絡中的應用和對多媒體的傳輸。

本文的主要研究工作是利用NS-2構建仿真平臺，對SCTP和TCP這兩種協(xié)議進行對比，并根據仿真的結果計算、分析和比較這兩種協(xié)議的性能，發(fā)現它們各自的優(yōu)缺點。

1 TCP和SCTP的單路徑的對比研究

單路徑的實驗拓撲圖如圖1所示，一共有6個節(jié)點，2個路由節(jié)點。其中0-2是發(fā)送節(jié)點，5-7是相應的接收節(jié)點。3個發(fā)送節(jié)點都綁定了FTP應用，其中0號節(jié)點的數據包發(fā)送往5號節(jié)點，流標簽為1；1號節(jié)點的數據包發(fā)送往6號節(jié)點，流標簽為2；2號節(jié)點的數據包發(fā)送往7號節(jié)點，流標簽為3。設置最大的傳輸單元為1500。路由3、4間的droptail隊列大小分別為5、10。本實驗主要更改了1號節(jié)點和6號節(jié)點的傳輸協(xié)議。現在設0-5號節(jié)點的路徑為L1，1-6號節(jié)點的路徑為L2，2-7號的路徑為L3。變量主要在L1上面。其中發(fā)送節(jié)點到路由節(jié)點3，路由節(jié)點4到接收節(jié)點的帶寬均為10Mbps，延遲均為15ms。路由節(jié)點3、4直接的帶寬為1.7Mbps，延遲為15ms。這樣路由節(jié)點3、4之間就成為接收方和發(fā)送方直接的瓶頸。

圖1 實驗拓撲圖

實驗一的過程是：在0.5s的時候三個節(jié)點同時開始發(fā)送數據，4s的時候斷開L1，7s的時候斷開L2。這樣做的主要目的是讓L1的數據包先在有兩個TCP傳輸協(xié)議競爭的情況下進行數據傳輸，然后逐漸斷開其他兩個鏈路的數據傳輸，來觀察TCP和SCTP在有TCP競爭條件下，數據傳輸的吞吐量，延遲和丟包率。吞吐量如圖2所示。

圖2 實驗一中TCP和SCTP數據的吞吐量

圖2所表示的是鏈路L2上的數據吞吐量。X坐標軸表示時間的變化，單位為s，Y坐標軸表示接收的數據量，單位為Byte。紅色線表示TCP協(xié)議在droptail隊列為5時的數據吞吐量。綠色線表示TCP協(xié)議在droptail隊列為10時的數據吞吐量。藍色線為SCTP協(xié)議在droptail隊列為5時的數據吞吐量，黃色為SCTP協(xié)議在droptail隊列為10時的數據吞吐量。從圖2中可以看出，總體上SCTP的吞吐量遠遠高過TCP。對于SCTP來說，在droptail隊列為5的時候，其吞吐量比10的時候略高，但差距不是很大。在兩個TCP數據傳輸斷掉以后，兩種情況下的吞吐量趨于相同，而且數據吞吐量趨于穩(wěn)定。看趨勢，在9s以后，droptail隊列為10的時候，其吞吐量會略大于5的時候。對于TCP協(xié)議來說，很明顯，在droptail隊列為10的時候，其吞吐量高于5的時候，在兩個TCP協(xié)議的數據傳輸都斷掉以后，數據吞吐量的增長率趨于平行式增長。

圖3 實驗一中TCP和SCTP延遲對比

圖3是實驗一中SCTP和TCP兩種協(xié)議數據傳輸延遲的對比。如圖所示，是TCP和SCTP在droptail隊列為5的時候，兩種協(xié)議延遲的對比。紅色線為TCP的延遲，綠色的為SCTP的延遲。X坐標軸表示數據傳輸的時間變化，單位為s，Y坐標軸表示兩種協(xié)議在某個時刻的延遲，單位為s。從圖3中可以看到，兩者的數據線略有交叉，SCTP的延遲略高于TCP；TCP的延遲是在一個范圍內上下波動，而SCTP的延遲呈一種階段性的梯度變化。從這里也可以看出兩種數據傳輸的差別：TCP在鏈路達到穩(wěn)定的時候，每次傳輸的數據量一定；而SCTP的數據傳輸，在沒有擁塞避免的情況下，是呈指數增長的。

根據實驗一的拓撲圖，更改鏈路L1和L3的數據傳輸時間，此為實驗二。在0.5s的時候1號節(jié)點開始發(fā)送數據，在1.5s的時候0號節(jié)點開始發(fā)送數據，在4.5s的時候3號節(jié)點開始發(fā)送數據，在7.5s的時候將L1和L3兩條鏈路斷開連接，8s的時候結束數據傳輸。通過觀察TCP和SCTP協(xié)議在逐漸有一個TCP協(xié)議和兩個TCP協(xié)議競爭的條件下的數據吞吐量，延遲和丟包率來對比兩種協(xié)議。

圖4 實驗二中TCP和SCTP兩種協(xié)議的數據吞吐量

在圖4中，表示的是鏈路L2上的數據吞吐量。X坐標軸表示時間的變化，單位為s，Y坐標軸表示接收的數據量，單位為Byte。紅色線表示TCP協(xié)議在droptail隊列為5時的數據吞吐量。綠色線表示TCP協(xié)議在droptail隊列為10時的數據吞吐量。藍色線為SCTP協(xié)議在droptail隊列為5時的數據吞吐量，黃色為SCTP協(xié)議在droptail隊列為10時的數據吞吐量。從圖4中可以看出，總體上來說，在相同的droptail隊列值的情況下，SCTP的吞吐量遠大于TCP的吞吐量。在兩個TCP競爭數據傳輸出現后，它們的吞吐量都有一個短暫性的下降，然后繼續(xù)趨于上升。在8.0s的時候，兩種協(xié)議的吞吐量開始趨于穩(wěn)定。

對比實驗一和實驗二中數據吞吐量的圖，我們看到，由于實驗一和實驗二的區(qū)別在于競爭的TCP協(xié)議出現的時間不同，在實驗一的環(huán)境下，SCTP在有其他協(xié)議競爭的條件下，能夠更容易、更快地達到數據吞吐的穩(wěn)定狀態(tài)，這樣非常有利于數據的傳輸。

圖5是實驗二中鏈路L2在droptail隊列值為10的時候的延遲對比。紅色線為TCP的延遲，綠色的為SCTP的延遲。X坐標軸表示數據傳輸的時間變化，單位為s，Y坐標軸表示兩種協(xié)議在某個時刻的延遲，單位為s。由圖5中可以看出，SCTP與TCP延遲隨時間的走勢相互交叉，與實驗一中的情形類似，SCTP的延遲略高于TCP。

圖5 實驗二TCP和SCTP的延遲對比

圖6 TCP和SCTP競爭時的延遲和吞吐量

圖6是在實驗一環(huán)境下，SCTP和TCP相互競爭下的延遲和吞吐量的對比，主要是鏈路L2和L3的對比，紅色線表示的是TCP，綠色線表示TCP。圖6上圖中，X坐標軸表示數據傳輸的時間變化，單位為s，Y坐標軸表示兩種協(xié)議在某個時刻的延遲，單位為s；圖6下圖中，X坐標軸表示時間的變化，單位為s，Y坐標軸表示接收的數據量，單位為Byte。從圖6中可以看出，情況基本與上面的實驗保持一致。在相同的droptail隊列值的情況下，SCTP的吞吐量遠大于TCP，但是TCP和SCTP的延遲相互交叉，SCTP延遲略高于TCP。

2 TCP和SCTP的多路徑的對比研究

多路徑的實驗拓撲圖如圖7所示，節(jié)點0-2合起來是一個發(fā)端，節(jié)點3-5合起來是一個收端。0是核心節(jié)點，1、2是接口，即該端點的兩個IP地址；3也是核心節(jié)點，4、5也是接口，也即該端點的兩個IP地址。1和4路徑命名為if0；2和5路徑命名為if1。

在SCTP傳輸過程中，數據只能從接口發(fā)或收，不能直接從核心節(jié)點發(fā)或收。該實驗過程為：應用層傳輸FTP數據，在0.5s后開始傳輸；在第5s前，路徑if0、if1的帶寬為5M，時延為50ms；在第5s，路徑if0性能惡化，帶寬變成1M，時延變?yōu)?00ms；在第8s，傳輸結束。

圖7 SCTP多路徑仿真拓撲圖

由于TCP沒有多路徑這個特點，所以，要與SCTP作對比，只能重新建立拓撲圖。拓撲圖如圖8所示：數據傳輸過程和SCTP一樣，應用層傳輸FTP數據，在0.5s后開始傳輸；在第5s的時候鏈路發(fā)生惡化，帶寬變成1M，時延變?yōu)?00毫秒；在第8s，傳輸結束。

圖8 相應的TCP拓撲圖

對于這兩種協(xié)議延遲方面的比較，我們在上一節(jié)中已經有過很詳細的對比，所以在這里，主要針對兩種協(xié)議在多路徑的情況下，對數據吞吐量作比較，如圖9所示。

圖9 多路徑下TCP與SCTP吞吐量的比較

如圖9，其中為了表示自己搭建的TCP網絡和SCTP網絡有對比性，所以測試了在圖8中拓撲圖中SCTP數據的吞吐量，如圖9中的綠線。從圖中來看，在6.5s以前兩種拓撲圖中SCTP的數據吞吐量完全吻合，這樣看來，兩種拓撲圖是具有可比性的。圖中藍色線表示TCP協(xié)議的吞吐量，黃色線表示if0路徑上SCTP的吞吐量，紅色線表示if1路徑是SCTP的吞吐量。X坐標軸表示時間的變化，單位為s，Y坐標軸表示接收的數據量，單位為Byte。從圖9中看，5s之前鏈路沒有惡化，SCTP默認if0是主路徑，5s之后鏈路if0惡化，吞吐量開始下降，此時，因為有另一條路徑if1的存在，而且鏈路狀態(tài)比if0好，SCTP開始將if1作為主路徑進行傳輸，圖中if1的吞吐量開始上升，由此可以看出，SCTP的吞吐量在經過一段時間的降低之后，會恢復原來的吞吐量，使數據傳輸不受影響。由圖9可以看出，TCP在路徑出現惡化的時候，吞吐量開始下降，如果路徑得不到緩解，吞吐量會受到很大的影響。由此可以看出，SCTP多路徑的特點較TCP存在很大的優(yōu)勢。我們再來分析路徑if0數據傳輸與時間的關系，如圖10所示。圖10中有上（紅色）、中（綠色）、下（藍色）三條線。上線（紅色）代表 SCTP 把數據包發(fā)送到緩存，即入隊列；中線（綠色）代表數據包從緩存注入到網絡，即出隊列；下線（藍色）代表數據包從收端反饋回來的證實 SACK。縱坐標代表所發(fā)送的數據包序列號，橫坐標代表時間，斜率指示傳輸速率（下面類似圖的信息也是這樣的）。在第5s，帶寬和時延發(fā)生變化，路徑性能變差，所以第5s后的斜率小于第5s前的斜率，即第5s后的傳輸速率小于第5s前的傳輸速率。

圖10 if0上數據傳輸與時間的關系

3 結束語

本文主要是通過NS-2構建仿真平臺，對TCP和SCTP在單路徑和多路徑的條件下進行對比。通過兩個實驗對比發(fā)現，兩種協(xié)議在數據傳輸的延遲方面，SCTP協(xié)議略高于TCP協(xié)議，相差不是很大，但是SCTP的數據吞吐量遠遠大于TCP協(xié)議。由于SCTP具有多路徑和多重定址的特點，在應對鏈路惡化的情況時，SCTP表現出更高的穩(wěn)定性。作為一個新的傳輸協(xié)議，SCTP還具有很大的發(fā)展空間，SCTP較TCP更能滿足高性能傳輸的要求，隨著IP網絡的迅猛發(fā)展，SCTP一定會有更廣闊的應用空間。

參考文獻：

[1] Esbold Unurkhaan， Erwin P， Andreas Jungmaier. Secure SCTP-A

Versatile Secure Transport Protocol[J].Springer，2004.10（3）：273

[2] V. Jaclbson. Congestion Avoidance and Contrl[J].ACM SIGCOMN，

1988.36（2）：273

[3] K.Fall and S.Floyd.Simulation-based comparisons of Tahoe Reno

and SACK TCP[J]. ACM Computer Communication Review，1996.26（3）：5

[4] L.Brakmo and L.Peterson.TCP Vegas：End to End Congestion

Avoidance on a Gloabal Internet[J]. IEEE Journal on Selected Areas in Communication，1995.13（8）：1465

[5] 周開波，劉桐，蔣皓等.mSCTP協(xié)議異構網絡切換性能評估[J].現代電

信科技，2011.3（3）：19

[6] 方路平，劉世華，陳盼等.NS-2網絡模擬基礎與應用[M].國防工業(yè)出

版社，2008.

[7] 胡文靜.SCTP主路徑自動切換的研究[D].吉林大學碩士學位論文，

2006.

[8] 葉凌偉，陳雁.SCTP與TCP的功能對比及應用分析[J].中國數據通

信，2003.1（2）：43

[9] 賀，張繼棠.流控傳輸協(xié)議SCTP的研究[J].山西電子技術，

2005.11（5）：21

[10] 黃曉波，鄭應平.流控制傳輸協(xié)議與TCP協(xié)議的比較[J].微型機與應

用，2005.7（6）：37

[11] 成為青.流控制傳輸協(xié)議概述[J].電子電氣教學學報，2003.4（2）：31

tcp協(xié)議范文2

【關鍵詞】TCP 協(xié)議；有色Petri網；形式化描述；可達樹

隨著數據通信和網絡的發(fā)展，現在TCP/IP（Transfer Control Protocol/Internet Protocol）協(xié)議簇成為占主導地位的網絡體系結構，被廣泛的使用。有色Petri網（Colored Petri Net，CPN）是由丹麥的Jensen Kurt于1981年在Petri網基礎上定義的一種具有層次性的高級Petri網。利用在計算機上開發(fā)的CPN的建模分析工具──CPN Tools，可以建立描述系統(tǒng)的CPN靜態(tài)模型，并對系統(tǒng)模型的動態(tài)行為進行仿真，分析系統(tǒng)的分布、并發(fā)、同步、異步等特性，以及建立系統(tǒng)模型的狀態(tài)空間并分析系統(tǒng)的活性問題、可達性問題等。由于CPN具有嚴格的網理論形式化的數學描述、上述的特性以及建模工具提供的仿真分析功能，因此在網絡通信協(xié)議的驗證和分析上得到了廣泛的應用。

一、TCP協(xié)議連接的建立過程

TCP是一個可靠的，面向連接的，端到端的傳輸協(xié)議，它提供了具有流量控制的可靠的數據傳輸。TCP的連接建立稱為“三次握手”。（1）客戶發(fā)送第一個報文段，SYN報文段，在這個報文段中只有SYN標志置1，這個報文段的作用是使序號同步。客戶端選擇一個隨機數作為第一序號，并把這個序號發(fā)給服務器。注意SYN報文段是一控制報文段，不攜帶任何數據但它消耗一個序列號。（2）服務器發(fā)送第二個報文段，即SYN+ACK報文段，其中有兩個標志置為1這個報文段有兩個目的，一個是使用SYN同步初始序號，另一個是服務器使用ACK標志確認已經從客戶端收到的SYN報文段，同時給出期望從客戶端收到的下一個序號。服務器還必須定義客戶端要使用的接收窗口（rwnd），這就實現了TCP的流量控制。（3）客戶端發(fā)送第三個報文段。這僅僅是一個ACK報文段。它使用ACK標志和確認號字段來確認收到了第二個報文。注意這個報文段的序號和SYN的報文段使用的序號一樣，這個ACK報文段不消耗任何序號。客戶還必須定義服務窗口值。在某些情況下第三個報文段可以攜帶客戶端的第一個數據塊，在這種情況下第三個報文段必須有一個新的序號來表示數據源的第一個自己的編號。一般的來說，第三個報文段不攜帶數據的，因而不消耗序號。

二、CPN模型

在利用CPN Tool建立具體模型之前，先對模型中各庫所和變遷，以及顏色類型，變量做一說明。當P1，P2，P4，P7中有標識的時候，即發(fā)送端主動打開準備發(fā)送連接請求和接受端被動打開監(jiān)聽，發(fā)送第一個請求報文，其序號用變量n1綁定，在接收端收到這個請求信息的時候把n1加1作為服務器想從客戶端得到下一報文段的序號，同時和自己的初始序號一起組成確認報文段序列，用（n3，n2）來綁定。當客戶端接到這個報文的時候進行檢查，如果n3=n1+1，說明得到服務器確認報文安全，發(fā)送客戶確認報文，用（n3，n4）綁定，同時把n1作為數據傳輸的初始序號。如果n3不等于n1+1，客戶端重新發(fā)送連接請求。在服務器端收到客戶端確認報文的時進行檢查，如果n4=n2+1，把n2作為接收數據的初始編號，等待接收數據，否則繼續(xù)監(jiān)聽。在初始標識下最后到的P8和P11中有標記，說明連接建立成功。

三、模型驗證與分析

Petri網的模型驗證方法有兩種：可達樹（Reachability Tree）方法和線性代數（Matrix Equations）方法。在初始標識下通過工具CPN Tool我們可以得到連接的CPN模型的可達樹。（1）可達樹各結點中庫所包含的標記不超過兩個，且當庫所包含兩個標識時標記顏色各不相同，因此TCP協(xié)議連接建立的有色Petri網模型是安全的，有界的。（2）可達樹中各變遷至少引發(fā)一次，沒有從不引發(fā)的變遷。樹中每個標號有后繼標號，即每個標號都是可以引發(fā)的。對于可達集R（M0），每一標號都有一條從根到的變遷路徑，即。根據活性的定義，可知該模型是活的，不會有死鎖發(fā)生。（3）可達樹中不存在無用的循環(huán)，其中兩個循環(huán)是處理發(fā)送端和接收端所接受的報文序號是否匹配。（4）可達樹中可達狀態(tài)M3經變遷T3可回到初始狀態(tài)，所以該CPN模型是可逆的。保證了協(xié)議周期的實現，即能夠重復執(zhí)行請求連接的功能。

本文利用有色Petri網的建模的方法和工具CPN Tool，建立了TCP協(xié)議的連接建立過程的有色Petri網模型，得到模型的了可達樹，通過可達樹的方法，驗證了所建模型的有界性、安全性、活性、可逆性等性質。從而證明了所構造的形式化模型的正確性，同時也驗證了協(xié)議的邏輯正確性。

參 考 文 獻

[1]周必水，酈泓．有色Petri網在通信協(xié)議中的應用[J]．系統(tǒng)仿真學報．2003，15（8）：112～114

tcp協(xié)議范文3

【關鍵詞】圖層，幀

計算機輔助教學（Computer Assisted Instruction 簡稱CAI）指的是應用計算機作為教學的輔助手段，通過學習者與計算機交互作用完成教學過程。CAI構成了一種個別化學習環(huán)境，讓學習者利用計算機的特點和優(yōu)勢，通過與計算機的交互，完成某一具體課程的學習。作為一種教學媒體，計算機可以起到與其它傳播媒體一樣的呈現知識、給予反饋等作用，但是由于其有著存貯、處理信息、工作自動化等功能，因此計算機輔助教學（CAI）具有如下特點：

（1）大容量的非順序式信息呈現。計算機可存貯相當豐富的信息量，可包括一門課程或與某個對象有關的全部知識。學習者既可以瀏覽所有知識，也可以按需要獲取其中任意所感興趣的一部分，而不僅是按順序閱讀，或是按教師所給出的那一部分。

（2）學生可以控制學習內容和學習進度。通常的CAI系統(tǒng)都允許學生選擇學習內容，也設置一些同步措施，僅當學生學習了前一部分知識后才進入下一步的學習。這樣，學生的學習進展不受時間與地點的限制，可以取得最佳的學習速度。

（3）實現因人施教的教學原則和及時反饋原則。CAI系統(tǒng)可通過提問、判斷、轉移等交互活動，分析學生的能力和學習狀況，調節(jié)學習過程，實現因人施教的教學原則和及時反饋原則。

（4）學生在CAI活動中處于一種積極、主動的精神狀態(tài)。因為教學進度由學生控制和連續(xù)的提問-反饋或是操作一反應刺激等交互活動，學生在CAI活動中處于一種積極、主動的精神狀態(tài)，不象被動受教時那么容易疲勞和受干擾，從而可以取得較好的教學效果。

（5）網絡技術使CAI可獲得群體的支持。目前的網絡技術使CAI可獲得群體的支持，解決個別化學習與群體學習的矛盾。

CAI活動的效果受教師態(tài)度的影響。實驗證明，CAI活動的效果受教師態(tài)度的影響，積極推廣CAI的教師所用CAI的教學效果好，反之亦然。

在過去的幾年里，CAI的發(fā)展速度是超出人們想象的。就全國來言，大量的學校、部門、公司、企業(yè)，以各自不同的目的，帶著極大的熱情投入到CAI的開拓當中，并以各自不同的優(yōu)勢推動著CAI向前迅猛地發(fā)展，目前，已經形成了以下幾個發(fā)展趨勢：

1.多媒體技術的采用使CAI手段更加豐富。多媒體教學系統(tǒng)是一種以計算機為中心，處理、控制各種教學媒體綜合進行教學活動的系統(tǒng)，它既具有各種教學媒體的特點和優(yōu)勢，又發(fā)揮了以計算機為核心的控制作用，因此他具有多重感觀刺激，傳輸信息量大，易于接受，人機交互性強，操作簡單等特點。它既是CAI發(fā)展方向，也是現代教育發(fā)展的方向，所以引起了各方人士高度的重視。

2.計算機生產技術的進步，存貯成本的降低， 使大量的存貯信息成為可能。目前，一方面硬盤的價格大幅度的降低，另一方面CD-ROM光盤的大量使用，使得存貯容量不再是問題。圖形、動畫、音像等各種素材得以大量存儲和自由調用。這也為多媒體教學系統(tǒng)打下了良好的物質基礎。

3.網絡技術在教學領域的采用，使教學的觀念發(fā)生了質的變化

4.平臺軟件為CAI軟件制作提供了方便的開發(fā)工具。目前CAI領域中的一項重大事件是工具平臺的使用。由于計算機技術的迅速發(fā)展，其功能不斷加強，操作卻越來越簡便和易于掌握。這不但使非計算機專業(yè)人員編制CAI軟件成為現實，而且使CAI軟件實現了多媒體技術。

5.微機操作的窗口化。新一代的操作系統(tǒng)（平臺）已經朝著直觀、易懂的窗口化方向發(fā)展，以圖標管理代替文件管理，以圖標形狀代替操作信息，以鼠標指點代替鍵盤操作方法。這為進一步普及微機應用提供了基礎。

傳輸控制協(xié)議（Transmission Control Protocol TCP）是一種面向連接的、可靠的、基于字節(jié)流的運輸層通信協(xié)議，通常由IETF的RFC 793說明。在簡化的計算機網絡OSI模型中，它完成運輸層所指定的功能。在因特網協(xié)議族中，TCP層是位于IP層之上，應用層之下的中間層。不同主機的應用層之間經常需要可靠的、像管道一樣的連接，但是IP層不提供這樣的流機制，而是提供不可靠的包交換。

TCP原理的特點和功能如下：

（1）面向連接的服務。對保證數據流傳輸可靠性十分重要。

（2）高可靠性：方法：確認與超時重傳。

（3）全雙工通信

（4）支持流傳輸：流傳輸 無報文丟失、重復、亂序的正確數據報文序列；

（5）傳輸連接的可靠建立與釋放：3次握手

（6）提供流量控制與擁塞控制

TCP協(xié)議的功能

（1）保證傳輸的可靠性。TCP協(xié)議是面向連接的。所謂連接，是指在進行通信之前，通信雙方必須建立連接才能進行通信，而在通信結束后終止其連接。相對于面向無連接的IP協(xié)議而言，TCP協(xié)議具有高度的可靠性。當目的主機接收到由源主機發(fā)來的IP包后，目的主機將向源主機回送一個確認消息，這是依靠目的主機的TCP協(xié)議來完成的。

TCP協(xié)議中有一個重傳記時器（RTO），當源主機發(fā)送IP包即開始記時需要說明的是，TCP協(xié)議所建立的連接是端到端的連接，即源主機與目的主機間的連接。internet中每個轉接節(jié)點（路由器）對TCP協(xié)議段透明傳輸。

總之，IP協(xié)議不提供差錯報告和差錯糾正機制，而TCP協(xié)議向應用層提供了面向連接的服務，以確保網絡上所傳送的數據包被完整、正確、可靠地接收。一旦數據有損傷或丟失，則由TCP協(xié)議負責重傳，應用層不參與解決。

（2）提供部分應用層信息的功能。在TCP協(xié)議之上是應用層協(xié)議（如FTP、SMTP、TELNET等），最終需依靠它們實現主機間的通信。TCP協(xié)議攜帶了部分應用層信息，可用來區(qū)別同一報文數據流的一組IP包及其性質。

TCP協(xié)議對這些應用層協(xié)議規(guī)定了整數標志符，稱為端口序號。被規(guī)定的端口序號成為保留端口，其值在0～1 023范圍內（如端口序號23，用于遠程終端服務）。此外還有自由端口序號，供個人程序使用，或者用來區(qū)分兩臺主機間相同應用層協(xié)議的多個通信，即兩臺主機間復用多個用戶會話連接。

進行通信的每臺主機的每個用戶會話連接都有一個插口序號，它由主機的IP地址和端口序號組成。在internet中插口序號是惟一的，一對插口序號惟一地標識了一個端口的連接（發(fā)端插口序號=源主機IP地址+源端口序號，收端插口序號=目的主機IP地址+目的端口序號）。利用插口序號可在目的主機中區(qū)分不同源主機對同一個目的主機相同端口序號的多個用戶會話連接。

在TCP協(xié)議段的頭部各域中具有碼位項。其中，SYN碼位為應用數據流的開始位（當SYN置1，表示該IP數據包為某一應用報文的第一份數據包），FIN碼位為應用數據流的結束位（當FIN置1時，表示此時數據包為某應用報文的最后一份數據包）。因此可利用SYN/FIN兩個碼位來規(guī)定某一應用報文（或某一應用數據流）的開始與結束。

TCP協(xié)議就是利用端口序號和SYN/FIN碼位來區(qū)分應用數據流并判斷其性質的，從而使具有四層功能的高端路由器具有某些對應用數據流的控制功能。

TCP協(xié)議只定義了一種報文格式，建立、拆除連接、傳輸數據使用同樣的報文

1.傳輸連接的建立

TCP是面向連接的協(xié)議，運輸連接的建立和釋放是每一次面向連接的通信中必不可少的過程

運輸連接的管理就是使運輸連接的建立和釋放都能正常地進行。

在連接建立過程中要解決以下三個問題：（1）要使每一方能夠確知對方的存在；（2）要允許雙方協(xié)商一些參數（如，最大報文段長度，最大窗口大小，服務質量等）；（3）能夠對運輸實體資源（如緩沖區(qū)大小，連接表中的項目等）進行分配

2.TCP的傳輸連接管理――三次握手技術。（1）TCP連接的建立采用客戶/服務器方式。（2）為了確保連接的建立和釋放都是可靠的，TCP使用三次握手的方式，其中交換了三個報文。（3）已證明三次握手是在分組丟失、重復和延遲的情況下確保非模糊協(xié)定的充要條件。

3.為何使用三次握手

當客戶端發(fā)送一連接請求報文段，沒有收到服務器端的確認，認為丟失。客戶端再重傳一次，得到確認，傳輸數據，釋放連接。

然而，客戶端第一個請求報文段并沒有丟失，而是延時到這次連接、數據傳輸、釋放連接后才到達服務器端。服務器端認為又一次新的連接，向客戶端發(fā)一確認。客戶端由于并沒有發(fā)起新的連接，不會發(fā)送數據，服務器端會一直等待，造成資源浪費。

3. TCP的流量控制。

（1）TCP采用可變發(fā)送窗口的技術進行流量控制，窗口大小的單位是字節(jié)。

（2）在TCP報文段首部的窗口字段寫入的數值就是當前設定的接收窗口數值。

（3）發(fā)送窗口在連接建立時由雙方商定，在通信過程中，接收端可根據自己的資源情況，隨時動態(tài)地調整自己的接收窗口，并且告訴對方，使對方的發(fā)送窗口和自己的接收窗口一致。

說明：（1）發(fā)送端要發(fā)送的數據共9個報文段，每個報文符長100字節(jié)，共900個字節(jié)；（2）而接收端允許的發(fā)送窗口為500字節(jié)；（3）在當前情況下，發(fā)送方可連續(xù)發(fā)送5個報文段，而不必收到確認，（已發(fā)送了二個，還可發(fā)送三個報文符）；

4. TCP差錯控制

差錯控制包括檢測受到損傷的報文段、丟失的報文段、失序的報文段和重復的報文段，以及檢測出錯后糾正差錯的機制。差錯檢測三種工具：檢驗和、確認和超時。對各種出錯報文段的處理：傳輸出錯報文段（重傳計時器）；丟失報文段（重傳計時器）；重復報文段（報文序號）；亂序報文段（對亂序報文段不確認，直到收到所有它以前的報文段為止。）；確認丟失（累計確認）

本文主要是從計算機輔助教學入手，從TCP原理演示來具體生動地介紹CAI的特點.全文全面地介紹了TCP協(xié)議，又通過動畫具體演示了TCP的連接和釋放過程，能夠生動地幫助學生理解TCP協(xié)議。從而具體體現了計算機輔助教學的優(yōu)點。

計算機輔助教學與傳統(tǒng)的教學方式相比較確實具有很多的優(yōu)勢。傳統(tǒng)的教學以課堂集體教學為基礎，這種教學通常以教師為中心，學生往往處于被動地位，其學習積極性難以調動。教師參照全班學生的平均水平和教學計劃確定教學進度并向學生提供反饋信息，忽視、較少注意或難于注意學生的個別差異。對于家庭作業(yè)，盡管教師能逐個學生加以批閱，但反饋信息不夠及時，有時學生幾天后才能得到教師批改過的作業(yè)，而這時學生又去顧及新的知識。然而計算機輔助教學相對于教師的傳統(tǒng)教學也有其固有的不足之處，比如真實性問題，雖然呈現給學生的信息可以是豐富多采的，但這些都是間接經驗，是別人做好讓學生看和聽的，甚至有的信息的真實性會受到懷疑。還有其它的不足之處，這需要從事教育工作者的合理運用。

參考文獻：

[1]吳功宜，《計算機網絡》，清華大學出版社

[2]謝希仁，《計算機網絡》，電子工業(yè)出版社

[3]肖秀金、陳霄峰，《網頁設計培訓教程》，地質出版社

[4]BehrouzA.Forouzan，Sophia Chung Fegan ，《TCP/IP協(xié)議族》，清華大學出版社

tcp協(xié)議范文4

關鍵詞：嵌入式系統(tǒng)；以太網；TCP/IP協(xié)議；UDP；ARP

中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2007)04-10947-03

1 引言

目前，嵌入式系統(tǒng)與網絡的結合已經成為嵌入式系統(tǒng)發(fā)展過程中所必須要面對的問題之一。嵌入式系統(tǒng)的網絡接入一般可以通過RS-232或RS-485等間接接入，也可以通過網絡協(xié)議直接與網絡相互連，其中，直接接入方式正逐步成為嵌入式系統(tǒng)接入網絡的主要方式，但是需要精簡TCP/IP協(xié)議棧的支持。目前使用廣泛的通用TCP/IP協(xié)議棧所包含的協(xié)議內容比較全，但同時也比較復雜。由于硬件平臺的差別，這些協(xié)議站無法直接應用于嵌入式系統(tǒng)，主要表現在以下三個方面：

(1)嵌入式操作系統(tǒng)都面向特定的領域和需求，嵌入式應用對實時性要求比較高。

(2)多任務操作系統(tǒng)的內存分配是動態(tài)的，但是在嵌入式系統(tǒng)中片RAM是靜態(tài)分配的，用于存放收到的數據包的的空間很有限。

(3)嵌入式系統(tǒng)在程序的具體實現上與通用計算機系統(tǒng)有所不同，主要體現在指針、參數傳遞、變量和數據結構的定義等方面。

因此，需要通用TCP/IP協(xié)議棧的基礎上進行精簡和改寫，以設計出精簡、高效的TCP/IP協(xié)議子集，以供嵌入式系統(tǒng)接入網絡使用。

2 TCP協(xié)議分析與簡化

通用計算機系統(tǒng)有足夠的資源支持，但是嵌入式系統(tǒng)則不同，因為其CPU處理能力和系統(tǒng)存儲能力都受到成本限制，充分利用資源、提高系統(tǒng)性價比是開發(fā)嵌入式應用的根本特點。

2.1 嵌入式TCP/IP協(xié)議棧的特點

嵌入式系統(tǒng)一般都是為了滿足某一特定的需求，對網絡支持的要求相對比較低，需要什么協(xié)議就添加相應的模塊，不需使用完整的TCP/IP協(xié)議。嵌入式TCP/IP協(xié)議棧應具有以下的特點：

(1)代碼比較簡潔，占用的存儲空間盡可能小，盡可能為應用程序節(jié)省系統(tǒng)資源。

(2)需要傳輸的數據量一般比較少，協(xié)議的實現代碼要有較高的執(zhí)行效率，具有較高的實時性。

(3)便于裁剪和擴展，對于面向不同應用的嵌入式系統(tǒng)應當根據特點對協(xié)議進行簡化或擴展，整個協(xié)議棧在滿足功能需求的前提下盡可能精簡。

TCP/IP協(xié)議棧具有層次特性，各個協(xié)議都有自己的數據格式，每次發(fā)送數據都要進行上下層協(xié)議的數據交換，進行打包和拆包的過程，在這個過程中如果采用數據拷貝的策略進行數據傳遞則會大大增加系統(tǒng)開銷。在嵌入式系統(tǒng)中，往往無法建立起數據傳遞的緩沖區(qū)，需要采用“零拷貝”技術用傳遞數據指針的方法來解決各層協(xié)議間的數據傳遞，以提高系統(tǒng)的實時性能。

2.2 TCP/IP協(xié)議的精簡

TCP/IP是幾百種網絡協(xié)議的集合。通用計算機系統(tǒng)有足夠的資源支持通信協(xié)議在內核實現，因此完整的TCP/IP協(xié)議棧（如圖1）能夠在數據傳輸的可靠性和數據流量的控制上做很多工作。

但是對于嵌入式系統(tǒng)來說，其硬件資源十分有限，同時對協(xié)議的要求也相對較低，必須對通用的TCP/IP協(xié)議進行精簡。進行精簡的途徑有兩種：

(1)將無關于系統(tǒng)功能的協(xié)議削減掉。即保留必需的協(xié)議，而對其它無關協(xié)議進行裁剪。

(2)對單獨的協(xié)議進行簡化。例如完整的ARP協(xié)議支持以太網、令牌環(huán)等網絡，但是嵌入式系統(tǒng)可能是面向于某一具體類型網絡的，對于其他的部分就可以簡化掉。

圖1

簡化后的協(xié)議仍然需要符合規(guī)定的標準：在網絡接口層，系統(tǒng)需實現ARP應答協(xié)議，該協(xié)議用于將IP地址映射成以太網MAC地址；在網際層，需要實現IP協(xié)議，主要負責IP報文報頭的正確性，并且對TCP和ICMP報文實行分流，此外，為了能夠測試系統(tǒng)與網絡的連接，在網際層還需要實現ICMP協(xié)議中的Ping應答協(xié)議，主要用于檢查網絡在傳輸層是否連通。作為運輸層的主要協(xié)議，TCP和UDP協(xié)議一般都不能缺少，對于具體的應用，一般都至少要實現其中之一。HTTP、FTP等應用層協(xié)議一般無需實現。這樣簡化后，就可以得到圖2所示的嵌入式TCP/IP協(xié)議棧的結構：

圖2 嵌入式TCP/IP協(xié)議棧結構

3 各協(xié)議的具體實現

本文實現的嵌入式TCP/IP協(xié)議運行于以89C51單片機和RTL8019AS網絡控制器為核心元件的硬件平臺上，協(xié)議代碼在Keil C51 V7.0環(huán)境下編寫。在程序的initial文件中提供了相關函數對89C51和RTL8019AS進行了初始參數設置，限于文章篇幅，與具體硬件相關的問題不再作詳細說明。

3.1 ARP協(xié)議的實現

ARP協(xié)議不攜帶用戶的有效數據，報頭長度為28字節(jié)。在ARP報頭中操作碼域表明了ARP包是ARP請求還是ARP回答，其值為1時為請求，為2時為應答。目標以太地址為目標節(jié)點IP對應的MAC地址，解析前是未知的。發(fā)送ARP請求應使用廣播方式，網段內的各個主機收到后檢查包內的IP地址，如果和本機的IP地址一樣則使用單播的方式返回ARP應答，在應答ARP包中源以太地址的域中填入自己的MAC地址。在具體設計時，要考慮到系統(tǒng)解析地址的實時性，如果每次互聯(lián)都要進行地址解析，則系統(tǒng)的實時性要下降，一般的做法是建立一個ARP地址映射表，存放常用IP地址與MAC地址的映射，這樣在解析地址時首先遍歷該表，如果目標地址已經被解析過則可以省去解析過程了。解析過程中還需要為ARP緩存中每個新生成條目賦予一個初始生存時間，使用定時器中斷，經過某一時間間隔對所有條目進行刷新檢測，若發(fā)現有條目發(fā)生超時，將其從ARP緩存中刪除。ARP緩存條目結構設計如下：

typedef struct

{unsigned long ip_addr; //IP地址

unsigned char macaddr[6]; //MAC地址

unsigned char timer; //定時器}

ARP_CACHE; //ARP緩存條目結構

3.2 IP協(xié)議及Ping 應答的實現

IP協(xié)議是TCP/IP協(xié)議族中最為核心的協(xié)議。所有的TCP、UDP、ICMP及IGMP包都以IP數據報格式傳輸。IP報頭的標準長度為20字節(jié)。在具體項目中由于數據量比較小，可以不考慮數據報分段的問題，即不允許數據報超出IP包的有效載荷。標準以太網幀數據域為1500字節(jié)，除去IP頭之外還有1480字節(jié)可以為上層協(xié)議提供有效的數據載荷，應該能夠滿足數據傳送的要求。這樣簡化可以省去軟件處理IP數據分段和重組的開銷，可以提高系統(tǒng)數據傳輸的實時性。IP協(xié)議對上一層傳下來的報文加上IP首部和IP校驗和并發(fā)往下一層，同時還要對下一層傳上來的報文進行校驗和檢查，將校驗正確的去掉IP首部，送往上一層。

為了便于測試，需要實現PING程序，在收到ICMP的回顯請求包后按照格式組裝一個ICMP的回顯應答包并發(fā)送。相關的主要函數有：

void ping_request() //PING請求

void ping_answer() //PING應答

void ping_echo() //PING應答收到后回顯

3.3 UDP協(xié)議的實現

UDP際上是直接利用IP協(xié)議進行數據報的傳輸，也就是將報文包含在IP數據包中 。UDP的數據傳輸是無連接，不可靠的，因為它不像TCP那樣，為了達到目標，首先要在兩點之間建立一個可靠的連接，因此UDP協(xié)議無法保證數據可靠性。但UDP協(xié)議具有對網絡資源開銷較小，數據處理速度快的優(yōu)點，UDP協(xié)議屬于簡單的端到端的數據傳輸協(xié)議，其報頭只有8字節(jié)，其中源端口表示UDP應用進程的端口號，除了0～1023預定的端口外，其余的都可以使用。具體實現時要完成對應用層傳下來的數據包，加上UDP首部和UDP校驗和，發(fā)往下一層。以及對下一層傳上來的數據包，進行校驗和檢查，若正確去掉UDP首部，提出數據送給應用層。需注意的是，要產生一個偽首部用于UDP數據檢驗和計算，涉及到的主要函數有：

unsigned char verifyudpcrc(union netcard xdata *pRxdnet) //對ucp頭進行校驗，錯誤返回0

void udp_send(union netcard xdata *pTxdnet, unsigned char xdata * psource, unsigned int len) //UDP包發(fā)送處理

void udp_recieve(union netcard xdata *pRxdnet)UDP包接收處理

3.4 TCP協(xié)議的實現

TCP協(xié)議是面向連接的、端對端的可靠通信協(xié)議，可分以下幾個步驟實現：

(1)建立連接。這一過程就是我們常說的三次握手過程。

(2)驗證。采取相應的措施消除傳輸中的錯誤，保障傳輸的可靠性，利用序列號解決通信時重復和失序的問題。

(3)流量控制。設置發(fā)送和接收窗口。

TCP協(xié)議的功能是為應用層協(xié)議提供可靠的面向連接的數據傳輸服務，是嵌入式應用系統(tǒng)協(xié)議棧中最為復雜的協(xié)議。在TCP協(xié)議實現中，由于請求發(fā)起端(客戶端)與請求相應端(服務器端)在通信中所處地位不同，相應地兩者的中間演變狀態(tài)也不完全相同。客戶端與服務器端在一個TCP連接從正常建立到正常中止分別經歷5個和6個狀態(tài)，相應控制信息均在TCP頭部信息的6位控制標記位中得以表示。對于嵌入式系統(tǒng)中TCP協(xié)議的實現，應從嵌入式應用的角度出發(fā)，盡可能減少冗余狀態(tài)。程序中需要構造一個TCP_STATUS結構來記錄每一個TCP連接的狀態(tài)信息，其結構如下：

typedef struct

{unsigned long ip_addr; //源IP 地址

unsigned int port; //端口號

unsigned long remo_sequ; //對方序列號

unsigned long local_sequ; //本方序列號

unsigned long old_sequ; //上一次序列號

unsigned long remo_ack; //對方應答號

unsigned char timer; //超時用定時器

unsigned char quiet; //連接活動性

unsigned char state; //當前狀態(tài)

}TCP_STATUS; //連接狀態(tài)結構

4 結束語

嵌入式系統(tǒng)的應用非常廣泛，解決嵌入式系統(tǒng)的網絡接入問題具有十分重要的意義。本文實現的精簡TCP/IP協(xié)議棧在具體應用中有良好表現，可以滿足正常的數據傳輸。由于設計與實現的過程中將應用層協(xié)議全部精簡，協(xié)議在運行過程中的流量控制能力及協(xié)議自身的安全性都有所下降，在對安全性和穩(wěn)定性要求較高的應用場合（如軍事、金融等領域），需要對協(xié)議的簡化有所斟酌。

參考文獻：

[1]羅蕾. 嵌入式實時操作系統(tǒng)及應用開發(fā)[M]. 北京:北京航空航天大學出版社. 2005.

[2]徐愛鈞，彭秀華. Keil Cx51 V7.0單片機高級語言編程與μVision2應用實踐[M]. 北京:電子工業(yè)出版社,2004.

[3]程耕國，高厚禮. 基于TCP/IP協(xié)議單片機上網的設計與實現[J]. 武漢科技大學學報(自然科學版)，2004,(2).

[4]田夏利，汪繼軍，薛勝軍. 嵌入式Internet中UDP協(xié)議的實現[J]. 計算機與數字工程，2006,(2).

tcp協(xié)議范文5

等特點，對常用 TCP/IPV6 協(xié)議棧進行了裁減和簡化，裁減掉一些不常用但不影響基本通信 功能的協(xié)議模塊，同時對要保留下來要實現的各個協(xié)議進行簡化，只實現其基本功能。設計完 成實現后的協(xié)議棧，具有代碼量少，運行效率高和良好的可移植性等特點，適合于各種嵌入 式設備，是一種解決嵌入式設備接入 IPV6 網絡的可行方案。

關鍵詞：IPV6；嵌入式操作系統(tǒng)；鄰居發(fā)現；ICMPV6；地址解釋

Abstract

Via the research and analyse for the IPV6 technique in this article.In allusion to the MCU on embeded system is not fast，and the storage capability is low，we cut down the common IPV6 stack. In this design we cut down some unusuary used but not affect basic communication protcols.Besides， for the saved protocols we only realize it’s basic function.After the achievment we find that this stack little-codes， efficiency-runing and have good grafted ability. So it fit for embeded system devices， and be

considered as a feasible scheme for embedded system connecting to IPV6 network.

Keywords: PV6; Embedded Operating System; Neighbor Discovery; ICMPV6; Address Resolution.

1. 引言

嵌入式Internet技術是指把Internet技術 應用于嵌入式設備， 實現嵌入式設備的信息 交互，是嵌入式技術與Internet技術的結合， 具有非常廣大的市場前景。目前不少廠商都 在進行這方面研究， 并推出了不少嵌入式 Internet解決方案，比較常用的成熟的解決方 案有，瑞士計算機科學院Adam Dunkels寫的 ulP和 LWIP，它們以IPV4技術為基礎，以精 簡為指導思想，把復雜的TCP/IP技術引入嵌 入式設備，滿足嵌入式設備接入網絡的需 求。而作為IPV4改良版本的IPV6，是對IPV4 的升級和改進，是下一代網絡的核心，如何 以IPV6技術為基礎，設計一款和嵌入設備結 合的具 有 代碼量 少 ，功能 簡 單的精簡 TCP/IPV6協(xié)議棧是一件非常現實意義的挑 戰(zhàn)，也是本課題設計的目的所在。

2. IPV6 協(xié)議棧

IPV6協(xié)議棧是基于IPV6網絡層的協(xié)議， 和IPV4一樣，遵循現有互聯(lián)網四層網絡互聯(lián) 體系結構，如圖1所示。從圖中我們可以看到， 協(xié)議棧分為網絡接口層，互聯(lián)網

層，傳輸層，應用層四層。應用層直接面 向用戶，并提供訪問其它層服務的功能;傳 輸層用于提供源主機和目的主機上的對等 實體對話;網絡接口層屏蔽了具體的硬件實

現細節(jié)，負責底層數據的接收和發(fā)送；網絡

層是整個TCP/IP體系結構的關鍵部分，其主 要功能是在網絡上提供可靠的主機到主機 的數據傳送。IPv6協(xié)議正是位于該層，它包 含的主要協(xié)議模塊有IPV6，ICMPV6，鄰居發(fā) 現ND，IPsec等。

2.1 IPV6 協(xié)議

根據RFC2460對IPV6功能的描述，IPV6 主要負責把上層來的數據段添加IPV6報頭， 交由底層發(fā)送；把下層接收到的報文經過處 理和分析，交給TCP，UDP或ICMPV6處理。 和IPv4相比 IPv6的改變主要集中在以下幾 個方面:地址容量的擴展，報頭格式的簡化， 支持擴展和選項的改進，數據流標簽的能力，認證和保密的能力等[1]。

2.2 ICMPV6 協(xié)議

ICMPV6協(xié)議合并了IPv4中ICMP(控制 報文協(xié)議)，I- GMP(組成員協(xié)議)、ARP(地 址解析協(xié)議)等多個協(xié)議的功能，實現差錯 控制，地址解釋等功能，并支持Mobile IPv6。 ICMPV6報文封裝在IP報文中，是IP報文的 有效載荷數據，它通過它的各種錯誤報文和 信息報文的交換來實現差錯控制，地址解釋 和路由前綴信息獲取等功能。

2.3 鄰居發(fā)現(Neighbor discovery) 協(xié)議

鄰居發(fā)現協(xié)議ND是IPv6協(xié)議棧中的核 心協(xié)議，是IPV6解決鄰節(jié)點交互的一個重要 協(xié)議。它定義了下列問題的解決機制：路由 發(fā)現，前綴發(fā)現，參數發(fā)現，地址自動配置， 地址解釋，下一跳決定，鄰居不可達，重復 地址檢測，重定向。鄰居發(fā)現的這些功能是 通過5個ICMP報文（鄰居請求/鄰居通告報 文，路由器請求/路由器通告報文，重定向報 文）的交換來實現的。 3. IPV6 協(xié)議棧的精簡

協(xié)議棧精簡的核心是“微型化”，我們對 協(xié)議棧進行協(xié)議模塊裁減和單個協(xié)議簡化。

3.1 協(xié)議模塊裁減

協(xié)議模塊裁減是指在保障基本通信功 能的前提下盡可能去掉一些協(xié)議模塊，節(jié)省 系統(tǒng)資源。網絡接口層我們只考慮 802.3 以 太網協(xié)議（CSMA/CD，MAC，LLC），不考 慮面向 CAN，RS-232，RS-485，射頻，藍牙等 相關的支持模塊。接入方式上只考慮用路由 器接入方式，不考慮撥號連接方式，去掉和 撥號連接方式相關的面向點對點連接的 PPP 協(xié)議和 SLIP 協(xié)議，這兩個協(xié)議在網絡 接口層占用的代碼量比較多；IP 層只實現基 本的報頭，不實現擴展報頭，去掉基于認證 頭和封裝安全載荷頭選項的 IPsec 協(xié)議，安 全控制交給其他層。ICMPV6 和 ND 是核心

協(xié)議必須保留；傳輸層 TCP 和 UDP 可以全 部實現也可以只實現一種，考慮的適應性， 本設計中都給予實現。因此協(xié)議模塊裁減后 要實現的核 心協(xié)議族 為 802.3 ， IPV6 ，

ICMPV6，ND，TCP，UDP。

3.2 單個協(xié)議簡化

單個協(xié)議簡化是指以單個協(xié)議為目標， 進行功能和數據結構的簡化。對 IPV6 協(xié)議 來說，只接收，發(fā)送報文，不支持報文的分 片與重組，不支持擴展報頭選項，對可靠連 接傳輸來講，包過大得不到確認，會根據擁 塞控制機制和重傳機制，減少數據分組長 度，進行重新發(fā)送，對大多數應用來說這不 會產生其他嚴重問題。對 ICMPV6 來說，只 實現錯誤報文中的目的不可達報文，信息報 文中的應答回復報文，不實現超時報文，報 文過大報文和應答請求報文，一般包過大， 超時報文由路由器實現，應答請求報文用于 主動測試中發(fā)起測試的 PC 機一端。對鄰居 發(fā)現 ND 模塊來說，只實現鄰居請求和鄰居 應答報文，嵌入式設備剛接入網絡，它可以靜 態(tài)的等待網絡上路由器定時發(fā)送的路由公 告報文，而不是主動發(fā)送路由請求報文來獲 取，不需實現路由請求/路由應答報文。嵌 入式設備連接的鄰居接點，路由一般簡單， 傳輸量少，不需重定向報文來進行路由定 向。簡化的大塊在 TCP，TCP 是整個協(xié)議簇 中最復雜，代碼量最多的協(xié)議。它的功能模 塊有：滑動窗口，流量控制，擁塞控制，TCP 連接狀態(tài)機，往返時間估計，重傳協(xié)議。本 協(xié)議棧的目標是有操作系統(tǒng)支持的嵌入式 系統(tǒng)，速度和存儲量比 8 位和 16 位單片機 都有提高，不必采用分配固定緩沖區(qū)的形式 進行接收一幀處理一幀，可以考慮采用分配 一個較大的緩沖區(qū)實現滑動窗口機制，用來 提高傳輸效率，實驗證明，傳輸效率的提高 是明顯的，往返時間估計和重傳機制比較簡 單，代碼量不大，可以實現，TCP 狀態(tài)機表 示 TCP 進程通信的狀態(tài)遷移，是 TCP 的核

心必須實現，可以不實現流量控制機制，因

為流量不是很大。因此 TCP 模塊實現的功 能有：TCP 有限自動機，滑動窗口，往返時 間估計，重傳協(xié)議。忽略流量控制與擁塞控 制模塊，在可靠連接中，當因擁塞而發(fā)生數 據丟失的時候，發(fā)送方收不到確認就采用重 傳機制重發(fā)數據[2]。

4. 嵌入式精簡 IPV6 協(xié)議棧的設

計與實現

在設計協(xié)議棧過程中，我們在嵌入式操 作系統(tǒng)基礎上設計和實現一個操作系統(tǒng)模 擬層，實現基本的時鐘，消息管理和進程同 步等基本操作系統(tǒng)功能。協(xié)議進程方面，把 所有的協(xié)議棧封裝到單獨進程中，應用程序 可以駐留在其中或作為一個單獨的進程，這 樣既實現了與操作系統(tǒng)分離，又避免了層間 切換。對于內存管理采用類 BSD buf 結構， 把靜態(tài)緩沖區(qū)和動態(tài)緩沖區(qū)鏈接起來[3]。

4.1 IPV6

IPV6 模塊主要用于完成對接收到的 IPv6 數據報進行處理，對需要發(fā)送的 IPV6 數據包進行構造并遞交底層發(fā)送。當接收到 一個數據包時，網絡設備驅動調用 ip_input() 函數來對其 IP 報頭進行檢查，檢查其版本 號，報文長度，載荷長度，目的節(jié)點地址和 下一報頭，待檢查無誤后，根據下一包頭的 類型分別提交給不同的處理模塊。當要發(fā)送 數據時 ， 必須要知道發(fā) 送報文的下 一跳 IPV6 地址，以及該地址的相對應 MAC 地址， ip_route()函數就是為實現這樣的功能而設 計的，其獲取下一跳 IPV6 地址與其對應 MAC 地址的處理流程如圖 2 所示。 圖中，目的緩存用來存儲著一系列最近 的報文流量與對應的下一跳 IP 地址的關系，

前綴列表存儲著一系列子網前綴和其他地 址前綴及其對應的下一跳 IP 地址的關系， 如果兩者中都沒有找到匹配的記錄，則再從 前綴列表中選擇默認路由器作為傳輸的下 一跳 IPV6 地址。

在成功獲取了下一跳 IPV6 地址后，數

據就進入傳輸階段，傳輸階段由 ip_outputif() 函數控制，ip_output()函數填充好報頭，選擇 好發(fā)送網絡接口，然后激活發(fā)送網絡接口進 行數據發(fā)送[4]。

4.2 ICMPV6

ICMPV6 負責接收， 解釋和發(fā) 送 ICMPV6 報文。收到報文后，如果為鄰居信 息報文則轉交給鄰居發(fā)現模塊，如果為診斷 報文則交給 ICMPV6 診斷模塊。ICMPV6 模 塊只實現了應答回復報文，目的不可達報 文。當處理到達的 IP 報文時，如果下一報 頭既不是 TCP，UDP 也不是 ICMPV6，那么 表示在嵌入式設備端的協(xié)議棧的已經到達 IP 層，是端口不可達，發(fā)送目的不可達報文。 當收到 ICMPV6 的應答請求報文時，就發(fā)送 應答回復報文，其格式與請求報文相似，在收 到的請求報文的基礎上改變報文類型，重新 計算校驗和，

在 IP 報頭中將源，目的地址對調就可 以了。4.3 鄰居發(fā)現

鄰居發(fā)現是精簡 IPV6 協(xié)議簇最核心的 協(xié)議，它利用鄰居請求報文和鄰居公告報文 的交換，實現地址解釋，地址重復性檢測， 以及地址自動配置功能。不實現路由器請求

/路由器公告報文，和重定向報文。

鄰居請求報文

類型值為 135，報文 IP 頭的源地址域為 發(fā)送鄰居請求報文接口的地址或者未指定， 目的地址域為與被請求目標地址相關聯(lián)的 被請求節(jié)點組播地址，或者就是被請求目標 地址本身。ICMPV6 報頭域中的目標地址域 為被請求目標地址。選項域可以包含源鏈路 層地址選項，用來告訴對方發(fā)送請求節(jié)點的 MAC 地址，當源地址為指定

地址時必須包含該選項。

鄰居公告報文

類型值為 136，用來響應鄰居請求報文， 或者用來告知節(jié)點其鏈路層地址的改變，報 文 IP 頭的源地址為發(fā)送鄰居公告報文的接 口地址，目的地址為發(fā)送鄰居請求的單播地 址，或者是用來公告給所有鄰居節(jié)點其鏈路 層地址改變的全節(jié)點多播地址。目標地址就 是被解釋的 IPV6 地址，或者在地址唯一性

驗證中將要采用的 IPV6 地址。 地址解釋就是節(jié)點僅僅知道鄰居節(jié)點

IP 地址的情況下，通過發(fā)送鄰居請求報文和 接收鄰居公告報文，來得到對應節(jié)點鏈路層 地址的過程，是鄰居發(fā)現模塊中最重要的一 個功能模塊，其處理過程如圖 3 所示。

節(jié)點 A 知道節(jié)點 B 的鏈路 IPV6 地址

FEC0:0:0:1::B 但不知道節(jié)點 B 的鏈路層地 址 00-10-5C-F7-5C-96，沿箭頭方向，A 發(fā)送鄰 居請求報文，IP 域的目的地址是要求被解釋

的目標地址 FEC0：0：0：1：：B。節(jié)點 B

收到鄰居請求報文后，查看目標地址就是屬 于本機，是則發(fā)送一個單播的鄰居公告報文 給 A，在鄰居公告報文的目的鏈路層地址選 項 里 包含節(jié) 點 B 的鏈 路層 地址

00-10-5C-F7-5C-96。這樣

節(jié)點 A 知道了節(jié)點 B 的鏈路層地址， 地址解釋過程完成[5]。

5. 測試與驗證

5.1 在 Altera De2 上的實現與測試

課題的開發(fā)環(huán)境： Altera De2（硬件平 臺）， Quartus II 5.1 和 Nios II 5.1（軟件平 臺），整個開發(fā)過程以 LWIP1.1.0 為參考， 在理解了 LWIP 的結構后在結合開發(fā)環(huán)境改 寫。完成后對協(xié)議棧進行了測試和驗證，測 試主要集中在網絡層的 ND，IPV6，ICMPV6 模塊。由 于鄰居發(fā) 現模塊建 立在 IPV6，ICMPV6 基礎上的，對鄰居模塊的測試 相當于對 IPV6 和 ICMPV6 也進行了測試，

很具有代表性[6]。

受周圍網絡環(huán)境中無 IPV6 路由器所 限，測試在 IPV6 局域網上進行，Altera de2 通過以太網與 PC 機直接相連。測試對象電 路板 MAC 地址為 00-10-5C-F7-5F-

5D，其經過地址轉換算法得到的本地 IPV6 地址為：fe80:210:5cff:fef7:5f5d，當它 接入網絡時，為了對自己將要配置的地址進 行唯一性驗證，它要發(fā)送鄰居請求報文，通 過 PC 端網絡抓包工具 Sniffer，我們抓到了由 目標板發(fā)出的鄰居請求報文，如圖 4 所示：

圖 4 鄰居請求報文

從圖中看到其報文的類型值為 135。目

標地址為 fe80:210:5cff:fef7:5f5d。

測試協(xié)議棧在獲取鏈路地址后，我們在

PC 機端執(zhí)行 ping6 fe80::210:5cff:fef7:5f5d。 這個過程中要知道目標板的鏈路層地址，于 是發(fā)起針對目標板 IPV6 地址的地址解釋。 在地址解釋過程中，我們抓到了目標協(xié)議棧 發(fā)送的，包含自己鏈路層地址的單播鄰居公 告報文，如圖 5 所示。

圖 5 鄰居公告報文

由圖可得知，報文類型值為 136，目標

地址為目

標板本地 IPV6 地址

fe80::210:5cff:fef7:5f5d。

5.2 在 s3c4410box 上的移植

移植目標平臺：基于 s3c4410box 處理器的 ARM7 開發(fā)板，按照通用的方法，先移植了 uc/os-ii 嵌入式操作系統(tǒng)，在移植好 的基礎上用操作系統(tǒng)函數編寫了操作系統(tǒng) 模擬層，把網絡接口層的函數指針指向電路 板提供的網卡驅動程序，在系統(tǒng)啟動初試化 函數中添加針對 IPV6 協(xié)議棧的啟動代碼。 完成這些后我們使用 altera de2 上一樣的測試方法進行測試，實驗結果證明協(xié)議棧滿足基本通信功能。證明協(xié)議棧可以在該電路板 上進行移植[7]。6. 結束語

本文介紹了嵌入式精簡 TCP/IPV6 的設 計思想和實現方法，精簡性和可移植性是其 考慮的主要方面，該協(xié)議棧是一種解決了嵌 入設備和接入 IPV6 網絡的可行解決方案。

參考文獻

[1] Robert e f. Embedded Internet Systems Come Home[ J]. IEEE Internet Computing，2001，5(1):52-53.

[2] Ruhuarvi j，Mahonen P，Saaranen M J. providing

[3] Soung S. Network-Driven layered multicast with IPV6[J]，Lecture Notesin Computer Science， 2000 ， Volume

18 :11.

[4] Liu Li-feng，Zou Shi-hong. A congestion and rate control scheme based on directed diffusion in wireless sensor networks[J].Journal of Beijing University of Posts and Telecommunications，2006，29(2):54-58.

[5] Chris M，Maillik T， A look at native Ipv6

multicast[J]， IEEE Internet Computing，2004 Volume8 Issue4: 48

[6] 周立功. SOPC 嵌入式系統(tǒng)實驗教程. 深圳:北京航空航天出版社. 2006 :241-248

tcp協(xié)議范文6

關鍵詞：互聯(lián)網；嵌入式系統(tǒng)；協(xié)議棧；數據；報文；擁塞

中圖分類號：TP311 文獻標志碼：A 文章編號：1009-3044(2008)31-0860-03

Research of Congestion Control Based on Embedded TCP/IP Protocol Stack

LI Chao1,2, HE Xian-bo1, WANG An-zhi1, HUANG Miao3

(puter College, China West Normal University, Nanchong 637002, China; 2.Nanchong Tourism School, Nanchong 637000, China; 3.Software Engineering School, Pingdingshan University, Pingdingshan 467003, China)

Abstract: This paper according to the present development condition of the computer network and embedded system software, summing up the general characteristics and procecing of the embedded TCP/IP protocol stack. Furthermore, discussing Congestion Control mechanism of the protocol stack in detail, especially analyzing and comparing sorts and implement algorithm of TCP Congestion Control mechanism and IP Congestion Control mechanism.Finally, setting up present Congestion Control solving methods of embedded TCP/IP protocol stack.

Key words: Internet; embedded system; protocol stack; data; message; congestion

1 引言

計算機網絡的飛速發(fā)展，已經改變了人們的生產和生活方式。數字化信息家電的日益普及，使嵌入式系統(tǒng)連接到網絡成為了可能。互聯(lián)網采用的是無連接的端到端數據包交換，提供“盡力而為”服務模型的設計機制。這種機制的最大優(yōu)勢是設計簡單，可擴展性強。然而隨著互聯(lián)網用戶數量的膨脹，網絡的擁塞問題也越來越嚴重。據統(tǒng)計，互聯(lián)網上95%的數據流和90%的報文數使用的是TCP/IP協(xié)議，因此，嵌入式TCP/IP協(xié)議棧的擁塞控制機制對控制網絡擁塞更具有特別重要的意義。

2 嵌入式TCP/IP協(xié)議棧概述

TCP/IP協(xié)議是由很多協(xié)議組成的協(xié)議族[1]。嵌入式系統(tǒng)引入互聯(lián)網支持所需的主要協(xié)議為ARP、RARP、IP、ICMP和TCP協(xié)議。ARP和RARP協(xié)議提供網絡地址的解析；ICMP協(xié)議提供網絡診斷功能；TCP和IP協(xié)議提供網絡傳輸和網絡互聯(lián)[1-2]。在網絡接口層,系統(tǒng)需實現ARP應答協(xié)議，該協(xié)議用于將IP地址映射成以太網MAC地址；在網際層，需要實現IP協(xié)議，主要負責IP報文報頭的正確性，并且對TCP和ICMP報文實行分流，此外，為了能夠測試系統(tǒng)與網絡的連接，在網際層還需要實現ICMP協(xié)議中的Ping應答協(xié)議，主要用于檢查網絡在傳輸層是否連通。

2.1 TCP/IP協(xié)議棧處理流程

TCP/IP協(xié)議棧接收數據包的過程就是解析數據包的過程。首先當一個數據幀到達時，網絡接口控制程序將其讀入緩沖區(qū)，檢查協(xié)議類型字段，如果值依次為0X0800，表示數據域內為IP包；如果值依次為0X0806，表示數據域內為ARP包[3]。由此以確定使用那種協(xié)議模塊來處理此分組。去掉以太網幀首部的數據包將被分配到IP緩存或者ARP緩存。接著，由IP協(xié)議處理模塊或ARP協(xié)議處理模塊繼續(xù)解析。在IP協(xié)議模塊處理數據包的過程，它要通過調用ARP協(xié)議獲得對方主機的物理地址。

2.2 嵌入式TCP/IP協(xié)議棧的特點

嵌入式系統(tǒng)一般都是為了滿足某一特定的需求，對網絡支持的要求相對比較低，不需使用完整的TCP/IP協(xié)議。嵌入式TCP/IP協(xié)議棧的特點如下：

1) 開放的協(xié)議標準，獨立于特定的計算機硬件、操作系統(tǒng)和網絡硬件，可以運行在局域網，廣域網和互聯(lián)網中。

2) 統(tǒng)一的網絡地址分配方案，使得整個TCP/IP設備在網中都具有唯一的地址；標準化的高層協(xié)議，可以提供多種可靠的用戶服務。

3) 代碼比較簡潔，占用的存儲空間盡可能小，盡可能為應用程序節(jié)省系統(tǒng)資源。

4) 便于裁剪和擴展，對于面向不同應用的嵌入式系統(tǒng)應當根據特點對協(xié)議進行簡化或擴展。

TCP/IP協(xié)議棧具有層次特性，各個協(xié)議都有自己的數據格式，每次發(fā)送數據都要進行上下層協(xié)議的數據交換，進行打包和拆包的過程。在嵌入式系統(tǒng)中，往往無法建立數據傳遞的緩沖區(qū)，需要采用“零拷貝”技術來解決各層協(xié)議間的數據傳遞，以提高系統(tǒng)的實時性能。網絡協(xié)議層次模型如圖1所示。

3 擁塞控制概述

描述擁塞現象有許多不同的度量，如傳輸延時、數據吞吐量、隊列長度和網絡效率等，但是沒有哪個度量能在局部和全局意義上完全滿足擁塞評判要求，因此人們對擁塞控制并無嚴格定義，甚至對擁塞的定義都無法完全統(tǒng)一。

3.1 基本概念

定義1：若因為網絡負載增加而導致用戶的滿意度降低，用戶則認為網絡發(fā)生擁塞。

形象地說，當網絡中存在過多的報文時，網絡的性能會下降，這種現象稱為擁塞[4,5]。擁塞導致的直接結果是分組丟失率提高，端到端時延加大，甚至整個系統(tǒng)發(fā)生崩潰。當發(fā)生擁塞崩潰時，微小的負載增量將使網絡的有效吞吐量急劇下降（如圖2所示）。

定義2：當負載達到網絡容量時，吞吐量開始緩慢增長，而響應時間急劇增加，這一點稱為膝點(Knee)。

定義3：如果負載繼續(xù)增加，路由器開始丟包，當負載超過一定量時，吞吐量開始急劇下降，這一點稱為崖點(Cliff)。

定義4：擁塞控制就是采用某種策略或機制，保持網絡工作在正常的狀態(tài)下，也就是使網絡經常工作在崖點左側的區(qū)域內。從而避免擁塞的發(fā)生或者對擁塞的發(fā)生做出反應。擁塞控制的目標就是使網絡在Knee附近工作。

3.2 產生擁塞的原因

網絡擁塞是“盡力而為”服務模型的一個固有屬性。用戶間無法相互協(xié)作共享資源，多個用戶對同一網絡資源提出請求時，就可能發(fā)生擁塞。網絡擁塞產生的原因有很多，直接原因主要有三個方面：1) 存儲空間不足；2) 帶寬容量不足；3) 處理器間處理能力和速度不一致。

3.3 擁塞控制算法的設計目標

由于擁塞控制算法性能的好壞會影響整個網絡系統(tǒng)，因此在設計和評價算法時，應該站在整個系統(tǒng)的角度來考查。對于任何一種擁塞避免或控制方案，人們希望它能同時滿足以下幾點要求：高效性、公平性(魯棒性)、穩(wěn)定性、可擴展性。

4 TCP擁塞控制機制

TCP協(xié)議[6]是目前Internet上使用最廣泛的一種傳輸層協(xié)議。TCP的主要目的是為了解決Internet的穩(wěn)定性、異質性(接受端緩沖區(qū)大小，網絡帶寬及延遲等)、各流之間享用帶寬的公平性，使用效率及擁塞控制等問題，從而為Internet提供可靠健壯的端到端通訊。TCP擁塞控制策略主要包括以下四個過程：

1) 慢啟動階段[7]：保證了連接建立初期進入網絡的突發(fā)數據的流量不會過大。

2) 擁塞避免階段：當數據發(fā)送速率超過一定閾值時，算法進入此階段，而后發(fā)送速率緩慢線性增長，避免了網絡擁塞的發(fā)生。

3) 快速重傳階段[9]：當網絡發(fā)生擁塞造成數據丟失或者重傳超時時，用該策略重傳丟失的分組。

4) 快速恢復階段：把網絡從擁塞狀態(tài)中恢復出來。

4.1 TCP擁塞控制的主要參數

1) 擁塞窗口(cwnd)：描述源端在擁塞控制情況下一次最多能發(fā)送的數據包數量。

2) 慢啟動閾值(ssthresh)：擁塞控制中慢啟動階段和擁塞避免階段的分界點。初始值設為65535bytes或awnd的大小。

3) 回路響應時間(RTT)：一個TCP數據包從源端發(fā)送到接收端、源端收到接受端確認的時間間隔。

4) 超時重傳計數器(RTO)：描述數據包從發(fā)送到失效的時間間隔，是判斷數據包丟失與否、網絡是否擁塞的重要參數。通常設為2RTT和5RTT。

4.2 TCP擁塞控制算法

4.2.1 Reno算法

1990年Jacobson在Tahoe的基礎上提出了Reno算法。Tahoe算法是最早被提出來的TCP源算法，但至今仍然被大多數TCP實現所采用。Reno算法對Tahoe的改進主要體現在兩個方面。第一，收到連續(xù)三個dupACK，算法不經過慢啟動，而直接進入擁塞避免階段。第二，增加了快速重傳/快速恢復(FR/FR)機制，具體過程為：

1) 收到三個dupACK進入FR/FR。ssthresh=max(cwnd/2,2)；

2) 重發(fā)去失的數據包；

3) 窗口膨脹。cwnd=ssthresh+ndupndup為收到的重復ACK數；

4) 當min(awnd，cwnd)足夠大時，發(fā)送新的數據包；

5) 當收到非重復的ACK時，cwnd=ssthresh；

6) 轉入擁塞避免階段。可見，Reno在收到三個dupACK后，就轉入FR/FR，而遇到超時，Reno和Tahoe一樣進入慢啟動階段。可從Reno狀態(tài)轉換圖直觀地看到Reno的整個數據傳輸過程(如圖3所示)。

Reno目前被廣泛采用，以其算法的簡單、有效和魯棒性成為TCP源算法的主流。

4.2.2 NewReno算法

NewReno算法對Reno算法的改進是通過盡量避免Reno在快速恢復階段的許多重傳超時，利用一個ACK來確定部分發(fā)送窗口，立即重傳余下的數據包，從而提高網絡性能。目前，在因特網中使用最廣泛的是NewReno算法。然而NewReno算法也存在著不足，它在高速遠距離網絡中不能有效利用帶寬。

4.2.3 Sack算法

Sack算法也是對Reno算法的改進，當檢測到擁塞后，不用重傳數據包丟失到檢測到丟失時發(fā)送的全部數據包，而是對這些數據包進行有選擇的確認和重傳，從而避免不必要的重傳，減少時延，提高網絡吞吐量。由于使用選擇重傳，所以在一個窗口中數據包多包丟失的情況下，Sack算法優(yōu)于NewReno算法。但是Sack算法的主要缺點是要修改接收端TCP。

5 IP擁塞控制機制

隨著Internet業(yè)務的迅猛發(fā)展，僅依靠單一的端到端的擁塞控制機制不可能有效地解決擁塞問題，另外期望所有用戶在Internet應用中都遵守這種端到端的擁塞控制也是不現實的，這要求網絡本身也必須參與對資源的管理與控制。基于此，提出了IP擁塞控制機制。

5.1 IP擁塞控制算法

5.1.1 隨機及早檢測(RED)算法

RED(Random Early Detective)算法在路由器監(jiān)控隊列長度，一旦發(fā)現擁塞迫近，就通知源端調整擁塞窗口。它也是通過丟包的方式使源端發(fā)現超時或重復應答，隱式通知源端擁塞情況。RED算法包含兩部分：如何監(jiān)控隊列長度和何時丟棄數據包。首先，RED使用類似TCP計算超時時使用的權值Weight來計算平均排隊長度：Qe=(1-Weight)×Qe+Weight×SampleQe其中，0

5.1.2 顯示擁塞指示(ECN)算法

ECN(Explicit Congestion notification)算法在源端數據包中嵌入ECN，由路由器根據網絡情況設置CE(Congestion Experienced)比特位，源端從網絡中接收反饋回來的已被CE置位的數據包，再將隨后發(fā)出的數據包標記為“可丟棄”的數據包。改進算法NewECN可通過調整擁塞窗口cwnd大小，糾正了有長時間RTT的TCP連接的偏差，改進了共享瓶頸處帶寬的公平性。

5.1.3 加權公平排隊(WFQ)算法

WFQ(Weight Fair Queue)是公平排隊(FQ)算法的改進算法。WFQ算法對每個流即每個排隊分配一個權值。這個權值決定了路由器每次轉發(fā)該隊列的比特數量，從而控制數據流得到的帶寬。將所有權值看成1，那么FQ也是一種特殊的WFQ。權值的分配往往對應不同優(yōu)先級的數據流，例如用IP包頭中TOS域指定流的優(yōu)先級，排隊時再按優(yōu)先級分配權值。總之，WFQ根據不同數據流應用的不同帶寬要求，對每個排隊隊列采用加權方法分配緩存資源，從而增加了FQ對不同應用的適應性。

6 結論

討論了嵌入式TCP/IP擁塞控制領域的研究熱點。近年來,非線性規(guī)劃和系統(tǒng)控制理論被引入擁塞控制研究中來,一些研究者使用數學模型來描述端系統(tǒng)和網關組成的系統(tǒng)，這對擁塞控制研究有很大的推動作用。然而，對于Internet這樣一個復雜系統(tǒng)的分析與控制，只有通過通信、控制和數學等多學科的共同努力，才有望獲得突破性成果。

參考文獻：

[1] W.Richard STEVEN. TCP/IP詳解 卷1：協(xié)議[M].范建華,胥光輝，張輝，等譯.北京：機械工業(yè)出版社,2000：170-269.

[2] Jon C.SNADER. 高級TCP/IP編程[M]. 劉江林譯.北京：中國電力出版社，2001:251-286

[3] Adam DUNKELS.Design and Implementation of the TCP/IP Stack[M]. Swedish:Institude of Computer Science,2001.

[4] Gevros P, Crowcroft J, Kirstein P, etal.Congestion control mechanisms and the best effort service model[J].IEEE Network,2001,15(3):16-26.

[5] Steves W.TCP Slows Start, Congestion Avoidance, Fast Retransmit and Fast Recovery Algorithms.RFC,2001[S], 1997.

[6] 陳崗,張會生.基于IPv6的移動互聯(lián)網絡研究與實現[J].微電子學與計算機,2006,23(2):40-42