ip協(xié)議范文

導語：如何才能寫好一篇ip協(xié)議，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。

篇1

關鍵詞:路由技術 算法 Rip

1、IP路由算法

IP路由算法可分為以下幾種:靜態(tài)和動態(tài)、單路和多路、平等和分級、源路由和透明路由、域內(nèi)和域間、鏈路狀態(tài)和距離向量。

鏈路狀態(tài)算法發(fā)送路由信息到互聯(lián)網(wǎng)上所有的結點,然而對于每個路由器,僅發(fā)送它的路由表中描述了其自身鏈路狀態(tài)的那一部分。距離向量算法則要求每個路由器發(fā)送其路由表全部或部分信息,但僅發(fā)送到鄰近結點上。從本質(zhì)上來說,鏈路狀態(tài)算法將少量更新信息發(fā)送至網(wǎng)絡各處,而距離向量算法發(fā)送大量更新信息至鄰接路由器。

由于鏈路狀態(tài)算法收斂更快,因此它在一定程度上比距離向量算法更不易產(chǎn)生路由循環(huán)。但另一方面,鏈路狀態(tài)算法要求比距離向量算法有更強的CPU能力和更多的內(nèi)存空間,因此鏈路狀態(tài)算法將會在實現(xiàn)時顯得更昂貴一些。除了這些區(qū)別,兩種算法在大多數(shù)環(huán)境下都能很好地運行。路由算法使用了許多種不同的度量標準去決定最佳路徑。復雜的路由算法可能采用多種度量來選擇路由,通過一定的加權運算,將它們合并為單個的復合度量、再填入路由表中,作為尋徑的標準。

2、RIP路由協(xié)議的原理分析

RIP是基于距離矢量的路由協(xié)議。運行RIP的路由器維持一個到網(wǎng)絡中可能目的地的路由表,路由表包含目的地址和開銷等信息。具體的說,RIP協(xié)議主要包括以下幾個方面的內(nèi)容。

2.1計算距離矢量

距離矢量路由協(xié)議利用度量來跟蹤它和所有已知目的地間的距離。這種距離信息使路由器可以找出到位于非近鄰獨立系統(tǒng)中的目的地最有效的下一跳。在RFC-1058中,有一個唯一的距離矢量單位,即跳數(shù)。在RIP中默認的跳數(shù)度量被置為1,這些距離度量用來構造路由表。路由表識別出數(shù)據(jù)包,以最小開銷到達目的地所要采取的下一跳。

2.2更新路由表

RIP只記錄每個目的地址的一條路由,這一事實要求RIP經(jīng)常保持其路由表的完整性。它通過要求所有活躍的RIP路由器周期性的向相鄰RIP路由器廣播它們路由表的內(nèi)容。通常,RIP依賴3個計時器來維護路由表:即更新計時器、路由暫休計時器、路由清楚計時器。更新計時器用來激發(fā)節(jié)點路由表的更新。每個RIP節(jié)點只有一個更新計時器。然而,路由暫休和路由清除計時器則是每條路由都有一個。因此,每個路由表條目中都有一個不同的暫休和路由清除計時器。總之,這些計時器使RIP節(jié)點能維護它們路由的完善性,并根據(jù)所用的時間進行激活,從而恢復網(wǎng)絡故障。

2.3激活路由更新

大約每30s激活一次路由更新。更新路由器用來跟蹤這個時間量。當這個時間量結束時,RIP發(fā)送一系列幀來維護整個路由表。這些幀廣播到每個鄰節(jié)點。因此,每個RIP路由器大約每30s就要接收來自鄰RIP節(jié)點的更新。

2.4識別無效路由

路由變得無效的兩種情況:其一,路由到期;其二,路由器可能通知某個路由器某條路由是不可用的。在這兩種情況下,RIP路由器都需要改變它的路由表,來反映給定路由的不可用性。假如路由器在給定的時間內(nèi)沒有接收到更新某路由的信息,該路由可能到期。路由暫休定時器常設成180s,當路由激活或更新時,該定時器初始化。假如180s過去了,路由器還沒有接到更新那條路由的信息,RIP路由器就認為目的IP地址不再可達。因此路由器把表中那條路由項標成無效。收到路由新近無效通知的鄰節(jié)點利用該信息來更新它們的路由表。這是路由表中路由變得無效的第2種方法。無效路由表項不會自動的從路由表中清除;相反,那條無效項繼續(xù)在路由表中保留很短一段時間。

2.5清除無效路由

當路由器認識到某條路由無效時,就初始化一個秒計時器,負責路由清除倒計時,這一計時稱為路由清除計時器。當路由清除計時器結束時,路由仍未被收到,這一路由就從路由表中清除。這些計時器是RIP恢復網(wǎng)絡故障能力中絕對重要的。

2.6編址方案

IETF保證RIP能夠完全向后兼容所有已知的RIP和ROUTED異體。即使這些異體專用程度很高,開放標準RIP仍有必要支持多種地址類型。

2.7路由到網(wǎng)關

很多實際網(wǎng)絡中,并不要計算到每個單個主機的路由。特別是在大型網(wǎng)絡中,這會使路由表膨脹,從而使整個網(wǎng)絡的路由工作繁重。因此在實際網(wǎng)絡中,幾乎總是概括路由,而不是指出每個可能目的地。假如一個給定的網(wǎng)絡(或子網(wǎng))上,每個主機都能通過網(wǎng)關到達的話,這時路由表只需定義那個網(wǎng)關為下一條IP地址就可以了。所有發(fā)往那個網(wǎng)絡或子網(wǎng)上的數(shù)據(jù)包將發(fā)送給那個網(wǎng)關,這時網(wǎng)關就承擔了把它發(fā)送到最終目的地的任務。

3、RIP協(xié)議處理過程

RIP協(xié)議的運行過程就是路由器軟件對消息輸入和輸出處理過程,其輸入和輸出處理大致如下所描述。

輸入處理:主要是指路由器協(xié)議軟件對在520號UDP端口收到的數(shù)據(jù)報進行的處理。對于輸入處理,首先必須先作一定格式檢查,檢查通過后,再分別對幾種輸入消息做相應的處理。

請求報文:路由器在開始運行時,為了從鄰機處獲取路由表的初始值,通常會發(fā)一個請求。報文的Command字段為。對所有或部分路由表的請求,一般以廣播形式從520號UDP端口發(fā)送。實際中,這種請求有兩種格式:請求獲取路由表的全部和請求獲取路由表的某些特定路由項。路由軟件先逐個路由項地處理請求,如果沒有任何路由項,也就沒有響應;如果請求中恰好只有一個路由項,并且addressfamilyidentifier為0,metric為16,則表示需要接收方發(fā)送所有路由表的請求;除此之外,則是要求部分路由,處理很簡單,沿著請求路由項表一個一個看,對于每個路由項,在主機路由數(shù)據(jù)庫中查找,如果找到,則將該路由的metric值填入數(shù)據(jù)報的metric字段,如果沒有,則向其中填16。一旦所有路由項均已處理,將command字段設為響應,并將該數(shù)據(jù)報發(fā)回其來自的端口。根據(jù)請求是否關于指定的一批目的地,還是關于整個路由表,處理有所不同。如果關于整個路由表,輸出作普通的處理即可,包括水平分割和子網(wǎng)隱藏,因此來自路由表的某些路由項將被隱藏;如果是指定路由項,則將查找結果返回,不作水平分割,如果需要還要返回子網(wǎng)信息。

響應報文:因為指定查詢、路由修改等原因而收到響應。不論收到什么樣的響應,RIP處理程序就開始更新它的路由表。

輸出處理:用于產(chǎn)生包含全部或部分路由表的響應信息的處理,可能由于輸入進程發(fā)現(xiàn)請求或路由修改而觸發(fā)。響應請求產(chǎn)生的輸出可以直接按需工作,而觸發(fā)的修改因為兩個方面需要處理。

首先,觸發(fā)的修改在容量有限或有許多路由器的網(wǎng)絡上可能導致格外大的負載,因此協(xié)議要求實現(xiàn)方在限制觸發(fā)式修改出現(xiàn)的頻率上采取一定的措施,觸發(fā)式修改發(fā)送后,需要隨機地將一個定時器設置成1到5秒,如果在定時器超時前發(fā)生其它修改,需要到定時器超時才觸發(fā)其中之一,然后定時器再隨機地設置成1到5秒,觸發(fā)式修改可能被一般修改所禁止;另外,觸發(fā)式修改可能不必包括整個路由表,原則上說,只有改變過的路由才需要包括,作為觸發(fā)式修改一部分的信息至少包括設置了路由修改標志的路由,也可以包括附加路由和全部路由。如果完整的修改需要多個數(shù)據(jù)報,則發(fā)送全部路由極有可能被打斷;而觸發(fā)式修改處理時,需要產(chǎn)生每個直連網(wǎng)絡的信息。產(chǎn)生觸發(fā)式修改或一般修改時,都需要進行水平分割操作。

參考文獻

篇2

【關鍵詞】 IP協(xié)議； IPv6； IPv4

物聯(lián)網(wǎng)的本質(zhì)是網(wǎng)絡間交互作用，但是，互聯(lián)互通是物聯(lián)網(wǎng)交互作用的前提條件。由于物理世界中物件數(shù)量難以計數(shù)，物的形態(tài)與性質(zhì)又是千變?nèi)f化、千差萬別，如何通過網(wǎng)絡把這些千奇百怪的物件不但能夠聯(lián)系起來，保持各自的性質(zhì)與狀態(tài)，而且將來能夠在網(wǎng)絡智能控制下交互作用，這就是物聯(lián)網(wǎng)建設中必須考慮與建設的標準問題。但是，隨著近30年互聯(lián)網(wǎng)的蓬勃發(fā)展，特別是物聯(lián)網(wǎng)的發(fā)展開始受到網(wǎng)絡IP地址的限制。有資料顯示全球IPv4地址可能在很短時間內(nèi)即將消耗殆盡，地址空間的不足必將影響互聯(lián)網(wǎng)的進一步發(fā)展。網(wǎng)絡IP地址不足，嚴重地制約了我國及其他國家互聯(lián)網(wǎng)的應用和發(fā)展。

基于這個背景，論文主要介紹企業(yè)在建設物聯(lián)網(wǎng)過程中應該如何選擇IP協(xié)議的相關問題，特別是IPv6對IPv4取代的必然性以及企業(yè)物聯(lián)網(wǎng)建設中應用IPv6應該注意的問題。

一、因特網(wǎng)協(xié)議IP（Internet Protocol，IP）的發(fā)展歷程

互聯(lián)網(wǎng)建設的終極目標是：網(wǎng)絡是中立和無控制的，任何人都沒有決定權；網(wǎng)絡的應用是無關的，網(wǎng)絡的任務就是如何更好地傳輸數(shù)據(jù)報。因此，要建立一個可以無縫鏈接到其他網(wǎng)絡的系統(tǒng)和如何設計一個面向未來的網(wǎng)絡，就需要一個大家都接受的網(wǎng)絡協(xié)議。這個協(xié)議就叫因特網(wǎng)協(xié)議，也叫IP協(xié)議產(chǎn)生的前提條件，也是IP協(xié)議的重要作用。

