ip協議范文

時間:2023-03-21 01:09:13

導語:如何才能(neng)寫好一篇ip協議(yi),這就需要搜集整理更多的(de)資料和文(wen)獻,歡(huan)迎(ying)閱讀由公務員之家整理的(de)十篇范(fan)文(wen),供你借鑒。

ip協議

篇1

關鍵詞:路由技術 算法 Rip

1、IP路由算法

IP路(lu)(lu)(lu)由(you)算法可分(fen)為以下幾種:靜態和(he)動態、單路(lu)(lu)(lu)和(he)多(duo)路(lu)(lu)(lu)、平等和(he)分(fen)級、源路(lu)(lu)(lu)由(you)和(he)透明路(lu)(lu)(lu)由(you)、域(yu)內和(he)域(yu)間、鏈路(lu)(lu)(lu)狀態和(he)距離向量。

鏈路狀(zhuang)態(tai)算(suan)法發(fa)(fa)(fa)送(song)(song)(song)路由(you)(you)信(xin)(xin)息(xi)(xi)到(dao)互聯網上(shang)所有(you)的結點,然而對于每(mei)個路由(you)(you)器,僅發(fa)(fa)(fa)送(song)(song)(song)它(ta)的路由(you)(you)表中描述(shu)了其自身鏈路狀(zhuang)態(tai)的那一(yi)部分。距離(li)向量算(suan)法則要求每(mei)個路由(you)(you)器發(fa)(fa)(fa)送(song)(song)(song)其路由(you)(you)表全部或部分信(xin)(xin)息(xi)(xi),但僅發(fa)(fa)(fa)送(song)(song)(song)到(dao)鄰近結點上(shang)。從本質上(shang)來(lai)說(shuo),鏈路狀(zhuang)態(tai)算(suan)法將少量更新信(xin)(xin)息(xi)(xi)發(fa)(fa)(fa)送(song)(song)(song)至網絡各(ge)處,而距離(li)向量算(suan)法發(fa)(fa)(fa)送(song)(song)(song)大(da)量更新信(xin)(xin)息(xi)(xi)至鄰接路由(you)(you)器。

由(you)于鏈路(lu)(lu)(lu)(lu)狀(zhuang)態算(suan)法(fa)(fa)收(shou)斂(lian)更快,因(yin)此它在(zai)(zai)一(yi)定(ding)程度(du)上(shang)比距(ju)離(li)向量算(suan)法(fa)(fa)更不(bu)易產(chan)生(sheng)路(lu)(lu)(lu)(lu)由(you)循環。但(dan)另一(yi)方面,鏈路(lu)(lu)(lu)(lu)狀(zhuang)態算(suan)法(fa)(fa)要(yao)求比距(ju)離(li)向量算(suan)法(fa)(fa)有更強(qiang)的(de)(de)(de)CPU能(neng)(neng)力和更多的(de)(de)(de)內存空間,因(yin)此鏈路(lu)(lu)(lu)(lu)狀(zhuang)態算(suan)法(fa)(fa)將會在(zai)(zai)實現(xian)時顯得更昂貴一(yi)些(xie)。除了這些(xie)區別,兩種(zhong)算(suan)法(fa)(fa)在(zai)(zai)大多數(shu)環境(jing)下都能(neng)(neng)很(hen)好地運行。路(lu)(lu)(lu)(lu)由(you)算(suan)法(fa)(fa)使用了許多種(zhong)不(bu)同的(de)(de)(de)度(du)量標準去決定(ding)最佳路(lu)(lu)(lu)(lu)徑。復(fu)(fu)雜的(de)(de)(de)路(lu)(lu)(lu)(lu)由(you)算(suan)法(fa)(fa)可(ke)能(neng)(neng)采用多種(zhong)度(du)量來選擇路(lu)(lu)(lu)(lu)由(you),通過一(yi)定(ding)的(de)(de)(de)加權運算(suan),將它們(men)合并為單個的(de)(de)(de)復(fu)(fu)合度(du)量、再(zai)填入路(lu)(lu)(lu)(lu)由(you)表中,作為尋(xun)徑的(de)(de)(de)標準。

2、RIP路由協議的原理分析

RIP是(shi)基于(yu)距(ju)離矢量的(de)(de)(de)路(lu)(lu)由(you)協(xie)議。運行RIP的(de)(de)(de)路(lu)(lu)由(you)器維持一(yi)個(ge)到(dao)網(wang)絡中可能目的(de)(de)(de)地的(de)(de)(de)路(lu)(lu)由(you)表(biao),路(lu)(lu)由(you)表(biao)包(bao)含目的(de)(de)(de)地址和(he)開銷等(deng)信(xin)息。具體的(de)(de)(de)說,RIP協(xie)議主要包(bao)括以下幾個(ge)方(fang)面的(de)(de)(de)內容(rong)。

2.1計算距離矢(shi)量

距離矢(shi)量(liang)(liang)路(lu)(lu)由協議利用度(du)(du)量(liang)(liang)來(lai)(lai)跟蹤它(ta)和(he)所有已知目的(de)(de)地間(jian)的(de)(de)距離。這種(zhong)距離信息使路(lu)(lu)由器可以找出(chu)到位(wei)于非近鄰獨立系統(tong)中(zhong)(zhong)的(de)(de)目的(de)(de)地最有效的(de)(de)下(xia)一(yi)跳(tiao)。在(zai)RFC-1058中(zhong)(zhong),有一(yi)個唯一(yi)的(de)(de)距離矢(shi)量(liang)(liang)單位(wei),即跳(tiao)數。在(zai)RIP中(zhong)(zhong)默(mo)認的(de)(de)跳(tiao)數度(du)(du)量(liang)(liang)被置為(wei)1,這些距離度(du)(du)量(liang)(liang)用來(lai)(lai)構造路(lu)(lu)由表(biao)。路(lu)(lu)由表(biao)識別出(chu)數據包,以最小開銷到達(da)目的(de)(de)地所要采(cai)取(qu)的(de)(de)下(xia)一(yi)跳(tiao)。

2.2更新路由表

RIP只記錄(lu)每(mei)(mei)個(ge)(ge)(ge)目的(de)地址的(de)一條(tiao)路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you),這一事實要求(qiu)RIP經(jing)常保持其路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)表的(de)完整性。它通(tong)過要求(qiu)所有(you)活(huo)躍(yue)的(de)RIP路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)器(qi)(qi)周期(qi)性的(de)向相鄰RIP路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)器(qi)(qi)廣播它們(men)路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)表的(de)內容(rong)。通(tong)常,RIP依賴3個(ge)(ge)(ge)計時(shi)器(qi)(qi)來(lai)維護(hu)路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)表:即更(geng)新(xin)計時(shi)器(qi)(qi)、路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)暫休(xiu)計時(shi)器(qi)(qi)、路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)清(qing)楚計時(shi)器(qi)(qi)。更(geng)新(xin)計時(shi)器(qi)(qi)用來(lai)激發(fa)節(jie)點(dian)路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)表的(de)更(geng)新(xin)。每(mei)(mei)個(ge)(ge)(ge)RIP節(jie)點(dian)只有(you)一個(ge)(ge)(ge)更(geng)新(xin)計時(shi)器(qi)(qi)。然(ran)而,路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)暫休(xiu)和路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)清(qing)除(chu)(chu)計時(shi)器(qi)(qi)則是每(mei)(mei)條(tiao)路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)都有(you)一個(ge)(ge)(ge)。因此(ci),每(mei)(mei)個(ge)(ge)(ge)路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)表條(tiao)目中都有(you)一個(ge)(ge)(ge)不同(tong)的(de)暫休(xiu)和路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)清(qing)除(chu)(chu)計時(shi)器(qi)(qi)。總(zong)之,這些計時(shi)器(qi)(qi)使(shi)RIP節(jie)點(dian)能維護(hu)它們(men)路(lu)(lu)(lu)(lu)(lu)(lu)由(you)(you)的(de)完善性,并根據所用的(de)時(shi)間進行激活(huo),從而恢復(fu)網絡故障。

2.3激活路(lu)由更新

大(da)約每(mei)30s激活一次(ci)路由更新(xin)。更新(xin)路由器用(yong)來跟蹤這(zhe)個(ge)時間量。當(dang)這(zhe)個(ge)時間量結束時,RIP發送一系列(lie)幀(zhen)來維護整個(ge)路由表。這(zhe)些(xie)幀(zhen)廣播到(dao)每(mei)個(ge)鄰節點。因此,每(mei)個(ge)RIP路由器大(da)約每(mei)30s就要接收來自鄰RIP節點的更新(xin)。

2.4識別無效路(lu)由

路(lu)(lu)(lu)(lu)由(you)(you)(you)變(bian)得無效(xiao)(xiao)的(de)(de)兩(liang)種情(qing)況:其一,路(lu)(lu)(lu)(lu)由(you)(you)(you)到期;其二,路(lu)(lu)(lu)(lu)由(you)(you)(you)器(qi)可能(neng)通(tong)知某個路(lu)(lu)(lu)(lu)由(you)(you)(you)器(qi)某條(tiao)(tiao)路(lu)(lu)(lu)(lu)由(you)(you)(you)是(shi)(shi)不可用的(de)(de)。在這(zhe)兩(liang)種情(qing)況下,RIP路(lu)(lu)(lu)(lu)由(you)(you)(you)器(qi)都(dou)需要改(gai)變(bian)它的(de)(de)路(lu)(lu)(lu)(lu)由(you)(you)(you)表(biao)(biao),來反(fan)映(ying)給定路(lu)(lu)(lu)(lu)由(you)(you)(you)的(de)(de)不可用性。假如(ru)路(lu)(lu)(lu)(lu)由(you)(you)(you)器(qi)在給定的(de)(de)時間內(nei)沒有(you)接收(shou)到更新(xin)某路(lu)(lu)(lu)(lu)由(you)(you)(you)的(de)(de)信息,該路(lu)(lu)(lu)(lu)由(you)(you)(you)可能(neng)到期。路(lu)(lu)(lu)(lu)由(you)(you)(you)暫休定時器(qi)常設(she)成(cheng)180s,當路(lu)(lu)(lu)(lu)由(you)(you)(you)激活或更新(xin)時,該定時器(qi)初始化。假如(ru)180s過去了,路(lu)(lu)(lu)(lu)由(you)(you)(you)器(qi)還沒有(you)接到更新(xin)那(nei)條(tiao)(tiao)路(lu)(lu)(lu)(lu)由(you)(you)(you)的(de)(de)信息,RIP路(lu)(lu)(lu)(lu)由(you)(you)(you)器(qi)就認為目的(de)(de)IP地址不再可達。因此路(lu)(lu)(lu)(lu)由(you)(you)(you)器(qi)把(ba)表(biao)(biao)中那(nei)條(tiao)(tiao)路(lu)(lu)(lu)(lu)由(you)(you)(you)項(xiang)標(biao)成(cheng)無效(xiao)(xiao)。收(shou)到路(lu)(lu)(lu)(lu)由(you)(you)(you)新(xin)近無效(xiao)(xiao)通(tong)知的(de)(de)鄰節點利用該信息來更新(xin)它們的(de)(de)路(lu)(lu)(lu)(lu)由(you)(you)(you)表(biao)(biao)。這(zhe)是(shi)(shi)路(lu)(lu)(lu)(lu)由(you)(you)(you)表(biao)(biao)中路(lu)(lu)(lu)(lu)由(you)(you)(you)變(bian)得無效(xiao)(xiao)的(de)(de)第(di)2種方法。無效(xiao)(xiao)路(lu)(lu)(lu)(lu)由(you)(you)(you)表(biao)(biao)項(xiang)不會自動的(de)(de)從(cong)路(lu)(lu)(lu)(lu)由(you)(you)(you)表(biao)(biao)中清(qing)除(chu);相反(fan),那(nei)條(tiao)(tiao)無效(xiao)(xiao)項(xiang)繼續在路(lu)(lu)(lu)(lu)由(you)(you)(you)表(biao)(biao)中保留很短一段時間。

2.5清除無效(xiao)路由

當路(lu)(lu)由(you)(you)器認識到某條路(lu)(lu)由(you)(you)無效時(shi)(shi),就初始(shi)化一個秒計時(shi)(shi)器,負責(ze)路(lu)(lu)由(you)(you)清除(chu)(chu)倒計時(shi)(shi),這(zhe)(zhe)一計時(shi)(shi)稱(cheng)為路(lu)(lu)由(you)(you)清除(chu)(chu)計時(shi)(shi)器。當路(lu)(lu)由(you)(you)清除(chu)(chu)計時(shi)(shi)器結束時(shi)(shi),路(lu)(lu)由(you)(you)仍未被收到,這(zhe)(zhe)一路(lu)(lu)由(you)(you)就從路(lu)(lu)由(you)(you)表(biao)中清除(chu)(chu)。這(zhe)(zhe)些計時(shi)(shi)器是RIP恢復網(wang)絡故障能(neng)力中絕對重(zhong)要的(de)。

2.6編址方案

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

2.7路由到網關

很多實際網(wang)(wang)絡(luo)(luo)(luo)中,并不(bu)要計算(suan)到(dao)每個單個主(zhu)機(ji)的(de)路(lu)由(you)(you)。特別是在大型網(wang)(wang)絡(luo)(luo)(luo)中,這(zhe)會使(shi)路(lu)由(you)(you)表(biao)膨脹(zhang),從而(er)使(shi)整個網(wang)(wang)絡(luo)(luo)(luo)的(de)路(lu)由(you)(you)工作繁重。因此在實際網(wang)(wang)絡(luo)(luo)(luo)中,幾乎總是概括路(lu)由(you)(you),而(er)不(bu)是指出每個可能(neng)(neng)目的(de)地(di)。假如一(yi)個給(gei)定(ding)的(de)網(wang)(wang)絡(luo)(luo)(luo)(或子網(wang)(wang))上,每個主(zhu)機(ji)都能(neng)(neng)通過網(wang)(wang)關(guan)到(dao)達的(de)話,這(zhe)時(shi)(shi)路(lu)由(you)(you)表(biao)只需定(ding)義那(nei)個網(wang)(wang)關(guan)為下一(yi)條IP地(di)址就可以了(le)。所有發往那(nei)個網(wang)(wang)絡(luo)(luo)(luo)或子網(wang)(wang)上的(de)數據包將發送給(gei)那(nei)個網(wang)(wang)關(guan),這(zhe)時(shi)(shi)網(wang)(wang)關(guan)就承擔了(le)把它發送到(dao)最終目的(de)地(di)的(de)任務。

3、RIP協議(yi)處理過程(cheng)

RIP協議的(de)運行過(guo)程(cheng)就是(shi)路由(you)器軟件對消息輸(shu)(shu)入(ru)和輸(shu)(shu)出(chu)處理過(guo)程(cheng),其輸(shu)(shu)入(ru)和輸(shu)(shu)出(chu)處理大致(zhi)如下所描述。

輸入(ru)處(chu)(chu)(chu)理(li)(li)(li):主(zhu)要是(shi)指路由器協議(yi)軟件對在520號UDP端(duan)口收(shou)到(dao)的數據報進行(xing)的處(chu)(chu)(chu)理(li)(li)(li)。對于輸入(ru)處(chu)(chu)(chu)理(li)(li)(li),首先(xian)必須先(xian)作(zuo)一定格(ge)式(shi)檢查,檢查通過后,再分(fen)別對幾(ji)種輸入(ru)消息(xi)做相(xiang)應的處(chu)(chu)(chu)理(li)(li)(li)。

請(qing)(qing)(qing)(qing)(qing)求(qiu)報(bao)(bao)文:路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)器在開始運行時,為(wei)了從鄰機處(chu)(chu)獲取(qu)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)表(biao)的(de)(de)初始值,通常會發(fa)一(yi)個(ge)請(qing)(qing)(qing)(qing)(qing)求(qiu)。報(bao)(bao)文的(de)(de)Command字(zi)(zi)段為(wei)。對(dui)(dui)所(suo)有(you)(you)(you)或部(bu)分(fen)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)表(biao)的(de)(de)請(qing)(qing)(qing)(qing)(qing)求(qiu),一(yi)般以廣播形(xing)式(shi)從520號UDP端口發(fa)送。實際中,這種請(qing)(qing)(qing)(qing)(qing)求(qiu)有(you)(you)(you)兩種格式(shi):請(qing)(qing)(qing)(qing)(qing)求(qiu)獲取(qu)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)表(biao)的(de)(de)全部(bu)和請(qing)(qing)(qing)(qing)(qing)求(qiu)獲取(qu)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)表(biao)的(de)(de)某(mou)些特(te)定路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)項(xiang)(xiang)(xiang)。路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)軟件先逐(zhu)個(ge)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)項(xiang)(xiang)(xiang)地處(chu)(chu)理請(qing)(qing)(qing)(qing)(qing)求(qiu),如(ru)(ru)果沒有(you)(you)(you)任何(he)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)項(xiang)(xiang)(xiang),也就沒有(you)(you)(you)響(xiang)應;如(ru)(ru)果請(qing)(qing)(qing)(qing)(qing)求(qiu)中恰好(hao)只有(you)(you)(you)一(yi)個(ge)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)項(xiang)(xiang)(xiang),并且addressfamilyidentifier為(wei)0,metric為(wei)16,則(ze)(ze)表(biao)示需要(yao)接收方發(fa)送所(suo)有(you)(you)(you)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)表(biao)的(de)(de)請(qing)(qing)(qing)(qing)(qing)求(qiu);除此(ci)之(zhi)外,則(ze)(ze)是要(yao)求(qiu)部(bu)分(fen)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you),處(chu)(chu)理很簡單(dan),沿著(zhu)請(qing)(qing)(qing)(qing)(qing)求(qiu)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)項(xiang)(xiang)(xiang)表(biao)一(yi)個(ge)一(yi)個(ge)看,對(dui)(dui)于(yu)(yu)每個(ge)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)項(xiang)(xiang)(xiang),在主機路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)數(shu)據庫中查找,如(ru)(ru)果找到,則(ze)(ze)將(jiang)該路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)的(de)(de)metric值填入數(shu)據報(bao)(bao)的(de)(de)metric字(zi)(zi)段,如(ru)(ru)果沒有(you)(you)(you),則(ze)(ze)向其(qi)中填16。一(yi)旦所(suo)有(you)(you)(you)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)項(xiang)(xiang)(xiang)均(jun)已(yi)處(chu)(chu)理,將(jiang)command字(zi)(zi)段設為(wei)響(xiang)應,并將(jiang)該數(shu)據報(bao)(bao)發(fa)回(hui)其(qi)來(lai)自的(de)(de)端口。根據請(qing)(qing)(qing)(qing)(qing)求(qiu)是否(fou)關(guan)(guan)于(yu)(yu)指定的(de)(de)一(yi)批(pi)目的(de)(de)地,還(huan)是關(guan)(guan)于(yu)(yu)整個(ge)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)表(biao),處(chu)(chu)理有(you)(you)(you)所(suo)不同。如(ru)(ru)果關(guan)(guan)于(yu)(yu)整個(ge)路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)表(biao),輸出作普通的(de)(de)處(chu)(chu)理即可(ke),包括水(shui)平(ping)分(fen)割(ge)和子網隱藏,因此(ci)來(lai)自路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)表(biao)的(de)(de)某(mou)些路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)項(xiang)(xiang)(xiang)將(jiang)被隱藏;如(ru)(ru)果是指定路(lu)(lu)(lu)(lu)(lu)(lu)(lu)由(you)項(xiang)(xiang)(xiang),則(ze)(ze)將(jiang)查找結果返回(hui),不作水(shui)平(ping)分(fen)割(ge),如(ru)(ru)果需要(yao)還(huan)要(yao)返回(hui)子網信息。

響應(ying)報文:因(yin)(yin)為指定查詢(xun)、路(lu)由修改等(deng)原因(yin)(yin)而收(shou)到響應(ying)。不論收(shou)到什(shen)么(me)樣的(de)響應(ying),RIP處理程(cheng)序就開始更新(xin)它的(de)路(lu)由表。

輸(shu)出處(chu)理(li):用(yong)于產生(sheng)包含全部或(huo)(huo)部分路(lu)由(you)(you)表的響(xiang)應(ying)信(xin)息的處(chu)理(li),可能由(you)(you)于輸(shu)入進程發現請(qing)求(qiu)或(huo)(huo)路(lu)由(you)(you)修(xiu)改而觸(chu)發。響(xiang)應(ying)請(qing)求(qiu)產生(sheng)的輸(shu)出可以直接按需(xu)工作(zuo),而觸(chu)發的修(xiu)改因為兩個方面需(xu)要處(chu)理(li)。

首先,觸(chu)(chu)發(fa)(fa)(fa)(fa)的(de)(de)修(xiu)(xiu)(xiu)(xiu)(xiu)改(gai)(gai)(gai)在(zai)容量有(you)(you)限或(huo)有(you)(you)許多路(lu)由(you)(you)器的(de)(de)網絡(luo)上可(ke)能導(dao)致格外大的(de)(de)負(fu)載,因(yin)此協(xie)議要求實(shi)現(xian)方在(zai)限制觸(chu)(chu)發(fa)(fa)(fa)(fa)式(shi)修(xiu)(xiu)(xiu)(xiu)(xiu)改(gai)(gai)(gai)出現(xian)的(de)(de)頻率(lv)上采取一(yi)定(ding)(ding)(ding)的(de)(de)措(cuo)施,觸(chu)(chu)發(fa)(fa)(fa)(fa)式(shi)修(xiu)(xiu)(xiu)(xiu)(xiu)改(gai)(gai)(gai)發(fa)(fa)(fa)(fa)送后,需(xu)要隨機地(di)將一(yi)個(ge)定(ding)(ding)(ding)時(shi)器設(she)置成(cheng)1到5秒(miao),如果在(zai)定(ding)(ding)(ding)時(shi)器超(chao)時(shi)前發(fa)(fa)(fa)(fa)生其(qi)它修(xiu)(xiu)(xiu)(xiu)(xiu)改(gai)(gai)(gai),需(xu)要到定(ding)(ding)(ding)時(shi)器超(chao)時(shi)才觸(chu)(chu)發(fa)(fa)(fa)(fa)其(qi)中之一(yi),然(ran)后定(ding)(ding)(ding)時(shi)器再隨機地(di)設(she)置成(cheng)1到5秒(miao),觸(chu)(chu)發(fa)(fa)(fa)(fa)式(shi)修(xiu)(xiu)(xiu)(xiu)(xiu)改(gai)(gai)(gai)可(ke)能被一(yi)般(ban)修(xiu)(xiu)(xiu)(xiu)(xiu)改(gai)(gai)(gai)所禁止;另外,觸(chu)(chu)發(fa)(fa)(fa)(fa)式(shi)修(xiu)(xiu)(xiu)(xiu)(xiu)改(gai)(gai)(gai)可(ke)能不必包括(kuo)(kuo)整個(ge)路(lu)由(you)(you)表,原則(ze)上說,只有(you)(you)改(gai)(gai)(gai)變過的(de)(de)路(lu)由(you)(you)才需(xu)要包括(kuo)(kuo),作為觸(chu)(chu)發(fa)(fa)(fa)(fa)式(shi)修(xiu)(xiu)(xiu)(xiu)(xiu)改(gai)(gai)(gai)一(yi)部分(fen)的(de)(de)信(xin)息至少包括(kuo)(kuo)設(she)置了路(lu)由(you)(you)修(xiu)(xiu)(xiu)(xiu)(xiu)改(gai)(gai)(gai)標(biao)志的(de)(de)路(lu)由(you)(you),也可(ke)以包括(kuo)(kuo)附加路(lu)由(you)(you)和全(quan)部路(lu)由(you)(you)。如果完整的(de)(de)修(xiu)(xiu)(xiu)(xiu)(xiu)改(gai)(gai)(gai)需(xu)要多個(ge)數據報,則(ze)發(fa)(fa)(fa)(fa)送全(quan)部路(lu)由(you)(you)極有(you)(you)可(ke)能被打(da)斷;而(er)觸(chu)(chu)發(fa)(fa)(fa)(fa)式(shi)修(xiu)(xiu)(xiu)(xiu)(xiu)改(gai)(gai)(gai)處理時(shi),需(xu)要產生每(mei)個(ge)直連網絡(luo)的(de)(de)信(xin)息。產生觸(chu)(chu)發(fa)(fa)(fa)(fa)式(shi)修(xiu)(xiu)(xiu)(xiu)(xiu)改(gai)(gai)(gai)或(huo)一(yi)般(ban)修(xiu)(xiu)(xiu)(xiu)(xiu)改(gai)(gai)(gai)時(shi),都需(xu)要進行(xing)水平(ping)分(fen)割操作。

參考文獻

篇2

【關鍵詞】 IP協議; IPv6; IPv4

