了解網絡應用與網絡協議

 　　網絡應用(network application)是計算機網絡之所以存在的理由。要是我們設想不出任何有用的網絡應用，那就沒有必要設計支持它們的網絡協議了。不過，過去30年內已有不少人設計出大量精妙的網絡應用。這些應用既包括從20世紀80年代流行起來的基於文本的經典應用，例如遠程計算機訪問、電子郵件、文件傳送、新聞組、聊天等;也包括近些年來所謂的多媒體應用，例如Web、因特網電話、視頻會議、音頻/視頻點播等。

　　盡管網絡應用品種繁多是有許多彼此交錯的部件，其軟件卻幾乎總處於核心地位。網絡應用的軟件分布於兩個或以上的端系統(即主機)。例如，Web應用包括彼此通信的兩部分軟件：運行在用戶的主機(PC機、MAC機、工作站等)中的浏覽器軟件，以及運行在Web服務器上的Web服務器軟件。Telnet應用同樣由分別運行於本地主機和遠程主機中的兩部分軟件構成。至於多方視頻會議，參與會議的每台主機上都運行著一部分軟件。

　　用操作系統的行話來說，彼此通信的實際上不是軟件部件(即程序)本身，而是進程。我們可以把進程看成是在端系統中運行著的程序。運行在同一個端系統上的進程彼此間通過使用進程間通信手段通信。進程間通信的具體規則由端系統的操作系統決定。本文不關心同一台主機內的進程間通信，而關心運行在不同主機(操作系統也可能不一樣)的進程間的通信。運行在不同端系統上的進程通過網絡交換消息彼此通信。發送進程創建消息並將之傳入網絡;接收進程收取這些消息，並可能發送消息作為響應，如下圖所示。每個網絡應用都有各自的應用層協議，它定義在進程間交流的消息的格式和順序，以及在送出或收到消息時采取的行動。

　　圖1：彼此通信的應用

　　應用層是我們著手研究協議的好地方。我們已經熟悉依賴於協議的許多應用。這將給我們一種似曾相識的感覺，知道協議的目的所在，有助於我們了解以後學習傳輸層協議、網絡層協議和數據鏈路層協議時會碰到的許多同樣的問題。

　　網絡應用(network application)是計算機網絡之所以存在的理由。要是我們設想不出任何有用的網絡應用，那就沒有必要設計支持它們的網絡協議了。不過，過去30年內已有不少人設計出大量精妙的網絡應用。這些應用既包括從20世紀80年代流行起來的基於文本的經典應用，例如遠程計算機訪問、電子郵件、文件傳送、新聞組、聊天等;也包括近些年來所謂的多媒體應用，例如Web、因特網電話、視頻會議、音頻/視頻點播等。

　　應用層協議

　　把網絡應用和應用層協議區分開來相當重要。應用層協議僅僅是網絡應用的一部分，讓我們看幾個例子。Web是一個允許用戶從Web服務器按要求取得“文檔”的網絡應用，web應用由許多部件構成，包括—個文檔格式的標准(即超文本標記語言HTML)、Web浏覽器軟件、Web服務器軟件(例如Apache、IIS服務器)、一個應用層協議。Web的應用層協議是超文本傳送協議(HTTP)，它定義如何在浏覽器和web服務器之間傳遞消息。因此HTTP僅僅是Web應用的一部分。另一個例於是電子郵件應用。電子郵件應用同樣由許多部件構成，包括安置用戶信箱的郵件服務器、讓用戶閱讀和創建電子郵件消息的郵件閱讀器、一個定義電子郵件消息結構的標推、一組定義如何在服務器之間以及服務器和閱讀器之間傳遞電子郵件消息並解釋其特定部分(例如信頭)的應用層協議。電於郵件應用的首要應用層協議是簡單郵件傳輸協議(SMTP)。因此SMTP也僅僅是電子郵件應用的一部分。

　　我們已經指出，應用層協議定義運行在不同端系統上的應用程序進程如何彼此傳遞消息。具體地說，一個應用層協議定義:

　　●所傳遞消息的類型，例如請求消息和響應消息。

　　●各種消息類型的語法，也就是消息中的各個字段以及它們如何定界。

　　●各個字段的語義，也就是各個字段中的信息的含義。

　　●確定一個進程何時以及如何發出消息或響應所收到消息的規則。

　　有些應用層協議是在RFC文檔中詳細說明的，也就是說它們處於可免費獲取的公眾域。例如，HTTP就可以作為RFC獲取。浏覽器軟件開發者只要遵循該RFC中定義的規則，其浏覽器就可以從同樣遵循這些規則的任何web服務器取得Web頁面。然而，其他許多應用層協議卻是專屬的，有意不放在公眾域中。例如，許多現有的因特網電話產品使用專屬的應用層協議。

　　客戶和服務器

