組織：中國互動出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者： lou_goodman（lou_goodman  lou_oxygen@163.net）
譯文發(fā)布時間：2001-4-27
版權(quán)：本中文翻譯文檔版權(quán)歸中國互動出版網(wǎng)所有?？梢杂糜诜巧虡I(yè)用途自由轉(zhuǎn)載，但必須
保留本文檔的翻譯及版權(quán)信息。

 
RFC 872        September 1982
 M82-48

局域網(wǎng)上的TCP協(xié)議
（RFC872  TCP-ON-A-LAN）

                                       M.A. PADLIPSKY
                                     THE MITRE CORPORATION
Bedford, Massachusetts


一: 摘要

       在這個文檔里,我們證明那些認為符合DoD(美國國防部)標準的TCP和IP協(xié)議不適
合局域網(wǎng)的觀點是不正確的.這個文檔是和M82-47, M82-49, M82-50, and M82-51緊密聯(lián)系
的.

二: 主旨

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

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

      第一個問題相當簡單[1]:
      一個晴朗的冬日,Piglet正在掃它家門前的雪.他突然發(fā)現(xiàn)Pooh在不停的繞圈圈,好像想
著什么問題.于是Piglet對他說:"
         "喂,你在干什么?"
         "獵取."
         "獵取什么啊?"
         "跟蹤難題."Pooh神秘的說.
         "什么難題?"
         "這正是我在想的問題,我在跟蹤什么問題?"
         "你覺得有答案了嗎?"
         "還沒有.看那."Pooh指著它前面的地面說:"那是什么?"
         "雪痕,動物的爪痕"Piglet興奮的尖叫到,",你不覺得這是一個Woozle嗎!"
         
   于是他們互相是對方相信這就是一個Woozle,一種可怕的動物.他們害怕起來,直到
Christopher Robin 來告訴他們說他們看到的只不過是自己的腳印.

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

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

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

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

   3: TCP

第三個我們需要知道的既直接又微妙.完全依靠我們對ARPANET標準協(xié)議的理解:直觀
上來說,Figure 1 和Figure 2都需要表述清楚,它們意味著ARPANET標準協(xié)議并非一個整體,
而是層次結(jié)構(gòu).為了更清楚的說明這個問題,我們認為:TCP協(xié)議是一個主機對主機協(xié)議(近似
等價于ISO標準協(xié)議的第五層).它的最顯著的性質(zhì)是提供了可靠的邏輯上的連接.(這一點稍
候又會提到.) TCP協(xié)議協(xié)議的另一個顯著性質(zhì)是它是為Catenet(或者說是Internet)而設(shè)計的,
也就是說連接在不同通信子網(wǎng)上的主機之間可以像Catenet上的主機一樣通信.TCP協(xié)議的其
它性質(zhì),像數(shù)據(jù)流控制,邏輯連接管理等很容易設(shè)計啦.
 
 因為TCP協(xié)議的獨特的地址機制(就是說,它用二維整體來表示外部主機地址,因為它不
知道主機是否和它在同一個子網(wǎng)上),它需要一個接口(IP協(xié)議)來處理不同子網(wǎng)的信息.這種接
口就是IP協(xié)議.盡管IP協(xié)議協(xié)議被設(shè)計為和TCP協(xié)議協(xié)議獨立,但它為主機間的數(shù)據(jù)傳輸提
供了基礎(chǔ).

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

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

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

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

抓住這只Woozle! 
                  
四: 其它性質(zhì)
       下面將闡述TCP/IP的其它性質(zhì):

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

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

 

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

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

六: 結(jié)論:

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

七: 參考文獻

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

     [2]  The LAN description is based on Clark, D. D.  et al., "An
          Introduction to Local Area Networks,"  IEEE Proc., V. 66, N.
          11, November 1978, pp. 1497-1517, several year's worth of
          conversations with Dr. Clark, and the author's observations
          of both the open literature and the Oral Tradition (which
          were sufficiently well-thought of to have prompted The MITRE
          Corporation/NBS/NSA Local Nets "Brain Picking Panel" to have
          solicited his testimony during the year he was in FACC's
          employ.*)

     [3]  The TCP/IP descriptions are based on Postel, J. B.,
          "Internet Protocol Specification," and "Transmission Control
          Specification" in DARPA Internet Program Protocol
          Specifications, USC Information Sciences Institute,
          September, 1981, and on more than 10 years' worth of
          conversations with Dr. Postel, Dr. Clark (now the DARPA
          "Internet Architect") and Dr. Vinton G. Cerf (co-originator
          of TCP), and on numerous discussions with several other
          members of the TCP/IP design team, on having edited the
          referenced documents for the PSTP, and, for that matter, on
          having been one of the developers of the ARPANET "Reference
          Model."

     [4]  Padlipsky, M. A., "A Perspective on the ARPANET Reference
          Model", M82-47, The MITRE Corporation, September 1982; also
          available in Proc. INFOCOM '83.

     ________________
     *  In all honesty, as far as I know I started the rumor that TCP
        might be overkill for a LAN at that meeting.  At the next TCP
        design meeting, however, they separated IP out from TCP, and
        everything's been alright for about three years now--except
        for getting the rumor killed.  (I'd worry about Woozles
        turning into roosting chickens if it weren't for the facts
        that:  1.  People tend to ignore their local guru; 2.  I was
        trying to encourage the IP separation; and 3.  All I ever
        wanted was some empirical data.)

     NOTE:  FIGURE 1. ARM in the Abstract, and FIGURE 2.  ARMS,
        Somewhat Particularized, may be obtained by writing to:  Mike
        Padlipsky, MITRE Corporation, P.O. Box 208, Bedford,
        Massachusetts, 01730, or sending computer mail to
        Padlipsky@USC-ISIA.
RFC872  TCP-ON-A-LAN                             局域網(wǎng)上的TCP協(xié)議


1
RFC中文翻譯計劃