IP協(xié)議最早形成于美國國防部高級研究項目局資助的工程所開發(fā)的協(xié)議（叫1822協(xié)議），在1970年為網(wǎng)絡控制協(xié)議（Network Control Protocol，NCP）所取代，NCP協(xié)議的目的是通過接口消息處理機（Interface Message Processor，IMP），現(xiàn)在也稱為智能物件的路由器，把網(wǎng)絡上的各個站點聯(lián)起來。Vint Cerf和Robert Kahn后來設計網(wǎng)絡傳輸控制協(xié)議TCP（Transport Control Protocol，TCP）來取代網(wǎng)絡控制協(xié)議NCP，由于兩者沒有分開，就統(tǒng)稱TCP/IP。在因特網(wǎng)協(xié)議（也叫IP協(xié)議）里，使用最為廣泛的兩個協(xié)議是傳輸協(xié)議TCP和用戶數(shù)據(jù)報協(xié)議UDP（User Datagram Protocol，UDP）。傳輸協(xié)議位于IP協(xié)議之上，為應用提供一種無須直接與IP層交互的通信機制。應用程序并不直接使用IP，而是通過傳輸協(xié)議相互通信。由于下層IP網(wǎng)絡盡最大可能傳遞數(shù)據(jù)報，但無法保證數(shù)據(jù)報一定可以到達目的地，也無法保證數(shù)據(jù)報的交付順序和發(fā)送時的順序相同，因此，用戶數(shù)據(jù)報協(xié)議UDP在IP層之上提供了一個附加層來解決前面的問題。IP使用地址標識因特網(wǎng)中的主機，UDP使用端口標識主機的每一個進程。端口是一個16bit的數(shù)值，用來區(qū)分每個端點不同的發(fā)送者和接收者。用戶數(shù)據(jù)報協(xié)議UDP提供一種盡力而為的傳送服務。

IPv4（TCP第4版）是在1982年設計，廣泛并成功地部署到全世界大量公用網(wǎng)絡和私有網(wǎng)絡中的數(shù)以億計的主機和路由器上。IPv6（TCP第6版）的發(fā)展是從1992年開始的，由IETF設計的下一代互聯(lián)網(wǎng)協(xié)議，目的是取代現(xiàn)有的互聯(lián)網(wǎng)協(xié)議第四版（IPV4）。經(jīng)過了十幾年的發(fā)展，IPv6的標準體系已經(jīng)基本完善，在這個過程中，IPv6逐步優(yōu)化了協(xié)議體系結構，為業(yè)務發(fā)展創(chuàng)造了機會。

隨著物聯(lián)網(wǎng)建設的發(fā)展，許多客觀世界中的物要通過智能物件經(jīng)過網(wǎng)絡聯(lián)系并能夠交互起來。這就需要IP協(xié)議能夠唯一識別并有效地把智能物件聯(lián)系起來。因此，一下子擴充了的網(wǎng)絡地址及其網(wǎng)絡操作發(fā)展中互通性、可擴展性、架構的穩(wěn)定性和普遍性受到人們的重視。

二、IPv6對IPv4取代：物聯(lián)網(wǎng)發(fā)展的必然

IPv4協(xié)議已經(jīng)使用了30多年，不可否認，IPv4在因特網(wǎng)的發(fā)展進程中起到了舉足輕重的作用。甚至今天的因特網(wǎng)中絕大多數(shù)仍是使用IPv4協(xié)議。但是，隨著計算機及路由器的迅速發(fā)展，特別是隨著物聯(lián)網(wǎng)的快速發(fā)展，IPv4的弊端日益明顯，IP6取代IP4成為物聯(lián)網(wǎng)發(fā)展的必需，具體如下：

（一）IPv6對IPv4的取代能夠解決物聯(lián)網(wǎng)發(fā)展過程中網(wǎng)絡地址的不足

當前，IPv4地址資源有限。從理論上講，編址1 600萬個網(wǎng)絡、大約43億個電腦可以聯(lián)到Internet上。但采用A、B、C三類編址方式后，可用的網(wǎng)絡地址和主機地址的數(shù)目大打折扣，以致目前的IP地址近乎枯竭。最近美國ARIN報告，A類地址已分配完；62%B類地址已分配；37%C類地址已分配，IPv4的地址空間將面臨耗盡的危險。IPv6產(chǎn)生的初衷主要是針對IPv4地址短缺問題，即從IPv4的32bit地址，擴展到了IPv6的128bit地址，充分解決了地址匱乏問題。同時，IPv6網(wǎng)絡中一個接口可以有一個或多個IPV6地址（包括單傳波地址、任播地址和多播地址），這也進一步增加了地址應用的擴展性。

（二）IPv6對IPv4的取代能夠解決物聯(lián)網(wǎng)發(fā)展過程中互通性、可擴展性、架構的穩(wěn)定性和普遍性的需要

1.IPv6取代IPv4，更能夠適應物聯(lián)網(wǎng)網(wǎng)絡傳輸控制的發(fā)展

網(wǎng)絡能夠互聯(lián)互通是網(wǎng)絡在任何數(shù)據(jù)改善之前，兩個端口之間必須建立一個鏈接。鏈接由端點的IP地址和TCP端口之間唯一確定。TCP在盡力而為的IP層之上提供一個可靠的字節(jié)流來傳輸服務，它通過緩沖數(shù)據(jù)并結合主動確認和重傳機制，實現(xiàn)傳輸可靠性；同時，TCP還提供包括建立和拆除鏈接的可靠方式。總之，TCP以更大的報頭和更為復雜的傳輸層協(xié)議的邏輯為代價降低了應用的復雜程度。

在物聯(lián)網(wǎng)環(huán)境下，智能物件有芯片內(nèi)存低、信息吞吐量低等特點。同時，用于物聯(lián)網(wǎng)環(huán)境下的UDP協(xié)議存在兩個缺點：UDP不為傳輸過程中丟失的數(shù)據(jù)報提供任何恢復機制，丟失的數(shù)據(jù)報由應用來恢復；同時，UDP不為應用提供任何機制來將數(shù)據(jù)割成大小適合網(wǎng)絡傳輸?shù)臄?shù)據(jù)塊。因此，必須計算出適合網(wǎng)絡傳送的分組數(shù)據(jù)大小，并相應地調(diào)整數(shù)據(jù)報。而這些功能TCP不但提供傳輸可靠性，還提供了一種自適應分組傳送報文大小的機制。這些功能就要求TCP的地址能夠把數(shù)量巨大的智能物件按唯一的身份聯(lián)系起來。因此，IPv6取代IPv4，更能夠適應物聯(lián)網(wǎng)網(wǎng)絡傳輸控制的發(fā)展。

2.IPv6取代IPv4更能夠適應物聯(lián)網(wǎng)發(fā)展過程中互通性、可擴展性、架構的穩(wěn)定性和普遍性的需要

隨著物聯(lián)網(wǎng)等信息技術的發(fā)展，雖然智能物件具有一定的智能，但是，它們畢竟是沒有智慧的物體，不能夠像人那樣熟悉直接操作網(wǎng)絡。因此，相對人來說，智能物件對物聯(lián)網(wǎng)中的網(wǎng)絡協(xié)議有更多的特殊要求，比如：可擴展性、互通性、架構穩(wěn)定性和普遍性等。

智能物件對IP協(xié)議的可擴展性需求是指IP協(xié)議能夠內(nèi)在支持智能物件的發(fā)展而具有可持續(xù)開發(fā)的機制；智能物件對IP協(xié)議的互通性需求是指IP協(xié)議能夠支持智能物件之間以及智能物件和網(wǎng)絡基礎設施之間可持續(xù)的互通性，這就要求IP協(xié)議提供網(wǎng)絡、應用和協(xié)議在網(wǎng)絡中不同鏈路層內(nèi)和層間的互通性；智能物件對IP協(xié)議的架構穩(wěn)定性和普遍性的需求是指雖然IP協(xié)議的可擴展很重要，但是IP協(xié)議的架構穩(wěn)定性和普遍性對智能物件在生命周期內(nèi)具有重要意義。

總之，IPv4近20年的空前成功，已經(jīng)證明了IPv4協(xié)議設計的基本思想、構架是值得肯定的。IPv6并不是一個全新的網(wǎng)絡協(xié)議標準，沒有完全IPv4的所有思路和結構，它總結IPv4近20年來運營所獲得的豐富經(jīng)驗和教訓，繼承IPv4協(xié)議運行的主要優(yōu)點，最后進行了大幅修改和功能擴充。例如：針對物聯(lián)網(wǎng)的發(fā)展需要，除了具有龐大的地址空間外，IPv6對IPv4功能上進行了發(fā)展，簡易靈活的頭部格式、網(wǎng)絡資源可進行預分配、更高的安全性、支持即插即用和移動性。由于這些特性技術含量較高，這里不進行具體介紹。智能物件由于自身的特殊性對物聯(lián)網(wǎng)的IP協(xié)議具有特殊的要求，新一代的IPv6能夠為物聯(lián)網(wǎng)的應用和服務提供可橫跨多種通信技術的互通、可擴展、穩(wěn)定和普遍的網(wǎng)絡架構協(xié)議，為互聯(lián)網(wǎng)換上一個簡捷、高效的引擎，這樣不僅可以解決IPv4目前的地址短缺難題，而且可以使物聯(lián)網(wǎng)擺脫日益復雜、難以管理和控制的局面，變得更加穩(wěn)定、可靠、高效和安全。

三、企業(yè)應用IPv6應該注意的主要問題

隨著3G通訊業(yè)務、智能手機等多種個人智能終端、超高速家庭網(wǎng)絡的發(fā)展，針對網(wǎng)絡地址不足等問題，我國已經(jīng)起動IPv6取代IPv4的工程。這對物聯(lián)網(wǎng)建設具有重要的現(xiàn)實意義。但是，正如每一個新生事物一樣，IPv6也有其不足的地方，企業(yè)在物聯(lián)網(wǎng)建設中應用IPv6除了進行詳盡的規(guī)劃與設計外，還應該主要注意過渡性問題與安全問題。

（一）過渡性問題

雖然IPv4有上述缺陷以及IPv6協(xié)議標準的成熟具有取代IPv4位置的必然趨勢，但是，這種取代的過程必然會經(jīng)歷一個相對漫長的過程。同時，盡管IETF在設計IPv6的時候已經(jīng)充分考慮了和IPv4的兼容性，但是這兩個版本不是完全兼容的。因此，企業(yè)在物聯(lián)網(wǎng)建設中必須考慮由IPv4向IPv6過渡的問題。首先是處理好IPv4向IPv6遷移時應該考慮的地方：Ipv4與Ipv6的主機必須可互操作；Ipv6主機和路由器的使用必須簡單，逐漸地分布普及到整個Internet，不能有太多的相互依賴性；網(wǎng)絡管理員和最終用戶必須認為這種遷移容易理解和執(zhí)行。其次是注意過渡技術的選擇，即雙協(xié)議棧技術、隧道技術和網(wǎng)絡地址轉換技術。

