如何基于Nagle算法設計嵌入式TCP協(xié)議?
隨著嵌入式系統(tǒng)的發(fā)展,在嵌入式系統(tǒng)中實現(xiàn)網(wǎng)絡連接已成為研究熱點,廣泛使用的廉價8/ 16 位嵌入式處理器的性能不足與網(wǎng)絡協(xié)議的復雜構成了尖銳的矛盾。 嵌入式Internet 技術的核心是在嵌入式系統(tǒng)中實現(xiàn)TCP/ IP 協(xié)議簇, TCP 協(xié)議的機制比較復雜,對8/ 16 位嵌入式處理器的存儲能力和運算能力要求較高,必須進行簡化。
本文引用地址:http://m.butianyuan.cn/article/201807/384684.htm本文提出了一種適用于8/ 16 位低速處理器的簡化TCP 協(xié)議。對其性能進行分析發(fā)現(xiàn),在嵌入式網(wǎng)絡大量使用小數(shù)據(jù)包,造成網(wǎng)絡帶寬利用率低下并且容易造成網(wǎng)絡阻塞。 因此在簡化的TCP 協(xié)議中引入Nagle 算法,大幅度減少了嵌入式網(wǎng)絡中發(fā)送的小數(shù)據(jù)包個數(shù),提高了吞吐率,并減少了所需的帶寬。
簡化TCP 協(xié)議的提出
TCP 協(xié)議的數(shù)據(jù)傳輸分為3 個階段: 建立連接、傳輸數(shù)據(jù)和斷開連接,可以用狀態(tài)機 來實現(xiàn)。8/ 16 位嵌入式微控制器要完整實現(xiàn)這樣復雜的狀態(tài)機是十分困難的。在嵌入式系統(tǒng)中簡化TCP 的實現(xiàn)已有相關的研究,本文進一步引入了Nagle 算法并且進行了網(wǎng)絡模擬,給出了實驗結果。
連接建立和斷開機制
TCP 建立連接有兩種方式:主動打開和被動打開。如果實現(xiàn)服務器端應用,可以將TCP 狀態(tài)機的主動打開連接部分簡化掉。同理客戶端應用,可以將狀態(tài)機的被動打開連接部分簡化掉。斷開連接也有兩種方式:主動斷開和被動斷開。其中被動斷開連接的處理較為簡單。但為了保證安全性,希望主動斷開連接。主動斷開連接簡化實現(xiàn)的方法是:發(fā)送一個Fin 數(shù)據(jù)報,在接收到對Fin 數(shù)據(jù)報的確認后,再發(fā)送一個Reset 數(shù)據(jù)報,就可完成主動斷開連接。
以服務器端的TCP 連接為例,簡化后的TCP狀態(tài)機如圖1。

單TCP 連接
在8/ 16 位微控制器上實現(xiàn)簡化TCP 協(xié)議,無需實現(xiàn)多個TCP 連接,只需實現(xiàn)單個TCP 連接即可。
簡單確認機制
嵌入式系統(tǒng)發(fā)送數(shù)據(jù)包不大,可以將TCP 協(xié)議的滑動窗口機制去掉,成為簡單確認機制,只對單個數(shù)據(jù)報而不是批量數(shù)據(jù)發(fā)送確認。實現(xiàn)方法是設置TCP 頭部windows 字段的大小為1 ,即可保證TCP協(xié)議雙方都使用簡單確認。
僅計算發(fā)送TCP 報文的校驗和
由于TCP 協(xié)議校驗和的計算對系統(tǒng)存儲和計算資源的占用都比較多,可以省去對接收數(shù)據(jù)報校驗和的計算,保留發(fā)送數(shù)據(jù)報TCP 校驗和的計算。
簡化TCP 方案小結
在上述4 個方面的基礎上,在嵌入式處理器中實現(xiàn)了簡化的TCP 協(xié)議,程序流程如圖2。其中“不同狀態(tài)的相應處理”指根據(jù)接收到的TCP 報文準備待發(fā)送數(shù)據(jù)報并將其發(fā)送到以太網(wǎng)上。
簡化TCP 協(xié)議的性能分析
這種簡化的TCP 協(xié)議的性能可以通過在NS-2

