一:摘要

在這個文檔里,我們證實那些認為符合DoD(美國國防部)標準的TCP和ip協議不適
合局域網的觀點是不正確的.這個文檔是和M82-47,M82-49,M82-50,andM82-51緊密聯系
的.

二:主旨

這篇論文的主旨是否定那種認為TCP協議用在局域網是一種woozle的觀點.為了達到
這一點,我們需要知道什么是woozle,什么是LAN,什么是TCP.

1:Woozles(一種可怕的動物)

第一個問題相當簡單[1]:
一個晴朗的冬日,Piglet正在掃它家門前的雪.他忽然發現Pooh在不停的繞圈圈,似乎想
著什么問題.于是Piglet對他說:"
"喂,你在干什么?"
"獵取."
"獵取什么啊?"
"跟蹤難題."Pooh神秘的說.
"什么難題?"
"這正是我在想的問題,我在跟蹤什么問題?"
"你覺得有答案了嗎?"
"還沒有.看那."Pooh指著它前面的地面說:"那是什么?"
"雪痕,動物的爪痕"Piglet興奮的尖叫到,",你不覺得這是一個Woozle嗎!"

于是他們互相是對方相信這就是一個Woozle,一種可怕的動物.他們害怕起來,直到
ChristopherRobin來告訴他們說他們看到的只不過是自己的腳印.

其實,這就像我們害怕TCP協議用在局域網中一樣.我們誤解了協議和環境本身,爾非技
術上不答應.

2:局域網

第二個問題就不那么簡單了.一般來說,局域網是一種短距離(幾千米),高傳輸速率(大于
幾百kbps),低誤碼率的通信機制(子網).它首先使得計算機(主機)之間能夠通信,;其次,答應網
絡打印機和TCP協議終端與主機通信,盡管這一點不是必須的.
這樣,從原則上講,主機是異類的.它們不是相同操作系統的疊加.為了達到ARPANET稱
作"資源共享"和ISO稱作"開放系統互連"的目標,主機之間通過層次協議進行通信.通信方式
是主機到主機(點到點)或廣播方式.(在一些非凡環境中,例如Ethernet,吸引人的方式是廣播;在
另一些環境,例如ARPA-和ISO-標準的"Internet",廣播方式是如此的昂貴一直與它不可能被
實現.)

對于局域網的實現介質和拓撲結構,我們沒作任何假定.局域網介質可能是雙絞線,CATV,
同軸電纜,光纖等.假如介質采用處理器到處理器的總線,那這個系統更像分布式多操作系統.
因微處理器不能用ARPANET或ISO的層次協議.像"PDSC"(thePacificDataServiceCenter)
和"NMIC"(theNationalMilitaryIntelligenceCenter)系統都不是局域網.

局域網的拓撲結構可能是總線,環網,或星型.從這一點來說數字PBX是一個局域網,因
為它有傳輸介質能提供資源共享和開放互連,雖然不能保證傳輸率和誤碼率.從拓撲結構來說,
它是中心星型結構.
對于我們來說,局域網的誘人性質是它的高數據傳輸率和低誤碼率.顯見,實現這個性質
的傳輸介質不能用為長距離通信網絡而設計的TCP協議(我們并沒有把帶寬的浪費歸結為數
據包頭.[2].pp.1509f,提供了對傳統的通信方式的反駁.)假如你想做的只是讓一些終端連接上
一些主機,你根本不需要任何網絡協議,你所做的只能被稱為LCN,而不是我們討論的LAN.

3:TCP

第三個我們需要知道的既直接又微妙.完全依靠我們對ARPANET標準協議的理解:直觀
上來說,Figure1和Figure2都需要表述清楚,它們意味著ARPANET標準協議并非一個整體,
而是層次結構.為了更清楚的說明這個問題,我們認為:TCP協議是一個主機對主機協議(近似
等價于ISO標準協議的第五層).它的最顯著的性質是提供了可靠的邏輯上的連接.(這一點稍
候又會提到.)TCP協議協議的另一個顯著性質是它是為Catenet(或者說是Internet)而設計的,
也就是說連接在不同通信子網上的主機之間可以像Catenet上的主機一樣通信.TCP協議的其
它性質,像數據流控制,邏輯連接治理等很輕易設計啦.