（二）安全性問題

引入IPv6出現(xiàn)的安全問題主要來源于兩方面：一方面是由于IPv6本身的缺陷所引發(fā)的安全問題；另一方面是由于IPv6的過渡技術引發(fā)的安全問題。由IPv6本身的缺陷引發(fā)的安全問題有：IPv6現(xiàn)在遇到的安全威脅主要包括地址掃描、非法訪問、分片、路由協(xié)議的認證、蠕蟲攻擊、對ICMPv6的攻擊、對鄰居發(fā)現(xiàn)的攻擊以及對無狀態(tài)地址自動配置的攻擊等；過渡技術引發(fā)的問題有：雙棧技術的安全問題、隧道技術的安全問題、地址翻譯技術的安全問題等。

四、結論與啟示

物聯(lián)網(wǎng)建設需要把數(shù)以億計的物件“互聯(lián)互通”并且“相互作用”，企業(yè)在建設物聯(lián)網(wǎng)過程中應該選擇IPv6對IPv4取代的IP協(xié)議的標準是：不僅要有充足的地址資源，更需要IPv6能夠在網(wǎng)絡操作發(fā)展中有更好的互通性、可擴展性、架構的穩(wěn)定性和普遍性。

IPv6對IPv4是一個不能夠相互兼容的IP協(xié)議。物聯(lián)網(wǎng)建設從IPv4向IPv6遷移產(chǎn)生不少的過渡困難。這給大家的啟示便是能夠有統(tǒng)一的標準，不僅是技術標準，也包括管理標準。如果說IPv4向IPv6遷移中技術問題比重較大的話，那么，基于物聯(lián)網(wǎng)會計云計算建設中就會克服更多的需要統(tǒng)一的管理標準。如：當前，由于沒有統(tǒng)一的云計算標準，Google、Amazon、微軟、IBM等公司紛紛推出自己的云計算平臺和云計算的實務標準。這就導致了不同廠商的服務出現(xiàn)兼容性問題。如何通過溝通協(xié)作，把這些實務標準變成統(tǒng)一標準需要大家共同努力。

篇3

關鍵詞:“計算機網(wǎng)絡”教學;Wireshark;TCP/IP

“計算機網(wǎng)絡”課程作為計算機科學與技術、網(wǎng)絡工程、通信工程和軟件工程等專業(yè)的主干課,其地位在課程體系群中尤為重要。學習這門課程,最重要的是掌握計算機網(wǎng)絡的原理,了解網(wǎng)絡硬件和軟件的工作機制。計算機網(wǎng)絡基礎理論復雜抽象,概念眾多,對剛開始學習計算機網(wǎng)絡的學生來說,這些概念和協(xié)議是非常難以理解和記憶的。計算機網(wǎng)絡原理主要描述的是各層的功能及其協(xié)議和服務,具體地說就是要理解網(wǎng)絡的相關功能層概念和網(wǎng)絡體系結構(包括OSI參考模型、TCP/IP模型協(xié)議族),以及功能模塊之間的協(xié)議交互[1],這是學好計算機網(wǎng)絡的關鍵。網(wǎng)絡體系結構是計算機網(wǎng)絡及其部件所應完成的功能的精確定義。計算機網(wǎng)絡原理主要講述的就是各層的功能及其協(xié)議和服務。在計算機網(wǎng)絡教學過程中,利用Wireshark網(wǎng)絡探測和分析軟件,通過從網(wǎng)絡中實時捕獲幾種常見協(xié)議數(shù)據(jù)包并進行分析,使學生對一些協(xié)議的工作原理及結構有了更加深刻的理解和認識[2]。

1Wireshark簡介

Wireshark(原名Ethereal)是目前世界上最受歡迎的協(xié)議分析軟件,利用它可將捕獲到的網(wǎng)絡二進制數(shù)據(jù)流翻譯為人們?nèi)菀鬃x懂和理解的文字和圖表等形式,極大地方便了對網(wǎng)絡活動的監(jiān)測分析和教學實驗。它有十分豐富和強大的統(tǒng)計分析功能,可在Windows,Linux 和UNIX等系統(tǒng)上運行。它允許在一個網(wǎng)絡內(nèi)部實時捕獲和分析數(shù)據(jù)包,用戶可以通過圖形界面很直觀地瀏覽捕獲到的數(shù)據(jù)信息,研究數(shù)據(jù)包每一層的詳細信息[3]。

學習和理解計算機網(wǎng)絡原理的最好方法是,理論聯(lián)系實際。在一個現(xiàn)實的局域網(wǎng)中,網(wǎng)絡數(shù)據(jù)流往往是來自不同用戶的各種各樣協(xié)議數(shù)據(jù)的大混雜,因此利用Wireshark的“捕獲過濾器”和“顯示過濾器”,從錯綜復雜的數(shù)據(jù)流中迅速提取自己所關心的網(wǎng)絡信息,了解和掌握網(wǎng)絡的工作原理和協(xié)議的交互過程。

Wireshark使用目的是網(wǎng)絡管理員使用Wireshark來檢測網(wǎng)絡問題、網(wǎng)絡安全工程師使用Wireshark來檢查資訊安全相關問題、開發(fā)者使用Wireshark來為新的通訊協(xié)議除錯、普通使用者使用Wireshark來學習網(wǎng)絡協(xié)議的相關知識等。

2用Wireshark分析網(wǎng)絡協(xié)議

網(wǎng)絡協(xié)議是網(wǎng)絡上所有設備(網(wǎng)絡服務器、計算機及交換機、路由器、防火墻等)之間通信規(guī)則的集合,它定義了通信時信息必須采用的格式和這些格式的意義。TCP/IP(Transmission Control Protocol / Internet Protocol),即傳輸控制協(xié)議/互聯(lián)網(wǎng)協(xié)議是不同操作系統(tǒng)的計算機網(wǎng)絡互連的通用協(xié)議,它是一組計算機通信協(xié)議族,其中最著名的兩個協(xié)議是TCP及IP協(xié)議。TCP/IP協(xié)議具有開放式互聯(lián)環(huán)境,很容易實現(xiàn)各種局域網(wǎng)和廣域網(wǎng)的集成式互聯(lián)。此協(xié)議是當今技術最成熟、應用最廣泛的網(wǎng)絡協(xié)議[4]。

TCP是一種面向連接的、可靠的運輸層協(xié)議,TCP數(shù)據(jù)傳輸(只有連接建立后才可進行數(shù)據(jù)傳輸)需要通過在客戶端和服務器端建立特定的虛電路連接來完成,該過程通常被稱為“三次握手”,即發(fā)送方先發(fā)送連接請求,然后接收方進行連接確認,最后發(fā)送方對接收方的確認再次進行確認(圖1)。下面就以Wireshark對 TCP連接建立交互過程的數(shù)據(jù)包捕獲分析為例,來說明對TCP/IP協(xié)議實現(xiàn)的分析。

2.1建立捕獲TCP連接報文的實驗環(huán)境

PCATTCP是一款不錯的測試局域網(wǎng)網(wǎng)絡速度的軟件。在局域網(wǎng)中,兩臺主機通過交換機連接起來。在服務器端和客戶端都安裝和運行PCATTCP進行通信,產(chǎn)生TCP流。啟動Wireshark進行數(shù)據(jù)包捕獲,單擊CaptureInterfaces菜單,選擇自己的網(wǎng)卡,選擇Start開始監(jiān)控流量。在服務器端運行ttcp,監(jiān)聽TCP的5001端口。圖2是服務器端的完整命令行輸出:

服務器配置好后,在客戶端運行ttcp,雙方開始通信。

2.2TCP報文分析

2.2.1客戶端發(fā)送連接請求

捕捉到的TCP 連接報文如圖3所示。

從圖3可以看出,客戶端發(fā)出的連接請求數(shù)據(jù)包封裝了三個頭信息:以太網(wǎng)(Ethernet)幀、IP數(shù)據(jù)報和TCP報文段。在數(shù)據(jù)鏈路層,數(shù)據(jù)以幀的方式進行傳輸。在網(wǎng)絡層,加工的主要數(shù)據(jù)對象是IP數(shù)據(jù)報。IP協(xié)議是TCP/IP協(xié)議族中的核心協(xié)議之一,所有的TCP、UDP、ICMP數(shù)據(jù)都以IP數(shù)據(jù)報格式傳輸。

在運輸層,主要數(shù)據(jù)對象是TCP報文。客戶端發(fā)送的連接請求如圖4所示。

第一條報文是沒有數(shù)據(jù)的TCP報文段,并且將首部的SYN位設置為1。因此,第一條報文常常被稱為SYN分組。這個報文段里的序列號是由系統(tǒng)隨機設置的數(shù)值,表示客戶端為后續(xù)報文設定的起始編號。此TCP報文段,序列號SEQ在連接請求時相對初始值是0,其實際值是c9 f4 65 c2;確認號是00 00 00 00,ACK標志為0表明確認號被忽略。SYN=1表示正在進行連接請求,通過SYN和ACK也可以用來區(qū)分Connection Request和Connection Accepted,在連接請求中,SYN=1、ACK=0,連接響應時,SYN=1、ACK=1。

SYN分組通常是從客戶端發(fā)送到服務器端。這個報文段請求建立連接。因為一旦成功建立連接,服務器進程必須已經(jīng)在監(jiān)聽SYN分組所指示的IP地址和端口號[5]。如果沒有建立連接,SYN分組將不會應答。如果第一個分組丟失了,客戶端通常會發(fā)送若干個SYN分組,如果多次嘗試不成功,客戶端將會停止并報告一個錯誤給應用程序。

2.2.2服務端連接響應

當服務器接收到連接請求時,就對請求方進行響應,以確認收到客戶端的第一個TCP報文段。響應的報文段SYN位和ACK位都將置1。通常稱這個報文段為SYNACK分組。SYNACK分組在確認收到SYN分組的同時也發(fā)出一個初始的數(shù)據(jù)流序列號,表示服務器發(fā)向客戶端的數(shù)據(jù)序號,它不需要與剛才客戶端發(fā)來的數(shù)據(jù)流的序列號相匹配。服務器端響應的數(shù)據(jù)包如圖5所示。

此數(shù)據(jù)包的起始序列號SEQ在協(xié)議框中顯示為0,在原始框中的實際值為63 cf 1a c9。所有初始序列號邏輯上都視同為序列號0。ACK標志為1表明確認號有效,SYN仍然為1。

圖6中確認號在協(xié)議框中顯示為1,在原始框中的值為c9 f4 65 c3(比c9 f4 65 c2多1)。這解釋了TCP的確認模式,TCP接收端確認第X個字節(jié)已經(jīng)收到,并通過設置確認號為X+1來表明期望收到的下一個字節(jié)號。

2.2.3客戶端連接確認

