物聯(lián)網(wǎng)應(yīng)用中TCP協(xié)議的簡化研究

馮翠麗，劉波濤，王青海，陳憲超

(1.長江大學(xué) 計(jì)算機(jī)科學(xué)學(xué)院，湖北 荊州 434023；2.勝利油田鉆井工藝研究院信息中心；3. 長沙華德科技開發(fā)有限公司)

當(dāng)前，研究得如火如荼的物聯(lián)網(wǎng)技術(shù)中，首先要解決的一個(gè)問題是將嵌入式設(shè)備接入網(wǎng)絡(luò)[1].其中，比較常見的一種實(shí)現(xiàn)方案是在嵌入式設(shè)備中集成精簡后的TCP/IP協(xié)議棧而將該設(shè)備接入Internet[2-3].在此過程中，如果需要實(shí)現(xiàn)基于TCP協(xié)議的高層應(yīng)用，就必須要根據(jù)嵌入式設(shè)備的具體功能來簡化實(shí)現(xiàn)TCP協(xié)議，因此如何針對該設(shè)備的具體應(yīng)用來有效地簡化實(shí)現(xiàn)TCP協(xié)議就是一個(gè)技術(shù)難點(diǎn).

1 標(biāo)準(zhǔn)TCP協(xié)議的功能及作用

TCP(Transmission Control Protocol)傳輸控制協(xié)議是TCP/IP協(xié)議簇的核心協(xié)議， 也是TCP/IP協(xié)議簇中最復(fù)雜的協(xié)議.它是一種面向連接的、可靠的、基于字節(jié)流的運(yùn)輸層通信協(xié)議[4].標(biāo)準(zhǔn)的TCP協(xié)議會實(shí)現(xiàn)流量控制、滑動窗口協(xié)議、擁塞控制、TCP各種計(jì)時(shí)器、TCP重傳、TCP有限狀態(tài)機(jī)及TCP連接管理等等功能[5].

2 TCP協(xié)議的裁剪設(shè)計(jì)與實(shí)現(xiàn)

通用計(jì)算機(jī)系統(tǒng)有足夠的資源支持系統(tǒng)在內(nèi)核中實(shí)現(xiàn)復(fù)雜的TCP重傳機(jī)制，然而對于嵌入式Web服務(wù)器有限的資源及比較低的處理速度來說，要想實(shí)現(xiàn)那些復(fù)雜的TCP協(xié)議既不現(xiàn)實(shí)也沒有必要.在研究嵌入式系統(tǒng)TCP協(xié)議的實(shí)現(xiàn)過程中，需要解決的幾個(gè)關(guān)鍵問題是：①如何精簡傳輸控制塊(TCB)；②如何精簡TCP協(xié)議的幾個(gè)計(jì)時(shí)器；③如何簡化TCP連接管理，裁剪TCP有限狀態(tài)機(jī)；④如何進(jìn)行流量控制，簡化滑動窗口協(xié)議，并實(shí)現(xiàn)TCP的重傳機(jī)制.

2.1 TCP數(shù)據(jù)包首部及其分析

TCP首部格式的定義需要遵循RFC 793的規(guī)定，可定義如下：

typedef struct

{ WORD SrcePort； //源端口號

WORD DestPort； //目的端口號

LWORD SeqNum； //系列號

LWORD AckNum； //確認(rèn)號

WORD LenFlags； //首部長度及標(biāo)識，首部=LenFlags&0xf000>>10

WORD WndSize； //窗口大小

WORD CkSum； //TCP校驗(yàn)和

WORD UrgPtr； //緊急指針

} _TCP_HDR；

標(biāo)準(zhǔn)的TCP選項(xiàng)有三種：最大報(bào)文長度選項(xiàng)、窗口擴(kuò)大因子選項(xiàng)和時(shí)間戳選項(xiàng).最大報(bào)文長度選項(xiàng)用于交互的雙方協(xié)商TCP數(shù)據(jù)的最大長度.窗口擴(kuò)大因子選項(xiàng)用于提高TCP的吞吐量，如果其值為n，則2的n次方與WndSize的積即是新的窗口大小.時(shí)間戳選項(xiàng)用于記錄往返時(shí)間，便于動態(tài)地定義超時(shí)時(shí)間.在嵌入式TCP中，可以使用固定大小的窗口和簡單的確認(rèn)機(jī)制來簡化程序以節(jié)約RAM空間，因此它不需要窗口擴(kuò)大因子和最大報(bào)文長度選項(xiàng).嵌入式TCP不需要?jiǎng)討B(tài)定義超時(shí)時(shí)間，也就是說，它不需要時(shí)間戳選項(xiàng).

