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

篇1

關(guān)鍵詞：tcp/IP協(xié)議網(wǎng)絡(luò)接口層網(wǎng)絡(luò)層傳輸層端口應(yīng)用層

中圖分類號(hào)：TP311.52 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1007-9416（2012）03-0000-00

因特網(wǎng)是當(dāng)今世界上最大的信息網(wǎng)絡(luò)，自80年代以來(lái)，它的應(yīng)用已從軍事、科研與學(xué)術(shù)領(lǐng)域進(jìn)入商業(yè)、傳播和娛樂(lè)等領(lǐng)域，并于90年代成為發(fā)展最快的傳播媒介。信息傳輸和網(wǎng)絡(luò)互連是根據(jù)協(xié)議進(jìn)行的，而因特網(wǎng)使用的就是TCP/IP協(xié)議。TCP/IP協(xié)議是因特網(wǎng)最基本的協(xié)議，是因特網(wǎng)的基礎(chǔ)。TCP/IP的全稱是Transmission Control Protocol/Internet Protocol的簡(jiǎn)寫，中文譯為傳輸控制協(xié)議/因特網(wǎng)互聯(lián)協(xié)議。

1969年，因特網(wǎng)的前身阿帕網(wǎng)（ARPAnet），誕生之初僅連接了4臺(tái)計(jì)算機(jī)，供科學(xué)家們進(jìn)行計(jì)算機(jī)聯(lián)網(wǎng)實(shí)驗(yàn)用。到70年代，ARPAnet已經(jīng)有了好幾十個(gè)計(jì)算機(jī)網(wǎng)絡(luò)，但是每個(gè)網(wǎng)絡(luò)只能在網(wǎng)絡(luò)內(nèi)部的計(jì)算機(jī)之間互聯(lián)通信，不同計(jì)算機(jī)網(wǎng)絡(luò)之間仍然不能互通?？ǘ饔?973 年提出開(kāi)放的網(wǎng)絡(luò)結(jié)構(gòu)的思想。所謂開(kāi)放的網(wǎng)絡(luò)結(jié)構(gòu)，指的是任何類型的網(wǎng)絡(luò)都可以通過(guò)“網(wǎng)絡(luò)互聯(lián)結(jié)構(gòu)”與其他網(wǎng)絡(luò)連接，這是因特網(wǎng)的核心技術(shù)思想。為了適應(yīng)開(kāi)放的網(wǎng)絡(luò)結(jié)構(gòu)環(huán)境的需要，瑟夫與卡恩共同開(kāi)發(fā)了TCP/IP協(xié)議，并于1974年正式提出。TCP／IP是實(shí)現(xiàn)不同網(wǎng)絡(luò)互聯(lián)的標(biāo)準(zhǔn)，成功地解決了不同硬件平臺(tái)、不同網(wǎng)絡(luò)產(chǎn)品和不同操作系統(tǒng)之間的兼容性問(wèn)題。

TCP/IP協(xié)議定義了電子設(shè)備如何連入因特網(wǎng)，以及數(shù)據(jù)如何在它們之間傳輸?shù)臉?biāo)準(zhǔn)，它是因特網(wǎng)事實(shí)上的國(guó)際標(biāo)準(zhǔn)。協(xié)議采用了4層的層級(jí)結(jié)構(gòu)，層次由低到高依次為：網(wǎng)絡(luò)接口層、網(wǎng)絡(luò)層、傳輸層、應(yīng)用層。每一層都調(diào)用它的下一層所提供的服務(wù)來(lái)完成自己的需求。

1、網(wǎng)絡(luò)接口層

網(wǎng)絡(luò)接口層（通信子網(wǎng)）是數(shù)據(jù)包從一個(gè)設(shè)備的網(wǎng)絡(luò)層傳輸?shù)搅硗庖粋€(gè)設(shè)備的網(wǎng)絡(luò)層的方法。由于ARPNET的設(shè)計(jì)者注重的是網(wǎng)絡(luò)互聯(lián)，允許網(wǎng)絡(luò)接口層采用已有的或是將來(lái)有的各種協(xié)議，所以這個(gè)層次中沒(méi)有提供專門的協(xié)議，因此網(wǎng)絡(luò)接口層實(shí)際上并不是因特網(wǎng)協(xié)議組中的一部分。實(shí)際上，TCP/IP協(xié)議可以通過(guò)網(wǎng)絡(luò)接口層連接到任何網(wǎng)絡(luò)上，例如X.25交換網(wǎng)或IEEE802局域網(wǎng)。[1]

2、網(wǎng)絡(luò)層

網(wǎng)絡(luò)層可以接收由網(wǎng)絡(luò)接口層發(fā)來(lái)的數(shù)據(jù)包，并把該數(shù)據(jù)包發(fā)送到傳輸層；也可以把從傳輸層接收來(lái)的數(shù)據(jù)包傳送到網(wǎng)絡(luò)接口層。網(wǎng)絡(luò)層的數(shù)據(jù)包是不可靠的，因?yàn)榫W(wǎng)絡(luò)層并沒(méi)有做任何事情來(lái)確認(rèn)數(shù)據(jù)包是按順序發(fā)送的或者沒(méi)有被破壞。數(shù)據(jù)包中含有發(fā)送它的主機(jī)的地址（源IP地址）和接收它的主機(jī)的地址（目IP的地址）。

網(wǎng)絡(luò)層的協(xié)議包括IP協(xié)議、ICMP協(xié)議、ARP協(xié)議、RARP協(xié)議等，其中IP協(xié)議是網(wǎng)絡(luò)層的核心協(xié)議，完成數(shù)據(jù)從從源網(wǎng)絡(luò)傳輸?shù)侥康木W(wǎng)絡(luò)的基本任務(wù)。IP協(xié)議定義了數(shù)據(jù)包在網(wǎng)際傳送時(shí)的格式，目前使用最多的是IPv4版本，這一版本中用32位定義IP地址，可供使用的地址數(shù)超過(guò)37.2億，但是仍然不能滿足現(xiàn)今全球網(wǎng)絡(luò)飛速發(fā)展的需求，因此IPv6版本應(yīng)運(yùn)而生。在IPv6版本中，IP地址共有128位，這樣的IP地址數(shù)是原IP地址數(shù)的296倍，目前來(lái)看，IPV6的IP地址是不可能用完的。[2]

3、傳輸層

傳輸層提供應(yīng)用進(jìn)程間的通信。兩個(gè)系統(tǒng)之間的應(yīng)用進(jìn)程的通信，是用每個(gè)信息中的如下四項(xiàng)進(jìn)行確認(rèn)的：源IP地址、目的IP地址、源端口號(hào)、目的端口號(hào)。其中源IP地址和目的IP地址已在網(wǎng)絡(luò)層的介紹中說(shuō)明。TCP/IP的端口號(hào)是一個(gè)軟件結(jié)構(gòu)，用來(lái)標(biāo)識(shí)本地計(jì)算機(jī)應(yīng)用層中各個(gè)進(jìn)程在和運(yùn)輸層交互時(shí)的接口。在因特網(wǎng)不同的計(jì)算機(jī)中，相同的端口號(hào)是沒(méi)有關(guān)聯(lián)的。一個(gè)端口號(hào)對(duì)應(yīng)一個(gè)16比特的數(shù)。服務(wù)進(jìn)程通常使用一個(gè)固定的端口，例如，SMTP使用25、HTTP使用80?？蛻暨M(jìn)程通常使用系統(tǒng)分配的一個(gè)隨機(jī)端口號(hào)。[2]

傳輸層協(xié)議主要是傳輸控制協(xié)議TCP(Transmission Control Protocol）和用戶數(shù)據(jù)報(bào)協(xié)議UDP(User Datagram protocol）。TCP協(xié)議是一種面向連接的、可靠的的傳輸機(jī)制。通信之前要建立連接，通訊完成時(shí)要拆除連接。它提供一種可靠的字節(jié)流保證數(shù)據(jù)完整、無(wú)損并且按順序到達(dá)，TCP協(xié)議還能盡量連續(xù)不斷地測(cè)試網(wǎng)絡(luò)的負(fù)載并且控制發(fā)送數(shù)據(jù)的速度以避免網(wǎng)絡(luò)過(guò)載，對(duì)于一些需要高可靠性的應(yīng)用，可以選擇TCP協(xié)議。UDP是一種面向無(wú)連接的，不可靠的傳輸機(jī)制。不是它特別不可靠，而是它不檢查數(shù)據(jù)包是否已經(jīng)到達(dá)目的地，并且不保證它們按順序到達(dá)。UDP的典型應(yīng)用是如音頻和視頻等這樣的流媒體，對(duì)它們而言，按時(shí)到達(dá)比可靠性更重要，或者如DNS查找這樣的簡(jiǎn)單查詢／響應(yīng)應(yīng)用，否則建立可靠的連接所需的額外開(kāi)銷將是不成比例地大。

4、應(yīng)用層

應(yīng)用層是大多數(shù)與網(wǎng)絡(luò)相關(guān)的程序?yàn)榱送ㄟ^(guò)網(wǎng)絡(luò)與其他程序通信所使用的層。數(shù)據(jù)從與網(wǎng)絡(luò)相關(guān)的程序以這種應(yīng)用程序使用的格式編碼成標(biāo)準(zhǔn)協(xié)議的格式并進(jìn)行傳送。來(lái)自應(yīng)用程序的數(shù)據(jù)一旦被編碼成一個(gè)標(biāo)準(zhǔn)的應(yīng)用層協(xié)議，它將被傳送到TCP/IP協(xié)議的下一層。

應(yīng)用層一般提供面向用戶的服務(wù)，如HTTP、FTP、SMTP、POP3。HTTP是超文本傳輸協(xié)議，用于瀏覽網(wǎng)頁(yè)，F(xiàn)TP是文件傳輸協(xié)議，一般用于下載和上傳文件。SMTP是簡(jiǎn)單郵件傳輸協(xié)議，用來(lái)控制信件的發(fā)送、中轉(zhuǎn)。POP3是郵局協(xié)議第3版本，用于接收郵件。

TCP/IP有一個(gè)非常重要的特點(diǎn)，就是開(kāi)放性，即TCP/IP的規(guī)范和Internet的技術(shù)都是公開(kāi)的。目的就是使任何廠家生產(chǎn)的計(jì)算機(jī)都能相互通信，使Internet成為一個(gè)開(kāi)放的系統(tǒng)。這正是后來(lái)Internet得到飛速發(fā)展的重要原因。

參考文獻(xiàn)

[1]萬(wàn)雅靜,黃巍,梁玉鳳.網(wǎng)絡(luò)基礎(chǔ)實(shí)用教程[C].北京:機(jī)械工業(yè)出版社,2011:14-16.

篇2

關(guān)鍵詞：TCP/IP；網(wǎng)絡(luò)擁塞；擁塞控制；算法

中圖分類號(hào)：TP393 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2013）07-1513-03

隨著網(wǎng)絡(luò)用戶的不斷增加，制約網(wǎng)絡(luò)應(yīng)用和發(fā)展的關(guān)鍵瓶頸是網(wǎng)絡(luò)擁塞問(wèn)題，對(duì)進(jìn)入網(wǎng)絡(luò)的數(shù)據(jù)流量進(jìn)行控制是擁塞控制的主要目的，通過(guò)控制擁塞保證用戶發(fā)送的數(shù)據(jù)流對(duì)通信網(wǎng)絡(luò)不造成阻塞，并且瓶頸資源能夠被合理的使用?？梢栽诰W(wǎng)絡(luò)協(xié)議的不同層次上實(shí)施擁塞控制，首先對(duì)網(wǎng)絡(luò)擁塞產(chǎn)生的原因進(jìn)行分析，分類、歸納擁塞控制，持續(xù)時(shí)間越長(zhǎng)的擁塞需要越高的控制層次來(lái)解決擁塞問(wèn)題，并且擁塞控制的實(shí)現(xiàn)主要在傳輸層和網(wǎng)絡(luò)層。

1 網(wǎng)絡(luò)擁塞概述

網(wǎng)絡(luò)的性能會(huì)逐漸下降，當(dāng)過(guò)多的數(shù)據(jù)包存在于網(wǎng)絡(luò)中時(shí)，這種現(xiàn)象被稱為網(wǎng)絡(luò)擁塞。吞吐量下降在發(fā)生網(wǎng)絡(luò)擁塞的時(shí)候，并且嚴(yán)重的時(shí)候擁塞崩潰的現(xiàn)象會(huì)在發(fā)生。通常而言，增加的網(wǎng)絡(luò)負(fù)載導(dǎo)致網(wǎng)絡(luò)效率降低，在此時(shí)容易發(fā)生擁塞崩潰的現(xiàn)象。擁塞現(xiàn)象的描述如圖1 。

圖1 擁塞現(xiàn)象的描述

在較小的網(wǎng)絡(luò)負(fù)載時(shí)，吞吐量隨著負(fù)載的增長(zhǎng)也會(huì)增長(zhǎng)，兩者為線性關(guān)系，相應(yīng)的時(shí)間也緩慢增長(zhǎng)。當(dāng)網(wǎng)絡(luò)容量被負(fù)載達(dá)到的時(shí)候，相應(yīng)的時(shí)間急劇增加，吞吐量呈現(xiàn)緩慢增長(zhǎng)，這一點(diǎn)被成為Knee點(diǎn)。吞吐量在負(fù)載超過(guò)一定量時(shí)開(kāi)始急劇下降，路由器在負(fù)載繼續(xù)增加的情況下開(kāi)始丟包，這一點(diǎn)是死鎖點(diǎn)。在擁塞控制機(jī)制中有擁塞控制和擁塞避免兩種方式，前者的目的是在控制運(yùn)行在死鎖點(diǎn)附近的網(wǎng)絡(luò)擁塞現(xiàn)象，后者是避免網(wǎng)絡(luò)運(yùn)行在Knee點(diǎn)的時(shí)候發(fā)證擁塞現(xiàn)象。前者是一種恢復(fù)措施，使網(wǎng)絡(luò)從擁塞中恢復(fù)過(guò)來(lái)，進(jìn)入正常運(yùn)行狀態(tài)；后者是一種預(yù)防措施，使網(wǎng)絡(luò)維持在低延遲、高吞吐量狀態(tài)，網(wǎng)絡(luò)擁塞現(xiàn)象得以避免。

2 分析網(wǎng)絡(luò)擁塞產(chǎn)生的原因

網(wǎng)絡(luò)的處理能力和資源容量被網(wǎng)絡(luò)的負(fù)載超出了是網(wǎng)絡(luò)擁塞產(chǎn)生的根本原因，也就是網(wǎng)絡(luò)對(duì)資源的總需求量大于總的可用資源，下面分析一下網(wǎng)絡(luò)擁塞產(chǎn)生的原因。

1）不足的存儲(chǔ)空間

一個(gè)輸出端口需要對(duì)各種報(bào)文在接收端口的緩沖區(qū)域中進(jìn)行排隊(duì)，因?yàn)樗邮艿膱?bào)文是由多個(gè)端口轉(zhuǎn)發(fā)而來(lái)的，若滿足使用要求的緩沖空間在輸出端，報(bào)文就會(huì)丟失，尤其是突發(fā)的數(shù)據(jù)流也會(huì)丟失。這一矛盾的緩解通過(guò)增加存儲(chǔ)空間來(lái)實(shí)現(xiàn)。但將會(huì)出現(xiàn)更加嚴(yán)重的擁塞現(xiàn)象在不斷增加存儲(chǔ)容量時(shí)。因?yàn)榫彌_區(qū)網(wǎng)絡(luò)結(jié)點(diǎn)的延時(shí)增加的時(shí)候，報(bào)文也會(huì)增加，最終端到端的確認(rèn)時(shí)間也增加了，就會(huì)產(chǎn)生超時(shí)重發(fā)。網(wǎng)絡(luò)負(fù)載因此會(huì)進(jìn)一步增加，擁塞現(xiàn)象最終會(huì)加重。

