本文通過對TCP協(xié)議具體低層實(shí)現(xiàn)過程中各個環(huán)節(jié)對時間消耗的分析，找出了提高系統(tǒng)效率，提高通信速度的方法。實(shí)踐證明這樣的設(shè)計提高了系統(tǒng)的效率，提高數(shù)據(jù)傳輸率，降低了網(wǎng)絡(luò)上傳送冗余分組的數(shù)量，明顯改善了系統(tǒng)性能。特別適用于高速、低數(shù)據(jù)量的采集或測控系統(tǒng)。

0引言

長久以來，串行RS 232和RS 485通信技術(shù)一直是自動化儀器、儀表中常用的通信標(biāo)準(zhǔn)。但近年來，隨著計算機(jī)技術(shù)、網(wǎng)絡(luò)技術(shù)、通信技術(shù)的發(fā)展及其在工業(yè)自動化系統(tǒng)中的應(yīng)用，使得工業(yè)自動化系統(tǒng)和儀器、儀表領(lǐng)域加速了向智能化、數(shù)字化和網(wǎng)絡(luò)化方向發(fā)展的進(jìn)程。出現(xiàn)了電力線通信技術(shù)、無線紅外和藍(lán)牙通信技術(shù)、基于USB接口的通信技術(shù)、現(xiàn)場總線技術(shù)以及嵌入式Internet接入技術(shù)等新技術(shù)。其中基于嵌入式Internet接入技術(shù)的網(wǎng)絡(luò)化儀器是近年提出的全新概念，它是儀器檢測技術(shù)與現(xiàn)代計算機(jī)技術(shù)、網(wǎng)絡(luò)通信技術(shù)、微電子技術(shù)深度融合的產(chǎn)物口。檢測儀器接入Internet，成為執(zhí)行測量和控制任務(wù)的儀器Web站點(diǎn)，這種網(wǎng)絡(luò)化儀器可以像普通儀器那樣按設(shè)定程序?qū)ο嚓P(guān)物理量進(jìn)行自動測控、存儲和顯示等，同時允許已授權(quán)的用戶通過Internet遠(yuǎn)程對儀器進(jìn)行操作、監(jiān)控、故障診斷等。在具體的應(yīng)用中，出現(xiàn)了不少問題，其中之一就是傳輸率和系統(tǒng)利用率不高，本文正是在這種背景下產(chǎn)生的。

1 TCP通信硬件接口

典型的8位機(jī)采用TCP協(xié)議接入Internet的以太網(wǎng)網(wǎng)絡(luò)接口如圖1所示。RTL8019AS以其優(yōu)異的性價比，成為目前單片機(jī)以太網(wǎng)系統(tǒng)的首選以太網(wǎng)接口芯片。該芯片符合IEEE802.3 10Base2和10BaseT標(biāo)準(zhǔn)，具有自動奇偶檢測和糾錯功能，支持全雙工工作模式。如圖1中，RTL8019AS工作于8位跳線模式，數(shù)據(jù)線SD0～SD7與8位單片機(jī)（51系列）的數(shù)據(jù)線（AD0～AD7）相連，地址線A0～A4與8位單片機(jī)的地址線（A0～A4）相連。讀寫信號經(jīng)74S04產(chǎn)生。RTL8019AS的基地址（配合引腳34（AEN））為0x8000H，對應(yīng)RTL8019AS內(nèi)部地址0x300H.RTL8019AS通過網(wǎng)絡(luò)變壓器HR901170A和RJ45接口與以太網(wǎng)相連接入internet，隔離網(wǎng)絡(luò)上的干擾信號。


圖1 RTL8019AS與8位單片機(jī)的接口圖

2單片機(jī)系統(tǒng)中TCP通信問題分析

TCP協(xié)議是TCP/IP協(xié)議簇的核心，也是最復(fù)雜的協(xié)議。但由于其獨(dú)特的自動檢錯和重發(fā)機(jī)制，實(shí)現(xiàn)了數(shù)據(jù)的可靠通信，但也正是由于其復(fù)雜性，在8位機(jī)上實(shí)現(xiàn)TCP協(xié)議通信耗時就比較多，傳輸速率低下。TCP協(xié)議的數(shù)據(jù)通信過程，以客戶機(jī)為例進(jìn)行分析。圖2是典型的采集系統(tǒng)TCP數(shù)據(jù)通信的時間序列圖。在建立連接后，由客戶機(jī)向服務(wù)器發(fā)送數(shù)據(jù)。假設(shè)此時客戶機(jī)的啟始序列號為100，每次固定發(fā)送100字的樣數(shù)據(jù)。服務(wù)器負(fù)責(zé)接受該數(shù)據(jù)，但不下發(fā)任何送數(shù)據(jù)，只確認(rèn)所接收的數(shù)據(jù)，其啟始序列號為50.對于單片機(jī)系統(tǒng)，由于其處理速度和內(nèi)存資源的局限，通常的處理流程如圖3.


