轉載自 這裡
TCP/IP 的起源歷史 :
早期的電腦﹐並非如我們日常生活中見到的個人 PC 那樣細小﹔它們大都是以一個集中的中央運算系統﹐用一定的線路與終端系統(輸入輸出設備)連接起來。這樣的一個連接系統﹐就是網路的最初出現形式。各個網路都使用自己的一套規則協定﹐可以說是相互獨立的.
在 1969 年﹐為美蘇冷戰期間﹐美國政府機構試圖發展出一套機制﹐用來連接各個離散的網路系統﹐以應付戰爭危機的需求。這個計劃﹐就是由美國國防部委託 Advanced Research Project Agency 發展的 ARPANET 網路系統﹐研究當部份電腦網路遭到工具而癱瘓後﹐是否能夠透過其他未癱瘓的線路來傳送資料.
ARPANET 的構想和原理﹐除了研發出一套可靠的資料通訊技術外﹐還同時要兼顧跨平臺作業。後來﹐ARPANET 的實驗非常成功﹐從而奠定了今日的網際網路模式﹐它包括了一組電腦通訊細節的網路標準﹐以及一組用來連接網路和選擇網路交通路徑的協定﹐就是大名鼎鼎的 TCP/IP 網際網路協定。 時至 1983 年﹐美國國防部下令用於連接長距離的網路的電話都必須適應 TCP/IP﹐同時 Defense Communication Agency (DCA) 將 ARPANET (Advanced Research Projects Agency Net)分成兩個獨立的網路﹕一個用於研究用途﹐依然叫做 ARPANET﹔另一個用於軍事通訊﹐則稱為 MILNET (Military Network).
ARPA 後來發展出一個開放版本, 以鼓勵大學和研究人員來採用它的協定﹐其時正適逢大部份大學電腦學係的 UNIX 系統需要連接它們的區域網路。由於 UNIX 系統上面研究出來的許多抽象概念與 TCP/IP 的特性有非常高度的吻合﹐再加上設計上的公開性﹐而導致其它組織也紛紛使用 TCP/IP 協定。從 1985 年開始﹐TCP/IP 網路迅速擴展至美國﹑歐洲好幾百個大學﹑政府機構﹑研究實驗室。它的發展大大超過了人們的預期﹐而且每年以超過 15% 的速度成長﹐到了 1994 年﹐使用 TCP/IP 協定的電腦已經超過三百萬台之多。及後數年﹐由於 Internet 的爆炸性成長﹐TCP/IP 協定已經成為無人不知﹑無人不用的電腦網路協定了.
TCP/IP 之標準制定 :
雖然 ARPA 計劃從 1970 年就開始發展交換網路技術﹐到了 1979 年 ARPA 組織了一個委員會叫做 Initernet Control and Configuration Board (ICCB)﹐但事實上 TCP/IP 協定並不屬於某一特定廠商和機構。它的標準是由 Internet Architecture Board (IAB) 所制定的。IAB 目前從屬於 The Internet Society (ISOC)﹐專門在技術上作監控及協調﹐且負責最終端評估及科技監控。
IAB 組織除了自身的委員會之外﹐它主要包含兩個主要團體﹕InternetResearch Task Force (IRTF) ﹐和 Internet Engineering Task Force (IETF)。這兩個團體的職能各有不同﹐IRTF 主要致力於短期和中期的難題﹔而 IETF 則著重處理單一的特別事件﹐其下又分出許多不同題目的成員與工作小組﹐各自從事不同的研究項目﹐研發出網際網路的標準與規格.
由於 TCP/IP 技術的公開性﹐它不屬於任何廠商或專業協會所有﹐因此關於它的相關資訊﹐是由一個叫 Internet Network Information Center (INTERNIC) 來維護和發表﹐以及處理許多網路管理細節(如 DNS 等)。TCP/IP 的標準大部份都以 Request For Comment (RFC) 技術報告的形式公開。RFC 文件包含了所有 TCP/IP 協定標準﹐以及其最新版本。RFC 所涵蓋的內容和細節非常廣﹐也可以為新協定的標準和計劃﹐但不能以學術研究論文的方式來編輯。RFC 有許多有趣且實用的資訊﹐並非僅限於正式的數據通訊協定規範而已. RFC 在全世界很多地方都有它的複製文件﹐可以輕易透過電子郵件﹑FTP 等方式從網際網路取得. (RFC Database)
RFC 是依據其所寫的時間順序來編號的﹐不過 RFC1000 這份文件﹐可以用來做 RFC 文件的指引﹐卻是一個不錯的起始點。閱讀及研究 RFC﹐恐怕是每一個網絡系統管理員必不可少的題目了吧.
TCP/IP 的應用 :
TCP/IP 可以用在任何互連網路上的通訊﹐其可行性在許多地方都已經得到證實﹐包括了家庭﹑校園﹑公司以及全球 61 個國家實驗室。例如在美國就有 National Science Foundation (NFS )﹑Department of Energy (DDE)﹑Department of Defense (DOD)﹑Health and Human Services Agency (HHS)﹐以及 National Aeronautics and Space Administration (NASA)﹐等大機構投注了相當大的資源來開發和應用 TCP/IP 網路.
這些技術的應用﹐讓所有與網路相連的研究人員能夠和全世界的同僚們共同分享資料和研究成果﹐感覺就像隔壁一樣。網路證明了 TCP/IP 的可行性和它優秀的整合性﹐使之能適應各種不同的現行網路技術。對今天的網路發展局面來說﹐TCP/IP 的實作可以說是一個卓越的成就.
TCP/IP 協定不僅成功的連接了不同網路﹐而且許多應用程式和概念也是完全以 TCP/IP 協定為基礎發展出來，從而讓不同的廠商能夠忽略硬體結構開發出共同的應用程式﹐例如今天應用廣泛的 WWW﹑E-MAIL﹑FTP﹑DNS 服務等等.
TCP/IP 的特性 :
對於一個電子郵件的使用者來說﹐他無需透徹了解 TCP/IP 這個協定﹔但對於 TCP/IP 程式人員和網路管理人員來說﹐TCP/IP 的一些特性卻是不能忽略的 :
* Connectionless Packet Delivery Service
* Reliable Stream Transport Service
* Network Technology Independent
* Universal Interconnection
* End-to-End Acknowledgements
* Application Protocol Standards
正式由於 TCP/IP 具備了以上那些有利特性﹐才使得它在眾多的網路連接協定中脫穎而出﹐成為大家喜愛和願意遵守的標準.
TCP/IP 在網路中所扮演的角色 :
TCP/IP 的全稱是 Transmission Control Protocol / Internet Protocol (TCP/IP)﹐當初是用來配合 ARPANET 來處理不同硬體之間的連接問題的﹐比如Sun系統和Mainframe﹑Mainframe和個人電腦之間的連接.
Internet Protocol (IP) 工作於網路層. 它提供了一套標準讓不同的網路有規則可循﹐當然﹐前提是您想使用 IP 從一個網路將封包路由到另一個網路。IP 在設計上是用來在 LAN 和 LAN 及 P C 和 PC 之間進行傳輸﹐每一台 PC 或每一個 LAN﹐都可以由一組 IP 位址來區分。一個 IP 位址的格式是四個用小數點( . ) 分隔開來的十進位數字﹐每各數值介乎於 0 到 255 之間。實實上，每一組數字﹐在 IP 位址中是以 “Octet”的格式承現的，也就是完整的 8 個 bit 。我們會在後面的「網際網路層」中詳細講解 IP 位址的所包含的信息和功用.
您可以把 IP 看成是遊戲規則﹐而 TCP 則用來詮釋這些規則的﹐更準確來說﹐TCP 在 IP 的基礎之上﹐解釋了參與通訊的雙方是如何透過 IP 進行資料傳送的。TCP 提供了一套協定﹐能夠將電腦之間使用的資料透過網路相互傳送﹐同時也提供一套機制來確保資料傳送的準確性和連續性.
雖然 TCP/IP 原先是專門為幾所大學和機構的使用而設計的﹐但現在TCP/IP已經成為最流行的通訊協定了﹐我們使用的Internet就是用TCP/IP來傳送封包的.
2010年11月10日 星期三
2010年11月6日 星期六
[網路教學] 網路概論 : 通訊協定
轉載自 這裡
前言 :
由於網路的迅猛發展﹐出現了許多供網路使用的軟體和硬體﹐為了讓它們都能夠有效的溝通﹐我們需要建立一些規則. 在這裡﹐將介紹目前比較通用的網路通訊協定﹐和模擬數據是如何的從一個節點傳送到另一個節點﹐從功能上面看看通訊協定的定義.
何為通訊協定 :
一個比較好理解的講法是﹕通訊協定就是一些標準和規則。例如﹐我們看到紅燈就要停、綠燈才可以走，者就是一種協定了。若是彼此使用不同的協定，那就會造成混亂：澳洲(或英聯邦)開車考左行使、台灣則靠右。只要所在國家不變，那麼該協定就可以運作，但是當到達協定不一樣的國家，就得進行協定上的轉換了。否則，不出車禍才怪！
在網路通訊中，如果主機 A 要將一個 packet 送給主機 B﹐它們就必須使用相同的通訊協定.
LAN 的工作就是讓應用程式利用網路獲得﹑管理﹑和安排數據. 每一個節點都透過一張網路卡(NIC, Network Interface Card)連接到網路﹐ 再由此和其它的節點溝通. 在每一個獨立的工作站上面﹐已經安裝了一些應用程式﹐如 Word 等。這些程式如果想使用網路上面的資源﹐比如在伺服器上面的數據﹑網路印表機﹑電子郵箱等等﹐會使用網路軟體(network software)去和 NIC 溝通﹐然後 NIC 再和網路上的其它節點溝通. 所有這些信息都要經過轉換﹐就必須要使用通訊協定來確保所有這些參與者﹐能夠彼此理解對方和進行有效的溝通.
正如您所見到的﹐在節點與節點之間﹐最先的交流是在 NIC 的層次上. 當數據從一個節點通過 NIC 傳送到另一個節點之後﹐數據再從 NIC 傳送到網路軟體。而這個網路軟體就是我們所說的傳輸通訊協定(Transport protocol)了﹐ 在雙方的機器上都會有這些 transport protocol. 對於這個所謂的網路軟體﹐可以從好些不同的角度去理解﹐不過我們可以簡單的從三個層次去看 :
* 第一, 也是最容易的理解的﹐就是 NIC 的驅動程式
它負責處理網路卡和傳輸協定之間的溝通。網路卡的廠家都會提供一支驅動程式讓您使用一些特定的協定﹐您可以使用同一張卡來供不同的作業系統使用。只要這張網卡在“物理”上是兼容的﹐那你就可以在作業系統上面使用了.
我們也知道要讓網路卡工作﹐除了要使用正確的驅動程式之外﹐您還得要確定 IRQ 和 IO 要正確。另外﹐在網路卡上面﹐還有一個由 6 組十六進位數字組成的 48bit 的物理位址(Physical Address)﹐也叫 MAC(Media Access Control) Address 或 Node ID﹐等名稱﹐相信我們前面也聽過數次了。這個位址其實分為兩個部份 : 前面三組數字為 Manufacture ID﹐也就是廠商 ID﹔而後面的三組是 Card ID. 如果我們見到一張卡的 MAC 位址是﹕02-60-8C-67-CD-54﹐那麼我們可以知道這張卡是 3Com 的﹐因為 02608C 就是 3Com 的ID。透過這兩組 ID ，我們可以在實體上區分各自的網路卡。理論上來說，全世界沒有兩張卡的 MAC Address 是相同的，而且我們也不應去修改它.
然後﹐基於這個物理位址﹐我們就可以把邏輯位址綑綁於其上。物理位址我們是無法更改的﹐而且您也很難找到兩張相同物理位址的網路卡﹔但邏輯位址則是由網路管理員來設定。就好比您不能將公司地址門牌給改了﹐但您喜歡給您的公司起什麼名字或搬到別的地址去都可以﹐只要不會和其它公司搞混了就行. 如果使用不同的傳輸協定﹐邏輯位址的格式也不相同(後面我們會就會講到這問題了)。但無論是物理位址還是邏輯位址﹐要在網路上面溝通的話﹐就必須不同﹐否則就是所謂的位址衝突啦.
* 第二, 在網路處理程式的另一端﹐需有一個重導向(Redirector) 的軟體
我們知道在單機作業模式下﹐當程式呼叫檔案 IO 的時候﹐會由作業系統接管這個請求﹐然後再傳給 BIOS﹐再到硬體那裡。如果當程式呼叫的檔案 IO 為網路位址的時候﹐那麼 redirector 就會接管這個請求﹐而重新導向到網路上面去﹐把請求交給對方機器。
例如﹐當您使用 Word 的時侯﹐要開啟一個在網路磁碟上面的檔案﹐將會如何呢﹖從 Word 的角度去看﹐它根本不知道有網路這回事﹐它只知道有一個和多個像 A﹕﹑B﹕﹑C﹕這樣的磁碟。就像您吃麥當勞的時候﹐您不用知道漢堡包是怎樣製作出來的﹐您只需知道魚柳包﹑雞柳包和拿到什麼樣的 Kitty 貓就是了。Word 在設計上並不是應用於非本地磁碟上的﹐當要使用存儲在網路上面的數據的時候﹐就必須有一種軟體能夠以磁碟代號的形式告訴 Word 才行。所以﹐如果您告訴 Word 去一個在叫 FILESER1 的伺服器之 DOC 目錄下面找檔案﹐那麼 redirector 軟體就會接管這個請求了 :
然而﹐redirector 在這個網路軟體集團裡面﹐也只是其中一個角色而已﹐要真正能夠拿回資料﹐我們還得需要另一角色的配合﹕ Redirector 只是工作在 client 上面﹐而在 server 那邊﹐還必須有一個檔案系統(File System)﹐或曰 mounter﹐來接應 redirector 的請求. 在網路世界中﹐有許多種這樣的 file system﹐最出名的有 Novell 的 NetWare File System﹑Unix 網路的 Network File System (NFS)﹑以及 Microsoft 的 CIFS (Common Internet File System or Server Message Block)。在 client 端的 redirector 必須要和在 server 上面的 file system 兼容(使用相同的協定)﹐否則 client 也只能望 file 興嘆而已.
* 第三, 終于來到這章的戲肉了﹗出場的就是通訊協定﹐也就是節點和節點之間在網路上搬運數據的方法
之所以將這三個層次的中間部份留在現在才說﹐是因為它是最抽象的。您或許可以這樣想象﹕NIC 驅動程式負責和 NIC 之間的溝通且儘力討其歡心﹔在 client 上面的 redirector 和在 server 上面的 mounter ﹐則和程式溝通﹐也極盡體貼之能事﹔然後通訊協定﹐則出盡法寶綴合 NIC 驅動程式和 redirector (或 mounter)﹐並建立起網路通訊的交通規則.
正如前述﹐通訊協定只是一些標準和規則而已﹐而這些規則令到交流的融合性得以標準化。就如我們不能離開一些經已認同的規矩去使用道路一樣﹐我們的網路也需要一些共同的溝通語言﹐才能讓所有機器相互交流而不至于混亂.
LAN 和 LAN 之間的通訊也一樣需要一些網路語言﹐所以它們都需要有語言大師的本領才行。事實上﹐網路語言有多種多樣﹐由于它們在設計之初只為了應付不同的工作﹐而且它們大部份都從來不考慮要和其它網路兼容的。傳輸協定雖然可說琳琅滿目﹐然而不幸得很﹐各自的廠商都有各自的一套偏好。但又非常幸運的是﹕大部份新的網路作業程式都支持超過一種協定. 下面我們就淺略的瀏覽一些您將會在網路上運用到的通訊協定.
NetBEUI :
讓我們回到 IBM 最初進軍個人電腦網路的時代﹐他們當時的確需要一個很基本的網路通訊協定﹐但他們並不打算用此來建構大型網路﹐僅僅供數十台電腦甚至更小的網路而已。基于這個訴求﹐就誕生了Network Basic Input/Output System﹐或稱 NetBIOS. NetBIOS 其實只有 18 個命令(command)來讓網路的電腦能夠建立﹑維持﹑和使用連接服務。不過 IBM 在不久後又再推出了 NetBIOS 的延伸版本﹕NetBIOS Extened User Interface﹐或稱 NetBEUI﹐基本上是 NetBIOS 的改良版本而已。然而﹐NetBIOS 和 NetBEUI 終究是不同的﹕NetBEUI 事實上可以說是一個傳輸協定﹐而 NetBIOS 充其量只是一組命令來讓系統可以使用網路而已﹐在技術角度來看﹐它是一個 Application Program Interface (API)。關於 NetBIOS 與 NetBEUI 的技術分歧，請參考 :
- Netbios Network Basic Input/Output System Protocols
- NetBios, NetBEUI, NBF, SMB, CIFS Networking
NetBEUI 可以算是您在 LAN 中能夠用到的最快通訊協定了。這個“最快”是指它可以將格式化資料放進封包裡面﹐而接收節點又可以迅速的解讀到內容。然而﹐NetBEUI 卻有一個最致命的弱點﹕它不是可路由(routable)協定﹐也就是不能夠和其它網路的機器對講. 不過﹐Microsoft 網路則運用一種叫 NetBIOS over IP 的技術﹐來連接不同網路的 NetBEUI 客戶。但歸根結底﹐用來達成路由的不是 NetBIOS 而是 TCP/IP﹐也就是下一個要介紹的協定.
TCP/IP :
若說起歷史，TCP/IP 也算得上是個冷戰時代的產物，它是應美國國防部的戰爭考量而提出開發的。TCP/IP 當初是用來配合 ARPANET (Advanced Research Projects Agency Network) 來處理不同硬體之間的連接問題的﹐比如 Sun 系統和 Mainframe﹑Mainframe 和個人電腦之間的連接.
事實上，TCP/IP 所指的是一整套龐大的通訊協定家族，其中以 Transmission Control Protocol(TCP) 及 Internet Protocol (IP) 這兩套協定最具代表性。IP 協定工作於網路層(以後會繼續和大家探討 OSI 的網路層級)﹐它提供了一套標準讓不同的網路有規則可循。當然﹐前提是您想使用 IP 從一個網路將封包路由到另一個網路。IP 在設計上可用來在 LAN-LAN 及 PC-PC 之間進行傳輸的.
您可以把 IP 看成是游戲規則﹐而 TCP 則用來詮釋這些規則的。雖然 TCP/IP 原先是專門為幾所大學和機構的使用而設計的﹐但現在 TCP/IP 已經成為最流行的通訊協定了﹐我們使用的 Internet 就是用 TCP/IP 來傳送封包的了。下面就讓我們看看 TCP/IP 是怎樣工作的.
假如您的公司在好些地方都有分公司﹐各自都有著自己的本地網路(LAN)﹐在總公司跑的是 PC 網路﹐但分公司大部份都是用麥金塔電腦。當 Mac 有數據要傳送給 PC 的時候將會如何呢 ? 首先﹐TCP 會在這兩個平臺建立起一個可以提供全雙工檢錯(對雙向的數據都進行錯誤檢測)的連接. 接著﹐IP 制定好 Mac 和 PC 之間的溝通規則，TCP 與上層協定制定用以連接的埠( port )。到這裡為止﹐Mac 端已經準備好數據了﹐如果數據太大﹐就將之分拆成幾份較小的封包﹐並且在封包上面加上一個新的 header (內含轉送位址)﹐確保封包會被正確傳送。TCP/IP 還會加上標籤說明數據的種類及其長度.
再下來﹐IP 協定將負責將封包傳送給 PC. 最後﹐在 PC 上面的 TCP 將封包解碼並翻譯成 PC 能夠懂的格式﹐也就是它自己所使用的網路協定. 您可以從下圖看到這個過程 :
TCP/IP 可說是現行協定中用途最廣的協定之一﹐它嘗試在所有硬體上實現所有事情。不過﹐它也是最慢的傳輸協定之一﹐在某些情形之下﹐它的傳送速度只有 NetBEUI 的七成。然而，由於 TCP/IP 在設計上可供多種硬體部件使用﹐所以它是一個可路由協定.
網路應用程式界面 (API) :
正如您在上面所讀到的﹐大多數應用程式其實都沒有意識到網路的存在. 不過﹐有些程式﹐如果 e-mail 或群組程式﹐是必須認知到網路﹐更可以說﹐它們是應網路而生的。它們要能夠“插入”到網路中﹐並和其它在網路機器上面跑的程式溝通。程式設計者建立的網路應用程式﹐都要適應於網路給應用程式的一套指令﹐這些指令就是所謂的 API 了.
如果您懂得開汽車的話﹐您一定知道當初學開車的時候是先學如何踏油門﹑如何踩煞車﹑如何轉向等基本動作. 我們可以將這些動作看成是一些“原始命令”﹐通過這些命令我們就可以做出將汽車倒出車庫然後開到目的地, 雖然學車的時候是沒有諸如“倒出車庫”的動作。那麼我們就可以將 API 當成是那些學車的“基本動作”，也就是所謂的操作界面.
在那些網路服務中﹐比如 redirector ﹐可以居於各種不同的傳輸協定之上﹐如果沒有 API ﹐您的網路軟體程式就要開發一個 redirector 程式來接通 IPX/SPX ﹐又要另外一個 redirector 程式接通 TCP/IP 了。其實來來去去都是同一個 redirector ﹐只是和不同的協定連接而已﹐而 API 則提供了一個共同的界面給所有網路服務使用. 這樣﹐我們就算開 BMW 或 Benz 都知道如何操作了. 但您未必會開游艇哦﹐因為汽車和游艇 API 是不同的。當然﹐如果有台汽車的油門是在左邊﹑煞車在右邊﹑離合器卻在中間﹑不用方向盤而是用搖竿﹗我們也可以說這台車的 API 是不同的.
剛才說的 redirector 並不是寫來供通訊協定使用﹐而是給一個 API 使用(在我們的例子中是 NetBIOS ). NetBIOS 可以居於 IPX/SPX﹑NetBEUI﹑和 TCP/IP 這些協定之上。這樣有個好處是﹐您可以改變您的通訊協定﹐而無需重寫您的網路服務﹐因為您的網路服務是針對API來寫的。API 會接管您的網路請求﹐然後運用正確的通訊協定進行工作.
您或許聽過 socket 這個詞﹐它其實就是 API 啦。在網路世界中﹐有三種 API 您或許會接觸到的 :
OSI 模型 :
有好幾個主要電腦廠家﹐如 IBM﹑DEC﹑Burroughs 等﹐都有設計它們各自的網路結構和通訊協定﹐如果採用這些設計的機器﹐在其各自的網路上面運作良好﹐但卻不能在不同廠家的機器之間進行溝通。為了解決這個問題﹐International Standardization Organisation (ISO) 於 1978 年開始開發一套標準架構﹐終於成功推出 Reference Model for Open System Interconnection (OSI) 作為其標準﹐它提供了一個很有用的模型去解釋各個不同層面的網路協定. OSI 模型共有七個層面﹐且它們可以被劃分為兩組 :
您也可以從下圖看到些協定層的排列 :
前面我們集中討論的就是其中的底層協定﹐也就是網路協定﹐這些功能是保障數據在網路中能夠迅速且準確的轉送.
實體層
資料連接層
網路層
在底下的三層之上﹐還有四層是屬于使用者功能範圍的﹐不過它們也常常會被整合在一起。您要記住的一點是﹕無論程式設計者如何定義這些協定﹐(例如﹐把它們分為兩層或四層)﹐這四層在實際上都會被執行的。
傳送層
會談層
表現層
應用層
前言 :
由於網路的迅猛發展﹐出現了許多供網路使用的軟體和硬體﹐為了讓它們都能夠有效的溝通﹐我們需要建立一些規則. 在這裡﹐將介紹目前比較通用的網路通訊協定﹐和模擬數據是如何的從一個節點傳送到另一個節點﹐從功能上面看看通訊協定的定義.
何為通訊協定 :
一個比較好理解的講法是﹕通訊協定就是一些標準和規則。例如﹐我們看到紅燈就要停、綠燈才可以走，者就是一種協定了。若是彼此使用不同的協定，那就會造成混亂：澳洲(或英聯邦)開車考左行使、台灣則靠右。只要所在國家不變，那麼該協定就可以運作，但是當到達協定不一樣的國家，就得進行協定上的轉換了。否則，不出車禍才怪！
在網路通訊中，如果主機 A 要將一個 packet 送給主機 B﹐它們就必須使用相同的通訊協定.
LAN 的工作就是讓應用程式利用網路獲得﹑管理﹑和安排數據. 每一個節點都透過一張網路卡(NIC, Network Interface Card)連接到網路﹐ 再由此和其它的節點溝通. 在每一個獨立的工作站上面﹐已經安裝了一些應用程式﹐如 Word 等。這些程式如果想使用網路上面的資源﹐比如在伺服器上面的數據﹑網路印表機﹑電子郵箱等等﹐會使用網路軟體(network software)去和 NIC 溝通﹐然後 NIC 再和網路上的其它節點溝通. 所有這些信息都要經過轉換﹐就必須要使用通訊協定來確保所有這些參與者﹐能夠彼此理解對方和進行有效的溝通.
正如您所見到的﹐在節點與節點之間﹐最先的交流是在 NIC 的層次上. 當數據從一個節點通過 NIC 傳送到另一個節點之後﹐數據再從 NIC 傳送到網路軟體。而這個網路軟體就是我們所說的傳輸通訊協定(Transport protocol)了﹐ 在雙方的機器上都會有這些 transport protocol. 對於這個所謂的網路軟體﹐可以從好些不同的角度去理解﹐不過我們可以簡單的從三個層次去看 :
* 第一, 也是最容易的理解的﹐就是 NIC 的驅動程式
它負責處理網路卡和傳輸協定之間的溝通。網路卡的廠家都會提供一支驅動程式讓您使用一些特定的協定﹐您可以使用同一張卡來供不同的作業系統使用。只要這張網卡在“物理”上是兼容的﹐那你就可以在作業系統上面使用了.
我們也知道要讓網路卡工作﹐除了要使用正確的驅動程式之外﹐您還得要確定 IRQ 和 IO 要正確。另外﹐在網路卡上面﹐還有一個由 6 組十六進位數字組成的 48bit 的物理位址(Physical Address)﹐也叫 MAC(Media Access Control) Address 或 Node ID﹐等名稱﹐相信我們前面也聽過數次了。這個位址其實分為兩個部份 : 前面三組數字為 Manufacture ID﹐也就是廠商 ID﹔而後面的三組是 Card ID. 如果我們見到一張卡的 MAC 位址是﹕02-60-8C-67-CD-54﹐那麼我們可以知道這張卡是 3Com 的﹐因為 02608C 就是 3Com 的ID。透過這兩組 ID ，我們可以在實體上區分各自的網路卡。理論上來說，全世界沒有兩張卡的 MAC Address 是相同的，而且我們也不應去修改它.
然後﹐基於這個物理位址﹐我們就可以把邏輯位址綑綁於其上。物理位址我們是無法更改的﹐而且您也很難找到兩張相同物理位址的網路卡﹔但邏輯位址則是由網路管理員來設定。就好比您不能將公司地址門牌給改了﹐但您喜歡給您的公司起什麼名字或搬到別的地址去都可以﹐只要不會和其它公司搞混了就行. 如果使用不同的傳輸協定﹐邏輯位址的格式也不相同(後面我們會就會講到這問題了)。但無論是物理位址還是邏輯位址﹐要在網路上面溝通的話﹐就必須不同﹐否則就是所謂的位址衝突啦.
* 第二, 在網路處理程式的另一端﹐需有一個重導向(Redirector) 的軟體
我們知道在單機作業模式下﹐當程式呼叫檔案 IO 的時候﹐會由作業系統接管這個請求﹐然後再傳給 BIOS﹐再到硬體那裡。如果當程式呼叫的檔案 IO 為網路位址的時候﹐那麼 redirector 就會接管這個請求﹐而重新導向到網路上面去﹐把請求交給對方機器。
例如﹐當您使用 Word 的時侯﹐要開啟一個在網路磁碟上面的檔案﹐將會如何呢﹖從 Word 的角度去看﹐它根本不知道有網路這回事﹐它只知道有一個和多個像 A﹕﹑B﹕﹑C﹕這樣的磁碟。就像您吃麥當勞的時候﹐您不用知道漢堡包是怎樣製作出來的﹐您只需知道魚柳包﹑雞柳包和拿到什麼樣的 Kitty 貓就是了。Word 在設計上並不是應用於非本地磁碟上的﹐當要使用存儲在網路上面的數據的時候﹐就必須有一種軟體能夠以磁碟代號的形式告訴 Word 才行。所以﹐如果您告訴 Word 去一個在叫 FILESER1 的伺服器之 DOC 目錄下面找檔案﹐那麼 redirector 軟體就會接管這個請求了 :
然而﹐redirector 在這個網路軟體集團裡面﹐也只是其中一個角色而已﹐要真正能夠拿回資料﹐我們還得需要另一角色的配合﹕ Redirector 只是工作在 client 上面﹐而在 server 那邊﹐還必須有一個檔案系統(File System)﹐或曰 mounter﹐來接應 redirector 的請求. 在網路世界中﹐有許多種這樣的 file system﹐最出名的有 Novell 的 NetWare File System﹑Unix 網路的 Network File System (NFS)﹑以及 Microsoft 的 CIFS (Common Internet File System or Server Message Block)。在 client 端的 redirector 必須要和在 server 上面的 file system 兼容(使用相同的協定)﹐否則 client 也只能望 file 興嘆而已.
* 第三, 終于來到這章的戲肉了﹗出場的就是通訊協定﹐也就是節點和節點之間在網路上搬運數據的方法
之所以將這三個層次的中間部份留在現在才說﹐是因為它是最抽象的。您或許可以這樣想象﹕NIC 驅動程式負責和 NIC 之間的溝通且儘力討其歡心﹔在 client 上面的 redirector 和在 server 上面的 mounter ﹐則和程式溝通﹐也極盡體貼之能事﹔然後通訊協定﹐則出盡法寶綴合 NIC 驅動程式和 redirector (或 mounter)﹐並建立起網路通訊的交通規則.
正如前述﹐通訊協定只是一些標準和規則而已﹐而這些規則令到交流的融合性得以標準化。就如我們不能離開一些經已認同的規矩去使用道路一樣﹐我們的網路也需要一些共同的溝通語言﹐才能讓所有機器相互交流而不至于混亂.
LAN 和 LAN 之間的通訊也一樣需要一些網路語言﹐所以它們都需要有語言大師的本領才行。事實上﹐網路語言有多種多樣﹐由于它們在設計之初只為了應付不同的工作﹐而且它們大部份都從來不考慮要和其它網路兼容的。傳輸協定雖然可說琳琅滿目﹐然而不幸得很﹐各自的廠商都有各自的一套偏好。但又非常幸運的是﹕大部份新的網路作業程式都支持超過一種協定. 下面我們就淺略的瀏覽一些您將會在網路上運用到的通訊協定.
NetBEUI :
讓我們回到 IBM 最初進軍個人電腦網路的時代﹐他們當時的確需要一個很基本的網路通訊協定﹐但他們並不打算用此來建構大型網路﹐僅僅供數十台電腦甚至更小的網路而已。基于這個訴求﹐就誕生了Network Basic Input/Output System﹐或稱 NetBIOS. NetBIOS 其實只有 18 個命令(command)來讓網路的電腦能夠建立﹑維持﹑和使用連接服務。不過 IBM 在不久後又再推出了 NetBIOS 的延伸版本﹕NetBIOS Extened User Interface﹐或稱 NetBEUI﹐基本上是 NetBIOS 的改良版本而已。然而﹐NetBIOS 和 NetBEUI 終究是不同的﹕NetBEUI 事實上可以說是一個傳輸協定﹐而 NetBIOS 充其量只是一組命令來讓系統可以使用網路而已﹐在技術角度來看﹐它是一個 Application Program Interface (API)。關於 NetBIOS 與 NetBEUI 的技術分歧，請參考 :
- Netbios Network Basic Input/Output System Protocols
- NetBios, NetBEUI, NBF, SMB, CIFS Networking
NetBEUI 可以算是您在 LAN 中能夠用到的最快通訊協定了。這個“最快”是指它可以將格式化資料放進封包裡面﹐而接收節點又可以迅速的解讀到內容。然而﹐NetBEUI 卻有一個最致命的弱點﹕它不是可路由(routable)協定﹐也就是不能夠和其它網路的機器對講. 不過﹐Microsoft 網路則運用一種叫 NetBIOS over IP 的技術﹐來連接不同網路的 NetBEUI 客戶。但歸根結底﹐用來達成路由的不是 NetBIOS 而是 TCP/IP﹐也就是下一個要介紹的協定.
TCP/IP :
若說起歷史，TCP/IP 也算得上是個冷戰時代的產物，它是應美國國防部的戰爭考量而提出開發的。TCP/IP 當初是用來配合 ARPANET (Advanced Research Projects Agency Network) 來處理不同硬體之間的連接問題的﹐比如 Sun 系統和 Mainframe﹑Mainframe 和個人電腦之間的連接.
事實上，TCP/IP 所指的是一整套龐大的通訊協定家族，其中以 Transmission Control Protocol(TCP) 及 Internet Protocol (IP) 這兩套協定最具代表性。IP 協定工作於網路層(以後會繼續和大家探討 OSI 的網路層級)﹐它提供了一套標準讓不同的網路有規則可循。當然﹐前提是您想使用 IP 從一個網路將封包路由到另一個網路。IP 在設計上可用來在 LAN-LAN 及 PC-PC 之間進行傳輸的.
您可以把 IP 看成是游戲規則﹐而 TCP 則用來詮釋這些規則的。雖然 TCP/IP 原先是專門為幾所大學和機構的使用而設計的﹐但現在 TCP/IP 已經成為最流行的通訊協定了﹐我們使用的 Internet 就是用 TCP/IP 來傳送封包的了。下面就讓我們看看 TCP/IP 是怎樣工作的.
假如您的公司在好些地方都有分公司﹐各自都有著自己的本地網路(LAN)﹐在總公司跑的是 PC 網路﹐但分公司大部份都是用麥金塔電腦。當 Mac 有數據要傳送給 PC 的時候將會如何呢 ? 首先﹐TCP 會在這兩個平臺建立起一個可以提供全雙工檢錯(對雙向的數據都進行錯誤檢測)的連接. 接著﹐IP 制定好 Mac 和 PC 之間的溝通規則，TCP 與上層協定制定用以連接的埠( port )。到這裡為止﹐Mac 端已經準備好數據了﹐如果數據太大﹐就將之分拆成幾份較小的封包﹐並且在封包上面加上一個新的 header (內含轉送位址)﹐確保封包會被正確傳送。TCP/IP 還會加上標籤說明數據的種類及其長度.
再下來﹐IP 協定將負責將封包傳送給 PC. 最後﹐在 PC 上面的 TCP 將封包解碼並翻譯成 PC 能夠懂的格式﹐也就是它自己所使用的網路協定. 您可以從下圖看到這個過程 :
TCP/IP 可說是現行協定中用途最廣的協定之一﹐它嘗試在所有硬體上實現所有事情。不過﹐它也是最慢的傳輸協定之一﹐在某些情形之下﹐它的傳送速度只有 NetBEUI 的七成。然而，由於 TCP/IP 在設計上可供多種硬體部件使用﹐所以它是一個可路由協定.
網路應用程式界面 (API) :
正如您在上面所讀到的﹐大多數應用程式其實都沒有意識到網路的存在. 不過﹐有些程式﹐如果 e-mail 或群組程式﹐是必須認知到網路﹐更可以說﹐它們是應網路而生的。它們要能夠“插入”到網路中﹐並和其它在網路機器上面跑的程式溝通。程式設計者建立的網路應用程式﹐都要適應於網路給應用程式的一套指令﹐這些指令就是所謂的 API 了.
如果您懂得開汽車的話﹐您一定知道當初學開車的時候是先學如何踏油門﹑如何踩煞車﹑如何轉向等基本動作. 我們可以將這些動作看成是一些“原始命令”﹐通過這些命令我們就可以做出將汽車倒出車庫然後開到目的地, 雖然學車的時候是沒有諸如“倒出車庫”的動作。那麼我們就可以將 API 當成是那些學車的“基本動作”，也就是所謂的操作界面.
在那些網路服務中﹐比如 redirector ﹐可以居於各種不同的傳輸協定之上﹐如果沒有 API ﹐您的網路軟體程式就要開發一個 redirector 程式來接通 IPX/SPX ﹐又要另外一個 redirector 程式接通 TCP/IP 了。其實來來去去都是同一個 redirector ﹐只是和不同的協定連接而已﹐而 API 則提供了一個共同的界面給所有網路服務使用. 這樣﹐我們就算開 BMW 或 Benz 都知道如何操作了. 但您未必會開游艇哦﹐因為汽車和游艇 API 是不同的。當然﹐如果有台汽車的油門是在左邊﹑煞車在右邊﹑離合器卻在中間﹑不用方向盤而是用搖竿﹗我們也可以說這台車的 API 是不同的.
剛才說的 redirector 並不是寫來供通訊協定使用﹐而是給一個 API 使用(在我們的例子中是 NetBIOS ). NetBIOS 可以居於 IPX/SPX﹑NetBEUI﹑和 TCP/IP 這些協定之上。這樣有個好處是﹐您可以改變您的通訊協定﹐而無需重寫您的網路服務﹐因為您的網路服務是針對API來寫的。API 會接管您的網路請求﹐然後運用正確的通訊協定進行工作.
您或許聽過 socket 這個詞﹐它其實就是 API 啦。在網路世界中﹐有三種 API 您或許會接觸到的 :
OSI 模型 :
有好幾個主要電腦廠家﹐如 IBM﹑DEC﹑Burroughs 等﹐都有設計它們各自的網路結構和通訊協定﹐如果採用這些設計的機器﹐在其各自的網路上面運作良好﹐但卻不能在不同廠家的機器之間進行溝通。為了解決這個問題﹐International Standardization Organisation (ISO) 於 1978 年開始開發一套標準架構﹐終於成功推出 Reference Model for Open System Interconnection (OSI) 作為其標準﹐它提供了一個很有用的模型去解釋各個不同層面的網路協定. OSI 模型共有七個層面﹐且它們可以被劃分為兩組 :
您也可以從下圖看到些協定層的排列 :
前面我們集中討論的就是其中的底層協定﹐也就是網路協定﹐這些功能是保障數據在網路中能夠迅速且準確的轉送.
實體層
資料連接層
網路層
在底下的三層之上﹐還有四層是屬于使用者功能範圍的﹐不過它們也常常會被整合在一起。您要記住的一點是﹕無論程式設計者如何定義這些協定﹐(例如﹐把它們分為兩層或四層)﹐這四層在實際上都會被執行的。
傳送層
會談層
表現層
應用層
This message was edited 3 times. Last update was at 17/07/2010 15:20:28
[網路教學] TCP/IP 基礎 : ARP 協定
參考至 這裡
前言 :
嚴格來說，TCP/IP 協定家族並沒有定義 "TCP/IP 專屬的" 網路硬體規格。硬體的範圍實在太過廣泛了﹐標準非常多﹐當今大部份的低層網路硬體標準都是由 IEEE 制定的，但也有許多標準是廠商專屬的。要讓 TCP/IP 協定能夠順利與不同類型的硬體進行溝通﹐那麼就需要建立起一些標準協定來讓大家共同參考。以我們最常用的乙太網(Ethernet)為例﹐我們無需理會廠商如何設計網路界面的驅動程式﹐一旦它能夠被系統接納﹐網路儲存層(Datalink)就能使用網路界面在實體網路上傳送和接收資料了.
IP 位址和實體位址對應之困擾 :
在「網路基礎」課程中﹐我們知道乙太網上面使用的傳送方式叫 CSMA/CD (Carrier-Sensing Multiple Access with Collision Detection)﹕雖然訊框會在整個網段(segment)中用廣播的方式傳遞﹐而且所有節點都會收到訊框﹐然而﹐只有目的位址符合自己實體位址的訊框才會被接收下來。因此，不管上層協定是哪一種(可以是 TCP/IP 也可以是其它)，在底層的傳送若是使用 Ethernet 的話，就得使用 MAC (Media Access Control) 實體位址。若要查詢到當前系統目前所有界面的實體位址，我們可在 Linux 系統裡面輸入 ifconfig 命令 :
從上面的命令結果中可發現 : 關於每一個界面的第一行資訊﹐最後的部份就是該界面的實體位址。訊框在實體網路上面傳送的過程中﹐IP 位址(或曰羅輯位址)一點都派不上用場。但問題是：當我們使用 TCP/IP 的時侯，上層的協定都是以 IP 位址為傳送依據的。那麼﹐這時候我們就必須有一套方法來對應 IP 位址和實體位址了.
在此一過程中﹐關鍵點是如果將 IP 位址對與實體位址做對應。有些使用簡單實體位址的網路(如 proNET-10 )﹐其實體位址只佔一個 byte 的長度﹐而且允許使用者在配置網路卡的是選擇自己的實體位址。在這樣的網路上進行 IP 位址和實體位址的對應﹐是比較簡單的﹐我們可以把實體位址設為和 IP 位址設為一樣。例如﹐假設某一個節點的 IP 位址為 192.168.1.17﹐那麼我們可以將該實體位址設為 17。 這樣﹐在 proNET 就可以輕易的根據 IP 位址來得到實體位址。這樣的對應非常簡單﹐而且要維護起來也很容易﹐在新機器假如網路的時候﹐並不需要修改或重編已存的資料.
然而﹐我們知道在乙太網上﹐每一個實體界面都有一個 48bit(6byte) 的 MAC 位址﹐而 IP (v4)使用的位址則為 32bit(4byte)﹔每各位址格式都只提供相應的層級協定使用﹐彼此是不能互換使用的。這時候我們就無法用簡單的數學關係來做 IP 位址和實體位址的對應了.
IP 位址和實體位址的對應方法 :
- 建立表格
首先﹐我們想到的最簡單方法是在每一台機器上建立一個 IP 位址和實體位址的對應表格( table )。不過這個方法還是沒辦法解決如下的情形 :
- 寫入高階程式
除了建立表格﹐我們還可以將實際的網路位址寫死在高階網路程式裡面。不過﹐和前一個方法一樣﹐如果遇到硬體位址變更等異動動情形﹐那麼﹐程式也需要重新編譯過才行. 顯然﹐上述兩個方法都不怎麼高明.
ARP 協定 :
這裡我們要介紹的是 Address Resolution Protocol (ARP)。 ARP 是 TCP/IP 設計者利用乙太網的廣播性質﹐設計出來的位址解釋協定。它的主要特性和優點是它的位址對應關係是動態的﹐它以查詢的方式來獲得 IP 位址和實體位址的對應。它的工作原理非常簡單 :
ARP 的查詢過程可參考下圖 :
前面說的 ARP 表格﹐只有在 TCP/IP 協定被載入核心之後才會建立﹐如果 TCP/IP 協定被卸載或關閉機器﹐那麼表格就會被清空﹔到下次協定載入或開機的時候再重新建立﹐而同時會向網路發出一個 ARP 廣播﹐告訴其它機器它的目前位址是什麼﹐以便所有機器都能保持最正確的資料.
然而﹐ARP cache 的大小是有所限制的﹐如果超過了界限﹐那麼越長時間沒被使用過渡資料就必須清理掉﹐以騰出空間來儲存更新的資料。所以﹐當機器收到 ARP equest 封包時﹐如果查詢對象不是自己﹐則不會根據發送端位址資料來更新自己的 ARP 表格﹐而是完全忽略該封包。同時﹐每筆存在 cache 中的資料﹐都不是永久保存的﹕每筆資料再更新的時候﹐都會被賦予一個存活倒數計時值﹐如果在倒數時間到達的時候﹐該資料就會被清掉。然而﹐如果該資料在倒數時間到達之前被使用過﹐則計時值會被重新賦予.
當然了﹐ARP 尚有一套機制來處理當 ARP 表格資料不符合實際位址資料的狀況, 如目的主機太忙碌而未能回答 ARP 請求等狀況.
RARP 協定 :
剛才介紹的 ARP 協定是透過向網路查詢而找出實體位址﹐那我們接下來探討的 RARP 協定則相反﹕它是籍由查詢網路上其它主機而得到自己的 IP 位址.
通常﹐我們使用的乙太網卡﹐在出廠的時候就有生產廠家把網卡的實體位址燒在 ROM 裡面﹐這個位址是不能改變的(某些型號的網路卡﹐或是透過其它技術手段﹐是允許您修改實體位址的)。不管系統是否起來﹐這個位址都會存在﹐而且要讓系統獲得它也很容易。然而，在一些無磁碟(diskless)工作站上面﹐系統檔案都存放在遠端的伺服器﹐當它在啟動的時候﹐因為本身沒有 IP 位址﹐也就無法和伺服器溝通﹐更不能將系統檔案載入。那麼﹐我們就必須要有一個辦法﹐讓這樣的無磁碟工作站在和伺服器溝通之前獲得自己的 IP 位址。RAPR 協定就是為解決此問題而設計出來的.
RARP 也是用廣播的形式來進行查詢. 只不過這時候問的 IP 位址不是別人而是自己的 IP 位址而已. 我們可以從下圖看出 RARP 的運作﹐其實和 ARP 是極其相似的 :
首先是查詢主機向網路送出一個 RARP Request 廣播封包﹐向別的主機查詢自己的 IP。在時候﹐網路上的 RARP 伺服器就會將發送端的 IP 位址用 RARP Reply 封包回應給查詢者。這樣查詢主機就獲得自己的 IP 位址了.
然而不像 ARP﹐查詢主機將 RARP Request 封包丟出去之後﹐可能得到的 RARP Reply 會不止一個 (在 ARP 查詢中﹐我們可以確定只會獲得一個回應而已)。因為網路上可能存在不止一台 RARP 伺服器(基於備份和分擔考量﹐極有可能如此設計)﹐那麼﹐所有收到 RARP 請求的伺服器都會嘗試向查詢主機作出 RARP Reply 回應。如果這樣的話﹐網路上將充斥這種 RARP 回應﹐做成額外的負荷。這時候﹐我們有兩種方法來解決RARP 的回應問題 :
PROXY ARP :
代理 (Proxy) ARP 通常用來在路由器上代為回答在它後面的某個網路主機的 ARP 請求。這是一種欺騙手法﹐因為查詢端會以為目標主機就是路由器本身﹐但事實上﹐機器是在另一個網路裡面. Proxy ARP 常使用於遠端連接網路(如撥接)環境中。例如在本地網路中有一台撥接主機﹐提供其他主機撥接上來連接本地網。當本地主機要查詢遠端撥接主機的 ARP 請求的時候﹐因為它的廣播封包是無法到達遠端的﹔此時撥接伺服器就可以代替遠端主機回答這個 ARP 請求﹐然後本地主機就將封包送給撥接伺服器﹐伺服器再將封包傳給遠端主機.
ARP 指令 :
假如您要在 Linux 系統上驗證一下前面所學的理論﹐只要您的網路功能已經設好﹐您可以用 arp 命令來檢查當前的 ARP 表格內容 :
在 Linux 系統中﹐輸入 arp 帶一個 -n 的參數﹐是將資料用數字(number)的形式顯示﹐否則它將嘗試用 DNS 或其他主機對應方式來顯示 IP 所對應的主機名稱。大家可以很輕易在每一行資料中找到 IP 位址和實體位址的對應﹐同時還有硬體類型等信息.
假如此時您下一個 ping 命令﹐連接一台沒有在 ARP 表格中出現的 IP :
此時您再次輸入 arp 命令的話﹐您將發現新主機的 ARP 資料 :
如果您把這台主機從網路上斷開﹐確定它不會再發送 ARP 請求或作出 ARP 回應﹐那麼過大約 20 分鐘後再輸入 arp 命令﹐您很可能發現許多 ARP 記錄都已經消失了﹐這就是資料存活倒數計時的後果. 假如您的 Linux 系統還裝有封包擷取軟體﹐如 tcpdump ﹐您可以在此期間抓些封包看看﹐細心點就能看出 ARP Request 和 ARP Reply 的過程.
您如果還有興趣的話﹐還可以找些更強勁的封包擷取工具(如﹕snifit)﹐把 ARP 封包的所有細節都抓出來看看。不過這裡暫時不做這樣的動作了。至於如何檢查封包的每一個細節﹐我們將在後面介紹 IP 和 TCP 封包的時候再介紹.
我們用 arp 不僅能查看當前的 ARP 記錄﹐而且我們還可以用 arp 命令來建立 ARP 記錄﹐例如﹐我們前面提到過的 Proxy ARP 功能﹐我們可以用中間的路由器來「隱藏」兩端的網路 :
上面 arp 命令中的 -s 參數就是用來設定 (set) 一個 ARP 記錄的。接著在輸入 arp 命令﹐就會發現剛纔設定的資料旗標為 MP 。這樣﹐當另一端網路要查詢 211.20.240.115 的時候﹐這個 Linux 路由器就能夠代為回應了.
ARP 之 RFC 文件 :
ARP 的詳細資料可以查詢 RFC-826﹑RFC-814﹑以及 RFC-1166 等文件。而 RARP 的資料則可以參考 RFC-903﹑RFC-906﹑還有 RFC-1293 等文件.
前言 :
嚴格來說，TCP/IP 協定家族並沒有定義 "TCP/IP 專屬的" 網路硬體規格。硬體的範圍實在太過廣泛了﹐標準非常多﹐當今大部份的低層網路硬體標準都是由 IEEE 制定的，但也有許多標準是廠商專屬的。要讓 TCP/IP 協定能夠順利與不同類型的硬體進行溝通﹐那麼就需要建立起一些標準協定來讓大家共同參考。以我們最常用的乙太網(Ethernet)為例﹐我們無需理會廠商如何設計網路界面的驅動程式﹐一旦它能夠被系統接納﹐網路儲存層(Datalink)就能使用網路界面在實體網路上傳送和接收資料了.
IP 位址和實體位址對應之困擾 :
在「網路基礎」課程中﹐我們知道乙太網上面使用的傳送方式叫 CSMA/CD (Carrier-Sensing Multiple Access with Collision Detection)﹕雖然訊框會在整個網段(segment)中用廣播的方式傳遞﹐而且所有節點都會收到訊框﹐然而﹐只有目的位址符合自己實體位址的訊框才會被接收下來。因此，不管上層協定是哪一種(可以是 TCP/IP 也可以是其它)，在底層的傳送若是使用 Ethernet 的話，就得使用 MAC (Media Access Control) 實體位址。若要查詢到當前系統目前所有界面的實體位址，我們可在 Linux 系統裡面輸入 ifconfig 命令 :
從上面的命令結果中可發現 : 關於每一個界面的第一行資訊﹐最後的部份就是該界面的實體位址。訊框在實體網路上面傳送的過程中﹐IP 位址(或曰羅輯位址)一點都派不上用場。但問題是：當我們使用 TCP/IP 的時侯，上層的協定都是以 IP 位址為傳送依據的。那麼﹐這時候我們就必須有一套方法來對應 IP 位址和實體位址了.
在此一過程中﹐關鍵點是如果將 IP 位址對與實體位址做對應。有些使用簡單實體位址的網路(如 proNET-10 )﹐其實體位址只佔一個 byte 的長度﹐而且允許使用者在配置網路卡的是選擇自己的實體位址。在這樣的網路上進行 IP 位址和實體位址的對應﹐是比較簡單的﹐我們可以把實體位址設為和 IP 位址設為一樣。例如﹐假設某一個節點的 IP 位址為 192.168.1.17﹐那麼我們可以將該實體位址設為 17。 這樣﹐在 proNET 就可以輕易的根據 IP 位址來得到實體位址。這樣的對應非常簡單﹐而且要維護起來也很容易﹐在新機器假如網路的時候﹐並不需要修改或重編已存的資料.
然而﹐我們知道在乙太網上﹐每一個實體界面都有一個 48bit(6byte) 的 MAC 位址﹐而 IP (v4)使用的位址則為 32bit(4byte)﹔每各位址格式都只提供相應的層級協定使用﹐彼此是不能互換使用的。這時候我們就無法用簡單的數學關係來做 IP 位址和實體位址的對應了.
IP 位址和實體位址的對應方法 :
- 建立表格
首先﹐我們想到的最簡單方法是在每一台機器上建立一個 IP 位址和實體位址的對應表格( table )。不過這個方法還是沒辦法解決如下的情形 :
- 寫入高階程式
除了建立表格﹐我們還可以將實際的網路位址寫死在高階網路程式裡面。不過﹐和前一個方法一樣﹐如果遇到硬體位址變更等異動動情形﹐那麼﹐程式也需要重新編譯過才行. 顯然﹐上述兩個方法都不怎麼高明.
ARP 協定 :
這裡我們要介紹的是 Address Resolution Protocol (ARP)。 ARP 是 TCP/IP 設計者利用乙太網的廣播性質﹐設計出來的位址解釋協定。它的主要特性和優點是它的位址對應關係是動態的﹐它以查詢的方式來獲得 IP 位址和實體位址的對應。它的工作原理非常簡單 :
ARP 的查詢過程可參考下圖 :
前面說的 ARP 表格﹐只有在 TCP/IP 協定被載入核心之後才會建立﹐如果 TCP/IP 協定被卸載或關閉機器﹐那麼表格就會被清空﹔到下次協定載入或開機的時候再重新建立﹐而同時會向網路發出一個 ARP 廣播﹐告訴其它機器它的目前位址是什麼﹐以便所有機器都能保持最正確的資料.
然而﹐ARP cache 的大小是有所限制的﹐如果超過了界限﹐那麼越長時間沒被使用過渡資料就必須清理掉﹐以騰出空間來儲存更新的資料。所以﹐當機器收到 ARP equest 封包時﹐如果查詢對象不是自己﹐則不會根據發送端位址資料來更新自己的 ARP 表格﹐而是完全忽略該封包。同時﹐每筆存在 cache 中的資料﹐都不是永久保存的﹕每筆資料再更新的時候﹐都會被賦予一個存活倒數計時值﹐如果在倒數時間到達的時候﹐該資料就會被清掉。然而﹐如果該資料在倒數時間到達之前被使用過﹐則計時值會被重新賦予.
當然了﹐ARP 尚有一套機制來處理當 ARP 表格資料不符合實際位址資料的狀況, 如目的主機太忙碌而未能回答 ARP 請求等狀況.
RARP 協定 :
剛才介紹的 ARP 協定是透過向網路查詢而找出實體位址﹐那我們接下來探討的 RARP 協定則相反﹕它是籍由查詢網路上其它主機而得到自己的 IP 位址.
通常﹐我們使用的乙太網卡﹐在出廠的時候就有生產廠家把網卡的實體位址燒在 ROM 裡面﹐這個位址是不能改變的(某些型號的網路卡﹐或是透過其它技術手段﹐是允許您修改實體位址的)。不管系統是否起來﹐這個位址都會存在﹐而且要讓系統獲得它也很容易。然而，在一些無磁碟(diskless)工作站上面﹐系統檔案都存放在遠端的伺服器﹐當它在啟動的時候﹐因為本身沒有 IP 位址﹐也就無法和伺服器溝通﹐更不能將系統檔案載入。那麼﹐我們就必須要有一個辦法﹐讓這樣的無磁碟工作站在和伺服器溝通之前獲得自己的 IP 位址。RAPR 協定就是為解決此問題而設計出來的.
RARP 也是用廣播的形式來進行查詢. 只不過這時候問的 IP 位址不是別人而是自己的 IP 位址而已. 我們可以從下圖看出 RARP 的運作﹐其實和 ARP 是極其相似的 :
首先是查詢主機向網路送出一個 RARP Request 廣播封包﹐向別的主機查詢自己的 IP。在時候﹐網路上的 RARP 伺服器就會將發送端的 IP 位址用 RARP Reply 封包回應給查詢者。這樣查詢主機就獲得自己的 IP 位址了.
然而不像 ARP﹐查詢主機將 RARP Request 封包丟出去之後﹐可能得到的 RARP Reply 會不止一個 (在 ARP 查詢中﹐我們可以確定只會獲得一個回應而已)。因為網路上可能存在不止一台 RARP 伺服器(基於備份和分擔考量﹐極有可能如此設計)﹐那麼﹐所有收到 RARP 請求的伺服器都會嘗試向查詢主機作出 RARP Reply 回應。如果這樣的話﹐網路上將充斥這種 RARP 回應﹐做成額外的負荷。這時候﹐我們有兩種方法來解決RARP 的回應問題 :
PROXY ARP :
代理 (Proxy) ARP 通常用來在路由器上代為回答在它後面的某個網路主機的 ARP 請求。這是一種欺騙手法﹐因為查詢端會以為目標主機就是路由器本身﹐但事實上﹐機器是在另一個網路裡面. Proxy ARP 常使用於遠端連接網路(如撥接)環境中。例如在本地網路中有一台撥接主機﹐提供其他主機撥接上來連接本地網。當本地主機要查詢遠端撥接主機的 ARP 請求的時候﹐因為它的廣播封包是無法到達遠端的﹔此時撥接伺服器就可以代替遠端主機回答這個 ARP 請求﹐然後本地主機就將封包送給撥接伺服器﹐伺服器再將封包傳給遠端主機.
ARP 指令 :
假如您要在 Linux 系統上驗證一下前面所學的理論﹐只要您的網路功能已經設好﹐您可以用 arp 命令來檢查當前的 ARP 表格內容 :
在 Linux 系統中﹐輸入 arp 帶一個 -n 的參數﹐是將資料用數字(number)的形式顯示﹐否則它將嘗試用 DNS 或其他主機對應方式來顯示 IP 所對應的主機名稱。大家可以很輕易在每一行資料中找到 IP 位址和實體位址的對應﹐同時還有硬體類型等信息.
假如此時您下一個 ping 命令﹐連接一台沒有在 ARP 表格中出現的 IP :
此時您再次輸入 arp 命令的話﹐您將發現新主機的 ARP 資料 :
如果您把這台主機從網路上斷開﹐確定它不會再發送 ARP 請求或作出 ARP 回應﹐那麼過大約 20 分鐘後再輸入 arp 命令﹐您很可能發現許多 ARP 記錄都已經消失了﹐這就是資料存活倒數計時的後果. 假如您的 Linux 系統還裝有封包擷取軟體﹐如 tcpdump ﹐您可以在此期間抓些封包看看﹐細心點就能看出 ARP Request 和 ARP Reply 的過程.
您如果還有興趣的話﹐還可以找些更強勁的封包擷取工具(如﹕snifit)﹐把 ARP 封包的所有細節都抓出來看看。不過這裡暫時不做這樣的動作了。至於如何檢查封包的每一個細節﹐我們將在後面介紹 IP 和 TCP 封包的時候再介紹.
我們用 arp 不僅能查看當前的 ARP 記錄﹐而且我們還可以用 arp 命令來建立 ARP 記錄﹐例如﹐我們前面提到過的 Proxy ARP 功能﹐我們可以用中間的路由器來「隱藏」兩端的網路 :
上面 arp 命令中的 -s 參數就是用來設定 (set) 一個 ARP 記錄的。接著在輸入 arp 命令﹐就會發現剛纔設定的資料旗標為 MP 。這樣﹐當另一端網路要查詢 211.20.240.115 的時候﹐這個 Linux 路由器就能夠代為回應了.
ARP 之 RFC 文件 :
ARP 的詳細資料可以查詢 RFC-826﹑RFC-814﹑以及 RFC-1166 等文件。而 RARP 的資料則可以參考 RFC-903﹑RFC-906﹑還有 RFC-1293 等文件.
訂閱：
文章 (Atom)
[Git 常見問題] error: The following untracked working tree files would be overwritten by merge
Source From Here 方案1： // x -----删除忽略文件已经对 git 来说不识别的文件 // d -----删除未被添加到 git 的路径中的文件 // f -----强制运行 # git clean -d -fx 方案2： 今天在服务器上 gi...
-
CNN 卷積神經網路簡介 STEP1. 卷積神經網路介紹 CNN 卷積神經網路可以分成兩大部分: * 影像的特徵提取 : 透過 Convolution 與 Max Pooling 提取影像特徵. * Fully connected Feedforward n... -
Understanding the core indexing classes : As you saw in our Indexer class ( A simple application ), you need the following classes to...
-
前言 : 在暑假作業學長要求寫一個對 RS232 讀寫的程式. 在 Java Google 到的解決方法有兩個. 一個是透過 Java Communications . 底下是官方網站對該 API 說明的部分擷取 : The Java Communica...