2）不足的寬帶容量

在低速鏈路中流通的高速數(shù)據(jù)流經(jīng)常會(huì)產(chǎn)生擁塞現(xiàn)象，在數(shù)據(jù)發(fā)送率小于信道容量的時(shí)候，擁塞現(xiàn)象才會(huì)避免。不然在節(jié)點(diǎn)的緩沖區(qū)域堆集大量的報(bào)文就會(huì)產(chǎn)生擁塞。

3）速度緩慢的節(jié)點(diǎn)處理機(jī)

報(bào)文被放入其CPU隊(duì)列中進(jìn)行緩存當(dāng)被路由器對(duì)其進(jìn)行接收的時(shí)候，路由器來(lái)選擇路由并且把報(bào)文轉(zhuǎn)發(fā)到相應(yīng)的節(jié)點(diǎn)。此時(shí)路由器的處理速度的快慢是能否出網(wǎng)絡(luò)現(xiàn)擁塞的關(guān)鍵因素。

總而言之，只有考慮到從以上三方面的因素，來(lái)解決擁塞現(xiàn)象，優(yōu)化整體性能。只考慮一方面內(nèi)的因素?fù)砣麊?wèn)題不僅不能夠解決，反而擁塞問(wèn)題還會(huì)更加嚴(yán)重。

3 控制擁塞的策略

1）Tahoe和Reno擁塞控制算法

隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，TCP擁塞控制有快速恢復(fù)（fast recovery）、快速重傳（fast retransmit）、擁塞避免（congertion avoidance）、慢啟動(dòng)（slow start）這四種，其中常用的是TCP Tahoe和TCP Reno兩種算法。快速重傳、擁塞避免、慢啟動(dòng)是Tahoe包括的三個(gè)部分，并且改進(jìn)了往返時(shí)間RTT，從而對(duì)超時(shí)重發(fā)計(jì)時(shí)器進(jìn)行更好的重新設(shè)定，具體的算法描述如下：

最多發(fā)一個(gè)報(bào)文在一個(gè)RTT內(nèi)。其中窗口的大小由w來(lái)表示，慢啟動(dòng)門限值由ssthresh來(lái)表示，是慢啟動(dòng)進(jìn)入擁塞避免的分界值。

這種算法的基本思想是通過(guò)線性增加速率源端對(duì)網(wǎng)絡(luò)中的空閑容量進(jìn)行探測(cè)，當(dāng)擁塞被檢測(cè)到的時(shí)候用指數(shù)遞減它的速率，在源端丟包被檢測(cè)到的時(shí)候確認(rèn)擁塞。實(shí)現(xiàn)擁塞避免和慢啟動(dòng)的例子如圖圖2 慢啟動(dòng)和擁塞避免的實(shí)現(xiàn)舉例

由上圖可知，每當(dāng)一個(gè)丟包被檢測(cè)到的時(shí)候，慢啟動(dòng)門限值被源端設(shè)置為當(dāng)前窗口的一半，對(duì)丟失的包重傳，窗口被設(shè)置為1，重新進(jìn)入慢啟動(dòng)。

2）TCP中擁塞控制的關(guān)鍵

TCP協(xié)議在Internet上被95%的數(shù)據(jù)流使用，對(duì)發(fā)送端的發(fā)送速率進(jìn)行控制是TCP中擁塞控制的關(guān)鍵。可以采用控制算法中的乘法減少加法增加（AIMD）的來(lái)解決擁塞問(wèn)題。每個(gè)擁塞窗口由發(fā)送方維持著，如果沒(méi)有發(fā)生窗口中的報(bào)文丟失，那么目前是良好的網(wǎng)絡(luò)狀況，窗口的大小被發(fā)送者加大，同時(shí)報(bào)文的發(fā)送速率加大。當(dāng)窗口內(nèi)的一個(gè)報(bào)文被發(fā)送方發(fā)現(xiàn)丟失的時(shí)候，則認(rèn)為報(bào)文的丟失是由網(wǎng)絡(luò)擁塞造成的，于是窗口的大小減半，隨之發(fā)送速率也減小，擁塞加重的現(xiàn)象得以避免。

3）慢啟動(dòng)階段的擁塞控制

一個(gè)連接被TCP啟動(dòng)的時(shí)候多個(gè)數(shù)據(jù)包被發(fā)送到網(wǎng)絡(luò)時(shí)會(huì)造成不必要的網(wǎng)絡(luò)擁塞和數(shù)據(jù)丟失，而慢啟動(dòng)可以避免這種現(xiàn)象的發(fā)生，還能避免吞吐量在AIMD算法中增加引起網(wǎng)速過(guò)慢的問(wèn)題。初始化擁塞窗口cwnd為一個(gè)數(shù)據(jù)包大小在新的TCP連接建立的時(shí)候，按照cwnd大小源端進(jìn)行數(shù)據(jù)的發(fā)送，也就是隨著RTT的增長(zhǎng)cwnd呈指數(shù)增長(zhǎng)。

4）擁塞避免階段

處理丟失數(shù)據(jù)包的方法被稱為擁塞避免算法。當(dāng)重復(fù)確認(rèn)被發(fā)送方收到或數(shù)據(jù)包超時(shí)被發(fā)送方發(fā)現(xiàn)的時(shí)候，網(wǎng)絡(luò)擁塞就會(huì)發(fā)生，此時(shí)進(jìn)入擁塞避免階段，置為1的cwnd在數(shù)據(jù)包發(fā)送超時(shí)并且重復(fù)確認(rèn)被發(fā)送方收到時(shí)，那么每收到一個(gè)ACK，cwnd將增加segsize*segsize/cwnd。其中數(shù)據(jù)包的大小被稱為segsize，cwnd在擁塞避免階段不是呈指數(shù)增長(zhǎng)而是呈線性增長(zhǎng)的。

5）快速恢復(fù)和快速重傳階段

當(dāng)3個(gè)或3個(gè)以上的重復(fù)ACK被源端收到的時(shí)候，發(fā)送方認(rèn)為出現(xiàn)數(shù)據(jù)包丟失的現(xiàn)象，對(duì)數(shù)據(jù)包進(jìn)行重新傳輸，而且啟動(dòng)閾值ssthresh被設(shè)置為一半的當(dāng)前cwnd，然后對(duì)丟失的數(shù)據(jù)包重新傳輸，這個(gè)過(guò)程被稱為快速傳輸。系統(tǒng)執(zhí)行的不是慢啟動(dòng)算法而是擁塞避免算法，這被稱為快速恢復(fù)，能夠使TCP連接的吞吐量提高。另外，不必要的重傳超時(shí)要想避免可以應(yīng)用一種受限傳輸機(jī)制：在接收方中允許如果有廣播窗口，一個(gè)或兩個(gè)重復(fù)的ACK被發(fā)送方接收到后，發(fā)送方對(duì)新的報(bào)文段繼續(xù)傳輸，具有較小窗口的TCP在受限的傳輸機(jī)制的允許下進(jìn)行錯(cuò)誤碼恢復(fù)，不必要的重傳得以避免。

6）IP 擁塞控制策略

對(duì)于Internet 的健壯性而言基于窗口的端到端的TCP擁塞控制起著關(guān)鍵性作用，在Internet的迅速發(fā)展的今天網(wǎng)絡(luò)的規(guī)模也越來(lái)越大，并且日趨復(fù)雜的結(jié)構(gòu)在不斷出現(xiàn)，端對(duì)端的擁塞控制已經(jīng)不能滿足需求，那么對(duì)擁塞的控制也需要在網(wǎng)絡(luò)層進(jìn)行，需要在路由器中采用數(shù)據(jù)丟棄和排隊(duì)算法策略。其中丟棄策略進(jìn)行分配緩存是通過(guò)決定哪些包被丟棄來(lái)實(shí)現(xiàn)的，排隊(duì)算法進(jìn)行分配寬帶是是通過(guò)決定哪些包可以被傳輸來(lái)實(shí)現(xiàn)的。IP 擁塞控制的方法有：先進(jìn)先出、公平排隊(duì)算法、加權(quán)公平排隊(duì)算法。

總而言之，無(wú)論哪種擁塞控制方法都有它的優(yōu)勢(shì)，總體上包括TCP 擁塞控制和IP 擁塞控制兩種，下面表格針對(duì)這兩種方式進(jìn)行了比較：

[TCP 與IP 擁塞控制的比較＼&參數(shù)＼&TCP 擁塞控制＼&IP 擁塞控制＼&實(shí)現(xiàn)位置＼&端系統(tǒng)中＼&網(wǎng)絡(luò)內(nèi)部＼&短期擁塞＼&可以處理＼&較好處理＼&長(zhǎng)期擁塞＼&可以處理＼&無(wú)法處理＼&不同數(shù)據(jù)流間的公平性＼&難于實(shí)現(xiàn)＼&可以實(shí)現(xiàn)＼&延遲＼&較大＼&無(wú)＼&]

4 結(jié)束語(yǔ)

通過(guò)上述網(wǎng)絡(luò)擁塞概述、網(wǎng)絡(luò)擁塞產(chǎn)生的原因、控制擁塞的策略，可以得知，隨著互聯(lián)網(wǎng)用戶越來(lái)越多，網(wǎng)絡(luò)寬帶等資源也在持續(xù)增加，但是用戶的需求仍然不能得到滿足，逐漸暴漏出網(wǎng)絡(luò)擁塞問(wèn)題，擁塞如何更好的預(yù)防和控制，使網(wǎng)絡(luò)具有同時(shí)到達(dá)資源并且低延時(shí)和低丟包率的最大效用。無(wú)論TCP擁塞控制還是IP 擁塞控制都有自身的優(yōu)勢(shì)，要想在這個(gè)基礎(chǔ)上更好的解決網(wǎng)絡(luò)擁塞問(wèn)題，需要結(jié)合各種方法并且靈活的使用。

參考文獻(xiàn)：

[1] The Stream Control Transmission Protocol （SCTP） as a Transport for the Session Initiation Protocol（SIP）.internet Draft，IETF，Jan，2005 Work in Progress.

[2] 黃衛(wèi)平.TCP/IP 協(xié)議中擁塞控制算法探討[J].廣西工學(xué)院學(xué)報(bào)，2003，14（2）：71-73.

[3] Gonzalo Camarillo，Raimo Kantola.Evaluation of Transport Protocols for SIP .IEEE Network September/October 2003.

[4] 武航星，慕德俊，潘文平.網(wǎng)絡(luò)擁塞算法綜述[J].計(jì)算機(jī)科學(xué)，2007，34（2）：51-54.

篇3

【關(guān)鍵詞】 嵌入式 TCP/IP協(xié)議 以太網(wǎng)

一、引言

嵌入式網(wǎng)絡(luò)通信在各個(gè)方面都得到了非常廣泛的運(yùn)用。目前最常見(jiàn)的就是總線和USB數(shù)據(jù)傳輸方式，傳輸速度即使可以達(dá)到較快的水平，但是其并不能夠滿足長(zhǎng)距離的數(shù)據(jù)傳輸。因此，以太網(wǎng)能夠彌補(bǔ)其在數(shù)據(jù)傳輸方面的缺陷。以太網(wǎng)能夠?qū)崿F(xiàn)一百米距離點(diǎn)對(duì)點(diǎn)的數(shù)據(jù)傳輸，如果要實(shí)現(xiàn)更加遠(yuǎn)距離的數(shù)據(jù)傳輸，則需要使用路由器或者交換機(jī)來(lái)完成。此文基于對(duì)CP2200嵌入式TCP/IP協(xié)議進(jìn)行探究，并實(shí)現(xiàn)以太網(wǎng)嵌入式系統(tǒng)設(shè)計(jì)。

二、嵌入式TCP/IP協(xié)議的探究與實(shí)現(xiàn)

TCP/IP協(xié)議棧從上到下分別是由應(yīng)用層、運(yùn)輸層、網(wǎng)絡(luò)層和網(wǎng)絡(luò)接口層所組成的四層結(jié)構(gòu)，每一層各司其職，都有著不同的網(wǎng)絡(luò)協(xié)議。依據(jù)軟件實(shí)際使用的情況，在嵌入式系統(tǒng)當(dāng)中為了達(dá)到網(wǎng)絡(luò)通信的目的，需要對(duì)TCP/IP協(xié)議族進(jìn)行裁剪。在對(duì)軟件進(jìn)行初始化的時(shí)候，也對(duì)單片機(jī)同時(shí)進(jìn)行了初始化，其中包括對(duì)系統(tǒng)時(shí)鐘、定時(shí)器、端口和串口進(jìn)行了初始化。當(dāng)然還有CP2200進(jìn)行初始化，其中包括對(duì)MAC層和物理層進(jìn)行初始化，并且中斷使能。

在TCP/IP協(xié)議棧當(dāng)中，運(yùn)用層包含HTTP協(xié)議，運(yùn)輸層包含TCP協(xié)議和UDP協(xié)議，網(wǎng)絡(luò)層包含ARP協(xié)議、IP協(xié)議和ICMP協(xié)議。以下是嵌入式TCP/IP協(xié)議的每個(gè)模塊的實(shí)現(xiàn)流程：

1、HTTP協(xié)議模塊。HTTP協(xié)議的發(fā)送函數(shù)http_send（）即是TCP協(xié)議的發(fā)送函數(shù)和數(shù)據(jù)信息的結(jié)合，但是http_ send（）函數(shù)主要是實(shí)現(xiàn)設(shè)計(jì)網(wǎng)頁(yè)內(nèi)容，JPEG的圖片和HTML（超文本標(biāo)記語(yǔ)言）等信息的使用依靠其函數(shù)實(shí)現(xiàn)。