在TCP連接建立的最后階段,客戶端對接收到數(shù)據(jù)包的服務器端進行確認,到此為止建立完整的TCP連接,開始全雙工模式的數(shù)據(jù)傳輸過程。客戶端收到服務器端確認后,發(fā)送帶有ACK標志的TCP報文段來完成三次握手的過程[6]。這個報文段將確認服務器端發(fā)送的SYNACK分組,并檢查TCP連接的兩端是否正確地打開和運作。

如圖7所示,在確認階段,數(shù)據(jù)包由客戶端發(fā)送至服務器端,TCP中的序列號為c9 f4 65 c3(即上次服務器響應報文的確認號)。

圖8中,報文段的本次確認號為63 cf 1a ca(即上次的序列號加1)表示客戶端下一次希望從主機接收的數(shù)據(jù)的起始位置。ACK標志為1表明確認號有效,SYN置為0表示連接建立結束。連接建立后,雙方可以根據(jù)各自的窗口尺寸開始傳輸數(shù)據(jù)。

2.3小結

從以上的圖可以看出,利用Wireshark可以針對每一數(shù)據(jù)包,完成從鏈路層、網(wǎng)絡層、運輸層到應用層的協(xié)議解析。通過上面步驟,可以更加直觀的觀察到TCP三次握手建立的過程,有助于理解TCP及其工作原理,掌握協(xié)議的語法細節(jié)。

3結語

計算機網(wǎng)絡基本理論復雜抽象,不易理解,但這部分內(nèi)容又是進一步學習“計算機網(wǎng)絡”課程,培養(yǎng)實踐應用能力的基礎。在教學過程中,通過合理組織授課內(nèi)容,采用先進的教學方法和較為科學的教學手段,使學生能夠較好地掌握計算機網(wǎng)絡的基本理論和方法。利用Wireshark網(wǎng)絡協(xié)議分析軟件,進行網(wǎng)絡性能參數(shù)和數(shù)據(jù)代碼的捕獲分析,了解協(xié)議的封裝結構、交互過程,對于計算機網(wǎng)絡教學有很大的幫助。

參考文獻:

[1] 謝希仁. 計算機網(wǎng)絡[M]. 大連:大連理工大學出版社,2004.

[2] 楊春勇,潘文君,朱翠濤. 計算機網(wǎng)絡課程教學及輔助教學方法研究[J]. 高等函授學報:自然科學版,2008,21(6):12-14.

[3] Angela Orebaugh,Gilbert Ramirez,Jay Beale. Wireshark & Ethereal Network Protocol Analyzer Toolkit[M]. Burlington:Syngress Press,2006.

[4] Forouzan.B.A. TCP/IP協(xié)議族[M]. 3版. 謝希仁,等譯. 北京:清華大學出版社,2006.

[5] 蔣波,李方軍,郝軍. 數(shù)據(jù)包的截獲與網(wǎng)絡協(xié)議分析[J]. 重慶三峽學院學報,2006,22(3):26-28.

[6] Miller D. 數(shù)據(jù)通訊與網(wǎng)絡[M]. 鄧勸生,薛建新,王涌,譯. 北京:清華大學出版社,2007.

The Application of Wireshark in TCP/IP Network Protocol Teaching

PAN Wen-chan, ZHANG Yun

(College of Computer Science, Nanjing University of Posts and Telecommunications, Nanjing 210003, China)

篇4

【關鍵詞】TCP/IP協(xié)議；通信報文；路由尋址；通信流程

1 概述

隨著信息科學技術和通信技術的不斷快速發(fā)展，基于互聯(lián)網(wǎng)的網(wǎng)絡通信應用在社會各個領域中的應用越來越廣泛，使得互聯(lián)網(wǎng)通信應用成為現(xiàn)代人日常生產(chǎn)生生活不可或缺的一部分，通過互聯(lián)網(wǎng)絡通信，網(wǎng)絡用戶之間可以實現(xiàn)數(shù)據(jù)傳輸、信息共享，從而極大地提高了人們的生活質(zhì)量。然而，互聯(lián)網(wǎng)絡中的數(shù)據(jù)傳輸過程，并不是雜亂無章的隨機傳送，而是在計算機網(wǎng)絡通信協(xié)議的基礎上，雙方都按照協(xié)議的內(nèi)容和機制，來發(fā)送數(shù)據(jù)信息和讀取分析數(shù)據(jù)信息，進而實現(xiàn)互聯(lián)網(wǎng)絡的數(shù)據(jù)傳輸和信息共享的功能，TCP/IP協(xié)議就是互聯(lián)網(wǎng)絡中重要的通信協(xié)議，它的存在奠定了整個互聯(lián)網(wǎng)絡通信的基礎，所以對于TCP/IP通信協(xié)議的學習對于理解互聯(lián)網(wǎng)通信機制來輔助互聯(lián)網(wǎng)學習和工作具有很大的幫助。

2 計算機網(wǎng)絡的TCP/IP通信協(xié)議

TCP/IP協(xié)議是“Transmission Control Protocol / Internet Protocol”的簡寫，是Internet網(wǎng)絡基本的協(xié)議，它為計算機通訊的數(shù)據(jù)打包傳輸以及網(wǎng)絡尋址提供了標準的方法。由于TCP/IP協(xié)議的優(yōu)越性，使得越來越多的通信設備支持TCP/IP協(xié)議，使互聯(lián)網(wǎng)絡逐步走向規(guī)范化，最終TCP/IP協(xié)議成為了當前網(wǎng)絡通信協(xié)議標準中最基本的網(wǎng)絡通信協(xié)議、Internet國際互聯(lián)網(wǎng)絡的基礎。

2.1 計算機網(wǎng)絡TCP/IP協(xié)議

針對計算機互聯(lián)網(wǎng)絡的通信協(xié)議，國際標準組織ISO創(chuàng)立了七層OSI網(wǎng)絡模型，自上而下，分別為應用層、表示層、會話層、傳輸層、網(wǎng)絡層、數(shù)據(jù)鏈路層、物理層。而TCP/IP協(xié)議則是應用在傳輸層和網(wǎng)絡層的數(shù)據(jù)傳輸控制協(xié)議，來規(guī)定網(wǎng)絡設備接入互聯(lián)網(wǎng)絡以及設備間數(shù)據(jù)通信的標準。在通信設備經(jīng)過互聯(lián)網(wǎng)絡進行數(shù)據(jù)傳輸時，通信設備數(shù)據(jù)發(fā)送端，發(fā)送TCP/IP通信報文，此時TCP/IP協(xié)議攜帶著通信設備發(fā)送端的傳輸數(shù)據(jù)內(nèi)容以及目標通信設備的地址標示在互聯(lián)網(wǎng)絡中進行尋址，從而正確地傳送到目標通信設備。當目標通信設備接收到TCP/IP通信報文后，按照協(xié)議內(nèi)容，去除通信標示，來獲取傳輸數(shù)據(jù)內(nèi)容，并加以校驗，如果經(jīng)校驗后發(fā)生差錯，目標通信設備會發(fā)出TCP/IP信息重發(fā)報文，讓發(fā)送通信設備再次將TCP/IP通信報文發(fā)展目標通信設備，去掉通信標示來獲取傳輸數(shù)據(jù)信息。

2.2 TCP/IP通信協(xié)議報文格式

在互聯(lián)網(wǎng)絡中，基于TCP/IP通信協(xié)議傳輸?shù)臄?shù)據(jù)內(nèi)容都是以通信報文的形式在互聯(lián)網(wǎng)絡內(nèi)部進行傳輸，通信報文實質(zhì)上就是一串二進制字符串，而字符串內(nèi)不同位置的二進制字符標示不同的含義。從TCP/IP通信協(xié)議的主要報文格式可以看出，IP協(xié)議是基于TCP協(xié)議至上的，TCP協(xié)議報文時作為IP通信報文的數(shù)據(jù)部分來進行傳輸?shù)摹嶋H上，互聯(lián)網(wǎng)內(nèi)傳輸?shù)耐ㄐ抛址€有其他的通信協(xié)議，TCP/IP通信報文也是作為其外層協(xié)議的通信數(shù)據(jù)部分嵌入到通信報文中在互聯(lián)網(wǎng)內(nèi)進行傳輸。

在IP協(xié)議首部，包含了一些關于IP協(xié)議的標示、通信地址等信息，主要包括數(shù)據(jù)字符串總長度的信息、通信標示號、源IP地址和目標IP地址等信息，當IP通信報文經(jīng)過路由尋址時，會根據(jù)首部內(nèi)記錄的目標IP地址來選擇傳輸方向，最終根據(jù)目標IP地址傳輸至目標通信設備。此外，IP通信報文首部還包含其他信息，比如IP協(xié)議版本號、首部長度、校驗信息、該IP通信報文生存時間（即該報文經(jīng)過多少個路由后自動取消傳輸）等與IP通信報文相關的信息，以確保IP報文傳輸?shù)恼_性和安全性。TCP協(xié)議通信報文是作為IP通信報文數(shù)據(jù)內(nèi)容存在的，TCP協(xié)議也分為TCP報文首部和TCP通信數(shù)據(jù)。TCP通信報文首部主要包括了源端口號和目標端口號等信息，當TCP/IP通信報文經(jīng)過互聯(lián)網(wǎng)絡到達目標通過新設備后，通信設備會根據(jù)TCP報文首部的目的端口號選擇設備端口號來接受該數(shù)據(jù)信息，進而實現(xiàn)互聯(lián)網(wǎng)絡的數(shù)據(jù)傳輸。

2.3 TCP/IP協(xié)議通信過程

互聯(lián)網(wǎng)絡的通信設備基于TCP/IP協(xié)議建立通信過程，也是根據(jù)TCP/IP協(xié)議來實現(xiàn)的。當源通信設備想向目標設備發(fā)送數(shù)據(jù)時，首先會發(fā)送一個TCP/IP通信報文來確認連接，該通信報文在互聯(lián)網(wǎng)絡中經(jīng)過尋找傳輸后找到目標設備，目標設備也會向源通信設備發(fā)送一個TCP/IP報文以確認建立通信連接，此時，源通信設備就會將通信數(shù)據(jù)以TCP/IP通信報文的形式進行數(shù)據(jù)打包，然后向目標數(shù)據(jù)進行傳輸，在收到數(shù)據(jù)后，目標設備同樣會發(fā)送TCP/IP報文以確認收到信息。當然，TCP/IP通信數(shù)據(jù)長度是一定的，當通信數(shù)據(jù)超過報文長度時，源通信設備會將其分段發(fā)送，而目標設備則會根據(jù)IP報文首部的標識號進行數(shù)據(jù)重組來重現(xiàn)傳輸數(shù)據(jù)信息，進而完成互聯(lián)網(wǎng)絡通信設備數(shù)據(jù)傳輸。

3 總結