物聯(lian)(lian)(lian)網(wang)(wang)的(de)(de)(de)本質是網(wang)(wang)絡(luo)間交(jiao)互作用(yong)(yong)(yong),但(dan)是,互聯(lian)(lian)(lian)互通是物聯(lian)(lian)(lian)網(wang)(wang)交(jiao)互作用(yong)(yong)(yong)的(de)(de)(de)前提條件(jian)。由于物理世界中(zhong)物件(jian)數量難以計數,物的(de)(de)(de)形態與(yu)(yu)性質又是千變萬(wan)化、千差萬(wan)別,如何通過網(wang)(wang)絡(luo)把(ba)這些千奇(qi)百怪的(de)(de)(de)物件(jian)不但(dan)能(neng)夠聯(lian)(lian)(lian)系起(qi)來,保持各自(zi)的(de)(de)(de)性質與(yu)(yu)狀態,而且(qie)將來能(neng)夠在網(wang)(wang)絡(luo)智能(neng)控制(zhi)下交(jiao)互作用(yong)(yong)(yong),這就是物聯(lian)(lian)(lian)網(wang)(wang)建(jian)設中(zhong)必須考慮與(yu)(yu)建(jian)設的(de)(de)(de)標準問題。但(dan)是,隨著(zhu)近30年互聯(lian)(lian)(lian)網(wang)(wang)的(de)(de)(de)蓬勃發(fa)(fa)展,特別是物聯(lian)(lian)(lian)網(wang)(wang)的(de)(de)(de)發(fa)(fa)展開(kai)始受到網(wang)(wang)絡(luo)IP地(di)址(zhi)的(de)(de)(de)限制(zhi)。有資料顯(xian)示全球IPv4地(di)址(zhi)可能(neng)在很短時間內即將消耗殆(dai)盡,地(di)址(zhi)空間的(de)(de)(de)不足(zu)必將影(ying)響互聯(lian)(lian)(lian)網(wang)(wang)的(de)(de)(de)進一步發(fa)(fa)展。網(wang)(wang)絡(luo)IP地(di)址(zhi)不足(zu),嚴重地(di)制(zhi)約了(le)我國(guo)及(ji)其他國(guo)家互聯(lian)(lian)(lian)網(wang)(wang)的(de)(de)(de)應(ying)用(yong)(yong)(yong)和發(fa)(fa)展。

基于這個背景(jing),論(lun)文主要介紹企(qi)業(ye)在建(jian)設(she)物(wu)聯網過(guo)程(cheng)中應該(gai)如何(he)選(xuan)擇IP協議的(de)相關問題,特別是IPv6對(dui)IPv4取代的(de)必然性以及企(qi)業(ye)物(wu)聯網建(jian)設(she)中應用IPv6應該(gai)注意的(de)問題。

一、因(yin)特網協議IP(Internet Protocol,IP)的發展歷程

互聯網(wang)(wang)(wang)建(jian)設的(de)終(zhong)極(ji)目標是(shi):網(wang)(wang)(wang)絡(luo)是(shi)中立和無控制的(de),任何人都沒有決(jue)定權;網(wang)(wang)(wang)絡(luo)的(de)應用是(shi)無關(guan)的(de),網(wang)(wang)(wang)絡(luo)的(de)任務(wu)就是(shi)如何更好地(di)傳輸數據(ju)報。因此,要(yao)建(jian)立一(yi)個(ge)(ge)可以(yi)無縫鏈接(jie)到(dao)其他網(wang)(wang)(wang)絡(luo)的(de)系統和如何設計一(yi)個(ge)(ge)面向(xiang)未來的(de)網(wang)(wang)(wang)絡(luo),就需要(yao)一(yi)個(ge)(ge)大家都接(jie)受的(de)網(wang)(wang)(wang)絡(luo)協議。這個(ge)(ge)協議就叫因特網(wang)(wang)(wang)協議,也叫IP協議產生的(de)前提條(tiao)件,也是(shi)IP協議的(de)重要(yao)作(zuo)用。

IP協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)最(zui)早形成于(yu)美(mei)國國防部高級研究(jiu)項目局(ju)資(zi)助的(de)工程(cheng)所(suo)開發的(de)協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)(叫1822協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)),在1970年為網(wang)絡控制(zhi)(zhi)協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)(Network Control Protocol,NCP)所(suo)取代,NCP協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)的(de)目的(de)是(shi)通(tong)過(guo)接(jie)口(kou)消息(xi)處理機(ji)(Interface Message Processor,IMP),現在也(ye)稱(cheng)為智能(neng)物件的(de)路由器,把網(wang)絡上(shang)的(de)各個(ge)(ge)站點聯起來。Vint Cerf和(he)Robert Kahn后來設(she)計網(wang)絡傳(chuan)輸(shu)(shu)控制(zhi)(zhi)協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)TCP(Transport Control Protocol,TCP)來取代網(wang)絡控制(zhi)(zhi)協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)NCP,由于(yu)兩者(zhe)沒有分開,就統稱(cheng)TCP/IP。在因(yin)(yin)特網(wang)協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)(也(ye)叫IP協(xie)(xie)(xie)(xie)議(yi)(yi)(yi))里(li),使用(yong)最(zui)為廣(guang)泛的(de)兩個(ge)(ge)協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)是(shi)傳(chuan)輸(shu)(shu)協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)TCP和(he)用(yong)戶(hu)數(shu)(shu)(shu)(shu)據(ju)(ju)報(bao)協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)UDP(User Datagram Protocol,UDP)。傳(chuan)輸(shu)(shu)協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)位于(yu)IP協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)之上(shang),為應用(yong)提(ti)(ti)供一(yi)種無(wu)須直(zhi)接(jie)與IP層(ceng)交互的(de)通(tong)信機(ji)制(zhi)(zhi)。應用(yong)程(cheng)序(xu)并不(bu)直(zhi)接(jie)使用(yong)IP,而是(shi)通(tong)過(guo)傳(chuan)輸(shu)(shu)協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)相(xiang)互通(tong)信。由于(yu)下層(ceng)IP網(wang)絡盡最(zui)大可能(neng)傳(chuan)遞數(shu)(shu)(shu)(shu)據(ju)(ju)報(bao),但無(wu)法保證(zheng)數(shu)(shu)(shu)(shu)據(ju)(ju)報(bao)一(yi)定可以到(dao)達目的(de)地,也(ye)無(wu)法保證(zheng)數(shu)(shu)(shu)(shu)據(ju)(ju)報(bao)的(de)交付順(shun)序(xu)和(he)發送時(shi)的(de)順(shun)序(xu)相(xiang)同(tong),因(yin)(yin)此,用(yong)戶(hu)數(shu)(shu)(shu)(shu)據(ju)(ju)報(bao)協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)UDP在IP層(ceng)之上(shang)提(ti)(ti)供了一(yi)個(ge)(ge)附加(jia)層(ceng)來解決前面的(de)問(wen)題(ti)。IP使用(yong)地址標(biao)(biao)識因(yin)(yin)特網(wang)中的(de)主機(ji),UDP使用(yong)端(duan)口(kou)標(biao)(biao)識主機(ji)的(de)每一(yi)個(ge)(ge)進(jin)程(cheng)。端(duan)口(kou)是(shi)一(yi)個(ge)(ge)16bit的(de)數(shu)(shu)(shu)(shu)值,用(yong)來區(qu)分每個(ge)(ge)端(duan)點不(bu)同(tong)的(de)發送者(zhe)和(he)接(jie)收(shou)者(zhe)。用(yong)戶(hu)數(shu)(shu)(shu)(shu)據(ju)(ju)報(bao)協(xie)(xie)(xie)(xie)議(yi)(yi)(yi)UDP提(ti)(ti)供一(yi)種盡力而為的(de)傳(chuan)送服(fu)務。

IPv4(TCP第4版(ban))是(shi)在1982年設計(ji),廣(guang)泛并成(cheng)功地部(bu)署到(dao)全世界大(da)量公用網(wang)絡和私有網(wang)絡中(zhong)的(de)(de)數以億計(ji)的(de)(de)主(zhu)機和路由器上。IPv6(TCP第6版(ban))的(de)(de)發(fa)展是(shi)從1992年開始的(de)(de),由IETF設計(ji)的(de)(de)下一代(dai)互聯網(wang)協議(yi),目(mu)的(de)(de)是(shi)取代(dai)現有的(de)(de)互聯網(wang)協議(yi)第四版(ban)(IPV4)。經過(guo)了(le)十(shi)幾年的(de)(de)發(fa)展,IPv6的(de)(de)標準體系(xi)已(yi)經基本完善,在這個過(guo)程中(zhong),IPv6逐步優化(hua)了(le)協議(yi)體系(xi)結構,為業務(wu)發(fa)展創(chuang)造了(le)機會。

隨著物(wu)聯網(wang)建設的(de)(de)發(fa)展(zhan)(zhan),許多客觀世界中(zhong)(zhong)的(de)(de)物(wu)要(yao)通(tong)過智(zhi)能(neng)物(wu)件經過網(wang)絡(luo)聯系并能(neng)夠交互起來。這(zhe)就需要(yao)IP協議能(neng)夠唯一(yi)識別(bie)并有效(xiao)地把智(zhi)能(neng)物(wu)件聯系起來。因此,一(yi)下子擴充了的(de)(de)網(wang)絡(luo)地址及其網(wang)絡(luo)操作(zuo)發(fa)展(zhan)(zhan)中(zhong)(zhong)互通(tong)性、可擴展(zhan)(zhan)性、架構的(de)(de)穩(wen)定性和普遍性受(shou)到人(ren)們(men)的(de)(de)重視。

二(er)、IPv6對IPv4取代(dai):物聯網發展的必然

IPv4協議已經使用了30多年,不可否(fou)認,IPv4在因(yin)特(te)網的(de)(de)發(fa)展(zhan)進程中(zhong)起到了舉足輕重的(de)(de)作用。甚至(zhi)今(jin)天的(de)(de)因(yin)特(te)網中(zhong)絕大多數仍是(shi)使用IPv4協議。但是(shi),隨著(zhu)計(ji)算機及路由器的(de)(de)迅速發(fa)展(zhan),特(te)別是(shi)隨著(zhu)物聯(lian)網的(de)(de)快速發(fa)展(zhan),IPv4的(de)(de)弊端日益明顯,IP6取代IP4成為物聯(lian)網發(fa)展(zhan)的(de)(de)必需,具體如下:

(一)IPv6對IPv4的取代能(neng)夠(gou)解決物(wu)聯網(wang)發展過(guo)程中網(wang)絡地址的不足

當前(qian),IPv4地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)資源有限。從(cong)理(li)論上講,編址(zhi)(zhi)(zhi)(zhi)1 600萬(wan)個(ge)網絡(luo)、大約43億(yi)個(ge)電(dian)腦可(ke)以聯到(dao)(dao)Internet上。但采用(yong)A、B、C三類(lei)編址(zhi)(zhi)(zhi)(zhi)方式后,可(ke)用(yong)的(de)(de)網絡(luo)地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)和主機地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)的(de)(de)數目大打折扣,以致目前(qian)的(de)(de)IP地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)近(jin)乎(hu)枯竭。最近(jin)美國ARIN報告,A類(lei)地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)已(yi)分(fen)(fen)配(pei)完;62%B類(lei)地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)已(yi)分(fen)(fen)配(pei);37%C類(lei)地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)已(yi)分(fen)(fen)配(pei),IPv4的(de)(de)地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)空間將面臨(lin)耗盡的(de)(de)危險。IPv6產生的(de)(de)初衷主要(yao)是針(zhen)對IPv4地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)短缺問(wen)題,即(ji)從(cong)IPv4的(de)(de)32bit地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi),擴展(zhan)到(dao)(dao)了IPv6的(de)(de)128bit地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi),充分(fen)(fen)解(jie)決了地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)匱乏問(wen)題。同時,IPv6網絡(luo)中一個(ge)接(jie)口可(ke)以有一個(ge)或多(duo)個(ge)IPV6地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)(包括單傳波地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)、任(ren)播地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)和多(duo)播地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)),這也進(jin)一步增加了地(di)(di)(di)(di)址(zhi)(zhi)(zhi)(zhi)應用(yong)的(de)(de)擴展(zhan)性(xing)。

(二)IPv6對(dui)IPv4的取代能夠(gou)解決物聯網發展過(guo)程中互(hu)通性、可擴展性、架構的穩定性和普遍性的需要

1.IPv6取代IPv4,更(geng)能夠適應(ying)物聯網網絡傳輸控(kong)制的(de)發(fa)展

網絡能夠互聯互通是網絡在任何數(shu)據(ju)(ju)改善之(zhi)前,兩個端口之(zhi)間必須建立一個鏈(lian)(lian)接。鏈(lian)(lian)接由(you)端點的IP地址和TCP端口之(zhi)間唯一確(que)定。TCP在盡力(li)而(er)為的IP層之(zhi)上提供一個可靠(kao)(kao)的字(zi)節流來(lai)傳(chuan)輸(shu)服務,它通過(guo)緩沖數(shu)據(ju)(ju)并結合主動確(que)認和重傳(chuan)機制(zhi),實現傳(chuan)輸(shu)可靠(kao)(kao)性;同(tong)時(shi),TCP還提供包括(kuo)建立和拆除鏈(lian)(lian)接的可靠(kao)(kao)方式(shi)。總之(zhi),TCP以更大的報(bao)頭和更為復(fu)雜的傳(chuan)輸(shu)層協議的邏輯為代價降低了應用的復(fu)雜程(cheng)度。

在物(wu)聯網環境(jing)下,智(zhi)能(neng)物(wu)件(jian)有(you)芯片內存低、信息吞吐量(liang)低等特(te)點。同(tong)(tong)時,用(yong)于物(wu)聯網環境(jing)下的(de)(de)UDP協議存在兩(liang)個(ge)缺(que)點:UDP不(bu)為(wei)(wei)傳輸(shu)過程中丟失的(de)(de)數(shu)(shu)據報(bao)提(ti)(ti)(ti)(ti)供任何恢(hui)復機(ji)制,丟失的(de)(de)數(shu)(shu)據報(bao)由(you)應用(yong)來(lai)恢(hui)復;同(tong)(tong)時,UDP不(bu)為(wei)(wei)應用(yong)提(ti)(ti)(ti)(ti)供任何機(ji)制來(lai)將數(shu)(shu)據割成大小(xiao)(xiao)適(shi)合(he)網絡(luo)傳輸(shu)的(de)(de)數(shu)(shu)據塊(kuai)。因此(ci),必須計算出適(shi)合(he)網絡(luo)傳送(song)的(de)(de)分(fen)組(zu)(zu)數(shu)(shu)據大小(xiao)(xiao),并相應地(di)調(diao)整數(shu)(shu)據報(bao)。而這些(xie)功(gong)能(neng)TCP不(bu)但(dan)提(ti)(ti)(ti)(ti)供傳輸(shu)可靠性(xing),還提(ti)(ti)(ti)(ti)供了(le)一(yi)種自適(shi)應分(fen)組(zu)(zu)傳送(song)報(bao)文大小(xiao)(xiao)的(de)(de)機(ji)制。這些(xie)功(gong)能(neng)就(jiu)要求TCP的(de)(de)地(di)址(zhi)能(neng)夠(gou)(gou)把(ba)數(shu)(shu)量(liang)巨大的(de)(de)智(zhi)能(neng)物(wu)件(jian)按唯一(yi)的(de)(de)身(shen)份(fen)聯系起(qi)來(lai)。因此(ci),IPv6取代IPv4,更能(neng)夠(gou)(gou)適(shi)應物(wu)聯網網絡(luo)傳輸(shu)控制的(de)(de)發展。

2.IPv6取(qu)代(dai)IPv4更(geng)能夠適應(ying)物聯網(wang)發展(zhan)過程中互通(tong)性、可擴展(zhan)性、架構的穩定性和普(pu)遍性的需(xu)要

隨著物(wu)聯網(wang)(wang)等信息技術的(de)(de)發展,雖然智(zhi)能(neng)(neng)(neng)物(wu)件具有一定的(de)(de)智(zhi)能(neng)(neng)(neng),但是(shi),它們畢(bi)竟是(shi)沒有智(zhi)慧的(de)(de)物(wu)體,不能(neng)(neng)(neng)夠像(xiang)人那樣熟悉直接操作網(wang)(wang)絡。因(yin)此,相對人來(lai)說,智(zhi)能(neng)(neng)(neng)物(wu)件對物(wu)聯網(wang)(wang)中的(de)(de)網(wang)(wang)絡協議有更多的(de)(de)特殊要(yao)求,比(bi)如:可擴展性(xing)、互通性(xing)、架構(gou)穩定性(xing)和(he)普遍(bian)性(xing)等。

智(zhi)(zhi)能(neng)物(wu)(wu)件(jian)(jian)對IP協(xie)議(yi)(yi)的(de)(de)可擴展性(xing)(xing)需求(qiu)是指IP協(xie)議(yi)(yi)能(neng)夠內(nei)(nei)在(zai)支(zhi)持(chi)(chi)智(zhi)(zhi)能(neng)物(wu)(wu)件(jian)(jian)的(de)(de)發展而具有可持(chi)(chi)續(xu)(xu)開(kai)發的(de)(de)機制;智(zhi)(zhi)能(neng)物(wu)(wu)件(jian)(jian)對IP協(xie)議(yi)(yi)的(de)(de)互通(tong)(tong)性(xing)(xing)需求(qiu)是指IP協(xie)議(yi)(yi)能(neng)夠支(zhi)持(chi)(chi)智(zhi)(zhi)能(neng)物(wu)(wu)件(jian)(jian)之(zhi)間(jian)以(yi)及智(zhi)(zhi)能(neng)物(wu)(wu)件(jian)(jian)和(he)網絡基礎設施之(zhi)間(jian)可持(chi)(chi)續(xu)(xu)的(de)(de)互通(tong)(tong)性(xing)(xing),這(zhe)就(jiu)要求(qiu)IP協(xie)議(yi)(yi)提(ti)供網絡、應用和(he)協(xie)議(yi)(yi)在(zai)網絡中不同鏈(lian)路(lu)層內(nei)(nei)和(he)層間(jian)的(de)(de)互通(tong)(tong)性(xing)(xing);智(zhi)(zhi)能(neng)物(wu)(wu)件(jian)(jian)對IP協(xie)議(yi)(yi)的(de)(de)架構穩定性(xing)(xing)和(he)普遍性(xing)(xing)的(de)(de)需求(qiu)是指雖然IP協(xie)議(yi)(yi)的(de)(de)可擴展很重(zhong)要,但是IP協(xie)議(yi)(yi)的(de)(de)架構穩定性(xing)(xing)和(he)普遍性(xing)(xing)對智(zhi)(zhi)能(neng)物(wu)(wu)件(jian)(jian)在(zai)生命周期(qi)內(nei)(nei)具有重(zhong)要意義。

總(zong)之,IPv4近(jin)20年(nian)的(de)(de)空(kong)前成功(gong),已經證明了IPv4協(xie)議(yi)設計的(de)(de)基本思想、構(gou)架是值(zhi)得肯定(ding)的(de)(de)。IPv6并(bing)不(bu)是一個全(quan)新的(de)(de)網(wang)(wang)絡(luo)協(xie)議(yi)標(biao)準,沒(mei)有(you)(you)完全(quan)IPv4的(de)(de)所(suo)有(you)(you)思路和(he)(he)(he)(he)結構(gou),它總(zong)結IPv4近(jin)20年(nian)來運營所(suo)獲得的(de)(de)豐富經驗和(he)(he)(he)(he)教訓,繼承(cheng)IPv4協(xie)議(yi)運行的(de)(de)主(zhu)要優點,最后(hou)進(jin)行了大(da)(da)幅修改和(he)(he)(he)(he)功(gong)能(neng)擴充。例(li)如:針對物(wu)(wu)聯(lian)(lian)網(wang)(wang)的(de)(de)發展(zhan)需要,除了具有(you)(you)龐大(da)(da)的(de)(de)地(di)址空(kong)間外,IPv6對IPv4功(gong)能(neng)上進(jin)行了發展(zhan),簡(jian)易靈活的(de)(de)頭(tou)部格(ge)式、網(wang)(wang)絡(luo)資源可進(jin)行預分(fen)配、更高的(de)(de)安(an)全(quan)性、支持即插即用(yong)和(he)(he)(he)(he)移動性。由于這(zhe)(zhe)些特性技術含量較高,這(zhe)(zhe)里(li)不(bu)進(jin)行具體介紹。智能(neng)物(wu)(wu)件由于自(zi)身的(de)(de)特殊性對物(wu)(wu)聯(lian)(lian)網(wang)(wang)的(de)(de)IP協(xie)議(yi)具有(you)(you)特殊的(de)(de)要求(qiu),新一代的(de)(de)IPv6能(neng)夠為物(wu)(wu)聯(lian)(lian)網(wang)(wang)的(de)(de)應用(yong)和(he)(he)(he)(he)服(fu)務提供可橫跨多(duo)種通信技術的(de)(de)互通、可擴展(zhan)、穩定(ding)和(he)(he)(he)(he)普遍的(de)(de)網(wang)(wang)絡(luo)架構(gou)協(xie)議(yi),為互聯(lian)(lian)網(wang)(wang)換(huan)上一個簡(jian)捷、高效的(de)(de)引擎,這(zhe)(zhe)樣不(bu)僅可以解(jie)決IPv4目前的(de)(de)地(di)址短(duan)缺難題,而且可以使物(wu)(wu)聯(lian)(lian)網(wang)(wang)擺脫日(ri)益復雜、難以管理和(he)(he)(he)(he)控制(zhi)的(de)(de)局面,變(bian)得更加穩定(ding)、可靠、高效和(he)(he)(he)(he)安(an)全(quan)。

三(san)、企(qi)業(ye)應用(yong)IPv6應該注意的(de)主要問題

隨著3G通訊業(ye)務、智能(neng)手機(ji)等多種(zhong)個人(ren)智能(neng)終端、超高速(su)家(jia)庭(ting)網(wang)絡的(de)(de)(de)發展,針(zhen)對(dui)網(wang)絡地址不(bu)足等問題,我國已經起動IPv6取代IPv4的(de)(de)(de)工程。這對(dui)物聯網(wang)建(jian)設具有重要(yao)的(de)(de)(de)現實(shi)意義(yi)。但(dan)是,正如每一(yi)個新生事物一(yi)樣,IPv6也有其不(bu)足的(de)(de)(de)地方(fang),企業(ye)在物聯網(wang)建(jian)設中應用IPv6除了進行詳盡的(de)(de)(de)規劃與設計外,還應該主要(yao)注意過渡性(xing)問題與安全問題。

(一)過渡性問題

雖然(ran)IPv4有(you)(you)上述缺陷以及IPv6協(xie)議(yi)標準的(de)(de)(de)(de)成熟具有(you)(you)取代IPv4位置的(de)(de)(de)(de)必然(ran)趨勢(shi),但是(shi)(shi),這(zhe)(zhe)種取代的(de)(de)(de)(de)過程必然(ran)會經(jing)歷(li)一個(ge)相對漫(man)長的(de)(de)(de)(de)過程。同時(shi),盡管(guan)IETF在設計IPv6的(de)(de)(de)(de)時(shi)候已經(jing)充分考慮了和(he)IPv4的(de)(de)(de)(de)兼容(rong)(rong)性(xing),但是(shi)(shi)這(zhe)(zhe)兩個(ge)版本不是(shi)(shi)完全兼容(rong)(rong)的(de)(de)(de)(de)。因(yin)此,企(qi)業在物聯(lian)網(wang)建設中必須考慮由IPv4向IPv6過渡的(de)(de)(de)(de)問題。首先(xian)是(shi)(shi)處理好IPv4向IPv6遷(qian)移時(shi)應該(gai)考慮的(de)(de)(de)(de)地方:Ipv4與(yu)Ipv6的(de)(de)(de)(de)主機必須可互(hu)(hu)操作;Ipv6主機和(he)路由器(qi)的(de)(de)(de)(de)使用必須簡單(dan),逐漸地分布普及到整個(ge)Internet,不能有(you)(you)太多(duo)的(de)(de)(de)(de)相互(hu)(hu)依賴(lai)性(xing);網(wang)絡(luo)(luo)管(guan)理員(yuan)和(he)最終用戶必須認為這(zhe)(zhe)種遷(qian)移容(rong)(rong)易理解和(he)執行。其次是(shi)(shi)注(zhu)意(yi)過渡技術的(de)(de)(de)(de)選(xuan)擇,即(ji)雙協(xie)議(yi)棧技術、隧道技術和(he)網(wang)絡(luo)(luo)地址轉換技術。

(二)安全性問題

引入IPv6出(chu)現(xian)的(de)(de)(de)(de)安全(quan)問(wen)(wen)題(ti)(ti)(ti)(ti)主要來(lai)源于(yu)兩方(fang)面:一方(fang)面是由(you)于(yu)IPv6本(ben)身的(de)(de)(de)(de)缺陷(xian)所引發的(de)(de)(de)(de)安全(quan)問(wen)(wen)題(ti)(ti)(ti)(ti);另(ling)一方(fang)面是由(you)于(yu)IPv6的(de)(de)(de)(de)過渡技(ji)術(shu)引發的(de)(de)(de)(de)安全(quan)問(wen)(wen)題(ti)(ti)(ti)(ti)。由(you)IPv6本(ben)身的(de)(de)(de)(de)缺陷(xian)引發的(de)(de)(de)(de)安全(quan)問(wen)(wen)題(ti)(ti)(ti)(ti)有:IPv6現(xian)在(zai)遇到的(de)(de)(de)(de)安全(quan)威(wei)脅主要包括(kuo)地址掃(sao)描、非法訪問(wen)(wen)、分片、路由(you)協(xie)議的(de)(de)(de)(de)認證、蠕(ru)蟲(chong)攻(gong)擊(ji)、對(dui)ICMPv6的(de)(de)(de)(de)攻(gong)擊(ji)、對(dui)鄰居(ju)發現(xian)的(de)(de)(de)(de)攻(gong)擊(ji)以及對(dui)無狀態地址自動配置(zhi)的(de)(de)(de)(de)攻(gong)擊(ji)等;過渡技(ji)術(shu)引發的(de)(de)(de)(de)問(wen)(wen)題(ti)(ti)(ti)(ti)有:雙棧技(ji)術(shu)的(de)(de)(de)(de)安全(quan)問(wen)(wen)題(ti)(ti)(ti)(ti)、隧道技(ji)術(shu)的(de)(de)(de)(de)安全(quan)問(wen)(wen)題(ti)(ti)(ti)(ti)、地址翻譯(yi)技(ji)術(shu)的(de)(de)(de)(de)安全(quan)問(wen)(wen)題(ti)(ti)(ti)(ti)等。

四、結論與啟示