2、TCP協(xié)議模塊。TCP協(xié)議的發(fā)送函數(shù)tcp_send（）是需要發(fā)送一個(gè)不包含任何數(shù)據(jù)的TCP報(bào)文，其作用是能夠?qū)ψ止?jié)頭和校驗(yàn)和進(jìn)行處理。通過(guò)對(duì)時(shí)間功能的設(shè)定，TCP協(xié)議的重傳函數(shù)tcp_retransmit（）能夠?qū)崿F(xiàn)對(duì)數(shù)據(jù)最多為兩次重傳的傳輸功能，實(shí)現(xiàn)傳輸功能的應(yīng)用程序是依靠傳送頁(yè)數(shù)據(jù)而實(shí)現(xiàn)的，即是HTTP服務(wù)程序。TCP協(xié)議的?；詈瘮?shù)tcp_ inacivity（）是沒(méi)半秒運(yùn)行一次，當(dāng)連接正在建立的狀態(tài)下，?；钇跐M了的時(shí)候并且沒(méi)能被再次使用，就會(huì)中斷連接。TCP協(xié)議的接收函數(shù)tcp_rcve（）實(shí)現(xiàn)對(duì)字節(jié)頭和校驗(yàn)和的運(yùn)算，進(jìn)而對(duì)HTTP服務(wù)程序和其連接狀態(tài)等情況進(jìn)行斷定，最后進(jìn)行TCP有限的狀態(tài)機(jī)判斷數(shù)據(jù)包的程序。

3、UDP協(xié)議模塊。UDP協(xié)議的發(fā)送函數(shù)udp_send（）能夠?qū)崿F(xiàn)對(duì)字節(jié)頭和校驗(yàn)和進(jìn)行處理，其接收函數(shù)udp_rcve（）是對(duì)所接收的UDP報(bào)文進(jìn)行處理，如果沒(méi)有受到UDP報(bào)文數(shù)據(jù)，就需要發(fā)送ICMP終點(diǎn)不可到達(dá)報(bào)文。

4、ARP協(xié)議模塊。ARP協(xié)議的發(fā)送函數(shù)arp_send（），在發(fā)送請(qǐng)求報(bào)文的時(shí)候，對(duì)于不清楚目的物理地址的，則是廣播報(bào)文；在發(fā)送應(yīng)答報(bào)文的時(shí)候，接收的一方的目的物理地址需要添加物理地址。ARP協(xié)議的重傳函數(shù)arp_retransmit（）能夠?qū)崿F(xiàn)當(dāng)其發(fā)出ARP請(qǐng)求之后的半秒時(shí)間內(nèi)沒(méi)有任何響應(yīng)，則進(jìn)行再一次發(fā)送的功能，但是當(dāng)兩次發(fā)送沒(méi)有得到響應(yīng)就會(huì)對(duì)報(bào)文進(jìn)行刪除。ARP協(xié)議的緩存更新函數(shù)age_ arp_cache（）能夠每一分鐘更新一次。ARP的解析函數(shù)arp_ resolve（）能夠?qū)λl(fā)送的IP報(bào)文目的IP地址進(jìn)行解析，如果發(fā)送IP地址和目的IP地址都不在相同的一個(gè)網(wǎng)絡(luò)當(dāng)中，那么此IP地址是網(wǎng)關(guān)IP地址，然后在緩存表當(dāng)中對(duì)其進(jìn)行查找，如果找不到就需要發(fā)送ARP請(qǐng)求報(bào)文。ARP協(xié)議的接收函數(shù)arp_rcve（）能夠?qū)崿F(xiàn)對(duì)報(bào)文進(jìn)行接收或者應(yīng)答，對(duì)緩存表需要進(jìn)行更新和重新定時(shí)，如果所接受的報(bào)文是應(yīng)答報(bào)文，則需要發(fā)送等候地址解析的IP報(bào)文，但是所接收到的報(bào)文是請(qǐng)求報(bào)文 ，則需要發(fā)送ARP應(yīng)答報(bào)文。

5、IP協(xié)議模塊。IP協(xié)議的發(fā)送函數(shù)ip_send9（）能夠?qū)崿F(xiàn)對(duì)發(fā)送IP報(bào)文的20字節(jié)頭和校驗(yàn)和進(jìn)行處理，進(jìn)而使用網(wǎng)絡(luò)接口層進(jìn)行發(fā)送。IP協(xié)議接收函數(shù)ip_rcve（）能夠根據(jù)版本情況和所接收?qǐng)?bào)文的種類轉(zhuǎn)移到相應(yīng)的接收函數(shù)來(lái)處理。

6、ICMP協(xié)議模塊。ICMP協(xié)議模塊的接收函數(shù)icmp_ rcve（）是實(shí)現(xiàn)對(duì)ping請(qǐng)求的接收進(jìn)行處理，并且處理ICMP不同種類的報(bào)文。其中Ping命令請(qǐng)求信息函數(shù)ping_send（）是用來(lái)檢測(cè)發(fā)送接收兩方的接收情況。

三、結(jié)言

綜上所述，此文對(duì)TCP/IP的網(wǎng)絡(luò)結(jié)構(gòu)中的各層協(xié)議模塊進(jìn)行探究，基于網(wǎng)絡(luò)控制芯片CP2200的以太網(wǎng)接口和單片機(jī)C8051F340，并用編程語(yǔ)言來(lái)實(shí)現(xiàn)嵌入式以太網(wǎng)通信，同時(shí)進(jìn)一步通過(guò)對(duì)各個(gè)層協(xié)議的裁剪，實(shí)現(xiàn)嵌入式以太網(wǎng)的數(shù)據(jù)通信。根據(jù)現(xiàn)階段來(lái)看，嵌入式網(wǎng)絡(luò)通信基本上都是依靠TCP/IP協(xié)議來(lái)實(shí)現(xiàn)的，嵌入式設(shè)備和網(wǎng)絡(luò)兩者相結(jié)合是嵌入式系統(tǒng)今后發(fā)展的主要方向。因此，我們要更加深入地對(duì)嵌入式TCP/IP協(xié)議進(jìn)行探究以及更深層次的功能實(shí)現(xiàn)。

參 考 文 獻(xiàn)

篇4

1網(wǎng)絡(luò)隱蔽通道的基本原理

早期對(duì)隱蔽通道的定義只局限于操作系統(tǒng)內(nèi)部，研究的重點(diǎn)也是針對(duì)操作系統(tǒng)的安全。隨著網(wǎng)絡(luò)技術(shù)的快速發(fā)展，隱蔽通道已經(jīng)被應(yīng)用到網(wǎng)絡(luò)技術(shù)中。由于網(wǎng)絡(luò)協(xié)議在設(shè)計(jì)時(shí)存在漏洞，如網(wǎng)絡(luò)協(xié)議的首部存在冗余字段，而網(wǎng)絡(luò)設(shè)備對(duì)這些字段的限制比較寬松，由此可以通過(guò)精心的構(gòu)造，利用這些字段實(shí)現(xiàn)隱蔽通信，就形成了網(wǎng)絡(luò)隱蔽通道［5］。因此，廣義地講，網(wǎng)絡(luò)隱蔽通道是指各種利用非正常的通信手段在網(wǎng)絡(luò)中傳遞信息的通道。圖1為隱蔽通道模型。

2建立網(wǎng)絡(luò)隱蔽通道的方法

建立隱蔽通道的方法一般就是利用網(wǎng)絡(luò)傳輸協(xié)議設(shè)計(jì)中存在的一些不嚴(yán)密的地方來(lái)隱藏信息，以躲過(guò)網(wǎng)絡(luò)安全防護(hù)系統(tǒng)和防火墻系統(tǒng)，達(dá)到傳輸非法信息的目的［6］。由于防火墻或入侵檢測(cè)系統(tǒng)往往只注重對(duì)數(shù)據(jù)部分的檢測(cè)，而忽略了對(duì)首部息的檢測(cè)，因此就可以從以下途徑來(lái)建立隱蔽通道：一是利用TCP／IP協(xié)議的首部中的一些很少使用或不使用的域來(lái)隱藏信息；二是可以利用數(shù)據(jù)傳輸時(shí)數(shù)據(jù)包頭中的一些必須強(qiáng)制填充的域（如IP數(shù)據(jù)包頭中的源地址、目的地址和TCP數(shù)據(jù)包頭中的源端口域、目的端口域、序列號(hào)域等）來(lái)隱藏信息；此外，還可以利用第三方合法主機(jī)中轉(zhuǎn)建立隱蔽通道，利用Ping命令隱藏信息建立隱蔽通道等方法。

3基于TCP協(xié)議首部的隱蔽通道

3．1TCP協(xié)議首部隱蔽通道設(shè)計(jì)思想基于TCP協(xié)議模型網(wǎng)絡(luò)隱蔽通道的設(shè)計(jì)思想主要是利用該模型中的協(xié)議來(lái)進(jìn)行的，而雙方的通信方式則是“合法的”，通信前雙方約定好用以隱藏或解析隱蔽信息的規(guī)則，然后發(fā)送端依據(jù)該規(guī)則對(duì)要發(fā)送的隱蔽信息進(jìn)行編碼、偽裝、發(fā)送，接收端收到經(jīng)過(guò)編碼的信息后，便會(huì)依據(jù)發(fā)送端產(chǎn)生的規(guī)則來(lái)解析隱蔽信息。TCP協(xié)議首部就是用于隱蔽信息的首選目標(biāo)。圖2為TCP協(xié)議首部的結(jié)構(gòu)，主要包括源端口和目標(biāo)端口字段、確認(rèn)序列號(hào)、首部長(zhǎng)度、標(biāo)志位、窗口、檢驗(yàn)和及緊急指針等字段。在TCP協(xié)議首部的這些字段中，很多字段在通常情況下根本不用或很少使用，可以用來(lái)隱藏信息。本文選擇序列號(hào)字段和確認(rèn)序列號(hào)字段作為隱蔽通道的載體，主要有兩方面的原因：一是它們的長(zhǎng)度達(dá)到32bit，可以隱藏更多信息，同時(shí)數(shù)據(jù)位很多，往往難以檢測(cè)；二是它們的值在數(shù)據(jù)傳輸過(guò)程中的變化具有規(guī)律性，接收端還原數(shù)據(jù)比較容易。假設(shè)要在網(wǎng)絡(luò)中的客戶端A和服務(wù)端B之間構(gòu)建隱蔽通道，還需要借助第三方受信的Web服務(wù)器C。利用TCP序列號(hào)來(lái)實(shí)現(xiàn)數(shù)據(jù)隱蔽傳輸?shù)姆椒ㄊ牵菏紫瓤蛻舳薃構(gòu)造自己的SYN數(shù)據(jù)包，向受信的Web服務(wù)器C發(fā)出建立連接的請(qǐng)求，而服務(wù)端B也捕獲到該SYN包，就偽造Web服務(wù)器C向客戶端A發(fā)送返回的SYN＋ACK數(shù)據(jù)包，并在TCP序列號(hào)字段中攜帶加密的隱秘信息；客戶端A從服務(wù)端B偽造的Web服務(wù)器返回?cái)?shù)據(jù)包中捕獲隱秘信息或指令解析并執(zhí)行，從而實(shí)現(xiàn)了將信息從客戶端A到服務(wù)端B之間的隱蔽傳輸。由于在整個(gè)數(shù)據(jù)通信過(guò)程中并沒(méi)有形成任何一個(gè)完整的TCP三次握手，并且返回的SYN＋ACK包可看作對(duì)每個(gè)SYN包的響應(yīng)，因此可以達(dá)到規(guī)避防火墻，實(shí)現(xiàn)隱藏信息的目的。

3．2隱蔽通道的構(gòu)建利用TCP協(xié)議首部構(gòu)建隱蔽傳輸通道，主要就是要在發(fā)送端生成包數(shù)據(jù)包時(shí)將隱秘信息嵌入，然后在接收端捕獲含有隱秘信息的數(shù)據(jù)，并將其解碼出來(lái)。由于在數(shù)據(jù)傳輸過(guò)程中使用了第三方受信的Web服務(wù)器，隱秘信息是隱藏在向Web服務(wù)器發(fā)送請(qǐng)求的數(shù)據(jù)包中，又通過(guò)接收方偽造Web服務(wù)器向發(fā)送方返回應(yīng)答數(shù)據(jù)包，同時(shí)也將隱秘信息隱藏在返回的應(yīng)答數(shù)據(jù)包中。在隱秘信息傳輸過(guò)程中沒(méi)有形成完整的三次握手，因此不會(huì)給正常通信造成影響，也不會(huì)引起防火墻的反應(yīng)。而將隱秘信息嵌入TCP數(shù)據(jù)包首部的序列號(hào)字段和確認(rèn)序列號(hào)字段，這兩個(gè)字段長(zhǎng)度均為32bit，因而可以隱藏更多信息，同時(shí)數(shù)據(jù)位多，更加難以檢測(cè)。

3．2．1數(shù)據(jù)包的生成和發(fā)送生成網(wǎng)絡(luò)數(shù)據(jù)包的方法有基于原始套接字的方法、基于WinPcap的方法和基于Libnet的方法等［7］。本文采用基于WinPcap的方法，具體包括兩個(gè)部分：（1）在客戶端生成獲取網(wǎng)關(guān)MAC地址的ARP請(qǐng)求數(shù)據(jù)包，目的是為了獲取本機(jī)、服務(wù)端以及網(wǎng)關(guān)的MAC地址。由于局域網(wǎng)中ARP數(shù)據(jù)包大量存在，且機(jī)器中的動(dòng)態(tài)ARP表需要不斷更新，正常的ARP數(shù)據(jù)包不會(huì)引起防火墻等設(shè)備的懷疑，因此只需要生成正常的ARP請(qǐng)求數(shù)據(jù)包即可。使用Winsock庫(kù)提供的SendARP（）函數(shù)能十分方便地生成ARP請(qǐng)求數(shù)據(jù)包，獲取與IP地址對(duì)應(yīng)的物理地址。（2）生成手工制作的TCP數(shù)據(jù)包，各字段符合TCP協(xié)議的定義，發(fā)起對(duì)受信的Web服務(wù)器的建立連接請(qǐng)求，在服務(wù)端則偽造Web服務(wù)器，返回嵌入了隱秘信息的SYN＋ACK數(shù)據(jù)包到客戶端。

3．2．2數(shù)據(jù)包的捕獲客戶端捕獲數(shù)據(jù)包后，需要對(duì)其進(jìn)行分解，對(duì)每層協(xié)議進(jìn)行解析，然后讀取所傳送的數(shù)據(jù)內(nèi)容，最后再對(duì)數(shù)據(jù)進(jìn)行解碼和處理。捕獲數(shù)據(jù)包的方法也有多種，對(duì)應(yīng)發(fā)送端，也采用了基于WinPcap的方法。其步驟為：首先使用pcap＿findalldevs（）獲得主機(jī)的網(wǎng)絡(luò)設(shè)備列表，然后使用pcap＿open＿live（）打開(kāi)網(wǎng)絡(luò)設(shè)備，使用函數(shù)pcap＿compile（）編譯過(guò)濾規(guī)則和使用函數(shù)pcap＿setfilter（）設(shè)置過(guò)濾規(guī)則。之后使用pcap＿loop（）和pcap＿next＿ex（）捕獲數(shù)據(jù)包。捕獲到數(shù)據(jù)包后就可以對(duì)其進(jìn)行分解和解析，將TCP首部中含有隱秘信息的序列號(hào)或確認(rèn)序列號(hào)的內(nèi)容取出，經(jīng)解密后就得到隱秘信息。

4基于TCP首部的隱蔽通道系統(tǒng)的實(shí)現(xiàn)