圖2 TCL數(shù)據(jù)通信的時間序列


圖3 單片機(jī)系統(tǒng)發(fā)送數(shù)據(jù)流程圖

由于服務(wù)器（一般為裝有windows系統(tǒng)的微機(jī)或工業(yè)計算機(jī)）并不是收到數(shù)據(jù)就直接發(fā)送確認(rèn)，而是繼續(xù)等待接受序列中的其他數(shù)據(jù)。這就會經(jīng)常觸發(fā)服務(wù)器的接受延時的確認(rèn)算法，這將導(dǎo)致剩下的數(shù)據(jù)不能在200 ms內(nèi)發(fā)送。對于高速交互的采樣系統(tǒng)而言，這將產(chǎn)生明顯的時延。Host Requirements RFC申明TCP必須實(shí)現(xiàn)Nagle算法，但必須為用戶提供一種方法來關(guān)閉該算法在某個連接上的執(zhí)行。該算法要求TCP連接上最多只能有一個未被確認(rèn)的未完成的小分組，在該分組的確認(rèn)到達(dá)之前不能發(fā)送其他的小分組。實(shí)際使用Sniffer監(jiān)聽軟件也得到同樣的結(jié)果，在接收到下位機(jī)的數(shù)據(jù)包后，上位機(jī)延時200 ms后，發(fā)送確認(rèn)包，其傳輸速度為10 packet/s，實(shí)際網(wǎng)絡(luò)利用率不足1％。由圖3可見，只要提高服務(wù)器確認(rèn)發(fā)送的速度，就可以提高通信的速度。對于本系統(tǒng)采用33M的主頻（C051F單片機(jī)）發(fā)送一個分組（1 024 B）和接受一個確認(rèn)分組（60 B）總用時為3～3.5 ms，關(guān)閉Nagle算法后，使用Sniffer監(jiān)聽分析數(shù)據(jù)包，系統(tǒng)上位機(jī)在收到數(shù)據(jù)包后，立即發(fā)送確認(rèn)包，期間只有0.3 ms左右的網(wǎng)絡(luò)延時，系統(tǒng)速率提高到設(shè)定的20 ms發(fā)送一次采樣數(shù)據(jù)，即100 packet/s，系統(tǒng)利用率提高為為原來的10倍。

然而對于有些應(yīng)用場合，每次采樣的數(shù)據(jù)量并不大（小于100 B），采用關(guān)閉Nagle算法來提高傳輸率是不理想的，因?yàn)檫@樣增加了網(wǎng)絡(luò)上傳輸?shù)姆纸M的數(shù)量，同時增大了客戶機(jī)（下位機(jī)）處理這些多出來的分組的時間消耗，降低了系統(tǒng)利用率，增大了傳輸出錯率，大幅度的減少了持續(xù)傳輸時間。實(shí)驗(yàn)中，當(dāng)采用高頻單片機(jī)（100M主頻），將數(shù)據(jù)通信速率提高到1 000 packet/s，發(fā)現(xiàn)傳輸錯誤的數(shù)據(jù)包達(dá)到5％，同時傳輸持續(xù)時間由原來的大于48 h不間斷，減少為不足2 h，系統(tǒng)利用率也只有不到2％，同時已無法繼續(xù)提高傳輸速度（由硬件條件限制）。為解決這個問題，同過分析具體TCP通信的各環(huán)節(jié)對時間的消耗過程，尋求在已有的硬件基礎(chǔ)上，通過軟件來解決問題。

首先是數(shù)據(jù)分組打包。這里的耗時與要打包的數(shù)據(jù)量和主頻有關(guān)。為了便于計算，以下都用最簡單的MCS-8051單片機(jī)為例進(jìn)行分析。對于發(fā)送100 B的數(shù)據(jù)，外界晶振為12M的51單片機(jī)，其一個機(jī)器周期為1μs.典型的打包代碼（包括TCP包和IP包）的執(zhí)行總周期約為2 200個機(jī)器周期（具體大小與編寫軟件所使用的語言和編譯器有關(guān)），用時為2.2 ms.

其次是數(shù)據(jù)備份。TCP協(xié)議需要超時重發(fā)，因而備份已發(fā)出而未收到確認(rèn)的數(shù)據(jù)分組是必要的。這里的耗時與數(shù)據(jù)量和主頻以及數(shù)據(jù)本備份的存儲器類型有關(guān)。對于100 B數(shù)據(jù)和40 B的頭部（包括TCP包的20 B頭部和IP包的20 B頭部），總共140 B的數(shù)據(jù)備份，采用外部存儲器，典型代碼的執(zhí)行周期為1 130個機(jī)器周期，用時為1.13 ms.