TCP/IP網(wǎng)絡協(xié)議是當前互聯(lián)網(wǎng)絡最基本的通信協(xié)議。根據(jù)TCP/IP網(wǎng)絡協(xié)議，連接在互聯(lián)網(wǎng)內(nèi)的通信設備可以根據(jù)TCP/IP通信報文格式的內(nèi)容將傳輸數(shù)據(jù)打包在TCP/IP通信報文內(nèi)，并以其規(guī)定的通信流程進行數(shù)據(jù)傳輸，從而實現(xiàn)互聯(lián)網(wǎng)絡內(nèi)的數(shù)據(jù)高效安全的傳輸。

參考文獻：

[1]楊紹文.談計算機網(wǎng)絡的TCP/IP協(xié)議[J].科技信息.2011（02）

[2]查東輝.試論計算機網(wǎng)絡通信協(xié)議[J].電腦知識與技術.2013（14）

[3]楊嬌娟.淺談TCP/IP協(xié)議[J].數(shù)字技術與應用.2012（03）

篇5

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

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

1 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TCP/IP是幾百種網(wǎng)絡協(xié)議的集合。通用計算機系統(tǒng)有足夠的資源支持通信協(xié)議在內(nèi)核實現(xiàn)，因此完整的TCP/IP協(xié)議棧（如圖1）能夠在數(shù)據(jù)傳輸?shù)目煽啃院蛿?shù)據(jù)流量的控制上做很多工作。

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

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

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

圖1

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

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

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

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

3.1 ARP協(xié)議的實現(xiàn)

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

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

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

void ping_request() //PING請求

void ping_answer() //PING應答

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

3.3 UDP協(xié)議的實現(xiàn)

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

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é)議的實現(xiàn)

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

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

(2)驗證。采取相應的措施消除傳輸中的錯誤，保障傳輸?shù)目煽啃裕眯蛄刑柦鉀Q通信時重復和失序的問題。

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

TCP協(xié)議的功能是為應用層協(xié)議提供可靠的面向連接的數(shù)據(jù)傳輸服務，是嵌入式應用系統(tǒng)協(xié)議棧中最為復雜的協(xié)議。在TCP協(xié)議實現(xiàn)中，由于請求發(fā)起端(客戶端)與請求相應端(服務器端)在通信中所處地位不同，相應地兩者的中間演變狀態(tài)也不完全相同。客戶端與服務器端在一個TCP連接從正常建立到正常中止分別經(jīng)歷5個和6個狀態(tài)，相應控制信息均在TCP頭部信息的6位控制標記位中得以表示。對于嵌入式系統(tǒng)中TCP協(xié)議的實現(xiàn)，應從嵌入式應用的角度出發(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)的網(wǎng)絡接入問題具有十分重要的意義。本文實現(xiàn)的精簡TCP/IP協(xié)議棧在具體應用中有良好表現(xiàn)，可以滿足正常的數(shù)據(jù)傳輸。由于設計與實現(xiàn)的過程中將應用層協(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é)議單片機上網(wǎng)的設計與實現(xiàn)[J]. 武漢科技大學學報(自然科學版)，2004,(2).

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

篇6

【關鍵詞】計算機多線程 協(xié)議還原 方法概述

1 協(xié)議并行處理方法

1.1 數(shù)據(jù)包級別并行方法

在協(xié)議棧并行處理方法中，數(shù)據(jù)包級別并行方法是一種并行度最高的處理方法。對于不同的數(shù)據(jù)包都會按照對應的處理器進行系列處理，達到同時處理多個數(shù)據(jù)包或者是歸屬于同一個鏈接的數(shù)據(jù)包。因巨大的吞吐性能以及不存在負載均衡的優(yōu)勢得到了廣泛運用。雖然其具有高度的并發(fā)性，但是在面對帶有上下文信息或狀態(tài)的協(xié)議來說，例如TCP，可以獲得的性能提升空間受到了很大的約束。

1.2 函數(shù)級別并行方法

函數(shù)級別并行方法主要運用于早期的協(xié)議并行處理中。早期協(xié)議是將鏈路控制數(shù)據(jù)和傳送數(shù)據(jù)置于同一個數(shù)據(jù)包中，這就意味著協(xié)議并行處理的函數(shù)必須要同時處理鏈路控制數(shù)據(jù)外加上傳送數(shù)據(jù)，從而出現(xiàn)的一個問題就是協(xié)議處理函數(shù)單元之間務必會存在大量的上下文相關結果。

1.3 協(xié)議棧層次間并行方法

協(xié)議棧層次間并行方法主要運用于目前網(wǎng)絡協(xié)議的層次結構中。在早期設計相關網(wǎng)絡協(xié)議時，為了大幅度的降低協(xié)議實現(xiàn)難度而將每個層次協(xié)議設計成為了相對獨立的部分，從而完成獨立層間之間的并行處理。但是就目前實際情況來看，這種方法雖然有許多的優(yōu)勢，但是性能受到了層次結構中吞吐量最低層次結構的限制，所以目前需要對協(xié)議棧中的每一個層次進行研究，優(yōu)化吞吐量最低的層次結構。

2 基于連接性多線程TCP/IP協(xié)議并行處理方法概述

2.1 TCP/IP協(xié)議棧多線程并行化存在的問題

TCP/IP協(xié)議棧多線程并行化存在的問題主要存在于臨界鎖以及處理器之間的負載均衡情況上。考慮到臨街鎖解決共享沖突的代價極大問題，多線程并發(fā)程序雖然可以解決部分問題，但是又帶來了諸如臨界區(qū)碰撞、內(nèi)核陷入等等問題，影響程序的運行效率。因此，對于多線程并行的TCP/IP協(xié)議而言，消除臨界鎖問題是至關重要的。對于處理器之間的負載均衡情況，需要考慮的就是協(xié)調(diào)好處理器之間的負載均衡問題。

2.2 多線程TCP/IP協(xié)議棧的結構

本文所要分析的多線程TCP/IP協(xié)議棧結構主要還是共享內(nèi)存多處理器平臺運行下的多線程TCP/IP協(xié)議棧結構，其基本的特點就是當共享內(nèi)存對處理器平臺上的處理器數(shù)量增加時，其結構的性能也隨之增加。多線程TCP/IP協(xié)議棧結構如圖1所示。

2.3 處理器均衡措施

處理器均衡措施具體可以細化分為兩個步驟。第一個步驟就是對IP數(shù)據(jù)包中的三元組即源地址、目的地址以及協(xié)議標識，按照一定的標準進行分發(fā)。僅僅采取第一步不能夠對處理器進行深度的處理，需要借助于第二個步驟。第二個步驟包括設置協(xié)議棧、促進操作系統(tǒng)借助于任務調(diào)度完成負載均衡的操作。后者的時間點在于運行線程數(shù)不小于硬件平臺的處理器數(shù)量。按照上述順序，可以達到處理器負載均衡的目的。

3 實驗方案結果

從本文的實驗方案測試結果中可以看出，首先單線程下的程序只能夠通過串來執(zhí)行，從而不能夠發(fā)揮出處理器的實際性能。其次，在處理器的數(shù)量和線程數(shù)量對等的情況之下，也不能夠發(fā)揮出系統(tǒng)硬件的全部性能。最后，在處理器數(shù)量小于協(xié)議棧線程數(shù)量的時點，通過適當?shù)脑黾泳€程數(shù)量，可以在很大程度上提高整個系統(tǒng)的吞吐量。另外，對于內(nèi)存分配方式對系統(tǒng)性能的影響上，結合實踐經(jīng)驗以及實驗方案結構可以發(fā)現(xiàn)，相比PtMalloc以及SmartBits而言，F(xiàn)ixMalloc可以降低動態(tài)內(nèi)存分配過程中出現(xiàn)的處理器消耗，降低的幅度值大概在8.12%上下。

4 結束語

由于現(xiàn)代處理器性能和網(wǎng)絡傳輸能力發(fā)展之間存在的很大的不平衡，從而推進了多處理器的發(fā)展。本文從網(wǎng)絡協(xié)議還原技術出發(fā)，提出了一整套的多線程并行的TCP/IP協(xié)議的相關還原方案。此外，在通用性的多處理器計算平臺的實際操作過程中發(fā)現(xiàn)，雖然計算機多線程TCP/IP協(xié)議還原技術可以很好的保障當下處理器平臺性能的發(fā)揮，但是對于進一步提升網(wǎng)絡入侵監(jiān)測系統(tǒng)協(xié)議還原能力以及挖掘高性能處理器平臺，以此來協(xié)調(diào)處理器性能和網(wǎng)絡傳輸能力發(fā)展不平衡的矛盾，將是下一階段研究和探究的重點內(nèi)容。

參考文獻

[1]Bjorkman M，Gunningberg P Performance Modeling of Multiprocessor Implementations of Protocols[J]，2009，11（03）：142-145.

[2]田偉，顧韻華，丁妮.網(wǎng)絡行為監(jiān)測與還原系統(tǒng)及關鍵技術研究[J].計算機工程與設計，2011，29（02）：111-113.

[3]譚敏生，湯亮.基于HTIP的網(wǎng)絡數(shù)據(jù)包還原技術研究[J].計算機技術與發(fā)展，2011，17（06）：14-16.

篇7

關鍵詞：TCP/IP 溫度監(jiān)測 Arduino LabView

中圖分類號：TP2 文獻標識碼：A 文章編號：1007-9416（2015）09-0000-00

現(xiàn)場總線系統(tǒng)是一種傳統(tǒng)的雙向數(shù)字的通信標準，廣泛應用于自動控制領域和生產(chǎn)過程中，但是由于現(xiàn)場總線的種類繁多，且各標準間的相互兼容性不強，加上各廠商和標準制訂組織之間存在利益競爭，各種現(xiàn)場總線技術無法實現(xiàn)無縫連接，也無法將生產(chǎn)現(xiàn)場的監(jiān)控數(shù)據(jù)共享給企業(yè)的信息管理系統(tǒng)，而將以太網(wǎng)技術引入到工業(yè)控制領域，將監(jiān)控數(shù)據(jù)進行標準的TCP/IP封裝，將能很好的解決不同生產(chǎn)設備間的高速連接問題和設備的“自動化孤島”問題，最終將生產(chǎn)自動化和辦公自動化無縫對接，實現(xiàn)“一網(wǎng)到底”[1]。工業(yè)以太網(wǎng)是指在工業(yè)環(huán)境的自動化控制及過程控制中應用的相關組件及技術，工業(yè)以太網(wǎng)多采用TCP/IP協(xié)議，和IEEE802.3標準兼容。溫度是生產(chǎn)過程中重要的物理參數(shù)之一，在工業(yè)生產(chǎn)過程中經(jīng)常要用到溫度的檢測及控制，本文對基于TCP/IP網(wǎng)絡的遠程溫度檢測系統(tǒng)進行了設計，給出了基于TCP/IP以太網(wǎng)的遠程溫度監(jiān)測方案。

1 系統(tǒng)結構

1.1系統(tǒng)物理結構