實(shí)現(xiàn)基于TCP首部的隱蔽通道就是采用第3節(jié)中所述的思想和方法，在發(fā)送端偽造TCP協(xié)議發(fā)送包含有隱秘信息數(shù)據(jù)包，在接收端對(duì)接收的數(shù)據(jù)包中的隱蔽信息進(jìn)行相應(yīng)處理。

4．1系統(tǒng)的總體構(gòu)架系統(tǒng)的功能原理如圖3所示。通過(guò)數(shù)據(jù)包生成技術(shù)，客戶端將隱藏信息加密后嵌入TCP協(xié)議首部的序列號(hào)字段或確認(rèn)號(hào)字段，對(duì)可信的第三方Web服務(wù)器發(fā)起連接請(qǐng)求。服務(wù)端則偽造Web服務(wù)器向客戶端返回SYN＋ACK數(shù)據(jù)包。通過(guò)數(shù)據(jù)包捕獲技術(shù)，服務(wù)端從客戶端發(fā)往Web服務(wù)器的請(qǐng)求數(shù)據(jù)包中捕獲隱秘信息并還原?？蛻舳藙t從服務(wù)端偽造Web服務(wù)器的返回?cái)?shù)據(jù)包中捕獲隱秘信息或指令解析并執(zhí)行。

4．2系統(tǒng)功能及實(shí)現(xiàn)

系統(tǒng)功能模塊系統(tǒng)可分為數(shù)據(jù)包生成模塊、數(shù)據(jù)包捕獲模塊、管理與控制模塊和指令解析模塊，如圖4所示。其中，數(shù)據(jù)包的生成和捕獲模塊利用多線程技術(shù)實(shí)現(xiàn)，執(zhí)行時(shí)不會(huì)造成MFC界面假死。管理與控制模塊負(fù)責(zé)處理網(wǎng)絡(luò)設(shè)備的獲取與控制。指令解析模塊對(duì)傳遞的信息進(jìn)行顯示和執(zhí)行指令。秘密信息經(jīng)加密后嵌入數(shù)據(jù)包發(fā)往公開(kāi)信道，接收端在公開(kāi)信道捕獲數(shù)據(jù)包并對(duì)其進(jìn)行解密。

5實(shí)驗(yàn)結(jié)果及分析

經(jīng)過(guò)實(shí)驗(yàn)，通信功能方面，雙方互發(fā)的消息都能正確接收?？刂乒δ芊矫妫軌蛲ㄟ^(guò)在客戶端發(fā)送命令來(lái)實(shí)現(xiàn)對(duì)服務(wù)端的控制。經(jīng)測(cè)試，該系統(tǒng)在WindowsXPSP2和Windows7操作系統(tǒng)中運(yùn)行良好。實(shí)驗(yàn)結(jié)果見(jiàn)表1和表2。實(shí)驗(yàn)結(jié)果表明，該系統(tǒng)不僅可以實(shí)現(xiàn)信息傳輸和遠(yuǎn)程控制的功能，而且能夠成功躲避各種安全防護(hù)系統(tǒng)的防范。

6結(jié)束語(yǔ)

篇5

關(guān)鍵詞：嵌入式系統(tǒng)；TCP/IP協(xié)議；應(yīng)用研究

1. 前言

隨著互聯(lián)網(wǎng)商品化的不斷發(fā)展，互聯(lián)網(wǎng)信息共享表現(xiàn)出越來(lái)越大誘惑力。在不用PC機(jī)基礎(chǔ)上，通過(guò)ISP采取8位的微控制器接到互聯(lián)網(wǎng)上并取代傳統(tǒng)以PC機(jī)為核心應(yīng)用模式，已成為現(xiàn)在乃至未來(lái)互聯(lián)網(wǎng)發(fā)展主要趨勢(shì)。為把單片機(jī)體系有效接到互聯(lián)網(wǎng)上務(wù)必要做好兩手準(zhǔn)備，在硬件上要根據(jù)系統(tǒng)的主控器加上網(wǎng)絡(luò)接口，在軟件商要為之提供相對(duì)應(yīng)通信協(xié)議。因單片機(jī)具有較小存儲(chǔ)單元且數(shù)據(jù)處理較慢，因此采用PC機(jī)TCP/IP協(xié)議已無(wú)法嵌到單片機(jī)里，所以簡(jiǎn)化TCP/IP協(xié)議，實(shí)現(xiàn)單片機(jī)和互聯(lián)網(wǎng)間電子郵件的運(yùn)輸對(duì)達(dá)到單片機(jī)和互聯(lián)網(wǎng)間信息傳輸目的具有重要推動(dòng)作用，下面主要研究嵌入式系統(tǒng)的TCP/IP協(xié)議的應(yīng)用研究。

2. 嵌入式系統(tǒng)TCP/IP協(xié)議在硬件中的應(yīng)用

2.1 單片機(jī)嵌入互聯(lián)網(wǎng)模式選擇

2.1.1 EmWarea其EMIT技術(shù)

這種技術(shù)采取的是標(biāo)準(zhǔn)互聯(lián)網(wǎng)協(xié)議并對(duì)16位和8位嵌入式的設(shè)備管理，該類嵌入模式是使用TCP/IP協(xié)議棧和網(wǎng)關(guān)在Internet里橋接。選取EMIT技術(shù)雖可使用在各類型單片機(jī)上，但卻要求系統(tǒng)工程師熟悉相關(guān)接口和掌握emNeT協(xié)議，有著較大工作量。

2.1.2 PC網(wǎng)卡加上專用網(wǎng)

該類單片機(jī)嵌入互聯(lián)網(wǎng)模式是采用CANBus、RS485、RS232等專用網(wǎng)絡(luò)將小批量單片機(jī)均連接起來(lái)后，再把專業(yè)網(wǎng)絡(luò)均連接在同一臺(tái)的PC機(jī)上面，因其依靠PC機(jī)為協(xié)議實(shí)現(xiàn)機(jī)制轉(zhuǎn)換，所以當(dāng)多個(gè)單片機(jī)體系較為分散時(shí)，該類專用網(wǎng)絡(luò)的布置就顯得很不方便，在PC機(jī)里裝上專門協(xié)議軟件來(lái)轉(zhuǎn)換機(jī)制，又將發(fā)開(kāi)成本增加了。

2.1.3 MCU加上網(wǎng)卡芯片

這類單片機(jī)嵌入互聯(lián)網(wǎng)模式是用單片機(jī)對(duì)TCP/IP協(xié)議進(jìn)行加載并據(jù)此對(duì)以太網(wǎng)網(wǎng)卡進(jìn)行控制實(shí)現(xiàn)數(shù)據(jù)的傳輸，是采用TCP/IP協(xié)議嵌入互聯(lián)網(wǎng)。該飯飯么有使用網(wǎng)關(guān)或PC機(jī)平臺(tái)，因此，開(kāi)發(fā)成本降低，只需相關(guān)人員深層次了解單片機(jī)、網(wǎng)卡的驅(qū)動(dòng)程序和TCP/IP協(xié)議。

分析完以上三種單片機(jī)嵌入互聯(lián)網(wǎng)方案，可知MCU加上網(wǎng)卡芯片為最佳方案，最為經(jīng)濟(jì)模式。

2.2 系統(tǒng)的硬件結(jié)構(gòu)

系統(tǒng)單片機(jī)應(yīng)該采取89C51，而網(wǎng)卡芯片應(yīng)該采取RTL8019AS。此外，讀取鍵盤其輸入數(shù)據(jù)與指令應(yīng)該串行E2PROM采取24C256.89C51在處理操作時(shí)，要通過(guò)網(wǎng)絡(luò)接口的電路和網(wǎng)卡芯片來(lái)實(shí)現(xiàn)單片機(jī)和互聯(lián)網(wǎng)接入任務(wù)，從而進(jìn)一步達(dá)成電子郵件接收發(fā)送功能。

3. 嵌入式系統(tǒng)TCP/IP協(xié)議在軟件中的應(yīng)用

3.1 TCP/IP協(xié)議特點(diǎn)

高級(jí)系統(tǒng)里雖可支持完整TCP/IP協(xié)議，但針對(duì)單片機(jī)系統(tǒng)卻很難將其做到。根據(jù)以上特點(diǎn)，第一，要按照各類系統(tǒng)特點(diǎn)及功能對(duì)TCP/IP協(xié)議進(jìn)行特定設(shè)計(jì)，僅僅需要達(dá)到相關(guān)協(xié)議需求；第二，針對(duì)具體實(shí)際運(yùn)用，為避免單片機(jī)其內(nèi)部資源出現(xiàn)不足，在保證所需協(xié)議實(shí)現(xiàn)基礎(chǔ)功能前提下做好精簡(jiǎn)工作。單片機(jī)中程序結(jié)構(gòu)通常為硬件中斷和順序執(zhí)行相結(jié)合模式，因此，對(duì)于處理TCP/IP協(xié)議工作應(yīng)該將其在主程序順序循環(huán)里，使用查詢式來(lái)控制網(wǎng)卡芯片，其它中斷任務(wù)實(shí)行間隙中間隙TCP/IP協(xié)議處理，使用時(shí)間成本換取系統(tǒng)可靠性。

單片機(jī)讀取數(shù)據(jù)是靠RTL8019AS在網(wǎng)絡(luò)上面接受，并從網(wǎng)絡(luò)接口的控制程序處將其讀到緩沖區(qū)即E2PROM里來(lái)檢測(cè)協(xié)議字段類型，從而去夜店那種協(xié)議可用來(lái)處理該分組。當(dāng)格式出現(xiàn)錯(cuò)誤時(shí)就將該分組丟棄。

3.2 TCP/IP協(xié)議的實(shí)現(xiàn)

實(shí)現(xiàn)軟件采取51系列的單片機(jī)C語(yǔ)言開(kāi)發(fā)的平臺(tái)偉福6000，同時(shí)用COMP51編譯器，下面具體就協(xié)議實(shí)現(xiàn)進(jìn)行分析：

3.2.1 APR協(xié)議

APR協(xié)議其首要目的是完成IP地址和以太網(wǎng)地址間映射。在APR包里操作碼相應(yīng)字段突出APR應(yīng)答、APR請(qǐng)求、RARP應(yīng)答、RARP請(qǐng)求四種操作形式。該單片機(jī)體系僅僅對(duì)APR請(qǐng)求與APR應(yīng)答響應(yīng)，為有效提升網(wǎng)絡(luò)傳輸效率與速度，防止每次數(shù)據(jù)傳輸前都要對(duì)APR地址給予解析才可活動(dòng)響應(yīng)目的地址，可構(gòu)建一個(gè)儲(chǔ)存常用目的地地址APR的高速緩存。其實(shí)現(xiàn)需要兩個(gè)進(jìn)程：（1）進(jìn)程處理，處理APR響應(yīng)與APR請(qǐng)求，與此同時(shí)也將APR的高速緩存更新；（2）進(jìn)程尋址，在APR的高速緩存里為相應(yīng)IP地址尋址與之對(duì)應(yīng)以太網(wǎng)的地址。

3.2.2 IP協(xié)議

為實(shí)現(xiàn)單片機(jī)里對(duì)IP協(xié)議進(jìn)行加載，同時(shí)又不對(duì)多個(gè)IP地址支持，主要通過(guò)以上進(jìn)程來(lái)完成：（1）進(jìn)程發(fā)送，首先把待發(fā)數(shù)據(jù)密閉封裝到IP包里，然后再查看本機(jī)和目的主機(jī)在同一子網(wǎng)里與否，當(dāng)處在同一子網(wǎng)里就將IP數(shù)據(jù)直接發(fā)送給目的主機(jī)，若不在同一子網(wǎng)就將數(shù)據(jù)包經(jīng)默認(rèn)路發(fā)送到路由器里；（2）進(jìn)程接收，在得到了IP包過(guò)后，要對(duì)TP目的地址、頭部版本等進(jìn)行校驗(yàn)，正確以后，再將協(xié)議字段類型給予解析，并交由高層協(xié)議去處理。

3.2.3 ICMP協(xié)議

IP協(xié)議因無(wú)法提供鏈接服務(wù)，所以錯(cuò)誤信息和報(bào)文無(wú)法傳送給最初主體，針對(duì)此情況，對(duì)系統(tǒng)里接收ICMP包校驗(yàn)且無(wú)誤后，且CODE域和TYPE來(lái)替代echo請(qǐng)求后，還需發(fā)送echo來(lái)應(yīng)答，從而實(shí)現(xiàn)網(wǎng)絡(luò)其診斷功能。

3.2.4 TCP協(xié)議

TCP協(xié)議面向端對(duì)端、連接可靠的通信協(xié)議，該部分主要通過(guò)以下進(jìn)程達(dá)成：（1）構(gòu)建連接。首先在客戶機(jī)發(fā)送對(duì)端接入要求時(shí)，要可隨時(shí)選送初始的序號(hào)；其次，服務(wù)器同樣要選送屬于自身初始的序號(hào)，客戶機(jī)傳送來(lái)的序號(hào)對(duì)答號(hào)要及時(shí)返送到客戶機(jī)上；最后，客戶機(jī)要再次發(fā)送應(yīng)答段給服務(wù)器來(lái)當(dāng)作服務(wù)器發(fā)送請(qǐng)求接入響應(yīng)，包括數(shù)據(jù)每個(gè)TCP段均要取得相應(yīng)對(duì)端返回應(yīng)答段來(lái)當(dāng)作握手信號(hào)以確保數(shù)據(jù)的可靠接收。作為應(yīng)答段其自身則不需應(yīng)答來(lái)預(yù)防應(yīng)答陷入永無(wú)止境嵌套；（2）進(jìn)程驗(yàn)證，該進(jìn)程要使用相應(yīng)措施對(duì)傳輸中錯(cuò)誤給予消除來(lái)確保數(shù)據(jù)傳輸可靠性，例如：可用持續(xù)跟蹤法對(duì)已發(fā)出的數(shù)據(jù)段進(jìn)行跟蹤來(lái)判斷其返回與否以及數(shù)據(jù)丟失與否；也可用序列號(hào)對(duì)通信時(shí)失序、重復(fù)問(wèn)題給予解決；對(duì)于數(shù)據(jù)誤碼的問(wèn)題可用校驗(yàn)來(lái)解決等；（3）進(jìn)程流量控制，首先設(shè)計(jì)滑動(dòng)窗口用循環(huán)緩沖區(qū)域來(lái)做，對(duì)于窗口與ACK的配合要指明處于正確接收最后數(shù)據(jù)包后，同時(shí)要處在可接受序列號(hào)的范圍內(nèi)，并以此來(lái)控制流量；（4）連接關(guān)閉，首先客戶 機(jī)對(duì)服務(wù)器發(fā)送關(guān)閉段，該時(shí)刻客戶機(jī)只可對(duì)數(shù)據(jù)進(jìn)行接收，不可再次發(fā)送數(shù)據(jù)；其次，服務(wù)器對(duì)客戶機(jī)發(fā)送關(guān)閉即應(yīng)答段，該時(shí)段，服務(wù)器仍舊可為客戶機(jī)傳輸數(shù)據(jù)，也就是接入處在半關(guān)閉的狀態(tài)；再次，服務(wù)器對(duì)客戶機(jī)發(fā)送關(guān)閉段，此時(shí)可服務(wù)器不可再次發(fā)送出去數(shù)據(jù)；最后，客戶機(jī)務(wù)必要對(duì)服務(wù)器關(guān)閉做出響應(yīng)，對(duì)服務(wù)器發(fā)送關(guān)閉即應(yīng)答段。