因為TCP協議的獨特的地址機制(就是說,它用二維整體來表示外部主機地址,因為它不
知道主機是否和它在同一個子網上),它需要一個接口(IP協議)來處理不同子網的信息.這種接
口就是IP協議.盡管IP協議協議被設計為和TCP協議協議獨立,但它為主機間的數據傳輸提
供了基礎.

為了處理不同子網的問題,IP協議擁有下面的性質:IP協議察看一張保存有離一個主機
最近的子網的信息(如優先級,服務等級,安全標記)的表,從而決定一個因特網地址是不是在這
個子網上;假如是,它就把信息發送給這個子網,否則,它把信息發送給網關(它有另一個IP協議
模塊).可見,IP協議協議處理因特網路由,而TCP協議協議處理因特網尋址.因為一些子網傳輸
能力差,只能傳輸小數據包,IP協議協議還應該能把大數據包分割成適合相應子網的大小.最
后,IP協議協議應該提供一種機制,使得它能被其它協議辨認出來.(這是靠層次原則來實現的:
你不需要了解IP協議所傳輸的數據,只需要了解IP協議要干什么.)

現在看起來有一點麻煩,因為有太多的機制.(更完整的討論,清參考文獻[4]).但這些已足
夠證實我們的觀點.一種未公開的協議是UDP協議-------用戶數據報協議.UDP協議更強調速
率而不是正確率,它是不可靠的.對于UDP協議協議來說,任何一個數據包都建立一個邏輯連
接..這樣,假如你想多路傳輸數據,你應該用UDP協議而非TCP協議.

三:局域網上的TCP協議

不管你的主機是否屬于一個局域網,也不管你是否了解TCP/IP協議,假如你要與因特網
上的另一臺主機通信,你必須用TCP協議.假如你想做一些網絡上的應用(ISO標準協議上的
第5層的部分服務和全部第6,7層),就需要TCP/IP協議,因為它通過邏輯連接提供了可靠性,
數據流控制,次序控制等內容.但假如你的應用不需要TCP協議的性質,就不要用它,不管你
是在干什么.假如你想跟同一個網絡上的主機通信,你可以自己設計一個協議,但這通常是極
其糟糕的.假如你想讓自己的網絡保持自然狀態,TCP/IP協議根本不會阻礙你.但應該提醒你,
你的應用多需要主機對主機的協議,因此,除非你想搞一個真正并行的東西……否則,主機間
的協議是必不可少的.

現在我要討論性能問題啦.這是一個非常細節化的問題.應該指出一點:在考慮可靠性的前
提下,許多人(包括我)都為TCP協議而汗顏.因為研究機構在好多種類型的主機上的實驗表明:
雖然TCP協議協議友好的容錯性,但它只有12%的效率.這讓我們考慮又沒有必要換一種主機
對主機間的協議來替代TCP協議.(假如有這樣一種協議,它也應該有TCP協議協議的可靠性
這個優點.因為你是在做TCP協議,而不是LCN,像前邊提到一樣.)

抓住這只Woozle!

四:其它性質
下面將闡述TCP/IP的其它性質:

1. TCP/IP可以用在兩個完全不同的操作系統之間;
2. TCP/IP已經應用好幾年了;
3. IP層不限制子網提供的接口協議(盡管其中的一些是一種浪費);
4. IP層不限制它的使用者,只要子網提供路由(不像X.25);
5. IP協議的網關同樣擁有3和4的性質;
6. TCP/IP符合DoD標準;
7. 應用協議和文件傳輸協議(包括Email)已經存在并被用在許多不同的操作系統
上;
8. TCP/IP是受到美國國防部協議標準的支持的;
9. 研究機構報告的最新數據是:

SUBNET
SUBNET
PHONELINE
實際值(kb/s)
300
1.2k
9.2
理論值(kb/s)
800
9.2k
9.6



