一:摘要

在這個(gè)文檔里,我們證實(shí)那些認(rèn)為符合DoD(美國國防部)標(biāo)準(zhǔn)的TCP和ip協(xié)議不適
合局域網(wǎng)的觀點(diǎn)是不正確的.這個(gè)文檔是和M82-47,M82-49,M82-50,andM82-51緊密聯(lián)系
的.

二:主旨

這篇論文的主旨是否定那種認(rèn)為TCP協(xié)議用在局域網(wǎng)是一種woozle的觀點(diǎn).為了達(dá)到
這一點(diǎn),我們需要知道什么是woozle,什么是LAN,什么是TCP.

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

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

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

其實(shí),這就像我們害怕TCP協(xié)議用在局域網(wǎng)中一樣.我們誤解了協(xié)議和環(huán)境本身,爾非技
術(shù)上不答應(yīng).

2:局域網(wǎng)

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

對于局域網(wǎng)的實(shí)現(xiàn)介質(zhì)和拓?fù)浣Y(jié)構(gòu),我們沒作任何假定.局域網(wǎng)介質(zhì)可能是雙絞線,CATV,
同軸電纜,光纖等.假如介質(zhì)采用處理器到處理器的總線,那這個(gè)系統(tǒng)更像分布式多操作系統(tǒng).
因微處理器不能用ARPANET或ISO的層次協(xié)議.像"PDSC"(thePacificDataServiceCenter)
和"NMIC"(theNationalMilitaryIntelligenceCenter)系統(tǒng)都不是局域網(wǎng).

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

3:TCP

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

因?yàn)門CP協(xié)議的獨(dú)特的地址機(jī)制(就是說,它用二維整體來表示外部主機(jī)地址,因?yàn)樗?br />知道主機(jī)是否和它在同一個(gè)子網(wǎng)上),它需要一個(gè)接口(IP協(xié)議)來處理不同子網(wǎng)的信息.這種接
口就是IP協(xié)議.盡管IP協(xié)議協(xié)議被設(shè)計(jì)為和TCP協(xié)議協(xié)議獨(dú)立,但它為主機(jī)間的數(shù)據(jù)傳輸提
供了基礎(chǔ).

為了處理不同子網(wǎng)的問題,IP協(xié)議擁有下面的性質(zhì):IP協(xié)議察看一張保存有離一個(gè)主機(jī)
最近的子網(wǎng)的信息(如優(yōu)先級(jí),服務(wù)等級(jí),安全標(biāo)記)的表,從而決定一個(gè)因特網(wǎng)地址是不是在這
個(gè)子網(wǎng)上;假如是,它就把信息發(fā)送給這個(gè)子網(wǎng),否則,它把信息發(fā)送給網(wǎng)關(guān)(它有另一個(gè)IP協(xié)議
模塊).可見,IP協(xié)議協(xié)議處理因特網(wǎng)路由,而TCP協(xié)議協(xié)議處理因特網(wǎng)尋址.因?yàn)橐恍┳泳W(wǎng)傳輸
能力差,只能傳輸小數(shù)據(jù)包,IP協(xié)議協(xié)議還應(yīng)該能把大數(shù)據(jù)包分割成適合相應(yīng)子網(wǎng)的大小.最
后,IP協(xié)議協(xié)議應(yīng)該提供一種機(jī)制,使得它能被其它協(xié)議辨認(rèn)出來.(這是靠層次原則來實(shí)現(xiàn)的:
你不需要了解IP協(xié)議所傳輸?shù)臄?shù)據(jù),只需要了解IP協(xié)議要干什么.)

現(xiàn)在看起來有一點(diǎn)麻煩,因?yàn)橛刑嗟臋C(jī)制.(更完整的討論,清參考文獻(xiàn)[4]).但這些已足
夠證實(shí)我們的觀點(diǎn).一種未公開的協(xié)議是UDP協(xié)議-------用戶數(shù)據(jù)報(bào)協(xié)議.UDP協(xié)議更強(qiáng)調(diào)速
率而不是正確率,它是不可靠的.對于UDP協(xié)議協(xié)議來說,任何一個(gè)數(shù)據(jù)包都建立一個(gè)邏輯連
接..這樣,假如你想多路傳輸數(shù)據(jù),你應(yīng)該用UDP協(xié)議而非TCP協(xié)議.