3.2.5 SMIP協(xié)議

SMIP協(xié)議只需依賴一個(gè)可靠規(guī)則數(shù)據(jù)的流通道，而不需依賴特定傳輸子系統(tǒng)。SMIP主要為面向基于命令、文字的協(xié)議，設(shè)計(jì)系統(tǒng)時(shí)該部分協(xié)議主要靠?jī)蛇M(jìn)程構(gòu)成：（1）處理底層郵件，提取信頭其各字段的信息，并按照數(shù)據(jù)編碼性質(zhì)來(lái)處理數(shù)據(jù)，讓其以用戶能夠接受刑事傳輸為圖形用戶的界面；（2）發(fā)送郵件，通過(guò)DATA、TO、RCPT、MAILFROM、HELO一系列接受方會(huì)話和指令，由25號(hào)能夠采取電子郵件的傳輸TCP其保留端口來(lái)進(jìn)行郵件的傳輸工作。

綜上所述，嵌入式系統(tǒng)TCP/IP協(xié)議在硬件和軟件上的應(yīng)用可有效實(shí)現(xiàn)在單片機(jī)里采取電子郵件傳輸任務(wù)，探究嵌入式系統(tǒng)TCP/IP協(xié)議的應(yīng)用不僅能夠提高單片機(jī)和互聯(lián)網(wǎng)間信息共享度，還可減少硬件的使用、降低成本和為使用帶來(lái)便利。此外，采取51系列的單片機(jī)，雖然利于軟件移植及二次開(kāi)發(fā)，但卻有著較慢數(shù)據(jù)傳輸速度，還需我們進(jìn)一步探究。

參考文獻(xiàn)：

.自動(dòng)化與儀器儀表,2011(05).

作者簡(jiǎn)介：

篇6

【關(guān)鍵詞】網(wǎng)絡(luò)設(shè)備；TCP/IP協(xié)議；TELNET協(xié)議；工作腳本

一、背景

隨著各電信運(yùn)營(yíng)商全業(yè)務(wù)市場(chǎng)運(yùn)營(yíng)的開(kāi)展，電信企業(yè)內(nèi)部的競(jìng)爭(zhēng)日趨激烈，在電信企業(yè)如火如荼的競(jìng)爭(zhēng)過(guò)程中，企業(yè)內(nèi)部的人力、成本等資源都集中到了市場(chǎng)營(yíng)銷、客戶服務(wù)與維系等窗口中，作為后臺(tái)網(wǎng)絡(luò)、設(shè)備維護(hù)人員，如何使用有限的人力資源和維護(hù)成本，來(lái)保障設(shè)備更穩(wěn)定、更高效的運(yùn)行成了各電信企業(yè)運(yùn)維管理、系統(tǒng)支撐部門必須考慮的問(wèn)題。

二、問(wèn)題分析

電信企業(yè)內(nèi)部接入網(wǎng)絡(luò)的設(shè)備主要由應(yīng)用服務(wù)器、生產(chǎn)終端設(shè)備和內(nèi)部局域網(wǎng)的組建、管理、支撐設(shè)備組成。在日常的維護(hù)過(guò)程中，我們發(fā)現(xiàn)這些設(shè)備存在以下特性：

1）設(shè)備的多樣性。上述設(shè)備中有網(wǎng)絡(luò)交換機(jī)、路由器、小型機(jī)、工控機(jī)等，涉及操作系統(tǒng)有HP UNIX、SCO UNIX、LINUX、SUN SOLARIS等多種。

2）設(shè)備數(shù)量較多。隨著電信企業(yè)內(nèi)部的信息化水平不斷提高，各類設(shè)備數(shù)量也不斷增加，僅以路由器、交換機(jī)為例，德州的數(shù)量就數(shù)以百計(jì)。

3）地理位置的分散性。由于上述設(shè)備主要為各級(jí)分公司的系統(tǒng)提供服務(wù)，由于各級(jí)分公司、營(yíng)業(yè)部位置的相對(duì)分散，就決定了此類設(shè)備在地理位置上的分散性。

設(shè)備多樣、數(shù)量龐大、位置分散的特性就造成了此類設(shè)備管理的復(fù)雜性，那么，如何對(duì)上述設(shè)備進(jìn)行有效的維護(hù)和管理呢？本文結(jié)合德州的實(shí)踐經(jīng)驗(yàn)，基于TCP/IP協(xié)議族，提出了電信企業(yè)內(nèi)部設(shè)備智能化管理系統(tǒng)設(shè)計(jì)方法。

三、技術(shù)介紹

傳輸控制協(xié)議（TCP）、Telnet協(xié)議都是TCP/IP協(xié)議族中的一員。這兩種協(xié)議為用戶提供了在本地計(jì)算機(jī)上完成連接、控制遠(yuǎn)程服務(wù)器的能力。在終端使用者的電腦上使用TCP或telnet協(xié)議，連接到遠(yuǎn)程服務(wù)器，并可以通過(guò)程序，在本地終端上輸入命令，送到服務(wù)器上運(yùn)行，就像直接在服務(wù)器的控制臺(tái)上輸入一樣。

TCP協(xié)議、TELNET協(xié)議是各類設(shè)備或其操作系統(tǒng)上普遍支持的兩種網(wǎng)絡(luò)協(xié)議，基于上述兩種協(xié)議，通過(guò)編程可以實(shí)現(xiàn)對(duì)各種網(wǎng)絡(luò)設(shè)備自動(dòng)控制、數(shù)據(jù)采集，來(lái)為我們的維護(hù)工作提供便利。

四、系統(tǒng)結(jié)構(gòu)

應(yīng)用服務(wù)器通過(guò)C語(yǔ)言編寫程序通過(guò)TCP協(xié)議、TELNET協(xié)議與各網(wǎng)絡(luò)設(shè)備建立連接通道，通過(guò)兩種方式與設(shè)備之間進(jìn)行交互。一種方式是定時(shí)解析通過(guò)既定的數(shù)據(jù)采集腳本向各網(wǎng)絡(luò)設(shè)備發(fā)送數(shù)據(jù)采集命令，由結(jié)果分析程序?qū)⒚罘祷氐慕Y(jié)果進(jìn)行分析，寫入數(shù)據(jù)庫(kù)。第二種方式，終端用戶通過(guò)主動(dòng)向應(yīng)用服務(wù)器發(fā)起查詢、操作命令請(qǐng)求，由應(yīng)用服務(wù)器將操作命令對(duì)一臺(tái)或多臺(tái)設(shè)備進(jìn)行命令處理，并將處理結(jié)果返回。

在整個(gè)處理過(guò)程中，應(yīng)用服務(wù)器扮演了兩種角色，一方面與各網(wǎng)絡(luò)設(shè)備建立雙向命令處理通道，一方面通過(guò)網(wǎng)頁(yè)來(lái)接受終端用戶的查詢、操作命令請(qǐng)求。

五、系統(tǒng)實(shí)現(xiàn)關(guān)鍵技術(shù)難點(diǎn)分析

在智能化網(wǎng)絡(luò)設(shè)備管理系統(tǒng)的實(shí)現(xiàn)過(guò)程中，我針對(duì)系統(tǒng)實(shí)現(xiàn)過(guò)程的兩個(gè)重點(diǎn)、難點(diǎn)問(wèn)題，來(lái)介紹系統(tǒng)的設(shè)計(jì)方案。

1、TCP、TELNET協(xié)議接口設(shè)計(jì)

在使用TCP、TELNET協(xié)議與各網(wǎng)絡(luò)設(shè)備連接過(guò)程中，在兩個(gè)過(guò)程中下可能會(huì)出較長(zhǎng)的時(shí)間延遲。

（1）在使用SOCKET、CONNECT函數(shù)與網(wǎng)絡(luò)設(shè)備建立連接的過(guò)程中，如果遠(yuǎn)程設(shè)備掉電，或出現(xiàn)局部的網(wǎng)絡(luò)中斷，這部分設(shè)備在整個(gè)局域網(wǎng)中將變?yōu)椴豢梢?jiàn)狀態(tài)。而無(wú)論是TCP協(xié)議還是TELNENT協(xié)議，在面向連接的協(xié)議，如果CONNET函數(shù)在建立連接的過(guò)程中阻塞，會(huì)進(jìn)行多次重試，直到重試次數(shù)超過(guò)操作系統(tǒng)設(shè)置最大超時(shí)次數(shù)位置，這個(gè)過(guò)程一般會(huì)持續(xù)3分鐘左右的時(shí)間。（2）在CONNECT連接建立后，與SOCKET套接字進(jìn)行命令發(fā)送的過(guò)程中，如果服務(wù)器對(duì)命令返回的結(jié)果未正確識(shí)別出有效的命令結(jié)束符號(hào)，或由于網(wǎng)絡(luò)設(shè)備自身硬件故障的原因造成命令處理過(guò)程放緩、或不執(zhí)行，從而無(wú)法獲得正確的返回結(jié)果，造成長(zhǎng)時(shí)間存在一個(gè)無(wú)效連接，這實(shí)際也是一種阻塞狀態(tài)。

上述兩種狀態(tài)如果在程序編寫的過(guò)程中，如果不增加超時(shí)處理，將大大放緩命令的執(zhí)行效率，造成終端用戶對(duì)系統(tǒng)的認(rèn)同度下降。因此，在上述兩種過(guò)程中，我們首先需要兩種基本數(shù)據(jù)局域網(wǎng)內(nèi)部的正常時(shí)間延遲、網(wǎng)絡(luò)設(shè)備的回顯延時(shí)。

（1）局域網(wǎng)內(nèi)部的正常通信延時(shí)的計(jì)算過(guò)程中，可要選取各IP網(wǎng)段的最大網(wǎng)絡(luò)延時(shí)作為參考。（2）網(wǎng)絡(luò)設(shè)備的回顯延時(shí)，由于網(wǎng)絡(luò)設(shè)備的生產(chǎn)廠家、設(shè)備型號(hào)、硬件配置、軟件配置、發(fā)送命令的不同，回顯時(shí)間延時(shí)也會(huì)不同，這種情況下，對(duì)于同廠家、同型號(hào)設(shè)備，選取一個(gè)日常維護(hù)操作處理時(shí)間最長(zhǎng)的操作時(shí)間作為參考。

通過(guò)上述兩種時(shí)間的界定，使用SELECT函數(shù)來(lái)設(shè)置超時(shí)時(shí)間，在超時(shí)時(shí)間到達(dá)前如果沒(méi)有收到正確的命令返回結(jié)果描述符，則產(chǎn)生一個(gè)中斷信號(hào)，來(lái)打破阻塞狀態(tài)。

2、各網(wǎng)絡(luò)設(shè)備采集命令管理問(wèn)題

由于網(wǎng)絡(luò)設(shè)備類型眾多、變更較為頻繁，如果將所有的操作、數(shù)據(jù)采集命令都固化到程序中，雖然會(huì)對(duì)程序代碼的執(zhí)行效率有一定的提升作用，但是同時(shí)會(huì)面臨程序拓展性差、維護(hù)困難的問(wèn)題。會(huì)讓我們工作陷入不斷進(jìn)行代碼更新，同時(shí)由于設(shè)備更替，代碼中又會(huì)產(chǎn)生部分冗余代碼僵局。為解決此問(wèn)題，首先，我們編寫了一個(gè)工作腳本分析進(jìn)程，固化部分關(guān)鍵字，如TELNET_IP（使用TELNET協(xié)議連接IP地址）、 AUTO_TCP_IP（使用TCP協(xié)議連接IP地址）、FIND（搜索返回結(jié)果串）、ENTER（輸入命令）、TO（將結(jié)果輸出到文件）等。然后，根據(jù)上述關(guān)鍵字規(guī)范，結(jié)合日常使用較為頻繁的操作命令。下面我通過(guò)SCO UNIX工控機(jī)和CISCO路由器的兩個(gè)工作腳本，來(lái)給大家介紹下此系統(tǒng)德州聯(lián)通內(nèi)部的實(shí)際應(yīng)用。

六、技術(shù)總結(jié)

在電信企業(yè)網(wǎng)絡(luò)設(shè)備智能化管理實(shí)現(xiàn)過(guò)程中，通過(guò)TCP/IP協(xié)議族協(xié)議的靈活使用，成功地解決了對(duì)多種數(shù)量龐大、位置離散的網(wǎng)絡(luò)設(shè)備的管理難題，實(shí)現(xiàn)各網(wǎng)絡(luò)設(shè)備數(shù)據(jù)的采集、入庫(kù)、顯示，以及管理人員與網(wǎng)絡(luò)設(shè)備的雙向交互。通過(guò)在德州聯(lián)通內(nèi)部的建設(shè)和使用，實(shí)踐表明此系統(tǒng)可以在網(wǎng)絡(luò)設(shè)備維護(hù)、監(jiān)控、操作方面，有效地縮短人工處理時(shí)間，此系統(tǒng)的實(shí)現(xiàn)方案對(duì)于各電信企業(yè)具有較強(qiáng)的借鑒意義。

參考文獻(xiàn)

[1]尚穆蓋姆.TCP/IP詳解（第2版）.電子工業(yè)出版社，2003

篇7

關(guān)鍵詞：檔案庫(kù)系統(tǒng)；Modbus/TCP；自動(dòng)識(shí)別；COM

中圖分類號(hào)：TP31

隨著信息化建設(shè)的不斷深入，各單位已經(jīng)全面的使用電子檔案系統(tǒng)，電子檔案具有傳遞便捷、資源共享、查閱方便等多種好處，不過(guò)由于紙質(zhì)檔案的形成必須要經(jīng)過(guò)人工操作，對(duì)原文件的任何篡改都會(huì)留下痕跡，所以紙質(zhì)檔案在法律上的可信度很高，能夠起到原始憑證的作用。因此在實(shí)際工作中電子檔案并不能完全替代紙質(zhì)檔案，很多情況下還是需要用到紙質(zhì)檔案。如何將電子檔案利用與紙質(zhì)檔案管理結(jié)合起來(lái)，大幅度降低檔案維護(hù)成本，提搞檔案管理效率，成為目前迫切需要解決的問(wèn)題。

本文針對(duì)以上問(wèn)題，提出了自動(dòng)檔案庫(kù)系統(tǒng)的解決方案。自動(dòng)檔案庫(kù)由多層檔案柜、通信模塊和計(jì)算機(jī)控制系統(tǒng)等組成，能夠?qū)崿F(xiàn)檔案的自動(dòng)借閱和歸還，是綜合了信息自動(dòng)化、存儲(chǔ)和自動(dòng)識(shí)別技術(shù)于一身的立體集成化系統(tǒng)。設(shè)計(jì)該系統(tǒng)的目標(biāo)是為了減少檔案管理人員的工作量，對(duì)檔案管理的業(yè)務(wù)流程進(jìn)行調(diào)整和優(yōu)化，進(jìn)而規(guī)范檔案業(yè)務(wù)操作，提升檔案管理的自動(dòng)化水平，大大提高工作效率。