2.2 TCB的實(shí)現(xiàn)

為了實(shí)現(xiàn)TCP面向連接的、可靠的服務(wù)，需要使用一個(gè)結(jié)構(gòu)來維持每條連接的相關(guān)信息，該結(jié)構(gòu)被稱為TCB(傳輸控制塊).針對標(biāo)準(zhǔn)的TCB，每種剪裁的實(shí)現(xiàn)都不一樣，筆者實(shí)現(xiàn)的TCB如圖1所示.

圖1 標(biāo)準(zhǔn)TCB及筆者實(shí)現(xiàn)的嵌入式TCB對比圖

筆者裁剪TCB的原則如下：①在標(biāo)準(zhǔn)的TCP服務(wù)中，客戶端在申請建立連接時(shí)和在與服務(wù)器建立連接后所使用的目的端口是不同的，前者使用的是HTTP協(xié)議的熟知端口80，而后者使用的是一個(gè)臨時(shí)端口，這種方式提高了系統(tǒng)的吞吐量.因此，標(biāo)準(zhǔn)的TCP服務(wù)需要記錄本地的臨時(shí)端口，考慮到嵌入式Web服務(wù)器的吞吐量不大，因此嵌入式TCB中也不需要記錄臨時(shí)端口；②標(biāo)準(zhǔn)的TCP協(xié)議支持多穴功能，因此需要記錄本地的IP地址.而嵌入式Web服務(wù)器沒有必要實(shí)現(xiàn)多穴功能，因此可以將該IP地址設(shè)置成一個(gè)全局變量，從而使得每個(gè)連接的本地IP都可以使用此變量.也就是說，嵌入式TCB不需要定義本地IP字段；③由于筆者沒有使用多任務(wù)OS，所以標(biāo)準(zhǔn)TCB中的進(jìn)程號沒有意義；④協(xié)議棧沒有進(jìn)行Socket封裝，故不需要接口號；⑤因?yàn)椴捎昧肆憧截惖姆獍獍记蒣6]，因此沒有必要定義緩存指針及緩存大?。虎薰P者使用了簡單的確認(rèn)機(jī)制[6]，而避免了實(shí)現(xiàn)復(fù)雜的滑動窗口協(xié)議，因此本地窗口及遠(yuǎn)程窗口沒有意義；⑦筆者沒有實(shí)現(xiàn)標(biāo)準(zhǔn)TCB中的堅(jiān)持計(jì)時(shí)器[5]，因此不需要定義往返時(shí)間.

2.3 TCP?；疃〞r(shí)器的實(shí)現(xiàn)

在標(biāo)準(zhǔn)的TCP服務(wù)中，實(shí)現(xiàn)?；疃〞r(shí)器是為了防止兩個(gè)TCP之間的連接長時(shí)期的空閑.假如一個(gè)客戶端打開了一個(gè)到服務(wù)器的連接，傳送一些數(shù)據(jù)后就出了故障，那么這個(gè)連接將永遠(yuǎn)的處于打開狀態(tài)，這對服務(wù)器來說是一個(gè)資源的浪費(fèi).并且，從安全性的角度考慮，這種服務(wù)器容易受到類似的攻擊從而無法完成正常的服務(wù).為了避免這種情況的發(fā)生，通常在服務(wù)器端設(shè)置一個(gè)?；疃〞r(shí)器，每當(dāng)服務(wù)器收到客戶端信息時(shí)都將該定時(shí)器復(fù)位.超時(shí)時(shí)間通常設(shè)置為2小時(shí)，若2小時(shí)后服務(wù)器還沒有收到客戶端的信息，它就發(fā)送10個(gè)間隔為75秒的探測報(bào)文.在此期間，如若服務(wù)器仍然沒有收到客戶端的響應(yīng)，它就會認(rèn)為客戶端出現(xiàn)故障而主動終止該連接.

嵌入式TCP服務(wù)中也會出現(xiàn)上述問題，因此，筆者在嵌入式TCP中也需要實(shí)現(xiàn)簡化的?；疃〞r(shí)器：①2個(gè)小時(shí)的超時(shí)時(shí)間對嵌入式Web服務(wù)器來說太長，因?yàn)樗且环N檢測、控制的工具，連接時(shí)間越長，其安全性越差，這個(gè)時(shí)間應(yīng)根據(jù)具體的應(yīng)用通過實(shí)驗(yàn)的方法來獲取比較合理.筆者經(jīng)過大量的實(shí)驗(yàn)表明，該值取20分鐘比較合理；②嵌入式Web服務(wù)器沒有必要發(fā)送探測報(bào)文，當(dāng)?；疃〞r(shí)器超時(shí)后可直接復(fù)位客戶端來關(guān)閉該連接.