物聯(lian)網建(jian)設(she)需要把數(shu)以億計(ji)的(de)(de)(de)物件(jian)“互(hu)(hu)(hu)聯(lian)互(hu)(hu)(hu)通”并且“相互(hu)(hu)(hu)作(zuo)用”,企業在建(jian)設(she)物聯(lian)網過(guo)程中應該選(xuan)擇IPv6對(dui)IPv4取代的(de)(de)(de)IP協議的(de)(de)(de)標(biao)準(zhun)是:不僅要有(you)充足的(de)(de)(de)地址資(zi)源(yuan),更(geng)需要IPv6能夠在網絡操作(zuo)發展中有(you)更(geng)好(hao)的(de)(de)(de)互(hu)(hu)(hu)通性(xing)(xing)、可擴展性(xing)(xing)、架構的(de)(de)(de)穩(wen)定性(xing)(xing)和(he)普遍(bian)性(xing)(xing)。

IPv6對IPv4是(shi)一(yi)(yi)個不能夠相(xiang)互兼(jian)容的(de)(de)(de)IP協議。物聯(lian)網(wang)(wang)建設(she)從IPv4向(xiang)IPv6遷移(yi)產生不少(shao)的(de)(de)(de)過(guo)渡困難。這給大(da)家的(de)(de)(de)啟示(shi)便是(shi)能夠有(you)統一(yi)(yi)的(de)(de)(de)標(biao)準,不僅是(shi)技(ji)術標(biao)準,也包(bao)括管(guan)理標(biao)準。如果說IPv4向(xiang)IPv6遷移(yi)中技(ji)術問題(ti)比(bi)重(zhong)較大(da)的(de)(de)(de)話,那么,基于(yu)物聯(lian)網(wang)(wang)會計云(yun)計算(suan)建設(she)中就(jiu)會克服更多的(de)(de)(de)需要(yao)統一(yi)(yi)的(de)(de)(de)管(guan)理標(biao)準。如:當(dang)前,由于(yu)沒有(you)統一(yi)(yi)的(de)(de)(de)云(yun)計算(suan)標(biao)準,Google、Amazon、微軟、IBM等公司(si)紛紛推出自己(ji)的(de)(de)(de)云(yun)計算(suan)平臺和(he)云(yun)計算(suan)的(de)(de)(de)實(shi)務標(biao)準。這就(jiu)導致了不同廠商(shang)的(de)(de)(de)服務出現(xian)兼(jian)容性問題(ti)。如何通過(guo)溝通協作,把這些(xie)實(shi)務標(biao)準變成統一(yi)(yi)標(biao)準需要(yao)大(da)家共同努力。

篇3

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

“計(ji)算(suan)機(ji)(ji)(ji)(ji)網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)”課程作(zuo)為計(ji)算(suan)機(ji)(ji)(ji)(ji)科學(xue)與技術、網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)工程、通信工程和(he)(he)(he)軟件(jian)工程等專業的(de)(de)(de)(de)(de)主干課,其(qi)地(di)(di)位(wei)在課程體(ti)系(xi)群(qun)中尤(you)為重要(yao)。學(xue)習這門課程,最重要(yao)的(de)(de)(de)(de)(de)是(shi)掌握計(ji)算(suan)機(ji)(ji)(ji)(ji)網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)的(de)(de)(de)(de)(de)原(yuan)理,了(le)解網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)硬件(jian)和(he)(he)(he)軟件(jian)的(de)(de)(de)(de)(de)工作(zuo)機(ji)(ji)(ji)(ji)制。計(ji)算(suan)機(ji)(ji)(ji)(ji)網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)基礎理論復雜(za)抽(chou)象,概念(nian)眾多,對(dui)(dui)剛(gang)開始(shi)學(xue)習計(ji)算(suan)機(ji)(ji)(ji)(ji)網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)的(de)(de)(de)(de)(de)學(xue)生來說(shuo),這些概念(nian)和(he)(he)(he)協(xie)(xie)議是(shi)非常難以理解和(he)(he)(he)記憶(yi)的(de)(de)(de)(de)(de)。計(ji)算(suan)機(ji)(ji)(ji)(ji)網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)原(yuan)理主要(yao)描述的(de)(de)(de)(de)(de)是(shi)各(ge)層(ceng)(ceng)的(de)(de)(de)(de)(de)功(gong)能(neng)及其(qi)協(xie)(xie)議和(he)(he)(he)服務,具(ju)體(ti)地(di)(di)說(shuo)就(jiu)是(shi)要(yao)理解網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)的(de)(de)(de)(de)(de)相關(guan)功(gong)能(neng)層(ceng)(ceng)概念(nian)和(he)(he)(he)網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)體(ti)系(xi)結(jie)構(包括OSI參考模(mo)型、TCP/IP模(mo)型協(xie)(xie)議族),以及功(gong)能(neng)模(mo)塊之間(jian)的(de)(de)(de)(de)(de)協(xie)(xie)議交互[1],這是(shi)學(xue)好計(ji)算(suan)機(ji)(ji)(ji)(ji)網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)的(de)(de)(de)(de)(de)關(guan)鍵。網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)體(ti)系(xi)結(jie)構是(shi)計(ji)算(suan)機(ji)(ji)(ji)(ji)網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)及其(qi)部件(jian)所應完成的(de)(de)(de)(de)(de)功(gong)能(neng)的(de)(de)(de)(de)(de)精(jing)確(que)定義。計(ji)算(suan)機(ji)(ji)(ji)(ji)網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)原(yuan)理主要(yao)講(jiang)述的(de)(de)(de)(de)(de)就(jiu)是(shi)各(ge)層(ceng)(ceng)的(de)(de)(de)(de)(de)功(gong)能(neng)及其(qi)協(xie)(xie)議和(he)(he)(he)服務。在計(ji)算(suan)機(ji)(ji)(ji)(ji)網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)教學(xue)過程中,利用Wireshark網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)探測和(he)(he)(he)分析(xi)軟件(jian),通過從(cong)網(wang)(wang)(wang)絡(luo)(luo)(luo)(luo)中實時捕獲幾種常見協(xie)(xie)議數據(ju)包并進行分析(xi),使學(xue)生對(dui)(dui)一些協(xie)(xie)議的(de)(de)(de)(de)(de)工作(zuo)原(yuan)理及結(jie)構有了(le)更加深刻的(de)(de)(de)(de)(de)理解和(he)(he)(he)認識[2]。

1Wireshark簡介

Wireshark(原名Ethereal)是(shi)目前世界上最受(shou)歡迎的協(xie)議(yi)分(fen)(fen)析軟件,利(li)用(yong)它(ta)可將捕獲(huo)到的網絡二進制(zhi)數據流翻譯(yi)為人們容易讀懂和(he)(he)理解的文(wen)字和(he)(he)圖(tu)表等形式,極大地方便了(le)對網絡活動(dong)的監測分(fen)(fen)析和(he)(he)教學實(shi)驗。它(ta)有十分(fen)(fen)豐富和(he)(he)強大的統(tong)計(ji)分(fen)(fen)析功能(neng),可在(zai)Windows,Linux 和(he)(he)UNIX等系統(tong)上運行。它(ta)允(yun)許(xu)在(zai)一(yi)個(ge)網絡內部實(shi)時捕獲(huo)和(he)(he)分(fen)(fen)析數據包,用(yong)戶可以通過圖(tu)形界面很直觀地瀏覽捕獲(huo)到的數據信息,研究數據包每(mei)一(yi)層的詳細信息[3]。

學習(xi)和(he)理解計(ji)算機(ji)網絡(luo)原理的(de)(de)最好方法是,理論聯系(xi)實(shi)際。在一個現實(shi)的(de)(de)局域網中(zhong),網絡(luo)數據流往往是來自不同(tong)用戶的(de)(de)各種(zhong)各樣(yang)協議(yi)(yi)數據的(de)(de)大混雜,因此利用Wireshark的(de)(de)“捕獲(huo)過(guo)濾器(qi)”和(he)“顯(xian)示過(guo)濾器(qi)”,從錯(cuo)綜復雜的(de)(de)數據流中(zhong)迅速(su)提取自己所關心的(de)(de)網絡(luo)信息,了解和(he)掌握(wo)網絡(luo)的(de)(de)工作原理和(he)協議(yi)(yi)的(de)(de)交互過(guo)程。

Wireshark使(shi)用(yong)目的是(shi)網絡(luo)管(guan)理員(yuan)使(shi)用(yong)Wireshark來(lai)檢測網絡(luo)問(wen)題、網絡(luo)安全工程師使(shi)用(yong)Wireshark來(lai)檢查資訊安全相關問(wen)題、開發者(zhe)使(shi)用(yong)Wireshark來(lai)為新的通訊協議除錯、普通使(shi)用(yong)者(zhe)使(shi)用(yong)Wireshark來(lai)學習網絡(luo)協議的相關知識等。

2用Wireshark分(fen)析(xi)網絡協(xie)議

網(wang)絡協(xie)(xie)(xie)(xie)議(yi)是網(wang)絡上(shang)所有設備(網(wang)絡服務器、計算(suan)機及(ji)(ji)交換機、路由(you)器、防(fang)火墻等)之間通信(xin)規則的(de)(de)(de)集(ji)合(he),它(ta)定義了通信(xin)時信(xin)息必須采用(yong)的(de)(de)(de)格(ge)式和這些格(ge)式的(de)(de)(de)意義。TCP/IP(Transmission Control Protocol / Internet Protocol),即傳輸控(kong)制協(xie)(xie)(xie)(xie)議(yi)/互(hu)(hu)聯網(wang)協(xie)(xie)(xie)(xie)議(yi)是不同操作系統的(de)(de)(de)計算(suan)機網(wang)絡互(hu)(hu)連的(de)(de)(de)通用(yong)協(xie)(xie)(xie)(xie)議(yi),它(ta)是一組計算(suan)機通信(xin)協(xie)(xie)(xie)(xie)議(yi)族,其中最著名的(de)(de)(de)兩個協(xie)(xie)(xie)(xie)議(yi)是TCP及(ji)(ji)IP協(xie)(xie)(xie)(xie)議(yi)。TCP/IP協(xie)(xie)(xie)(xie)議(yi)具有開放式互(hu)(hu)聯環(huan)境,很容易實現(xian)各種局(ju)域(yu)網(wang)和廣(guang)域(yu)網(wang)的(de)(de)(de)集(ji)成(cheng)式互(hu)(hu)聯。此協(xie)(xie)(xie)(xie)議(yi)是當(dang)今技術最成(cheng)熟、應用(yong)最廣(guang)泛的(de)(de)(de)網(wang)絡協(xie)(xie)(xie)(xie)議(yi)[4]。

TCP是(shi)一種面向(xiang)連(lian)接(jie)(jie)的、可靠的運輸(shu)(shu)層(ceng)協議,TCP數(shu)據(ju)傳輸(shu)(shu)(只(zhi)有連(lian)接(jie)(jie)建立(li)后(hou)(hou)才可進(jin)行(xing)數(shu)據(ju)傳輸(shu)(shu))需(xu)要(yao)通過在(zai)客戶端和服務器(qi)端建立(li)特定的虛電路(lu)連(lian)接(jie)(jie)來完成,該過程(cheng)(cheng)通常(chang)被稱為“三次握手”,即(ji)發(fa)送方(fang)先發(fa)送連(lian)接(jie)(jie)請(qing)求,然后(hou)(hou)接(jie)(jie)收方(fang)進(jin)行(xing)連(lian)接(jie)(jie)確(que)(que)認,最后(hou)(hou)發(fa)送方(fang)對接(jie)(jie)收方(fang)的確(que)(que)認再次進(jin)行(xing)確(que)(que)認(圖1)。下面就以Wireshark對 TCP連(lian)接(jie)(jie)建立(li)交互過程(cheng)(cheng)的數(shu)據(ju)包捕(bu)獲分析為例(li),來說明對TCP/IP協議實現的分析。

2.1建立(li)捕獲TCP連接(jie)報文的實驗環境(jing)

PCATTCP是一款不錯的測試局域網(wang)(wang)(wang)(wang)網(wang)(wang)(wang)(wang)絡速度的軟件。在(zai)(zai)局域網(wang)(wang)(wang)(wang)中(zhong),兩臺主機(ji)通過交換(huan)機(ji)連接起(qi)來。在(zai)(zai)服務器(qi)端(duan)(duan)和客(ke)戶端(duan)(duan)都(dou)安裝(zhuang)和運(yun)行(xing)PCATTCP進行(xing)通信,產(chan)生TCP流。啟動Wireshark進行(xing)數(shu)據包捕(bu)獲(huo),單(dan)擊CaptureInterfaces菜單(dan),選(xuan)擇自己(ji)的網(wang)(wang)(wang)(wang)卡,選(xuan)擇Start開始監控流量。在(zai)(zai)服務器(qi)端(duan)(duan)運(yun)行(xing)ttcp,監聽(ting)TCP的5001端(duan)(duan)口。圖2是服務器(qi)端(duan)(duan)的完(wan)整命(ming)令行(xing)輸(shu)出:

服務(wu)器配置好后,在(zai)客戶(hu)端運行ttcp,雙方(fang)開始通(tong)信。

2.2TCP報文分析

2.2.1客戶端(duan)發送連接(jie)請求

捕捉到(dao)的(de)TCP 連接報文如圖(tu)3所示。

從圖3可以(yi)看出,客戶端發出的(de)連接請求數(shu)(shu)據(ju)包封裝了三(san)個頭信息:以(yi)太網(Ethernet)幀(zhen)、IP數(shu)(shu)據(ju)報(bao)(bao)和TCP報(bao)(bao)文(wen)段。在數(shu)(shu)據(ju)鏈路層,數(shu)(shu)據(ju)以(yi)幀(zhen)的(de)方式(shi)進行傳(chuan)輸(shu)。在網絡(luo)層,加(jia)工的(de)主要(yao)數(shu)(shu)據(ju)對象是IP數(shu)(shu)據(ju)報(bao)(bao)。IP協議(yi)是TCP/IP協議(yi)族中的(de)核心協議(yi)之一,所有的(de)TCP、UDP、ICMP數(shu)(shu)據(ju)都以(yi)IP數(shu)(shu)據(ju)報(bao)(bao)格(ge)式(shi)傳(chuan)輸(shu)。

在運輸層,主要(yao)數據對(dui)象是TCP報文。客戶(hu)端發送的(de)連接(jie)請求如(ru)圖4所示。

第一條報(bao)(bao)文(wen)是(shi)沒有(you)數據的(de)TCP報(bao)(bao)文(wen)段(duan),并(bing)且將(jiang)首(shou)部的(de)SYN位(wei)設(she)(she)(she)置(zhi)為1。因此(ci),第一條報(bao)(bao)文(wen)常常被(bei)稱(cheng)為SYN分組(zu)。這個報(bao)(bao)文(wen)段(duan)里的(de)序列(lie)(lie)號是(shi)由系(xi)統隨機(ji)設(she)(she)(she)置(zhi)的(de)數值(zhi),表示(shi)客戶端為后續報(bao)(bao)文(wen)設(she)(she)(she)定的(de)起始編號。此(ci)TCP報(bao)(bao)文(wen)段(duan),序列(lie)(lie)號SEQ在(zai)連(lian)接(jie)請(qing)求(qiu)時相對初始值(zhi)是(shi)0,其實(shi)際(ji)值(zhi)是(shi)c9 f4 65 c2;確認(ren)號是(shi)00 00 00 00,ACK標志(zhi)為0表明確認(ren)號被(bei)忽略。SYN=1表示(shi)正在(zai)進行連(lian)接(jie)請(qing)求(qiu),通(tong)過SYN和(he)(he)ACK也(ye)可以用來區分Connection Request和(he)(he)Connection Accepted,在(zai)連(lian)接(jie)請(qing)求(qiu)中,SYN=1、ACK=0,連(lian)接(jie)響(xiang)應時,SYN=1、ACK=1。

SYN分(fen)組通常是從客戶端(duan)(duan)發(fa)(fa)送(song)到(dao)服務(wu)器(qi)端(duan)(duan)。這個(ge)報(bao)文段請求建立連(lian)(lian)接(jie)。因為一(yi)旦成功(gong)建立連(lian)(lian)接(jie),服務(wu)器(qi)進程必(bi)須已經在監聽SYN分(fen)組所指示的IP地址和端(duan)(duan)口號[5]。如果沒有建立連(lian)(lian)接(jie),SYN分(fen)組將(jiang)不(bu)會(hui)應答。如果第(di)一(yi)個(ge)分(fen)組丟失了,客戶端(duan)(duan)通常會(hui)發(fa)(fa)送(song)若干個(ge)SYN分(fen)組,如果多次嘗試不(bu)成功(gong),客戶端(duan)(duan)將(jiang)會(hui)停(ting)止并報(bao)告一(yi)個(ge)錯誤(wu)給應用程序。

2.2.2服務(wu)端(duan)連接響應

當服務器(qi)接(jie)收(shou)到(dao)連接(jie)請(qing)求(qiu)時,就對(dui)請(qing)求(qiu)方進行響應(ying),以確認(ren)收(shou)到(dao)客(ke)戶端(duan)的(de)第一(yi)個TCP報文段(duan)(duan)。響應(ying)的(de)報文段(duan)(duan)SYN位和ACK位都將置1。通常稱這個報文段(duan)(duan)為(wei)SYNACK分組(zu)。SYNACK分組(zu)在確認(ren)收(shou)到(dao)SYN分組(zu)的(de)同時也發(fa)出一(yi)個初(chu)始的(de)數據流(liu)序(xu)(xu)列(lie)(lie)號(hao),表示服務器(qi)發(fa)向客(ke)戶端(duan)的(de)數據序(xu)(xu)號(hao),它不需要與剛(gang)才(cai)客(ke)戶端(duan)發(fa)來的(de)數據流(liu)的(de)序(xu)(xu)列(lie)(lie)號(hao)相匹配。服務器(qi)端(duan)響應(ying)的(de)數據包如(ru)圖5所示。

此(ci)數據包(bao)的起(qi)始(shi)(shi)序(xu)列(lie)號(hao)SEQ在協議框中顯(xian)示為(wei)0,在原始(shi)(shi)框中的實(shi)際值為(wei)63 cf 1a c9。所有初始(shi)(shi)序(xu)列(lie)號(hao)邏輯上都(dou)視(shi)同為(wei)序(xu)列(lie)號(hao)0。ACK標志為(wei)1表明(ming)確認號(hao)有效,SYN仍然為(wei)1。

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

2.2.3客戶(hu)端連接確認

在TCP連接(jie)(jie)建(jian)立(li)的(de)(de)最后階段(duan)(duan),客戶(hu)(hu)端(duan)對接(jie)(jie)收到數據包(bao)的(de)(de)服(fu)(fu)務器端(duan)進行確認(ren)(ren),到此為止建(jian)立(li)完(wan)整的(de)(de)TCP連接(jie)(jie),開(kai)始全(quan)雙工模式的(de)(de)數據傳輸(shu)過(guo)程。客戶(hu)(hu)端(duan)收到服(fu)(fu)務器端(duan)確認(ren)(ren)后,發(fa)送(song)(song)帶有ACK標(biao)志的(de)(de)TCP報(bao)文段(duan)(duan)來(lai)完(wan)成三(san)次握手的(de)(de)過(guo)程[6]。這個報(bao)文段(duan)(duan)將確認(ren)(ren)服(fu)(fu)務器端(duan)發(fa)送(song)(song)的(de)(de)SYNACK分組,并檢查TCP連接(jie)(jie)的(de)(de)兩端(duan)是(shi)否正確地打開(kai)和運作。

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

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

2.3小結

從以(yi)上(shang)的(de)(de)圖可以(yi)看出(chu),利用Wireshark可以(yi)針對(dui)每一(yi)數(shu)據包,完成(cheng)從鏈路層(ceng)、網絡層(ceng)、運(yun)輸(shu)層(ceng)到應用層(ceng)的(de)(de)協議(yi)(yi)解析。通過上(shang)面步(bu)驟,可以(yi)更加(jia)直觀(guan)的(de)(de)觀(guan)察(cha)到TCP三次(ci)握手建(jian)立(li)的(de)(de)過程,有助(zhu)于理解TCP及其工作原理,掌握協議(yi)(yi)的(de)(de)語法細節(jie)。

3結語

計算機(ji)(ji)網絡(luo)(luo)基本(ben)理(li)論復雜抽象,不易理(li)解(jie),但這部分內容又是(shi)進(jin)一步學(xue)(xue)習“計算機(ji)(ji)網絡(luo)(luo)”課程,培養(yang)實(shi)踐應(ying)用能(neng)力的(de)基礎。在教(jiao)學(xue)(xue)過(guo)程中,通過(guo)合理(li)組織(zhi)授課內容,采用先進(jin)的(de)教(jiao)學(xue)(xue)方(fang)法和較為科學(xue)(xue)的(de)教(jiao)學(xue)(xue)手(shou)段,使學(xue)(xue)生能(neng)夠較好地掌握計算機(ji)(ji)網絡(luo)(luo)的(de)基本(ben)理(li)論和方(fang)法。利(li)用Wireshark網絡(luo)(luo)協議分析(xi)軟(ruan)件,進(jin)行網絡(luo)(luo)性(xing)能(neng)參數和數據代碼的(de)捕獲(huo)分析(xi),了(le)解(jie)協議的(de)封(feng)裝結構、交互過(guo)程,對于計算機(ji)(ji)網絡(luo)(luo)教(jiao)學(xue)(xue)有(you)很大的(de)幫(bang)助。

參考文獻:

[1] 謝希(xi)仁. 計算機網(wang)絡(luo)[M]. 大(da)連(lian):大(da)連(lian)理(li)工大(da)學出版(ban)社,2004.

[2] 楊春勇,潘文君,朱翠濤(tao). 計算(suan)機網絡課(ke)程教學(xue)(xue)(xue)(xue)及(ji)輔助教學(xue)(xue)(xue)(xue)方法研究[J]. 高等(deng)函授學(xue)(xue)(xue)(xue)報:自(zi)然科學(xue)(xue)(xue)(xue)版(ban),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協議族[M]. 3版(ban). 謝希仁,等譯(yi). 北京(jing):清華大學出版(ban)社,2006.

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

[6] Miller D. 數據通訊與網(wang)絡(luo)[M]. 鄧勸生,薛(xue)建新,王涌,譯(yi). 北京:清華(hua)大學出版社,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

【關(guan)鍵詞(ci)】TCP/IP協議(yi);通信(xin)報(bao)文;路由尋址;通信(xin)流程

1 概述

隨(sui)著信(xin)(xin)(xin)(xin)(xin)息(xi)(xi)科學(xue)(xue)技(ji)術(shu)和(he)通(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)技(ji)術(shu)的(de)(de)(de)不(bu)斷快速(su)發展(zhan),基(ji)于互(hu)(hu)聯(lian)(lian)網(wang)的(de)(de)(de)網(wang)絡(luo)通(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)應(ying)(ying)用(yong)在(zai)社會各個領域中(zhong)的(de)(de)(de)應(ying)(ying)用(yong)越來越廣泛,使得互(hu)(hu)聯(lian)(lian)網(wang)通(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)應(ying)(ying)用(yong)成為(wei)現代人日常生產(chan)生生活不(bu)可或(huo)缺的(de)(de)(de)一(yi)部分,通(tong)(tong)(tong)過互(hu)(hu)聯(lian)(lian)網(wang)絡(luo)通(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin),網(wang)絡(luo)用(yong)戶之間可以實(shi)現數據傳輸(shu)、信(xin)(xin)(xin)(xin)(xin)息(xi)(xi)共享,從而(er)(er)極大地提高了人們的(de)(de)(de)生活質量。然而(er)(er),互(hu)(hu)聯(lian)(lian)網(wang)絡(luo)中(zhong)的(de)(de)(de)數據傳輸(shu)過程(cheng),并不(bu)是雜(za)亂無章的(de)(de)(de)隨(sui)機(ji)傳送(song),而(er)(er)是在(zai)計(ji)算(suan)機(ji)網(wang)絡(luo)通(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)協議的(de)(de)(de)基(ji)礎上,雙(shuang)方都按照協議的(de)(de)(de)內容和(he)機(ji)制,來發送(song)數據信(xin)(xin)(xin)(xin)(xin)息(xi)(xi)和(he)讀(du)取(qu)分析數據信(xin)(xin)(xin)(xin)(xin)息(xi)(xi),進(jin)而(er)(er)實(shi)現互(hu)(hu)聯(lian)(lian)網(wang)絡(luo)的(de)(de)(de)數據傳輸(shu)和(he)信(xin)(xin)(xin)(xin)(xin)息(xi)(xi)共享的(de)(de)(de)功能,TCP/IP協議就是互(hu)(hu)聯(lian)(lian)網(wang)絡(luo)中(zhong)重(zhong)要的(de)(de)(de)通(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)協議,它(ta)的(de)(de)(de)存在(zai)奠定了整個互(hu)(hu)聯(lian)(lian)網(wang)絡(luo)通(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)的(de)(de)(de)基(ji)礎,所以對(dui)于TCP/IP通(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)協議的(de)(de)(de)學(xue)(xue)習對(dui)于理解(jie)互(hu)(hu)聯(lian)(lian)網(wang)通(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)機(ji)制來輔(fu)助互(hu)(hu)聯(lian)(lian)網(wang)學(xue)(xue)習和(he)工作(zuo)具(ju)有(you)很大的(de)(de)(de)幫助。

2 計(ji)算機網絡的TCP/IP通(tong)信協(xie)議

