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

篇1

關鍵詞：tcp/IP協議網絡接口層網絡層傳輸層端口應用層

中圖分類號：TP311.52 文獻標識碼：A 文章編號：1007-9416（2012）03-0000-00

因特網是當今世界上最大的信息網絡，自80年代以來，它的應用已從軍事、科研與學術領域進入商業、傳播和娛樂等領域，并于90年代成為發展最快的傳播媒介。信息傳輸和網絡互連是根據協議進行的，而因特網使用的就是TCP/IP協議。TCP/IP協議是因特網最基本的協議，是因特網的基礎。TCP/IP的全稱是Transmission Control Protocol/Internet Protocol的簡寫，中文譯為傳輸控制協議/因特網互聯協議。

1969年，因特網的前身阿帕網（ARPAnet），誕生之初僅連接了4臺計算機，供科學家們進行計算機聯網實驗用。到70年代，ARPAnet已經有了好幾十個計算機網絡，但是每個網絡只能在網絡內部的計算機之間互聯通信，不同計算機網絡之間仍然不能互通。卡恩于1973 年提出開放的網絡結構的思想。所謂開放的網絡結構，指的是任何類型的網絡都可以通過“網絡互聯結構”與其他網絡連接，這是因特網的核心技術思想。為了適應開放的網絡結構環境的需要，瑟夫與卡恩共同開發了TCP/IP協議，并于1974年正式提出。TCP／IP是實現不同網絡互聯的標準，成功地解決了不同硬件平臺、不同網絡產品和不同操作系統之間的兼容性問題。

TCP/IP協議定義了電子設備如何連入因特網，以及數據如何在它們之間傳輸的標準，它是因特網事實上的國際標準。協議采用了4層的層級結構，層次由低到高依次為：網絡接口層、網絡層、傳輸層、應用層。每一層都調用它的下一層所提供的服務來完成自己的需求。

1、網絡接口層

網絡接口層（通信子網）是數據包從一個設備的網絡層傳輸到另外一個設備的網絡層的方法。由于ARPNET的設計者注重的是網絡互聯，允許網絡接口層采用已有的或是將來有的各種協議，所以這個層次中沒有提供專門的協議，因此網絡接口層實際上并不是因特網協議組中的一部分。實際上，TCP/IP協議可以通過網絡接口層連接到任何網絡上，例如X.25交換網或IEEE802局域網。[1]

2、網絡層

網絡層可以接收由網絡接口層發來的數據包，并把該數據包發送到傳輸層；也可以把從傳輸層接收來的數據包傳送到網絡接口層。網絡層的數據包是不可靠的，因為網絡層并沒有做任何事情來確認數據包是按順序發送的或者沒有被破壞。數據包中含有發送它的主機的地址（源IP地址）和接收它的主機的地址（目IP的地址）。

網絡層的協議包括IP協議、ICMP協議、ARP協議、RARP協議等，其中IP協議是網絡層的核心協議，完成數據從從源網絡傳輸到目的網絡的基本任務。IP協議定義了數據包在網際傳送時的格式，目前使用最多的是IPv4版本，這一版本中用32位定義IP地址，可供使用的地址數超過37.2億，但是仍然不能滿足現今全球網絡飛速發展的需求，因此IPv6版本應運而生。在IPv6版本中，IP地址共有128位，這樣的IP地址數是原IP地址數的296倍，目前來看，IPV6的IP地址是不可能用完的。[2]

3、傳輸層

傳輸層提供應用進程間的通信。兩個系統之間的應用進程的通信，是用每個信息中的如下四項進行確認的：源IP地址、目的IP地址、源端口號、目的端口號。其中源IP地址和目的IP地址已在網絡層的介紹中說明。TCP/IP的端口號是一個軟件結構，用來標識本地計算機應用層中各個進程在和運輸層交互時的接口。在因特網不同的計算機中，相同的端口號是沒有關聯的。一個端口號對應一個16比特的數。服務進程通常使用一個固定的端口，例如，SMTP使用25、HTTP使用80。客戶進程通常使用系統分配的一個隨機端口號。[2]

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

4、應用層

應用層是大多數與網絡相關的程序為了通過網絡與其他程序通信所使用的層。數據從與網絡相關的程序以這種應用程序使用的格式編碼成標準協議的格式并進行傳送。來自應用程序的數據一旦被編碼成一個標準的應用層協議，它將被傳送到TCP/IP協議的下一層。

應用層一般提供面向用戶的服務，如HTTP、FTP、SMTP、POP3。HTTP是超文本傳輸協議，用于瀏覽網頁，FTP是文件傳輸協議，一般用于下載和上傳文件。SMTP是簡單郵件傳輸協議，用來控制信件的發送、中轉。POP3是郵局協議第3版本，用于接收郵件。

TCP/IP有一個非常重要的特點，就是開放性，即TCP/IP的規范和Internet的技術都是公開的。目的就是使任何廠家生產的計算機都能相互通信，使Internet成為一個開放的系統。這正是后來Internet得到飛速發展的重要原因。

參考文獻

[1]萬雅靜,黃巍,梁玉鳳.網絡基礎實用教程[C].北京:機械工業出版社,2011:14-16.

篇2

關鍵詞：TCP/IP；網絡擁塞；擁塞控制；算法

中圖分類號：TP393 文獻標識碼：A 文章編號：1009-3044（2013）07-1513-03

隨著網絡用戶的不斷增加，制約網絡應用和發展的關鍵瓶頸是網絡擁塞問題，對進入網絡的數據流量進行控制是擁塞控制的主要目的，通過控制擁塞保證用戶發送的數據流對通信網絡不造成阻塞，并且瓶頸資源能夠被合理的使用。可以在網絡協議的不同層次上實施擁塞控制，首先對網絡擁塞產生的原因進行分析，分類、歸納擁塞控制，持續時間越長的擁塞需要越高的控制層次來解決擁塞問題，并且擁塞控制的實現主要在傳輸層和網絡層。

1 網絡擁塞概述

網絡的性能會逐漸下降，當過多的數據包存在于網絡中時，這種現象被稱為網絡擁塞。吞吐量下降在發生網絡擁塞的時候，并且嚴重的時候擁塞崩潰的現象會在發生。通常而言，增加的網絡負載導致網絡效率降低，在此時容易發生擁塞崩潰的現象。擁塞現象的描述如圖1 。

圖1 擁塞現象的描述

在較小的網絡負載時，吞吐量隨著負載的增長也會增長，兩者為線性關系，相應的時間也緩慢增長。當網絡容量被負載達到的時候，相應的時間急劇增加，吞吐量呈現緩慢增長，這一點被成為Knee點。吞吐量在負載超過一定量時開始急劇下降，路由器在負載繼續增加的情況下開始丟包，這一點是死鎖點。在擁塞控制機制中有擁塞控制和擁塞避免兩種方式，前者的目的是在控制運行在死鎖點附近的網絡擁塞現象，后者是避免網絡運行在Knee點的時候發證擁塞現象。前者是一種恢復措施，使網絡從擁塞中恢復過來，進入正常運行狀態；后者是一種預防措施，使網絡維持在低延遲、高吞吐量狀態，網絡擁塞現象得以避免。