再次是發(fā)送數(shù)據(jù)分組。這里的耗時也與數(shù)據(jù)量和主頻有關(guān)。典型發(fā)送分組代碼的執(zhí)行總周期為2 200個機(jī)器周期，耗時為2.2 ms.

最后確認(rèn)分組。這里要做的工作有：檢測接口芯片，判斷分組類型，拆分IP包，拆分TCP包，典型代碼的執(zhí)行周期為4 130個機(jī)器周期，用時4.13 ms.

總共用時9.66 ms，其中接受確認(rèn)分組耗時最多，占總用時的42.8％。

3改進(jìn)后的TCP通信方案

由上面分析可以看出，對于小分組來說，接收確認(rèn)分組的過程比較復(fù)雜，因而耗時也最多。因而控制服務(wù)器確認(rèn)分組的發(fā)送數(shù)量，成為提高效率的關(guān)鍵。

研究發(fā)現(xiàn)通過調(diào)整Nagle算法的延時時間（每個接口的延遲ACK定時器可通過設(shè)定注冊表表項(xiàng)TCPDelAckTicks的值（HKLM＼SYSTEM＼CurrentControlSet＼Services＼Tcpip＼Parameters＼Interface＼）來調(diào)整，該注冊表表項(xiàng)在MicrosoftWindows NT 4.0 Service Pack 4中首次引進(jìn)）和采樣單片機(jī)的發(fā)送流程來控制服務(wù)器發(fā)送確認(rèn)的數(shù)量。

如圖4所示，這里發(fā)送數(shù)據(jù)分組并沒有等待確認(rèn)分組這個過程。當(dāng)有確認(rèn)到達(dá)時，所做的工作正常情況下和圖3所示的系統(tǒng)沒什么區(qū)別，只是在當(dāng)丟失了分組后的異常狀態(tài)出現(xiàn)后，才在更新連接狀態(tài)時處理了超時檢測和出錯重發(fā)等事件。之后在數(shù)據(jù)打包后也沒有備份，這里是采用了大存儲器數(shù)據(jù)偏移技術(shù)，也就是說在一個分組的確認(rèn)未到達(dá)時，其原始數(shù)據(jù)是不會被覆蓋的，新的分組打包在其后的內(nèi)存單元中，這樣就節(jié)省了數(shù)據(jù)備份所消耗的時間，不過無形中增大了對內(nèi)存的需求。但本應(yīng)用針對的是小分組情況，所以實(shí)際需求的內(nèi)存并不大。實(shí)際工作中，為了使系統(tǒng)穩(wěn)定工作，應(yīng)建立2個TCP連接，一個用于服務(wù)器（上位機(jī)）發(fā)送控制命令和進(jìn)行參數(shù)設(shè)定使用，一個用于客戶機(jī)（下位機(jī)）上傳采樣數(shù)據(jù)使用。雖然TCP可以雙向傳送數(shù)據(jù)，可實(shí)際工作中，發(fā)現(xiàn)這樣在高速通信下出錯率比雙連接單向數(shù)據(jù)通信要高出許多，主要是因?yàn)榭蛻魴C(jī)（下位機(jī)）對TCP頭部的確認(rèn)號和序列號的調(diào)整容易出錯所致。實(shí)際使用3～5個采樣分組發(fā)送一個確認(rèn)分組。因?yàn)檠訒r太短體現(xiàn)不了效率的提高，但延時太長，如果出錯，將產(chǎn)生大量重發(fā)分組的情況，影響網(wǎng)絡(luò)性能，同時也增大了對內(nèi)存的需求量。通過使用Snifferr軟件進(jìn)行監(jiān)聽比較，在同樣的采樣速率下，在改進(jìn)前，發(fā)送包速率為500packet/s，接收確認(rèn)包速率為500 packte/s，出錯率5％，持續(xù)傳輸時間小于2 h；改進(jìn)后，發(fā)送包速率為500 packet/s，接收確認(rèn)包速率為183 packet/s，出錯率小于0.1％，持續(xù)時間大于48 h.同時，同樣的硬件條件下，理論上可以進(jìn)一步提高采樣速率。


圖4 改進(jìn)后的系統(tǒng)發(fā)送數(shù)據(jù)流程

4典型應(yīng)用

對于高速、低數(shù)據(jù)量的采集或測控系統(tǒng)，如石油管道的查漏和修復(fù)系統(tǒng)，要求高速采集對管壁的超聲波掃描信號，通常結(jié)合溫度、壓力、深度和角度信號為一組采樣信號，其總量不足20 B.這些系統(tǒng)要求高的采樣速率，但每次采集的數(shù)據(jù)并不多，這就產(chǎn)生了大量小的數(shù)據(jù)分組，這些小分組將迅速降低系統(tǒng)性能和網(wǎng)絡(luò)性能。采用本方案，可以較好地解決這些問題。