TCP/IP協議(yi)是“Transmission Control Protocol / Internet Protocol”的(de)簡寫,是Internet網(wang)絡(luo)(luo)基本(ben)的(de)協議(yi),它(ta)為(wei)計算(suan)機(ji)通(tong)訊的(de)數據打包傳輸以及(ji)網(wang)絡(luo)(luo)尋址(zhi)提供了(le)標(biao)準(zhun)(zhun)的(de)方法。由(you)于TCP/IP協議(yi)的(de)優越(yue)性(xing),使(shi)得越(yue)來越(yue)多的(de)通(tong)信設備支持TCP/IP協議(yi),使(shi)互(hu)聯(lian)網(wang)絡(luo)(luo)逐步走向規范化,最終TCP/IP協議(yi)成為(wei)了(le)當(dang)前網(wang)絡(luo)(luo)通(tong)信協議(yi)標(biao)準(zhun)(zhun)中最基本(ben)的(de)網(wang)絡(luo)(luo)通(tong)信協議(yi)、Internet國際互(hu)聯(lian)網(wang)絡(luo)(luo)的(de)基礎(chu)。

2.1 計算機(ji)網(wang)絡TCP/IP協議

針對計算機互(hu)聯(lian)網絡的通(tong)(tong)信(xin)(xin)(xin)(xin)協(xie)議(yi)(yi),國際(ji)標準(zhun)組織ISO創立了(le)七層(ceng)(ceng)(ceng)OSI網絡模型,自上而(er)下,分(fen)別為應(ying)用層(ceng)(ceng)(ceng)、表示層(ceng)(ceng)(ceng)、會(hui)話層(ceng)(ceng)(ceng)、傳(chuan)(chuan)輸(shu)(shu)(shu)層(ceng)(ceng)(ceng)、網絡層(ceng)(ceng)(ceng)、數(shu)據(ju)(ju)鏈路層(ceng)(ceng)(ceng)、物理層(ceng)(ceng)(ceng)。而(er)TCP/IP協(xie)議(yi)(yi)則是應(ying)用在(zai)傳(chuan)(chuan)輸(shu)(shu)(shu)層(ceng)(ceng)(ceng)和網絡層(ceng)(ceng)(ceng)的數(shu)據(ju)(ju)傳(chuan)(chuan)輸(shu)(shu)(shu)控制協(xie)議(yi)(yi),來規定網絡設(she)備(bei)(bei)接入(ru)互(hu)聯(lian)網絡以(yi)及設(she)備(bei)(bei)間(jian)數(shu)據(ju)(ju)通(tong)(tong)信(xin)(xin)(xin)(xin)的標準(zhun)。在(zai)通(tong)(tong)信(xin)(xin)(xin)(xin)設(she)備(bei)(bei)經(jing)過互(hu)聯(lian)網絡進(jin)行(xing)數(shu)據(ju)(ju)傳(chuan)(chuan)輸(shu)(shu)(shu)時(shi),通(tong)(tong)信(xin)(xin)(xin)(xin)設(she)備(bei)(bei)數(shu)據(ju)(ju)發(fa)(fa)送端(duan),發(fa)(fa)送TCP/IP通(tong)(tong)信(xin)(xin)(xin)(xin)報(bao)文,此時(shi)TCP/IP協(xie)議(yi)(yi)攜帶(dai)著通(tong)(tong)信(xin)(xin)(xin)(xin)設(she)備(bei)(bei)發(fa)(fa)送端(duan)的傳(chuan)(chuan)輸(shu)(shu)(shu)數(shu)據(ju)(ju)內容以(yi)及目(mu)(mu)標通(tong)(tong)信(xin)(xin)(xin)(xin)設(she)備(bei)(bei)的地址(zhi)標示在(zai)互(hu)聯(lian)網絡中(zhong)進(jin)行(xing)尋址(zhi),從而(er)正確地傳(chuan)(chuan)送到目(mu)(mu)標通(tong)(tong)信(xin)(xin)(xin)(xin)設(she)備(bei)(bei)。當目(mu)(mu)標通(tong)(tong)信(xin)(xin)(xin)(xin)設(she)備(bei)(bei)接收到TCP/IP通(tong)(tong)信(xin)(xin)(xin)(xin)報(bao)文后(hou),按照協(xie)議(yi)(yi)內容,去(qu)除(chu)通(tong)(tong)信(xin)(xin)(xin)(xin)標示,來獲取傳(chuan)(chuan)輸(shu)(shu)(shu)數(shu)據(ju)(ju)內容,并加以(yi)校驗,如果經(jing)校驗后(hou)發(fa)(fa)生差錯,目(mu)(mu)標通(tong)(tong)信(xin)(xin)(xin)(xin)設(she)備(bei)(bei)會(hui)發(fa)(fa)出(chu)TCP/IP信(xin)(xin)(xin)(xin)息重發(fa)(fa)報(bao)文,讓發(fa)(fa)送通(tong)(tong)信(xin)(xin)(xin)(xin)設(she)備(bei)(bei)再次將(jiang)TCP/IP通(tong)(tong)信(xin)(xin)(xin)(xin)報(bao)文發(fa)(fa)展目(mu)(mu)標通(tong)(tong)信(xin)(xin)(xin)(xin)設(she)備(bei)(bei),去(qu)掉通(tong)(tong)信(xin)(xin)(xin)(xin)標示來獲取傳(chuan)(chuan)輸(shu)(shu)(shu)數(shu)據(ju)(ju)信(xin)(xin)(xin)(xin)息。

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

在互(hu)聯(lian)網絡中,基于TCP/IP通(tong)(tong)(tong)信(xin)協(xie)議(yi)(yi)(yi)(yi)傳(chuan)輸(shu)的(de)(de)數據(ju)內(nei)(nei)容(rong)都是(shi)以(yi)(yi)通(tong)(tong)(tong)信(xin)報文(wen)(wen)(wen)(wen)的(de)(de)形式(shi)在互(hu)聯(lian)網絡內(nei)(nei)部進行(xing)(xing)傳(chuan)輸(shu),通(tong)(tong)(tong)信(xin)報文(wen)(wen)(wen)(wen)實質(zhi)上(shang)就(jiu)是(shi)一串(chuan)(chuan)二進制字符串(chuan)(chuan),而字符串(chuan)(chuan)內(nei)(nei)不同位置的(de)(de)二進制字符標示不同的(de)(de)含義。從TCP/IP通(tong)(tong)(tong)信(xin)協(xie)議(yi)(yi)(yi)(yi)的(de)(de)主要報文(wen)(wen)(wen)(wen)格式(shi)可(ke)以(yi)(yi)看出,IP協(xie)議(yi)(yi)(yi)(yi)是(shi)基于TCP協(xie)議(yi)(yi)(yi)(yi)至上(shang)的(de)(de),TCP協(xie)議(yi)(yi)(yi)(yi)報文(wen)(wen)(wen)(wen)時作為(wei)IP通(tong)(tong)(tong)信(xin)報文(wen)(wen)(wen)(wen)的(de)(de)數據(ju)部分來進行(xing)(xing)傳(chuan)輸(shu)的(de)(de)。實際上(shang),互(hu)聯(lian)網內(nei)(nei)傳(chuan)輸(shu)的(de)(de)通(tong)(tong)(tong)信(xin)字符串(chuan)(chuan)還有(you)其他的(de)(de)通(tong)(tong)(tong)信(xin)協(xie)議(yi)(yi)(yi)(yi),TCP/IP通(tong)(tong)(tong)信(xin)報文(wen)(wen)(wen)(wen)也是(shi)作為(wei)其外層(ceng)協(xie)議(yi)(yi)(yi)(yi)的(de)(de)通(tong)(tong)(tong)信(xin)數據(ju)部分嵌(qian)入到通(tong)(tong)(tong)信(xin)報文(wen)(wen)(wen)(wen)中在互(hu)聯(lian)網內(nei)(nei)進行(xing)(xing)傳(chuan)輸(shu)。

在(zai)IP協(xie)議(yi)(yi)(yi)首(shou)部,包含了(le)一些關于IP協(xie)議(yi)(yi)(yi)的(de)(de)標(biao)(biao)(biao)示(shi)、通(tong)(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)地(di)址(zhi)等(deng)信(xin)(xin)(xin)(xin)(xin)息(xi),主要(yao)包括數(shu)(shu)據(ju)字符串總長度的(de)(de)信(xin)(xin)(xin)(xin)(xin)息(xi)、通(tong)(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)標(biao)(biao)(biao)示(shi)號(hao)、源IP地(di)址(zhi)和目(mu)(mu)標(biao)(biao)(biao)IP地(di)址(zhi)等(deng)信(xin)(xin)(xin)(xin)(xin)息(xi),當IP通(tong)(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)報(bao)文(wen)(wen)(wen)經過路由尋址(zhi)時,會(hui)根(gen)據(ju)首(shou)部內記(ji)錄的(de)(de)目(mu)(mu)標(biao)(biao)(biao)IP地(di)址(zhi)來選擇(ze)(ze)傳輸(shu)(shu)方向(xiang),最終根(gen)據(ju)目(mu)(mu)標(biao)(biao)(biao)IP地(di)址(zhi)傳輸(shu)(shu)至目(mu)(mu)標(biao)(biao)(biao)通(tong)(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)設(she)(she)備(bei)(bei)。此(ci)外,IP通(tong)(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)報(bao)文(wen)(wen)(wen)首(shou)部還(huan)包含其他信(xin)(xin)(xin)(xin)(xin)息(xi),比如(ru)IP協(xie)議(yi)(yi)(yi)版本號(hao)、首(shou)部長度、校驗(yan)信(xin)(xin)(xin)(xin)(xin)息(xi)、該(gai)(gai)IP通(tong)(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)報(bao)文(wen)(wen)(wen)生存時間(即該(gai)(gai)報(bao)文(wen)(wen)(wen)經過多(duo)少個路由后自動取消傳輸(shu)(shu))等(deng)與IP通(tong)(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)報(bao)文(wen)(wen)(wen)相關的(de)(de)信(xin)(xin)(xin)(xin)(xin)息(xi),以確保(bao)IP報(bao)文(wen)(wen)(wen)傳輸(shu)(shu)的(de)(de)正確性和安(an)全性。TCP協(xie)議(yi)(yi)(yi)通(tong)(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)報(bao)文(wen)(wen)(wen)是作為IP通(tong)(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)報(bao)文(wen)(wen)(wen)數(shu)(shu)據(ju)內容存在(zai)的(de)(de),TCP協(xie)議(yi)(yi)(yi)也分為TCP報(bao)文(wen)(wen)(wen)首(shou)部和TCP通(tong)(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)數(shu)(shu)據(ju)。TCP通(tong)(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)報(bao)文(wen)(wen)(wen)首(shou)部主要(yao)包括了(le)源端(duan)(duan)口(kou)號(hao)和目(mu)(mu)標(biao)(biao)(biao)端(duan)(duan)口(kou)號(hao)等(deng)信(xin)(xin)(xin)(xin)(xin)息(xi),當TCP/IP通(tong)(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)報(bao)文(wen)(wen)(wen)經過互聯(lian)網(wang)絡到(dao)達目(mu)(mu)標(biao)(biao)(biao)通(tong)(tong)(tong)(tong)過新設(she)(she)備(bei)(bei)后,通(tong)(tong)(tong)(tong)信(xin)(xin)(xin)(xin)(xin)設(she)(she)備(bei)(bei)會(hui)根(gen)據(ju)TCP報(bao)文(wen)(wen)(wen)首(shou)部的(de)(de)目(mu)(mu)的(de)(de)端(duan)(duan)口(kou)號(hao)選擇(ze)(ze)設(she)(she)備(bei)(bei)端(duan)(duan)口(kou)號(hao)來接受(shou)該(gai)(gai)數(shu)(shu)據(ju)信(xin)(xin)(xin)(xin)(xin)息(xi),進而實現互聯(lian)網(wang)絡的(de)(de)數(shu)(shu)據(ju)傳輸(shu)(shu)。

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

互(hu)(hu)聯(lian)網絡(luo)(luo)的(de)通(tong)信(xin)(xin)(xin)設(she)備(bei)(bei)(bei)基于TCP/IP協(xie)議建(jian)立通(tong)信(xin)(xin)(xin)過程,也(ye)是根據(ju)(ju)(ju)TCP/IP協(xie)議來實現的(de)。當(dang)(dang)源通(tong)信(xin)(xin)(xin)設(she)備(bei)(bei)(bei)想(xiang)向目(mu)標(biao)設(she)備(bei)(bei)(bei)發(fa)送(song)數據(ju)(ju)(ju)時(shi),首(shou)先會(hui)發(fa)送(song)一個TCP/IP通(tong)信(xin)(xin)(xin)報(bao)文來確認連(lian)接,該通(tong)信(xin)(xin)(xin)報(bao)文在互(hu)(hu)聯(lian)網絡(luo)(luo)中經過尋找傳(chuan)輸后找到目(mu)標(biao)設(she)備(bei)(bei)(bei),目(mu)標(biao)設(she)備(bei)(bei)(bei)也(ye)會(hui)向源通(tong)信(xin)(xin)(xin)設(she)備(bei)(bei)(bei)發(fa)送(song)一個TCP/IP報(bao)文以確認建(jian)立通(tong)信(xin)(xin)(xin)連(lian)接,此時(shi),源通(tong)信(xin)(xin)(xin)設(she)備(bei)(bei)(bei)就會(hui)將通(tong)信(xin)(xin)(xin)數據(ju)(ju)(ju)以TCP/IP通(tong)信(xin)(xin)(xin)報(bao)文的(de)形(xing)式進行數據(ju)(ju)(ju)打包,然后向目(mu)標(biao)數據(ju)(ju)(ju)進行傳(chuan)輸,在收(shou)到數據(ju)(ju)(ju)后,目(mu)標(biao)設(she)備(bei)(bei)(bei)同樣(yang)會(hui)發(fa)送(song)TCP/IP報(bao)文以確認收(shou)到信(xin)(xin)(xin)息。當(dang)(dang)然,TCP/IP通(tong)信(xin)(xin)(xin)數據(ju)(ju)(ju)長(chang)度是一定的(de),當(dang)(dang)通(tong)信(xin)(xin)(xin)數據(ju)(ju)(ju)超過報(bao)文長(chang)度時(shi),源通(tong)信(xin)(xin)(xin)設(she)備(bei)(bei)(bei)會(hui)將其分段(duan)發(fa)送(song),而目(mu)標(biao)設(she)備(bei)(bei)(bei)則會(hui)根據(ju)(ju)(ju)IP報(bao)文首(shou)部的(de)標(biao)識號進行數據(ju)(ju)(ju)重(zhong)組來重(zhong)現傳(chuan)輸數據(ju)(ju)(ju)信(xin)(xin)(xin)息,進而完成互(hu)(hu)聯(lian)網絡(luo)(luo)通(tong)信(xin)(xin)(xin)設(she)備(bei)(bei)(bei)數據(ju)(ju)(ju)傳(chuan)輸。

3 總結

TCP/IP網(wang)絡協議是(shi)當前互(hu)聯網(wang)絡最基本的通信(xin)(xin)協議。根(gen)據(ju)(ju)TCP/IP網(wang)絡協議,連接在(zai)(zai)互(hu)聯網(wang)內(nei)(nei)(nei)的通信(xin)(xin)設備可(ke)以根(gen)據(ju)(ju)TCP/IP通信(xin)(xin)報文格式的內(nei)(nei)(nei)容(rong)將(jiang)傳(chuan)輸數(shu)據(ju)(ju)打包在(zai)(zai)TCP/IP通信(xin)(xin)報文內(nei)(nei)(nei),并以其規定的通信(xin)(xin)流程(cheng)進行數(shu)據(ju)(ju)傳(chuan)輸,從而實現互(hu)聯網(wang)絡內(nei)(nei)(nei)的數(shu)據(ju)(ju)高(gao)效安(an)全的傳(chuan)輸。

參考文獻:

[1]楊紹(shao)文.談計(ji)算機網絡的(de)TCP/IP協議[J].科(ke)技信息.2011(02)

[2]查東輝(hui).試論計算(suan)機網(wang)絡通(tong)信協議[J].電(dian)腦知(zhi)識與技術.2013(14)

[3]楊嬌娟.淺談(tan)TCP/IP協議[J].數字技(ji)術與應用(yong).2012(03)

篇5

關鍵詞(ci):嵌入式系(xi)統;以(yi)太網;TCP/IP協議;UDP;ARP

中圖(tu)分類號(hao)(hao):TP393文(wen)獻標識碼:A文(wen)章(zhang)編號(hao)(hao):1009-3044(2007)04-10947-03

1 引言

目前(qian),嵌(qian)入(ru)(ru)(ru)式(shi)(shi)系(xi)統與網絡(luo)的(de)(de)結合已經成為(wei)嵌(qian)入(ru)(ru)(ru)式(shi)(shi)系(xi)統發展過程中所必(bi)須要(yao)面(mian)對(dui)的(de)(de)問題(ti)之一(yi)。嵌(qian)入(ru)(ru)(ru)式(shi)(shi)系(xi)統的(de)(de)網絡(luo)接(jie)入(ru)(ru)(ru)一(yi)般可以通(tong)過RS-232或RS-485等間接(jie)接(jie)入(ru)(ru)(ru),也可以通(tong)過網絡(luo)協(xie)(xie)議(yi)直(zhi)接(jie)與網絡(luo)相互連,其中,直(zhi)接(jie)接(jie)入(ru)(ru)(ru)方(fang)(fang)式(shi)(shi)正逐步成為(wei)嵌(qian)入(ru)(ru)(ru)式(shi)(shi)系(xi)統接(jie)入(ru)(ru)(ru)網絡(luo)的(de)(de)主要(yao)方(fang)(fang)式(shi)(shi),但是(shi)需(xu)要(yao)精簡TCP/IP協(xie)(xie)議(yi)棧(zhan)的(de)(de)支(zhi)持。目前(qian)使用(yong)廣(guang)泛的(de)(de)通(tong)用(yong)TCP/IP協(xie)(xie)議(yi)棧(zhan)所包含的(de)(de)協(xie)(xie)議(yi)內容(rong)比(bi)較全,但同(tong)時也比(bi)較復(fu)雜。由于硬件平臺(tai)的(de)(de)差別(bie),這些協(xie)(xie)議(yi)站(zhan)無(wu)法直(zhi)接(jie)應用(yong)于嵌(qian)入(ru)(ru)(ru)式(shi)(shi)系(xi)統,主要(yao)表現在以下(xia)三(san)個方(fang)(fang)面(mian):

(1)嵌入(ru)式操作系統都面向特(te)定的領域和需(xu)求(qiu),嵌入(ru)式應(ying)用(yong)對實時性要求(qiu)比較高(gao)。

(2)多任務操(cao)作系(xi)統(tong)的(de)內存分配是動(dong)態的(de),但是在嵌入(ru)式(shi)系(xi)統(tong)中片RAM是靜態分配的(de),用于存放收(shou)到的(de)數據包的(de)的(de)空間很有限。

(3)嵌入式系統在(zai)程(cheng)序的具(ju)體(ti)實現上與通用(yong)計算機系統有所(suo)不同(tong),主要體(ti)現在(zai)指針、參數(shu)傳遞、變(bian)量和(he)數(shu)據結構的定義等方面。

因此(ci),需要通用TCP/IP協議棧的基礎(chu)上進行精(jing)簡和改寫,以(yi)設計出精(jing)簡、高(gao)效的TCP/IP協議子集,以(yi)供嵌入式(shi)系統(tong)接(jie)入網絡使用。

2 TCP協議(yi)分析與(yu)簡化

通用計算(suan)機(ji)系(xi)統(tong)有(you)足夠的(de)資源支(zhi)持,但是嵌入(ru)(ru)式系(xi)統(tong)則(ze)不(bu)同,因(yin)為(wei)其CPU處理(li)能力和(he)系(xi)統(tong)存儲能力都受到(dao)成本限制,充分(fen)利用資源、提高系(xi)統(tong)性價比是開發嵌入(ru)(ru)式應用的(de)根本特點。

2.1 嵌入(ru)式(shi)TCP/IP協(xie)議棧的特點

嵌(qian)入式(shi)系統一般都是為了滿足某一特定的(de)(de)需(xu)求,對(dui)網絡支(zhi)持的(de)(de)要(yao)(yao)求相(xiang)(xiang)對(dui)比(bi)較低,需(xu)要(yao)(yao)什么(me)協(xie)議就(jiu)添加相(xiang)(xiang)應(ying)(ying)的(de)(de)模(mo)塊,不需(xu)使用完整的(de)(de)TCP/IP協(xie)議。嵌(qian)入式(shi)TCP/IP協(xie)議棧應(ying)(ying)具有以下(xia)的(de)(de)特點:

(1)代碼比較簡潔,占用的(de)存儲空間盡可(ke)能小,盡可(ke)能為應(ying)用程序節(jie)省系(xi)統資源。

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

(3)便于裁剪和擴展,對(dui)于面向不(bu)同應(ying)用的嵌入式系(xi)統應(ying)當根據特點對(dui)協(xie)議(yi)進行簡化(hua)或擴展,整個(ge)協(xie)議(yi)棧在滿足功(gong)能(neng)需求的前提下(xia)盡可能(neng)精簡。

TCP/IP協(xie)議(yi)棧具有(you)層次特性(xing),各個協(xie)議(yi)都有(you)自己的(de)(de)數(shu)(shu)據(ju)(ju)格式,每(mei)次發送數(shu)(shu)據(ju)(ju)都要(yao)進(jin)(jin)行上下(xia)層協(xie)議(yi)的(de)(de)數(shu)(shu)據(ju)(ju)交(jiao)換(huan),進(jin)(jin)行打(da)包和拆包的(de)(de)過(guo)程,在這個過(guo)程中如果采用(yong)數(shu)(shu)據(ju)(ju)拷(kao)貝(bei)的(de)(de)策略(lve)進(jin)(jin)行數(shu)(shu)據(ju)(ju)傳遞(di)則(ze)會大(da)大(da)增加(jia)系(xi)(xi)統開銷。在嵌入式系(xi)(xi)統中,往往無法建立起(qi)數(shu)(shu)據(ju)(ju)傳遞(di)的(de)(de)緩沖區,需要(yao)采用(yong)“零拷(kao)貝(bei)”技術(shu)用(yong)傳遞(di)數(shu)(shu)據(ju)(ju)指針的(de)(de)方(fang)法來解決(jue)各層協(xie)議(yi)間(jian)的(de)(de)數(shu)(shu)據(ju)(ju)傳遞(di),以提高(gao)系(xi)(xi)統的(de)(de)實時(shi)性(xing)能(neng)。

2.2 TCP/IP協議的精(jing)簡(jian)

TCP/IP是幾百種網絡協(xie)議的集合。通(tong)用計算機(ji)系統有足夠的資源(yuan)支持通(tong)信協(xie)議在(zai)內核實現,因此完(wan)整的TCP/IP協(xie)議棧(如圖1)能夠在(zai)數(shu)據傳(chuan)輸的可靠性和數(shu)據流量的控制上做很多工(gong)作。

但是對(dui)于嵌入(ru)式系統來(lai)說,其硬件資源十分有(you)限,同時(shi)對(dui)協議(yi)(yi)的(de)要(yao)求也(ye)相對(dui)較低,必須對(dui)通用的(de)TCP/IP協議(yi)(yi)進行精簡。進行精簡的(de)途(tu)徑有(you)兩種:

(1)將無關于系(xi)統功能(neng)的協(xie)議(yi)削減掉。即保留必需的協(xie)議(yi),而對其它無關協(xie)議(yi)進行裁剪。

(2)對單獨的(de)(de)協議進行簡(jian)化。例如完整的(de)(de)ARP協議支持以太(tai)網(wang)(wang)、令牌環等網(wang)(wang)絡(luo),但是(shi)嵌入式系統可能是(shi)面向于(yu)某一具體類型網(wang)(wang)絡(luo)的(de)(de),對于(yu)其(qi)他(ta)的(de)(de)部分就可以簡(jian)化掉。

圖1

簡化后的協議(yi)(yi)仍然(ran)需(xu)(xu)要(yao)(yao)符合規定的標準:在網(wang)絡接口層(ceng),系統(tong)需(xu)(xu)實現ARP應(ying)答協議(yi)(yi),該(gai)協議(yi)(yi)用于將IP地(di)址映(ying)射成以(yi)太(tai)網(wang)MAC地(di)址;在網(wang)際(ji)層(ceng),需(xu)(xu)要(yao)(yao)實現IP協議(yi)(yi),主要(yao)(yao)負責IP報(bao)文(wen)報(bao)頭(tou)的正確性,并且對TCP和ICMP報(bao)文(wen)實行分流,此(ci)外,為(wei)了能夠測(ce)試系統(tong)與網(wang)絡的連接,在網(wang)際(ji)層(ceng)還需(xu)(xu)要(yao)(yao)實現ICMP協議(yi)(yi)中(zhong)的Ping應(ying)答協議(yi)(yi),主要(yao)(yao)用于檢(jian)查網(wang)絡在傳輸層(ceng)是否連通。作為(wei)運輸層(ceng)的主要(yao)(yao)協議(yi)(yi),TCP和UDP協議(yi)(yi)一(yi)般(ban)都不能缺少(shao),對于具體的應(ying)用,一(yi)般(ban)都至少(shao)要(yao)(yao)實現其(qi)中(zhong)之一(yi)。HTTP、FTP等應(ying)用層(ceng)協議(yi)(yi)一(yi)般(ban)無需(xu)(xu)實現。這樣簡化后,就可以(yi)得到圖2所(suo)示的嵌(qian)入式TCP/IP協議(yi)(yi)棧的結構(gou):

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

3 各協議的具體實現

