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