1 系統(tǒng)總體設(shè)計(jì)

本文所設(shè)計(jì)的控制系統(tǒng)分為三層：應(yīng)用管理層、檔案柜管理層和檔案柜控制層。應(yīng)用管理層與檔案柜管理層通過(guò)TCP協(xié)議進(jìn)行通信，檔案柜管理層與檔案柜控制層通過(guò)Modbus/TCP進(jìn)行通信，如圖1所示。

應(yīng)用管理層為檔案管理系統(tǒng)，它構(gòu)件了完整的檔案資源信息共享服務(wù)平臺(tái)，支持檔案管理全過(guò)程的信息化處理，主要包括以下功能：檔案接收、檔案移交、檔案查詢、檔案統(tǒng)計(jì)、檔案借閱、檔案歸還、檔案數(shù)據(jù)維護(hù)、檔案借閱記錄管理、檔案發(fā)送記錄管理、報(bào)表打印輸出、數(shù)據(jù)庫(kù)管理等。

檔案柜管理層對(duì)檔案柜控制層的集中管理，包括兩個(gè)方面的內(nèi)容：把應(yīng)用管理層發(fā)來(lái)的指令轉(zhuǎn)化為對(duì)檔案柜控制層的指令，定時(shí)讀取檔案柜控制層的消息，并轉(zhuǎn)為系統(tǒng)事件通知應(yīng)用管理層進(jìn)行相應(yīng)。

檔案柜控制層根據(jù)檔案柜管理的指令，控制檔案柜的走層、檔案的存取、檔案盤庫(kù)等操作，實(shí)時(shí)根據(jù)傳感器改變狀態(tài)寄存器的內(nèi)容。

圖1 系統(tǒng)總體框架圖

2 基于Modbus/TCP的傳輸控制協(xié)議

Modbus是一種應(yīng)用層報(bào)文傳輸協(xié)議，用于實(shí)現(xiàn)不同類型的網(wǎng)絡(luò)連接的設(shè)備之間的客戶機(jī)服務(wù)器之間的通信。Modbus/TCP協(xié)議一種的開(kāi)放的通信協(xié)議，用戶可以根據(jù)需要靈活進(jìn)行擴(kuò)展。[1]它支持C/S模式，將應(yīng)用層的Modbus消息封裝成IP包在網(wǎng)絡(luò)上傳輸。[2]

Modbus/TCP是采用C/S模式來(lái)進(jìn)行報(bào)文傳輸，此模式基于4種類型報(bào)文，即請(qǐng)求（Modbus Request）、指示（Modbus Confirmation）、響應(yīng)（Modbus Indication）和證實(shí)（Modbus Response），如圖2所示。請(qǐng)求是客戶端發(fā)送給服務(wù)器用來(lái)啟動(dòng)報(bào)文，指示是服務(wù)端接收的請(qǐng)求報(bào)文對(duì)客戶端的反饋，響應(yīng)是服務(wù)器針對(duì)客戶端的請(qǐng)求發(fā)送的具體響應(yīng)，證實(shí)是在客戶端接收的響應(yīng)信息時(shí)給服務(wù)器的反饋。[3]

圖2 Modbus/TCP報(bào)文傳輸

協(xié)議檔案柜管理層由運(yùn)行在PC機(jī)上檔案柜管理程序構(gòu)成，檔案柜控制層由觸摸屏（TPC）和控制電機(jī)和傳感器的可編程邏輯器件（PLC）構(gòu)成。協(xié)議檔案柜管理層通過(guò)網(wǎng)絡(luò)的Modbus/TCP協(xié)議，對(duì)各個(gè)觸摸屏（TPC）和可編程邏輯器件PLC的位變量、整型變量等的讀寫實(shí)現(xiàn)對(duì)檔案柜的遠(yuǎn)程測(cè)控，如圖3所示。

圖3 協(xié)議檔案柜管理層構(gòu)成圖

3 檔案自動(dòng)識(shí)別

目前成熟的檔案識(shí)別方法有條碼識(shí)別法[4]、RF識(shí)別法[5]。條碼識(shí)別法是在把打印好的條形碼粘貼到檔案盒上，把條形碼作為識(shí)別檔案的唯一標(biāo)示；RF識(shí)別法則是通過(guò)粘貼在檔案盒上的電子標(biāo)簽來(lái)識(shí)別檔案的。兩種識(shí)別方法特點(diǎn)不一，接下來(lái)對(duì)這兩種方法進(jìn)行具體討論。

使用條碼管理檔案，做法是為每個(gè)檔案盒編配唯一的條碼，條碼中包含特定規(guī)則的位置信息，然后將條碼貼到檔案盒外面的背脊上。一旦檔案盒中有檔案存入時(shí)，條碼、檔案盒和檔案就建立起了唯一的映射關(guān)系。將這種對(duì)應(yīng)關(guān)系信息錄入到計(jì)算機(jī)上的檔案管理系統(tǒng)中，為每一份檔案建立一條記錄，保存這份檔案對(duì)應(yīng)的條碼、在檔案柜中的位置、是否在柜等信息，這樣就打好了檔案識(shí)別的基礎(chǔ)。檔案首次入庫(kù)時(shí)，條碼與檔案的映射關(guān)系建立，數(shù)據(jù)庫(kù)中產(chǎn)生相關(guān)記錄。當(dāng)需要借閱或者歸還檔案時(shí)，檔案識(shí)別系統(tǒng)就可以通過(guò)條碼定位檔案盒，找到了檔案盒就相當(dāng)于找到了目標(biāo)檔案。

射頻識(shí)別系統(tǒng)由電子標(biāo)簽和閱讀器兩部分組成。在檔案識(shí)別系統(tǒng)中通常的做法是把閱讀器安裝在檔案柜中，把電子標(biāo)簽粘貼到檔案盒上。電子標(biāo)簽中保存的數(shù)據(jù)通過(guò)特定的編碼存儲(chǔ)在電子標(biāo)簽中，閱讀器可以非接觸的讀取電子數(shù)據(jù)。系統(tǒng)工作過(guò)程分為能力供給和信號(hào)識(shí)別兩個(gè)部分。其中能力供給指的是電子標(biāo)簽對(duì)電子標(biāo)簽閱讀器發(fā)出的微波查詢信號(hào)進(jìn)行轉(zhuǎn)換，把微波信號(hào)轉(zhuǎn)換為電流；信號(hào)識(shí)別指的是微波查詢信號(hào)經(jīng)過(guò)電子標(biāo)簽內(nèi)部的電路處理之后，攜帶了電子標(biāo)簽內(nèi)部存儲(chǔ)的數(shù)據(jù)信息，利用電子標(biāo)簽自帶的微型天線返回到閱讀器中。經(jīng)過(guò)能力供給和信號(hào)識(shí)別兩個(gè)過(guò)程，閱讀器就可以拿到電子標(biāo)簽存儲(chǔ)的數(shù)據(jù)信息，實(shí)現(xiàn)檔案識(shí)別。以下針對(duì)條碼識(shí)別法、RF識(shí)別法分別比較兩者優(yōu)缺點(diǎn)，如表1所示。

表1 條碼識(shí)別法、RF識(shí)別法優(yōu)缺點(diǎn)比較

條碼識(shí)別法 RF識(shí)別法

掃描速度 掃描槍一次只能掃描一個(gè)條碼 RFID閱讀器可同時(shí)辨識(shí)讀取多個(gè)RFID標(biāo)簽

抗污染能力和耐久性 條形碼采用紙張打印，抗污染能力和耐久性差 RFID一般采用塑料材質(zhì)封裝，具有很強(qiáng)的耐污性和耐久性

穿透性和無(wú)屏障閱讀 在沒(méi)有阻擋和近距離的情況下，條碼才能被識(shí)別 RFID通信具有一定的穿透性，除金屬材質(zhì)外一般材質(zhì)都能穿透

成本 條碼和條碼掃描槍成本很低 RFID標(biāo)簽和RFID閱讀器成本較高

針對(duì)條碼識(shí)別法、RF識(shí)別法的特點(diǎn)，各單位可以根據(jù)需求選用不同的方案。條碼識(shí)別法和RF識(shí)別法在系統(tǒng)中識(shí)別和傳輸過(guò)程中，由于條碼被污染和斜放等情況，RF識(shí)別法信道中有噪聲干擾和標(biāo)示有重疊的情況，引起數(shù)字信號(hào)波形的失真導(dǎo)致錯(cuò)誤，針對(duì)錯(cuò)碼的問(wèn)題，通過(guò)兩種策略來(lái)處理。一種方法是在檔案標(biāo)識(shí)上設(shè)置冗余的信息位，在一定錯(cuò)誤率的情況下可以通過(guò)算法推算出錯(cuò)誤的信息，常用算法有循環(huán)冗余CRC校驗(yàn)；另外一種是設(shè)置校驗(yàn)位，通過(guò)校驗(yàn)位來(lái)驗(yàn)證發(fā)送的信息，驗(yàn)證不通過(guò)的情況下讓接收方請(qǐng)求重傳，常用算法有奇偶校驗(yàn)、漢明校驗(yàn)。因?yàn)闄n案柜在掃描槍掃描過(guò)程中一般都是一次掃描，所以我們一般采用糾錯(cuò)碼的策略來(lái)解決誤碼的問(wèn)題。

5 檔案自動(dòng)盤庫(kù)

為了解決人工歸還和借閱檔案時(shí)放錯(cuò)位置的問(wèn)題，設(shè)計(jì)檔案自動(dòng)盤庫(kù)功能，通過(guò)該功能可以對(duì)整個(gè)檔案柜的檔案進(jìn)行批量整理并與檔案信息系統(tǒng)中存放的檔案存放信息進(jìn)行核對(duì)修改。

自動(dòng)盤庫(kù)操作流程如下所示：（1）執(zhí)行檔案柜走層操作，準(zhǔn)確走到確定層；（2）啟動(dòng)盤庫(kù)掃描槍從左到右運(yùn)動(dòng)掃描整個(gè)層中的檔案，一層掃描完成后，盤庫(kù)掃描槍從右到左運(yùn)動(dòng)回到起始點(diǎn)再執(zhí)行走層動(dòng)作，直到掃描完畢，經(jīng)過(guò)掃描得到的柜號(hào)、層號(hào)、檔案標(biāo)識(shí)通過(guò)Modbus/TCP協(xié)議傳給檔案柜控制層，檔案柜控制層通知應(yīng)用層程序，對(duì)掃描的數(shù)據(jù)進(jìn)行處理；（3）檔案柜向上走一層，繼續(xù)流程2，直到完成所有層的掃描，自動(dòng)盤庫(kù)完成。

在進(jìn)行盤庫(kù)操作時(shí)，檔案柜控制層把盤庫(kù)掃描槍掃描到一個(gè)檔案標(biāo)識(shí)就會(huì)將柜號(hào)、層號(hào)、檔案標(biāo)識(shí)發(fā)送給檔案柜管理層，檔案柜管理層觸發(fā)應(yīng)用層程序的事件，應(yīng)用程序處理相應(yīng)事件顯示差異信息，用戶根據(jù)差異信息選擇進(jìn)行更新檔案存取信息和借閱情況。

5 檔案管理層接口規(guī)范

不同廠商采用的硬件類型一般是不同的，同一廠商的不同型號(hào)的設(shè)備通常也有所區(qū)別，傳統(tǒng)的檔案管理軟件基本都是針對(duì)某一款特定的檔案柜設(shè)計(jì)的，所以不具有通用性。硬件上一些小改動(dòng)或升級(jí)就會(huì)導(dǎo)致整個(gè)應(yīng)用程序的大范圍改動(dòng)甚至重寫。傳統(tǒng)的檔案管理程序與設(shè)備是一一對(duì)應(yīng)的，每一種設(shè)備都需要開(kāi)發(fā)專用的管理程序和相應(yīng)驅(qū)動(dòng)。傳統(tǒng)檔案管理層的開(kāi)發(fā)示意圖如圖4所示。

圖4 傳統(tǒng)檔案管理層的開(kāi)發(fā)示意圖

在實(shí)際的大型檔案管理系統(tǒng)中，檔案柜類型往往不止一種，同種類型的檔案柜每隔一段時(shí)間也會(huì)進(jìn)行硬件升級(jí)，在這種情況下，檔案管理層的接口如果仍然按照傳統(tǒng)的結(jié)構(gòu)進(jìn)行設(shè)計(jì)，必然會(huì)帶來(lái)很多問(wèn)題，在很大程度上增加系統(tǒng)開(kāi)發(fā)和維護(hù)的成本。在本文的檔案柜系統(tǒng)設(shè)計(jì)中，檔案柜管理層為了實(shí)現(xiàn)與底層硬件設(shè)備的無(wú)關(guān)性，需要硬件設(shè)備已經(jīng)統(tǒng)一的基于COM組件，不同硬件設(shè)備指需要按照統(tǒng)一COM編寫自己組件，就可以實(shí)現(xiàn)協(xié)議檔案柜管理層對(duì)檔案柜控制層的操作，如圖5所示。

圖5 基于COM組件的檔案層接口規(guī)范

6 結(jié)束語(yǔ)

通過(guò)對(duì)自動(dòng)檔案庫(kù)系統(tǒng)合理設(shè)計(jì)，將系統(tǒng)分為應(yīng)用管理層、檔案柜管理層和檔案柜控制層。應(yīng)用管理層與檔案柜管理層通過(guò)TCP/IP協(xié)議進(jìn)行通信，檔案柜管理層與檔案柜控制層通過(guò)Modbus/TCP協(xié)議進(jìn)行通信，針對(duì)人工歸還和借閱檔案時(shí)放錯(cuò)位置的問(wèn)題，專門設(shè)計(jì)檔案自動(dòng)盤庫(kù)功能，同時(shí)為了實(shí)現(xiàn)檔案柜管理層與底層硬件設(shè)備的無(wú)關(guān)性，制定了檔案管理層接口規(guī)范。實(shí)際使用表明：基于Modbus/TCP協(xié)議自動(dòng)檔案庫(kù)系統(tǒng)可以方便快捷的實(shí)現(xiàn)電子檔案系統(tǒng)與紙載檔案管理的無(wú)縫結(jié)合，在大幅度提高檔案的管理效率和檔案管理自動(dòng)化水平的同時(shí)，降低了檔案管理費(fèi)用和檔案管理人員的工作量，充分提高工作效率。

參考文獻(xiàn)：

[1]喬永衛(wèi)，程帥.基于Modbus協(xié)議的自動(dòng)控制系統(tǒng)的通信研究[J].自動(dòng)化與儀表，2012（08）：34-37.

[2]白焰，鐘艷輝，秦宇飛.基于VC的Modbus協(xié)議通信測(cè)試軟件的實(shí)現(xiàn)―Modbus串口通信與Modbus/TCP通信[J].現(xiàn)代電力，2008（06）：76-81.