2.4 TCP簡單確認(rèn)機(jī)制的實(shí)現(xiàn)

標(biāo)準(zhǔn)的TCP使用了慢啟動的滑動窗口機(jī)制，它允許發(fā)送方在等待一個(gè)確認(rèn)之前發(fā)送多個(gè)報(bào)文.對于使用了滑動窗口的TCP連接，其確認(rèn)是一種批量報(bào)文的確認(rèn).考慮到嵌入式處理器要對多個(gè)數(shù)據(jù)報(bào)連續(xù)傳輸進(jìn)行維護(hù)和處理，困難較大.仔細(xì)考察滑動窗口協(xié)議可以發(fā)現(xiàn)，滑動窗口的一個(gè)極限情況就是對每個(gè)報(bào)文都對應(yīng)發(fā)一個(gè)確認(rèn)，使用這個(gè)方法后，所有的處理只是針對單個(gè)數(shù)據(jù)報(bào)的發(fā)送進(jìn)行確認(rèn).這樣一來，既節(jié)約了系統(tǒng)的資源，又便于維護(hù)連接.當(dāng)然了，為了協(xié)議的兼容性，需要在通信的客戶端也使用簡單確認(rèn)的方法.因?yàn)槿绻蛻舳耸褂昧溯^大的窗口，就可能造成服務(wù)器被淹沒.

遵循以上思路，筆者采取了如下方式來實(shí)現(xiàn)TCP的簡單確認(rèn)機(jī)制：①在連接建立初期，服務(wù)器通過TCP的最大報(bào)文長度選項(xiàng)來通知客戶端，它以后的每個(gè)報(bào)文的最大長度都是一個(gè)定值M；②不允許交互雙方的任何一方使用窗口擴(kuò)大因子；③在三次握手[7]時(shí)的ACK+SYN報(bào)文中，將WndSize字段的大小取固定值W，通知客戶端其滑動窗口的大小是W；④讓W(xué)≤M，使得客戶端在每收到一個(gè)報(bào)文后就給服務(wù)器發(fā)送一個(gè)對應(yīng)的確認(rèn).W和M的值理論上都可以取到65536，考慮到底層網(wǎng)絡(luò)是以太網(wǎng)，其最大傳輸單元MTU等于1518，為了避免IP包被分片傳輸，發(fā)送的TCP包大小不能超過1518字節(jié).而最小以太首部、IP首部和TCP首部的長度和為54，還考慮到在建立連接初期要用到四字節(jié)的TCP最大報(bào)文選項(xiàng)，故發(fā)送TCP包的有效載荷數(shù)據(jù)長度最大只能取1518-54-4=1460字節(jié)，筆者建議取W=M=1400.

2.5 TCP連接的實(shí)現(xiàn)及狀態(tài)機(jī)的剪裁

TCP是一種面向連接的服務(wù).“面向連接”就意味著[8]：①客戶端和服務(wù)器彼此交換TCP數(shù)據(jù)之前，必須先建立一個(gè)TCP連接；②建立連接后進(jìn)行數(shù)據(jù)傳輸；③數(shù)據(jù)傳輸完畢后必須終止連接.其中，連接的建立是通過三向握手來建立的；連接的終止由四向握手而正常終止，也有可能由異常復(fù)位而帶來異常終止；為了清楚地跟蹤這三個(gè)階段中所發(fā)生的不同事件，TCP使用了TCP有限狀態(tài)機(jī).

三向握手是客戶端主動打開而服務(wù)器被動打開連接的情況，還有一種情況是雙方同時(shí)主動打開.為了減少程序的復(fù)雜度，筆者實(shí)現(xiàn)的服務(wù)器不支持這種主動打開，也就是說，它只被動的接收客戶端請求.

針對嵌入式Web應(yīng)用，筆者簡化了四向握手的過程，當(dāng)服務(wù)器收到客戶端的FIN報(bào)文后，直接將ACK報(bào)文和FIN報(bào)文合為一個(gè)ACK+FIN報(bào)文發(fā)送給客戶端.也就是說，筆者設(shè)計(jì)的服務(wù)器不支持連接的半關(guān)閉和主動關(guān)閉.

