基于8位單片機的TCP通信速度研究

0 引 言

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

1 TCP通信硬件接口

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

2 單片機系統中TCP通信問(wèn)題分析

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

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

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

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

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

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

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

總共用時(shí)9.66 ms，其中接受確認分組耗時(shí)最多，占總用時(shí)的42.8%。

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

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

研究發(fā)現通過(guò)調整Nagle算法的延時(shí)時(shí)間(每個(gè)接口的延遲ACK定時(shí)器可通過(guò)設定注冊表表項TCPDelAckTicks 的值 (HKLM SYSTEM CurrentControlSetServicesTcpipParametersInterface)來(lái)調整，該注冊表表項在MicrosoftWindows NT 4.0 Service Pack 4中首次引進(jìn))和采樣單片機的發(fā)送流程來(lái)控制服務(wù)器發(fā)送確認的數量。

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

4 典型應用

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

5 結 論

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