本文(wen)實現的嵌入式TCP/IP協議運(yun)行(xing)于以89C51單片機和RTL8019AS網(wang)絡控制器為核心(xin)元件的硬(ying)件平臺上,協議代碼在(zai)(zai)Keil C51 V7.0環境下編寫。在(zai)(zai)程序的initial文(wen)件中(zhong)提供了相關函數對89C51和RTL8019AS進(jin)行(xing)了初始參數設(she)置(zhi),限于文(wen)章篇幅,與(yu)具(ju)體硬(ying)件相關的問題(ti)不再作(zuo)詳細說明。

3.1 ARP協議(yi)的實現

ARP協議不攜帶用(yong)戶的(de)(de)有(you)效數據,報頭長度為(wei)28字節(jie)。在(zai)ARP報頭中(zhong)(zhong)操作碼域(yu)表(biao)明了(le)(le)ARP包(bao)是(shi)ARP請求(qiu)還(huan)是(shi)ARP回答,其值為(wei)1時(shi)(shi)為(wei)請求(qiu),為(wei)2時(shi)(shi)為(wei)應(ying)答。目(mu)(mu)標(biao)以(yi)太地址(zhi)(zhi)為(wei)目(mu)(mu)標(biao)節(jie)點(dian)IP對應(ying)的(de)(de)MAC地址(zhi)(zhi),解析(xi)(xi)(xi)前是(shi)未知的(de)(de)。發送ARP請求(qiu)應(ying)使(shi)用(yong)廣播方式,網(wang)段(duan)內的(de)(de)各(ge)個(ge)(ge)(ge)主機(ji)收到后檢(jian)查包(bao)內的(de)(de)IP地址(zhi)(zhi),如果(guo)和本機(ji)的(de)(de)IP地址(zhi)(zhi)一樣則(ze)使(shi)用(yong)單播的(de)(de)方式返回ARP應(ying)答,在(zai)應(ying)答ARP包(bao)中(zhong)(zhong)源以(yi)太地址(zhi)(zhi)的(de)(de)域(yu)中(zhong)(zhong)填入(ru)自己的(de)(de)MAC地址(zhi)(zhi)。在(zai)具體設計(ji)時(shi)(shi),要(yao)(yao)考慮到系統(tong)解析(xi)(xi)(xi)地址(zhi)(zhi)的(de)(de)實時(shi)(shi)性(xing),如果(guo)每次互聯都要(yao)(yao)進(jin)行地址(zhi)(zhi)解析(xi)(xi)(xi),則(ze)系統(tong)的(de)(de)實時(shi)(shi)性(xing)要(yao)(yao)下(xia)降,一般的(de)(de)做法是(shi)建(jian)立一個(ge)(ge)(ge)ARP地址(zhi)(zhi)映(ying)射表(biao),存(cun)放常用(yong)IP地址(zhi)(zhi)與MAC地址(zhi)(zhi)的(de)(de)映(ying)射,這樣在(zai)解析(xi)(xi)(xi)地址(zhi)(zhi)時(shi)(shi)首先遍(bian)歷(li)該(gai)表(biao),如果(guo)目(mu)(mu)標(biao)地址(zhi)(zhi)已經被解析(xi)(xi)(xi)過則(ze)可以(yi)省去解析(xi)(xi)(xi)過程了(le)(le)。解析(xi)(xi)(xi)過程中(zhong)(zhong)還(huan)需要(yao)(yao)為(wei)ARP緩(huan)存(cun)中(zhong)(zhong)每個(ge)(ge)(ge)新(xin)生(sheng)成條目(mu)(mu)賦予一個(ge)(ge)(ge)初始生(sheng)存(cun)時(shi)(shi)間,使(shi)用(yong)定(ding)時(shi)(shi)器中(zhong)(zhong)斷,經過某一時(shi)(shi)間間隔對所有(you)條目(mu)(mu)進(jin)行刷(shua)新(xin)檢(jian)測(ce),若發現(xian)有(you)條目(mu)(mu)發生(sheng)超(chao)時(shi)(shi),將其從(cong)ARP緩(huan)存(cun)中(zhong)(zhong)刪除(chu)。ARP緩(huan)存(cun)條目(mu)(mu)結構設計(ji)如下(xia):

typedef struct