使用標準的TCP/IP協(xié)議實現(xiàn)現(xiàn)場層與監(jiān)控層的數(shù)據(jù)傳輸，其中現(xiàn)場層通過連接廠內(nèi)的傳感器，實時獲取各種信息通過以太網(wǎng)絡傳送至監(jiān)控層，這一層主要由低功耗運行穩(wěn)定的嵌入式實現(xiàn)；監(jiān)控層主要是通過以太網(wǎng)絡連接廠內(nèi)的現(xiàn)場層的各個數(shù)據(jù)采集點，將這些信息數(shù)據(jù)備份，存儲至監(jiān)控系統(tǒng)的數(shù)據(jù)庫，并在溫度超過警示值時發(fā)出警報。本系統(tǒng)完成了下位機數(shù)據(jù)采集與上位機數(shù)據(jù)監(jiān)測的功能，物理結構圖如圖1所示。

圖1 系統(tǒng)物理結構圖

1.2 系統(tǒng)邏輯結構

本系統(tǒng)的溫度信息由數(shù)據(jù)采集結點通過以太網(wǎng)發(fā)送到監(jiān)控層計算機，并將歷史數(shù)據(jù)存儲致數(shù)據(jù)庫服務器，企業(yè)的辦公網(wǎng)絡和外網(wǎng)用戶可通核心路由器訪問數(shù)據(jù)庫，系統(tǒng)的數(shù)據(jù)在各層中的流向如圖2所示。

圖2 系統(tǒng)邏輯結構

2 數(shù)據(jù)采集與發(fā)送端

2.1數(shù)字溫度采集點設計

K型熱電偶可以測量固體介質(zhì)和汽液體蒸氣的表面溫度，其測量范從0℃到1300℃[2]。具有很高的靈敏度和很好的穩(wěn)定性，非線性誤差小，熱電動勢較大，對于復雜環(huán)境下的工業(yè)環(huán)境有很好的適應性等優(yōu)點，因此，在工業(yè)監(jiān)控領域得到廣泛的使用。但是，由于其輸出熱電勢與冷端溫度相關，輸出的數(shù)據(jù)為模擬量，且與被測量端的溫度有關，因此需要進行溫度補償和模數(shù)轉換。如果采用軟件補償?shù)姆椒ǎ环矫鏁黾映绦蚓幹萍罢{(diào)試電路的難度，另一方面，軟件補償會占用一定的數(shù)字結點的計算資源，而以太網(wǎng)使用了CSMA/CD，會產(chǎn)生數(shù)據(jù)傳送過程中的不確定性，影響精度。所以，本系統(tǒng)采用了使用硬件進行溫度補償?shù)姆桨福捎肕AX6675串行模數(shù)轉換器對采集的數(shù)據(jù)進行處理，在進行溫度補償?shù)耐瑫r，也提供了信號量為12位分辨率的模數(shù)轉換，加強了與控制器數(shù)據(jù)通信的兼容性[3]。

嵌入式控制器采用Arduino開源硬件平臺，它使用AtmelAVR單片機為核心處理器，采用基于開放源代碼的軟硬件平臺，由于其功耗低、穩(wěn)定性強、開發(fā)周期短等特點，目前被廣泛應用于各個領域，越來越多的工程師選用Arduino平臺進行項目開發(fā)，截止到現(xiàn)在，Arduino開發(fā)團隊已開發(fā)出多種控制器。考慮到系統(tǒng)部署后期可能有更多數(shù)據(jù)采集點的加入，本系統(tǒng)選用的是以Atmega2560核心的ArduinoMega2560控制板（以下簡稱Mega2560），相對于普通的Arduino Uno，Meg2560可用的數(shù)字輸入輸出口多達到54個，插接傳感器擴展模塊后的數(shù)字I/O可以達到100多個，給系統(tǒng)的升級與擴展帶來極大的便利。

硬件連線如圖3所示，將K型熱電偶連接至MAX6675的接線座上，確保正負兩極連接無誤。分別將MAX6675對應用的電源、地線、SO、CS、SCK端連接至控制器 Mega256上的5V、GNU、數(shù)字口5、6、7。

圖3 控制器與MAX675連線圖

2.2以太網(wǎng)通信模塊

由于Mega2560無法直接連接到以太網(wǎng)絡，需要采用包含以太網(wǎng)的Ethernet模塊來實現(xiàn)，本文選用的是集成WIZnetW5100網(wǎng)絡芯片的擴展模塊。W5100 是一款高集成度的網(wǎng)絡通信芯片，全硬件實現(xiàn)標準的TCP/IP 協(xié)議棧、以太網(wǎng)介質(zhì)傳輸層（MAC）和物理層（PHY），具備了高穩(wěn)定、高性能和低功耗的特點，其數(shù)據(jù)傳輸速率最高可達100Mbps，由于TCP/IP協(xié)議均在商用與民用領域經(jīng)過了多年的應用和長足的發(fā)展，相關技術已經(jīng)十分成熟，資源豐富，極大的縮短了上位機與下位機程序的開發(fā)周期。

根據(jù)Mega2560的接口特點，本系統(tǒng)采了采用SPI總線方式與嵌入式控制器進行通信，與Ethernet模塊連接如圖4所示，其接口功能描述為SS：使能信號；SCLK：時鐘信號；MOSI：數(shù)據(jù)發(fā)送；MISO：數(shù)據(jù)接收。

圖4 SPI總線連接圖

由于Arduino系列的控制器均采用了相互兼容的可堆疊的標準化設計，Ethernet可以直接插接到Mega2560上不作任何配置，即可進行通信。W5100 內(nèi)部用于數(shù)據(jù)傳輸?shù)木彌_存儲器容量有 16KB，完全能夠滿足溫度監(jiān)控數(shù)據(jù)的本地緩存，使用W5100不需要考慮以太網(wǎng)底層的控制，采用常規(guī)的網(wǎng)絡編程方法即可實現(xiàn)與W5100的以太網(wǎng)通信。通過Mega256引腳圖（圖5）[3]可知，插接了Ethernet模塊后，SPI總線會占用Mega2560控制器的50～53號引腳，因此在使用的時候要注意避開。

圖5 Arduino Mega2560引腳圖

3 軟件設計

3.1 溫度采集點軟件設計

在以太網(wǎng)傳輸中，常用的傳輸控制協(xié)議（TCP）和用戶數(shù)據(jù)報協(xié)議（UDP）均可以完成下位機到上位機的數(shù)據(jù)傳輸，但TCP是基于連接的可靠傳輸協(xié)議，能進行錯誤監(jiān)測，鑒于工業(yè)現(xiàn)場對于數(shù)據(jù)可靠性的要求，所以本文的軟件設計中并未采用傳輸性能較高的UDP協(xié)議。因為，在辦公網(wǎng)絡中一個數(shù)據(jù)包的丟失可能是無關緊要的，但在工業(yè)現(xiàn)場監(jiān)控中，帶來的影響可能是巨大的。在Arduino標準庫中包含了Ethernet和SPI通信所需要的類與函數(shù)，在編寫程序的時候需要包含Ethernet.h、SPI.h和MAX6675.h這三個頭文件。下面是Arduino控制器的程序代碼。

#include “MAX6675.h”

#include “Ethernet.h”

#include “SPI.h”

MAX6675 mySenor（5，6，7）； //定義MAX6675類型的傳感器對象mySenor

EthernetServer server（8000）； //創(chuàng)建一個服務器對象，并設置網(wǎng)絡傳送端口為8000

Byte mac[]={0XDE，0XAD，0XBE，0XEF，0XEF，0XFE，0XED}；//設置Ethernet模塊MAC地址

IPAdress ip{192.168.1.110}； //設置Ethernet模塊IP地址

void setup（）{ //初始化各功能模塊

Serial.begin（9600）； //設置串口波特率

mySenor.setOffset（0）；

Ethernet.begin（mac，ip）；

Server.begin（）；

}

void loop（） //控制器循環(huán)操作

{

float sendData=0；

sendData=mySenor.getCelsius（）； //從傳感器對象讀取溫度數(shù)據(jù)

server.print（sendData）； //通過網(wǎng)絡發(fā)送數(shù)據(jù)

Serial.println（sendData）； //向串口發(fā)送數(shù)據(jù)，用于監(jiān)控調(diào)試

delay（500）； //設置延時

}

3.2 監(jiān)控層軟件設計

在工業(yè)現(xiàn)場的溫度監(jiān)測中，不僅要完成實時溫度數(shù)據(jù)的監(jiān)測同時也需要將生成的歷史數(shù)據(jù)進行分析，使用計算機豐富的計算資源以彌補嵌入式控制器的不足，使用虛擬儀器是一很好的選擇，虛擬儀器是將計算機和儀器技術接合的結晶[4]，同樣也是測試技術和計算機深層次結合的產(chǎn)物，它具有數(shù)據(jù)采集與信號分析的功能，本文的監(jiān)控層軟件設計采用了美國國家儀器公司（NI）設計的LabVIEW平臺，LabVIEW的系統(tǒng)的組成[2]如圖6所示。

圖6 LabVIEW系統(tǒng)組成

LabVIEW采用圖形化的G語言進行編程，設置TCP連接地址為下位機的IP地址為192.168.110，通信端口為8000，超時設置為60000毫秒，通過波形控件提供歷史溫度顯示，溫度顯示控件顯示實時溫度，監(jiān)控層的上位機程序代碼如圖7所示。

圖7 上位機程序框圖

4 結語

經(jīng)測試，本系統(tǒng)能準確的對工業(yè)現(xiàn)場的實時溫度進行顯示和歷史數(shù)據(jù)的顯示，如圖8所示，可得知當前溫度為200攝氏度，而在過去的500分鐘歷史記錄中發(fā)現(xiàn)系統(tǒng)出現(xiàn)了10次超過溫度警戒值800攝氏度的記錄。該設計充分利用了TCP/IP技術實現(xiàn)了對工業(yè)生產(chǎn)過程的監(jiān)控，進一步提高了各項監(jiān)督工業(yè)，有助于現(xiàn)場工程師及時采取應急處理等業(yè)務操作，需要注意的是以太網(wǎng)技術帶來的高數(shù)據(jù)高實時的同時，也產(chǎn)生了一些網(wǎng)絡安全問題，對于這一問題可通過網(wǎng)關采取包過濾的方法將內(nèi)部控制網(wǎng)絡與外部網(wǎng)絡系統(tǒng)分開[5]。綜上所述，隨著以太網(wǎng)技術在工業(yè)現(xiàn)場中的逐步推廣和應用，使生產(chǎn)現(xiàn)場數(shù)據(jù)與企業(yè)信息系統(tǒng)實現(xiàn)無縫對接，在即將到來的第四次工業(yè)革命中，全面實現(xiàn)“數(shù)字化工廠”這一宏偉目標[6]。

圖8 LabVIEW程序運行效果圖

參考文獻

[1]徐皚冬.工業(yè)以太網(wǎng)實時通信技術[J].信息與控制，2005，34（1）：60-64.

[2]沈金鑫，Arduino與LabVIEW開發(fā)實戰(zhàn)[M].北京：機械工業(yè)出版社，2014：182―187.

[3]開源硬件知識庫[OL].[2014-10-21]. http：///

