網(wǎng)絡(luò )應用(network application)是計算機網(wǎng)絡(luò )之所以存在的理由。要是我們設想不出任何有用的網(wǎng)絡(luò )應用，那就沒(méi)有必要設計支持它們的網(wǎng)絡(luò )協(xié)議了。不過(guò)，過(guò)去30年內已有不少人設計出大量精妙的網(wǎng)絡(luò )應用。這些應用既包括從20世紀80年代流行起來(lái)的基于文本的經(jīng)典應用，例如遠程計算機訪(fǎng)問(wèn)、電子郵件、文件傳送、新聞組、聊天等;也包括近些年來(lái)所謂的多媒體應用，例如Web、因特網(wǎng)電話(huà)、視頻會(huì )議、音頻/視頻點(diǎn)播等。
盡管網(wǎng)絡(luò )應用品種繁多是有許多彼此交錯的部件，其軟件卻幾乎總處于核心地位。網(wǎng)絡(luò )應用的軟件分布于兩個(gè)或以上的端系統(即主機)。例如，Web應用包括彼此通信的兩部分軟件：運行在用戶(hù)的主機(PC機、MAC機、工作站等)中的瀏覽器軟件，以及運行在Web服務(wù)器上的Web服務(wù)器軟件。Telnet應用同樣由分別運行于本地主機和遠程主機中的兩部分軟件構成。至于多方視頻會(huì )議，參與會(huì )議的每臺主機上都運行著(zhù)一部分軟件。
用操作系統的行話(huà)來(lái)說(shuō)，彼此通信的實(shí)際上不是軟件部件(即程序)本身，而是進(jìn)程。我們可以把進(jìn)程看成是在端系統中運行著(zhù)的程序。運行在同一個(gè)端系統上的進(jìn)程彼此間通過(guò)使用進(jìn)程間通信手段通信。進(jìn)程間通信的具體規則由端系統的操作系統決定。本文不關(guān)心同一臺主機內的進(jìn)程間通信，而關(guān)心運行在不同主機(操作系統也可能不一樣)的進(jìn)程間的通信。運行在不同端系統上的進(jìn)程通過(guò)網(wǎng)絡(luò )交換消息彼此通信。發(fā)送進(jìn)程創(chuàng )建消息并將之傳入網(wǎng)絡(luò );接收進(jìn)程收取這些消息，并可能發(fā)送消息作為響應，如下圖所示。每個(gè)網(wǎng)絡(luò )應用都有各自的應用層協(xié)議，它定義在進(jìn)程間交流的消息的格式和順序，以及在送出或收到消息時(shí)采取的行動(dòng)。
應用層是我們著(zhù)手研究協(xié)議的好地方。我們已經(jīng)熟悉依賴(lài)于協(xié)議的許多應用。這將給我們一種似曾相識的感覺(jué)，知道協(xié)議的目的所在，有助于我們了解以后學(xué)習傳輸層協(xié)議、網(wǎng)絡(luò )層協(xié)議和數據鏈路層協(xié)議時(shí)會(huì )碰到的許多同樣的問(wèn)題。
應用層協(xié)議
把網(wǎng)絡(luò )應用和應用層協(xié)議區分開(kāi)來(lái)相當重要。應用層協(xié)議僅僅是網(wǎng)絡(luò )應用的一部分，讓我們看幾個(gè)例子。Web是一個(gè)允許用戶(hù)從Web服務(wù)器按要求取得“文檔”的網(wǎng)絡(luò )應用，web應用由許多部件構成，包括—個(gè)文檔格式的標準(即超文本標記語(yǔ)言HTML)、Web瀏覽器軟件、Web服務(wù)器軟件(例如Apache、IIS服務(wù)器)、一個(gè)應用層協(xié)議。Web的應用層協(xié)議是超文本傳送協(xié)議（HTTP），它定義如何在瀏覽器和web服務(wù)器之間傳遞消息。因此HTTP僅僅是Web應用的一部分。另一個(gè)例于是電子郵件應用。電子郵件應用同樣由許多部件構成，包括安置用戶(hù)信箱的郵件服務(wù)器、讓用戶(hù)閱讀和創(chuàng )建電子郵件消息的郵件閱讀器、一個(gè)定義電子郵件消息結構的標推、一組定義如何在服務(wù)器之間以及服務(wù)器和閱讀器之間傳遞電子郵件消息并解釋其特定部分(例如信頭)的應用層協(xié)議。電于郵件應用的首要應用層協(xié)議是簡(jiǎn)單郵件傳輸協(xié)議（SMTP）。因此SMTP也僅僅是電子郵件應用的一部分。
我們已經(jīng)指出，應用層協(xié)議定義運行在不同端系統上的應用程序進(jìn)程如何彼此傳遞消息。具體地說(shuō)，一個(gè)應用層協(xié)議定義:
●所傳遞消息的類(lèi)型，例如請求消息和響應消息。
●各種消息類(lèi)型的語(yǔ)法，也就是消息中的各個(gè)字段以及它們如何定界。
●各個(gè)字段的語(yǔ)義，也就是各個(gè)字段中的信息的含義。
●確定一個(gè)進(jìn)程何時(shí)以及如何發(fā)出消息或響應所收到消息的規則。
有些應用層協(xié)議是在RFC文檔中詳細說(shuō)明的，也就是說(shuō)它們處于可免費獲取的公眾域。例如，HTTP就可以作為RFC獲取。瀏覽器軟件開(kāi)發(fā)者只要遵循該RFC中定義的規則，其瀏覽器就可以從同樣遵循這些規則的任何web服務(wù)器取得Web頁(yè)面。然而，其他許多應用層協(xié)議卻是專(zhuān)屬的，有意不放在公眾域中。例如，許多現有的因特網(wǎng)電話(huà)產(chǎn)品使用專(zhuān)屬的應用層協(xié)議。
客戶(hù)和服務(wù)器
一個(gè)網(wǎng)絡(luò )應用協(xié)議通常擁有客戶(hù)端(client side)和服務(wù)器端(server side)這兩個(gè)對等的“端”或實(shí)體，它們分別對應運行客戶(hù)程序的客戶(hù)進(jìn)程(簡(jiǎn)稱(chēng)客戶(hù))和運行服務(wù)器程序的服務(wù)器進(jìn)程(簡(jiǎn)稱(chēng)服務(wù)器)，如圖2所示。處于一個(gè)端系統中的客戶(hù)端與處于另一個(gè)端系統中的服務(wù)器端彼此通信。例如，web瀏覽器實(shí)現的是HTTP客戶(hù)端，web服務(wù)器實(shí)現的是HTTP服務(wù)器端。在電子郵件應用中，發(fā)送郵件消息的郵件服務(wù)器扮演SMIP的客戶(hù)端角色，接收郵件消息的郵件服務(wù)器扮演SMTP的服務(wù)器端角色。
對于許多應用來(lái)說(shuō)，它們的客戶(hù)端和服務(wù)器端可以同時(shí)實(shí)現在單臺主機上。就以主機A和主機B之間的一個(gè)Telnet會(huì )話(huà)為例。如果這個(gè)Telnet會(huì )話(huà)是由主機A發(fā)起的(即主機A上有一個(gè)用戶(hù)登錄到了主機B)，那么主機A運行的是該應用的客戶(hù)端，主機B運行的是該應用的服務(wù)器端。相反，如果這個(gè)Telnet會(huì )話(huà)是由主機B發(fā)起的，那么主機B運行的是該應用的客戶(hù)端。用于在兩臺主機之間傳送文件的FTP提供了另外一個(gè)例子。兩臺主機之間一旦啟動(dòng)一個(gè)FTP會(huì )話(huà)，其中任何一臺主機就可以在該會(huì )話(huà)結束之前向另一臺主機傳達文件。盡管如此，我們還是按照幾乎所有網(wǎng)絡(luò )應用的慣常情況，把發(fā)起會(huì )話(huà)的主機標為客戶(hù)。另外，單臺主機實(shí)際上可能同時(shí)作為某個(gè)給定應用的客戶(hù)主機和服務(wù)器主機。例如，郵件服務(wù)器主機同時(shí)運行著(zhù)SMlP客戶(hù)端(用于發(fā)送郵件)和服務(wù)器端（用于接收郵件）。
進(jìn)程間跨網(wǎng)絡(luò )的通信
一個(gè)網(wǎng)絡(luò )應用涉及兩臺不同主機中跨網(wǎng)絡(luò )彼此通信的兩個(gè)進(jìn)程(當然，組播網(wǎng)絡(luò )應用有可能涉及兩臺以上主機間的通信)。這兩個(gè)進(jìn)程通過(guò)經(jīng)由各自的套接字(socket)發(fā)送和接收消息彼此通信。我們可以把套接字看作相應進(jìn)程上的“門(mén)”:進(jìn)程把消息發(fā)送到網(wǎng)絡(luò )或從網(wǎng)絡(luò )接收消息都得經(jīng)過(guò)自身的套接字。當一個(gè)進(jìn)程想給另一臺主機中的另一個(gè)進(jìn)程發(fā)送消息時(shí)，它就把該消息推出自家的門(mén)。該進(jìn)程認定在這扇門(mén)的另一側有一個(gè)傳輸設施會(huì )把這個(gè)消息傳輸到目的進(jìn)程的門(mén)口。
圖3展示了通過(guò)因特網(wǎng)彼此通信的兩個(gè)進(jìn)程間的套接字通信(本圖假設底層的傳輸協(xié)議是TCP，不過(guò)UDP也可以同樣使用)?？梢?jiàn)套接字是單臺主機內應用層和傳輸層之間的接口。套接字也用于指代應用程序和網(wǎng)絡(luò )之間的應用程序接口(application program interface，簡(jiǎn)稱(chēng)API)，因為它又是用于構造因特網(wǎng)中的網(wǎng)絡(luò )應用程序的編程接口。應用程序開(kāi)發(fā)人員可以完全控制套接字的應用層一側，對于套接字的傳輸層一側卻幾乎無(wú)能為力。對于傳輸層一側他們只能控制:(1)傳輸協(xié)議的選擇;(2)諸如最大緩沖區大小和最大片段大小等有限幾個(gè)傳輸層參數的調整。一旦選定某個(gè)可用的傳輸協(xié)議，就使用由該協(xié)議提供的傳輸層服務(wù)來(lái)構造應用程序。
進(jìn)程尋址
要讓一臺主機中的進(jìn)程給另一臺主機中的進(jìn)程發(fā)送消息，發(fā)送進(jìn)程必須能夠識別接收進(jìn)程。用于標識接收進(jìn)程的信息有兩個(gè):(1)接收主機的主機名或主機地址，(2)在接收主機內部識別接收進(jìn)程的標識符。
讓我們先考慮主機地址。在因特網(wǎng)應用中，接收主機是用其IP地址(1P addresse)標識的?，F在，我們知道IP地址是惟一標識每個(gè)端系統的一個(gè)32位二進(jìn)制數值(更準確地說(shuō)，IP地址惟一地標識將各臺主機連接到因特網(wǎng)的網(wǎng)絡(luò )接口)，既然連接到公共因特網(wǎng)的任何端系統的IP地址必須全球惟一，IP地址的分配就必須仔細管理。ATM網(wǎng)絡(luò )的尋址標準則不同于因特網(wǎng)。ITU—T已規定，在公共ATM網(wǎng)絡(luò )中使用稱(chēng)為E.164地址(ITU1997)的類(lèi)似電話(huà)號碼的地址。
除了知道接收進(jìn)程所在端系統的地址外，發(fā)送進(jìn)程還得指定可讓接收端系統把所傳送消息定向到接收進(jìn)程的信息。因特網(wǎng)中用于此目的的是接收進(jìn)程的端口號(port number)。流行的應用層協(xié)議已被賦予特定的端口號。例如，使用HTTP協(xié)議的web服務(wù)器進(jìn)程是以端口號80標識的，使用SMTP協(xié)議的郵件服務(wù)器是以端門(mén)號25標識的。RFC 1700列出了所有因特網(wǎng)標準協(xié)議眾所周知的端口號。在開(kāi)發(fā)新的網(wǎng)絡(luò )應用程序時(shí)，必須賦予它一個(gè)新的端口號。
用戶(hù)代理
再開(kāi)始繼續研究應用層協(xié)議之前，討論一下用戶(hù)代理(user agent)的概念也許有所裨益。用戶(hù)代理是一個(gè)位于用戶(hù)和網(wǎng)絡(luò )應用之間的接口。例如，Web應用的用戶(hù)代理是諸如Netscape Navigator和微軟Internet Explore這樣的瀏覽器。瀏覽器使得用嚴可以觀(guān)看web頁(yè)面、進(jìn)行web沖浪、提供表單輸入、與JAVA小應用程序交互，等等。瀏覽器還實(shí)現了HTTP協(xié)議的客戶(hù)端。因此啟動(dòng)后的瀏覽器除給用戶(hù)提供一個(gè)接口外，其進(jìn)程還同時(shí)在經(jīng)由一個(gè)套接字發(fā)送接收消息。另一個(gè)例子是關(guān)于電子郵件應用的。電子郵件應用的用戶(hù)代理是“郵件閱讀器”，它使得用戶(hù)可以編寫(xiě)和閱讀郵件消息。許多公司提供可運行在PC機、MAC機和工作站上的圖形用戶(hù)界面的郵件閱讀器(例如Eudora，Netscape Messenger，Microsoft outlook)。運行在PC機上的郵件閱讀器還實(shí)現了多個(gè)應用層協(xié)議的客戶(hù)端，典型的有用于發(fā)送郵件的SMTP協(xié)議的客戶(hù)端.以及用于檢索郵件的某個(gè)郵件檢索協(xié)議(例如POP3或IMAP)的客戶(hù)端。
應用所需的服務(wù)
我們知道套接字是應用進(jìn)程和傳輸協(xié)議之間的接口。發(fā)送端的應用進(jìn)程通過(guò)這扇門(mén)送出消息。在門(mén)的另一側，傳輸協(xié)議負責把這些消息跨網(wǎng)絡(luò )傳送到接收進(jìn)程的門(mén)口。包括因特網(wǎng)在內的許多網(wǎng)絡(luò )體系結構提供不止一個(gè)傳輸協(xié)議。在開(kāi)發(fā)應用程序時(shí)，必須選擇一個(gè)可用的傳輸協(xié)議。如何進(jìn)行選擇呢?最可能的情形是，先研究一下由可用的傳輸協(xié)議提供的服務(wù)，再選出其服務(wù)與應用程序的需求最為匹配的協(xié)議。
這種情形類(lèi)似于在兩個(gè)城市之間旅行時(shí)選擇乘火車(chē)還是乘飛機。你只能選擇其中一種運輸方式，而每種方式提供的服務(wù)是不同的(例如火車(chē)提供市區載客服務(wù).飛機提供更短的運輸時(shí)間)。
網(wǎng)絡(luò )應用可能要求傳輸協(xié)議提供什么樣的服務(wù)呢?我們可以把網(wǎng)絡(luò )應用的服務(wù)需求按以下3個(gè)尺度粗略地進(jìn)行劃分:可靠性、帶寬、實(shí)時(shí)性。
可靠性
有些應用要求完全可靠地傳送數據，也就是說(shuō)不能有數據丟失，例如電子郵件、文件傳送、遠程主機訪(fǎng)問(wèn)、Web文檔傳送、財務(wù)應用等。丟失文件數據或財務(wù)交易數據的災難性后果是可想而知的。另有一些丟失容忍應用(lose-tolerant application)可以容忍一定數量的數據丟失，例如實(shí)時(shí)音頻/視頻或倉儲音頻/視頻等多媒體應用。在丟失容忍的多媒體應用中，數據的丟失可能會(huì )在播放出的音頻/視頻中引入短時(shí)脈沖干擾，不過(guò)不是至關(guān)緊要的損傷。數據丟失對于應用質(zhì)量的影響以及實(shí)際可容忍的分組丟失量強烈依賴(lài)于應用本身及所用的編碼方案。
帶寬
有些應用必須以特定的持續速率傳送數據才會(huì )有效。例如，如果某個(gè)因特網(wǎng)電話(huà)應用32Kbps的速率編碼語(yǔ)音，那么它必須能夠以同樣的速率把數據發(fā)送到網(wǎng)絡(luò )，再由網(wǎng)絡(luò )遞送到接收應用。如果得不到這個(gè)數量的帶寬，應用就得以一個(gè)較低的速率編碼，還得獲取足以維持這個(gè)編碼速率的帶寬，否則只能放棄，因為對于這樣的帶寬敏感應用(bandwidth-sensitive application)來(lái)說(shuō)，僅僅得到所需帶寬的一半是沒(méi)有用的。許多當前的多媒體應用對帶寬敏感，不過(guò)將來(lái)的多媒體應用可能用上自適應編碼技術(shù)，能夠以與當前的可用帶寬相匹配的速率編碼。帶寬敏感應用需要一個(gè)給定數量的帶寬，而與之相對的是，彈性應用(elastic application)卻可以根據臨時(shí)可用量隨多隨少地使用帶寬。電子郵件、文件傳送、遠程訪(fǎng)問(wèn)、web傳送等都是彈性應用。當然帶寬肯定越高越好。
實(shí)時(shí)性
諸如因特網(wǎng)電話(huà)、虛擬環(huán)境、遠程電話(huà)會(huì )議、多方游戲等交互式實(shí)時(shí)應用要求數據的遞送滿(mǎn)足嚴格的定時(shí)限制，以此保證有效。這些應用中有許多要求端到端的延遲在數百毫秒或以下的數量級。例如，因特網(wǎng)電話(huà)中的長(cháng)延遲往往導致交談中不自然的停頓:在多方游戲或虛擬交互環(huán)境中，從采取行動(dòng)到看見(jiàn)來(lái)自環(huán)境的響應之間的長(cháng)延遲(譬如說(shuō)在某個(gè)端到端連接結束時(shí)才看到來(lái)自另一個(gè)玩家的響應)將使得應用感覺(jué)起來(lái)不大現實(shí)。對于非實(shí)時(shí)應用來(lái)說(shuō)，低延遲總比高延遲可取，不過(guò)它們不會(huì )對端到端延遲施加任何嚴格的限制。
下表匯總了一些流行的和新興的因特網(wǎng)應用的可靠性、帶寬和實(shí)時(shí)性需求。這僅僅是一些較為流行的因特網(wǎng)應用的若干關(guān)鍵需求的概要。我們的目的并不是提供網(wǎng)絡(luò )應用需求的一個(gè)完整分類(lèi)，而是簡(jiǎn)單地標識出可由此將網(wǎng)絡(luò )應用需求歸類(lèi)的幾個(gè)最重要的軸。
因特網(wǎng)(更一般地說(shuō)，TCP網(wǎng)絡(luò ))給應用程序提供兩個(gè)傳輸協(xié)議:用戶(hù)數據報協(xié)議(UserDatagram Protocol，UDP)和傳輸控制協(xié)議(Transaction Control Protocol，TCP)。當開(kāi)發(fā)人員創(chuàng )建一個(gè)新的因特網(wǎng)應用時(shí)，他必須選擇UDP或TCP這兩個(gè)協(xié)議之一用于該應用。這兩個(gè)協(xié)議給應用提供不同的服務(wù)模型。
由因特網(wǎng)傳輸協(xié)議提供的服務(wù)
TCP服務(wù)
TCP服務(wù)模型包括面向連接的服務(wù)和可靠的數據傳輸服務(wù)。調用TCP作為其傳輸協(xié)議的應用同時(shí)取得這兩種服務(wù)。
面向連接的服務(wù)指的是客戶(hù)端和服務(wù)器端的TCP在開(kāi)始傳輸應用層消息之前，先交換傳輸層控制信息。這個(gè)所謂的握手過(guò)程警示客戶(hù)和服務(wù)器，以便它們?yōu)閬?lái)自對方的分組沖擊做好準備。握手階段結束之后，我們說(shuō)這兩個(gè)進(jìn)程的套接字之間存在一個(gè)TCP連接(TCP connection)。這是一個(gè)全雙工的連接，也就是說(shuō)客戶(hù)和服務(wù)器這兩個(gè)進(jìn)程可以同時(shí)通過(guò)該連接向對方發(fā)送消息。完成消息的發(fā)送后，應用進(jìn)程必須告知TCP拆除這個(gè)連接。稱(chēng)這種服務(wù)為“面向連接”服務(wù)而不是“連接”服務(wù)(或者說(shuō)“虛電路”服務(wù))的理由在于，它兩端的進(jìn)程是以非常松散的方式連接的。
可靠的傳輸服務(wù)指的是彼此通信的進(jìn)程可以依賴(lài)TCP無(wú)錯地順序遞送所有數據。當其中任何一個(gè)應用進(jìn)程把一個(gè)字節流傳入套接字時(shí)，它可以指望TCP把同樣的字節流遞送到對方的套接字，中間不會(huì )有字節的丟失或重復。
TCP還包含一個(gè)擁塞控制機制，它是因特網(wǎng)的一種公益服務(wù)，其目的不在于讓彼此通信的進(jìn)程直接受益。TCP擁塞控制機制在網(wǎng)絡(luò )變得擁塞時(shí)抑制發(fā)送進(jìn)程(可以是客戶(hù)，也可以是服務(wù)器)。確切地說(shuō)，TCP擁塞控制試圖把每個(gè)TCP連接限定在它所公平共享的網(wǎng)絡(luò )帶寬內。對于有最小帶寬需求限制的實(shí)時(shí)音頻和視頻應用來(lái)說(shuō)，抑制傳輸率會(huì )有很壞的后果。此外，實(shí)時(shí)應用可容忍數據丟失，不需要完全可靠的傳輸服務(wù)。由于這些原因，實(shí)時(shí)應用程序的開(kāi)發(fā)人員通常設計成在UDP而不是TCP上運行他們的應用。
概述完TCP提供的服務(wù)后，我們說(shuō)一下TCP沒(méi)有提供的服務(wù)。首先，TCP不保證最小傳輸率。具體地說(shuō)，TCP不允許發(fā)送進(jìn)程以想要的任意速率發(fā)送；相反，發(fā)送速率受到TCP擁塞控制的調節，發(fā)送進(jìn)程有可能被迫以一個(gè)較低的平均速率發(fā)送。其次，TCP不提供任何延遲保證。具體地說(shuō)，發(fā)送進(jìn)程把數據傳入自己的TCP套接字之后，這個(gè)數據將最終到達其接收套接字，然而就該數據花多長(cháng)時(shí)間到達那兒來(lái)說(shuō)，TCP絕對不作保證?；◣资肷踔翈追昼姷却齌CP從web服務(wù)器往Web瀏覽器遞送一個(gè)消息(例如，其中含有一個(gè)HTML文件)也非罕見(jiàn)?？傊?，TCP保證遞送全部數據，但對遞送速率和所經(jīng)歷的延遲不加保證。
UDP服務(wù)
UDP是一個(gè)不提供非必要服務(wù)的輕量級傳輸協(xié)議，具有一個(gè)最簡(jiǎn)約的服務(wù)模型。UDP是無(wú)連接的，因此兩個(gè)進(jìn)程彼此通信之前沒(méi)有握手過(guò)程。UDP提供不可靠的數據傳輸服務(wù)，也就是說(shuō)當一個(gè)進(jìn)程往自己的UDP套接字發(fā)出一個(gè)消息時(shí)，UDP不能保證這個(gè)消息會(huì )最終到達接收套接字。另外，就確實(shí)到達接收套接字的消息而言，它們的到達順序也可能與發(fā)送順序不一致。
UDP不包含擁塞控制機制，因此發(fā)送進(jìn)程能夠以任意速率往UDP套接字傾注數據。盡管不能保證所有的數據都到達接收套接字，但是仍會(huì )有相當比例的數據到達。實(shí)時(shí)應用程序的開(kāi)發(fā)人員往往選擇在UDP上運行他們的應用。與TCP類(lèi)似，UTP也不提供任何延遲保證。
下表指出了一些流行的因特網(wǎng)應用所用的傳輸協(xié)議。我們看到，電子郵件、遠程終端訪(fǎng)問(wèn)、web和文件傳送都使用TCP。這些應用選擇TCP的主要原因在于TCP提供可靠的數據傳輸服務(wù)，能夠保證所有數據最終到達其目的地。我們還看到，因特網(wǎng)電話(huà)一般運行在UDP之上。一個(gè)因特網(wǎng)電話(huà)應用的兩端都得以某個(gè)最小速率跨網(wǎng)絡(luò )發(fā)送數據:與TCP相比，UDP更可能滿(mǎn)足這個(gè)要求。另外，因特網(wǎng)電話(huà)應用可容忍數據丟失，因此并不需要由TCP提供的可靠數據傳輸服務(wù)。
我們已經(jīng)指出，TCP和UDP都不提供定時(shí)保證，這是不是意味著(zhù)時(shí)間敏感的應用不能運行在當今的因特網(wǎng)上呢?其答案顯然是否定的——時(shí)間敏感的應用已在因特網(wǎng)上存在好多年了。這些應用往往工作得相當出色，因為它們已被設計成能夠盡最大程度地對付這種缺乏保證的服務(wù)。盡管如此，當延遲過(guò)大時(shí)(這在公共因特網(wǎng)中是常事)，最聰明的設計也有其局限?？傊?，當今的因特網(wǎng)通常能夠為時(shí)間敏感的應用提供滿(mǎn)意的服務(wù)，但不能提供任何定時(shí)或帶寬上的保證。
本文準備介紹的網(wǎng)絡(luò )應用
因特網(wǎng)上，公眾域和專(zhuān)屬的應用層出不窮。我們不想百科全書(shū)式地羅列一大堆因特網(wǎng)應用，于是選了少數幾個(gè)既重要且流行的應用集中討論。我們將具體地討論4個(gè)流行的應用:Web、文件傳送、電子郵件、目錄服務(wù)。我們首先討論web，其原因不僅在于web是一個(gè)極其流行的應用，還在于它的應用層協(xié)議(即HTTP)相對簡(jiǎn)單，可用于闡明網(wǎng)絡(luò )協(xié)議的許多關(guān)鍵因素。接下來(lái)討論文件傳送，因為其協(xié)議與HTTP恰好形成對照，使得我們可以強調一些額外因素。我們還討論電子郵件，它是因特網(wǎng)中第一個(gè)高度流行的應用。應該看到，現代的電子郵件使用不止一個(gè)應用層協(xié)議。Web、文件傳送和電于郵件有共同的服務(wù)需求:需要可靠的傳輸服務(wù)，沒(méi)有特別的定時(shí)需求，能接受彈性帶寬服務(wù)。TCP提供的服務(wù)完全滿(mǎn)足這3個(gè)應用。域名系統(Domain Name System，DN5)是我們討論的第4個(gè)應用，它為因特網(wǎng)提供目錄服務(wù)。多數用戶(hù)不會(huì )直接與DNS打交道;相反，他們通過(guò)其他應用(包括即將討論的那3個(gè)應用)間接求助于DNS。DNS精妙地展示了可以怎樣在因特網(wǎng)中實(shí)現分布式數據庫。這4個(gè)即將討論的應用對時(shí)間都不大敏感。
