發布日期：2022-07-14 點擊率：66
隨著查詢/響應類應用聯網設備的不斷增加,以及帶寬競爭的加劇,高效實現互動數據交換就顯得十分迫切。在臃腫的網絡上,響應時間、存儲器的使用、可靠性和互動性是選擇傳輸協議時需要考慮的多個重要因素,本文就從這幾個方面說明三種不同的傳輸層協議對上述指標的影響,并說明具備T/TCP功能的聯網設備可能是未來的發展趨勢。
目前,連接上網的嵌入式設備的數量和種類都在迅速增加。許多數據通訊應用方面的要求涉及頻繁的查詢-響應,或者在客戶端設備與服務器設備之間小型數據(小到可以放在單一而不拆分的IP包中)的互動數據交換(transaction)類型互換。本文中“客戶端”指啟動這種信息交換的設備,而“服務器”是指響應該請求的設備。客戶同服務器的關系可以是多對一,一對多或者是多對多的關系。
聯網設備通常都采用IP(互聯網絡協議)作為網絡層協議。傳輸應用中一個至關重要的選擇就是傳輸層協議的應用。本文著重討論這種選擇所面臨的若干問題以及注意事項,特別是(但不僅僅是)在嵌入式設備中,要注意存儲器、網絡帶寬、響應時間、可靠性以及互動性等問題。根據這些情況,傳輸層協議將分別考慮三種可能的選擇:UDP、TCP以及T/TCP.
用于互動數據交換的TCP擴充
一般來說,傳輸控制協議(TCP)和用戶數據包協議(UDP)是讀者比較熟悉的,而用于互動數據交換的TCP擴充協議(T/TCP)還不太為人所知,本段簡要介紹有關該協議的概況。
T/TCP并不是一種新的協議。該協議在1994年就以RFC1644標準的形式給出了定義。在標準版TCP的基礎上,通過增加某些新功能來實現互動數據交換應用的優化,從而構成了T/TCP。在T/TCP中使用了所有的標準版TCP的機制及基本結構。T/TCP后向兼容TCP。T/TCP不論是在客戶端還是在服務器端,當與一個不支持T/TCP協議的對等設備通訊時,就會自動適配為標準版TCP。
T/TCP連接中的每一個IP包(TCP術語中稱為一個區段)都會用一個32位的連接計數(connection count)來標識,該連接計數對每個連接來說都是唯一的。絕大多數情況下,它能防止舊的區段破壞后續連接。一個稱為“CC”的TCP數據頭選項可以攜帶T/TCP連接計數。
對持續時間較短---小于一個數據段最長壽命(MSL)---的連接來說,CC選項的一個好處就是它可以縮短或者避免出現TCP的TIME_WAIT狀態。TIME_WAIT狀態提供保護TCP數據流不被破壞的一種機制,這種機制通過復制同一個連接以往數據段的早期副本來實現。TCP連接的一端駐留在TIME_WAIT狀態來維持兩個MSL---一個MSL通常持續兩分鐘---的時間間隔,這樣可以防止當所有的副本信息段在網絡上仍然處于有效期時創建同一連接的新副本。T/TCP的CC選項確保TIME_WAIT狀態可以被截短到最多高達一個連接往返時間(RTT)的八倍。更重要的是,同一連接的新副本可以立即創建,也就是說,TIME_WAIT狀態可以完全消除。
T/TCP會維護每一個相互作用的遠程主機的協議信息的緩存。這個緩存包括往返時間、最大信息段長度以及堵塞窗口等相關信息。因此,這些信息無需在每一次連接中重新創建,T/TCP連接可以根據這些參數立即運行。
標準TCP連接總是以一個不攜帶任何數據信息的三段同步(SYN)序列開始,而以同樣不攜帶任何數據信息的一個三段結束(FIN)序列來中止。SYN與FIN之間的數據段攜帶需要交換的信息。如果需要發送數據的總量可以整合在單一的數據段中,那么T/TCP就可以將SYN、FIN以及數據功能組合為單個信息段(single segment),所以完整的一個T/TCP連接僅需要三個數據段就可以打開和關閉。
用于T/TCP的插座API是標準TCP插座API的最小擴充。通過將兩個現有的API功能“send to”和“send”進行了擴展,可以確保應用端整合各種要求,從而打開連接、傳輸數據和關閉連接傳輸方向以便被單API調用。
在客戶端一方,三區段連接的最小持續時間與一個簡單的往返時間為同一數量級。這里,通常假定與往返時間相比,服務器處理請求并且發送響應需要花費的時間很小。
存儲器的使用
由于生產成本較高,所以嵌入式設備的存儲器通常都比較有限,因此進行軟件設計時必須牢記這一約束條件。
標準TCP之所以可靠,一個原因是一旦連接中止,那么啟動連接中止的一端(通常是客戶端)就會進入TIME_WAIT狀態,并且維持這一狀態的時間較長,通常為二倍MSL。在這段時間內,不會創建同一連接的新例程。這種機制保護TCP連接免受同一端點之間早期連接中相同端點之間舊的復制信息段的破壞。這樣看來,當TIME_WAIT狀態時間到期為止,所有這些舊的信息段都將在網絡上到期。
當一個連接維持在TIME_WAIT狀態時,TCP就必須為該連接維護一個包括狀態信息的控制模塊。通常情況下,一個連接的TCP控制模塊會占用幾百個字節的存儲器空間。
與此同時,如果客戶端應用希望管理與同一個服務器之間后續互動數據交換的話,就必須為每一個客戶端應用分配一個新的本地TCP端口,并且為該連接的TCP控制模塊分配存儲器。如果客戶端應用運行的硬件平臺中存儲器空間比較緊張,該TCP層的設計就要考慮讓傳輸容量能夠滿足一定數量的同時連接需要。一旦連接容量(connection capacity)為TIME_WAIT狀態下的連接全部占用,那么只有其中的一個TIME_WAIT狀態到期才能創建新的連接。這可能嚴格制約傳輸的速率,例如,如果TIME_WAIT狀態的持續時間是兩分鐘,并且客戶設備的容量是20個同時連接,那么所能達到的最大傳輸速率就是每分鐘10次互動數據交換。
由于UDP沒有連接狀態,因而無需維護連接狀態,所以對UDP來說,存儲器的大小和使用不成為問題。
T/TCP的TIME_WAIT具有截短特征(truncation feature),因此應用可以立刻復用上一個連接的本地TCP端口,而無需進行額外的TCP控制模塊分配。
即使應用并不復用同一本地TCP端口,由于T/TCP的TIME_WAIT狀態持續時間與標準TCP相比通常都很短,那么,相對來說有限的同時連接容量而導致的互動數據交換速率(transaction rate)的下降就很小。
網絡帶寬
如果位于客戶端和服務器之間路徑上的網絡數據傳輸量相對它們的容量來說負載很重的話,那么就可能出現因堵塞而導致的信息包丟失,使用具有較小開銷的傳輸層協議就能夠使這種風險降到最小。
使用標準TCP實現的一個最小互動數據交換通常需要9個TCP區段,盡管這些區段中只有兩個區段攜帶有應用數據。7個額外的區段用于三方握手,以開放/關閉連接以及做出應答,因而開銷很大。
此外,由于網絡堵塞而產生的區段丟失將導致數據重傳,這都會增加數據包數量。當然,傳輸協議中潛在的開銷越大,那么數據路徑上的網絡數據傳輸也就更容易出現堵塞。
使用UDP的一個最小互動數據交換只需要兩個UDP數據包,每一個方向各一個數據包,因而UDP可以使網絡上的負載最小。
一對主機之間初始的T/TCP互動數據交換需要6個區段,同一對主機之間后續的傳輸只需要3個區段。
響應時間
如果客戶端和服務器之間網絡路徑上的一個或者多個數據鏈使用低速(例如串行的PPP鏈接)傳輸介質或者呈現出較大的傳輸延時(例如用同步軌道衛星中的衛星鏈路),那么互動數據交換的發起者就需要相對較長的響應時間。對于操作人員來說,這或許算只是等得不耐煩的問題。而對于具有嚴格實時約束的客戶端程序來說,問題就嚴重了。
在采用標準TCP的互動數據交換中,客戶端需要的響應時間至少是連接路徑往返時間的兩倍,加上服務器應用端處理請求／詢問以及產生響應所需要的時間。后者的服務器處理時間稱為SPT,因此,總的響應時間至少是2*RTT+SPT。
在采用UDP的一個最小互動數據交換中,客戶端的響應時間是RTT+SPT。
一對主機之間初始的T/TCP互動數據交換具有與TCP同樣的響應時間(2*RTT + SPT)。同一對主機之間所有后續互動數據交換的響應時間與UDP相似(RTT + SPT)。
可靠性
IP網絡的可靠性不夠高,例如單個信息包可能由于網絡節點的堵塞而丟失。如果某種應用要求端到端數據傳輸的可靠性,那么就必須在傳輸層或者通過應用端自身來確保這種可靠性。
由于標準TCP是一種可靠的數據傳輸協議,它能夠很好地從堵塞導致丟失的區段中恢復并且完成互動數據交換。對于應用軟件來說,只是增加了響應時間,這種情況非常明顯。如果由于一個網絡節點出現故障以及/或者客戶端和服務器之間的數據路徑被切斷,并且沒有任何其它可能的路由而導致互動數據交換不能完成,那么應用端就會被告知出現了故障,從而造成數據交換無法進行。
UDP不是一種可靠的傳輸協議。如果一個UDP數據包由于網絡堵塞而丟失,那么互動數據交換就不能完成。如果要求數據的傳遞必須可靠,那么這種可靠性就必須在應用層中構建。T/TCP具有和標準TCP一致的可靠性。
互動性
與使用專屬協議棧或者尚未普遍使用的新的協議棧相比,采用公認和業已實現的標準協議棧更容易實現互動性。
標準TCP不會對互動性造成任何障礙。
如果要求可靠性,就必須在UDP之上使用一種專有機制,這樣可能會導致互動性方面的問題。
由于T/TCP具有后向兼容標準TCP,因而它的應用對于互動性的影響較小甚至不會產生任何障礙。一個特例是如果一個客戶端T/TCP試圖與一個有故障的標準TCP(該TCP不能無視CC選項)進行通訊,那么可能存在障礙。當T/TCP的性能優勢不能在這種“互動性”模式中實現時,至少互動數據交換本身仍然可以發生。
應用復雜性
如果一個請求需要可靠的數據傳輸,就必須使用一個可靠的傳輸層協議,或者由應用自身來提供這種可靠性。在請求中包含數據傳輸的可靠性機制能極大地增加復雜性并且提高應用的開發成本。
如果使用的傳輸層協議實現方案為其它的應用廣泛采用,那么與傳輸層協議接口的代碼很可能也是從其它應用“克隆”得到,而不是從頭開始開發的。這種優勢不可能通過使用一種專有的協議棧或者一種尚未被許多應用所使用的新協議棧來實現。
由于TCP是一種可靠的數據傳輸協議,因而無需在使用TCP的應用中引入可靠性機制。絕大多數TCP實現都提供事實標準BSD插座API。
絕大多數UDP的實現也提供事實標準BSD插座API,另一方面,UDP并不提供任何的可靠性保證,所以應用端自身必須提供可靠性機制。
T/TCP提供與TCP一樣的可靠性保障,所以使用T/TCP的應用無需提供可靠性機制。由于TCP的API進行了適當的擴展以實現對T/TCP的支持,與T/TCP接口的應用代碼不可能完全從使用標準TCP的應用中“克隆”得到。但是差別并不明顯,而且那些代碼仍然可以作為開發起點,從而利用T/TCP的優點,并避免對代碼進行大的改動。
性能比較
下列測試中的客戶機是一個運行FreeBSD 4.4版本0并且具有T/TCP補丁的PC機。路由器是一個運行Linux .0的PC機。服務器是一個運行Windows 98并且具有Fusion 6.5 TCP/IP協議棧的PC機。
在某些測試中,路由器上要用一個工具加入250ms的延時后才把數據包從出口路由出去(如圖1所示),這樣做的目的是模擬一個“長”鏈接的延時特性,比如地球同步人造衛星鏈接,因此,實際上有四種測試配置,分別代表以下四種網絡路徑:
1. HB-DL:高帶寬,低延時；
2. HB-HD:高帶寬,高延時；
3. LB-LD:低帶寬,低延時；
4. LB-HD:低帶寬,高延時。
每一次互動數據交換中,客戶端應用都向服務器端應用發送一個1,000字節的請求,服務器端應用通過重復回送這一請求給客戶端來完成對客戶端應用的響應。由于API差異較小,因此在T/TCP和標準TCP測試中要用不同的客戶/服務器應用程序。
每一次試驗都連續快速地執行100次互動數據交換。客戶端應用在前一個互動數據交換結束之后,立即啟動一個新的互動數據交換。網絡監控器捕獲這些數據流用來進行脫機分析。三個試驗分別在上述四種結構中執行,對每一種結構考察第一次互動數據交換的第一個包,和第100次互動數據交換的最后一個包之間所花費的全部時間并且記錄下來。同時記錄的還有每次試驗中通過該網絡的TCP區段數量。將每一種結構中三個試驗的結果取平均值(事實上這些結果的變化基本上可以忽略),結果顯示在表1中。
在絕大多數結構中,測試結果表明差別主要區段計數上。T/TCP互動數據交換的區段計數是三個,標準TCP是9個。唯一的例外就是在低帶寬結構中運行標準的TCP,在這種結構下,包的數量甚至高于期望值。這是由于某些不必要的由客戶端查詢的1,000字節的重發,造成這種情況的原因在于啟動重新互動數據交換定時器的值小于客戶端接收確認的時間值。由于T/TCP緩存測量的往返時間(取決于基于哪一個重新傳輸定時器)并且應用在后續的連接中,所以這種情況就不會出現在T/TCP(在第一次傳輸時可能出現)中。標準TCP不能記憶跨連接之間的RTT。
所有的測試結構都表明,T/TCP互動數據交換的完成要快于標準TCP互動數據交換。這種差別在HB-HD結構中效果最明顯,在這種結構中標準TCP互動數據交換大約要花T/TCP互動數據交換時間的兩倍。這種結構中決定往返時間的重要因素是延時；標準TCP需要兩個往返時間,而T/TCP只需要一個。在LB-LD結構中差距最小,這是因為在這種結構中1,000字節的查詢和響應的傳輸時間構成最主要的時間成分。
本文小結
隨著查詢/響應類應用聯網設備的不斷增加,以及帶寬競爭的加劇,高效實現互動數據交換就顯得十分重要。由于許多這樣的應用是交互式的,并且可能運行在臃腫的網絡上,因此響應時間也構成設計過程需要考慮的一個重要的因素。
傳輸層協議的選擇會影響帶寬效率,而且也是決定響應時間的重要因素。UDP具有最佳的帶寬效率因而被廣泛采用,很清楚,傳輸層協議并不適合于那些數據傳輸可靠性要求非常嚴格的應用。如果具有嚴格的可靠性方面的要求,那么標準TCP就可能是更好的選擇。但是如同本文所介紹的,T/TCP在帶寬效率和響應時間兩方面都要優于TCP,與此同時仍然保持較高的可靠性。基于上述原因,網絡上在不久的將來可能會出現大量具備T/TCP功能的設備。
參考資料
1. Braden, R. "T/TCP - TCP Extensions for Transactions Functional Specification," RFC 1644, 1994.
2．Stevens, W.R. TCP為傳輸,HTTP,NNTP以及UNIX域協議。Boston: Addison Wesley, 1996.
作者簡介:Michael Mansberg是NetSilicon Softworks小組的主任軟件工程師。他持有馬里蘭大學的計算機科學學位,并且具有在實現數據通訊協議領域廣泛的經驗。可以通過電子地址:mmansberg@與他聯系。
作者:Michael Mansberg