在標(biāo)準(zhǔn)的TCP服務(wù)中，服務(wù)器在連接發(fā)生以下情況之一時(shí)會向客戶端發(fā)送RST報(bào)文，使之能夠異常地終止一個(gè)不正常的連接：①客戶端TCP請求了一條到服務(wù)器并不存在的端口的連接；②服務(wù)器發(fā)現(xiàn)客戶端TCP已經(jīng)空閑很長一段時(shí)間；③服務(wù)器偵測到異常事件，并愿意異常終止該連接.考慮到嵌入式Web服務(wù)器的需求，針對上述標(biāo)準(zhǔn)的要求，筆者簡化如下：①由于嵌入式Web服務(wù)器沒有使用臨時(shí)端口，因此，目的端口不是80的數(shù)據(jù)包就不可能是TCP包，服務(wù)器可以簡單丟棄，不作任何處理；②由于嵌入式Web服務(wù)器的保活計(jì)時(shí)器超時(shí)時(shí)間設(shè)置得比較短，服務(wù)器能夠及時(shí)發(fā)現(xiàn)客戶端TCP已經(jīng)空閑，從而發(fā)出RST報(bào)文來關(guān)閉該連接；③服務(wù)器的異常事件很多，限于嵌入式Web服務(wù)器的應(yīng)用需求，只需要處理必要的異常事件：收到的報(bào)文沒有合法的ACK號；重發(fā)計(jì)時(shí)器超時(shí)并且重發(fā)次數(shù)超過規(guī)定值.

圖2 筆者裁減后的TCP有限狀態(tài)機(jī)

TCP有限狀態(tài)機(jī)越復(fù)雜，維護(hù)的開銷就越大，對系統(tǒng)的存儲能力和運(yùn)算能力要求就越高.標(biāo)準(zhǔn)的TCP有限狀態(tài)機(jī)太過復(fù)雜，筆者精簡如圖2所示.當(dāng)發(fā)生以下事件之一時(shí)，發(fā)生如圖2中的異常事件：收到RST報(bào)文、收到的報(bào)文沒有合法的ACK及?；钣?jì)時(shí)器超時(shí).

2.6 TCP重傳機(jī)制的實(shí)現(xiàn)

TCP的重傳機(jī)制是TCP成為一種可靠協(xié)議的基礎(chǔ).在標(biāo)準(zhǔn)的TCP協(xié)議實(shí)現(xiàn)中，重傳機(jī)制的核心是計(jì)算RTO(Retransmission TimeOut)，具體計(jì)算過程參見參考文獻(xiàn)[4].而對于嵌入式Web服務(wù)器有限的資源及比較低的處理速度來說，花費(fèi)巨大的代價(jià)來計(jì)算RTO并不值得.因此，精簡TCP的重傳首要任務(wù)是需要尋找一種簡化的方法以便于很容易地得到RTO.這里，筆者采用了最簡化的方式，即取固定的大小的RTO.

圖3 筆者設(shè)計(jì)的TCP重傳模塊順序鏈表結(jié)構(gòu)示意圖

RTO確定之后，剩下的就是當(dāng)重傳計(jì)時(shí)器超時(shí)后進(jìn)行重發(fā)TCP包的操作.可以有很多方法來實(shí)現(xiàn)該重發(fā)操作.筆者的設(shè)計(jì)思路是利用順序鏈表記錄每個(gè)已發(fā)送的TCP數(shù)據(jù)包，而當(dāng)收到TCP確認(rèn)報(bào)文時(shí)就從該順序鏈表中刪除相應(yīng)的TCP數(shù)據(jù)包.同時(shí)，每隔一個(gè)RTO時(shí)間就觸發(fā)一個(gè)TCP重傳事件，以發(fā)送那些已經(jīng)超時(shí)但沒有收到確認(rèn)的TCP數(shù)據(jù)包.其中，順序鏈表的結(jié)構(gòu)如圖3所示.順序鏈表的頭指針、鏈表長度、該TCP數(shù)據(jù)包中TCP層數(shù)據(jù)部分的長度分別由TCB中的MemPoolHeader、MemPkgNum、TcpDataLen字段給出，如圖2所示.圖3中，BuffPtr和TotalPkgLen字段定義了可能需要重發(fā)的TCP報(bào)文的首地址和總長度，這便于直接調(diào)用發(fā)送驅(qū)動函數(shù)進(jìn)行重發(fā)操作，也便于在ARP解析失敗后直接進(jìn)行ARP重傳操作的處理.Next字段將該連接中所有可能需要重發(fā)的TCP報(bào)文都掛在一個(gè)順序鏈表上.ExpectAck是該結(jié)點(diǎn)中的關(guān)鍵字，便于在收到TCP確認(rèn)后進(jìn)行相應(yīng)的刪除操作.