{unsigned long ip_addr; //IP地址

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

unsigned char timer; //定時器(qi)}

ARP_CACHE; //ARP緩存條目結構

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

IP協(xie)議(yi)是TCP/IP協(xie)議(yi)族中最為核(he)心的(de)(de)(de)(de)協(xie)議(yi)。所有(you)(you)(you)的(de)(de)(de)(de)TCP、UDP、ICMP及IGMP包都以(yi)(yi)IP數據(ju)報(bao)(bao)(bao)(bao)格式傳輸(shu)。IP報(bao)(bao)(bao)(bao)頭的(de)(de)(de)(de)標準長度(du)為20字節。在具(ju)體項目中由于數據(ju)量比較小,可(ke)以(yi)(yi)不考慮數據(ju)報(bao)(bao)(bao)(bao)分(fen)段(duan)的(de)(de)(de)(de)問題,即(ji)不允(yun)許(xu)數據(ju)報(bao)(bao)(bao)(bao)超出IP包的(de)(de)(de)(de)有(you)(you)(you)效(xiao)載(zai)荷(he)。標準以(yi)(yi)太網幀數據(ju)域為1500字節,除去IP頭之外還有(you)(you)(you)1480字節可(ke)以(yi)(yi)為上(shang)層(ceng)協(xie)議(yi)提(ti)供有(you)(you)(you)效(xiao)的(de)(de)(de)(de)數據(ju)載(zai)荷(he),應該能夠滿足數據(ju)傳送的(de)(de)(de)(de)要求。這樣簡化可(ke)以(yi)(yi)省去軟件處理IP數據(ju)分(fen)段(duan)和(he)重組的(de)(de)(de)(de)開(kai)銷,可(ke)以(yi)(yi)提(ti)高系統數據(ju)傳輸(shu)的(de)(de)(de)(de)實時性。IP協(xie)議(yi)對上(shang)一(yi)(yi)層(ceng)傳下(xia)來的(de)(de)(de)(de)報(bao)(bao)(bao)(bao)文(wen)加上(shang)IP首部(bu)和(he)IP校(xiao)驗和(he)并發往(wang)下(xia)一(yi)(yi)層(ceng),同(tong)時還要對下(xia)一(yi)(yi)層(ceng)傳上(shang)來的(de)(de)(de)(de)報(bao)(bao)(bao)(bao)文(wen)進(jin)行校(xiao)驗和(he)檢查,將校(xiao)驗正(zheng)確的(de)(de)(de)(de)去掉IP首部(bu),送往(wang)上(shang)一(yi)(yi)層(ceng)。

為了便于測試,需要(yao)實現(xian)PING程序,在收(shou)到ICMP的(de)回(hui)顯(xian)請求包后(hou)按(an)照(zhao)格式組(zu)裝一個ICMP的(de)回(hui)顯(xian)應(ying)答包并發送。相關的(de)主要(yao)函數有:

void ping_request() //PING請求

void ping_answer() //PING應答

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

3.3 UDP協議的實現

UDP際上(shang)是(shi)直接(jie)(jie)利用(yong)IP協(xie)(xie)(xie)議進行數據(ju)(ju)(ju)(ju)(ju)報(bao)的(de)(de)傳(chuan)(chuan)輸,也就(jiu)是(shi)將報(bao)文(wen)包含在(zai)IP數據(ju)(ju)(ju)(ju)(ju)包中(zhong) 。UDP的(de)(de)數據(ju)(ju)(ju)(ju)(ju)傳(chuan)(chuan)輸是(shi)無(wu)連(lian)接(jie)(jie),不可(ke)(ke)靠(kao)(kao)的(de)(de),因為(wei)它不像(xiang)TCP那樣,為(wei)了(le)達(da)到(dao)目標(biao),首(shou)先要(yao)(yao)在(zai)兩點(dian)之(zhi)間建立(li)一(yi)個(ge)可(ke)(ke)靠(kao)(kao)的(de)(de)連(lian)接(jie)(jie),因此UDP協(xie)(xie)(xie)議無(wu)法保證數據(ju)(ju)(ju)(ju)(ju)可(ke)(ke)靠(kao)(kao)性。但UDP協(xie)(xie)(xie)議具(ju)有對(dui)(dui)網絡資源(yuan)(yuan)開銷較小,數據(ju)(ju)(ju)(ju)(ju)處理速度快的(de)(de)優(you)點(dian),UDP協(xie)(xie)(xie)議屬(shu)于簡單(dan)的(de)(de)端(duan)到(dao)端(duan)的(de)(de)數據(ju)(ju)(ju)(ju)(ju)傳(chuan)(chuan)輸協(xie)(xie)(xie)議,其報(bao)頭(tou)只有8字節,其中(zhong)源(yuan)(yuan)端(duan)口表示UDP應用(yong)進程的(de)(de)端(duan)口號(hao),除了(le)0~1023預定的(de)(de)端(duan)口外,其余的(de)(de)都可(ke)(ke)以使用(yong)。具(ju)體實現時要(yao)(yao)完成對(dui)(dui)應用(yong)層(ceng)傳(chuan)(chuan)下(xia)來(lai)的(de)(de)數據(ju)(ju)(ju)(ju)(ju)包,加上(shang)UDP首(shou)部(bu)和(he)UDP校(xiao)驗和(he),發往下(xia)一(yi)層(ceng)。以及對(dui)(dui)下(xia)一(yi)層(ceng)傳(chuan)(chuan)上(shang)來(lai)的(de)(de)數據(ju)(ju)(ju)(ju)(ju)包,進行校(xiao)驗和(he)檢查,若(ruo)正(zheng)確(que)去掉UDP首(shou)部(bu),提出數據(ju)(ju)(ju)(ju)(ju)送(song)給應用(yong)層(ceng)。需注意(yi)的(de)(de)是(shi),要(yao)(yao)產生一(yi)個(ge)偽首(shou)部(bu)用(yong)于UDP數據(ju)(ju)(ju)(ju)(ju)檢驗和(he)計算,涉及到(dao)的(de)(de)主要(yao)(yao)函數有:

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

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

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

3.4 TCP協議(yi)的實現

TCP協議(yi)是面(mian)向連接的、端(duan)對端(duan)的可靠通(tong)信協議(yi),可分以下幾個步驟實現(xian):

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

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

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

TCP協(xie)(xie)議(yi)的(de)功能是為(wei)應(ying)(ying)用層(ceng)協(xie)(xie)議(yi)提供(gong)可靠的(de)面向(xiang)連接(jie)的(de)數據傳輸服(fu)(fu)務(wu),是嵌入式應(ying)(ying)用系統協(xie)(xie)議(yi)棧(zhan)中(zhong)最為(wei)復雜(za)的(de)協(xie)(xie)議(yi)。在(zai)(zai)TCP協(xie)(xie)議(yi)實(shi)現(xian)中(zhong),由于請(qing)(qing)求(qiu)發起端(客(ke)戶(hu)端)與(yu)請(qing)(qing)求(qiu)相應(ying)(ying)端(服(fu)(fu)務(wu)器端)在(zai)(zai)通(tong)信(xin)(xin)中(zhong)所處地位(wei)不(bu)同,相應(ying)(ying)地兩(liang)者的(de)中(zhong)間演變(bian)狀(zhuang)(zhuang)態(tai)也不(bu)完全相同。客(ke)戶(hu)端與(yu)服(fu)(fu)務(wu)器端在(zai)(zai)一(yi)個(ge)TCP連接(jie)從正(zheng)常(chang)建立(li)到正(zheng)常(chang)中(zhong)止分別經歷5個(ge)和(he)6個(ge)狀(zhuang)(zhuang)態(tai),相應(ying)(ying)控制信(xin)(xin)息均在(zai)(zai)TCP頭部信(xin)(xin)息的(de)6位(wei)控制標記位(wei)中(zhong)得以(yi)表示。對于嵌入式系統中(zhong)TCP協(xie)(xie)議(yi)的(de)實(shi)現(xian),應(ying)(ying)從嵌入式應(ying)(ying)用的(de)角度出發,盡可能減(jian)少冗余狀(zhuang)(zhuang)態(tai)。程序中(zhong)需要構造一(yi)個(ge)TCP_STATUS結構來記錄每一(yi)個(ge)TCP連接(jie)的(de)狀(zhuang)(zhuang)態(tai)信(xin)(xin)息,其(qi)結構如下:

typedef struct

{unsigned long ip_addr; //源IP 地址

unsigned int port; //端口號

unsigned long remo_sequ; //對方(fang)序(xu)列(lie)號

unsigned long local_sequ; //本方序列號

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

unsigned long remo_ack; //對(dui)方應(ying)答號

unsigned char timer; //超時用(yong)定時器

unsigned char quiet; //連接活(huo)動性

unsigned char state; //當前狀(zhuang)態

}TCP_STATUS; //連接狀(zhuang)態(tai)結構

4 結束語

嵌入式(shi)系統(tong)的應(ying)用(yong)非常(chang)廣泛,解決嵌入式(shi)系統(tong)的網絡接入問題具(ju)有(you)十分重要的意義。本文實(shi)現的精簡(jian)TCP/IP協議(yi)(yi)棧在具(ju)體應(ying)用(yong)中有(you)良(liang)好(hao)表現,可以滿足(zu)正常(chang)的數(shu)據傳輸。由于設(she)計與(yu)實(shi)現的過程(cheng)中將應(ying)用(yong)層協議(yi)(yi)全部精簡(jian),協議(yi)(yi)在運(yun)行過程(cheng)中的流量控(kong)制能力及(ji)協議(yi)(yi)自身的安(an)全性(xing)都有(you)所(suo)下降,在對(dui)安(an)全性(xing)和穩(wen)定性(xing)要求較(jiao)高的應(ying)用(yong)場(chang)合(he)(如軍事、金融等領(ling)域(yu)),需要對(dui)協議(yi)(yi)的簡(jian)化有(you)所(suo)斟酌。

參考文獻:

 [1]羅蕾. 嵌入式(shi)實時操(cao)作系統及應用開發[M]. 北(bei)京(jing):北(bei)京(jing)航空航天大(da)學出版社. 2005.

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

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

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

篇6

【關(guan)鍵詞(ci)】計算機(ji)多線程 協議還原(yuan) 方法(fa)概述

1 協議并行處理(li)方法

1.1 數據包級別(bie)并行方法

在(zai)協議棧并行處(chu)理(li)方(fang)法(fa)(fa)中,數據包級別并行方(fang)法(fa)(fa)是一種并行度最高(gao)的(de)處(chu)理(li)方(fang)法(fa)(fa)。對(dui)于不同(tong)的(de)數據包都會(hui)按(an)照對(dui)應(ying)的(de)處(chu)理(li)器進行系列(lie)處(chu)理(li),達到同(tong)時處(chu)理(li)多(duo)個(ge)(ge)數據包或(huo)者是歸屬于同(tong)一個(ge)(ge)鏈接的(de)數據包。因(yin)巨大的(de)吞吐性(xing)能以及不存在(zai)負載(zai)均衡的(de)優勢得(de)(de)到了(le)廣泛運用。雖然其具有高(gao)度的(de)并發性(xing),但是在(zai)面對(dui)帶(dai)有上下(xia)文信息或(huo)狀(zhuang)態的(de)協議來(lai)說,例如TCP,可以獲得(de)(de)的(de)性(xing)能提(ti)升(sheng)空間受(shou)到了(le)很大的(de)約(yue)束(shu)。

1.2 函數級(ji)別(bie)并行方(fang)法

函(han)數(shu)(shu)級別并行方(fang)法主要運用于早(zao)期的(de)協(xie)議(yi)并行處(chu)(chu)理中(zhong)。早(zao)期協(xie)議(yi)是(shi)將鏈路控制(zhi)數(shu)(shu)據(ju)和傳送(song)數(shu)(shu)據(ju)置于同(tong)一個數(shu)(shu)據(ju)包(bao)中(zhong),這就(jiu)意味著(zhu)協(xie)議(yi)并行處(chu)(chu)理的(de)函(han)數(shu)(shu)必須(xu)要同(tong)時處(chu)(chu)理鏈路控制(zhi)數(shu)(shu)據(ju)外加上(shang)傳送(song)數(shu)(shu)據(ju),從而出現的(de)一個問題就(jiu)是(shi)協(xie)議(yi)處(chu)(chu)理函(han)數(shu)(shu)單元之(zhi)間務必會存在(zai)大量的(de)上(shang)下文相關(guan)結果(guo)。

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

協(xie)議(yi)棧層(ceng)次(ci)(ci)間并行方法主要(yao)運用(yong)于目(mu)(mu)前(qian)網(wang)絡協(xie)議(yi)的(de)(de)層(ceng)次(ci)(ci)結構(gou)(gou)中。在早期設(she)計(ji)相關網(wang)絡協(xie)議(yi)時,為(wei)了大幅度(du)的(de)(de)降低協(xie)議(yi)實(shi)現難(nan)度(du)而(er)將(jiang)每(mei)個層(ceng)次(ci)(ci)協(xie)議(yi)設(she)計(ji)成為(wei)了相對獨立(li)的(de)(de)部分,從而(er)完成獨立(li)層(ceng)間之間的(de)(de)并行處理。但是(shi)就目(mu)(mu)前(qian)實(shi)際情況來看(kan),這種方法雖然有許多的(de)(de)優勢,但是(shi)性能受到了層(ceng)次(ci)(ci)結構(gou)(gou)中吞(tun)吐量(liang)最低層(ceng)次(ci)(ci)結構(gou)(gou)的(de)(de)限制(zhi),所以(yi)目(mu)(mu)前(qian)需(xu)要(yao)對協(xie)議(yi)棧中的(de)(de)每(mei)一(yi)個層(ceng)次(ci)(ci)進行研究,優化吞(tun)吐量(liang)最低的(de)(de)層(ceng)次(ci)(ci)結構(gou)(gou)。

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

2.1 TCP/IP協(xie)議棧多線程并行化存在(zai)的問(wen)題(ti)

TCP/IP協(xie)議(yi)棧多線(xian)程并(bing)行化存在(zai)的(de)(de)問(wen)(wen)題(ti)主要(yao)存在(zai)于臨(lin)界鎖(suo)以及處(chu)理器(qi)之間(jian)的(de)(de)負(fu)(fu)載均衡情況(kuang)上。考慮到臨(lin)街鎖(suo)解決(jue)共享沖(chong)突的(de)(de)代價極大問(wen)(wen)題(ti),多線(xian)程并(bing)發程序(xu)雖然可以解決(jue)部分(fen)問(wen)(wen)題(ti),但是又帶來(lai)了諸如臨(lin)界區碰撞、內核陷入等等問(wen)(wen)題(ti),影響程序(xu)的(de)(de)運行效率。因(yin)此,對(dui)于多線(xian)程并(bing)行的(de)(de)TCP/IP協(xie)議(yi)而言,消除(chu)臨(lin)界鎖(suo)問(wen)(wen)題(ti)是至關重要(yao)的(de)(de)。對(dui)于處(chu)理器(qi)之間(jian)的(de)(de)負(fu)(fu)載均衡情況(kuang),需要(yao)考慮的(de)(de)就是協(xie)調好處(chu)理器(qi)之間(jian)的(de)(de)負(fu)(fu)載均衡問(wen)(wen)題(ti)。

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

本文所要(yao)分析的多線(xian)程(cheng)TCP/IP協議棧(zhan)結(jie)構主要(yao)還(huan)是(shi)共享內(nei)存(cun)多處理器(qi)平臺(tai)運行下的多線(xian)程(cheng)TCP/IP協議棧(zhan)結(jie)構,其(qi)基本的特點(dian)就是(shi)當共享內(nei)存(cun)對處理器(qi)平臺(tai)上(shang)的處理器(qi)數(shu)量增加時,其(qi)結(jie)構的性能也隨之(zhi)增加。多線(xian)程(cheng)TCP/IP協議棧(zhan)結(jie)構如圖(tu)1所示。

2.3 處理器均衡措施

處(chu)理(li)(li)(li)器(qi)(qi)(qi)均衡(heng)措施具體可以細化分為兩個步驟(zou)。第(di)一個步驟(zou)就是對IP數(shu)據(ju)包(bao)中的(de)三元組即源地址(zhi)、目的(de)地址(zhi)以及(ji)協議標識(shi),按照一定的(de)標準進行(xing)(xing)(xing)分發。僅(jin)僅(jin)采取第(di)一步不能夠對處(chu)理(li)(li)(li)器(qi)(qi)(qi)進行(xing)(xing)(xing)深度(du)的(de)處(chu)理(li)(li)(li),需要(yao)借助于(yu)第(di)二(er)個步驟(zou)。第(di)二(er)個步驟(zou)包(bao)括設置協議棧、促進操(cao)作系統借助于(yu)任務調度(du)完(wan)成負(fu)(fu)載均衡(heng)的(de)操(cao)作。后(hou)者的(de)時間點在于(yu)運行(xing)(xing)(xing)線(xian)程數(shu)不小于(yu)硬件平(ping)臺的(de)處(chu)理(li)(li)(li)器(qi)(qi)(qi)數(shu)量。按照上(shang)述順序,可以達到(dao)處(chu)理(li)(li)(li)器(qi)(qi)(qi)負(fu)(fu)載均衡(heng)的(de)目的(de)。

3 實驗方案結果

從本文的(de)(de)(de)實驗方(fang)案測試結(jie)果(guo)中(zhong)可(ke)以(yi)(yi)(yi)看(kan)出,首先單(dan)線程(cheng)下的(de)(de)(de)程(cheng)序(xu)只(zhi)能夠通(tong)過串來(lai)執行,從而不能夠發(fa)揮出處理(li)器(qi)(qi)的(de)(de)(de)實際性能。其(qi)次,在(zai)(zai)(zai)處理(li)器(qi)(qi)的(de)(de)(de)數(shu)(shu)量(liang)和線程(cheng)數(shu)(shu)量(liang)對等的(de)(de)(de)情況之下,也不能夠發(fa)揮出系統(tong)硬件的(de)(de)(de)全部性能。最后(hou),在(zai)(zai)(zai)處理(li)器(qi)(qi)數(shu)(shu)量(liang)小于(yu)協議棧線程(cheng)數(shu)(shu)量(liang)的(de)(de)(de)時點(dian),通(tong)過適當的(de)(de)(de)增加線程(cheng)數(shu)(shu)量(liang),可(ke)以(yi)(yi)(yi)在(zai)(zai)(zai)很大程(cheng)度上提高整個系統(tong)的(de)(de)(de)吞吐量(liang)。另(ling)外,對于(yu)內存(cun)分(fen)配方(fang)式對系統(tong)性能的(de)(de)(de)影響(xiang)上,結(jie)合實踐(jian)經驗以(yi)(yi)(yi)及(ji)實驗方(fang)案結(jie)構可(ke)以(yi)(yi)(yi)發(fa)現,相比PtMalloc以(yi)(yi)(yi)及(ji)SmartBits而言,FixMalloc可(ke)以(yi)(yi)(yi)降低(di)動態內存(cun)分(fen)配過程(cheng)中(zhong)出現的(de)(de)(de)處理(li)器(qi)(qi)消耗(hao),降低(di)的(de)(de)(de)幅度值大概(gai)在(zai)(zai)(zai)8.12%上下。

4 結束語

由于現代處理(li)器(qi)(qi)性(xing)(xing)能和網(wang)(wang)絡(luo)傳輸能力發(fa)展之間(jian)存(cun)在(zai)的(de)(de)(de)很(hen)大的(de)(de)(de)不(bu)平(ping)(ping)衡(heng),從而推進了多處理(li)器(qi)(qi)的(de)(de)(de)發(fa)展。本(ben)文從網(wang)(wang)絡(luo)協議(yi)還原技術出(chu)發(fa),提出(chu)了一(yi)整(zheng)套的(de)(de)(de)多線程(cheng)(cheng)并行的(de)(de)(de)TCP/IP協議(yi)的(de)(de)(de)相關(guan)還原方案。此(ci)外,在(zai)通用性(xing)(xing)的(de)(de)(de)多處理(li)器(qi)(qi)計(ji)算平(ping)(ping)臺的(de)(de)(de)實(shi)際操作過程(cheng)(cheng)中發(fa)現,雖然計(ji)算機多線程(cheng)(cheng)TCP/IP協議(yi)還原技術可以(yi)(yi)很(hen)好的(de)(de)(de)保障(zhang)當下(xia)處理(li)器(qi)(qi)平(ping)(ping)臺性(xing)(xing)能的(de)(de)(de)發(fa)揮,但是對(dui)于進一(yi)步提升網(wang)(wang)絡(luo)入侵監測系統協議(yi)還原能力以(yi)(yi)及挖掘高性(xing)(xing)能處理(li)器(qi)(qi)平(ping)(ping)臺,以(yi)(yi)此(ci)來協調處理(li)器(qi)(qi)性(xing)(xing)能和網(wang)(wang)絡(luo)傳輸能力發(fa)展不(bu)平(ping)(ping)衡(heng)的(de)(de)(de)矛(mao)盾,將是下(xia)一(yi)階段(duan)研究和探(tan)究的(de)(de)(de)重點內容(rong)。

參考文獻

[1]Bjorkman M,Gunningberg P Performance Modeling of Multiprocessor Implementations of Protocols[J],2009,11(03):142-145.

[2]田偉,顧韻(yun)華,丁(ding)妮.網(wang)絡行(xing)為(wei)監(jian)測(ce)與(yu)還原系統及關(guan)鍵技(ji)術研究[J].計(ji)算機工(gong)程與(yu)設計(ji),2011,29(02):111-113.

[3]譚敏生,湯(tang)亮.基于HTIP的網絡數據包還原技術研究[J].計算機技術與(yu)發展,2011,17(06):14-16.

篇7

關鍵詞:TCP/IP 溫度監測(ce) Arduino LabView

中圖分類號(hao)(hao):TP2 文(wen)獻標識碼:A 文(wen)章編號(hao)(hao):1007-9416(2015)09-0000-00

現(xian)場(chang)總線系(xi)統是一種傳統的(de)(de)(de)(de)雙向數(shu)字的(de)(de)(de)(de)通信(xin)標準(zhun)(zhun),廣泛(fan)應用(yong)于自(zi)(zi)動(dong)(dong)控制(zhi)領(ling)域(yu)和生產(chan)過(guo)程(cheng)(cheng)中(zhong)(zhong),但是由(you)于現(xian)場(chang)總線的(de)(de)(de)(de)種類繁多,且各(ge)(ge)標準(zhun)(zhun)間的(de)(de)(de)(de)相互(hu)兼容(rong)性不強,加上各(ge)(ge)廠(chang)商和標準(zhun)(zhun)制(zhi)訂(ding)組織之間存(cun)在利益競爭,各(ge)(ge)種現(xian)場(chang)總線技術(shu)(shu)無法(fa)實現(xian)無縫連(lian)接(jie),也(ye)無法(fa)將(jiang)生產(chan)現(xian)場(chang)的(de)(de)(de)(de)監控數(shu)據共享給企(qi)業(ye)的(de)(de)(de)(de)信(xin)息管理系(xi)統,而將(jiang)以(yi)太(tai)網(wang)(wang)技術(shu)(shu)引(yin)入到(dao)(dao)工(gong)(gong)業(ye)控制(zhi)領(ling)域(yu),將(jiang)監控數(shu)據進(jin)(jin)行(xing)標準(zhun)(zhun)的(de)(de)(de)(de)TCP/IP封裝,將(jiang)能很(hen)好的(de)(de)(de)(de)解決不同生產(chan)設(she)備間的(de)(de)(de)(de)高速連(lian)接(jie)問(wen)題和設(she)備的(de)(de)(de)(de)“自(zi)(zi)動(dong)(dong)化(hua)孤(gu)島(dao)”問(wen)題,最終將(jiang)生產(chan)自(zi)(zi)動(dong)(dong)化(hua)和辦公(gong)自(zi)(zi)動(dong)(dong)化(hua)無縫對接(jie),實現(xian)“一網(wang)(wang)到(dao)(dao)底”[1]。工(gong)(gong)業(ye)以(yi)太(tai)網(wang)(wang)是指在工(gong)(gong)業(ye)環境的(de)(de)(de)(de)自(zi)(zi)動(dong)(dong)化(hua)控制(zhi)及過(guo)程(cheng)(cheng)控制(zhi)中(zhong)(zhong)應用(yong)的(de)(de)(de)(de)相關(guan)組件及技術(shu)(shu),工(gong)(gong)業(ye)以(yi)太(tai)網(wang)(wang)多采用(yong)TCP/IP協議,和IEEE802.3標準(zhun)(zhun)兼容(rong)。溫(wen)度(du)是生產(chan)過(guo)程(cheng)(cheng)中(zhong)(zhong)重要的(de)(de)(de)(de)物理參數(shu)之一,在工(gong)(gong)業(ye)生產(chan)過(guo)程(cheng)(cheng)中(zhong)(zhong)經(jing)常(chang)要用(yong)到(dao)(dao)溫(wen)度(du)的(de)(de)(de)(de)檢測及控制(zhi),本文對基(ji)于TCP/IP網(wang)(wang)絡的(de)(de)(de)(de)遠(yuan)程(cheng)(cheng)溫(wen)度(du)檢測系(xi)統進(jin)(jin)行(xing)了(le)(le)設(she)計,給出了(le)(le)基(ji)于TCP/IP以(yi)太(tai)網(wang)(wang)的(de)(de)(de)(de)遠(yuan)程(cheng)(cheng)溫(wen)度(du)監測方案。

1 系統結構

1.1系統物理結構

使用標準的(de)(de)(de)TCP/IP協議實現(xian)(xian)現(xian)(xian)場層(ceng)與(yu)監(jian)(jian)控(kong)層(ceng)的(de)(de)(de)數據(ju)(ju)傳輸,其(qi)中現(xian)(xian)場層(ceng)通(tong)過(guo)(guo)連(lian)接廠內的(de)(de)(de)傳感器,實時獲取各種信(xin)息通(tong)過(guo)(guo)以太網(wang)絡傳送至(zhi)監(jian)(jian)控(kong)層(ceng),這(zhe)(zhe)一層(ceng)主(zhu)要(yao)由低功耗(hao)運行穩(wen)定的(de)(de)(de)嵌入式實現(xian)(xian);監(jian)(jian)控(kong)層(ceng)主(zhu)要(yao)是通(tong)過(guo)(guo)以太網(wang)絡連(lian)接廠內的(de)(de)(de)現(xian)(xian)場層(ceng)的(de)(de)(de)各個數據(ju)(ju)采集點(dian),將這(zhe)(zhe)些信(xin)息數據(ju)(ju)備份,存儲至(zhi)監(jian)(jian)控(kong)系統(tong)(tong)的(de)(de)(de)數據(ju)(ju)庫(ku),并在溫度(du)超過(guo)(guo)警示值時發(fa)出警報。本系統(tong)(tong)完成了(le)下位(wei)機數據(ju)(ju)采集與(yu)上位(wei)機數據(ju)(ju)監(jian)(jian)測的(de)(de)(de)功能,物理結構圖如圖1所示。

圖1 系統(tong)物理結(jie)構圖

1.2 系統邏輯結構

本系統(tong)的溫度信息(xi)由(you)數(shu)據(ju)(ju)采集結點通(tong)過以太網發(fa)送到監控層(ceng)計算機,并將歷史(shi)數(shu)據(ju)(ju)存儲致數(shu)據(ju)(ju)庫服務器(qi),企業的辦(ban)公(gong)網絡(luo)和外網用戶可通(tong)核心路由(you)器(qi)訪問數(shu)據(ju)(ju)庫,系統(tong)的數(shu)據(ju)(ju)在各(ge)層(ceng)中的流(liu)向如圖2所示。

圖2 系統(tong)邏輯結構

2 數據采集與發送端

2.1數(shu)字溫度采集點設(she)計(ji)

K型熱(re)電(dian)偶(ou)可以測量(liang)固體介(jie)質和汽液體蒸氣的(de)(de)(de)(de)(de)表面(mian)溫度(du)(du)(du),其測量(liang)范從0℃到1300℃[2]。具有(you)(you)很高的(de)(de)(de)(de)(de)靈敏度(du)(du)(du)和很好的(de)(de)(de)(de)(de)穩定(ding)性(xing)(xing),非線性(xing)(xing)誤差小,熱(re)電(dian)動勢較大,對于復(fu)雜環境(jing)下的(de)(de)(de)(de)(de)工(gong)業環境(jing)有(you)(you)很好的(de)(de)(de)(de)(de)適(shi)應性(xing)(xing)等優點(dian),因此(ci),在(zai)工(gong)業監控領域得到廣泛(fan)的(de)(de)(de)(de)(de)使(shi)用(yong)。但(dan)是(shi),由于其輸出(chu)熱(re)電(dian)勢與冷端(duan)(duan)溫度(du)(du)(du)相關(guan),輸出(chu)的(de)(de)(de)(de)(de)數(shu)(shu)據為模擬量(liang),且與被測量(liang)端(duan)(duan)的(de)(de)(de)(de)(de)溫度(du)(du)(du)有(you)(you)關(guan),因此(ci)需要進(jin)(jin)行溫度(du)(du)(du)補(bu)償和模數(shu)(shu)轉(zhuan)換。如(ru)果采(cai)用(yong)軟(ruan)件補(bu)償的(de)(de)(de)(de)(de)方法,一方面(mian)會增加程(cheng)序編制及(ji)調試電(dian)路的(de)(de)(de)(de)(de)難度(du)(du)(du),另(ling)一方面(mian),軟(ruan)件補(bu)償會占(zhan)用(yong)一定(ding)的(de)(de)(de)(de)(de)數(shu)(shu)字結點(dian)的(de)(de)(de)(de)(de)計算資源,而以太網(wang)使(shi)用(yong)了(le)(le)CSMA/CD,會產生數(shu)(shu)據傳送過程(cheng)中的(de)(de)(de)(de)(de)不確(que)定(ding)性(xing)(xing),影響精度(du)(du)(du)。所以,本系(xi)統采(cai)用(yong)了(le)(le)使(shi)用(yong)硬件進(jin)(jin)行溫度(du)(du)(du)補(bu)償的(de)(de)(de)(de)(de)方案,采(cai)用(yong)MAX6675串(chuan)行模數(shu)(shu)轉(zhuan)換器(qi)對采(cai)集的(de)(de)(de)(de)(de)數(shu)(shu)據進(jin)(jin)行處理(li),在(zai)進(jin)(jin)行溫度(du)(du)(du)補(bu)償的(de)(de)(de)(de)(de)同時,也提供了(le)(le)信號量(liang)為12位分辨(bian)率的(de)(de)(de)(de)(de)模數(shu)(shu)轉(zhuan)換,加強了(le)(le)與控制器(qi)數(shu)(shu)據通(tong)信的(de)(de)(de)(de)(de)兼容性(xing)(xing)[3]。

嵌入式控制(zhi)(zhi)器(qi)(qi)采(cai)用(yong)Arduino開(kai)源(yuan)硬(ying)件平臺(tai),它使用(yong)AtmelAVR單片(pian)機為核心處理器(qi)(qi),采(cai)用(yong)基于(yu)開(kai)放源(yuan)代碼的(de)(de)軟硬(ying)件平臺(tai),由于(yu)其功耗(hao)低、穩(wen)定性(xing)強、開(kai)發周(zhou)期短等(deng)特點,目前被廣泛應用(yong)于(yu)各個(ge)領域,越來越多(duo)(duo)的(de)(de)工(gong)程師選(xuan)用(yong)Arduino平臺(tai)進行(xing)項目開(kai)發,截止(zhi)到(dao)現(xian)在,Arduino開(kai)發團隊已(yi)開(kai)發出多(duo)(duo)種控制(zhi)(zhi)器(qi)(qi)。考慮到(dao)系統部署后期可能有更多(duo)(duo)數(shu)(shu)據采(cai)集點的(de)(de)加入,本系統選(xuan)用(yong)的(de)(de)是(shi)以(yi)Atmega2560核心的(de)(de)ArduinoMega2560控制(zhi)(zhi)板(以(yi)下簡稱Mega2560),相對(dui)于(yu)普通的(de)(de)Arduino Uno,Meg2560可用(yong)的(de)(de)數(shu)(shu)字輸(shu)入輸(shu)出口多(duo)(duo)達到(dao)54個(ge),插(cha)接傳感器(qi)(qi)擴展模塊后的(de)(de)數(shu)(shu)字I/O可以(yi)達到(dao)100多(duo)(duo)個(ge),給系統的(de)(de)升(sheng)級與擴展帶來極(ji)大的(de)(de)便(bian)利。

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

圖3 控制器與MAX675連線圖

2.2以太網通信模塊

由于(yu)Mega2560無法直接連(lian)接到以太(tai)網(wang)(wang)絡,需要(yao)采用(yong)包含(han)以太(tai)網(wang)(wang)的(de)(de)Ethernet模塊來實現,本文選用(yong)的(de)(de)是(shi)集成(cheng)(cheng)(cheng)WIZnetW5100網(wang)(wang)絡芯片的(de)(de)擴展(zhan)模塊。W5100 是(shi)一款高集成(cheng)(cheng)(cheng)度的(de)(de)網(wang)(wang)絡通信芯片,全硬(ying)件(jian)實現標準的(de)(de)TCP/IP 協議(yi)棧、以太(tai)網(wang)(wang)介質傳輸(shu)層(MAC)和(he)(he)物理(li)層(PHY),具(ju)備了高穩定(ding)、高性能和(he)(he)低功(gong)耗(hao)的(de)(de)特點,其數據傳輸(shu)速率(lv)最高可達100Mbps,由于(yu)TCP/IP協議(yi)均在商用(yong)與(yu)民用(yong)領域經過了多年的(de)(de)應用(yong)和(he)(he)長足(zu)的(de)(de)發展(zhan),相(xiang)關技術已經十(shi)分成(cheng)(cheng)(cheng)熟,資源豐富(fu),極大(da)的(de)(de)縮短了上位機(ji)與(yu)下位機(ji)程序的(de)(de)開發周(zhou)期(qi)。

根(gen)據(ju)Mega2560的接(jie)口特(te)點,本(ben)系統采了采用SPI總線方式與嵌入式控制(zhi)器進行(xing)通信(xin),與Ethernet模塊(kuai)連接(jie)如圖4所示,其接(jie)口功(gong)能描述為(wei)SS:使能信(xin)號(hao)(hao);SCLK:時鐘信(xin)號(hao)(hao);MOSI:數(shu)據(ju)發送;MISO:數(shu)據(ju)接(jie)收。

圖(tu)4 SPI總線(xian)連接圖(tu)

由于(yu)Arduino系(xi)列的(de)(de)控(kong)(kong)(kong)制(zhi)(zhi)器均采用(yong)(yong)了相互兼容(rong)(rong)的(de)(de)可(ke)堆疊的(de)(de)標(biao)準化設計(ji),Ethernet可(ke)以(yi)直接(jie)插(cha)接(jie)到Mega2560上不(bu)作任何配置,即(ji)可(ke)進行通(tong)信(xin)。W5100 內部用(yong)(yong)于(yu)數(shu)據傳輸(shu)的(de)(de)緩(huan)沖存(cun)(cun)儲器容(rong)(rong)量有(you) 16KB,完(wan)全能(neng)夠滿足溫(wen)度監控(kong)(kong)(kong)數(shu)據的(de)(de)本地緩(huan)存(cun)(cun),使用(yong)(yong)W5100不(bu)需要考慮以(yi)太網(wang)(wang)底層(ceng)的(de)(de)控(kong)(kong)(kong)制(zhi)(zhi),采用(yong)(yong)常規(gui)的(de)(de)網(wang)(wang)絡編(bian)程方法即(ji)可(ke)實現與W5100的(de)(de)以(yi)太網(wang)(wang)通(tong)信(xin)。通(tong)過Mega256引腳(jiao)圖(tu)(圖(tu)5)[3]可(ke)知,插(cha)接(jie)了Ethernet模塊后(hou),SPI總線(xian)會占用(yong)(yong)Mega2560控(kong)(kong)(kong)制(zhi)(zhi)器的(de)(de)50~53號(hao)引腳(jiao),因此在使用(yong)(yong)的(de)(de)時(shi)候要注意避(bi)開。

圖(tu)5 Arduino Mega2560引腳圖(tu)

3 軟件設計

3.1 溫度采(cai)集點軟件設計

在以(yi)太(tai)網傳輸(shu)(shu)(shu)中,常用的(de)(de)傳輸(shu)(shu)(shu)控制(zhi)協(xie)(xie)議(TCP)和(he)用戶(hu)數據(ju)報協(xie)(xie)議(UDP)均可以(yi)完成下位機到上(shang)位機的(de)(de)數據(ju)傳輸(shu)(shu)(shu),但TCP是(shi)(shi)基于連(lian)接的(de)(de)可靠(kao)傳輸(shu)(shu)(shu)協(xie)(xie)議,能(neng)進行錯誤監測,鑒于工(gong)業現場對于數據(ju)可靠(kao)性的(de)(de)要(yao)求,所以(yi)本(ben)文(wen)的(de)(de)軟件設(she)計(ji)中并未(wei)采(cai)用傳輸(shu)(shu)(shu)性能(neng)較高的(de)(de)UDP協(xie)(xie)議。因為,在辦公網絡中一個數據(ju)包(bao)的(de)(de)丟失可能(neng)是(shi)(shi)無關緊要(yao)的(de)(de),但在工(gong)業現場監控中,帶來的(de)(de)影(ying)響(xiang)可能(neng)是(shi)(shi)巨(ju)大的(de)(de)。在Arduino標準庫中包(bao)含(han)了(le)Ethernet和(he)SPI通信(xin)所需(xu)(xu)要(yao)的(de)(de)類與函(han)數,在編寫程序的(de)(de)時候需(xu)(xu)要(yao)包(bao)含(han)Ethernet.h、SPI.h和(he)MAX6675.h這三個頭文(wen)件。下面是(shi)(shi)Arduino控制(zhi)器的(de)(de)程序代(dai)碼。

#include “MAX6675.h”

#include “Ethernet.h”

#include “SPI.h”

MAX6675 mySenor(5,6,7); //定義MAX6675類型的傳(chuan)感(gan)器對象(xiang)mySenor

EthernetServer server(8000); //創建一(yi)個服務器對象(xiang),并設置網絡傳(chuan)送端(duan)口為8000

Byte mac[]={0XDE,0XAD,0XBE,0XEF,0XEF,0XFE,0XED};//設置Ethernet模塊(kuai)MAC地(di)址(zhi)

IPAdress ip{192.168.1.110}; //設置Ethernet模塊IP地(di)址(zhi)

void setup(){ //初始(shi)化(hua)各功能模塊

Serial.begin(9600); //設置串口波特率(lv)

mySenor.setOffset(0);

Ethernet.begin(mac,ip);

Server.begin();

}

void loop() //控(kong)制器循環操作

{

float sendData=0;

sendData=mySenor.getCelsius(); //從傳感器對象讀取(qu)溫(wen)度(du)數據(ju)

server.print(sendData); //通過(guo)網(wang)絡發送數據(ju)

Serial.println(sendData); //向串口發送數(shu)據,用于監控調試(shi)

delay(500); //設置延時

}

3.2 監控層軟件設計

在工業現場的(de)溫(wen)度(du)監(jian)測中,不(bu)僅要完成(cheng)實時溫(wen)度(du)數(shu)據的(de)監(jian)測同時也需(xu)要將生成(cheng)的(de)歷史(shi)數(shu)據進行分析(xi),使用計(ji)算(suan)(suan)機豐富的(de)計(ji)算(suan)(suan)資(zi)源以(yi)彌補嵌入(ru)式控制器(qi)(qi)的(de)不(bu)足(zu),使用虛(xu)擬(ni)儀(yi)(yi)器(qi)(qi)是(shi)一很好的(de)選擇,虛(xu)擬(ni)儀(yi)(yi)器(qi)(qi)是(shi)將計(ji)算(suan)(suan)機和儀(yi)(yi)器(qi)(qi)技術接(jie)合的(de)結晶[4],同樣也是(shi)測試技術和計(ji)算(suan)(suan)機深層次(ci)結合的(de)產物,它(ta)具有數(shu)據采集與信號(hao)分析(xi)的(de)功能(neng),本文的(de)監(jian)控層軟件設計(ji)采用了美國國家儀(yi)(yi)器(qi)(qi)公司(NI)設計(ji)的(de)LabVIEW平臺,LabVIEW的(de)系統的(de)組成(cheng)[2]如(ru)圖6所示(shi)。

圖6 LabVIEW系統組成(cheng)

LabVIEW采用圖(tu)(tu)形化的G語言(yan)進行編程(cheng),設(she)(she)置(zhi)TCP連接地(di)址為(wei)下(xia)位機(ji)的IP地(di)址為(wei)192.168.110,通信端(duan)口為(wei)8000,超時設(she)(she)置(zhi)為(wei)60000毫(hao)秒,通過波形控件提供歷史溫(wen)(wen)度(du)顯(xian)示,溫(wen)(wen)度(du)顯(xian)示控件顯(xian)示實(shi)時溫(wen)(wen)度(du),監控層的上位機(ji)程(cheng)序代碼(ma)如(ru)圖(tu)(tu)7所示。

圖(tu)7 上位(wei)機程序框圖(tu)

4 結語

經測試,本系(xi)(xi)統(tong)能準確的(de)對(dui)工(gong)(gong)業(ye)(ye)現(xian)場的(de)實(shi)時(shi)溫度(du)進(jin)行(xing)顯(xian)示和歷(li)史數(shu)據(ju)的(de)顯(xian)示,如(ru)圖8所示,可得知(zhi)當(dang)前溫度(du)為200攝氏度(du),而在過去的(de)500分(fen)鐘歷(li)史記錄中發現(xian)系(xi)(xi)統(tong)出現(xian)了(le)10次超過溫度(du)警戒值800攝氏度(du)的(de)記錄。該設計(ji)充分(fen)利用(yong)了(le)TCP/IP技(ji)術實(shi)現(xian)了(le)對(dui)工(gong)(gong)業(ye)(ye)生產(chan)過程(cheng)的(de)監控,進(jin)一(yi)步(bu)提(ti)高(gao)(gao)了(le)各項監督工(gong)(gong)業(ye)(ye),有助于現(xian)場工(gong)(gong)程(cheng)師(shi)及(ji)時(shi)采取(qu)應急處理等業(ye)(ye)務操作,需(xu)要注意的(de)是(shi)以太(tai)網(wang)(wang)技(ji)術帶來的(de)高(gao)(gao)數(shu)據(ju)高(gao)(gao)實(shi)時(shi)的(de)同時(shi),也產(chan)生了(le)一(yi)些網(wang)(wang)絡安全問(wen)題,對(dui)于這(zhe)一(yi)問(wen)題可通過網(wang)(wang)關采取(qu)包過濾(lv)的(de)方(fang)法將內部(bu)控制網(wang)(wang)絡與外(wai)部(bu)網(wang)(wang)絡系(xi)(xi)統(tong)分(fen)開[5]。綜上所述,隨著以太(tai)網(wang)(wang)技(ji)術在工(gong)(gong)業(ye)(ye)現(xian)場中的(de)逐步(bu)推廣和應用(yong),使(shi)生產(chan)現(xian)場數(shu)據(ju)與企(qi)業(ye)(ye)信息(xi)系(xi)(xi)統(tong)實(shi)現(xian)無(wu)縫對(dui)接,在即將到來的(de)第(di)四次工(gong)(gong)業(ye)(ye)革(ge)命中,全面實(shi)現(xian)“數(shu)字化工(gong)(gong)廠”這(zhe)一(yi)宏偉目標[6]。

圖(tu)8 LabVIEW程序運行效果圖(tu)

參考文獻

[1]徐皚冬.工業以太網(wang)實時通信技(ji)術[J].信息與控制,2005,34(1):60-64.

[2]沈金鑫,Arduino與LabVIEW開(kai)發(fa)實戰(zhan)[M].北京:機械工業出版(ban)社(she),2014:182―187.

[3]開源(yuan)硬件(jian)知(zhi)識庫[OL].[2014-10-21]. http:///

[4]余成(cheng),謝東坡.網(wang)絡化測控技術與(yu)實現[M].北(bei)京(jing):高等教育出(chu)版(ban)社,2009:194-198.

[5]孫德輝,史運濤,李(li)志軍,楊楊編,網絡化控制系統[M].北(bei)京:國(guo)防工業出版社,2008:124―134.

[6]陳積明.工業(ye)以太(tai)網的研究現(xian)狀(zhuang)及展(zhan)望[J].化(hua)工自動化(hua)入(ru)儀表,2001,28(6):1-4.

收(shou)稿日(ri)期:2015-08-08

篇8

關鍵詞:互聯(lian)網;嵌入式(shi)系統;協議棧(zhan);數據;報文;擁塞

中圖分類號: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 引言

計算機(ji)網(wang)絡的(de)(de)(de)飛速發展,已經改變(bian)了人們(men)的(de)(de)(de)生(sheng)產和生(sheng)活方式。數(shu)字化信息家電的(de)(de)(de)日(ri)益(yi)普及,使(shi)嵌入式系統(tong)連接到(dao)網(wang)絡成為了可能。互(hu)聯網(wang)采用(yong)的(de)(de)(de)是無連接的(de)(de)(de)端到(dao)端數(shu)據包(bao)交(jiao)換,提供“盡力而(er)為”服務模(mo)型的(de)(de)(de)設(she)計機(ji)制(zhi)(zhi)(zhi)。這種機(ji)制(zhi)(zhi)(zhi)的(de)(de)(de)最(zui)大優(you)勢是設(she)計簡(jian)單,可擴展性強。然而(er)隨著互(hu)聯網(wang)用(yong)戶(hu)數(shu)量的(de)(de)(de)膨(peng)脹,網(wang)絡的(de)(de)(de)擁(yong)塞問(wen)題也越來越嚴重。據統(tong)計,互(hu)聯網(wang)上95%的(de)(de)(de)數(shu)據流和90%的(de)(de)(de)報(bao)文數(shu)使(shi)用(yong)的(de)(de)(de)是TCP/IP協議(yi),因此,嵌入式TCP/IP協議(yi)棧(zhan)的(de)(de)(de)擁(yong)塞控制(zhi)(zhi)(zhi)機(ji)制(zhi)(zhi)(zhi)對控制(zhi)(zhi)(zhi)網(wang)絡擁(yong)塞更具有特別重要的(de)(de)(de)意義。

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

TCP/IP協(xie)(xie)(xie)議(yi)(yi)(yi)是(shi)由很多協(xie)(xie)(xie)議(yi)(yi)(yi)組(zu)成的協(xie)(xie)(xie)議(yi)(yi)(yi)族[1]。嵌入(ru)式(shi)系(xi)(xi)統引入(ru)互聯網(wang)(wang)支(zhi)持所需的主(zhu)要(yao)協(xie)(xie)(xie)議(yi)(yi)(yi)為(wei)ARP、RARP、IP、ICMP和TCP協(xie)(xie)(xie)議(yi)(yi)(yi)。ARP和RARP協(xie)(xie)(xie)議(yi)(yi)(yi)提(ti)供網(wang)(wang)絡(luo)(luo)地(di)址(zhi)的解析(xi);ICMP協(xie)(xie)(xie)議(yi)(yi)(yi)提(ti)供網(wang)(wang)絡(luo)(luo)診斷功能(neng);TCP和IP協(xie)(xie)(xie)議(yi)(yi)(yi)提(ti)供網(wang)(wang)絡(luo)(luo)傳輸和網(wang)(wang)絡(luo)(luo)互聯[1-2]。在(zai)網(wang)(wang)絡(luo)(luo)接口層(ceng),系(xi)(xi)統需實(shi)現(xian)ARP應(ying)答協(xie)(xie)(xie)議(yi)(yi)(yi),該(gai)協(xie)(xie)(xie)議(yi)(yi)(yi)用(yong)于(yu)將IP地(di)址(zhi)映(ying)射成以太網(wang)(wang)MAC地(di)址(zhi);在(zai)網(wang)(wang)際層(ceng),需要(yao)實(shi)現(xian)IP協(xie)(xie)(xie)議(yi)(yi)(yi),主(zhu)要(yao)負責IP報(bao)(bao)文(wen)報(bao)(bao)頭(tou)的正確(que)性(xing),并且對TCP和ICMP報(bao)(bao)文(wen)實(shi)行分流(liu),此(ci)外,為(wei)了(le)能(neng)夠測試(shi)系(xi)(xi)統與網(wang)(wang)絡(luo)(luo)的連接,在(zai)網(wang)(wang)際層(ceng)還需要(yao)實(shi)現(xian)ICMP協(xie)(xie)(xie)議(yi)(yi)(yi)中(zhong)的Ping應(ying)答協(xie)(xie)(xie)議(yi)(yi)(yi),主(zhu)要(yao)用(yong)于(yu)檢查網(wang)(wang)絡(luo)(luo)在(zai)傳輸層(ceng)是(shi)否連通。

2.1 TCP/IP協議棧處理流程

TCP/IP協(xie)(xie)議棧接收數(shu)據(ju)(ju)(ju)包(bao)(bao)(bao)的(de)過(guo)程就是(shi)解析數(shu)據(ju)(ju)(ju)包(bao)(bao)(bao)的(de)過(guo)程。首(shou)(shou)先當一個數(shu)據(ju)(ju)(ju)幀到達時,網絡接口控制(zhi)程序(xu)將其讀(du)入緩(huan)(huan)沖(chong)區(qu),檢查協(xie)(xie)議類型字(zi)段(duan),如(ru)果值(zhi)依(yi)次為0X0800,表示(shi)數(shu)據(ju)(ju)(ju)域內(nei)為IP包(bao)(bao)(bao);如(ru)果值(zhi)依(yi)次為0X0806,表示(shi)數(shu)據(ju)(ju)(ju)域內(nei)為ARP包(bao)(bao)(bao)[3]。由此(ci)(ci)以確定使用那種協(xie)(xie)議模塊來處理此(ci)(ci)分組。去(qu)掉以太(tai)網幀首(shou)(shou)部的(de)數(shu)據(ju)(ju)(ju)包(bao)(bao)(bao)將被分配到IP緩(huan)(huan)存(cun)或(huo)者ARP緩(huan)(huan)存(cun)。接著(zhu),由IP協(xie)(xie)議處理模塊或(huo)ARP協(xie)(xie)議處理模塊繼續解析。在IP協(xie)(xie)議模塊處理數(shu)據(ju)(ju)(ju)包(bao)(bao)(bao)的(de)過(guo)程,它要通過(guo)調用ARP協(xie)(xie)議獲得對方主(zhu)機的(de)物理地址。

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

嵌入(ru)式系統一般都是為了滿足某(mou)一特(te)定(ding)的(de)需求(qiu),對網(wang)絡支持的(de)要求(qiu)相對比較低(di),不需使用完(wan)整(zheng)的(de)TCP/IP協(xie)(xie)議。嵌入(ru)式TCP/IP協(xie)(xie)議棧的(de)特(te)點如下(xia):

1) 開放的(de)協議標準,獨立于特定的(de)計算機硬(ying)件、操作系統(tong)和網絡(luo)硬(ying)件,可以(yi)運行在局域網,廣(guang)域網和互聯網中。