2 分析網絡擁塞產生的原因

網絡的處理能力和資源容量被網絡的負載超出了是網絡擁塞產生的根本原因，也就是網絡對資源的總需求量大于總的可用資源，下面分析一下網絡擁塞產生的原因。

1）不足的存儲空間

一個輸出端口需要對各種報文在接收端口的緩沖區域中進行排隊，因為它接受的報文是由多個端口轉發而來的，若滿足使用要求的緩沖空間在輸出端，報文就會丟失，尤其是突發的數據流也會丟失。這一矛盾的緩解通過增加存儲空間來實現。但將會出現更加嚴重的擁塞現象在不斷增加存儲容量時。因為緩沖區網絡結點的延時增加的時候，報文也會增加，最終端到端的確認時間也增加了，就會產生超時重發。網絡負載因此會進一步增加，擁塞現象最終會加重。

2）不足的寬帶容量

在低速鏈路中流通的高速數據流經常會產生擁塞現象，在數據發送率小于信道容量的時候，擁塞現象才會避免。不然在節點的緩沖區域堆集大量的報文就會產生擁塞。

3）速度緩慢的節點處理機

報文被放入其CPU隊列中進行緩存當被路由器對其進行接收的時候，路由器來選擇路由并且把報文轉發到相應的節點。此時路由器的處理速度的快慢是能否出網絡現擁塞的關鍵因素。

總而言之，只有考慮到從以上三方面的因素，來解決擁塞現象，優化整體性能。只考慮一方面內的因素擁塞問題不僅不能夠解決，反而擁塞問題還會更加嚴重。

3 控制擁塞的策略

1）Tahoe和Reno擁塞控制算法

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

最多發一個報文在一個RTT內。其中窗口的大小由w來表示，慢啟動門限值由ssthresh來表示，是慢啟動進入擁塞避免的分界值。

這種算法的基本思想是通過線性增加速率源端對網絡中的空閑容量進行探測，當擁塞被檢測到的時候用指數遞減它的速率，在源端丟包被檢測到的時候確認擁塞。實現擁塞避免和慢啟動的例子如圖圖2 慢啟動和擁塞避免的實現舉例

由上圖可知，每當一個丟包被檢測到的時候，慢啟動門限值被源端設置為當前窗口的一半，對丟失的包重傳，窗口被設置為1，重新進入慢啟動。

2）TCP中擁塞控制的關鍵

TCP協議在Internet上被95%的數據流使用，對發送端的發送速率進行控制是TCP中擁塞控制的關鍵。可以采用控制算法中的乘法減少加法增加（AIMD）的來解決擁塞問題。每個擁塞窗口由發送方維持著，如果沒有發生窗口中的報文丟失，那么目前是良好的網絡狀況，窗口的大小被發送者加大，同時報文的發送速率加大。當窗口內的一個報文被發送方發現丟失的時候，則認為報文的丟失是由網絡擁塞造成的，于是窗口的大小減半，隨之發送速率也減小，擁塞加重的現象得以避免。

3）慢啟動階段的擁塞控制

一個連接被TCP啟動的時候多個數據包被發送到網絡時會造成不必要的網絡擁塞和數據丟失，而慢啟動可以避免這種現象的發生，還能避免吞吐量在AIMD算法中增加引起網速過慢的問題。初始化擁塞窗口cwnd為一個數據包大小在新的TCP連接建立的時候，按照cwnd大小源端進行數據的發送，也就是隨著RTT的增長cwnd呈指數增長。

4）擁塞避免階段

處理丟失數據包的方法被稱為擁塞避免算法。當重復確認被發送方收到或數據包超時被發送方發現的時候，網絡擁塞就會發生，此時進入擁塞避免階段，置為1的cwnd在數據包發送超時并且重復確認被發送方收到時，那么每收到一個ACK，cwnd將增加segsize*segsize/cwnd。其中數據包的大小被稱為segsize，cwnd在擁塞避免階段不是呈指數增長而是呈線性增長的。

5）快速恢復和快速重傳階段

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

6）IP 擁塞控制策略

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

總而言之，無論哪種擁塞控制方法都有它的優勢，總體上包括TCP 擁塞控制和IP 擁塞控制兩種，下面表格針對這兩種方式進行了比較：

[TCP 與IP 擁塞控制的比較＼&參數＼&TCP 擁塞控制＼&IP 擁塞控制＼&實現位置＼&端系統中＼&網絡內部＼&短期擁塞＼&可以處理＼&較好處理＼&長期擁塞＼&可以處理＼&無法處理＼&不同數據流間的公平性＼&難于實現＼&可以實現＼&延遲＼&較大＼&無＼&]

4 結束語

通過上述網絡擁塞概述、網絡擁塞產生的原因、控制擁塞的策略，可以得知，隨著互聯網用戶越來越多，網絡寬帶等資源也在持續增加，但是用戶的需求仍然不能得到滿足，逐漸暴漏出網絡擁塞問題，擁塞如何更好的預防和控制，使網絡具有同時到達資源并且低延時和低丟包率的最大效用。無論TCP擁塞控制還是IP 擁塞控制都有自身的優勢，要想在這個基礎上更好的解決網絡擁塞問題，需要結合各種方法并且靈活的使用。

參考文獻：

[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] 黃衛平.TCP/IP 協議中擁塞控制算法探討[J].廣西工學院學報，2003，14（2）：71-73.

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

[4] 武航星，慕德俊，潘文平.網絡擁塞算法綜述[J].計算機科學，2007，34（2）：51-54.

篇3

【關鍵詞】 嵌入式 TCP/IP協議 以太網

一、引言

嵌入式網絡通信在各個方面都得到了非常廣泛的運用。目前最常見的就是總線和USB數據傳輸方式，傳輸速度即使可以達到較快的水平，但是其并不能夠滿足長距離的數據傳輸。因此，以太網能夠彌補其在數據傳輸方面的缺陷。以太網能夠實現一百米距離點對點的數據傳輸，如果要實現更加遠距離的數據傳輸，則需要使用路由器或者交換機來完成。此文基于對CP2200嵌入式TCP/IP協議進行探究，并實現以太網嵌入式系統設計。

二、嵌入式TCP/IP協議的探究與實現

TCP/IP協議棧從上到下分別是由應用層、運輸層、網絡層和網絡接口層所組成的四層結構，每一層各司其職，都有著不同的網絡協議。依據軟件實際使用的情況，在嵌入式系統當中為了達到網絡通信的目的，需要對TCP/IP協議族進行裁剪。在對軟件進行初始化的時候，也對單片機同時進行了初始化，其中包括對系統時鐘、定時器、端口和串口進行了初始化。當然還有CP2200進行初始化，其中包括對MAC層和物理層進行初始化，并且中斷使能。