3 嵌入式TCP的測試方法及結(jié)果

根據(jù)嵌入式TCP協(xié)議的特點(diǎn)，筆者進(jìn)行了三種測試：①跟蹤三向握手及對應(yīng)的狀態(tài)圖變遷；②測試TCP?；钣?jì)時(shí)器；③跟蹤TCP重傳.這里采用測試方法是將嵌入式Web服務(wù)與PC機(jī)在RJ-45口及串口分別對接[9].利用串口精靈接收嵌入式Web服務(wù)器的輸出并顯示，利用Sniffer Pro抓取PC機(jī)發(fā)送和接收的數(shù)據(jù)包.

3.1 三向握手及狀態(tài)圖的測試

圖4 服務(wù)器收到的SYN報(bào)文

如圖4所示，在5.058s時(shí)，服務(wù)器TCP收到了客戶端TCP發(fā)起SYN請求，其源端口是1507，包序號是291941000，這個(gè)包首部長度是28字節(jié)，由于筆者設(shè)計(jì)的系統(tǒng)不支持接收包的TCP選項(xiàng)，故該包的此選項(xiàng)被忽略.在收到這個(gè)包后，服務(wù)端TCP有限狀態(tài)機(jī)就變成了SYN_RCVE；接著由服務(wù)器TCP產(chǎn)生一個(gè)SYN+ACK報(bào)文，其序號字段值是640001，確認(rèn)號是291941001，如圖5所示.

圖5 服務(wù)器發(fā)送SYN+ACK報(bào)文

圖6 服務(wù)器收到ACK報(bào)文

圖7 客戶端發(fā)送的HTTP請求

然后是客戶端給服務(wù)器發(fā)送ACK報(bào)文以確認(rèn)服務(wù)器到客戶端的連接，其序號是291941001，確認(rèn)號是640002，服務(wù)器在收到該報(bào)文后，其TCP有限狀態(tài)機(jī)變遷為ESTABLISHED，如圖6所示.當(dāng)建立連接后，客戶端緊接著就發(fā)送了HTTP請求，如圖7所示.

由上述測試可以得出結(jié)論：筆者設(shè)計(jì)的TCP連接管理模塊工作正常，并且在此期間其TCP有限狀態(tài)機(jī)按照筆者設(shè)計(jì)的方式進(jìn)行變遷.

3.2 ?；钣?jì)時(shí)器及狀態(tài)圖的測試

為了方便測試，筆者做了如下設(shè)置：讓?；钣?jì)時(shí)器每隔5s輪詢一次，并設(shè)置其超時(shí)時(shí)間值為15s.這時(shí)輸出的信息如圖8所示.從該圖的第3、第4及第7個(gè)報(bào)文后輸出的信息(即“TCP ActiveTimer update!”)可以看出，在建立連接后，每當(dāng)TCP收到一個(gè)包，它都要更新該連接的?；钣?jì)時(shí)器.在收到客戶端最后一個(gè)包(即圖中的第7個(gè)包)后，每隔5s輪詢一次Inactivity_Tcp()函數(shù)，在該函數(shù)中Conn[0].ActTimer字段被減一，當(dāng)其減至0時(shí)，說明保活計(jì)時(shí)器超時(shí)，于是發(fā)送RST報(bào)文(對于圖中的第8個(gè)包)到客戶端.接著關(guān)閉服務(wù)器端的該TCP連接，并使TCP狀態(tài)變成LISTEN態(tài).此后，由于此時(shí)沒有TCP連接，故沒有輸出相關(guān)的信息.

由上述測試可知，TCP?；钣?jì)時(shí)器工作正常，并且當(dāng)?；畛瑫r(shí)時(shí)，TCP有限狀態(tài)機(jī)按預(yù)期地方式變遷到LISTEN態(tài).

圖8 測試TCP?；钣?jì)時(shí)器輸出信息

圖9 測試TCP順序鏈表時(shí)的輸出信息

圖10 測試TCP重傳計(jì)時(shí)器輸出信息

3.3 TCP重傳的測試