2) 統一的(de)網絡地址分配方(fang)案,使得整個TCP/IP設備在網中(zhong)都(dou)具有唯一的(de)地址;標準(zhun)化的(de)高層(ceng)協(xie)議,可以提供多種可靠的(de)用(yong)戶服務(wu)。

3) 代碼比較簡(jian)潔,占用的存儲空間盡可能小(xiao),盡可能為應用程序節(jie)省系統資源。

4) 便于裁(cai)剪和擴展,對(dui)于面向不同應用的嵌入式系統應當(dang)根據特點對(dui)協議進(jin)行(xing)簡化或擴展。

TCP/IP協(xie)(xie)(xie)議(yi)棧具有層次(ci)特性,各個協(xie)(xie)(xie)議(yi)都(dou)有自己的(de)(de)數據格(ge)式,每次(ci)發(fa)送數據都(dou)要進(jin)(jin)行(xing)上下層協(xie)(xie)(xie)議(yi)的(de)(de)數據交(jiao)換,進(jin)(jin)行(xing)打(da)包和(he)拆包的(de)(de)過程。在嵌入式系統中,往往無法(fa)建立數據傳(chuan)遞的(de)(de)緩沖區,需要采用“零(ling)拷貝”技(ji)術(shu)來解決各層協(xie)(xie)(xie)議(yi)間的(de)(de)數據傳(chuan)遞,以(yi)提高系統的(de)(de)實(shi)時性能。網(wang)絡協(xie)(xie)(xie)議(yi)層次(ci)模型如圖1所示。

3 擁塞控制概述

描述擁塞現象有(you)許多(duo)不(bu)同的(de)度量(liang),如(ru)傳輸延時(shi)、數據吞吐量(liang)、隊(dui)列(lie)長(chang)度和(he)網絡效率等(deng),但是沒有(you)哪個度量(liang)能在局(ju)部和(he)全(quan)局(ju)意(yi)義(yi)上(shang)完全(quan)滿足(zu)擁塞評判要求,因(yin)此人們對擁塞控制并(bing)無嚴格定(ding)義(yi),甚至對擁塞的(de)定(ding)義(yi)都無法完全(quan)統一。

3.1 基本概念

定義1:若因為網(wang)絡(luo)(luo)負載增加而(er)導致用戶的(de)滿意度降低,用戶則認(ren)為網(wang)絡(luo)(luo)發(fa)生擁(yong)塞。

形象(xiang)地說(shuo),當網(wang)絡中存在過多的(de)(de)報文(wen)時(shi),網(wang)絡的(de)(de)性能會下降(jiang),這種(zhong)現象(xiang)稱為(wei)擁(yong)塞(sai)(sai)[4,5]。擁(yong)塞(sai)(sai)導致的(de)(de)直接結果是分(fen)組(zu)丟失率提(ti)高,端到端時(shi)延加(jia)大,甚(shen)至整個(ge)系(xi)統發(fa)生崩(beng)潰(kui)。當發(fa)生擁(yong)塞(sai)(sai)崩(beng)潰(kui)時(shi),微小的(de)(de)負(fu)載(zai)增量將使網(wang)絡的(de)(de)有(you)效吞吐量急劇下降(jiang)(如圖2所示)。

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

定義3:如果負(fu)載繼續增加,路(lu)由器開始(shi)(shi)丟包,當負(fu)載超過一定量時,吞吐量開始(shi)(shi)急(ji)劇下降,這一點(dian)稱為崖點(dian)(Cliff)。

定義4:擁塞控(kong)制(zhi)就是采用某(mou)種(zhong)策略(lve)或(huo)(huo)機制(zhi),保持(chi)網絡工作在正(zheng)常(chang)的(de)狀態下,也(ye)就是使(shi)網絡經常(chang)工作在崖點左(zuo)側的(de)區域內(nei)。從而避免擁塞的(de)發(fa)生(sheng)或(huo)(huo)者(zhe)對擁塞的(de)發(fa)生(sheng)做出(chu)反應(ying)。擁塞控(kong)制(zhi)的(de)目標就是使(shi)網絡在Knee附(fu)近工作。

3.2 產(chan)生(sheng)擁(yong)塞的(de)原因

網絡(luo)(luo)擁塞(sai)是(shi)“盡力而為”服(fu)務模(mo)型(xing)的一個固有(you)屬性。用戶間無(wu)法(fa)相互協作共(gong)享資源,多個用戶對同一網絡(luo)(luo)資源提出請求時,就可能發生擁塞(sai)。網絡(luo)(luo)擁塞(sai)產生的原因有(you)很(hen)多,直接原因主要有(you)三個方面(mian):1) 存儲空(kong)間不足;2) 帶寬容量不足;3) 處理(li)器間處理(li)能力和(he)速度不一致(zhi)。

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

由于(yu)擁塞控(kong)制(zhi)算法性(xing)能(neng)的好壞(huai)會影(ying)響整(zheng)個網絡系統,因此在(zai)設計和評價(jia)算法時,應該站在(zai)整(zheng)個系統的角度來考查(cha)。對于(yu)任(ren)何(he)一種擁塞避免或控(kong)制(zhi)方案(an),人(ren)們(men)希望它能(neng)同時滿足以下幾點(dian)要求:高(gao)效性(xing)、公平性(xing)(魯(lu)棒性(xing))、穩定(ding)性(xing)、可擴展性(xing)。

4 TCP擁塞控(kong)制(zhi)機(ji)制(zhi)

TCP協議[6]是目前Internet上(shang)使(shi)用最廣泛的(de)一種傳(chuan)輸層協議。TCP的(de)主(zhu)要(yao)目的(de)是為(wei)了解決Internet的(de)穩定性、異質性(接(jie)受端(duan)(duan)緩沖區大小,網(wang)絡(luo)帶寬(kuan)(kuan)及(ji)延遲等)、各流之間(jian)享用帶寬(kuan)(kuan)的(de)公(gong)平性,使(shi)用效率及(ji)擁塞控制等問(wen)題,從而為(wei)Internet提供可靠健壯的(de)端(duan)(duan)到端(duan)(duan)通訊。TCP擁塞控制策略主(zhu)要(yao)包括以下四個過程:

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

2) 擁(yong)(yong)塞避(bi)免階(jie)段(duan)(duan):當(dang)數據發(fa)送(song)速率超過一定(ding)閾值時,算法進(jin)入此階(jie)段(duan)(duan),而后(hou)發(fa)送(song)速率緩(huan)慢線(xian)性增長,避(bi)免了網絡擁(yong)(yong)塞的(de)發(fa)生。

3) 快速重傳(chuan)階段[9]:當(dang)網絡(luo)發(fa)生擁塞(sai)造成數據丟(diu)失或者(zhe)重傳(chuan)超時(shi)時(shi),用(yong)該策略重傳(chuan)丟(diu)失的(de)分組。

4) 快速(su)恢復(fu)階(jie)段(duan):把網絡從擁塞狀態(tai)中恢復(fu)出(chu)來。

4.1 TCP擁塞(sai)控(kong)制的(de)主要參(can)數

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

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

3) 回路響應時(shi)間(RTT):一個(ge)TCP數據(ju)包(bao)從源端(duan)(duan)發送(song)到接(jie)收(shou)端(duan)(duan)、源端(duan)(duan)收(shou)到接(jie)受端(duan)(duan)確認的時(shi)間間隔。

4) 超時(shi)重傳計(ji)數(shu)(shu)器(RTO):描述數(shu)(shu)據包從發(fa)送到失效的時(shi)間間隔,是判斷(duan)數(shu)(shu)據包丟失與否、網絡是否擁塞的重要(yao)參數(shu)(shu)。通常(chang)設為2RTT和5RTT。

4.2 TCP擁(yong)塞控(kong)制算法

4.2.1 Reno算法

1990年Jacobson在Tahoe的(de)基礎(chu)上提出(chu)了Reno算(suan)法(fa)。Tahoe算(suan)法(fa)是最(zui)早(zao)被提出(chu)來的(de)TCP源算(suan)法(fa),但(dan)至今(jin)仍然(ran)被大多數TCP實現所采用。Reno算(suan)法(fa)對(dui)Tahoe的(de)改(gai)進(jin)主要(yao)體(ti)現在兩(liang)個方面。第一,收(shou)到連續三個dupACK,算(suan)法(fa)不(bu)經過慢啟動,而直接進(jin)入(ru)擁塞避免階段。第二,增加了快(kuai)速重傳/快(kuai)速恢(hui)復(FR/FR)機制,具體(ti)過程為:

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

2) 重發去失的數據包;

3) 窗(chuang)口膨脹。cwnd=ssthresh+ndupndup為收到的重復(fu)ACK數(shu);

4) 當(dang)min(awnd,cwnd)足夠大時,發送新的數據包;

5) 當收到非(fei)重(zhong)復(fu)的(de)ACK時(shi),cwnd=ssthresh;

6) 轉入擁塞避免階段(duan)。可見(jian),Reno在收到(dao)(dao)三(san)個dupACK后,就轉入FR/FR,而遇到(dao)(dao)超時,Reno和Tahoe一(yi)樣進入慢啟動階段(duan)。可從Reno狀態轉換圖直(zhi)觀地看(kan)到(dao)(dao)Reno的整(zheng)個數據(ju)傳輸過(guo)程(cheng)(如(ru)圖3所(suo)示(shi))。

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

4.2.2 NewReno算法

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

4.2.3 Sack算(suan)法(fa)

Sack算(suan)(suan)法(fa)也(ye)是(shi)對Reno算(suan)(suan)法(fa)的(de)(de)改(gai)進(jin),當(dang)檢測(ce)到(dao)(dao)擁(yong)塞后,不用重(zhong)傳(chuan)數(shu)據包(bao)(bao)丟失(shi)到(dao)(dao)檢測(ce)到(dao)(dao)丟失(shi)時發(fa)送的(de)(de)全部數(shu)據包(bao)(bao),而(er)是(shi)對這(zhe)些(xie)數(shu)據包(bao)(bao)進(jin)行有選(xuan)擇(ze)的(de)(de)確認和重(zhong)傳(chuan),從而(er)避免不必要(yao)的(de)(de)重(zhong)傳(chuan),減少(shao)時延,提高(gao)網(wang)絡吞(tun)吐(tu)量(liang)。由于(yu)使(shi)用選(xuan)擇(ze)重(zhong)傳(chuan),所以(yi)在一個窗口(kou)中數(shu)據包(bao)(bao)多包(bao)(bao)丟失(shi)的(de)(de)情(qing)況下,Sack算(suan)(suan)法(fa)優于(yu)NewReno算(suan)(suan)法(fa)。但是(shi)Sack算(suan)(suan)法(fa)的(de)(de)主要(yao)缺點是(shi)要(yao)修改(gai)接收端(duan)TCP。

5 IP擁塞控制機(ji)制

隨著Internet業(ye)務的(de)(de)迅猛發展,僅依靠單一的(de)(de)端到端的(de)(de)擁(yong)塞(sai)控制(zhi)(zhi)機制(zhi)(zhi)不(bu)(bu)可能有效地(di)解決擁(yong)塞(sai)問題,另外期(qi)望(wang)所有用(yong)戶在Internet應用(yong)中都遵守這(zhe)種端到端的(de)(de)擁(yong)塞(sai)控制(zhi)(zhi)也是不(bu)(bu)現實的(de)(de),這(zhe)要求網(wang)絡本身也必須參與(yu)對(dui)資(zi)源(yuan)的(de)(de)管理與(yu)控制(zhi)(zhi)。基于此,提(ti)出了IP擁(yong)塞(sai)控制(zhi)(zhi)機制(zhi)(zhi)。

5.1 IP擁塞(sai)控制算法(fa)

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

RED(Random Early Detective)算法在路由器監(jian)控隊列(lie)(lie)長(chang)(chang)度(du),一(yi)旦(dan)發(fa)現(xian)擁塞迫近,就(jiu)通(tong)知源(yuan)端調整擁塞窗口(kou)。它也(ye)是通(tong)過丟包的方式使源(yuan)端發(fa)現(xian)超(chao)時或(huo)重復應答,隱(yin)式通(tong)知源(yuan)端擁塞情況。RED算法包含(han)兩部分:如何(he)監(jian)控隊列(lie)(lie)長(chang)(chang)度(du)和何(he)時丟棄(qi)數據包。首(shou)先,RED使用類似TCP計(ji)算超(chao)時時使用的權值(zhi)Weight來(lai)計(ji)算平均(jun)排隊長(chang)(chang)度(du):Qe=(1-Weight)×Qe+Weight×SampleQe其中,0

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

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

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

WFQ(Weight Fair Queue)是(shi)公平排(pai)隊(dui)(dui)(dui)(dui)(FQ)算法的(de)(de)(de)(de)改進算法。WFQ算法對(dui)每(mei)(mei)個流(liu)即每(mei)(mei)個排(pai)隊(dui)(dui)(dui)(dui)分配一個權(quan)值(zhi)。這個權(quan)值(zhi)決(jue)定(ding)了路由器(qi)每(mei)(mei)次轉發(fa)該隊(dui)(dui)(dui)(dui)列(lie)的(de)(de)(de)(de)比(bi)特(te)數(shu)(shu)量(liang),從而(er)控制數(shu)(shu)據流(liu)得到的(de)(de)(de)(de)帶寬。將(jiang)所有權(quan)值(zhi)看成1,那么FQ也(ye)是(shi)一種特(te)殊的(de)(de)(de)(de)WFQ。權(quan)值(zhi)的(de)(de)(de)(de)分配往往對(dui)應(ying)(ying)不(bu)同優先(xian)級(ji)的(de)(de)(de)(de)數(shu)(shu)據流(liu),例(li)如(ru)用IP包頭(tou)中TOS域指定(ding)流(liu)的(de)(de)(de)(de)優先(xian)級(ji),排(pai)隊(dui)(dui)(dui)(dui)時(shi)再按優先(xian)級(ji)分配權(quan)值(zhi)。總之,WFQ根(gen)據不(bu)同數(shu)(shu)據流(liu)應(ying)(ying)用的(de)(de)(de)(de)不(bu)同帶寬要(yao)求,對(dui)每(mei)(mei)個排(pai)隊(dui)(dui)(dui)(dui)隊(dui)(dui)(dui)(dui)列(lie)采(cai)用加權(quan)方法分配緩存資(zi)源(yuan),從而(er)增加了FQ對(dui)不(bu)同應(ying)(ying)用的(de)(de)(de)(de)適應(ying)(ying)性。

6 結論

討論了嵌入式TCP/IP擁塞(sai)(sai)控(kong)(kong)制(zhi)領域的(de)(de)研(yan)(yan)究(jiu)熱點。近年來,非線性(xing)規劃和(he)(he)系(xi)統(tong)(tong)控(kong)(kong)制(zhi)理論被引入擁塞(sai)(sai)控(kong)(kong)制(zhi)研(yan)(yan)究(jiu)中來,一(yi)些研(yan)(yan)究(jiu)者(zhe)使用數學模型來描述端(duan)系(xi)統(tong)(tong)和(he)(he)網關組成的(de)(de)系(xi)統(tong)(tong),這對擁塞(sai)(sai)控(kong)(kong)制(zhi)研(yan)(yan)究(jiu)有很大(da)的(de)(de)推動作用。然而,對于Internet這樣一(yi)個復雜系(xi)統(tong)(tong)的(de)(de)分析(xi)與控(kong)(kong)制(zhi),只有通過通信(xin)、控(kong)(kong)制(zhi)和(he)(he)數學等多學科(ke)的(de)(de)共(gong)同努(nu)力,才(cai)有望獲(huo)得突破性(xing)成果。

參考文獻:

[1] W.Richard STEVEN. TCP/IP詳解(jie) 卷1:協(xie)議(yi)[M].范(fan)建(jian)華,胥光(guang)輝(hui),張輝(hui),等譯.北(bei)京:機械工業出版社,2000:170-269.

[2] Jon C.SNADER. 高級TCP/IP編程[M]. 劉(liu)江林譯.北京:中國電力出(chu)版社,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] 陳崗,張會生.基(ji)于IPv6的移動互(hu)聯網絡研究(jiu)與實現[J].微(wei)電子學與計(ji)算機,2006,23(2):40-42

篇9

關(guan)鍵詞:IPv4;IPv6;HSRP;雙協(xie)議棧;平滑過渡

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

1 IPv4/IPv6雙協議棧熱備冗余(yu)網(wang)絡(luo)在企業的應用前景

隨(sui)著1998年IETF正式公布了RFC2460標(biao)準,IPv6協議就正式誕(dan)生了。IPv6具有2的(de)(de)128次方個IP地(di)(di)址(zhi),是IPv4地(di)(di)址(zhi)的(de)(de)2的(de)(de)96次方倍,解(jie)決了IPv4地(di)(di)址(zhi)空(kong)間的(de)(de)枯竭的(de)(de)問題。

IPv6具有極強(qiang)的(de)(de)安全(quan)性(xing)和可(ke)靠性(xing),在擴展頭中增加(jia)了身份驗證頭AH和封裝安全(quan)性(xing)數(shu)據(ju)(ju)頭(ESP),大大降低了數(shu)據(ju)(ju)被篡改(gai)的(de)(de)可(ke)能;IPv6增強(qiang)了對(dui)流的(de)(de)支持,流標簽(qian)的(de)(de)引入為整合(he)、優化(hua)語音、視頻和數(shu)據(ju)(ju)網(wang)絡提供了更好的(de)(de)條(tiao)件,同時高QoS特性(xing)使得數(shu)據(ju)(ju)傳(chuan)輸質量更加(jia)高效; IPv6還增強(qiang)了對(dui)移動(dong)性(xing)主(zhu)機的(de)(de)內在支持等功能。

將IPv6協(xie)議(yi)優秀的新(xin)特性和功能(neng)及早應(ying)用(yong)于(yu)企(qi)(qi)業,同時又能(neng)很好地兼容(rong)IPv4應(ying)用(yong),增強企(qi)(qi)業核心網(wang)絡(luo)性能(neng),采用(yong)IPv4/IPv6雙協(xie)議(yi)棧熱冗余模式建設企(qi)(qi)業核心網(wang)絡(luo)對企(qi)(qi)業計算機應(ying)用(yong)就有著非(fei)常重要(yao)的意(yi)義。

2 IPv6的新(xin)特性

2.1 全(quan)新(xin)的地(di)址(zhi)管理方(fang)案

地(di)(di)址(zhi)(zhi)管理方(fang)案(an)中(zhong)(zhong),首先改變了(le)地(di)(di)址(zhi)(zhi)擁(yong)(yong)有方(fang)式,IPv4中(zhong)(zhong),地(di)(di)址(zhi)(zhi)是用戶擁(yong)(yong)有,IPv6成(cheng)了(le)ISP擁(yong)(yong)有。其次IPv6還包(bao)括IPv4中(zhong)(zhong)沒有統一(yi)解決方(fang)案(an)的地(di)(di)址(zhi)(zhi)解析協議(ABP)和(he)可達性檢測等(deng)等(deng)。

IPv6還提(ti)供了(le)地(di)址自動配置機制,實現(xian)了(le)主機的即插即用功(gong)能。為了(le)保(bao)證主機地(di)址的唯(wei)一性(xing),IPv6定義了(le)重復(fu)地(di)址檢測(ce)(ce)過程,每當生成(cheng)地(di)址時,均反復(fu)執(zhi)行生成(cheng)和(he)檢測(ce)(ce)過程,直到(dao)得到(dao)唯(wei)一的地(di)址。

2.2 報文的安(an)全傳送

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

身份(fen)驗證(zheng)頭AH首先為IP數(shu)據(ju)(ju)(ju)報(bao)(bao)提供(gong)強大的(de)完整和身份(fen)驗證(zheng),為IP數(shu)據(ju)(ju)(ju)報(bao)(bao)承載內容驗證(zheng)數(shu)據(ju)(ju)(ju)和將實體與數(shu)據(ju)(ju)(ju)報(bao)(bao)內容相鏈接;其次(ci)在完整中使(shi)用公共密鑰數(shu)字簽名算(suan)法,AH還可(ke)以(yi)為IP數(shu)據(ju)(ju)(ju)報(bao)(bao)提供(gong)不可(ke)抵賴服務以(yi)及通過使(shi)用順序號字段來防止重(zhong)放攻擊。再有,AH還可(ke)以(yi)在隧道模式或透明模式下使(shi)用,既可(ke)用于(yu)(yu)為兩個(ge)節點間的(de)簡單(dan)直接的(de)數(shu)據(ju)(ju)(ju)報(bao)(bao)傳送提供(gong)身份(fen)驗證(zheng)和保護(hu),也可(ke)用于(yu)(yu)對發給安全性網關或由安全性網關發出的(de)整個(ge)數(shu)據(ju)(ju)(ju)報(bao)(bao)流進行封裝。

封裝安(an)全(quan)性(xing)數(shu)據(ju)頭通過(guo)加密提(ti)供(gong)數(shu)據(ju)報的機(ji)密性(xing),通過(guo)使(shi)用(yong)公(gong)共密鑰(yao)加密對數(shu)據(ju)來(lai)源進(jin)行身份驗(yan)證,通過(guo)由(you)AH提(ti)供(gong)的序(xu)列號機(ji)制提(ti)供(gong)對抗(kang)重放服(fu)務,以及通過(guo)使(shi)用(yong)安(an)全(quan)性(xing)網關來(lai)提(ti)供(gong)有限的業務流(liu)機(ji)密性(xing)。

2.3 對流的(de)支(zhi)持