在TCP/IP協議棧當中，運用層包含HTTP協議，運輸層包含TCP協議和UDP協議，網絡層包含ARP協議、IP協議和ICMP協議。以下是嵌入式TCP/IP協議的每個模塊的實現流程：

1、HTTP協議模塊。HTTP協議的發送函數http_send（）即是TCP協議的發送函數和數據信息的結合，但是http_ send（）函數主要是實現設計網頁內容，JPEG的圖片和HTML（超文本標記語言）等信息的使用依靠其函數實現。

2、TCP協議模塊。TCP協議的發送函數tcp_send（）是需要發送一個不包含任何數據的TCP報文，其作用是能夠對字節頭和校驗和進行處理。通過對時間功能的設定，TCP協議的重傳函數tcp_retransmit（）能夠實現對數據最多為兩次重傳的傳輸功能，實現傳輸功能的應用程序是依靠傳送頁數據而實現的，即是HTTP服務程序。TCP協議的保活函數tcp_ inacivity（）是沒半秒運行一次，當連接正在建立的狀態下，保活期滿了的時候并且沒能被再次使用，就會中斷連接。TCP協議的接收函數tcp_rcve（）實現對字節頭和校驗和的運算，進而對HTTP服務程序和其連接狀態等情況進行斷定，最后進行TCP有限的狀態機判斷數據包的程序。

3、UDP協議模塊。UDP協議的發送函數udp_send（）能夠實現對字節頭和校驗和進行處理，其接收函數udp_rcve（）是對所接收的UDP報文進行處理，如果沒有受到UDP報文數據，就需要發送ICMP終點不可到達報文。

4、ARP協議模塊。ARP協議的發送函數arp_send（），在發送請求報文的時候，對于不清楚目的物理地址的，則是廣播報文；在發送應答報文的時候，接收的一方的目的物理地址需要添加物理地址。ARP協議的重傳函數arp_retransmit（）能夠實現當其發出ARP請求之后的半秒時間內沒有任何響應，則進行再一次發送的功能，但是當兩次發送沒有得到響應就會對報文進行刪除。ARP協議的緩存更新函數age_ arp_cache（）能夠每一分鐘更新一次。ARP的解析函數arp_ resolve（）能夠對所發送的IP報文目的IP地址進行解析，如果發送IP地址和目的IP地址都不在相同的一個網絡當中，那么此IP地址是網關IP地址，然后在緩存表當中對其進行查找，如果找不到就需要發送ARP請求報文。ARP協議的接收函數arp_rcve（）能夠實現對報文進行接收或者應答，對緩存表需要進行更新和重新定時，如果所接受的報文是應答報文，則需要發送等候地址解析的IP報文，但是所接收到的報文是請求報文 ，則需要發送ARP應答報文。

5、IP協議模塊。IP協議的發送函數ip_send9（）能夠實現對發送IP報文的20字節頭和校驗和進行處理，進而使用網絡接口層進行發送。IP協議接收函數ip_rcve（）能夠根據版本情況和所接收報文的種類轉移到相應的接收函數來處理。

6、ICMP協議模塊。ICMP協議模塊的接收函數icmp_ rcve（）是實現對ping請求的接收進行處理，并且處理ICMP不同種類的報文。其中Ping命令請求信息函數ping_send（）是用來檢測發送接收兩方的接收情況。

三、結言

綜上所述，此文對TCP/IP的網絡結構中的各層協議模塊進行探究，基于網絡控制芯片CP2200的以太網接口和單片機C8051F340，并用編程語言來實現嵌入式以太網通信，同時進一步通過對各個層協議的裁剪，實現嵌入式以太網的數據通信。根據現階段來看，嵌入式網絡通信基本上都是依靠TCP/IP協議來實現的，嵌入式設備和網絡兩者相結合是嵌入式系統今后發展的主要方向。因此，我們要更加深入地對嵌入式TCP/IP協議進行探究以及更深層次的功能實現。

參 考 文 獻

篇4

1網絡隱蔽通道的基本原理

早期對隱蔽通道的定義只局限于操作系統內部，研究的重點也是針對操作系統的安全。隨著網絡技術的快速發展，隱蔽通道已經被應用到網絡技術中。由于網絡協議在設計時存在漏洞，如網絡協議的首部存在冗余字段，而網絡設備對這些字段的限制比較寬松，由此可以通過精心的構造，利用這些字段實現隱蔽通信，就形成了網絡隱蔽通道［5］。因此，廣義地講，網絡隱蔽通道是指各種利用非正常的通信手段在網絡中傳遞信息的通道。圖1為隱蔽通道模型。

2建立網絡隱蔽通道的方法

建立隱蔽通道的方法一般就是利用網絡傳輸協議設計中存在的一些不嚴密的地方來隱藏信息，以躲過網絡安全防護系統和防火墻系統，達到傳輸非法信息的目的［6］。由于防火墻或入侵檢測系統往往只注重對數據部分的檢測，而忽略了對首部息的檢測，因此就可以從以下途徑來建立隱蔽通道：一是利用TCP／IP協議的首部中的一些很少使用或不使用的域來隱藏信息；二是可以利用數據傳輸時數據包頭中的一些必須強制填充的域（如IP數據包頭中的源地址、目的地址和TCP數據包頭中的源端口域、目的端口域、序列號域等）來隱藏信息；此外，還可以利用第三方合法主機中轉建立隱蔽通道，利用Ping命令隱藏信息建立隱蔽通道等方法。

3基于TCP協議首部的隱蔽通道

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

3．2隱蔽通道的構建利用TCP協議首部構建隱蔽傳輸通道，主要就是要在發送端生成包數據包時將隱秘信息嵌入，然后在接收端捕獲含有隱秘信息的數據，并將其解碼出來。由于在數據傳輸過程中使用了第三方受信的Web服務器，隱秘信息是隱藏在向Web服務器發送請求的數據包中，又通過接收方偽造Web服務器向發送方返回應答數據包，同時也將隱秘信息隱藏在返回的應答數據包中。在隱秘信息傳輸過程中沒有形成完整的三次握手，因此不會給正常通信造成影響，也不會引起防火墻的反應。而將隱秘信息嵌入TCP數據包首部的序列號字段和確認序列號字段，這兩個字段長度均為32bit，因而可以隱藏更多信息，同時數據位多，更加難以檢測。

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

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

4基于TCP首部的隱蔽通道系統的實現

實現基于TCP首部的隱蔽通道就是采用第3節中所述的思想和方法，在發送端偽造TCP協議發送包含有隱秘信息數據包，在接收端對接收的數據包中的隱蔽信息進行相應處理。

4．1系統的總體構架系統的功能原理如圖3所示。通過數據包生成技術，客戶端將隱藏信息加密后嵌入TCP協議首部的序列號字段或確認號字段，對可信的第三方Web服務器發起連接請求。服務端則偽造Web服務器向客戶端返回SYN＋ACK數據包。通過數據包捕獲技術，服務端從客戶端發往Web服務器的請求數據包中捕獲隱秘信息并還原。客戶端則從服務端偽造Web服務器的返回數據包中捕獲隱秘信息或指令解析并執行。