三:局域網(wǎng)上的TCP協(xié)議

不管你的主機(jī)是否屬于一個(gè)局域網(wǎng),也不管你是否了解TCP/IP協(xié)議,假如你要與因特網(wǎng)
上的另一臺(tái)主機(jī)通信,你必須用TCP協(xié)議.假如你想做一些網(wǎng)絡(luò)上的應(yīng)用(ISO標(biāo)準(zhǔn)協(xié)議上的
第5層的部分服務(wù)和全部第6,7層),就需要TCP/IP協(xié)議,因?yàn)樗ㄟ^邏輯連接提供了可靠性,
數(shù)據(jù)流控制,次序控制等內(nèi)容.但假如你的應(yīng)用不需要TCP協(xié)議的性質(zhì),就不要用它,不管你
是在干什么.假如你想跟同一個(gè)網(wǎng)絡(luò)上的主機(jī)通信,你可以自己設(shè)計(jì)一個(gè)協(xié)議,但這通常是極
其糟糕的.假如你想讓自己的網(wǎng)絡(luò)保持自然狀態(tài),TCP/IP協(xié)議根本不會(huì)阻礙你.但應(yīng)該提醒你,
你的應(yīng)用多需要主機(jī)對主機(jī)的協(xié)議,因此,除非你想搞一個(gè)真正并行的東西……否則,主機(jī)間
的協(xié)議是必不可少的.

現(xiàn)在我要討論性能問題啦.這是一個(gè)非常細(xì)節(jié)化的問題.應(yīng)該指出一點(diǎn):在考慮可靠性的前
提下,許多人(包括我)都為TCP協(xié)議而汗顏.因?yàn)檠芯繖C(jī)構(gòu)在好多種類型的主機(jī)上的實(shí)驗(yàn)表明:
雖然TCP協(xié)議協(xié)議友好的容錯(cuò)性,但它只有12%的效率.這讓我們考慮又沒有必要換一種主機(jī)
對主機(jī)間的協(xié)議來替代TCP協(xié)議.(假如有這樣一種協(xié)議,它也應(yīng)該有TCP協(xié)議協(xié)議的可靠性
這個(gè)優(yōu)點(diǎn).因?yàn)槟闶窃谧鯰CP協(xié)議,而不是LCN,像前邊提到一樣.)

抓住這只Woozle!

四:其它性質(zhì)
下面將闡述TCP/IP的其它性質(zhì):

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

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



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

五:其它有用的數(shù)據(jù)

到這里,我們已經(jīng)把問題討論清楚,但進(jìn)一步分析主機(jī)的性能是合理的,假如僅僅想搞清
楚前面的討論.主機(jī)終端是刷新模式,每一屏的內(nèi)容有16ms.那么中斷1秒鐘能刷新多少次?我
們知道,硬盤尋道時(shí)間是17ms,數(shù)據(jù)從硬盤提取出來要2ms,假如數(shù)據(jù)傳輸?shù)骄W(wǎng)絡(luò)有1ms,那么
加起來就要20ms,盡管主機(jī)什么也沒做.假如本地硬盤的I/O速率是16kb,那么1秒鐘,主機(jī)只
能提供50屏/秒的刷新率,大約800kb/s,這個(gè)速率符合TCP協(xié)議的速率(見性質(zhì)9).在一個(gè)實(shí)際
的系統(tǒng)中,主機(jī)看起來達(dá)不到這個(gè)速率.(主機(jī)數(shù)據(jù)傳輸速率的分析是困難的,因?yàn)樗揽肯到y(tǒng)
內(nèi)部的性能.因?yàn)榻?jīng)典操作系統(tǒng)的本質(zhì),如進(jìn)程間共享?xiàng)５男枰?輸入數(shù)據(jù)占據(jù)內(nèi)存的需要時(shí)
的不可能得到比你所能產(chǎn)生的傳輸率更高的數(shù)據(jù)傳輸率.)

六:結(jié)論:

認(rèn)為TCP協(xié)議協(xié)議不能用于局域網(wǎng)的看法是沒有任何根據(jù)的.TCP協(xié)議協(xié)議完全能
用于局域網(wǎng)中,實(shí)現(xiàn)主機(jī)之間的通信.

七:參考文獻(xiàn)

[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.