IPv6在(zai)設計時就(jiu)充分(fen)考慮了對流(liu)(liu)(liu)(liu)(liu)的(de)支持,改變(bian)了IPv4對流(liu)(liu)(liu)(liu)(liu)的(de)處理即需要(yao)路由器(qi)判(pan)斷源和目的(de)IP地(di)址,又需要(yao)判(pan)斷傳輸控制協議或用戶數據報協議的(de)端口號的(de)復雜操作過程。在(zai)IP6的(de)IP頭(tou)的(de)格式里,有專門的(de)20bit流(liu)(liu)(liu)(liu)(liu)標簽(qian)域。主(zhu)機(ji)發送報文(wen)時,流(liu)(liu)(liu)(liu)(liu)標簽(qian)里填入(ru)相應的(de)流(liu)(liu)(liu)(liu)(liu)編號,路由器(qi)收(shou)到流(liu)(liu)(liu)(liu)(liu)的(de)第一個報文(wen)時,以流(liu)(liu)(liu)(liu)(liu)編號為索引建立處理上(shang)(shang)下(xia)文(wen),流(liu)(liu)(liu)(liu)(liu)中(zhong)的(de)后續報文(wen)都按上(shang)(shang)下(xia)文(wen)處理,因(yin)此IPv6對流(liu)(liu)(liu)(liu)(liu)的(de)處理方(fang)式要(yao)高效得多。

同時IPv6定義了(le)流的(de)(de)優(you)先級,分別支持不(bu)(bu)同的(de)(de)業(ye)務需求。通(tong)過對語(yu)音、視(shi)頻(pin)、數據(ju)等不(bu)(bu)同類(lei)型的(de)(de)數據(ju)流進行合(he)理、有(you)效的(de)(de)優(you)先級設置(zhi),為企業(ye)建(jian)設和優(you)化語(yu)音、視(shi)頻(pin)、數據(ju)三(san)網合(he)一網絡平(ping)臺提(ti)供了(le)遠優(you)于(yu)IPv4網絡的(de)(de)解決方(fang)案。

3 IPv6采(cai)用的關(guan)鍵技術

3.1 應用支持IPv6的技術(shu)

IPv6繼承了(le)IPv4網(wang)絡中大量應用協議,比如:FTP、Telnet、SMTP、HTTP、NFS、DNS等,它(ta)們會(hui)在IPv6中繼續使(shi)用。只有(you)少部分如:IPv4 socket接口(kou)需要改為IPv6 socket接口(kou),而協議本(ben)身(shen)機制可以基本(ben)不做改動。

3.2 IPv6過(guo)度技(ji)術

為了保(bao)護在IPv4上的大量投資(zi),IPv6應該能與IPv4的主機(ji)和路由器共存。逐步演進(jin)、逐步部署(shu)、地址兼容(rong)(rong)、降低(di)費用(yong)等內(nei)容(rong)(rong)便成了IPv6設計(ji)時的指(zhi)導(dao)思想。為了實現這(zhe)一(yi)目標,IPv6主要(yao)過度技術(shu)有十多種,而(er)基(ji)本的過度技術(shu)就是(shi)雙(shuang)協議棧和隧(sui)道。

1)雙協議棧技術

IPv4/IPv6雙協(xie)議棧技術(shu),就是(shi)使IPv6網絡節點具有一個(ge)IPv4棧和一個(ge)IPv6棧,同時支持IPv4和IPv6協(xie)議。兩(liang)者(zhe)都應用于相(xiang)同的(de)物理平臺,以及(ji)承載相(xiang)同的(de)傳輸(shu)層協(xie)議TCP或UDP。

2)隧道技術

隧道(dao)(Tunnel)是(shi)指將(jiang)一(yi)種協(xie)(xie)議(yi)(yi)報(bao)頭封(feng)裝在(zai)另(ling)一(yi)種協(xie)(xie)議(yi)(yi)報(bao)頭中(zhong),這(zhe)樣(yang)一(yi)種協(xie)(xie)議(yi)(yi)就可以通(tong)過另(ling)一(yi)種協(xie)(xie)議(yi)(yi)的封(feng)裝進行(xing)通(tong)信。IPv6隧道(dao)是(shi)將(jiang)IPv6報(bao)頭封(feng)裝在(zai)IPv4報(bao)頭中(zhong),這(zhe)樣(yang)IPv6協(xie)(xie)議(yi)(yi)包就可以穿(chuan)越IPv4網絡(luo)進行(xing)通(tong)信。

4 組建具有熱備冗余功能的(de)IPv4/IPv6雙協(xie)議棧(zhan)網絡

4.1 IPv6網絡建設策略

IPv4到IPv6的(de)升(sheng)級切換不(bu)可(ke)能一(yi)蹴(cu)而(er)就,必須循序(xu)漸進。因(yin)此(ci)在基于(yu)IPv6的(de)特(te)點以及公司目(mu)前IPv4網(wang)(wang)絡(luo)(luo)的(de)應用(yong)情況(kuang),在建設(she)IPv6網(wang)(wang)絡(luo)(luo)時(shi)做了以下幾點:不(bu)影(ying)響(xiang)現(xian)有(you)(you)基于(yu)IPv4協議的(de)所有(you)(you)網(wang)(wang)絡(luo)(luo)應用(yong);保(bao)(bao)持現(xian)有(you)(you)網(wang)(wang)絡(luo)(luo)的(de)層次結構;確保(bao)(bao)計算機終端同時(shi)對(dui)IPv4和(he)IPv6網(wang)(wang)絡(luo)(luo)的(de)訪問能力;滿(man)足今后平滑實(shi)現(xian)IPv4網(wang)(wang)絡(luo)(luo)到IPv6網(wang)(wang)絡(luo)(luo)的(de)過渡;通(tong)過IPv6網(wang)(wang)絡(luo)(luo)的(de)建設(she),進一(yi)步提(ti)高企業(ye)核心網(wang)(wang)絡(luo)(luo)的(de)性能。因(yin)此(ci),IPv6網(wang)(wang)絡(luo)(luo)建設(she)中(zhong)采用(yong)了熱(re)備冗余功能和(he)IPv4/IPv6雙協議棧技術。

4.2 網絡拓撲

IPv6網絡核(he)心(xin)(xin)建設(she)完(wan)成后形成圖(tu)1所示的結(jie)構示意圖(tu),核(he)心(xin)(xin)交換(huan)(huan)機A與(yu)核(he)心(xin)(xin)交換(huan)(huan)機B用(yong)兩(liang)對(dui)光纖連接實(shi)現熱備(bei)份(fen)互(hu)聯基礎,兩(liang)臺交換(huan)(huan)機與(yu)下一層交換(huan)(huan)機分別互(hu)聯,形成雙鏈路,在啟(qi)用(yong)HSRP及相關配置后實(shi)現雙機熱備(bei)路由功能。

配置(zhi)IPv4/IPv6網(wang)絡需要完成如(ru)圖2所示步(bu)驟。

4.3 雙協議棧的啟用

為了(le)實現(xian)IPv4/IPv6雙協議(yi)棧功能,在網(wang)絡接口設置中(zhong)必須同時啟用(yong)兩種協議(yi)。現(xian)有交換機IPv4已經啟用(yong),啟用(yong)IPv6協議(yi)及配置節點地址步驟如下:

interface fastethernet 1/1

IPv6 enable //啟(qi)用IPv6協議

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

4.4 路由實現

全(quan)局模式下IPv4使(shi)用(yong)IP routing啟(qi)用(yong)路(lu)(lu)由(you)(you)功能,IPv6則(ze)使(shi)用(yong)IPv6 unicast-routing啟(qi)用(yong)路(lu)(lu)由(you)(you)功能。IPv6是(shi)對IPv4的(de)(de)(de)(de)革新,盡管大多數IPv6的(de)(de)(de)(de)路(lu)(lu)由(you)(you)協議都需(xu)(xu)要重新設(she)計或者開發,但IPv6路(lu)(lu)由(you)(you)協議相對IPv4只有很小的(de)(de)(de)(de)變化。在(zai)靜(jing)態路(lu)(lu)由(you)(you)方面(mian)與IPv4也基本相同,只需(xu)(xu)為(wei)節(jie)點配置地址并作為(wei)客(ke)戶機網關,即可實(shi)現網段間的(de)(de)(de)(de)路(lu)(lu)由(you)(you)。

全局模式下啟用IPv6路由(you)及相關(guan)配置

IPv6 unicast-routing //打開ipv6單播(bo)路(lu)由功(gong)能

IPv6 dhcp pool test //新建(jian)一個IPv6的dhcp地址池test,供客(ke)戶(hu)機自動(dong)獲取(qu)使用

prefix-delegation pool test1 lifetime 1800 600

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

4.5 Windows2003中IPv6 DNS配置

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

②配置(zhi)IPv6 DNS

a、打開(kai)了DNS配(pei)置向導(dao);

b、在(zai)導航(hang)窗格中, 單擊用于你(ni)的服(fu)務(wu)器(qi)在(zai)DNS服(fu)務(wu)器(qi)對象(xiang),用鼠(shu)標(biao)右鍵單擊服(fu)務(wu)器(qi)對象(xiang),然后單擊 配置(zhi)DNS服(fu)務(wu)器(qi)以啟動配置(zhi)DNS服(fu)務(wu)器(qi)向導,步驟見圖3。

4.6 IPv6客戶機配(pei)置

通常情(qing)況下IPv6客戶機在啟用(yong)IPv6協議后,地址(zhi)會從最(zui)近的網絡節點自動(dong)(dong)獲取(qu),無(wu)需(xu)用(yong)戶手動(dong)(dong)配(pei)置(zhi),但是對于(yu)像服務器這類(lei)需(xu)固定IP地址(zhi)的則需(xu)手動(dong)(dong)配(pei)置(zhi),以便(bian)于(yu)訪(fang)問。以Windows Server 2003為例,步(bu)驟(zou)如下:

1)IPv6 協議棧的安(an)裝

在(zai)“開始(shi)”―>“運行(xing)”處執行(xing)IPv6 install命(ming)令

2)IPv6 地址設置

在(zai)“開始”―>“運行(xing)(xing)(xing)(xing)”處(chu)(chu)執(zhi)行(xing)(xing)(xing)(xing)netsh命令(ling),進入系統網絡參數(shu)設(she)置環(huan)境netsh>,執(zhi)行(xing)(xing)(xing)(xing)interface ipv6 add address “本地連(lian)接” 2001:d0a8:3207::e002命令(ling)設(she)置地址;或者在(zai) 開始 -->“運行(xing)(xing)(xing)(xing)”處(chu)(chu)執(zhi)行(xing)(xing)(xing)(xing) ipv6 adu 4/2001:d0a8:3207::e002。

3)IPv6 默認網(wang)關設置(zhi),在netsh>標(biao)識后(hou)輸入(ru)

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

4.7 IPv6網站的訪問

用(yong)戶在實際使(shi)用(yong)中,IPv4和IPv6同樣(yang)使(shi)用(yong)域名網(wang)址進行訪(fang)(fang)問,使(shi)用(yong)IP地址訪(fang)(fang)問時(shi)有所(suo)不(bu)同,IPv6協議需要使(shi)用(yong)帶中括弧(hu)方(fang)式(shi)來訪(fang)(fang)問,例如:[ 2001:d0a8:3207::e001]。

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

網絡核(he)心采(cai)用熱備份(fen)路(lu)(lu)(lu)由(you)(you)(you)器(qi)(qi)協(xie)議技術(HSRP:Hot Standby Router Protocol),系統中使用兩臺路(lu)(lu)(lu)由(you)(you)(you)交換機滿足(zu)HSRP多臺路(lu)(lu)(lu)由(you)(you)(you)器(qi)(qi)的(de)(de)條件(jian),組(zu)(zu)成一(yi)個(ge)(ge)“熱備份(fen)組(zu)(zu)”,這個(ge)(ge)組(zu)(zu)形成一(yi)個(ge)(ge)虛擬(ni)路(lu)(lu)(lu)由(you)(you)(you)器(qi)(qi)。在任一(yi)時刻,一(yi)個(ge)(ge)組(zu)(zu)內(nei)(nei)只有(you)一(yi)個(ge)(ge)路(lu)(lu)(lu)由(you)(you)(you)器(qi)(qi)是活(huo)動的(de)(de),并由(you)(you)(you)它來(lai)轉發數據包,如果活(huo)動路(lu)(lu)(lu)由(you)(you)(you)器(qi)(qi)發生了(le)故(gu)(gu)障(zhang),將選擇備份(fen)路(lu)(lu)(lu)由(you)(you)(you)器(qi)(qi)來(lai)替代活(huo)動路(lu)(lu)(lu)由(you)(you)(you)器(qi)(qi),但是在本網絡內(nei)(nei)的(de)(de)主(zhu)機看來(lai),虛擬(ni)路(lu)(lu)(lu)由(you)(you)(you)器(qi)(qi)沒有(you)改(gai)變。所以主(zhu)機仍(reng)然(ran)保持連(lian)接,沒有(you)受到(dao)故(gu)(gu)障(zhang)的(de)(de)影響,這樣就較好地解決了(le)路(lu)(lu)(lu)由(you)(you)(you)器(qi)(qi)切換的(de)(de)問(wen)題。配置步驟如圖4。

1)熱備份(fen)交換機通道配(pei)置

交換機A

interface Port-channel1 //創建(jian)一個(ge)捆綁通(tong)道(dao)組1

description HSRP_packet //描述該通道是(shi)傳遞(di)hsrp包用

interface GigabitEthernet5/1

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

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

2)VLAN冗余(yu)組配置

交換機A

interface Vlan1//配置vlan 1接口

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

IPv6 enable

standby version 2//啟用版本2

standby 1 ip 10.1.1.1//設置vlan 1到熱備組1,同時設置vlan 1的ipv4網關

standby 1 priority 110 //在本交換機(ji)的(de)優(you)先(xian)級(ji)110(默認100,優(you)先(xian)級(ji)高的(de)為主用)

standby 1 preempt//打開熱備組(zu)1搶(qiang)占功能

 standby 1 track Port-channel1 //熱備組1通(tong)過捆綁接(jie)口Port-channel1實(shi)現(xian)雙機信(xin)息告知

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

在交換機B中進行(xing)同理(li)配置(zhi)。

5 結束語

1)通過雙機熱備份路(lu)由器協議的使用,公司(si)網(wang)絡(luo)穩定性(xing)能得到很大提高,更好(hao)地滿足了(le)目前公司(si)數(shu)十套業務系統全(quan)天候(hou)不(bu)間斷的運(yun)行要求,很好(hao)地支持了(le)公司(si)的發(fa)展(zhan);

2)為公司正進(jin)行的全面信(xin)息化及電子商(shang)務的建設提供了高(gao)效、安全、可(ke)靠和(he)無阻塞的信(xin)息處理網絡平臺;

3)通過對IPv6技術的應用,它(ta)擁有的全(quan)(quan)新網絡安全(quan)(quan)架構技術使(shi)企業業務數據的傳輸安全(quan)(quan)得到了進一步保證(zheng);

4)IPv6對流(liu)的充(chong)分支持,加快了企(qi)業對流(liu)業務應用系(xi)統的開發(fa),為建設高效的企(qi)業語音、視頻(pin)、數據三網合一(yi)網絡平臺起到了重(zhong)要作用;

5)該系(xi)統的成功實施(shi)為公司(si)業務(wu)(wu)系(xi)統今(jin)后及早融入(ru)IPv6網(wang)(wang)絡環境(jing)打下了(le)基(ji)礎,為公司(si)ERP及電子(zi)商(shang)務(wu)(wu)系(xi)統更快、更好地融入(ru)新的網(wang)(wang)絡信(xin)息平(ping)臺做(zuo)好了(le)充(chong)分準備。

6)IPv6網(wang)站(zhan)的建成(cheng),已成(cheng)為國家IPv6應用試驗典(dian)范。

參考文獻:

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

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

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

篇10

【關鍵詞(ci)】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 引言

隨(sui)著(zhu)全球信(xin)息(xi)(xi)化進(jin)(jin)程的(de)不斷發展,越(yue)來越(yue)多的(de)企(qi)業(ye)使用(yong)局(ju)域網(wang)來管理各種事務。但隨(sui)著(zhu)局(ju)域網(wang)的(de)機器(qi)增多,軟件的(de)應用(yong)對(dui)局(ju)域網(wang)的(de)信(xin)息(xi)(xi)吞吐、處理能力的(de)要求(qiu)也越(yue)高。為解決上述矛盾,就(jiu)有必要設(she)計一個在(zai)局(ju)域網(wang)里的(de)ICQ,通過該系統,進(jin)(jin)行(xing)文件傳輸,消(xiao)息(xi)(xi)的(de),提高企(qi)業(ye)的(de)工作效率。

1 需求分析

該系(xi)統基(ji)于TCP/IP網絡(luo)協(xie)議,采用C/S模式(shi),服務器端(duan)(duan)與數(shu)據庫連接,客(ke)戶端(duan)(duan)安(an)裝在不同電腦上可通(tong)過同一服務器實現數(shu)據通(tong)訊。實現的功能如下:

(1)用戶注冊,隨機(ji)分配(pei)號碼并填寫個(ge)人(ren)信(xin)息(xi);

(2)用戶(hu)登(deng)入驗證并導出(chu)好友列表;

(3)能夠查找好(hao)友并認(ren)證(zheng)后加為好(hao)友;

(4)文字聊天(tian),聊天(tian)記錄保存;

(5)點對點文(wen)件傳輸功能;

(6)視頻語音(yin)捕獲與傳(chuan)輸(視頻語音(yin)聊(liao)天功能)。

2 詳細設計

2.1 概要設計

本課(ke)題在研(yan)究和(he)(he)分(fen)析計算(suan)機TCP/IP網絡協議基礎(chu)上,在不(bu)同(tong)計算(suan)機之(zhi)間實(shi)現數據(ju)通訊(xun)。采用TCP和(he)(he)UDP傳輸(shu)方式,編(bian)寫客(ke)(ke)戶(hu)端與服(fu)(fu)務(wu)(wu)(wu)器(qi)端網絡軟件。客(ke)(ke)戶(hu)向(xiang)服(fu)(fu)務(wu)(wu)(wu)器(qi)發出(chu)(chu)服(fu)(fu)務(wu)(wu)(wu)請(qing)(qing)求,服(fu)(fu)務(wu)(wu)(wu)器(qi)作出(chu)(chu)應答響應,服(fu)(fu)務(wu)(wu)(wu)器(qi)監聽客(ke)(ke)戶(hu)發出(chu)(chu)的請(qing)(qing)求,當客(ke)(ke)戶(hu)提出(chu)(chu)連(lian)接請(qing)(qing)求后,服(fu)(fu)務(wu)(wu)(wu)器(qi)作出(chu)(chu)應答,并為客(ke)(ke)戶(hu)提供相(xiang)應的服(fu)(fu)務(wu)(wu)(wu)。

本系統前臺(tai)使用Delphi6.0進行(xing)設計(ji),后臺(tai)運用Sql Server 2000進行(xing)數據(ju)管理(li)。

2.2 方案設計

該即(ji)時(shi)(shi)通(tong)(tong)(tong)的工作過程如下:當(dang)服務器開啟時(shi)(shi),用戶(hu)(hu)(hu)從(cong)客(ke)戶(hu)(hu)(hu)端(duan)登錄,通(tong)(tong)(tong)過TCP/IP網絡(luo)將輸(shu)入(ru)的帳(zhang)號(hao)和密碼傳到服務器,服務器從(cong)數據(ju)庫(ku)中對(dui)應的數據(ju)表查找(zhao)驗證,若驗證錯(cuo)誤,返回錯(cuo)誤提示信息;若驗證通(tong)(tong)(tong)過,則登錄QQ主頁面(mian)。在進(jin)入(ru)主頁面(mian)后,用戶(hu)(hu)(hu)可(ke)通(tong)(tong)(tong)過輸(shu)入(ru)對(dui)方(fang)QQ號(hao)查找(zhao)其他用戶(hu)(hu)(hu)且加對(dui)方(fang)為好友。兩用戶(hu)(hu)(hu)可(ke)通(tong)(tong)(tong)過點對(dui)點通(tong)(tong)(tong)訊實現文字聊天,語(yu)音視頻聊天,文件傳輸(shu)等(deng)。

2.3 系統數(shu)據表(biao)設計

本系(xi)統使用(yong)SQL Server 2000設計后臺數據庫,共設計了兩張數據表(biao)(biao):用(yong)戶信(xin)息(xi)表(biao)(biao)和好友(you)信(xin)息(xi)表(biao)(biao)。

用(yong)戶(hu)信(xin)息(xi)數據(ju)表用(yong)于儲存注冊用(yong)戶(hu)的(de)信(xin)息(xi),存儲的(de)信(xin)息(xi)包(bao)括:用(yong)戶(hu)QQ號(主鍵)、用(yong)戶(hu)密碼、用(yong)戶(hu)昵稱、性別、是否在線(1為在線,0為不在)、用(yong)戶(hu)上線地址、國籍、省份(fen)、城市(shi)等。

好(hao)(hao)(hao)友(you)信(xin)息(xi)(xi)數據表(biao),主要用(yong)(yong)于添加用(yong)(yong)戶好(hao)(hao)(hao)友(you)信(xin)息(xi)(xi),用(yong)(yong)戶登(deng)錄時調用(yong)(yong)相關信(xin)息(xi)(xi)并顯示。存儲的信(xin)息(xi)(xi)包括(kuo):用(yong)(yong)戶QQ號(hao)、好(hao)(hao)(hao)友(you)QQ號(hao)、好(hao)(hao)(hao)友(you)是否在(zai)線(xian)、好(hao)(hao)(hao)友(you)在(zai)線(xian)地址、好(hao)(hao)(hao)友(you)昵稱。

2.4 詳細模塊設計及功能實現

客戶端包括七個模塊:

(1)登(deng)錄(lu)模(mo)塊(kuai):此模(mo)塊(kuai)實現客戶端與服務器連接,用戶登(deng)錄(lu)時驗(yan)證身(shen)份,驗(yan)證通(tong)過則(ze)進(jin)入QQ主頁面模(mo)塊(kuai),并調取好(hao)友信(xin)息顯示。

(2)主(zhu)頁(ye)面模塊:用戶在登錄模塊驗證身份通(tong)過后,從服(fu)務器調取好友信息,并在QQ主(zhu)頁(ye)面上顯示。

(3)查找(zhao)(zhao)模(mo)塊(kuai):該(gai)模(mo)塊(kuai)用于用戶(hu)查找(zhao)(zhao)好(hao)友(you),輸入(ru)對方帳號查找(zhao)(zhao)對方信(xin)息,并(bing)加為好(hao)友(you),與服務器(qi)連接并(bing)修改數據表的(de)內(nei)容,在(zai)主頁面(mian)上添加上新好(hao)友(you)。

(4)文字(zi)(zi)聊(liao)天(tian)模塊:此模塊實現(xian)用戶間的點(dian)對點(dian)聊(liao)天(tian),兩客戶端通過UDP連(lian)接(jie),發送(song)和接(jie)收文字(zi)(zi)信息,實現(xian)局域網文字(zi)(zi)聊(liao)天(tian)。

(5)文(wen)(wen)件(jian)傳(chuan)輸(shu)模塊(kuai):此模塊(kuai)實現兩客戶端點(dian)對(dui)點(dian)文(wen)(wen)件(jian)傳(chuan)輸(shu),圖片(pian),文(wen)(wen)本文(wen)(wen)檔及壓(ya)縮包等均可傳(chuan)輸(shu)。

(6)語(yu)音(yin)視頻聊天(tian)模塊:此(ci)模塊實(shi)現了語(yu)音(yin)和(he)視頻的(de)捕獲以及點(dian)對點(dian)傳輸功能(neng)。

服務器端根據(ju)功能要求可分為(wei)以下三(san)個模塊:

(1)服(fu)務器監聽(ting)模塊:用于回(hui)應(ying)客(ke)戶(hu)端(duan)請求,包括(kuo)登錄回(hui)應(ying),注冊回(hui)應(ying),調用好友信息回(hui)應(ying)等。

(2)遠程截(jie)圖模(mo)塊:此模(mo)塊實現服務器端從(cong)上線的客戶端獲取(qu)IP地址后截(jie)取(qu)對(dui)方屏幕顯(xian)示。

(3)查(cha)(cha)詢(xun)模塊(kuai):此模塊(kuai)實(shi)現服(fu)務器端訪(fang)問數(shu)據(ju)庫并查(cha)(cha)詢(xun)數(shu)據(ju)庫信息。分為綜合查(cha)(cha)詢(xun)和詳細查(cha)(cha)詢(xun)功能。

3 系統程序的總體設計與實現

本系(xi)統軟件采(cai)用模塊(kuai)化結構,由用戶登錄程(cheng)(cheng)序(xu)、用戶注冊程(cheng)(cheng)序(xu)、好(hao)友信息(xi)顯示程(cheng)(cheng)序(xu)、好(hao)友查找(zhao)程(cheng)(cheng)序(xu)、文字聊天程(cheng)(cheng)序(xu)、文件傳(chuan)輸程(cheng)(cheng)序(xu)等子(zi)程(cheng)(cheng)序(xu)構成。其中(zhong),文件傳(chuan)輸,語音視頻(pin)聊天模塊(kuai)都(dou)具有獨立性(xing),可在單獨設計后加(jia)入(ru)到整(zheng)個(ge)系(xi)統中(zhong),其余各模塊(kuai)間需要服務(wu)(wu)器客(ke)戶端相互(hu)連接同時調試(shi)才可實現。服務(wu)(wu)器端首先(xian)開啟運行,在和客(ke)戶端相互(hu)通訊(xun)實現基本功(gong)能。

4 結束語

本(ben)系統基(ji)于(yu)Delphi6.0和Sql Server 2000的運用(yong),在研究和分(fen)析計算機TCP/IP網絡協議基(ji)礎(chu)上,實(shi)現(xian)不同計算機之間的數據通(tong)訊(xun)。采用(yong)C/S結(jie)構,實(shi)現(xian)在功能有:用(yong)戶(hu)的注冊和登(deng)錄(lu),好(hao)友的顯示和查找,好(hao)友文(wen)字(zi)、語音視頻聊(liao)天,文(wen)件傳輸等。

【參考文獻】