[4]余成，謝東坡.網(wǎng)絡化測控技術與實現(xiàn)[M].北京：高等教育出版社，2009：194-198.

[5]孫德輝，史運濤，李志軍，楊楊編，網(wǎng)絡化控制系統(tǒng)[M].北京：國防工業(yè)出版社，2008：124―134.

[6]陳積明.工業(yè)以太網(wǎng)的研究現(xiàn)狀及展望[J].化工自動化入儀表，2001，28（6）：1-4.

收稿日期：2015-08-08

篇8

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

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

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

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

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

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

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

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

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

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

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

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

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

3 擁塞控制概述

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

3.1 基本概念

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

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

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

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

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

3.2 產(chǎn)生擁塞的原因

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

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

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

4 TCP擁塞控制機制

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

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

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

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

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

4.1 TCP擁塞控制的主要參數(shù)

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

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

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

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

4.2 TCP擁塞控制算法

4.2.1 Reno算法

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

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

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

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

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

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

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

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

4.2.2 NewReno算法

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

4.2.3 Sack算法

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

5 IP擁塞控制機制

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

5.1 IP擁塞控制算法

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

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

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

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

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

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

6 結論

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

參考文獻：

[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)網(wǎng)絡研究與實現(xiàn)[J].微電子學與計算機,2006,23(2):40-42

篇9

關鍵詞：IPv4；IPv6；HSRP；雙協(xié)議棧；平滑過渡

中圖分類號： TP368.6 文獻標識碼：A文章編號：1009-3044(2011)22-5340-03

1 IPv4/IPv6雙協(xié)議棧熱備冗余網(wǎng)絡在企業(yè)的應用前景

隨著1998年IETF正式公布了RFC2460標準，IPv6協(xié)議就正式誕生了。IPv6具有2的128次方個IP地址，是IPv4地址的2的96次方倍，解決了IPv4地址空間的枯竭的問題。

IPv6具有極強的安全性和可靠性，在擴展頭中增加了身份驗證頭AH和封裝安全性數(shù)據(jù)頭(ESP)，大大降低了數(shù)據(jù)被篡改的可能；IPv6增強了對流的支持，流標簽的引入為整合、優(yōu)化語音、視頻和數(shù)據(jù)網(wǎng)絡提供了更好的條件,同時高QoS特性使得數(shù)據(jù)傳輸質(zhì)量更加高效； IPv6還增強了對移動性主機的內(nèi)在支持等功能。

將IPv6協(xié)議優(yōu)秀的新特性和功能及早應用于企業(yè)，同時又能很好地兼容IPv4應用，增強企業(yè)核心網(wǎng)絡性能，采用IPv4/IPv6雙協(xié)議棧熱冗余模式建設企業(yè)核心網(wǎng)絡對企業(yè)計算機應用就有著非常重要的意義。

2 IPv6的新特性

2.1 全新的地址管理方案

地址管理方案中，首先改變了地址擁有方式，IPv4中，地址是用戶擁有，IPv6成了ISP擁有。其次IPv6還包括IPv4中沒有統(tǒng)一解決方案的地址解析協(xié)議(ABP)和可達性檢測等等。

IPv6還提供了地址自動配置機制，實現(xiàn)了主機的即插即用功能。為了保證主機地址的唯一性，IPv6定義了重復地址檢測過程，每當生成地址時，均反復執(zhí)行生成和檢測過程，直到得到唯一的地址。

2.2 報文的安全傳送

IPv6繼承了IPv4的報文傳送技術，在IPv6地址設計中增強了接口ID設置，這種ID設置提供了確認對方物理終端的技術條件，同時在其擴展頭中增加了身份驗證頭AH和封裝安全性數(shù)據(jù)頭(ESP)。

身份驗證頭AH首先為IP數(shù)據(jù)報提供強大的完整和身份驗證，為IP數(shù)據(jù)報承載內(nèi)容驗證數(shù)據(jù)和將實體與數(shù)據(jù)報內(nèi)容相鏈接；其次在完整中使用公共密鑰數(shù)字簽名算法，AH還可以為IP數(shù)據(jù)報提供不可抵賴服務以及通過使用順序號字段來防止重放攻擊。再有，AH還可以在隧道模式或透明模式下使用，既可用于為兩個節(jié)點間的簡單直接的數(shù)據(jù)報傳送提供身份驗證和保護，也可用于對發(fā)給安全性網(wǎng)關或由安全性網(wǎng)關發(fā)出的整個數(shù)據(jù)報流進行封裝。

封裝安全性數(shù)據(jù)頭通過加密提供數(shù)據(jù)報的機密性,通過使用公共密鑰加密對數(shù)據(jù)來源進行身份驗證,通過由AH提供的序列號機制提供對抗重放服務,以及通過使用安全性網(wǎng)關來提供有限的業(yè)務流機密性。

2.3 對流的支持

IPv6在設計時就充分考慮了對流的支持，改變了IPv4對流的處理即需要路由器判斷源和目的IP地址，又需要判斷傳輸控制協(xié)議或用戶數(shù)據(jù)報協(xié)議的端口號的復雜操作過程。在IP6的IP頭的格式里，有專門的20bit流標簽域。主機發(fā)送報文時，流標簽里填入相應的流編號，路由器收到流的第一個報文時，以流編號為索引建立處理上下文，流中的后續(xù)報文都按上下文處理，因此IPv6對流的處理方式要高效得多。

同時IPv6定義了流的優(yōu)先級，分別支持不同的業(yè)務需求。通過對語音、視頻、數(shù)據(jù)等不同類型的數(shù)據(jù)流進行合理、有效的優(yōu)先級設置，為企業(yè)建設和優(yōu)化語音、視頻、數(shù)據(jù)三網(wǎng)合一網(wǎng)絡平臺提供了遠優(yōu)于IPv4網(wǎng)絡的解決方案。

3 IPv6采用的關鍵技術

3.1 應用支持IPv6的技術

IPv6繼承了IPv4網(wǎng)絡中大量應用協(xié)議，比如：FTP、Telnet、SMTP、HTTP、NFS、DNS等，它們會在IPv6中繼續(xù)使用。只有少部分如：IPv4 socket接口需要改為IPv6 socket接口，而協(xié)議本身機制可以基本不做改動。

3.2 IPv6過度技術

為了保護在IPv4上的大量投資，IPv6應該能與IPv4的主機和路由器共存。逐步演進、逐步部署、地址兼容、降低費用等內(nèi)容便成了IPv6設計時的指導思想。為了實現(xiàn)這一目標，IPv6主要過度技術有十多種，而基本的過度技術就是雙協(xié)議棧和隧道。

1）雙協(xié)議棧技術

IPv4/IPv6雙協(xié)議棧技術，就是使IPv6網(wǎng)絡節(jié)點具有一個IPv4棧和一個IPv6棧，同時支持IPv4和IPv6協(xié)議。兩者都應用于相同的物理平臺，以及承載相同的傳輸層協(xié)議TCP或UDP。

2）隧道技術

隧道(Tunnel)是指將一種協(xié)議報頭封裝在另一種協(xié)議報頭中，這樣一種協(xié)議就可以通過另一種協(xié)議的封裝進行通信。IPv6隧道是將IPv6報頭封裝在IPv4報頭中，這樣IPv6協(xié)議包就可以穿越IPv4網(wǎng)絡進行通信。

4 組建具有熱備冗余功能的IPv4/IPv6雙協(xié)議棧網(wǎng)絡

4.1 IPv6網(wǎng)絡建設策略

IPv4到IPv6的升級切換不可能一蹴而就，必須循序漸進。因此在基于IPv6的特點以及公司目前IPv4網(wǎng)絡的應用情況，在建設IPv6網(wǎng)絡時做了以下幾點：不影響現(xiàn)有基于IPv4協(xié)議的所有網(wǎng)絡應用；保持現(xiàn)有網(wǎng)絡的層次結構；確保計算機終端同時對IPv4和IPv6網(wǎng)絡的訪問能力；滿足今后平滑實現(xiàn)IPv4網(wǎng)絡到IPv6網(wǎng)絡的過渡；通過IPv6網(wǎng)絡的建設，進一步提高企業(yè)核心網(wǎng)絡的性能。因此，IPv6網(wǎng)絡建設中采用了熱備冗余功能和IPv4/IPv6雙協(xié)議棧技術。

4.2 網(wǎng)絡拓撲

IPv6網(wǎng)絡核心建設完成后形成圖1所示的結構示意圖，核心交換機A與核心交換機B用兩對光纖連接實現(xiàn)熱備份互聯(lián)基礎，兩臺交換機與下一層交換機分別互聯(lián)，形成雙鏈路，在啟用HSRP及相關配置后實現(xiàn)雙機熱備路由功能。

配置IPv4/IPv6網(wǎng)絡需要完成如圖2所示步驟。

4.3 雙協(xié)議棧的啟用

為了實現(xiàn)IPv4/IPv6雙協(xié)議棧功能，在網(wǎng)絡接口設置中必須同時啟用兩種協(xié)議。現(xiàn)有交換機IPv4已經(jīng)啟用，啟用IPv6協(xié)議及配置節(jié)點地址步驟如下：

interface fastethernet 1/1

IPv6 enable //啟用IPv6協(xié)議

IPv6 address 2001:400:25:1::1/64//配置IPv6節(jié)點地址

4.4 路由實現(xiàn)

全局模式下IPv4使用IP routing啟用路由功能，IPv6則使用IPv6 unicast-routing啟用路由功能。IPv6是對IPv4的革新，盡管大多數(shù)IPv6的路由協(xié)議都需要重新設計或者開發(fā)，但IPv6路由協(xié)議相對IPv4只有很小的變化。在靜態(tài)路由方面與IPv4也基本相同，只需為節(jié)點配置地址并作為客戶機網(wǎng)關，即可實現(xiàn)網(wǎng)段間的路由。

全局模式下啟用IPv6路由及相關配置

IPv6 unicast-routing //打開ipv6單播路由功能

IPv6 dhcp pool test //新建一個IPv6的dhcp地址池test，供客戶機自動獲取使用

prefix-delegation pool test1 lifetime 1800 600

dns-server 2001:400:4:1::101//指定IPv6 dns服務器地址

4.5 Windows2003中IPv6 DNS配置

①安裝DNS服務及IPv6 DNS插件；

②配置IPv6 DNS

a、打開了DNS配置向導；

b、在導航窗格中, 單擊用于你的服務器在DNS服務器對象，用鼠標右鍵單擊服務器對象，然后單擊 配置DNS服務器以啟動配置DNS服務器向導，步驟見圖3。

4.6 IPv6客戶機配置

通常情況下IPv6客戶機在啟用IPv6協(xié)議后，地址會從最近的網(wǎng)絡節(jié)點自動獲取，無需用戶手動配置，但是對于像服務器這類需固定IP地址的則需手動配置，以便于訪問。以Windows Server 2003為例，步驟如下：

1）IPv6 協(xié)議棧的安裝