由于筆者設(shè)計(jì)的系統(tǒng)中，TCP重傳的實(shí)現(xiàn)依賴于順序鏈表，因此，為了使服務(wù)器的重發(fā)模塊運(yùn)行穩(wěn)定，測試順序鏈表的操作就必不可少.測試順序鏈表時(shí)輸出的信息如圖9所示.每當(dāng)發(fā)送一個(gè)非RST型的TCP報(bào)文都被插入到順序鏈表中，如圖9中信息“Insert_Mem(): firstly insert PkgNum=6”表明：第2個(gè)TCP報(bào)文被插入到順序鏈表的第一個(gè)位置()；而每當(dāng)收到報(bào)文時(shí)，就用該報(bào)文的ACK號在順序鏈表中找到該報(bào)文，如“Search_Mem(): find PkgNum=6 Pkg”；接著刪掉順序鏈表中該報(bào)文以前的TCP報(bào)文，如“Delete_Mem():the first Pkg of PkgNum=5 deleted”和“Delete_BeforSeqMem(): total 2 pkgs are deleted”表明服務(wù)器利用收到的報(bào)文9的ACK號刪掉了順序鏈表中對應(yīng)的報(bào)文5和報(bào)文6；信息“Free_Mem(): free the PkgNum=5 success”則表明該包的空間被成功地釋放.

由于將系統(tǒng)直接接到PC上時(shí)，網(wǎng)絡(luò)環(huán)境比較穩(wěn)定，為了迫使TCP啟動重傳模塊，可以在服務(wù)器TCP層發(fā)送數(shù)據(jù)時(shí)人為將系統(tǒng)與PC機(jī)的網(wǎng)絡(luò)斷開一會兒后迅速連上.此時(shí)，調(diào)試信息如圖10所示.由圖10可以看出，由于沒有及時(shí)收到客戶端的ACK而導(dǎo)致重發(fā)了報(bào)文5和報(bào)文6，并且在收到的報(bào)文9后刪掉了順序鏈表中對應(yīng)的報(bào)文5和報(bào)文6.

通過上述跟蹤TCP收發(fā)包的過程及重傳操作的測試可知，順序鏈表的操作無誤、TCP重傳模塊工作正常.

4 結(jié)語

筆者詳細(xì)討論了如何設(shè)計(jì)并實(shí)現(xiàn)精簡的TCP協(xié)議，并做了相關(guān)測試，驗(yàn)證了該設(shè)計(jì)思路的可行性.這為嵌入式設(shè)備中順利實(shí)現(xiàn)嵌入式TCP/IP協(xié)議棧，進(jìn)而實(shí)現(xiàn)物聯(lián)網(wǎng)技術(shù)打下了堅(jiān)實(shí)的基礎(chǔ).

參考文獻(xiàn)：

[1]International Telecommunication Union UIT[R].ITU Internet Reports 2005: The Internet of Things. 2005.

[2]馮翠麗，劉波濤.一種嵌入式TCP/IP協(xié)議棧的設(shè)計(jì)與實(shí)現(xiàn)[J].長江大學(xué)學(xué)報(bào)(自然科學(xué)版)理工卷，2008，5(4)：331～333.

[3]李金梁，景博.嵌入式Internet中TCP協(xié)議的設(shè)計(jì)與實(shí)現(xiàn)[J].微計(jì)算機(jī)信息，2005，21(7)：40～138.

[4]RFC793 - Transmission Control Protocol [S]. IETF，1981.

[5]謝希仁.計(jì)算機(jī)網(wǎng)絡(luò)[M] .北京：電子工業(yè)出版社，2008：187～219.

[6]劉波濤.物聯(lián)網(wǎng)中嵌入式TCP/IP協(xié)議棧的設(shè)計(jì)技巧[J].通化師范學(xué)院學(xué)報(bào)，2011，32(2)：40～42.

[7]夏春濤，杜學(xué)繪，郝耀輝，等.基于.NET 平臺的SYN Flood攻擊測試的實(shí)現(xiàn)[J].計(jì)算機(jī)工程與設(shè)計(jì)，2011，32(6)：1918～1921.

[8]李立清，路海.應(yīng)用于嵌入式系統(tǒng)的TCP簡化實(shí)現(xiàn)方法[J].計(jì)算機(jī)工程與應(yīng)用，2004(7)：142～145.

[9]劉波濤，馮翠麗，王青海，等.應(yīng)用RTL8019AS的嵌入式Web服務(wù)器硬件實(shí)現(xiàn)[J].長江大學(xué)學(xué)報(bào)(自然科學(xué)版)，2008，5(1)，75～78.