因為性質8,沒有其它協議比TCP/IP更適合.非凡注重上面的性質不該被誤解為局域網
上TCP/IP協議的性能分析的一種限制.(但你應該知道局域網中性能分析的困難:1.用一種備
選協議來測量比較困難;2.大部分主機不能產生如你所設想的高數據產生率.)這樣就像是限
制了TCP/IP協議的運用.

五:其它有用的數據

到這里,我們已經把問題討論清楚,但進一步分析主機的性能是合理的,假如僅僅想搞清
楚前面的討論.主機終端是刷新模式,每一屏的內容有16ms.那么中斷1秒鐘能刷新多少次?我
們知道,硬盤尋道時間是17ms,數據從硬盤提取出來要2ms,假如數據傳輸到網絡有1ms,那么
加起來就要20ms,盡管主機什么也沒做.假如本地硬盤的I/O速率是16kb,那么1秒鐘,主機只
能提供50屏/秒的刷新率,大約800kb/s,這個速率符合TCP協議的速率(見性質9).在一個實際
的系統中,主機看起來達不到這個速率.(主機數據傳輸速率的分析是困難的,因為它依靠系統
內部的性能.因為經典操作系統的本質,如進程間共享棧的需要,輸入數據占據內存的需要時
的不可能得到比你所能產生的傳輸率更高的數據傳輸率.)

六:結論:

認為TCP協議協議不能用于局域網的看法是沒有任何根據的.TCP協議協議完全能
用于局域網中,實現主機之間的通信.

七:參考文獻

[1]Milne,A.A.,"Winnie-the-Pooh",variouspublishers.

[2]TheLANdescriptionisbasedonClark,D.D.etal.,"An
IntrodUCtiontoLocalAreaNetworks,"IEEEPRoc.,V.66,N.
11,November1978,pp.1497-1517,severalyear'sworthof
conversationswithDr.Clark,andtheauthor'sobservations
ofboththeopenliteratureandtheOralTradition(which
weresufficientlywell-thoughtoftohavepromptedTheMITRE
Corporation/NBS/NSALocalNets"BrainPickingPanel"tohave
solicitedhistestimonyduringtheyearhewasinFACC's
employ.*)

[3]TheTCP/IPdescriptionsarebasedonPostel,J.B.,
"InternetProtocolSpecification,"and"TransmissionControl
Specification"inDARPAInternetProgramProtocol
Specifications,USCInformationSciencesInstitute,
September,1981,andonmorethan10years'worthof
conversationswithDr.Postel,Dr.Clark(nowtheDARPA
"InternetArchitect")andDr.VintonG.Cerf(co-originator
ofTCP),andonnumerousdiscussionswithseveralother
membersoftheTCP/IPdesignteam,onhavingeditedthe
referenceddocumentsforthePSTP,and,forthatmatter,on
havingbeenoneofthedevelopersoftheARPANET"Reference
Model."

[4]Padlipsky,M.A.,"APerspectiveontheARPANETReference
Model",M82-47,TheMITRECorporation,September1982;also
availableinProc.INFOCOM'83.

________________
*Inallhonesty,asfarasIknowIstartedtherumorthatTCP
mightbeoverkillforaLANatthatmeeting.AtthenextTCP
designmeeting,however,theyseparatedIPoutfromTCP,and
everything'sbeenalrightforaboutthreeyearsnow--except
forgettingtherumorkilled.(I'dworryaboutWoozles
turningintoroostingchickensifitweren'tforthefacts
that:1.Peopletendtoignoretheirlocalguru;2.Iwas
tryingtoencouragetheIPseparation;and3.AllIever
wantedwassomeempiricaldata.)

NOTE:FIGURE1.ARMintheAbstract,andFIGURE2.ARMS,
SomewhatParticularized,maybeoBTainedbywritingto:Mike
Padlipsky,MITRECorporation,P.O.Box208,Bedford,
Massachusetts,01730,orsendingcomputermailto
Padlipsky@USC-ISIA.