[3]翁建年，張浩，彭道剛.基于嵌入式ARM的Modbus_TCP協(xié)議的研究與實(shí)現(xiàn)[J].計(jì)算機(jī)應(yīng)用與軟件，2009（10）：36-39.

[4]張應(yīng)福.物聯(lián)網(wǎng)技術(shù)與應(yīng)用[J].通信與信息技術(shù)，2010（01）：50-54.

[5]杜曉明，葛世倫.基于RFID和條形碼的中小企業(yè)倉(cāng)庫(kù)管理系統(tǒng)研究[J].組合機(jī)床與自動(dòng)化加工技術(shù)，2010（02）：106-110.

[6]郎為民.射頻識(shí)別（RFID）技術(shù)原理與應(yīng)用[M].北京：機(jī)械工業(yè)出版社，2006.

[7]康東，石喜勤，李勇鵬.射頻識(shí)別RFID核心技術(shù)與典型應(yīng)用開(kāi)發(fā)案例[M].北京：人民郵電出版社，2008.

[8]Don 本質(zhì)論[M].潘愛(ài)民，譯.北京：中國(guó)電力出版社，2001.

[9]（美）WilliamA.Shay.高傳善等譯.數(shù)據(jù)通信與網(wǎng)絡(luò)教程[M].北京：機(jī)械工業(yè)出版社，2005.

[10]胡嘯，陳星，吳志剛.無(wú)線射頻識(shí)別安全初探[J].信息安全與通信保密，2005（06）.

[11]柴先明，黃知濤.信道編碼盲識(shí)別問(wèn)題研究[J].通信對(duì)抗，2008（02）：1-4.

[12]Vaidya N，Das S R.RFID based networks exploiting diversity and redundancy[J].ACM SIGMOBILE Mobile Computing and Communications Review，2008（01）：2-14.

[13]葉佳帆.基于modbus/tcp以太網(wǎng)技術(shù)的靜電除塵器的研究[D].碩博學(xué)位論文，2009.

篇8

關(guān)鍵詞：風(fēng)電場(chǎng)；遠(yuǎn)程監(jiān)控；SCADA；Modbus/TCP；PLC

中圖分類號(hào)：TP277 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1674-7712 （2014） 02-0000-01

對(duì)風(fēng)力發(fā)電機(jī)組進(jìn)行遠(yuǎn)程監(jiān)視控制十分必要，而風(fēng)電廠遠(yuǎn)程監(jiān)控系統(tǒng)的軟件則是重中之重，它直接決定了整個(gè)系統(tǒng)的穩(wěn)定性和效率。

Modbus/TCP協(xié)議目前應(yīng)用廣泛，絕大多數(shù)廠商的PLC都支持Modbus/TCP協(xié)議，其具有良好的通用性，因此基于Modbus/TCP協(xié)議開(kāi)發(fā)客戶端程序已成為風(fēng)電遠(yuǎn)程監(jiān)控系統(tǒng)一種行之有效的方法。

一、Modbus/TCP協(xié)議

Modbus/TCP協(xié)議以一種非常簡(jiǎn)單的方式將Modbus幀嵌入到TCP幀中，使其成為工業(yè)以太網(wǎng)應(yīng)用層協(xié)議，Modbus協(xié)議層在TCP之上，其主要完成的任務(wù)為：在服務(wù)器端，負(fù)責(zé)解譯來(lái)自客戶端的Modbus幀，執(zhí)行相應(yīng)的請(qǐng)求[1]。

Modbus TCP協(xié)議的幀格式如表1所示。應(yīng)用協(xié)議報(bào)頭分為4個(gè)部分，數(shù)據(jù)標(biāo)識(shí)符用來(lái)標(biāo)識(shí)Modbus幀的次序，每多發(fā)送一個(gè)Modbus幀，該值加1；協(xié)議標(biāo)識(shí)符用來(lái)確認(rèn)是不是Modbus協(xié)議，如果是Modbus協(xié)議用1表示，其他協(xié)議用0表示；接下來(lái)2個(gè)字節(jié)用來(lái)表示后續(xù)字節(jié)數(shù)，即從單元標(biāo)識(shí)符開(kāi)始一直到數(shù)據(jù)域結(jié)束的字節(jié)數(shù)，單元標(biāo)識(shí)符用來(lái)標(biāo)識(shí)Modbus串行線上的某個(gè)設(shè)備單元，由于風(fēng)機(jī)都是網(wǎng)絡(luò)結(jié)構(gòu)，所以這一字節(jié)并沒(méi)有實(shí)際意義，填0x0或0xFF即可。功能碼的含義如表2所示。數(shù)據(jù)域則添加要發(fā)送的數(shù)據(jù)，如果是向PLC發(fā)送讀請(qǐng)求的話，數(shù)據(jù)域?yàn)橐x取的寄存器起始地址和要讀取的寄存器個(gè)數(shù)，如果是向PLC發(fā)送寫請(qǐng)求，則數(shù)據(jù)域?yàn)橐獙懭氲募拇嫫髌鹗嫉刂泛鸵獙懭氲募拇嫫鱾€(gè)數(shù)、需要寫入的字節(jié)數(shù)以及需要寫入的數(shù)據(jù)。

一、運(yùn)用C#編程實(shí)現(xiàn)通訊

C#是微軟公司設(shè)計(jì)的一種編程語(yǔ)言，是從C和C++派生來(lái)的一種簡(jiǎn)單、現(xiàn)代、面向?qū)ο蠛皖愋桶踩木幊陶Z(yǔ)言，并且能夠與.NET框架完美結(jié)合[2]。

為了簡(jiǎn)化網(wǎng)絡(luò)編程復(fù)雜度，.NET對(duì)套接字又進(jìn)行了封裝，封裝后的類就是.Sockets命名空間下的TcpListener類和TcpClient類。但是要注意，TcpListener和TcpClient只支持標(biāo)準(zhǔn)協(xié)議編程。如果希望編寫非標(biāo)準(zhǔn)協(xié)議的程序，只能使用套接字來(lái)實(shí)現(xiàn)[3]。

核心代碼

值得一提的是，由于PLC與計(jì)算機(jī)的數(shù)據(jù)存儲(chǔ)方式可能不同，因此需要進(jìn)行大小端判斷及轉(zhuǎn)換，轉(zhuǎn)換可以采用Reverse（）方法。軟件界面的設(shè)計(jì)如圖2所示，通過(guò)該界面可以實(shí)現(xiàn)對(duì)風(fēng)機(jī)進(jìn)行啟?？刂疲β收{(diào)節(jié)，數(shù)據(jù)采集，繪制圖表，查看故障等功能，可滿足風(fēng)電場(chǎng)遠(yuǎn)程監(jiān)控系統(tǒng)的絕大部分需求。

三、結(jié)束語(yǔ)

實(shí)踐表明，該軟件通過(guò)Modbus TCP協(xié)議與風(fēng)力發(fā)電機(jī)組實(shí)現(xiàn)了數(shù)據(jù)交互，可通過(guò)上位機(jī)對(duì)機(jī)組進(jìn)行啟動(dòng)、停機(jī)、復(fù)位、限定功率等控制，查看機(jī)組各傳感器反饋數(shù)據(jù)，查看故障代碼，運(yùn)行穩(wěn)定，操作簡(jiǎn)單，具有實(shí)際價(jià)值。

參考文獻(xiàn)：

[1]郝曉弘，祖守圓，徐維濤.基于VC的Modbus/TCP協(xié)議模型通信測(cè)試軟件的實(shí)現(xiàn)[J].微計(jì)算機(jī)信息，2006.

篇9

關(guān)鍵詞：會(huì)話初始化協(xié)議SIP；TCPN；建模；模型

中圖分類號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2016）25-0035-02

1 引言

第三代合作伙伴3GPP選擇SIP協(xié)議作為第三代移動(dòng)通信系統(tǒng)的IP多媒體子系統(tǒng)（IMS）心靈協(xié)議，是因其具有靈活、無(wú)縫和可擴(kuò)展性，它將逐漸成為下一代網(wǎng)絡(luò)NGN中關(guān)鍵控制協(xié)議之一。它可以滿足多媒體通信與網(wǎng)絡(luò)電話的要求，所以很多的通訊公司均先后研發(fā)出了支持SIP的服務(wù)產(chǎn)品與終端產(chǎn)品。為充分適應(yīng)這些技術(shù)的發(fā)展，SIP協(xié)議需要進(jìn)行進(jìn)一步的完善與擴(kuò)充，但是如果協(xié)議在設(shè)計(jì)環(huán)節(jié)出現(xiàn)任何問(wèn)題都會(huì)給系統(tǒng)帶來(lái)難以預(yù)料的影響，所以為保證協(xié)議的穩(wěn)定性和安全性，應(yīng)在早期開(kāi)發(fā)時(shí)盡可能挖掘其隱蔽的問(wèn)題并找出解決方案。

目前研究SIP協(xié)議主要涉及以下幾方面：基于SIP的應(yīng)用于服務(wù)[3]；SIP測(cè)試工具和方法；其他協(xié)議與SIP協(xié)同工作。因時(shí)間著色Petri網(wǎng)TCPN[2]在描述帶有較復(fù)雜的交互動(dòng)作和時(shí)間約束的系統(tǒng)過(guò)程中具有明顯的優(yōu)勢(shì)，故本文以TCPN為模型分析工具進(jìn)行SIP協(xié)議分層TCPN模型的構(gòu)造，并在不同狀態(tài)下實(shí)現(xiàn)分層建模。

2 SIP協(xié)議事務(wù)處理

SIP協(xié)議通過(guò)事務(wù)進(jìn)行會(huì)話控制，其主要事務(wù)有INVITE、non_INVITE事務(wù)。INVITE事務(wù)完成會(huì)話的創(chuàng)建，non_INVITE事務(wù)則完成會(huì)話的保持與關(guān)閉。SIP端系統(tǒng)（User Agent，UA）是連接服務(wù)器從而發(fā)送服務(wù)請(qǐng)求的一種應(yīng)用程序。因UA向服務(wù)器發(fā)送服務(wù)請(qǐng)求并接收來(lái)自服務(wù)器的響應(yīng)，故一個(gè)UA有UAS（用戶服務(wù)器）和UAC（用戶客戶端）兩部分，這兩部分就是SIP協(xié)議中的兩個(gè)最關(guān)鍵的參與者，UAC創(chuàng)建呼叫請(qǐng)求，UAS接受呼叫給出響應(yīng)。

在SIP的請(qǐng)求消息中，最常用的有INVITE、REGISTER、CANCEL和BYE。其響應(yīng)消息有1xx、2xx、3xx、4xx、5xx、6xx6種。SIP的呼叫方式有3種：從UAC到UAS的直接呼叫、從UAC發(fā)出的重定向呼叫、服務(wù)器發(fā)起呼叫。本文主要針對(duì)應(yīng)用最廣的直接呼叫進(jìn)行分層建模。

3 SIP協(xié)議TCPN分層建模

本文應(yīng)用CPN Tools[4]進(jìn)行INVITE事務(wù)的分層建模，并在不同的抽象層次上描述協(xié)議行為細(xì)化模型。這種方法在一個(gè)層次中描述協(xié)議細(xì)節(jié)，有利于優(yōu)化或局部完善協(xié)議模型，也能有效把握模型規(guī)模，便于確認(rèn)模型與分析協(xié)議性質(zhì)。

SIP協(xié)議的TCPN分層模型中的10個(gè)模型頁(yè)分別處于不同的層次，每頁(yè)所描述的是對(duì)應(yīng)抽象級(jí)別上的協(xié)議功能，低級(jí)別頁(yè)作為高級(jí)別頁(yè)的替代變遷子頁(yè)。各層次模型頁(yè)功能描述如下表1。各層內(nèi)部模塊細(xì)化是依據(jù)UAS與UAC在INVITE事務(wù)執(zhí)行過(guò)程中具備的不同狀態(tài)進(jìn)行的，因在terminated狀態(tài)下協(xié)議無(wú)行為，而僅表示終止事務(wù)，故沒(méi)有單獨(dú)描述此狀態(tài)。

3.1 總體流程建模

SIP協(xié)議分層TCPN模型的top page（頂級(jí)頁(yè)）如下圖1所示，它總體描述了協(xié)議運(yùn)行的網(wǎng)絡(luò)拓?fù)?，其中使用?個(gè)替代變遷對(duì)NET、UAS和UAC在協(xié)議運(yùn)行過(guò)程中的交互行為進(jìn)行描述。UAC通過(guò)NET向UAS發(fā)送REQUEST型數(shù)據(jù)，UAS將RESPONSES型數(shù)據(jù)通過(guò)NET回傳給UAC。

Client頁(yè)用以描述UAC的行為，下圖2所示為其頁(yè)模型。圖中的3個(gè)替代變遷對(duì)應(yīng)的子頁(yè)能夠更加細(xì)致地描述處于不同狀態(tài)的UAC端行為。庫(kù)所Scene用以描述UAC的行為，變遷TransErr可以模擬協(xié)議在不同條件下出現(xiàn)傳輸層錯(cuò)誤時(shí)所采取的處理方式。

3.2 網(wǎng)絡(luò)層建模

下圖3所示為NET頁(yè)模型，描述的是由UAC到UAS的網(wǎng)絡(luò)傳輸建模。庫(kù)所Schannel_Em記錄的是有多少個(gè)消息被成功地傳送到了UAS端，其初值為0。庫(kù)所CollectorCTS用以收集不可靠鏈路丟失的消息。變遷RCTS與CTOS用以模擬不可靠鏈路。不可靠鏈路的具體建模方式如表2所示。

通過(guò)上述時(shí)間類型、弧表達(dá)式及防衛(wèi)表達(dá)式的應(yīng)用，可模擬存在重復(fù)數(shù)據(jù)包、延遲、丟包的不可靠鏈路。若對(duì)其某些參數(shù)做適當(dāng)?shù)男薷模憧蓜?dòng)態(tài)調(diào)整其鏈路的可靠性，以此來(lái)真實(shí)地模擬不可靠鏈路。

3.3 具體行為建模

本文表1中的Sproceeding、Ccalling、Cproceeding等底層模型頁(yè)描述UAS和UAC在不同狀態(tài)下處理事件的過(guò)程，也就是對(duì)協(xié)議的具體行為建模。下文以UAC端處于Ccalling狀態(tài)時(shí)的應(yīng)答消息處理行為為例，闡述具體行為的模型描述方式。

下圖4所示為UAC處于Ccalling狀態(tài)時(shí)處理INVITE消息的模型，即Ccalling頁(yè)模型。圖中CallTimer表示UAC處于超時(shí)狀態(tài)時(shí)消息的處理過(guò)程，CallResp表示UAC收到UAS應(yīng)答時(shí)對(duì)消息的處理過(guò)程。庫(kù)所TimerAorB用以控制A與B兩個(gè)定時(shí)器的觸發(fā)。融合庫(kù)所cloneCs用隊(duì)列存放UAC每次狀態(tài)的變化，其隊(duì)首為UAC的當(dāng)前狀態(tài)，Scenec記錄UAC的當(dāng)前狀態(tài)和導(dǎo)致UAC變?yōu)榇藸顟B(tài)的事件。Message存放初始條件下從SIP協(xié)議上層收到的INVITE請(qǐng)求。Channel_Em用以記錄當(dāng)前是否收到UAS的應(yīng)答，其初值為0。