4．2系統功能及實現

系統功能模塊系統可分為數據包生成模塊、數據包捕獲模塊、管理與控制模塊和指令解析模塊，如圖4所示。其中，數據包的生成和捕獲模塊利用多線程技術實現，執行時不會造成MFC界面假死。管理與控制模塊負責處理網絡設備的獲取與控制。指令解析模塊對傳遞的信息進行顯示和執行指令。秘密信息經加密后嵌入數據包發往公開信道，接收端在公開信道捕獲數據包并對其進行解密。

5實驗結果及分析

經過實驗，通信功能方面，雙方互發的消息都能正確接收。控制功能方面，能夠通過在客戶端發送命令來實現對服務端的控制。經測試，該系統在WindowsXPSP2和Windows7操作系統中運行良好。實驗結果見表1和表2。實驗結果表明，該系統不僅可以實現信息傳輸和遠程控制的功能，而且能夠成功躲避各種安全防護系統的防范。

6結束語

篇5

關鍵詞：嵌入式系統；TCP/IP協議；應用研究

1. 前言

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

2. 嵌入式系統TCP/IP協議在硬件中的應用

2.1 單片機嵌入互聯網模式選擇

2.1.1 EmWarea其EMIT技術

這種技術采取的是標準互聯網協議并對16位和8位嵌入式的設備管理，該類嵌入模式是使用TCP/IP協議棧和網關在Internet里橋接。選取EMIT技術雖可使用在各類型單片機上，但卻要求系統工程師熟悉相關接口和掌握emNeT協議，有著較大工作量。

2.1.2 PC網卡加上專用網

該類單片機嵌入互聯網模式是采用CANBus、RS485、RS232等專用網絡將小批量單片機均連接起來后，再把專業網絡均連接在同一臺的PC機上面，因其依靠PC機為協議實現機制轉換，所以當多個單片機體系較為分散時，該類專用網絡的布置就顯得很不方便，在PC機里裝上專門協議軟件來轉換機制，又將發開成本增加了。

2.1.3 MCU加上網卡芯片

這類單片機嵌入互聯網模式是用單片機對TCP/IP協議進行加載并據此對以太網網卡進行控制實現數據的傳輸，是采用TCP/IP協議嵌入互聯網。該飯飯么有使用網關或PC機平臺，因此，開發成本降低，只需相關人員深層次了解單片機、網卡的驅動程序和TCP/IP協議。

分析完以上三種單片機嵌入互聯網方案，可知MCU加上網卡芯片為最佳方案，最為經濟模式。

2.2 系統的硬件結構

系統單片機應該采取89C51，而網卡芯片應該采取RTL8019AS。此外，讀取鍵盤其輸入數據與指令應該串行E2PROM采取24C256.89C51在處理操作時，要通過網絡接口的電路和網卡芯片來實現單片機和互聯網接入任務，從而進一步達成電子郵件接收發送功能。

3. 嵌入式系統TCP/IP協議在軟件中的應用

3.1 TCP/IP協議特點

高級系統里雖可支持完整TCP/IP協議，但針對單片機系統卻很難將其做到。根據以上特點，第一，要按照各類系統特點及功能對TCP/IP協議進行特定設計，僅僅需要達到相關協議需求；第二，針對具體實際運用，為避免單片機其內部資源出現不足，在保證所需協議實現基礎功能前提下做好精簡工作。單片機中程序結構通常為硬件中斷和順序執行相結合模式，因此，對于處理TCP/IP協議工作應該將其在主程序順序循環里，使用查詢式來控制網卡芯片，其它中斷任務實行間隙中間隙TCP/IP協議處理，使用時間成本換取系統可靠性。

單片機讀取數據是靠RTL8019AS在網絡上面接受，并從網絡接口的控制程序處將其讀到緩沖區即E2PROM里來檢測協議字段類型，從而去夜店那種協議可用來處理該分組。當格式出現錯誤時就將該分組丟棄。

3.2 TCP/IP協議的實現

實現軟件采取51系列的單片機C語言開發的平臺偉福6000，同時用COMP51編譯器，下面具體就協議實現進行分析：

3.2.1 APR協議

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

3.2.2 IP協議

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

3.2.3 ICMP協議

IP協議因無法提供鏈接服務，所以錯誤信息和報文無法傳送給最初主體，針對此情況，對系統里接收ICMP包校驗且無誤后，且CODE域和TYPE來替代echo請求后，還需發送echo來應答，從而實現網絡其診斷功能。

3.2.4 TCP協議

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

3.2.5 SMIP協議

SMIP協議只需依賴一個可靠規則數據的流通道，而不需依賴特定傳輸子系統。SMIP主要為面向基于命令、文字的協議，設計系統時該部分協議主要靠兩進程構成：（1）處理底層郵件，提取信頭其各字段的信息，并按照數據編碼性質來處理數據，讓其以用戶能夠接受刑事傳輸為圖形用戶的界面；（2）發送郵件，通過DATA、TO、RCPT、MAILFROM、HELO一系列接受方會話和指令，由25號能夠采取電子郵件的傳輸TCP其保留端口來進行郵件的傳輸工作。

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

參考文獻：

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

作者簡介：

篇6

【關鍵詞】網絡設備；TCP/IP協議；TELNET協議；工作腳本

一、背景

隨著各電信運營商全業務市場運營的開展，電信企業內部的競爭日趨激烈，在電信企業如火如荼的競爭過程中，企業內部的人力、成本等資源都集中到了市場營銷、客戶服務與維系等窗口中，作為后臺網絡、設備維護人員，如何使用有限的人力資源和維護成本，來保障設備更穩定、更高效的運行成了各電信企業運維管理、系統支撐部門必須考慮的問題。

二、問題分析

電信企業內部接入網絡的設備主要由應用服務器、生產終端設備和內部局域網的組建、管理、支撐設備組成。在日常的維護過程中，我們發現這些設備存在以下特性：

1）設備的多樣性。上述設備中有網絡交換機、路由器、小型機、工控機等，涉及操作系統有HP UNIX、SCO UNIX、LINUX、SUN SOLARIS等多種。

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

3）地理位置的分散性。由于上述設備主要為各級分公司的系統提供服務，由于各級分公司、營業部位置的相對分散，就決定了此類設備在地理位置上的分散性。

設備多樣、數量龐大、位置分散的特性就造成了此類設備管理的復雜性，那么，如何對上述設備進行有效的維護和管理呢？本文結合德州的實踐經驗，基于TCP/IP協議族，提出了電信企業內部設備智能化管理系統設計方法。

三、技術介紹

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

TCP協議、TELNET協議是各類設備或其操作系統上普遍支持的兩種網絡協議，基于上述兩種協議，通過編程可以實現對各種網絡設備自動控制、數據采集，來為我們的維護工作提供便利。

四、系統結構