在“開始”―>“運行”處執(zhí)行IPv6 install命令

2）IPv6 地址設置

在“開始”―>“運行”處執(zhí)行netsh命令，進入系統(tǒng)網(wǎng)絡參數(shù)設置環(huán)境netsh>，執(zhí)行interface ipv6 add address “本地連接” 2001:d0a8:3207::e002命令設置地址；或者在 開始 -->“運行”處執(zhí)行 ipv6 adu 4/2001:d0a8:3207::e002。

3）IPv6 默認網(wǎng)關設置，在netsh>標識后輸入

interface ipv6 add route ::/0 “本地連接” 2001:d0a8:3207::e001 publish=yes命令即可；或者在在“開始”-->“運行”處執(zhí)行 IPv6 rtu ::/0 4/2001:d0a8:3207::e001。

4.7 IPv6網(wǎng)站的訪問

用戶在實際使用中，IPv4和IPv6同樣使用域名網(wǎng)址進行訪問，使用IP地址訪問時有所不同，IPv6協(xié)議需要使用帶中括弧方式來訪問,例如：[ 2001:d0a8:3207::e001]。

4.8 熱備份路由器協(xié)議配置

網(wǎng)絡核心采用熱備份路由器協(xié)議技術（HSRP：Hot Standby Router Protocol），系統(tǒng)中使用兩臺路由交換機滿足HSRP多臺路由器的條件，組成一個“熱備份組”，這個組形成一個虛擬路由器。在任一時刻，一個組內(nèi)只有一個路由器是活動的，并由它來轉發(fā)數(shù)據(jù)包，如果活動路由器發(fā)生了故障，將選擇備份路由器來替代活動路由器，但是在本網(wǎng)絡內(nèi)的主機看來，虛擬路由器沒有改變。所以主機仍然保持連接，沒有受到故障的影響，這樣就較好地解決了路由器切換的問題。配置步驟如圖4。

1）熱備份交換機通道配置

交換機A

interface Port-channel1 //創(chuàng)建一個捆綁通道組1

description HSRP_packet //描述該通道是傳遞hsrp包用

interface GigabitEthernet5/1

channel-group 1 mode on //將端口劃入捆綁接口Port-channel1

在交換機B中進行同理配置。

2）VLAN冗余組配置

交換機A

interface Vlan1//配置vlan 1接口

ip address 10.1.1.12 255.255.255.0 //配置本地Vlan1接口Ipv4地址

IPv6 enable

standby version 2//啟用版本2

standby 1 ip 10.1.1.1//設置vlan 1到熱備組1，同時設置vlan 1的ipv4網(wǎng)關

standby 1 priority 110 //在本交換機的優(yōu)先級110（默認100，優(yōu)先級高的為主用）

standby 1 preempt//打開熱備組1搶占功能

standby 1 track Port-channel1 //熱備組1通過捆綁接口Port-channel1實現(xiàn)雙機信息告知

standby 1 ipv6 2001:400:1:1::100/64 //啟用IPv6 HSRP協(xié)議

在交換機B中進行同理配置。

5 結束語

1）通過雙機熱備份路由器協(xié)議的使用，公司網(wǎng)絡穩(wěn)定性能得到很大提高，更好地滿足了目前公司數(shù)十套業(yè)務系統(tǒng)全天候不間斷的運行要求，很好地支持了公司的發(fā)展；

2）為公司正進行的全面信息化及電子商務的建設提供了高效、安全、可靠和無阻塞的信息處理網(wǎng)絡平臺；

3）通過對IPv6技術的應用，它擁有的全新網(wǎng)絡安全架構技術使企業(yè)業(yè)務數(shù)據(jù)的傳輸安全得到了進一步保證；

4）IPv6對流的充分支持，加快了企業(yè)對流業(yè)務應用系統(tǒng)的開發(fā)，為建設高效的企業(yè)語音、視頻、數(shù)據(jù)三網(wǎng)合一網(wǎng)絡平臺起到了重要作用；

5）該系統(tǒng)的成功實施為公司業(yè)務系統(tǒng)今后及早融入IPv6網(wǎng)絡環(huán)境打下了基礎，為公司ERP及電子商務系統(tǒng)更快、更好地融入新的網(wǎng)絡信息平臺做好了充分準備。

6）IPv6網(wǎng)站的建成，已成為國家IPv6應用試驗典范。

參考文獻：

[1] 張寵科,蘇偉.IPv6路由協(xié)議棧原理與技術[M].北京:北京郵電大學出版社,2006(7).

[2] 高發(fā)桂,郭學理,王路群.IPv6安全特性的分析與應用研究[J].計算機應用與軟件,2002(11).

[3] 杜治國,肖德琴,徐東風.基于雙棧技術的IPv6校園網(wǎng)絡設計[J].計算機工程與設計,2007(11).

篇10

【關鍵詞】TCP/IP；delphi6.0；SQLserver 2000

【Abstract】The designand implementation of LAN communication tool have been proposrd. The system was designed in delphi 6.0 and stored data in SQLserver 2000.The transmission form of TCP and UDP and C/S structure were used in the design.At last，the function just as user registration and login，the display and find between friends，the text chat，the voice and video chat were achived.

【Key words】TCP/IP；delphi6.0；SQLserver 2000

0 引言

隨著全球信息化進程的不斷發(fā)展，越來越多的企業(yè)使用局域網(wǎng)來管理各種事務。但隨著局域網(wǎng)的機器增多，軟件的應用對局域網(wǎng)的信息吞吐、處理能力的要求也越高。為解決上述矛盾，就有必要設計一個在局域網(wǎng)里的ICQ，通過該系統(tǒng)，進行文件傳輸，消息的，提高企業(yè)的工作效率。

1 需求分析

該系統(tǒng)基于TCP/IP網(wǎng)絡協(xié)議，采用C/S模式，服務器端與數(shù)據(jù)庫連接，客戶端安裝在不同電腦上可通過同一服務器實現(xiàn)數(shù)據(jù)通訊。實現(xiàn)的功能如下：

（1）用戶注冊，隨機分配號碼并填寫個人信息；

（2）用戶登入驗證并導出好友列表；

（3）能夠查找好友并認證后加為好友；

（4）文字聊天，聊天記錄保存；

（5）點對點文件傳輸功能；

（6）視頻語音捕獲與傳輸（視頻語音聊天功能）。

2 詳細設計

2.1 概要設計

本課題在研究和分析計算機TCP/IP網(wǎng)絡協(xié)議基礎上，在不同計算機之間實現(xiàn)數(shù)據(jù)通訊。采用TCP和UDP傳輸方式，編寫客戶端與服務器端網(wǎng)絡軟件。客戶向服務器發(fā)出服務請求，服務器作出應答響應，服務器監(jiān)聽客戶發(fā)出的請求，當客戶提出連接請求后，服務器作出應答，并為客戶提供相應的服務。

本系統(tǒng)前臺使用Delphi6.0進行設計，后臺運用Sql Server 2000進行數(shù)據(jù)管理。

2.2 方案設計

該即時通的工作過程如下：當服務器開啟時，用戶從客戶端登錄，通過TCP/IP網(wǎng)絡將輸入的帳號和密碼傳到服務器，服務器從數(shù)據(jù)庫中對應的數(shù)據(jù)表查找驗證，若驗證錯誤，返回錯誤提示信息；若驗證通過，則登錄QQ主頁面。在進入主頁面后，用戶可通過輸入對方QQ號查找其他用戶且加對方為好友。兩用戶可通過點對點通訊實現(xiàn)文字聊天，語音視頻聊天，文件傳輸?shù)取?/p>

2.3 系統(tǒng)數(shù)據(jù)表設計

本系統(tǒng)使用SQL Server 2000設計后臺數(shù)據(jù)庫，共設計了兩張數(shù)據(jù)表：用戶信息表和好友信息表。

用戶信息數(shù)據(jù)表用于儲存注冊用戶的信息，存儲的信息包括：用戶QQ號（主鍵）、用戶密碼、用戶昵稱、性別、是否在線（1為在線，0為不在）、用戶上線地址、國籍、省份、城市等。

好友信息數(shù)據(jù)表，主要用于添加用戶好友信息，用戶登錄時調(diào)用相關信息并顯示。存儲的信息包括：用戶QQ號、好友QQ號、好友是否在線、好友在線地址、好友昵稱。

2.4 詳細模塊設計及功能實現(xiàn)

客戶端包括七個模塊：

（1）登錄模塊：此模塊實現(xiàn)客戶端與服務器連接，用戶登錄時驗證身份，驗證通過則進入QQ主頁面模塊，并調(diào)取好友信息顯示。

（2）主頁面模塊：用戶在登錄模塊驗證身份通過后，從服務器調(diào)取好友信息，并在QQ主頁面上顯示。

（3）查找模塊：該模塊用于用戶查找好友，輸入對方帳號查找對方信息，并加為好友，與服務器連接并修改數(shù)據(jù)表的內(nèi)容，在主頁面上添加上新好友。

（4）文字聊天模塊：此模塊實現(xiàn)用戶間的點對點聊天，兩客戶端通過UDP連接，發(fā)送和接收文字信息，實現(xiàn)局域網(wǎng)文字聊天。

（5）文件傳輸模塊：此模塊實現(xiàn)兩客戶端點對點文件傳輸，圖片，文本文檔及壓縮包等均可傳輸。

（6）語音視頻聊天模塊：此模塊實現(xiàn)了語音和視頻的捕獲以及點對點傳輸功能。

服務器端根據(jù)功能要求可分為以下三個模塊：

（1）服務器監(jiān)聽模塊：用于回應客戶端請求，包括登錄回應，注冊回應，調(diào)用好友信息回應等。

（2）遠程截圖模塊：此模塊實現(xiàn)服務器端從上線的客戶端獲取IP地址后截取對方屏幕顯示。

（3）查詢模塊：此模塊實現(xiàn)服務器端訪問數(shù)據(jù)庫并查詢數(shù)據(jù)庫信息。分為綜合查詢和詳細查詢功能。

3 系統(tǒng)程序的總體設計與實現(xiàn)

本系統(tǒng)軟件采用模塊化結構，由用戶登錄程序、用戶注冊程序、好友信息顯示程序、好友查找程序、文字聊天程序、文件傳輸程序等子程序構成。其中，文件傳輸，語音視頻聊天模塊都具有獨立性，可在單獨設計后加入到整個系統(tǒng)中，其余各模塊間需要服務器客戶端相互連接同時調(diào)試才可實現(xiàn)。服務器端首先開啟運行，在和客戶端相互通訊實現(xiàn)基本功能。

4 結束語

本系統(tǒng)基于Delphi6.0和Sql Server 2000的運用，在研究和分析計算機TCP/IP網(wǎng)絡協(xié)議基礎上，實現(xiàn)不同計算機之間的數(shù)據(jù)通訊。采用C/S結構，實現(xiàn)在功能有：用戶的注冊和登錄，好友的顯示和查找，好友文字、語音視頻聊天，文件傳輸?shù)取?/p>

【參考文獻】