TCP/IP
TCP/IP 的歷史發展
一、TCP/IP的歷史發展
TCP/IP的由來，與網際網路的歷史發展有著絕對密切的關係。1967年，美國國防部為了奠定國內電腦網路的技術，成立了國防高等研究計劃站(Defense Advanced Research Project Agency, 簡稱DRAPA)，針對相關的實驗和研究提供研究經費。也就從那個時候開始，美國高等研究規劃網路(Advanced Research Project Agency NETwork, 簡稱ARPANET)開始萌芽，這便是今日網際網路的濫觴。自1969年開始，ARPANET以實驗性的分封交換系統連接電腦，網際網路最初是採用主從架構，但後來決定使用用主機對主機(Host-to-Host)的網路控制協定(NCP, Network Control Protocol)。(註25)
為了要讓網際網路能連接各式各式各樣的主機，因此美國國防部便要求建立一個通信協定，使得不論採用何種廠牌的傳輸媒體、何種型式的的存取法則，都可以相互連接並進行傳輸。1973年，TCP協定組合由Bob Kahn開始發展，然後由DARPA、Vinton Cerf、及史丹佛大學接續開發。1970年代末期，TCP的開發已經完成了大部分，而TCP/IP的名稱也正式出現。
到了1980年代，ARPANET上的所有機器均已採用TCP/IP協定。1983年，DARPA資助柏克萊大學把TCP/IP整合到UNIX上，此整合產品是一項成功的產品，並且使TCP/IP成為標準。1985年，美國國家基金會(NSF, National Science Foundation)開始籌募基金，期望建造一個骨幹來連接大學與研究機構，此骨幹稱為NSFnet，它取代了ARPANET，成為了國際網路的骨幹，而NSFnet亦延續採用TCP/IP做為主要的傳輸通信協定。而在此同時，TCP/IP協定組也繼續發展，並規劃出一套測試與驗證的準則，以確定發展廠商是否符合TCP/IP標準。TCP/IP標準是公開的，發展者可免費獲得，不需特別的許可權。換句話說，使用TCP/IP即可保證其相連性與共同運作的可能。(註26)
今日，網際網路已深入全球，成為全球連的龐大通信網，而依據網際網路的特性而發展的TCP/IP，由於具備強大的網路互連功能以及開放性的特色，在今日世界各地均有極大的使用率，可說是目前被利用最廣的通信協定。
二、TCP/IP的規格描述與相關組織
TCP/IP協定規格描述－RFCs (Requests for Comments)
(一) TCP/IP協定規格描述－RFCs (Requests for Comments)
RFC可說是TCP/IP和Internet發展及成長的基石，所有有關於TCP/IP和網際網路的規格、協定內容、會議記錄、發展歷史等文件資料都以RFC數字編號的方式，由美國網路資訊中心(Network Information Center, 簡稱NIC)所收集。例如RFC1000即介紹了一些RFC的歷史，以及各種RFC的分類。
若有人對於改進TCP/IP現有能力有新的想法時，可以寫一個計劃案發表在網際網路上，這個計劃案是即所謂的RFC。RFC的作者都是自願的，其創作得不到任何報償。每個RFC會被賦予一個號碼，此號碼為一遞增的數字，絕不會被重新指定。更新的RFC有更高的數字編號，並使得舊的RFC成失效，因此若發現在不同的文件中討論的是相同的主題的話，應以編號較高的RFC為依據。另外，亦可能有自願的評論者則對RFC作建設性的批評與意見，原作者可據以校訂原先的設計使之更加完美。若一切無問題，該項RFC便成為起草標準(Draft Standard)，程式設計人員就可依該份標準來設計軟體，實作出其所描述的功能。在真正的程式碼出現之前，RFC都不被認定是正式標準。(註27)
圖四顯示了一個RFC標準形成的步驟：(註28)
圖四：RFC標準的形成
資料來源：Stephen A Thomas, IPng and the TCP/IP Protocols : Implementing the Next Generation Internet, (New York : Wiley Computer Publishing, 1996), 465; 中文部分由筆者自譯之.
(二) TCP/IP的相關組織
目前對有關網際網路與TCP/IP的管理研究工作是由網際網路工作委員會(Internet Activities Board, 簡稱IAB)來進行推動。IAB成立於1980年代，屬於非營利機構，負責技術的針和策略的擬定，以及管理工作的導引協調，例如有關TCP/IP的發展、決定那些協定是否能成為TCP/IP的一員、在何時可以成為標準，以及網際網路的演進、網路系統與通信技術之研發等工作。在IAB之下，有研究小組及工作小組兩個主要的單位，並有一些小型指導群，共同進行設定標準及決定策略的工作。IAB的組織架構可以圖五來說明：(註29)
圖五：IAB的組織架構
資料來源：林榮松，「Internet與TCP/IP的由來與發展」，網路通訊雜誌 第22期 (民國82年5月)：頁155。
三、TCP/IP的階層架構與協定組
TCP/IP在設計之初，即定義了三大類的服務：(註30)
連線服務：運作於網路最底層，指示資料如何自一台電腦經由網路連線媒介傳遞到另一台電腦。連線服務並不保證資料能以正確的順序抵目的地，甚至無法保證資料能到達目的地。
傳輸服務：運作於網路中間層，可增強上述的連線服務，以提供完整可靠的通訊品質。
應用服務：位於網路最高層，可讓一台電腦上的應用程式與另一台電腦上類似的程式交談，執行如檔案拷貝、上傳下載等工作。應用服務必須靠連線服務和傳輸服務來達到可靠而有效率的服務品質。
TCP/IP，顧名思義，是由TCP與IP兩個主要協定所組合而成的。但在實際上，它是由許多協定所組成的協定組(Protocol Suit)，每一類型的服務目前都有開發出來的應用協定實際運作著，並執行某些特定的工作，若使用其中一個協定，無法成就一個可運作的網路。不過，在整個協定堆疊中，還是有許多不常用到的通信協定。
TCP/IP雖然定義了三大類的服務，但它實際上並未包含實體網路技術的層次與協定，而目前TCP/IP的服務大多是架在OSI所定義的實體層(Physical Layer)以及資料鏈結層(Data-Link Layer)之上。
綜合上述，TCP/IP的階層架構，及其對應的一些主要協定，可以圖六來表示：
圖六：TCP/IP的階層架構與相關協定組
以下舉出一個TCP/IP服務的運作實例：(註31)
當某人寄了一封電子郵件給朋友後，TCP/IP必須告訴網路裝置如何做到以下幾件工作：
將友人的名字轉成TCP/IP格式的位址。這是連線服務在運作。
產生封包，並於封包上註明從那裡到那裡。這是傳輸服務在運作。
確定訊息正確無誤地到達友人處，當訊息的所有封包都扺達後，再重組成原來的樣子)。這是傳輸服務在運作。
將該份郵件遞送給友人本人。這是應用服務在運作。
資料在TCP/IP上是以封包的形式來傳送的。一個TCP/IP封包是由表頭區和資料區所組成，而每一階層的協定都有其自己的表頭區定義，並有特定的程式負責解讀表頭區的欄位，以瞭解對方的需求並採取適當的處置。所以一個完整的TCP/IP封包，由內而外會包括了連線服務、傳輸服務、應用服務、以及實體網路技術等四層表頭。資料從應用程式開始就一層層地加上表頭，完整的TCP/IP封包經由實體的網路傳輸到對方的主機，而接收方再一層層地將封包表頭拆解開來，最後的原始資料才傳送到接收者的手中。整個傳輸的程序可以圖七來表示：(註32)
圖七：TCP/IP資料傳輸程序
資料來源：方盈編著，TCP/IP通訊協定：理論與實務，(台北市：博碩，民國86年)，頁2-9。
以下分別對每一個服務階層中的常用協定作一概念性的介紹：
TCP/IP的階層架構與協定組/連線服務 |
(一) 連線服務
連線服務/網際網路協定
1. 網際網路協定(Internet Protocol, 簡稱IP)
IP的主要目的是為了提供通訊子網之間的連接，以形成可傳輸資料的網際網路。它提供了下列幾個主要的功能：(註33)
定址(Addressing)：(註34)為了使資料能在不同類型、不同的傳輸介質及不同的電腦系統間有效地傳輸，通信協定必須定制一套通用的定址方法來辨別網際網路中的每一台主機。理想的標定格式必須能提供足夠的跨網資訊且不佔太多的儲存空間，IP利用一個32位元所構成的數值來進行定址，在應用上為了方便表達，我們通常將此數值切為4段，每連續8位元一組。8位元的十進位範圍為0-255，所以寫成四個十進位數字ddd.ddd.ddd.ddd。每一部連上Internet的主機的IP位址都是唯一的，因此必須透過標準單位來統一分配，如全世界的IP位址是由NIC來負責，亞太地區是APNIC，而目前台灣的IP位址是由APNIC之下的TWNIC來負責。IP位址包含路號碼(Network Number)及主機號碼(Host Number)二種資料，並依可容納主機的數量分為五個等級：Class A、 B、C是一般所採用的，Class D為實驗群播(Multicast)的位址，Class E則是為未來而保留的。雖然IP位址的最大容量理論值是47億個(232)，但因分級的關係，實際可用的較理論上少很多。目前網際網路所遇到的瓶頸之一即是IP位址即將耗盡，而已有許多研究者在嘗試發展下一代IP(IP next generation, 簡稱IPng)以解決這個問題。
封包的切割(Fragmentation)和再組合(Reassamble)：由於在封包傳送過程中可能會跨越不同架構的實體網路，而每一實體網路都有定義的最大封包大小的限制(Maximum Transfer Unit, 簡稱MTU)，所以在傳送的過程中有時必需將封包切割成數個較小的個體才能將它繼續往目的地傳送。所有封包的切割與再組合是屬於連線服務中IP的工作。
尋徑(Routing)：IP可以幫助資料封包尋找、解決傳送的路徑，負責決定一個封包要經由怎麼樣的路線才能到達目地的。
IP主要具有下列特性：(註35)
非連接導向(Connectionless)：每個資料封包都視為是互相獨立毫無關連的，所走的路徑可能會完全不相同，也不保證先送的一定會先到達。
不可信賴性(Unreliable)：送出去的IP封包並不保證一定會送到對方的手中，亦即資料往某個方向送出之後，就不再理會資料的下落。此方式具有機動性高及效率高的優點，但送出的封包若在途中被損毀或遺失，接收端將無法得知其下落。
盡力傳送(Best-Effort Delivery)：由於每個發送者並不管資料以後的下場，為避免資料找不到收信者，而在網路中流浪形成負擔，每個封包的傳送均給序一個生命期(Finite Packet Lifetime)，即計算一定時間之後，若還未找到收信者，封包便會自動消失。
連線服務/網際網路控制訊息協定
2. 網際網路控制訊息協定(Internet Control Message Protocol, 簡稱ICMP)
ICMP的主要目的是用來發出網路問題或錯誤狀態之報告，並轉送特定的網路資訊。I P封包在傳送時若偵測到錯誤，便會將它傳給ICMP。ICMP封包是嵌在IP封包中的資料區部分，當網際網路上的某一個閘道發現它手上的封包由於某種原因而無法往下一個目的地傳送時，ICMP會根據錯誤的狀況發送一個”Destination Unreachable”的封包給最原始的發送者，說明封包無法傳達到最終目的地的原因，並把該原始含資料的封包丟棄。(註36)
連線服務/位址解決協定
3. 位址解決協定(Address Resolution Protocol, 簡稱ARP) (註37)
IP對的網路上每個節點都定義了唯一的位址，提供給較高階層的網路程式設計者作為識別之用，使其省去瞭解低階層程式運作的麻煩。但是，封包的傳輸必須經由最底層網路介面卡來收送，而網路介面卡並不懂得什麼是IP位址，必須靠網路的硬體位址來識別。這就如同我們在寄信時，若只寫收信者的名字(IP位址)，是無法寄達對方的手中的，還必須寫上對方的地址(實際位址)才可以。相對地，如果我們只寫了地址而不寫名字的話，信雖然能到達目的地，但卻會成為一封無主信件。
因此，ARP協定便因此而產生：它定義了IP位址與硬體位址間的對映與轉換，當已知對方的IP位址時，透過它便可得知其實際的網路位址，以便將資料封包送到對方手上。ARP的設計原理是利用廣播(Broadcasting)的方式，若某主機A欲送出一資料封包給另一主機B，而又只知道它的IP位址時，它就會在網路上廣播一個ARP request封包來詢問B的實際位址，主機在B收到此一訊息之後就會回送一個ARP reply封包給A，上面有它自己的硬位址資料。如此，A就可知道B的實際位址了。
但是，若使用者在每次有資料要傳送時便做一次ARP的廣播詢問，會使網路無法負荷，因此，網路上的每一主機在自己的快取空間或記憶體中都會維護一份ARP table，儲存一些常用的位址轉換資訊，主機在傳送資料之前，先在ARP table中查詢是否有其所需資訊，如此可以滅少大量ARP request封包的數量，並提高資料傳輸的效率。不過， ARP table的容量有限，無法將所有主機的硬體位址包括進來，因此其管理和維護必須依系統的特性及需要，找尋一個最佳的策略。
連線服務/反位址解決協定
4. RARP反位址解決協定(Reverse Address Resolution Protocol)
RARP的功能與ARP是相對的，其最主要的工作是經由詢問網路上其它主機而得知自己或其它主機的IP位址。舉例來說，若某主機A不知道自己的IP位址，RARP便會廣播一個RARP request封包到網路上詢問其他主機，藉此方式來得到解答。不過，雖然A只需要一個RARP reply，但是透過此方法，網路上知道A的IP位址的主機都會送出一個RARP reply封包，會造成不必要的網路負擔。因此，RARP可將各主機作等級上的區分，訂定回答的優先權，如此就不會造成多餘的RARP reply充斥在網路上。
TCP/IP的階層架構與協定組/傳輸服務 |
(三) 傳輸服務
傳輸服務/傳輸控制協定
1. 傳輸控制協定(Transmission Control Protocol, 簡稱TCP)
TCP的主要任務是負責發送端及收受端的協定建立，建立超越通信子網間的傳送。它使用IP來傳送封包給上一層的應用程式，並保證資料在網路上的流動安全可靠。簡言之，TCP具有下列幾個主要的功能：(註38)
循序編號(Sequence Number)：TCP為每一個封包建立編號，使封包就算不能按照原來的發送順序抵達收受端，也可依此編號正確重組。
確認(Acknowledgement)：接收端針對發送端所傳來的每一封包，回送「我已收到」的確認封包，類似郵政掛號中「回執」的概念。
檢查(Checksum)：TCP在每個封包的表頭中加上一個檢查欄位，以確認其是否為欲傳送的原始封包。如果封包到了接收端卻發現檢查值不合，即表示封包發展了錯誤或損毀，因此接收端就無法發出確認的封包。
重送(Restransmission)：發送端如果在某一預定的時間內沒有收到該確認封包，就會認定封包傳送失敗，於是重送該封包，直到收到該封包抵達收受端確認訊息為止。
在使用TCP進行資料傳輸時，必須先建立起兩者之間的連線關係。TCP連線的建立是透過帶有連線控制訊息的封包在兩端主機間傳遞，再藉由TCP表頭中的循序編號和錯誤檢查值的檢查正確無誤，經一番交談後，雙方乃同意進入連線狀態。經由此連線請求、連線確認、連線成功的程序，便形成了三向式的握手協定(3-way handshaking)(註39)，而斷線時也是採用相似的程序：斷線請求、斷線確認、斷線成功。
歸結上述的功能，TCP具有以下特性：(註40)
連接導向(Connection-Oriented)：在資料發送時，兩端會建立起虛擬電路，讓資料能有跡可循地往下傳送。所以，TCP是屬於連接導向的，傳輸的雙方必須先做溝通，確認連線建立後才可傳送資料。
可靠性(Reliable)：TCP以確認、重送、檢查三個觀念來完成可靠性的資料傳輸。它利用TCP封包表頭內的某些欄位來控制資料確實地傳送到對方，而在資料遺失時，TCP則會要求發送端重新傳送。
全雙工式通訊(Full Duplex)：(註41)封包一旦扺達正確的IP位址，TCP就開始在發送端和接收端的電腦上，為正被傳送的資料建立起對話(Dialog)，而兩端可以分別進行資料的收發。由於此全雙工的特性，使得確認回執的工作可以輕易地達成。
資料流(Stream)：TCP是以資料流型的傳輸型態來傳送資料，也就是說，資料像流水般有次序地從本端主機流向遠方主機，而遠端主機則依序自資料流中讀取資料，將它傳給應用程式去處理。但是，當某些資料必須優先處理時，接收端就會進入緊急狀態(Urgent Mode)，開始接收緊急資料(Urgent Data)。每個TCP封包可攜帶一長串的資料，而不是一個位元、一個位元地傳送。
有了TCP，資料傳輸的可靠性由它來處理即可，上層的應用程式只要把要傳送的資料透過介面丟給TCP匯流排，而不必煩惱資料如何正確無誤地傳送到對方的手裡。應用程式當然還是可以直接利用IP在自己的程式裡控制資料傳輸的可靠性，但這樣做會造成上層應用程式的負擔，程式也較不容易維護。基於網路上分層處理及程式設計模組化的觀念，最好還是透過TCP來做可靠性的資料傳輸。(註42)
TCP協定是一個十分重要且較複雜的通訊協定，有許多在它上層的應用協定如TELNET、FTP等，都是依據它的功能而發展出來的。
傳輸服務/使用者資料元協定
2. 使用者資料元協定(User Datagram Protocol, 簡稱UDP)
UDP在運作時採用了一個重要的概念—通訊端點位址(Port)。雖然IP是識別不同主機的唯一標記，但我們若僅使用一個IP位址，在某些環境下並不足以明確地指定資料接收端的身分，這是因為每個主機可能有多個使用者同時使用，而每個使用者又可能會同時產生好幾個作業程序(Process)。因此，如果我們能在每一使用者啟動一個網路應用軟體時便指定一個Port號碼給它(通常是一個2 位元整數)，如此就可以真正明確地區分發送端和接收端的角色了。因此，「IP位址+port號碼」便是網路上一個通訊端點的明確定義。(註43)
但是，IP中並沒有定義Port的欄位，為了使資料的傳輸能有Port的概念，TCP/IP便在IP層上面架構了UDP：(註44) IP負責將封包經由網際網路傳至對方主機，UDP則將收到的封包分發給不同的應用程式或作業程序。UDP不提供錯誤檢查，也不執行封包的排序，亦不會在資料發生錯誤時重新傳送資料，不過使用UDP的應用程式可以自行設計將上述的功能加入程式中。由上述可知，UDP具有無連接導向(Connectless)及不可信賴性(Unreliable)的特點。
我們可以將UDP比喻成寫信：若是寄平信，我們並不能確定這封信一定能送到對方的手中，因為信可能會在半途被弄丟或截走；而TCP則可以比喻為打電話：必須先經對方的同意(對方必須在家而且肯接電話)才有可能開始通訊，在通話期間，如果對方講話太小聲以至於無法聽清楚，就隨時可以要求對方重講直到聽清楚為止。
TCP相當於是UDP的功能再加上可靠性傳輸的控制。因為TCP需要有控制傳輸可靠性的額外負擔，因此對於某些較不重要的資料傳輸(如E-MAIL)，一般利用UDP來做就可以了，而如FTP、TELNET等對傳輸內容要求絕對正確的應用層協定，則非用TCP來做不可。(註45)
TCP/IP的階層架構與協定組/應用服務 |
(四) 應用服務
支援TCP/IP應用服務層的協定十分地眾多，在此僅介紹幾種目前比較常見且常用的協定：
應用服務/遠程載入
1. 遠程載入(Remote Login)：TELNET
TELNET是一個終端機模擬程式，可將本端主機模擬成遠端主機的終端機，利用TCP連線的功能來傳送本端主機上傳和遠端主機下傳的資料。TELNET提供了一個雙向通訊工具，作為主機與主機、或主機與個人電腦間溝通的介面。任何一端利用TELNET協定所建立的連線，即被視為網路中的伺服端(Server)與用戶端(Client)，或主機(Host)與終端機(Terminal)間的關係，讓使用者能載入(Login)遠方主機的作業系統，進行檔案的編輯、查詢檔案內容、或執行主機上的應用程式等工作。(註46)
應用服務/檔案傳輸
2. 檔案傳輸(File Transfer)
(1) 檔案傳輸協定(File Transfer Protocol, 簡稱FTP)
FTP採用易懂的文字命令和回應訊息，使得網路上對檔案服務有需求的用戶端，和遠方執行檔案服務的伺服端得以交談，並對伺服端所在檔案系統進行上傳下載、存取、刪除及查詢檔案等作業，以達到資源共享的目的。(註47)但是，它通常會對不同使用者的存取權限某些限定。
FTP是架在TCP之上的，所以有關資料傳輸可靠性和連線的處理都在已傳輸層達成，而剩下的任務則是一些有關檔案型別、檔案結構和傳輸模式等協商工作。綜言之，FTP具有以下優點：(註48)
提供可靠且快速的檔案傳輸。
使檔案資源能被更充分地利用。
不同的檔案系統間也能共享檔案。
(2)簡單檔案傳輸協定 (Trivial File Transfer Protocol, 簡稱TFTP)
TFTP可以說是FTP的簡易版本，它的功能主要是傳送小型檔案。以無磁碟機的工作站來說，因為它沒有自己的磁碟機，所以開機用的程式一定要先從伺服器上載入，此時就必須靠TFTP來運作。但TFTP不能像FTP可以隨意變更工作目錄，也不能增加或刪除檔案或目錄，只能從作檔案的讀取或傳送。另外，TFTP也沒有嚴密的使用者確認程序，因此為了防止重要資料的流失，它限制使用者只能讀取某些目錄之下的檔案。(註49)
不過，TFTP在傳送上還是具有許多的優點：(註50)它所傳送的資料長度有最大值的限制，所以較能掌握記憶空間的調配；另外，TFTP只須建立一個通道就可進行資料與命令的傳送，在管理上簡單易控制，不必像FTP需要建立兩個通道。
大部分的TFTP都是架在UDP上執行，由於UDP對於資料是否流失、資料是否被重複傳送等效率和可靠性上的問題，都不做任何的補救，因此TFTP必須負起這些責任，其採取的方法是在每個命令送出後，有一個空間(Buffer)保留這些命令，對方收到資料後，會回送一個確認的訊息給發送端，而若接收端收到的是錯誤訊息命令，則為防止無法結束的情況發生，就不再回送一個確認給發送端，而直接結束傳送資料的動作。
應用服務/訊息處理
3. 訊息處理(Electronic Mail Transfer )
(1)簡單郵件傳輸協定(Simple Mail Transfer Protocol, 簡稱SMTP)
SMTP是一個讓使用者與使用者之間傳輸郵件的協定。在整個傳輸過程中，郵件伺服器是唯一必須維持啟動狀態的機器，同一網路中各使用者的信箱皆集中其上。伺服器等待郵遞用戶前來與之建起通訊線路，以便提供信件傳遞、讀取、轉寄等服務，使用者可以在任何時候對伺服器提出要求，而不必為了接收不定時的來信，讓機器一直保持在開啟的狀態。(註51)只要能連結上伺服器，使用者隨時隨地均可享受SMTP所提供的服務。
如果在傳送郵件時，指定的接收端無法接收的話，郵件伺器將會稍後再試。在試著傳送幾次之後，如果仍然不成功的話，它將會刪除該訊息，或者將訊息送回給傳送者。(註52)
(2) 多目的網際網路郵件延伸協定(Multipurpose Internet Mail Extensions Protocol, 簡稱MIME)
MIME是一種在網際網路上使用ASCII資料規格來遞送非ASCII資料規格的協定。換句話說，透過MIME，網際網路郵件程式可以以純文字信件來傳送程式、影像、聲音、圖片等其他二進位(Binary)檔案格式。例如，當郵件程式接收到包含一個MPEG影像檔的MIME信件時，它會從信件的文字中重建原始的MPEG資料來為新的播放作準備。(註53) MIME超越了簡單收送電子郵件訊息的能力，豐富了網際網路的資料型態，同時能和既有的郵件傳送程式相容，即使它們是以純文字為主要環境。
郵件程式會檢視信件的表頭(message headers)，來決定信件是否包含ASCII文字或MIME資料。MIME的運作程序，簡單地來說就是數據的轉換：如影像檔等二進位檔案經網際網路的電子郵件傳輸時，需先轉換成文字檔(即Encode)，然後再傳輸出去；反之，收信的一方則需將已編碼的檔案還原成原來的二進位檔。此編碼與解碼的方式即是由MIME來規範。(註54)
應用服務/網路管理
4. 網路管理 (Network Management)：簡易網路管理協定(Simple Network Management Protocol, 簡稱SNMP)
SNMP是由IETF所提出的，其主要功用是解決各廠商所供應的網路系統間複雜的網路管理問題。目前SNMP所提供的監控功能是獨立於TCP/IP之外，因此SNMP可建置在各種網路媒體及各種通訊協定之上。對於不需即時性的應用來說，SNMP是個有效且經濟的解決方案，也由於它的建置容易及成本低廉，絕大多數的廠商都提供了SNMP代理伺服器。(註55)
SNMP的網管架構植基於三個主要元件：(註56)
管理者(Manager)：指位於網路管理站之程式，管理者可使用SNMP之指令來向代理者查詢。
代理者(Agent)：指置於被管理之網路設施的程式，掌理有關的管理資料，以提供管理者查詢之需。
管理資訊庫(Management Information Base, 簡稱MIB)：指由網路管理需要的資料項目所組成的虛擬資料庫。
管理者是在網路管理工作站上執行的軟體，使用UDP協定送出請求訊息，而代理者則與管理資訊庫交談，並提供回應訊息給管理者。在分散式的多廠牌網路環境中，管理必須存取不同的管理資訊庫及其參數值，以完成網路管理功能。(註57)
IETF為了提昇速度、安全性及系統管理等能力，又發展了第二版的，即SNMPv2。它具有網路安全管理、管理者與管理者間的通訊等重要功能，也將支援TCP/IP以外的網路協定。但是，SNMPv2在目前並不與SNMP相容，且由於它的架構較複雜，建構成本也較高，所以，SNMPv2必須先解決與SNMP的相容問題，並提供與其他標準相合及低建置成本的能力，才較可能有良好的發展。(註58)
應用服務/領域名稱服務
5. DNS 領域名稱服務 (Domain Name Service)
雖然IP位址的表示方式已十分地清楚，但對人們而言，數字所代表的意義畢竟還是不能與文字相比。所以，我們便以主機名稱(Host Name)或領域名稱(Domain Name)來指涉主機。在網際網路中有上百萬的主機，為了方便管理，人們採用樹狀結構來進行分類，如圖八所示(註59)。每個節點(Node)代表一個領域或主機，除了根節點為空標籤外，其餘每個節點皆有一個英文標籤以為名稱，愈往下的節點，其所涵蓋的領域範圍愈狹窄。網際網路允許一個領域或主機可以擁有數個領域名稱，但其中必須有一個正規名稱，其他為別名，以方便記憶及了解其所提供服務之類型。
圖八：領域名稱的樹狀結構
資料來源：方盈編著，TCP/IP通訊協定：理論與實務，(台北市：博碩，民國86年)，頁2-9。
每台主機同時具有IP位址與領域名稱，IP位址是給電腦分類用的，領域名稱則是給人分類用的。對TCP/IP而言，領域名稱必須被轉為IP位址才會被認得，所以就有了DNS的產生。簡單地說，DNS是一種目錄服務，它負責為電腦搜尋並找出對應的IP位址，反之亦同。由於要保有網際網路上所有電腦位址資訊的所需空間非常龐大，因此必須要有許多個名稱伺服器一起工作，將名稱轉換成地址。目前DNS的作法是採用分散式資料庫為架構，所有的領域名稱資料階層式地散布在許多領域名稱伺服器中，提供查詢服務。而傳統的主機則用來儲存一些位於本地網域，或是較常用的領域名稱對照表，以加快查詢效率。(註60)
(四) 協定組的依存關係DNS的組成元件包括了分散式資料庫、網域、名稱伺服器、委託器、解答者、系統管理員及網路管理員等部分。在設計其服務時，DNS必須考慮一致性與效率問題：在效率問題上，可採用分散資料庫、快取空間、以及備份等技巧的來提昇查詢速度；而在一致性上，由於為提昇效率而有快取及備份等方法，因此各領域名稱伺服器之間必定會有短時間內資料不一致的狀況存在。(註61)
以上所介紹的眾多協定，其相互間的依存關係可如圖九所示：(註62)
圖九：TCP/IP協定組的依存關係
資料來源：周明天、汪文勇編著，TCP/IP網路原理與技術，(台北巿：儒林，民國84年)，頁440。
最底部是硬體介面。TCP/IP在這一層次採用現有的協定標準，包括各邏輯鏈路控制和介質存取等多種協定。而正是最低層協定的紛繁複雜，體現了TCP/IP協定的包容性和適應性，為TCP/IP的成功奠定了基礎。
在連線服務層中，IP的重要性是不可否認的。在圖九中，只有IP是橫跨整個階層的(它既可建立在ARP與RARP之上，也可直接建立在硬體介面協定上)，這意味著所有上層軟體都必須經由IP層傳輸外出封包，而所有下層協定所接收到的進入訊息也必須先交給IP處理。這樣的特點充分體現了IP在TCP/IP分層結構中的重要作用，作為通用的封包傳輸手段，IP可以說是TCP/IP協定組的核心。(註63)而ARP與RARP可作為實體位址和IP位址間的界面，有著隱藏實體位址細節的重要作用，所以特別將它提出，不過事實上除了ARP與RARP之外，還有許多地址解析的方式。在一般情況下，ARP多用於乙太網路，RARP則很少用到。
傳輸服務層中的TCP與 UDP是屬於相同階層的協定，兩者的地位是並行的，沒有從屬的關係。TCP提供可靠資料流服務的連接導向的傳輸協定，而UDP則是簡單的非連接式協定；TCP適用於多分封傳輸的場合，如大檔案傳輸、遠程登錄作業等；而UDP適用於事務處理型的場合，如遠程聯機訂票等；TCP特別強調可靠性，比UDP複雜且功能強大；UDP簡潔實用，易於實現，如果通信子網能提供足夠的可靠性，則使用UDP將獲得可觀的效率。TCP與UDP各有其長短，所以各應用程式可以根據其資料傳輸的性質和對可靠性的要求來選擇不同的資料傳輸手段。(註64)
四、TCP/IP的特色應用服務的相關協定很多，其依賴關係相當複雜，這種現象與具體應用的種類繁多有著密切的相關。應用層協定可分為三類：(註65)一類依賴於連接導向式的TCP，如TELNET、FTP、SMTP等(其中FTP既依賴於TELNET又依賴於TCP)；一類依賴於非連接導向式的UDP，如SNMP、TFTP等；另一類則可同時依賴於兩者，如DNS。而應用程式與其他協定則可能會有三種依賴關係：(註66)依賴於上述標準應用層協定(呼叫它們所提供的庫存函數)、直接依賴於TCP或UDP協定、抑或是依賴於IP協定。
綜合上述，TCP/IP特色可歸結為以下幾點：
允許開放式的存取，應用範圍廣泛：使用者不需要受限於選擇某家廠商的產品來配合使用，具有獨立性的網路技術(Network Technology Independence)。(註67)其應用範圍可以涵蓋各種網路拓蹼、各種傳輸媒介(如雙絞線、光纖等)、各種電信通信網路(如X.25、Novell Netware等)、各種主機(如個人電腦、超級電腦等)、各種作業系統(如UNIX、IBM等)、以及各種不同的軟硬體作業平台(如Oracle等)。
分封交換的傳輸方式：TCP/IP將待傳資料分割成小的訊息封包，再依位址分別傳送，並具有連接導向與非連接導向兩種傳輸方式，可依不同的需求加以選擇。
廣泛性網路連接(Universal Interconnection)：(註68)在同一網路系統中可依據IP進行定址，如需跨越不同的網路系統，只需經由中際系統轉接，亦即用尋徑(Routing)的方式就可以加以連接。
相關協定眾多，技術成熟：TCP/IP具備許多了各種層次、各種功能的協定來提供應用上的選擇，而相關的協定標準與開發技術也已十分成熟。
支援網際網路：TCP/IP主要是在網際網路的環境中開發出來的，因此特別能支援配合其特性和需求，為目前網際網路中所採用的主要協定標準。
註釋 |
註25： 王家輝編著，透視TCP/IP原理與實務，(台北市：和碩，民國82年)，頁6。
註26： 林榮松，「Internet與TCP/IP的由來與發展」，網路通訊雜誌 第22期 (民國82年5月)：頁153-154。
註27： Stephen A Thomas, IPng and the TCP/IP Pprotocols : Implementing the Next Generation Internet, (New York : Wiley Computer Publishing, 1996), 465.
註28： 同上註。
註29： 同註26，頁155。
註30： 威爾斯基(Marshall Wilensky)著；蔡國瑞編譯，TCP/IP的奧秘，(台北巿：松格資訊，民國85年)，頁38。
註31： 同上註，頁38-39。
註32： 同註3，頁2-9。
註33： 納格爾(Matthew G Naugle)著；潘育群、顧金福、與邵喻美合譯，網路協定百科全書，(台北市：和碩，民國85年)，頁309。
註34： 同註17，頁84。
註35： 同註17，頁86。
註36： Sidnie Feit, TCP/IP : Architecture, Protocols, and Implementation with Ipv6 and IP Security, (New York: McGraw-Hill, 1997), 139.
註37： 同註3，頁3-2 – 3-9。
註38： 同註7，頁880。
註39： 同註25，頁99。
註40： Douglas Comer, Internetworking with TCP/IP, (Englewood Cliffs, N.J.: Prentice Hall, 1994), 227.
註41： 同註30，頁68。
註42： 同註3，頁7-3。
註43： Sidnie Feit, TCP/IP: Architecture, Protocols, and Implementation. (N.Y.: McGraw-Hill, Inc, 1993), 166.
註44： 同註30, p.179.
註45： 同註1，頁421。
註46： 許時祝，「TELNET－終端機模擬器的利器」，網路通訊雜誌 第9期 (民國81年4月)：頁170-173。
註47： 史至義，「檔案傳輸協定概論—FTP」，網路通訊雜誌 第10期 (民國81年5月)：頁138。
註48： 同上註，頁138-141。
註49： 許時祝，「TFTP－簡易檔案傳輸協定」，網路通訊雜誌 第12期 (民國81年7月)：頁116。
註50： 同上註，頁119。
註51： Floyd Wilder, A Guide to the TCP/IP Protocol Suite, (Boston: Artech House, 1993), 166.
註52： 史至義。「TCP/IP網路上的郵遞系統」。網路通訊雜誌 第13期 (民國81年8月)，頁157。
註53： 同註40, p.443.
註54： 張竣豪，「豐富網路訊息的MIME」，微電腦傳真 第16卷第3期 (民國86年3月)：頁291。
註55： 劉台斌，「全球網路管理標準之發展分析」，網路通訊雜誌 第42期 (民國84年1月)：頁10。
註56： 莊琮琪，透視SNMP & SNMPv2，(台北市：和碩，民國83年)，頁99。
註57： 同註55。
註58： 同註56，頁246。
註59： 同註17，頁84。
註60： 同註36, p.278.
註61： 同註30，頁159。
註62： 同註1，頁440。
註63： 同註1，頁441。
註64： 同註1，頁425。
註65： 同註40，p.467.
註66： 同註1，頁442。
註67： 洪茂盛、許麗玲，「TCP/IP與OSI通訊協定之介紹」，國民教育 第34期第7/8卷 (民國83年4月)：頁10-11。
註68： 同上註，頁11。