應用服務器通過C語言編寫程序通過TCP協議、TELNET協議與各網絡設備建立連接通道，通過兩種方式與設備之間進行交互。一種方式是定時解析通過既定的數據采集腳本向各網絡設備發送數據采集命令，由結果分析程序將命令返回的結果進行分析，寫入數據庫。第二種方式，終端用戶通過主動向應用服務器發起查詢、操作命令請求，由應用服務器將操作命令對一臺或多臺設備進行命令處理，并將處理結果返回。

在整個處理過程中，應用服務器扮演了兩種角色，一方面與各網絡設備建立雙向命令處理通道，一方面通過網頁來接受終端用戶的查詢、操作命令請求。

五、系統實現關鍵技術難點分析

在智能化網絡設備管理系統的實現過程中，我針對系統實現過程的兩個重點、難點問題，來介紹系統的設計方案。

1、TCP、TELNET協議接口設計

在使用TCP、TELNET協議與各網絡設備連接過程中，在兩個過程中下可能會出較長的時間延遲。

（1）在使用SOCKET、CONNECT函數與網絡設備建立連接的過程中，如果遠程設備掉電，或出現局部的網絡中斷，這部分設備在整個局域網中將變為不可見狀態。而無論是TCP協議還是TELNENT協議，在面向連接的協議，如果CONNET函數在建立連接的過程中阻塞，會進行多次重試，直到重試次數超過操作系統設置最大超時次數位置，這個過程一般會持續3分鐘左右的時間。（2）在CONNECT連接建立后，與SOCKET套接字進行命令發送的過程中，如果服務器對命令返回的結果未正確識別出有效的命令結束符號，或由于網絡設備自身硬件故障的原因造成命令處理過程放緩、或不執行，從而無法獲得正確的返回結果，造成長時間存在一個無效連接，這實際也是一種阻塞狀態。

上述兩種狀態如果在程序編寫的過程中，如果不增加超時處理，將大大放緩命令的執行效率，造成終端用戶對系統的認同度下降。因此，在上述兩種過程中，我們首先需要兩種基本數據局域網內部的正常時間延遲、網絡設備的回顯延時。

（1）局域網內部的正常通信延時的計算過程中，可要選取各IP網段的最大網絡延時作為參考。（2）網絡設備的回顯延時，由于網絡設備的生產廠家、設備型號、硬件配置、軟件配置、發送命令的不同，回顯時間延時也會不同，這種情況下，對于同廠家、同型號設備，選取一個日常維護操作處理時間最長的操作時間作為參考。

通過上述兩種時間的界定，使用SELECT函數來設置超時時間，在超時時間到達前如果沒有收到正確的命令返回結果描述符，則產生一個中斷信號，來打破阻塞狀態。

2、各網絡設備采集命令管理問題

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

六、技術總結

在電信企業網絡設備智能化管理實現過程中，通過TCP/IP協議族協議的靈活使用，成功地解決了對多種數量龐大、位置離散的網絡設備的管理難題，實現各網絡設備數據的采集、入庫、顯示，以及管理人員與網絡設備的雙向交互。通過在德州聯通內部的建設和使用，實踐表明此系統可以在網絡設備維護、監控、操作方面，有效地縮短人工處理時間，此系統的實現方案對于各電信企業具有較強的借鑒意義。

參考文獻

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

篇7

關鍵詞：檔案庫系統；Modbus/TCP；自動識別；COM

中圖分類號：TP31

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

本文針對以上問題，提出了自動檔案庫系統的解決方案。自動檔案庫由多層檔案柜、通信模塊和計算機控制系統等組成，能夠實現檔案的自動借閱和歸還，是綜合了信息自動化、存儲和自動識別技術于一身的立體集成化系統。設計該系統的目標是為了減少檔案管理人員的工作量，對檔案管理的業務流程進行調整和優化，進而規范檔案業務操作，提升檔案管理的自動化水平，大大提高工作效率。

1 系統總體設計

本文所設計的控制系統分為三層：應用管理層、檔案柜管理層和檔案柜控制層。應用管理層與檔案柜管理層通過TCP協議進行通信，檔案柜管理層與檔案柜控制層通過Modbus/TCP進行通信，如圖1所示。

應用管理層為檔案管理系統，它構件了完整的檔案資源信息共享服務平臺，支持檔案管理全過程的信息化處理，主要包括以下功能：檔案接收、檔案移交、檔案查詢、檔案統計、檔案借閱、檔案歸還、檔案數據維護、檔案借閱記錄管理、檔案發送記錄管理、報表打印輸出、數據庫管理等。

檔案柜管理層對檔案柜控制層的集中管理，包括兩個方面的內容：把應用管理層發來的指令轉化為對檔案柜控制層的指令，定時讀取檔案柜控制層的消息，并轉為系統事件通知應用管理層進行相應。

檔案柜控制層根據檔案柜管理的指令，控制檔案柜的走層、檔案的存取、檔案盤庫等操作，實時根據傳感器改變狀態寄存器的內容。

圖1 系統總體框架圖

2 基于Modbus/TCP的傳輸控制協議

Modbus是一種應用層報文傳輸協議，用于實現不同類型的網絡連接的設備之間的客戶機服務器之間的通信。Modbus/TCP協議一種的開放的通信協議，用戶可以根據需要靈活進行擴展。[1]它支持C/S模式，將應用層的Modbus消息封裝成IP包在網絡上傳輸。[2]

Modbus/TCP是采用C/S模式來進行報文傳輸，此模式基于4種類型報文，即請求（Modbus Request）、指示（Modbus Confirmation）、響應（Modbus Indication）和證實（Modbus Response），如圖2所示。請求是客戶端發送給服務器用來啟動報文，指示是服務端接收的請求報文對客戶端的反饋，響應是服務器針對客戶端的請求發送的具體響應，證實是在客戶端接收的響應信息時給服務器的反饋。[3]

圖2 Modbus/TCP報文傳輸

協議檔案柜管理層由運行在PC機上檔案柜管理程序構成，檔案柜控制層由觸摸屏（TPC）和控制電機和傳感器的可編程邏輯器件（PLC）構成。協議檔案柜管理層通過網絡的Modbus/TCP協議，對各個觸摸屏（TPC）和可編程邏輯器件PLC的位變量、整型變量等的讀寫實現對檔案柜的遠程測控，如圖3所示。

圖3 協議檔案柜管理層構成圖

3 檔案自動識別

目前成熟的檔案識別方法有條碼識別法[4]、RF識別法[5]。條碼識別法是在把打印好的條形碼粘貼到檔案盒上，把條形碼作為識別檔案的唯一標示；RF識別法則是通過粘貼在檔案盒上的電子標簽來識別檔案的。兩種識別方法特點不一，接下來對這兩種方法進行具體討論。

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