網(wǎng)絡模擬器中進行模擬實現(xiàn)。
通常在嵌入式的環(huán)境中,應用層產(chǎn)生的數(shù)據(jù)包是很小的,經(jīng)常是每個包只有幾個、十幾、幾十個字節(jié)的數(shù)據(jù),這樣就產(chǎn)生了一個問題: TCP 協(xié)議的報頭開銷太大。假設數(shù)據(jù)僅有一個字節(jié),而TCP 的包頭有40 個字節(jié),這樣的數(shù)據(jù)報對底層網(wǎng)絡的利用率僅僅只有1/ 41 ,考慮到分組之間的間隙和網(wǎng)絡硬件組成幀還需要一些比特,實際的網(wǎng)絡利用率更低。 嵌入式系統(tǒng)的這種常見的小的數(shù)據(jù)包造成了網(wǎng)絡帶寬的極大浪費。除了網(wǎng)絡利用率不高之外,還有另外一個問題是產(chǎn)生TCP 數(shù)據(jù)包數(shù)量極多,網(wǎng)關和路由器會由于這些極大數(shù)量的小數(shù)據(jù)包而發(fā)生阻塞。
組塊技術與其不足
通過以上分析,很自然的想到采用組塊技術(clumping) 把一定數(shù)量的數(shù)據(jù)包組成一個幀,這樣既能減小報頭開銷,又能減小TCP 數(shù)據(jù)包的數(shù)量,而且代碼量增加很少。但是,這樣組包會產(chǎn)生一個問題,TCP 在數(shù)據(jù)幀未達到一定大小之前不會傳輸數(shù)據(jù),這樣產(chǎn)生的延時會影響到數(shù)據(jù)的實時傳輸。因此,有必要對怎樣避免這種延時進行研究。
Nagle 算法的由來
在因特網(wǎng)發(fā)展初期,由于bbs 和新聞組的流行,網(wǎng)絡上充斥著大量的telnet 產(chǎn)生的小的數(shù)據(jù)包,數(shù)量極大的這些數(shù)據(jù)包使得路由器和網(wǎng)關發(fā)生了嚴重的阻塞現(xiàn)象,這和嵌入式系統(tǒng)中的情形類似。JoneNagle 提出了一種算法來對付這種棘手的小數(shù)據(jù)包問題,后來被稱為Nagle 算法。
Nagle 算法與簡單的組包( clumping) 技術不同,它和慢啟動一樣使用自計時( self clocking) 、用確認的到達來觸發(fā)其余數(shù)據(jù)的傳輸。因此它沒有引入額外的延時,而且能有效地減少網(wǎng)絡上小數(shù)據(jù)包的流量。
Nagle 算法的描述
在一個連接上已經(jīng)傳輸?shù)臄?shù)據(jù)還沒有被確認的情況下,發(fā)送方的應用程序又生成了后續(xù)數(shù)據(jù),并照常將數(shù)據(jù)送到輸出緩沖區(qū)中,但這時并不發(fā)送后續(xù)報文段,而是等到有足夠的數(shù)據(jù)填滿一個達到最大長度的報文段之后再把緩沖區(qū)中的數(shù)據(jù)發(fā)送出去。
如果某個應用程序每次僅產(chǎn)生一個八位組的數(shù)據(jù), TCP 會立即發(fā)送最初的那個八位組,但是在確認到達之前, TCP 會把后續(xù)數(shù)據(jù)存入緩沖區(qū)中。因此當應用程序生成數(shù)據(jù)的速率比網(wǎng)絡的速率快很多時(如傳送文件) ,后續(xù)的報文段將包含大量的數(shù)據(jù),而當應用程序比網(wǎng)絡速度更慢時(如用戶敲鍵盤) ,就會發(fā)送較短的報文段而不必經(jīng)過長的延時。
Nagle 算法在嵌入式環(huán)境的適用性
在嵌入式系統(tǒng)的環(huán)境中,嵌入式TCP 協(xié)議會面臨著各種情況,比如一兩個開關量的傳輸,或者是傳感器數(shù)據(jù)實時的傳輸,而Nagle 算法能夠自動適應網(wǎng)絡速率和應用層數(shù)據(jù)流量的各種情況,因為它是以確認來觸發(fā)的自計時的協(xié)議。
網(wǎng)絡模擬
NS-2 是一個應用于網(wǎng)絡研究的離散事件模擬器,它充分支持有線與無線網(wǎng)絡上對于TCP、路由和多播協(xié)議的模擬。它自問世以來受到學術界的充分信賴,成為設計和檢驗新的協(xié)議和算法的權威網(wǎng)絡模擬測試平臺。
網(wǎng)絡模擬環(huán)境的構建
圖3 是本文構建的網(wǎng)絡模擬環(huán)境:節(jié)點0 使用本文提出的嵌入式TCP 協(xié)議發(fā)送數(shù)據(jù),節(jié)點1 使用用戶投文協(xié)議(UDP) 組播協(xié)議來發(fā)送大量的數(shù)據(jù),用于測試嵌入式TCP 協(xié)議在網(wǎng)絡阻塞情況下的性能,節(jié)點2 和節(jié)點3 之間是瓶頸路徑,模擬交換機之間的線路情況。
評論