前言：中文期刊網精心挑選了tcp協議范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。
tcp協議范文1
關鍵詞： 流控制傳輸協議； 傳輸控制協議； 單路徑； 多路徑； 吞吐率； 延遲
中圖分類號：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代表的是流控制傳輸協議，它是由IEFT的信令傳輸工作組（SIGTRAN）新近提出的一種面向多媒體通信的流控制協議（SCTP），用于在IP網絡上傳輸PSTN信令消息，即通常所說的SS7 over IP。
在國內，1985年是流控制傳輸協議技術開始萌芽的時期。從1985到1995年，該技術主要局限于計算機網絡中接人端口數據流的控制技術，以防止計算設備之間大量數據互相通信時出現阻塞，保證更高的傳輸效率和可靠性。目前對該技術的研發仍處于較淺的層次，對整個IP網絡中實規PSTN信令傳輸的技術還鮮有涉及；國內的SCTP研究還主要側重于應用方面，比如SCTP與TCP的比較、SCTP在移動環境下的性能研究（例如平滑切換，移動IP，最后一跳性能惡化問題，基于SCTP移動Internet傳輸模型等）、基于獨立路徑擁塞控制的SCTP負荷分擔機制研究、結合SS7的研究，以及SCTP的安全問題研究、軍事應用等。
國外則更側重于起草標準，如：定義SCTP負荷分擔草案（多路徑同時傳輸）；制定部分可靠傳輸標準；提交建立SCTP偶聯后的動態地址重配置；提交SCTP API草案；定義SCTP對移動IP的支持；提交單播擁塞控制建議標準；TCP友好可變速率控制等等。目前，IETF致力于把SCTP作為一種通用的傳輸協議。對SCTP本身的研究集中在對其功能的完善和擴展上，主要是從兩個本質特點入手：多路徑和多流。同時，對SCTP應用的研究主要集中在兩個方面：在移動網絡中的應用和對多媒體的傳輸。
本文的主要研究工作是利用NS-2構建仿真平臺，對SCTP和TCP這兩種協議進行對比，并根據仿真的結果計算、分析和比較這兩種協議的性能，發現它們各自的優缺點。
1 TCP和SCTP的單路徑的對比研究
單路徑的實驗拓撲圖如圖1所示，一共有6個節點，2個路由節點。其中0-2是發送節點，5-7是相應的接收節點。3個發送節點都綁定了FTP應用，其中0號節點的數據包發送往5號節點，流標簽為1；1號節點的數據包發送往6號節點，流標簽為2；2號節點的數據包發送往7號節點，流標簽為3。設置最大的傳輸單元為1500。路由3、4間的droptail隊列大小分別為5、10。本實驗主要更改了1號節點和6號節點的傳輸協議?，F在設0-5號節點的路徑為L1，1-6號節點的路徑為L2，2-7號的路徑為L3。變量主要在L1上面。其中發送節點到路由節點3，路由節點4到接收節點的帶寬均為10Mbps，延遲均為15ms。路由節點3、4直接的帶寬為1.7Mbps，延遲為15ms。這樣路由節點3、4之間就成為接收方和發送方直接的瓶頸。
圖1 實驗拓撲圖
實驗一的過程是：在0.5s的時候三個節點同時開始發送數據，4s的時候斷開L1，7s的時候斷開L2。這樣做的主要目的是讓L1的數據包先在有兩個TCP傳輸協議競爭的情況下進行數據傳輸，然后逐漸斷開其他兩個鏈路的數據傳輸，來觀察TCP和SCTP在有TCP競爭條件下，數據傳輸的吞吐量，延遲和丟包率。吞吐量如圖2所示。
圖2 實驗一中TCP和SCTP數據的吞吐量
圖2所表示的是鏈路L2上的數據吞吐量。X坐標軸表示時間的變化，單位為s，Y坐標軸表示接收的數據量，單位為Byte。紅色線表示TCP協議在droptail隊列為5時的數據吞吐量。綠色線表示TCP協議在droptail隊列為10時的數據吞吐量。藍色線為SCTP協議在droptail隊列為5時的數據吞吐量，黃色為SCTP協議在droptail隊列為10時的數據吞吐量。從圖2中可以看出，總體上SCTP的吞吐量遠遠高過TCP。對于SCTP來說，在droptail隊列為5的時候，其吞吐量比10的時候略高，但差距不是很大。在兩個TCP數據傳輸斷掉以后，兩種情況下的吞吐量趨于相同，而且數據吞吐量趨于穩定?？蹿厔?，在9s以后，droptail隊列為10的時候，其吞吐量會略大于5的時候。對于TCP協議來說，很明顯，在droptail隊列為10的時候，其吞吐量高于5的時候，在兩個TCP協議的數據傳輸都斷掉以后，數據吞吐量的增長率趨于平行式增長。
圖3 實驗一中TCP和SCTP延遲對比
圖3是實驗一中SCTP和TCP兩種協議數據傳輸延遲的對比。如圖所示，是TCP和SCTP在droptail隊列為5的時候，兩種協議延遲的對比。紅色線為TCP的延遲，綠色的為SCTP的延遲。X坐標軸表示數據傳輸的時間變化，單位為s，Y坐標軸表示兩種協議在某個時刻的延遲，單位為s。從圖3中可以看到，兩者的數據線略有交叉，SCTP的延遲略高于TCP；TCP的延遲是在一個范圍內上下波動，而SCTP的延遲呈一種階段性的梯度變化。從這里也可以看出兩種數據傳輸的差別：TCP在鏈路達到穩定的時候，每次傳輸的數據量一定；而SCTP的數據傳輸，在沒有擁塞避免的情況下，是呈指數增長的。
根據實驗一的拓撲圖，更改鏈路L1和L3的數據傳輸時間，此為實驗二。在0.5s的時候1號節點開始發送數據，在1.5s的時候0號節點開始發送數據，在4.5s的時候3號節點開始發送數據，在7.5s的時候將L1和L3兩條鏈路斷開連接，8s的時候結束數據傳輸。通過觀察TCP和SCTP協議在逐漸有一個TCP協議和兩個TCP協議競爭的條件下的數據吞吐量，延遲和丟包率來對比兩種協議。
圖4 實驗二中TCP和SCTP兩種協議的數據吞吐量
在圖4中，表示的是鏈路L2上的數據吞吐量。X坐標軸表示時間的變化，單位為s，Y坐標軸表示接收的數據量，單位為Byte。紅色線表示TCP協議在droptail隊列為5時的數據吞吐量。綠色線表示TCP協議在droptail隊列為10時的數據吞吐量。藍色線為SCTP協議在droptail隊列為5時的數據吞吐量，黃色為SCTP協議在droptail隊列為10時的數據吞吐量。從圖4中可以看出，總體上來說，在相同的droptail隊列值的情況下，SCTP的吞吐量遠大于TCP的吞吐量。在兩個TCP競爭數據傳輸出現后，它們的吞吐量都有一個短暫性的下降，然后繼續趨于上升。在8.0s的時候，兩種協議的吞吐量開始趨于穩定。
對比實驗一和實驗二中數據吞吐量的圖，我們看到，由于實驗一和實驗二的區別在于競爭的TCP協議出現的時間不同，在實驗一的環境下，SCTP在有其他協議競爭的條件下，能夠更容易、更快地達到數據吞吐的穩定狀態，這樣非常有利于數據的傳輸。
圖5是實驗二中鏈路L2在droptail隊列值為10的時候的延遲對比。紅色線為TCP的延遲，綠色的為SCTP的延遲。X坐標軸表示數據傳輸的時間變化，單位為s，Y坐標軸表示兩種協議在某個時刻的延遲，單位為s。由圖5中可以看出，SCTP與TCP延遲隨時間的走勢相互交叉，與實驗一中的情形類似，SCTP的延遲略高于TCP。
圖5 實驗二TCP和SCTP的延遲對比
圖6 TCP和SCTP競爭時的延遲和吞吐量
圖6是在實驗一環境下，SCTP和TCP相互競爭下的延遲和吞吐量的對比，主要是鏈路L2和L3的對比，紅色線表示的是TCP，綠色線表示TCP。圖6上圖中，X坐標軸表示數據傳輸的時間變化，單位為s，Y坐標軸表示兩種協議在某個時刻的延遲，單位為s；圖6下圖中，X坐標軸表示時間的變化，單位為s，Y坐標軸表示接收的數據量，單位為Byte。從圖6中可以看出，情況基本與上面的實驗保持一致。在相同的droptail隊列值的情況下，SCTP的吞吐量遠大于TCP，但是TCP和SCTP的延遲相互交叉，SCTP延遲略高于TCP。
2 TCP和SCTP的多路徑的對比研究
多路徑的實驗拓撲圖如圖7所示，節點0-2合起來是一個發端，節點3-5合起來是一個收端。0是核心節點，1、2是接口，即該端點的兩個IP地址；3也是核心節點，4、5也是接口，也即該端點的兩個IP地址。1和4路徑命名為if0；2和5路徑命名為if1。
在SCTP傳輸過程中，數據只能從接口發或收，不能直接從核心節點發或收。該實驗過程為：應用層傳輸FTP數據，在0.5s后開始傳輸；在第5s前，路徑if0、if1的帶寬為5M，時延為50ms；在第5s，路徑if0性能惡化，帶寬變成1M，時延變為200ms；在第8s，傳輸結束。
圖7 SCTP多路徑仿真拓撲圖
由于TCP沒有多路徑這個特點，所以，要與SCTP作對比，只能重新建立拓撲圖。拓撲圖如圖8所示：數據傳輸過程和SCTP一樣，應用層傳輸FTP數據，在0.5s后開始傳輸；在第5s的時候鏈路發生惡化，帶寬變成1M，時延變為200毫秒；在第8s，傳輸結束。
圖8 相應的TCP拓撲圖
對于這兩種協議延遲方面的比較，我們在上一節中已經有過很詳細的對比，所以在這里，主要針對兩種協議在多路徑的情況下，對數據吞吐量作比較，如圖9所示。
圖9 多路徑下TCP與SCTP吞吐量的比較
如圖9，其中為了表示自己搭建的TCP網絡和SCTP網絡有對比性，所以測試了在圖8中拓撲圖中SCTP數據的吞吐量，如圖9中的綠線。從圖中來看，在6.5s以前兩種拓撲圖中SCTP的數據吞吐量完全吻合，這樣看來，兩種拓撲圖是具有可比性的。圖中藍色線表示TCP協議的吞吐量，黃色線表示if0路徑上SCTP的吞吐量，紅色線表示if1路徑是SCTP的吞吐量。X坐標軸表示時間的變化，單位為s，Y坐標軸表示接收的數據量，單位為Byte。從圖9中看，5s之前鏈路沒有惡化，SCTP默認if0是主路徑，5s之后鏈路if0惡化，吞吐量開始下降，此時，因為有另一條路徑if1的存在，而且鏈路狀態比if0好，SCTP開始將if1作為主路徑進行傳輸，圖中if1的吞吐量開始上升，由此可以看出，SCTP的吞吐量在經過一段時間的降低之后，會恢復原來的吞吐量，使數據傳輸不受影響。由圖9可以看出，TCP在路徑出現惡化的時候，吞吐量開始下降，如果路徑得不到緩解，吞吐量會受到很大的影響。由此可以看出，SCTP多路徑的特點較TCP存在很大的優勢。我們再來分析路徑if0數據傳輸與時間的關系，如圖10所示。圖10中有上（紅色）、中（綠色）、下（藍色）三條線。上線（紅色）代表 SCTP 把數據包發送到緩存，即入隊列；中線（綠色）代表數據包從緩存注入到網絡，即出隊列；下線（藍色）代表數據包從收端反饋回來的證實 SACK?？v坐標代表所發送的數據包序列號，橫坐標代表時間，斜率指示傳輸速率（下面類似圖的信息也是這樣的）。在第5s，帶寬和時延發生變化，路徑性能變差，所以第5s后的斜率小于第5s前的斜率，即第5s后的傳輸速率小于第5s前的傳輸速率。
圖10 if0上數據傳輸與時間的關系
3 結束語
本文主要是通過NS-2構建仿真平臺，對TCP和SCTP在單路徑和多路徑的條件下進行對比。通過兩個實驗對比發現，兩種協議在數據傳輸的延遲方面，SCTP協議略高于TCP協議，相差不是很大，但是SCTP的數據吞吐量遠遠大于TCP協議。由于SCTP具有多路徑和多重定址的特點，在應對鏈路惡化的情況時，SCTP表現出更高的穩定性。作為一個新的傳輸協議，SCTP還具有很大的發展空間，SCTP較TCP更能滿足高性能傳輸的要求，隨著IP網絡的迅猛發展，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協議異構網絡切換性能評估[J].現代電
信科技，2011.3（3）：19
[6] 方路平，劉世華，陳盼等.NS-2網絡模擬基礎與應用[M].國防工業出
版社，2008.
[7] 胡文靜.SCTP主路徑自動切換的研究[D].吉林大學碩士學位論文，
2006.
[8] 葉凌偉，陳雁.SCTP與TCP的功能對比及應用分析[J].中國數據通
信，2003.1（2）：43
[9] 賀，張繼棠.流控傳輸協議SCTP的研究[J].山西電子技術，
2005.11（5）：21
[10] 黃曉波，鄭應平.流控制傳輸協議與TCP協議的比較[J].微型機與應
用，2005.7（6）：37
[11] 成為青.流控制傳輸協議概述[J].電子電氣教學學報，2003.4（2）：31
tcp協議范文2
【關鍵詞】TCP 協議；有色Petri網；形式化描述；可達樹
隨著數據通信和網絡的發展，現在TCP/IP（Transfer Control Protocol/Internet Protocol）協議簇成為占主導地位的網絡體系結構，被廣泛的使用。有色Petri網（Colored Petri Net，CPN）是由丹麥的Jensen Kurt于1981年在Petri網基礎上定義的一種具有層次性的高級Petri網。利用在計算機上開發的CPN的建模分析工具──CPN Tools，可以建立描述系統的CPN靜態模型，并對系統模型的動態行為進行仿真，分析系統的分布、并發、同步、異步等特性，以及建立系統模型的狀態空間并分析系統的活性問題、可達性問題等。由于CPN具有嚴格的網理論形式化的數學描述、上述的特性以及建模工具提供的仿真分析功能，因此在網絡通信協議的驗證和分析上得到了廣泛的應用。
一、TCP協議連接的建立過程
TCP是一個可靠的，面向連接的，端到端的傳輸協議，它提供了具有流量控制的可靠的數據傳輸。TCP的連接建立稱為“三次握手”。（1）客戶發送第一個報文段，SYN報文段，在這個報文段中只有SYN標志置1，這個報文段的作用是使序號同步?？蛻舳诉x擇一個隨機數作為第一序號，并把這個序號發給服務器。注意SYN報文段是一控制報文段，不攜帶任何數據但它消耗一個序列號。（2）服務器發送第二個報文段，即SYN+ACK報文段，其中有兩個標志置為1這個報文段有兩個目的，一個是使用SYN同步初始序號，另一個是服務器使用ACK標志確認已經從客戶端收到的SYN報文段，同時給出期望從客戶端收到的下一個序號。服務器還必須定義客戶端要使用的接收窗口（rwnd），這就實現了TCP的流量控制。（3）客戶端發送第三個報文段。這僅僅是一個ACK報文段。它使用ACK標志和確認號字段來確認收到了第二個報文。注意這個報文段的序號和SYN的報文段使用的序號一樣，這個ACK報文段不消耗任何序號?？蛻暨€必須定義服務窗口值。在某些情況下第三個報文段可以攜帶客戶端的第一個數據塊，在這種情況下第三個報文段必須有一個新的序號來表示數據源的第一個自己的編號。一般的來說，第三個報文段不攜帶數據的，因而不消耗序號。
二、CPN模型
在利用CPN Tool建立具體模型之前，先對模型中各庫所和變遷，以及顏色類型，變量做一說明。當P1，P2，P4，P7中有標識的時候，即發送端主動打開準備發送連接請求和接受端被動打開監聽，發送第一個請求報文，其序號用變量n1綁定，在接收端收到這個請求信息的時候把n1加1作為服務器想從客戶端得到下一報文段的序號，同時和自己的初始序號一起組成確認報文段序列，用（n3，n2）來綁定。當客戶端接到這個報文的時候進行檢查，如果n3=n1+1，說明得到服務器確認報文安全，發送客戶確認報文，用（n3，n4）綁定，同時把n1作為數據傳輸的初始序號。如果n3不等于n1+1，客戶端重新發送連接請求。在服務器端收到客戶端確認報文的時進行檢查，如果n4=n2+1，把n2作為接收數據的初始編號，等待接收數據，否則繼續監聽。在初始標識下最后到的P8和P11中有標記，說明連接建立成功。
三、模型驗證與分析
Petri網的模型驗證方法有兩種：可達樹（Reachability Tree）方法和線性代數（Matrix Equations）方法。在初始標識下通過工具CPN Tool我們可以得到連接的CPN模型的可達樹。（1）可達樹各結點中庫所包含的標記不超過兩個，且當庫所包含兩個標識時標記顏色各不相同，因此TCP協議連接建立的有色Petri網模型是安全的，有界的。（2）可達樹中各變遷至少引發一次，沒有從不引發的變遷。樹中每個標號有后繼標號，即每個標號都是可以引發的。對于可達集R（M0），每一標號都有一條從根到的變遷路徑，即。根據活性的定義，可知該模型是活的，不會有死鎖發生。（3）可達樹中不存在無用的循環，其中兩個循環是處理發送端和接收端所接受的報文序號是否匹配。（4）可達樹中可達狀態M3經變遷T3可回到初始狀態，所以該CPN模型是可逆的。保證了協議周期的實現，即能夠重復執行請求連接的功能。
本文利用有色Petri網的建模的方法和工具CPN Tool，建立了TCP協議的連接建立過程的有色Petri網模型，得到模型的了可達樹，通過可達樹的方法，驗證了所建模型的有界性、安全性、活性、可逆性等性質。從而證明了所構造的形式化模型的正確性，同時也驗證了協議的邏輯正確性。
參 考 文 獻
[1]周必水，酈泓．有色Petri網在通信協議中的應用[J]．系統仿真學報．2003，15（8）：112～114
tcp協議范文3
【關鍵詞】圖層，幀
計算機輔助教學（Computer Assisted Instruction 簡稱CAI）指的是應用計算機作為教學的輔助手段，通過學習者與計算機交互作用完成教學過程。CAI構成了一種個別化學習環境，讓學習者利用計算機的特點和優勢，通過與計算機的交互，完成某一具體課程的學習。作為一種教學媒體，計算機可以起到與其它傳播媒體一樣的呈現知識、給予反饋等作用，但是由于其有著存貯、處理信息、工作自動化等功能，因此計算機輔助教學（CAI）具有如下特點：
（1）大容量的非順序式信息呈現。計算機可存貯相當豐富的信息量，可包括一門課程或與某個對象有關的全部知識。學習者既可以瀏覽所有知識，也可以按需要獲取其中任意所感興趣的一部分，而不僅是按順序閱讀，或是按教師所給出的那一部分。
（2）學生可以控制學習內容和學習進度。通常的CAI系統都允許學生選擇學習內容，也設置一些同步措施，僅當學生學習了前一部分知識后才進入下一步的學習。這樣，學生的學習進展不受時間與地點的限制，可以取得最佳的學習速度。
（3）實現因人施教的教學原則和及時反饋原則。CAI系統可通過提問、判斷、轉移等交互活動，分析學生的能力和學習狀況，調節學習過程，實現因人施教的教學原則和及時反饋原則。
（4）學生在CAI活動中處于一種積極、主動的精神狀態。因為教學進度由學生控制和連續的提問-反饋或是操作一反應刺激等交互活動，學生在CAI活動中處于一種積極、主動的精神狀態，不象被動受教時那么容易疲勞和受干擾，從而可以取得較好的教學效果。
（5）網絡技術使CAI可獲得群體的支持。目前的網絡技術使CAI可獲得群體的支持，解決個別化學習與群體學習的矛盾。
CAI活動的效果受教師態度的影響。實驗證明，CAI活動的效果受教師態度的影響，積極推廣CAI的教師所用CAI的教學效果好，反之亦然。
在過去的幾年里，CAI的發展速度是超出人們想象的。就全國來言，大量的學校、部門、公司、企業，以各自不同的目的，帶著極大的熱情投入到CAI的開拓當中，并以各自不同的優勢推動著CAI向前迅猛地發展，目前，已經形成了以下幾個發展趨勢：
1.多媒體技術的采用使CAI手段更加豐富。多媒體教學系統是一種以計算機為中心，處理、控制各種教學媒體綜合進行教學活動的系統，它既具有各種教學媒體的特點和優勢，又發揮了以計算機為核心的控制作用，因此他具有多重感觀刺激，傳輸信息量大，易于接受，人機交互性強，操作簡單等特點。它既是CAI發展方向，也是現代教育發展的方向，所以引起了各方人士高度的重視。
2.計算機生產技術的進步，存貯成本的降低， 使大量的存貯信息成為可能。目前，一方面硬盤的價格大幅度的降低，另一方面CD-ROM光盤的大量使用，使得存貯容量不再是問題。圖形、動畫、音像等各種素材得以大量存儲和自由調用。這也為多媒體教學系統打下了良好的物質基礎。
3.網絡技術在教學領域的采用，使教學的觀念發生了質的變化
4.平臺軟件為CAI軟件制作提供了方便的開發工具。目前CAI領域中的一項重大事件是工具平臺的使用。由于計算機技術的迅速發展，其功能不斷加強，操作卻越來越簡便和易于掌握。這不但使非計算機專業人員編制CAI軟件成為現實，而且使CAI軟件實現了多媒體技術。
5.微機操作的窗口化。新一代的操作系統（平臺）已經朝著直觀、易懂的窗口化方向發展，以圖標管理代替文件管理，以圖標形狀代替操作信息，以鼠標指點代替鍵盤操作方法。這為進一步普及微機應用提供了基礎。
傳輸控制協議（Transmission Control Protocol TCP）是一種面向連接的、可靠的、基于字節流的運輸層通信協議，通常由IETF的RFC 793說明。在簡化的計算機網絡OSI模型中，它完成運輸層所指定的功能。在因特網協議族中，TCP層是位于IP層之上，應用層之下的中間層。不同主機的應用層之間經常需要可靠的、像管道一樣的連接，但是IP層不提供這樣的流機制，而是提供不可靠的包交換。
TCP原理的特點和功能如下：
（1）面向連接的服務。對保證數據流傳輸可靠性十分重要。
（2）高可靠性：方法：確認與超時重傳。
（3）全雙工通信
（4）支持流傳輸：流傳輸 無報文丟失、重復、亂序的正確數據報文序列；
（5）傳輸連接的可靠建立與釋放：3次握手
（6）提供流量控制與擁塞控制
TCP協議的功能
（1）保證傳輸的可靠性。TCP協議是面向連接的。所謂連接，是指在進行通信之前，通信雙方必須建立連接才能進行通信，而在通信結束后終止其連接。相對于面向無連接的IP協議而言，TCP協議具有高度的可靠性。當目的主機接收到由源主機發來的IP包后，目的主機將向源主機回送一個確認消息，這是依靠目的主機的TCP協議來完成的。
TCP協議中有一個重傳記時器（RTO），當源主機發送IP包即開始記時需要說明的是，TCP協議所建立的連接是端到端的連接，即源主機與目的主機間的連接。internet中每個轉接節點（路由器）對TCP協議段透明傳輸。
總之，IP協議不提供差錯報告和差錯糾正機制，而TCP協議向應用層提供了面向連接的服務，以確保網絡上所傳送的數據包被完整、正確、可靠地接收。一旦數據有損傷或丟失，則由TCP協議負責重傳，應用層不參與解決。
（2）提供部分應用層信息的功能。在TCP協議之上是應用層協議（如FTP、SMTP、TELNET等），最終需依靠它們實現主機間的通信。TCP協議攜帶了部分應用層信息，可用來區別同一報文數據流的一組IP包及其性質。
TCP協議對這些應用層協議規定了整數標志符，稱為端口序號。被規定的端口序號成為保留端口，其值在0～1 023范圍內（如端口序號23，用于遠程終端服務）。此外還有自由端口序號，供個人程序使用，或者用來區分兩臺主機間相同應用層協議的多個通信，即兩臺主機間復用多個用戶會話連接。
進行通信的每臺主機的每個用戶會話連接都有一個插口序號，它由主機的IP地址和端口序號組成。在internet中插口序號是惟一的，一對插口序號惟一地標識了一個端口的連接（發端插口序號=源主機IP地址+源端口序號，收端插口序號=目的主機IP地址+目的端口序號）。利用插口序號可在目的主機中區分不同源主機對同一個目的主機相同端口序號的多個用戶會話連接。
在TCP協議段的頭部各域中具有碼位項。其中，SYN碼位為應用數據流的開始位（當SYN置1，表示該IP數據包為某一應用報文的第一份數據包），FIN碼位為應用數據流的結束位（當FIN置1時，表示此時數據包為某應用報文的最后一份數據包）。因此可利用SYN/FIN兩個碼位來規定某一應用報文（或某一應用數據流）的開始與結束。
TCP協議就是利用端口序號和SYN/FIN碼位來區分應用數據流并判斷其性質的，從而使具有四層功能的高端路由器具有某些對應用數據流的控制功能。
TCP協議只定義了一種報文格式，建立、拆除連接、傳輸數據使用同樣的報文
1.傳輸連接的建立
TCP是面向連接的協議，運輸連接的建立和釋放是每一次面向連接的通信中必不可少的過程
運輸連接的管理就是使運輸連接的建立和釋放都能正常地進行。
在連接建立過程中要解決以下三個問題：（1）要使每一方能夠確知對方的存在；（2）要允許雙方協商一些參數（如，最大報文段長度，最大窗口大小，服務質量等）；（3）能夠對運輸實體資源（如緩沖區大小，連接表中的項目等）進行分配
2.TCP的傳輸連接管理――三次握手技術。（1）TCP連接的建立采用客戶/服務器方式。（2）為了確保連接的建立和釋放都是可靠的，TCP使用三次握手的方式，其中交換了三個報文。（3）已證明三次握手是在分組丟失、重復和延遲的情況下確保非模糊協定的充要條件。
3.為何使用三次握手
當客戶端發送一連接請求報文段，沒有收到服務器端的確認，認為丟失?？蛻舳嗽僦貍饕淮?，得到確認，傳輸數據，釋放連接。
然而，客戶端第一個請求報文段并沒有丟失，而是延時到這次連接、數據傳輸、釋放連接后才到達服務器端。服務器端認為又一次新的連接，向客戶端發一確認。客戶端由于并沒有發起新的連接，不會發送數據，服務器端會一直等待，造成資源浪費。
3. TCP的流量控制。
（1）TCP采用可變發送窗口的技術進行流量控制，窗口大小的單位是字節。
（2）在TCP報文段首部的窗口字段寫入的數值就是當前設定的接收窗口數值。
（3）發送窗口在連接建立時由雙方商定，在通信過程中，接收端可根據自己的資源情況，隨時動態地調整自己的接收窗口，并且告訴對方，使對方的發送窗口和自己的接收窗口一致。
說明：（1）發送端要發送的數據共9個報文段，每個報文符長100字節，共900個字節；（2）而接收端允許的發送窗口為500字節；（3）在當前情況下，發送方可連續發送5個報文段，而不必收到確認，（已發送了二個，還可發送三個報文符）；
4. TCP差錯控制
差錯控制包括檢測受到損傷的報文段、丟失的報文段、失序的報文段和重復的報文段，以及檢測出錯后糾正差錯的機制。差錯檢測三種工具：檢驗和、確認和超時。對各種出錯報文段的處理：傳輸出錯報文段（重傳計時器）；丟失報文段（重傳計時器）；重復報文段（報文序號）；亂序報文段（對亂序報文段不確認，直到收到所有它以前的報文段為止。）；確認丟失（累計確認）
本文主要是從計算機輔助教學入手，從TCP原理演示來具體生動地介紹CAI的特點.全文全面地介紹了TCP協議，又通過動畫具體演示了TCP的連接和釋放過程，能夠生動地幫助學生理解TCP協議。從而具體體現了計算機輔助教學的優點。
計算機輔助教學與傳統的教學方式相比較確實具有很多的優勢。傳統的教學以課堂集體教學為基礎，這種教學通常以教師為中心，學生往往處于被動地位，其學習積極性難以調動。教師參照全班學生的平均水平和教學計劃確定教學進度并向學生提供反饋信息，忽視、較少注意或難于注意學生的個別差異。對于家庭作業，盡管教師能逐個學生加以批閱，但反饋信息不夠及時，有時學生幾天后才能得到教師批改過的作業，而這時學生又去顧及新的知識。然而計算機輔助教學相對于教師的傳統教學也有其固有的不足之處，比如真實性問題，雖然呈現給學生的信息可以是豐富多采的，但這些都是間接經驗，是別人做好讓學生看和聽的，甚至有的信息的真實性會受到懷疑。還有其它的不足之處，這需要從事教育工作者的合理運用。
參考文獻：
[1]吳功宜，《計算機網絡》，清華大學出版社
[2]謝希仁，《計算機網絡》，電子工業出版社
[3]肖秀金、陳霄峰，《網頁設計培訓教程》，地質出版社
[4]BehrouzA.Forouzan，Sophia Chung Fegan ，《TCP/IP協議族》，清華大學出版社
tcp協議范文4
關鍵詞：嵌入式系統；以太網；TCP/IP協議；UDP；ARP
中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2007)04-10947-03
1 引言
目前，嵌入式系統與網絡的結合已經成為嵌入式系統發展過程中所必須要面對的問題之一。嵌入式系統的網絡接入一般可以通過RS-232或RS-485等間接接入，也可以通過網絡協議直接與網絡相互連，其中，直接接入方式正逐步成為嵌入式系統接入網絡的主要方式，但是需要精簡TCP/IP協議棧的支持。目前使用廣泛的通用TCP/IP協議棧所包含的協議內容比較全，但同時也比較復雜。由于硬件平臺的差別，這些協議站無法直接應用于嵌入式系統，主要表現在以下三個方面：
(1)嵌入式操作系統都面向特定的領域和需求，嵌入式應用對實時性要求比較高。
(2)多任務操作系統的內存分配是動態的，但是在嵌入式系統中片RAM是靜態分配的，用于存放收到的數據包的的空間很有限。
(3)嵌入式系統在程序的具體實現上與通用計算機系統有所不同，主要體現在指針、參數傳遞、變量和數據結構的定義等方面。
因此，需要通用TCP/IP協議棧的基礎上進行精簡和改寫，以設計出精簡、高效的TCP/IP協議子集，以供嵌入式系統接入網絡使用。
2 TCP協議分析與簡化
通用計算機系統有足夠的資源支持，但是嵌入式系統則不同，因為其CPU處理能力和系統存儲能力都受到成本限制，充分利用資源、提高系統性價比是開發嵌入式應用的根本特點。
2.1 嵌入式TCP/IP協議棧的特點
嵌入式系統一般都是為了滿足某一特定的需求，對網絡支持的要求相對比較低，需要什么協議就添加相應的模塊，不需使用完整的TCP/IP協議。嵌入式TCP/IP協議棧應具有以下的特點：
(1)代碼比較簡潔，占用的存儲空間盡可能小，盡可能為應用程序節省系統資源。
(2)需要傳輸的數據量一般比較少，協議的實現代碼要有較高的執行效率，具有較高的實時性。
(3)便于裁剪和擴展，對于面向不同應用的嵌入式系統應當根據特點對協議進行簡化或擴展，整個協議棧在滿足功能需求的前提下盡可能精簡。
TCP/IP協議棧具有層次特性，各個協議都有自己的數據格式，每次發送數據都要進行上下層協議的數據交換，進行打包和拆包的過程，在這個過程中如果采用數據拷貝的策略進行數據傳遞則會大大增加系統開銷。在嵌入式系統中，往往無法建立起數據傳遞的緩沖區，需要采用“零拷貝”技術用傳遞數據指針的方法來解決各層協議間的數據傳遞，以提高系統的實時性能。
2.2 TCP/IP協議的精簡
TCP/IP是幾百種網絡協議的集合。通用計算機系統有足夠的資源支持通信協議在內核實現，因此完整的TCP/IP協議棧（如圖1）能夠在數據傳輸的可靠性和數據流量的控制上做很多工作。
但是對于嵌入式系統來說，其硬件資源十分有限，同時對協議的要求也相對較低，必須對通用的TCP/IP協議進行精簡。進行精簡的途徑有兩種：
(1)將無關于系統功能的協議削減掉。即保留必需的協議，而對其它無關協議進行裁剪。
(2)對單獨的協議進行簡化。例如完整的ARP協議支持以太網、令牌環等網絡，但是嵌入式系統可能是面向于某一具體類型網絡的，對于其他的部分就可以簡化掉。
圖1
簡化后的協議仍然需要符合規定的標準：在網絡接口層，系統需實現ARP應答協議，該協議用于將IP地址映射成以太網MAC地址；在網際層，需要實現IP協議，主要負責IP報文報頭的正確性，并且對TCP和ICMP報文實行分流，此外，為了能夠測試系統與網絡的連接，在網際層還需要實現ICMP協議中的Ping應答協議，主要用于檢查網絡在傳輸層是否連通。作為運輸層的主要協議，TCP和UDP協議一般都不能缺少，對于具體的應用，一般都至少要實現其中之一。HTTP、FTP等應用層協議一般無需實現。這樣簡化后，就可以得到圖2所示的嵌入式TCP/IP協議棧的結構：
圖2 嵌入式TCP/IP協議棧結構
3 各協議的具體實現
本文實現的嵌入式TCP/IP協議運行于以89C51單片機和RTL8019AS網絡控制器為核心元件的硬件平臺上，協議代碼在Keil C51 V7.0環境下編寫。在程序的initial文件中提供了相關函數對89C51和RTL8019AS進行了初始參數設置，限于文章篇幅，與具體硬件相關的問題不再作詳細說明。
3.1 ARP協議的實現
ARP協議不攜帶用戶的有效數據，報頭長度為28字節。在ARP報頭中操作碼域表明了ARP包是ARP請求還是ARP回答，其值為1時為請求，為2時為應答。目標以太地址為目標節點IP對應的MAC地址，解析前是未知的。發送ARP請求應使用廣播方式，網段內的各個主機收到后檢查包內的IP地址，如果和本機的IP地址一樣則使用單播的方式返回ARP應答，在應答ARP包中源以太地址的域中填入自己的MAC地址。在具體設計時，要考慮到系統解析地址的實時性，如果每次互聯都要進行地址解析，則系統的實時性要下降，一般的做法是建立一個ARP地址映射表，存放常用IP地址與MAC地址的映射，這樣在解析地址時首先遍歷該表，如果目標地址已經被解析過則可以省去解析過程了。解析過程中還需要為ARP緩存中每個新生成條目賦予一個初始生存時間，使用定時器中斷，經過某一時間間隔對所有條目進行刷新檢測，若發現有條目發生超時，將其從ARP緩存中刪除。ARP緩存條目結構設計如下：
typedef struct
{unsigned long ip_addr; //IP地址
unsigned char macaddr[6]; //MAC地址
unsigned char timer; //定時器}
ARP_CACHE; //ARP緩存條目結構
3.2 IP協議及Ping 應答的實現
IP協議是TCP/IP協議族中最為核心的協議。所有的TCP、UDP、ICMP及IGMP包都以IP數據報格式傳輸。IP報頭的標準長度為20字節。在具體項目中由于數據量比較小，可以不考慮數據報分段的問題，即不允許數據報超出IP包的有效載荷。標準以太網幀數據域為1500字節，除去IP頭之外還有1480字節可以為上層協議提供有效的數據載荷，應該能夠滿足數據傳送的要求。這樣簡化可以省去軟件處理IP數據分段和重組的開銷，可以提高系統數據傳輸的實時性。IP協議對上一層傳下來的報文加上IP首部和IP校驗和并發往下一層，同時還要對下一層傳上來的報文進行校驗和檢查，將校驗正確的去掉IP首部，送往上一層。
為了便于測試，需要實現PING程序，在收到ICMP的回顯請求包后按照格式組裝一個ICMP的回顯應答包并發送。相關的主要函數有：
void ping_request() //PING請求
void ping_answer() //PING應答
void ping_echo() //PING應答收到后回顯
3.3 UDP協議的實現
UDP際上是直接利用IP協議進行數據報的傳輸，也就是將報文包含在IP數據包中 。UDP的數據傳輸是無連接，不可靠的，因為它不像TCP那樣，為了達到目標，首先要在兩點之間建立一個可靠的連接，因此UDP協議無法保證數據可靠性。但UDP協議具有對網絡資源開銷較小，數據處理速度快的優點，UDP協議屬于簡單的端到端的數據傳輸協議，其報頭只有8字節，其中源端口表示UDP應用進程的端口號，除了0～1023預定的端口外，其余的都可以使用。具體實現時要完成對應用層傳下來的數據包，加上UDP首部和UDP校驗和，發往下一層。以及對下一層傳上來的數據包，進行校驗和檢查，若正確去掉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包發送處理
void udp_recieve(union netcard xdata *pRxdnet)UDP包接收處理
3.4 TCP協議的實現
TCP協議是面向連接的、端對端的可靠通信協議，可分以下幾個步驟實現：
(1)建立連接。這一過程就是我們常說的三次握手過程。
(2)驗證。采取相應的措施消除傳輸中的錯誤，保障傳輸的可靠性，利用序列號解決通信時重復和失序的問題。
(3)流量控制。設置發送和接收窗口。
TCP協議的功能是為應用層協議提供可靠的面向連接的數據傳輸服務，是嵌入式應用系統協議棧中最為復雜的協議。在TCP協議實現中，由于請求發起端(客戶端)與請求相應端(服務器端)在通信中所處地位不同，相應地兩者的中間演變狀態也不完全相同?？蛻舳伺c服務器端在一個TCP連接從正常建立到正常中止分別經歷5個和6個狀態，相應控制信息均在TCP頭部信息的6位控制標記位中得以表示。對于嵌入式系統中TCP協議的實現，應從嵌入式應用的角度出發，盡可能減少冗余狀態。程序中需要構造一個TCP_STATUS結構來記錄每一個TCP連接的狀態信息，其結構如下：
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; //當前狀態
}TCP_STATUS; //連接狀態結構
4 結束語
嵌入式系統的應用非常廣泛，解決嵌入式系統的網絡接入問題具有十分重要的意義。本文實現的精簡TCP/IP協議棧在具體應用中有良好表現，可以滿足正常的數據傳輸。由于設計與實現的過程中將應用層協議全部精簡，協議在運行過程中的流量控制能力及協議自身的安全性都有所下降，在對安全性和穩定性要求較高的應用場合（如軍事、金融等領域），需要對協議的簡化有所斟酌。
參考文獻：
[1]羅蕾. 嵌入式實時操作系統及應用開發[M]. 北京:北京航空航天大學出版社. 2005.
[2]徐愛鈞，彭秀華. Keil Cx51 V7.0單片機高級語言編程與μVision2應用實踐[M]. 北京:電子工業出版社,2004.
[3]程耕國，高厚禮. 基于TCP/IP協議單片機上網的設計與實現[J]. 武漢科技大學學報(自然科學版)，2004,(2).
[4]田夏利，汪繼軍，薛勝軍. 嵌入式Internet中UDP協議的實現[J]. 計算機與數字工程，2006,(2).
tcp協議范文5
等特點，對常用 TCP/IPV6 協議棧進行了裁減和簡化，裁減掉一些不常用但不影響基本通信 功能的協議模塊，同時對要保留下來要實現的各個協議進行簡化，只實現其基本功能。設計完 成實現后的協議棧，具有代碼量少，運行效率高和良好的可移植性等特點，適合于各種嵌入 式設備，是一種解決嵌入式設備接入 IPV6 網絡的可行方案。
關鍵詞：IPV6；嵌入式操作系統；鄰居發現；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協議棧是一件非?，F實意義的挑 戰，也是本課題設計的目的所在。
2. IPV6 協議棧
IPV6協議棧是基于IPV6網絡層的協議， 和IPV4一樣，遵循現有互聯網四層網絡互聯 體系結構，如圖1所示。從圖中我們可以看到， 協議棧分為網絡接口層，互聯網
層，傳輸層，應用層四層。應用層直接面 向用戶，并提供訪問其它層服務的功能;傳 輸層用于提供源主機和目的主機上的對等 實體對話;網絡接口層屏蔽了具體的硬件實
現細節，負責底層數據的接收和發送；網絡
層是整個TCP/IP體系結構的關鍵部分，其主 要功能是在網絡上提供可靠的主機到主機 的數據傳送。IPv6協議正是位于該層，它包 含的主要協議模塊有IPV6，ICMPV6，鄰居發 現ND，IPsec等。
2.1 IPV6 協議
根據RFC2460對IPV6功能的描述，IPV6 主要負責把上層來的數據段添加IPV6報頭， 交由底層發送；把下層接收到的報文經過處 理和分析，交給TCP，UDP或ICMPV6處理。 和IPv4相比 IPv6的改變主要集中在以下幾 個方面:地址容量的擴展，報頭格式的簡化， 支持擴展和選項的改進，數據流標簽的能力，認證和保密的能力等[1]。
2.2 ICMPV6 協議
ICMPV6協議合并了IPv4中ICMP(控制 報文協議)，I- GMP(組成員協議)、ARP(地 址解析協議)等多個協議的功能，實現差錯 控制，地址解釋等功能，并支持Mobile IPv6。 ICMPV6報文封裝在IP報文中，是IP報文的 有效載荷數據，它通過它的各種錯誤報文和 信息報文的交換來實現差錯控制，地址解釋 和路由前綴信息獲取等功能。
2.3 鄰居發現(Neighbor discovery) 協議
鄰居發現協議ND是IPv6協議棧中的核 心協議，是IPV6解決鄰節點交互的一個重要 協議。它定義了下列問題的解決機制：路由 發現，前綴發現，參數發現，地址自動配置， 地址解釋，下一跳決定，鄰居不可達，重復 地址檢測，重定向。鄰居發現的這些功能是 通過5個ICMP報文（鄰居請求/鄰居通告報 文，路由器請求/路由器通告報文，重定向報 文）的交換來實現的。 3. IPV6 協議棧的精簡
協議棧精簡的核心是“微型化”，我們對 協議棧進行協議模塊裁減和單個協議簡化。
3.1 協議模塊裁減
協議模塊裁減是指在保障基本通信功 能的前提下盡可能去掉一些協議模塊，節省 系統資源。網絡接口層我們只考慮 802.3 以 太網協議（CSMA/CD，MAC，LLC），不考 慮面向 CAN，RS-232，RS-485，射頻，藍牙等 相關的支持模塊。接入方式上只考慮用路由 器接入方式，不考慮撥號連接方式，去掉和 撥號連接方式相關的面向點對點連接的 PPP 協議和 SLIP 協議，這兩個協議在網絡 接口層占用的代碼量比較多；IP 層只實現基 本的報頭，不實現擴展報頭，去掉基于認證 頭和封裝安全載荷頭選項的 IPsec 協議，安 全控制交給其他層。ICMPV6 和 ND 是核心
協議必須保留；傳輸層 TCP 和 UDP 可以全 部實現也可以只實現一種，考慮的適應性， 本設計中都給予實現。因此協議模塊裁減后 要實現的核 心協議族 為 802.3 ， IPV6 ，
ICMPV6，ND，TCP，UDP。
3.2 單個協議簡化
單個協議簡化是指以單個協議為目標， 進行功能和數據結構的簡化。對 IPV6 協議 來說，只接收，發送報文，不支持報文的分 片與重組，不支持擴展報頭選項，對可靠連 接傳輸來講，包過大得不到確認，會根據擁 塞控制機制和重傳機制，減少數據分組長 度，進行重新發送，對大多數應用來說這不 會產生其他嚴重問題。對 ICMPV6 來說，只 實現錯誤報文中的目的不可達報文，信息報 文中的應答回復報文，不實現超時報文，報 文過大報文和應答請求報文，一般包過大， 超時報文由路由器實現，應答請求報文用于 主動測試中發起測試的 PC 機一端。對鄰居 發現 ND 模塊來說，只實現鄰居請求和鄰居 應答報文，嵌入式設備剛接入網絡，它可以靜 態的等待網絡上路由器定時發送的路由公 告報文，而不是主動發送路由請求報文來獲 取，不需實現路由請求/路由應答報文。嵌 入式設備連接的鄰居接點，路由一般簡單， 傳輸量少，不需重定向報文來進行路由定 向。簡化的大塊在 TCP，TCP 是整個協議簇 中最復雜，代碼量最多的協議。它的功能模 塊有：滑動窗口，流量控制，擁塞控制，TCP 連接狀態機，往返時間估計，重傳協議。本 協議棧的目標是有操作系統支持的嵌入式 系統，速度和存儲量比 8 位和 16 位單片機 都有提高，不必采用分配固定緩沖區的形式 進行接收一幀處理一幀，可以考慮采用分配 一個較大的緩沖區實現滑動窗口機制，用來 提高傳輸效率，實驗證明，傳輸效率的提高 是明顯的，往返時間估計和重傳機制比較簡 單，代碼量不大，可以實現，TCP 狀態機表 示 TCP 進程通信的狀態遷移，是 TCP 的核
心必須實現，可以不實現流量控制機制，因
為流量不是很大。因此 TCP 模塊實現的功 能有：TCP 有限自動機，滑動窗口，往返時 間估計，重傳協議。忽略流量控制與擁塞控 制模塊，在可靠連接中，當因擁塞而發生數 據丟失的時候，發送方收不到確認就采用重 傳機制重發數據[2]。
4. 嵌入式精簡 IPV6 協議棧的設
計與實現
在設計協議棧過程中，我們在嵌入式操 作系統基礎上設計和實現一個操作系統模 擬層，實現基本的時鐘，消息管理和進程同 步等基本操作系統功能。協議進程方面，把 所有的協議棧封裝到單獨進程中，應用程序 可以駐留在其中或作為一個單獨的進程，這 樣既實現了與操作系統分離，又避免了層間 切換。對于內存管理采用類 BSD buf 結構， 把靜態緩沖區和動態緩沖區鏈接起來[3]。
4.1 IPV6
IPV6 模塊主要用于完成對接收到的 IPv6 數據報進行處理，對需要發送的 IPV6 數據包進行構造并遞交底層發送。當接收到 一個數據包時，網絡設備驅動調用 ip_input() 函數來對其 IP 報頭進行檢查，檢查其版本 號，報文長度，載荷長度，目的節點地址和 下一報頭，待檢查無誤后，根據下一包頭的 類型分別提交給不同的處理模塊。當要發送 數據時 ， 必須要知道發 送報文的下 一跳 IPV6 地址，以及該地址的相對應 MAC 地址， ip_route()函數就是為實現這樣的功能而設 計的，其獲取下一跳 IPV6 地址與其對應 MAC 地址的處理流程如圖 2 所示。 圖中，目的緩存用來存儲著一系列最近 的報文流量與對應的下一跳 IP 地址的關系，
前綴列表存儲著一系列子網前綴和其他地 址前綴及其對應的下一跳 IP 地址的關系， 如果兩者中都沒有找到匹配的記錄，則再從 前綴列表中選擇默認路由器作為傳輸的下 一跳 IPV6 地址。
在成功獲取了下一跳 IPV6 地址后，數
據就進入傳輸階段，傳輸階段由 ip_outputif() 函數控制，ip_output()函數填充好報頭，選擇 好發送網絡接口，然后激活發送網絡接口進 行數據發送[4]。
4.2 ICMPV6
ICMPV6 負責接收， 解釋和發 送 ICMPV6 報文。收到報文后，如果為鄰居信 息報文則轉交給鄰居發現模塊，如果為診斷 報文則交給 ICMPV6 診斷模塊。ICMPV6 模 塊只實現了應答回復報文，目的不可達報 文。當處理到達的 IP 報文時，如果下一報 頭既不是 TCP，UDP 也不是 ICMPV6，那么 表示在嵌入式設備端的協議棧的已經到達 IP 層，是端口不可達，發送目的不可達報文。 當收到 ICMPV6 的應答請求報文時，就發送 應答回復報文，其格式與請求報文相似，在收 到的請求報文的基礎上改變報文類型，重新 計算校驗和，
在 IP 報頭中將源，目的地址對調就可 以了。4.3 鄰居發現
鄰居發現是精簡 IPV6 協議簇最核心的 協議，它利用鄰居請求報文和鄰居公告報文 的交換，實現地址解釋，地址重復性檢測， 以及地址自動配置功能。不實現路由器請求
/路由器公告報文，和重定向報文。
鄰居請求報文
類型值為 135，報文 IP 頭的源地址域為 發送鄰居請求報文接口的地址或者未指定， 目的地址域為與被請求目標地址相關聯的 被請求節點組播地址，或者就是被請求目標 地址本身。ICMPV6 報頭域中的目標地址域 為被請求目標地址。選項域可以包含源鏈路 層地址選項，用來告訴對方發送請求節點的 MAC 地址，當源地址為指定
地址時必須包含該選項。
鄰居公告報文
類型值為 136，用來響應鄰居請求報文， 或者用來告知節點其鏈路層地址的改變，報 文 IP 頭的源地址為發送鄰居公告報文的接 口地址，目的地址為發送鄰居請求的單播地 址，或者是用來公告給所有鄰居節點其鏈路 層地址改變的全節點多播地址。目標地址就 是被解釋的 IPV6 地址，或者在地址唯一性
驗證中將要采用的 IPV6 地址。 地址解釋就是節點僅僅知道鄰居節點
IP 地址的情況下，通過發送鄰居請求報文和 接收鄰居公告報文，來得到對應節點鏈路層 地址的過程，是鄰居發現模塊中最重要的一 個功能模塊，其處理過程如圖 3 所示。
節點 A 知道節點 B 的鏈路 IPV6 地址
FEC0:0:0:1::B 但不知道節點 B 的鏈路層地 址 00-10-5C-F7-5C-96，沿箭頭方向，A 發送鄰 居請求報文，IP 域的目的地址是要求被解釋
的目標地址 FEC0：0：0：1：：B。節點 B
收到鄰居請求報文后，查看目標地址就是屬 于本機，是則發送一個單播的鄰居公告報文 給 A，在鄰居公告報文的目的鏈路層地址選 項 里 包含節 點 B 的鏈 路層 地址
00-10-5C-F7-5C-96。這樣
節點 A 知道了節點 B 的鏈路層地址， 地址解釋過程完成[5]。
5. 測試與驗證
5.1 在 Altera De2 上的實現與測試
課題的開發環境： Altera De2（硬件平 臺）， Quartus II 5.1 和 Nios II 5.1（軟件平 臺），整個開發過程以 LWIP1.1.0 為參考， 在理解了 LWIP 的結構后在結合開發環境改 寫。完成后對協議棧進行了測試和驗證，測 試主要集中在網絡層的 ND，IPV6，ICMPV6 模塊。由 于鄰居發 現模塊建 立在 IPV6，ICMPV6 基礎上的，對鄰居模塊的測試 相當于對 IPV6 和 ICMPV6 也進行了測試，
很具有代表性[6]。
受周圍網絡環境中無 IPV6 路由器所 限，測試在 IPV6 局域網上進行，Altera de2 通過以太網與 PC 機直接相連。測試對象電 路板 MAC 地址為 00-10-5C-F7-5F-
5D，其經過地址轉換算法得到的本地 IPV6 地址為：fe80:210:5cff:fef7:5f5d，當它 接入網絡時，為了對自己將要配置的地址進 行唯一性驗證，它要發送鄰居請求報文，通 過 PC 端網絡抓包工具 Sniffer，我們抓到了由 目標板發出的鄰居請求報文，如圖 4 所示：
圖 4 鄰居請求報文
從圖中看到其報文的類型值為 135。目
標地址為 fe80:210:5cff:fef7:5f5d。
測試協議棧在獲取鏈路地址后，我們在
PC 機端執行 ping6 fe80::210:5cff:fef7:5f5d。 這個過程中要知道目標板的鏈路層地址，于 是發起針對目標板 IPV6 地址的地址解釋。 在地址解釋過程中，我們抓到了目標協議棧 發送的，包含自己鏈路層地址的單播鄰居公 告報文，如圖 5 所示。
圖 5 鄰居公告報文
由圖可得知，報文類型值為 136，目標
地址為目
標板本地 IPV6 地址
fe80::210:5cff:fef7:5f5d。
5.2 在 s3c4410box 上的移植
移植目標平臺：基于 s3c4410box 處理器的 ARM7 開發板，按照通用的方法，先移植了 uc/os-ii 嵌入式操作系統，在移植好 的基礎上用操作系統函數編寫了操作系統 模擬層，把網絡接口層的函數指針指向電路 板提供的網卡驅動程序，在系統啟動初試化 函數中添加針對 IPV6 協議棧的啟動代碼。 完成這些后我們使用 altera de2 上一樣的測試方法進行測試，實驗結果證明協議棧滿足基本通信功能。證明協議?？梢栽谠撾娐钒?上進行移植[7]。6. 結束語
本文介紹了嵌入式精簡 TCP/IPV6 的設 計思想和實現方法，精簡性和可移植性是其 考慮的主要方面，該協議棧是一種解決了嵌 入設備和接入 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 嵌入式系統實驗教程. 深圳:北京航空航天出版社. 2006 :241-248
tcp協議范文6
關鍵詞：互聯網；嵌入式系統；協議棧；數據；報文；擁塞
中圖分類號：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 引言
計算機網絡的飛速發展，已經改變了人們的生產和生活方式。數字化信息家電的日益普及，使嵌入式系統連接到網絡成為了可能?；ヂ摼W采用的是無連接的端到端數據包交換，提供“盡力而為”服務模型的設計機制。這種機制的最大優勢是設計簡單，可擴展性強。然而隨著互聯網用戶數量的膨脹，網絡的擁塞問題也越來越嚴重。據統計，互聯網上95%的數據流和90%的報文數使用的是TCP/IP協議，因此，嵌入式TCP/IP協議棧的擁塞控制機制對控制網絡擁塞更具有特別重要的意義。
2 嵌入式TCP/IP協議棧概述
TCP/IP協議是由很多協議組成的協議族[1]。嵌入式系統引入互聯網支持所需的主要協議為ARP、RARP、IP、ICMP和TCP協議。ARP和RARP協議提供網絡地址的解析；ICMP協議提供網絡診斷功能；TCP和IP協議提供網絡傳輸和網絡互聯[1-2]。在網絡接口層,系統需實現ARP應答協議，該協議用于將IP地址映射成以太網MAC地址；在網際層，需要實現IP協議，主要負責IP報文報頭的正確性，并且對TCP和ICMP報文實行分流，此外，為了能夠測試系統與網絡的連接，在網際層還需要實現ICMP協議中的Ping應答協議，主要用于檢查網絡在傳輸層是否連通。
2.1 TCP/IP協議棧處理流程
TCP/IP協議棧接收數據包的過程就是解析數據包的過程。首先當一個數據幀到達時，網絡接口控制程序將其讀入緩沖區，檢查協議類型字段，如果值依次為0X0800，表示數據域內為IP包；如果值依次為0X0806，表示數據域內為ARP包[3]。由此以確定使用那種協議模塊來處理此分組。去掉以太網幀首部的數據包將被分配到IP緩存或者ARP緩存。接著，由IP協議處理模塊或ARP協議處理模塊繼續解析。在IP協議模塊處理數據包的過程，它要通過調用ARP協議獲得對方主機的物理地址。
2.2 嵌入式TCP/IP協議棧的特點
嵌入式系統一般都是為了滿足某一特定的需求，對網絡支持的要求相對比較低，不需使用完整的TCP/IP協議。嵌入式TCP/IP協議棧的特點如下：
1) 開放的協議標準，獨立于特定的計算機硬件、操作系統和網絡硬件，可以運行在局域網，廣域網和互聯網中。
2) 統一的網絡地址分配方案，使得整個TCP/IP設備在網中都具有唯一的地址；標準化的高層協議，可以提供多種可靠的用戶服務。
3) 代碼比較簡潔，占用的存儲空間盡可能小，盡可能為應用程序節省系統資源。
4) 便于裁剪和擴展，對于面向不同應用的嵌入式系統應當根據特點對協議進行簡化或擴展。
TCP/IP協議棧具有層次特性，各個協議都有自己的數據格式，每次發送數據都要進行上下層協議的數據交換，進行打包和拆包的過程。在嵌入式系統中，往往無法建立數據傳遞的緩沖區，需要采用“零拷貝”技術來解決各層協議間的數據傳遞，以提高系統的實時性能。網絡協議層次模型如圖1所示。
3 擁塞控制概述
描述擁塞現象有許多不同的度量，如傳輸延時、數據吞吐量、隊列長度和網絡效率等，但是沒有哪個度量能在局部和全局意義上完全滿足擁塞評判要求，因此人們對擁塞控制并無嚴格定義，甚至對擁塞的定義都無法完全統一。
3.1 基本概念
定義1：若因為網絡負載增加而導致用戶的滿意度降低，用戶則認為網絡發生擁塞。
形象地說，當網絡中存在過多的報文時，網絡的性能會下降，這種現象稱為擁塞[4,5]。擁塞導致的直接結果是分組丟失率提高，端到端時延加大，甚至整個系統發生崩潰。當發生擁塞崩潰時，微小的負載增量將使網絡的有效吞吐量急劇下降（如圖2所示）。
定義2：當負載達到網絡容量時，吞吐量開始緩慢增長，而響應時間急劇增加，這一點稱為膝點(Knee)。
定義3：如果負載繼續增加，路由器開始丟包，當負載超過一定量時，吞吐量開始急劇下降，這一點稱為崖點(Cliff)。
定義4：擁塞控制就是采用某種策略或機制，保持網絡工作在正常的狀態下，也就是使網絡經常工作在崖點左側的區域內。從而避免擁塞的發生或者對擁塞的發生做出反應。擁塞控制的目標就是使網絡在Knee附近工作。
3.2 產生擁塞的原因
網絡擁塞是“盡力而為”服務模型的一個固有屬性。用戶間無法相互協作共享資源，多個用戶對同一網絡資源提出請求時，就可能發生擁塞。網絡擁塞產生的原因有很多，直接原因主要有三個方面：1) 存儲空間不足；2) 帶寬容量不足；3) 處理器間處理能力和速度不一致。
3.3 擁塞控制算法的設計目標
由于擁塞控制算法性能的好壞會影響整個網絡系統，因此在設計和評價算法時，應該站在整個系統的角度來考查。對于任何一種擁塞避免或控制方案，人們希望它能同時滿足以下幾點要求：高效性、公平性(魯棒性)、穩定性、可擴展性。
4 TCP擁塞控制機制
TCP協議[6]是目前Internet上使用最廣泛的一種傳輸層協議。TCP的主要目的是為了解決Internet的穩定性、異質性(接受端緩沖區大小，網絡帶寬及延遲等)、各流之間享用帶寬的公平性，使用效率及擁塞控制等問題，從而為Internet提供可靠健壯的端到端通訊。TCP擁塞控制策略主要包括以下四個過程：
1) 慢啟動階段[7]：保證了連接建立初期進入網絡的突發數據的流量不會過大。
2) 擁塞避免階段：當數據發送速率超過一定閾值時，算法進入此階段，而后發送速率緩慢線性增長，避免了網絡擁塞的發生。
3) 快速重傳階段[9]：當網絡發生擁塞造成數據丟失或者重傳超時時，用該策略重傳丟失的分組。
4) 快速恢復階段：把網絡從擁塞狀態中恢復出來。
4.1 TCP擁塞控制的主要參數
1) 擁塞窗口(cwnd)：描述源端在擁塞控制情況下一次最多能發送的數據包數量。
2) 慢啟動閾值(ssthresh)：擁塞控制中慢啟動階段和擁塞避免階段的分界點。初始值設為65535bytes或awnd的大小。
3) 回路響應時間(RTT)：一個TCP數據包從源端發送到接收端、源端收到接受端確認的時間間隔。
4) 超時重傳計數器(RTO)：描述數據包從發送到失效的時間間隔，是判斷數據包丟失與否、網絡是否擁塞的重要參數。通常設為2RTT和5RTT。
4.2 TCP擁塞控制算法
4.2.1 Reno算法
1990年Jacobson在Tahoe的基礎上提出了Reno算法。Tahoe算法是最早被提出來的TCP源算法，但至今仍然被大多數TCP實現所采用。Reno算法對Tahoe的改進主要體現在兩個方面。第一，收到連續三個dupACK，算法不經過慢啟動，而直接進入擁塞避免階段。第二，增加了快速重傳/快速恢復(FR/FR)機制，具體過程為：
1) 收到三個dupACK進入FR/FR。ssthresh=max(cwnd/2,2)；
2) 重發去失的數據包；
3) 窗口膨脹。cwnd=ssthresh+ndupndup為收到的重復ACK數；
4) 當min(awnd，cwnd)足夠大時，發送新的數據包；
5) 當收到非重復的ACK時，cwnd=ssthresh；
6) 轉入擁塞避免階段?？梢?，Reno在收到三個dupACK后，就轉入FR/FR，而遇到超時，Reno和Tahoe一樣進入慢啟動階段?？蓮腞eno狀態轉換圖直觀地看到Reno的整個數據傳輸過程(如圖3所示)。
Reno目前被廣泛采用，以其算法的簡單、有效和魯棒性成為TCP源算法的主流。
4.2.2 NewReno算法
NewReno算法對Reno算法的改進是通過盡量避免Reno在快速恢復階段的許多重傳超時，利用一個ACK來確定部分發送窗口，立即重傳余下的數據包，從而提高網絡性能。目前，在因特網中使用最廣泛的是NewReno算法。然而NewReno算法也存在著不足，它在高速遠距離網絡中不能有效利用帶寬。
4.2.3 Sack算法
Sack算法也是對Reno算法的改進，當檢測到擁塞后，不用重傳數據包丟失到檢測到丟失時發送的全部數據包，而是對這些數據包進行有選擇的確認和重傳，從而避免不必要的重傳，減少時延，提高網絡吞吐量。由于使用選擇重傳，所以在一個窗口中數據包多包丟失的情況下，Sack算法優于NewReno算法。但是Sack算法的主要缺點是要修改接收端TCP。
5 IP擁塞控制機制
隨著Internet業務的迅猛發展，僅依靠單一的端到端的擁塞控制機制不可能有效地解決擁塞問題，另外期望所有用戶在Internet應用中都遵守這種端到端的擁塞控制也是不現實的，這要求網絡本身也必須參與對資源的管理與控制?；诖耍岢隽薎P擁塞控制機制。
5.1 IP擁塞控制算法
5.1.1 隨機及早檢測(RED)算法
RED(Random Early Detective)算法在路由器監控隊列長度，一旦發現擁塞迫近，就通知源端調整擁塞窗口。它也是通過丟包的方式使源端發現超時或重復應答，隱式通知源端擁塞情況。RED算法包含兩部分：如何監控隊列長度和何時丟棄數據包。首先，RED使用類似TCP計算超時時使用的權值Weight來計算平均排隊長度：Qe=(1-Weight)×Qe+Weight×SampleQe其中，0
5.1.2 顯示擁塞指示(ECN)算法
ECN(Explicit Congestion notification)算法在源端數據包中嵌入ECN，由路由器根據網絡情況設置CE(Congestion Experienced)比特位，源端從網絡中接收反饋回來的已被CE置位的數據包，再將隨后發出的數據包標記為“可丟棄”的數據包。改進算法NewECN可通過調整擁塞窗口cwnd大小，糾正了有長時間RTT的TCP連接的偏差，改進了共享瓶頸處帶寬的公平性。
5.1.3 加權公平排隊(WFQ)算法
WFQ(Weight Fair Queue)是公平排隊(FQ)算法的改進算法。WFQ算法對每個流即每個排隊分配一個權值。這個權值決定了路由器每次轉發該隊列的比特數量，從而控制數據流得到的帶寬。將所有權值看成1，那么FQ也是一種特殊的WFQ。權值的分配往往對應不同優先級的數據流，例如用IP包頭中TOS域指定流的優先級，排隊時再按優先級分配權值?？傊?，WFQ根據不同數據流應用的不同帶寬要求，對每個排隊隊列采用加權方法分配緩存資源，從而增加了FQ對不同應用的適應性。
6 結論
討論了嵌入式TCP/IP擁塞控制領域的研究熱點。近年來,非線性規劃和系統控制理論被引入擁塞控制研究中來,一些研究者使用數學模型來描述端系統和網關組成的系統，這對擁塞控制研究有很大的推動作用。然而，對于Internet這樣一個復雜系統的分析與控制，只有通過通信、控制和數學等多學科的共同努力，才有望獲得突破性成果。
參考文獻：
[1] W.Richard STEVEN. TCP/IP詳解 卷1：協議[M].范建華,胥光輝，張輝，等譯.北京：機械工業出版社,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的移動互聯網絡研究與實現[J].微電子學與計算機,2006,23(2):40-42