射頻識別系統由電子標簽和閱讀器兩部分組成。在檔案識別系統中通常的做法是把閱讀器安裝在檔案柜中，把電子標簽粘貼到檔案盒上。電子標簽中保存的數據通過特定的編碼存儲在電子標簽中，閱讀器可以非接觸的讀取電子數據。系統工作過程分為能力供給和信號識別兩個部分。其中能力供給指的是電子標簽對電子標簽閱讀器發出的微波查詢信號進行轉換，把微波信號轉換為電流；信號識別指的是微波查詢信號經過電子標簽內部的電路處理之后，攜帶了電子標簽內部存儲的數據信息，利用電子標簽自帶的微型天線返回到閱讀器中。經過能力供給和信號識別兩個過程，閱讀器就可以拿到電子標簽存儲的數據信息，實現檔案識別。以下針對條碼識別法、RF識別法分別比較兩者優缺點，如表1所示。

表1 條碼識別法、RF識別法優缺點比較

條碼識別法 RF識別法

掃描速度 掃描槍一次只能掃描一個條碼 RFID閱讀器可同時辨識讀取多個RFID標簽

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

穿透性和無屏障閱讀 在沒有阻擋和近距離的情況下，條碼才能被識別 RFID通信具有一定的穿透性，除金屬材質外一般材質都能穿透

成本 條碼和條碼掃描槍成本很低 RFID標簽和RFID閱讀器成本較高

針對條碼識別法、RF識別法的特點，各單位可以根據需求選用不同的方案。條碼識別法和RF識別法在系統中識別和傳輸過程中，由于條碼被污染和斜放等情況，RF識別法信道中有噪聲干擾和標示有重疊的情況，引起數字信號波形的失真導致錯誤，針對錯碼的問題，通過兩種策略來處理。一種方法是在檔案標識上設置冗余的信息位，在一定錯誤率的情況下可以通過算法推算出錯誤的信息，常用算法有循環冗余CRC校驗；另外一種是設置校驗位，通過校驗位來驗證發送的信息，驗證不通過的情況下讓接收方請求重傳，常用算法有奇偶校驗、漢明校驗。因為檔案柜在掃描槍掃描過程中一般都是一次掃描，所以我們一般采用糾錯碼的策略來解決誤碼的問題。

5 檔案自動盤庫

為了解決人工歸還和借閱檔案時放錯位置的問題，設計檔案自動盤庫功能，通過該功能可以對整個檔案柜的檔案進行批量整理并與檔案信息系統中存放的檔案存放信息進行核對修改。

自動盤庫操作流程如下所示：（1）執行檔案柜走層操作，準確走到確定層；（2）啟動盤庫掃描槍從左到右運動掃描整個層中的檔案，一層掃描完成后，盤庫掃描槍從右到左運動回到起始點再執行走層動作，直到掃描完畢，經過掃描得到的柜號、層號、檔案標識通過Modbus/TCP協議傳給檔案柜控制層，檔案柜控制層通知應用層程序，對掃描的數據進行處理；（3）檔案柜向上走一層，繼續流程2，直到完成所有層的掃描，自動盤庫完成。

在進行盤庫操作時，檔案柜控制層把盤庫掃描槍掃描到一個檔案標識就會將柜號、層號、檔案標識發送給檔案柜管理層，檔案柜管理層觸發應用層程序的事件，應用程序處理相應事件顯示差異信息，用戶根據差異信息選擇進行更新檔案存取信息和借閱情況。

5 檔案管理層接口規范

不同廠商采用的硬件類型一般是不同的，同一廠商的不同型號的設備通常也有所區別，傳統的檔案管理軟件基本都是針對某一款特定的檔案柜設計的，所以不具有通用性。硬件上一些小改動或升級就會導致整個應用程序的大范圍改動甚至重寫。傳統的檔案管理程序與設備是一一對應的，每一種設備都需要開發專用的管理程序和相應驅動。傳統檔案管理層的開發示意圖如圖4所示。

圖4 傳統檔案管理層的開發示意圖

在實際的大型檔案管理系統中，檔案柜類型往往不止一種，同種類型的檔案柜每隔一段時間也會進行硬件升級，在這種情況下，檔案管理層的接口如果仍然按照傳統的結構進行設計，必然會帶來很多問題，在很大程度上增加系統開發和維護的成本。在本文的檔案柜系統設計中，檔案柜管理層為了實現與底層硬件設備的無關性，需要硬件設備已經統一的基于COM組件，不同硬件設備指需要按照統一COM編寫自己組件，就可以實現協議檔案柜管理層對檔案柜控制層的操作，如圖5所示。

圖5 基于COM組件的檔案層接口規范

6 結束語

通過對自動檔案庫系統合理設計，將系統分為應用管理層、檔案柜管理層和檔案柜控制層。應用管理層與檔案柜管理層通過TCP/IP協議進行通信，檔案柜管理層與檔案柜控制層通過Modbus/TCP協議進行通信，針對人工歸還和借閱檔案時放錯位置的問題，專門設計檔案自動盤庫功能，同時為了實現檔案柜管理層與底層硬件設備的無關性，制定了檔案管理層接口規范。實際使用表明：基于Modbus/TCP協議自動檔案庫系統可以方便快捷的實現電子檔案系統與紙載檔案管理的無縫結合，在大幅度提高檔案的管理效率和檔案管理自動化水平的同時，降低了檔案管理費用和檔案管理人員的工作量，充分提高工作效率。

參考文獻：

[1]喬永衛，程帥.基于Modbus協議的自動控制系統的通信研究[J].自動化與儀表，2012（08）：34-37.

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

[3]翁建年，張浩，彭道剛.基于嵌入式ARM的Modbus_TCP協議的研究與實現[J].計算機應用與軟件，2009（10）：36-39.

[4]張應福.物聯網技術與應用[J].通信與信息技術，2010（01）：50-54.

[5]杜曉明，葛世倫.基于RFID和條形碼的中小企業倉庫管理系統研究[J].組合機床與自動化加工技術，2010（02）：106-110.

[6]郎為民.射頻識別（RFID）技術原理與應用[M].北京：機械工業出版社，2006.

[7]康東，石喜勤，李勇鵬.射頻識別RFID核心技術與典型應用開發案例[M].北京：人民郵電出版社，2008.

[8]Don 本質論[M].潘愛民，譯.北京：中國電力出版社，2001.

[9]（美）WilliamA.Shay.高傳善等譯.數據通信與網絡教程[M].北京：機械工業出版社，2005.

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

[11]柴先明，黃知濤.信道編碼盲識別問題研究[J].通信對抗，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以太網技術的靜電除塵器的研究[D].碩博學位論文，2009.

篇8

關鍵詞：風電場；遠程監控；SCADA；Modbus/TCP；PLC

中圖分類號：TP277 文獻標識碼：A 文章編號：1674-7712 （2014） 02-0000-01

對風力發電機組進行遠程監視控制十分必要，而風電廠遠程監控系統的軟件則是重中之重，它直接決定了整個系統的穩定性和效率。

Modbus/TCP協議目前應用廣泛，絕大多數廠商的PLC都支持Modbus/TCP協議，其具有良好的通用性，因此基于Modbus/TCP協議開發客戶端程序已成為風電遠程監控系統一種行之有效的方法。

一、Modbus/TCP協議

