時間：2022-06-13 09:45:57
開篇：寫作不僅是一種記錄，更是一種創造，它讓我們能夠捕捉那些稍縱即逝的靈感，將它們永久地定格在紙上。下面是小編精心整理的12篇tcp協議，希望這些內容能成為您創作過程中的良師益友，陪伴您不斷探索和進步。
1 概述
隨著信息科學技術和通信技術的不斷快速發展，基于互聯網的網絡通信應用在社會各個領域中的應用越來越廣泛，使得互聯網通信應用成為現代人日常生產生生活不可或缺的一部分，通過互聯網絡通信，網絡用戶之間可以實現數據傳輸、信息共享，從而極大地提高了人們的生活質量。然而，互聯網絡中的數據傳輸過程，并不是雜亂無章的隨機傳送，而是在計算機網絡通信協議的基礎上，雙方都按照協議的內容和機制，來發送數據信息和讀取分析數據信息，進而實現互聯網絡的數據傳輸和信息共享的功能，TCP/IP協議就是互聯網絡中重要的通信協議，它的存在奠定了整個互聯網絡通信的基礎，所以對于TCP/IP通信協議的學習對于理解互聯網通信機制來輔助互聯網學習和工作具有很大的幫助。
2 計算機網絡的TCP/IP通信協議
TCP/IP協議是“Transmission Control Protocol / Internet Protocol”的簡寫，是Internet網絡基本的協議，它為計算機通訊的數據打包傳輸以及網絡尋址提供了標準的方法。由于TCP/IP協議的優越性，使得越來越多的通信設備支持TCP/IP協議，使互聯網絡逐步走向規范化，最終TCP/IP協議成為了當前網絡通信協議標準中最基本的網絡通信協議、Internet國際互聯網絡的基礎。
2.1 計算機網絡TCP/IP協議
針對計算機互聯網絡的通信協議，國際標準組織ISO創立了七層OSI網絡模型，自上而下，分別為應用層、表示層、會話層、傳輸層、網絡層、數據鏈路層、物理層。而TCP/IP協議則是應用在傳輸層和網絡層的數據傳輸控制協議，來規定網絡設備接入互聯網絡以及設備間數據通信的標準。在通信設備經過互聯網絡進行數據傳輸時，通信設備數據發送端，發送TCP/IP通信報文，此時TCP/IP協議攜帶著通信設備發送端的傳輸數據內容以及目標通信設備的地址標示在互聯網絡中進行尋址，從而正確地傳送到目標通信設備。當目標通信設備接收到TCP/IP通信報文后，按照協議內容，去除通信標示，來獲取傳輸數據內容，并加以校驗，如果經校驗后發生差錯，目標通信設備會發出TCP/IP信息重發報文，讓發送通信設備再次將TCP/IP通信報文發展目標通信設備，去掉通信標示來獲取傳輸數據信息。
2.2 TCP/IP通信協議報文格式
在互聯網絡中，基于TCP/IP通信協議傳輸的數據內容都是以通信報文的形式在互聯網絡內部進行傳輸，通信報文實質上就是一串二進制字符串，而字符串內不同位置的二進制字符標示不同的含義。從TCP/IP通信協議的主要報文格式可以看出，IP協議是基于TCP協議至上的，TCP協議報文時作為IP通信報文的數據部分來進行傳輸的。實際上，互聯網內傳輸的通信字符串還有其他的通信協議，TCP/IP通信報文也是作為其外層協議的通信數據部分嵌入到通信報文中在互聯網內進行傳輸。
在IP協議首部，包含了一些關于IP協議的標示、通信地址等信息，主要包括數據字符串總長度的信息、通信標示號、源IP地址和目標IP地址等信息，當IP通信報文經過路由尋址時，會根據首部內記錄的目標IP地址來選擇傳輸方向，最終根據目標IP地址傳輸至目標通信設備。此外，IP通信報文首部還包含其他信息，比如IP協議版本號、首部長度、校驗信息、該IP通信報文生存時間（即該報文經過多少個路由后自動取消傳輸）等與IP通信報文相關的信息，以確保IP報文傳輸的正確性和安全性。TCP協議通信報文是作為IP通信報文數據內容存在的，TCP協議也分為TCP報文首部和TCP通信數據。TCP通信報文首部主要包括了源端口號和目標端口號等信息，當TCP/IP通信報文經過互聯網絡到達目標通過新設備后，通信設備會根據TCP報文首部的目的端口號選擇設備端口號來接受該數據信息，進而實現互聯網絡的數據傳輸。
2.3 TCP/IP協議通信過程
互聯網絡的通信設備基于TCP/IP協議建立通信過程，也是根據TCP/IP協議來實現的。當源通信設備想向目標設備發送數據時，首先會發送一個TCP/IP通信報文來確認連接，該通信報文在互聯網絡中經過尋找傳輸后找到目標設備，目標設備也會向源通信設備發送一個TCP/IP報文以確認建立通信連接，此時，源通信設備就會將通信數據以TCP/IP通信報文的形式進行數據打包，然后向目標數據進行傳輸，在收到數據后，目標設備同樣會發送TCP/IP報文以確認收到信息。當然，TCP/IP通信數據長度是一定的，當通信數據超過報文長度時，源通信設備會將其分段發送，而目標設備則會根據IP報文首部的標識號進行數據重組來重現傳輸數據信息，進而完成互聯網絡通信設備數據傳輸。
3 總結
TCP/IP網絡協議是當前互聯網絡最基本的通信協議。根據TCP/IP網絡協議，連接在互聯網內的通信設備可以根據TCP/IP通信報文格式的內容將傳輸數據打包在TCP/IP通信報文內，并以其規定的通信流程進行數據傳輸，從而實現互聯網絡內的數據高效安全的傳輸。
參考文獻：
[1]楊紹文.談計算機網絡的TCP/IP協議[J].科技信息.2011（02）
[2]查東輝.試論計算機網絡通信協議[J].電腦知識與技術.2013（14）
[3]楊嬌娟.淺談TCP/IP協議[J].數字技術與應用.2012（03）
引 言
超文本傳輸協議（HTTP）是目前通過Internet進行信息交換最主要的方式。HTTP協議是建立在請求/響應(request/response)模型上的。首先由客戶建立一條與服務器的TCP鏈接，并發送一個請求到服務器，請求中包含請求方法、URI、協議版本以及相關的MIME(Multipurpose Internet Mail Extensions)樣式的消息。服務器響應一個狀態行，包含消息的協議版本、一個成功和失敗碼以及相關的MIME式樣的消息(包含服務器的信息、資源實體的信息和可能的資源內容)。圖1給出了HTTP協議實現的一個簡單模型。HTTP/1.0[3]為每一次HTTP的請求/響應建立一條新的TCP鏈接，因此一個包含HTML內容和圖片的頁面將需要建立多次的短期的TCP鏈接。一次TCP鏈接的建立將需要3次握手。另外，為了獲得適當的傳輸速度，則需要TCP花費額外的回路鏈接時間（RTT）。每一次鏈接的建立需要這種經常性的開銷，而其并不帶有實際有用的數據，只是保證鏈接的可靠性，因此HTTP/1.1[4]提出了可持續鏈接的實現方法。HTTP/1.1將只建立一次TCP的鏈接而重復地使用它傳輸一系列的請求/響應消息，因此減少了鏈接建立的次數和經常性的鏈接開銷。
可持續鏈接減少了每次TCP鏈接建立的時間，但是一個空閑的TCP鏈接將需要一個Socket和相應的存儲緩沖區。一個Socket緩沖區的最小長度必須大于一個TCP包的最大長度，即64 KB，而且很多實現方法在鏈接建立時將預分配一些緩沖區。可用的Socket的數量是有限的，很多基于BSD的操作系統對于能夠同時打開的鏈接數都有一個缺省的最大值。
無線掌上設備PDA的應用（如瀏覽器）[5]特點表現在：① 因為頁面是針對掌上設備制作的，一般在1 K~2 K字節，比較小；② 目前無線通信網絡的帶寬很窄，GSM的數據信道帶寬只有9.6 K。當前Web頁面的訪問大多通過HTTP協議，并使用TCP作為下層的傳輸控制協議。但不幸的是，TCP并不適合短會話的應用情況，不同于現在采用的使用單一TCP傳輸協議進行數據傳輸的方式。本文提出了采用動態選擇傳輸層協議（TCP、UDP）的方法來改善取回頁面的延遲、網絡擁塞以及服務器的負荷。
這種混合TCP-UDP的方法結合兩個方面的優點：首先，對于需要比較少數據傳輸的情況，它將使用UDP作為傳輸層的協議，從而避免了TCP鏈接的多次握手開銷；另外，對于需要較多數據傳輸的情況，它將使用可靠的帶有重排序和擁塞控制的TCP協議作為傳輸層的協議。混合TCP-UDP的實現方法只需要對應用層的改動，而操作系統的核心代碼不用任何更改。僅采用UDP協議的缺點在于，需要在應用層建立一套類似于TCP復雜的控制協議，從而進行重排序和擁塞控制來保證傳輸的可靠性。
1 背 景
HTTP是一個請求/響應協議，客戶端的應用程序通過提供一個URL可以從服務器上得到所需的數據。HTTP可以用來訪問各種不同類型的資源，其中包括文本、圖形、影音、可執行文件、數據庫查詢結果等等。
圖2給出了在客戶端發起HTTP GET請求后，在客戶端和服務器之間進行數據包交換的示意。圖中只有兩個數據包是有用的（即攜帶了數據）：一個是HTTP GET請求，另一個是HTTP的響應。其它的都是TCP用來進行握手操作的數據包。為了減輕Web服務器的負荷，經常采用重定向機制。這樣從服務器發來的重定向響應報文是很短的數據包。使用TCP作為傳輸協議需要至少7個數據包，而使用UDP則只需要2個數據包就足夠了。
2 設 計
我們使用混合傳輸層[6]的方法即對于少量數據傳輸的鏈接采用UDP，而對于大量數據傳輸的鏈接采用TCP作為傳輸層協議。這樣對于短鏈接而言就避免了TCP經常性的握手開銷，而對于長鏈接則仍可獲得TCP的優點，如超時重傳、擁塞控制、錯誤恢復機制等。這種方法中，客戶端首先嘗試使用UDP作為傳輸層的協議，如果對于所請求的URL UDP并不適合，則再次使用TCP鏈接。這種方法提供了以下保證：
如果初始的UDP數據包丟失，將采用TCP重新鏈接而不會受到影響。
如果所鏈接的服務器沒有使用混合傳輸層的實現機制，客戶端將使用TCP重新進行鏈接。
圖3給出了混合TCP、UDP的實現算法。一個采用混合算法的HTTP客戶端首先使用UDP作為傳輸層的協議發出HTTP GET請求，同時啟動超時定時器。
當服務器處理客戶端發來的請求時，它可以從以下兩點做出選擇：
① 如果響應的數據足夠小（比如，可放到一個數據包中），服務器將使用UDP發回響應。像比較小的網頁或HTTP REDIRECT響應就屬于這一類。
② 如果響應的數據很大，無法放進一個UDP數據包中，服務器則要求客戶端使用TCP重試。這可以通過添加一個HTTP的頭部字段來解決如 TCPRETR。
在客戶端，將會出現以下三種情況：
客戶端從服務器接收到響應。如果響應中包含了所需的HTTP響應，客戶端將對數據進行處理。如果服務器要求客戶端重試，客戶端將使用TCP作為傳輸層重試。
如果服務器沒有處理通過UDP傳輸的HTTP包，客戶端就會收到ICMP錯誤消息（目的地址無法到達/協議無法到達）。此時客戶端將會使用TCP重試。
如果定時器超時，客戶端應使用TCP重試。
圖4給出了在定時器超時情況下，客戶端和服務器之間數據包的交換。這種超時機制提供了可靠性，以及與未使用混合TCP-UDP方法的服務器的兼容性。
圖5示意了服務器要求客戶端使用TCP重發請求時，客戶端和服務器之間的數據包交換。
3 結 語
混合TCP-UDP方法改善了參與HTTP傳輸的三個方面：客戶端、服務器和網絡。
對于客戶端而言，可以避免由于TCP而引入的三向握手的時間，從而減少了瀏覽的延遲時間。
TCP/IP協議是網絡中使用的基本通信協議。雖然從名字上看它包括兩個協議：TCP協議和IP協議，但確切的說，TCP/IP實際上是一組協議，除了最常用的TCP和IP協議外，還包含許多其它的工具性協議、管理協議及應用協議。TCP/IP協議共分為4層，即：應用層、傳輸層、互連網絡層、網絡接入層。其中，應用層向用戶提供訪問Internet的一些高層協議，使用最廣泛的有TELNET、FTP、SMTP、DNS等。傳輸層提供應用程序端到端的通信服務，該層有兩個協議：TCP和UDP。互連網絡層負責相鄰主機之間的通信，該層協議主要有IP和ICMP等。網絡接口層是TCP/IP協議軟件的最低一層，主要負責數據幀的發送和接收。
典型協議安全性分析與防范
TCP協議
協議工作過程
TCP是基于連接的。為了在主機A和B之間傳送TCP數據，必須先通過3次握手機制建立一條TCP連接。若A為連接方、B為響應方，則連接建立過程如下：首先，連接方A發送一個包含SYN標志的TCP報文(即同步報文)給B，SYN報文會指明連接方A使用的端口以及TCP連接的初始序號X； 隨后，響應方B在收到連接方A的SYN報文后， 返回一個SYN+ACK的報文(其中SYN是自己的初始序號Y，ACK為確認號X+1，表示客戶端的請求被接受，正在等待下一個報文)。最后，連接方A也返回一個確認報文ACK(序列號y+1)給響應方B。到此一個TCP連接完成。
TCP協議的安全問題
在連接過程中，可能受到的威脅如下：攻擊者監聽B方發出的SYN＋ACK報文，然后向B方發送RST包。接著發送SYN包，假冒A方發起新的連接。B方響應新連接，并發送連接響應報文SYN＋ACK。攻擊者再假冒A方對B方發送ACK包。這樣攻擊者便達到了破壞連接的作用。若攻擊者再趁機插入有害數據包，則后果更嚴重。
例如，在TCP的3次握手中，假設1個用戶向服務器發送了SYN報文后突然死機或掉線，那么服務器在發出SYN+ACK應答報文后是無法收到客戶端的ACK報文的(即第3次握手無法完成)，這種情況下服務器端一般會再次發送SYN+ACK給客戶端，并等待一段時間后丟棄這個未完成的連接，這段時間的長度我們稱為SYN Timeout，一般來說這個時間是分鐘的數量級(大約為30秒-2分鐘)；1個用戶出現異常導致服務器的一個線程等待1分鐘并不是什么大問題，但如果有一個惡意的攻擊者大量模擬這種情況，服務器端將為了維護一個非常大的半連接列表而消耗非常多的資源。服務器端將忙于處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求，此時從正常客戶的角度看來，服務器失去響應，這種情況我們稱作服務器端受到了SYN Flood攻擊。
防范方法
對于SYN Flood攻擊，目前還沒有完全有效的方法，但可以從以下幾個方面加以防范：
(1)對系統設定相應的內核參數，使得系統強制對超時的SYN請求連接數據包復位，同時通過縮短超時常數和加長等候隊列使得系統能迅速處理無效的SYN請求數據包；
(2)建議在該網段的路由器上做些配置的調整，這些調整包括限制SYN半開數據包的流量和個數；
(3)建議在路由器的前端做必要的TCP攔截，使得只有完成TCP三次握手過程的數據包才可進入該網段，這樣可以有效的保護本網段內的服務器不受此類攻擊。
IP協議
IP協議的安全問題
IP協議在互連網絡之間提供無連接的數據包傳輸。IP協議根據IP頭中的目的地址項來發送IP數據包。也就是說，IP路由IP包時，對IP頭中提供的源地址不作任何檢查，并且認為IP頭中的源地址即為發送該包的機器的IP地址。這樣，許多依靠IP源地址做確認的服務將產生問題并且會被非法入侵。其中最重要的就是利用IP欺騙引起的各種攻擊。
以防火墻為例，一些網絡的防火墻只允許網絡信任的IP數據包通過。但是由于IP地址不檢測IP數據包中的IP源地址是否為放送該包的源主機的真實地址，攻擊者可以采用IP源地址欺騙的方法來繞過這種防火墻。另外有一些以IP地址作為安全權限分配依據的網絡應用，攻擊者很容易使用IP源地址欺騙的方法獲得特權，從而給被攻擊者造成嚴重的損失。事實上，每一個攻擊者都可以利用IP不檢驗IP頭源地址的特點，自己填入偽造的IP地址來進行攻擊，使自己不被發現。
防范方法
基于IP欺騙的防范方法有：
(1)拋棄基于地址的信任策略。這是最簡單的方法。
(2)進行包過濾。如果網絡是通過路由器接入Internet的，那么可以利用路由器來進行包過濾。確認只有內部LAN可以使用信任關系，而內部LAN上的主機對于LAN以外的主機要慎重處理。路由器可以過濾掉所有來自于外部而希望與內部建立連接的請求。
(3)使用加密技術。阻止IP欺騙的一種簡單的方法是在通信時要求加密傳輸和驗證。當有多種手段并存時，加密方法可能最為適用。
ICMP協議
ICMP協議的安全問題
ICMP即Internet控制消息協議。用于在IP主機、路由器之間傳遞控制消息。控制消息是指網絡通不通、主機是否可達、路由是否可用等網絡本身的消息。Ping就是最常用的基于ICMP的服務。ICMP協議本身的特點決定了它非常容易被用于攻擊網絡上的路由器和主機。比如，可以利用操作系統規定的ICMP數據包最大尺寸不超過64KB這一規定，向主機發起“Ping of Death”(死亡之Ping)攻擊。“Ping of Death” 攻擊的原理是：如果ICMP數據包的尺寸超過64KB上限時，主機就會出現內存分配錯誤，導致TCP/IP堆棧崩潰，致使主機死機。此外，向目標主機長時間、連續、大量地發送ICMP數據包，使得目標主機耗費大量的CPU資源處理，也會最終使系統癱瘓。
防范方法
對于“Ping of Death”攻擊，可以采取兩種方法進行防范：
(1)路由器上對ICMP數據包進行帶寬限制，將ICMP占用的帶寬控制在一定的范圍內。這樣即使有ICMP攻擊，它所占用的帶寬也是非常有限的，對整個網絡的影響非常少；
關鍵詞:TCP;擁塞控制;亂序數據包;快速重傳
1 引言
作為互聯網上最為核心的通信協議之一,TCP協議最早于1974年由Vinton Cerf和Robert Kahn共同提出。最初,TCP協議設計的主要目的是如何在異構的主機之間可靠地傳輸數據,因此主要包括基于窗口的流量控制,丟包恢復等功能。上個世紀80年代,由于互聯網用戶和流量的激增,互聯網經歷了多次嚴重的擁塞崩潰事件。為了解決這一問題,上世紀80年代后期,Van Jacobson等人首次把擁塞控制應用到TCP協議當中,從而極大地改善了Internet上端到端連接的性能和穩定性,保證了整個互聯網的穩定運行[1]。TCP是目前互聯網中使用最廣泛的傳輸協議。非常多的應用,如FTP,Web,Email等,都采用了TCP協議。根據2009年11月份的最新統計,互聯網總字節數的90%和總報文數的87%均使用TCP協議進行傳輸[2]。
隨著互聯網的飛速發展,各種新技術被應用到互聯網中,如多路由技術,并行處理技術,鏈路層重傳技術等。這些技術在提升互聯網性能的同時,也導致了傳輸層亂序數據包的出現。大量的研究表明,亂序數據包會使位于傳輸層的TCP協議性能大幅下降。國內外眾多學者已經提出了各種不同的方法來提高TCP協議在面臨亂序數據包時的性能。
本文首先分析了亂序數據包造成TCP性能下降的主要原因,然后討論了各國學者所提出的不同解決方案;在此基礎上給出了在面臨亂序數據包時,提高TCP協議性能的幾個研究方向。
2 亂序數據包對TCP協議的影響
TCP協議擁塞控制的基本原理是:當網絡發生擁塞時,發送端應減小發送速率。實際上,位于通信連接末端的TCP擁塞控制算法無法了解網絡中究竟是否真的發生了擁塞,只能根據接收端收到的信息推測網絡狀態。因此設定了一個假設前提,即分組丟失意味網絡擁塞。即使這樣,TCP協議還是無法確切了解是否真的發生了分組丟失事件,只能根據確認指示推測分組是否丟失。現行的TCP協議可以通過兩種方式來判定數據包的丟失[3]。
(1)重傳定時器超時。
(2)接收端收到一定數量的重復應答(通常為3個)。
TCP通過數據包的序列號來保證數據包的正確,按序交付。假設序列號為 的數據包丟失,接收端每收到一個序列號大于 的數據包都會認為這是一個亂序數據包,在數據包 被正確接收之前,每收到一個這樣的數據包,都將產生一個對于 的重復應答。如果發送端收到一定數量的重復應答,將認為該數據包丟失,并由此推測網絡發生了擁塞。此時,重傳丟失的數據包,并將擁塞窗口減半。
這種丟包判定方式有效的前提是:網絡結構穩定,同屬一個連接的所有數據包按照同一路徑到達接收端,并且中間路由采用先到先服務和FIFO的原則。在以上條件成立的情況下,數據包的到達遵循“先發先到”的原則。數據包如果沒有按序到達則意味著丟失。然而,這種丟包判定方式容易受到網絡中持續的亂序數據包的影響。
亂序數據包是一種數據包到達順序與發送順序不一致的網絡現象。許多針對網絡中數據包的亂序問題的觀察、測量和本質研究指出:數據包的亂序并不是網絡的病態行為,而是作為一種普遍現象伴隨著網絡一直存在。統計顯示約有0.1%-2%的數據包會經歷亂序事件[4]。
亂序數據包的出現會給TCP協議帶來很大影響:(1)不必要的傳輸層重傳,浪費帶寬;(2)擁塞窗口不必要的減小,降低網絡利用率。
3 現有的解決方案分析
針對亂序數據包對于傳輸層TCP協議的影響,眾多學者提出了不同的解決方案,主要包括以下三種。
3.1 增大觸發快速重傳的門限值
一些學者指出,將觸發快速重傳的門限值(dupthresh)固定為3,會使得TCP協議對于亂序數據包的容忍程度太低,容易誘發不必要的重傳。因此提出改變dupthresh的取值[5]。目前主要有三種dupthresh設定算法:
(1)當亂序數據包出現時,通過固定參數K增大dupthresh的取值。
該算法的主要思路是:當亂序數據包出現時,將快速重傳門限值dupthresh增大為dupthresh+K。為此,需要在接收端檢測亂序數據包事件。檢測過程如下:如果數據包在dupthresh之后到達,即,已經被判定為丟失的數據包到達接收端,則認為這是一個亂序數據包事件。此時,將dupthresh增大為dupthresh+K。此后,將按照新的dupthresh進行丟包判斷。
這種方法的優點是實現簡單,缺點也很明顯,接收端可能需要多個周期,才能將dupthresh設定為合理值。這個收斂過程和整個算法的性能依賴于K的選擇。
(2)將dupthresh動態設定為當前值與亂序數據包長度和的一半。
該算法的主要思路是:當接收端檢測到數據包缺失時,開始記錄亂序到達的數據包數量,稱為亂序數據包長度,記為L,直到缺失的數據包到達。此時,將快速重傳的門限值dupthresh修改為(dupthresh+L)/2。
這種方法的優點是,它能夠較第一種算法更為迅速地使dupthresh根據網絡狀態收斂于理想值。缺點在于一個偶然的較大的亂序數據包長度可能造成dupthresh過大,影響TCP協議的性能。
(3)根據亂序數據包長度,利用指數加權移動平均算法設定dupthresh。
為了克服上述兩種算法的缺陷,Leung等人在文獻[6]中提出利用指數加權移動平均算法(EWMA:Exponentially Weighted Moving Average)動態設定dupthresh。同第二種設定算法一樣,當接收端檢測到數據包缺失時,開始記錄亂序數據包的長度L,直到缺失的數據包到達。此時,根據以下公式,計算平均亂序數據包長度:
if L > avg
avg = (1-α)*avg + α*L
else
avg = (1-α*x)*avg + (α*x)*L
其中,α為EWMA因子,通常取1/3,x為乘性因子,通常取4。
隨后,將dupthresh設定為平均亂序數據包長度avg。這種算法的優點在于dupthresh可以根據網絡狀態動態更新,并且,避免了第二種算法中單個過大的亂序數據包長度對dupthresh造成的過大影響。缺點在于接收端需要增加統計變量,并且隨時更新亂序數據包長度也會對接收端的性能造成一定影響。
3.2 Eifel算法
R. Ludwig和R. Katz提出使用Eifel算法來減少由亂序數據包引發的偽超時與偽重傳對TCP協議的影響[7]。Eifel的原理如圖1所示,發送端在T1時刻發送報文S時,將時間戳插入TCP頭部。在T2時刻,發送端檢測到S丟失,重傳S,并執行擁塞控制算法。重傳的S與原始發送的S相比,包含不同的時間戳T2。當接收端收到原始的S后,發送應答時,包含原始S的發送時間T1。當此應答到達發送端時,發送端發現此應答包含的時間信息T1小于存儲與Retransmit TS變量中的T2,由此判斷此重傳為假重傳。當檢測到假重傳時,發送端會將擁塞窗口和慢啟動門限值恢復到錯誤重傳前的值,然后如同沒有發生錯誤重傳一樣繼續發送數據分組。
Eiefl算法的優點在于能夠在很短的時間內檢測出假重傳,從而避免了后續不必要的重傳和擁塞回退機制。Eiefl算法還可以解決分組亂序、分組重復等問題。Eifel算法的缺陷在于,Eifel算法必須使用TCP協議的數據段參數來進行錯誤重傳判斷,并且Eifel算法僅僅是在檢測到偽重傳時避免了擁塞窗口的減小,并不能減少偽重傳的數據包數量,因此不能減少偽重傳對帶寬的消耗。
3.3 DSACK機制
重復選擇確認機制(DSACK)通過擴展TCP協議的SACK選項來克服亂序數據包的影響[8]。
DSACK算法的原理如圖2所示,發送端發送S1-S4數據包。由于網絡原因造成S1數據包亂序,它在S4數據包之后到達接收端。因此S2,S3,S4數據包均會產生對S1的重復應答。在收到這3個重復應答后,發送端將重傳S1。當重傳的S1到達接收端后,會產生一個對于S5的重復應答,同時SACK信息會指明此重復應答是由S1引起的。當此應答到達發送端后,發送端就可以判斷出剛才對于S1的重傳是假重傳。
DSACK算法要求發送端維護檢測到分組丟失時的擁塞窗口和慢啟動門限值等信息,發送端根據DSACK信息檢測到假重傳時,將擁塞窗口和慢啟動門限值恢復到錯誤重傳前的值。雖然沒有增加分組的開銷,但是它無法解決網絡中的分組重復和ACK丟失等問題。如果包含DSACK信息的應答丟失,則接收端無法進行恢復。并且,由于DSACK信息在丟失恢復結束后才到達發送端,因此發送端在丟失恢復階段無法檢測到假重傳。
4 結束語
本文總結了目前國內外學者提出的幾種典型的TCP協議亂序數據包處理算法,并對這些算法進行了詳細的分析和比較。綜上所述,該領域仍存在著一些亟待解決的問題,未來的研究可以考慮從以下方面展開:
(1)充分利用TCP數據包頭部的閑置字段,描述鏈接及網絡狀態,接收端可以利用這些狀態參數,判斷缺失的數據包是否是由于網絡擁塞導致。
(2)設計更加合理的快速重傳門限值設定算法,使其能夠以較快的速度收斂于真實網絡狀態,同時算法應盡量減輕接收端的計算量和存儲空間開銷。
(3)利用接收端已知參數,如往返時延,重傳超時時間等,在不增加接收端開銷的基礎上,判斷亂序數據包的出現。
參考文獻
[1] Nagle J. RFC896: Congestion control in IP/TCP Internet works. Internet Engineering Task Force, 1984.
[2] Internet2 NetFlow: Weekly reports. netflow.internet2.edu/weekly/. 2009, 11.
[3] Allman M, Paxson V, Stevens W. RFC 2581: TCP Congestion Control. Internet Engineering Task Force, 1999.
[4] Bennett J C R, Partridge C, Shectman N. Packet Reordering is Not Pathological Network Behavior [J]. IEEE/ACM Transactions on Networking, 1999, 7 (6): 789-798.
[5] Chaudhary R, Jacob L. Corruption and Reordering Robust TCP-Friendly Rate Contro l [J]. Computer Communications, 2005, 28: 97-107.
[6] Leung K C, Ma C. Enhancing TCP Performance to Persistent Packet Reordering [J]. Journal of Communication and Networks, 2005, 7(3):385-393.
等特點，對常用 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協議棧是一件非常現實意義的挑 戰，也是本課題設計的目的所在。
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協議
1 面向連接和無連接區別概述
網絡編程中最基本的概念就是面向連接（connection-oriented）和無連接（connectionless）協議。盡管本質上來說，兩者之間的區別并不難理解，但對那些剛剛開始進行網絡編程的人來說，卻是個很容易混淆的問題。面向連接和無連接協議可以，而且通常也確實會共享同一條物理介質。
無連接協議中的分組被稱為數據報（datagram），每個分組都是獨立尋址，并由應用程序發送的。從協議的角度來看，每個數據報都是一個獨立的實體，與在兩個相同的對等實體之間傳送的任何其他數據報都沒有關系。
通常這就意味著客戶端和服務器不會進行長期的對話--客戶端發起一條請求，服務器回送一個應答。這還意味著協議很可能是不可靠的。也就是說，網絡會盡最大努力傳送每一個數據報，但并不保證數據報不丟失、不延遲或者不錯序傳輸。
另一方面，面向連接的協議則維護了分組之間的狀態，使用這種協議的應用程序通常都會進行長期的對話。記住這些狀態，協議就可以提供可靠的傳輸。典型的面向連接協議有三個階段。第一階段，在對等實體間建立連接。接下來是數據傳輸階段，在這個階段中，數據在對等實體間傳輸。最后，當對等實體完成數據傳輸時，連接被拆除。
一種標準的類比是：使用面向連接的協議就像打電話，而使用無連接協議就像寄信。給朋友寄信時，每封信都是一個獨立尋址且自包含的實體。郵局不會維護以往通信者的歷史記錄--也就是說，它不會維護信件之間的狀態。郵局也不保證信件不丟失、不延遲、不錯序。這種方式就對應于無連接協議發送數據報的方式。
這種類比雖然很形象，但并不是非常貼切的。電話系統有實際的物理連接。而我們的"連接"則完全是想象的--它只是由兩端記錄的狀態構成的。為了說明這一點，我們來看看當一個空閑連接一端的主機崩潰并重啟時會發生什么情況。
2 TCP＼IP協議應用
既然無連接協議有這么多的缺點，大家可能會奇怪，為什么還要使用這種協議呢？我們會看到，在很多情況下，使用無連接協議構建應用程序都是有意義的。但更重要的是，無連接協議是構建面向連接協議的基礎。為了更具體地說明這個問題，來看看TCP/IP協議族，TCP/IP基于一個4層的協議棧。
棧的底部是接口層，直接與硬件相連。棧的頂部是應用程序，比如Telnet、ftp和其他標準的以及用戶編寫的應用程序。因此，IP是構建整個TCP/IP協議族的基礎。但IP提供的是一種盡力而為的、不可靠的無連接服務。它接收來自其上層的分組，將它們封裝在一個IP分組中，根據路由為分組選擇正確的硬件接口，從這個接口將分組發送出去。一旦將分組發送出去了，IP就不再關心這個分組了。和所有無連接協議一樣，它將分組發送出去之后就不再記得這個分組了。
現在我們來看看TCP是怎樣利用這種簡單的無連接服務來提供可靠的面向連接服務的。TCP的分組被稱為段（segment），是放在IP數據報中發送的，因此，根本無法假定這些分組會抵達目的地，更不用說保證分組無損壞且以原來的順序到達了。
首先，它為TCP段中的數據提供了校驗和。這樣有助于確保抵達目的地的數據在傳輸過程中不會被網絡損壞。
第二，它為每字節分配了一個序列號，這樣，如果數據抵達目的地時真的錯序了，接收端也能夠按照恰當的順序將其重裝起來。
第三，TCP提供了一種確認-重傳機制，以確保最終每個段都會被傳送出去。
確認/重試機制是到目前為止我們討論的三種附加機制中最復雜的一種，我們來研究一下它是怎樣工作的。
TCP連接的每一端都維護了一個接收窗口（receive window），接收窗口就是可以從對等實體接收的數據序列號范圍。最小值表示窗口的左邊界，是所期望的下一字節的序列號。最大值表示窗口的右邊界，是TCP緩沖區空間所能容納字節的最大編號。使用接收窗口而不只是所期望的下一字節計數器，就可以通過流量控制來提高可靠性。流量控制機制可以防止TCP傳輸的數據使其對等實體的緩沖區空間溢出。
我們要注意這樣一個事實：RTO定時器超時并不意味著原來的數據沒有到達目的地。有可能是ACK丟失了，或者原來的段在網絡中延遲的時間太長，以至于在其ACK到達之前RTO定時器就超時了。但這并不會造成什么問題，因為如果原來的數據確實到達了，那么重傳的數據就會處于接收端TCP接收窗口范圍之外，會被丟棄。
IP地址（這些地址通常都是以因特網標準的點分十進制表示法給出的）用來將一個IP數據報傳送給一臺特定的主機。數據報到達目的主機時，還需要將其數據傳送給恰當的應用程序。例如，一個UDP分組的目標可能是回聲服務，而另一個的目標則可能是時間查詢服務。分組到達時，內核會搜索其套接字列表，查找一個與分組中的協議、地址和端口號相匹配的套接字。如果找到了匹配的套接字，就由指定的協議（在我們所討論的情形中，就是TCP或UDP）來處理數據，并將這些數據提供給所有打開了匹配套接字的應用程序。
3 小結
總之，在本文中，我們研究了無連接和面向連接協議的區別。可知道，不可靠的無連接數據報協議是構建可靠的面向連接協議的基礎，還簡單介紹了可靠的TCP協議是如何構建在不可靠的IP協議上的。對TCP來說，連接完全是想象的。它是由端點所記憶的狀態組成的，并不存在"物理"連接，而打電話的時候是有物理連接的。
參考文獻
[1]朱加強編著.計算機網絡技術[D].北大燕工教育研究院，2007（06）.
[2]魏大新，李育龍編著.Cisco網絡技術教程（第2版）[M].北京：電子工業出版社，2007（04）.
[3] 陳涓，趙振平譯.TCP/IP高效編程：改善網絡程序的44個技巧[M].北京：人民郵電出版社，2011（04）.
[4]王達編著.網絡工程師必讀―網絡工程基礎[M].北京：電子工業出版社，2006（07）.
[5]網管員世界雜志社編著.網管員世界2011超值精華本[M].北京：電子工業出版社，2011（06）.
作者單位
關鍵詞：以太網；數據包；TCP/IP；套接字
中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2011)29-7122-03
Investigation of Data Packet Interception System Based on TCP/IP Protocol
LI Na
(Department of Computer Science & Technology, Shaanxi University of Technology, Hanzhong 723001, China)
Abstract: This article discusses the TCP/IP protocol (which is the IP protocol version IPv4) packet capture and analysis technology. By using the technology that allows a host to receive all the data flowing through the host package. The system uses the Socket (Socket) on the card program to achieve the interception and analysis of the data packet. The technology in the field of network security and network management has a pivotal position.
Key words: ethernet; packet; TCP/IP; socket
網絡數據監聽是網絡入侵和網絡安全協議技術研究的核心技術。監聽技術主要是對網絡的狀態、信息流動和信息內容等進行監視，相應的工具被稱為網絡分析儀。在幾乎所有的IDS(入侵檢測系統)中，最基本的要求就是要能夠實現網絡監聽與過濾，所有的安全策略、防護、檢測、響應都建立在此基礎上，它是幫助網絡管理員查找和解決網絡故障，為防火墻和入侵檢測系統構建基礎。因此，局域網數據監聽系統的研究，對于更好的維護計算機網絡及解決網絡安全問題有著重要的意義。
1 數據包截獲及分析工具設計
1.1 設計目標
通過原始套接字（SOCK_RAW）和網卡的混雜工作模式截獲和掃描經過網絡通信端口的IP數據包，實現網絡流量統計、網絡協議分析等功能。
1.2 數據報截獲原理
信息在網絡中是以廣播形式發送的，以太網卡收到報文后，通過對目的地址進行檢查，來判斷是否是傳遞給自己的，如果是，則把報文傳遞給操作系統；否則，將報文丟棄，不進行處理。數據包捕獲程序工作在網絡底層，將網卡設置為混雜模式以后，從網絡底層捕獲到的數據包會直接上發給應用程序進行處理，而不象普通的數據包那樣經過操作系統的層層過濾。這樣一來，應用程序接收到的數據包是最原始的數據包，是經過封裝的。也就是說監聽主機接收到的數據包中，除了數據包本身的內容之外，還帶有從對方主機中的傳輸層、網絡層以及數據鏈路層等各層打上的數據包頭信息，所以要想獲得數據包里的應用數據，是需要我們自己來按照每一層的協議剝離數據包頭中的每一層首部內容的，這就是協議分析需要完成的工作。
1) 首先是需要去掉數據鏈層的包頭，此時可以獲得IP數據報，在這一層中可以對IP數據報做一定的統計和分析，如流量統計、網絡掃描等等；
2) 對于IP數據報去除網絡層的包頭以后，可以獲得傳輸層數據報，在該文的模型中就特指的TCP報文和UDP報文，對這一層數據報進行協議分析的主要工作就是根據TCP數據包和UDP數據包的包頭標志，將一個連接的所有IP數據報重整還原出一個完整的TCP流和UDP流，在這一層中還可以獲得數據報的端口號信息，根據端口號進一步判斷數據報屬于何種應用層協議。
1.3 總體設計
該軟件是運用Microsoft Visual C++開發的，該軟件主要由兩大主要部分（功能）構成：
1) 數據包截獲：用程序實現本地網卡狀態為“混雜”模式，當網卡處于這種“混雜”方式時，該網卡具備“廣播地址”，它對遇到的每一個幀都產生一個硬件中斷以便提醒操作系統處理流經該物理媒體上的每一個報文包。
2) 數據包分析：通過對數據包幀的格式的分析，判斷數據包所含協議的類型，源IP地址及目的IP地址，源端口和目的端口。這樣我們對數據包的安全性有所了解。
數據包捕獲模塊用于監視和驗證網絡流量情況，可以捕獲通過原始套接口(Socket)的原始數據包(Raw Packet)，當一個數據包到達網絡接口時數據包捕獲程序就直接從緩存區讀取捕獲的數據包，以供數據分析和處理時調用。數據包截獲模塊的結構如圖1所示。
在數據包捕獲程序中，通過設置網卡工作于混雜狀態，對網絡鏈路進行監聽并收集數據包，從而獲得數據包頭信息。其流程圖如圖2示。
可以看出，整個監聽檢測程序主要分為兩大部分：程序驅動程序部分和應用程序部分。驅動程序工作在核心態，負責網絡數據的接受和發送；應用程序工作在用戶態，除了與驅動程序進行正常的通信外，還需要將有關信息顯示出來，并提供過濾等操作。緩沖區由應用程序動態分配提供。
2 數據包截獲及分析工具代碼實現
1) 創建套接字
使用Socket()函數創建原始套接字Socketfd=Socket(AF INEF,SOCK RAW,0)。第一個參數是地址類型，設為AFINET~I是用于不同主機之間的通信；第二個參數即Socket的類型參數，這里使用SOCK RAW；第三個參數是協議參數，指定程序使用具體的協議。這里使用0，表示TCP/IP協議。
2) 將網卡設置為混雜模式
在程序中使用WSAIoct10函數是用來將網卡設置為混雜模式的。IntWSAloctl(SOCKETS, DWORDdwloC-ontrolCode, LPVOID IpvinBufer, DW ORDcbinBuffer, LPVOID lpvoutBufer, DWORD cbout-Bufer,LPDW ORD lpcbByteReturned, LPW SAOV?ELAPPED lpOverlapped, LPW SAOVERLAPPED-COM PLETION-ROUTINE IpcompIetionRoutine)。
3) 捕獲數據包
網絡接口設置為混雜模式以后，進人捕獲數據包的模塊。調用Recv(socket，bufer，sizeof(bufer)，0)函數。其中第一個參數是以連接套接字的描述符。第二個參數是接收數據的緩沖區地址。第三個參數是緩沖區大小。第四個參數是調用方式，O表示無特殊行為。
引言
S1C33209是EPSON公司推出的RISC結構的32位高性能CMOS微處理器，具有高速、低功耗、低電壓操作、精簡指令集等特點，提供乘與累加功能，既可用于辦公設備，也特別適用于需要高級數據處理的便攜設備，可以進行高速運算、靈活的I/O口控制和高效的數據操作。S1C33209具有8KB的內部RAM，其運算速率可達60MHz，加上優化的多數為單時鐘周期的指令集，使S1C33209吞吐量大為提高。S1C33209比常規MCU有更快的運算速度及可靠的性能、可重復編程的結構，使得精簡的TCP/IP能夠在其中可靠運行。
1 硬件平臺結構及設計
信息家電遠程訪問時，通信數據量不大，10M以太網的通信速率即可滿足要求；其次信息家電對實時性的要求不高，可定位在秒級。
在這種情況下，構造了家電網絡硬件平臺服務器S1C-WebServer，其結構如圖1所示。S1C33-WebServer主要由三部分組成，即S1C33209微處理器、RTL8019AS全雙工以太網控制器（RealTek公司出品，100腳的TQFP封裝，最大速率10Mbps，自帶16KB的SRAM，工作在Ethernet II和IEEE802.3、10Base5、10Base2、10BasetT下，全雙工，支持8位與16位數據總線，與NE2000兼容）、可擦寫Flash(采用Intel的E28F320，容量為4MB)。考慮到Flash的擦寫在程序調試中不太方便，所以為S1C33209外圍擴展512KB的SDRAM。在S1C33209中，運行用戶程序和S1C33-Stack。在Flash中，存放S1C-WebServer的各種Web資源信息，綜可處理Web頁面、圖像文件等，與PC機上WebServer中的硬盤可以存儲大量的不同頁面。Flash的容量決定了WebServer的資源文件的大小。RTL9019AS是Ethernet控制器，負責S1C33209與Ethernet的數據傳遞。在信息家電已具備RS232或相關標準接口的條件下，使用家庭自動化總線HAB（Home Automation Bus）作為S1C33-WebServer與家庭網絡協議SHNP（Simple Home Networks Protocol）。家電通過RS232接口與S1C33-WebServer連接，經由EEthernet接入Internet。
經過分析，S1C33209與RTL8019AS讀寫時序是兼容的，而且MCU的讀寫時延比RTL8019AS小得多。MCU與RTL8019AS的連接如圖2所示。RTL8019AS的工作電壓為5V，而S1C33209的工作電壓為3.3V，所以RTL8019AS的數據線輸出需要電平的轉換。選用2個8位（采用16位數據總線）的具有雙向數據傳輸功能的74HC245來完成，由于S1C33209的輸出電平符合RTL8019AS輸入電平的要求，所以地址線可以直接相連，而不需電平轉換，RTL8019AD中斷信號（INT0）為高電平有效，在S1C33209中選用端口中斷輸入的K60端口與之相連。由于S1C33209的中斷有效方式（高、低電平或脈沖）可以根據對寄存器的設置調節），所以不用對INT0作反向或電平轉換。
2 精簡TCP/IP協議棧的實現
構建的S1C33-Stack運行在以S1C33209嵌入式CPU為基礎的硬件平臺上，是一組可配置的多種Internet協議的組成。這些協議按照分層協議棧的方式組織，包括應用層的HTTP、DHCP、SMTP，傳輸層的TCP、UDP，網絡層的IP/ICMP、ARP，通過鏈路層和物理層（如Ethernet）進行數據的交互。S1C33-Stack的結構模型如圖3所示。S1C33-Stack利用S1C33的高速處理能力處理TCP/IP數據包，避免了在有限容量的RAM中緩存大量數據，使得控制器可以處理比內部RAM總線更多的數據包。利用嵌入的S1C33-Stack，Webserver能通過Hypertext Transfer Protocol(HTTP)與任何瀏覽器通信，能夠提供各種類型的資源，如HTML、圖片文件等。這些資源可以使用一種特殊的文件系統URI，被存放在容量為4MB的Flash中。這種文件系統可包含任意多的目錄，對URL的長度也沒有限制。
考慮到嵌入式系統的可用資源有限，在此采用經過裁減的TCP/IP協議棧—uIP。uIP協議主要包括TCP/IP協議組中的四個基本的協議：ARP、IP、ICMP、TCP。鏈路層協議，如PPP，則作為設備驅動在uIP底層實現。應用層協議，如HTTP、FTP、SMTP則作為應用程序在uIP上層實現。
（1）地址解析協議ARP
該協議將IP地址映射成以太網MAC地址。在uIP中，ARP的執行依靠維持一張表來完成IP地址和MAC的地址的映射。當有一個IP數據包要發送到以太網上時，從ARP表中查詢相應的MAC地址。如果在ARP表中找不到IP地址則送出相應的ARP請求。當目的主機收到ARP請求報文后，發送ARP REPLY報文將請求的MAC地址送出。當收到ARP REPLY后，ARP表被更新。每隔10s，ARP表就被新新一次，舊的ARP表項將被刪除。每個ARP表項的生存周期是20min。
（2）網間協議IP
在uIP中，IP層的代碼有兩個功能：驗證到來的IP報文報頭的正確性，并且對TCP和ICMP報文實行分流。因為不考慮IP的分片和重組，uIP中IP層的代碼非常的精簡。
（3）網間報文控制協議ICMP
在uIP中，僅有一種類型的ICMP信息被實現：ICMP ECHO主要用于應用程序ping，檢查網絡是否連通。在uIP中，ICMP ECHO通常以一種很簡單的方式進行處理；將ICMP類型由“ECHO”改為“REPLY”，同時調整ICMP校驗，交換發送方和接收方的IP地址。
（4）傳送控制協議TCP
為了減少對內存的使用，在uIP中，TCP并不使用滑動窗口來接收和發送數據，到達的TCP報文并不進行緩沖而是立刻交給應用程序處理。但是應用程序本身可以對要發送的程序本身可以對要發送的數據進行緩沖，因為每次連接中通常有若干的TCP報文要發送。uIP網絡通信模塊結構如圖4所示。
網絡通信需要要底層RTL8019AS驅動程序的支持，參考RTL8019AS與S1C33209的資料說明文檔，編寫出針對此系統的RTL8019AS驅動。
uIP并不緩存到達的數據包，當網絡上有數據包（在這里專指出太幀）到達網卡時，網卡驅動程序將暫存在網卡緩存中的數據包，一次一個的以DMA形式傳送到目標板上的RAM中。這時將會有一段代碼將到達目標板RAM中的數據包復制到全局數組uip_buf[]中，uIP協議棧程序隨后對uip_buf[]中的數據進行操作。
當上層應用程序或協議棧程序產生了向網絡上發送的數據包時，也將數據包放入uip_buf[]。然后調用網卡驅動程序，將uip_buf[]中的數據讀到網卡的緩存中，隨后發送到網絡中。
在此要說明一下協議棧與網卡驅動程序、應用程序之間的同步機制問題。在系統初始化的時候，通過操作系統提供的系統調用vcre_tsk()創建三個任務：任務一(task1)，uIP協議棧；任務二（task2），家電監控程序；任務三（idle_task），空閑任務。而網卡驅動程序則作為硬件中斷，由“檢測到網絡上傳過來數據包”事件激發。
整個協議棧程序流程圖如圖5所示。
任務一的優先級最高，任務二次之，任務三的優先級最低。當系統開始運行時，任務一首先進入RUN狀態，在任務一中加入系統調用wai_flg()，由于沒有網絡請求，任務一隨后進入WAIT狀態。此時任務二進入RUN狀態。當網絡上有數據包到達，網卡驅動程序作為硬件中斷開始執行。在退出中斷前，通過系統調用set_flg()，將任務一期望的標志位置位。當中斷返回后，由于任務一的等待條件已經滿足，任務一的優先級又高于任務二，因此任務一進入RUN狀態，即uIP協議開始處理數據。如果網絡上一直有數據包到達，則任務一和中斷程序不斷的切換。當網絡任務完成，返回到任務二的斷點處繼續向下執行。
由于uIP不緩存網絡數據，因此在任務一執行的過程中，即uip_buf[]正在作時，將關閉所有中斷。這樣可以避免數據包被破壞，缺點是實時性差了一些，但是滿足本系統要求。
3 操作系統
本系統使用的操作系統是由EPSON公司提供的ROS33V31。ROS33是為S1C33系列MCU提供的一種嵌入式實時操作系統，符合uITRON 3.0標準。使用ROS33可以迅速、有效地開發針對打印機、PDA以及各類控制設備的嵌入式應用程序。
ROS33具有以下特點：
*支持uITRON 3.0標準——符合該標準的S級*最大任務數為255，采用優先級調度機制，支持9種不同的優先級，提供信號燈、郵箱、消息緩沖等多種通信機制：
*內核優先并緊湊——最小可為1.7K；
*響應快——最快調度響應時間為7.8μS(CPU主頻為33MHz，下同)，最大中斷屏蔽時間為4.3μs ；
*高級語言支持——除匯編語言外，還支持基于ANSI標準的C語言編程。
注釋：μITRON將系統功能分成四級。R級（必要級）只提供包括實時、多任務OS所需的基本系統調用；S級（標準級）提供所有標準的系統調用；E級（擴展級）包括附加的和擴展的系統功能；C級（CPU依賴級）的系統功能依賴于具體的CPU和系統實現方式。
ROS33基本內核按功能劃分為6大部分：
*任務管理——負責系統中任務狀態的變遷；
*任務相關的同步管理——通過睡眠/喚醒、掛起/解掛等操作，處理相關任務及任務之間的同步關系；
*同步與通信——通過信號燈、事件、郵箱等通信機制，實現獨立任務之間的同步與通信；
*系統管理——對系統環境的管理；
*時鐘管理——日歷時鐘、定時器、定時任務等的管理；
*中斷管理——開/關中斷。
圖6給出了ROS33內核的概念模型。
4 Web服務器及上層應用程序框架
WEB服務器所采用的方式稱為uip_connect,比通常在設計中所使用的Socket套接字更適合于嵌入式系統下面即是WEB服務器的大體框架。
#include<uip.h>
void http_listen_init(void){
uip_listen(80);
} //http listen初始化
void listen_init(void){
http_listen_init();
}
void application(void){
if(uip_connected()) //如果當前的連接狀態為connected
switch (uip_conn->lport){
case htons(80):
httpd; //如果80 PORT有數據到達，則調用HTTP處理HTML文件的傳送
}
}
首先，服務器與客戶機建立連接，再通過偵聽端口80，判斷是否有客戶請求到達，若有則將調用應用程序httpd進行相應處理，否則，繼續偵聽。Httpd是用于處理HTTP請求的應用程序，具體設計在協議棧uIP中有描述。uip.h是協議uIP的一個頭文件。
在應用軟件上實現簡單WEB服務器功能，其主要由兩個模塊構成：一是用戶登陸模塊；二是家電監控模塊。用戶登陸模塊需要解決用戶的合法性檢查，即接收用戶輸入的用戶名和密碼，進行校驗，合法則進入家單監控頁面，非法則發出警告頁面。家電監控模塊針對各家電的硬件情況，收集信息家電的狀態碼，并通過網頁形式顯示。
在兩個模塊中，有一部分相似的處理，即對輸入的數據進行解析。現在定義數組htmlinputs來存放解析后的信息。對表單輸入的數據進行解析后，將其name值和value值分別存放在htmlinput_struct.name和htmlinput_struct.value里，便于以后的處理。變量htmlinputcount存放表單里輸入變量的個數。定義如下：
struct htmlinput_struct htmlinputs[100];
int htmlinputcount=0;
除此外，定義函數get_inputs()和translate()對輸入的數據進行處理。
Int get_inputs();//將從表單輸入的數據分別裝到對應的name/value數據隊中
Void translate(char*sourcestr);//解讀編碼URL字符
具體程序代碼在此就不再多述。
整個上層應用程序的流程圖如圖7所示。
關鍵詞：計算機 網絡通信協議
0 引言
本文就計算機網絡通信協議、選擇網絡通信協議的原則、TCP/IP通信協議的安裝、設置和測試等，作進一步的研究和探討。
1 網絡通信協議
目前，局域網中常用的通信協議主要有：NetBEUI協議、IPX/SPX兼容協議和TCP/IP協議。
1.1 NetBEUI協議 ①NetBEUI是一種體積小、效率高、速度快的通信協議。在微軟如今的主流產品，在Windows和Windows NT中，NetBEUI已成為其固有的缺省協議。NetBEUI是專門為幾臺到百余臺PC所組成的單網段部門級小型局域網而設計的。②NetBEUI中包含一個網絡接口標準NetBIOS。NetBIOS是IBM用于實現PC間相互通信的標準，是一種在小型局域網上使用的通信規范。該網絡由PC組成，最大用戶數不超過30個。
1.2 IPX/SPX及其兼容協議 ①IPX/SPX是Novell公司的通信協議集。與NetBEUI的明顯區別是，IPX/SPX顯得比較龐大，在復雜環境下具有很強的適應性。因為，IPX/SPX在設計一開始就考慮了多網段的問題，具有強大的路由功能，適合于大型網絡使用。②IPX/SPX及其兼容協議不需要任何配置，它可通過“網絡地址”來識別自己的身份。Novell網絡中的網絡地址由兩部分組成：標明物理網段的“網絡ID”和標明特殊設備的“節點ID”。其中網絡ID集中在NetWare服務器或路由器中，節點ID即為每個網卡的ID號。所有的網絡ID和節點ID都是一個獨一無二的“內部IPX地址”。正是由于網絡地址的唯一性，才使IPX/SPX具有較強的路由功能。在IPX/SPX協議中，IPX是NetWare最底層的協議，它只負責數據在網絡中的移動，并不保證數據是否傳輸成功，也不提供糾錯服務。IPX在負責數據傳送時，如果接收節點在同一網段內，就直接按該節點的ID將數據傳給它；如果接收節點是遠程的，數據將交給NetWare服務器或路由器中的網絡ID，繼續數據的下一步傳輸。SPX在整個協議中負責對所傳輸的數據進行無差錯處理，IPX/SPX也叫做“Novell的協議集”。③NWLink通信協議。Windows NT中提供了兩個IPX/SPX的兼容協議：“NWLink SPX/SPX兼容協議”和“NWLink NetBIOS”，兩者統稱為“NWLink通信協議”。NWLink協議是Novell公司IPX/SPX協議在微軟網絡中的實現，它在繼承IPX/SPX協議優點的同時，更適應了微軟的操作系統和網絡環境。Windows NT網絡和Windows的用戶，可以利用NWLink協議獲得NetWare服務器的服務。從Novell環境轉向微軟平臺，或兩種平臺共存時，NWLink通信協議是最好的選擇。
1.3 TCP/IP協議 TCP/IP是目前最常用到的一種通信協議，它是計算機世界里的一個通用協議。在局域網中，TCP/IP最早出現在Unix系統中，現在幾乎所有的廠商和操作系統都開始支持它。同時，TCP/IP也是Internet的基礎協議。①TCP/IP具有很高的靈活性，支持任意規模的網絡，幾乎可連接所有的服務器和工作站。但其靈活性也為它的使用帶來了許多不便，在使用NetBEUI和IPX/SPX及其兼容協議時都不需要進行配置，而TCP/IP協議在使用時首先要進行復雜的設置。每個節點至少需要一個“IP地址”、一個“子網掩碼”、一個“默認網關”和一個“主機名”。在Windows NT中提供了一個稱為動態主機配置協議（DHCP）的工具，它可自動為客戶機分配連入網絡時所需的信息，減輕了聯網工作上的負擔，并避免了出錯。同IPX/SPX及其兼容協議一樣，TCP/IP也是一種可路由的協議。TCP/IP的地址是分級的，這使得它很容易確定并找到網上的用戶，同時也提高了網絡帶寬的利用率。當需要時，運行TCP/IP協議的服務器（如Windows NT服務器）還可以被配置成TCP/IP路由器。與TCP/IP不同的是，IPX/SPX協議中的IPX使用的是一種廣播協議，它經常出現廣播包堵塞，所以無法獲得最佳的網絡帶寬。②Windows中的TCP/IP協議。Windows的用戶不但可以使用TCP/IP組建對等網，而且可以方便地接入其它的服務器。如果Windows工作站只安裝了TCP/IP協議，它是不能直接加入Windows NT域的。雖然該工作站可通過運行在Windows NT服務器上的服務器（如Proxy Server）來訪問Internet，但卻不能通過它登錄Windows NT服務器的域。要讓只安裝TCP/IP協議的Windows用戶加入到Windows NT域，還必須在Windows上安裝NetBEUI協議。 ③TCP/IP協議在局域網中的配置。只要掌握了一些有關TCP/IP方面的知識，使用起來也非常方便。④IP地址。TCP/IP協議也是靠自己的IP地址來識別在網上的位置和身份的，IP地址同樣由“網絡ID”和“節點ID”（或稱HOST ID，主機地址）兩部分組成。一個完整的IP地址用32位（bit）二進制數組成，每8位（1個字節）為一個段（Segment），共4段（Segment1～Segment4），段與段之間用“，”號隔開。為了便于應用，IP地址在實際使用時并不直接用二進制，而是用大家熟悉的十進制數表示，如192.168.0.1等。在選用IP地址時，總的原則是：網絡中每個設備的IP地址必須唯一，在不同的設備上不允許出現相同的IP地址。⑤子網掩碼。子網掩碼是用于對子網的管理，主要是在多網段環境中對IP地址中的“網絡ID”進行擴展。例如某個節點的IP地址為192.168.0.1，它是一個C類網。其中前面三段共24位用來表示“網絡ID”；而最后一段共8位可以作為“節點ID”自由分配。⑥網關。網關（Gateway）是用來連接異種網絡的設置。它充當了一個翻譯的身份，負責對不同的通信協議進行翻譯，使運行不同協議的兩種網絡之間可以實現相互通信。如運行TCP/IP協議的Windows NT用戶要訪問運行IPX/SPX協議的Novell網絡資源時，則必須由網關作為中介。如果兩個運行TCP/IP協議的網絡之間進行互聯，則可以使用Windows NT所提供的“默認網關”（Default Gateway）來完成。⑦主機名。網絡中唯一能夠代表用戶或設備身份的只有IP地址。但一般情況下，眾多的IP地址不容易記憶，操作起來也不方便。為了改善這種狀況，我們可給予每個用戶或設備一個有意義的名稱，如“HAOYUN”。
2 選擇網絡通信協議的原則
2.1 所選協議要與網絡結構和功能相一致。如你的網絡存在多個網段或要通過路由器相連時，就不能使用不具備路由和跨網段操作功能的NetBEUI協議，而必須選擇IPX/SPX或TCP/IP等協議。另外，如果你的網絡規模較小，同時只是為了簡單的文件和設備的共享，這時你最關心的就是網絡速度，所以在選擇協議時應選擇占用內存小和帶寬利用率高的協議，如NetBEUI。當你的網絡規模較大，且網絡結構復雜時，應選擇可管理性和可擴充性較好的協議，如TCP/IP。
2.2 除特殊情況外，一個網絡盡量只選擇一種通信協議。現實中許多人的做法是一次選擇多個協議，或選擇系統所提供的所有協議，其實這樣做是很不可取的。因為每個協議都要占用計算機的內存，選擇的協議越多，占用計算機的內存資源就越多。一方面影響了計算機的運行速度，另一方面不利于網絡的管理。事實上一個網絡中一般一種通信協議就可以滿足需要。
2.3 注意協議的版本。每個協議都有它的發展和完善過程，因而出現了不同的版本，每個版本的協議都有它最為合適的網絡環境。從整體來看，高版本協議的功能和性能要比低版本好。所以在選擇時，在滿足網絡功能要求的前提下，應盡量選擇高版本的通信協議。
2.4 協議的一致性。如果要讓兩臺實現互聯的計算機間進行對話，它們兩者使用的通信協議必須相同。否則中間還需要一個“翻譯”進行不同協議的轉換，這樣不僅影響通信速度，同時也不利于網絡的安全和穩定運行。
3 TCP/IP通信協議的安裝、設置和測試
局域網中的一些通信協議，在安裝操作系統時會自動安裝NetBEUI通信協議；在安裝NetWare時，系統會自動安裝IPX/SPX通信協議。在3種協議中，NetBEUI和IPX/SPX在安裝后不需要進行設置就可以直接使用，但TCP/IP要經過必要的設置。下面是Windows NT環境下的TCP/IP協議的安裝、設置和測試方法。①TCP/IP通信協議的安裝：在Windows NT中，如果未安裝有TCP/IP通信協議，可選擇“開始/設置/控制面板/網絡”，出現“網絡”對話框后，選擇對話框中的“協議/添加”命令，選取其中的TCP/IP協議，然后單擊“確定”按鈕。系統會詢問你是否要進行“DHCP服務器”的設置。如果你的IP地址是固定的，可選擇“否”。隨后，系統開始從安裝盤中復制所需的文件。②TCP/IP通信協議的設置：在“網絡”對話框中選擇已安裝的TCP/IP協議，打開其“屬性”，在指定的位置輸入已分配好的“IP地址”和“子網掩碼”。如果該用戶還要訪問其他Windows NT網絡的資源，還可以在“默認網關”處輸入網關的地址。③TCP/IP通信協議的測試：當TCP/IP協議安裝并設置結束后，為了保證其能夠正常工作，在使用前一定要進行測試。筆者建議大家使用系統自帶的工具程序PING.EXE，該工具可以檢查出任何一個用戶是否與同一網段的其他用戶連通，是否與其他網段的用戶正常連接，同時還能檢查出自己的IP地址是否與其他用戶的IP地址發生沖突。
互聯網是基于TCP/IP協議，TCP/IP是TransmissionControlProtocol/InternetProtocol的簡寫，而且TCP/IP協議由很多協議組成的。TCP/IP協議中有一個重要的概念就是分層，TCP負責發現傳輸的問題，保證數據的準確傳輸。而IP是給因特網的每一網設備規定一個地址，相當于一個精確地址，防止丟失。
網絡協議即網絡中（包括互聯網）傳遞、管理信息的一些規范。如同人與人之間相互交流是需要遵循一定的規矩一樣，計算機之間的相互通信需要共同遵守一定的規則，這些規則就稱為網絡協議。
一臺計算機只有在遵守網絡協議的前提下，才能在網絡上與其他計算機進行正常的通信。網絡協議通常被分為幾個層次，每層完成自己單獨的功能。通信雙方只有在共同的層次間才能相互聯系。常見的協議有：TCP/IP協議、IPX/SPX協議、NetBEUI協議等。在局域網中用得的比較多的是IPX/SPX.。用戶如果訪問Internet，則必須在網絡協議中添加TCP/IP協議。
（來源：文章屋網 ）
關鍵詞：無線TCP；無線局域網
中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2007)16-31019-01
TCP Wireless LAN Technology
DING Zhi-yun
(Yancheng Institute Technician,Yancheng 224002,China)
Abstract:Wireless communications and the Internet is the future with the development trend. Internet TCP protocol provides reliable end-to-end services, multimedia services can provide QoS guarantees transmission is widely used in support such as FTP, Telnet, HTTP and Internet business. TCP was originally aimed at the design of cable channel, cable channel transmission performance is relatively good, network congestion that can affect QoS is the only reason, therefore this is a TCP Congestion Control and Flow Control. The channel features such as multipath fading, interference, and makes limited spectrum when the traditional wired TCP performance when used in wireless serious decline.
Key words:Wireless TCP;Wireless LAN
1 引言
根據OIS參考模型來看，傳輸層協議應該使用獨立于下面各層的技術。例如，TCP不必關心IP是運行于有線網絡還是無線網絡，TCP也沒有必要關心數據在數據鏈路層的轉換和其他變換。在有線網絡中這些假設正確，而在無線網則不成立。在有線網絡中TCP負責傳輸層擁塞控制，而當今幾乎所有的程序實現都假設分組丟失是由擁塞而非信道（數據鏈路層）錯誤引起的，所以當定時器超時后會放慢數據發送速度。這種方法隱含的意思是減輕網絡的載荷以緩解擁塞，然而無線傳輸線路是很不可靠的，丟失分組是經常的事。解決分組丟失的最好方法是盡快地重發這些分組而不是放慢數據發送速度，如果這樣只會使情況更糟。由此可見，在無線網絡中對于分組丟失的錯誤解釋使得網絡的性能大大降低，有線網絡TCP/IP參考模型包括網絡接口層，網際層IP，運輸層，應用層，其中TCP傳輸控制協議工作在運輸層；無線網絡邏輯結構包括物理層，數據鏈路層，網絡層，高層協議，其中TCP工作在數據鏈路層。
2 影響TCP的無線環境因素
2.1無線鏈路數據包丟失原因
在傳統的TCP中，絕大多數數據段和確認的丟失是由于網絡擁塞引起的，而對于一般的無線鏈路，大多數丟失是由于以下原因引起的。
(1)數據包在高誤碼率的無線鏈路上傳輸發生的錯誤；
(2)連接的臨時斷開（由于信號衰落，用戶的移動引起的連接臨時斷開或者網絡斷開）
(3）數據包在最后一跳路由器發生擁塞問題。
2.2影響TCP的無線環境因素。
(1)帶寬有限
有線LAN的速率可達100Mb/s，而在IEEE802.2b中所規定的無線局域網的速率僅為11Mb/s。所以當無線主機和有線主機之間進行數據交換時會產生瓶頸。
(2)較長的鏈路往返時間RTT
一般來說無線媒介的等待時延比有線的要長。因為在無線網絡中數據要借助電磁波進行傳輸，其間可能遇到障礙物或者影響介質，如此一來平均往返時間就會增加。
(3)誤碼率較高
因為無線鏈路采用空氣中的電磁波做為介質，所以比起有線鏈路來更加容易丟失數據。
(4)用戶的移動
當用戶從一個蜂窩移動到另一個蜂窩時，期間會有一小段的斷開時間，TCP會誤將這一小段的時間使用擁塞控制/擁塞避免算法，引起網絡性能下降。
(5)短流量
短流量數據傳輸導致數據鏈路不能得到充分利用
(6)功率損耗
3 提高無線TCP 性能的方案
(1)端到端方案
對于這類協議，發送端可以知道下層的信道是有線還是無線，此方案直接修改通信兩端的TCP協議，修改后的協議可以改善無線TCP環境。如TCP-Reno，TCP-SACK等。TCP Reno 利用一定數目的累計ACK和超時計時器來判定分組是否丟失，但它只能判定一個發送窗口中的數據分組發生了丟失，而不能判定有幾個分組丟失。所以當一個發送窗口中有多個分組丟失時，TCP Reno 無法給發送端提供足夠的信息來進行快速恢復。為了解決這個問題，可使用增強型的TCP算法，如選擇證實(SACK)算法和SMART算法。SACK中每一個ACK都包含連續三個數據分組被接收端成功接收的信息,其中每一個數據分組用開始和結尾的字節序號來描述。當分組丟失發生時，仍然使用標準TCP的擁塞控制機制。SMART機制中，使用的ACK中包含累積ACK和已經成功接收的TCP分組的序號，當發現序號不連續時，立刻重發。
此方案的優點在于符合TCP語義，通信時兩端是一個完整的TCP連接，發送方收到的確認即意味著接收方收到了該數據。缺點在于需要修改雙方的TCP協議，工作麻煩，并且只能和具備這些協議的主機通信。
(2)TCP分段連接方案
TCP分段連接方案采用的是分裂連接協議，比如間接TCP（Indirect-TCP）。在無線鏈路上，重傳是差錯恢復的有效方法,但因為端到端重傳太慢，會引入長的時延,故可將TCP端到端連接分裂，將其為兩部分，從無線主機到基站為無線連接段，使用改進的TCP/RLP協議；從基站到有線主機為有線連接段，使用傳統的TCP/IP協議。無線鏈路上的數據丟失對發送端是屏蔽的。中間節點是基于數據的轉發。此方案的優點是兩個連接段均為同質的，對有線和無線部分上的超時可以分別采用不同的機制來處理，缺點是破壞了端到端的TCP連接語義，并且無線主機和中間節點需要修改TCP協議。因為現在每部分都是一個完整的TCP連接，中繼站可以按通常的方式對每個TCP數據段進行確認，但是發送方收到的確認并不意味著接收方收到了該數據，而只是說明了中繼站得到了該數據。
(3)TCP緩存方案
此方案最具代表性的是Snoop協議，Snoop協議在基站中引入一個“Snoop”的模塊，如圖5，該模塊監視通過雙向TCP連接的每一個分組。當固定主機向移動主機發送數據時，Snoop將已發送但還未得到接收端確認的TCP報文段保存在存儲區中。利用從移動主機接收的累積復制TCP ACK的數目或本地計時器超時來判斷分組是否在無線鏈路上丟失，并對丟失分組（仍然存在Snoop的存儲區中）進行本地重傳。同時，清除累計復制TCP ACK的計數，這樣TCP發送端就不知道在無線鏈路上發生的分組丟失，即對TCP隱藏了與網絡擁塞無關的分組丟失。
反之，當移動主機向固定主機發送數據時，Snoop 監視收到的分組的丟失情況，根據本地存儲區排隊長度等信息，區分該丟失的種類,是擁塞還是無線鏈路差錯造成的,并記錄下來。當收到固定主機發送的ACK 確認該分組丟失時, 在TCP ACK報文段的首部加上1bit 的ELN。ELN ( Explicit Loss Notification) 用于通知TCP 發送端分組丟失的種類。移動主機的TCP 根據收到的ELN 識別丟失與擁塞無關，因此，只重傳該分組，而不啟動任何擁塞控制算法。
此方案的優點是不破壞TCP語義，是通過對中繼站網絡層編碼進行一些細小的改動來實現的，增加一種探測來探測和緩存發往移動主機的TCP數據段，以及傳回的確認。缺點是Snoop協議并不能完全解決系統的分組丟失問題，比如在高擁塞丟失率的情況下性能較差。
4 結束語
本課題主要研究將基于有線的TCP技術應用于無線網絡所帶來的問題；提高無線TCP技術的性能方案；以及在實際環境中TCP所引起問題的解決。研究的目的在解決將基于有線的TCP技術應用于無線網絡所帶來的性能下降問題；掌握無線環境下TCP的差錯和流量控制，從而提高無線TCP 性能。以及在以后構建無線網絡環境時能更好地處理傳輸控制的性能，也有利于以后對無線局域網的差錯控制和傳輸控制。
參考文獻：
[1]劉乃安.無線局域網(WLAN)-原理,技術與應用.西安電子科技大學出版社,2004:322-336.
[2]謝希仁.計算機網絡.北京：電子工業出版社,1999:68-83.
[3]金慶江.無線網絡技術及應用.上海：上海交通大學出版社,2003:55-56.
關鍵詞： 網絡編程；TCP/IP；實時監測
0 引言
作為現代網絡的主導技術，TCP/IP編程看起來非常簡單，但在經歷了最初的高效率后，往往會在細節面前停滯不前，這常常是因為對TCP協議底層細節的缺乏了解所導致的。
TCP是面向連接協議，而UDP是無連接協議，許多初學者發現可以沒有任何數據流通過一個空閑的TCP連接，如果TCP連接的雙方都沒有向對方發送數據，則在兩個TCP模塊之間不交換任何信息。這意味著可以啟動一個客戶與服務器建立一個連接，然后離去數小時至數個星期連接依然保持。中間路由器可以崩潰和重啟，電話線可以被掛斷再連通，只要兩端的主機沒有被重啟，則連接依然保持建立。
因此，初次接觸TCP/IP協議組的程序員感到很迷惑：TCP中并沒有可以在其他網絡協議中發現的連接階段的輪詢，甚至發現TCP不給應用程序提供既時的網絡連接中斷的通知。一些程序員據此斷定TCP不適用于一般的應用程序到應用程序的通信。TCP為什么不提供通知呢？
1 原理分析
TCP通常被稱為可靠的協議，即“TCP保證發送數據的傳輸”，這通常會產生誤解：TCP不會出錯。事實是只要雙方保持連接，TCP就能保證數據的正確傳輸，但是當連接中斷時，就會產生問題，原因有3個：1）永久的或暫時的網絡紊亂；2）對等方應用程序崩潰；3）對等方主機崩潰，當出現以上問題時，會使雙方應用程序不能互相通信，而其中一個應用程序卻不能立刻意識到。發送數據給對等方的應用程序可能在知道TCP在放棄重發之前才會發現連接中斷，如果應用程序沒有發送數據，可能永遠不會發現網絡已經中斷。例如應用程序可能是一個正在等待對等方發出下一個請求的服務器，因為客戶端不能和服務器通信，下一個請求永遠不會到達，甚至客戶端的TCP放棄并撤銷連接，導致客戶端中斷，服務器也沒有意識到這一點。
其他的通信協議如SNA和X.25，當連接中斷時會給應用程序提供通知。比如簡單的直接點對點專有鏈接復雜的任何協議都必須使用一種輪詢協議來連續地測試對等方是否存在。輪詢-選擇協議可能會采用顯式地發送“你有要發送給我的任何數據嗎?”諸如此類的消息的形式，或者它們會采用后臺靜態幀的形式來檢測虛擬線路是否仍然存在。每一個輪詢消息都會消耗網絡資源，而這些資源本來可以用于“有效負載”數據的傳輸。
對可獲得的網絡帶寬的消耗是TCP不提供網絡中斷立即通知的一個原因。因為大多數的應用程序不需要即時的通知，所以沒有必要以降低帶寬的代價來提供這個功能。需要以一種及時的方式知道對等方不可到達的應用程序可以實現它們自己的機制來發現網絡中斷，如后面介紹的那樣。
TCP/IP設計中使用的一個基本原則是終端對終端參數[Saltzer el al.1984]，該參數應用到網絡上時可以表述為所有的智能應當盡可能地接近連接的終端點，而網絡本身應當相對沒有智能。這就是為什么TCP自己處理錯誤控制而不是依靠網絡來提供它的原因。當這個原則應用到監控對等應用程序之間的連接時，應用程序應當提供它自己需要的功能，而不是不管應用程序是否需要這個功能都由下層提供。
TCP不提供及時連接中斷通知的最重要的原因是：網絡突然中斷時仍可以維持通訊的能力。TCP最早是美國國防部發起的一項研究的成果，它要求提供一個遇到戰爭或自然災害引起的網絡中斷時仍然可以維持計算機之間可靠的通信的網絡協議。通常網絡紊亂是暫時的，路由器也可能找到連接的另一條路徑。通過允許連接的暫時中斷，甚至在終端應用程序意識到中斷之前TCP就已經處理好了紊亂。
2 解決方案
2.1 方案一：使用TCP Keep-alive機制
人們希望知道連接是否中斷了，因此許多TCP的具體實現提供了一個稱作Keep-alive的機制用于檢測死連接，但是它并不經常用于應用程序。如果應用程序啟用Keep-alive機制時，TCP就會在連接已經空閑了一段時間間隔后發送一個特殊的段給對等方。如果對等方主機可到達而且對等方應用程序仍然運行，對等方TCP就會響應一個ACK應答。在這種情況下，TCP發送Keep-alive重置空閑時間為零，并且應用程序不會收到消息交換的任何通知。
如果對等方主機可以到達但是對等方應用程序沒有運行，對等方TCP就響應RST消息，發送Keep-alive消息的TCP撤銷連接并返回ECONNRESET錯誤給應用程序。這通常是對等方主機崩潰后重起的結果，因為如果僅僅是對等方應用程序中斷或崩潰了，對等方TCP可能已經發送FIN消息了。
如果對等方主機沒有響應ACK或RST消息，發送Keep-alive消息的TCP繼續發送Keep-alive探詢消息，直到它認為對等方不可到達或已經崩潰了。這時它就撤銷連接并通知應用程序ETIMEDOUT錯誤，如果路由器已經返回主機或網絡不可到底的ICMP消息的話，就返回EHOSTUNREACH或ENERUNREACH錯誤。
通過Keep-alive機制，TCP提供了協議層面的網絡中斷通知功能，但這種機制有很多問題以至于很少用于應用程序。