　　一個網絡應用協議通常擁有客戶端(client side)和服務器端(server side)這兩個對等的“端”或實體，它們分別對應運行客戶程序的客戶進程(簡稱客戶)和運行服務器程序的服務器進程(簡稱服務器)，如圖2所示。處於一個端系統中的客戶端與處於另一個端系統中的服務器端彼此通信。例如，web浏覽器實現的是HTTP客戶端，web服務器實現的是HTTP服務器端。在電子郵件應用中，發送郵件消息的郵件服務器扮演SMIP的客戶端角色，接收郵件消息的郵件服務器扮演SMTP的服務器端角色。

　　圖2：客戶/服務器交互

　　對於許多應用來說，它們的客戶端和服務器端可以同時實現在單台主機上。就以主機A和主機B之間的一個Telnet會話為例。如果這個Telnet會話是由主機A發起的(即主機A上有一個用戶登錄到了主機B)，那麼主機A運行的是該應用的客戶端，主機B運行的是該應用的服務器端。相反，如果這個Telnet會話是由主機B發起的，那麼主機B運行的是該應用的客戶端。用於在兩台主機之間傳送文件的FTP提供了另外一個例子。兩台主機之間一旦啟動一個FTP會話，其中任何一台主機就可以在該會話結束之前向另一台主機傳達文件。盡管如此，我們還是按照幾乎所有網絡應用的慣常情況，把發起會話的主機標為客戶。另外，單台主機實際上可能同時作為某個給定應用的客戶主機和服務器主機。例如，郵件服務器主機同時運行著SMlP客戶端(用於發送郵件)和服務器端(用於接收郵件)。

　　進程間跨網絡的通信

　　一個網絡應用涉及兩台不同主機中跨網絡彼此通信的兩個進程(當然，組播網絡應用有可能涉及兩台以上主機間的通信)。這兩個進程通過經由各自的套接字(socket)發送和接收消息彼此通信。我們可以把套接字看作相應進程上的“門”:進程把消息發送到網絡或從網絡接收消息都得經過自身的套接字。當一個進程想給另一台主機中的另一個進程發送消息時，它就把該消息推出自家的門。該進程認定在這扇門的另一側有一個傳輸設施會把這個消息傳輸到目的進程的門口。

　　圖3展示了通過因特網彼此通信的兩個進程間的套接字通信(本圖假設底層的傳輸協議是TCP，不過UDP也可以同樣使用)。可見套接字是單台主機內應用層和傳輸層之間的接口。套接字也用於指代應用程序和網絡之間的應用程序接口(application program interface，簡稱API)，因為它又是用於構造因特網中的網絡應用程序的編程接口。應用程序開發人員可以完全控制套接字的應用層一側，對於套接字的傳輸層一側卻幾乎無能為力。對於傳輸層一側他們只能控制:(1)傳輸協議的選擇;(2)諸如最大緩沖區大小和最大片段大小等有限幾個傳輸層參數的調整。一旦選定某個可用的傳輸協議，就使用由該協議提供的傳輸層服務來構造應用程序。

　　圖3：應用程序進程、套接字

　　進程尋址

　　要讓一台主機中的進程給另一台主機中的進程發送消息，發送進程必須能夠識別接收進程。用於標識接收進程的信息有兩個:(1)接收主機的主機名或主機地址，(2)在接收主機內部識別接收進程的標識符。

　　讓我們先考慮主機地址。在因特網應用中，接收主機是用其IP地址(1P addresse)標識的。現在，我們知道IP地址是惟一標識每個端系統的一個32位二進制數值(更准確地說，IP地址惟一地標識將各台主機連接到因特網的網絡接口)，既然連接到公共因特網的任何端系統的IP地址必須全球惟一，IP地址的分配就必須仔細管理。ATM網絡的尋址標准則不同於因特網。ITU—T已規定，在公共ATM網絡中使用稱為E.164地址(ITU1997)的類似電話號碼的地址。

　　除了知道接收進程所在端系統的地址外，發送進程還得指定可讓接收端系統把所傳送消息定向到接收進程的信息。因特網中用於此目的的是接收進程的端口號(port number)。流行的應用層協議已被賦予特定的端口號。例如，使用HTTP協議的web服務器進程是以端口號80標識的，使用SMTP協議的郵件服務器是以端門號25標識的。RFC 1700列出了所有因特網標准協議眾所周知的端口號。在開發新的網絡應用程序時，必須賦予它一個新的端口號。

　　用戶代理

　　再開始繼續研究應用層協議之前，討論一下用戶代理(user agent)的概念也許有所裨益。用戶代理是一個位於用戶和網絡應用之間的接口。例如，Web應用的用戶代理是諸如Netscape Navigator和微軟Internet Explore這樣的浏覽器。浏覽器使得用嚴可以觀看web頁面、進行web沖浪、提供表單輸入、與JAVA小應用程序交互，等等。浏覽器還實現了HTTP協議的客戶端。因此啟動後的浏覽器除給用戶提供一個接口外，其進程還同時在經由一個套接字發送接收消息。另一個例子是關於電子郵件應用的。電子郵件應用的用戶代理是“郵件閱讀器”，它使得用戶可以編寫和閱讀郵件消息。許多公司提供可運行在PC機、MAC機和工作站上的圖形用戶界面的郵件閱讀器(例如Eudora，Netscape Messenger，Microsoft outlook)。