Modbus/TCP協議以一種非常簡單的方式將Modbus幀嵌入到TCP幀中，使其成為工業以太網應用層協議，Modbus協議層在TCP之上，其主要完成的任務為：在服務器端，負責解譯來自客戶端的Modbus幀，執行相應的請求[1]。

Modbus TCP協議的幀格式如表1所示。應用協議報頭分為4個部分，數據標識符用來標識Modbus幀的次序，每多發送一個Modbus幀，該值加1；協議標識符用來確認是不是Modbus協議，如果是Modbus協議用1表示，其他協議用0表示；接下來2個字節用來表示后續字節數，即從單元標識符開始一直到數據域結束的字節數，單元標識符用來標識Modbus串行線上的某個設備單元，由于風機都是網絡結構，所以這一字節并沒有實際意義，填0x0或0xFF即可。功能碼的含義如表2所示。數據域則添加要發送的數據，如果是向PLC發送讀請求的話，數據域為要讀取的寄存器起始地址和要讀取的寄存器個數，如果是向PLC發送寫請求，則數據域為要寫入的寄存器起始地址和要寫入的寄存器個數、需要寫入的字節數以及需要寫入的數據。

一、運用C#編程實現通訊

C#是微軟公司設計的一種編程語言，是從C和C++派生來的一種簡單、現代、面向對象和類型安全的編程語言，并且能夠與.NET框架完美結合[2]。

為了簡化網絡編程復雜度，.NET對套接字又進行了封裝，封裝后的類就是.Sockets命名空間下的TcpListener類和TcpClient類。但是要注意，TcpListener和TcpClient只支持標準協議編程。如果希望編寫非標準協議的程序，只能使用套接字來實現[3]。

核心代碼

值得一提的是，由于PLC與計算機的數據存儲方式可能不同，因此需要進行大小端判斷及轉換，轉換可以采用Reverse（）方法。軟件界面的設計如圖2所示，通過該界面可以實現對風機進行啟停控制，功率調節，數據采集，繪制圖表，查看故障等功能，可滿足風電場遠程監控系統的絕大部分需求。

三、結束語

實踐表明，該軟件通過Modbus TCP協議與風力發電機組實現了數據交互，可通過上位機對機組進行啟動、停機、復位、限定功率等控制，查看機組各傳感器反饋數據，查看故障代碼，運行穩定，操作簡單，具有實際價值。

參考文獻：

[1]郝曉弘，祖守圓，徐維濤.基于VC的Modbus/TCP協議模型通信測試軟件的實現[J].微計算機信息，2006.

篇9

關鍵詞：會話初始化協議SIP；TCPN；建模；模型

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2016）25-0035-02

1 引言

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

目前研究SIP協議主要涉及以下幾方面：基于SIP的應用于服務[3]；SIP測試工具和方法；其他協議與SIP協同工作。因時間著色Petri網TCPN[2]在描述帶有較復雜的交互動作和時間約束的系統過程中具有明顯的優勢，故本文以TCPN為模型分析工具進行SIP協議分層TCPN模型的構造，并在不同狀態下實現分層建模。

2 SIP協議事務處理

SIP協議通過事務進行會話控制，其主要事務有INVITE、non_INVITE事務。INVITE事務完成會話的創建，non_INVITE事務則完成會話的保持與關閉。SIP端系統（User Agent，UA）是連接服務器從而發送服務請求的一種應用程序。因UA向服務器發送服務請求并接收來自服務器的響應，故一個UA有UAS（用戶服務器）和UAC（用戶客戶端）兩部分，這兩部分就是SIP協議中的兩個最關鍵的參與者，UAC創建呼叫請求，UAS接受呼叫給出響應。

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

3 SIP協議TCPN分層建模

本文應用CPN Tools[4]進行INVITE事務的分層建模，并在不同的抽象層次上描述協議行為細化模型。這種方法在一個層次中描述協議細節，有利于優化或局部完善協議模型，也能有效把握模型規模，便于確認模型與分析協議性質。

SIP協議的TCPN分層模型中的10個模型頁分別處于不同的層次，每頁所描述的是對應抽象級別上的協議功能，低級別頁作為高級別頁的替代變遷子頁。各層次模型頁功能描述如下表1。各層內部模塊細化是依據UAS與UAC在INVITE事務執行過程中具備的不同狀態進行的，因在terminated狀態下協議無行為，而僅表示終止事務，故沒有單獨描述此狀態。

3.1 總體流程建模

SIP協議分層TCPN模型的top page（頂級頁）如下圖1所示，它總體描述了協議運行的網絡拓撲，其中使用了2個替代變遷對NET、UAS和UAC在協議運行過程中的交互行為進行描述。UAC通過NET向UAS發送REQUEST型數據，UAS將RESPONSES型數據通過NET回傳給UAC。

Client頁用以描述UAC的行為，下圖2所示為其頁模型。圖中的3個替代變遷對應的子頁能夠更加細致地描述處于不同狀態的UAC端行為。庫所Scene用以描述UAC的行為，變遷TransErr可以模擬協議在不同條件下出現傳輸層錯誤時所采取的處理方式。

3.2 網絡層建模

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

通過上述時間類型、弧表達式及防衛表達式的應用，可模擬存在重復數據包、延遲、丟包的不可靠鏈路。若對其某些參數做適當的修改，便可動態調整其鏈路的可靠性，以此來真實地模擬不可靠鏈路。

3.3 具體行為建模

本文表1中的Sproceeding、Ccalling、Cproceeding等底層模型頁描述UAS和UAC在不同狀態下處理事件的過程，也就是對協議的具體行為建模。下文以UAC端處于Ccalling狀態時的應答消息處理行為為例，闡述具體行為的模型描述方式。

下圖4所示為UAC處于Ccalling狀態時處理INVITE消息的模型，即Ccalling頁模型。圖中CallTimer表示UAC處于超時狀態時消息的處理過程，CallResp表示UAC收到UAS應答時對消息的處理過程。庫所TimerAorB用以控制A與B兩個定時器的觸發。融合庫所cloneCs用隊列存放UAC每次狀態的變化，其隊首為UAC的當前狀態，Scenec記錄UAC的當前狀態和導致UAC變為此狀態的事件。Message存放初始條件下從SIP協議上層收到的INVITE請求。Channel_Em用以記錄當前是否收到UAS的應答，其初值為0。

當收到UAS會送的響應消息時，變遷CallResp被點火執行，即運行其對應的函數代碼。此函數代碼中sta與st均為SCENEC型變量，st是處理消息前UAC的狀態，sta為處理消息后UAC的狀態。Action部分調用函數call_resp（st，resp）完成UAC對不同類型響應消息的處理，該函數代碼如下：

由上述代碼可知，處理類型為r2xx的應答消息后UAC處于TERM狀態，處理類型為r3xx的應答消息后處于COMP狀態，處理類型為r1xx的應答消息后處于PROC狀態。

4 總結