當(dāng)收到UAS會(huì)送的響應(yīng)消息時(shí)，變遷CallResp被點(diǎn)火執(zhí)行，即運(yùn)行其對(duì)應(yīng)的函數(shù)代碼。此函數(shù)代碼中sta與st均為SCENEC型變量，st是處理消息前UAC的狀態(tài)，sta為處理消息后UAC的狀態(tài)。Action部分調(diào)用函數(shù)call_resp（st，resp）完成UAC對(duì)不同類型響應(yīng)消息的處理，該函數(shù)代碼如下：

由上述代碼可知，處理類型為r2xx的應(yīng)答消息后UAC處于TERM狀態(tài)，處理類型為r3xx的應(yīng)答消息后處于COMP狀態(tài)，處理類型為r1xx的應(yīng)答消息后處于PROC狀態(tài)。

4 總結(jié)

本文給出了SIP協(xié)議處理INVITE事務(wù)的TCPN分層模型，對(duì)該協(xié)議總體流程、網(wǎng)絡(luò)層、UAS與UAC間的具體行為在不同模型層次上分別進(jìn)行建模。該層次模型規(guī)?？煽亍⒐δ軇澐种庇^、數(shù)據(jù)結(jié)構(gòu)完備，為建模后期協(xié)議的驗(yàn)證與改進(jìn)提供了較完善的模型基礎(chǔ)。

參考文獻(xiàn)：

[1] 姜秀玉，楊峰，崔再惠.SIP協(xié)議實(shí)現(xiàn)中消息解析的研究[J].計(jì)算機(jī)工程與設(shè)計(jì)，2010（7）.

[2] 何中陽(yáng)，李鷗，楊白薇，等.基于TCPN的TCP協(xié)議形式化描述[J].計(jì)算機(jī)工程，2011（9）.

篇10

關(guān)鍵詞：UDP協(xié)議；Socket；網(wǎng)絡(luò)通信

中圖分類號(hào)：TP393文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1009-3044(2008)34-1867-02

Socket Network Programs Based on UDP Protocol

ZHOU Li-juan

(College of Science, Hunan University of Technology, Zhuzhou 412008, China)

Abstract: Windows Socket is a network programming interface,and applications can correspond to eachother in different domains without worrying about the different protocols by using it.This paper introduces the mechanism and principle of Socket network programs based on UDP protocol,and proposes a method of network with Java socket.

key words: UDP protocol;socket; network communication

Socket適用于網(wǎng)絡(luò)環(huán)境中的進(jìn)程間通信，它已成為當(dāng)前許多操作系統(tǒng)的網(wǎng)絡(luò)API，也是網(wǎng)絡(luò)操作系統(tǒng)中必不可少的基礎(chǔ)功能。隨著Linux操作系統(tǒng)和Internet的不斷發(fā)展，Linux網(wǎng)絡(luò)環(huán)境下尤其是基于UDP的socket通信技術(shù)仍廣為注目。文章介紹了socket的編程原理，并通過(guò)一個(gè)Java編寫的客戶/服務(wù)器程序，描述了網(wǎng)絡(luò)中基于UDP的不同主機(jī)上的兩個(gè)進(jìn)程之間的socket通信機(jī)制。

1 Socket通信機(jī)制

Socket（套接字）機(jī)制是一種API，是網(wǎng)絡(luò)應(yīng)用程序的編程接口。Socket是通過(guò)標(biāo)準(zhǔn)文件描述符和其它程序通訊的一個(gè)方法。每一個(gè)套接字都用一個(gè)半相關(guān)描述：{協(xié)議，本地地址、本地端口}來(lái)表示；一個(gè)完整的套接字則用一個(gè)相關(guān)描述：{協(xié)議，本地地址、本地端口、遠(yuǎn)程地址、遠(yuǎn)程端口}，每一個(gè)套接字都有一個(gè)本地的由操作系統(tǒng)分配的唯一的套接字號(hào)。

根據(jù)傳輸數(shù)據(jù)類型的不同，Socket主要分為三類：1) 流式Socket（SOCK_STREAM），在這種方式下，兩個(gè)通訊的應(yīng)用程序之間要先建立一種虛擬的連接，提供可靠的、面向連接的通信流，它使用TCP協(xié)議，從而保證了數(shù)據(jù)傳輸?shù)恼_性和順序的。2) 數(shù)據(jù)報(bào)Socket（SOCK_DGRAM），它使用數(shù)據(jù)報(bào)協(xié)議UDP，定義了一種無(wú)連接的服務(wù)，數(shù)據(jù)通過(guò)相互獨(dú)立的報(bào)文進(jìn)行傳輸，是無(wú)序的，并且不保證可靠、無(wú)差錯(cuò)。3) 原始Socket，原始套接字允許對(duì)底層協(xié)議如IP或ICMP直接訪問(wèn)，它功能強(qiáng)大但使用較為不便，主要用于一些協(xié)議的開(kāi)發(fā)。

2 UDP協(xié)議的工作原理

UDP協(xié)議是一個(gè)面向無(wú)連接的協(xié)議，其連接的建立不必像TCP那樣需要服務(wù)器端偵聽(tīng)，也不需要有客戶機(jī)請(qǐng)求連接，屬于一種“強(qiáng)制”性的網(wǎng)絡(luò)連接。UDP提供一對(duì)一或一對(duì)多的、無(wú)連接的數(shù)據(jù)報(bào)服務(wù)。該服務(wù)對(duì)消息中傳輸?shù)臄?shù)據(jù)提供不可靠的、最大努力的傳送，這意味著它不保證數(shù)據(jù)的到達(dá)，也不保證所傳送的數(shù)據(jù)報(bào)的順序是否正確，UDP不重新傳輸丟失的數(shù)據(jù)。其主要工作是：將應(yīng)用程序傳輸過(guò)來(lái)的數(shù)據(jù)分塊交給網(wǎng)絡(luò)層，確認(rèn)接受到分組信息。

盡管UDP無(wú)法像TCP一樣提供可靠的數(shù)據(jù)傳輸，但UDP并不比TCP缺乏優(yōu)越性。UDP在傳輸效率方面比TCP要高一些，而且許多應(yīng)用程序并不需要保證嚴(yán)格的傳輸可靠性，比如視頻會(huì)議系統(tǒng)等，需要實(shí)時(shí)的交互，但并不要求音頻視頻的絕對(duì)正確。

使用UDP協(xié)議傳輸數(shù)據(jù)時(shí)，首先設(shè)置客戶計(jì)算機(jī)的Local Port(本地端口)屬性，而作為服務(wù)器的計(jì)算機(jī)只需要設(shè)置Remoter Host(遠(yuǎn)程主機(jī))屬性為客戶計(jì)算機(jī)的IP地址或域名即可，并將其Remote Port屬性設(shè)置為客戶計(jì)算機(jī)上的Local Port屬性。使用UDP端口號(hào)時(shí)，端口提供了用于發(fā)送消息的位置，每個(gè)端口由一個(gè)唯一的編號(hào)來(lái)標(biāo)識(shí)。當(dāng)應(yīng)用程序向另一臺(tái)計(jì)算機(jī)發(fā)送數(shù)據(jù)時(shí)，UDP生成一個(gè)數(shù)據(jù)頭，包括源端口，這些端口提供送達(dá)信息所需要的地址。UDP協(xié)議還為數(shù)據(jù)和數(shù)據(jù)頭計(jì)算出求和檢驗(yàn)的值，在目標(biāo)計(jì)算機(jī)中，數(shù)據(jù)包被傳遞至UDP協(xié)議程序并送到目的地端口。

3 UDP套接字的通信過(guò)程

中提供了兩個(gè)類DatagramSocket和DatagramPacket用來(lái)支持?jǐn)?shù)據(jù)報(bào)通信。DatagramSoc ket用來(lái)在程序之間建立傳送數(shù)據(jù)報(bào)的通信連接，是數(shù)據(jù)報(bào)通信中的Socket。在數(shù)據(jù)報(bào)實(shí)現(xiàn)C/S通信程序時(shí)，無(wú)論在客戶端還是服務(wù)器端，都要首先建立一個(gè)DatagramSocket對(duì)象，用來(lái)表示數(shù)據(jù)報(bào)通信的端點(diǎn)，應(yīng)用程序通過(guò)Socket接收或發(fā)送數(shù)據(jù)報(bào)。

DatagramPacket則用來(lái)表示一個(gè)數(shù)據(jù)報(bào)，它是傳輸數(shù)據(jù)的載體，封裝了數(shù)據(jù)、數(shù)據(jù)長(zhǎng)度、數(shù)據(jù)報(bào)地址等信息。

采用UDP套接字方式實(shí)現(xiàn)C/S的通信程序由客戶端和服務(wù)器端兩部分組成。服務(wù)器進(jìn)程依次按以下步驟進(jìn)行：1) 調(diào)用Socket()創(chuàng)建一個(gè)數(shù)據(jù)報(bào)套接字；2) 調(diào)用bind()把服務(wù)器地址綁定在該套接字上；3) 調(diào)用recvform()等待客戶進(jìn)程發(fā)來(lái)的請(qǐng)求，服務(wù)器此時(shí)處于無(wú)限循環(huán)狀態(tài)；4) 服務(wù)進(jìn)程接收到客戶進(jìn)程所發(fā)來(lái)的數(shù)據(jù)報(bào)后，進(jìn)行處理，調(diào)用sendto()將處理結(jié)果返回給客戶進(jìn)程，返回狀態(tài)3)，繼續(xù)監(jiān)聽(tīng)；5)服務(wù)進(jìn)程調(diào)用close()撤消套接字，終止服務(wù)。

客戶進(jìn)程則按以下步驟進(jìn)行：1) 調(diào)用Socket()創(chuàng)建一個(gè)數(shù)據(jù)流套接字；2) 調(diào)用sendto()向服務(wù)器進(jìn)程發(fā)送數(shù)據(jù)報(bào)；3) 調(diào)用recvfrom()等待服務(wù)器進(jìn)程返回該處理結(jié)果；4) 客戶進(jìn)程調(diào)用close()撤消套接字。

4 數(shù)據(jù)報(bào)通信實(shí)例

程序由服務(wù)器端和客戶端兩部分組成，服務(wù)器端主機(jī)中有一個(gè)名為“udp_socket.txt”文件，文件中保存了一段英文。服務(wù)器端接收一個(gè)客戶端的請(qǐng)求，就從文件中讀取若干個(gè)英文字符發(fā)送給客戶端。當(dāng)文件中所有內(nèi)容發(fā)送給完畢，服務(wù)器端程序?qū)⑼顺?。客戶端首先?gòu)造一個(gè)數(shù)據(jù)報(bào)發(fā)送給服務(wù)器端，然后等待接受服務(wù)器端響應(yīng)，當(dāng)接收到服務(wù)器端的數(shù)據(jù)報(bào)后，顯示數(shù)據(jù)并結(jié)束通信。

1) 服務(wù)器端程序

public class Server_Th

{ boolean m_q=true;

public void serverWork() throea IOException

{DatagramSocket ds=new DatagramSocket(2000)

//創(chuàng)建端口號(hào)為2000的數(shù)據(jù)報(bào)套接字

BufferedReader in=new BufferedReader(new FileReader (“udp_socket.txt”));

while(m_q)

{ byte buf[ ]=new byte[256];//創(chuàng)建緩沖區(qū)

DatagramPacket packet=new DatagramPacket (buf, buflength); //創(chuàng)建接收數(shù)據(jù)報(bào)對(duì)象

ds.receive(packet);//接收數(shù)據(jù)報(bào)

String dString=null;

if((dString=in.reaLine())==null)

{in.close();

m_q=false;

dString=”Good Morning!”;}

buf=dString.getBytes();//將數(shù)據(jù)存儲(chǔ)到buf中

inetAddress address=packet.getAddress();

//得到客戶端IP地址

int prot=packet.getPort();//得到客戶端的端口

packet=new DatagramPacket (buf,buf.length, address. port );

//構(gòu)造要發(fā)送數(shù)據(jù)報(bào)

ds.send(packet);//發(fā)送數(shù)據(jù)報(bào)

}

ds.close();//關(guān)閉

}

public void main(String args[])

{ Server_Th server=new Server_Th();

try

{server.serverWork();}

Catch(IOException e){}

}}

2) 客戶端程序

public class Client_Th

{public void main(String args[ ]) throws IOException

{ DatagramSocket socket=new DatagramSocket( );

//創(chuàng)建套接字對(duì)象

byte buf[ ]=new byte[256];

InetAdress address=InetAddress.getByName(“20.14.30.9”);

//服務(wù)器IP地址

DatagramPacket packet=new DatagramPacket(buf,buf. Length,address,2000);//創(chuàng)建要發(fā)送的數(shù)據(jù)報(bào)對(duì)象

socket.send(packet);//接收數(shù)據(jù)報(bào)

packet=new DatagramPacket(buf,buf.length);

//創(chuàng)建要接收的數(shù)據(jù)報(bào)對(duì)象

socket.receive(packet);//接收數(shù)據(jù)報(bào)

String received=new String(packet.getData());

System.out.println(“The string form the server: ”+recerived);

//取得數(shù)據(jù)報(bào)中的數(shù)據(jù)并顯示

Socket.close();//關(guān)閉socket

}}

編寫程序時(shí)客戶端和服務(wù)器端的DatagramSocket必須用一個(gè)端口，因?yàn)榭蛻舳讼蚍?wù)器端請(qǐng)求時(shí)，服務(wù)器需要知道從哪個(gè)端口監(jiān)聽(tīng)請(qǐng)求。當(dāng)數(shù)據(jù)進(jìn)行傳輸時(shí)，服務(wù)器從接收到的數(shù)據(jù)報(bào)中得到客戶端的接收數(shù)據(jù)的端口，然后將數(shù)據(jù)報(bào)發(fā)送到這個(gè)端口，客戶端則監(jiān)聽(tīng)這個(gè)端口而得到服務(wù)器端發(fā)送過(guò)來(lái)的數(shù)據(jù)報(bào)并顯示其內(nèi)容。運(yùn)行時(shí)要先運(yùn)行服務(wù)器端程序，再運(yùn)行客戶端程序。

5 小結(jié)

Socket在網(wǎng)絡(luò)編程方面發(fā)揮著很大的作用。UDP是可靠性無(wú)法得到保障的協(xié)議，但對(duì)于質(zhì)量要求不是很高的網(wǎng)絡(luò)應(yīng)用程序，UDP是一個(gè)很好的選擇。

參考文獻(xiàn)：

[1] 張桂珠.Java面向?qū)ο蟪绦蛟O(shè)計(jì)[M].北京:郵電出版社,2006.

[2] 周坤,傅德勝.基于Windows Socket的網(wǎng)絡(luò)數(shù)據(jù)傳輸及其安全[J].計(jì)算機(jī)工程與設(shè)計(jì),2007,28(22):5381-5386.