網絡應用(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)標識的?，F在，我們知道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)。運行在PC機上的郵件閱讀器還實現了多個應用層協議的客戶端，典型的有用于發送郵件的SMTP協議的客戶端.以及用于檢索郵件的某個郵件檢索協議(例如POP3或IMAP)的客戶端。

　　應用所需的服務

　　我們知道套接字是應用進程和傳輸協議之間的接口。發送端的應用進程通過這扇門送出消息。在門的另一側，傳輸協議負責把這些消息跨網絡傳送到接收進程的門口。包括因特網在內的許多網絡體系結構提供不止一個傳輸協議。在開發應用程序時，必須選擇一個可用的傳輸協議。如何進行選擇呢?最可能的情形是，先研究一下由可用的傳輸協議提供的服務，再選出其服務與應用程序的需求最為匹配的協議。這種情形類似于在兩個城市之間旅行時選擇乘火車還是乘飛機。你只能選擇其中一種運輸方式，而每種方式提供的服務是不同的(例如火車提供市區載客服務.飛機提供更短的運輸時間)。

　　網絡應用可能要求傳輸協議提供什么樣的服務呢?我們可以把網絡應用的服務需求按以下3個尺度粗略地進行劃分:可靠性、帶寬、實時性。

　　可靠性

　　有些應用要求完全可靠地傳送數據，也就是說不能有數據丟失，例如電子郵件、文件傳送、遠程主機訪問、Web文檔傳送、財務應用等。丟失文件數據或財務交易數據的災難性后果是可想而知的。另有一些丟失容忍應用(lose-tolerant application)可以容忍一定數量的數據丟失，例如實時音頻/視頻或倉儲音頻/視頻等多媒體應用。在丟失容忍的多媒體應用中，數據的丟失可能會在播放出的音頻/視頻中引入短時脈沖干擾，不過不是至關緊要的損傷。數據丟失對于應用質量的影響以及實際可容忍的分組丟失量強烈依賴于應用本身及所用的編碼方案。

　　帶寬

　　有些應用必須以特定的持續速率傳送數據才會有效。例如，如果某個因特網電話應用32Kbps的速率編碼語音，那么它必須能夠以同樣的速率把數據發送到網絡，再由網絡遞送到接收應用。如果得不到這個數量的帶寬，應用就得以一個較低的速率編碼，還得獲取足以維持這個編碼速率的帶寬，否則只能放棄，因為對于這樣的帶寬敏感應用(bandwidth-sensitive application)來說，僅僅得到所需帶寬的一半是沒有用的。許多當前的多媒體應用對帶寬敏感，不過將來的多媒體應用可能用上自適應編碼技術，能夠以與當前的可用帶寬相匹配的速率編碼。帶寬敏感應用需要一個給定數量的帶寬，而與之相對的是，彈性應用(elastic application)卻可以根據臨時可用量隨多隨少地使用帶寬。電子郵件、文件傳送、遠程訪問、web傳送等都是彈性應用。當然帶寬肯定越高越好。

　　實時性

　　諸如因特網電話、虛擬環境、遠程電話會議、多方游戲等交互式實時應用要求數據的遞送滿足嚴格的定時限制，以此保證有效。這些應用中有許多要求端到端的延遲在數百毫秒或以下的數量級。例如，因特網電話中的長延遲往往導致交談中不自然的停頓:在多方游戲或虛擬交互環境中，從采取行動到看見來自環境的響應之間的長延遲(譬如說在某個端到端連接結束時才看到來自另一個玩家的響應)將使得應用感覺起來不大現實。對于非實時應用來說，低延遲總比高延遲可取，不過它們不會對端到端延遲施加任何嚴格的限制。

　　下表匯總了一些流行的和新興的因特網應用的可靠性、帶寬和實時性需求。這僅僅是一些較為流行的因特網應用的若干關鍵需求的概要。我們的目的并不是提供網絡應用需求的一個完整分類，而是簡單地標識出可由此將網絡應用需求歸類的幾個最重要的軸。

　　表1：一些網絡應用的服務需求

　　因特網(更一般地說，TCP網絡)給應用程序提供兩個傳輸協議:用戶數據報協議(UserDatagram Protocol，UDP)和傳輸控制協議(Transaction Control Protocol，TCP)。當開發人員創建一個新的因特網應用時，他必須選擇UDP或TCP這兩個協議之一用于該應用。這兩個協議給應用提供不同的服務模型。

　　由因特網傳輸協議提供的服務

　　TCP服務

　　TCP服務模型包括面向連接的服務和可靠的數據傳輸服務。調用TCP作為其傳輸協議的應用同時取得這兩種服務。

　　面向連接的服務指的是客戶端和服務器端的TCP在開始傳輸應用層消息之前，先交換傳輸層控制信息。這個所謂的握手過程警示客戶和服務器，以便它們為來自對方的分組沖擊做好準備。握手階段結束之后，我們說這兩個進程的套接字之間存在一個TCP連接(TCP connection)。這是一個全雙工的連接，也就是說客戶和服務器這兩個進程可以同時通過該連接向對方發送消息。完成消息的發送后，應用進程必須告知TCP拆除這個連接。稱這種服務為“面向連接”服務而不是“連接”服務(或者說“虛電路”服務)的理由在于，它兩端的進程是以非常松散的方式連接的。

