嵌入式tcpip協(xié)議的分析與研究(編輯修改稿)
2025-06-11 04:22 本頁面
【文章內(nèi)容簡介】 器的專用芯片，通過其標準的輸入輸出口，可與絕大多數(shù)單片機相連。軟件方式是把TCP/IP協(xié)議以軟件方式嵌入到ROM中。在軟件方式具體實現(xiàn)時，又有以下兩種不同設(shè)計思想：第一種設(shè)計是針對高檔MCU片上系統(tǒng)，如ARM7或386EX等，可運行嵌入式實時操作系統(tǒng)，實現(xiàn)較完整的TCP/IP協(xié)議。采用這種方式最靈活，能按用戶需求實現(xiàn)很多復(fù)雜的功能，但是采用這種方式對開發(fā)人員的要求比較高，開發(fā)周期也較長。第二種設(shè)計是針對低檔的8/16位MCU的嵌入式系統(tǒng)，考慮到其系統(tǒng)速度和內(nèi)存的限制，不可能實現(xiàn)完整的TCP/IP協(xié)議，只能實現(xiàn)精簡的TCP/IP協(xié)議。5 TCP協(xié)議的機制裁減在傳統(tǒng)傳感器中嵌入式WEB服務(wù)器，遠程用戶就可以對傳感器實現(xiàn)遠程監(jiān)控，這就是通常所說的基于Internet的網(wǎng)絡(luò)傳感器，通常數(shù)據(jù)傳輸量很小。作為一種嵌入式Internet技術(shù)應(yīng)用，在TCP之上實現(xiàn)有限的WEB服務(wù)，只需要一部分TCP服務(wù)機制，或者并不對TCP所有機制都有很高的要求。針對這個這個特點，我們可以從前面討論的四個方面對TCP協(xié)議進行裁減：確認與超時重傳機制、流量和擁塞控制、TCP連接狀態(tài)和TCP運行狀態(tài)機。 確認與超時重傳 捎帶確認機制通信過程中，通信雙方都必須對對方上一次發(fā)送來的數(shù)據(jù)給予確認。這是保證傳輸可靠性的基本方法。但是，如果接收方對每一個數(shù)據(jù)報文都返回獨立的應(yīng)答報文，會在很大程度上浪費帶寬，造成通信效率的降低。我們可以讓發(fā)送方發(fā)送數(shù)據(jù)時捎帶對上一次接收到的數(shù)據(jù)確認。這樣只需要在發(fā)送的TCP頭部中設(shè)置一個應(yīng)答標志位和一個確認序列號。這樣做不會額外增加網(wǎng)絡(luò)上的數(shù)據(jù)報流量，可以有效提高通信質(zhì)量。 應(yīng)用層參與重傳如果發(fā)出的數(shù)據(jù)包在一定時間（RTT，Round Trip Time，發(fā)出數(shù)據(jù)到收到確認所需的往返時間）內(nèi)沒有收到確認，發(fā)送方由TCP執(zhí)行重傳。如果存儲空間允許，可以定義分配兩個緩沖區(qū)，一個存放待發(fā)送數(shù)據(jù)，另一個存放已發(fā)送數(shù)據(jù)，這樣重發(fā)就變得很方便了。但是，為了節(jié)省存儲空間，TCP對已發(fā)送的數(shù)據(jù)不進行任何緩存，由應(yīng)用程序重新生成數(shù)據(jù)，重復(fù)上一次發(fā)送過程。當(dāng)周期計時器減至0時，激活TCP重傳事務(wù)，然后調(diào)用HTTP回調(diào)函數(shù)HTTP_Appcall（），檢測重傳標志位，進行重傳工作。如果在連接已經(jīng)建立階段，就重新生成重傳數(shù)據(jù)，如果在連接建立或關(guān)閉過程中，說明丟失的是確認或應(yīng)答包，根據(jù)不同的TCP連接狀態(tài)，重發(fā)不同類型的數(shù)據(jù)包。這樣并不會增加應(yīng)用程序的復(fù)雜性，因為確認重傳的時機是TCP的責(zé)任，而應(yīng)用程序只需要重發(fā)時使應(yīng)用層數(shù)據(jù)指針重新指向上一次發(fā)送的數(shù)據(jù)即可。應(yīng)用層參與重傳機制的實現(xiàn)，有效降低了對微處理器存儲能力的要求。 流量控制和擁塞控制由于網(wǎng)絡(luò)傳感器傳輸數(shù)據(jù)量很小，我們沒有必要犧牲大量的存儲空間實現(xiàn)滑動窗口機制換取對流量和擁塞的控制。我們可以采用停等協(xié)議，它是滑動取窗口協(xié)議的一個極限情況，只使用一個窗口。發(fā)送方每發(fā)送一個分組，都等待確認。收到確認后再發(fā)送下一個分組。這樣做即能夠保證傳輸?shù)慕^對可靠，在數(shù)據(jù)量不大的情況下，傳輸?shù)膶崟r性也不會有明顯的折扣。更重要的是，化解了流量和擁塞問題。當(dāng)然，如果只是用一個窗口，還要求對方也使用簡單的確認機制。這可以通過設(shè)置TCP頭部Windows字段來通知對方自己的接收緩沖區(qū)大小，避免對方連續(xù)發(fā)送大量數(shù)據(jù)造成接收緩沖區(qū)溢出，以至丟包。 同時支持少數(shù)TCP連接每個TCP連接由套接字唯一標識。TCP初始化后處于端口偵聽狀態(tài)，當(dāng)接到客戶機建立TCP連接的請求時，除了發(fā)送“請求＋應(yīng)答”報文以外，還要記錄該TCP的狀態(tài)，包括源端IP地址、源端口號、目的IP地址、目的端口號、序列號等大量連接信息，以便對接收和發(fā)送的TCP段進行跟蹤。經(jīng)過簡化TCP機制，去除滑動窗口協(xié)議，我們盡量使用較少的TCP狀態(tài)數(shù)據(jù)，這樣可以節(jié)省存儲開銷。另外，遠程檢測需要多用戶同時訪問檢測頁面，所以，應(yīng)該同時支持多個TCP連接。但是，如果同時處理多個連接的請求和應(yīng)答，除了記錄各個連接的狀態(tài)信息之外，還要在不同狀態(tài)之間切換，無疑會增加RAM的使用。所以，可以僅支持十個TCP連接同時存在，即最多有10個用戶同時訪問服務(wù)器。對于8位單片機來講，這是合適的選擇。 TCP狀態(tài)機TCP的面向連接和可靠性傳輸?shù)忍匦詻Q定了每一個標準的TCP協(xié)議連接都要經(jīng)過三次握手建立和拆除連接，這個過程可以用狀態(tài)圖機描述。為了狀態(tài)機的正常工作，即各種狀態(tài)之間的正確切換，必須存儲每種狀態(tài)的相關(guān)信息。因此，狀態(tài)機越復(fù)雜，TCP協(xié)議實現(xiàn)的規(guī)模越大，維護狀態(tài)機的開銷就越多，對處理器存儲能力的要求也越高。一個標準的狀態(tài)機可以分為服務(wù)器和客戶機兩部分，服務(wù)器狀態(tài)機又分為被動建立連接和主動拆除連接兩部分，而拆除和客戶機之間的連接過程很復(fù)雜。但是，服務(wù)器發(fā)送完數(shù)據(jù)，向客戶機發(fā)送關(guān)閉連接請求后，客戶機一般沒有多余的數(shù)據(jù)要發(fā)送，所以當(dāng)接收到服務(wù)器的關(guān)閉連接請求后客戶機會直接發(fā)送FIN+ACK，服務(wù)器接到應(yīng)答后，回應(yīng)ACK，并直接進入“計時等待”狀態(tài)，等待關(guān)閉。這樣服務(wù)器關(guān)閉TCP連接的過程就大大簡化了。通過以上分析可以，作為一種嵌入式Internet技術(shù)，我們可以根據(jù)特定的應(yīng)用不失一般性的裁減掉復(fù)雜和冗余的機制。這樣，除去標準狀態(tài)機中的客戶端部分，簡化服務(wù)器關(guān)閉連接過程（不失一般性）。圖中CLOSED、LISTEN、SYN_RCVD、ESTABLISHED、FIN_WAIT、TIME_WAIT分
規(guī)章制度相關(guān)推薦
鄂ICP備17016276號-1