本文給出了SIP協議處理INVITE事務的TCPN分層模型，對該協議總體流程、網絡層、UAS與UAC間的具體行為在不同模型層次上分別進行建模。該層次模型規模可控、功能劃分直觀、數據結構完備，為建模后期協議的驗證與改進提供了較完善的模型基礎。

參考文獻：

[1] 姜秀玉，楊峰，崔再惠.SIP協議實現中消息解析的研究[J].計算機工程與設計，2010（7）.

[2] 何中陽，李鷗，楊白薇，等.基于TCPN的TCP協議形式化描述[J].計算機工程，2011（9）.

篇10

關鍵詞：UDP協議；Socket；網絡通信

中圖分類號：TP393文獻標識碼：A文章編號：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適用于網絡環境中的進程間通信，它已成為當前許多操作系統的網絡API，也是網絡操作系統中必不可少的基礎功能。隨著Linux操作系統和Internet的不斷發展，Linux網絡環境下尤其是基于UDP的socket通信技術仍廣為注目。文章介紹了socket的編程原理，并通過一個Java編寫的客戶/服務器程序，描述了網絡中基于UDP的不同主機上的兩個進程之間的socket通信機制。

1 Socket通信機制

Socket（套接字）機制是一種API，是網絡應用程序的編程接口。Socket是通過標準文件描述符和其它程序通訊的一個方法。每一個套接字都用一個半相關描述：{協議，本地地址、本地端口}來表示；一個完整的套接字則用一個相關描述：{協議，本地地址、本地端口、遠程地址、遠程端口}，每一個套接字都有一個本地的由操作系統分配的唯一的套接字號。

根據傳輸數據類型的不同，Socket主要分為三類：1) 流式Socket（SOCK_STREAM），在這種方式下，兩個通訊的應用程序之間要先建立一種虛擬的連接，提供可靠的、面向連接的通信流，它使用TCP協議，從而保證了數據傳輸的正確性和順序的。2) 數據報Socket（SOCK_DGRAM），它使用數據報協議UDP，定義了一種無連接的服務，數據通過相互獨立的報文進行傳輸，是無序的，并且不保證可靠、無差錯。3) 原始Socket，原始套接字允許對底層協議如IP或ICMP直接訪問，它功能強大但使用較為不便，主要用于一些協議的開發。

2 UDP協議的工作原理

UDP協議是一個面向無連接的協議，其連接的建立不必像TCP那樣需要服務器端偵聽，也不需要有客戶機請求連接，屬于一種“強制”性的網絡連接。UDP提供一對一或一對多的、無連接的數據報服務。該服務對消息中傳輸的數據提供不可靠的、最大努力的傳送，這意味著它不保證數據的到達，也不保證所傳送的數據報的順序是否正確，UDP不重新傳輸丟失的數據。其主要工作是：將應用程序傳輸過來的數據分塊交給網絡層，確認接受到分組信息。

盡管UDP無法像TCP一樣提供可靠的數據傳輸，但UDP并不比TCP缺乏優越性。UDP在傳輸效率方面比TCP要高一些，而且許多應用程序并不需要保證嚴格的傳輸可靠性，比如視頻會議系統等，需要實時的交互，但并不要求音頻視頻的絕對正確。

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

3 UDP套接字的通信過程

中提供了兩個類DatagramSocket和DatagramPacket用來支持數據報通信。DatagramSoc ket用來在程序之間建立傳送數據報的通信連接，是數據報通信中的Socket。在數據報實現C/S通信程序時，無論在客戶端還是服務器端，都要首先建立一個DatagramSocket對象，用來表示數據報通信的端點，應用程序通過Socket接收或發送數據報。

DatagramPacket則用來表示一個數據報，它是傳輸數據的載體，封裝了數據、數據長度、數據報地址等信息。

采用UDP套接字方式實現C/S的通信程序由客戶端和服務器端兩部分組成。服務器進程依次按以下步驟進行：1) 調用Socket()創建一個數據報套接字；2) 調用bind()把服務器地址綁定在該套接字上；3) 調用recvform()等待客戶進程發來的請求，服務器此時處于無限循環狀態；4) 服務進程接收到客戶進程所發來的數據報后，進行處理，調用sendto()將處理結果返回給客戶進程，返回狀態3)，繼續監聽；5)服務進程調用close()撤消套接字，終止服務。

客戶進程則按以下步驟進行：1) 調用Socket()創建一個數據流套接字；2) 調用sendto()向服務器進程發送數據報；3) 調用recvfrom()等待服務器進程返回該處理結果；4) 客戶進程調用close()撤消套接字。

4 數據報通信實例

程序由服務器端和客戶端兩部分組成，服務器端主機中有一個名為“udp_socket.txt”文件，文件中保存了一段英文。服務器端接收一個客戶端的請求，就從文件中讀取若干個英文字符發送給客戶端。當文件中所有內容發送給完畢，服務器端程序將退出。客戶端首先構造一個數據報發送給服務器端，然后等待接受服務器端響應，當接收到服務器端的數據報后，顯示數據并結束通信。

1) 服務器端程序

public class Server_Th

{ boolean m_q=true;

public void serverWork() throea IOException

{DatagramSocket ds=new DatagramSocket(2000)

//創建端口號為2000的數據報套接字

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

while(m_q)

{ byte buf[ ]=new byte[256];//創建緩沖區

DatagramPacket packet=new DatagramPacket (buf, buflength); //創建接收數據報對象

ds.receive(packet);//接收數據報

String dString=null;

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

{in.close();

m_q=false;

dString=”Good Morning!”;}

buf=dString.getBytes();//將數據存儲到buf中

inetAddress address=packet.getAddress();

//得到客戶端IP地址

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

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

//構造要發送數據報

ds.send(packet);//發送數據報

}

ds.close();//關閉

}

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( );

//創建套接字對象

byte buf[ ]=new byte[256];

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

//服務器IP地址

DatagramPacket packet=new DatagramPacket(buf,buf. Length,address,2000);//創建要發送的數據報對象

socket.send(packet);//接收數據報

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

//創建要接收的數據報對象

socket.receive(packet);//接收數據報

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

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

//取得數據報中的數據并顯示

Socket.close();//關閉socket

}}

編寫程序時客戶端和服務器端的DatagramSocket必須用一個端口，因為客戶端向服務器端請求時，服務器需要知道從哪個端口監聽請求。當數據進行傳輸時，服務器從接收到的數據報中得到客戶端的接收數據的端口，然后將數據報發送到這個端口，客戶端則監聽這個端口而得到服務器端發送過來的數據報并顯示其內容。運行時要先運行服務器端程序，再運行客戶端程序。

5 小結

Socket在網絡編程方面發揮著很大的作用。UDP是可靠性無法得到保障的協議，但對于質量要求不是很高的網絡應用程序，UDP是一個很好的選擇。

參考文獻：

[1] 張桂珠.Java面向對象程序設計[M].北京:郵電出版社,2006.

[2] 周坤,傅德勝.基于Windows Socket的網絡數據傳輸及其安全[J].計算機工程與設計,2007,28(22):5381-5386.