　　可靠的傳輸服務指的是彼此通信的進程可以依賴TCP無錯地順序遞送所有數據。當其中任何一個應用進程把一個字節流傳入套接字時，它可以指望TCP把同樣的字節流遞送到對方的套接字，中間不會有字節的丟失或重復。

　　TCP還包含一個擁塞控制機制，它是因特網的一種公益服務，其目的不在于讓彼此通信的進程直接受益。TCP擁塞控制機制在網絡變得擁塞時抑制發送進程(可以是客戶，也可以是服務器)。確切地說，TCP擁塞控制試圖把每個TCP連接限定在它所公平共享的網絡帶寬內。對于有最小帶寬需求限制的實時音頻和視頻應用來說，抑制傳輸率會有很壞的后果。此外，實時應用可容忍數據丟失，不需要完全可靠的傳輸服務。由于這些原因，實時應用程序的開發人員通常設計成在UDP而不是TCP上運行他們的應用。

　　概述完TCP提供的服務后，我們說一下TCP沒有提供的服務。首先，TCP不保證最小傳輸率。具體地說，TCP不允許發送進程以想要的任意速率發送;相反，發送速率受到TCP擁塞控制的調節，發送進程有可能被迫以一個較低的平均速率發送。其次，TCP不提供任何延遲保證。具體地說，發送進程把數據傳入自己的TCP套接字之后，這個數據將最終到達其接收套接字，然而就該數據花多長時間到達那兒來說，TCP絕對不作保證?；◣资肷踔翈追昼姷却齌CP從web服務器往Web瀏覽器遞送一個消息(例如，其中含有一個HTML文件)也非罕見?？傊?，TCP保證遞送全部數據，但對遞送速率和所經歷的延遲不加保證。

　　UDP服務

　　UDP是一個不提供非必要服務的輕量級傳輸協議，具有一個最簡約的服務模型。UDP是無連接的，因此兩個進程彼此通信之前沒有握手過程。UDP提供不可靠的數據傳輸服務，也就是說當一個進程往自己的UDP套接字發出一個消息時，UDP不能保證這個消息會最終到達接收套接字。另外，就確實到達接收套接字的消息而言，它們的到達順序也可能與發送順序不一致。

　　UDP不包含擁塞控制機制，因此發送進程能夠以任意速率往UDP套接字傾注數據。盡管不能保證所有的數據都到達接收套接字，但是仍會有相當比例的數據到達。實時應用程序的開發人員往往選擇在UDP上運行他們的應用。與TCP類似，UTP也不提供任何延遲保證。

　　下表指出了一些流行的因特網應用所用的傳輸協議。我們看到，電子郵件、遠程終端訪問、web和文件傳送都使用TCP。這些應用選擇TCP的主要原因在于TCP提供可靠的數據傳輸服務，能夠保證所有數據最終到達其目的地。我們還看到，因特網電話一般運行在UDP之上。一個因特網電話應用的兩端都得以某個最小速率跨網絡發送數據:與TCP相比，UDP更可能滿足這個要求。另外，因特網電話應用可容忍數據丟失，因此并不需要由TCP提供的可靠數據傳輸服務。

　　表2：流行的應用及采用的協議

　　我們已經指出，TCP和UDP都不提供定時保證，這是不是意味著時間敏感的應用不能運行在當今的因特網上呢?其答案顯然是否定的——時間敏感的應用已在因特網上存在好多年了。這些應用往往工作得相當出色，因為它們已被設計成能夠盡最大程度地對付這種缺乏保證的服務。盡管如此，當延遲過大時(這在公共因特網中是常事)，最聰明的設計也有其局限?？傊?，當今的因特網通常能夠為時間敏感的應用提供滿意的服務，但不能提供任何定時或帶寬上的保證。

　　本文準備介紹的網絡應用

　　因特網上，公眾域和專屬的應用層出不窮。我們不想百科全書式地羅列一大堆因特網應用，于是選了少數幾個既重要且流行的應用集中討論。我們將具體地討論4個流行的應用:Web、文件傳送、電子郵件、目錄服務。我們首先討論web，其原因不僅在于web是一個極其流行的應用，還在于它的應用層協議(即HTTP)相對簡單，可用于闡明網絡協議的許多關鍵因素。接下來討論文件傳送，因為其協議與HTTP恰好形成對照，使得我們可以強調一些額外因素。我們還討論電子郵件，它是因特網中第一個高度流行的應用。應該看到，現代的電子郵件使用不止一個應用層協議。Web、文件傳送和電于郵件有共同的服務需求:需要可靠的傳輸服務，沒有特別的定時需求，能接受彈性帶寬服務。TCP提供的服務完全滿足這3個應用。域名系統(Domain Name System，DN5)是我們討論的第4個應用，它為因特網提供目錄服務。多數用戶不會直接與DNS打交道;相反，他們通過其他應用(包括即將討論的那3個應用)間接求助于DNS。DNS精妙地展示了可以怎樣在因特網中實現分布式數據庫。這4個即將討論的應用對時間都不大敏感。